The previous post described the SPIN methodology and showed how it is a highly structured way to establish a chain of reasoning to establish business needs. Now, in enterprise modeling, there’s an established way to record needs and dependencies – motivation models. So now let’s look at how the SPIN model has synergies with them.
Summary: The SPIN (Solution-Problem-Implication-Need) methodology that is taught to solution sales representatives turns out to have a natural synergy with motivation models as used in enterprise modeling. This means that you can use a motivation model to structure your conversations with stakeholders while applying the SPIN approach.
There’s a variety of standards out there that provide ways to model motivations; TOGAF has the motivation extension, the OMG has the Business Motivation Model, and so on. I’ll be using the ArchiMate motivation extension in this article. The basic schema is shown below.
So, Stakeholders have Drivers that influence Assessments, which influence Goals, which influence Requirements and other Goals. So how does this relate to the Situation-> Problem-> Implication-> Need paradigm?
The Situation relates to the Driver. A driver is defined as something that creates, motivates, and fuels the change in an organization. For example, the regulatory environment or the mission of the organization, could be drivers. How the driver is met is modeled by the Assessment – “An assessment is defined as the outcome of some analysis of some driver.”
In our discussion, the problems that we identify translate to Assessments. Not every Assessment in a motivation model is a problem, of course. But some are and so this is how we model the problems that we have identified.
Now we can look at what the impact of the assessments are – what practical prescriptions do they feed into – and these readily map appear as goals. To quote the ArchiMate specification, “A goal is defined as an end state that a stakeholder intends to achieve.” Just as an implication can lead on to a need, but also on to another implication, so a goal can influence a requirement or a further goal that may even influence another goal which in turn influences a need.
Which brings us to how we model needs in our mapping of the SPIN methodology to an ArchiMate motivation model. “A requirement is defined as a statement of need that must be realized by a system,” says the ArchiMate specification, making the mapping fairly explicit.
So let’s recap. We can establish the Situation, expressed as a set of Drivers (which ones are important could vary from stakeholder to stakeholder), which is affected by a number of Problems, appearing as Assessments. These Problems have implications for the business, expressed as Goals, which in turn cause the organization to have Needs, expressed as Requirements.
So how to use this? First of all, a picture paints a thousand words, so it becomes much easier to walk an executive stakeholder through this approach when it’s shown as a diagram. Unfortunate - perhaps. Frustrating – probably. But true nonetheless. Second, it serves as a reference to come back to and refresh understanding of why the initiative is being undertaken in the first place.
In the last two posts, I’ll consider two real world examples of applying this approach.