Best laid plans: how to handle mid-project changes

Things don’t always go to plan, do they? With all the planning in the world, sometimes requirements can change part way through the project and we pride ourselves on being responsive to that. To be honest, we see it alot.

We like to hypothetically discuss this situation at the start of a project, and think about how we might want to handle necessary changes should they crop up. And we’ve found that, broadly speaking, there are three approaches to a mid-project change to scope:

Stick to the plan but create a wishlist for later

This means that anything new or extra is deferred to a wishlist for after the initial project. We’ll keep track of all potential new requirements and revisit them once the original project is complete – on time and on budget, as originally agreed.

Descope some original requirements and prioritise new ones

In our original project we may have discussed, scoped, and budgeted for some features that although are worthy, are not essential and may be good candidates to descope should something more important come up during the project. Swapping features like this will allow us to stick more closely to the original project budget and timeframe.

Make case-by-case feature changes based on individual time and cost estimates

This approach works best for more flexible projects where requirements aren’t 100% defined at kick-off. We can scope out all the options for you as we go and then, armed with all the information you need, you can decide if, what and when to integrate them into the original plan. It will almost certainly result in revisions to the original timeline and budget, but, if circumstances allow it can be a great way to manage the project.

It may be that your project doesn’t fit neatly into one of these three options. In fact, it probably won’t. But rest assured that when that late night email from your CEO who has just had a moment of epiphany drops into your inbox and totally derails your carefully laid plans, we’ve got your back.