|
Do not get me wrong, there are times when termination is the route. Waste no time in releasing destructive team members. The team performs better, not because they are scared that they are next, rather that they are pleased to see some leadership that is stopping the insanity.
Strategic or Tactical
There are more subtle forms of conflict and kinder methods of resolution. Some so subtle the project sponsor is unable to see the conflict and needs help understanding the core problem. For instance, a few years ago I was assigned to a project and had a very difficult time getting people to understand the project was ill defined. The customer's documentation clearly stated the goal of the project was to assess the problems with an existing tool and "stop the bleeding." A tactical solution was a good approach since they were hesitant to invest money in something they may throw away in a few years. Even though this project was listed as tactical, the budget was $1.8 million. The year prior, a similar project was proposed with a budget of only $800,000. Further investigation uncovered statements in the proposal documentation saying, "fifty percent of the code would be reusable." (I am still wondering how they planned to test this.) These seemed a little incongruous with an "extremely tactical project," so I escalated it to the Project Sponsor. Here I ran into something unexpected. The newly assigned sponsor had not been part of the original definition. He put project scope at the top of the triple constraints. The sponsor gets what the sponsor wants, they have the budget.
|
||||||||||||
I shook my head and moved on to initial design meetings. Here the architect defined a solution that entailed moving the system, rather than fixing the existing one, to a different platform and enhancing the product to provide the base functionality. In doing this, multiple tasks were added to the activity list. One, titled "Refactor Struts to JSF," looked as if it was stepping way outside the tactical definition. To help me out, the schedule stretched out and the required budget suddenly jumped $400,000. That did it, this was just wrong.
I put the data that I had into a simple table (Figure 1) to present to executive management. I am sure that the nearly 25% increase in budget caught their attention first, but rest of the data allowed them to draw their own conclusions on the how the project's intent had shifted. Within the course of a couple days, the project sponsor had an epiphany and the project was drastically scaled back.
Evaporating Clouds
Critical chain advocates approach the problem from a very different angle—the evaporating cloud. They actively look for the conflict and focus on the problem's root cause. For instance, let's take the following conflicting opinions:
|
- Letting the team talk to the customer will cause scope creep;
- To gather requirements the team must talk to the customer.
The problem is diagrammed to show the need, translate customer needs into a product, and the resulting logic to get to this result. Figure 2 illustrates this simple case. Boiling the conflict down into two diametrically opposed statements, the analyst can arrive at the conflict and work on the root cause. The theory says at core of the conflict is an incorrect business assumption. In this case, the errant thought may be that the project team will increase scope or an intermediate analyst will be unable to get the correct definition. Proper education and leadership will avert the conflicting concerns. The critical chain team would look for the incorrect assumptions and work at resolving them.
Of course if you fail to resolve it this way, just fire the bastards. (You know I am kidding, right?)
.gif){kind=spacer}
