Part 3 - Stakeholder Maps
In my last two posts, I've talked about the importance of using horror stories and highlighting risks as a way to garner support from the executive suite. In this post I'm going to highlight the need to eat your own dogfood - in particular by drawing up stakeholder maps.
There's a reaction I expect is going through a fair few people's heads right now.
“Yeah, yeah, stakeholder maps.” Does this guy really think we don't know what they are?
I would hope that most modeling team leads know what a stakeholder map is – whether they prefer using TOGAF, ArchiMate, or some other standard. The idea of mapping out the stakeholders for an initiative, and their concerns, is a well-known activity.
But my point is that a modeling practice is an initiative itself, so it will have stakeholders as well. Some of those stakeholders will be outright hostile to the whole idea of modeling efforts. I once encountered an executive who openly said, “None of my next quarter’s targets get helped by what you’re proposing. So why should I want you spending time on this?”
Such difficult stakeholders can actually be a “canary in the coalmine”, in that they can be a warning sign of what others worry about but don’t voice… addressing them can end up handling unspoken objections. More difficult is the stakeholder who is not necessarily hostile but simply needs to understand how you can help them be successful.
So my recommendation is to always create a stakeholder map for the actual modeling initiative itself. In the rest of this discussion, I’m going to suggest how to populate the stakeholder map.
Let’s start from the first principles – to state the obvious, there are really two main parts of a stakeholder map – stakeholders and their concerns.
The first area is likely to be a lot easier. Bluntly, either the modeling lead or the person who brought them in is going to have a good idea of who has an interest in this effort. But there are also other resources out there.
To identify the stakeholders for an effort, the most obvious resource is TOGAF – specifically, chapter 24. It does offer a good set of principles – who can derail your project? Who might want to? Who has expressed an interest (positive or negative)? And so on (there is no value added by simply reciting that chapter).
A secondary resource will be the ITIL standard. The processes and operations that TOGAF identifies also necessarily identifies a list of roles that can inform a list of stakeholders. Thinking about the processes involved is often an excellent starting point for identifying the stakeholders for a modeling effort.
So much for identifying a set of stakeholders. The question still exists – what are their particular concerns? Which is to say, a datacenter manager may be more concerned on low cost of operation, regulatory compliance, staff retention… usually this will be driven by a mixture of the environment (e.g., a datacenter manager in a remote area working for a largely unregulated industry is likely to focus on staff retention over audit compliance).
That said, what is there, that we can use as a starting point for picking and choosing between drivers. Indeed, how do we even identify drivers to select from?
At this point I’m going to reference a third standard, that of COBIT – the ISACA standard for IT governance. This particular standard was revised quite heavily recently, and one of the best enhancements was the introduction of the goals cascade.
To translate this into English, COBIT defines a set of 17 business drivers, based on observation of the most experienced industry thinkers that are in practice, but also defines;
- Questions that might be posed by business stakeholders that imply an interest in a specific business driver
- Mappings from a business driver to an IT driver that supports that business driver
- Mappings from IT drivers to IT process to support all of the above
What this rolls up to is not just a reference model of potential concerns, not just a reference model of IT concerns, but also a standardized way to trace through from stakeholder question to IT activity.
Or to put it another way…
“None of my next quarter’s targets get helped by what you’re proposing. So why should I want you spending time on this?”
“There’ll be this minor impact on your next quarter’s targets… and this significant impact on your following quarter’s targets”.
The important point is being able to know which concerns count. Which concerns to address? A stakeholder map won’t tell you this, any more than a process model will automatically tell you what to change – but it will at least shape your thinking into a useable structure.
So: use stakeholder maps to gain buy-in to the modeling efforts, and leverage TOGAF and COBIT to help you populate them. It’s an extra overhead – but it’s the best way to avoid joining the long list of modeling initiatives that get shelved for lack of support.
If you enjoyed this blog post, check out this free resource for using the standard TOGAF® 9 stakeholder management approach, addressing the four steps of Identification, Classification, Definition and Tailoring the viewpoints for C-Level stakeholders >>