Five Top Causes of Project Delays
Delays happen – sometimes for things way out of the project lead’s control. Project delays are a way of life in the project management world. We do everything we can (at least we think we are doing everything we can) to avoid project delays by starting with a good project schedule that we’re watching closely. We stay on top of all the project tasks, we create filtered reports that make it easier to see what tasks are on schedule, what tasks are late, what tasks should have already started that haven’t started yet, what tasks are starting next week, etc., etc. You get the picture. We have the ability to be on top of the tasks at any point in time.
So why are we ever late? Well, I think we all know that there is far more to keeping the project on schedule than just monitoring project tasks in a piece of software. If that were true, my dog could probably be a project manager. It takes much more than that including keen leadership, decisive decision-making, some timely negotiation, periodic conflict resolution, and some good old fashion luck.
But there are definitely things that come up – that we can’t help or that we couldn’t anticipate or that we perhaps did not prepare well enough or thoroughly enough for as project managers and project team members – that can easily and swiftly throw our project timeline off course. From my experience, here are my personal top five…
Any time you change resources on a project, you are inviting risk, issues, customer concerns, and potential project delays. The outgoing resource had tasks and the incoming resource knows little to nothing about the project (usually), let alone the tasks that the outgoing resources was working on. Not only do you need to get the incoming resource up to speed on the project as quickly as possible (this can be costly and time consuming), but you also have to educate them on their new role and everything the outgoing resource was working on. And, you want them to be as efficient and effective on the project as quickly as possible – otherwise you may start to cause the project customer concerns that the team has now been weakened and that this ‘change’ should be considered a project setback. You don’t want to go there. So swift action must be taken – and the only way to do that is to dedicate some time and resources to the effort of getting the new resource on-boarded. This can cause some delays and definitely some costs that had not originally been planned for.
I realize this sounds incredibly broad, but it is not inaccurate. If you plan for risk you still won’t plan for everything. If you think of anything that could come up, you’ll still miss something. I had a huge project with the Food and Drug Administration (FDA) go completely south because the legacy data ended up being a much bigger integration task than we had previously planned for, priced for or brought in the resources for. This caused delays, budget overruns, and ultimately led to a cancellation of the original project. It was not a proud career moment. Issues happen and must be managed carefully. But every project from the beginning of time on has been affected by unforeseen issues…how much they delay the project depends both on their magnitude and our ability to react quickly and efficiently to them.
There can be little argument that scope issues can cause project delays. If they are quickly detected and documented as change orders, then revenue and time can be added to the project and everything remains on track. But if out of scope work creeps into the project, then the budget takes a hit and the schedule will be at risk for the rest of the engagement. The key is to manage scope as closely as possible – and that’s no small task when you have multiple individuals talking to the project client and doing work for them. Education of the project team is critical – make sure they are aware of what gold-plating means and what may or may not be within the scope of the project as laid out in the statement of work (SOW) and requirements. Weekly internal team meetings are a must, and scope issues or concerns should always be a part of this essential team meeting.
I mentioned risks earlier. We all talk about them, but most of us do very little – and sometimes nothing – to identify potential risks early in the project. Even if we do, we are rarely thorough at planning for them and how we will either avoid them or mitigate them. It’s time consuming and everyone wants to get down to the real work of the project. Don’t skip the very important risk management step – it’s critical to avoiding major issues and rework later in the engagement.
Never discount the affects of changes on the customer side that can significantly impact the project timeline. Organizational changes at the customer level can change priorities on their side leaving you with unanswered phone calls and outstanding tasks that the customer is making no measurable progress on. Customer sponsors can get bogged down with their ‘day jobs’ and can suddenly find themselves with little to no time to spend on this new project effort that was dumped on them. That leaves you with no one to go to for questions, answers, and decisions that must be made…thus delaying the project further.
When a customer becomes disengaged, weekly participation in the ever important status call can be disrupted leaving you wondering if you should be plodding ahead or pulling up the reins waiting for input from the very entity that you are doing all this work for. I’ve seen teams move ahead when a customer becomes disengaged, only to find themselves heading in the wrong direction when the customer re-enters the picture. There’s only one word for it…frustration.
Summary / call for input
This is just my list of my personal top five that I’ve come up with from experience and colleague interaction. What are your thoughts on this list? Does it match up with your experiences? What other major or common causes for project delays have you experienced or noticed? How did you respond or workaround these delays?