What is scope creep?
Scope creep feels like a thorn in my side, especially when it comes in the form of the dreaded “90% syndrome,” where it contributes to delaying project closure right at the end. “Can’t we just add this one last thing? Pretty please?”
The Project Management Institute (PMI) defines scope creep as “The uncontrolled expansion to product or project scope without adjustments to time, cost, and resources.” So, adding requirements or activities to a project isn’t an issue if there’s time, money, and resources, right? Maybe. But there’s another all-important consideration: stakeholder agreement. That’s where competing or conflicting incentives, priorities, organizational politics, and other human elements can make changing the project scope difficult.
Why does it happen?
Most stakeholders can agree that justifiable reasons for scope change include environmental factors, like budget cuts or policy changes, and requirements that were simply overlooked during project planning. And sometimes, an executive stakeholder or project sponsor with ultimate authority may insist on a scope change, leaving the project manager with no choice. But it’s often the case that stakeholders are divided on changing the scope. For example, the project manager and project team usually want to close the project on schedule, while other stakeholders without the same incentives may not see the consequences of adding requirements as the project goes along.
There are both positive and negative forces that influence requests to change the project scope. Positive forces include things like desire, convenience, and satisfaction. A stakeholder may want an extra feature built into the widget or more mouse clicks eliminated from the software interface. Negative forces include fear and anxiety. A stakeholder may be afraid of project closure, believing they will lose the knowledge and support of the project team, leaving them holding the bag of project deliverables. Or stakeholders may fear the project will cause unwanted changes in the organization, so they request changes to extend it and delay the inevitable.
So how do we deal with it?
Regardless of the reason, it’s the project manager’s responsibility to balance needs, allay fears, and negotiate a resolution each time a scope change is proposed. Understanding the motivations for a scope change request can help guide the resolution to one of four possibilities:
Accept the change.
Modify and accept the change.
Refuse the change.
Take the change offline.
So let’s look at the tools we have available to assist and guide us.
Beyond the definition of scope creep, the PMI goes on to say that “Change is inevitable; therefore, some type of change control process is mandatory for every project.” In other words, the change control portion of your project plan is key to keeping things on track. If there’s a defined process to handle change requests that is agreed at the project outset, it can relieve a lot of the burden from stakeholders. It assures everyone that all change requests are considered in the same way and are handled fairly and responsibly.
It's important to design the process with your project team, and ensure that all stakeholders read and agree to the entire project plan before you begin. Your goal is to design a process that isn’t cumbersome, but is rigorous enough to ensure responsible and fair consideration of requests, while discouraging frivolous requests. The process should lead you to one of the first three outcomes above.
Your change control process will support you through project closure. However, as closure approaches there is increased potential for change requests and reluctance to close when the last stakeholder desires and fears surface.
Project EMC2 can help
Fortunately, Project EMC2 has a couple of tools to help you through last-minute change requests. The first is a standard report entitled “Closure Consent Request.” Announcing that a project is closing without advanced notice can come as a shock to some stakeholders, especially those who have shown little interest in the project until now, when the deliverables will most likely have their full impact. Providing early communications is key to smoothing the process. The report shows the status of the project, with summaries of all activities, requirements, risks, and issues. The wording of the report can be customized as appropriate for the project. In fact, you may not need stakeholder consent to close the project at all, but you’ll still want to provide advance notice.
The second tool is the closure readiness test. At closure, Project EMC2 performs error checks to ensure that all requirements are met, all the activities are complete, and all the project risks and issues are resolved. It may seem straight forward, but you’ll want to ensure that all the boxes are ticked. In fact, Project EMC2 won’t let you close the project until all critical closure errors have been addressed. This will give you confidence that the project is indeed ready to close.
Finally, what about those lingering requests that really shouldn’t be included in the project or prevent closure? You don’t want to leave a stakeholder unsatisfied, so how do you address their remaining concerns? That’s where I’ve had some success exercising the last option: Take the change request offline. In most IT organizations, there is a ticketing system that tracks and manages service requests. If the change request is small and manageable, I offer to create a service request ticket for the stakeholder and promise that the work will get done. This assures the stakeholder that the request will be tracked and fulfilled, without the need to hold up the project.
If the change request is more lengthy or costly, I might establish a memo of understanding with the stakeholder, which may include interdepartmental exchange of funds or other resources. And if the request is even more complex, I insist on initiating a new project to address their needs. I rarely need to exercise this last option, but having a dependable path to negotiate in these situations relieves a lot of stress.