What Should an Agile Project Charter Contain?

Posted by Shane Hastie on May 30, 2010

Sections

Process & Practices

Topics

Agile ,

Agile in the Enterprise ,

Adopting Agile ,

Project Management

Tags

Charter

 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?

Shane Hastie is an agile coach, trainer and consultant working for Software Education in Australia & New Zealand

1. Back to top

   get 'er done

   by craig w

   What happened to just getting things done? I think people get to wrapped up in the agile and/or "minimalist" approach to software development to the point that their productivity slows down.
   
   I think as a team you document as feels naturally necessary depending on your conditions. Are you working on a contract that requires a user manual? If so, write one. Do you plan on adding several people to the team over the course of a year? If so, perhaps starting a wiki with "how to get started developing" is a good thing to iterate on.
   
   Either way, I'd focus more on being productive and get things rolling naturally and not worry so much about having a well defined process, just be agile and roll with the punches ;)

   Reply

2. Back to top

   Re: get 'er done

   by Zdenek Farana

   Well said Craig!

   Reply

3. Back to top

   Re: get 'er done

   by Jonathan Harley

   Agreed. The rub comes when we introduce agile practices into enterprise situations, which is really where I think chartering is aimed in general - not that all projects couldn't benefit from some focus.
   
   There is a whole aspect of project governance that goes against the grain of the pure agilista, but never-the-less must be handled.
   
   There are many benefits to using agile techniques and practices, even in 'hostile environments'. Project charters and like practices are just more stakeholder requirements.

   Reply

4. Back to top

   Re: get 'er done

   by Mark Levison

   Craig - that works really well in small team (<10 people), with a well understood goal. Project charters are useful in large companies where team members might not know the users of their application, where they might not have customer contact. In those cases a half day to write a paragraph or two can keep the team focused. If you don't a project charter - great. If you don't sprint/iteration - that's also great, but most enterprises are big enough that their team members don't have the visibility they need. Most enterprises need a little process to keep them focused.
   
   As to adding more people to your project incrementally I just wrote about that: agilepainrelief.com/notesfromatooluser/2010/06/...
   
   Cheers
   Mark Levison
   Agile Pain Relief Consulting

   Reply

5. Back to top

   Re: get 'er done

   by Jason Little

   I agree with Mark. A simple project charter is a very effective way to get alignment early. For starters it brings everyone together (stakeholders and team members) and sets the right expectation plus it's a great reference during the project when inevitable changes happen.
   
   I don't see this as an 'agile' type of thing at all, this is just good common sense.

   Reply

6. Back to top

   Re: get 'er done

   by Michael Lant

   Hi Craig,
   I wrote one of the original articles to which Shane refers. I have found that a lightweight project charter is extremely helpful even for the smallest projects. Case in point: I am a member of technology networking group called Silicon Halton. We have about 150 members and we have several goals as an organization - one of which is to promote growth of the tech industry in our region. On Tuesday seven of us met to strategize how we are going to write our business plan. All seven of us are very experienced IT and project management people - on average at least 20 years of experience. At least two of the people are serious PMBOK practitioners. We've all written business plans, and we’ve all done a lot of project management. If any group should know what to do and how to do it, it should be this group – especially for a business plan that will likely be a mere 15-20 pages.
   The group notion at the beginning of the exercise was to get'er done. Instead, we stopped and wrote a project charter for the project of writing the business plan. This may sound silly, especially give that the resulting project charter was five bullet pints and it took us three hours to write. In part, it took three hours because no one was familiar with creating a project charter like this and needed to learn how to do it. More importantly, however, the process for the most part took so long because while trying to create the charter we discovered some very different ideas as to what we were trying to accomplish. Seven bright, committed, experienced people and seven ideas of what success looked like. At the end of the exercise, we were all in agreement and knew what we were supposed to be accomplishing. In spite of initial resistance and a large degree of impatience on the part of some of the team members to “get'er done”, all were thankful that we didn't just start working on it. We now all agree on what success looks like and how to measure it. The few hours we spent up front likely saved us days of in-flight debate and rework down the line.
   After decades of witnessing countless software projects struggle and sometimes fail because of simple misalignments that are easily resolved with a few hours of work up front, I don’t start any project now without a one page project charter. Since doing this, my success rate has improved dramatically.
   
   Michael
   michaellant.com

   Reply

7. Back to top

   Be careful that this does not accidentally restrict the project

   by Frank Carver

   While I certainly see the value of thinking about, and even documenting, these kinds of issues, I worry that on many kinds of projects the overall goals cannot (and should not) be fully articulated at the start.
   
   For me, one of the key benefits of an agile approach is that there is an explicit understanding that _anything_ might change during the project. Typically this understanding leads to planning only short stories, sprints or iterations, and leaving decisions about further work until the first bits have been done.
   
   An example from my experience. Despite the fact that some people made a fuss about an imagined final product, The _real_ goal of the first iteration was to produce something compelling enough to show unconvinced board members that the project was worth continued internal funding. To a large degree the _detail_ of what was produced was unimportant. Once approval was gained, the overall goals of the project changed again, this time to producing a technology demo for integration with a potential partner. And so on.
   
   Even by the end of the second iteration showing the early versions to the stakeholders had already changed the product vision a long way from the initial plans which had been talked about so much.
   
   At each stage, the outcome of the work for the iteration affected (often profoundly and largely unpredictably) the goals for the next piece of work. Attempting to set down any kind of charter with a longer expected lifetime than a single iteration would have been both a waste of time and a (potentially dangerous) distraction.
   
   For me, "embrace change" is king. Don't attempt to guess, or worse enforce, the future.

   Reply

8. Back to top

   Re: Be careful that this does not accidentally restrict the project

   by Mark Levison

   I think the trick is to appreciate that the charter isn't there to restrict the product instead its there to ensure that the team shares the vision. If the vision becomes dated or it needs to change then the charter needs to be amended. Think of it as a tool to help remind people what the original goal was.
   
   Cheers
   Mark Levison
   Agile Pain Relief Consulting

   Reply

9. Back to top

   French translation

   by Fabrice AIMETTI

   Hello Shane,
   
   Nice! I've translated into french your article :
   agilarium.wikispaces.com/Que+contient+la+D%C3%A...
   
   Regards, Fabrice

   Reply

• Older >