All projects change. It’s a fact of life, but too many changes can lead to a project failing. These changes constitute scope creep, and you need to deal with it. So, it’s vital for you and your software partner to agree on how to manage the changes that will undoubtedly occur.

What is Scope Creep?

Scope creep is caused by changes in parameters and deliverables. It affects budgets and deadlines and is one of the major causes of project failure – along with delays and poor user adoption. So how do you prevent it from happening in the first place?

Any number of factors can cause scope creep. From infrastructure and funding changes to licensing issues and changes in legislature. New requirements present themselves along with subtle changes to existing requirements. Together they expand the boundaries of the original design. It’s important to distinguish between legitimate changes brought on by bugs, for example, where something doesn’t work and an alternative must be implemented, and feature requests which are in addition to the agreed plan. Feature requests create scope creep.

Small changes are to be expected and are usually accommodated without being a problem. But saying yes to every request can be counterproductive for both the client and the partner. You and your provider need to agree from the outset how to handle these changes.

We have known many companies who were unable to escape restrictive contracts with their software partner. Some were locked in to change limitations that required expense every time they requested a small change. As a result, things got uncomfortable and pricy very quickly. It is important to agree, at the very start the level of flexibility you will be permitted with your chosen partner.

How to Avoid Scope Creep

Be clear from the start. Make sure everyone involved in the project is clear about the project and what it sets out to achieve. A good partner will talk you through all the deliverables and parameters and provide you with a statement of work. This is a detailed catalogue of requirements, which you should agree and sign off. It ensures everyone is aware of what is going to be delivered. Make sure you understand it fully and tell your partner if you don’t. If you fail to address any ambiguities or assumptions at this stage, there is a good chance they will come back to bite you later on in the project and by then they will be harder to deal with.

Change Management

Systems naturally evolve as people become familiar with what they can do and how new features can be leveraged for other areas of your business. There is always room for change and additional requirements, but they need to be prioritised; or perhaps the timeline needs extending to accommodate the extra work involved. Discuss with your software partner how they will handle any changes, should they arise (which they will).

Remember, if the worst starts to happen, it’s not the end of the project.

Find out more about how to save a failing D365 project.