Defining the Project Scope: Part One

The first phase in many project methodologies is to define the scope of the project. The scope states what the objectives of the project are and what work will be done to complete the project. The scope describes the parameters for what is included in a project and what is excluded from a project. The scope will become more refined as a project progresses, but it should always remain within the initial parameters defined.

When through the maturity of a project, the direction of a project changes where it goes outside the initial parameters—this is a change in the scope of the project. Likewise, if there are any changes to what will be done for the project, no matter how small or how large and no matter if they were specifically requested or not, it is a change in scope of the project.

Scope changes can make a project larger or smaller. Scope changes can affect the timeline of the project and the cost of the project. These changes in scope are more commonly referred by the term scope creep. In a nutshell, scope creep is the change or growth of project scope.

There is a mistaken belief among some project managers that perfect planning can be achieved, thus eliminating scope creep. In companies with good project management processes, scope creep is expected and planned for.

How to write a Scope Statement, by Eric Stallworth, is a step-by-step guide on writing a scope statement.

It is common for IT projects today to be over budget or to not be implemented in the initial target timeframe. Often the cause is attributed to scope creep. Therefore, in the eyes of many in I.T. management, scope creep is to be avoided.

In general terms, scope creep can cost up to four times as much as initial development costs. The costs of scope creep can include:

• deferred benefits
• lowered return on investment (ROI)
• increased maintenance costs
• additional expected loss, such as if the project is cancelled

To combat scope creep companies can use change management, controlling both internally generated changes and customer-driven changes in the scope of projects. You can establish a "configuration control board" or "change control board" to regulate changes. For customer-driven changes, the customer participates as a member of the configuration control board. The configuration control board addresses the following three questions at a minimum:

• What is the cost of the change?
• What is the impact of the change on project schedules?
• What added value does the change represent for the cusotmer or end user?

The benefit of developing a change management process is that it allows you to manage your customer. When your customer inititates a change request, you must be able to predict immediately the impact of the change on schedule, safety, cost, and technical performance. This information must be communicated to the customer immediately, especially if your project management methodology is that no further changes are possible becuase of the life cycle phase you have entered.

Educating your customer as to how your methodology works is critical in getting customer buy-in for you recommendations during the scope change process. The importance of having a structured change control process as part of the methodology is critical.

Project managers must remember that change management and risk management function together. Risks generate changes (scope creep), that in turn, create new risks. In companies with established project management processes, change amangement and risk management occur continuously throughout the life cycle of the project. The impact on product quality, cost, and timing are continuously updated and reported to management as quaickly as possible. The goal is always to minimize the number and extent of surpises.

In the second article in this series I will provide examples of and links to change management templates.

For a deeper understanding of risk management, read Bob Legrand's article, Risk Analysis and Risk Management.