In the meantime, the program languishes until some solution is finally reached through some kind of back-room consensus. The team licks their wounds and gets back to work, behind schedule and over budget and nursing resentful feelings. Is this an overstatement? I have seen it happen in many companies. What is more, they don’t seem to learn, and it happens many times!
There is a clear method to avoid these situations, but it takes up-front planning and top management support. The method is to define a very clear escalation path for any problem that cannot be handled within the team, and have the whole organization agree on escalation protocols. One way is to define an Oversight Team, composed of appropriate people at the supervisor level, and above that an Escalation team of VP-level managers. The Escalation Path is illustrated in Figure 2, with typical roles on the teams:
Those teams in place, we need some protocols upon which everyone agrees:
- If someone on the project team feels that there is a problem that cannot be solved within the team, he/she brings it to the project manager or the project team meeting. If the PM and team agree that they need to escalate, before doing so, they come up with at least two alternative solutions to propose to the Oversight Team. The escalation should be done or led only by the project manager and taken to the Oversight Team – no “end runs” please! Of course that does not mean that people should not communicate with their supervisors; the latter should be aware of the problem, but not doing outside escalations; otherwise we are back to the chaos. They should discuss it as an Oversight Team, not in a vacuum.
- The Oversight Team should agree to meet promptly (say, within 2 business days) and decide about what to do. With busy executives and sometimes heavy travel, this timing may be tough; nonetheless they should do it even if it means evening or weekend web- or teleconferences; or possibly designating a proxy. If they can solve the problem, they do it. If not or if they don’t have the decision-making power (increasing the budget, for example), they send it to the Escalation Team with their recommendations.
- The Escalation Team also agrees to meet within 2 business days and follow the same rules. If they cannot decide or make the decision, the problem gets sent up to the GM (or highest decision-making level). He or she agrees to make a decision within 2 business days as well.
- When the project manager gets the decision, he or she immediately documents it and sends that document to all parties involved, in the form of: “Here is the problem and here is what the management team decided to do about it, so here is our new plan of record.”
If everyone in the organization agrees to the escalation path and the protocols for escalation, project completion will be much smoother and the sense of “blame” will be minimized. The time to solve any problem or reset the project scope or expectations will be reduced from weeks or months of wheel-spinning to, at most, 6 days in the example above.
We recommend that there not be more than two escalation bodies between project team and the top decision maker, or it extends resolution time too much. We have seen companies collapse or stagnate from their mere size because the number stops on the escalation path grew so large that they were no longer agile in making decisions.
In summary: At the beginning of any major project or program, defining a clear escalation path and protocols for problems that cannot be resolved within the team will greatly speed the project and minimize animosity in the organization.