Change of scope. I’m sure you’ve heard that phrase before. In some companies, it’s ubiquitous. In fact, some project managers love scope changes because they offer opportunities to adjust the schedule. The sinister sister of scope changes is “scope creep”.
What is scope creep? It’s a risk faced by projects that try to lock down the business requirements at the outset of a project. Once the requirements are locked, any request that results in additional work causes scope creep. Every time the business stakeholders change a requirement or add a new one the project manager yells “change in scope” to squeeze more time and money out of the business.
Unmanaged scope creep is bad because if work is added without extending the schedule or allocating additional people, the risk of failure increases. In theory, if scope is properly managed, it cannot creep — approved changes with associated impact assessments don’t increase risk.
You stay on your side. I’ll stay on mine.
Unfortunately, scope often becomes a kind of demilitarized zone between the business and development teams. The business team encroaches into the DMZ in search of capability they need but may have omitted. The development team fights back claiming the requested capability is additional work requiring a change request and schedule/budget increases. Each side digs in to protect its interests.
Agile software development projects don’t have to deal with scope creep because they let scope float. It’s a fallacy to believe that scope can be locked down on any enterprise-scale project. It’s impossible. Business people cannot predict the future. Their needs are constantly evolving and growing. What they need today — right now — will not be the same as what they’ll need in a few weeks or months.
Gold plating only makes it worse.
Some businesses attack the prediction issue by piling on software features in anticipation of what their needs will be in the future. That’s called gold plating and it’s equally bad. Gold plating the requirements results in bloated software that takes longer to deliver and is harder to use. Worst of all, it’s unlikely to meet the predicted needs of a rapidly growing business.
The scope of an enterprise-scale project cannot be fully determined and locked down at the outset. Any attempt to do so is foolhardy. It’s time to abandon the concept of scope creep. If scope isn’t locked down, it can’t creep. We also eliminate the need for change control and all the paperwork and review cycles that go with it.
Schedule and budget can and should be tightly controlled. Go ahead. Establish an end date (with some intermediate milestones). Allocate funding with a not-to-exceed dollar figure. Let scope float as needed to hit the date and meet the budget.
It’s less combative and it’s much easier to manage.