Project Charter Part 6: The Product Vision Drives the Project Charter, Summary

Manage product capabilities over timeAs far as I can tell, all organizations have the appetite for more work than they have people or time to do that work. It does not matter if the organization is one person or thousands. We all want to accomplish more than we have people.

That's why we need a product vision to drive the project charter effort. In effect, we can use test-driven “management” or “leadership” to test the product strategy.

Test Zero: Do We Have a Product Leader?

Too many organizations do not have effective product leadership for all products. There is no product sponsor, no primary “stakeholder” who can make decisions.

In that case, do not start the project. You won't be able to answer all the other tests. Instead, this is feedback to the project portfolio team. While you might have a project team, that team is incomplete if you do not have a product leader. Do not start this project. Use the ideas in the delays in management decision time or Cost of Delay to explain to the portfolio team why you have an incomplete project team. Ask them to assign a product leader to your project.

Test One: Do We Know the Value This Project Must Deliver?

Projects exist to deliver some container of product value. What is that value? That is the product vision.

  • New or improved features offer value directly to the customers/users.
  • Alternatively, sometimes the value is for the company, such as to pay down some form of cruft (unfinished work) or technical debt. (When we fix existing problems, we expect to be able to finish the next project faster.)
  • With any luck, there is value for both the customers and the company.

Every container of product value reflects the current product strategy. When we know that product strategy, we can then clarify the project risks.

Test Two: How Will We Manage the Project Risks?

The project risks, in the form of the driver, boundaries, and constraints, help the team decide how to make the daily decisions and tradeoffs. They also offer the first insight into how short the feedback loops need to be.

Test Three: How Will We Manage Our Need for Innovation?

The more innovation the product requires, the shorter the feedback loops need to be. The team can decide how to shorten those feedback loops:

  • Collaborate as a team, with pairing, swarming, and mobbing.
  • Maintain a lower overall WIP (Work in Progress).
  • Sequence work so it makes more “sense” from a technical perspective. (Sometimes, product leaders want stories in a specific order. However, that order makes more work for the team. The team and the product leader can collaborate on that order to shorten feedback loops and manage the innovation better.)

Test Four: How Will We Know When We Are Done?

Release criteria matter, so we do not add more features that we do not need in this project container. Sometimes, we realize as we proceed that the release criteria do not offer enough value to the people in Test One. (Rarely, they offer too much value!) That's when the team and the product leader can collaborate to change the definition of “how little” for this project.

Project charters do not need to take hours. With a product leader who understands the product strategy, the entire team can workshop the project charter in under an hour. But without that product leader? The charter can take days or weeks.

Do not start a project with scarcity. That is a no-win situation. Instead, use these tests to create a useful project charter in much less time than you think.

The Project Charter Series

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.

Leave a Reply

Scroll to Top