<img height="1" width="1" style="display:none;" alt="" src="https://dc.ads.linkedin.com/collect/?pid=150057&amp;fmt=gif">

4 Key Causes of Scope Creep and How to Mitigate Them

01st Nov 18

Posted by Richard Wood

When projects over-deliver, significant cost and schedule overrun are usually the two biggest casualties. Scope creep is a risk in the vast majority of projects – as an area of project management, it’s widely known, often well understood yet frustratingly difficult to avoid. Here we look at four fundamental causes of this phenomenon.

1. Scope Defined Too Early

Scope definition is premature when it’s founded on inadequate information. One cause of this is can be the overvaluing of executive views, i.e. the c-suite incorrectly presumes their position alone provides them with the required knowledge, which it doesn’t. When projects are initiated from an inadequate understanding of what’s needed, scope creep invariably follows.

Often the proposed antidote to this phenomenon is feasibility analysis. It’s a powerful technique if performed correctly, but all too often becomes unsubstantiated window dressing, giving only the illusion of thorough decision making. In other words, the exercise can be fudged to support the result that the executive was promoting all along.

2. Lack of Sponsor and Stakeholder Involvement

Typically, project sponsors are overworked and spinning many different plates. If the sponsor doesn't receive frequent communication about the project, he/she is at risk of becoming unengaged, and more likely to pass over project decisions to the team. The less interested the sponsor, the more likely scope creep is because the core of activity moves away from the sponsor and toward the team.

Similarly, stakeholders often don't dedicate enough time to project work, yet their input is needed for defining and reviewing requirements. Again, the project team may fill the void, increasing the likelihood of scope creep.

3. Scope Defined in Unsuitable Terms

Project Times notes that when project scope is only defined in terms of objectives or tasks to be performed, projects are often doomed to creep. While setting objectives is crucial for project success, they shouldn’t be the only basis for project scope, as each person will likely have a different idea of what is needed to achieve each objective. What’s more, this variation in ideas won’t necessarily be voiced and recognized by the team.

Tasks to be performed will always be a key basis for project scope. And a vendor can ensure they meet contractual obligations, as they can control the tasks they perform. But, importantly, that won’t necessarily mean the client’s needs have been met. When a client points this out, the vendor can then suggest follow-on work – additional tasks to satisfy the client’s needs. If the needs are still not met, even more tasks are added. This process may well repeat itself several times…

4. Requirements Without Context Are Not Tracked

PMI points out that when a project is in full swing, if requirements aren’t continuously linked back to business and project objectives, teams will fall back on their own judgment when deciding whether to include individual requirements.

This issue can be intensified when there is a close relationship between management and members of the project team, as personal alliances can cause standard procedures to be circumvented – additional work may be agreed to when it shouldn’t be.

How to Mitigate Scope Creep 

When changes are incorporated in the project scope of work without suitable change control processes having been set up, scope creep inevitably follows.

To give your project a fighting chance of avoiding it, try to follow these guidelines:

  1. Feasibility analysis should be as objective, consistent, and honest as possible, aiming to ensure that a project is operationally, legally, financially, and technically viable. To discourage biases from executives or any other staff, maximise the use of empirical and statistical methods. For example, The Master of Project Academy describes project feasibility studies in the context of the Six Sigma methodology. 
  2. Confirm the project and scope execution plan with stakeholders and sponsors before the start of the project. To encourage their involvement, roles and responsibilities should be clearly defined in the project charter, and potentially using tool like a RACI (Responsible Accountable Consulted Informed) matrix. Engaging project status reports should be distributed frequently to maintain involvement, but, equally, lack of stakeholder participation should be identified and treated as a risk, early-on in the project.
  3. Define the scope of work accurately and at the appropriate time. To define project scope, you must first identify: project objectives, goals, deliverables, sub-phases, tasks, resources, budget, and schedule. You then need to specify the parameters of the project and clearly pinpoint any elements that are not to be included. 
  4. Ensure the schedule and resource plan is centered on how to complete the defined deliverables.
  5. Measure performance against the project baseline, after setting it at the planning stage.
  6. Ensure funds in budgets and resources are always tied in with any change in work.
  7. Objectively evaluate scope, schedule impact, and resource requirements before any new activities are included within the schedule. 

Of course, in 2018, project management software is needed to get the best results from each guideline. Which is why Safran Cloud offers full schedule impact analysis, change management features, and enables you to perform full scope, resource plan, and schedule control. If you’d like to see for yourself, request your free trial now.

Safran Cloud