I’ve been exploring some of the things the practicing IT project manager should take into consideration when replacing heritage (AKA “legacy”) software applications. In Part One, I pointed out some of the things that the heritage application represents to the users, and in Part Two, I explored the way the software and the business processes become intertwined over time. In this section, I’m going to talk about the feelings users have for their applications.
One of the concerns we often hear when we suggest substituting a familiar application with a new, web-based replacement is about training. The expectation is that the new application will be more difficult to learn or use than the familiar application, with all of its quirks, multiple-key stroke combinations, and peculiar distribution of features among the menus. Experienced users have a great deal of confidence in their ability to navigate, extract information, and enter data into their existing system. Familiarity gives them a sense of comfort – they like their comfortable old system, even if it’s unstable, quirky, and sometimes forces them to add massive amounts of data in a field called “Comments.” Any replacement is an unknown, and the unknown … well, is unknown.
When I hear this, I usually ask if they’ve ordered anything from Amazon or some other online store – if so, did they need to take a class on how to do it, or did they just fool around with it until they understood it well enough to browse, add items to the shopping cart, and order them? I then add that we’ll have to plan for familiarization and training on new and updated business processes, in order to get them involved in user acceptance testing. This reminder that they have skin in the game is usually enough to either make them even more worried, or restore their confidence based on their role in the process.
Another interesting aspect of the average user’s understanding of their familiar system is information security. They figure they have a pretty good grasp of which user should have access to view, update, and correct data records, and how the application enforces those access rights. Relationships between users and between the users and the system are well-established, and if one user needs to ask another to make an entry, it’s all part of their normal interactions. But when a modern application uses role-based security, they can get very uncomfortable about discussing those same access rights as a property of some hypothetical role that doesn’t match their job title.
In such as case, it can be useful to ask them to describe which services or tasks they perform, and what access they have to the data. Can they create new records? Retrieve existing records? Edit them? Can they access reports? All of the reports, or just some? Who has similar access? Who controls their access? How do they request a password reset? All of these elements are necessary in order to plan for information security in a new application; you just need to map the information you glean from the users to the controls of the new application.
One of the most potentially sensitive aspects of replacing a well-established application with a new one is the impact it has on those sometimes called “Power Users.” They are the ones whom the other users come to for answers and assistance, and for many, the sense of job security that their knowledge of an obscure application can provide is a powerful draw to the status quo. Some of these folks will look forward to mastering a new application; other will resent the replacement application and raise objections every step of the way. I was on one project a number of years ago where the heritage system expert apparently inserted some errors to the data conversion script in order to force abortion of the cutover, but the team recovered, and we went live on schedule.
There isn’t a foolproof approach to getting the support of the power users, but I’ve found that including them as a key resource on the project, and even removing them from daily operations so that the rest of the users have to fend for themselves frequently speeds the process. One of the things I’ve seen is the gradual realization on the part of the other users that they know the system as well as the power user, and maybe better in some ways. And opening up competition for the title of power user in the new system frequently brings all kinds of previously hidden conflicts into view. An effective project manager will anticipate the risk of those conflicts, and have a plan in place to deal with them.
Now that we’ve explored the potential replacement of a heritage application with Software as a Service from the perspective of a user, in Part Four we’ll take a look at it from the perspective of IT Operations, and in Part Five we’ll look at a SaaS procurement and contract from the perspective of the purchasing and legal folks. See you next week!