Irrational Management

Antipattern Name: Irrational Management
Also Known As: Pathological Supervisor, Short-Term Thinking, Managing by Reaction, Decision Phobia, Managers Playing with Technical Toys
Most Frequent Scale: Enterprise
Refactored Solution Name: Rational Decision Making
Refactored Solution Type: Role and Process
Root Causes: Responsibility (the universal cause)
Unbalanced Forces: Management of Resources
Anecdotal Evidence: "Who's running this project?" "I wish he'd make up his bloody mind!" "What do we do now?" "We better clear this with management before we get started." "Don't bother asking; they'll just say no."

Background

Irrational Management covers a range of commonly occurring software project problems that can be traced back to the personalities of the person(s) running the project.

For example, the manager may have obsessive interests in some aspect of the technology or personality limitations that cause them to become ineffective or irrational managers. Irrational management can be viewed as a skewed set of priorities where the manager's personal priorities, no matter how nonsensible, guide the software project in irrational directions.

General Form

The manager (or management team) of one or more development projects cannot make decisions. This may be a personality defect or the result of an obsession with details.

The details may be personal interests or behaviors of the manager, such as technical "toys" or micromanagement. When faced with a crisis, the manager's decisions are knee-jerk reactions rather than carefully thought-out strategies or tactical actions. These reactions often cause further problems. The cycle of indecision and reaction can escalate in frequency and severity of consequences.

The Irrational Management AntiPattern is significantly compounded by a manager's inability to direct development staff. This is also called a lack of good people-management skills, characterized by the inability to:

Recognize staff capabilities, both strengths and weaknesses.
Provide clear objectives that are appropriate to staff skills.
Communicate effectively with staff.

Symptoms And Consequences

The primary symptom of the Irrational Management AntiPattern is project thrashing, an ongoing debate on a critical topic. A decision must be made to allow development staff to progress. Thrashing has several consequences.

Increased staff frustration.
Incremental delays to delivery.
Exploitation by Corncobs.

Typical Causes

The manager lacks the ability to manage:

Development staff.
Other managers.
Development processes.

He or she also has no clear vision and strategy, and therefore:

Cannot make decisions.
Fear of Success
Is ignorant of the true state of project activities and deliverables.

Known Exceptions

There should never be any exceptions to the Irrational Management AntiPattern. However, a "golden child" who possesses guru-level skills that are completely unique in some manner and provides a major technical advantage should be tolerated, while a better and longer-term solution is planned.

Refactored Solution

Follow these guidelines to resolve the Irrational Management AntiPattern:

Admit you have a problem and get help. When managers suffer from one or more of the typical causes, they must first recognize that they have a problem.
Assuming that they are unaware of their situation, the first step is to identify key indicators, the most common of which is that of "finding out the hard way."

For example, rather than technical staff addressing a growing problem and asking for help in dealing with it, the irrational manager finds out only after a problem has reached crisis stage; no one is willing to discuss problems, because doing so never helps. Managers must surround themselves with talented staff (or consultants) who share the complex job of managing and are willing to listen to them.

Understand the development staff. Managers need to understand both the technical skills and the personality traits of their staff members. Awareness of technical skills helps a manager delegate work; awareness of personalities helps a manager designate working relationships.
Provide clear, short-term goals. Easily achievable objectives should be specified for the project. Long-term objectives are necessary, but do not as successfully motivate staff on a daily basis. A manager must ensure that short-term, highly specific objectives are set and that staff understands how they can be achieved.
Share a focus. Project staff must share the purpose of their project to ensure they are all working toward the same goals. The manager must initiate and grow the focus.
Look for process improvement. Recognizing that every project is slightly different from the previous one, a manager must monitor the development processes and improve them where and when necessary. Although these are often small tweaks to make a specific process more pragmatic, they can significantly improve productivity.
Facilitate communication. Whenever a "hot" topic fuels debate, deciding on the way to move forward is best achieved in a facilitated session. To do so:

Identify the key players.
Collect evidence on the debate.
Get clear agreement on the problem(s).
Make sure everyone's voice is heard.
Confirm that the solution options are understood by all.
Agree to the preferred option.
Involve the concerned staff in implementing the solution where possible.

Manage communication mechanisms. E-mail and newsgroups in general are useful communication mechanisms, but both can set people on a winding path of destruction. E-mails can quickly get out of hand, and newsgroups can generate arrogant and aggressive debates.
The solution is to track e-mails and newsgroup postings daily and identify any miscommunications. Talk directly to the involved parties and tell them to stop the electronic debate. If it's important to find a solution, then a facilitated meeting is usually faster and far more effective.

Manage by exception. Extremes are always dangerous, and overmanagement is no exception. Daily meetings and weekly reviews that require a manager's involvement in all threads of a project are examples of over- or micromanagement. Instead, manage by exception; watch, but don't interfere. Allow problems some time to be resolved by others. Step in only when necessary.
Apply effective decision-making techniques. Two rational management techniques from Kepner-Tregoe are particularly effective in software decision making. The first is called situation analysis This technique assists in the organization and management of unstructured and chaotic environments. It can be used on an individual or group basis.
The second is called decision analysis This technique is essential for making decisions objectively. Subjective biases in decision-making processes can have devastating consequences in software projects. We have often seen these kind of biases result in software disasters.

Biases can be generated by friendships, the timing of the sales call, unnecessary platform constraints, and invisible infrastructure constraints.

These two techniques are explained in some depth in the following subsections.

Situation Analysis

The purpose of situation analysis is to identify the highest-priority concerns in a complex situation. A tailored version of this technique contains the following steps:

List all of the concerns. These may include known issues, action items, commitments, technology gaps, and other items. In other words, the list may contain virtually anything that affects the project at hand.
Rate the concerns with respect to three criteria: seriousness, urgency, and growth potential. Use three levels: high, medium, and low.
For example, if the concern is critical to project success, it is highly serious. If the concern must be resolved immediately for the resolution to be effective, it is rated highly urgent. If the seriousness is expected to increase dramatically in time, it is rated as having high growth potential.

Tabulate scores for each item based upon the ratings. Assign numbers to the rating levels: high = 2, medium = 1, and low = 0. For example, a rating of high/medium/low would score 3 points (2 + 1 + 0).
Prioritize the items in terms of the scores. For all of the concerns that score 6, choose the most important, second important, and so forth. Continue the priority assignment with the items scoring 5 and lower, until the entire list of concerns is assigned a priority number.
Assign the items that can be resolved to the appropriate staff. Some items on the list will be controlled by external forces, and it would be unreasonable to expend energy resolving them until the situation changes. Other items must be resolved before others due to dependencies. For the properly qualified staff, the resolution of most items will be straightforward: Program a necessary object, create an analysis model, reduce risk through testing, and so forth. The manager must make the best match of staff resources to the concerns that must be resolved.
Work on the top-priority items on the list. The situation analysis technique works on the principle of addressing first things first and second things never. Using situation analysis, the manager can effectively address the most important issues from among the confusing list of concerns confronting software projects.

Decision Analysis

A tailored process for decision analysis contains these steps:

Define the scope of the decision to be addressed. In other words, the process must begin with a written question to resolve.
Identify alternative solutions for resolving the decision. These can include specific concrete alternatives, such as specific software products or categories of solutions that can be evaluated.
Define the decision criteria. Situation analysis can be used to create this list.
Divide the criteria between the essentials and desirables. The essential criteria are characteristics that must be part of the solution in order for it to be acceptable. If any essential criteria are missing from an alternative, the alternative is disqualified. For this reason, the essential criteria should be a carefully chosen, short list. All other criteria are called desirables, and they must be prioritized. Use the priority assignment process from situation analysis for this purpose, then assign the desirable alternatives a weight. For example, if there are seven criteria, the most important has a weight of 7; the next most important has a weight of 6, and so forth.
Determine whether the alternatives satisfy all the essential criteria. If not, eliminate the unsatisfactory alternatives.
Perform any fact finding. Research to assess the satisfaction of the criteria by each of the alternatives.
Set up a table that displays the alternatives in columns and the criteria in rows. In the table, rank the alternatives for desirable criteria. For example, if there are five alternatives, the best alternative gets a rank of 5; next best gets a rank of 4, and so forth.
Multiply the weights by the ranks to calculate a score for each position in the matrix. Add up the scores in each column to calculate the score for each alternative. The highest scoring alternative is the rational (or best) choice.
Be aware that the rational choice may not be the choice that managers or customers will accept. An important bias or criteria that was not properly reflected in the decision analysis may cause this, in which case, it is important to evaluate the decision criteria. Experiment with the weights on the desirable criteria, and add new criteria until the decision analysis selects the acceptable alternative. Confirm that the resulting criteria and weights match the subjective decision criteria that drive this solution. Perhaps the decision-making authorities will change their criteria to more realistic assumptions when confronted with the actual influence that their biases have on the decision.

Variations

Consultants can be an invaluable resource. They can bring missing knowledge and skills to an organization, and can give advice that is independent of internal politics and detailitis; that is, they can be objective in a charged situation. Consultants can play three key roles in a software project. These categories are based on Block's model for general consulting practice :

Pair of Hands.
Technical Expert.
Management Peer.

Filling the Pair-of-Hands role, the consultant becomes another software developer, similar to that of an ordinary employee. As a Technical-Expert, the consultant resolves problems in a specific domain.

As a Management-Peer, the consultant is an advisor to management, providing a mentoring knowledge transfer from his or her related experience. Although it's professionally rewarding for the consultant to be in the latter two roles, we have seen outstanding results from the Pair-of-Hands role, particularly in rapid prototyping situations with new technologies.

Examples

A manager we worked with came into a project at the halfway point. He did not have an understanding of the staff's skills, nor a good background on the project to date.

When problems occurred, he reallocated staff. This created more serious problems. Staff members were moved onto projects to which they had no previous exposure. This resulted in diminished effectiveness. The situation was partially resolved when the manager left the company.

The new manager was a very strong "people-person" who made sure that employees' skills matched the necessary activities. Unfortunately, the delays already experienced could not be made up for.

In another situation, a project architect (a Corncob) voiced his opinions on C ++ coding standards via e-mail to all project staff. The project had several guru-level C ++ developers who took exception to some of the architect's statements.

This resulted in a two-month e-mail and newsgroup "war." The eventual solution was that the project manager appointed a "tiger team" to resolve the issue. This was a facilitated solution based upon the run-ahead principle. Unfortunately, no precautions were taken to eliminate similar destructive communications on a variety of other topics. The instance was dealt with rather than the overriding problem.

In a third example, a system's integrator project had an irrational management team. The individual managers were owners of their part of the process. This created stovepipe processes with neither coherence nor contiguity. This resulted in various ownership wars.

One war was based on the entrance criteria to move from one phase of the development to the next. This caused a month of thrashing and disagreement, which then diffused focus on emerging development problems. Corporate management had to step in. And because the resolution was enforced from above, it was not sustainable.

The final solution, after several wars between the owners, was the appointment of a process facilitator whose job was to ensure that:

A coherent and contiguous process was produced.
The entrance criteria were agreed on for each phase of the development, which supported iterative delivery.
Process improvements were implemented across the relevant processes.