Your project sponsor catches you just before you leave for the day and say, 'Oh, and you know that invoicing module? Will you make sure it does currency conversion for our international accounts?' 

On your way back to your desk after lunch, the Sales Manager stops you in the corridor. 'We've done some focus groups with customers,' she says, 'and here's what they want from the database.' She hands you a long list. 'Mostly new stuff, but these two are just rewriting some reports. You can do it all for the launch day, can't you?' The reports had already been written. How are you going to tell the development team that they would have to do it all again? The changes don't even look that important.

Project managers aren't doormats. Saying yes to everyone, even though there is no way to get it all done, is not the way to deliver a project successfully. The requirements in both these scenarios are too fluid and the project manager needs a new approach to keep the project - and the stakeholders - on track. Many project managers have this problem. At the start of the project you thought it was great that people were so enthusiastic about making sure that the project delivered something which was fit for purpose. If that meant a few changes here and there, so be it. Now the changes are piling up and it looks as if you'll never get finished if the goal posts keep moving.

Get used to changes

Changes to requirements are common on projects. After all, when you started out you may have had a clear vision of what needed to be done, but as the project progresses, users start to realise what is possible and ask for more features. Or perhaps the client keeps changing her mind. Whatever the reasons behind all the changes, in these situations you are facing a project suffering from major scope creep.

Watch out for the warning signs

Is your project in dire need of proper change control? Is your requirements matrix getting bigger and bigger? Here are some of the warning signs to look out for.

  • People are changing their minds about what they want.
  • Requirements that were agreed last week are now different, or removed entirely.
  • You are spending a lot of time chasing people for agreement.
  • Your plan is out of date as soon as you have updated it.
  • The project is running late because you are having to schedule rework to cope with the changing requirements.
  • You can't see the end of the project.

What's wrong with doing nothing?

You could carry on as you are, in a constant state of never being on top of anything. The project will drag on as frequent changes to the requirements means that nothing is ever completed. Eventually, the project will be cancelled or you will be asked to step down. The project will be taken over by someone who will be able to deliver what is needed. And what is needed is not necessarily every single change that is requested by someone in a corridor conversation.

Your credibility as a project manager depends on being able to complete projects and ensure they deliver business value, so there is a risk here that you'll end up being seen in the organisation as someone who can't control a project - which is not good for your career. 

Controlling change

Changes aren't necessarily bad; they just need to be handled in a controlled way. You need to stop the scope creep and make sure that everyone signs up to the current list of requirements. And you need a way to make sure that if there are changes in the future everyone understands what the impact is of making those changes. When the requirements keep changing, it's important to nail them down as quickly as possible to get back on track. Establish where you are now and how you will handle changes when something else changes - because it will! In summary, you need:

  1. An agreed set of current requirements.
  2. A clear understanding amongst your project team and stakeholders of the impact of making changes.
  3. A change control process.

Let's look at those in turn, starting with the first two which are covered by this article

A clear set of requirements

First look at the requirements you already have. If you haven't already got a list, use a tool like iMindQ in a workshop where you gather and categorize all the known requirements. For the moment, forgot all the other stuff that people may ask for in the future and for now just concentrate on what you currently understand as the project scope.

It may help to go back to your scope document and the business case. What is this project trying to achieve? This forms the underpinning structure of your requirements. List all the requirements that 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 organise 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 (more on that later).

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 (both of which could be a bad thing: early isn't always better).
  • More resources could be required.
  • The result could be a different quality outcome to what was previously agreed.
  • The project could cost more.

Of course, change isn't always bad, and for those desirable changes, stakeholders should know that they do have the option to amend what is in scope 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. How do project team members and stakeholders submit their changes for analysis, and how do you tell them if they can be accommodated or not?

Now, we are going to be looking at the change control process. When 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, 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. How you receive it could vary. Sometimes the PMO will handle change requests, sometimes it is as informal as a phone call.

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.

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.

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.

Be prepared when project changes happen

Changes to project requirements happen - you just have to be prepared for them when they do. 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.