Charting a Course for Requirements

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:

1. Statement of Purpose: Explain why the organization wants to undertake this project and how this project supports organizational objectives. This is the business case.

2. 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, sponsors, stakeholders, domain experts, people who’ll use the system, and the proposed project team.

3. 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 needed and produced by it. Analysts use this to establish event lists, use cases, and context views.

4. Goals: 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.”

5. Expectations: Consider these perspectives when describing expectations about project completion: the customer, the project team, and management.

6. Constraints: 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.

7. Risks: 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.

8. Resources: 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.

9. Acceptance: 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 me as requirements facilitator for their project team. We spent the morning developing a statement of purpose, which everyone agreed to. Many of us proceeded to the next step of defining charter items. Jane assigned tasks to gather information, to develop lists, and to develop the charter entries. Over the next three weeks we met for about seventy-five minutes each morning. We discussed anything that seemed inconsistent with the project purpose and where we had problems. We reviewed a draft at the end of each week. By the end of the third week, we had a charter good enough to present to Jane’s boss. Four months later when a significant change was suggested, that charter was crucial for the negotiation.

When something is presented to a sponsor, expect these possible outcomes: a) acceptance of the charter, b) feedback that prompts a revision cycle, or c) a no-go decision. Cancellation at this point may be due to project risks not worth taking or goals that aren’t feasible at this time. Far from disappointment, this might be the best outcome.

Like any process, chartering can go awry. Here’s an example I experienced some years ago. Ted, the president, proposed a project that involved collaboration with a new business partner. He asked department heads for opinions and observations. I identified a risk that we would be dependent on this partner for specific expertise we didn’t have. Another person noted an inherent conflict with the suggested partner. After everyone contributed, Ted announced what we would do, totally ignoring our input. Soon after the project started, the partner dropped their commitment to the project.

Charters That Work

Here’s a quick list of the minimum elements you need for a charter that works:

• involve people who have a stake in the outcome and in shaping the problem statement and solution
• have an idea of how you want to structure meetings and tasks
• conduct sanity checkpoints for assessing the process and document integrity
• expect insight, not precision
• be concise, clear, and to the point, like a project resume

If you have no project charter, create one! Write what you believe is the charter, and pass it around. The feedback may reveal large gaps in expectations, or not. Either way you will have a better fix on where you are and where you can go. Then you’ll be ready to launch!