What Is the Difference between Scope and Objectives?

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:

Project Scope

To develop a user -friendly system by July 1 to track customer enquiries in head office.

There are some very serious problems with this type of scope statement.

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



Following this idea, a very useful tool for stating project scope is the modified use of a technique developed by Kepner and Tregoe (1981) for problem statement. As shown in Figure 8.4, this technique involves stating what the scope is, what it is not (could be but), and, in early stages of the project planning, what is not resolved.

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.

The Take It Away Test

Another useful test for evaluating the effectiveness of your modeling of objectives is to take the objective away. By taking away an objective such as, "To provide customer enquiry summaries to customer service management" do you make the scope of the project different? If so, then you have a valid objective.

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 [2] and, as a result, must have the unilateral right to make the final decision about the scope and objectives of his or her project.

[2] The real owners for most projects are the stakeholders and clients .

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:

  • Corporate: The strategic objectives of the organization as contained in the strategic plans or organization mission statement.

  • Department or business: The objectives of each department or business unit in the organization. Clearly, these must reflect the corporate objectives.

  • Project: The objectives for the project. These objectives must reflect the department-level objectives of the organization business unit that is sponsoring the project and are contained in the Is column of the scope and objectives statement.

  • System: A subset of the project objectives that will be implemented in the information or business system.

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.

  • Who: Which managers?

  • What: What information?

  • When: When do they want the information?

  • How much: How much improvement is required?

As a result of these questions, the initial objective can be refined as follows :

To produce statistics on processing time and defect levels in invoice processing daily (5:00 p.m.) for accounts management in the central office.

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. [3]

[3] Many IT people will recognize this as the same as the distinction between logical and physical models. Logical systems are implementation technology independent, whereas physical models are technology dependent.

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:

  • Corporate: The strategic objectives of the organization as contained in the strategic plans or organization mission statement.

  • Deadlines and time frames : Your project must deliver by a fixed date or within a fixed time frame.

  • Budget: Your project is limited by a fixed amount of capital or finance.

  • Resources: Your project is limited in the number of people or skills.

  • Technology: Your project must conform to preexisting or planned technology platforms.

  • Policy: Your project must conform to existing or planned corporate or government policy.

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.

Radical Project Management
Radical Project Management
ISBN: 0130094862
EAN: 2147483647
Year: 2002
Pages: 136
Authors: Rob Thomsett

Similar book on Amazon

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net