In our earlier article about managing stakeholder goals, we looked at the relationships between principal stakeholder goals and end-user stakeholder goals. We also showed a way to trace those dependencies. But that approach does not provide us with any insight about the alignment (or lack thereof) between differing goals. This article explores a means to visualize those relationships.
Principals and End Users
We identified four classes of stakeholders in our previous article on managing stakeholder goals.
- Principals – the business sponsors for a product or project. These folks have business goals they are trying to achieve. Your mission is to understand those goals. You also need to recognize that they may be moving targets, and be prepared to adapt to those changes. And we need to understand why they want what they want.
- End Users – the people who ultimately interact with the software. The best software development processes are focused on satisfying the end users. And a lot of authors are out there teaching us how to do that, although none perhaps as visibly as Alan Cooper.
- Partners – people who are neither principals nor end users. These are the folks who don’t directly benefit from your product, don’t use it directly, and didn’t help create it. But they are responsible for helping your product live, thrive, and interact with other products. Think IT people, keeping your system running, and keeping other systems talking to it.
- Insiders – the people who define the product. Your (internal) team. Not only product managers and developers, but business folks, marketers, testers, support staff, finance, etc. The people creating a product influence what ends up being created. And they are stakeholders in a narrow scope – they are affected by the creation and ongoing support of your product.
We alluded to the possibility that principals and end users have goals that may or may not be aligned with each other. When we manage those goals via traceability, we can clearly see when a user goal supports a principal goal. What we can’t see is the magnitude of alignment between the goals. We also have no insight into conflicting goals.
End User Goals
You can identify end user goals with the following approach:
- Identify the actors that interact with the software.
- Identify the personas that represent those actors – thus avoiding the elastic user syndrome.
- Develop an understanding of the personal goals of the personas – and by extension, the actors through ethnographic research.
We write about goal-driven, or goal directed requirements a lot. With principal stakeholders, who are not direct users of the software, goals are usually related to the metrics by which they are judged. These are often metrics that tie to ROI for their employer, and focus on the principal’s sphere of influence. Examples might be reducing costs in their department, or growing market share.
Sometimes, the user’s goals are aligned with the principal’s goals, and sometimes they are not.
End User Goals
Imagine you’re working on a product for a call center. Following the example above, you identify one of the actors as a call center rep. You then study the reps and develop a persona that represents them effectively. You identify Fred Jackson as your persona
You spend time understanding the desires of that persona and you develop a set of personal goals. You relate those back to their job and find the following set of goals:
Fred wants to earn a bonus. In the call center, this translates into
- Reducing the time the rep spends on each support call.
- Reducing the percentage of “unsolved” calls that the rep has to escalate to a more experienced (tier 2) rep.
Fred also wants to earn a promotion from his current “tier 1″ role to a “tier 2″ role. Tier 2 reps only field the calls that the tier 1 reps can not solve. These reps earn more, and only work on the “hard” problems. This translates into
- Increasing the rep’s level of knowledge.
With this understanding of the goals of the end user, you can now look at the goals of the principal. In our example, the principal is the manager of the call center – Jane. Jane’s performance is measured by looking at several operational measurements of the call center. Based on those measurements, Jane’s goals are as follows:
- Reduce Employee Training Costs (Low priority)
- Reduce Call Center Labor Costs (Medium priority)
- Increase the Satisfaction Rating found by third party surveyors of the callers (High priority)
- Reduce Call Center Overhead Costs (Medium priority)
In an ideal world, the prioritization will be based purely on ROI. In the real world, the priorities, in the opinion of this principal, will be aligned with the principal’s goals. And those goals are often reflective of how the principal’s performance is evaluated.
You can see some obvious alignment – reducing the time spent per call will reduce labor costs (either by handling more growth with fewer new hires, or by reducing the workforce, or by freeing up time for the reps so that they can invest it in other areas). What you can’t easily see is when the goals are unrelated – or when the goals are potentially conflicting.
You can create a grid that lists end user goals along the side, and principal goals across the top. Using the examples above, you would get a graph that looks like the following:
Each actor goal has a row in the table, and each principal goal has a column. The number in the intersection represents the alignment of the two goals. Positive numbers represent positive alignment, negative numbers reflect goals in opposition, and a zero indicates that the two goals are unrelated.
In the table above, the “Reduce Time Per Call” user goal is unrelated to the principal’s goals of reducing training costs and reducing overhead costs. The “Reduce Time Per Call” goal has a positive alignment with the goal of increasing customer satisfaction, and a strong alignment with the goal of reducing the labor costs for the department.
In the example above, the user goal of increasing knowledge is in opposition to the goal of reducing training costs.
This does not mean that one goal must be sacrificed for the other (although that might be what you decide to do). What it indicates is that the most obvious approaches to achieving the goals are in opposition. A negative number is, in effect, a call to arms to invent an approach that makes a positive alignment (killing two birds with one stone).
We’ve shown that personal goals can contribute to design decisions in the software development process. Your challenge is to come up with an approach that eliminates the negative relationship and creates a positive one. You have to make some of these decisions before completing the software requirements specification.
For example, you could choose to design software that walks reps through a decision tree when addressing a caller’s needs. You could include notes, background data, and statistics in the user interface that help a rep learn while doing. This will have little impact on the time it takes to resolve a call, without introducing extra training costs. This approach would turn the goals into complimentary goals.
What Do You Think?
What do you think about this approach?