Simplifiers podcast - Season 1 - Episode 4

Episode transcript:

Meet Sacha: A Psychologist in the IT World

[Amel]
Welcome to Simplifiers, the podcast where we make sense of the complex world of digital business. Welcome, Sacha.

[Sacha]
Thank you very much, Amel, for having me here.

[Amel]
Tell us a little bit about your background. How did you end up where you are now?

[Sacha]
First of all, I'm Swiss, so I ended up in Finland due to my wife finding me 26 years ago in St. Petersburg, of all places. So maybe I was one of the first immigrants that was infiltrated through Russia into Finland at that wave. We have nowadays two kids. We live in Jyväskylä. And trivia is, I'm a psychologist. So maybe the almost bigger step than moving to Finland from Switzerland is moving into the IT world as a psychologist.

At least that's not what I was thinking will happen when I started my studies. But in hindsight, it really makes sense because I was really interested in how to shape environments to make them human friendly. The same applies for digital environments, be that in our private life, in smart homes, be that in traffic, be that in schools, where nowadays they use a lot of technology, or then business solutions.

I was getting quite fascinated about business solutions and how to help businesses transform and make use of technology and IT. And that's how I'm in my current position as an advisor in that space.

Defining Failure: When the Mission Starts to Drift

[Amel]
Very, very interesting. As you said, it's not a typical background, but it makes perfect sense.

[Sacha]
Yes. Although I must admit, Amel, I was traveling here and I was thinking, how did I end up the guy that gets invited when one wants to talk about failed transformations? But let's find out.

[Amel]
Well, let's kick off with trying to understand what do we really mean when we talk about failure in digital transformation. So in your experience, when a transformation, so to say, fails, what does that actually look like on the ground?

[Sacha]
First, let's stop for one minute about what even is a transformation. So we're not talking here now about implementing a single campaign or putting up a landing page or something. We're talking about something that's much more complex, much more process, long duration, something transforming. Taking a business from one form to another form, that's a transformation.

Along that path, a lot of complexity is involved, a lot of things that are unpredictable, not foreseen, a lot of learning and so forth. So that's what we talk about.

In the same sense, then a failure is not that your site crashes or you have a blackout or orders don't go through at the moment. It's something much more subtle. It's somehow the whole mission is starting to derail or it's kind of fading away.

Usually what we see is that the project, if it's kind of in a project mode, is moving into this kind of micromanagement mode where we're really only occupied with tickets and technical issues and looking at release dates and kind of the bigger picture is kind of disappearing in the background. The purpose of why we actually even are in that process together is kind of vanishing.

And then you also see kind of from our point of view, on the customer side, kind of the group of people that you have contact with is getting smaller and smaller. So your reach into the organization and kind of the touch of the organization is getting narrower or shallower.

The Go-Live Myth: Business-Ready vs. Technically Ready

[Amel]
Interesting. Are we sometimes too quick to call something a success just because it's launched?

[Sacha]
That as well. Of course, you have these milestones that you get live with certain systems. And there is probably a little bit of a misconception or kind of a misfocus also on the provider side that we're very focused on delivering what has been agreed on the technical side.

And then we kind of hand over and we say, have fun. But business is not necessarily ready to have fun. So they need support. They need to kind of adopt this solution. They need to integrate that into their business model. So making a solution business ready, something different from making it technically ready.

Change Management and Expectation Management

[Amel]
Joining me today is Juhana Ovaska. From your point of view and from your long experience, what does failure mean in digital transformation?

[Juhana]
Well, there are of course multiple definitions what it can be. But from my own experience, it often culminates in the things like not being able to do the change management as well as you're supposed to.

So after completing the projects, how to onboard the existing stakeholders and the users and the customers in a way that it's convenient for everybody. And also the processes and overall how the change is communicated within your organization and outside the organization. So that's one of the big failures you can have. Well, not big, but partial failures you can have in your projects.

[Amel]
Yeah. I want to grab onto what you said about communications, because I think a big role when it comes to any kind of transformation is expectation management. So from your point of view, specifically if we think about expectation management towards management, what kind of role does that play? And does failure sometimes correlate actually not to actual failure, but just to failure of meeting expectations?

[Juhana]
Yeah, it's of course a big part of that and how to make a concise communication to EMT members, the management team members, that what are we actually going to do and what the results will be.

So that's something that needs to be on point and really refined in a way that everybody knows the expectations from top to bottom levels, and then actually measuring those KPIs and delivering those reports. So if there's any miscommunications there or it's not measured as you were promising, then that's a failure.

Binary Labels vs. Reality: The Traffic Light Problem

[Amel]
Do you think we sometimes in business like to categorize things as binary, a failure or a success, rather than seeing that actually there may be quite a bit of shades in between?

[Sacha]
Definitely. I mean, simplifiers and the more you move up in management, and usually that's what you do when you talk to the actual buyers or the steering participants to projects, they want to have simple answers. They want to put simple requests there, but the process of a transformation is very complex.

It has so many angles. You need to actually to talk to the people that really own very nifty details of the processes. But then the reporting side, when they just have five minutes to listen, is it on track or not? They want their traffic lights, right?

[Amel]
Exactly.

[Sacha]
And that usually red can mean many things, but to them red just means bad. And it's not always like that.

[Amel]
That's true. And also what you mentioned about a project perhaps being technically ready or technically green in this scenario, is it always so then aligned strategically?

When Projects Steal Focus from Strategy

[Sacha]
No. Actually, we just this week have a phase going on, which is quite difficult with one of the customers. And it's an interesting one where I was personally now for many years deeply involved.

Maybe if we simplify, you have these two layers. You have kind of the project performance, all the project metrics around the budget. Are we on budget overrunning and so forth? Are we on schedule? How the resourcing goes? How is the scope coming along? And those are important metrics.

Now, in that case, that was all red. But then the digital transformation, the strategic achievements, the business was after those goals, we actually all the time achieved those still. Okay. We were always a little bit late. It was a little bit too much escalations to get there, but we actually achieved those.

You can also have the vice versa. Unfortunately, I'm seeing more of the vice versa. The project is doing quite okay, but somehow we're not getting the value out of the transformation or our customers are not getting the value out of the transformation, at least from my point of view.

Both levels are important and we should keep sight on both levels. And typically the project is the one, especially the IT project, the technical project is somehow the one that steals too much focus the longer you go through the transformation. In the beginning, there's a lot of this big talk about all the dreams and the hopes you have and the strategy, but then it's kind of narrows down to the technical part.

Organizational Blockers: Buy-In, Sponsorship, and Availability

[Amel]
Exactly. That's a really, really important point. Well, when we talk about transformation, ultimately we're talking about change. And as we know, and you even more as a psychologist, people struggle with change.

So let's talk a little bit about why organizations struggle with change internally. From your perspective, what are some typical blockers inside an organization that you see when it comes to transformation and change?

[Sacha]
We're actually talking about change of complex systems. So as you say, that's also the organization, the operational process, the people, their roles, the teams, the competence they have there, it's the IT, it's their business model, it's the offering, it's the interaction with stakeholders and customer. So it's a system, it's a very complex system.

It has a lot of variables. The organization is one variable from our point of view as a provider, as a change agent, and the organization is one of the key resources we have. But it's also the one that we usually have the most difficulty to get hold on.

Most projects that have difficulties usually show that the organization we work with, the customer organization, there is not a broad enough buy-in. There is not broad enough sponsorship. People are not available to us when we need them.

And it's quite obvious why that is so, because my main work is to do nothing else than transformation projects. Their main work is to run the business. And on the side, they have these kind of projects going on that for some businesses, they really reserve enough resources and intention, and other business, they think it's a hobby on the side going on.

Especially for those people that we really need to have frequently at the table, which are the business owners. Of course, the IT people, they collaborate with us because we have releases and on that level there is interaction. We need the business owners at the table to keep them engaged.

Silos, Budgets, and Fragmentation: The Customer Doesn’t See Your Org Chart

[Amel]
How do internal structures like budgets from different silos or ownership, how do they impact project progress?

[Sacha]
First of all, that organization has a lot of different departments and usually every organization is already all the time struggling themselves and making sense of their organization and breaking silos and so forth.

There is a few kind of pre-signals that are kind of warning signals coming at early stages. Usually when I'm talking at early stages to one of the people that is kind of a contact person for initiating the project with us, when they say things like, oh, my team completely knows why we need this, but my superior is not yet vital on board, red lamp. Or we need to work together with that team, but actually we don't have a history of working together with that team, red lamp.

Then we start to realize that actually what they want to do is not to drive a transformation project with the organizational resources, but they want to implement the project and as a sidekick, they want this to facilitate their organizational change. And that's quite a big thing to carry on your shoulder as a provider.

And sometimes we do underestimate kind of those factors.

Then you have a lot of talk about customer journeys and unifying the experience, but typically the way that is structured in our customer organizations is per silo. So they own very different envelopes of that kind of internal budget.

You see business cases that drive the investment where product management has visions that once we have this new channel, we will sell so much more products and this and that. But nobody thinks about what's going to happen to the customer service and the call center and how many calls are going to go up there because that's another budget. We don't care about that one, but their customers, they don't see those silos.

They interact with the business across all the channels. So this kind of fragmentation is something that we see quite often.

The most fascinating projects, I think, are the global ones. Enterprises that operate in many markets. Those group projects are usually carried by the vision that we want to unify us across countries. We want to standardize things because that brings return on investment.

But then you have very different countries. You have the innovators and you have those that kind of are running very simple solutions. What will usually happen is that after a while, the innovators think, oh, now we are chained to this standardization and our money is just being used to lift up all the other countries. They start to go rogue and then kind of the transformation momentum breaks apart.

Resistance to Change: Promoters, Detractors, and Politics

[Amel]
Something that came to mind is also, how much do you see, when we think of kind of the struggle within organizations, that it's about either lack of collaboration or lack of culture, maybe to a certain point. But how much do you see also just outright resistance?

[Sacha]
That as well. As I said, for our customers' organizations, the people they're in and the functions they have, this project is not their core business. Their core business is about their function, their budget, their career, their CV.

So there's a lot of people that feel negatively impacted by even positive transformation projects. There is always these promoters and detractors, and that's one kind of an approach of an advisory as well: to help identify the promoters and the detractors and manage those.

But again, we are there in a political sphere where we don't always have the actual mandate. We're not even really accepted because even from the customer point of view, they might want us as the digital provider and not as their organizational change agent. But we definitely see that those are the things we need to take in our hand.

The Contract Contradiction: Agile Talk, Waterfall Paperwork

[Amel]
Let's move on to talk a little bit about contracts, maybe even kind of the contract contradiction. From your point of view, how does the contracting model get in the way of transformation?

[Sacha]
That's kind of an aha experience I had over the years. The whole slogan about 70 to 80 percent of all the transformations fail has been put out by industry analysts probably 10 years ago. People were starting to think, why do they fail? What can we do differently?

One of the focuses was that big transformation projects tried to pre-specify the end state of a solution way too early. So you have this huge so-called RFP monster. Request for proposals with thousands of lines of all the requirements that we want to implement in three years. That's not humane. Nobody can predict the future over three years and every single process and how it should work and so forth.

So we were starting to move in the direction that you need to be more agile, more iterative. There needs to be space for flexibility and learning and making sense and problem solving.

Then you have the contracts and they're kind of these antique monsters because the contract, at least in its traditional fashion, wants to exclude unpredictability and uncertainty, make everything black and white and sanctionable.

So you have on one side this need for flexibility and learning, and then you have the contract on the other side that strangles you. And usually the contract is not built against the purpose of why we're here or what outcome we want to achieve, but based on what will you do and what will you deliver, and later you can be called accountable against that.

Although you realize across the way that maybe what we thought originally didn't make sense after all, it wasn't even possible, or it was way too complex and we underestimated the effort.

But going back to top management, they want to have something to limit their risks. But you need to embrace risk if you want to go through transformation together.

[Amel]
Would you agree with my thinking here that many companies say they want to be agile, they want to describe themselves as agile companies, but still yet they sign waterfall style contracts?

[Sacha]
Yes, definitely. We even now especially see that trend that businesses are getting very risk averse. It takes them a lot of effort to make a decision in a world that already imposes even more uncertainty. Waterfall is much safer for them. So it's a fact, and the contracts are lagging behind in that sense.

Trust: The Ultimate Resource in Collaboration

[Amel]
Do you see trust having a role in kind of any of this?

[Sacha]
Of course. It's a trust business and it is. But me being a psychologist, let's open up this trust a little bit. What does trust actually mean?

One definition of trust is how much you can rely on some other party to do what they promised. How predictable it is for you that what that party will do, say, what the result of your collaboration will be, is what you expected.

If the trust level sinks, that means more and more you're not able to predict what the other party is doing. That is not only difficult in the sense of maybe not getting what you want, but you might actually get it in a different form or too late or whatever, it costs you more.

The biggest issue is the complexity that it introduces. You have a variable that you don't know how it will spin, and businesses are already complex. So they need to reduce complexity.

If they have a collaboration partner that they all the time don't know what is going to happen next, will they release, will they not, what will be the quality, that introduces complexity to them in their system. And that might have chain reactions because they maybe already promised to another partner that on that date, we will get this, and then you can start doing your next task and so forth.

What I'm seeing often is it's not the trust that we as a provider wouldn't deliver what we said, but it's kind of the uncertainty of when exactly we will deliver, how we will deliver and so forth.

There is some simple mechanism you can alleviate this: communicate, be honest, say it early enough. But then the contractual things come in: can we say this already or not, and we will get penalized immediately.

Looking back, in most projects it would have been better to be immediately open and honest and communicate and help our customers to deal with the adjustments that things need.

Trust is definitely, I would say, the primary and ultimate resource of any collaboration.

Horizontal vs. Vertical Complexity: The “Button” Example

[Amel]
You've introduced a very powerful metaphor describing horizontal versus vertical scope and horizontal versus vertical complexity. Can you explain that a little bit?

[Sacha]
Actually, it's very simple. At least I hope it's very simple. Going back to the scope of work discussion. Stating what are the deliverables, what requirements should be met by the new system, whatnot.

To put it very simple, usually those are bullet points or lines in an Excel or in a table. It has maybe 100 lines. And that's kind of what management says, yes, that's what we want you to deliver to us with that budget and that timeframe. That is what I call the horizontal scope. It's kind of the width of the scope.

We can go through it and on line 97, it says, this page needs to have that button. Okay. It's that button.

But then the problem comes with diving into that one item of the horizontal scope. You dive into the vertical of that button.

In one customer case, it can be that we start to discuss: okay, what's the button doing? Oh, it's very simple. It's just anybody can click on it and it redirects you to this other page. All right. That makes sense.

Another customer is: oh yeah, it's this button. We have that like for many years. So it appears only to some segments, some parts of the day. And when they click on it, it will redirect them to different pages, depending on their profile and what they have ordered in the last two weeks under a certain condition that blah, blah, blah.

Then you start to realize, oh my God, what you now uncover under this one line. If you start to dive into the vertical scope, the complexity of this one item is much bigger.

The problem is when you then come back again to top management, the steering committee, and say, oh, scope is much bigger. We realized. And they say, no, it's still this button.

Now some listeners might say, okay, but then you didn't do your homework. You should have studied it more. You should have done more analysis. That's true, but that means you're already in the project. You're already starting to do that requirements elicitation. You're already doing the design work. So basically you're already in phases that, as per contract, you should already get paid.

We can introduce contractual models that have checkpoints along the way, so we can adapt. But your leverage to move the budget is not infinite and it's usually a little bit less than the complexity you have now discovered.

And also there is not the single point that now we know exactly how much it cost, how complex it was, and how long it took. And you know when that is?

[Amel]
After.

[Sacha]
After. Then I know it. Hindsight is always an easier viewpoint.

Even after the design phase, once you start to implement it, you still uncover new things. Once I implemented this button for this one complex customer, at some stage I will still realize: okay, but now where do we get this segment information from? Do you have this integration? No, we don't have this integration. It's this guy that does it manually until now.

Why Scope Gets Misjudged: Access, Incentives, and RFP Reality

[Amel]
I like this button example because it's so concrete. But the word going in my mind at the moment is why? Why do we end up in those situations? Why do projects often underestimate how deep this one single requirement can go?

[Sacha]
Certain humane constraints. You don't have access maybe to the people that actually know the detail. Usually the people that we interact first with, they have some understanding of the business. And then the buyers, again, they are sitting in higher management, so they only know about the button.

Then we find at some stage, Peter somewhere actually knows everything about the button, but he's not available at the earlier time because of course we cannot talk to everybody.

So that's one of the reasons. Top management doesn't even know the complexity. They want to see things simpler, simple answers.

Another reason is: if I come in as a provider and answer to an RFP and say, dear buyer, we don't know this at the moment. Can we just leave it blank? Very honest answer. For sure there is a competitor next to us that says, oh, we know everything. It's almost cost you nothing. And then we'll probably take the other one.

So there's a lot of really trivial reasons why this is so.

Honesty as a Value Point—and a Trust Builder

[Sacha]
On that point, actually incidentally, I just had a discussion yesterday with a new colleague that joined us a couple of weeks back. She was pondering on her first experiences meeting us and what could be kind of value points we have for the market.

Completely, I don't think it's coming from the shelf, but talking to people, she found that we're honest. We have honesty. And that's like a counter trend in today's world we live.

We should try to use that. Maybe we'll lose some cases or not win some cases by being honest. But again, we're here to talk about failed transformation. We're talking about trust. I think honesty will probably take us further on the trust scale than not being honest.

Trust Dynamics: Between Client and Vendor—and Inside the Client Team

[Amel]
Do you see more trust issues between client and vendor, or perhaps within the client team itself?

[Sacha]
I don't know more or less, but both are there as a phenomenon.

Usually we have this one team, or actually it often gets down to one person that is kind of the key ally and the key spokesperson for us within the organization. It's the same person often that already helped selling the project into the organization and the collaboration into the organization.

Now that person is in a dual trust space towards us, but then there's always a lot of people that doubt his choices, his recommendations. As we said earlier, there's conflicts, there's people that have different interests in their career or for their position.

So he's in this tension space, and the better we can make his or her life to maintain trust together and cohesion within the organization, of course, the better that person will be off.

When tough times come around, it's for that person easier to throw the provider under the bus and change, because that's safer to say up to the board that, okay, up to here it was okay, or we made a bad choice and we change.

As a psychologist and not only as a provider, often they would be better off sticking through the tough times with the provider. Of course, there are situations you need to change, definitely.

If we take a marriage, if you have a really violent marriage, there's an end to things. But just having difficult times, getting divorced—we know now that people that stick in their marriages tend to be happier in the end than those that switch all the time. I think it applies to any cooperation relationship.

How Anora Chooses Partners: Points, Fit, and Gut Feeling

[Amel]
How does Anora choose their digital partners?

[Juhana]
We have a measuring system. We have a point system that we use if we want to take a new partner, for example, or if we want to compare existing partners.

We do internal evaluation or we use a third-party vendor to help with us in the evaluation processes. We do some market research, then what we are trying to achieve.

After giving out all the points in different categories, then we also have the most important field in the end, and that's gut feeling. We need to find the correct fit.

We also look at things like: is the partner the correct size for us? We are very medium-sized, so getting too small or too big vendor can be a risk. Absolutely, there are multiple weightings that we do and give out there. But yeah, we give points and we keep track of them.

Shared Responsibility: Business Depth vs. Partner Expertise

[Amel]
And how do you share responsibility? What belongs to the partner, and what do you need to own yourselves?

[Juhana]
Of course, we know our business the best. So all the business decisions that have the depth of our business knowledge has to come from us.

But then best practices from across the field, we prefer suppliers and partners with extensive knowledge of the industry that we are working in. So we can establish and discuss best practices and get ideas and involvement, even learning opportunities from the same industry.

We very heavily trust on the partner's technical expertise on building this. But as the bond deepens and we do more and more together, then we also very heavily want the supplier to understand our business.

We take the supplier's people to our factories and facilities and do tours and have them talk with the business people as much as possible. So they can understand what are we actually doing, what are we striving for, what's the strategy. And when that's deep enough, we can give more and more reigns to the supplier also.

From Supplier to Co-Strategist

[Amel]
Would it be fair to say that you see the role of a transformation partner evolving from a supplier to something more of even a co-strategist?

[Juhana]
Absolutely. At least in sub-strategies. Of course, the whole company strategy comes from BMT, but absolutely when defining our digital strategy—how to grow with e-commerce, lifestyle sites, what to do with AI, product management—we rely and trust our partners to do the strategies and see the roadmap with us in the future.

Warning Signs: Disengagement, Legacy Clinging, and Micro-Level Drift

[Amel]
We're starting to wrap up a little bit, but I want to talk about warning signs of a failing transformation. What are some things our listeners can be on the lookout for?

[Sacha]
Some we already talked to. You start to lose some of the people you need to have engaged. Quite often it's the business owners that somehow are there that pretends of I'm occupied and I'm busy and so forth. They're not anymore there with you.

That means typically they have already retired from the whole transformation, and they were usually the initiator of the transformation, or they're already working on a plan B.

Another thing is that we sometimes see the business owners come back with a requirement list, and the requirement lists start to look like all the legacy processes and features they had. Now they only want to hold on to what they had earlier. They don't want to lose anything.

We need to understand there's kind of two big personas or power centers. There's the buyer, the economic buyer that owns the budget. And then there has to be business owners.

Business owners are in a dissonant situation. They want to change, but they have to make money throughout the change. They cannot have the business disrupted.

Other signals you should pay close attention to: when you find yourself all the time only discussing technical issues. You need to reserve time to discuss where we are in our journey. You need to have this discussion over and over again.

From the top of my head: you lose stakeholders, and you're too much on the micro level, on the project level instead of the overall impact.

Momentum and the “Contract Gravity” Effect

[Amel]
Do you see that momentum has a role?

[Sacha]
Definitely. It sucks out the momentum when you're only talking about projects. Usually then the contract is coming in. It sucks out the spirit of the transformation.

[Amel]
When you start hearing more about the contract again, that's a clear sign as well. Any final tips or hints?

Final Advice: First Value, Breathable Contracts, Visual Communication

[Sacha]
We were on the right track when we started to figure out: let's not pre-specify these monsters. Aim for the first single value use case that you can implement that will make the users actually say, now I already have a reason to log into this system, because it already provides me some value.

Often we think: oh, and now where we added, let's also do this and that. That's not even necessary. If they already want to onboard to your future solution, you have them there. Then you can grow.

Then make sure the contract leaves you space, be adopted over time, have mechanisms to review the contracts. I think that's the biggest problem we need to solve, especially with the legal departments, because they are usually only there to minimize the risks. And these things are in conflict with a lot of the philosophy of how transformations should be run.

Pay attention to the soft parts. Have meetings where you say, okay, now things are not clear for us and we don't know. It's not just a signal of weakness. It's a signal of honesty. It's a signal that you want to solve problems.

Don't lose vision. Communicate. Keep in mind that some people are close to the project and know what's going on. Others zoom in twice a year. You need more than huge PowerPoints with a lot of text and dashboards. You need something that's visual. We often use prototypes to visualize what's actually happening: what will be the experience?

And finally, try to focus always on the outcome: the business targets, the goals, the KPIs you want to follow throughout your project. After the project, again, it's not only the technical readiness, business readiness. So focus on that. Don't pay too much attention only to the original list, the scope of work. What should be done, but why are we here?

Closing: Real Value Over Paper Delivery

[Amel]
Very, very well said. Thank you so much for this conversation. It's been honest, refreshingly grounded, and I think extremely insightful.

[Sacha]
Thank you again, Emil, for having me and looking forward for you to invite me again when we talk about how transformation succeeds.

[Amel]
That's true. We need a part two. Definitely.

Now, if you're listening and planning or currently perhaps leading a digital transformation, I hope today's episode has helped you reframe what success really looks like. Because it's not about delivering on paper. It's about delivering real value with clarity, alignment, and with the right people in place.

This was Simplifiers, brought to you by Solteq. And if you found this useful, please share it with a colleague, subscribe, and join us next time. Until then, keep simplifying your digital world.