Defining Scope

Defining scope is perhaps the most important part of the initial definition and planning process. If you don’t know what you are delivering and what the boundaries of the project are, you have no chance for success. If you have not done a good job of defining scope, managing scope will be almost impossible.

The purpose of defining scope is to clearly describe and gain agreement on the logical boundaries of your project. Scope statements are used to define what is within the boundaries of the project and what is outside those boundaries. The more aspects of scope you can identify, the better off your project will be. There are two major aspects of defining scope on your project – deliverables and boundaries.

• The deliverables
  Even if you are not sure what else to include in your scope definition, you should always include your deliverables. Understanding the deliverables you are producing goes a long way to understanding the scope of the project. There are many deliverables that could be listed, but you should focus on the final deliverables of the project, plus any internal deliverables that are client-focused.
• Project boundaries
  Boundary statements are used to describe aspects of the environment that are in-scope for the project versus those that are out of scope. You would not need to state that some aspect of the project was in-scope unless you could also contrast that with some aspect that is out of scope. The nature of a true boundary statement is that there is both an in-scope and a relevant out-of-scope counterpart. For example.
  • The major life-cycle processes that are in scope and out of scope.
    For instance, your project may include the Analysis Phase only and not the Design, Construct or Test Phases.
  • The types of data that are in scope and out of scope.
    “Data types” refer to business units such as financial data, sales data, employee data, etc. It is possible that your project works with some types of data and does not work with others.
  • The organizations that are in scope and out of scope.
    In some cases, the organizations involved in the project help to define the boundaries. For instance, your project may be applicable to the Human Resources and Accounting Departments, but the Manufacturing Division might be out of scope.
  • The major functionality that is in scope and out of scope.
    For instance, decision support and management reporting might be in scope, while overnight batch processing might be out of scope.

These two areas - deliverables and boundaries are used to define the high-level scope of the project.

Use High-Level Objectives as Your Starting Point

When the project was proposed for funding, there should have been an initial set of high-level objectives and deliverables defined. There may even be some type of high-level scope statement. Any information that was created earlier should be used as the starting point for defining the more detailed scope statements for the Project Charter. If you find that you do not have enough information to create a clear and comprehensive scope statement, you must work with the sponsor to gather additional information. That is one of the main purposes of the definition and planning process.

If you have project objectives, look at them to help shape the scope statements. By definition, there needs to be one or more deliverables created to fulfill each objective, and defining the project deliverables is one of the primary aspects of project scope. After you determine the major deliverables the project will produce, start asking other questions to determine other aspects of scope. The deliverables describe ‘what’ the project will deliver. You can also identify ‘what’ organizations are impacted, ‘what’ types of data are needed, ‘what’ major features and functions are needed, etc. These statements help shape the boundaries.

As a point of clarity and contrast, you can also identify out-of-scope conditions. Of course, there are an infinite number of out-of-scope statements. For the purposes of scope definition, you want to include only those statements that help define the project boundary and touch upon related areas that the reader may have questions about. For instance, if you were installing financial software, you might state that a new Accounts Payable package is in scope, but the related Purchasing System is out of scope. This would make sense because the Purchasing and Accounts Payable processes are related and there may be questions as to whether the Purchasing System was in scope. However, you would not have to list every other system as out of scope – just the ones that the reader might have questions about.

It is a good practice to document those organizations that are in scope and those related organizations that are out of scope. The readers can then determine more easily if they are impacted or expected to assist in the project. Also, it may make sense to identify the organizations that are in scope so that you can have people from those organizations represented on the project team – perhaps on a steering committee.

Aligning Objectives and Scope

When you have completed creating your objectives and scope statements, go back and make sure that they are all in alignment. You should not have any objectives that make references to deliverables that are not defined in your scope statements. If you are not building something to satisfy an objective, you will not be able successfully complete the objective.

Likewise, you don’t want to include deliverables in your project scope that do not help to achieve the project objectives. If you are proposing to build deliverables that do not help you achieve your project objectives, you would need to ask yourself why. Since the objectives describe the purpose of the project and are used to validate project success, why would you want to build deliverables that do not help you achieve your objectives?

If the objectives and the deliverables in your scope section are not aligned, you need to determine how to bring them into alignment.

• If you have an objective without a deliverable, you need to validate whether the objective is really important. If it is, then you will need to add or modify the deliverables to satisfy the objective.

• If you have a deliverable without an objective, then you need to ask whether the deliverable is really important. If it is not, then remove it from the project. If the deliverable really is important, you need to work with the sponsor to determine the business objective for creating it. It is likely this objective is valid, but unspoken yet.

Aligning objectives and deliverables will help ensure that you are building all of the deliverables required to support the objectives - and no more.