Scope Creep

Whenever something goes wrong in a project’s performance it is often blamed on “scope creep.” Scope creep has become such a familiar feature in project management that it is mostly accepted as the correct reason and even worse, being accepted as a fact of project life. The prevailing belief is that it cannot be helped, it is “beyond the PM’s control,” and therefore is part of the necessary evil in managing projects. Not True!!

This is the sixth blog by Mat-Thys in the series “Managing Projects: The Forgotten Art Of Influencing People To Get Results”

Scope creep: Adding additional features or functions of a new product, requirements, or work that is not authorized (i.e., beyond the agreed-upon scope).

Source: Project Management Institute

The Biggest Excuse In Managing Projects; Scope Creep – How To Avoid This Pitfall?

To decide what to do about this scope creep excuse we need to first investigate the reasons why we are experiencing scope creep. We will make suggestions about what could be done to minimize the probability of experiencing the scope creep situation. The most common reasons for experiencing scope creep include the following:

  • Poor initial alignment of stakeholder expectations – We dealt with this in section one. This is when the initial requirements or expectations are not actively discussed, detailed and aligned with the end-user and/or customer. We are undertaking this project to satisfy a customer need and if not met and completed we will not be able to earn revenue with this service.
  • Poor initial scoping of the project – The customer agreed to expectations and requirements, which are interpreted in project deliverables that would be summarized by the project’s scope. If we do not understand the exact implications of the customer needs then the chances are poor that we would be able to interpret this in appropriate deliverables. This results in a poor scope that will have to be modified as we progress through the project.
  • Poor monitoring and control – If you were not keeping your finger on the pulse, how will you know that you need to take action? Taking action could avoid additional actions and hence avoid pressure on scope requirements.
  • Poor “feedback loop” – Not getting feedback in time or not getting feedback in specific enough details could also put pressure on the initial scope. Most project issues can be resolved fairly successfully if detected and action taken in time. Getting into the habit of identifying GAPS with the project requirements early could save you and your project a lot of time, effort and rework.
  • “Poor speak” – This is all about being specific and again this was covered in detail in section three. Specificity plays a major role in all of the bullet points above. Not verifying in detail what has been communicated can leave room for personal biased interpretation, which is not good.
  • Legitimate reasons – This is where we had technology improvements or the scope of the project genuinely altered due to market or condition changes.

How To Avoid Scope Creep?

So, how do we suggest you tackle this issue of scope creep successfully? Firstly, we suggest that you do not freak out when it happens, but immediately try to find the underlying reasons why it occurred. Knowing what caused it might alert you to future similar problems with this same project and you need to treat this instance as a warning sign of what is to come. This should be the ideal time to fix the problem and to avoid more serious potential future scope creep situations.

Scope creep has become such a familiar feature in project management that it is mostly accepted as the correct reason and even worse, being accepted as a fact of project life.

We would suggest the following strategy:

  • Based on past experience it all starts with having a vague, ill-defined or poorly stated client/end-user expectations. Do not use a “junior” person to formulate the client expectations, because they do not always have the necessary business experience to interpret what the business meant by a specific requirement. You might think that this is going over the top, but we can guarantee you that you will “thank your stars” over and over as you progress through your own project. This is going to save you many iterations of the project scope.
  • Once you have all the expectations you need to translate this into project deliverables. This is not easy to do and we suggest you do this in small teams with a combination of stakeholders until you have your final list. This final list should state emphatically what is not included in these deliverables. There is nothing more clear than stating what will not be delivered.
  • In the midst of all this is the nagging requirement of being as specific as possible. This is true for all the points above. The listing of expectations and project scope deliverables to the way the internal project communications are handled needs to be highly specific.
  • Create an effective feedback loop that ensures you and your staff have their “ears to the ground” all the time to gather project intelligence. Nothing can be as effective as being proactive. This will also ensure that if anything does go wrong, it is contained and dealt with quickly and effectively.
Learn More About KEPNERandFOURIE®

This blog and this entire series of blogs were first published by Thinking Dimensions Global.

Mat-Thys Fourie
"I believe that Management would like to see their staff as skilled problem solvers, solving and restoring service issues/incidents 'first time every time', reducing company Mean Time to Restore and Mean Time To Repair cycles. This is done by providing staff with repeatable tools/templates and worked situational questions to stay on the path through organizational difficulties and barriers towards restoration and successful recovery." Dr. Matthys Fourie is a Professional Problem Solver as accredited by the Institute of Professional Problem Solvers (IPPS). He is an author of several books on Root Cause Analysis, Project Management, Problem Solving and is the co-author of the KEPNERandFOURIE® Thinking methodologies. He has over 31 years of Problem Solving and Decision Making experience helping organizations across the world solve some of their most vexing and seemingly unsolvable problems. He has worked across a wide spectrum of industries from Automotive, Financial, Manufacturing, Medical Devices, Pharmaceutical, Nuclear, Insurance, Airline, Technology, and Telecommunications. He has work in companies such as Macquarie Group, SASOL, Unisys, SITA, Barclays, RBS, NCS, Singapore Stock Exchange, BMW, VW, Cadbury Schweppes, Westpac, National Australia Bank, Department of Education NSW Australia, Kimberly-Clark, Hollister, Stihl Inc. and the U.S. Navy.