Stage gates: looking back and forward

Last week I talked about how a formal stage-gate process can take the drama out of project management decisions. But I oversimplified one point.

Remember that the basic idea is to define objective criteria at the beginning of the project for what it takes to wrap up each stage and move onto the next one. Then when it is time for one of these stage transitions, you know what you should have achieved. So you can go down the list and check: Did we do them all? If yes, you move forward. If no, you've still got work to do in the current stage.

Sure, what's wrong with that?

The oversimplification is that I described it as if you can make these decisions blindly, guided just by the mechanical operation of the checklist itself. But while it's true that the use of a checklist helps to depersonalize the process and thus reduce the associated drama—Yes, we have to delay the release but it's not about you; it's just that Task 17 isn't done yet—on the other hand we all know that making decisions blindly is a bad idea.

Things might have changed since you made your first plan. Maybe you've learned during the project that one of your planned features is impossible, or (more likely) that it's going to cost far more to develop than you will ever make back. So you haven't passed all your tests (because the product is still missing that one feature) but the rest of the product is fine and now you think it's good enough.

Or maybe once you got deep into the development process you discovered new risks you hadn't known about before. In this case maybe the product does pass all of its tests, because back at the beginning of the project you never thought to test for these new issues. But now that you know about them, you're really not comfortable releasing it yet—even though your formal testing is at 100%.

So what do we do?

The answer is to use the stage gates to make two different evaluations: one looking backward to assess what has actually been accomplished, and one looking forward to weigh risks in the future.

In practice, I have seen this idea implemented in different ways. One company actually held two meetings for each stage gate, with different (but overlapping) attendance lists. Another company kept it to a single meeting, but the discussion points shifted halfway through.

Part one

The first part, then, is to ascertain the facts about what has really been done. Pull out your list for all the things that were supposed to be accomplished in the stage you are now ending, and invite the people responsible for their accomplishment. Then start at the top. 

"Attendee #1, did you succeed in __________?" If you get the answer Yes, ask for proof (such as a test report). If you get the answer No, ask for the status: is it just because the department needs another day to wrap things up, or are there fundamental problems that have surfaced? Write down the issues, plus any actions that have already been planned and any projected completion dates. Then go on to the next question, and proceed through the whole list just like that. 

At the end, you will have a full picture of the project's status as of today. These tasks are done, and here is a list of the relevant artifacts. The rest of the tasks are still open; and for each one here is an explanation of why, plus a list of the actions still planned and expected completion dates. So far, so good.

Part two

Then the second part is to decide What next? But notice that this is a very different kind of question from the ones you asked in the first part. 

• The questions in the first part were all project management questions: What's the status? Who is responsible? When will you finish? 
• The questions in the second part are business decisions: What do we do? What are our options? What have we committed? What can we afford? What are the risks? What are the consequences?  

The point is that you have to know all the facts before you make a decision; but ultimately mere facts don't make the decision for you.  

So in the case where you found that one feature was a lot harder than planned, you can discuss the consequences of releasing your product without that feature. I worked on a project once where exactly that happened. Since we were designing the product for one specific customer, we asked the customer what they wanted us to do. They said, "We don't need that feature until next year, but we need the rest of the product right away—literally as soon as you can start shipping." We agreed with them to release the product as-is, but to start a second project to develop that last remaining feature so we could release it in an update a year later. 

Or in the case where you discover previously-unsuspected risks, you can decide that even though your checklist is 100% satisfied you are going to hold the product and not release it yet. Then you can assign a team to investigate the new risks, and to evaluate how likely they are and how much damage they will entail. Maybe another team can work on ways to mitigate the risks, so that the likelihood and severity both decrease. And when the teams are done, meet again to evaluate what they have learned, and to decide whether and how to move forward.   

Do we have to go through this rigamarole for each stage gate, or just to release the product? 

Well, naturally it's most important to go through it before you release a product to your customer or to the public. If you release a product with defects, you'll likely incur warranty costs repairing it, and in some cases there might be legal penalties as well. The business impact of a wrong decision at this point can be huge.

But in principle you should handle the other stage gates the same way. After all, what if you discovered a problem in the middle of the design phase such that you can already tell this project will become a money pit? Do you really want to keep working on it all the way up to release? Or do you want a chance to reconsider? Using the interim stage gates to make the business decision "Yes, keep going" or "No, stop this now" affords you a finer granularity of control over the work. 

Who attends these meetings? 

Quality has to be there of course. Quality, as a neutral arbiter, often runs the meetings. Other than Quality, there are two answers:

You need the responsible members of the project team to give you information about the project status. This is what I have called the "first part" of the stage gate decision.

But the project team typically shouldn't make business decisions (the "second part"). Business decisions cost money, and they expose the company to risk. So they have to be made by people who are authorized to spend the money and assume the risk. Often this means Senior Management. In a small or mid-sized company, it could well mean the President.

Does this mean you have to drag the CEO into all these project meetings? 

Every company is different. Figure out what works for you. But before you dismiss the idea as "obviously ridiculous," do a little math on the back of a napkin. How much will it cost if your stage-gate decision is wrong? You'll find the numbers add up fast. And when your company has to make any other decision to put that much money at risk, who has to be in the room?

Well then. 

Summary (TL;DR)

To recap, here are the basics.

• The stage gate decisions in any formal product development process must have two parts: a project management assessment of the current status, and a business decision about whether and how to move forward. 
• Normally a clean project management assessment means you are ready to move ahead. But not always.
• Normally a failed project management assessment means you can't move forward because you still have to fix things in your current stage. But not always.
• All these decisions have to be made from the perspective of what's good for the whole business. And they have to be made by people who can speak for the business.

That's all.