{"id":4461,"date":"2019-01-22T13:33:41","date_gmt":"2019-01-22T13:33:41","guid":{"rendered":"https:\/\/rbbs.nl\/?page_id=4461"},"modified":"2026-06-11T05:24:44","modified_gmt":"2026-06-11T05:24:44","slug":"how-do-you-recognize-your-project-is-escalating","status":"publish","type":"page","link":"https:\/\/rbbs.nl\/?page_id=4461","title":{"rendered":"How do you recognize your project is escalating?"},"content":{"rendered":"
\n
\n
\n
\n
<\/div>\n
<\/div>\n
<\/div>\n<\/div>\n
\n
\n
\n
\n

How do you recognize your project is escalating?<\/h1>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/section>\n
\n
\n
\n
<\/div>\n<\/div>\n
\n
\n
<\/div>\n
\n
\n
<\/div>\n
\n
\n
\"\"<\/div>\n<\/div>\n<\/div>\n<\/div>\n
\n
<\/div>\n
\n
\n
\n
\n

“Is your project turning into a black hole?”<\/span><\/p>\n<\/div>\n<\/div>\n<\/div>\n

\n
\n
\n

IT projects can become the business equivalent of what astrophysicists know as black holes, absorbing large quantities of matter and energy. Resources get sucked in, but little or no business benefit ever comes out. How can you recognizing if your project is becoming a black hole?<\/span><\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/section>\n

\n
\n
\n
<\/div>\n<\/div>\n
\n
\n
<\/div>\n
\n
\n
<\/div>\n
\n
\n
\n
\n

Projects will not turn into a black hole in one day. They go through a process. Keil and M\u00e4hring (2010) created a framework we can use to detect whether a project is at risk of becoming a black hole and determine to what stage the process has advanced. The table below shows the differtent stages of project escalation. <\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n

\n
\n
\n
Project set-up<\/span><\/div>\n
\n
\n
\n
\n
\n

Many design mistakes can be made in the set-up of the project. Projects can be set-up for success or for failure. Some best practices for a good project set-up (without being complete) are involvement of the business, clear scope, appropriate representation of senior management, solid business case (including project objectives, project deliverables and business benefits you want to realize) and an intrinsic motivated team, which is available.<\/span><\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n

\n
Phase 1 – Drifting<\/span><\/div>\n
\n
\n
\n
\n
\n

Phase 1 of the escalation process is when the first problems emerges. You can recognize your project is drifting when there are ambiguities regarding project goals and direction. Especially if the ambiguities cannot be resolved within a relative short period of time. Another sign your project is drifting is when stakeholders have a different view on the primary objective of the project, than there is little hope that they will agree on the scope of the project. Do the <\/span>one minute test<\/a> to see if your project is drifting.<\/span><\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n

\n
Phase 2 – Treating symptoms<\/span><\/div>\n
\n
\n
\n
\n
\n

The second stage of the escalation process is when problem visibility increases. More people in the organization are now aware the project\/ program is not running as it should be. Still, in many cases the project-related problems are addressed rather superficial and the problems are handled isolated from each other. Project managers will tell you, if we solve this issue, everything will be fine and we can continue. Root causes of project failure (e.g. lack of leadership, lack of methodology, high complexity, high uncertainty) are not addressed. <\/span>Do the test<\/a> to see if your project is already in the phase of treating symptoms.<\/span><\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n

\n
Phase 3 – Rationalizing continuation<\/span><\/div>\n
\n
\n
\n
\n
\n

The third phase of escalation involves rationalizing continuation. By this point, decision makers and project participants have become acutely aware that the problems facing the project are more serious than they had originally judged them to be. During this phase, more people begin to doubt the project and, depending on the culture of the organization, these doubts may be expressed and discussed more widely. At the same time, projects in this stage of escalation normally have highly committed and influential backers, who are unwilling to consider termination. Do <\/span>the test<\/a> to see if you are rationalizing continuation. <\/span><\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n

\n
Project termination or turnaround<\/span><\/div>\n
\n
\n
\n
\n
\n

The final stage of the escalation process. Are you continuing with your project or do you terminate it? If you are in doubt if you need to continue or not, you can conduct a number of hearing. Ask if you owned this company, what would you do with the project, and why?\u201d Be clear that you are not looking to criticize, but to get a good picture of a complex situation.<\/span><\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n

\n
<\/div>\n
\n
\n
<\/div>\n
\n
\n
\n
\n

Obviously, the sooner you detect your project is escalating, the better. The further you are in the escalating process, the more costlier and more difficult it will be to stop. In an early stage of escalation, fewer resources have been consumed and it is less difficult to change the direction of a project because the project has less momentum. So, what can you do if your project is escalating? <\/p>\n

\n

Keil and M\u00e4hring give some options:  <\/p>\n