Project Scope

Planning a project is about deciding what work needs to be done in order to achieve the objectives of the project, who will undertake each task involved, when each task will be carried out and how long the work will take, and what resources will be required. In addition, all of these activities must be viewed against the backdrop of cost, both ongoing and final. The project plan addresses questions such as what, when, how and by whom.

There can be no plan, however, until it is known with some certainty exactly what has to be accomplished in terms of the deliverables that have to be produced for the project client - in other words the scope of the project. Establishing the scope of the project is important, therefore, because it determines both the extent of the resources required and the amount of time needed to complete the project. Both factors will have a direct bearing on the overall cost.

In order to define the scope of the project, it is necessary to determine the requirements that must be met. This is achieved by talking to the customer and studying the problem to be solved to ensure that the requirements are fully understood. Ultimately, the customer wants a solution to a specific problem or set of problems, and what you are trying to elicit from them is a definitive set of criteria that must be met by the solution in order for it to be accepted. Bear in mind that the customer’s perception of how the problem should be solved may not be the best solution, and may be missing one or more critical elements.

Once the acceptance criteria have been established, they become the objectives for the project. If the project objectives are achieved, therefore, the customer will be satisfied. It is very important to be able to prove to the customer that the project objectives have been met. They must be defined in unambiguous terms, and they must be measurable.

From the customer's point of view, the set of requirements defined will include all of the features that the final deliverable must exhibit (e.g. compliance with applicable industry standards or regulatory guidelines) and the functionality provided (e.g. the actions that the system will perform or the work it will carry out). It is also good practice to try to group requirements into three categories. The first of these will be a basic set of features and functionality that must be provided.

The other two categories will be split between those features and functions that would be highly desirable, and those that would simply be nice to have if time and financial circumstances allowed. This approach defines a basic package and two levels of value-added features and functions, and provides some scope for making decisions on what is to be included in the final deliverable during the planning phase (or even beyond, should circumstances change).

The document that defines what deliverables are to be provided (in other words, the objectives of the project) is called the scope description, and its purpose is to describe as fully and as unambiguously as possible what will be produced, including details of the required features and functionality, and the agreed-upon acceptance criteria. It is important to clarify both what is, and what is not included in the scope of the project, since this defines the project boundaries.

The scope description should list the major tasks that will be undertaken in order to produce the deliverables, and should provide a realistic estimate of when the implementation phase of the project will end. The document should also identify the project's stakeholders. A stakeholder is any individual or group that is either contributing to the project, or is affected by it directly or indirectly.

The scope of a project determines, to a great extent, how much time and effort will be involved in carrying the project through to completion. A preliminary baseline will be established that defines project milestones and the projected work schedule and costs for each phase of the project. The baseline will provide a basis for formulating the project plan, as well as a yardstick against which the actual costs and work carried out at each stage of the project schedule can be measured.

In the early stages of the project, the baseline may be amended to take into account any agreed upon changes or additions to the project scope, but at some point it will be frozen. From this point on, the original baseline will be used as a historical reference point. A revised baseline may be produced at the end of each major phase of the project to reflect any changes in scope that may have occurred. Any significant changes to the scope of a project will have profound consequences on both cost and timescale. The scope does, after all, effectively represent the overall scale of the undertaking.

It is invariably the case however that for a project of any size changes will occur – a phenomenon sometimes called scope creep. The reasons for such changes are many and varied. While they usually involve some additional work having to be carried out (e.g. an extension of the project's scope), there are occasionally situations where the scope of a project is actually reduced. Either way, contingencies must be available for dealing with changes in scope.

It is important to understand the reasons why the scope of a project can change, and (to some extent) to be able to differentiate between them. It may be, for example, that certain tasks have been left out the project plan either because they were simply overlooked, or because not enough information was available to properly define them when the project plan was drawn up.

In such circumstances you are not extending the scope of the project but simply adding to the list of work that must be carried out in order to achieve the agreed upon objectives. There should therefore be some contingency built in to both the budget and the project schedule to allow for this. On the other hand, the customer may request additional features or functionality not included in the original agreement. The scope of the project must therefore be extended to take these changes into account.

Once it has been established that the requested changes are feasible, the impact on the project’s budget and work schedule must be assessed. The project plan will need to be modified accordingly, and any additional costs for the extra work involved should be agreed with the customer, together with a revised completion date.

Another scenario that can (and often does) arise is where the actual time taken to carry out the work exceeds the time scheduled for it, or the cost of materials is higher than anticipated. It should be clearly noted that this kind of occurrence does not constitute a change in the scope of the project. Since the scope of the project is used to determine the project baseline, deviations from the planned work schedule or cost overruns do not warrant a change to the project baseline. Rather, the baseline is maintained in order that we can assess actual performance against it, and determine to what degree it has deviated from the project plan.