How To Make Your Project Not Suck by Using an Agile Project Charter
An Agile Project Charter
The Problem
What the customer really needed (Click on image for full size view)
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.
Vision
Help busy office workers have more energy, more time and feel healthier by supplying quick, convenient, affordable, nutritionally balanced, good tasting lunches.
Mission
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.
Success Criteria
- 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.
Michael
I am an independent consultant who has been leading software teams, designing, building and delivering software for nearly three decades. It’s still as exciting and enjoyable for me today as at was when I wrote my very first Hello World program and saw it spring to life in front of me.
You May Also Like
11 Comments
Leave a Reply
This site uses Akismet to reduce spam. Learn how your comment data is processed.
Discovery Sessions: Start a project off right
March 10, 2023 at 10:52 am[…] Lant provided an example of what a project charter would look like when it’s stripped of unnecessary content and focuses on the information necessary to get your […]
Discovery Sessions: Start a project off right - KBP Media -
February 29, 2020 at 11:55 am[…] Lant provided an example of what a project charter would look like when it’s stripped of unnecessary content and focuses on the information necessary to get your […]
GridPulse : Don’t skip the charter, it may save your project | Bogdan Costea
December 22, 2010 at 5:58 pm[…] information: https://michaellant.com/2010/05/18/how-to-make-your-project-not-suck/ […]
Alexandre de Oliveir
May 31, 2010 at 9:59 pmIf you pay close attention to “Interprise” environments, you’ll see lots of bureaucratic methods that, let’s say, work, but are not effective (the hundred pages you cited is an example). And those methods became the market standards because it’s what the big men are doing.
However, underneath the global media and news, there are people who are applying what really works on projects. The thing is that these “small” players are showing results. The best example I can give is 37signals. What they’re saying is the most obvious anyone could say. Even so, everyone is mouth-opened.
As we were talking on Twitter, the best thing we can do is to do what is needed to accomplish ours objectives.
I see only radical agile developers who stand for “no documentation here”. What they don’t see is that documentation is needed and developers shouldn’t worry about it, because it’s not their business, it’s project manager’s.
Great post. Now I am willing to hear what you have to say on your next text (risk management, isn’t it 🙂
Michael
June 1, 2010 at 12:15 amEinstein said “Things should be made as simple as possible, but not simpler.” I believe that this is an implicit objective of Agile. I do believe, however, that in some cases, Agile practitioners do make things too simple. Software developers are notoriously bad documenters – they hate doing it, and Agile seemed to be an excuse for some to do no documentation at all. Working out a detailed design before writing a line of code can save endless hours of rework. It also saves time for the person who will eventually inherit your work. Documentation is indeed needed – if not for the developers, then for the stakeholders. There is usually a lot of money at stake, a company’s reputation, or even lives so ensuring that the correct things are done is essential, and project sponsors need to have evidence of this.
On the other hand, I’ve seen projects drown in documentation. I still use UML, and I still do a lot of architecture drawings, and I believe this type of documentation essential. Are SLAs, legal commitments and such, important – yes they are, but I don’t think they are important to everyone on the team. Good software design strives for an appropriate “separation of concerns” Good documentation should do the same. That’s why I make the project charter a single page document, and place the legal and other wording in other documents. It’s still there, but the documentation is now actually focused, readable and useful.
My next post will indeed be on risk management. I should have it ready mid-week.
Juho Vepsäläinen
May 30, 2010 at 7:28 amI agree that it’s essential to define it per project basis. I like the way you present project charter. It contains just the aspects you need to help to guide your project.
I think in case of “traditional” (non-commercial, distributed) open source projects the charter is usually more implicit. A project may have more general purpose (ie. photo manipulation) that it tries to strive towards. Of course there may be subprojects that try to attain some more specific goal that’s part of the general one (ie. photo color manipulation). It probably would not hurt if open source projects used more explicit charter such as the one you described, though.
Michael
May 30, 2010 at 11:58 amThank you for your thoughtful comments. I agree with your assertions. In particular:
1. Because this form of project charter is so lightweight, it can indeed, and likely should be used for sub-projects.
2. All projects should have a charter irrespective of size or whether or not they are open source. Without a consensus as to what success looks like, how do you know if you’ve succeeded? This is perhaps even more important with open source projects because unlike commercial projects, there is no profit imperative to define success. An open source project is undertaken for different reasons than commercial projects. Some of those reasons may not be clear or even shared amongst the various stakeholders. A simple project charter of this type gives contributors something to which they can say: “Yes, I can stand behind that, and I’m willing to contribute my time to its success.” If, however, you can’t agree on the charter, you have a problem, and shouldn’t even start the project.
Juho Vepsäläinen
May 30, 2010 at 3:38 pmI have a sort of love/hate relationship with success (I’m currently working on a thesis about it). I prefer to think about it recursively based on a simple taxonomy (individual, project, ecosystem, etc.). It seems to me that these different levels of success are interrelated somehow. Ie. successful individuals tend to hang around successful projects.
The meaning of success is highly subjective. There are plenty of predefined metrics for success already. Trying to apply them on projects may give different results than by actually interviewing the project members upon how they see it. Sometimes a project that looks like a failure, might not be it on personal level. By doing something wrong, you learned not to do it again that way. Perhaps you can use this experience in the next project to avoid failure.
I agree that a project charter would most likely be a useful tool for open source projects to use. I think that particularly small projects still in their embryonic phase could benefit from it.
Having clear goals and such helps to keep the project scope in check. It’s easy for a project to succumb to scope and feature creep if proper bounds have not been set early on.
I think that in case of open source, there’s some extent of antagonistic behaviour behind the movement. If you look at big, well known projects, you’ll see they tend to oppose something, usually a corporate entity. In this way their success may be seen linked to this somewhat directly. As use of open source solutions has become more prevalent, the situation has changed a bit, however.
This development has lead to increasing adoption of open source particularly within commercial sector. In fact the term “open source” was coined in 1998 just for this specific purpose; to make it commercially appealing.
I think we are currently witnessing some form of convergence where it becomes increasingly more common to use open source solutions and to build business based on them. Besides this it seems the very basic ideas have found themselves new homes in other domains beyond software. Services such as Wikipedia and YouTube provide good examples of this, particularly of crowdsourcing (essential part of bazaar style open source development).
Open source tends to thrive particularly in horizontal domains of software. Essentially open source projects tend to provide solutions for problems appealing to many. I prefer to think open source projects as a pyramid. As time goes on, more and more vertically aligned projects will come forth. These projects build upon the groundwork laid by earlier, mature projects.
How does this relate to project success then? To some extent software development is more like weaving these days. You just pick up some components and combine them to produce some value. This is where open source tends to shine. There are plenty of blocks to pick from. The real problem lies within assembling them.
This might be a bit simplistic view as assembling might actually be hard thing to do as it takes some amount of expertise. The value of open source lies not only in the source code but in the people as well.
The assembly idea does not probably relate to the idea of charter directly. It’s related more directly to the actual implementation. I do think that assembly view does give some nice tools to work with, however.
Using agile/lean methodologies (ok, perhaps BDUF works in some cases) and combining them with open source projects and expertise one ought to be able to navigate towards real success in more comfortable manner. It won’t be easy but at least there’s something to work with already in most cases. Of course there are many ways to the same result. I’m not saying that open source is a silver bullet. It may provide a different kind of way to work, though. 🙂
Michael
May 31, 2010 at 10:35 pmWhat you point out as a shortcoming of a success focus is actually the very reason for defining it in the charter.
Case in point: I once hired an energetic, idealistic young programmer. He was very much into the use of open source tools, but has used commercial software as well. The organization into which I hired him is a commercial software company that uses open source tools for most of its development efforts. I’ve worked with this person the past and we know each other pretty well. I had discussed the project with him prior to hiring him, so he had a pretty good idea what he was in for, and what technologies we would use. After he had settled in we began our in-depth project discussions. I was very surprised to discover that in spite of what I had always thought as a clear communication channel between the two of us, he had a very different idea of what the resulting application was supposed to be. Somehow he had ended up with the idea that our mission was to create an application using open source tools. Our mission, however, was to produce an RIA application. Never had there been mention of the result being based on open source tools. His supposition was that because we were using open source tools for everything else, then surely our mission for this project was to create the next great application using those same tools. Silverlight was the right technology for this effort.
The point here is that the mission and the tools had somehow been confused. The tools were not the mission. We needed to not try to put square peg open source tools into round hole requirements of the project for the sake of using open source tools. His idealism was outweighing the pragmatism that was needed to produce the correct solution, and the charter was the compass needed for the correct orientation of everyone.
Juho Vepsäläinen
June 1, 2010 at 1:44 amVery valid point. Open source is not the right solution always. It’s just a tool among others. I suppose it’s easy to turn a blind eye to alternatives if you take it too ideologically.
It might make sense to state constraints (or the lack of) related to technology in the charter itself to clear this sort of confusion, no?
Michael
June 2, 2010 at 10:56 amListing Constraints is essential – so is listing Assumptions. I place these things in separate documents coincidentally called Constraints and Assumptions. This could be two documents if the list becomes large and unwieldy, or a single document if there are few items to list. I want the project charter to ideally be posted in everyone’s workspace, and that’s why I want it to be a single page.
I recently met a very senior partner at one of the big four consulting firms. He has been extremely successful in the organization and is apparently one of, if not the youngest ever to make partner and has a staff of a few hundred people. His success has been based on delivery of value to his clients. He has an office that is free of clutter (not much on the walls) and he has pinned to the wall beside where his laptop sits a card with the the Vision, Mission and Values of the organization typed onto it. The card is on the same sight line as his monitor. He says he consults it regularly and uses it as the basis for any of the decision he makes. There are plenty of other things he could put on his wall like productivity charts, risk registers, revenue and profit numbers, etc… He does indeed track all of that elsewhere, but he keeps his target in plain view, and constantly adjusts his actions to stay in alignment. This is what I want to accomplish with the project charter – the same level of focus on producing what we’ve all decided to produce and for the same reasons.