Why Are We Using Gates?
I am not claiming to have done an anthropological study, but I can make an educated guess into origins of this practice. I can imagine a project team making a decision to start building some part of a product prior to completion of the entire design. They felt comfortable that designs were complete enough to start building and they accepted the risk of some rework. Unfortunately, there was a fundamental design flaw and the rework was significant. Senior managers or the customer got upset and required their review and approval prior any major work proceeding. Voilà, the gate was born.
Often justified as being a method to ensure management is engaged with the project, I see gates as a way to ensure that management is anything but engaged. It creates a mentality that management does not need to monitor progress, drop in on meetings, talk to team project team members, or any of the practices that good leaders and managers do to ensure they can spot problems early. Instead, gate processes create an atmosphere where managers feel justified in ignoring the project, since every couple of months the project will stop and wait for them.
Gate review meetings then become a game where project managers try to get their projects to pass the gate without any hassle—minimizing troubles as to avoid management attention. Attention brings "help" from people unfamiliar with the intricacies, interrelationships, and individuals in the project.
Now, besides trying to reassemble the team, the project manager needs to assign them work from task force assigned to fix the project. A task force that assigns works instead of doing work.
Hurry Up And Wait
The effect on the project team is immense. Stopping work to wait for a bureaucratic process destroys the team's sense of urgency. If the project can wait for a group of managers to approve its progress, especially if they have little background in the project's domain, then the project can wait for the team members to do other work. The project team loses interest in completing tasks quickly as the energy and excitement slowly dwindles. Any concept of urgency is lost and team members take a lackadaisical approach to completing their tasks.
What Was I Doing?
To make matters worse the team needs to remain billable, so they are assigned to new tasks. These are necessarily off the project, since it is waiting for gate approval. Besides the inherent slowing of the project brought on by multitasking, the break in the project means that people need to refocus repeatedly on various tasks. The distraction and lack of continuity removes people's ability to concentrate on the product and mistakes increase. Worse, fine points in the product are lost. The quality decreases and the customer gets frustrated.
Gates prohibit work in the follow-on phases until all other work catches up. Yet, allowing some work to proceed shows areas of weakness long before other groups have wasted time with a faulty design. This is the concept behind prototypes, mock-ups, wire frames, and iterative processes, such as agile. By allowing given areas to move ahead, designers, builders, and customers can judge the validity of a concept and use semifunctional tangible product to determine its usefulness. Therefore, gates remove valuable exposure of the product to the customer.
The solution is better stakeholder engagement. Monitoring and experiencing the project, its progress, risks, and challenges as they appear, rather than quarterly, removes the need for gates processes. This is one of the powerful advantages of an agile methodology. Management is continuously apprised. The update does not even wait for the end of the iteration, it happens in the daily scrums.
However, I am not simply being an agile bigot (although I am one). I am highlighting one of the many ways that senior management causes more problems for projects than they have solved. The process of managing and the art of leadership are lost as people struggle climb the ladder and promote themselves.