Coping with Scope
ASG Engineer Matt Gum isn't afraid of scope creep. Here are his insights and ideas on how to stop it before it starts.
Scope change happens. Sometimes it’s unavoidable. But when scope change becomes scope creep, projects suffer. ASG Engineer Matt Gum knows all about it. He’s managed scope creep on dozens of projects. In this Q&A, Matt shares insights that could help you keep your own projects on track.
How do you define scope creep?
It’s what happens when the boundaries of a project’s scope continue to grow without adjustments to schedule, cost and resources. It’s called scope “creep” because it can sneak up on you, and suddenly, team members are doing things that weren’t in the initial project plan.
For example, consider the situation where the project team identifies an exciting new feature that clients would love to see in the system. Everyone seems to agree that it’s a great idea, and so the team forges ahead with implementing the feature into the product. But in everyone’s enthusiasm, there was no planning or evaluation of the effect(s) to the system.
Soon enough, the engineers realize there are major design challenges, the equipment supplier learns that the quoted system can’t manufacture the product, and the financial controllers find that the manufacturing cost of the product has doubled.
Miscommunication and unclear goals are often the sources of a scope creep problem, which can cause a cascade effect on other areas of the project.
How can unclear goals and requirements lead to scope creep on a project?
When team members have a poor understanding of the project requirements, they can’t define a standard for verifying that the project was successfully delivered. Project requirements help define project scope, so everyone understands that any later change in requirements is a potential change in scope.
If requirements are missing or unclear, the project will deliver a system that doesn’t meet the needs of the client. System costs and timeline are likely to increase as the number of requirements increases to account for previously unknown customer needs.
If requirements are overdefined or unnecessary, they may add cost and delays to the system delivery and cause confusion for team members.
In what other ways can scope creep impact a team?
When scope change happens but there’s no real planning behind it, the effects on team members can harm overall project morale. Project expenditures can start to increase due to unforeseen needs. When workload greatly increases but personnel resourcing remains the same, team members can become overworked and overwhelmed. As a result, schedule targets are missed.
Then the team loses sight of the project’s goals and the project can spiral into a cycle of scope creep.
ASG’s project managers know the value of focusing the project team on scope creep before it happens.
How do you avoid it?
Avoiding scope creep starts early in the project. The first step for many ASG projects is to develop a project plan with a clear understanding of the requirements. This plan could go by many names, but it should define the purpose, objectives and scope of the project. With the scope defined clearly at the beginning, the project has a plan to refer to throughout the project, and the team will be more likely to pay close attention to how scope changes affect the plan.
Having a good project manager adds another level of control. A good project manager is a steady hand at the helm, so that any potential scope increases are evaluated with awareness of how it would affect the project’s schedule and cost.
ASG’s project managers know the value of focusing the project team on potential scope creep before it happens, identifying where there will be new risks, deciding if the risks outweigh the benefits and planning how to implement scope changes responsibly.
What’s the most responsible way to manage project changes?
It depends a lot on how significant the change is. At the very least, an informal discussion or evaluation should occur within the project team to identify risks of the potential change and determine if deeper discussions are needed. For very significant changes, there should be focused discussions of the risks and if there are ways to address them, including input from all necessary subject matter experts.
There are certain documents and resources that should be implemented to keep the project on track. The project plan, as mentioned earlier, is a document to reference when considering any scope change. Ideally a change control process should be in place for any major project. It could be part of the project plan or spelled out in another document.
Generally, a formal change notice would include several details about the change including: background and reason for the change, effects of the change (risks and benefits), current state of the project/system before the change, state of the project/system after making the change and a general implementation plan.
To accomplish a healthy change in scope, the project needs to take stock of the risks of the change.
Can scope change ever be a good thing?
If the change is controlled and deliberate, scope change can potentially allow the project to take advantage of a new development, such as a greater product demand or additional system features. It’s possible that the initial project scope was too narrow to accommodate a change that makes sense.
If recognized and properly handled, scope changes can create opportunities for an organization to increase sales, deliver more value and strengthen client relationships. To accomplish a healthy change in scope, the project needs to take stock of the potential risks of the change.
For example, consider a project to deliver an assembly line for integrating a drug product with a delivery device. Now assume that in the course of the project, a drug product is identified that can use the same delivery device, but the drug product is in a larger or smaller vial. This new drug product is outside of the original project scope.
The system supplier is asked to evaluate the cost and schedule impacts of redesigning the system to accept the new drug vial, and the engineers are asked to determine the estimated capacity of the system, and the increased time needed to qualify it for a second product.
The team may find that the business case for the system is improved, even considering the increased timeline and costs. The correct follow-up is to put in place a new plan for delivery of the system, which might include adding team members and a rewrite of the project plan.
Need help with scope creep?
Read more about ASG’s services, including program management and how we work to avoid scope creep on each and every project.
