As project managers, we certainly always want to get our projects off on the right foot from the start of a project, right? We want to do anything possible that we can do to ensure the success of our project and there's no better start than having everything in order as we prepare to embark on kicking off the project. After all, it's our first impression that we'll be giving to the customer, the customer team, our own project team, and any other stakeholders involved in the project or with a vested interest in its outcome. You want to make a good first impression because if you misstep in the beginning, you know that you can create a level of concern, dissatisfaction, or lack of confidence that can be very hard to overcome. You will have dug a hole that you now have to climb back out of.
Let's consider, then, some common problems that project managers encounter when they begin to kick off a project and discuss possible ways to avoid or remedy those potential problems ...
Knowledge transfer from the deal closer
It's a given you need knowledge transfer from the account manager who closed the actual deal with the client and any technical people that may have helped clarify requirements or mockup reports and prepare a final price for the client. These are key pieces of information for your project moving forward and you'll need the proper amount of contact with these individuals prior to preparing for a formal kickoff with the customer. If you have trouble reaching these people, then it's imperative that the kickoff be delayed. The project kickoff is your time to fill in the gaps before you start real work with the customer on the project. If you go into the kickoff session with less than EVERYTHING that is possibly available to you, then you're already one step behind. Don't do it. Never kickoff the engagement till the proper amount of knowledge transfer has taken place.
Detailed budget not set up
Ok, so you best and final budget may not be in place - it probably never will be because you'll be refining it on at least a weekly basis throughout the project if you're properly staying up on it. However, you should go into the project kickoff with a detailed project budget setup based on everything you know from the knowledge transfer, the statement of work, the final price, resource assumptions and planning that was done to prepare the estimate, and your own information that is budget input from your project schedule that you've started putting together. Have the detailed budget ready for project kickoff because there will likely be some changes necessary and if you've got it in place then they are just that ... changes. Otherwise you'll come out of the project kickoff with a lot of extra work still left to do before you can start working with the customer on the project.
Resources not in place
Depending on your organization and how resources are assigned to your project, you may not have a full team assigned at the time of project kickoff. And you may not want an entire team assigned because the minute they're assigned they are likely charging - and you don't want that to happen if you're not ready for them to start charging any time. It can cause you budget problems early on that you hadn't counted on. However, it is wise to get someone assigned - likely a business analyst (BA) prior to the kickoff meeting so that they can attend and take notes as well as ask some deeper technical questions of the client. Getting some answers out of the way at the kickoff meeting can help you have more productive working session going forward after the project has been formally kicked off.
Too many customer participants
At the beginning of any project, the customer is usually very excited about getting started. And, in order to keep everyone even remotely involved with the new solution up to speed, they will often tend to invite as many people as possible to the project kickoff meeting. I've kicked of projects at the customer site where there have been as many as 45 participants from the customer side and it's taken two days to get through the material and all the questions and discussions from the many people who were 'involved' but weren't prepared in advance. Forty-five client participants are way too many - about forty to many to be exact. If your customer needs or wants more than 5 participants sitting in on their side - and I mean active participants who have a vested interest and something to offer to the discussion - then there's something wrong. Work with your customer in advance of the kickoff session and find out who they intend to bring to the table so you can work to limit the number of participants before you get unwittingly overwhelmed when you show up to kickoff the engagement ... .as I did. Lesson learned, and it will never happen again. Funny how we usually have to feel the pain at least once to figure it out, isn't it?
Customer unavailable
Just as concerning as 'too many cooks in the kitchen' on the customer side during the kickoff session is the potential lack of availability - or even involvement - of the customer prior to or during project kickoff. It's their project and their money - you would think they'd want to be heavily involved in at least making sure the project gets off on the right foot. Right? But that's not always the case. Granted, it's a rare occurrence - at least it has been for me. But it does happen ... and it's very frustrating. You get information from your account manager and you need to follow-up with the client to clarify some issues or assumptions or things that were discussed as you prepare for a formal kickoff - and then you can't seem to get a minute of their time. It's a dangerous precedent to set because you need their input and if they are willing to be involved now, what real chance does your team have of success throughout the project? Beware and be aware of these situations. Go over the sponsor's head if you need to because if you're not getting critical answers or information that you need as you kickoff the project then there are likely going to be problems soon with the budget and project timeline and planning ends up taking longer than anticipated.
Overloaded delivery team resources
When resources are assigned to your project, be sure that they are ready to work on your project. Few things are more frustrating than getting a key resource assigned and counting on them for work only to find that they're really overloaded on another project you'll have to wait. Well, the problem is, you've now set project expectations with the customer and customers aren't usually very patient when it comes to resource excuses. Go to the resource's supervisor or to whoever assigned that resource and either get them freed up or get a different resource assigned ... ASAP. Waiting very long can cause serious customer satisfaction and project timeline issues.
Poor customer requirements
It is a critical one and also a very common one. Your best scenario sees the customer come in with detailed requirements that he has documented through many meetings with his end users and support staff. With these in hand, you have an excellent view into his business processes and what he really needs the end solution to look like. That almost never happens. But something close or at least reasonably close is still getting your project off to a great start. The converse is the problem. When your customer comes into the working part of the engagement with very little documented in the way of meaningful detailed requirements then you know you have a great deal of planning ahead of you for you, your team, and the customer. And if your customer gave one expectation to Sales who closed the deal and a very different scenario plays out once the project gets underway then what that means is that all that planning you need to do to get the real requirements documented is above and beyond the price of the project. Now you have to hit the client with a costly change order right out of the gate - and that's not going to make them very happy even if the fault is theirs and not yours.
Major change in requirements during kickoff
Another problem that also centers on requirements is the issue of a major requirement change coming to light around project kickoff time. The project is planned and priced for one technology and as you sit and discuss the project with the customer - no matter how detailed their original requirements are - you find that an entirely different technology is going to be needed which may be resulting in tens of thousands of dollars more expense than anticipated ... or priced. Again, another situation where you have to immediately be discussing a price increase with the customer and it's just not a great way to start off the project.
Disagreements on how to proceed
Finally, as you're kicking off the project with the client you may have a process or methodology that you have followed successfully many times before. And you're the PM in charge of reporting, communication, your team, etc. If the customer comes in demanding an entirely different process or methodology or is mapping out a different plan for the project than you may find yourself with a disagreement - or even a stalemate right out of the gate on the project. Or you might find yourself working with a controlling client who wants his PM in charge of everything - making it difficult for you and your team to work and make good project decisions in a timely manner.