If there is a question, the answer for which most project managers will agree on, it would have to be whether Gold Plating and Scope Creeping are allowed. The mere suggestion that any functionality is sneaked into scope without being officially vetted in would send any project manager into an infinite spin.
I don’t intentionally want to challenge this world view but I want to better understand its underlying premises and, on the way, determine whether the black-and-white view we normally ascribe to this question should be normalized, to allow a meaningful discussion and thus a different conclusion to this question.
Gold Plating and Scope Creep refer to two different project events and outcomes:
Gold Plating is about providing a greater level of quality, beyond the level deemed by the customer as being sufficient. It is thus wasteful as the time and effort spent on this increased functionality could have been spent on other value work.
Scope Creep is about the uncontrolled growth in the project’s scope without complementing this growth with a corresponding change in project resources. So, just to make sure this point is crystal clear, increase in scope due to a proper change management process is NOT an instance of scope creep, as the change process evaluate the impact of these changes on time, cost, quality, etc.
While for many the mere mentioning of Gold Plating or Scope Creep is sufficient to elicit an uncontrollable body convulsion, my own attitude to the two is somewhat less troublesome.
So here’s what I think:
Gold Plating, almost by definition, is wrong, as it is a deliberate use of project resources to produce a product whose specifications were not required, requested or sought by the customer.
Scope Creep, however, represents (or rather – can represent) a situation where a functionality requested by the customer, but was officially left out of the project’s scope – due to perceived time or cost constraints – is added into the scope due to these constraints no longer playing a role.
I am aware that many of my distinguished project management colleagues would consider this an abhorrent thought but I will add here a few more qualifying comments, and sum them up as The Commander’s Intent.
In a 2010 HBR article titled “Manage Uncertainty with Commander’s Intent“, Chad Storlie makes the observation that as part of the approach for managing uncertainty it is crucially important to outline to the team what the intent of the project is and what will a successful mission going to look like. With that in mind, should the plan need to change or unforeseen things occur, the team (given its understanding of what success should look like) will be able to quickly make the necessary adjustments and continue the drive towards the desired destination.
The article brings, as an example, the events taking place during D-Day, where despite serious deviations from rehearsed plans, the troops on the ground were able to re-group and achieve their objectives – clearly resulting from their appreciation of what the end goal is and allowing them to make the necessary improvisations to get the job done.
I’m not really familiar with the history of D-Day but, if I understand Chad’s argument correctly, it seems like the success of the day was NOT a result of implementing a Plan-B or a Plan-C (i.e. invoking the Risk Management Plan). Rather it was a free interpretation of the desired outcomes which allowed the various forces on the ground to make the necessary adjustments, on the fly, and achieve their objectives.
Had the D-Day operation been managed as most IT Projects I’m familiar with, it would have surely ended up being a colossal disaster. To begin with, how many PM’s do you know that would allow their teams to implement ad hoc plans, should the authorized plan hit major stumbling blocks? Surely a detailed change management process would have had to be invoked, examining the new circumstances before obtaining the necessary approvals to implement new plans.
So, let’s go back to the question regarding Scope Creep. Implementing features that are within the desired framework of the Commander’s Intent (i.e. functionality that is understood to be welcomed by the customer, given the statement of intent they helped construct) should not be automatically shunned upon. Provided that a trust exists between the project manager, the project team and the customer it is entirely plausible to see circumstances where unauthorized, but yet – intended – scope is allowed to creep in to the scope of delivery – all with the provision that no adverse time or cost implications are envisaged as a result.
Breath in and think about it!