In the best of all possible worlds, our world is a stable, predictable, and understandable place. A place where the business case methodology I described in my last post works flawlessly. In this world:
Our executives are the best of all possible decision-makers and they have at their disposal all the information they need to make the best of all possible decisions. Not only can the merit of our business case be proven beyond a shadow of a doubt, but we can also produce the best of all possible project plans that prescribes every step we need to take to achieve perfect success at minimum cost. Centralized command and control assures that all significant decisions are made early and by those most qualified to make them. The implementation itself is treated as fungible work and shopped-out to the lowest-cost provider.
In the best of all possible worlds, our business case methodology is the best of all possible business case methodologies. It may even be a good choice when we occupy the second best of all possible worlds, maybe even in the third best. At some point, however, we encounter a world where predictions are dicey and no matter how hard we try we can never fully comprehend it. In this world:
Our executives may do their damnedest but may not always be the best. The information they possess is incomplete and sometimes incorrect and they are lucky if they have enough time to make a good decision much less the best one possible. Yet we must proceed.
Under these conditions, mistaken judgments are likely to infect our decision making process and result in sub-optimal, even poor conclusions. Unfortunately, our business case methodology was designed to work in the best of all possible worlds — not in some second-rate universe where faulty information and flawed judgments are not anomalies. Consequently it has few provisions for avoiding or recovering from mistakes and, as we have seen, once these mistakes are codified in a project charter they are nearly impossible to reverse, even as they grow ever more pronounced.
When I was in high school I was exposed to the Greek tragedy Oedipus Rex. I didn’t get it. If the oracle clues everybody in up front about the bad stuff that happens later on, why is this considered great drama? Now, many years later, I get it. It’s not surprise that gives the play dramatic impact; it’s that you know what is going to happen and THERE IS NOTHING YOU CAN DO TO STOP IT. Certainly, anyone with children knows what I’m talking about. You plead with them to not do something stupid, remembering as you do how your parents pleaded with you to not do the same stupid thing. Grimly you become aware something bad is going to happen and there is nothing you can do but watch the MARCH of the DOOMED. It’s that much worse when the doomed know they are doomed but have no choice but to march on. This we have seen on many projects (especially software development projects). The team knows that the project is doomed and they have known it for a long time, but there is nothing anyone can do to change course because way back when the project charter was formed the fate of the project and theirs along with it was determined once and for all.
How might a business case methodology designed for an imperfect world compare with one that assumes the world is perfect? First let’s start with the traditional approach. We start with making a judgment call that determines whether or not we have enough information to decide that proceeding with the project is a good idea. If we decide to proceed, we codify the findings in a project charter, which dictates the terms for the implementation team to follow during the project. Otherwise we don’t proceed with the project. This works great when there is sufficient knowledge to make good decisions. However, if knowledge is insufficient (i.e. under uncertain conditions), we risk making an incorrect judgment and once the judgment call is made, mistaken or not, it’s nearly impossible to reverse.
Our alternative approach works as follows: If we decide that we don’t know enough (i.e. conditions are uncertain) to confidently make a go/no decision, we defer final judgment, produce a tentative charter, and proceed with the first increment of the project. After the first increment is completed, we review what we have learned. We then make our next judgment. We may decide we now know enough to complete the business case and stop the project after the first increment. Or we may decide to defer final judgment again, revise our charter in light of new information, and proceed with the next project increment. We continue in this fashion until we decide it to make the final judgment, which completes the business case decision. We then either end the project or authorize the project to continue according to finalized charter. Management judgments are made incrementally on the basis of new information that comes from the incremental project implementation. Management can keep open the option of ending the project at any time or authorize the project to proceed without further management intervention, once uncertainty has been reduced to an acceptable level.
One of the key differences between the two approaches is that in the first case, the full judgment about whether the complete project should proceed is made before the project begins and once that decision is made it’s difficult to reverse. In the second case, although an initial judgment is made to do the first project increment, the final judgment on whether or not the project should continue is deferred and revised on the basis of new information discovered over the course of the project. In fact, the business case decision may not be fully resolved until the project is nearly complete. We can compare the two management decision style perspective.
|Traditional management decision style||Agile management decision style|
|Assumption: Know all you need to know before project starts||Assumption: Must start project before all critical knowledge is known & learn as you go|
|Important decisions made before project starts||Important decisions deliberately deferred & made incrementally|
|Executive makes significant decisions; team follows orders (command & control)||Executive & team collectively contribute to joint decision making|
|Go/no go decision all or nothing||Incremental go/no go decision|
|Outcome is fully realized before you begin project||Outcome is refined as the project proceeds|
|Plan & charter once authorized final||Plan & charter assumed to be tentative & need to be continuously re-affirmed and/or revised|
It is well known that incremental delivery is a cornerstone of agile project management. What is not as clear is that to get the full benefit of Agile delivery it should be complemented with an Agile management decision style. This is especially evident in the business case decision, since this is where the world of project methodology and management decision making clearly intersect.
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 United States License.