This was a post I wrote back in 2014, which unfortunately still is relevant +10 years after.
I read an article by Lars Nielsen the other day in the Danish newspaper Jyllandsposten. Lars Nielsen is a journalist with a deep insight into the Danish economic fields, especially within the private sector. In his article Lars describes how Danish banks are doing well from an economical perspective, but on the same time are losing trust to their real gold — their customers. According to Lars, the customers are loosing their trust mainly due to lack of customer perspective and lack of knowing what the customer needs. Many of the banks come up with new products, but simply aren’t good enough to test and validate it on their user base.
No wonder
In my opinion Lars is spot on in his perspective. During the last four months I have been working inside a large Danish bank, as an IT consultant. My responsibilities have been to support an internally developed IT system and making sure changes, e.g. alteration of software, were scheduled, delegated and developed as planned. In terms of change management I have come to experience how one of Scandinavia’s largest banks not have been very good at involving their internal users, i.e. their employees, in the change process. The lack of user involvement has become truly apparent in 1) how the change process was carried out, 2) the roles in the change process, and 3) how changes were requested and entered through a software service. That said, I was merely engaged with developers, supporters and stakeholders of IT (IT people from now), so I can only speak of this small segment of users.
The process was not backed up
According to the IT people the change process was changed a while back by upper management to the framed IT process ITIL. As per 1) users were not involved sufficiently in this decision. In my experience, the change to a new change process was against the will of many IT people who wanted to keep working agile. They had done so before apparently, where the flexibility and dynamic way of developing and delivering software solutions were highly appreciated. From a business perspective the new change method, ITIL, allows control and monitoring, which is very important for corporations for the right and valuable things to be developed. On the flipside however, this might create overhead in terms of approval and filling in changes accordingly, as was the case in the bank I worked for.
No clear change manager role
This overhead seemed mainly to be due to 2) roles and responsibilities in the change process, and 3) the change management software solution called Remedy.
The ITIL process is rather large and includes many different actors with different responsibilities. For a change to go through, i.e. be correctly setup, scheduled, delegated and implemented on time, a Change Manager is appointed to the specific change for its whole lifecycle. However, at the bank I worked for it was not specified who was supposed to create, fill in the details of the change (change specification) and act as change manager. This was a constant struggle between the requesters and the receivers, as departments had their own take on this — and no one seemed to want the role as change manager. For the IT people I talked to, having a centralized department that could act as change managers, but letting requester and receiver ensure the content of the change was correct, could be a way of solving this.
Remedy — a story in itself
A major reason for many IT people denying the role as change manager was simply due to 3) Remedy — the enterprise change management software that many large corporations has chosen for managing their IT change processes. For me, the alarm started ringing when I was handed over a “15 minute guide to create a change in Remedy”. …Wait — what? 15 minutes? Yes, 15 minutes. Jaw dropping and incredible in the sense that people from the bank I worked at had created the guide, and some must actually have been thinking — “This guide is good and will help people create changes”. Indeed, it did help, but how can a 15 minute guide of just creating the change itself be helpful. That’s a huge bottleneck and barrier in my opinion.
My contribution as Change Manager at the bank, did very much involve guiding change requesters in how to use Remedy, and often correct changes for them, as they did not know how to create it according to the change process. This of course also led to creating a new and simpler guide, which we referred people to once they had questions regarding the software. Furtermore, I had talks back and forth with the product owners of Remedy, simply to give the feedback of what I heard people and what I experienced. Unfortunately, in a conservative super tanker organization, once you have set sails it is — apparently — hard to change the direction. The reason for this, I found, was mainly due to the many stakeholders and decision makers (mainly from upper management), even though the IT people and other foot-soldiers were the ones using the software.
Lars Nielsen was spot on
After having worked in a bank, I really think Lars Nielsen was spot on, even though his perspective was on banks and their external customers. From both his and my perspective it currently seems like the Danish bank I worked for, and presumably other larger Danish banks, should work on the following:
- User involvement
- User need
- User feedback.
I believe all three points above can be helped underway, by starting to talk and listen to the employees. What do they think of the business and what do they really want? Surveys can do, but otherwise simply asking the employees can make a huge difference.
I fully believe much of this can be done better, and I hope that’s what new and smaller banks in Denmark have seen: a more agile organization that listens to its customers and develops what they need. Could this be the big FAIL of large Danish banks? The points given in this post could certainly be some of the reasons in my opinion.
Leave a Reply