I’ve found that getting a project started off on the right foot, while it doesn’t guarantee success, is certainly a way to help success become more likely.
I’ve been exploring ways to get projects started in an effective and not overbearing manner, and it turns out there’s a technique in existence for a while that is not used as frequently as it should be – project chartering.
In the resources section below I share a few different views on the activity of project chartering and the output from that activity.
A common theme in all work on project chartering is that the output is concise – usually just a page in length, and the outcome is that your team has a shared understanding about:
- The problem you’re trying to solve
- How you will measure whether you’ve solved that problem
- Any constraints you have on the solution to solve that problem.
Project chartering is an activity where the team develops and maintains a high-level summary of the project’s key success factors, synthetic enough that it can be displayed on one wall of the team room as a flipchart-sized sheet of paper. This description includes at least the major objectives of the project, scope boundaries, and reciprocal agreements between the project’s implementation team and external stakeholders.
An Agile Project Charter
Michael 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 project started. The key to this approach that he learned from Gil Broza is to “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.”
Intercom uses project briefs labeled with the quirky name “intermissions” to start all of the projects on their products. Their Product Managers are responsible for figuring out how to explain, on a page or less the problem their trying to solve, how to measure success, and the scope of the project.
“The goal of the Intermission doc is to have a shared understanding of what we are building and why.”
Intermissions are described in a couple of different posts on the Inside Intercom blog. One post describes how Intercom started using job stories and includes an Intermission Template. Another post describes how Intercom incorporates Intermissions into their overall process.
The Design Brief
Chris Matts and Richard Warner took a look at teams in a large financial services organization trying to use models such as the Vision Board to start projects and found that tool better suited for a startup than large enterprises.
They realized that the order in which you discover the aspects of the model drives different behavior in a startup versus an enterprise setting. Their hypothesis is: “Depending on your insight, you need first to establish the outcome, market and needs. Once you have these three, they form the design brief for the UX designer to design the feature.”
I’ve mentioned Marty Cagan’s opportunity assessment a few times before. It’s in this context of project chartering where it is most useful. Marty see opportunity assessment as an important responsibility for product managers. “The purpose of a good product opportunity assessment is either to a) prevent the company from wasting time and money on poor opportunities; or b) for those that are good opportunities, to understand what will be required to succeed.”