I started this series by saying a team can create a useful project charter in less time than you think. So what prevents teams from doing so?
Too often, the project is not ready. The team might be ready, but the project is not. In effect, the project starts with scarcity. (I used to think projects only had scarcity when it came to enough people on the team. See Don't Start a Project with Scarcity. I was wrong. It's entirely possible to start a project with insufficient product information.)
Every project exists to create some kind of product. For many products, a project will offer specific strategic capabilities over time. (That's the point of the image at the top of this post.)
That's why every project needs this information as a minimum checklist for the charter:
- The product vision. Who is this version of the product for? What will satisfy these customers?
- How will the team make the tradeoffs in terms of the project driver, boundaries, and constraints?
- What are the ideal feedback loop durations for this project? That helps the team decide which kind of lifecycle or agile approach to use.
- How will the product risks affect that lifecycle or agile approach? Does the team require more or less experimentation?
- What are the release criteria so the team—and everyone else—knows when the project is done?
If you use this checklist in advance, the team might be able to write the project charter in as little as 20 minutes. Why that long? To make sure the entire project team understands and agrees to the charter.
Unfortunately, I don't often see this minimal preparation for a project charter. That's when we need the right people in the room to manage everyone's time.
Clarify the Right People for Your Project Charter
Every project needs a product leader. I've been vague in defining who this product leader might be. Back in the 70s, 80s, and 90s, we had product managers who did not interact with project teams very often. They gave us a PRD, a Product Requirements Document. Wasn't that enough? (laugh with me, please.)
That's why I loved the idea of a product owner for agile teams.
Early in my agile career, I thought a Product Owner could define the product strategy. That includes the product vision and product risks. Then, that person could collaborate with the team to discuss lifecycles, experimentation, and release criteria.
But with all my experience with agility, I have learned this: Projects rarely had enough product managers. Teams rarely have enough product owners. In effect, we have no product owner at all. (I will do a series of posts on how to use a Product Value Team with insufficient product leadership, but that's not this post.)
What can you do? Look for a product leader and invite them to come to your project charter meeting. Give them the above checklist as the questions they will need to answer.
If there is no product leader, the team does not have to start the project, especially if they plan to use an agile approach. They can go to the portfolio team and say, “Hey, portfolio team, who is the person who is the product leader for this project? We need that person, and we need them now. We can start with the project charter as soon as you assign someone.”
If the portfolio team does not have a product leader, the project is not ready to start. It is that simple. If the team does have a product leader, they are ready to workshop the charter.
Workshop the Project Charter
Once you have all the right people in the room, the project team can start the project, in the form of workshopping the project charter.
Who does what?
Early in my project management career, I took the responsibility of writing down everything in the project charter myself. As the people decided, I wrote down the vision, the release criteria, and any other notes I thought the team needed.
However, the more agility the team wanted, the less I could write down myself. We needed to collaborate on everything, including the project charter. That's when I asked other people on the team to take notes for each of the pieces. (We used either index cards or yellow stickies. We posted them on the wall or the whiteboard as we proceeded.) At the end of the workshop, we could see all the pieces and make sure we agreed. Then, and only then, could we take all the pieces and write down the project charter.
While it is possible for the project manager to do all the writing, it's more effective when the team members take on some of the writing. When team members write down the agreements, they all jointly own the decisions. I recommend this, especially if you are a consultant/a fractional someone/or anyone who is not in the middle of the product development.
Product leaders make all the difference in the time the team spends workshopping the project charter.
Product Leadership Avoids Pointless Chartering Efforts
We've all been in pointless meetings. Those meetings often occur when we don't have the right people. That's why I'm a big fan of checklists for being Ready. (Yes, I now capitalized that so teams can use this on their various boards.
The portfolio team can use this approach when they assign a team to a project. The product function can use this to make sure they have a product leader assigned to each project. And the project team can use this idea to know they are ready to start.
Projects exist to create products. If we don't have a project sponsor or a product leader, why are we starting this project? Don't start. Because you won't be able to finish.
I will write a summary post.
The Project Charter Series
- How to Create a Useful Project Charter in Less Time Than You Think: Overview
- Project Charter Part 1: Write (And Test) a Product Vision for This Project
- Project Charter Part 2: Clarify the Project Driver, Boundaries, and Constraints for This Project
- Project Charter Part 3: How Product Risks Can Support or Change Your Feedback Loop Choices
- Project Charter Part 4: Define Release Criteria so You Know What Done Means & Avoid Scope Creep
- Project Charter Part 5: Workshop the Project Charter with the Right People to Manage Everyone's Time
See my books: Manage It! and Create Your Successful Agile Project for what I already wrote about project charters.
Project Lifecycles: How to Reduce Risks, Release Successful Products, and Increase Agility will help you see your feedback loop needs. And help you decide how to instill more agility in any approach if you want to.