Most of us wouldn't think of launching on a critical journey without some forethought about destination, route, and risk. Why would software projects launch with anything less? In this week's column, Becky Winant explains how and why to create a project charter.
Projects are like voyages; they both start with a launch. Ever wonder what happens before we get into the boat and it pushes off from shore? I might assume that someone has planned for this journey, but what if the plan isn't in the boat with us? Analysts need to explore requirements. We need a clear target for our investigations. What could point us in the right direction and guide our exploration? A project charter.
What Is a Project Charter?
At some point, interested parties convene to discuss a potential project. They usually bring numerous opinions and loads of data, but might hit an impasse when prioritizing what must be done. What should we talk about first? What is most important? Chartering can lend structure to identifying a focus, a true motivation, and support for this project.
Here is what a project charter document contains:
- Statement of Purpose
Explain why the organization wants to undertake this project and how this project supports organizational objectives. This is the business case.
- Project Contributors
List who is involved or should be, and why and how they might be involved. You might name individuals or organizations and include customers, ponsors, stakeholders, domain experts, people who'll use the system, and the proposed project team.
- Project Context and Scope
Identify what directly affects or is affected by this project and do the same for the proposed system. What in the system's environment drives its behavior? You might list markets, organizations, people, devices, and other systems. Describe system boundaries and information that will be eeded and produced by it. Analysts use this to establish event lists, use cases, and context views.
Goals state specific project targets that achieve the desired project purpose. The targets state something you can measure. For example, a threshold may be specified: "We'll be using new tax rules software by January 1 of next year." Proof through observation may satisfy a goal: "Support sales with a functioning product demo of the three key new features."
Consider these perspectives when describing expectations about project completion: the customer, the project team, and management.
Both the project and system have limitations imposed by customer request. A second set may be imposed by the organization. Constraints include reuse, needed technology, safety, security, standards, ergonomics, governing regulations, time, and cost. This information feeds into the architect's plans and work.
A risk is a potential problem that might keep us from successfully achieving a goal or fulfilling our customer's needs. Each risk carries a probability that may be designated simply as high, medium, or low. A risk might be failing to meet a constraint, or losing a resource or key contributor. It also might cite broader industry or economic events that could obstruct or stop project progress. The risk list requires contingency plans and affects management decisions about the project.
This category includes what we need to successfully undertake this project. An estimated budget, necessary software and hardware purchases, training and staffing, and partner participation are all useful entries.
The person supporting and funding this project signs the document. An agreement with an outside partner may have more than one signature.
Creating Project Charters
The project charter process surveys both opportunities and necessary realities. Just as we might weigh the pros and cons when purchasing a house, we need to evaluate this project's usefulness, desirability, and viability.
On one well-run project, the project manager, Jane, began with a meeting. She brought in the departments who would have a stake in the completed project: a technical architect, team leads, her boss (the sponsor), and