Managing Scope Creep: An Ounce of Prevention

Project managers often speak of "managing" scope creep, which begs the question: "Shouldn't we be trying to eliminate it instead?"

To answer that question, we should first consider whether scope creep is actually avoidable in the first place. And if it is, do we really want to "avoid" it altogether? After all, many innovative products and solutions were developed because of - not in spite of - scope creep. Apple's former chairman, Steve Jobs, was known to tell his engineers that a product is not finished until it ships. This undoubtedly frustrated everyone involved in the project, since they knew their work might be un-done or re-done at any point along the way. But who can argue when the ultimate product goes on to change the world?

Perfection is rarely if ever achieved, and certainly not on the first try. Indeed, some degree of scope creep would seem to fit within the entire notion of progressive elaboration. We often must go through various iterations when developing a solution, especially in more technical fields.

The definitions for scope creep vary depending on who you ask. Some say scope creep is any deviation from the established project plans and baselines. Others might say it is uncontrolled or unapproved changes made during the project. Still others might suggest that scope creep only occurs when these changes cause the schedule or budget to slip.

The first definition seems too rigid - we must have the ability to adapt to circumstances, even if it involves tweaking our plans. The other two characterizations seem more meaningful. After all, no project manager should allow unapproved changes to occur, even if they might benefit the project. And we certainly must do all we can to adhere to the schedule and budget.

So our first step should be to define exactly what we seek to avoid. For purposes of this article, "scope creep" will include uncontrolled or unapproved change, as well as change that adversely affects the established schedule and budget.

Now that we have more clearly established our goal, we must identify the various project areas where scope creep arises, and take steps on the front end to help ensure we ultimately stick to the plan.

Identifying Stakeholders and Collecting Requirements

We all know by now how critical it is to accurately identify and involve stakeholders in the creation of project plans and designs. But many failures occur because this gets done too late in the day. For example, designing a business solution before all end users have offered input often results in changed plans and specifications. After all, the end users have different needs for the solution, depending on their roles. We must actively engage these users - and all other relevant stakeholders - early in the project planning process.

But this should not be a one-time affair. Stakeholders must weigh in at various points during the project planning process. First and foremost, they must provide the requirements, which outline the features and functionality we need to deliver. Gathering every stakeholder's requirements at the outset puts us in a great starting position, but that is just the first step of a long and important process.

If you ever managed a project where every stakeholder agreed on all requirements, and how to prioritize them, consider yourself very lucky. This rarely happens, and as the project manager you will find yourself mediating many disputes in this arena. After all, we must put boundaries on the project work if we ever hope to deliver on time and on budget. So we must identify and resolve these stakeholder conflicts early on. It won't always be easy, especially when dealing with strong personalities, but the project's success depends on it.

How you resolve the stakeholder conflicts will vary in each situation, but in every case you absolutely must document each stakeholder's approval of the end result. Perhaps that seems too optimistic - after all some stakeholders will not get their way and won't want to provide their "approval." In such cases, obtain their "acknowledgement" instead. Whatever you call it, get them to sign their name to the Requirements Documentation. They may be unhappy, but they can't later say they were not part of the process.

Another important thing to remember here is the need for detail. Scope creep often occurs because the project team started with vague requirements. Drill down to the fine details, understand and document why this requirement is needed, trace the requirement back to a particular business segment or stakeholder, identify any requirements which seem to conflict with, or perhaps overlap with, other requirements and resolve these issues. Simply put, don't move on until your requirements documentation is absolutely air tight.

Defining Your Scope

You have now created a set of very detailed requirements, and they have been properly acknowledged. Next you must translate these requirements into an actual deliverable.

Some project managers might simply hand over the requirements to the design experts and let them do their work, but this is just asking for trouble. Just as your stakeholders were closely involved in articulating the requirements, so too must they be involved in converting those requirements to a tangible outcome. Expect some more conflict here. Some requirements may have to get cut, while others still may have to be added in order to arrive at the ultimate design. Compromises and trade-offs will often be made again here, and you must closely orchestrate and mediate the process.

Your completed scope statement will serve as the guiding light for all project work. It describes in detail what the deliverable will be, and all the work that will be done to achieve it. Just as importantly, the scope statement outlines what work will not be done, and what the deliverable will not include. Spend some time documenting these exclusions in detail, as it will serve you well later in the project. Finally, remember to have the key stakeholders sign off on or formally acknowledge the scope statement as well. This won't necessarily save you from being approached later in the project by stakeholders wanting to add or change product features, however, it will place you in a much better position to handle these issues.

Managing Change Requests

A change request is just that - a request. You may become inundated with them in certain projects, particularly if you did not properly engage the key stakeholder during project planning. Your job is not to accommodate every request for change, but you must oversee the process and this starts with having the proper procedures clearly set forth.

Every project management plan should have detailed change control procedures which govern, among other things, how a change is requested, who can approve various types of change, the timeline for doing so, etc. We know that some change is inevitable, but we want to avoid uncontrolled change. So have a clear plan set forth and be prepared to follow it to the letter. Some changes seem so minor as to not fall within the integrated change control parameters, but remember, small changes often lead to much bigger changes down the road. Be a stickler here.

Handling Procurements

Procurement management does not often come up in conversations about scope creep, but if you are relying upon outside people or organizations to perform important project tasks, you should have this in mind. Many projects can go awry because of a lack of understanding or communication between the project team and outside personnel performing important project work.

Consider holding kick off meetings with these external people or organizations that are working for you. Have they reviewed and acknowledged the scope statement and requirements documentation? They are stakeholders after all, so we need to make sure we are all on the same page.

After ensuring a common understanding of the project work, reach out to these people periodically to ensure what they are doing truly aligns with what you need them to be doing. Use procurement audits if and when necessary to actually inspect their operations. You must also confirm a common understanding exists with regard to the change control procedures.

Conclusion

Managing scope creep will be a critical part of every project manager's success, and may be one of the most challenging aspects of the overall effort. The key is to understand where things are likely to go awry, and get out ahead of the issue. Take a precautionary approach, as opposed to a reactionary one, and your projects will run much more smoothly.