Categories
Cause Feature Symptom

Causes of Project Failure

The causes of project failure can be chameleon like in their manifestation and rarely is there a single catastrophic event that leads to the downfall of the project.

Types of Causes

There are two types of causes that you should be aware of and the importance revolves around whether the causes you expend effort to address are within your sphere of influence and control or not.

Just a Cause

There are the simple plain old causes that happen. Someone was sick so a report was missed.

There was a delay as a result of the supply-chain failing to deliver a part on-time.

These causes occur and they leave little impact and are genuine one-off causes that were a product of circumstances that are unlikely to happen again and if they did, it would be infrequent and the impact would again be minimal.

Some causes are the result of something else further up the branch.

The problem with causes is that you can expend time and effort to remedy them but they may not be the root of the problem.

Root Causes

If you are investigating a cause of a problem then you should always seek to find the remedy that ensures the cause (and its symptoms that are time consuming and distracting) cannot occur again in the future.

‘Root causes’ are causes (when resolved) that save significant time, effort and delay down the line.

By eliminating a root cause, you eradicate any downstream causes and all the symptoms that would be generated from those causes.

Fixing Root Causes provides a compounding effect.

Not only for now and this incident but for all future incidents that this root cause would have generated in the future.

Fixing root causes provides a compounding effect. Effectively preventing future project failures as a result of these causes in the future.

Read about Root Causes and what to do about them next.

Categories
Feature Symptom

Symptoms of Project Failure

Project Failure is rarely from a single catastrophic failure but more often a catalogue of signals lead upto the failure, are these symptoms of project failure?

These signals can be many and subtle:

  • a missed project status report coming through
  • a minor deliverable not delivered to time
  • a risk flares up unexpectedly

All of which in isolation may have different causes or contexts that make them innocuous and no cause for alarm.

When multiple signals begin to occur then these may be symptoms of project failure, there may be a series of causes that are linked and require attention.

Symptoms

Projects often ignore symptoms.

This is not to say that the project or programme manager are incompetent, far from it. But identifying what is and what is not a symptom of project failure is not a straightforward task.

The context and timing of events can play a big part in whether there’s a symptom to be identified or if the manifestation is simply the normal ebb and flow of project management.

How to identify Symptoms of Project Failure

Identifying and Addressing Problem Symptoms

Test your knowledge of identifying symptoms of problems.

1 / 5

Which of the following is a key symptom of a problem in a project?

2 / 5

What symptom might indicate a problem in an educational setting, like school or university?

3 / 5

A noticeable decrease in ___________ can be a symptom of a problem in a retail business.

4 / 5

In a manufacturing setting, a significant symptom of a problem could be:

5 / 5

Which symptom might indicate a problem with a software development project?

Your score is

The average score is 71%

0%

The three key factors that drive projects are:

  • Time
  • Cost
  • Quality

Where there are signals or events that impact either of these three then it is time to investigate if this is a signal or a symptom.

Difference between a Signal and Symptom?

A not particularly challenged work stream missing a status report would indicate a signal rather than a symptom. Where indictors are good the work stream should be no cause for alarm.

Where the project manager is running hot then a similar missed work stream update might be a symptom to investigate.

The latter would be a likely candidate for further investigation to identify what is the ’cause’ behind the missed update.

Where the project appears to be running fine but there is an inconsistent attendance of the project stand-up, this would be a signal that might go unheeded by the project for a time but should deserve some investigation as early as possible.

What to do with Symptoms of Project Failure?

An identified symptom requires swift action to map back to the cause(s) to address them, yes there may be more than one cause and it can take time to find them and address them.

The immediate action is usually to quickly implement a workaround to address the symptoms if not the cause.

Categories
Feature Resources

IPA Annual Report 2020-21

The IPA annual report of the Infrastructure and Projects Authority is here.

This year the report references:

  • Managing the GMPP
  • Capacity & Capability
  • Infrastructure Delivery
  • Net Zero
  • COVID-19
  • EU Exit
  • Commercial Advice
  • PFI Centre of Excellence and Contract Management
  • International work

Case Studies

  • HS2 Phase 1
  • DEFRA’s Future Farming and Countryside programme
  • Dreadnought
  • The Technology Sourcing Programme (TSP)
  • Army Basing Programme
  • Wellingborough New Build Prison (Five Wells)
  • Leeds Phase 2 Flood Scheme
  • Social Housing Decarbonisation Fund
  • Vaccines Task Force
  • Space-based PNT Programme
Categories
Feature Resources

Lessons from Transport for the sponsorship of Major Projects

It is vital that we are constantly challenging ourselves to learn from experience when things go right, and perhaps even more importantly, when things go wrong.

Link to the report with the five themes and twenty four lessons is here.

Theme 1 – Accountability must be unambiguous:

  • Ensure clarity of role and extent of autonomy
  • Hold the Delivery organisation’s Board accountable for controlled Delivery
  • Evolve Governance and personnel across the lifecycle stages
  • Maintain a stable scope and operating environment
  • Joint sponsorship requires careful design and operation
  • Join up across Departments

Theme 2 – Behaviour matters more than process:

  • Act decisively when in exception
  • Invest in building relationships between leaders
  • Use control gates to step back and consider status objectively
  • Challenge the objectivity of delivery confidence assessments
  • Recognise both the value and limitations of independent assurance
  • Invest in preparing contingency plans for the most significant risks
  • Identify, capture, share and apply lessons

Theme 3 – Control schedule and benefits as well as cost:

  • Use an evidenced range rather than a single target date
  • Set a realistic cost envelope
  • Protect benefits
  • Test value for money through benchmarking
  • Increase focus on managing schedule

Theme 4 – Deal with systems integration risk:

  • Ensure clear organisational accountability for systems integration
  • Reduce systems integration risk by controlling complexity
  • Protect the test phase diligently

Theme 5 – Enter service cautiously:

  • Ensure clear accountability for the decision on whether to commission
  • Manage the whole portfolio to protect other projects and service users
  • Prepare to recover from disruption when new services are introduced

Further Lessons from Major Service Transformations are available.

Categories
Feature Resources

Lessons from Major Service Transformation

This NAO Briefing Note (2015) outlines the major lessons of service transformation and can be found here.

  • Lesson 1 – transformation programmes raise the greatest risks of failure
  • Lesson 2- set realistic goals and be honest about what really matters
  • Lesson 3 – policy development must take account of implementation
  • Lesson 4 – don’t be tempted to score benefits early
  • Lesson 5 – do identify tangible short-term gains
  • Lesson 6 – recognise the (senior) organisational cost of transformation
  • Lesson 7 – don’t underestimate what you can learn from engagement
  • Lesson 8 – recognise the value of learning and market development
  • Lesson 9 – do anticipate the need to make changes in live running
  • Lesson 10 – recognise the opportunities and limits of technology
  • Lesson 11 – set out clear decision-making and challenge