If you think of a transformation as a journey, then the first stage/Realize loop is all about getting our bearings: where are we headed and what is it that we want to achieve? We call this first loop the big picture. Essentially we focus on strategy elaboration & stakeholder mobilization, on business blueprint & operating model, and on migration strategy & value management. We pay some (but not too much) attention to governance and support. In a four-day workshop, we get a good sense of what the transformation will look like that is ready for sign-off. This should get the ball in play in the next two iterations. 
 
The second stage/Realize loop is all about getting the organization ready for executing the transformation. We call this loop plan for change. When embarking on a transformation journey, we not only need a solid plan, we also need to get the people ready. We live by the statement that: 

In an increasingly digital world, you have to put the people first. 

In light of the objective for this phase, this means that we must work on two tracks. On the one hand, we need to get a deeper understanding of what we want to achieve in the first “real” change iteration. We do this by going through the adaptive architecture & design phase and more detailed roadmapping in the migration strategy & value management phase. On the other hand, we need to make sure people are ready to work on the transformation. Often, we see that people do transformation work “on the side” and may require new skills. We help to ensure that there people have enough time to do transformation work, that they have the right skills (training/coaching), and help to take care of other obstacles that may occur. These things typically take time, hence the 4-week time period.  
 
With the preparations done, we are (finally) ready for execution. As stated before:  

Vision without action is a daydream, action without vision is wasted energy. 

In other words: we need vision and action and now the focus shifts to the latter. We may have to revisit the result from the previous phases, but the focus should on execution. Four months is a decent amount of time and typically that is needed to get some results. We’re not only designing but mainly focus on achieving change: in processes, data flows, roles and responsibilities – whatever is needed. This again may require both (top-down) governance and (bottom-up) support to make sure that we transition smoothly to the new reality.  
 
As a final remark for this section, when we start on the execute iteration, we often get ready to do another iteration of plan for change at the same time. That way, we can easily slide into a second execute iteration and keep going, one step at a time.  

Three cases 

To further illustrate the tailoring/adaptation of Realize to a specific situation, I will discuss three cases that I’ve worked on. I have permission to talk about these cases, but not to share actual project results. Therefore, I have decided to keep the cases somewhat anonymized. Feel free to reach out if you want to know more.  

Cross-selling insurance with lease 

This case is from a few years ago and took place at a financial organization in the Netherlands – mainly in the leasing business. An executive came in our office and suggested, “We want to start cross-selling insurance with lease. Tick-box on the website and that should be it. Can we do it?” The interesting thing is: we did not use Realize explicitly, but I used it as guard rails in this project.  
 
Usually I would start a team and go through the big picture iteration of Realize. This time, we barely had the time for it: I had a few days to get some answers for the executives. I did round up come colleagues and instead of giving answers, we started asking questions (strategy elaboration) such as: what kind of insurance are we talking about? Do we want to become an insurer, or an intermediary? And are we doing this in one country, or in many countries?  
 
The first response was, “you ask too many questions – I just want the checkmark on the website!” Later in the project, management acknowledged that they were the right questions. Once we understood that we were going for a start-up (one country) / scale-up (multiple countries) scenario, it wasn’t so hard to come up with a blueprint and roadmap that got us started.  

IT-direction for Dutch harbor 

This project is more recent, and started with a phonecall that boiled down to: we believe our IT process/people/systems are not good enough if we want to achieve our new strategic direction – we need help. For this project, we “worked by the book” even though we combined the big picture and the plan for change iterations somewhat. Some highlights from the project setup:  

• We assembled a mixed team with three consultants and six people from the organization itself. This included the CFO, who was our sponsor.  
  
• We designed a series of workshops to redesign business/IT processes, the team, and design a blueprint that will help to improve the IT landscape in light of business vision.  
  
• This is not a big organization, and the team had a lot of work on their plate already. Therefore, we set a rhythm of two workshops (1.5 days) per week over a period of 8 weeks.  
  
• We roughly followed the pattern: (1) set high-level goals that we want to achieve, (2) analyze current situation and identify pain points in light of the goals, (3) design a business blueprint based on principles, (4) gap analysis, (5) roadmaping and designing project charters.   
  

We were able to execute the plan as designed. The organization stopped several initiatives to make sure we had enough focus to do this well. The fact that we had the CFO in the room ensured that a) everyone was paying attention, b) we had the right focus, and c) we had all the information at hand that we needed. At the end of the assignment, we organized sessions to update all the teams on the new vision as the basis for decision making. That got the wheels in motion. The organization is still in the middle of executing this transformation – mostly according to plan. 

Becoming more data-driven 

We’ve done several projects where we helped organizations to ‘become more data-driven.’ The interesting thing is: a lot of organizations claim they want to do this but are unsure what it actually means! It almost always makes me wonder: why would you want to become something that you do not understand? Here, I will relate the story of a pension provider that we helped a few years ago.  
 
In this case, we made a team with two consultants and about a dozen people from the organization itself. We found that a lot of professionals had strong opinions on terminology, on what the current situation looked like, and what the future should look like. Everyone was adamant that “they were right and the others are wrong.” This motivated us to get started with a round of training. By training everyone on the DMBOK-framework for data management, we at least got alignment on terminology (Henderson et al., 2024; Van Gils, 2025). This also helped to make people see the perspective of the other team members and that, in turn, helped to make the project go more smoothly.  
 
With the training under our belt, the project went fairly smoothly. We analyzed the objectives and used that as a basis to assess the current maturity of the organization. The short version: it was poor. This shared understanding helped us to design a realistic view / blueprint that was not too far in the future and focused on the foundational elements that were needed (governance, data integration, data quality management, meta-data, etc.) We agreed that it would be good to work on this foundation before attempting moving on to value-creation use-cases. This is unlike our usual recommendation where we attempt to balance foundational work with value creation, but here it seemed necessary to implement that tactic. We also made a roadmap and, after approvals were finally in several months later, did several more rounds of training to kick-off implementation.  

Conclusion 

In this post, I discussed the way we use Realize as a way of thinking/a philosophy (as opposed to treating it as a fixed method). I introduced the 4-4-4 method which helps to structure a transformation in three distinct phases and then illustrated how we do this in practice with three cases. Each situation was a transformation, and each context was different. Each time we adapted to what we felt was needed based on our experience and the needs/insights of the customer. To quote a teacher from back at the university (prof. dr. Willem-Jan van den Heuvel), each situation and each project setup was “vaguely the same and precisely different.” It would be nice if there were clear heuristics and guidelines on how to do this but, in my opinion, there is no substitute for experience in designing these transformation initiatives.  
 
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 

• Bossel, H. (2007). Systems and models: Complexity, dynamics, evolution, sustainability. Books on Demand GmbH. 
  
• Forrester, J. W. (1968). Principles of systems: Text and workbook chapters 1 through 10. System Dynamics Society. 
  
• Henderson, D., Earley, S., & Bradley, C. (Eds.). (2024). DAMA-DMBOK: Data management body of knowledge (Second edition, revised, first printing). Technics Publications. 
  
• Meadows, D. H. (2008). Thinking in systems: A primer. Chelsea Green Publishing. 
  
• Van Gils, B. (2025). Data management: A gentle introduction: balancing theory and practice (2nd ed.). Van Haren Publishing.