Holistic Methodologies: Odd bed partners (Six Sigma and PMLC/SDLC), but Harmonious Relatives
Voices from Unexpected Places – Part 2, Sources
In the first part of this article we reviewed some familiar ground regarding requirements gathering and some pitfalls you may have already encountered. We also covered stakeholder influence and how you should weight the importance of the requirements you are gathering from those sources.
In this second part of the article we will explore the source of the voices and how they interact in more detail.
Stakeholder or Customer?
A difference between the customers and stakeholders needs to be explained: Customers are users of the product of the project, and can be internal or external. Stakeholders are a broader category that also includes customers. They may have responsibility for controls, or resources that can block or enable the delivery of the product or process. They may be approvers with no specific role in the process who own the success of the product or process.
Sources – Human or Otherwise
Sources may also be passive, or not even human. This includes historical data or data from various listening posts within the process such as defects, cycle times, or positive and negative feedback loops.
Voice of the Customer – VOC
In an earlier article we explored how VOC can be used to map requirements across the lifecycle of the process from supplier to the output to the customer. In most cases we are building the product in service of the customer, or the product is to enable a core business process where the customer may be an actor or recipient of the output. So in most cases the VOC is the governing voice. But!
Know Your Customer
Customers come in different segments too, and should be grouped accordingly. These customers may have differing priorities and may also serve a joint role of customer and supplier.
Is the customer always right? What if the customer is external and you have no access to that customer to evaluate their needs? What if the customer is new or does not understand or know what they want? Does your customer speak in generalities like, "I want it to be faster, easier to use, less error prone?" These generalities can still be success criteria or core tenet deliverables. In Agile they are often referred to as epics, but there are typically very specific requirements underneath to support those core tenets that will have to be gathered elsewhere or further defined with the customer.
Voice of the Supplier – VOS
In the SIPOC example above and in the case where a customer may also be a supplier, it is important to understand the difference between a customer consuming the output and a supplier to a downstream customer. Enter the Voice of the Supplier (VOS)! VOS requirements gathering is found in supply chain analysis. This voice is often ignored because the supplier is just expected to deliver or we find another source.
Suppliers can have valuable insight into how your product should be designed. This may also become a constraint based on what product or services they can deliver. They can also be a partner to save money by engineering their input product to satisfy the needs of your process. The voice of the supplier should not be overlooked.
Voice of the Managed Service Provider
A managed service provider (MSP) is a person or entity whose role is to perform a service that has been outsourced to a person or entity that is specialized in performing that service. The service is typically governed by a contract with delivery and performance SLAs. When a supplier is an MSP, this input becomes even more critical. An MSP is also an example of risk transference to a third party to provide some ongoing service to your company. Your company has chosen to outsource this capability as it is not considered a core competency or it can be done more cost effectively by someone else. However, that may not diminish the criticality of the MSP's role in the process or shaping the product.
Their service delivery role may also be affected by your project. This impact can come from an operational supportability capacity; or, more importantly, they may have skill sets and knowledge that do not exist elsewhere. Your MSP should not be overlooked as a valid voice. Giving them a seat at the table will also help when it comes to deployment and post-deployment support.
Some caveats are that most MSP models are cost-driven and may be generic in nature. Some MSPs keep costs down by standardizing to their internal processes, which may be either complementary or contrary to what is best for your business. Another concern is trust between the MSP and the stakeholders based on current and historical service quality.
Voice of the Business – VOB
How is VOC different from VOB? In a prior article we explored the intricacies of a Quality Function Deployment (QFD). The various rooms within the QFD provided facets of the voices that make up the generic voice of the business. VOC is specific to the customer's needs, but the customer can't always tell you the whole picture—for example, how much value you need to draw from your competitive edge, relationships between the Voice of the Customer and what is Critical to Quality, or the costs of delivering a specific feature set. The Voice of the Business should encompass all of those components. Additionally, the VOB identifies the organizational culture and the business appetite for sponsoring the product or feature being delivered—in some cases, even if a specific feature is considered the most important capability the customer is asking for.
Voice of the Process – VOP
Voice of the Process is typically not a person, and may be passive or active. A passive VOB would consist of historical data from prior deliverables or process executions. An active voice may be current data from each process run, or survey data that is still being gathered. Active and passive data, as mentioned in prior articles, needs to be normalized and managed to avoid injecting bias through variance.
The VOP is a very powerful voice, and in my opinion every bit as important as the VOC. VOP data should be used to validate or refute other voices, either to support or question it. As mentioned above, the truth can be drawn from sources that come to the same conclusion using independent methods.
If the data is normalized it has its own truth, which can be inconvenient if it flies in the face of conventional wisdom or the strong beliefs of powerful stakeholders. It is important to socialize these data—to rationalize and build consensus between the VOC and VOP to validate your path forward. A fishbone diagram can be used to illustrate where the VOC and VOP may differ. Using a form of root cause analysis may also be beneficial for addressing the root of those differing perceptions. This tool can be used for assumption busting in a controlled environment to understand how these differences exist or if there is an inherent flaw in the dataset.
Critical to Process – CTP
Typically CTPs are process input variables. In an earlier article we discussed the formula Y = f(x1, x2, x3 ... xn), where Y is the output and the inputs are a function of the output from a criticality standpoint. The CTPs are those x inputs. Using a Pareto diagram will help identify the criticality and interrelationships of those x's.
What you should take away from this is the impact of changing one of or more of those input variables on the overall output of the product or process. An example could be the impact of taking away an inspection or test: while it may not add to the actual value to the product, it may cause the quality of the product to be diminished.
Critical to Quality – CTQ
CTQs are often a byproduct of CTCs and are typically provided by the stakeholder or customer. They often take the form of what is important or critical to the customer, including product quality and even compliance requirements. CTQs are often very subjective in nature, such as look and feel or an opinion. If engineering tolerances can be obtained, those tolerances will provide the CTQs.
CTQs can also be gathered using a CTQ tree. The CTQ tree is made up of three components that support each other. This tree helps guide you from the need to the driver and ultimately the requirement.
The need can be in the form of a wish, desire, or high-level epic. For example, I want the application to be more intuitive or run faster.
The drivers are criteria that identify how well the delivery of the need matches the customer's expectation. It can also be the reason the need is important to them. Using the example above, the driver to make the application more intuitive or run faster can be new staff coming on board or feedback that the system is difficult to use. It can also be identified from data entry errors.
Performance is also subjective unless specific use cases are developed and measured. Drivers in this case would be improved throughput or hardware utilization. These criteria can also provide additional information to help measure customer satisfaction.
Requirements are those specific performance standards to which the product must conform to either to satisfy the customer needs or meet an engineering tolerance. In the example above a specific screen design or specific task performance metrics would be the requirement. This requirement should be testable through the quality control of the product.
Critical to Customer – CTC
Critical to Customer (CTC) simply means what requirements will satisfy the needs of the customer. CTCs are not always actionable; they can be very subjective in nature and may require interpretation. They may also include CTQs.
It is important that CTCs are captured in the language of the customer (VOC) and steps are taken to translate those CTCs into CTQs using the tree structure above. Those CTQs should then be validated with the customer to make sure that nothing was lost in translation. We explored the translation of CTCs into CTQs in greater depth in the prior article on Quality Function Deployment
While it may be intuitive to ask for everyone's opinion when gathering requirements, I hope that this has given you a framework and set of tools to take your requirements to a higher level of maturity and credibility. Hopefully you can now listen to voices from unexpected places. You can now understand weighting and how voices can be complementary, as well as how to address their often contradictory nature.