IT Employment optimize

Don?t use contingency hours to complete out-of-scope work

Adding contingency hours to offset project uncertainties is an important part of the estimating process. But as Project Mentor Tom Mochal explains, project teams should avoid using contingency time to complete work that is out of scope.

Each week, project management veteran Tom Mochal provides valuable advice about how to plan and manage projects. Tom first describes a common problem scenario, based on real-life situations. He then offers a solution, using practical project management practices and techniques.

The dilemma
Ted is one of the project managers working on the implementation of a manufacturing software package at our new plant. I reviewed the project definition before my first meeting with Ted. He explained that this was the fourth plant in which he had installed this manufacturing software package. “Although they’re all similar, each plant has its own unique needs,” Ted explained. “For instance, our clients have just requested that we implement a custom inventory-management module that the other plants did not need.”

I was surprised to learn about the custom module. “Your project definition says that you are going to implement base-package functionality only. If there is a new business need, I hope you are invoking scope-change management.”

“I talked to the customer about scope change,” Ted said. “But they pointed out that our estimate included a 15 percent contingency. They thought we could use that funding for this new work.”

I asked why he included the 15 percent estimating contingency.

“The contingency covered a couple of unknowns,” Ted explained. “First, although I have done this kind of project before, the rest of my team hasn’t. It may take some time to get up to speed. We’re also installing a new release of the package that wasn’t used in the other plants.”

Those sounded like valid reasons to add contingency. Even so, I questioned what would happen if Ted’s people needed extra time with the learning curve and/or if the new software had unexpected glitches, but they had used up their contingency by completing work that is outside of scope.

“I guess the project will be over budget,” Ted concluded. “Then I will look like a bad manager, even though I thought I was being customer focused.”

Mentor advice
One of the steps in the estimating process is to add contingency hours to reflect the level of uncertainty associated with the estimate. However, once the estimate is approved, there may be pressure to use the contingency to absorb additional requirements. The customer might ask why he or she needs to invoke scope-change management for new requirements if you already have padding built into the estimate. Project managers must resist the temptation to use these built-in hours to complete new work because there will be plenty of reasons to use the contingency when activities take longer than expected.

In Ted’s case, his project has just begun and there is already a request to use the contingency. If he uses the contingency for this additional requirement, he opens his project up to two risks:
  1. His project will go over budget if the uncertainties associated with the original estimate materialize. As Ted correctly notes, he will then be seen as a poor manager (or a poor estimator), even though he thought his actions were customer focused.
  2. By skipping the scope-change process, Ted is denying the sponsor an opportunity to determine whether the requested change is justified from a cost/benefit perspective. Instead, he is making the decision himself.

The better choice is to push the request through the scope-change process and let the sponsor determine if it’s worth the incremental time and cost to the project. If so, the budget should be increased to cover this work. If the original estimating contingency is not fully utilized, the remaining money can be returned to an internal customer at the end of the project (or it would be retained as additional project profit if this were an external customer).

Project management veteran Tom Mochal is director of internal development at a software company in Atlanta. Most recently, he worked for the Coca-Cola Company, where he was responsible for deploying, training, and coaching the IS division on project management and life-cycle skills. He’s also worked for Eastman Kodak and Cap Gemini America and has developed a project management methodology called TenStep.


Got project management woes?
Tell us about them. Tom Mochal will answer those that affect the widest number of readers. Post a comment below or send us a note.

 
0 comments