A guide to system replacement projects form a business person’s point of view.
Business people smile nervously when they hear about a system’s replacement project. Especially when it’s an important system. The IT gang, however, seems very happy. To them it makes sense to replace the system in order to modernise and simplify, but for the business team, it means change, and potentially another failed project. We often forget about the client and business impact as a result of a major system change. When core systems are replaced, it disrupts the entire eco system within the company, and although the change may not be visible to the actual customer, it impacts all areas of business from frontline to back office. With some types of system changes, there may be no turning back. Its not a good idea to run dual core systems and incurring the costs, support and maintenance required for both systems. Some programmes are so prominent that it is known to the company’s shareholders, and this increases the pressure to make it a success. Also, core system replacements could span over many months and years and cost an astronomical amount of money.
Signature Business Solutions has had the privilege of being involved with core banking replacement programmes and we know it’s not a walk in the park. This article will provide some insight into large system transformation projects from a business stakeholders point of view, and will provide some advice as to how to manage these kinds of programmes. Oscar Wilde said: “Experience is the name everyone gives to their mistakes.” Making mistakes is part of life, but with large programmes, we need to try and avoid irritating and disheartening our business community.
In our experience, business stakeholders may have some of the following concerns about system changes:
The current system is working well enough.
Even though running on old technology, the system does what it is supposed to do. Why fiddle with something that works? We could argue that the enemy of great is good, but according to business, the system works. Replacing it is costly and may yield no quantifiable business benefit over the short term. Especially old mainframe systems may be outdated, but try and explain the technology jargon to frontline people. They are used to the system and business processes have been built around these systems.
Issues being experienced by the business may not just be system related.
When issues are being experienced in a company, it may be partly system related e.g. slow response times, outdated processes etc. But in many cases, it could just be something relatively simple like an inefficient business process or a culture of bad customer service. Fixing the system, may sort out some aspects, but may not solve the problem. Having a new system is not going to change negative attitudes or bad leadership. This frustrates business, because they know very well its more than the system that needs fixing.
Is the programme an IT change or a business transformation initiative?
With large system changes, we often have to look at improving processes and ways of working in the business. Are we only making a system change or are we transforming the way we operate? Changing a system may involve the way we think about our processes and business. Who is going to drive this strategic change within the business? The change may be much larger than the actual system. It could involve re-thinking our strategy and culture. Business needs to drive this change and make it happen. It’s not just an IT initiative, business needs to be involved as well. Question is: ‘’Who is leading the initiative?’’ It has to be collaborative.
This was tried before and failed.
Previous projects may have failed. Business therefore, justifiably, questions the need for the new system. Companies have institutional memory. Re-packaging the project may not work. Business may feel ‘’we have been here before.’’ Top leadership changes, and the new regime would like to suggest a transformation, including new systems, but your operational people are the ones who have to buy into the change and have to make it work. Sometimes management thinks a change in the project methodology will make the project successful this time. And this may actually be the case, but business however, may question the need for the ‘’new’’ system.
The project may be seen as an inconvenience and makes like more difficult (in the short term).
People, generally don’t like change. Business faces a lot of pressure and adding the effort of a system change is not always fair. The timing will never be right. Business may not understand the strategic importance of a new system. We need to have empathy for them.
Business people still have their day jobs.
The system change is something additional to what the business team already does. They still have to manage products, engage with customers and get new business. The new system is something additional to their already busy schedules. Now they have to attend project meetings, provide requirements and be involved in implementations. Give us a break please!
Why are we doing this?
Let’s pause on the reasons for the system change. The executives and IT professionals may understand the reasons for the change, but the actual user may not. We have found that the project team themselves may not have a solid explanation for the replacement. It makes it difficult to sell to business when the team themselves don’t have an answer. It sounds obvious that the new system will improve business, but it may not be easy to explain. Business may ask: ‘’Why do we have to move our systems to the cloud?’’. As mentioned, some systems have been around for years and still work.
How do we make system replacements work from a business point of view?
We don’t specifically want to recommend a project methodology, but you will notice a strong leaning to agile ways of working given this article deals with system replacements which relates to building software. Herewith some tips and advice on what to consider when managing these initiatives:
Keep your business stakeholders close.
Project methodologies like agile have this principle built in. Business and IT work closely together to design and build the solution. Agile principles like ‘’Business people and developers must work together daily throughout the project’’ and ‘’Our highest priority is to satisfy the customer through early and continuous delivery of valuable software’’ are very useful. There are many benefits with the agile way of thinking in terms of managing change, cutting down on documentation and managing requirements according to the needs of the customer in a very reactive way. Business feels part of the process, contributes to developing the product, and can see real value in terms of the IT spend as the journey progresses. Try and always focus on ‘’business speak’’ when talking about system aspects. Make it understandable to business. Try and avoid jargon and abbreviations. Business doesn’t care about what an ‘’API’’ or a micro service is. Position the programme as an ‘’all in’’ programme not just an IT thing.
Think of the programme as a journey.
Break the programme up into manageable chunks. Have a look at the business value that each part of the programme adds. You may have certain products and features that may be more urgent to business. Prioritise these. The journey is important because it impacts the lives of all involved. It’s not just about a system. The development journey is important. Business needs to take the lead. Mapping out the journey, involving business and socialising the plan with various stakeholders is a good idea. How do you eat an elephant? One bite at a time.
Think of the entire eco system.
Peter Senge, many years back, mentioned systems thinking. It’s very true for system replacements. The system is ‘’alive’’ and changing one part of the system has a ripple effect on other parts. It’s worth the effort, to understand and map out the landscape. Almost like a spider diagram, with the system at the middle and understanding all the stuff around it. For some systems, have a product or client view and expand on this. Having the client at the centre of the diagram makes the programme real and assists with explaining requirements and features to business.
Integration may be a showstopper.
Companies have legacy systems and these are all built around the core system. Replacing a core system is like open heart surgery. You are performing a heart transplant on a live patient with various interconnected parts around the ‘’heart’’. Be careful and mindful. Building functionality in the new core system itself may be the easy part. The interaction that the core system has with the eco systems around it, is where things get tricky. Don’t underestimate the integration work required. Companies may have middleware or API technology, but older systems may prove to be a challenge. In our experience, getting the partner systems to make the changes to their systems may be difficult. These IT teams have their own priorities. Understand your dependencies and always keep an eye on strategic initiatives happening across the organisation that could impact the programme. We all compete for time and resources which are limited.
On the softer side, don’t bad mouth the older system.
It still works and may have been in place for many years. Respect the system as well as the team who supports it. Remember people will feel unsettled during change, so be respectful on how you deal with them. A suggestion is to involve the legacy system’s team in the work. There may be decommissioning work required on the old system. So don’t let go of key members. Be careful how you position the retirement of the old system. It’s about people not systems.
Remember business processes.
A system is part of a process. One of the most important stakeholders, is the operations part of the business who deal with processes and systems. In our experience, operations will highlight the issues and problems being experienced, and may provide very valuable and real insight. Operations may also deal with customers. They know the business inside and out. Involve them in the system build and testing.
Have risk and compliance partners as part of the project.
We have learnt through some hard knocks, that a dedicated risk person (s) may be required on the programme. Having risk, legal, audit and compliance people attending meetings once in a while is not optimal. You need focus and an understanding of the changes. The risk person must be involved and should become a fan and supporter of the change. Lobby them and make them part of the team.
Your governance structure is important.
Have the right executives, with clout, involved in the project. Some of the successful programmes we worked on had the concept of a ‘’triad’’. A triad consists of three important high level executives i.e. a technical lead, business representative and a delivery lead who makes it all happen, and serves as the link between business and IT. You then have a combination of IT, business and a high powered, connected delivery person who orchestrates the programme. A large project has to be visibly supported by senior management preferably at C and board level. Make it a priority to report back on a regular basis. You need powerful people to remove blockers and kick butt where required.
Adapt your project methodology.
Replacing an existing system is not like building a brand new product or feature. We struggled with some agile principles in terms of deploying code into production regularly. We battled with breaking down work into features that had business value and could be completed within a sprint or programme increment. With system replacements, analysis is crucial and the team spends a lot of time on analysis before design and build can happen. Analysts should run ahead and complete analysis, so work can be pulled in for development. This takes a lot of time. Plenty of analysis work needs to be done upfront. Don’t try and rush this process. Without proper discovery, things will be missed in the build. Don’t underestimate replacing an existing system and the analysis and research required.
Manage the system replacement in a programme construct.
We have found that a major system’s replacement should be managed as a programme construct. Trying to incrementally make changes via a business as usual process may not work. You need dedicated resources and focus. Depending on the project methodology you apply, trying to get priority from external stakeholders (getting onto their ‘’backlog’’) is difficult. Managing the project on a piecemeal basis will prolong the project and frustrate everyone. Business always has new products and changes on the go, and a system’s replacement project will always be lower on their list of priorities. Have a dedicated team with a dedicated budget.
Adapt your existing approval / governance processes.
With some of the projects we were involved with, tough approval processes existed for simple changes. Especially when products or processes change, existing structures could be cumbersome and bureaucratic. We found that approvals were delaying our deployments and became show stoppers. In line with the suggestion to have dedicated compliance and risk person, some of the existing governance forums and processes may have to be changed to ensure quicker delivery for large programmes.
Manage change carefully.
Include your change management people in the process. Managing change is not a new concept and getting buy in from key people and influencers makes all the difference. You can apply all kinds of change management tools and methods, but change is only successful when the actual system users adopt the system as soon as possible. Involve business during the entire process. We have made this point several times.
Keep feature teams small.
Too many people in a development team doesn’t work. This is echoed in agile. Teams should be less than 10 people. This is a practical suggestion as per our experience but there is plenty of agile material to read up on regarding this.
Involve the right people.
Have a mix of new team members and older more experienced people. It’s difficult to balance new ideas and innovation with the experience and wisdom of the older ways of doing things. Check out the bullet below concerning balancing innovation and the old ways of doing things.
Don’t get stuck in ‘’analysis paralysis’’.
We tend to over analyse things and we get stuck in this phase. Incremental delivery works. Analysis is an ongoing activity and should run ahead of the team building the features. Get input from all, present the analysis and make a call as to the way forward. Don’t get side tracked by too much analysis. Start building something, and learn quickly when a mistake is made. Having something is better than always just talking about it.
Use the skills and input from the system vendor but ensure you have knowledge transfer to your own people.
Core systems especially, need to be understood by people within the company. Be careful when you gather requirements, not to leverage only the vendor’s input, but also the relevant people in your company. Especially from business.
Be careful how much you customise the new system.
The new system may not have the exact features of the old system. Older systems were customised to suit the business and may have bespoke code. This may not have been documented anywhere. This may lead to customisation required for the new system. Be careful. In our experience, changes were made to the new system based on the old ways of doing things. This has all sort of implications. The principle should be to keep to the vendor’s standard system. This may lead to tough calls having to be made. Remember a customer is used to a certain feature and if the new system doesn’t match it exactly, the customer needs to be consulted and informed.
Customer engagement and data cleaning activities are part of the programme.
Don’t underestimate the importance of these tasks and the time it could take to complete.
Actively listen to business and ensure learning happens early, and continuously.
“Optimism is an occupational hazard of programming: feedback is the treatment. “ Kent Beck. We suggest an agile approach in terms of learning. By delivering software incrementally and continually, feedback happens all the time. Having showcases to show working software is important. Having daily stand ups and participating in sprint planning and other ceremonies improve communications, and helps to remove blockers quicker. Business has the opportunity to have a look at what is being built and to make changes and adjustments as required.
Data is key.
We suggest being data led in everything you do. Data should inform your decisions regarding the system and features. We may build a feature only because it exists on the old system. Data will tell you if the feature is actually being used currently. Why spend effort on building a redundant feature on the new system? We would also recommend having dedicated data resources as part of the programme. Data should be provided timeously. Having to depend on data teams outside of the programme may cause delays. Data is key to what and how we build, and informs decision making.
Balancing innovation vs. keeping the old.
We have found that with system replacements, companies may build almost ‘’like for like’’ features on the new system. Given the time constraints and pressure to replace the old system, the team may not focus on innovation and doing things differently. It also depends on who you consult during the process. If you only depend on the views of the existing business people, they may get stuck on the old ways of working. You need to balance the analysis, design and build to include fresher views. How can we do things differently? Don’t underestimate the importance of ‘’out of the box’’ thinking, but balance it with the older, more experienced views to get to a solution.
Remember the potential impact to the actual customer.
With some of the feature changes to the core system, customers may be directly impacted. Especially for larger corporate clients, they may have systems linked to the core system. Changes to the company’s system will force the client to change their own systems. This could include line of business system integrations, reporting, reconciliations etc. Customers will have to spend time and effort on changing their own systems. Involving your business people will highlight these requirements and the podetial impact to clients.
Testing is very important.
As with all IT projects, ensure you thoroughly test the features. Have a dedicated testing team. Testing must include business (including user acceptance testing). The difference between success and failure is delivering working software all the time. Involve your developers in the testing process. Then get business to test as the feature gets released. The difference should be that features are delivered and tested all the time and business should be involved every step of the way.
Measure your progress.
As per an old management saying: ‘’you cannot manage what you cannot measure’’. Have metrics in place. We would suggest metrics at a programme as well as a feature team level. What progress have you made and how can you improve? There are various tools available. We could suggest a few.
Let’s summarise our advice:
Have empathy with the business team.
They work with customers daily and are on the frontline. They have to be involved with and find value in the system being replaced. They should be part of the process and should be an active partner in the journey.
Communication.
As per usual, communication is important from start to finish. It’s important to have honest feedback happening all the time across the project, vertically and horizontally. Keep people informed all the time.
Involve all parts of the business.
From the customer, to the front line to the back office. We have often found a gap may exist i.e. we have buy in from senior management and lower level staff but middle management are completely out of the loop. Involve all levels across the company.
Ending off with a bit of humour from a business person’s point of view: ‘’What is the difference between a project manager and a used car salesman? The used car salesman always knows when he is lying.’’. Managing projects is difficult. Business and IT should be one team.
System replacement programmes take a lot of effort and time. Planning is important and understanding what to look out for makes a huge difference. The insights provided above are just a few high level aspects to consider. Please feel free to contact us to assist you with your projects. We can provide advice and assist in managing programmes.