Scope Creep or Death by a Thousand Cuts

Imagine this scenario: You and your significant other decide to build a house. Let’s say it’s a split-level with two bedrooms, two bathrooms, a one-car garage, no frills. And so you hire an architect and she gets to work on a blueprint. And after she’s been building the house for a couple of months, you approach her and tell her you want to make some changes. Specifically you tell her you now want three bedrooms, a two-car garage, a deck and – just for fun – an in-ground pool. And she says, “No problem. I will build the house within the same schedule for the same budget with no added risk. Don’t worry about it.”

Sound crazy? Well, it is. And guess what? We do pretty much exactly this same thing every day on our projects. For ‘architect’, substitute project manager and for ‘you and significant other’ substitute stakeholder/customer. What you, the homeowner have done is increase scope. And significantly. What the architect has done is to agree to do the impossible. Why? Perhaps she’s concerned that maybe you’ll find another architect or you won’t recommend her to someone else. Maybe she succumbed to pressure. Perhaps she wants to be a “nice guy.”

But in reality, no architect, at least none that I’ve ever met, would do this. If the house wasn’t too far along, a change order would be issued and new plans, including budget, would be produced and executed to. Failing to perform rigorous change control is what we call scope creep, which the Project Management Body of Knowledge, defines as “the uncontrolled expansion to product or project scope without adjustments to time, cost and resources.”¹

So if the architect won’t do this why do we? (I know we do because as a consultant and instructor, this is the number one problem I see everywhere). I believe we do it for a number of reasons:

1. The scope was never really understood in the first place. The customer sort of knew what he wanted and so consequently we sort of knew how to provide it to him. Scope begins with requirements and so if the customer cannot articulate his requirements (“I want a house kind of like the one down the street, only bigger”), it is impossible for us to give him what he wants.
2. If the scope *is* understood, we have no real mechanism in place for when the inevitable changes are requested. And so we do everything that everybody asks in more or less random order. And so minus this change control system (and change control board), we are barely above chaos and frequently rearranging the deck chairs on our own private Titanic.
3. We don’t know how to push back. Yes, despite the possible existence of the above two factors, in many environments, the stakeholder that yells loud enough always gets the changes he wants anyway. And so canceled vacations, overtime, last-minute heroics and attendant burnout. Ten pounds of project in a five pound bag. And then everybody says, “Well it killed everybody but we got what we wanted.” But having gone through that once, why would you ever want to go through it again?

There are likely other reasons that play into this phenomenon but for me, item number three overrides the others. The stakeholder says, basically, “If you don’t make the changes I want then you don’t love me (or my project.)” The good project manager says no, not allowing changes in a haphazard fashion demonstrates exactly that I do love the project. And want to protect it. And so therefore the good PM enforces good scope control and good change control and pulls the stakeholders – perhaps kicking and screaming – up a level in project maturity. Proving that just because we’ve always done it that way doesn’t mean that’s the way we should continue to do it.

And if the customer says “Why can’t we do it like we always did, “you can always say – politely, of course – “And how has that worked out for us in the past?”

1. Project Management Body of Knowledge, Fifth Edition, p. 562. PMI