The Objective Statement
First, I like to get a simple statement of the objective. It should be unqualified, overarching, and able to survive changing circumstances. It should also act as the arbiter in case of conflicts.
The farthest thing from a clear objective is a long list of features and things to do. I've seen this a lot in the federal government. A list of features is a design and a list of things to do is a plan. Neither is an objective.
Don't throw the list away. It'll be useful later.
Also common is the short list of objectives, usually about three statements that are somewhat entangled. In this case we can usually look at them a bit and the one thing they are trying to achieve will show itself. If the listed goals are independent, we may have more than one project on our hands.
Here are two objective statements:
(1) "To be compliant with Government ITSec requirements by Christmas."These are both simple statements that make the objective clear. They both define a broad measure of success.
(2) "To preserve Canada's documentary heritage for the benefit of present and future generations."
Sometimes it's also useful to have a short phrase that captures the spirit of the venture. In the second case above, we used
"Make it all accessible, to everyone, forever."The "sloganized" objective statement is handy when there are a lot of people involved who will be making decisions affecting success; we want to make it easy for them to focus on the goal.
It's never quite as simple as the objective statement would imply. The Scope provides constraints, prescriptions, guidelines, etc. that limit the ways we can achieve the objective. For example, in the first case above, one of the scope statements was
"This plan will not include any areas, staff or processes handling information classified above SECRET."This is not the place to start sneaking in functional specifications. The scope is only about the objective—the what, not the how. When we're working with stakeholders on this part of the plan, we'll keep a notebook handy for all of the input we'll get that belongs somewhere else.
The Target Environment
The Target Environment is a collection of "future truths" about the world when the plan has succeeded and the objective has been achieved. Once again, these are what, not how. For a project that will build something, this can include those design elements that are user-visible.
It's here that metrics are introduced—measurements that can be made and standards to be met that tell us when we've succeeded. Ideally, they'll be such that we can send a dozen people out to find out how close we are to finished, and they'll all come back with the same answer. It's not always possible, but the effort is worthwhile.
A few examples:
"The internship program produces between four and six fully qualified electronic technicians per year."The Target Environment specifies the factors that will be used to measure the plan's progress between the start of the project, when the statements are false, and the end of the project when they're true. Statements that are true both at the beginning and the end of the project have no discernable use. If there's a need to brag, justify the current state of affairs or establish a base line, add a "Current Environment" section and put it all there.
"All staff have taken security awareness training tailored to their handling of sensitive information."
"The system can scan and index over 2000 book pages per day."
Now that we have a crystal clear view of what we want to accomplish, we're ready to start thinking about how we'll do it.