THE THREE MOMENTS WHEN YOU'RE MOST AT RISK FOR FAULTY ESTIMATES

Good news, bad news. “I finished the project.” “But we went over the budget.”

Two reasons account for most cost overruns. These are Scope Creep and Faulty Estimating. Scope creep occurs because the Project Manager (PM) didn’t control change requests made to the original project plan. An approved change always comes at a cost and, therefore, a change that is approved must be accompanied by additional funding. Faulty estimating is the other usual reason for cost overruns. In this case, the budget was incorrectly calculated at the start. There are three moments during the project life cycle that the PM is particularly vulnerable.

This article discusses those high-risk moments.

Moment #1: At the start of the relationship

It’s one of your first meetings with the client. Naturally you want to start the relationship on the right foot. Pleasantries are exchanged after introductions are made. Both sides talk and walk “gingerly.” Nobody wants to rock the boat.

This is the first high-risk moment. In this situation, a Project Manager (PM) is likely to commit the first grave error—accepting client statements at face value without verifying them. Everyone on the project team is equally likely to make that mistake. It’s up to the PM to catch it, however, since the PM is ultimately responsible and accountable for the project's outcome.

(Incidentally, why does it seem that the Subject Matter Experts (SMEs) are the second most likely members of the project team to commit the mistake? I think this occurs because their stature as experts puts them in a particular frame of mind.)

Acknowledge every statement or assumption that they make but tell them that you will verify each one. There are many tactful ways to communicate this, beginning with the truth, and that is to check because both of you—the client and yourselves—want to accomplish the objective effectively and that correct assumptions are necessary for that to happen. Acknowledge it like the Japanese. During negotiation, they will say “hai!” Although it means “yes,” during the initial meetings, this yes simply means that they acknowledge receipt of a point and not agreement with that point.

You, the PM, must be firm about this. Do not concede to pressure from executive stakeholders (e.g., your Sales Vice President or the client’s executive). Since you are responsible and accountable for the project's outcome, you have the authority and power to perform the necessary steps. You will return to this theme again and again. Like the American colonists who sparked the Revolution against Great Britain, you must be represented if you are going to be taxed. In this case, the metaphor is that you must have the power to do the necessary things to create the desired outcome if you will be held responsible and accountable for that outcome.

Finally, do what you said you would. Confirm all assumptions. Verify every assumption that they make. And verify every assumption you and your team also make. Some assumptions will be difficult to verify but verify them anyway. An example of a difficult assumption is the client's contention that they already have the necessary computer workstations for the project. Confirm that and get that confirmation in writing signed off by the appropriate party.

Moment #2: When you negotiate with your project sponsor

You've finished the preliminary project plan. Now you're sitting with your sponsor. This is the moment for you to firmly explain that, to be prudent, we should follow PMI methodology and create a contingency allowance as well as management and contingency reserves.

The third edition of the PMBOK identifies two types of reserves. A Management Reserve is a portion of the approved project budget, controlled by management that is reserved for unidentified or unexpected work inside the scope of the project. This reserve is excluded from the baseline until it is utilized. Another accepted definition: A Management Reserve is a designated amount of time and/or funds held to account for parts of the project that cannot be predicted. These are sometimes called “unknown unknowns.” Use of the management reserve generally requires a baseline change.

A Contingency Reserve is an amount (of dollars and time) held by the project sponsor for possible changes in project scope or quality. All scope and quality changes to the project will affect the project’s cost and schedule and this reserve will cover those. Another definition: A Contingency Reserve is a designated amount of time and/or funds held to account for parts of the project that cannot be fully predicted. These are sometimes called “known unknowns.”

The PMBOK also recognizes the concept of a Contingency Allowance. It is a specific provision meant to cover variations in the expected cost or schedule, but not scope or quality. The scope of the project may not change but unforeseen factors may change the budgeted cost and schedule.

These three concepts are now illustrated.

First is the Management Reserve. Assume a project’s objective is to wire a building’s electrical subsystem. If the area is unexpectedly hit by an earthquake (an unknown unknown), the ensuing clean-up and repair is a major activity involving numerous tasks (e.g., checking the building’s structural integrity). Covering these unknown unknowns is the reason for the Management Reserve.

Second is the Contingency Reserve. When the scope or quality of a project is officially changed, there will be additional tasks. These additional tasks are not unidentified or unexpected, as in the previous case. The Contingency Reserve is used to cover the cost and time of these additional tasks. Continuing the previous example, assume that from experience, you are certain that there will be some electrical rework, but the amount of rework and when it will occur in the project are unknown.

And third is the Contingency Allowance. Assume a project whose objective is to migrate a company’s IT operations to a new data center. The objective is straightforward—move operations from point-A to point-B. Since there’s only one Point-B whose purpose is to become the new data center, it’s unlikely that the scope of will change. However the cost or schedule easily could. It might require more man-hours than expected to shut down and restart the company’s data servers. These are the surprises that the Contingency Allowance covers.

To reiterate, therefore, the Management Reserve is held and released at management’s discretion to deal with unknown unknowns. The Contingency Reserve is held and released by the project sponsor (usually) to deal with known unknowns. And the Contingency Allowance is a wise precaution that the PM should create to deal with potential changes in cost and schedule.

Moment #3: At the start of the actual project

Complete your documentation before starting the project. This is easier said than done. PMs are usually pressured to begin with the assurance that the documentation will follow. When your boss’s boss makes that assurance, you frequently have no choice. What you can do, however, is get that assurance in writing. If the signed documentation isn’t delivered, you should firmly exercise your power and explain that it won’t be proper to hold you responsible and accountable if your right to act appropriately is curbed. Once again, reiterate that you have to exercise the power to do the necessary things to create the desired outcome if you will be held responsible and accountable for that outcome.

Your documentation should be meticulously prepared and organized. Contracts should be intact copies, email should be filed, and so forth. Remember those assumptions that you verified? Keep the evidence of verification. Remember those reserves and allowance you created? Know the warning signs and the steps you’ll need to take to avail of them.

Finally, note that you can only prepare so much. Be cognizant of those moments above and you’ll be off to a strong start!

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.