Scope creep is demonised in the world of digital project management; it’s seen as an enemy to or guard against or defeat. I’m not convinced this is the right way to look at it; in fact, we often welcome it in our work. Now, I can hear the sharp intake of breath, but hear me out on this.
To begin, let me clarify:
- I think it’s okay if, throughout a project, new requirements are realised. In fact, it’s okay if we start a digital project and some elements are unknown and unestimated.
- I think it’s fine if some requirements, even those initially considered to be necessary, do not get built because others end up being prioritised above them.
- I also think it’s all right, if, after build begins, some time is spent on experimenting.
And, when I say the above items are okay, I mean that it’s all right for everyone, clients included.
Accepting scope creep as a part of any digital project
We usually start our projects with a discovery stage which allows us to get to grips with the brief. It gives us a chance to research, design and come up with the best solution we can realise, ahead of actually building.
However, if you accept that it’ll never be possible to capture every reasonable requirement at this stage (and that planning to do so would be futile), then it naturally follows that the scope of any project will creep and change a little. We expect backlog items logged as part of discovery to change throughout a digital project.
Instead of worrying about scope creep, I’d rather make sure it’s anticipated and managed by working closely and transparently with the client. In my experience as a Digital Project Manager, this far-sighted view of what’s likely to crop up on the horizon (and planning for it) is one of the most valuable services I can offer to the team around me.
What happens when things overrun?
If the actual time spent on a piece of functionality or story is double or triple the estimate because of late added changes, then we certainly acknowledge that that something is up. Clearly, such a situation isn’t sustainable, and I’m not advocating having zero accountability when it comes to scope changes; it is in no one’s interest to blow a budget and cease production of a site or web app because money runs out.
However, the default reaction to such a situation needn’t be panic or blame apportioning. After all, if we’re part of an effectively managed team that transparently logs what progress has been made, chances are we could all see the overrun coming and understand why it’s happening, even if it is frustrating to be off track.
Stay committed to the client
When this happens, I try to keep in mind that our commitment is to creating the best product for the client, not sticking slavishly to a brief. It’s tempting to see features added at a late stage as blockers to the work you did have planned, or in some way less valuable, but if they make the product better, why shouldn’t they be implemented? If scope creep can help keep our customers happy, why are we trying to defeat it?
Viewed this way, it’s clear that what’s crucial is deciding when to allow a scope to expand, and when to push back. The answer here will vary from project to project, but late changes need to be viewed with fair scrutiny. Dismissing them out of hand runs the risk of delivering a sub-par product, accepting them all will mean you never deliver a product at all.
We subject late scope change requests to a simplified version of the MoSCoW process we apply during discovery, albeit with a few extra restrictions added to reflect the late stage of the project (we’re unlikely to greenlight any new features that would require bringing in specialist contractors, for example).
Naturally, not every late idea will add enough value to make it worth dropping other features, so, as a compromise, we like to track late feature requests as a sort of future product roadmap. Just because things aren’t possible now (due to time or budget constraints) that doesn’t mean you won’t want to introduce these later.
Scope growth, anybody?
If the customer’s goals are put first and become our own, if the whole team is collaborating, and there are frequent opportunities to test, and for sharing feedback then we’ll create a great product.
Perhaps we’ve got the terminology wrong? Maybe we could bin the term scope creep and instead start speaking of scope growth? Either way, I don’t think it’s anything to be scared of.
The post Scope creep (and why it’s not as evil as you think) appeared first on Browser London.
Top comments (0)