Failure Hackers
I’m reminded again today of the classic machine gun salesman at a medieval battle being turned away by the General because he is too busy fighting a hopeless battle.
What’s triggered this reminder today is a leader in a much more modern than medieval technology space.
Working against an overwhelming backlog of items that need their attention, but unable to make the time to discuss tactics to help tackle the backlog……because they are too busy battling the backlog they are working through. *sigh*
There is plenty of research that demonstrates that projects across industries and geographies struggle to meet the most basic targets.
Source: “Why do projects fail?”, Project Magazine, Summer 2015 (http://bit.ly/1QpmN1G)
These do not meet their cost targets. Most strikingly, this trend has been constant with no improvement over the past century.
A good example of a major project failure was the NHS National Programme for IT, also known NPFiT.
Some of the headlines from the project that hit the newspapers were not good reading.
The Dyson electric car project was a high profile newsworthy attempt to enter the electric car market by the innovative engineering firm.
Typically there are three dimensions to project success. These are known as the three constraints, Iron Triangle or project triangle:
Quality is the 4th constraint that exists in the centre of the triangle. Quality focuses on the project’s outputs being fit for purpose.
There was research undertaken by the Oxford Global Group into data on over 12,000 projects:
For me as a project professional, this is a poor state of affairs but a strong indicator as to how prevalent project failure is.
Knowing there are key factors that influence project failure is a good start to prevention.
In terms of identifying whether or not your project is going adrift you have to keep your senses alert and be on the lookout for symptoms.
On the Time factor then symptoms could be missed milestones, late deliverables, risks around timelines escalating.
On the cost factor there could be symptoms around a lower spend profile than forecast (something not being done when it should to incur the costs) and then the alternative is a higher spend where unforeseen costs appear.
With the scope factor you could face additional activities coming into scope that were previously unknown.
Managing the symptoms early will ensure the project can course correct before significant harm is done.
You can read up on how to address the symptoms of project failure starting the series with the article here.
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.
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.
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.
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.
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:
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.
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.
The three key factors that drive projects are:
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.
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.
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.
