Troubled IT Projects: When to Rescue and When to Abandon

Introduction

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.

Defining a troubled project

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.

Identifying signs of troubled IT projects

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:

• Missing major deadlines/milestones regularly, things getting out of hand in terms of schedule, procedures, technology, budget;
• Poor planning, disagreement on project requirements/goal definitions;
• Frequent changes, improvisation on part of developers, lack of clear input from top management;
• Lack of resources and/or required skills;
• Conducting activities/tasks not specified in the documentation/project plan;
• Delays, negative status reports, cost overruns;
• Negative mood about the project, low team morale, high employee turnover.

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.

Assessment

In project management language, such analysis is called troubled project assessment, aimed at determining one of further actions:

• to pursue and save the project,
• to save the project by starting it over completely,
• or shut the project down (terminate).

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:

• A work breakdown structure (WBS);
• Project resources – human and technological;
• Risk assessment (logged and yet unidentified);
• Scheduling;
• Project-specific work organization and processes;
• Deliverable defects or inconsistencies.

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).

To save or not to save: Rescue vs Termination

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.

Project recovery implications

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:

• Mending communication and management issues;
• Redefining the project (scope, objectives, profits);
• Solving technical problems;
• Attributing more resources/costs;
• Replacing a project manager.

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:

• Fixing product defects;
• Establishing new rules for work processes;
• Finishing or reworking project documentation;
• Developing a structured recovery plan;
• Implementing new quality control and progress reporting

Project termination implications

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:

• Double-check the possibility of project recovery
• Make all of the specific reasons for cancellation clear to all
• Be sharply specific in data – costs, damages, timeline, people, etc.
• Check back with a project contract for obligations (there might even be a cancellation fee)
• Make it a learning experience for management and employees

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.

Basic tips

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.