Learn To Embrace Scope Creep

We recognize the term “scope creep” as the developers’ term for the firestorm that erupts late in the game when the people who said they wanted X now say they want X+1 and then X+2 or even Y.

It happens in virtually every project. So why is everyone surprised and unprepared when it happens?

It’s critical to the success of your project to expect it and prepare for it. Set up your system to formally, quickly and respectfully consider and handle requests for changes in the specs.

Any right-thinking person knows users and people close to them are gonna be smarter about what’s really needed after you start working on the thing.  So be ready to delay the release date if it’s necessary to accommodate newly-found must-haves.

Why push blindly to make the original delivery date when you’ve learned X isn’t what anybody wants anymore?

December 16 was the date we were supposed to release the new system. At our Friday morning stand-up staff meeting, I asked everyone “Are we gonna make December 16?” The young woman in front responded “Don’t look at me. I’m done with my stuff!” I said that was good, but noted that her part was in the front part of the project, and not likely to be hanging out at the end close to the deadline anyway, and suggested that maybe the folks responsible for the later stuff – like acceptance testing – might be able to use some help from the “earlier people” for the final push.

The take-home messages:

Have a process in place to consider changes to the specs as and when they come.

Make sure from the start that those with responsibility for the front part of the project are committed to helping the folks who have the back part get their jobs done, and vice versa. Through repeated heroic actions, the back-end workers may have unwittingly creating the impression of an expanded capacity. Clear communications and a shared familiarity about what it really takes to get these jobs done in all phases of the project will go a long way to managing expectations and getting the highest-priority capabilities into each release.

Any manager of a development team can play the guardian-protector protecting her staff from too many demands, and say “No” to a change request. But “No” in this context may be based upon an unreasonable assumption that the requestor knew exactly what was needed at the outset, and that your role is to either either build it — exactly as requested — or refuse to engage at all.

The manager of a development team’s job is to educate users and those close to them as to what’s possible, and to help them get the best of what they want, within the constraints of the resources available.