Topic 4: Defining and managing scope

Defining scope

The three fundamental elements of project management—scope, schedule and budget—are interdependent. One cannot be altered without affecting one or both of the others. If the project budget is altered, then some compensating adjustment has to be made to either the project's scope, schedule or both. Nevertheless, when the project manager formally commences work on the 'contract' work, all three elements are fixed. Scope change is a 'given' in any project. Project scope will change. Managing that change is essential—but difficult.

Scope is slightly different depending on whether one's perspective is that of a customer or that of a contractor. Ultimately, scope defines the 'things' that are delivered to the customer, but it also includes those things we need to do and manage within the project to ensure that the 'things' are delivered. Thus, we document scope in two ways.

In summary, if we are to manage projects effectively, then scope has to match budget. If the scope of the deliverable package is not finalised, then we cannot set the budget or price for the deliverable package. In those instances 'scope' must refer initially to the work of defining the final deliverable scope, not the final deliverable scope itself. Just as scope evolves, so too does the process of defining scope. The 'somethings' we use to define scope are the contract and the work breakdown structure (WBS).

We can see a number of stages whereby scope is gradually refined, and then the contract is awarded and implemented. The stages don't have any official names, so for our purposes let's call them the:
* Search stage
* Proposal stage
* Tender stage
* Negotiation stage
* Contract stage.

For this unit a critical difference from the Project Management unit is that the WBS stops at the cost account level. It is not decomposed into individual work activities. That decomposition and ownership is the responsibility of the cost account manager(s). The difference between a cost account and an activity is fundamental. A cost account is a management entity defining work scope and performance accountability; an activity is a 'task'—one of many tasks—undertaken as a consequence of that assigned management accountability. We don't 'undertake' a cost account, but we do undertake the activities.

A cost account is a package of work that can be assigned to a single point of management accountability (a manager/owner). The cost account will have a scope summary, a start date and a finish date, and a budget. This budget may be in three parts: labour budget, material budget, and other-direct-cost budget. The cost account start and finish dates are derived from the project schedule. The cost account is a performance measurement unit, not a description of how that unit of work will be undertaken.

Two types of traceability are needed for effective scope management during the acquisition
process:
* horizontal traceability
* vertical traceability.

By horizontal traceability we mean the ability to trace from the original proposal estimates and price to the final estimates and contracted price. Because every WBS element, regardless of its level, has a scope statement accompanying it, we can quickly see what is included and what has been left out.

By vertical traceability we mean the ability to trace both the scope and the budget from the contract at the top to the work packages at the bottom. We can do this because of the WBS's ability to roll-up cost from the bottom to the top—and because each element at every level has a comprehensive scope statement that fixes the boundaries and the content of the element.

We have seen that:
* the WBS breaks the scope down into 'bite-sized chunks' controlled by a single manager at all levels the WBS has one responsible manager for the element (who may be responsible for many elements)
* we can map the WBS via these responsibilities to the OBS and, hence, form the responsibility assignment matrix (RAM)
* the WBS dictionary should show all deliverables, data items and interfaces; and, therefore, maps to the list of deliverables, the statement of work (SOW) and the contract data requirements list (CDRL).

Managing scope

Just as we defined the integrated management task as that of bringing the three key project dimensions—cost, schedule, system design—into synchronisation, so we must fix baselines for each of those three dimensions. The cost and schedule dimensions we fix with a performance measurement baseline (PMB), and the system dimensions we fix with configuration management baselines.

Configuration management baselines are system design 'maturity' points. However the system is defined by an ever-changing collection of requirements and design documents. We will call the collection of requirements and design documents as specifications. Thus a system design 'maturity' point must be a point where we 'fix' the then current specifications and proclaim them to formally describe the system until further formal notice.

The Performance Measurement Baseline (PMB) must enable:
* Objective measurement of contract work accomplished
* Production of data summaries useful for all levels of management
* Early indication of problems and unfavourable performance trends
* Identification of cost impact of technical problems and schedule changes
* Identification of cost forecasts based on actual performance

The PMB is defined as the time-phased budget plan against which contract performance is measured. It is formed by budgets assigned to scheduled cost accounts and the applicable budgets for indirect costs. It includes future effort not yet planned to cost account level, the budget assigned to the higher-level WBS elements, and undistributed budget from approved changes.

A starting point for our discussion is that scope change is a 'given' in any project; that
project scope will change, and that managing that change is essential—but difficult. In this topic, contract change means change to technical scope and/or the cost and schedule related to that scope. All scope change can be categorised as either customer-initiated change or contractor-initiated change.

Remember, with customer funded changes, the change 'price' has to have mark-up and management reserve deducted from it before it becomes part of the PMB. Similarly, with contractor-initiated changes, the PMB has to be increased in level to reflect the budget for the increased cost account scope; this increase comes from management reserve.

Completing scope

Our objective in this part of the topic is simply to describe the mechanisms for ensuring that scope 'sell-off' is successful. If we want to summarise who has the accountability for success throughout the development lifecycle, we could say that there are six process steps as shown in the left hand column. The right hand column shows that accountability for the success of the overall process is shared:

* Identification of a set of capabilities that are needed to satisfy an organisational need (Customer)
* Translation of those capabilities into a set of requirements against which a system could be procured (Customer, Contractor)
* Agreement on the method by which the system will be accepted (Customer, Contractor)
* Decomposition of the system requirements into a set of system design documents and subsystem requirements documents which will enable the development of the specified subsystems (Contractor)
* Development of the subsystems and qualification of those subsystems against their design requirements (Subcontractors)
* Integration of the developed subsystems and qualification of the integrated system against the
qualification requirements. (Contractor)

A constraint that has to be accommodated, though, is that success needs to be quantifiable, if it is to be useable as a metric. If it cannot be measured objectively, then it is not possible to reach agreement as to whether it has been achieved.

A simple diagram common throughout the systems engineering world is the 'V' model of verification and validation. We have spent some time talking about how system requirements are allocated down through the System Breakdown Structure to lower level components. This means that for every de-composition, we need to verify that we did the decompositing correctly, and that the sum of the parts does meet or exceed the sum of the whole. Secondly, that at each level of decomposition, we should conduct some 'test' to ensure that what we have is what we should have.

Qualification of the system requirements can be achieved by methods other than testing. Qualification can be undertaken progressively, often starting quite early in the development program. There are a variety of possible qualification methods. The acceptability of any particular one has to be agreed with the customer and should be defined in the contract. The following is a list of possible methods: (i) Test, (ii) Trial, (iii) Inspection, (iv) Demonstration, (v) Analysis, (vi) Extension, (vii) Design Comparison

Common problems

There are a number of problems that appear frequently in reviews of complex projects in relation to the definition and management of scope. They can be summarised under the following three headings.

SCOPE DEFINITION
At the root of this set of problems is inadequate WBS development and inadequate traceability of the basis on which estimates were made and changed. Often, not only are the scope statements for the WBS elements inadequate, but the structure itself is based on organisational principles—who is doing the work—rather than how the work is to be broken down into logical work products.

BASELINE MAINTENANCE AND MANAGING SCOPE
There are many problems with the effective maintenance of baselines and managing changes to those baselines. The first problems relate to budgeting practices, the second to the change management organisation.

The principal problems with maintenance of the PMB relate to:
Inadequate forward planning:
Undisciplined budget practices:

ACCEPTANCE PLANNING
The acceptance planning problems have three aspects.
* Lack of coherence in the trace from desired business outcomes to the technical
performance measures which will drive the design.
* Poor requirements traceability from system to lower level elements, which results in an
inability to achieve an effective development test and evaluation program and an
inability to plan a cost-effective qualification program.
* Lack of end-to-end test and acceptance planning means that there is a lack of
integrated effort across all development and acceptance phases.