Editor’s Note: Housing 21's Information Services Team won HDI’s Best Change Management Initiative Award for 2019.
Housing 21 is a leading, not-for-profit provider of retirement housing and extra care for older people of modest means. Based in Birmingham, they operate in nearly 200 local authority areas across England, managing around 20,000 retirement and extra care living properties and providing more than 42,000 hours of social care each week.
What challenge was the support organization attempting to solve when you identified the need for improving change management?
Major fragmentation between the IT department and other departments in Housing 21 inhibited the experience by both staff and the residents of the retirement properties.
The Housing 21 IT team recently deployed a major new system to our Operations team, providing them with a tablet-based, Wi-Fi-connected, 4G-enabled mobile working solution for delivering services to residents living in Housing 21 properties. As part of the system deployment, lots of functions previously run from centralized teams at the Head Office were devolved to local staff to deliver a more effective, in-person service.
While this new system delivered a range of new IT equipment and software, it was not an IT project per se (even though the IT department played a major role in its delivery). The system is still in the process of being handed over into business-as-usual (BAU) support, while also undergoing some functionality changes; and this is being handled by the Projects team in conjunction with IT.
It became evident that some changes being required were pure IT changes, to be handled by the IT department using existing subject matter experts. But other changes were being carried out by the Projects team directly, without intervention or support from IT.
Changes were being carried out without intervention or support from IT.
IT’s changes were being recorded and managed via established change management processes in SysAid (the ITSM tool used by Housing 21), but the Projects team’s changes were not, and IT was not aware that the Project’s changes were being made. This was the challenge that we needed to solve.
How did you choose this particular approach to change management?
Our Projects team was becoming frustrated with an apparent slow turnaround time for RFCs, as they were unaware of the processes required in a change management environment to safely assess and deliver a change, while taking into account knock-on impact s with other scheduled works. Although the process made perfect sense to the IT department, who had a wider view of the requirement s in context with managing the wider infrastructure and estate, the Projects team only saw their (relatively) small part of the change management picture and were unaware that resourcing levels, f or example, meant that not all of t heir RFCs could be brought to fruition in the timescales they demanded. The Projects team was invited to a change management overview meeting, which explained the context in which change controls were applied, taking into account resources, timescales, systems-availability, and infrastructure-availability.
What was your adoption process?
After the go-live of the new systems in May 2019, the Projects team would email a brief requirement to the IT department giving an outline of what it was they were proposing to do or what changes they wanted IT to make—on occasions, these “requests” were even made verbally. There was rarely sufficient information provided to fulfill such requests, much less create a good RFC from it. This was due to the Projects team being unaware that what they were asking for did not contain sufficient information.
Throughout June, it became evident that this methodology was not working for the IT department. The IT management team met at the start of July to discuss the lack of information issue and decided to create a template document for the Projects team to use, which provided them with the information required to successfully request such changes. Once they were accustomed to providing the required information in the correct format, we looked at how we could make it easier to get that information to us. The existing method was merely a Word document attached to a request ticket for the Infrastructure or Apps Support teams to transpose into a workable format for IT.
We then developed a request template within SysAid (replacing the Word document) for that data to be directly input into fields that matched our change management process, complete with categorization and prioritization, reducing the amount of time an IT resource had to spend looking through a ticket.
Finally, we made the request template available within our self-service portal, allowing the team to log all the required information directly into a service request in SysAid, which could then be handled with the minimum of triage from the service desk.
We saw an immediate uptake in the use of the self-service portal by the Projects team, resulting in an almost total reduction of walk-ups to members of the IT team. With the data requirements scoped out and captured accurately in an easy-to-submit form, both the projects and the IT departments can now focus their activity on providing speedier services to end users.
In the future, our plans are to take these details and use them to directly create an RFC with all information pre-populated, further reducing the time spent by an IT resource managing a ticket.
By the end of August, the Projects team will also be able to use SysAid to log all their changes directly, allowing them to then see the status of a change they have initiated. This helps us provide a better service to them, and then the wider business, by allowing them to see status and progress on RFCs, without having to request updates from IT resources (who can also then spend their time better in their roles of providing service to the business as a whole).
While we are still in the beginning of this initiative, the progression from informal requesting of works from the Projects team to the IT department has improved incrementally, but significantly, so that all requests are now captured in an agreed process and manner. It has meant that there is no ambiguity in requirements as all data required is specified and captured at the point of entry into the system, feeding into a defined process that the entire IT department works to. It has brought structure to the chaos of urgent requests and gives us, as a department, visibility of works we would have otherwise been unaware of. For the Projects team, it has been their first step into a service management tool environment, and they have already seen the benefits of doing this by identifying that the tool can also offer them advantages in its use.
We are now planning a further migration of their BAU processes and work packages into SysAid’s ITIL-compliant processes for incident, request and problem management. The Project team will migrate their work lists from existing Excel spreadsheets into our SysAid implementation to allow them to better assign a resource to issues and manage those issues through to resolution, thus providing a better service to the business as a whole.
Our success in this regard will be continually monitored in our Change Approval Board, where we expect to see fully formed RFCs submitted for approval with realistic timescales requested, backed up by fully resourced action plans whilst also impressing that just because it’s urgent, it’s not necessarily an emergency that requires processes to be significantly deviated from. The ultimate arbiter of the success of an RFC will be two-fold:
An increased set of functionalities delivered
No additional incidents tickets raised because of the RFC
What challenges did you overcome within the adoption, and is there anything that you would do differently?
Perception and understanding of change management by the Project team has been the main obstacle in our initiative. Everyone always thinks that their issue or requirement is the most important one above all others, and that’s due to not seeing, or being aware of, a bigger picture.
We are fortunate in that our IT estate has been very resilient for well over five years and has not suffered a significant outage. This is not by luck; it is due to having robust systems in place and effective change controls to ensure that risks are managed and minimized. It was not widely known in the organization that having these in place has directly attributed to our core systems’ stability. So we wanted to fix that!
With our change management initiative, all of the factors that attributed to the core systems’ stability have now been demonstrated to the Project team by showing them lists of active changes with go-live dates—to show other works taking place, which proved that timescales demanded for some of their changes were totally unrealistic and would have a detrimental effect on other aspects of planned works taking place.
With the Project team joining the IT department in a single change management process, it is now the intention to reintroduce a formal change advisory board (CAB) for changes to be presented before scheduling them to take place. Currently, the CAB exists virtually within IT, but will only meet physically if presented with a large and complex enough change requiring special focus to minimize risk upon enacting.
With hindsight, having seen the issues relating to Project-driven changes, we arguably should have been more proactive in selling the benefits of a formal change management approach to the Project team and gotten them on board with our change management processes much earlier than we did. A lack of visibility of some of the changes being made by the Project team clouded this opportunity, preventing us from seeing the full picture.
Was there anything unique or innovative about the change management initiative?
For Housing 21, this is the first instance of a non-IT team being brought into a formal process previously 100% focused on the IT department. IT required significant negotiation with the Project team to sell them the positives of taking a formalized approach, where previously they had carte blanche to do as they pleased without seeking or needing approval from IT.
How has the change management initiative improved the overall efficiency of the support organization?
The start of our change management journey with the Project team has led to a greater appreciation and understanding of why IT acts the way it does. It’s not out of habit, ritual, or having process for the sake of processes sake, but rather it’s there to help us control and minimize impact on the otherwise-stable estate that Housing 21 has enjoyed for so long.
Having a defined change management process has meant that our customers have enjoyed long periods of system uptime across the board, as changes get delivered into production seamlessly, meaning they spend more time doing the role they are employed to do and less time trying to communicate issues to the service desk. The additional value for our service desk team is that they do less fire-fighting of incidents reported by the business. Outside of scheduled downtime for system upgrades, system uptime across our major monitored infrastructure items and business systems has averaged 99% over 12 months.
HDI honored Service Management Award finalists and winners at Service Management World. Visit the HDI Awards pages to see the full list of winners and learn more about HDI Service and Support Awards.
HDI is the first professional association created for the service and support industry. Since its founding in 1989, HDI has remained the source for professional development by offering resources to promote organization-wide success through exceptional customer service. We do this by facilitating collaboration and networking, hosting acclaimed conferences and events, producing renowned publications and research, and certifying and training thousands of professionals each year. At 150,000 people strong, HDI is a community built by industry peers and leaders that gives its members the resources, knowledge, and drive to be great at what they do.