Rescuing or ending crisis projects: Project turnaround in IT projects
When an IT project runs into trouble, there is rarely a lack of activity. Plans are revised, issues are escalated, resources are added, and reporting becomes more frequent. What is usually missing is something else entirely: a decision about whether the project, in its current form, is still the right one. A project turnaround begins at exactly this point. It is first and foremost a decision-making task, and only afterward a planning task. This article shows how clients and project managers recognize that normal management is no longer sufficient, how they clarify the situation, and how they make an objective choice between remediation, restarting, and termination.
What a project turnaround is
A project turnaround is the deliberate interruption of the current approach with the goal of making an unmanageable project decidable again. This distinguishes it from a plan change. A plan change shifts deadlines or budgets within the existing logic. A turnaround questions the logic itself: the goal, scope, responsibilities, and the nature of the collaboration.
This also clarifies what a turnaround is not. It is not stricter controlling, and it is not an additional reporting cycle. More reports on a project whose fundamentals are flawed produce more paperwork, but not manageability.
Three signs that normal management is no longer enough
Delays alone do not constitute a project crisis. The situation becomes critical when the usual corrective measures no longer have any effect. In practice, this can be identified through three observations.
Reporting and reality diverge. The status has read “almost done” for weeks, without anything actually being finished. Hauke Thun describes this pattern in Computerwoche as the 90 percent syndrome, and points to a second consequence: when critical details that were missing from status reports repeatedly come to light upon inquiry, trust between the steering committee and project management suffers lasting damage.
No one can show a usable interim result. Percentage figures are estimates. A state that the client side can test for itself is a fact. If this is missing for an extended period, actual progress remains unknown, regardless of the quality of the reports.
Decisions are postponed. Open issues remain unresolved across multiple meetings, the team gets by with workarounds, and the steering committee acknowledges risks without deciding anything. At that point at the latest, a scheduling problem has become a leadership problem.
If two of these three observations apply, a sober stocktaking is worthwhile. If all three apply, it is overdue.
Clarify the situation first, then act
The most common mistake in a project crisis is jumping straight from realization to action. Anyone who immediately replans or adds staff is acting on the same information that led the project into crisis in the first place. A brief, clearly defined phase in which nothing is fixed but everything is clarified is more sensible. Three questions structure this phase.
What has been agreed? The contract, scope of services, change requests, and payments to date all need to be brought together in one place. Only then can it be determined what scope is actually owed and what has been added along the way without formal agreement.
What actually exists? This includes a demonstrable status, but also secured access to source code, systems, and documentation. A client who cannot access their own project deliverables in an emergency has no options for action. Conversations with the people actually building the system often add crucial details that the reports leave out.
Who has the authority to decide? A crisis cannot be addressed as long as it is not officially acknowledged. It must be named, and someone needs the mandate to halt new commitments and change requests while the situation is being clarified.
An independent expert assessment from outside is helpful at this stage, because everyone involved has a history with the project. It is important that the assessor has no personal interest in follow-on work.
The decision: two questions instead of one question of blame
Crisis meetings tend to circle around the question of who caused the situation. For the decision about the project’s future, this is secondary. Two questions, answered separately, are more helpful.
Is the goal still worthwhile? What matters is the comparison between the effort still required from today onward and the benefit still to be expected from today onward. Money already spent has no place in this calculation, since it has been spent equally under any option. This rule is simple, yet it is routinely violated, because no one wants to be responsible for an expensive project with no result.
Is the path to get there viable? This concerns three things: whether the requirements are clear enough, whether what has been built so far can still be used, and whether collaboration between those involved still works.
Combining these leads to three possible directions:
- The goal is worthwhile and the path is viable: the project is remediated, meaning it continues with a corrected scope, clear leadership, and a realistic plan.
- The goal is worthwhile but the path is not viable: the project is restarted. Depending on the weak point, this means first clarifying the requirements, renewing the technical foundation, or changing the implementation partner.
- The goal is no longer worthwhile: the project is terminated in an orderly manner, even if the path would be technically feasible.
The strength of this distinction is that it makes the third option visible. Many organizations discuss only the path and never put the goal itself up for debate.
Rescuing a crisis project: what needs to change in a remediation
A remediation that only replaces the schedule repeats the crisis with a new date. It becomes effective through four changes.
Mandate. A named individual is given the authority to decide on scope, priorities, and suppliers, along with a steering committee that makes decisions within days rather than weeks. Without this authority, every measure remains merely a recommendation.
Scope. A project in crisis does not build trust through completeness, but through a first result that is put to productive use. Anything not needed for that is moved to a later expansion stage.
Proof. Percentage figures are replaced by a near-term delivery date with a verifiable result. A deadline that is met has a stronger effect on the team and the client than any promise.
Staffing. The reflex to speed up a delayed project with additional staff has been described as a fallacy for decades. Frederick Brooks put it into a formula back in 1975: adding staff to a late software project delays it further, because onboarding and coordination initially tie up capacity. Adding staff only makes sense once requirements and architecture are stable.
Terminating or rescuing a project: when ending it is the better decision
In many companies, termination is seen as an admission of failure. Viewed objectively, it is an investment decision like any other. Typical reasons include goals that are no longer achievable, lack of resources, external factors such as changes in legislation, significantly shifted company priorities, and persistent technical or organizational problems.
A simple rule applies to the process: decide thoroughly, implement swiftly. The decision requires a clean analysis and alignment with stakeholders. Once it has been made, every additional week consumes resources without any return.
A termination has costs that must be put on the table beforehand: contracts to be wound down, possible contractual penalties, and results that can no longer be used. But it also has value if carried out in an orderly manner. Requirements documents, data models, analyses, and insights into the root causes are preserved and shorten any later restart. A project that quietly fades out loses this as well.
What external project turnaround management can deliver
Clarifying the situation and preparing the decision is difficult for internal stakeholders. They have helped shape the project, are part of the conflicts, and must continue working together after the crisis. An external interim project manager brings three things that are rarely available internally at the same time: no history with the project, experience with comparable situations, and the capacity to devote themselves exclusively to this task.
The mandate is decisive here as well. External support without decision-making authority becomes just another layer of reporting. How project management can be flexibly brought in as a service is described in the article Time to rethink: the benefits of Project Management as a Service. Since a turnaround always realigns the expectations of sponsors, business units, and suppliers, it is also worth taking a look at successful stakeholder management in large projects.
Anyone facing a crisis project today does not need to know how it will turn out. It is enough to follow the sequence: name the crisis, clarify the situation, assess the goal and the path separately, and then decide.
