In last week’s article, we started to look at the reasons why projects fail. We set out the first five of ten Points of Project Failure.
In this week’s article, we’ll look at the second set of causes. Five more reasons why projects fail.
If you did not read last week’s article, I recommend you do so first.
I have observed ten points of project failure. Because there is a lot to say about each, I have had to split this article into two. The first five are last week’s article. They were:
Let’s just dive in, and get started!
Below each Point of Project Failure are examples of primary reasons why projects fail.
No resources: no project. That much is obvious, I hope. However, it is often the case that projects fail when there are insufficient of the right resources in the right place, at the right time.
If you don’t have enough resources (money, people, materials, tools…) your project will struggle. As a project manager, your ablity to negotiate for what you need is part of your route to success.
But equally, projects fail through having the quantity, but not the quality. It is usually better to have the right resources in too small a quantity, than plenty of the wrong ones.
‘Judy is the right person. We’ll get her to do this.’ Brilliant. But is Judy available? Has she got enough time? Does the time she has available match the time when you need her? Hadn’t you better speak with Judy before you assign her to the role?
You may have a very clear idea of what you expect of me. But do I? Is my sense of it the same as yours? Always document roles and responsibilities. And, ideally, do so after negotiating them with me, not before.
This could equally fit under ‘weak leadership’. However you classify it, if your people aren’t committed to your project’s success, they may as well be committed to its failure.If your people aren't committed to your project's success, they may as well be committed to its failure. Click To Tweet
It would be easy to conclude that projects fail because of poor Project Management. That would be glib. But if we start to break down the discipline of Project Management, we can identify numerous points of project failure. Here are some of the more common ones.
Below in this section, we’ll list some of the specific project skills which, when lacking, mean projects fail. But let’ start by noting that an under-trained project manager, with insufficient understanding of the processes, tools, and disciplines of project management, will start at a disadvantage. If you succeed on a small project, you may not necessarily have the full skill-set and knowledge to take on a big one. This was one of the driving forces behind the foundation of OnlinePMCourses.
Again, we’ll look at this in more detail below, but if you are not in full control of your project, it will get away from you. This means giving your project enough of your attention. Projects fail under an absentee project manager, who thinks they can do other things, and so neglects what’s going on.Projects fail under an absentee #project manager Click To Tweet
We will look at this in more detail below, but failing to control quality properly is a common reason why projects fail at a low level. The deliverables fail to meet the required specifications, or start to fail in use. Of course, spectacular project failure can also arise through poor quality control to. This can lead to dire (and even life-thretening) consequences.
It is not enough just to manage your project. You must also lead the people working on your project, so a lack of day-to-day project leadership will leave your team without the motivation or co-ordination to deliver effectively.
One of the biggest causes of project failure is undisciplined changes to specification, once delivery has started. This creates abortive work, and constant calls for additional funding. Staff start to lose sight of what their priorities are, and costs ramp up, with consequent delays. Things don’t get finished and stakeholders start to become frustrated. There is nothing wrong with changes. It is a necessary consequence of the real world. As a project manager, you must, however, impose change control to ensure you cost all changes and make decisions in the light of all the facts.
You might like these articles:
A closely related problem (also remedied by rigorous change control) is scope creep. Project fail when clients continually add requirements and the project team either fails to acknowledge this,or fails to push back or secure additional resources and time. Particularly insidious are undisciplined scope additions from low level staff who pursue their own preferences with no regard to the strategic intent behind the project. Not only do their scope changes consume resource and threaten your project: they also deliver little or no value in themselves.
You might like these articles:
I would argue that a project manager does not need to be a technical expert in the discipline at the core of your project. your technical skills lie in the realm of Project Management itself. However, if you don’t have a strong technical grasp of your project’s discipline, you must find a solution. The way I found was to recruit technical experts on whom I can rely. Having done so, I spend time with them. I want to understand the boundaries of their expertise, and build a strong sense of who to rely on for what issues.
This should not need saying. If you fail to manage risk well, your project is likely to fail. But for the sake of completion, let’s formally note that projects fail when risk management is not properly prioritised and carried out.
We have written a lot of articles about Project Risk Management.
A far more insidious reason why projects fail is poor engagement with your stakeholders. Project Managers like to get our heads down and focus hard on delivering our projects. We are good at managing our team, tracking progress, and controlling slippages and issues. But if you fail to look outwards sufficiently, your stakeholders will feel under-valued and their lack of knowledge about what is going on will be the trigger for gossip and rumours.
We have written a lot of articles about Stakeholder Engagement.
As your project progresses, your products will evolve. So too will the documentation that goes with them. An update here, a correction there. It’s very easy to issue revised versions quickly, and forget to up-issue the version number, or to record the changes. Before you know it, there are two, three, or four versions of the same document in play. And then it happens… Two people, working to two different versions, do conflicting things, because the difference is material. But who was right? It’s dull, it’s time consuming, but it is absolutely necessary to manage version control, configurations and documents rigorously. If you don’t, it may not just be a poor audit trail and questions about accountability that you face. ‘For the want of a nail…’ Projects fail over small details as well as large problems.'For the want of a nail...' #Projects fail over small details as well as large problems. Click To Tweet
Shift happens. So a project team needs to be adept at handling challenges as they arise. An important part of Project Management is your ability to facilitate creative problem solving. Any team is capable of this, as long as they are led well, so this is a core PM skill.A core part of #Project Management is your ability to facilitate creative problem solving. Click To Tweet
A more subtle reason why projects fail is a failure by the project team to fully understand the operational context and the needs of the business. The potential consequence is simple: what the project delivers is not what the business needs.
As your project shifts under you, there comes a time when your plan is no longer a sound guide to the future. The accepted project management approach is to review the baseline plan and create a new plan from which to work. However, to some project managers, this feels like an admission of failure that they would rather not face up to. For whatever reason things have slipped, however, you must face reality. Projects fail with sad inevitability, when project managers succumb to ‘We’ll make up the time later’ syndrome.#Projects fail with sad inevitability, when project managers succumb to ‘We’ll make up the time later’ syndrome. Click To Tweet
These articles include:
Inevitably, projects fail if the products are not tested, or if you fail to give sufficient attention to the quality processes. So how does this happen? Let’s look at some examples.
On a big project, it is reasonable to appoint testing managers, quality assurance managers, and quality controllers. This is not so, on smaller projects. It becomes a distributed responsibility, with these roles sitting within people’s portfolios of responsibilities. But the skills of testing and quality management are specific. So too is the mindset that allows people to thrive in these roles. So what tends to happen is that nobody really wants the job, and so concludes that it isn’t their responsibility. If everyone does that, then nobody takes care of quality. Be very clear in allocating job responsibilities to team members, and periodically check up on how they are discharging each of their roles.
‘It’s bound to work. Let’s just get started.’ Piloting takes time and resources, so we can move more quickly if we skip the prototype and spend more time shaking down the prime product. Oops. The problems are bigger than we thought. If only we’d discovered that earlier, before we committed all our resources. Projects fail often, when we start the delivery without strong evidence that our products will work.
You may have seen projects fail in this very simple way:
build, build, build, build, build, test, fail, attempted fix, fail, attempted fix, fail, attempted fix, fail… project abandoned.
Don’t just push testing to the point where it is too late to catch fundamental issues. Even if you can remediate, it can have catastrophic consequences on deadlines and budgets – not to mention sleep patterns. Test incrementally as you go. This is fundamentally the principle of Agile Project management:
build, test, fix, stabilise, build, test, fix, stabilise, build, test, fix, stabilise, build, test, fix, stabilise, build, test, fix, stabilise, finish.
Whether it is time during the development stages, or time at the end of development or both, projects fail when there is insufficient time budgeted for proper testing and remediation. And, thanks to the wonders of over-optimism bias, the problem usually lies in remediation time. Testing managers make thorough plans to test and document. But the development team, confident as a fox, assumes the fixes will be minor and straightforward. ‘Let’s allow a week.’ A week into remediation, and the problem starts to look clearer… and it’s a big one that could take six weeks to fix, before re-testing can even start. Oops.
This happens especially when project managers find themselves under budget or schedule pressure. They allow a shortened testing process that can only ever establish broad compliance. What gets missed are the complex situations and edge cases. These may not show up in early use, which can mean that this symptom does not lead to obvious project failure at all. In this case, projects fail much later – and it may not even get ascribed to a failing in the project itself. A win for the project team, you may think. Maybe, but a big lose for the organization that commissioned the project.
The real world is messy. Operational users are troublesome. Only project staff can be trusted to be disciplined to use the new systems as they were designed to be used. Therefore, let’s just get the project team to test the deliverables. The obvious problem with this strategy is that those troublesome operational users will do what they like once your products hit the real world. Allow enough time to deal with the ill-discipline of real users doing what they want, without properly understanding how they are supposed to use your deliverables. You may hate the experience but, in the long term, you won’t regret it.
This is the most insidious reason why projects fail as a result of poor testing. Here, the testing shows a clear fault. But someone say something like this:
‘That’s an exception. It can’t happen in real life. Let’s ignore it and move on.’
Need I say more?
A lot of the reasons why projects fail that we have examined in this and the previous article occur during the implementation stage of a project. So I shan’t reiterate all of them here. What I shall do is identify some more, implementation-stage causes of project failure.
Some people say that Project Management and Change Management are different disciplines. I firmly believe they are merely two ends of one continuous spectrum of skills. Either way, though, they are both necessary. If you aren’t planning how to handle the soft, human and cultural issues associated with implementing your project, you are doomed.If you aren't planning how to handle the soft, human and cultural issues associated with implementing your #project, you are doomed. Click To Tweet
Here are some articles, and a full video training program to help you with the soft issues around change:
One specific example of this is failing to offer the right training. New system, new process, old staff. These staff are intelligent, adaptable, and motivated. But they cannot magically do stuff they have never been exposed to. And they certainly won’t be able to do it well, without mistakes, setbacks and delays. Unless you train them thoroughly. This needs to be part of your implementation plan.
You’ve planned for the future. You’ve planned implementation. But have you forgotten the point of handover? What will happen, hour-by-hour, on the day you switch over? You cover everything but this one detail, and your project fails. How ironic.
Ask most people what they expect to happen after their bright shiny project goes live, and they will anticipate a step change upwards in performance. Nope. Won’t happen. What typically happens is a performance dip in the run up to handover. The dip continues after handover, and then, if you have planned and executed well, performance will start to recover. it will rise and rise, to eventually achieve a level exceeding the previous performance level. Success!
But if you don’t anticipate the dip, you will see it as a failure. Projects fail not because they have failed, but because people fail to recognise the dip as a step towards success, and stop the project too soon. Welcome to the world of complex Government policy failures.
A good Project Manager will spend your time trying to control your project. But you cannot control events, decisions, and changes outside it. Often projects fail due to external factors and, while they are outside your control, your response to them is not.
We have talked about the need for good problem solving and creative thinking, but the next step in the process is important too. Projects fail when the project leaders give poor focus on creating the environment for high quality decision-making. You need to be able to respond quickly and accurately to changes and this is partly a matter of governance, and partly down to the quality of time you allow yourself to step back from the day-to-day issues, to survey the trends and think carefully about their implications.
Projects rarely happen in isolation. Almost certainly, the sponsoring organization will also be promoting a good number of other projects and initiatives. If you do not understand these and co-ordinate your project with them, one or more of these projects may fail. And it might be yours.
A little competition is healthy. It drives up standards, boost morale, and generates pace. But too much of a good thing is possible. So don’t allow yourself to get trapped into unhealthy competition with other project teams. If your attention is on them and how to ‘win’, you won’t spot the leading indicators we’ve talked about for why projects fail. And you will lose.
I have saved my favourite for last. Many projects fail for reasons that are wholly aside from poor project management, poor project teams, poor discipline or processes. Everything is good. Except… the organization tries to do too much. It’s commitment to new projects exceeds its capacity, and there are not enough resources to go around. So the projects that fail to get the resources they need, or the management attention they deserve will fail. It’s not your fault. It is a strategic issue for the organization. But if you spot out, tackle it head on, as soon as possible.
In this article and the previous one, we have covered ten areas where Projects fail. One of the big themes that seems to emerge is that they are balanced among ‘hard and soft’ Project Management reasons, which led us to write another article specifically about this idea. But what is your experience?
Why do you think Projects fail?
Please share your thoughts in the comments section, below.
This pair of articles has been so successful, we have created two more-convenient formats for you.
Project Failure is all too Common. What are the Reasons for it, and How can You Stop Them?
How to Avoid Project Failure will alert you to the ten points of project failure. And, for each, you’ll learn some of the primary reasons why projects fail.
Dr Mike Clayton is one of the most successful and in-demand project management trainers in the UK. He is author of 13 best-selling books, including four about project management. He is also a prolific blogger and contributor to ProjectManager.com and Project, the journal of the Association for Project Management. Between 1990 and 2002, Mike was a successful project manager, leading large project teams and delivering complex projects. In 2016, Mike launched OnlinePMCourses.
Please log in again. The login page will open in a new window. After logging in you can close it and return to this page.