Oh, would that he was so easy to identify.  Stealthily creeping through our projects, leaving as little trace as possible, the scope creep is definitely one of the major villains of our project stories.  Amazingly, he’s easy to spot IF (and it’s a very big IF) we have a clear baseline for our projects.  There are three keys to not only spot him, but to keep him from skulking around our projects and causing havoc. The three keys? The Baseline, The Baseline Tolerance, The “Glad To!”

The Baseline

As a former Earned Value Professional (as certified by the Association for the Advancement of Cost Engineering International-AACEI), I hear “baseline” and tend to think what you might think.  I think of cost and time. That’s insidious.  Scope baselines go so much further than just cost and time, but because it’s hard to clearly state a requirements baseline, that side of the triple constraint is often overlooked in baseline conversations.  What’s the best evidence of a requirements baseline?  The scope statement and the decomposition thereof.  (I didn’t say the WBS, as the Agile universe still has its decomposition, but it’s the project backlog).

If you don’t have those documents, you have truly invited the scope creep to set up housekeeping on your project.  But there’s good news!  If you don’t have those documents because no one took the initiative to write them, it’s an opportunity.  You can write them.  And if you get them wrong (as declared by an executive or a customer), you get to win the day with the follow-up question: If this statement is wrong, how should it be rendered right?  Get or create the answer to that question just once, and the scope creep begins to fade away.

Congratulations!  You have a scope statement.  Hopefully, you understand it because you had a serious hand in writing it.  You have a breakdown of the component elements of the scope statement, and you can now wrap your arms around the project requirements.

The Baseline Tolerance

With that information in hand, you can now set the limits for in and out of scope.  If you had someone painting a room and you realized that you’d like to have a shelf that matches the paint job on the room, would painting the shelf be “in scope” or “out of scope”?  The original scope statement said, “Paint the room”, with no reference to ancillary attachments.  But painting the shelf would likely take only minutes for a skilled contractor. The contractor says, “Glad to!” (We’ll get to that in a moment).  

Now YOU are the scope creep.  You generated an unplanned, undocumented, unauthorized element of work that is found nowhere in the original documents.  But it’s a tiny thing.  It’s so small.  Chasing it down with a mountain of paperwork and change control board meetings would be silly.  So where do changes go from being small, insignificant things to the problems that they ultimately may become?

That’s a line that you and the project team need to draw. It’s easy to draw when there’s time or cost associated with it (e.g., anything that consumes more than half a resource-day or the cost thereof). But when the time and cost seem insignificant, ask the broader question: Does it truly serve the original project baseline? For the same painting project, suppose the customer asked the painting crew to spend part of their day washing a car. Ridiculous!  No.  That’s simple.  But suppose the customer asked the painting crew to spend an hour with a professional photographer in front of the building to highlight their work? It seems like a nice idea. It’s self-promotional. It’s low level of effort. It’s evil. It’s the scope creep.

As project managers, we should never give our effort away. If there’s something you can get in trade for seemingly innocuous scope creep, fine.  But document what you’re giving and what you’re getting.  By declaring any small change as a change, the project organization wins.  You win.  Your team wins. The scope creep loses.

Glad To!

The scope creep has friends. And you are probably connected to them on LinkedIn or other social media. These people are often referred to as “pleasers.” They are individuals who studiously avoid conflict and work diligently to be liked. Want a little freebie on your project? Go to the pleasers. They’re hanging around Starbucks with the Scope Creep.  They all want to like and be liked.  Your job? Keep them in check.  In the Agile environment, they expose themselves at the daily scrum.  They bask in the glory of their supposed helpfulness.

Can they be stopped?

YES! And it doesn’t take a firm boot in the buttocks. It takes praise and glory for every time they just say “no.” When a team member explains that she put the latest customer request on hold until she vetted it with the team, this is a cause for celebration. When she says she offered the customer a change order form, tears should well up in our eyes as we applaud such an accomplishment. If you lay out the baseline, set some baseline tolerances for added requirements, and shut down the folks with an innate habit of telling the customer: We’d be glad to, everyone wins. Eventually the scope creep disappears or fades into the high grass.

Carl Pritchard, PMI-RMP, PMP is a project management trainer of the highest order, presenting classes live and on-line for clients across the country. He’s the author of ten books, and is considered the “fun guy” of risk and project management. He’s hiding out in the high grass of western Maryland with his lovely wife, Nancy and dog, Mocha. Questions or comments? Carl@Carlpritchard.com OR 301-606-6519