An IT migration project typically aims to seize opportunities from adopting new technology to drive competitive advantage. The project may seek to reduce the risk of running core processes on outdated, unsupported systems wide open to cyber threats. In my previous article on “How to lay the foundations for successful digital transformation projects”, I discussed the importance of clearly defining the AS IS state as well as the desired TO BE state. This article looks at handling the risks of moving from the former to the latter.
Teams can become so focused on creating something new with the latest technologies, that they ignore the constraints imposed by the AS IS state which impinge on the design of the TO BE. This creates significant risk of delays and cost overruns. Redesigns may be needed to accommodate factors identified later in the project, with a worst-case scenario of project cancellation if there is no viable migration journey.
The TO BE state: where do you want to reach?
There are a host of potential reasons for planning a transformation project:
- Upgrading to the latest software versions to maintain security
- Supporting changes to the business
- Re-architecting systems for future business change
- Migrating to a replacement technology stack to reduce operational costs; provide access to new technology features; enhance staff productivity; and build responsiveness into the systems
- Improving the user experience through redesigned processes.
It is essential to document the TO BE state and gain buy-in from stakeholders for the investment to deliver the proposed change.
The AS IS state: fully understanding where you are
In an IT migration project, understanding and documenting the AS IS state is also vital. Existing systems will have proven their worth over many years and are likely keeping the business ticking over without too much effort or investment. However, there may be limited knowledge of existing system functionality that leads to a risk of finding processes not supported in the TO BE system.
Original system specifications, database designs and documentation of interfaces may have been lost over time. The employees and third parties involved in the design and implementation of existing systems may have left, be overstretched just keeping things running or on the verge of retirement. It is still vital to ensure that the AS IS situation is well documented or the migration project will be on shaky ground from the start.
Risk, Opportunity, Mitigation and Contingency
Opportunity and risk are two sides of the same coin. We can articulate risk by considering the probability of an event occurring and the size or significance of the impact of the event. It is then possible to project any likely losses and develop mitigation strategies. An organisation that has well-trained staff experienced at taking on complex challenges, will understand the associated risks and has procedures to effectively manage these to successfully deliver on the opportunities.
Having determined the probability of an event occurring and the impact if it does, mitigation and contingency measures should be considered. Mitigation seeks to reduce the likelihood of the risk occurring and contingencies deal with an event if it does occur.
Risk mitigation includes keeping systems updated with all patches and security updates. Mitigation might also include identifying key personnel and rewarding them based on their importance in keeping the business running and helping with the IT migration project. Developing contingency plans makes it possible to assess the best balance between spending time and resources to:
- Minimise the probability of an event occurring
- Minimise the impact if it does happen
- Prepare and test plans to recover from the failure
- Review each of the events based on this probability.
IT Transformation Project Risk
IT migration projects can be especially challenging as they are infrequent. There may not be relevant expertise within the organisation. A proven strategy is to seek assistance from third parties with migration project management experience, skills in ‘legacy technologies’ used in the AS IS state, and also understanding of the latest IT developments to feature in the TO BE.
Risks can be categorised into different classes:
- Technology Risk associated with running older technology – for example, hardware and software becoming unsupported by IT vendors and commercial risks from them increasing support charges or even going out of business.
- Delivery Risk related to an organisation’s ability to deliver a transformation project which may cut across the organisation’s management structures and require processes that are not well defined. Potential scope creep must be controlled. Multiple supplier organisations need coordinating and there needs to be a focus on communications across all stakeholders.
The key approaches to minimise these risks are:
- Set up a steering committee chaired by a senior executive to oversee the project
- Ensure effective contracts are in place, with obligations clearly defined, that encourage collaboration
- Ensure effective change management is practised
- Use agile methods to manage activity on a day-to-day basis
- Use a shared data area to give a single view of the truth for all aspects of the project, and an area for managing deliverables.
In conclusion
Knowing exactly where you are at the outset, the AS IS state of your current systems landscape, is just as important defining the exciting new world promised by the TO BE. Ensuring that the project team is effectively managed, with a focus on change management and communications, will mean all parties have clear responsibilities, deliver on time and are held to account, while maintaining flexibility when issues inevitably arise.
The aim is to ensure that nothing is missed so the organisation’s smooth running is not jeopardised as the result of an IT migration project. Utilise experienced third parties with migration project management expertise, knowledge of ‘legacy technologies’ and also understanding of the latest IT developments.