Unclear Escalation Paths can Kill Projects
In any kind of project or program, situations often occur that require escalation for decisions to be made above the level of the project team. Typical examples of such situations include changes of project scope, unforeseen technical problems, overspending, lost expertise, and schedule slippages or changes. The problems can get especially costly in a heavily matrixed organization, wherein people who report to various functions (engineering, marketing, finance, manufacturing, etc.) are essentially “on loan” to a program manager to complete the deliverables. Some or all of these people may be working on more than one program team, plus contributing work to their functional teams. When a program encounters a roadblock in such a system, something close to chaos can occur, putting a halt to productive progress and polluting the organization with animosity. For example, say that something technical happened that will cost the program 10% more money and require more resources or time. The finance team member may go back and report to his boss – the controller – that the engineers want to go over budget. An engineer may go back to her supervisor saying that the scope changed and now they can’t meet the technical requirements. The product manager may go back to his boss – the marketing manager – and say that the engineers aren’t smart enough to meet the customer requirement, and so forth. Those managers may kick the problem up to their bosses at the VP-level. In the meantime, the program manager is pleading with her PMO team or boss for more time and money. These supervisors may then meet one-on-one or in various groups to discuss the situation, argue about whom is to blame, etc., as illustrated in Figure 1.
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.