Image by José Manuel de Laá from Pixabay.
Why are so many projects late? In project management there are so many details that can cause a project delay.
In the delayed projects I experienced, there were similar causes. Find out what causes project delay and what countermeasures you can take.
8 Important Causes Of Project Delay – And Countermeasures
Cause 1 – Ineffective Communication
I am convinced that the number one cause of project delay is ineffective communication, caused by:
- Lack of information – the right information is not available to the right person at the right time. Without any doubt this will cause trouble.
- Misunderstanding – you assigned a task. The result is not close to what you expected. Does that sound familiar?
Stakeholder management results in a communication plan. This is an effective tool to prevent lack of information. Read my approach to stakeholder management here.
In his blog “little things matter”, Todd Smith presents six interesting ways to avoid misunderstandings. Explore them here.
Cause 2 – Late Reaction To Deviations
It is a possible strategy to deal with deviations only when they show an effect at some point. By then lots of efforts have been spent into the deviation to grow. In addition, time and efforts have to be spent to remove the deviation. Lack of control is a good strategy to cause project delay.
Within quality assurance, I introduce regular control events into my projects. My benefit is that I am able to identify deviations early. The sooner I am able to identify deviations, the sooner I can remove them.
Cause 3 – Ineffective Decisions
There are two types of ineffective decisions that have great potential to cause project delay:
- The overhasty decision – it is quick, but the decision maker may not even have understood the problem to be decided about. You recognize an overhasty decision when the problem is still there or when the decision causes even more problems.
- The perfectionist decision – it is perfect. It considers all information available. It created a solution that is capable of completely solving the problem with least possible efforts. But since the process took so long, in the mean time the problem was solved by a number of isolated workarounds that have already caused a much bigger problem.
How can you make effective decisions? I am confident in my decisions when I follow a structured decision making process. Beyond that, I highly value Graham Oaks’ considerations about slow decision-making. Find them here.
Cause 4 – Interpretation of Requirements
At some point in a project it may turn out that the project team and the customer do have a different interpretation of a requirement. Resulting discussions and the correction of already performed tasks have a great potential to cause project delay. How can there be a different interpretation?
One of the reasons is that a customer and a project team do have different perspectives: A customer tends to focus on the satisfaction of his business needs. A project team tends to focus on an efficient way to realize a product or service. Sometimes the wording of a requirement can be interpreted in both ways.
What can you do about this? When writing requirements, I make sure that I do understand the customer need. How can I be sure? I discuss the requirements and needs with my customer until I am confident that we have the same understanding. I include that understanding of the need into the requirement data.
Cause 5 – Change of Requirements
Business is changing. So are the needs of the customer. Shouldn’t changes to a requirement be easy to be implemented into a project? Sometimes they are, more often they open a box of worms. Documentation, interfaces, overall functionality – just to name a few things that may come up and cause unpredictable project delay (read my post how to avoid undesirable changes).
Don’t get me wrong. If the requirement as it is does not fit the customer need any more, I believe it is necessary to respect a customer request for change (read my post about necessary changes). To manage the impact of change on the project, I follow a structured requirements change process. If the customer is willing to accept the impact, the requirement can be changed.
Cause 6 – Over-Compliance
Technology is advancing. So are the capabilities of the project team. Wouldn’t it be great if all that potential can be integrated into the project result? As an engineer I feel thrilled to do so. But as a project manager I know, over-compliance causes project delays.
How can you prevent over-compliance? Besides continuous control, systems engineering practice includes several milestones. At each milestone, there is a chance to reflect, whether the achieved results and upcoming steps comply with the requirements. For me this also includes schedule and cost requirements – which both help me to eliminate over-compliance.
Cause 7 – Over-Ambitious Schedule
Schedules need to be ambitious. If they are not, the spare time will be wasted anyway and the project cost is higher than necessary. In a bottom-up planning approach, the project schedule is aggregated from task and work package durations. If some of them – in particular those on the critical path – are over-ambitious, they cannot be kept and cause project delay.
While over-ambitious schedules can even exist with the best planning, I observed two major reasons for them:
- Underestimation of efforts – some tasks just sound too simple. There is no need for detailed investigation of the efforts. They can be done quickly. Obviously.
- Design to schedule – Oh, the plan does not meet the predefined project end date? Lets just cut the durations of some tasks, there must have been margins anyway.
The first reason can be countered with discipline only. I use a checklist to estimate the efforts for tasks. And I force myself to complete it even for the “simple tasks”.
If my project schedule does not meet the end date, there are better solutions to prevent project delay than just randomly shrinking bars in the Gantt chart. Read more about fast-tracking and crashing your schedule here.
Cause 8 – External Delays
A project delay does not have to be caused within a project’s internal environment. External delays can be another important reason for a project delay. I consider these three sources for external delay as most important:
- Subcontractors – If a subcontractor is late, the project may be late. All the causes presented in this article are also relevant for subcontractors. They are the most important causes for subcontractor delay.
- Customers – The project customer may be responsible to create some preconditions for a project to be completed (e.g. infrastructure, interfaces, operating staff). If those preconditions are not created in time, there will be a project delay.
- Suppliers – Even if project supplies are only ordered, they can cause project delay. There may be production delays or logistic delays. The order might also just have been placed too late.
I see two strategies to deal with external delays. And I would follow both. Besides the agreement of contractual consequences for delay, cooperation is a promising strategy: transparency and communication are great tools to identify and solve problems early enough to prevent project delay.
How To Recognize These Causes?
One thing is knowing how project delay is caused. The other thing is recognizing whether any of these causes are already in place in your project.
Quality management defines processes that are designed to prevent project delay. Within quality assurance in a project, indicators have to be defined and monitored. Depending on size, importance and budget, the project manager may be supported in his project monitoring tasks e.g. by:
- a quality assurance manager
- independent project surveillance
- project management coaching
Are There More Important Causes?
For sure. In my experience, the causes above are just the most important. Are there any causes missing that are important to you? Please leave a reply with your feedback below this post. Also do not hesitate to contact me.