Editor’s Note: Ron Leeman is a world-recognized Change Manager and author of several Change, Process, and Project training guides on Flevy. He has decided to write a series of articles that chronicle his personal “change” journey. This is the second installment (part). You can read beginning from the first piece here. You can also learn more about Ron and his approach to Change in our recent interview with him.
* * * *
Here we go then the next in line of my Life and Times of a Change Manager series.
This assignment was for Raiffeisen Bank Polska, a major Polish bank which was one of two pilot sites of the RZB group to be involved in the implementation of a new core banking system called Globus. This Project was split between the launch of a new Consumer Banking Operation and the conversion of the existing Corporate Bank.
I called this assignment…
Poles Apart – a Cha(lle)nge in Poland!
The Globus system was live on the Consumer Banking side of the business and needed to go live on the Corporate Banking side as soon as possible after completion of the technical implementation. My role was specifically for the Corporate Bank implementation.
The roll-out of Globus was within the Country Head Office and 30 branches around Poland and would significant change ways of working and business procedures as well as job and organisational changes. All in all a significant impact on bank staff.
The roll-out was already suffering major delays and had no previous Change Management involvement. This should have been a warning sign for me!
Once again I can remember the interview process very well. I was flown out to Warsaw for 3-days to be given an overview/insight to the project and was interviewed by a number of people. Two things stood out for me from this process:
- On turning up for one of the interviews I thought it a bit strange that I was sat outside the office with another candidate for the role. Anyway when it was time to go in for the interview both of us stood up and walked into the Head of Operations office and sat down. Following a short exchange it transpired I had incorrectly worked out my timings and I should have been there an hour later. Oooops … not a good omen I thought! Anyway I swiftly made my apologies and went and sat outside until it was my proper turn.
- After day 2 of interviews, overviews and insights I was asked to produce a high-level Change Management Plan including Timelines & Targets for a Go-Live date in 7-months time. Do what I thought to myself! However I took this as an indication that I had been successful with the interviews and this was a final “test” to see if I could produce a plan for a restricted implementation time-scale. So gathering all of the information I had gleaned I produced what they wanted but tbh didn’t really think it was feasible but hey I wasn’t going to say that was I. The actual plan I produced is pictured below:
This high-level plan meant very little in terms of eventual project time scales but hey I got the role otherwise I would’nt be writing about it here.
My Role & Responsibilities
- Developing and measuring business benefits.
- Managing the preparation of all end user documentation.
- Developing and implementing the training strategy and plan.
- Developing and implementing the communication strategy and plan.
- Design and implementation of new job roles and responsibilities.
- Re-engineering of processes where necessary.
No problem, I’m a Change Manager, that’s what I do!
What they didn’t tell me!
All the other change initiatives going on in the bank that would also have a significant impact e.g.:
- Cultural Audit of Management Styles.
- Centralisation of Complaints Handling.
- Outsourcing of Transaction Processing.
- Implementation of Imaging and Document Retrieval.
- Overarching review of Internal Communications.
- Review of Risk Management process.
- Operations Centralisation.
- Credit Process review
On top of all that:
- Pending changes to the Board of Management.
- Three different project sponsors.
- Twelve technical work streams all working in silos.
- Autonomous Regional Management.
- Pending merger of two technical platforms.
- Self-proclaimed change resistant people.
- The language issue … kind of.
But hey I kept on smiling …
So given all of the above I thought that there was a need to co-ordinate all of this activity to try and ensure that any impacts and associated priorities were effectively managed and how they were aligned, or otherwise, to the Globus implementation.
So as a first step created a high-level model, including all change the aforementioned initiatives and key roles … it looked something like this:
Part of the process would be to define the key roles in the context of the above to ensure that there were adequate resources involved and that they all knew what their roles/responsibilities were. Five specific change roles were recommended for each of the change initiatives:
For each of the initiatives it was then necessary to determine what key information was needed e.g.:
- Key Milestones.
- Impact Assessment.
This would be used to input to a “change matrix” … the idea being that all change matrices were used to coordinate and track each initiative against the Globus implementation and additionally for reporting requirements to the Board of Management.
It should be noted that:
- The Change Manager’s role was critical in the whole process e.g.:
- Responsible for the Change Management of the core Globus initiative.
- Responsible for ensuring that all the other initiatives were aligned.
- Managing the resource deployment.
- Reporting to the Board of Management.
NOTE: Because of the linkages between initiatives some people had dual roles.
The model was presented to the Bank’s Board of Directors.
Well guess what … whilst they agreed that it had merit, unfortunately because of the issues surrounding the Globus implementation this overarching approach was never implemented. As a consequence I concentrated on my role of change managing the core Globus implementation because it was felt that this was where the effort and associated resources should be prioritised.
So what follows is a short synopsis of some of my main areas of responsibility:
- Documentation Creation.
- Business Readiness.
But before I go into that I would just like to show you what a challenge this project was e.g. some of the Project Conflicts that manifested themselves during the project life-cycle:
OK, onto the stuff mentioned earlier.
The necessity for implementing a comprehensive communications plan was of paramount importance due to the fact that there had been little communication previously and people were not fully aware of what was going on and the extent of the impact the implementations would have on the Bank. So taking the experience from my previous project once again I implemented a full and comprehensive communication plan that consisted of the following:
The main problem with this was that while the Project was essentially English speaking all communications had to be in Polish so initial “copy’ was created in English by me and then translated. This was by no means easy because of the difficulty in getting the same message across in a different language. So for every communication there was an initial translation by one of my Project Managers which was then read by another Project Manager and compared against the original English “copy” and then, just to be on the safe side, there was a third check by someone from the Communications Team. A bit of a convoluted process but at the end of the day it worked.
All communications to the RZB Head Office in Vienna and to the Board of Management was in English.
Some interesting experiences:
- Business Roadshows … these were usually attended by a Board of Management member, who would do the presentation in English and then take questions in either English or Polish. Answers to the questions in English were obviously easy to give, however, questions in Polish had to be translated, answers given in English and then translated into Polish again … interesting times!
- Internal Press Conferences … I was responsible for pulling together all of the individual slide decks of the presenters which were all in Polish so you can imagine me trying to work out the order in which these slides were due to be presented but, more importantly, whether they contained the right level of detail and information that needed to be conveyed. Needless to say I had to sit with each of the presenters for them to give me a run through of their Polish language slides in English.
- Cascade Communication … Senior and Middle Manager were responsible for cascade communications to their direct reports and invariably a lot of things were “lost in translation” which was evidenced by some of the feedback and questions we got via the Intranet.
But hey at the end of the day it all worked … kind of.
Before embarking on a comprehensive Training programme there was a requirement to have a full set of documentation to augment and facilitate the training process. It was agreed that that for the roll-out documentation should consist of the following:
- Process Flows.
- User Guides.
- Associated Training Material.
Regarding 2 and 3 just to give you an idea of scope as at 19th August 2002 there were some 859 Procedures and User Guides required to be created:
NOTE: All Process Flows, Procedures and User Guides were made available on the Intranet.
As you can imagine creating Procedures and User Guides coupled with the production of associated Process Flows was an enormous undertaking. There were two key things which had to be taken into consideration during the document creation programme:
- The creation of documents while the system was still being configured with the danger being that it could potentially lead to rework … to minimise the risk of excessive rework we implemented a collaborative/iterative approach (now probably called “Agile”) between the Developers and Document Creation Team with regular alignment sessions which started at when development was 80% complete.
- It was of paramount importance that the documentation was of a style and format that would be suited to the end-user and could be easily updated and amended as necessary … to gauge whether the documentation was acceptable the end-user population we undertook some telephone research with randomly selected individuals from Branches and Head Office Departments with the following outcomes:
The conclusions reached as a result of this research were:
- Those who use the Training System also made good use of the Documentation.
- The quality of the Documentation varied but positive comments were made about Loans, Limits and Guarantees
- If the intranet was easier to access more people would use the Documentation e.g. icon on the Desktop
Clearly there was still work to be done and we initiated an action plan to address the issues raised e.g.:
- Access to the Intranet.
- Try and increase the use of the Training System (see below).
- Use Loans, Limits and Guarantees as a benchmark for quality.
After putting into place an action plan based on the above, all Procedures and User Guides + associated Process Flows were successfully completed to a good level of quality and consistency.
As with other technology implementations, one of the key success factors is that of training on the new system and it was no exception for this project. There was a requirement to provide training for end-users on all of the products being developed for Corporate Banking and training could only commence after all necessary documents had been produced (see above).
The following were key elements of the provision of training:
We have already covered Document Creation so I will briefly cover the other aspects mentioned above.
Work undertaken on training planning had already identified that in order to achieve focused training delivery it was far more efficient to have a number of regionalised centres to spread the training load. Three centres were identified:
These centres were equipped with all the necessary hardware and environments to carry out the required training.
Training delivery was planned in the following phases:
- Train the Trainer – approximately 8 > 10 people over a period of 1-week.
- Customer & Account Training – Branch Support (heavy users – approximately 40 > 50 people) over a period of 2-weeks.
- Customer & Account Training – Others (medium users – approximately 250 people over a period of 2-weeks.
- Product Training – Approximately 600 people over a period of 7-weeks.
- Branch IT – approximately 20 people over a period of 1-week.
With any training programme there needs to be a way of monitoring and evaluating the training delivery to ensure end-users receive continue to receive quality training.
A database was set-up to facilitate this monitoring and evaluate training from both a quantitative and qualitative perspective.
- Quantitative – using a scoring system of 1 > 5 (where 1 = Very Poor and 5 = Excellent) the following attributes were scored:
- Quality of Training Material.
- Course Content.
- Trainer Knowledge.
- Trainer Help and Attentiveness.
- Training Facilities.
- Qualitative – further feedback should be also be gathered (comment form) in relation to:
- The training itself.
- The system functionality.
The database was made available on all training PC’s and completed by end-users immediately after completion of their training. Analysis of the information was done on a daily basis and issues of inappropriate training scores addressed immediately to ensure future training is of a better quality.
Training Evaluation after completion of approximately 85% of classroom training showed the following:
Not brilliant scores, but certainly good.
To gauge the readiness of the business we built what was called a Globus Knowledge Tool which would be used to monitor all elements of training and complimentary activities. The tool consisted of the following:
- Attendance at f2f Training Sessions.
- Completion of e-Learning Modules.
- Use of Training System (TIPQA).
- Involvement in Double Entry process.
I have covered 1 and 2 above so I will briefly outline 3 and 4.
Use of Training System (TIPQA)
We were told, on a number of occasions, that staff would be more confident in Globus if they were able to ‘see it’ before the intended go-live date so a Training System called TIPQA was created that everyone would have access to and reflected all Globus modules that would be used at go-live. The system mirrored the modules and was refreshed on a daily basis to reflect any new functionality that was created some of which had been tested but some of which had not. The idea behind providing this new environment is to:
- Give a “look and feel” of the live system.
- Increase knowledge and awareness of system functionality.
- Build confidence in system use.
- Validate Procedures and User Guides.
- Validate the Help Desk process.
- Validate the Security Management System.
We recommended a structured approach to the use of TIPQA and suggested that Branches and H Departments looked at what functionality they were likely to use and prioritise this in order of frequency of use. This would ensure they spent more time learning the functionality they were likely to use most during their day-to-day work.
It was suggested that individuals spend a minimum of 1 hour using TIPQA per day but this was obviously dependant on their workload. We further suggested that this time should be either at the beginning or the end of the day when the workload was likely to be less.
We also implemented a monitoring system for the use of TIPQA through the Globus Audit Log to collect information on:
- Who used the system?
- When it was used?
- Which transaction(s) were performed?
This enabled us to get a good indication of the overall use of the system at all levels.
Involvement in Double Entry
Double Entry was simply the process of inputting data to Globus as well as the old system to ensure that on go-live Globus was populated with correct data.
The reason for using this as part of the Business Readiness Evaluation was because it gave individuals valuable experience of using a variety of Globus modules.
An example of the Globus Knowledge Tool output is shown below with the Business Readiness monitoring outcomes highlighted in red (the higher the numbers and populated cells the better):
This tool captured information at an individual role level and could also be analysed at Branch, Area and Regional level as necessary.
As this was a long project I could go into a lot more detail but I will end by saying that this was a very politically sensitive project given the delays and associated costs as a result of that.
But one of the biggest issues for me was the cultural one. I will probably come in for a bit of flack from any Pole reading this but these were my observations at the time (things may have changed since then):
- Self-confessed as ‘change resistant’ – it’ was difficult ‘leading the horse to water’ let alone ‘trying to make it drink’.
- Uncomfortable with the concept of ‘multi-tasking’ – had to finish one thing before starting another.
- Perfectionists – ‘Rolls Royce’ syndrome rather than the ‘Volkswagen’ approach.
- Blame – finding scapegoats and pointing the finger were evident.
- Responsibility averse – unwilling to accept responsibility and would look to delay/avoid ‘signing off’ anything.
After some 15-months, due to an internal “coup d’tat” (no names no pack drill), I and several other colleagues either left the project early or our contracts were not renewed. In a way this was a bit of a god send because the project politics had descended into a situation where it was becoming difficult for all concerned.
Go-live was some 3-months after we left.
To end on a slightly happier note this was a picture of the Senior Management Team taken at the Bank’s annual Christmas Bash (note the Change Manager had to be different … lol). Happy days.
My next Life and Times article will be related to my role as a Business Process Change Manager & Performance Improvement Consultant for LloydsTSB Bank.