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 P aths 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!