Scope Creep

You’ve been through the RFP process, refined your SOW and have finished contracting to start your new project.

A few months later, you think everything is going fine until you get a call.

It’s then you find out that, “unfortunately, this is going to take a lot more than we initially thought.” Cue an increase in pricing and scope to give you the ultimate business betrayal.

A Look in the Mirror

Don’t get me wrong, even the sourcing can inadvertently add to the scope creep issue.

But typically, we shouldn’t be pushing the supplier to a point where they have to make up money on the back end. Negotiations should be based on market research and information to know what potential profit margin the company is making.

And if we are using a demand-management technique, it should be agreed upon with the business. It doesn’t make sense to cut scope if you are going to add it back later. It completely defeats the purpose.

I’m not saying a sourcing person hasn’t screwed this up once or twice.  But, if they are doing their job properly, they shouldn’t be the source of the problem.

Click Here to Learn More about Ms Category Management – Dana Small

When you are your own worst enemy.

That’s right. We shouldn’t be so quick to point the finger at a supplier or vendor, either.

There are plenty of times I’ve heard the complaint, only to find out it’s because the team added ten new features, shortened the timeline, or some other counterproductive tactic that ends up damaging their project.

Why does this happen? Typically it’s because the project hasn’t been thought through and vetted through all the right resources. Because if it had, the scope of the project, including resources and requirements, would have been nailed down from the beginning.

You could argue that you can’t always predict changes from management, team members, etc. But you can plan for them to happen, and put a buffer into the project.

You know there’s almost always a black swan issue or two that will arise should be status quo. Under promising and over-delivering is still better than the alternative.

This also can happen when certain people, not to name names – ahem, try to squeeze the supplier for free work — thinking that they’ve handed them enough business already, that it’s wholly justified.

What’s a free 8 hour workday on a million-dollar piece of business, tends to be the logic.  But would you feel the same if your boss asked you to work for free on the weekend? I doubt it.

But what if you’ve clearly defined your project, the scope, detailed out the needs and timelines (with a buffer of course), and you still get that dreaded call? Well, then that’s a different story.

Lying in Wait

There are plenty of times where there is a legitimate reason for scope creep. So that’s not what I’m focusing on. I’m talking about the times where it’s not warranted. Things like…

• Making up for lost profit on other projects
• Saying you have the capabilities (when you don’t)
• Inattention to detail on project needs/timelines
• Because it’s a corporation, and they can afford it
• Because the customer is a pain in the ass
• To get the customer to terminate the agreement
• Mismanagement of time

Most of these aren’t business partners you want to keep. So if you suspect this is happening, it’s best to include sourcing for an SRM review.

Tips to Manage Scope Creep

• Ensure that you have a clear and detailed scope with milestone payments
• Make sure you complete reference checks on suppliers’ capabilities
• Involve all stakeholders to review SOW prior to timeline finalization
• Build in a project buffer (timeline, pricing, etc.)
• Involve your sourcing partner in a discussion regarding changes/pricing
• Have a termination for convenience clause in your contract
• When all else fails pause payment and the project until an agreement can be made

Scope creep can always be managed with an iron fist (i.e. you outright refuse to pay any additional costs). But if you believe your business partner values your relationship as much as you do, you should make all efforts to resolve it prior to slamming your fists on the table and potentially ruining any further projects.

The Standish Group’s CHAOS Summary 2009 found that:

Only 32% of all projects were successful, meaning delivered on time, on budget, with required features and functions

Villanova University Article Link