Defining The Scope

Defining The Scope

Scope changes are the most common source of project overruns. Clearly, they require firm management. But a scope change cannot be recognized until the scope baseline is established. If you do not define the scope at the start of the project, you will lose a lot of sleep through being unable to refuse apparently logical client requests for even more work that will set your beleaguered project back even further.

It was a payroll project, and it was almost complete when the client, reviewing a menu, asked, ''How do I produce year-end taxation slips?"

Project Manager: Year-end taxation slips? They weren't part of the definition.

Client: Of course they were. Taxation slips are a standard requirement of all payroll systems.

Both were correct. The client had not specified taxation slips, and such slips are standard.

The problem, of course, is that not all details of the scope can be defined in advance, and some misunderstandings are inevitable. The more time you invest in clarifying the scope, the fewer problems you can expect as the project unfolds. Be prepared to spend time gaining agreement on scope before you expend effort on the project; otherwise, client expectations will solidify and you may be stuck having to do more than you planned.

There are two types of scope: the scope of the system and the scope of the project. The scope of the system concerns functionality, business rules, procedures, and interfaces to other systems. The scope of the project concerns the degree of effort and formality required of the project deliverables.

The Scope of the System

Defining the scope of the system means coming to a common understanding of its major boundaries and the business functions it encompasses. For example, an inventory control system may be defined to include manufacturing and finished goods inventory, but to exclude fixed assets. More generally, the system may be defined to exclude (or include) bill of materials, purchasing, order entry, or any other functions that affect or are affected by inventory control.

The scope of any system becomes blurred because all business functions interact with one another. Purchasing interacts with inventory, which interacts with order entry, which interacts with sales, which interacts with ..., and all these systems interact with general accounting. This interdependency makes project managers who want to be cooperative vulnerable to scope change requests. It is hard to argue with a client who says of a purchasing system, "What good is it to capture vendor prices if I can't use that information to pay them?" The answer, of course, is that the system you are developing is purchasing, not accounts payable. If the client wants accounts payable, that's a scope change.

To help define the scope of the system, list and briefly describe the major inputsforms, screens, and interfacesand the major outputsreports, calculations, interfaces, and inquiries. Note the word major. Until you are at the point of detailed specifications, nobody, not even the client, can exhaustively identify everything. However, by listing the major inputs and outputs, you and the client can reach an understanding of the general scope of the system. For example, if, while specifying an accounts receivable system, the client describes an inquiry showing a customer's purchasing history, then the scope of the project must include on-line access to a sales database. You can either include that access in the scope or question whether it should be part of the system. In either case, once the exercise is finished, both you and the client will have come to expect roughly the same thing.

The Scope of the Project

The scope of the project deals with how each deliverable is prepared and presented. For example, the deliverable item "program specifications" can vary in formality from some handwritten sentences on a sheet of paper to a fully elaborated program structure diagram. Neither is inherently better, and both, being program specifications, fulfill the spirit of the deliverable. However, the two require vastly different levels of effort.

Be wary of statements that include the word standards, such as, "The system will produce documentation according to corporate standards." This could mean that all documents must conform to documentation standards specifying such things as fonts, headers and footers, or section numbering. But "corporate standards" could also refer to a development methodology that dictates what is to be produced and how it is to be approved. Some methodologies, if strictly followed, call for dozens of documents and demand that each be submitted to a multiphase review and approval process. Project managers who plan to produce only the obvious deliverables will see their plans shattered as the client requests documents they have never heard of.

The scope of the project is normally dictated by the client's development methodology and the rigidity with which it is applied. The methodology will state what documents are to be prepared, the sequence of preparation, and the contents. Some methodologies include samples showing the level of detail expected in each deliverable. Be alert for different opinions on standards. If your client is the accounting department, it may not care about development methodologies, but the information systems department may have some exacting requirements in this area. Do not rely on your client to understand the impact of or requirements for a methodology.

Methodologies are like rainwear: a nuisance to put on, but indispensable when the storms hit. The biggest problem with them is the way they are applied by systems departments. The best regard them as a tool kit stocked with techniques and procedures to be drawn on when required. There are two forms of worst: One regards them as law to be followed rigidly, regardless of the application; the other regards them as a waste of shelf space and gatherer of dust.

To define the scope of the project, you must determine what methodology the client uses and how rigidly it is applied. If the client regards methodology as a waste of effort, you should still follow it to the extent that it contributes to the success of the project.

Scope and Indeterminate Projects

In some projects, the scope is indeterminate, either because the application area is new or because the client has not fully clarified the mandate of the project. In these cases, since nobody can define the scope clearly, you are at risk of a runaway project. However, even though you cannot define the scope in terms of the business requirements, you may be able to define it in terms of work products.

Defining scope by work products means basing the scope on measures such as function points, screens, interfaces, or reports. For example, you may stipulate that the project will not exceed 200 function points or that it will be limited to five data entry and fifteen inquiry screens. This method of defining scope is not accurate, since a screen, for example, may be simple or extremely complex, but basing scope on work products does serve to delimit the work to some extent.

In some cases, the scope may even be based on low-level technical work products such as the number of elements in the data dictionary, the number of entities in the data model, or even the number of programs or lines of code. Identifying scope in this manner is unsatisfying and, especially for the client, dangerous, since there is never a clean relationship between technical work products and business functionality. However, if the client cannot define the scope according to business rules, defining it according to this kind of measure is an alternative. In this case, the client is agreeing that if the magnitude of the project exceeds some predetermined threshold, there will be additional costs and schedule delays.

Scope Change Mechanisms

Regardless of how conscientiously you define the scope, it will change, which means that you need a mechanism for managing it. Make sure that you and the client agree that when the scope changes, you will identify the impact on the cost and the schedule, and the client will either approve or reject the change. The degree of formality of the process will vary, but the central principle is constant: The scope does not change without authorization. If your organization does not have a scope change mechanism, here are some suggestions.

1. When you identify a change of scope, submit it to your technical people for estimates, and calculate the effect of the change on the project schedule and costs. (Identifying scope changes is a major problem in itself. See "Managing Scope Changes" in Chapter 5 for ways to ensure that they do not creep in unobserved and unmanaged.)

2. Document the change and its impacts on a change request form. A sample form is shown in Exhibit 3.2.

3. Submit the change request form to the client. In particular, note that the form includes a "Date Required." This is the date by which a decision whether or not to proceed with the change must be made, because after this date, the change will be harder to accommodate and will have greater impact. For example, the change might affect a program that has not yet been designed. On the date required, the program design is scheduled to begin, and, once it is under way, the change will be more difficult.

4. After this, the change becomes a matter of client approval. It may require negotiations or modifications of the change, but ultimately, the client must either approve or reject the change.

5. If the change is approved, redo the project plan incorporating the change.

What If?

The Client is Unclear About The Scope of The System.

Without a clear scope, your project will be vulnerable to new requirements, which the client will insist were always included.

Actions

Determine if the lack of clarity arises because of an unwillingness to be specific or because the nature of the project makes clarity impossible.

If the client is not willing to be specific, then prepare the estimate, budget, and schedule and present them to the client with a covering memo explaining that they are based on your understanding of the scope, then describing what you assume to be in and out of the scope. If the client disagrees about the scope, you will be able to adjust your plans accordingly.

If the client cannot be specific because of the nature of the project, suggest that the estimates must be based on some agreed-upon measure such as function points, with some change mechanism triggered when the actual number of function points exceeds the estimate.

In your project plan, include a scope section in which you list the items that are in the scope and related items that are not. Ask the client to sign off on the plan.

The Client Department Does Not Want "All The Paperwork" That The Corporate Methodology Requires.

Your project will be caught in a battle between the systems department and its requirement for adherence to its methodology and the client department and its desire for brevity and minimum overhead.

Actions

Recognize that the systems department will usually prevail, since systems are its responsibility. If the methodology requirement is reasonable, inform the client department that you cannot override the policy without good cause, and that, in fact, you agree with it.

If the methodology requirement is not reasonable for the size of the project, discuss the situation with the systems manager and attempt to get the requirement modified. However, if the systems department is adamant, you and your client will have no choice, and you should build your plan accordingly.

The Methodology is Inappropriate For The Project.

The methodology is probably inappropriate because:

It is too cumbersome for the size of the project.

It does not apply to your development approach.

The methodology is new to the organization, and your project has not agreed to be a pilot.

In all of these cases, applying the methodology will extend the effort of your project beyond any benefit the methodology will confer.

Actions

Prepare two estimates, one with the methodology and one without, present them to the steering committee, and ask the committee to help you adopt a more appropriate methodology.

Failing that, request committee approval to charge the difference between the estimates to a nonproject account.

If the steering committee still does not agree, then, when you are running the project, ensure that you comply with the methodology, that you attempt, as much as possible, to extract value from its deliverables, and that you add necessary deliverables that the methodology does not include.