Mastodon
King John seated at a table, signing the Magna Carta document, as nobles and clergy look on.

King John of England approving a project charter (the Magna Carta, "great charter"). Source: A Chronicle of England, B.C. 55-A.D. 1485, James E. Doyle, 1864.

Slow Down, We’re in a Hurry

Program Management Mar 26, 2024

TL;DR

  • Taking time out upfront to plan work usually results in finishing sooner, with better results, than just diving in. Slow down to go fast!
  • Project charters are the execution equivalent of what Product Requirements Documents (PRDs) are for product development, and design docs are for engineering.
  • The value of project charters comes from writing things down, in a structured way, and sharing what you’ve written with others to get feedback.
  • Charters clarify thinking, build consensus, accelerate decision-making, fight scope-creep, and after the project is finished, tell the story of what you and your team did.
  • It’s important to keep charters short, or people won’t read them, and they lose their value.

Hot Take

People rush to get new work efforts moving—the sooner you start, the sooner you’ll finish, and the sooner you’ll get the benefits of the work… right? Wrong: there’s a wealth of research, across many industries, showing that time spent thinking, writing, and discussing work, in advance, leads to faster delivery at lower cost. As people have said since at least Medieval times, “measure twice, cut once”; and as the title of this piece suggests, the fastest path forward is to slow down at the beginning. Program charters are a superb tool for doing this.

What’s a Project Charter?

💡
Project charters are the execution equivalent of what Product Requirements Documents (PRDs) are for product development, and design docs are for engineering.

All three are planning practices that clarify thinking, build consensus, keep the team aligned, and communicate. All three make sure that decisions that are hard to change later are thoroughly thought through early on, when big changes are cheap and easy. All three help get your stakeholders on board, and keep them there. Where they differ is on their subject matter and audience:

  • PRDs are about what defining a product
  • Design docs are about how to build something
  • Charters are about the scope of work and how that work will be executed

Charters go by more than one name; project charter and program charter are probably the most common, but you’ll also see them called business plans, statements of work, terms of reference, and more.

💡
There are many variations of project charters, but the their name and format aren’t where the magic is—the magic comes from writing things down, in a structured way, and sharing what you’ve written with others to get feedback.

Let’s go deeper in what charters are and how they’re used by walking through their lifecycle. Not all charters go through all these steps, but many do.

Step 1: Clarify Your Thinking by Writing it Down

Ideas start out as vague, hand-wavy things; writing them down is an important step in solidifying them, making them actionable, and making it clear where there are holes in your thinking that need to be filled in. Charters are "thinking tools" to help you do this by providing structure and discipline.

George Heilmeier demonstrating an early prototype of a liquid crystal display.
George Heilmeier demonstrating one of his other inventions, the Liquid Crystal Display (LCD)

George Heilmeier was Director of DARPA, the Defense Advanced Research Projects Agency, in the 1970s. You might know DARPA as the US agency that was integral to driving the research behind little things like the internet, GPS, weather satellites, and much more. In his role as head of DARPA, Heilmeier was deluged with proposals for research projects asking for funding, many of which were written in ways that made it hard to tell whether they were worthwhile... or even what it was they were proposing to do! To cut through this and improve the speed and quality of decision making, he invented what became known as the Heilmeier Catechism—every project proposal needed to clearly and concisely answer a specific list of questions before they would be considered. Here they are, verbatim, from the man himself:

  • What are you trying to do? Articulate your objectives using absolutely no jargon.
  • How is it done today, and what are the limits of current practice?
  • What is new in your approach and why do you think it will be successful?
  • Who cares? If you are successful, what difference will it make?
  • What are the risks?
  • How much will it cost?
  • How long will it take?
  • What are the mid-term and final “exams” to check for success?

What Heilmeier was doing was instituting project charter discipline, and to this day, his standard questions are an excellent template for a charter. Instead of just writing your thoughts down free-form, writing down your answers to Heilmeier’s questions will do wonders to firm up your plans for your project.

In my own experience there are a few others things that are useful to include in charters that weren’t on Heilmeier’s list (e.g. “non-goals”—things someone might mistakenly think are in your scope that you don’t plan to work on), and there are some modern buzzwords that people like to include to make their boss happy (e.g. “business impact”, which I think is the same as Heilmeier’s “who cares?”), but otherwise the Heilmeier Catechism is an ideal guide to writing a charter.

💡
Premium supporters of this newsletter can download a program charter template I have had a lot of success with that's based on the Heilmeier Catechism; feel free to use it or adapt it to your own use as you see fit (or don’t, I'm a callout, not a cop!). Premium supporters can also view the charter for the Order From Chaos, Today! business, as an example of a real, complete, fully worked-out charter.

Step 2: Feedback and Building Consensus

At this point you’ve written a charter—you’ve answered Heilmeier’s questions and any others that are relevant to your situation—and you have a nice document. The next step is to share that document with your team and other stakeholders to get their feedback on it.

If your charter is doing its job right, this could be hard: the primary benefits of a charter is to catch oversights and misalignments, to refine fuzzy thinking, and to make fundamental changes of direction before it’s too late… and those can all be difficult conversations to have: it’s easy for folks to give a quick thumbs up when you share your great idea over coffee, but when you write it down in detail for them you may find they start having concerns, and even strong disagreements with, what you’re proposing, and they’ll ask for changes.

During charter review, every time someone asks a question or asks for a change, that’s an opportunity to build and strengthen the alignment and consensus between members of your team with each other, and with your stakeholders. Sometimes the changes are easy, but often they require deeper explanations, research, negotiation, and compromise.

This consensus-building ability of charters makes them useful to create even if a project is already well underway. More than once I’ve taken on projects that were in trouble at their midpoint, and I started bringing “order out of chaos” by writing a charter and sharing it with stakeholders: “Here’s what I think we’re doing; do you agree?” You’d be surprised (maybe not?) the number of times projects go off track because there was never a “meeting of the minds” on scope, roles, or deliverables. Even if you’re halfway through a project, writing a charter can surface those misalignments, setting the stage for resolving them.

Step 3: Prioritization and Approval

A project charters can be thought of as the “metadata” of a project, a sort of glorified “cover sheet”. It contains a concise summary of what your project is all about that will quickly get anyone up to speed on the basics.

As such, charters are a natural input into your organization’s prioritization and approval process. When there are many project candidates but only enough staff, time, or funding for one, decision-making will happen faster, and produce better results, if the decision makers are using charters for those projects as their key references: they answer the same questions, using the same format, and the team and stakeholders have already reviewed and agreed that they accurately represent each projects’ work to be done and benefits.

In Radical Prioritization I wrote about narrowing your team’s focus to a small number of top priority work efforts; charters fit right into that process.

💡
A charter is the metadata for a prioritizable unit of work.

I was once managing a team of Technical Program Managers (TPMs) supporting a large engineering organization that had too much work for the number of engineers they had. My team worked with tech leads around the org to create charters for all their projects consuming more than 1 engineer, then listed them all in a spreadsheet. We shared the spreadsheet and folder of charters with the tech leads and their management and did a complete review, dropping a number of projects (some of which the management hadn’t even known about!), and moved staffing to other projects with higher priorities. The key to doing this quickly and objectively was the charters: they allowed people outside the immediate teams to easily understand and compare projects on an apples-to-apples basis.

A final note on charter approvals: in some companies (including ones I've worked in, though not in the "tech" industry) the project charter process is very formal—so formal that a charter is the project manager's equivalent to 007's "license to kill": they consider an approved charter to be a project manager's formal authority to hire, spend money, and more. In those environments you don't need to use the charter to build consensus—you only need the "consensus" of the people who will ultimately sign off on it. My advice: even if you work in such a company, don't treat your charter (or team) that way—use the charter to build consensus, and only go for sign-off and project authorization when your team has bought into what you're doing.

Step 4: Stay on Target

During execution, charters are a key tool for fighting “scope creep”, so it’s important they not be “living documents” that change frequently—once they’re approved they should be locked down so they can serve as a consistent guide to the team.

That doesn’t mean they’ll never need to be updated—the environment is always changing, and there are always “surprises”—that’s physics—but when changes are needed it’s important everyone understands and buys into the changes and understands the reasons for them; that means approval should go through the same sort of review the charter went through originally, and ideally, the same people who approved it before should be asked to re-approve the new version.

Stability is important for team health, and lack of stability can jeopardize the goals the team is trying to achieve. By having your charter under some kind of light-weight “change control” you can make it easier for team members to plan and execute their work, and for the whole team to achieve their goals.

Step 5: Communicate What You Did

Your charter should be the first thing you send anyone who wants to understand what your team is working on, but charters also come in handy even after a project is over as a concise record of what you did and why it mattered.

It’s common for people higher up in your organization, who are making decisions about budgets, headcount, and salary not to know much about the details of your domain. You could hope a manager who knows your and your team’s work well will be able to effectively explain it to those higher-ups… but how much better for everyone if there’s a short document they could read in a few minutes that gave them a concise view of the team’s work and business impact, signed off and vouched for by senior stakeholders?

At a personal level, charters can be a great part of your “leadership narrative”, to help “sell” your work for a performance evaluation, or to demonstrate your readiness for promotion:

  • Here’s what the situation was before I arrived.
  • Here’s what we planned to do about it, and the success criteria we set for ourselves (insert your charter here).
  • Here are the results we achieved, which met the success criteria we set.

I've been in more than one promotion meeting when the fact that documentation like this existed impressed reviewers and moved the promotion across the finish line!

Common Mistakes

No one is going to read a 50-page charter (even worse, most people will say they read it... but then won't, and will make decisions based on what they imagine it contains). If you want to have any chance that people will actually read it, it has to be short and concise.

One way to keep charters concise is to avoid putting any “tactical” information in them. The charter should represent the long-term “execution envelope” for the project, not its fine details. You’re going for clarity, understanding, and agreement on strategy. You don’t want to get sidetracked by disagreements about details that would be easy to change later.

💡
I love this advice on the value of conciseness: "Minimize the surface area of your argument."

Another common mistake is to have too many charters. They should be short, but each one still takes time to write, read, comment on, and bring to consensus. An engineering director I used to work with had a rule of thumb I liked for determining when a charter was useful: he asked for charters for any work that was going to need more than 4 person-weeks of effort. This threshold is a tradeoff, and might be different for your team: if you make it too low, charters become bureaucratic; if you make it too high, too much of your team’s energy goes into work that doesn’t align, and/or that aren’t the best investments.

How You Can Bring Order From Chaos, Today

I believe they are an important and powerful tool for clarifying your thinking, building consensus across your team, for keeping your team aligned, and for communicating what your team did and the value of it's contribution.

Of course you can try writing a charter for your next big project when it comes around, but here are some things you can do, starting now, to apply and take advantage of these ideas:

  • If you’re already working on a large project that doesn’t have a charter, start one now. It doesn’t need to be formal—just start writing down what you think the answers to George Heilmeier’s questions are, or start filling out the charter template (link for premium supporters only).
  • Charters aren’t just for teams—try writing a charter for a personal project you’re thinking about that’s larger than the “four person-week” threshold I mentioned. I find charters are useful to me, personally, even if I’m the only person working on a project, and even if I never share it with anyone else. I find the discipline of answering the Heilmeier and other questions in the charter forces me to think through my plans in more detail than I would have, and leads to better results. The charter for the OFCT newsletter (link for premium supporters only) is an example of a personal project charter; I found writing it invaluable for focusing my thinking and launching this newsletter.

What Do You Think?

I'd love to hear about your experiences with charters! If you're a premium supporter of this newsletter (hint, hint!) you can add comments below.

Want to Learn More?

Tags

Forrest Thiessen

I'm a geek who's worked at Google building data centers, networks, developer tools, and more for 17 years. I'm interested in science, technology, space, history, scifi, law, urbanism, and economics.