“I wish there was a business that offered scope creep mediation services. Wouldn’t that be useful!”

I heard this recently from a developer frustrated when their client asked for additional features. It’s a constant dread haunting the projects space in any industry. So what do you do when you’re faced with a client who’s asking for more? How do you balance customer satisfaction with your own budgets/health/wellbeing?

Enter: Business Analyst and/or Project Manager.

There are only two reasons why scope creep becomes an issue:

There was no BA/PM engaged in the project
The BA/PM engaged hasn’t done their job

Too often I see companies devaluing these “peripherals”. IT companies will either trim these in the interest of landing the deal, or a client will push for a better price, only to end up with a project that’s delivered late and over-budget. These roles are crucial to the successful delivery of any project and cannot be under-estimated.

Lesson #1: Ensure you have a capable BA and/or PM to avoid scope creep

If you are a BA/PM, or you’re in a position where one isn’t available and quickly need to mitigate the risk of scope creep lest you end up another statistic, focus on these two items and you should be OK.

1. Document your requirements

If it’s Waterfall, create a thorough detailed design document. Leave no stone unturned. List all assumptions and put in as many sections, pictures, tables, exclusions etc as needed until both parties are satisfied the client’s requirements have been met. Make sure you read this document together and give all parties the opportunity to raise any concerns and clarify any ambiguities that may come up.

If it’s Agile, your first step is to make sure all parties are familiar with this methodology. It’s not enough if just the development team understand it. The client will generally play the Product Owner role and will need to understand what a backlog is, how it works, how user stories should be structured etc. Spend some time establishing the “ground rules” to avoid headaches in the future.

On the note of user stories, you’ll need a solid structure for them. Make sure the following parties are all in agreement with how a story should be written:

Those writing the stories
Those prioritising them
Those building them
Those testing them
Those requesting the functionality

2. Actively manage issues, risks and change requests

There’s a fundamental difference between a risk and an issue: an issue has already occurred; a risk has a probability of occurring. Here are our register templates for risks and issues:

These aren’t “set and forget” artefacts. Create them, run your risk and issue workshops with relevant stakeholders, and review them as required.

Change requests need to be managed with the same level of diligence. Document them in a change request register, scope them based on features, time and cost and agree on which of these three variables is going to suffer in order to get it done. Note that it may be more than one…

One final note: If you’re already knee-deep in it and scope creep has become an issue, it’s usually too late to undo the damage and somebody is going to have to wear the cost. It’s just a question of who. In this scenario the only thing you need to consider is the value of an ongoing relationship vs the value of the scope creep.

If you’re setting up a project and would like more information about how to run a risk workshop, or are half-way through one and concerned there’s going to be some nasty scope creep around the corner contact us at info@theadvicestand.com.au.