Users and IT Change. Think of it like rehabilitation.

My mother recently had hip replacement surgery. She’s tough, has needed this most of her life, and only had the surgery now because doctors wouldn’t treat her any more without it. So we kids are taking our turns visiting her during her six to eight week recovery period. The one thing I’ve noticed since I arrived, is that while she is thrilled to have a hip that works like it hasn’t since she was a teenager, the things she cannot do frustrate her. One rule is that you take steps one at a time during the healing process, stepping up with the good foot and only then lifting the other. Yesterday we dropped by the hospital to straighten out a billing error, and she decided to climb some cement steps like she was a teen. Ever dutiful, I called her on it, and pointed out the prescribed procedure. “Well I have to start using it some time, it’s going to get weak if I don’t” was the reply. Bending too deeply is another no-no while healing, and that one she follows, but it really irritates her every time I have to pick something up.

This bears an uncanny resemblance to something I’ve seen before. Many times.

Every system gets outdated. This is both a fortunate and unfortunate axiom of contemporary computer science. The fact is that the reasons the system was deployed go away, the requirements of users change, the technology available changes, or in many institutions, the champion and/or technical specialists leave. That’s the point at which upgrades look much less appealing, and replacement is considered. No one – not the business, not IT, and certainly not top-level management wants to replace a system that works just fine, but when two retired guys living on a remote pacific island are the only ones who can maintain it reasonably, it’s time to move along.

When the time comes, if the system is important or widely used, IT takes huge steps to get requirements right, line up appropriate resources, set contracting for purchased bits of the solution, get AppDev set up for any integration, network staff and storage admins working on provisioning, and gathering requirements from the users. On one project i was involved with, user requirements gathering was an astounding waterfall method of approach every stakeholder, get them to assign people to work with IT, get all the information, then go back and try to reconcile different groups’ various needs. To me it was a fascinating process because users’ needs changed as the rounds went by. This was an incredibly important application that was used by almost every employee in this mid-sized company. After a while the pattern became clear… The first time you asked, answers were all in relation to the existing system, but as you circled back, requests and requirements started to include the state and capability of today’s technology instead of the 25 year old technology they were leaving. In the end, it was pretty clear that the users would get what they wanted, and some extra stuff they had only been dreaming of.

Because one portion of this monstrous system was billing, it could not run in tandem with the existing system. One or the other had to be live, in the oft-repeated on/off scenario.

Like many large projects that have an “on/off” switch to them, the project ran in parallel to the existing system for many months while user acceptance testing was going on. Every night the data from the existing systems was ported over to the new one, and staff in each department dedicated a couple of hours a day testing and seeing how they would do all that they used to do.

And that’s where the trouble started. While most of them were thrilled to have the new system in place and saw a future where they could do astounding things, the product in front of them was foreign and caused work slowdowns akin to the slowdown taking one step at a time causes my Mother. The complaints started rolling in. “I used to do X, now I don’t know how to do it” was a common phrase. Interestingly, the organization had given us time and resources to do end-user training on the new system, and the testers had all been through it. Since there was a Q&A session at the end of this training, all questions should have been answered, or at least most questions.

Slowly, one by one, the people with the worst problems started talking about how bad this system was. After millions of dollars and hundreds of man-years, that is not exactly what IT needed to hear. The problem, as it turned out, was that we did end-user training up-front, having budgeted it and slated it so that the users were trained before they touched the new system. That was fine for what it was intended, but a class room and guided instruction is nothing like sitting and doing your daily job. Once they got back to their desks, then the questions that would not have come up in the classroom started appearing. So we set up a variety of communications channels, and we went out to their sites to sit with users while they tried to do something, and showed them where to find it.

Just like my Mother with her hip is improving daily, and getting closer to normal walking bending and climbing again, users started getting closer to the productivity they’d had on the old system. Just like the physical therapy they give after a hip replacement, our assistance helped the users get back to “normal”. In the end, the testing users became the advocates for the new system, pointing out all that was easier, and all that was just not possible on the old system.

We in IT are the agents of change in these situations. We drive users to solutions that are in the best interests of the company, we push back against systems that would spread our staff too thinly, and we architect both large and small bits of an application, envisioning in our mind’s eye how much better it could be, while the users sometimes don’t see that future until presented with a prototype or even a working model. But too often we’re seen as doing to our partners in the business, rather than doing for them.

Fight the perception, teach them how to work like they used to, help them get up those stairways. It’s a part of the job we overlook when immersed in this database or that application or the other network appliance, but it is a critical part. As a service organization there are some things that will always be rough for IT, but this is one area we can make better by monitoring and communicating, so take the time, the business isn’t better with a new application, the business is better with a new application that users know how to do their jobs with.

Related Blogs:

Published Jun 07, 2011
Version 1.0

Was this article helpful?

No CommentsBe the first to comment