This blog post covers it as it occurs outside of agile development. Managing scope creep inside the Agile Framework will be a matter of a future blog post.
Scope Creep happens. It’s a reality. The PMI calls it “progressive elaboration” as it recognizes that the stakeholder developing the vision for the product (usually the Client or Product manager) doesn’t know what they want and they don’t realize that they don’t know it until it’s in front of them. It can be an effective tool to ensure the client has realistic expectations about what’s getting delivered as the evolved expectations are based on what is getting built so far.
The fact they don’t have that clear vision until something is in front of them can be harnessed by offering a demo with limited functionality as the feature is getting developed, part way through the development cycle, with time and budget to account for refinement of the requirements and fulfilling the scope.
Scope creep can also be a way to continue a project that provides decent income for the company, or to make up for a loss on a previous build or project for that client.
All these things seem like good things! Why does Scope Creep have such a bad rap then? A few reasons:
- I want it free!
Sometimes the client expects that the change in requirements is insignificant- and while it could seem like a minor tweak to them, once you perform an AOM (Assessment of Magnitude- an estimate of the effort to perform a task) it is a significant amount of time and effort involved in it. Stakeholder satisfaction is always critical to a project success, so it could be a delicate balance of affecting the change required to satisfy the stakeholder, versus ensuring the project is properly budgeted (by either time or money) for the work involved.
- I want it different!
Changes which can seem reasonable tweaks to the client can be huge changes to the team. Part of the issue with this expectation is when they have the choice at the outset when the difference is easily accommodated. Later, the client could have the expectations that changing their minds could be a simple matter, but now that the foundation is in place- it’s really not.
Let’s use the analogy of making a dinner for the client, and the client says they want chicken have a budget of $25 for ingredients and want it served for 7pm. No problem! You get the ingredients and are positive on your budget, and are on schedule for seven. You have prepped the veggies and potatoes and have just shoved the seasoned chicken into the oven when the client pops their head in the kitchen at 6:30 and says “Oops! I actually want Pasta!” Well that scope change means the client won’t be happy if you serve chicken and if you acquiesce and serve pasta, they won’t be fed at 7 and you’ll go over budget on ingredients because you need buy the ingredients for pasta.
- Gold Plating
Gold Plating is different from the other because it’s often perpetrated by a member of the internal team instead of exogenous. A team member will include a piece of functionality that is unnecessary, unrequested, undocumented and not paid for. It can be a nasty surprise during UAT.
- I don’t want it anymore
This is sometimes the case with multi-year projects. Budgets get allocated away, markets change quickly precluding the competitive need for that project or making it financially untenable, technologies evolve- any number of reasons out of the control of the client and the producer (or production partners), and sometimes a full stop can mean a huge investment has a zero return. This could lead to lawsuits, crippled companies, any number of very unfortunate conclusions that results in stakeholder satisfaction being at a loss.
The “I don’t want it anymore” scenario is probably the hardest to deal with, but depending on the circumstances is sometimes predictable, so a reallocation of resources can mitigate the loss that results.
Gold Plating is a matter of diligence of communicating and enforcing the processes. This is an expansive topic in itself- a future blog post will cover some of the tools and best practices for enforcing processes, but in this case- reminding the perpetrator why it’s important to exclude features that are ‘off the range’. Depending on the culture of the company it will determine how gentle this reminder is, but I caution against lowering the boom for this- remember- it’s a safe assumption this person was operating in good faith – to better the product or enhance the UX.
Here are some of the tools for dealing with what in my experience are the most common forms of scope creep- which is the expectation to deliver additional features without a change in the deliverable date, or change to budget.
Exercising diligence in the process surrounding a feature change will not only ensure the proper updates to the Requirements and scope document are completed, but send a tacit message to the client that the work involved represents no small effort (You probably wouldn’t be going to the trouble of massive updates if it’s a small tweak). They might have it in their head that their change will be minimal effort involved. Performing an AOM at the outset on the work will determine if this is the case, and if it’s not, and you have a good case that it’s chargeable (Change of requirements as opposed to progressive elaboration), then you need to update documentation including a Change Request (Or the equivalent at your organization) that includes new deliverable dates and costs involved.
If there’s a hard date or hard budget everyone needs to work inside- It doesn’t necessarily mean catastrophe! Reassessment of the Minimal Viable Product (MVP) can mean that the new features get included at the cost of previously planned features that are less valuable by comparison. This swap out is a simple and creative solution that I’ve found is elusive to more junior project managers. It allows everyone to win!
If no features of the MVP can be substituted and all features must be present, including the newly articulated scope, perhaps a second round should be discussed. This is also referred to a Rolling release, and it’s where Round 1 of takes place as scheduled with limited functionality, and subsequently a second round occurs where additional features are released, perhaps to complete the product UX and make the product whole.
Sometimes at product launches you’ll see a beta version being released with great fanfare- with a full version being available a number of weeks or months after- this could be because the public and celebrated product launch was scheduled, and then scope changed to preclude a full completion by the launch date resulting in a rolling feature release.
In closing, Scope creep has a bad reputation, but is it truly deserved? Sure there’s risk it opens up for rancor, but a practiced Project Management hand can swiftly move things from acrimonious to harmonious (Good God that’s a cheesy way to put it) using stakeholder management techniques of never saying “No”, but pushing back on unreasonable requests.
And of course, this is all incredibly relevant in Agile where Progressive Elaboration is one of the trademarks of the Agile Development Model- build, review, assess, requirements. But the prioritization comes in the form of backlog grooming, but that issue again is a matter for a future blog post.