Help! The requirements keep changing and I can’t nail them down (part 1)

by ·


Project Pain RelieverThis is an extract from Project Pain Reliever. I contributed two chapters and they are being serialised here over a month. The last two extracts looked at producing a realistic schedule by involving the team in the planning. Read about the issues and warning signs here, and how to create a collaborative plan here.

Today’s extract is the first part of the chapter about requirements management.

Everything changes…

Emily was nearly at the door when her Sponsor said, “Oh, and you know that invoicing module?  Will you make sure it does currency conversion for our international accounts?”  Emily smiled tightly.  This was the fifth change to the requirements for the invoicing module this week – and it was only Wednesday.  Last week her Sponsor had told her that the module only had to cope with national accounts.  “I’ll see what I can do,” she said.

On her way back to her desk, Samantha from Sales stopped Emily in the corridor.  “We’ve done some focus groups with customers,” she said, “and here’s what they want from the database.”  Samantha handed her 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?”

“I’ll see what I can do,” Emily said.  The reports had already been written.  How could she tell the development team that they would have to do it all again?  The changes didn’t even look that important.  All the requirements for this project were changing on a daily basis and at this rate they would never get everything done by the launch date.

Emily knew she couldn’t carry on like this.  She was being a doormat and just saying yes to everyone although there was no way it would all get done.  The requirements were too fluid and she needed a new approach to keep the project – and the stakeholders – on track.

Problem

At the start 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.

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, you are facing a project suffering from major scope creep.

Warning Signs

  • 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 will happen if I do nothing?

The project will drag on as constant changes to requirements mean 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.

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.

Solution

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

Next Wednesday’s extract will show you how to get there.

 

Project Pain Reliever, edited by Dave Garrett, is published by J. Ross and is available on Amazon.

  • Valérie Laforest

    Hi there, 
    I wrote a short report from a presentation given during the last PMI EMEA congress in Marseille about mastering the fuzzy constraint that scope is: http://bit.ly/NLuU9PHope it brings additional things on the table! 

    • http://www.otobosgroup.com Elizabeth

       Valerie, that link doesn’t work. Do you have the non-shortened link that you could share with us?

  • Kwame

    I actually bought this book, based on the prior excerpts. I must say I am impressed. I will however mention that there is no link for US readers of this blog on this post.

    • http://www.otobosgroup.com Elizabeth

       Kwame, thanks for pointing that out. US readers can get a copy at Amazon.com (affiliate link, like all my Amazon links).

  • Pingback: New PM Articles for the Week of June 25 – July 1 | The Practicing IT Project Manager

  • http://www.facebook.com/profile.php?id=1057438064 Dave Fletcher

    I would add one other thing to  the list even though it might be assumed:  A “release schedule” for requirements. I’ve seen teams get buried, then harassed without one

    • http://www.otobosgroup.com Elizabeth

       Hi Dave. Do you mean a log of all the requirements so that you have traceability? These are really valuable tools. You can see where the requirement originated from and also what status it is now, and they are great for being able to produce test scripts later on. You’re right, without one teams will find it difficult to stay on top of the requirements and things fall through the cracks. I should have included that!

  • Monguko

    The blog is really helpful as I prepare for my PMP. Thanks

    • http://www.otobosgroup.com Elizabeth

      I’m glad you think so. Good luck with your studies.

Previous post:

Next post: