How To Make Your Project Not Suck by Using an Agile Project Charter
An Agile Project Charter
Any project can fail, and any project can fail for a seemingly endless array of reasons. In particular, large complex projects sometimes fail because they are well… large and complex. High complexity means more unknowns. More unknowns make estimation and management of budget, time, resource requirements, and a multitude of other factors extremely complex. The higher complexity of large projects implies that they have a higher likelihood of failure. Statistics seem to support this premise, but small projects also fail at an alarming rate. Certainly we can do better.
The Standish Group published their groundbreaking report in 1995. The Study looked at projects ranging on average from about $434,000 for smaller companies to about $2.3 million for larger companies. The report revealed that of an estimated 175,000 projects worth about $250 billion, a staggering 31.1% of projects were cancelled before they were completed, 52.7% of projects cost 189% of their original estimates, and a mere 16.2% were classified as successful. In large companies, it was even worse with only 9% of projects delivered on time and on budget. With continuing advances in development tools and technologies as well as the adoption of PMBOK, Agile and the use of frameworks and methodologies like Zachman and TOGAF the situation seemed to gradually improve. In their 2006 report they stated that 35% of projects were deemed successful. However, in the “CHAOS Summary 2009”, the results showed a marked decrease in project success rates, with only 32% of all projects succeeding, 44% were challenged and 24% failed. Yikes!
Know Where You Are Headed
“If you don’t’ have a clear definition of your destination when you set sail, any port will do.” – (unknown)
In spite of the fact that smaller projects are significantly less complex, their success rate is only marginally better than that of larger projects – how can that be?
Consultants are often brought into projects when something goes wrong, and over the years that I have been a consultant, I have witnessed a great many projects that were challenged. I have also noticed a few traits common to those projects that seem to be contributors to their challenged state. I have no empirical evidence to support my conclusions (your mileage may vary), but it often comes down to a few simple things. I will deal with some of those causes in subsequent posts, but the one I want to address here is something that seems so obvious that it is hard to imagine that it could be missed. It is simply a clear, and agreed upon definition of what success looks like. 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 definition of success I am referring to is a 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. Software product companies are particularly guilty of this and I think it is a potentially fatal mistake – often for the project, and sometimes for the company itself. Part of the challenge is that project charters have a reputation of being onerous, unwieldy, inflexible documents that no one uses. I’ve seen project charters that are over 50 pages long, and some even approaching 100 pages, and in such cases I have to agree. If your project charter is that large, it’s no wonder nobody references it, and consequently, it shouldn’t be too surprising if the project becomes misaligned with its objectives. When a project becomes misaligned with its objectives, it fails.
An Agile Project Charter
So what to do? If defining what success looks like, and ensuring that the entire team shares that vision is onerous, then make it easy. The solution is to make the charter small enough to be useful and meaningful for everyone on the team. I learned the following approach from Gil Broza of 3pVantage.com in a session he gave on project charters at Agile Tour Toronto (October 20, 2009). His technique made so much sense that I put it into effect immediately on couple of small projects to great effect. The solution is simple. 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 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 an 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.
An Agile Charter has three primary components:
- Vision: The vision defines the “Why” of the project. This is the higher purpose, or the reason for the project’s existence.
- Mission: This is the “What” of the project and it states what will be done in the project to achieve its higher purpose.
- Success Criteria: The success criteria are management tests that describe effects outside of the solution itself.
A Charter Example
While Agile and Scrum are most often associated with software development projects, an Agile Project Charter can in fact be used for virtually any project. The following example is the charter for the launch of a fictional midtown Manhattan healthy lunch takeout and delivery company under the highly creative name “Healthy Lunches to Go”. This example illustrates a simplified version of what that charter might look like.
Help busy office workers have more energy, more time and feel healthier by supplying quick, convenient, affordable, nutritionally balanced, good tasting lunches.
Create a profitable and highly regarded lunch takeout and delivery shop in midtown Manhattan that provides an economical, healthy, nutritionally balanced selection of soups, salads, sandwiches and other luncheon fare.
- Opening day of July 5th 2010
- Takeout sales of $5,000 and Delivery sales of $2,000 in the first week
- Takeout sales of $25,000 and Delivery sales of $10,000 in the first month
- Recognition in the fall lunchtime restaurant roundup by midtown news as one of the top five nutritious lunch takeout and delivery providers.
- All deliveries made in under 30 minutes of receiving the order
- All takeout customers served in under seven minutes
Although this is a simplified charter, there is no ambiguity as to why the project is being undertaken (Vision), what will be done to realize the vision (Mission), or how management will determine its success or failure (Success Criteria).
Using the Charter
Development of a project charter requires leadership to build consensus amongst parties that may have potentially competing needs and objectives. Failure to reach consensus guarantees that your project will not succeed – how can it if there is no agreement on what is to be done, its definition of success, or even why it is being undertaken in the first place.
A charter should not be filed away, never again to be seen. For it to be effective in helping your project succeed, it must be out in the open, accessible and regularly referenced by all members of the team. Doing so ensures ongoing, consistent alignment of project efforts to the objectives of project. Like all things in the universe, projects adhere to the law of entropy and tend towards chaos. Just as leadership is required in creating the charter, keeping a project aligned to the charter requires leadership. Events in the world outside of a project conspire to change the business environment within which the project and its final result must exist. Occurrences such as budget cuts, changing customer needs and market dynamics all exert forces on the project objectives and requirements. You may find mid-project that what you must create, and why you are creating it may have changed. If that happens, gather the stakeholders together again and rewrite the charter. Failing to do so means the project and charter are misaligned with the business objectives of the organization and thus by definition, the project will not succeed.
Having a good project charter is only one of many things that can affect your project and does not guarantee its success. Having a well written charter and being constantly vigilant of a project’s alignment to its charter does, however, improve the odds that your project will succeed and thus, not suck.
I’m looking forward to your feedback. Please leave your comments below.
Tags: Agile, Agile Development, development tools, Estimation, frameworks, Methodologies, Mission, Project Charter, Project Failure, Project Management, Project Success, resource requirements, Scrum, Standish Group, Success Criteria, success rates, Vision, zachman