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.

WHY THE INFORMATION LIFE CYCLE MATTERS

Information has a life cycle. It may come as a surprise but many things do although we don’t realize it.

Information Lifecycle Management (ILM) has become more important these past few years. Its importance will only increase as a consequence of two factors: storage has become inexpensive and the Internet has kicked off a veritable barrage of data.

Before proceeding, let’s clarify the difference between information and data. What is information? How does it differ from data? Even though the two terms are frequently used interchangeably, there is a technical difference. I like this definition: information is data in a meaningful context. The number 150, for example, is data. When it stands for the quantity of calories in a cookie, then it becomes information. In this article, information and data will be used interchangeably. If one is being specifically referenced, then it shall be clearly identified as such.

When users request their IT department to recover lost data, that information is almost always less than one month old (90% of the time). When lawyers request information, that data is almost always one or more years old.

Information has a life cycle. Information is generally most valuable at the moment of its creation. When you write down an address, that information is useful until you drop off the package at the post office. In fact, many of us would probably crumple the piece of paper the address was written on immediately after the mailing label had been written.

As a rule, therefore, information declines in value with the passage of time. Why is that?

Information is knowledge that almost always needs a decision or action. When you learn that your customer tried to call you, you react. When you emailed a co-worker, it was to finalize each other's part in a project. When you wrote the address down, it was the package’s destination. In these situations, the information prompted you to make a decision and act. Three months hence, how valuable is the information? Not much although the email may have value if the project were investigated.

Information should be stored and treated according to its value. That concept has spurred the creation of concepts like tiered-storage and terms such as “on-line,” “near-line,” and “off-line” data. This will be discussed in another post.

Information Lifecycle Management (ILM) recognizes the need to manage information according to its value. These are the aspects of ILM:

1. Legal and regulatory requirements
2. Security and confidentiality
3. The path that information takes through the organization
4. Whether information is structured or unstructured
5. How aware and conscious members of the organization are about information’s value
6. The tools the organization needs to manage information
   

Before information can be managed, it must be:

1. Identified
2. Categorized
3. Classified

After these steps, the framework for managing information can finally be created.

Do all these really need to be done? Unfortunately, yes.

There is really little choice since laws and regulations are effectively mandating the need to manage information.

The best reason for doing this work however is that it makes good business sense. You have to wrap your arms around the information octopus. Once you understand it, you’ll make wiser decisions about designing your information architecture and acquiring data storage.

Remember Y2K? It turned out to be a non-event, didn’t it?

Why weren’t more critics vocal about the hundreds of millions of dollars spent preparing for it? It is because of unexpected benefit of the Y2K effort. That benefit was derived from the enormous house cleaning operation that Y2K required. Old computers were replaced by new ones. The dust was literally cleared out of hidden data closets. Equipment was identified and tagged. Data processes were finally documented. And so forth.

Enforcing ILM will result in a similar type of benefit. And that is the best reason to do it.