.png)
Scope (from the Greek skopos = target, aim) is one of the most difficult things to manage in a project, and classic Project Management 101 teaches you that scope creep is every Project Manager’s nemesis.
One thing is certain about scope: it will change
Yet thinking (hoping?) your project scope is set in stone and will remain unchanged is unrealistic. No matter how much time you spend upfront defining your scope: things will change. This is not to suggest you shouldn’t define your scope: it is an essential starting block to any project, but what you have to get right is the core target: the key things that your project is ultimately set out to deliver and achieve. The details of the final result and of how you get to it are different questions that need to allow for flexibility (or as it is now customary to call it: agility).
Uncertainty is an inherent characteristic of what projects are about: bringing something new to life. And when you deal with something new (whether it’s a product or a service) , there’s no way you can know exactly how it will actually turn out – or can predict all the hurdles that will stand in your way.
Change your course, not your core target
Don’t fear or try to avoid scope creep at all costs (a project with no scope change would worry me and tell me no one cares), but be prepared to anticipate and deal with change. Keep your end goals in sight, but be ready, in some occasions, to alter the way you reach them. People (your project team, stakeholders, sponsor, you…) learn throughout a project, and as they gain knowledge, their take on what they thought they needed or should do might also evolve. Of course you don’t want to go down the path of changing directions all the time and taking on every change request, and as a PM, you need to have a solid change management process in place. But to put it simply, when you’re getting scope change requests, you need to answer two questions:
Will this change truly serve the end result (what if we do it?)?
Will we fail if this change doesn’t happen (what if we don’t do it)?
If you (or your team, or your sponsor, or anyone who asked for the change) can’t answer “yes” to these questions, then don’t change your scope.
The exception to the rule: accepting changes to make people happy
There are occasions when it’s actually okay to make a change that is non-essential just because it keeps people happy (not a bad outcome in itself). If you have a key stakeholder who has her heart really set on getting something that wasn’t originally planned, and that change doesn’t throw your budget or timeline (or other requirements) out of the window, see if there’s room to say yes. If you can help this person achieve what they need without compromising your project, you’ll get their support back. Change is also about give and take.
Up close, targets may appear a little different to what you imagined from afar
The end product or service you are delivering as an outcome of your project may sometimes seem a world away from what you initially took on, other times surprisingly close to what was envisioned. Think about the projects you have done before; what do you remember: the scope changes that crept up or the end result you delivered?