Some teams try to start projects directly with user stories, but many important things need to happen earlier to make those effective. Chartering (aka Liftoff) provides a better way to structure the start of a project. Beyond that, there are tools that can help teams understand the context and goals, to help frame the user stories. While chartering is generally useful, not all the tools I mention below apply to all teams or projects.
Chartering/Liftoff
Chartering and Liftoff are names for similar activities around project initiation. To begin, you need a project sponsor who recognizes an idea or need, and is willing to invest in addressing it. The goal of chartering is to bring together a project community to define and agree on their initial intent, approach, resources, plans. It may take hours to days to do this.
I’m not going to go through all the possible elements of a liftoff. For that, I recommend Liftoff: Start and Sustain Successful Agile Teams (2/e) by Diana Larsen and Ainsley Nies. But I will share some tools I’ve found useful for teams, and that are commonly used in liftoff sessions.
Project Community
A project community, most broadly, is anybody affecting or affected by the project. This is clearly a large group, and you’re well-served to think about who is in it. Some are inside your organization, others are outside. Some are favored (sponsor, team, customers), others are disfavored (hackers, competitors).
I’d like to focus on a few particular types of people:
Sponsor – The sponsor has (or was given and convinced to have) an idea, and has the means (money, resources and/or authority) to make it happen. Learn what the sponsor wants and needs. Some sponsors are very hands-off, happy to have a quarterly report if things are on track; others are very hands-on. Some feel a deep connection to their idea; others will delegate direct ownership of it to others.
Gatekeepers – Some organizations have people who can block or slow down a project. For example, at various times I’ve seen Legal, Audit, Architecture, Database, Configuration Management, and other groups block projects. It’s helpful to get these groups “in the tent” early. They’re usually trying to make something important happen or prevent something bad. It’s often the case that they’re open to alternate ways of addressing their underlying goals and needs.
Customer – The person who pays, typically expecting to receive the benefits of the system. In an internal project, the sponsor may be the customer, or another group may ultimately pay. In enterprise software, it’s common that some person or team buys (or buys access to) software that others will use.
User – For a software project, the person who interacts with the system. User is a very generic term – can you identify these roles more completely?
Disfavored User / Abuser – I first heard the terms “abuse cases”, “misuse cases”, and “abuser stories” years ago, but they’re more common concerns now. There are some users who we’re explicitly trying not to support. AI, doorbell cameras, location tracers, social media – all these have been used to harm people, and we need to explicitly consider that possibility.
Context Diagram
A context diagram is a tool that’s been around since at least the 1970s. It’s designed to show the necessary connections from a system to other systems and the outside world.
A context diagram a simple picture: your system goes in the middle, and you have arrows connecting it to other systems. There’s nothing shown inside your “bubble” – we’re not talking at all about how you process things. You only show one level deep – things your system communicates with – as you’re not talking at all about how they process things. You’re “just” showing the communication that takes place between your system and others’.
In this example, the search system is the focus. We don’t show how the outside systems or roles connect to each other. Since they’re outside our boundary, that’s not our concern.
A context diagram can help a project save time. In one case, I worked with a team that was merging and integrating data from multiple sources; the project’s goal was to merge from new data sources as well. They took the trouble to draw a context diagram and identify all the data flowing in. During their chartering session, they realized that some of the new data was redundant with the old data or between new data streams. Eliminating this duplication early cut a noticeable amount of work from the project.
In another case I know about, two teams were both preparing material to add to some (paper) bills going out. Only when both teams had deployed did they realize that each had assumed the other would integrate their result into the print stream, so neither had anything printing out. I don’t know how the projects were chartered, but the overall project (coordinating both) clearly missed something that a context diagram could have cleared up.
Business Model
As a coach, I often ask teams how their business works – how does it make money? What’s the business model? A surprising number have never considered it. I’ve even run into this confusion with Product Owners or Product Managers (though not often).
Here’s a model of a search enterprise. I used plausible but not real numbers. The various “input” numbers represent points of control: we’ll make more money if we increase the # searches, the click-through rate (CTR), the cost per click (CPC), etc., or if we reduce the costs of indexing, searching, or overhead.
The model could be in any form: a business model canvas, a spreadsheet, a few equations, even a coherent story. But for projects focused on economic benefits, a team must understand where they fit in and how they can know if they’re changing critical numbers.
Outcome vs Output
Beyond understanding the general shape of the business model, most projects have outcomes they’re trying to achieve. It’s not enough to say “Here’s what we did”; we want to say “We achieved this result by doing these things”.
Liftoff describes “mission tests” – the indicators we’ll use to decide whether we are succeeding in our mission. (Joshua Kerievsky and III called them “management tests“.) While we may have tests that are internal (“followed process xyz”, “team satisfaction”, “85% or better code quality score”), the real challenge is external tests: tests that assess our impact in the world.
There’s an old model for business impacts – IRACIS: Increase Revenue, Avoid Costs, Improve Service. It suggests most software projects are trying to accomplish things in one or more of these three areas. (The oldest reference I’ve found to this is in Structured Systems Analysis, by Gane and Sarson, 1977.) Many projects need to address these areas to sustain a business.
But projects and companies can have larger missions too. “Our goal is to take money from your pocket and put it in ours” may be true for many companies, but it doesn’t inspire customers or teams. Better missions are possible – Ikea: “create a better everyday life for the many people”, Gene Codes Forensics: “accurate identification of victims from mass disasters and in missing persons cases”, Patagonia: “save our home planet”.
Look beyond your team and your business. Can you target outcomes in terms of what your customers or users accomplish? To the world beyond?
Conclusion
While it might be attractive to jump in to a project and start writing user stories and code, most projects require that we align and agree on a mission, consider the context, and agree on a general approach. Liftoff (chartering) provides a way to structure that alignment, and there are many tools that help us understand the context and goals.
References
Business Model Canvas Template, from Strategyzer.com
“Charters and Chartering: Immunization Against Foreseeable Project Failure“, by III.
Liftoff: Start and Sustain Successful Agile Teams (2/e), by Diana Larsen and Ainsley Nies, 2016.
“Project Community“, Industrial XP.
“Right Game, Wrong Team“, by Joshua Kerievsky and III. Dr. Dobb’s Journal, 2003.
Structured Systems Analysis, by Gane and Sarson, 1977. (Link is to a 1979 edition)
“System Context Diagram“, Wikipedia. Retrieved 2020-10-05.