Hi everyone — I’m Jennifer Xia, a data scientist on Ripple’s Data Science team.
On the Data Science team, we start every project by writing a project charter that clearly identifies the purpose and plan for the proposed work.
Like Amazon, we find that addressing a problem using a narrative structure is a powerful and effective way to organize our thoughts around complex questions and share them across the organization.
In this blog post, I’ll talk about the benefits of using project charters and how we go about writing them.
Benefits of Using Project Charters
We use a Jira board to plan the work on our team. Stakeholders could drop tickets on our board when they had a problem they wanted us to research.
However, using this approach, we often found ourselves working on projects before our team and our stakeholders truly understood the depth of the problem. We also saw scenarios in which different stakeholders were asking the same questions, but for different purposes.
Sound familiar?
Writing project charters before starting work on a project has helped us address some of these challenges. In fact, since adopting project charters as a part of our process, we’ve seen a number of benefits. Using project charters has helped us:
- Ensure that we are spending our time doing impactful work.
Because the charter highlights the motivations for and benefits of the project, as well as the action items based on project outcomes, it makes the impact of the work clear. If we have a hard time clearly articulating any of these things, it’s usually a sign that the project is not yet well-defined or is not worth doing. - Create alignment between teams and get everyone on the same page.
A project charter is especially helpful in the face of open-ended questions, which many of the questions we are asked are! The project charter helps create consensus by serving as living documentation of what the project aims to achieve. Stakeholders can contribute to its contents and help guide it in the right direction. By providing an agreed upon view of the project, the project charter can also help protect against confirmation bias and scope creep. - Make it easy for team members to provide feedback on the suggested approach.
The project charter serves as a central place for the team to have conversations about the proposed method and for those decisions to be documented. This can be especially helpful on a distributed team like ours. It also enables time-constrained stakeholders to comment out-of-band. We write our project charter in Google Docs because it makes sharing and commenting easy, captures change history, and works well for technical and non-technical people.
Writing a Project Charter
Let’s walk through a hypothetical sample project charter and talk about some of the typical sections we include.
This hypothetical sample project charter addresses an actual question we worked on answering:
How do we measure and understand the liquidity dynamics of digital asset markets?
| Liquidity Monitoring Measure and understand the liquidity dynamics of digital asset markets. | Start with a title and a one-sentence summary of the project. |
| Purpose and Context This project aims to standardize measurements of liquidity efficiency, depth, and resiliency in digital assets markets. | State the motivation for the project. Provide any other background information that provides context. |
| Stakeholders Go-to-market team | State who will take action based on the outcome of the project. Though a project often has many stakeholders, we'll focus on just one for this example. |
| Sponsors VP of Marketing | List the sponsors of the project. This is typically the person or people who introduced the project. There may be some overlap between sponsors and stakeholders. I try to distinguish between the two by thinking of sponsors as the people who will stand up for the project if it is in danger of being blocked or deprioritized. |
| Assumptions The dynamics of historical data are indicative of future behavior, barring any fundamental changes in market structure. | State the underlying assumptions that need to be true for these results to be meaningful. If these assumptions are not true, they have a high likelihood of killing the project. For example, in this case, if we believed that historical data was not going to be a good representation of the future, conducting an analysis based on historical data would not provide meaningful results. |
| Use Cases As the go-to-market team, I want to be able to compare the liquidity of different corridors. | List the actions that each stakeholder will be empowered to take depending on the outcome of the project. I think this is one of the most important sections of the project charter, perhaps only second to the section on purpose and context. I find it helpful to write the use cases as user stories, e.g., “As X, I need Y so that I can Z.” |
| Completion Criteria (i) A document that outlines the definitions and calculations of liquidity metrics. (ii) A dashboard that allows the go-to-market team to evaluate corridor liquidity on demand. | Define the scope of the project. How do we know when we are done? This can include thoughts around what project deliverables could look like. For example, for us, this is often a document, dashboard, or presentation. |
When appropriate, we also include sections that describe the proposed methodology and references, such as links to literature or blog posts that provide more context or ideas on approaches--though we take care to not introduce too many technical details as this can sometimes distract the charter’s audience.
There are no hard-and-fast rules about including every section. Some sections don’t make sense for some projects, and some projects require details not covered by the sections above.
Also, it’s important to point out that we rarely write a perfect project charter on our first try. More often than not, the project charter goes through many iterations and request-for-comment periods during which we tune it until it meets the requirements of the entire team. Sometimes, we go through the exercise of writing a project charter only to realize that the ask requires more work than originally anticipated or is not well-formed. We can then prioritize them for a later date or abandon them entirely.
Challenges in Using Project Charters
As with many high-growth startups, our business and priorities are constantly evolving. This can throw a wrench into well-laid project plans. Some of the most common challenges include changes in priorities, stakeholders, and assumptions.
When we receive new information that impacts the project charter, we reevaluate it in its entirety. We strive for intellectual honesty, asking ourselves, our stakeholders, and the project sponsors if the project still makes sense given the new information. For example, in the past, we had written a charter on monitoring and understanding the drivers of a particular metric. As our business evolved and our understanding of customers’ needs grew, we realized that it was not the most important metric for us to be focused on, and drastically changed the focus and scope of that project as a result.
One of the benefits of writing project charters is that they help make the trade-offs and commitments clear so that we can respond to such changes effectively.
Project Charters for the Win
While writing project charters requires an initial investment, we’ve found that they help reduce wasted time and effort later.
The process of writing project charters enables our Data Science team and our stakeholders to shape and agree upon the use cases and goals of a project before any work has begun. With a project charter in hand, our team has the actionable information it needs to deliver impactful research that precisely serves the needs of our stakeholders.