Poor Practices

Underqualified participants set lower standards to match their knowledge and experience in enterprise IT project delivery. Failure becomes inevitable when the project team lacks the requisite competency to contribute to their respective roles. This section examines the poor practices that lead to project failure and the corrective actions taken to steer projects back on track.

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

  • Project reporting often presents the status positively, masking problems that could harm the project’s reputation.
  • Project leaders focus on managing and presenting a favourable outlook to senior stakeholders while downplaying issues 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, potentially:

  • 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 may not 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 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 varies.

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 are faced with significant consequences 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 end of 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 an IT enterprise project is a fifty-fifty lifeline: it might save the project — or not. 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:

  1. Identify a responsible party (a scapegoat).
  2. Remove the culprit (the scapegoat).
  3. Give the impression that the project will get back on track (find the next scapegoat the project does not recover).

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.
Before Replacing the Project Leadership Team

To improve the likelihood of project recovery before replacing the leadership team, consider the following steps:

  • Understand the challenges by identifying all current and foreseen 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 and expected project outcomes.
  • 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 bring in a rescuer, they retain their roles while adding temporary executives and senior managers to the team. These rescuers are well compensated in return for the promise of meeting fixed 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. Issues will supposedly be resolved if the project:

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

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 money. Without clear accountability, rescuers often become an overhead in enterprise IT projects, offering supposed expertise and solutions that lack real value.

The Rescue Project

The Rescuer

Peggy Bank is a self-proclaimed five-star consultant who came highly recommended—not through formal vetting and merit but through a recommendation from 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 negotiated a bonus for the successful turnaround of Project Gloom. 

Rescue in Action

With Peggy on board, Project Gloom continued its operations, and senior stakeholders felt a (false) sense of security, believing that something productive was in the works. Meetings were held, and buzzwords were thrown around, creating a perception of progress. However, the project team soon realised that the same persistent issues—unclear deliverables, miscommunication, and rising costs—remained unresolved.

Months passed, and the project showed no signs of improvement. Resource costs had tripled under Peggy's leadership without indication of the promised rescue. Peggy faced no consequences as she completed her tenure and headed for a well-deserved break on an island paradise. Meanwhile, Project Gloom was left in ruins with a drained budget.

The Plumber Analogy

Imagine a burst kitchen pipe: water gushing everywhere, wasting resources, the threat of rot to wooden fixtures, and 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 Gloom. Unlike Peter, a plumber with training and experience, Peggy lacks formal project management education. 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 burst pipe, her assurances create a perception of progress. But while Peter rolls up his sleeves and tackles the problem directly, Peggy’s approach turns into a morale-boosting exercise that fails to address the underlying issues.

As the project spirals into disarray, the contrast becomes stark. Peter would face demands for a refund if he did not adequately fix the problem immediately and within a warranty period. 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 demonstrates that organisations and individuals who claim to be professionals—whether plumbers or project managers—must be accountable for the results of their work. Just as Peter's reputation depends on resolving plumbing issues, a project rescuer's success should be tied to measurable outcomes, ideally with a money-back guarantee for their services.

Accountability in Project Rescue

Fundamental changes are needed to ensure accountability in project rescues and prevent a Project Gloom mishap, including but not limited to:

  • Transparent communication: Rescuers must prioritise open dialogue with the project team, who is familiar with the details, rather than focusing solely on presenting a conceptual rescue plan to executives. This approach ensures that those who understand the intricacies and will ultimately act on any proposed rescue steps are fully informed of the project’s actual state and the necessary next steps.
  • Performance-based fees: Professional fees should be tied to specific milestones and deliverables, ensuring fees are only paid for quantifiable progress. If Peggy promises to turn around a project in three months, her compensation must be directly linked to measurable improvements delivered within the agreed timeframes.
  • Money-back guarantee: Every project rescue contract should include a guarantee to protect the project from paying for the  failure to deliver the rescue remit.