Once upon-a-time there was no such thing as “legacy” in IT. It was a time when systems were shiny and new and development was Greenfield (and green-screen). We’ve moved on, IT has grown up and legacy systems are abound. Version numbers increase, licenses expire, software is no longer supported. “Upgrade” and “migrate” become priorities on the CIOs agenda.Because upgrades and migration projects have an IT focus, they generally remain in the ownership of, and funded by IT with the business only playing a peripheral role. After all, the requirements are already known; just move (aka “port”) everything that is “as-is” to the new “to-be”.
The reality is all too often slightly different.
It is a common misconception that “porting functionality” is a simple re-write. Here’s an example of a bank who was engaged in migrating its legacy applications onto a new, single stack environment. There were 39 legacy applications that supported 280 processes.
The original business case conducted by the IT organisation was built upon the assumption that 100% of the functionality could be ported. When these figures were shared with the business they baulked. They were incredulous that IT could be building something new, and building all that was wrong in the existing processes on the new platform. What they didn’t have was a business case that articulated what the cost “wrong” was. So the project was put on hold, no longer could it be soley in the ownership of IT, the business needed to ratify the requirements.
The business took an enlightened approach to requirement ratification (they got me involved!) We ran a series of focus groups with key stakeholders, then went into the field undertaking what I could pompously call ethnographic research. We spent time shadowing staff on the ground, observing staff-customer interactions, watching how they interacted with the technology, what applications they used, how long they spent on them and what bank processes they touched. It rapidly became clear that much of what IT was proposing to “straight port” was not fit for purpose. Simple, core bank processes took up significant customer time. For new staff to get up to speed with the basket of applications, it took weeks, if not months.
What soon became apparent, (as expected by the business), only a fraction of the overall functionality offered to the bank users was actually used. Indeed of the thirty nine applications that users had access to, five were redundant; their functionality was never used or was replicated elsewhere. When looking at banking processes that the applications covered, almost a quarter were ripe for redesign. Initially there was resistance to this figure; after all, the processes existed “as-is” and the bank was working with them. The original business case did not justify the significant additional cost that redesign over port would offer. But the ethnographic research gave grounds to challenge this. We could point to the time that users spent interacting with the technology rather than interacting with the customer. The underlining processes were not necessarily broken, but their technical implementation hindered staff work effectively. For example, on opening an account for a new customer the bank employee more time keying data into the application than talking to the customer. This prevented a conversation; the first personal touch point the bank had with a customer was a poor experience. And focussing upon form filling rather than the needs of the customer left both parties potentially unfulfilled.
Worse for the bank, when an existing customer informed the employee of a change of name and address (i.e. just got married), the employee would visibly sink in their chair. Again. rather than engaging in a conversation, congratulating the customer, talking about their new financial needs following their change of life, they had to update the same information in six different places. The technology was an impedance. And thus a cost.
What if we could reduce the time spent entering data into the system? What if there was time for conversation? Time to probe the customers financial needs…? We could model different scenarios whereby this initial customer meeting could drive revenue with cross sell opportunities. Furthermore, if we could reduce the time spent with each customer and thus increase footfall there would be an opportunity to reduce costs. For example, assume the request for a change of address generates a new home insurance lead, model different conversion rate scenarios and we have a business case for improving the change of address process.
To demonstrate the art of the possible, we created a functional prototype. This started with lo-fi sketches, testing these with users before moving to an HTML prototype that supported different journeys through key processes. This was tested with users in a usability lab. We got bank staff to come in, gave them tasks to complete in a role playing scenario (e.g. Here’s Jon, he is a new customer. He wants to open a current account…) With no training, everyone who played with the prototype was able to accomplish their goals, something that was impossible on the current applications (that remember, IT just wanted port). For the most data-entry intensive process, that of completing a new customer account opening, we were able to reduce the time taken by more than 30%. And this was for novice users who had never used the system before. We now had metrics that we could input into the business case, to further strengthen the case for redesign.
And that’s when I left the project. Some functionality was still ported, but the focus shifted from an IT owned project to a business owned programme of work.
This case study demonstrated the fallacy that porting functionality should ever be a simple task that can be driven by IT. It provides an excellent opportunity to audit what you have got and make things better. Almost undoubtedly there will be a compelling business case for doing something more drastic than an IT owned project to make changes to the underlying technology. And the best way to demonstrate this? Ask the people whose lives are impacted by the technology. Use prototypes to test ideas of change. And take measurements.
(I’ve been on holiday, hence the ability to write long blog entries. In case you were wondering!)
