IT Consulting from the Trenches

PROJECT MANAGEMENT: A BEST PRACTICE FOR PREVENTING SCOPE CREEP

A most insidious thing that will wreck havoc on your project is scope creep. The term refers to the addition of one addition after another to the original objective. The additions are usually done in a subtle manner and seem minor initially. Unchecked, you may find yourself with an objective that is more complicated, time-consuming, and expensive than the objective that was originally agreed upon.

After the project baseline has been created, the requirements of the project are cast in stone. The requirements were derived from the project’s scope. That means that any changes to the project’s scope will cause the requirements to change.

Until those changes are approved, the scope does not change and the requirements do not change. The requirements that any proposed changes will make are not official; they are preliminary.

Until those changes are approved, there are only “preliminary” requirements and “baselined” requirements. Train your people to distinguish between these two. Train your people to refer to the requirements of proposed changes as “preliminary” requirements. The official requirements are the ones that were cast in stone after the project and its corresponding scope were baselined. These requirements are “baselined” requirements. Thus, baselined projects have baselined requirements. Proposed changes bring preliminary requirements.

HOW IT WORKS

Consistently using these adjectives reinforces the fact that a baseline already exists and that any other requirements are preliminary ones that are not part of the baseline. Consistently using these qualifiers reinforces the fact that all requirements are preliminary until they are added to the baseline. There is only one way for preliminary requirements to become a part of the project’s requirements—the origin of the preliminary requirements, namely the proposed change, must be approved.

The careful use of terminology is an effective way to create an environment that discourages scope creep. Here’s an example.

One way that a customer or a stakeholder can try to introduce change is by insisting that his people meet directly with your people. He insists that he wants the information “raw.” He believes that if the information passes through the project management office (PMO), the information is filtered before it reaches him. As a Project Manager, you may have to permit his people meet your people directly as he requested. However, your permission should be given with the condition that your people are not authorized to accept or otherwise permit any changes to the original project objective. Any proposed additions must go through the PMO. Make sure that your people and theirs acknowledge and agree to that condition—in writing if it’s necessary.

THE SANCTITY OF THE BASELINE

After the project’s scope has been agreed upon, the scope is captured in a baseline. This baseline is one of the most important documents in the project. Time and again, everyone from the project team to the stakeholders will return to the baseline. The project baseline is the reference standard of the entire project.

The baseline captures the project scope. The scope, as discussed earlier, includes the requirements. The requirements are expressed in terms of time and costs. Time represents the project schedule. Costs represent the resources.

The baseline typically takes the form of a tracking Gantt chart. A tracking Gantt shows the actual project’s progress beside the original forecast. The Gantt shows the project’s duration by task. The sum of task durations is the agreed-upon schedule (or time) of the project. The agreed-upon costs are visible behind the chart. The costs are shown by resources and the amount of resources used by individual tasks. These explain why the baseline is so important. It contains the triple constraints of scope, time, and costs.

The baselining, i.e., act of creating the baseline, is typically done at the end of the project planning phase. As the term suggests, the project has been planned and the stakeholders have signed off on the plans.

At that point, it is very very important for the Project Manager (PM) to notify all stakeholders that "from this point forward, the team will be strictly adhering to the change control process." The PM must emphasize the seriousness of the change control process. After the stakeholders have signed off on the project plan, i.e., the baseline, the PM must emphasize that any changes must first be approved before its attendant requirements are added to the project's requirements.

DISTINGUISH DISTINGUISH DISTINGUISH

A proposed change can take the shape of an addition, revision, or subtraction of the project objective. If the change is accepted without going through a formal change control process, it becomes a part of the project scope. It becomes a part of the project’s requirements. This is scope creep. The scope changes incrementally, i.e., it creeps.

Train your team to always make the distinction between preliminary and baselined requirements and the environment will change. It’s a subtle thing but it works. Everyone will stay alert and know the difference between the original and the still-unaccepted requirements.

To reiterate, the team should never use the term “requirements” by itself. Never say or write it by itself with stakeholders and especially customer-stakeholders. Requirements are either preliminary or baselined. This reminds everyone that the scope and project requirements were already agreed upon and documented in the baseline.

IT IS ALL PSYCHOLOGICAL

I consider this to be a best practice for psychological reasons. Stakeholders, especially customer-stakeholders, tend not to take the original requirements of the planning seriously. Consequently, these stakeholders never treat the baseline with respect. Left unchecked, these stakeholders will continually propose changes that effectively create new requirements. Left unchecked, if these changes are passively acknowledged, stakeholders will learn to expect the acceptance of their proposed changes without any consequences. That should not be the case. The baseline reflects everything that all stakeholders had agreed upon. Any changes have a “preliminary” nature until they are formally accepted.

IT BECOMES A TEAM EFFORT

Through this practice, the PM will not be forced to implement the ban on unauthorized changes alone. Team members will stay alert and know the difference between the original and the still-unaccepted requirements. This involves them in the fight against scope creep. The team helps the PM with one of the most vexing problems that confront a PM during the execution phase of the project, namely, scope creep. Training your team in the manner described above turns the effort to control scope creep into a team effort.