Requirements are changed in all phases of all projects. The later in the project we change the requirements the more costly the change will be. SEs and PMs know controlling that change is key is managing scope, cost and schedule. We often talk about 'locking down' requirements, or freezing them to stop churn, but how do you actually get to that 'locked down' state?
No matter what phase of the project you're currently in, there are three key actions you can take to reduce requirements churn:
Build a Shared Vision
A shared vision of the system or project is key to aligning all players. The vision should extend beyond your part of the project to the overall goal. This allows you and your team to make good decisions based on goals of the entire project goals, without constantly needing to double check if it aligns with other partners. It makes the solutions you propose more acceptable to the customer and other players because it is clearly inline with their project goals. This alignment of goals reduces the amount of redefinition of requirements and thus reduces the churn throughout the project.
Focus on Need vs Requirement
Contracts are very good at capturing requirements, but not customer need. Requirements are a good checklist for ensuring a solution meets the customer need, but that only works when the requirements are developed to address the customer need. When requirements are developed focusing on testing the solution rather than quantifying the need we can end up with a mismatch. We could be designing something different than what our customer actually needs. In such a situation the customer has one lever to move the design in their desired direction, and that's to change requirements. Those changes will be late in the project cycle and costly because each will be made only when the customer recognizes the gap.
We can short cut this situation by focusing on customer need to create the original requirements. For instance, if a customer has stated they require a radar with a range of X nautical miles, we need to focus on the why and how. Most radars can't provide a consistent range at all elevations, or in all weather conditions. Meeting such a requirement in all possible circumstances would be very costly and is likely not the actual intent. If we understood the scenario that caused a need for such a radar we could better determine the correct (cost effective) solution. With that solution, we can re-scope the requirement into what is actually needed that will better meet the customer's intended use, or need.
To develop that understanding we need to create scenarios, or concept of operations. Working with the customer we can develop a comprehensive view of how the system is used (rather than what it is composed of). The view is captured in the scenarios or concept of operations and is updated as our joint understand of system use evolves. If we develop our requirements based on this shared understanding of use, there will be less need to change requirements as we proceed through design.
Become the Expert
Requirements also churn when you haven't yet gained the trust of your customer. If they are unsure of your expertise they will use requirements to change your proposed solution to match their desired solution. Unfortunately, no one knows the customer's business better than the customer, so they'll often be right which further erodes your position as the expert. This erosion will motivate the customer to question other design decisions. When they disagree with your decisions, the customer will use their one lever to change design: the requirements.
You can avoid this type of churn by becoming the expert the customer whats to rely on. To do this you need to not only know the technical aspects of the system you're designing, but have a deep understand of how it is used. For example, if you've been asked to provide a sea navigation radar, it's not sufficient to simply understand the frequencies and data protocols of the radar. You need to know how the radar is used in navigation, how it is used in collision avoidance, etc. When you understand all aspects of the radar function and use you'll find it easier to communicate with the customer, and thus easier to maintain their trust and reduce any second guessing.
It's All Connected
The three steps are closely linked. First we build a shared vision with the customer to align our goals. We then elaborate on that shared vision through the development of scenarios and concepts of operations. The scenarios allow us to understand the customer need and in turn create robust requirements that closely align with the customer's need. Finally we use our expertise to build customer trust and reassure them that we are indeed specifying the system they will actually be able to use. These steps help ensure the requirements developed align with our customer's need reducing requirements churn.
-Michael Sepa, P.Eng
5 October 2014
INCOSE Canada publishes an article of technical interest to engineers each week. You can read them all by clicking here.
No matter what phase of the project you're currently in, there are three key actions you can take to reduce requirements churn:
- Build a shared vision
- Focus on need vs requirement
- Become the expert
Build a Shared Vision
A shared vision of the system or project is key to aligning all players. The vision should extend beyond your part of the project to the overall goal. This allows you and your team to make good decisions based on goals of the entire project goals, without constantly needing to double check if it aligns with other partners. It makes the solutions you propose more acceptable to the customer and other players because it is clearly inline with their project goals. This alignment of goals reduces the amount of redefinition of requirements and thus reduces the churn throughout the project.
Focus on Need vs Requirement
Contracts are very good at capturing requirements, but not customer need. Requirements are a good checklist for ensuring a solution meets the customer need, but that only works when the requirements are developed to address the customer need. When requirements are developed focusing on testing the solution rather than quantifying the need we can end up with a mismatch. We could be designing something different than what our customer actually needs. In such a situation the customer has one lever to move the design in their desired direction, and that's to change requirements. Those changes will be late in the project cycle and costly because each will be made only when the customer recognizes the gap.
We can short cut this situation by focusing on customer need to create the original requirements. For instance, if a customer has stated they require a radar with a range of X nautical miles, we need to focus on the why and how. Most radars can't provide a consistent range at all elevations, or in all weather conditions. Meeting such a requirement in all possible circumstances would be very costly and is likely not the actual intent. If we understood the scenario that caused a need for such a radar we could better determine the correct (cost effective) solution. With that solution, we can re-scope the requirement into what is actually needed that will better meet the customer's intended use, or need.
To develop that understanding we need to create scenarios, or concept of operations. Working with the customer we can develop a comprehensive view of how the system is used (rather than what it is composed of). The view is captured in the scenarios or concept of operations and is updated as our joint understand of system use evolves. If we develop our requirements based on this shared understanding of use, there will be less need to change requirements as we proceed through design.
Become the Expert
Requirements also churn when you haven't yet gained the trust of your customer. If they are unsure of your expertise they will use requirements to change your proposed solution to match their desired solution. Unfortunately, no one knows the customer's business better than the customer, so they'll often be right which further erodes your position as the expert. This erosion will motivate the customer to question other design decisions. When they disagree with your decisions, the customer will use their one lever to change design: the requirements.
You can avoid this type of churn by becoming the expert the customer whats to rely on. To do this you need to not only know the technical aspects of the system you're designing, but have a deep understand of how it is used. For example, if you've been asked to provide a sea navigation radar, it's not sufficient to simply understand the frequencies and data protocols of the radar. You need to know how the radar is used in navigation, how it is used in collision avoidance, etc. When you understand all aspects of the radar function and use you'll find it easier to communicate with the customer, and thus easier to maintain their trust and reduce any second guessing.
It's All Connected
The three steps are closely linked. First we build a shared vision with the customer to align our goals. We then elaborate on that shared vision through the development of scenarios and concepts of operations. The scenarios allow us to understand the customer need and in turn create robust requirements that closely align with the customer's need. Finally we use our expertise to build customer trust and reassure them that we are indeed specifying the system they will actually be able to use. These steps help ensure the requirements developed align with our customer's need reducing requirements churn.
-Michael Sepa, P.Eng
5 October 2014
INCOSE Canada publishes an article of technical interest to engineers each week. You can read them all by clicking here.