Why Wait for Project Kickoff – Let’s Go!

Business Analysts… has this ever happened to you?

The project customer that you are getting to know pre-kickoff or the project manager or anyone on the team or even your own senior management wants to start a project right now? Today. No matter what. Let’s go. What are you waiting for?

It’s hard sometimes to wait and do things right. I realize that. But as the business analyst assigned to the project, you are tasked with helping the project manager make sure everything is in place, all those ducks are in a row, and everyone is on the same page before you start. I’ve seen it happen before – I’ve been in the middle of it on a project I was assigned and went onsite to the customer. Truly, finding out a little too late that you are starting a project that really shouldn’t be started yet can be a resource, timeline and budget nightmare. Not to mention it can cause setbacks with the project customer – even if it was their decision to move forward now in the first place – that are hard to get past. First impressions are everything and you end up looking like an idiot who is not in control of the engagement when a project starts prematurely and needs a restart. It isn’t pretty and it is never fun.

So, how can this be avoided? In my opinion, there are five things that you need to know – especially on technical projects which are mostly what I deal with – before you can really kick the project off. As you read through my list, please consider your own top 5 or things that you would add to this list and let’s discuss.

Has the customer had any necessary training?

Sometimes, in order to successfully nail down project requirements, the customer needs some knowledge about what your product is and does. If they don’t have that, then they may have trouble giving you a clear picture of their relevant business processes that are being affected by the solution. It’s hard to go from the “as is” to the “to be” if you don’t know what is getting you there. If a little training or a couple of webinars will help them get there and make requirements definition successful…and shorter…then halt the project and provide that training. You will not be sorry and neither will your client. I’ve had to do it…trust me it was worth it.

Is funding in place?

The money issue. Is it really available to make this happen? Companies fish around with consultants and project customers fish around with delivery organizations considering potential projects before money is really in place to move forward. Sometimes that funding can take another six months…sometimes it never happens. It’s a painful question to ask so be careful. But if you sense it may be an issue, you need to figure out some way to ask this question.

Do we have the staff ready to staff this project?

Resource-wise, are we even ready to execute on this project. Do we have staff available to take this on? One organization hired me as a consultant to setup some planning tools just so they could figure this out on an ongoing basis because they had a CEO selling projects worldwide faster than they could staff and have available equipment for project execution. Signing up clients was never a problem, but executing on them because they didn’t realize their resource pool was expended was the problem. You’d think that’s a good problem to have but it really isn’t. I was able to help them solve that before they lost too much credibility with clients and then they were able to set realistic expectations with new clients on when they could really be ramped up resource-wise to execute on their projects.

Is the project feasible?

Is this project even feasible? And if it is feasible, is it even really worth it. I mean, we know that we can put a man on the moon…sure…but do you really need that and want to spend that kind of money? Heading in to kickoff and planning on something that logically can’t be done is a waste of time and money. Look at the proposed project on paper and make sure that it is a real project worth at least thinking about vs. some pie in the sky idea scribbled on a napkin by an executive at a bar at 2am.

Do we have some high-level requirements?

We all know that we are going to need to define real requirements with the client. But coming in we need at least a 10,000-foot view of what the client thinks they need. If not, it’s going to take a lot of project team time and money just to figure out what they need. Having some high-level requirements at least gets us in the same book if not on the same page. Working from high-level requirements instead of nothing at all can actually save thousands of dollars and many days or even weeks on the project timeline. If they don’t exist, send the customer home for a week to figure these out and then come back to the table.

Summary / call for feedback

The bottom line is we need the proper planning, schedule and kickoff meeting in place before we start the work. Too many things can fall through the cracks and cause project problems even before we get started and if we don’t stay in control from the start the project can quickly veer off track.

Readers – what makes up your list? If you haven’t had an anxious customer or team to quell yet, at some point you probably will so be considering this. Have you had any nightmares you experienced on projects that were forced to start before they really should have started? If this has happened to you, what did you do to fix it? What would you do next time? Please share and let’s discuss – it can be a painful experience and you may or may not be powerless.