A couple weeks ago we wrote about Outside-in Software Development, by Carl Kessler and John Sweitzer. One of their ideas about stakeholders and goals has got us thinking about traceability.
Types of Stakeholders
Carl and John present a framework for understanding stakeholders that groups them into four categories – principals, end users, partners, and insiders.
- 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.
In the book, they go into more detail on the different types of stakeholders. One interesting thing that jumped out at me is something the authors mentioned about competing agendas for different stakeholders.
Support Or Not
Carl and John mention that end users have goals that usually, but not necessarily, are aligned with the goals of the principals. This makes sense – someone responsible for the ROI of an improved process would likely have some aligned goals with the person who uses the software within that process. Users are represented with personas, and those personas articulate goals – both personal and practical. This is one are of stakeholder goals. The user’s practical goals are (or should be) aligned with the goals of the principal responsible for the results of what the user does.
Tracing Among Goals
We use tracing to represent the supporting relationships between requirements artifacts.
The diagram above shows the general relationships between different types of artifacts. The following diagram shows how this tracing can incorporate the needs of users.
The top portion of this diagram accentuates that there is tracing within a requirement type. That is – goals can support other goals. From the perspective of stakeholder analysis, Carl and John describe it as alignment.
When we think about traceability, a good way to represent these aligned goals is through subordinate “supporting” relationships and traceability. Carl and John mention that the challenge is to identify conflicting goals and adjust prioritization accordingly (not all stakeholders are created equal!). This is great advice that resonates. The authors also point out that you need to be careful to not ignore a user goal that is critical to the achievement of a principal’s goal.
By tracking principal goals as corporate goals, and end user goals as practical goals, we can identify when goals are aligned (and supportive). We can also identify when goals are unaligned. This is exactly the visibility we need to address the two key elements the authors suggest we look at. Rewording into representation-centric maxims:
- Don’t ignore persona practical goals that support principal (corporate) goals.
- Question persona practical goals that are not aligned with principal (corporate) goals.
Conclusion
Outside-in Software Development continues to be a good read with good ideas. Understanding the relationships between the goals of principal stakeholders and end user stakeholders is one of those good ideas.
Using traceability to manage and communicate our understanding of those relationships will help us to make good decisions about supporting and prioritizing those goals.
For those of you who’ve read this far:
A cow is a steak holder of sorts. Couldn’t resist. Also thought about a vampire picture – would that have been worse?
That’s a very very … very bad joke.
Interesting diagram. It clarifies the traceability between goals and software system. However, in my opinion, the direct translation of organization goal towards use case/requirements is a dangerous one.
In my experience, it leads often to “task based applications”. I wrote about a new possible requirements framework here:
http://process-transformation.blogspot.com/2007/10/james-triggered-me-again-around.html
And about the dangers of the task oriented application here:
http://process-transformation.blogspot.com/2007/10/need-for-new-requirements-approach-and.html
Regards,
Roeland
Craig – big grin!
Roeland – I might agree, not sure – I need more caffeine, and some clarification. How are you defining tasks?
I ask, because your “task-based is bad” position sounds a lot like my “feature-based is bad” position, but for slightly different reasons.
Feature-based is bad because it lacks context. You are unlikely to create a decent experience (usability), diluting the effectiveness of the feature. Further, without context, you are unlikely to optimize how you invest in development – will you invest in the most valuable features, or the ones that are easiest (or riskiest) to implement?
If you’re defining tasks at a granular level where they are conceptually no different than features, then I agree. However, I always think about defining things in terms of use cases that achieve (or support) corporate goals. This level of chunking / abstraction keeps things tangible, and provides clarity of context. It also gives us the opportunity to clearly associate a capability (the ability to sell a product, the ability to optimize pricing, etc) with the goal(s) it supports.
Would love additional insights if you’re still here and following the thread. Thanks in advance, and thanks in arrears for the previous comment!
Sorry for the delay, finally some time to catch up.
Yes, I think your concept of feature is the same as my task concept. Applications that provide functionality without a clear linkage to a context (which in my eyes, in the corporate world would be often the case), are not process aware.
I see many leaders slowly starting to say: between corporate goal and results are many things, but process is one of them, and one of the vital ones.
Now going back to requirements: If you go from corporate goals directly to use cases, in my view, you skip a step. And skipping this, increases the risk of creating feature based solutions.
From corporate goals it is better to start with process: what processes are needed to reach these goals. “Be nr 1 on market XYZ with product ABC” – well, we will need to market, produce, sell, invoice and service our products. And our business model will be XYZ, taking position ABC in the value chain in our industry. From this process architecture, it is much simpler to start deriving use cases.
Process is not equal to use case. A use case is something that defines the requirements for a specific actor goal, using a certain solution (informal definition :-)). A process is more – more steps, more stakeholders, and possibly multiple automated solutions.
So when looking to a process, consisting of steps, collaborations, communications, decisions, etc, etc, for each of these, you might define one or more use cases. Now with much more context than before…
So…
corporate goals -> processes (& products & information) -> use cases…
Feedback most welcome!