What makes a “good enough” project charter? Agile projects have a strong emphasis on people over process and verbal rather than paper communication. In contrast, many formalised methodologies require heavyweight project chartering/initiation documents that have to be completed in order to gain funding and approval to proceed with work.
Given this potential conflict, what should an Agile project charter contain – how much documentation is “just enough” to answer the key questions and what format should this information be presented in?
A number of commentators have attempted to address these questions:
Michael Lant in a blog post titled “How to make your project not suck” states that many projects begin without a clear statement of what success looks like. He states “ No industry, and no organization large or small, be it government, not for profits, start-ups or large multi-nationals seems to be immune to this gaffe., To be clear, not all projects suffer from it, but it is remarkably common.”
The clear definition he’s talking about is a well crafted Project Charter –
Larger projects seem to be better at this – perhaps because they tend to have more project management resources. Smaller projects, however, tend to overlook project charters, and if they do create a charter, it is rarely (if ever) referenced. In particular, and for a variety of reasons, smaller projects often take shortcuts, and a project charter is often one of the first things to go.
He provides some advice on preparing a project charter:
Separate out all of the legal mumbo jumbo and other extraneous information that is commonly found in a charter. These things are certainly important to the success of the project, but not usually to the people executing, so put those things it into a separate document. Now create a project charter that is no more than one page long, whose purpose is solely to provide a clear and concise definition of what success looks like for that project.
The project charter is the most important document you will create in a project and it is essential that all stakeholders participate in its creation. It balances intentions, aligns stakeholders and provides and agreed upon definition of what success looks like. Although the charter is only one page long, it can be a challenging piece of work to craft an effective document. It should take at a minimum a couple hours to create, and even for a small project, it could take an entire day. Its content must be arrived at by consensus amongst the stakeholders. This is all time well spent, and can save potentially endless days or weeks of revisions to realign the project.
A useful project charter contains three key elements:
1. Vision: The vision defines the “Why” of the project. This is the higher purpose, or the reason for the project’s existence.
2. Mission: This is the “What” of the project and it states what will be done in the project to achieve its higher purpose.
3. Success Criteria: The success criteria are management tests that describe effects outside of the solution itself.
In his post he goes on to provide an example of a charter, and advice on using the charter to set the direction of the project and keep it on track.
Martin Proulx provides a worked example of an Agile project charter on the Analytical Mind blog.
Another tool that is often used as part of the project charter is the Success Sliders. Debbie Schatz wrote an article describing this tool in the Mortgage Banking magazine – it is available on the CCPace website
The Sliders are set to indicate the relative importance of various “dimensions” of the project, and provide guidance when potentially conflicting decisions come about. Rob Thomsett describes the tool in detail in his book Radical Project Management.
Ryan Martens discusses the value of the one page A3 report. The A3 (named for the size of the sheet of paper, approx the same as two foolscap pages side by side) is a technique used in Toyota to distil the essence of a problem down to what can fit onto a single sheet of paper. He quotes John Shook’s article in MIT Sloan Management Review
1. “Establish the business context and importance of a specific problem or issue
2. Describe the current conditions of the problem
3. Identify the desired outcome
4. Analyze the situation to establish causality
5. Propose countermeasures
6. Prescribe an action plan for getting it done
7. Map out the follow-up process”
Allan Kelly provides a template for an A3 report
While the A3 report described by Shook doesn’t contain all of the elements of a project charter, the technique provides a simple tool concentrate the whole team’s focus a clear statement of what the problem is to be solved and what the solution needs to deliver.
What constitutes a good Agile Project Charter in your environment, are you able to share examples with the InfoQ community?