The Crucial “Go/No Go” Decision
Jun 12th, 2005 by phil
When a new project is started at an organization there is a time where everyone is figuring out what is going on. Initial requirements are gathered and the team is assembled. After that there is a phase of discovery where the requirements are fleshed out, risks are identified and estimates are refined. The RUP refers to these phases as Inception and Elaboration. Even in organizations where no formal process is being followed, events happen in roughly this order.
What doesn’t happen very often is a cost/benefit analysis whose goal is to determine if the project is still worth pursuing. Usually what happens is that a decision is made to initiate the project and that decision is not reviewed until the project is late and management has a sort of buyers remorse over the whole thing. This unfortunate situation is actually relatively easy to prevent.
Steve McConnell in his book Software Project Survival Guide describes a “Planning Checkpoint Review” to be held at the end of the discovery phase. In a RUP shop this would be at the end of Elaboration, although it would not hurt to also have one at the end of Inception. The goal of this review is to get a “go/no go” decision on whether or not to continue the project.
The reality of software development is that at the beginning of a project very little is known. There is an idea, a vision, for what needs to come out of the project, but it is impossible to build estimates on that. During the discovery phases of the project knowledge is built up and this knowledge is used to create and refine estimates. It is only after discovery has taken place that enough information is known to make a well-informed decision about whether a project will provide enough business value to justify its cost.
The Planning Checkpoint Review has another beneficial side-effect: it increases the decision maker’s visibility of the project and puts the cost right up front. Of course, this means that some projects will be cancelled or postponed during the review. This is a good thing. If the decision maker was not committed to the project enough to want to continue it, then it is better to know early before money is spent and the organization feels committed to finishing it. This is the first step to properly managing expectations for the project and making sure that everyone is happy with the end result.
Like many problems in the area of software development process, this is a big problem that has a relatively simple solution. Simple in theory if not in practice. It is human nature that people become emotionally attached to projects that they spend a lot of time working on, and others are afraid that a cancelled project will reflect poorly on them. Everyone involved must understand from the beginning that cancelling a project during the Planning Checkpoint Review may actually be a good thing for the organization, and those involved in the project should be prepared to move on to other projects that hopefully provide more business value.
(Nice post and blog. Glad I ran across it!)
A simple change in thinking but hard to add into an existing methodology (or lack-of-methodology methodology).
You need upper management buy-in. If you go in cold with just this change, you’re saying to management, ” The most important contribution I can make to the company is to cancel more projects. I won’t produce more, I’ll produce less. Praise me.”
I know the argument is justifiable, you’re really saying that you’ll waste less and that’s good for the bottom line. I just don’t think it’s a practical argument. At the very least you need to be prepared to be ignored.
In that case, you could probably get the change in during buyer’s remorse. When people question the value of the project, you have a good chance to pull out some data saying that you could have caught and stopped the project earlier. Then you can discuss adding the Planning Checkpoint Review to your methodology.
Of course, the ideal time to add this would be when you’re doing a complete review of your methodology.
You make a good point here, and it’s often difficult for both management and the development team to stop and think about whether a project is worth pursuing. I would argue that these checkpoints already exist in RUP, and the go/no-go decisions happens at the end of both Inception and Elaboration (and theoretically can happen in each iteration), when the team does the phase assessments.
Using the business case to justify the investment in the project is a good way to measure the costs against the proposed benefits. If you’re lucky, and you have provable financials to back up the benefits, then you can do a cash flow analysis that any manager should understand. Even when building a clear financial model is rarely possible, listing out goals and proposed benefits and weighing them against planned costs will still get you a long way. The key point is to stop and look at whether the project is still worth pursuing.
This is one area of RUP that I find missing in XP/Agile. XP/Agile somewhat deal with this problem by being more flexible to requirements changes, and costing out requirements during iteration planning, but more at a requirement/feature level as opposed to the overall project.
Keep up the great work on your blog. Best wishes WaltDe