PROJECT MANAGEMENT: A BEST PRACTICE FOR PREVENTING SCOPE CREEP

One of the most insidious things 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.

Once a baseline has been created, there are only “preliminary” requirements and “baselined” requirements. Train your people to use these terms “preliminary” and “baselined” before the word “requirements.” Consistently using the adjectives will ingrain the fact that a baseline already exists and that any and I mean, 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 included in the baseline.

One way that a customer or a stakeholder can try to introduce an addition 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 you think that it’s necessary.

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

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. You might say that the project baseline is the reference standard of the entire project.

If you think about it, the baseline captures more than the project scope. It also incorporates the time and costs. 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.

From that point, the Project Manager (PM) should clearly 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. From this point forward, the PM must emphasize that the baselining process must be followed.

An addition, if it is accepted without going through a formal change control process, becomes a requirement. It becomes part of the scope. This is what scope creep is—the scope changes incrementally, i.e., it creeps.

Returning to that earlier example, the PM should instruct his team to never say or use the term “requirements” by itself. Again, never use the term “requirements” by itself with stakeholders and especially customer-stakeholders. Remind them that the scope and project requirements were already agreed upon and documented in the baseline.

Once a baseline has been created, there are only “preliminary” requirements and “baselined” requirements. Train your people to use these terms “preliminary” and “baselined” before the word “requirements.” Consistently using these adjectives will ingrain the fact that a baseline already exists and that any and I mean, 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 included in the baseline.

Any change that pops up after the baseline is not included in the scope. It is referred to as a “preliminary requirement.” It stays preliminary until it goes through the change control process. If the change is accepted, then it turns into a “baselined” requirement.

I consider this to be a best practice for psychological reasons. Stakeholders, especially customers, 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 submit new requirements and expect their acceptance 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’s a subtle thing that works. Train your team to always make the distinction between preliminary and baselined requirements and the environment will change. Everyone will stay alert and know the difference between the original and the still-unaccepted requirements.

One of the most insidious things 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.

Once a baseline has been created, there are only “preliminary” requirements and “baselined” requirements. Train your people to use these terms “preliminary” and “baselined” before the word “requirements.” Consistently using the adjectives will ingrain the fact that a baseline already exists and that any and I mean, 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 included in the baseline.

One way that a customer or a stakeholder can try to introduce an addition 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 you think that it’s necessary.

A practical way to create an environment that discourages scope creep is through the careful use of terminology. Here’s an example.

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. You might say that the project baseline is the reference standard of the entire project.

If you think about it, the baseline captures more than the project scope. It also incorporates the time and costs. 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. From that point, the PM should clearly 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.

The PM must clearly 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. From this point forward, the PM must emphasize that the baselining process must be followed.

An addition, if it is accepted without going through a formal change control process, becomes a requirement. It becomes part of the scope. This is what scope creep is—the scope changes incrementally, i.e., it creeps.

Returning to that earlier example, the PM should instruct his people to never say or use the term “requirements” by itself. Again, never use the term “requirements” by itself with stakeholders and especially customer-stakeholders. Remind them that the scope and project requirements were already agreed upon and documented in the baseline.

Once a baseline has been created, there are only “preliminary” requirements and “baselined” requirements. Train your people to use these terms “preliminary” and “baselined” before the word “requirements.” Consistently using the adjectives will ingrain the fact that a baseline already exists and that any and I mean, 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 included in the baseline.

Any change that pops up after the baseline is not included in the scope. It is referred to as a “preliminary requirement.” It stays preliminary until it goes through the change control process. If the change is accepted, then it turns into a “baselined” requirement.

I consider this to be a best practice for psychological reasons.

Stakeholders, especially customers, have a tendency to not take the original requirements of the planning seriously. Consequently, these stakeholders never treat the baseline with respect. Left unchecked, stakeholders will continually submit new requirements and expect the acceptance of these additions 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. The distinction is subtle and should continually be pointed out. Train your team to always make the distinction between preliminary and baselined requirements and the project environment will change.

Through this practice, a 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.