/* Template Name: Autoresponder */ Myth #11: A New Project Manager Would Recover An Out-Of-Control Project – Part #2 (Lesson 31) - Global Village Transformations

Myth #11: A New Project Manager Would Recover An Out-Of-Control Project – Part #2 (Lesson 31)

 

How do projects get into such trouble?

The simple answer is, of course, one day at a time.

This email series should have already given you plenty of clues that point to some of the easily avoidable pitfalls, so I will not repeat them here.

In general terms, though, consider the following key aspects of troubled projects:

  • Projects do not suddenly get into trouble overnight.
  • Early warning signs are often overlooked or misinterpreted.
  • Many project managers lack the skills to recover a troubled project.
  • Many companies do not know how to handle troubled projects.

So, what are the early warning signs that could indicate trouble ahead for a project?

Sound the alarm bells…

There are many ways in which a project can encounter problems, but not all of these problems will lead to failure.

In complex technology projects, uncertainty and risk mean that much of the detail is unknown at the beginning of a project. Thousands of problems will pop up all through the project life cycle, which is what the assembled team of talented resources are employed to overcome.

Early warning signs that may prove to be a portent of impending failure include:

  • People:
    • Poor morale on the project team, or amongst stakeholders/end-users.
    • Tension within or between teams and stakeholders.
    • Lack of commitment from stakeholders.
    • Unexplained or high staff turnover.
    • Lack of resources/priority not assigned to this project.
    • Resource conflicts between this project and other projects.
    • Resource conflicts between project and BAU workload.
    • Lack of accountability or acceptance of responsibility.
    • Excessive hours being worked, and excessive/unacceptable workloads.
  • Governance:
    • Lack of visible sponsor/direction.
    • Lack of involvement or commitment from the steering committee.
    • Lack of clear processes.
    • Decisions not being made in a timely fashion, resulting in missed deadlines.
    • Ill-defined scope and/or excessive scope change.
    • Requirements that are unclear/ambiguous/contradictory.
    • Requirements that are not agreed or prioritised.
    • Ignoring the project manager’s advice/requests for help.
  • Project Management:
    • Inadequate estimation, planning, or resources.
    • Unrealistic schedule, or overly optimistic/unclear milestones.
    • Selecting an inappropriate approach for the project.
    • Failure to plan adequate quality reviews and audits.
    • Risks not being identified/not being correctly managed.
    • Starting the next phase before completing the previous phase.
    • Progress reporting that is non-existent/inconsistent.
    • Progress reporting with the wrong focus, or that lacks proper tracking metrics.
    • Lack of appropriate change control, or striving for perfection.
    • Unclear and/or unrealistic expectations.
    • Many ‘unexpected’ problems that should have been recognised earlier.
  • Outcomes:
    • Business case that is no longer achievable.
    • Disagreement over project objectives.
    • Technical blockages that cannot be removed.
    • Change in business landscape lessening need for project outcomes.

Whether or not the project manager or the project governance team can identify the problems and then commit to addressing them determines whether the project enters the death spiral – or whether control is retained.

This is a good point to bring in help from outside the project to provide an independent health-check and an unbiased view of the real project status.

Once a project is in its death spiral, avoiding project failure will only happen through decisive, corrective action by the whole organisation, and the skilful leadership of a great project manager with excellent project recovery and rescue skills.

Projects are not recovered by chance, nor by the drug called ‘hopium’.

How many problems in the chain of events will be encountered before your project starts to go off-track and needs to be recovered?

How many problems will you ignore before your project spins out of control and needs rescuing?

Worse still, how many problems will you ignore before your project is terminated, having failed to deliver against most (or even any) of its intended outcomes?