How to keep your IT production process up to speed

Turning business ideas into IT is something we have already been doing for many years now but unfortunately, statistics tell us that our worldwide success ratio is no higher than 25 to 30 percent. In my storyline I mention many reasons for underperforming, but understanding and taking IT production seriously at management level is #1 by far. Often it goes hand in hand with lack of prioritisation, which means everything is equally important. And when expected outcomes are overdue, we just think we can solve it by increasing control and staff; more people will probably do the job. For this reason, we see IT organisations growing and growing but not delivering better results.

We need fact-based prioritisation instead of moving forward based on control, powerplay, and politics!

The effect of not prioritising is that we intend to give every existing product the same priority and this means we will constantly move them forward all at the same time. As long as we are just updating (maintaining) our products this seems not too hard. Unfortunately, there are many other reasons why we constantly need to act which are more complicated. Let me give you some examples:

• We need to redesign and realign our product portfolio with our strategic intention in order to meet our new goals
• The product experience of customers and/or business users is not sufficient anymore;
• A business unit has a new insight to conduct work more efficiently and wants to change the business process of the product under their supervision;
• Technology is end-of-life and we need to migrate to our new goal architecture, and also be capable of using new technology. Within this new goal architecture, artificial intelligence is available to increase the performance of business product ‘supporting capabilities’ enormously, and routine work will become less;
• For certain products we are using an old technology framework, and the most experienced people who were working on it are leaving for retirement, but replacement is hard to find. Anyhow, why would we replace colleagues if the technology used is outdated?;
• We have outsourced an IT system which does not comply with our usability requirements anymore and the supplier does not manage transience of the system fast enough because shareholders of the outsourcing company do not like to invest. Why didn't we see this coming, they seemed so pleasant and willing when we offered them the chance to deliver this wonderful service to us, didn’t they?;
• Oops, we are maintaining a system that is hardly being used because of the small population of businesses it still needs to support. Turning it off is impossible because of legal responsibility to keep on supplying the businesses until the population does not exist anymore. Could we move it to our goals architecture easily?;
• We have major data quality problems that built up over the years and moving forward is getting almost irresponsible. Yes, we are pretty late and moving to our new goal architecture is essential, but did we build up enough experience with it to start transformation at scale?

Then often, from a situation of misunderstanding on how to manage the transience of an IT-landscape, a manager with great insight and strong words comes along with an apparent knowledge on how to solve these problems. He proposes a renewal program and building from scratch a completely new IT landscape of a so-called greenfield approach, and when he is ready to migrate to his promised land business can just continue as usual but with a disrupted IT support.

Of course, he did not understand he was going to play billiards (for a not-so-necessary explanation of this metaphor, please read previous posts) and that all the high dependencies he created in his plans, risk logs, and planning did for the most part not come together over time in a planned and expected outcome.

After panicking and flying in, his enterprise architects asked him why their models had promised paradise, but after many years and high cost they still had not reached it. Of course the manager got fired and the next one came along and was received as the hero to solve the problem. After months of in-depth analysis together with strategic partners he went on stage in front of the whole organisation, shaking his head as if his dog just died, telling the audience he found what he already expected. He needs to kill the greenfield program and he thanks everybody for the blood and sweat delivered.

Digital Transformation is a lifestyle and therefore a fundamental choice to jump on a bicycle for an endless journey while making and repeating a lot of mistakes and finding solutions for conducting your digital transformation because you managed to stay upright. It is like reaching a state of zen because of deep understanding and insight combined with an overview of your landscape. The fact that you managed to keep upright without falling throughout conducting your Digital Transformation journey on a bicycle, managing thousands of small dependencies, results in the dopamine you deserved.

Staying upright on a bicycle because the knowledge system (bicycle plus human) learned how to do it does not make you a high performer yet. We need information about the road behind us to analyse how we can approach the road before us, ride it more efficiently, and be prepared for the next time when we take the same or a similar road. When we know a bit more about the road ahead we can adjust the capabilities of our bike to perform better when we arrive. Also, when we are cycling we need to know the status of parts of our bicycle so that we can carry out timely maintenance without our performance deteriorating.

Cyclists have a lot of equipment nowadays, like Google, to find out everything about frames, performance monitoring apps, health apps about what to do when we are not cycling. We can even cycle at home, simulating conditions as we like.

A Digital Transformation cannot move forward without a dashboard that is constantly based on facts, telling us what the status is of our business capability performance along with the status of our IT landscape. So based on the substantive governance from Story 10: Governance to create the ultimate state of flow (2-3), we know when to update or innovate a business product or renew to technology and start building the infrastructure underneath it. And when we have met the prerequisites in all aspects of our organisation and goal architecture to start cycling, we will never need big transformations anymore. This means we will move forward with an ever-changing product portfolio and changing technology households accordingly, and the performance of our capabilities tells us how good our cycling performance is.

As explained, there are multiple reasons why an organisation wants to change (update or innovate) a business product, underlying technology. Or even build a new business product. While being in flow on your bicycle in the governance of the organisation (Story 11: Governance to create the ultimate state of flow (3-3)), based on priorities we keep on turning updates (changes) and innovations (new business idea) into IT.

The question we constantly ask ourselves is: I would like to turn a business change or idea into IT and when it supports the outcome as foreseen I am going to actually use it. Depending on how we enter this process we will more or less use every part of the IT production process every time again and again in the same manner. And this is what I will elaborate on in the next two stories.

BECOME A ‘HIGH PERFORMER’ AND ACHIEVE THE ULTIMATE STATE OF ‘FLOW’

Sincerely,

Hans van Bommel,
Digital Transformation Accelerator