REALIZE Blog series Fact sheet Strategy Elaboration & Stakeholder Management 
 

Introduction 

This blog is part of a series of posting on our Realize approach to digital transformation. So far, I have laid the (theoretical/philosophical) groundwork for discussing each of the phases in turn. The purpose of this post is to give an overview of the first phase: strategy elaboration & stakeholder management in the form of a fact sheet. I will discuss (1) the goal for this phase, (2) the difference between doing this at the enterprise level and doing this at the level of a project, (3) several techniques that can be used in this phase. I will end with (4) final considerations and a conclusion.  

Goals 

In previous posts in this series, I defined digital transformation as: 
 
Digital transformation is a process that uses (digital) technologies to fundamentally change the business model of an organization, its processes, and resources in order to improve business performance. 
 
And I have defined architecture as: 
 
Architecture is a conceptualization of the fundamental organization of a system and the principles guiding its design and evolution. It can be represented as a set of artifacts are intended to help achieve some level of coherence in the system. The artefacts are created by an architecture capability. The architecture, as expressed through artifacts, can be implemented.  
 
I have made the case that both are subjective notions. Different stakeholders have different ideas of the (current) business model and architecture of the organization. They may have different views of what should consitute the new business model and what “improved performance” means in practice. I have also argued that Realize is built on a pragmatist philosphy where:  

• We accept that reality constantly changes and understanding is evaluated against usefulness in new situations. 
  
• The best method is the one that solves the problem. It is all about finding out to achieve some change. 
  
• Combination of quantitative and qualitative methods: whatever works.  
  

We firmly believe that a sufficiently good, shared understanding of (1) the current organization and (2) the goals regarding the future are necessary for a successful digital transformation initiative. This should be the basis for onboarding stakeholders and getting enough alignment to embark on the transformation journey. Therefore, the goals for this phase are:  

• Goal 1: get a shared and approved understanding of the goals for the digital transformation journey.  We should be able to answer questions such as: what is it that we are trying to achieve? What is in/out of scope? Why did we make these choices? What are the trade-offs?  
  
• Goal 2: get enough alignment between stakeholders to embark on a successful transformation initiative. We should be able to answer questions such as: who are the main stakeholders here? What drives/motivates them? Which goals do they approve of, and where are they struggling?  
   
  

Note the repeated use of the term shared. To us, this means that we collect data and present them for all relevant stakeholders to see. We try to create a safe environment where everyone can review and state their opinion about this data. This may sound trivial and perhaps it is more common in academic settings. In real organizations, we see that siloed cultures, trust-issues, politics, and power games sometimes get in the way.  
 
Note also that we emphasize alignment between stakeholders. To us this means that stakeholders acknowledge the selected goals and commit to achieving them. In some cases, there can be a difference between someone saying they agree but still showing different behavior and therefore we acknowledge that there is more to this than “getting sign-off on a piece of paper.”  

Two settings 

The Realize approach is typically used in two settings that may seem the same but do have different characteristics. I will only recount them briefly here:  

• Digital transformation of (a major part of) an organization. In this setting, there are typically a lot of unknowns. A transformation initiative may impact everything and everyone in the organization. This tends to fuel uncertainty and sometimes even stress -often leading to political games and power struggles. Getting alignment of the shared future is difficult and it is hard to predict how people will respond. Every vision of the future and the effect of interventions in the organization is a mere hypothesis. An effective strategy is to ensure constructive discourse about the transformation, attempt interventions, carefully monitor responses, and adjust accordingly.  
  
• A (major) project or program with a digital component. In such a setting, there are still unknowns, but it appears that the level of uncertainty is not as big. When embarking on a project, there tends to be at least some (shared) agreement on what we want achieve (even though the how remains elusive). A more constructive and to-the-point debate may arise particularly since the scope of the initiative is better known. An effective strategy is to develop a shared vision that serves as a hypothesis for the desired future, and work from there. 
  

More information on working with different types of settings and response strategies can be found in the Cynefin framework (Snowden & Boone, 2007; Hasan & Kazlauskas, 2009). A full discussion is beyond the scope of this blog post. Suffice to say that we believe that digital transformations take place in the complex domain whereas projects may have elements to them that are in the complicated domain.  
 
For the strategy elaboration and stakeholder management, it makes a difference which setting we are in. As a rule, the more uncertainty there is, the more we emphasize the need for constructive dialog and careful exploration. Everyone’s opinion is a datapoint that we must carefully consider. All data that we can collect “objectively” will help, too. Getting all data points out in the open provide a good baseline for the constructive dialogue and decision making in subsequent phases.  
 
A more elaborate discussion on the “art” of strategy elaboration and stakeholder management is, unfortunately, beyond the scope of this post. The brief introduction serves as a backdrop for a more technical discussion where we illustrate the techniques that we tend to use in this phase. There, too, we will have to be brief and refer to other materials for more information.  

Techniques 

Three horizons 

Different versions of the three horizons techniques are in use. It is unfortunate that they all go by the same time – but that is not something we can easily remedy. I would like to credit the creator of this version – but I’m not sure who/which company came up with it (If you know: do send me a note!)  
 
The objective of this technique is to explore the goals for an initiative and group them in three categories:   

• Improvement: which improvements to the current situation do we envision? What would we like to achieve with this and why? Example: streamline the customer onboarding process with first time right principles.  
  
• New developments: what ‘new’ things do we want to achieve? What are things that we do not already do/have that are relevant to us, and why? Example: use AI smart assistants to enhance customer experience.  
  
• Trends: What trends are on the horizon that we want to consider, but do not yet know whether they will end up impacting our improvements or new developments. Example: biotech, quantum computing, etc. Note that these are “just” technologies and we don’t know where/how/when we will use them.  
  

With a clear map of our goals – even when they are not completely clear – we have a good tool for having a discussion at the more abstract/strategic level: where are we going to invest? Are we cautiously moving from the current situation to a future situation (suggesting horizon 1 emphasis) or are we boldly moving to some new reality (suggesting a horizon 2 emphasis).  Getting clarity here tends to reduce stress, improve alignment, and provide a sound basis for further analysis.  

ArchiMate motivation  

ArchiMate is an architecture modeling notation. It has been around since 2003 and has been adopted by The Open Group (side note: whether it is indeed an open standard remains to be seen). In the past, I have done quite a bit of research on ArchiMate that was published in book form as well as in peer-reviewed articles. Even more, I have been teaching ArchiMate at the university/Antwerp Management School for years and I believe I know the language well. Before diving into the motivation-aspect of ArchiMate, I would like to clarify a few things: 
 

• Do not confuse the language ArchiMate with the tools that implement it (e.g. the opensource Archi tool).  
  
• Do not assume you have to use every concept in the motivation aspect of ArchiMate. Pick what is useful in your setting. 
  
• Don’t let tooling distract you. We find that low-tech solutions with sticky notes or whiteboard magnets work best. Modeling is a team sport and contact sport.  
  
• Force yourself to concentrate on the big picture (and write down detailed observations for later use). 
   
  

With these warnings under our belt, we can give in on an overview of how the motivation aspect in ArchiMate works. The idea is to model the “motivation for embarking on a transformation” using concepts (boxes) and relationships (lines between boxes). The concepts (more precisely put: the concept types) are stakeholder, driver/concern, assessment (how well are we doing regarding a concern), goals, outcomes, and several others.  
 
The models that are created to capture the motivation for a transformation can be come quite big and messy. That only makes sense if you think about it. Assume you have somewhere between 6-10 goals (from the three horizons analysis) that you will focus on, then you will easily impact 10 stakeholders, each with their drivers. This alone might add up to 25-35 “boxes”, let alone the “lines” between them.  This is why I believe that the process of modeling and the story that a model tells is more important than the actual diagram that comes out of the modeling process.  
 
The results are interesting for further processing, though. An analysis that I commonly make is to create a cross-table with the stakeholders in the rows and the goals in the columns. In the cells, I can then add nods (or use colors) to create visual that helps me tell a story about the motivation behind a transformation. Also, the stakeholders can be further analyzed in a stakeholder map.  

Stakeholder map 

The third tool that I find indispensable is the stakeholder map and I use it in various shapes and forms. The idea behind a stakeholder map is to explore the intent/expected behavior/expected disposition of various stakeholders that are involved in a digital transformation initiative.  
 
The “classic” stakeholder map is a 2x2 grid with two dimensions. On one of the axis, you map out how much power (ability to influence the outcome of an initiative) a stakeholder may have, and on the other, you map out how big their interest is regarding the outcome of the transformation initiative. This creates four groups of stakeholders. The “high high” group tends to be the group that is key to the initiative. The stakeholders with a lot of power but low interest, or those with low power but high interest, each deserve a separate approach. The “low low” group tends to get less attention. Sometimes, the power grid is enriched by specifying (color, smileys) if we expect stakeholders to have a positive or negative disposition towards the transformation initiative.  
 
A more interesting approach to stakeholder mapping  can be found in (Walley, 2013), referring back to research from the mid 1990s. Its main structure consists of three overlapping circles creating a venn-diagram as follows: 

With this approach, you potentially create seven different groups of stakeholders to create a more nuanced overview of “who sits where”. This, in turn, provides a good basis for deciding who to involve in what capacity in your digital transformation initiative. 

Whichever approach you take, know that the stakeholder map is a means to an end. It helps you to decide who you want to engage in what way for your transformation initiative. 

Parting thoughts

The objective for this posting was to give an overview of the strategy elaboration & stakeholder management phase in the Realize approach. I’ve discussed the two main goals, gave some theoretical background, and discussed three of the techniques that we tend to use a lot. A final word of warning seems prudent.

In many transformations/projects that I’ve been a part of, there was a tendency to “get busy fast”. Once we get started, we should get results soon, right? The (positive) energy and drive to get quick results is laudable but always productive. It always puts me in mind of a quote by Martin van Battum, “Vision without action is a daydream, but action without vision is wasted energy.” It is important, in my mind at least, to get a sufficiently good understanding of the playing field before we embark on a transformation initiative. 

The second warning has to do with assumptions. Typically, we engage a group of stakeholders when going into this phase. We look at the world and do our analysis. We capture the outcomes on flipcharts, whiteboards, sticky notes, and whiteboard magnets…. and forget that they are assumptions. To illustrate, we may think that a stakeholder has a certain concern – but how can we be sure? Did we check it? We may think s/he is positive or negative about some goal but did we really check it? The warning is: verify your results or at least be weary of confusing the map for the territory. 

The main/corresponding author for the Realize series is Bas van Gils. He can be reached at bas.vangils@strategy-alliance.com. If you have thoughts of questions, then feel free to reach out.

References

• Hasan, H., & Kazlauskas, A. (2009). Making sense of IS with the Cynefin framework. PACIS 2009 Proceedings, 47.
• Snowden, D. J., & Boone, M. E. (2007). A leader’s framework for decision making. Harvard Business Review, 11(68), 68–76.
• Walley, P. (2013). Stakeholder management: The sociodynamic approach. International Journal of Managing Projects in Business, 6(3), 485–504. https://doi.org/10.1108/IJMPB-10-2011-0066