Underqualified participants, unprepared for their roles in enterprise IT projects, lower frameworks and standards to match their limited knowledge and competencies. Failure becomes inevitable when a project team lacks the skills to meet even the minimum requirements. This section examines the poor practices resulting from underqualified participants that lead to project failure, along with the corrective actions taken to steer projects back on track.

Acknowledging failure is the first step in rescuing a troubled enterprise IT project. However, who volunteers this information? Typically, no one, for several reasons:

• Project reporting often presents the status positively, masking challenges that could harm the project’s image.
• Project leaders concentrate on managing and presenting a favourable outlook to senior stakeholders while minimising problems that might expose weaknesses in their leadership.
• The project team supports the positive narrative to safeguard their roles within the project.

The point at which failure is acknowledged depends on the integrity of project leaders when faced with tough decisions:

• Recognise professional limitations early and seek help while the impact on the budget and schedule is still manageable.
• Offer excuses and ask for support when the project can’t be saved without additional costs and extended deadlines.
• Delay intervention and overestimate abilities until the project's critical state is undeniable or until time and funding are exhausted.

Once failure is acknowledged, a troubled project can explore options for corrective action: cutting further losses, replacing the leadership team, or bringing in a project rescuer.

Cut Further Losses

Stopping a project in the middle of execution can be a viable option for smaller-scale IT projects, such as enhancement initiatives, where business operations may continue as usual using existing systems and processes. Evaluating this option is part of the project assurance process — typically through a project health check audit.

When deciding to cut losses on a failing enterprise IT project, the impact on participants is significant and varied.

Consultants

For consultants, the end of a project often means sitting on the bench, waiting for the next assignment. This period of inactivity can be stressful and uncertain, as they might be left without billable work for an unknown duration. In some cases, consultants might be quickly redeployed to other projects.

Contractors

Contractors face the harshest impact when a project prematurely ends. They might find themselves unemployed if they do not have another contract lined up.

Permanent employees

Permanent employees will return to their BAU roles. This abrupt transition can be jarring as they shift from a significant project's intense, high-stakes environment to their regular duties.

The unplanned nature of wrapping up a project means participants often have to navigate these transitions at short notice. It can also affect professional reputations, as the failure of a project might be seen as a setback on each participant's record.

Replace the Project Leadership Team

Restructuring within an IT enterprise project is a fifty-fifty lifeline: it might save or not the project. This becomes the default path for projects that cannot be discontinued, such as those required for regulatory compliance or bound by contractual obligations.

The rationale behind changing the leadership team is to rejuvenate corporate management’s commitment to the project. This drastic measure typically involves a three-step plan:

While compelling, this plan is misleading because merely changing project leaders does not ensure the rescue of a troubled project. It does, however, guarantee two outcomes:

• First, it temporarily conceals the underlying issues until the new leaders prove capable (or not). 
• Second, there will be a rename-the-project competition, as it is crucial to delineate past and present leadership. By association, the participants inherit the project name’s reputation.

Essential Preparations Before Replacing the Project Leadership Team

To enhance the likelihood of success before replacing the project leadership team, consider the following steps:

• Understand the challenges by identifying all current and potential issues impacting project progress.
• Analyse the root cause of the problems through deep investigation of the underlying reasons for project setbacks.
• Determine existing and expected gaps by assessing the discrepancies between current project outcomes and the expected goals.
• Develop a comprehensive strategy to address these gaps, ensure a smooth transition under new leadership, and prepare a recovery plan.

Bring in a Project Rescuer

When project leaders engage a rescuer, they keep their roles while adding temporary executives and senior managers to the team. These rescuers are compensated handsomely in the hopes of meeting immovable project deadlines.

Project rescuers, whether consultancies or self-proclaimed experts, typically:

• Do not bother getting to the root cause of the problem.
• Do not bother with facts and details of what, where, and why the project is in trouble.
• Aim to make a solid, immediate impact to demonstrate value.

The assumption is that the existing project team is the problem, which is sometimes the case but not always. Everything will supposedly be resolved if the project:

• Implements the rescuers’ checklist of theories and solutions.
• Subscribes to their project enablers (with extra charges, of course).

In reality, multiple factors contribute to project challenges. Rescuers often learn at their own pace—at the project’s expense—before realising that the problems are complex and do not have a simple fix. However, project rescue becomes a win-win situation for rescuers and project leaders, as neither party faces consequences for wasted time and resources. Without clear accountability, rescuers often become an overhead in enterprise IT projects, offering supposed expertise and solutions that lack real value.

The Problem

Peggy Bank is a self-proclaimed five-star consultant who came highly recommended—not through formal vetting but through a network of connections in high positions. Her strategy was straightforward: appear onsite, assert her expert status, and assure everyone that all would be well under her guidance. Naturally, her services did not come cheap. In addition to hefty professional fees, she secured a bonus for the successful turnaround of Project Gloom. The leadership team felt relieved—indeed, this solved their failing project.

The Rescue in Action

With Peggy on board, Project Gloom continued its operations, and senior stakeholders were tricked into a false sense of security, believing that something productive must be happening. Meetings were held, and buzzwords were thrown around, creating an illusion of progress. However, the project team soon realised that the same persistent issues—unclear deliverables, miscommunication, and rising costs—remained unaddressed.

Months passed, and the project showed no signs of improvement. Resource costs had tripled under Peggy's leadership without indicating the promised rescue. However, Peggy faced no consequences as she completed her tenure and headed off for a well-deserved break on an island paradise. Meanwhile, Project Gloom lay in ruins, left to limp without real progress.

The Plumber Analogy

Imagine a burst kitchen pipe: water gushing everywhere, wasting resources, threatening to ruin wooden fixtures, and creating the risk of electrocution from soaked electrical systems. Enter Peter Plumb, the plumber. He quickly assesses the situation, quotes an eye-watering fee for his services, and assures you he will fix the problem. With the crisis escalating by the second, there is little choice but to accept the steep cost. Peter guarantees results.

Now, consider Peggy Bank, who claims she can rescue Project Doom. Unlike Peter, a qualified plumber with training and experience, Peggy lacks any formal education in project management. She relies on her years of experience, mistakenly believing that this qualifies her for the task. While Peter brings hands-on problem-solving skills, Peggy’s approach is based on her preferences and opinions rather than best practices.

Initially, the project may seem to gain momentum under Peggy’s guidance, with stakeholders feeling optimistic about her perceived expertise. Much like Peter’s promise to fix the pipe, her assurances create an illusion of progress. But while Peter rolls up his sleeves and tackles the problem directly, Peggy’s approach often turns into a morale-boosting exercise that fails to address the underlying issues.

As the project spirals further into disarray, the contrast becomes stark. Peter would face demands for a refund if he did not adequately fix the problem or if it broke again shortly after his work. In Peggy’s case, she walks away with her fees and bonus intact, having done little to resolve the chaos she was brought in to fix.

This analogy highlights that true professionals, whether plumbers or project managers, should be held accountable for their results. Just as Peter's reputation relies on solving plumbing issues, a project rescuer's success must link to tangible outcomes—with a money-back guarantee for their services.

What Should Change

To avoid situations like Project Gloom, some fundamental changes are necessary to ensure accountability and results in project rescues:

• Transparent communication: Rescuers should maintain open communication with all project participants, not just the executives. This ensures everyone knows the project’s actual state and next steps.
• Performance-based fees: Professional fees should be tied to specific milestones and deliverables, ensuring fees are only paid for tangible progress. If Peggy promises to turn around a project in three months, her compensation must be directly linked to measurable improvements.
• Money-back guarantee: Every project rescue contract should include a guarantee to protect the project from paying for failure.

Having explored the poor practices in enterprise IT projects, it is evident that many of these issues stem from the lack of proper oversight and adherence to established processes. This sets the stage for introducing project assurance, a structured approach to mitigate these risks by addressing compliance, quality, and performance gaps.