The Standish Chaos report about why projects succeed and fail contains a real nugget. You might be surprised by this breakdown of opinions about why a project succeeds.

Half of the respondents chose one of these three reasons: User involvement, Executive management support, or Clear statement of requirements.

A quarter of the respondents chose from this set of good project management practices: Realistic expectations, Smaller project milestones, Ownership, or Clear vision & objectives.

Only a small portion – a tenth – of the respondents felt that ‘Proper Planning; was the reason projects succeed. About another tenth felt that ‘hard working, focused staff’ and ‘competent staff’  are the keys to success.

Isn’t that interesting?! What does this say about the ‘hero’ culture wherein we hope that one amazing project manager can rescue a project, or bring it to a successful conclusion. And our project management abilities to plan things out is not the key either. Instead, success derives from the whole network of people involved, and how clear the goals are to everyone.

The beginning of a project can put railroad tracks to success in place. It’s the time to be vigorous and get the direction right.

Seth Godin, in Linchpin, talks about frank beginnings this way. “Get scared early, not late. Be brave early, not late. Thrash now, not later. It’s too expensive to thrash later.” (p. 106) Thrashing is a necessary brainstorming and tweaking we all want to encourage, but, as he puts it, “Professional creators thrash early. The closer the project gets to completion, the fewer people see it and the fewer changes are permitted.”

If we can think about technical and cultural readiness as an interconnected web, we can get every part of that web ready for our project’s results to land into, and this, I think is what all change management efforts are trying to do. Instead of pinning change management tasks onto one specialist on the team, often timed for later in a project, how could that orientation be in place from the beginning; and how could users be involved from the beginning?

Maybe our clients’ key people, in key roles, that will help sustain the project’s results into the future, is part of it. Or maybe we have to be more aware of ‘nearby’ projects with related scope, so we can “thrash out” more precisely our project’s realm and expected results.

Certainly we have to strive for very robust completion definitions – the ‘how will we know we are done’ question needs a crystalized, soundbite-like answer that everyone can keep top of mind. The earlier in a project that we facilitate all the interested parties through to a clear completion definition, the better.

Here’s a project charter template we’ve developed as a starting point – everyone ends up customizing it in their own way, but we like the writing in blue in here, the ideas for content and comments about what each section is really for. We use another version of the content here as a checklist for any project we get involved in (no matter how far along the project is when we join). The table of contents makes for a good kick-off meeting agenda, as well.

Project Charter  – a Template in MSWord