{"id":19100,"date":"2021-06-11T00:00:00","date_gmt":"2021-06-11T05:00:00","guid":{"rendered":"https:\/\/blog.planview.com\/project-managers-how-to-deal-with-dreaded-scope-creep\/"},"modified":"2021-06-11T00:00:00","modified_gmt":"2021-06-11T05:00:00","slug":"project-managers-how-to-deal-with-dreaded-scope-creep","status":"publish","type":"post","link":"https:\/\/blog.planview.com\/project-managers-how-to-deal-with-dreaded-scope-creep\/","title":{"rendered":"Project Managers: How to Deal with Dreaded Scope Creep"},"content":{"rendered":"

<\/p>\n

While time-honored business principles are useful, there are exceptions to the rule. For example, sometimes it’s not a good idea to “under-promise and over-deliver.” And while “praising loudly and blaming quietly” is good advice, there are situations where this doesn’t apply.<\/span><\/p>\n

<\/p>\n

And then there’s another slice of wisdom that is so deeply rooted in business thinking, that for many managers and leaders it’s sacrosanct and beyond question: “the customer is always right.” Except, that is, when they aren’t. And few professionals know this better — yet wish they didn’t — than project managers who have gone to <\/span>battle against dreaded scope creep<\/span><\/a>.<\/span><\/p>\n

Scope creep refers to a customer change request — which is typically in the form of a command — that is outside the agreed upon scope, and if carried out would have a materially negative impact on project cost or schedule (and usually both). Or in some cases, such requests may have a minimal or tolerable impact on the project in question, but would adversely affect another project in the portfolio.<\/span><\/p>\n

And so, since scope creep is the enemy, project managers need to deftly prevent it in a manner that not only keeps their projects on-track, but at the same time prevents customers from getting unhappy — or worse, enraged. That’s a difficult juggling act, but thankfully (and mercifully) it’s not impossible. Here’s the game plan:<\/span><\/p>\n

Step 1: Understand the Intention<\/b><\/p>\n

Before screaming out a few not-safe-for-work phrases or seeing if laptops can fly if thrown out the window (hint: they can’t), take a few deep breaths, and strive to learn what the customer is aiming for. It could be mutually enlightening. <\/span><\/p>\n

For example, a customer may casually state that they want an in-development piece of software to conform to a complex security standard that is nowhere to be found in the agreement. It’s the better part of wisdom (and safe blood pressure levels) to have a conversation about this categorically out-of-scope “request,” and ideally, get it off the table as quickly as it arrived. <\/span><\/p>\n

To continue the example, after a conversation the customer may agree that conforming to the security standard is unnecessary, or could be counter-productive if it creates usability or compatibility issues down the road. <\/span><\/p>\n

Step 2: Explain the Consequences<\/b><\/p>\n

Ideally, the conversation described above pulls the plug on potential scope creep to everyone’s satisfaction. But since project management can be less about idealism and more about damage control, it doesn’t always work. Actually, if we’re being brutally honest, it doesn’t often work (but try it anyway).<\/span><\/p>\n

The next step is to clearly and professionally explain to customers that Newton’s Third Law is alive and well in the world of project management: for every action, there is an opposite and equal reaction. Translated into the context of scope creep, this means that customers who insist on seeing their request come to life must understand that “something’s gotta give.” And that something is going to be <\/span>increasing the budget<\/span><\/a>, extending the schedule (and all impacted deliverables and deadlines), reducing or eliminating certain project objectives<\/a>, and so on.<\/span><\/p>\n

Getting customers to accept these consequences isn’t easy. But then again, being a project manager isn’t easy. Using facts and evidence (e.g. different versions of possible schedules, highlighting relevant sections of the initial agreement, etc.) is critical here, as is demonstrating a desire to mitigate the pain. For example, a project manager who knows that their customer is especially cost sensitive can pitch solutions that minimize impact on the budget. Even if the customer (grudgingly) accepts the budget increase, they’ll appreciate that their project manager tried to cushion the blow.<\/span><\/p>\n

Step 3: Document Everything<\/b><\/p>\n

Project managers as a breed prefer doing stuff rather than documenting stuff, which isn’t a bad thing. However, when it comes to capturing and locking down scope creep, documentation is essential. <\/span><\/p>\n

If project managers are too busy to plug in all of the data and details — including accurate notes of all customer conversations and meeting — then delegating (not dumping) this on a qualified team member is the way to go. <\/span><\/p>\n

\n
Increase your business agility with Planview AdaptiveWork’s project management software<\/div>\n
Take a Product Tour<\/a><\/div>\n<\/div>\n

Step 4: Map, Monitor and Manage<\/b><\/p>\n

Once the change request has been officially approved, it needs to be mapped, monitored and managed using <\/span>project management software<\/span><\/a> that:<\/span><\/p>\n