Project management

How to solve the problem of scope creep

Psoda blog author avatar
5 June 2018

Have you ever been involved in a project that grows and grows? It feels like every day something else is added to the to-do list. Welcome to scope creep, something most project managers dread.
It can happen to almost any project and when it does, the impacts are far reaching. From budget blowouts, stakeholder frustration and dissatisfaction to the project not meeting its promised benefits and being declared a failure.

What is scope creep?

PMBOK defines scope creep as “adding features and functionality (project scope) without addressing the effects on time, costs, and resources, or without customer approval” [PMI (2008), PMBOK Guide, 4th edition, p 440]
In essence, scope creep is when someone wants to add something shiny and new to your project, but doesn’t actually think about how this will happen.

An example of scope creep

I was involved in a project which, initially, was expected to deliver one piece of software functionality to a department. The product being installed had more than just that one function but it was agreed that everything, except the one piece of functionality being implemented, would be turned off.
About half way into the project, the head of the department involved suddenly changed his mind and wanted more of the functionality to be made available. This was agreed to without any consultation with the project team. There was no re-scoping, no change process, no recalculation of the project budget or schedule revision. The project manager was told of the change in a project meeting.
By this time, a lot of the ground work had been done on the project, which had to be re-done. This meant the project was suddenly running late and was over spending. The project manager was tearing her hair out as this “small” change had wrecked her project.
When the project was finally complete, after delivering all the additional work, it was classed as a failure. The reason? It had gone over schedule and over budget.
In reality though, it failed because of badly managed scope creep.

Examples of things that cause scope creep

Using the abovementioned project, I believe there were four main reasons for the scope creep causing the problems it did.

Problem 1: Loose scope definition

In this case, the project sponsor and business owner had completely different expectations compared to the project team. They thought they had the ability to add more of the product’s functionality as they saw fit. The project team thought the scope was as it had been defined in the business case.
In my mind, there are three things that could have helped prevent this from happening:

  1. The project manager needed to work with the sponsor to make sure the project charter had a clearly defined scope statement.
  2. The team should have worked out exactly what was in and out of scope, and made sure it was documented in the project charter and the business case. This would have saved a lot of drama on this project. To prove that more functionality was out of scope would have been easy.
  3. As soon as the project manager knew there had been a change request approved without following due process, she should have raised it with her steering committee. They could then have made the decision to follow good change control. Instead she had to manage on her own.

Problem 2: Poorly defined requirements

The project’s requirements weren’t collected in a controlled way. People were asked what they wanted the solution to do and what they would like it to have. There was no centrally controlled list, so there was no way of tracing the impacts of any changes. When the senior responsible owner (the department head) decided to change the requirements, there was no way to trace the impact of those changes on the rest of the project.
This could have been solved by:

  1. Having a formal requirements gathering process managed by a business analyst. This should have included loading requirements into a central repository which everyone could access. Any changes would be tracked and logged.
  2. Having the agreed requirements formally signed off. This would have ensured everyone was on board with what was supposed to be delivered.
  3. Using an automated requirements traceability matrix. As soon as a requirement was changed, the matrix would flag the requirements that would be impacted. This would have allowed the project team to review the affected requirements and make changes.

Problem 3: Too little stakeholder engagement

The project manager wasn’t proactively managing her stakeholders. That was clear when the project manager was blindsided by the decision to change the scope. The project manager could have stopped this from happening by:

  1. Making sure the project’s stakeholders were involved in the project meetings. This would have made them feel part of the team and may have stopped the department head from making the decision he did.
  2. Having regular one on one meetings with key stakeholders. Not only would this have make them feel important, it would have been an opportunity to discuss any concerns or changes they had and nipped any wayward behaviour in the bud.
  3. Asking the steering committee for help to engage with the project stakeholders. Sometimes, for whatever reason, stakeholders prefer to engage with someone other than the project manager. Nine times out of ten a steering committee member has better luck.

Problem 4: No change control process

Instead of using a formal change control process where any changes were logged and managed, everything was agreed informally. Putting a formal change control process in place would have solved a lot of the problems by:

  1. Clearly showing the different tolerances for change and who could make the decisions at each level. E.g. up to +/- 10% of time or budget the project manager could make the change. Over +/- 10% the steering committee needed to make the change.
  2. Giving the project manager the power to say no. The proposed change was outside the remit of the senior responsible owner and should be passed to the steering committee to make the decision.

Managing scope creep effectively is essential if you want to deliver a successful project. By building in processes and plans from the beginning, you go a long way towards doing that.

Psoda plug

If you’re looking for an awesome tool that will help you manage scope creep in your projects, check out Psoda. It has tools to manage requirements, a full traceability matrix, version control, project management tools and excellent reports. Take it for a test run with a free 30 day trial. Just click on the big red button at the top of the page to register.

Rhona Aylward avatar
Written by Rhona Aylward
Rhona is Deputy Everything Officer at Psoda, where she does everything except code. After starting life as a microbiologist she moved into PMO leadership roles around the world before settling in New Zealand with her family.

Leave a Reply

Your email address will not be published. Required fields are marked *