Regardless of size, every system implementation project will require some Business Change to ensure success. Making change is not always a well understood subject. In this blog we hope to give readers a better understanding by providing an eight step guide on this occasion focusing on the NHS but the principles can be applied to any IT driven change project.
So what is business change and why is it so important? Simon Stevens’ “NHS Five Year Forward View” places a focus on change and joined up care. It explains how the NHS will change the way it serves patients and care professionals by giving them access to electronic medical records and services online. Doctors and nurses will spend less time wading through paper notes and patients will be able to manage some of their own information with secure access. Pad and pen record keeping is going to be replaced with joined up IT systems and shared processes. Steven’s vision of united services across acute, community, mental health and other agencies including social care will require large scale process improvement across and within individual Trusts. Changing the way they work in order to improve patient care, reduce clinical risk and make cost savings is business change.
It can be done with or without a new IT system and in fact many Trusts have separated these two activities. Transformation teams at many Trusts are already looking at how cost and efficiency savings can be made. For example; reducing length of stay, closing wards or beds and improving administrative activities around procurement such as refining stock controls to reduce the number of drugs that expire annually. These examples are not necessarily linked to new IT systems and can be made by improving existing processes. The change from paper to electronic medical records however needs to be aligned to the chosen EPR software as the design of new processes will be dependent on system functionality.
So what is the best way to make change? The following 8 steps are intended to provide a quick guide:
Step 1: Make sure someone owns the change
Appoint a business change manager to manage the change. They will identify the risks and dis-benefits by mitigating resistance to change and manage any change overloads by clear, concise and appropriate communications. This person is the bridge between the programme and the users. It is an important role and requires strong leadership with good communications working hand in hand with the programme manager
Step 2: Understand the internal and external influences
Start by looking at how well your organisation performs looking at Structure, Systems, Staff, Skills and Strategy. Do these all align? For example you could use McKinsey’s 7S framework which will allow you to review these shared values and identify what needs to be realigned to improve performance. This will also help to identify risks the change will expose during the programme so the team can prepare mitigations to reduce the likelihood and impact on business as usual.
Step 3: Identify current processes
Spend time with key users, both in workshops and in clinical areas. Understand what everyone does on a day to day basis and ask them why they do it that way. Spend time observing in clinics and floor walking in wards to gain an understanding of current working practices. This will allow the team to identify the frustrations that clinicians experience on a daily basis and where inefficiencies exist. Talk to the clinicians and document your observations using process mapping tools such as Rich Pictures, Flowcharts, Swim-lanes or Data flow diagrams. Review standard operating procedures, understand the official processes and compare with the observations in clinical areas. They may be different. You need to identify the process that does happen and not the one that should happen.
Step 4: Validate the outputs
Validate the outputs from the fact finding in Step 3 by holding workshops and discussing findings with key users. Make no assumptions and challenge everything. Keep a good record using data capture tools and make sure the final versions of each process are signed off by a variety of clinical users. After all it is them who will feel the change not the programme team so you will need their agreement.
Step 5: Design the future state
If your change is co-dependent on a new IT system work closely with the supplier to ensure your ‘To Be’ processes compliment the software. Use workshops with key staff, brown paper and yellow stickers transferred onto Visio to jointly capture the new processes, ensure you document your design, keep version controlled copies and record why decisions were made. Identify risks and issues as you go along and review regularly to ensure mitigations remain valid. It is helpful to prioritise your requirements by using a business analysis format such as MOSCOW.
|Must Have||A requirement that is fundamental and must be met|
|Should Have||A requirement if not directly met has a workaround|
|Could Have||A requirement that can be left out of the development|
|Won’t Have||A requirement that has been noted but may be developed in the future|
Step 6: Managing the benefits
Align the ‘To Be’ state with the benefits listed in the programme business case. The primary purpose of determining benefits is to support the financial investment in a cost/benefit analysis. For example, if a strategic goal is to deliver an electronic medical record across the trust, then the change should support this goal by closing gaps in information flows. This in turn should support more informed clinical decision making and therefore improving patient safety.
Benefits should be measurable, they are likely to fall into four categories; financial cash releasing, financial non-cash releasing, quantifiable and non-quantifiable. All are valid but in the main the success of the programme will be measured against the first two. Try to identify where the future state will deliver cash releasing benefits to demonstrate the success of the programme and support the cost / benefit analysis in the business case.
Step 7: Test the change
Do the new processes and/or system meet, exceed or fail the objectives? A good test strategy will be required. It should cover, the approach to be taken, the test stages, people and skills required, test scripts, success criteria and how the testing will be tracked and managed. Without this how will a Trust know if their future state design works? A good test plan should follow five key stage points, plan, execute, review, re-test (as many times as necessary) and finally sign-off. A future blog will cover testing in detail to help you plan your resources and how to manage scenarios.
Step 8: Let everyone know
There is a further step, a very important one. Communications. Ensure regular and consistent messages are issued to stakeholders. The success or failure of a change programme is dependent on good, clear communications.
Our next blog will focus on how to develop and deliver a consistent and cohesive communications plan.
Article by channel:
Everything you need to know about Digital Transformation
The best articles, news and events direct to your inbox