Tools & Consulting for the webMethods® platform

Tools & Consulting for the webMethods® platform

My approach to digitization

Digitization projects are challenging and often don't meet the original expectations. In this article I explain how I approached such a project, using principles from agile software development. Those can easily be applied to the organizational side of the project as well and increase your chance of success considerably.

Similar to my approach for creating customer value the core idea is extremely simple.

Start with small things today

What I have seen a couple of times now, in very different types of organizations, is that people are kind-of afraid to get started. Mostly it seems to come from a feeling that the first project needs to be big and yield powerful results. In my view, that is actually the worst possible approach. Let me explain why and what other things I consider relevant.

Start small

Assuming that you have absolutely no experience in climbing mountains, would you start with the highest mountain on earth, the K2? Of course not. Instead, if you had that ambition, there would be many years of training and climbing smaller mountains first. Unless you are suicidal, of course. So why on earth are people still starting digitization with big projects?

I guess it is either ignorance or the inability (for many different reasons) to withstand internal pressure. So we need to help those poor souls with actionable advice. Instead of saying “no”, folks need a better approach. One that has been proven to be universally successful: show small results quickly.

Practical examples could be really trivial. If people are used to printing out a lot of things, ask them to question themselves for the need. Example: Ten years ago I would have responded that I need to print texts (like a response to a request for proposal, aka RfP) for proof-reading. Today, with bigger and better monitors, I may still do that but only for the last two iterations. You can argue that this does not truly qualify as a digitization initiative in terms of outcome. But in terms of changing the mindset it surely does.

A slightly less trivial example are invoices via email. Assuming the legal side is clear, you could start asking your customers whether an electronic invoice would be ok for them, instead of the usual printed one sent via the post office. While this looks trivial on the surface, it makes a wonderful starting point for exploring what non-technical challenges might come up. Which brings us nicely to the next point.

Reduce complexity

The section heading says it all. The first order of business, if you sail into uncharted waters, is to make things as easy as possible. That means to understand what the various dimensions of a digitization program actually are. The second step is to look at what experience the organization already has with those areas. And if there is little to no existing knowledge, this means that extra care is required.

When you take into account the whole picture of digitization, as a minimum we are looking at a combination of business process re-engineering, change management, and IT roll-out. All those topics are hard on their own already, with change management being the toughest. (Remember Peter Drucker: “Culture eats strategy for breakfast.”)

If we start with the scenario of sending out invoices via email in the future, we can focus on non-technical aspects. Or do you prefer to combine those with the migration of a mission-critical monolithic application with 2 million lines code to Microservices? Easier things look more realistic to people. Which helps us with the core challenge of getting people on board.

Make things tangible

People need to understand things, otherwise their instinctive reaction will be to dislike or even dismiss them. Therefore, giving presentations about the great outcomes of a large initiative is not going to help. For any given topic the majority of people will have a hard time mapping it onto their own life. And since this is a very individual thing, it does not help to say “this is what it means for people in department XYZ”. Because everybody has a unique personality, and working in the same department very often does not mean doing the same thing.

When it comes to reacting to new things, we are basically talking about instincts that were made for survival thousands of years ago. On a sub-conscious level substantial change in the workplace is something that our brain treats with high importance and sees as a threat. That is not something that can be ignored and you need to convince people to get them on board. And the easiest as well as most effective approach is to let them experience some positive results first hand.

A direct, personal experience offers another huge benefit, relative to some presentation that leaves people with the task to map the content into their own world. Experience greatly reduces the risk of misunderstanding. In today’s world we have international teams that collaborate from all over the globe. So everything is in English and, in many cases, people have to comprehend complex content that is conveyed in a foreign language. In addition, meetings are not face-to-face. So how convinced are you that the majority of people really gets what you want to say?

Have open discussions

Once people have made some personal experience, you can have a proper discussion with them. They have witnessed how the new way of doing things impacts their daily work. There is feeling in the game. And you will see quickly who is keen for the journey and where the reservations dominate. To better understand the different members of the second group is important. There will be people who in principle are on board but have just had a specific problem with the new way. Skeptics and naysayers are the two other standard groups. Plus all the gray areas between them.

Regarding the openness, you need to find a format that works for your personality and overall situation. The key message, which people must be given, is that their input is valued and makes a difference (the latter is a huge step-up from the former). If you start a meeting by presenting your view and asking for feedback or other opinions, you already lost. Instead ask people to prepare something before the meeting and present it there. Do not broadcast any thoughts before. Also try to refrain from engaging in the discussion other than encouraging people to speak candidly.

Delegate some decisions

You should very seriously think who is best qualified to make which decision when. In many organizations the HiPPO (highest payed person’s opinion) principle rules, i.e. the person highest up in the hierarchy decides. If that person is you, think long and hard. Chances are that someone younger, closer to technology, and with less time in the organization has a more open mind. And since we are talking about innovation, those factors may be more relevant than political standing.

If you are brave and innovative enough to delegate some decisions (yes, you can delegate more than work), you will also change the organization for the better. Although at the beginning of the journey that is more of a by-product. The critical success factor is to deliver tangible results fast. Using the “start small” approach will make this less risky. So if some junior person has only seen the technical simplicity of a certain approach and neglected the backlash from a certain department, the damage is limited.

Run things as a series of experiments

If you have multiple experiments running in parallel, you gain a number of things. By calling activities “experiment” rather than “mini project”, you already set expectations the way they should be. Because what you do are truly experiments. Learning certain things in addition to providing a solution is a key aspect. And not everything will work out the way it was expected. As long as you truly learn something relevant, this is success.

I thought long whether I should add this section. But I truly believe it is the most accurate description of how things should be handled and not an easy way out. It will also encourage people to be more open-minded. And isn’t that what you desperately need for such a transformation?

In closing

There is a lot more to say. But for now think about the approach outlined above as the positive variant of “death by a thousand cuts”. Your likelihood to transform the organization is much higher by starting small, trying out very different things, and letting people run their own mini-initiatives. Allow everybody to experience new things and learn, most importantly yourself. This is a journey. For the organization as well as every individual.

If you want me to write about other aspects of this topic, please leave a comment or send an email to info@jahntech.com. The same applies if you want to talk how we at JahnTech can help you with your project.

© 2024 by Christoph Jahn. No unauthorized use or distribution permitted.

Share:

Facebook
Twitter
Pinterest
LinkedIn

One Response

  1. Thank you for sharing this insightful article! I appreciate your straightforward approach to tackling digitization projects. Your analogy of starting small, akin to climbing mountains, resonates well. It’s a reminder that sometimes the best way forward is through incremental steps. Your emphasis on reducing complexity and making digitization tangible for individuals within the organization is spot-on. And your advice on having open discussions and delegating decisions aligns perfectly with fostering a culture of innovation and collaboration. I couldn’t agree more with your perspective, and I look forward to reading more on this topic in the future.

Leave a Reply

Your email address will not be published. Required fields are marked *

On Key

Related Posts

Microservices and code reuse for integration platforms

Today I want to write about a software development approach I was able to put into practice a few years ago. I was myself very much surprised how well things worked out, and especially how fast I was able to see tangible benefits for the business side.

Custom logging with Log4j on Integration Server

Every serious IT system needs proper logging. This article describes how I use Log4j v2 with webMethods Integration Server. There is no need to change anything on the system, just install the package and it works.

External Java libraries in webMethods Integration Server

To get most out of your Integration Server you will sooner or later need to leverage the functionality of existing Java libraries. Common examples are Log4j or Apache POI (for working with Excel or Word files). Here is a short guide for this.

Running webMethods Integration Server in containers

Organizations are moving from traditional deployments to containers and Kubernetes to increase business agility. This article discusses a lot of topics that are relevant to actually reach the goal of faster delivery of value to the business through software. Because if you do it wrong, you just end up with yet another technology stack. And, as always, technology is not your biggest challenge.