No one likes to tell the customer to wait. But starting a project before everyone is ready and before all the details are worked out is a very bad idea. Here are nine things that can delay the start of the project.
No one likes to delay the start of a project. No project manager likes to break the news to the customer that the customer – or the deliver organization – is not ready to start yet. It can set a bad first impression that is difficult to recover from. But not ready is not ready. And you'll never be sorry delaying the start of a project till everyone is ready. Success is much easier to achieve that way.
That said, let's consider my list of nine good reasons to delay the start of a project. Solve these issues first...then start.
1. Customer needs training.
I've been here before. This reason usually comes about when you are looking to implement a proprietary solution at a customer location and they lack the necessary knowledge on the solution...and thus are unable to help connect business processes with real requirements. The customer needs at least some understanding of the technology and capabilities of the proposed solution – otherwise they won't be able to help you get to detailed, final requirements. And those requirements are critical to delivering the right end user solution.
2. Requirements are a mess.
Again, requirements. They are the lifeblood of the project. Without them you can't start the real work designing and developing the solution. You can't test the solution and the customer won't be able to do user acceptance testing (UAT). And you'll be very sorry when trying to manage project scope. Bad requirements means there is no real project scope. Delay the start of the project till you're ready to define real, complex and detailed requirements.
3. Funding not in place.
Gotta love those customers who talk you into starting work without a real budget in place. You may find out the hard way that they only have 25% of the work funded and the rest was just somehow “going to happen.” Wait till everything is signed and a budget or funding is in place...even if it means delaying the start of a big project.
4. Real project not defined.
Sometimes – surprisingly often, actually – the real project is not what is identified upfront. It may only be a symptom of the real need. Walk through business processes with the client...discuss the project and potential solution...ask questions. If more planning is needed, then add it to the timeline. Don't start before you know what you're starting. You will regret it. Trust me.
5. Goals not defined.
What is this project supposed to accomplish? If you don't know the detailed goals or that nice end target, how will you know when you get there. Sounds like more planning must happen. Talk about the goals. Know what you're shooting for before starting the work.
6. Team not assembled.
Let's face it, the PM can kick the project off by themselves...though I like to have a business analyst assigned if at all possible. But they can't start the project work. You need a team assigned before you can get started or you'll be knee deep in trouble before you start. The end result will likely be some customer frustrations and confidence issues. Better to delay than to start short-handed.
7. Customer disengaged.
It's tough enough to look around and not find your project sponsor or key customer contact unavailable at mid-project for information and decision-making. If this is already happening right out of the gate, perhaps the project needs to wait till they are fully available for planning, or maybe a new key customer contact needs to be assigned. Either way, delay the start of the project.
8. No formal project kickoff scheduled.
Don't start the project without a somewhat formal project kickoff session. I repeat, don't start without kickoff. How formal or how big depends on the project size and importance, of course. But you need that kickoff so that all expectations can be set and so that everyone starts on the same page. If it isn't scheduled or you can't manage to get this to happen, delay the start of the project. You won't be sorry that you did.
9. Project leadership not defined.
If project leadership on one or both sides of the project is not yet defined, then there is no reason to start the project. The PM for the delivery side must be in place...not just some company exec or even just the business analyst. And certainly you need to know who you're working with on the customer side. Changing leadership there could mean changing requirements or direction before the project even gets going. Delay the start till leadership is in place. Think of the re-work you'll be avoiding by doing so.
Bad news is bad news. But good project managers can put the right twist on the type of bad news I'm describing here to show it's for the best to delay the project start date.