Skip to content 
So-called “Waterfall” or “Phase-Gate” product development methodologies often give management the illusion that they are under control of the project, while they are actually just meddling and slowing it down. Each formal gate meeting or project review is an opportunity for every manager to put the project team under scrutiny about what they have accomplished and whether they should continue with the next phase. I have been on both sides of the PC projector for many of these reviews, so I know what I am talking about. When a gate checkpoint meeting or formal review is approaching, the project slows down. The project manager and key technical contributors view the meeting as an opportunity to show their value or possibly to slip up, which may affect not only their project, but quite possibly their personal ranking and stature. Therefore they spend a lot of time and emotional energy on perfecting slideware – deciding what to emphasize or perhaps what to obfuscate about the progress of the project. These meetings drive other suboptimal behavior as well; for example, in order to show a “quick win” at a review, the team may take on a quick, low-risk piece of the development instead of concentrating their talents on retiring the higher-risk elements as early as possible. These deferred high-risk elements can cause major project problems and delays later.
On the other hand, management cannot just hand a blank check to the project team and say “go away and come back with a great product whenever you are ready.” There have to be some boundaries to be enforced, right?
The answer is –YES – and “boundaries” provides the right concept for team empowerment within a management control framework. Empowering the team means providing it with the clear responsibility for the project, the authority to make the critical decisions, and the ability to execute.
The team has the Ability to execute the project if they have sufficient resources (with enough capacity), knowledge, talent and tools for the job. But how can we provide them with the proper amount of responsibility and authority if they are running unchecked? Isn’t that what Gate meetings and Project Reviews are for?
The simple answer is to negotiate a set of boundaries early in the project within which the team may make all its own decisions, and then largely leave the team members alone to run as fast and efficiently as they can. The boundaries can be displayed as a simple polygon, as in the illustration below.
In this pentagon figure, each flat side represents a constraint for the project, such as “the total cost of the development project must not exceed $__M,” or “The final Bill of Materials for the manufactured product must not exceed $300.” As the project proceeds, someone on the team (usually the Project Manager) indicates in real time how the project is performing within these boundaries. Green marks indicate that everything looks good for staying within the boundary; amber indicates that the team is having trouble to stay inside, and red means that a boundary is likely to be exceeded.
Once the boundaries are negotiated and set-up, they are usually reviewed quickly in a weekly, informal check-in meeting with management. Assuming that the team does not mislead or hide some major problem, this weekly check-in meeting can be very short (15 minutes is typical) and works very well to obviate the wasteful, formal Gate review meetings and other window-dressing reviews. If the project is heading for a boundary breech, then it is incumbent upon the project manager to call an “Out-Of-Bounds” meeting with management to escalate the situation and decide what to do. Management should set up a clear and rapid escalation process to handle these situations and get the project back on track (see Unclear Escalation Paths can Kill Projects).
In summary, if you want a product development project team to run fast and efficiently, don’t weigh it down with a heavy “Gate Check-Point” or “Formal Project Review” structure. Instead, give the team some overall boundaries, empowering it with sufficient resources and full and clear responsibility and authority within those limits, and let it fly free!
Further Reading
Discover the best resources for learning about Agile methodology by checking out our curated list of top Agile books written by respected authors.