Shaher Ahmad, Partner, Factor 7 Medical06.02.21
When it comes to product development, change of direction and scope creep are inevitable and, if not recognized or addressed, can negatively impact projects or companies along with employee morale. This article will cover signs of scope creep and a suggested method and approach to minimize that impact.
Perhaps you have found yourself in this situation: Your product development team is well on its way into a project, and everything is going according to plan. Then, the competition comes out with a new product. Management says the current project scope will no longer cut it; you’ll have to incorporate additional product features—the company doesn’t have a choice. Suddenly, your team is under immense pressure, and regardless of your best efforts, you miss your deadline.
Perhaps this scenario also sounds familiar: Your team is instructed to develop a product for specific countries and for a specific segment. After some time, you’re told the product will now also be sold in additional regions and it will cover other segments, all with different testing and registration requirements. Potentially, getting the product redesigned, retested, and reapproved for the additional regions/segments takes more time and resources, stressing your team and, ultimately, delaying the release of the product.
Following are few more causes of scope creep:
Scope creep will happen and it’s likely to occur frequently. It is a challenge, and the majority of development teams struggle with it. Product development teams also struggle with edicts to change project direction and deliverables without being offered more people or time to accomplish the additional tasks. Sometimes, even if more resources are provided, it does not help make up for the time required for a third party to test a product, for example; that factor is usually fixed and hard to change.
At the same time, change is often seen as a natural part of product development. It is to be expected and teams must adjust and deliver. I realize this isn’t fair, but it happens.
Change can be extremely frustrating, however, for those involved and it can create a team that is not engaged. Should this happen, undoubtedly, the results will suffer. When communication transforms into edicts of “just get it done,” a company and/or the project can lose people—if not physically, then mentally. The impact to the development process can be devastating.
It is recommended companies and teams take a systematic approach to adapting to changes without having to improvise on the spot. While this process may seem like common sense, it is not used everywhere consistently. It’s critical to establish an understanding among teams with regard to how to prepare for scope creep such that everyone is on board with the change to minimize the impact.
Following are five recommendations to help minimize scope creep:
1. Establish and Document Requirements
The problem statement needs to be clear. Prior to anything else, and based on research and customer interviews, a problem statement that customers agree to and your organization can align around needs to be created. Once that is accomplished, establish, document, and approve requirements. All stakeholders—from leadership to middle management to marketing to the design team—should have a chance to review the requirements so everyone is on the same page. It’s important stakeholders not only approve the requirements but also truly understand what they mean and ensure they are achievable.
The project requirements need to be well understood, agreed upon, and easily accessible to everyone. This is truly the foundation of what you do.
2. Set up a Product Development Change Control Process
It is important to address changes in a systematic fashion to avoid projects going too far off track. It is recommended all project stakeholders discuss and consider changes to determine if everyone is onboard and completely understand the ramifications of any change.
Ensure the scope is clear and well understood by the stakeholders. For example, is it essential to make a device housing black-anodized aluminum after you have been working for the past six months on getting that nice matte-finish stainless steel and have already set up the manufacturing process to do so? Does everyone realize what it will entail in terms of time and resources to change it? Everyone should understand the full ramifications of the change and decide if it is truly necessary.
3. Create a Clear Project Schedule
After communicating, reviewing, and approving requirements, create a schedule that is in line with the expected deliverables—no more and no less. This sounds like a “no-brainer,” but having a clear, well-thought-out schedule that all stakeholders endorse is extremely important, but difficult as well. If everyone agreed on the requirements, proposed schedule, and level of resources allocated to the project, they should then appreciate the ramifications of coming back with a significant change.
4. Plan for Contingencies but Do Not Go Overboard
Having zero contingency allowance is unrealistic. It is necessary to plan based on real and well-thought-out project risks.
A project manager may have 10 milestones to deliver and decide to allow a two-week contingency for each. That is 20 weeks of added project time that can easily be consumed if not managed well.
Instead, add contingency at the end (again, based on project risks and examples from prior projects). For instance, if the project schedule comes to 24 months and there is a technology risk that will require three to six months to address, it is appropriate to negotiate that possible added time as a contingency.
The project manager may say, “Here is what we are doing to manage risk and meet or exceed the 24-month schedule. But if the following risks do materialize, you are looking at another six months worst case. Anything beyond that, you can hold me accountable.”
5. Make and Keep Commitments as a Team
The project team must not only be part of developing and agreeing to all requirements, they must also embrace the product development change control process. It is counterproductive for one member to sign off on changes without consulting the rest of the team. An example of this would be when a project manager or a department head promises management something during a boardroom review, or someone from the R&D team has lunch with a marketing team member and agrees to include a new product feature they have been experimenting with that isn’t really ready yet. These are all well-intended actions that unfortunately have negative ramifications on any project. Making commitments without the team is dangerous. Usually, people come back with egg on their faces and trust is broken.
Change is going to happen. Markets, customer needs and preferences, competitive environment, and regulations change. How you handle these changes is really up to the project team and leadership. It basically boils down to open communication and being honest about what you can and can’t do. Following the five steps outlined in this article will help minimize the impact of scope creep and ensure projects are well managed with all stakeholders aligned.
Shaher Ahmad is a founding partner of Factor 7 Medical and has over 25 years of experience in the medical technology industry. He can be reached at shaher.ahmad@factor7medical.com.
Perhaps you have found yourself in this situation: Your product development team is well on its way into a project, and everything is going according to plan. Then, the competition comes out with a new product. Management says the current project scope will no longer cut it; you’ll have to incorporate additional product features—the company doesn’t have a choice. Suddenly, your team is under immense pressure, and regardless of your best efforts, you miss your deadline.
Perhaps this scenario also sounds familiar: Your team is instructed to develop a product for specific countries and for a specific segment. After some time, you’re told the product will now also be sold in additional regions and it will cover other segments, all with different testing and registration requirements. Potentially, getting the product redesigned, retested, and reapproved for the additional regions/segments takes more time and resources, stressing your team and, ultimately, delaying the release of the product.
Following are few more causes of scope creep:
- Poor estimation of time requirements, budget, etc.
- Problem statement, requirements, and original project scope not clear
- Not engaging end customer in the process
- More time required for testing than previously thought
- Product features and benefits not associated with value to customer, and all are pursued without clear priority
- Stakeholders not aligned on direction of project
- Lack of control over change process associated with product development
- Customers change their preferences (customers are always right)
- Supply chain disruption and/or suppliers not meeting their commitments
Scope creep will happen and it’s likely to occur frequently. It is a challenge, and the majority of development teams struggle with it. Product development teams also struggle with edicts to change project direction and deliverables without being offered more people or time to accomplish the additional tasks. Sometimes, even if more resources are provided, it does not help make up for the time required for a third party to test a product, for example; that factor is usually fixed and hard to change.
At the same time, change is often seen as a natural part of product development. It is to be expected and teams must adjust and deliver. I realize this isn’t fair, but it happens.
Change can be extremely frustrating, however, for those involved and it can create a team that is not engaged. Should this happen, undoubtedly, the results will suffer. When communication transforms into edicts of “just get it done,” a company and/or the project can lose people—if not physically, then mentally. The impact to the development process can be devastating.
It is recommended companies and teams take a systematic approach to adapting to changes without having to improvise on the spot. While this process may seem like common sense, it is not used everywhere consistently. It’s critical to establish an understanding among teams with regard to how to prepare for scope creep such that everyone is on board with the change to minimize the impact.
Following are five recommendations to help minimize scope creep:
1. Establish and Document Requirements
The problem statement needs to be clear. Prior to anything else, and based on research and customer interviews, a problem statement that customers agree to and your organization can align around needs to be created. Once that is accomplished, establish, document, and approve requirements. All stakeholders—from leadership to middle management to marketing to the design team—should have a chance to review the requirements so everyone is on the same page. It’s important stakeholders not only approve the requirements but also truly understand what they mean and ensure they are achievable.
The project requirements need to be well understood, agreed upon, and easily accessible to everyone. This is truly the foundation of what you do.
2. Set up a Product Development Change Control Process
It is important to address changes in a systematic fashion to avoid projects going too far off track. It is recommended all project stakeholders discuss and consider changes to determine if everyone is onboard and completely understand the ramifications of any change.
Ensure the scope is clear and well understood by the stakeholders. For example, is it essential to make a device housing black-anodized aluminum after you have been working for the past six months on getting that nice matte-finish stainless steel and have already set up the manufacturing process to do so? Does everyone realize what it will entail in terms of time and resources to change it? Everyone should understand the full ramifications of the change and decide if it is truly necessary.
3. Create a Clear Project Schedule
After communicating, reviewing, and approving requirements, create a schedule that is in line with the expected deliverables—no more and no less. This sounds like a “no-brainer,” but having a clear, well-thought-out schedule that all stakeholders endorse is extremely important, but difficult as well. If everyone agreed on the requirements, proposed schedule, and level of resources allocated to the project, they should then appreciate the ramifications of coming back with a significant change.
4. Plan for Contingencies but Do Not Go Overboard
Having zero contingency allowance is unrealistic. It is necessary to plan based on real and well-thought-out project risks.
A project manager may have 10 milestones to deliver and decide to allow a two-week contingency for each. That is 20 weeks of added project time that can easily be consumed if not managed well.
Instead, add contingency at the end (again, based on project risks and examples from prior projects). For instance, if the project schedule comes to 24 months and there is a technology risk that will require three to six months to address, it is appropriate to negotiate that possible added time as a contingency.
The project manager may say, “Here is what we are doing to manage risk and meet or exceed the 24-month schedule. But if the following risks do materialize, you are looking at another six months worst case. Anything beyond that, you can hold me accountable.”
5. Make and Keep Commitments as a Team
The project team must not only be part of developing and agreeing to all requirements, they must also embrace the product development change control process. It is counterproductive for one member to sign off on changes without consulting the rest of the team. An example of this would be when a project manager or a department head promises management something during a boardroom review, or someone from the R&D team has lunch with a marketing team member and agrees to include a new product feature they have been experimenting with that isn’t really ready yet. These are all well-intended actions that unfortunately have negative ramifications on any project. Making commitments without the team is dangerous. Usually, people come back with egg on their faces and trust is broken.
Change is going to happen. Markets, customer needs and preferences, competitive environment, and regulations change. How you handle these changes is really up to the project team and leadership. It basically boils down to open communication and being honest about what you can and can’t do. Following the five steps outlined in this article will help minimize the impact of scope creep and ensure projects are well managed with all stakeholders aligned.
Shaher Ahmad is a founding partner of Factor 7 Medical and has over 25 years of experience in the medical technology industry. He can be reached at shaher.ahmad@factor7medical.com.