Conducting the Project Kick-Off Meeting

The Project Kick-Off Meeting is the formal announcement to the organization that this project has been planned and approved for execution. This meeting happens only once on each project — at the beginning of the project, after the project plan and project itself have been approved but before any work has been done. It is not only a get-acquainted meeting for the team members, but it's also your opportunity to get the project off to a good start.

The meeting signals the start of the project. It has the following two major parts.

• The sponsor-led part
• The project manager–led part

Sponsor-Led Part

The first part is basically a show-and-tell for the organization. Selected senior managers and other interested parties are invited to this brief meeting. It should last no more than 30 minutes. The project sponsor provides a brief overview of the project, why it is being done, what it will accomplish, and what business value will be derived from it. The Project Overview Statement (POS) is a good outline of what this briefing might include.

Project Manager–Led Part

The second part is an initial working session for the entire project team. This part will last for the remainder of the day. Except for small projects, the team members may not know one another, or they may have worked on the same projects but did not directly interact with one another. The project team comprises not only the development team members but also the client team members. In larger organizations, these two groups may never have had the chance to work together before. This first meeting of the entire project team can be filled with confusion about what is to be done, who is to do it, and when it must be completed. Some may be asking, “What is our project manager like and what are her (or his) expectations of me?”

Purpose of the Project Kick-Off Meeting

This is the meeting that gets the project started. You will want to make it an event to remember. Here is a sample Project Kick-off Meeting agenda:

• Introduce the sponsor to the project team
• Introduce the importance of the project by the sponsor
• Introduce the project (client)
• Introduce the project (project manager)
• Introduce the project team members to each other
• Write the PDS
• Establish the team operating rules
• Review the project plan
• Finalize the project schedule
• Write work packages

The meeting lasts until this entire agenda is completed. In mid- to large-sized projects, the meeting often lasts a full day. The first three agenda items are completed in the sponsor-led part. The remaining items are completed in the project manager–led part.

Attendees

The Project Kick-Off Meeting is usually attended by the following:

• Sponsor
• Other managers
• Project team
• Contractors and vendors

The sponsor's role is to get the project team excited about the project and its importance to the business of the organization. In larger organizations, there may be some political ramifications, so other senior-level managers may be invited by the sponsor so that they are aware of the project and its value to the organization as well. For the sponsor, this is a good way to cultivate a support group for later project portfolio decisions that may impact this project.

You might wonder why I include contractors in the attendee list. The objective is to make the contractors feel as much a part of the project as the project team. I like to include them in every project team activity that I can. If possible and if it makes sense, I try to make them feel like an equal partner. More to the point, I like them to have their own work space in the team war room. Having them attend the Project Kick-Off Meeting is a good way to start building a collaborative and supportive relationship with your contractors and vendors.

Facilities and Equipment

The Project Kick-Off Meeting includes a working meeting, and the facility needs to accommodate that purpose. Except for a brief introductory period during which several managerial-level people and the sponsor may be present, the only other attendees will be the project team, contractors, and vendors. In some cases, the first part of the meeting might take place using a theater styled layout, and the working part of the agenda might convene in a more appropriate facility with separate worktables. For larger projects, you will probably need a few breakout rooms attached to the central larger room. If a team war room is available, that would be an excellent choice.

You will need an ample supply of sticky notes, tape, scissors, and colored marking pens. Flip charts are good to have on hand for use at each worktable configuration. You can never have too much whiteboard space. For more high-tech equipment, an LCD projector and a PC are all you need for everyone in the room to see the details as they come together. The project team members should bring their laptops. You should have distributed the POS, Requirements Breakdown Structure (RBS), and project proposal to them earlier, and they should have these loaded on their laptops as well.

The Working Session Agenda

The agenda for the working session portion of the Project Kick-Off Meeting is straightforward. Here's a typical list of agenda items:

• Introduce the project team members to each other
• Write the PDS
• Review the project plan
• Finalize the project schedule
• Write work packages

Introducing the Project Team Members to Each Other

“Hi, I'm Earnest F. Forte, and I'm the Senior Business Analyst in Supply Chain Management” just isn't the introduction I'm thinking about. This part of the meeting is critical to the project manager because it is the first opportunity to begin building an open and honest relationship with and between each team member. Remember you don't have a project team yet; all you have is a group of people wondering what their manager got them into. The introductions are an open invitation to build esteem and credibility among and between all team members. The best way to do this is for you to facilitate a conversation with each team member. You will have to do some homework so that you know something about each person and why they are on the team. Engage them in a conversation that starts with your introducing them by name, position title, something about them, and why they are on the team. They will immediately begin building their self-esteem. Then ask them an open-ended question to get the conversation started. For example, a good open-ended question is “How do you see yourself contributing to this project?”

Writing the Project Definition Statement

One of the first things the project manager will want to do is make sure every team member has the same understanding of what the project is all about. There is a lot of documentation to support this exercise: COS, POS, RBS, WBS, and project proposal. All of these documents should have been distributed to every team member prior to the Project Kick-Off Meeting so the project team has a chance to review them beforehand.

Everyone will come to the Project Kick-Off Meeting with questions about the project and with a different point of view with regards to what this project is all about. That is not a good foundation on which to go forward. It is essential that everyone have the same point of view. To achieve this, I have found that having the project team draft a Project Definition Statement (PDS) is quite successful. Just as the client and the project manager benefit from the COS and the POS, the project manager and the project team will benefit from the PDS. The PDS uses the same five parts as the POS but incorporates considerably more detail. Whereas the POS is a single-page document, the PDS will be several pages. The project manager and the project team use the detailed information provided in the PDS for the following:

• As a basis for continued project planning
• To clarify the project for the project team
• As a reference that keeps the team focused in the right direction
• As an orientation for new team members
• As a method for discovery by the team

In most cases, the PDS expands on two sections of the POS. The first part is the project objectives statement. In the POS, the project objectives are written so that they can be understood by anyone who might have reason to read them. In the PDS, the situation is somewhat different. The PDS is not circulated outside the project team; therefore, the language can be technical and the development more detailed. Project objectives take on more of the look of the RBS. The purpose is to provide a description that the project team can relate to.

The second part is the assumptions, risks, and obstacles statement. The POS contains statements of assumptions, risks, and obstacles that will be of interest to senior management. For the PDS, the list will be of interest to the project team, so it will be much longer and more detailed. In my experience, the PDS list is built during the JPPS, whereas the POS list is built as part of the scoping activity of the project.

The PDS document was discussed for the first time in the second edition of this book. Since then, my consulting engagements have verified that the PDS can be used by the team to help them understand the project at their level of detail. The POS did not satisfy this need, so I developed the PDS. It is simply a variant of the POS designed specifically for the team. In implementing the PDS, I felt that it could further clarify the communications problems that often arise in the project as team members come and go. In the several cases where I have used it, the PDS has proven to be of value to the team.

Reviewing the Project Plan

Some of the project team members will be seeing the project plan for the first time, and their input is necessary. You also need to give them a chance to buy into the plan and begin thinking about their role. They will be the best objective observers you have, so don't miss an opportunity to get their input.

Finalizing the Project Schedule

The project schedule was built in the planning phase, and certain assumptions were made regarding availability. Now it's time to integrate every team member's schedules with the project schedule to present a workable schedule that meets the client's needs. Final assignments can be made, too.

Writing Work Packages

Work packages should be written for every task that is on the critical path, has a high risk of failure, has a high duration variance, or uses scarce resources. You want to protect the project as much as possible from the potential loss of a team member. Knowing how team members were going to complete their task and knowing the status of their task at the time of their loss provides good protection.