Caution! Project creep ahead

Although all changes that are proposed are meant to be improvements in schedule, cost or performance of projects, another universal truth is that there’s many a slip between the cup and the lip. Michelle LaBrosse says “project creeps” are best avoided.

One New Year’s resolution every project manager would love to keep is to avoid the dreaded “project creep.” This is the disease of “we can make it better” or “the customer decided they really want this feature.” One little change here or there and before you know it, you’re working on something completely different from what was agreed upon initially.

Some changes will have negligible impact, but others could significantly derail or delay the project, or put the costs far out of budget. Project changes should not be undertaken lightly.

What causes project creep?

Sometimes project creep comes from circumstances that are out of everyone’s control, ie, if there are new threats from competitors, if new technologies emerge, or if there are changes in the environment—political, economic regulatory—that can change the objective. But in other cases, project objectives can change if the basic concepts of the project evolve into something new, if customer requirements change (because customers are at the mercy of inescapable changes, too), if the availability of resources for the project change, or if there’s a change of leadership or strategy at your company or at the customer’s.

Now, more than ever, change is the only constant, and it isn’t necessarily bad—as long as we can be prepared for it, make good decisions about it and manage it in a way that keeps our projects humming along on track, not wandering into unknown territory. Here are some ways to help you manage change and keep project creep to a minimum.

During planning

Bring the customers into the process early: Customer involvement is key to avoiding project creep. In the planning process, customers should be brought in who are directly and indirectly affected by this project, who are experts in their field and who can make informed decisions about their processes, goals and work. They are the source of information about the business requirements that lead to project initiation; and their detailed input will prevent inaccurate or vague project outcomes. They should be walked through the project agreement, understand the risks clearly, specify and sign off on project expectations.
Head off confusion in the project agreement: As mentioned above, inaccurate or vague project outcomes are a major cause of project creep. The trouble spots in a project agreement are:

1. Incomplete project identity information: The title of the project, the persons creating the project agreement, the date the project agreement was created, and the project sponsor (the person authorising the project to its completion) are not sufficient. As noted above, the list of people creating the project agreement should officially include a representative customer (or customers). It’s surprising how often the end user is kept out of the loop… until they get the final product and say, “that’s not really what I needed.”
2. A vague project objective: The final deliverable of the project, or project objective, should be a clear, brief statement of one to three sentences that conveys the desired final outcome. An objective that is focused on process instead of outcome is too vague and is likely to be changed. A sure sign of poor project management—and project creep—is a project objective that changes throughout the life of the project. Clarity and specificity is essential.
3. Indefinite project boundaries: It is smart to spell out precisely when the project team will start its work and when the project will be completed. Although every project agreement details what the project will cover, a project creep-proof agreement will also specify what won’t be covered.
4. An outdated business case: Every project agreement should include a strategic business case that offers compelling reasons for completing the project from the perspective of the overall value to the company. However, if the business case changes—if technology makes the project obsolete or the market goes in a different direction—then the project’s reason for continuing changes as well, and it must be relaunched or closed out.
5. Indistinct project priorities: The various constituents involved in the project—sponsor, stakeholders, customers, project managers and project team members—must clearly identify their priorities and hold to them. “Must have” vs “Nice to have” is a simple way to prioritise, using the business case as the guideline. Identify the risks for each must-have requirement and get the stakeholders’ approval—especially the customers’.

After the launch

Have a process for change requests: Make sure there is a process for changes or revisions in scope once the project has begun. This has two advantages:

• It ensures that any changes are considered comprehensively
• A change requisition process sometimes weeds out the lower priority changes.

For very large scale projects, a Project Change Committee (composed of the project sponsor, the project leader and other stakeholders) can analyse the proposed changes and decide whether or not to incorporate them and in what priority.

When considering changes to the project, team members may refer to the priorities recorded in an earlier stage of the process and look at how that change will affect all the other decisions that were made up to that point and in the future. The changes could span budget, project features, or any other feature—and might well lead to a project going off the rails.

Meetings may not be necessary. A less formal process can be a change requisition form, completed by the team member suggesting the change, which details the business case for the change, for submission to the project leader. In addition to the rationale for the change, the form should include an impact analysis with an estimation of the costs and time associated with the change. That will help the team decide whether or not the proposed change is high or low priority.

Proposals for smaller scale changes can be handled with a change impact assessment matrix. The matrix helps the project team understand the effects of changes on the project.

In this simple example of a change impact assessment matrix, the team examines each change proposed or needed in the light of the impact on schedule, cost, final deliverable acceptance criteria (or performance) and risk. (Of course, a more complex change might require additional impact categories.) Then using the project priorities identified in the project agreement, the team specifies the priority of the proposed change as a top priority, medium priority or low priority with a simple one to three scale. (Please note that using the project priorities in the project agreement as a guide keeps everyone honest). The effect ranking ranges between –5 and +5, with –5 representing the worst-case scenario and +5 the best case scenario, with zero representing no impact. Add the priority and effect figures for the schedule, cost, performance and risk categories and enter them in their respective lines in the total column. Finally, add up the numbers in the total column to consider and that will help you evaluate whether the change is worth making.

Freeze the project or relaunch

At some point, the project must proceed along the planned lines or it will be unrecognisable. Set a deadline after which no changes will be accepted and stick to it. A well planned process, with all stakeholders represented and informed of the deadline, will go a long way to keeping a project on time, on target, and on budget. The earlier you “freeze” the design of the product or service, including the set of features, the faster the project will move; you can include future feature ideas as upgrade possibilities for later versions of the product or service.

However when faced with a major change, or a high number of changes over a short time, it is better to close out the project and start again as that project may not have any internal support, or does not satisfy its business case, its project agreement or its customers and stakeholders.

In sum, change is inevitable and it can be your servant, not your master. Advance planning, good communication, being specific and having good processes can go a long way to make sure every project change is a meaningful improvement and not busywork. In that case, change becomes a powerful tool in your success in the coming year.

The author is CEO of Cheetah Learning LLC (www.cheetahlearning.com), a PMI Registered Education Provider. She has been designing and teaching accelerated learning programmes for business for nearly 30 years.