Let me set the context for this post about the project charter: By now, the team knows what it has to accomplish because they have a product vision. The next question is: How will the team manage their risks to achieve those outcomes? That's where I recommend a team define its project driver, up to two boundaries, and floating constraints.
When teams see their project risks, they can plan to minimize those risks. Since Things Always Happen, the team can then clarify how to make tradeoff decisions as risks occur. Those decisions help the team deliver as much as possible within their constraints.
Use a Project Driver Matrix to Define Tradeoffs in Advance
Because the project pyramid describes the risks, I always recommend the team rank those risks, often with the project sponsor. I start with this question:
Imagine this scenario. It's three weeks before the (desired) end of the project. The team has not finished the desired feature set. Worse, there are more defects than the team feels comfortable with. What decision will you, the sponsor, make?
- To finish all the features? (Feature set drives the project)
- To fix all the defects? (Low defects drives the project.)
- Or to ship the darn thing? (Release date drives the project.)
It's possible the sponsor will say, “No. Cut our losses now.” In that case, Cost to release does drive the project. But I have never heard any sponsor say that. Ever.
Instead, I hear sponsors say, “I need two out of three.”
Nope. They get one risk to drive the project. Then, the team can manage up to two constraints. Then, the team must have the flexibility to float the other risks. (I have written a lot about this. See Manage It! or this series: Summary for a Project’s Boundaries: Drivers, Constraints, & Floats for more details.)
Why can't sponsors get two, or even all three risks as #1? Because each risk requires a different approach to the project. At minimum, the team might choose a different lifecycle or agile approach. (See this Lifecycle Series about your context or Project Lifecycles: How to Reduce Risks, Release Successful Products, and Increase Agility for understanding how these risks can help a team decide how best to work.) Depending on how the sponsor ranks all the risks, the team might define their product minimums differently, to minimize all the risks.
Three Quick Examples for How Teams Might Choose Different Approaches to Manage Risks
Imagine Project A needs to release something in a month. Maybe they have a demo, tradeshow, or an impatient investor. That means release date is most important. The team needs to finish something and show it. I would recommend an agile approach where the team collaborates on everything. (Keep WIP to one item.) In addition, I would use a kanban approach because it's easier to see all the WIP. This team needs short feedback loops. (See Five Practical Tips for Any Team to Reduce Risks, Increase Agility, and Deliver Value as an example.)
If Project B needs to experiment with a variety of algorithms to select one for the remainder of the project, I might choose an agile approach with low WIP, high collaboration, and frequent demos. That might look like one-week iterations, if you prefer iterations. Or, this might be a spike. This team also needs short feedback loops.
Project C is a port from “old” infrastructure to “new” infrastructure. (This might be hardware, software, or both.) In that case, low defects matter much more than the feature set or the release date. (Feature set is right after low defects, but it's still after.) I might use an incremental or a combination iterative-incremental approach, especially if the team does not operate inside an agile culture. This team might be able to manage with longer feedback loops, since they can see the current product.
But no sponsor ever gets to have it “all.” Sponsors have to choose, to rank each of the risks for the project. That's why the driver, boundaries, and constraints are so useful. They help a team discuss this with all the right people. Then, they can choose an approach that makes sense.
The next post is about product risks and how those affect lifecycle choices.
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.