That said, I'd like to discuss seven key things that the project customer - and really every stakeholder involved with the project at that point – should know as the project kickoff session ends and the project work and real planning is about to begin.
The communication structure of the project is critically important. I always say that communication is Job One for the project manager. I believe that the responsibility for project communication begins and ends with the project manager. Don't get me wrong; communication is going to happen on the project that doesn't originate or even go through the project manager. But everything important needs to at least be cc'd to that individual and most, if not all, of anything of significance, needs to originate from the PM role. It sends the right message to all stakeholders. It gives a clear picture of who owns the communication and who is accountable for it.
Related Article: 5 Keys to the Best Project Client Retention Rate
Be consistent and the small important things won't fall through the cracks.
Planned meeting arrangements
This goes hand in hand with the communication structure – a subset of that process. The customer and all stakeholders should leave the kickoff meeting knowing when project status calls will happen, how and when any phase reviews, planning sessions, testing sessions, design reviews, and sign off/review meetings will be scheduled and conducted. It's all about setting expectations so that the rest of the engagement can go as smoothly as possible.
How to escalate issues
The customer needs to know how to escalate issues. Again, this is really part of the communication process, yes. But if the client does not know how to raise issue flags and who that should go to, then it may always be an awkward process and can cause customer frustration to rise and customer satisfaction to go down. Set expectations on this from the very beginning because every project has issues. You'll probably leave the kickoff meeting with several issues and many, many action items.
Change management process
Equally important is how the entire project will handle the change control process. How will change orders be originated, managed, estimated, reviewed, approved, signed off, executed, and tracked? And what if there is a disagreement on whether or not something should be a change order? What if the customer disagrees and doesn't believe that a certain proposed effort is really out of scope – who decides that and how? Project change orders are a reality on every project – make sure your customer knows how the project team is going to handle those change orders that will come up no matter how well everyone understands the requirements.
What happens in the first two months after kickoff
When the project kickoff session ends, the real work on the project starts. All key stakeholders on the project should have a very good feeling about what is happening over the course of at least the next two months on the project. The project schedule alone should show that. But even more specifically, that should be a goal of the project manager to thoroughly discuss what happens next on the project and to set expectations for what happens next among all project stakeholders. And I don't mean what happens in the next week or ten days. Let's plan and plan well. Let's make sure that everyone knows what's happening and what's expected of them over the next two months. Fewer surprises = project success.
The Importance of business processes and requirements
The project customer needs to know how critical it is that the project manager and the entire project team understands the customer's business processes – at least insofar as how they align with and rely on the goals and objectives of the project. Equally important is the customer understanding the critical need to have detailed, complex project requirements identified, documented, and approved by all involved – and signed off by the customer. This is where the project scope starts and what sets the stage for a great project and easier project testing and user acceptance testing.
Delivery team structure
While not an essential piece of the project success puzzle, I feel that it is important to define the project team roles to the customer at the beginning of the project – whether all the roles have been filled at this point or not. Knowing that the team is loaded with the right roles (and the right people) will go a long way in giving the project customer the confidence to know that his project is being handled in the best professional way possible. And it lets him know that the delivery team understands the project and what it is going to take to get it done right.
Summary / call for input
The entire project will be defined at a high level as the kickoff session ends. That better be true. Not everything will be defined in detail – and that which is can always be subject to change. The key is to have the best possible understanding of key elements of the project, who is doing what, how everything will be handled and managed, what is expected of the project customer and what the project manager role will really look. All this can definitely set the stage for a successful project engagement.
How about our readers? What are your feelings on this list of seven things I've presented? What would you add to it? What would you change about it? I've always felt that knowing these things very early on – and knowing what is specifically happening in the next two-month window at any given time – gives everyone on the project a good understanding of expectations and directions. And that's never a bad thing.