Part of our jobs as systems engineers is to translate voice of customer needs to actionable requirements and work with our design engineers to ensure the deliverables meet those needs.  Occasionally, there can be an overwhelming number of needs that seem to be high priority and the systems engineer must figure out a way to balance these stakeholder requests with available time and resources. As a super analytical person, I like to apply a variety of analysis toolkits to aide in these types of situations. One method that I’ve found incredibly useful is deploying a Pareto analysis to effectively valuate the various priorities and determine prioritization rankings. This analysis is also a great way to get buy-in to the prioritization list from the stakeholders by ‘tricking’ them into generating it themselves.

If you are unfamiliar with the concept of a Pareto analysis; it’s quite simple!  First, it’s important to understand a Pareto chart.  A Pareto chart is a bar chart where the lengths of the bars correspond to a measurement analysis, most typically - frequency.  The bars are ranked highest to lowest.  Each bar is representative of an activity, project, problem, goal, need, etc.  There is usually a logarithmic-looking line that is indicative of the cumulative total of the frequency.

You may be asking, “what is the actual analysis part and how in the world does this help me get buy in from my stakeholders?”

The analysis is a valuation of the wants and needs of the stakeholders in the context of their own thoughts, opinions, and desires. The beauty is those who have that emotional and financial attachment are the people who perform the valuation, and through the process, they recognize that their own opinion has produced the data set. And data doesn’t lie.  

In the past, I have asked all the stakeholders to write down their deepest desired needs and wants for the system of interest.  I compile the list, grouping like categories together and then have everyone sit down in the same room (not necessary, but makes the analysis easier) and evaluate each want and need against all other wants and needs.  This process forces the stakeholders to choose which wants are most important to them.  I ask – “If you had to choose Want A or Want B, which one would it be and why?”  I then write down the need or want that wins each ‘mini battle’ (Figure 1.)  

The needs and wants are graphed according to the frequency of their wins, generating a beautiful Pareto chart, and pulling the most critical needs and wants towards the top and minimizing some of the desires that are seemingly not as high priority (Figure 2.) (I should note that there are always going to be exceptions to this prioritization process. Things like safety concerns and adherence to regulations should trump all else.)

‍

By completing this process and involving the stakeholders, the high priority tasks fall out and you generally have complete buy in from your stakeholders as they provided their direct input into the process. The completed analysis is a great tool to share with the design engineers (or other personnel responsible for delivering the goals.) Scientists and engineers are inquisitive by nature and can question the rationale for non-obvious priorities, but by capturing the rationalization of choosing Goal A over Goal C and sharing this with the entire team, you can achieve company-wide buy in.  

People are much more motivated when they understand the rationale behind their goals.  And motivated people equal an effective and efficient workplace.  

‍

‍