Rescue or termination? Let's analyze implications of both and learn how to assess whether to continue a troubled IT project.
In today’s highly competitive market, every business entity is striving to utilize the latest digital technologies and tools to gain an edge over the competition. In a quest to accelerate delivery and reduce costs, IT companies and software engineers undertake all kinds of initiatives.
However, often instead of the anticipated transformation towards efficiency, many initiatives get crushed by budget/infrastructure/schedule restraints and turn into troubled IT projects.
According to the Project Management Survey 2017 by KMPG, 31% of companies deliver projects on time, 29% are likely to fulfill projects on budget, and only 34% deliver projects that receive stakeholders’ approval. CIO puts it more bluntly, saying that 50% of IT projects fail in the end.
Overall, various surveys find that poor estimation, poor objectives, senior management uninvolvement and lack of communication are the top precursors to failing projects.
They say, if you’ve never advised someone to cancel a project, you haven’t been a good project manager. Managing troubled projects is clearly challenging due to IT complexity, human nature, and a variety of others factors.
Thus, a rescue effort to regroup and start over or a project termination could both be relevant. Together, let’s consider when it is worth saving a project and when to cancel it.
A project in software development is failing when it struggles in terms of quality, cost, and schedule. In troubled IT projects, the dissimilarity between what has been planned and what has been achieved becomes so big that a project falls apart and ultimately fails. In case of failure, it leads to loss of money and damage to reputation.
The causes of distressed projects, mostly, lie in project management responsible for workflow organization. Needless to say, typical causes are poor planning/communication/leadership, inaccurate cost estimation, lack of clear requirements, lack of tracking/accountability, etc.
Basically, we can put all of them into 3 groups: human, communication and process factors.
Drawing parallels between a medical condition and a project in trouble, symptom (cause) identification, and early action is key. Realizing trouble and delaying the intervention will only make things worse. However, most software projects acknowledge trouble late, in part due to IT management mistakes.
Pay attention to the following signs that may require further investigation:
Note, that “trouble” is not just the existence of such conditions, it’s in the persistence of issues and overall growing sense of unease. Seeing trouble does not automatically mean project failure. It’s a basis on which to analyze why the project is failing and what could be done about it.
In project management language, such analysis is called troubled project assessment, aimed at determining one of further actions:
Project assessment of both prospects – project continuation versus project termination, and respective consequences could go about by focusing on key questions.
Can we save the project by updating project plan, changing staff, revising milestones, increasing funding, etc.? Are there benefits to project cancellation… can it free up resources/budgets to work on other projects?
The prime goals of assessment are scrutinizing all project aspects in detail, analyzing data, assembling the findings and reporting it to top management or stakeholders. Hence, it is an examination of project’s performance, deliverables, issues, and overall condition.
As a result of the assessment, we are able to determine what has to be changed (regarding people, process or product) and recommend the next stage: rescue or termination.
Along with investigating the current real project status, the following project variables should be thoroughly analyzed as well:
The assessment team or manager also conducts team debriefs and interviews to evaluate threats and opportunities, as well as corroborate findings. This could also be a good setup for further team involvement in rescue efforts (check out our previous post about team meeting tips).
The sequence of actions with troubled IT projects is basically four stages: Assessment, Recommendation (decision), Planning and Execution. So after a thorough assessment, management is faced with a big decision to make – recover a project or terminate it.
Naturally, you’d weigh in all the pros and cons of both scenarios. Here are a few analysis directions to begin with:
If market conditions and technical aspects/requirements haven’t changed drastically, and business benefits can still be gained in a reasonable time, a project might be worth rescuing.
Recovering a failing project may infer revision of a project scope and objectives, extension of budget and/or timeline. The general purpose of project recovery is restoring business feasibility. With that in mind, the core goals are redefining the project plan, setting new (realistic) deadlines, reviving customer confidence, correcting problems.
In terms of a project team, there may be a need to re-staff it, or even possibly re-assemble the original team. It will be mainly the responsibility of a project manager to perform team evaluation, to convince stakeholders of recovery, to motivate the staff, to establish a recovery plan and monitor it at all times, to be decisive and build momentum for a successful outcome.
Note: because the project team is key in recovery efforts (“..you’re only as good as your team..”), it is highly advised to involve every team member in creating the rescue roadmap.
Approaches to a project recovery are always company-specific, typically being one or a combination of the following:
Needless to say, the prime goal is to eliminate the root cause(s) of trouble and prevent it from ever happening again. It is vital to remember about actions on three levels: people, process, and product. Actions to reach this goal may include:
When is it reasonable to cancel a project altogether? When project deliverables cannot be produced within a sensible time or cost is one example. Other scenarios urging termination might be a change of business goals and/or market conditions, technological transformations that render project unfeasible, investor exit, lack of team motivation, and legal issues.
Again, it’s important to emphasize that a project termination is not necessarily a failure. It could be appropriate if everyone – from stakeholders to developers – came to the same conclusion.
The popular tech magazine CIO has such recommendations about terminating troubled IT projects:
The last point here is especially notable, as the next projects should be approached more wisely in terms of setting expectations, team tasks, allocating resources and a budget. In other words, canceled projects should lead to better results next time.
Concrete steps to execute project termination comprise consultations with other departments, obtaining top management approval, preparing a written statement informing team members and customers, announcing the termination, assigning developers to other projects/tasks, finishing a project review.
It is often hard to identify trouble due to deficient control and human error. To timely detect trouble, pay attention to signs (symptoms) we mentioned, and treat recovery as a separate project.
Conduct a rescue when you can extract tradeoffs out of project constraints, and still achieve the result. If that seems impossible, or a corrective action won’t suffice, don’t be afraid to cancel a project. Reduce the negative impact and learn from failure.
Get actionable product building tactics in your mailbox, monthly.
No previous chapters
No next chapters