Project Planning 1.0: The Importance of the Project Kickoff

[Also available as a Podcast]

You cannot underestimate the importance of the Project Kickoff. It sets the tone for the rest of the project, and it is often the first time all of the key players on the Project will be face to face. In some cases, it may be the only time they all get together - so make it count!

It may also be the first time that you get to review the project objectives as a team, and it is where you will build the collective understanding of what you are trying to achieve - and the first stage in Project Team Development.

But what exactly is a Project Kickoff, and why do we really need it? In this session we will explore what it is - and why it is so important.

What is the Project Kickoff?

The Project Kickoff is not a party. Sure there will be some socializing, team members will be getting to know each other, all that - but it is actually an important key activity in every project.

At this point in time, you will have the project objectives, you (hopefully) have the budget, you have (also hopefully) a Project Sponsor, you have assigned team members...you have a deadline, so ready, set - go!

Well, not quite. If you don't know where you are going, any road will take you there, and if your team does not know where you are going, they will travel as many different roads as you have team members. And nobody will end up in the same place.

You might even have a good starter project plan tucked away in your laptop - but it won't help you, unless you share it. And if you put that on the table right off, it can actually confuse things. So keep it handy, but out of the way for just a little bit.

Your goal, as Project Manager, is to make sure that everyone is travelling, more or less, in the same direction, and will all end up in the same place, at more or less the same time - with a successful project delivery. The Project Kickoff is a key tool (and sometimes a make-or-break activity) for delivering successful projects.

Every project, large or small, needs a Project Kickoff. But they can range in length from only an hour or two, to spanning multiple days depending on the size/scope of your project. If you have a small project (a few weeks, or maybe a month), a short meeting to get things pointed in the right direction (and have everyone agree on the direction and basic details) may suffice. For a complex, multi-year project, be prepared to invest some serious time up-front, clear your calendar and buckle in. You may find you need 4-5 days. On the type of projects I have worked with, this has been the norm.

In short, the Project Kickoff is where the rubber starts to hit the road - all the pieces come into play, and the Project Manager and Project Sponsor set everyone going in the right direction.

When you leave the Project Kickoff you will have many important things hashed out, the team will know who each other are and what role they all play - and you will also have an initial (draft) Project Plan. Perhaps even more than that - but let's start there.

Planning the Project Kickoff

Yes, you need to plan it. Running a Project Kickoff without any preparation can be problematic, even disastrous. The effects can range from loss of faith in the Project Manager ("if this is how they run a meeting, what is going to happen with the project?"), to the project rapidly getting off the rails - which can be difficult, expensive or sometimes impossible to recover from fully.

So take a few minutes (or hours) to plan it. Just as the Project itself has objectives, so does the Project Kickoff. And there are a few key deliverables that you should expect to walk away from the Project Kickoff with that will help you with the overall project. These are listed in point form, but expanded in the next section. Acronyms will be expanded, so bear with.

- Project Team (roles assigned & basic responsibilities known and understood)
- Clear understanding of the Project Objectives
- Stakeholder Map
- CRAIDL
- High Level Project Plan
- RAM
- Skeleton Communication Plan
- Project reporting and recurring meeting schedule
- Sharing of any templates to be used on the project.

When you leave these will not all be in final, publishable form - but you will have a starting point for each, and in some cases quite fleshed-out lists, documents and spreadsheets.

Note: we will assume that you already have a Project Charter in place - the brief guiding document that has authorized your project to start. If you don't have one, you can include that as part of the Project Kickoff outputs as well.

10 Elements of a good Project Kickoff

1) Agenda, published in advance.

Yes, this is not really a deliverable - more of an input, but if you have a clear agenda the whole process will work more smoothly. You may also need to tweak the agenda as you go (multiple day event), so it is not just a static piece of paper.

The specific agenda you develop may include most or all of the items below, plus probably a technical overview, etc.

2) Project Team: Have all key people present.

This includes the Project Manager, the identified key (all team lead) project team members, Subject Matter Experts (SMEs) that will be involved in delivery or decision-making, key stakeholders - and the Project Sponsor. If you are missing key people at the beginning, bad things tend to happen.

- People "missed the message"

- People feel left out

- People do not feel they had input to the process, so may be resentful

- Team bonding gets delayed

- You start with an "us" vs "them" scenario - vs "we"

- People not initially present may not buy-in, or even actively obstruct the project later on

And remember - people may not know each other yet, so do introductions, and perhaps a short icebreaker. Get people talking to each other. Allow a bit of time for this before the meeting starts in earnest - and allow breaks where people can have some refreshments and continue to connect. Some of your team members may be "remote" after this, so spending some time getting to know each other helps ease any future communication issues when you are talking on the phone/email etc.

And on the Virtual note - if you do have anyone videoconferencing in, please pre-test the setup and check periodically during the meetings that they can see and be seen, hear and be heard. Phone-in is possible of course but video is probably better if you can manage it.

Enter the Monkey: An excellent facilitator we had on one project had a little "gimmick" that really worked - and grew a life of it's own during the project. He brought in a little stuffed toy monkey on the first morning and parked it on the table. Everyone looked at it, asked each other about it - nobody could figure it out - and then he told us what it was for. (It wasn't the icebreaker, at least, not intentionally).

The "Monkey" represents responsibility (as in "who has the monkey on their back"?) He used this device to help keep us focused as we did our planning - for any task, there can only be one "monkey" - one person (or team leader representing a group) responsible for delivering that item.

3) Break down the Key Project Objectives.

Use simple, clear words. You may have received a vision statement in management-ese about the objectives of the project from the organizational level, but it may be hard to translate that into something you can put your arms around. i.e. "Our goal is to have this project deliver a sustainable business support system to support operational outcomes and reduce costs." Say what? If nobody on the project understands what we are doing - and why we are doing it, they will not be fully engaged, and they will not buy into it (whatever "it" is).

Break the objectives down into simple, clear words. And really, the fewer the better. Not sure where to start breaking it down? Ask the Sponsor to explain what it is that they are really wanting to be achieved (this is a big reason they are there). Still not clear? Ask questions, have them provide examples, etc. Make it easy to grasp - so the team can buy into it. "i.e. Replace the servers and upgrade the software, which will reduce costs and reduce current user frustration." If you can put it on a bumper sticker, you are going in the right direction. Who knows? Your Communication Plan may include some publicity and catch-phrases that came out of the Project Kickoff.

Note that this is not the Project Plan - we are trying to set our GPS for the destination. We will figure out how to get there soon - but not just yet!

(Don't spend endless hours on this - set a time limit; the purpose is to ensure everyone understands the core project objectives. Shared vision generates emotion, emotion drives buy-in).

4) Identify the stakeholders.

Who are your project stakeholders? Think carefully now, and even a bit outside the box. Your stakeholders include the entire project team, the sponsors, the end users/customers/recipents of the result, and potentially many others that will touch on the project or its end result. The specific stakeholder map will vary from project to project - and may even include unexpected people outside of your organization or the customer's organization.

Identifying the stakeholders is a key step because it helps ground us and remind us "who we are doing this for", in addition to who makes decisions, who needs to be consulted, and of course who pays the bills.

Tip: You will want to use a spreadsheet for this - ideally a template.

You will also want to collect some basic information about those stakeholders - email, phone, address etc.

5) Build the CRAIDL. No, not Cradle. This is an acronym for:

Constraints

Risks

Assumptions

Issues

Decisions

Lexicon

These vehicles will become part of the ongoing life of the project, where key information is kept and maintained by the Project Manager/Project Coordinator and used on a regular basis by the team. (Note: If you are not going to use it, why collect it?)

Each of these items may have their own discussion session during the kickoff, or you may be completing these as you go during a brainstorming session. But the point is that more heads are better than one, and synergy develops when you work together. You are less likely to let important things fall through the cracks when you are collaborating and sharing.

Here are some brief descriptions of each item in the CRAIDL:

Constraints: It is a good idea to identify and write down any items that may limit the project, or limit future decisions, opportunities etc. Even if "everybody knows it" there is value in writing it down. Example constraints are budget, regulatory constraints, drop-dead key deadlines, etc.

Risks: Start setting up the risk log now. The group will be able to fairly quickly identify common and some unexpected risks (and opportunities - Positive Risk) that may impact the project. Risk management will be explored more fully in a later session.

Sidebar: What is a Risk? A key difference between Risks and Issues is that Risks have a probability. Issues are things that you have to deal with now - or you know you must address at a definite time. Risks are things that might occur, and will have an associated cost/impact (positive, or negative). A future realized Risk will be an Issue - if and when it happens.

Assumptions: Assumptions are just that - part of the "it's just how it works" from your culture, and there will also be assumptions about the delivery, execution and outcomes of the project that differ from stakeholder to stakeholder. Remember that these are not just your assumptions - these are team and known/anticipated stakeholder assumptions as well. But don't forget your own assumptions in favour of the team's - include yours as well, as you may have your own biases ("of course all of my projects are successful!")

Issues: As mentioned above - Issues are known items that you will have to address - they may be obstacles to navigate, problems to solve - or simply key things that will catch you up if you do not plan and take action to handle them.

Decisions: During your brainstormning, you will identify a number of items (few or many) that will require someone to make a decision - now, or at some point in the project. When a Decision item is added - it is important to identify who will need to make the decision (person or persons).

Lexicon: This one is optional for small teams and internal projects - but can be invaluable when your project involves Vendor and Customer. As you go through the Project Kickoff meeting(s), take note of jargon that people are using, and write it down, along with the meaning. The two groups may have very different "project language" and a key part of working together is to make sure you can communicate together. Sometimes there will be "new words" or acronyms, or there may be different understandings of the same terms. So make notes as you go - and review it at the end, and distribute it to the team. Add to it over time, as well.

Notes on brainstorming: Many ideas will come out that you may not be sure how to "label" right off. Don't worry about it - and don't stop moving - just record it on a Post-it, and park it. It will become clear as you work through the CRAIDL items where they belong - i.e. Aha! - that is an Issue, but this other needs to go to the Decision Log.

6) High Level Project Plan - Build it together. Use post-its!

It is time to start building up the high level elements of the project plan (the major moving parts and the major deliverables). Don't rush on and start up Microsoft Project just yet. This is still brainstorming time.

Note: You may be a highly experienced Project Manager, or relatively fresh - but please take this advice: If you already have a detailed Project Plan because "you know what needs to be done", don't throw it out on the table or on the screen. Tuck it away! You will have plenty of time to refine the details of the Project Plan once you finish the Kickoff. So hold onto "all of the details  that you know" - because, really - you don't. If you knew absolutely everything that needed to be done and how to do it, you wouldn't have a Project. You would have an assembly line.

You have assembled a team to help you deliver this project; it may be 3 people, 30 or 300. Every project is unique; it may be similar to others, but never the same. There are always wrinkles and twists - so hold back on being the "project expert" - and listen to the team as they work together. Your primary role (as a PM) in the Kickoff is as a Facilitator, or Coach. For now, everyone else is "the expert" - and you need their expertise plus your guidance and experience, working together, to deliver. You are certainly expected to know how to run the project, but at this stage - play the role of Coach/Facilitator, and draw out all of the important information you need for this project. Otherwise, they may not speak up at all.

Tip: It is important that, as the PM, you do have a grasp on all of the major elements required for the project. You can use those as starting points in the discussion. You may already have these prepared on Post-its, or have them written down and write them up as you go.

Ready? Set? Go! - Start with the major elements of the project, and start breaking them down into a semblance of a WBS, but with post-its. You may move them around a fair bit as you go. Take a photo and tidy it up in your favourite project planning tool after the meeting. (We will assume that you already know something about project planning, and how to setup a WBS structure. More on that in a separate session, but for now - "you are the expert" at this on your project.)

However, some guidelines - but first, a question.

Why go through this exercise of having all of the key people help flesh out the high level project plan, when you have most of it anyway? 
Answer: Because otherwise you will miss important things if you just try to do it on your own, and - a huge bonus - the TEAM built the plan. If you participate in building something, you have an investment, and you will buy in.

If you had just thrown up "the plan" on the screen, you would have people shutting down, not contributing, and not buying in. Then you have a long, long road of struggle ahead.

PM Tip: Guess who orders the Post-its? The PM (you). So most likely the plan will take shape mostly like you had envisioned it anyway - and you can help draw out any pieces you think might have been missed - but you will also be including all of the things that you would have missed yourself. A great starter of a plan - a team effort. Everyone will be tired at the end of the planning session - but they are much more likely to leave as a Team rather than Bob from Dept A, Sue from B, etc. They may even be smiling and buying you a drink. (Ok, maybe not, they may expect you to buy the first round, but at least they want you in the same pub!)

After that - once you have taken the photo of the postits, numbered/ordered and collected them, you can take them away and build up the details from there in your planning tool.

And of course - the project plan is not complete, you will have further sessions with smaller groups to refine the details. But you are off to a great start.

(Note: if you are running a smaller project, you will be trimming the above down quite a lot, maybe into an hour. And you may have a tight timeline, so you may already have the plan prepared. But still go in with the same "did I miss anything?" attitude - rather than "take it or leave it". So don't panic if you are on a smaller project - you can prepare a lot of the above yourself, and have the team help fill in any gaps, and then get rolling!)

7) RAM and RASCI

In step 4 we identified the Stakeholders, and in step 6 we developed the High Level Project plan. Now, we are going to look at what roles those stakeholders play, and include some clarifying notes in the context of the high level plan.

Introducing the RAM -  Responsibility Assignment Matrix

This may already be a well-used spreadsheet template from your toolbox, but it is a key tool to help identify who is doing what - and who is involved (in some way) with the various apects of the project. Now that you have the fledgeling Project Plan, and, having bought the first round and then studiously gone home to write up all thos post-it notes and WBS number them, it is time to put some teeth into it. Make some decisions, nominate the guilty and assign ownership to items.

The Responsibility Assignment Matrix is a way to map the Project Plan to people - and more than one person may have a role per item. Generally you will be mapping to the project plan (WBS# and title), but you may have some "external" items to track as well that do not (yet) fit into the project plan - i.e. the parking lot. You may wrap those into the plan later on.

You should end up with a spreasheet with the items (WBS#/title) as rows, and the key project members (team leads, SMEs, decision makers, key stakeholders) as columns.

And then what? You assign each row/column cell (as appropriate) a code. If they have no involvement in it, just leave it blank.

Assignment of Responsibility Codes: RASCI, which stands for

Responsible for Execution

Approver / Accountable

Support the Activity

Consult

Informed

Some guidelines:

a) Only ONE "Responsible" person or team per item (one job, one Monkey - see my article on Project Communications: Cutting through the Noise for more reasons for this). If you seem to need to have more than one "Responsible" person or team, then the item is too large and you need to break it down further. Think of it as the bottom level of the WBS - i.e. the Work Package. One package - one person or team. Or perhaps - you really mean that one team/person is the lead and another is a (S)upporter.

You still might still list the high-level items, such as the case where "John Smith" is the decision maker for anything in that branch. No point repeating it in every element unless it is truly needed for clarity.

b) Approver/Accountable person - this is a decision maker, the person who has the authority to make the decision and the accountability for the outcome. You can have more than one of these, but it is a good idea to mark the "key" person. One Monkey!

c) Supporter of the activity. You can have many people assigned here - so they have heads up that even if they do not need to deliver the item, they will be called on periodically for advice, help etc.

d) Consult the person on the item - this is for Subject Matter Experts (SMEs) that may not be decision makers or accountable for the overall item, but they do know their stuff, and like a farmer, is "out-standing in their field". You will end up asking these people lots of questions, so be careful not to burn them out.

e) Inform the person on the item (status/progress/issues) - some people just need to know what is going on, but do not need to take action, or "do" anything. These are the people you need to "CC" on anything related to that item.

8) Communication Plan

This is a good time to introduce the Communication Plan. You may only get started a little bit on developing it during the Kickoff, but it is important that everyone knows that there is one - and they may play a part in it. We won't go into the details of the communication plan here (that will be another session), but suffice it to say that you need to look at your Stakeholder list, internal and external, and discuss what types of communication will need to be sent to whom, by what methods, with what frequency and at which stages of the project. Not everyone needs to be communicated about everything all the time.

Tip: The RAM and RASCI chart will also factor into this. Part of your communication plan may be that any Team Member doing work on an item that has "A" or "I" people will always need to CC those persons on emails related to that item. As simple as that! ...And potentially as huge as a national multi-media presentation on live TV.

9) Project reporting and regular meetings established.

Before you close the meeting and send everyone back to their desks/office/other location, make sure that you have a few other items covered.

- Spend a little bit of time to go over any status reporting templates and documents the team will need to be using on a regular basis. Covering that now lets people ask questions and reduces confusion later on.
- Decide on the recurring meeting schedule. What meetings do you need to have as a team? How often? In person, by phone, online, or an alternating mix?
- Discuss the importance of each sub-team having its own regular meetings, to help catch things early etc.
- Share the contact list. Names, phone, email, etc. for everyone in the team. Make sure everyone knows how to get hold of each other.
- Share the initial RAM with everyone - make sure that everyone knows, at least at the high level, who is doing what - and who they need to go to for help, decisions and support. Who has the Monkey for that?
- Make sure enveryone knows how to get to the project documents/repository/etc.

Tip: Don't leave this session to last. People will be tired, ready to go "home" and no longer listening, because it is not as "engaging" as some of the other sessions. Do it the morning of the last day, or sometime in the schedule where people are still awake and not full of pasta.

10) Summary/Close

It will have been a busy few hours or days spent together. But don't forget to summarize the things you have done and built together in the Kickoff. It will remind them of how much has been accomplished - and re-affirm the joint vision and direction for the team.

And finally - review the Action Items from the Kickoff (with the Team), so that people know what they need to start addressing as soon as they depart/get back to their office.

Some additional Notes:

Key people/roles to include in the kickoff:

- Scribe. Have someone with quick ears/eyes and quicker fingers capture everything -all notes, all decisions, all key points from the discussion. Note that the Scribe is a dedicated function in this context - they are not expected to be involved in the conversation themselves, or they will stop listening/looking and will miss important elements. It goes without saying (well, let's just say it) that the Project Manager is never the Scribe in the Project Kickoff (unless it is the really short 1 hour version).
- Facilitator (usually the Project Manager, but possibly not, if you can get a professional facilitator, or someone very good at it. Do, however, make sure that the PM is putting all of the pieces of the High Level Plan post-its together, and not the Facilitator in this case)

Take Breaks!
- Schedule in regular breaks. You will be working hard, so give your body the rest it needs and have regular breaks. Have coffee/tea/water available, and snacks, lunch etc catered if that is an option. It is also a good opportunity for the team to begin to form and socialize. No alcohol until after hours though - and remember you need to be fresh to start again in the morning!

Keep them close
- Momentum is easy to lose. So if you go offsite for lunch, don't go far - and do it together. It is disruptive and stressful on the newly developing team to be waiting for someone to return who "just stepped back to the office for a minute".

Set the meeting ground rules
- Basic etiquette - cellphones, laptops, etc can be both tools and distractions (or escapes). Set up some ground rules at the outset - and they will form the "norm" for all project meetings that you have. So think carefully, choose wisely, and be firm about things that may detract from this and future meetings - even with the CEO.

Good luck with your project, and have a successful Project Kickoff!

Project Planning Series
Read the next article : Project Planning 1.1: Project Tracking - Plan it Now!

Gary Nelson, PMP
Gazza Consulting Services