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.”1
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:
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