Select Page
Project Pain Reliever

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 want the widget in blue and Customer Services want it to be orange – ask your Sponsor to arbitrate.  It might be easier to get everyone in the same room to agree 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.

This exercise will give you a baseline for the project’s requirements. Any changes after this need to be assessed and taken through the change control process.

2. Set expectations

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.
  1. 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.

An example change process is show in the diagram below.

RFC process
A request for change process

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.

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.

Project Pain Reliever , edited by Dave Garrett, is published by J. Ross.

Click For Original Article