How To Manage Constantly Changing Requirements

This is an extract from Project Pain Reliever. I contributed two chapters.

Are your project requirements constantly changing? Are you expected to get something done without really knowing what it is that you are supposed to be doing?

If you find yourself in a similar situation, here’s what you can do about it.

Note: This article assumes you are working in a predictive environment. If you are using agile methodologies, you have other tools available to you to manage changes in requirements because flexing the scope of the project is very much built into the agile way of working.

However, that’s not the case for people who are in a more predictive environment without the structures and culture of agile to support project delivery.

What should I do?

When the requirements keep changing, it’s important to nail them down as quickly as possible to get back on track, even if you can’t see that far into the future. Work on what you can manage, and put a process in place for adapting to future changes.

Establish where you are now and how you will handle changes when something else changes – because it will!

1. Clear set of requirements

Go back to your scope document, terms of reference, business case or project charter. What is this project trying to achieve? 

This forms the underpinning structure of your requirements. List all the requirements you currently have on the project and make sure they all tie back to the project’s objectives.

Ask all your stakeholders to review the list and confirm that it presents the current view of what they want the project to deliver.

If there are conflicting requirements – Marketing wants the widget in blue and Customer Services wants it to be orange – ask your Sponsor to arbitrate. It might be easier to get everyone in the same room to agree on the final list, although if you expect there will be some conflicts, you could organize individual sessions with each of your stakeholders in the first instance.

Read next: How to deal with conflicting requirements with strategies for dealing with conflict on projects

2. Set expectations

Set and manage expectations (here’s how to do that). As part of talking to all the project’s stakeholders about their requirements and the definitive list, take the time to explain to them that there is always a cost associated with making a change. If they change their minds in the future and want to add or modify a requirement, there will be a price to pay. It’s not always a financial price.

As a result of the change:

• The project could take longer or finish earlier
• More resources could be required
• The result could be a different quality outcome to what was previously agreed
• The project could cost more.

Changes are often desirable, so they aren’t something to be worried about. Embrace the changes: stakeholders should know that they do have the option to make changes if required. 

However, they should do so in the full knowledge of what the impact should be, and with guidance from you about how possible it is to make the change. For example, it is far easier to accommodate changes early in the project. 

If you are building a hotel, it is not going to be easy to change the layout of all the bedrooms when the decorators are just finishing up. Any smaller changes that cannot be accommodated now could be packaged up into a Phase 2 or another project in the future.

3. Create (or review) the change control process

Now you have a baseline of project requirements, you need to know what to do should you be asked to make another change. 

A change control process informs how requests are handled for new requirements, or modifications to existing requirements. You may have a formal change management process that perhaps isn’t working, or you may choose something less formal.

Either way, the steps to go through are the same:

1. A request to make a change to the baselined requirements is received.

2. The change is assessed against set criteria, typically the impact on:

• The schedule
• Resources
• Other requirements
• The budget
• Project risks
• The objectives and project as a whole if the change is not done.

You may have a defined list of things against which to assess the change, or you may rely on professional judgement from the subject matter experts involved. Either is fine, but make sure the review process is fair and repeatable.

3. A decision is taken whether to implement the change or not.

• If yes, document the change, update the plans and schedule and let everyone know.
• If no, tell the person who requested the change that the work will not be done, and the reasons why.

Either choice is fine. Provide feedback as necessary to the requestor and the team so everyone has the same expectation of what happens next.

Make sure that project stakeholders and in particular, your Sponsor, understand and agree to the change control process that you will be using from now on. The experience of working through this one change will help you talk about why it’s necessary to make changes in a structured way.

You know you’re in a good place when…

You know you’re in a good place when:

• You have a clear set of requirements to act as a baseline
• Everyone understands what making changes to these means
• Everyone understands how changes can impact the project
• You have a process in place for controlling change on the project.

Changes to requirements happen and often they are a good thing – you just have to be prepared for them when they do so they don’t stress you out or cause stakeholders to worry when you present them with the impact of the change.

If you enjoyed this chapter, buy the book! Project Pain Reliever, edited by Dave Garrett, is published by J. Ross and contains contributions from a broad range of project management experts.