Every R&D manager knows about Stage Gates or Phase Gates as they are also known, and the vast majority of companies use them in one form or another.
The concept certainly dates back to the 1940s but in the R&D context it is mostly associated with the name of Bob Cooper of Penn State University who has written extensively (to put it mildly) on the subject. He has even registered the name “Stage Gate”. There’s a Wikipedia article that gives a good overview of the subject.
The basic idea, of course, is simply that at certain points in a project’s life there should a formal review to check if all is going to plan and to decide what to do next. It is so easy for a project that is in trouble to limp along consuming scarce resources. A stage gate process forces managers to review all aspects of the project – not just the technical work but all the surrounding business issues – and to take decisions.
Soft hold now accepted
When the process was first discussed the principle was that if all was not going to plan the project should literally stop at the gate until the problem was cleared up. Now most companies accept the idea of a “soft hold” in which the rest of the project can go on while a problem is addressed; but only for an agreed time. After that a decision must be made to continue, to change course or to cancel the project altogether.
Most companies that do R&D will develop a standard Stage Gate process, designed to be suitable for the majority of their new projects. This is an essential management tool but such standard processes do have a number of vices. I list a few below in the hope of stimulating a bit of discussion on how to make stage gate processes work better.
The first vice is having too many gates. The current view is that 5 or 6 should be enough, but some companies feel they need twice as many. How does one choose?
The second vice is a tendency to over-elaborate the gate processes. I have seen companies go through cycles with this. First some disaster exposes the lack of control so they install a formal stage gate process, which is initially welcomed. They review the new process regularly and update it, but whenever anything has gone wrong they add an extra feature (a report, a check list or whatever) to make sure it won’t happen again. So over time the process becomes more elaborate and onerous, and it starts to be seen as a waste of time; after all, things don’t go wrong very often. So it falls into disuse until another disaster happens and the cycle begins again. How do you stop this happening?
Another vice is insisting that absolutely every project should go through the standard process. (You can tell that this is a problem when managers start setting up “skunk works” to keep pet projects away from “the bureaucracy”.) Small or straightforward projects need a lightweight process, just enough to prevent them going awry without burdening them with heavy reporting. A heavyweight process can stifle creativity in exploratory projects. And novel projects that take the company in a new direction will need their own special oversight.
The final issue– not so much a vice as simply a problem- is that the gate reviews tend to be confrontational with participants defending their own work rather than collaborating to make sure that their project is on the right track. You want people to go away feeling pleased to have caught hold of some problems and dealt with them, not just grateful to have got out alive.
It’s easy to say, but difficult to do.