The theory states that the scope of a project defines the boundary of the project and the responsibility of the project manager. However, every business project manager has struggled with "how" to state the scope of his or her project. The concept is fine, but most scope statements look like high-level objectives.
The scope of an information system can be defined graphically using contemporary technical specification techniques such as data flow diagrams and data models. The scope of a building is defined by the physical boundaries such as walls, roads , and so on.
The real issue here is simply that the concept of project scope was borrowed from the construction industry (remember Chapter 2, "Project Management Evolution") where a physical scope makes sense. For decades, business project managers have struggled to apply the concept to abstract business projects (see Figure 8.2). Defining the scope and objectives of a complex policy project or some new software to power the Internet is a completely different problem.
Figure 8.2. Scope? What scope?
All business and information systems impact the organization and its people in some manner. Often, the successful implementation of a new information system or enhancement will require related job redesign, physical office alteration, new procedures, and new managerial control patterns. In addition, large projects may involve legal issues, financial management, and extensive administrative support such as travel and accommodations. These projects would require a number of noninformation-system activities (often undertaken by business area experts). It is essential that the project scope and objectives reflect the business system objectives as well as the information system objectives.
This leaves you and other project managers with a particularly difficult problem: How can you graphically represent the scope of a project, not a system? This is a serious issue as typical statements of scope look something like this:
First, it looks suspiciously like an objective. Second, it is very loose in that it is imprecise and fuzzy. For example, does developing the system involve altering any business processes? Finally, it contains a date (July 1) and quality expectations (user-friendly), which, as we describe later, aren't either scope or objectives!
What you need is the ability to draw a circle in the sand that clearly defines the boundaries of your project with the objectives you have to achieve inside that circle. As shown in Figure 8.3, one powerful technique is to use the Japanese pottery trick of using the reverse of the circle to make the circle more obvious.
Figure 8.3. The Zen of scope and objectives
Figure 8.4. Modified Kepner “Tregoe scope/objectives tool
Of course, as discussed later, any unresolved issues need to be raised with the project sponsor for clarification as a matter of urgency.
If scope is the boundary of the project manager's responsibility, then the project objectives are what the project manager is accountable for delivering. In the Kepner “Tregoe model, the Is column should contain the objectives of the project and the combination of the Is and the Is not provides a clear definition of the scope.
As we cover later, you'll also notice that the Is not column also contains objectives that become the related objectives that stakeholders and project managers of related projects will be responsible for achieving.
In effect, scope and objectives are the same thing ”it's just that some objectives are "in scope" and others are "outside scope." However, both sets of objectives must be met for the project to be successful. This important fact is covered in more detail later in this chapter.
Conflict Is Inevitable
Using the Kepner “Tregoe technique for defining your project's scope and objectives generally leads to some debate among your stakeholders about which objectives are in and which are out.
In addition, the more stakeholders you have, the higher the degree of initial confusion about what your project is going to achieve.
The trick here is to look for a common set of objectives that all your stakeholders can agree are in scope and to see if you can reach consensus on whether each of the remaining objectives should be in or out.
Any remaining conflict should be raised with your sponsor. This is the first example of the Captain Kirk model of project sponsors. As we discuss in later chapters, the sponsor is the person who "owns" the project  and, as a result, must have the unilateral right to make the final decision about the scope and objectives of his or her project.
Levels of Objectives
As the objectives for your project evolve , they come in all shapes and sizes. Initially, in your scope and objectives statement, you'll get a grab bag of objectives and other things such as constraints and quality expectations. Don't panic. We'll sort them out step by step.
There will be at least four levels of objectives in any project:
All project business cases must explicitly show this hierarchy of objectives to ensure that the project is aligned with the strategic objectives of the organization.
Refining Your Objectives
Objectives should also be specific and measurable. The following process can help you in developing clear and measurable objectives.
For example, the initial objective may be stated as, "To improve management information."
By asking the following questions, the project manager and his or her team will be able to parse the objective to produce a more detailed and specific objective.
As a result of these questions, the initial objective can be refined as follows :
As discussed later in Chapter 9, "Analyze Added Value," any well-defined objective has an output that has benefits to the organization. This concept also helps you in refining your objectives.
Let's Not Get Physical
A common mistake in many projects is the confusing of project objectives with system objectives. Simply, well-stated project objectives state what has to happen and system objectives state how the system (business and system) will implement the objectives. 
For example, "To use the Aardvarker database Release 1.1" is not a project objective, but rather a system objective. System objectives generally are technology or process dependent and project objectives are independent of technology. System objectives are added later as your project progresses through the development cycle.
Don't Fence Me In
Another common mistake is to confuse constraints with objectives. For example, "To implement the system by July 1."
Typically, in projects, you will encounter a predictable set of constraints:
You should never confuse constraints with objectives. Constraints are limits to your capability of achieving your objectives.
In the initial Kepner “Tregoe model developed during the planning sessions, you will probably find that the Is column contains a mixture of objectives (corporate, business, project, and system), quality requirements, solutions, and constraints. As described in this chapter, you can filter out into the various components of the business case during the RAP session. Again, what is important here is to let the stakeholders feel that they are being heard and that the RAP process flows smoothly.