Project Chartering

Description

I've had success with project chartering in my organization as well (internal IT software development for a large organization). It was a useful and effective communication and feedback mechanism for increasing awareness of the project (and its raison d'etre) sideways and upwards in the organization, and helps secure buy-in and commitment from management (if you don't have that up front, must as well find out early on so you can stop the train in its tracks).

Yes, at its heart, Chartering is about increasing communication within a Project Community. Such communication doesn't end at project start-up. So that's why we the practice is called "chartering." -- JoshuaKerievsky

We also had several forms of project "kickoff" (which the project charter helped feed into): we had one for the end-user community, one for the project team itself (development and the customers/reps and stakeholders they would regularly interact with) and another for the management/peer community (sideways and upwards) that we required cooperation and commitment from.

Is a "project kickoff" considered part of project chartering, or is it covered under another practice?

--BradAppleton

I've learned from David Schmaltz and Amy Schwab that building a vibrant Project Community is an essential activity. I would say that a "project kickoff" contributes towards building such a Project Community.

-- JoshuaKerievsky

The only thing that I can guess at is that the more 'annoying' ones were at companies where the first communication between 'management' and the team was the kickoff... (as opposed to the kickoff being a ceremony to mark something that everyone pretty much already knew about...)

I think there is a question here... probably something about "what can make a project kick-off not build community?" or "What are the elements of a good project kickoff?"

-- SteveBerczuk?

Context: Openly and explicitly acknowledging the context within which the project operates can contribute immensely to an effective kickoff. This includes the 'official' project success criteria as well as each person's success criteria; the project challenges (those aspects of 'this place' that are likely to get in the way of doing the project -- the features surrounding this project, not problems to be solved by it such as competing political agendas, clueless decision makers, inadequate resources); the nature of the project (is this dog-like or cat-like); and how the organization has dealt with similar projects in the past.

Getting these often 'undiscussable' things out on the table allows the community to talk and consider how they will work together in the face of these realities. Openly conversing about the strengths within the project community is equally useful -- it helps the community identify the tools they have available for dealing with these challenges.

Obviously, not everything is grist for a kickoff meeting but the openness of the kickoff will greatly color what is okay and not okay for the rest of the project and the rest of our working relationship.

Goals: I recommend a thorough (or as thorough as the time allows) conversation about what the goals of the project mean, how they were arrived at, what trade-offs have been considered and made, open questions/issues and how those will be handled. Again, as I mentioned above, this includes the initial aspiration / bright idea that instigated the project, the target or end state that will define the end of the project (and the thinking behind what was chosen), the legacies (what will be left after the project is completed), the constraints (the scope, critical success factors, and risks), and the regulators (the ways (processes, structure, methodology, etc.) that have been chosen for this project). I also like it when there can also be a conversation about what I call 'motivator goals' -- when each person can share what they are using this project for personally. If you know that I'm using this project to learn more about the selected technology and I know that you are using this project to get better acquainted with the folks in the customer organization, we can work together so we can both get our motivators met without ever encumbering the project.

Community: Finally, this is a look at who is 'us'. It includes everyone who can affect and can be affected by the project. I can almost guarantee that no kickoff meeting will include all of 'us'. However, if the key constituencies are represented, included in these conversations that set the stage for the rest of the project, they will more likely become a real contributing part of the community instead of perennially out of context 'thems'.

Finally, the end of the kickoff should (and I don't use this word very often) either be the initial planning session for the project or lead into the initial community planning session). The kickoff is most effective if it ends with clear and specific next steps for the project. Otherwise it leads to this 'so what?' sense.

The only thing that I can guess at is that the more 'annoying' ones were at companies where the first communication between 'management' and the team was the kickoff... (as opposed to the kickoff being a ceremony to mark something that everyone pretty much already knew about...)

I think there is a question here... probably something about "what can make a project kick-off not build community?" or "What are the elements of a good project kickoff?"

I've been involved in several kickoffs that some of the more cynical-leaning members of the community dreaded. Where there is real openness displayed, and plenty of opportunity for them to get their concerns voiced and heard (not necessarily answered), the dread (and even sometimes the cynicism) goes away. I have not explicitly employed Norm Kerth's Prime Directive but I can see how the explicit invocation of a similar directive would be useful.

So here's Amy's Prime Kickoff Directive: We will listen openly and generously to the information that everyone brings, trust that they are as interested as we are in a successful outcome, extend the benefit of the doubt, ask for clarification, and comment on any mysteries that arise for us.

What can make a project kick-off NOT build community? Not listening to what is said, judging some input as stupid or irrelevant, displaying distrust for certain project constituencies, intentionally excluding 'certain people', not being open to revisit or at least try to understand conflicting requirements, pretending like the difficulties in the project environment don't matter, doing a 'hand-holding' feel good session that doesn't include any real tough project conversation, creating an unsafe environment -- the list goes on and on and on.

I've described my ideal kickoff -- and much of the ground work is appropriate to have been done in greater detail prior to the first 'kickoff' meeting. Other kick off formats I've used over the many years include elements that are included in the above -- hopes/fears/expectations.

How are IXP kickoffs different?

AmySchwab?