How Would You Manage Frequent Changes In User Requirements?

(This post contains affiliate links. Read my full disclosure.)

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

Are your project requirements constantly changing? Are you expected to get something washed 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 practice about it.

In this article:

What should I practice?
- 1. Clear set of requirements
- 2. Set expectations
- 3. Create (or review) the alter control procedure
You know you lot're in a good identify when…

Annotation: This article assumes you are working in a predictive environment. If you are using active methodologies, you have other tools available to yous to manage changes in requirements because flexing the scope of the project is very much congenital into the active 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 commitment.

What should I do?

When the requirements keep changing, it's of import to nail them down equally quickly as possible to become dorsum on track, even if you tin't see that far into the futurity. Work on what you tin manage, and put a process in place for adapting to future changes.

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

1. Articulate prepare of requirements

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

This forms the underpinning structure of your requirements. List all the requirements you currently take on the project and make sure they all necktie back to the project's objectives.

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

If there are conflicting requirements – Marketing want the widget in blue and Customer Services want it to be orange – inquire your Sponsor to intervene. It might be easier to get everyone in the aforementioned room to agree the final list, although if you expect there will exist some conflicts yous could organize individual sessions with each of your stakeholders in the starting time example.

This exercise volition requite you a baseline for the projection'south requirements. Whatsoever changes after this demand to be assessed and taken through the change control process.

Read adjacent: How to deal with alien requirements with strategies for dealing with conflict on projects

2. Set up expectations

Set and manage expectations (here's how to do that). As part of talking to all the project's stakeholders near their requirements and the definitive listing, take the fourth dimension to explain to them that there is always a cost associated with making a change. If they modify their minds in the future and desire to add or modify a requirement, in that location will exist a price to pay. It's not always a fiscal price.

As a result of the alter:

The project could take longer or cease earlier
More resources could be required
The result could exist a different quality effect to what was previously agreed
The project could cost more.

Changes are often desirable, so they aren't something to be worried most. Embrace the changes: stakeholders should know that they do have the pick 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 conform changes early in the project.

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

3. Create (or review) the alter control process

Now you accept a baseline of project requirements, yous need to know what to do should you be asked to brand some other change.

A modify command procedure 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 yous may cull something less formal.

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

A asking to make a change to the baselined requirements is received.

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

The schedule

Resources

Other requirements

The upkeep

Projection risks

The objectives and project as a whole if the change is not done.

You may have a defined list of things confronting which to assess the change, or yous may rely on professional person judgement from the subject matter experts involved. Either is fine, but make certain the review procedure 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 permit everyone know.

If no, tell the person who requested the change that the work volition not be done, and the reasons why.

Either selection is fine. Provide feedback as necessary to the requestor and the squad so anybody has the same expectation of what happens adjacent.

Make sure that project stakeholders and in particular, your Sponsor, empathise and agree to the modify command process that you will exist using from now on. The feel of working through this one change will help y'all talk about why it's necessary to make changes in a structured manner.

Tip: Document the decision in the change log. You could also use a decision log as a way to record any related decisions that drib out of the conversations about this change.

You know you're in a practiced place when…

You know y'all're in a good place when:

You lot accept a clear set of requirements to act as a baseline
Anybody understands what making changes to these ways
Anybody 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 affair – you just have to be prepared for them when they exercise so they don't stress you out or cause stakeholders to worry when you present them with the bear upon of the alter.

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

How to manage constantly changing requirements

Pivot for later reading:

Writer, mentor

Elizabeth Harrin is a Swain of the Association for Project Management in the United kingdom, a trainer, mentor and author. She helps managers juggle their projects and ditch the overwhelm, making tools and techniques work in the real earth. Elizabeth is likewise the founder of the Project Management Rebels customs, a instruction-led mentoring group for professionals. She'due south written several books including Managing Multiple Projects.