After one week on the job as CIO of Des Moines, Michael Armstrong was thinking he’d made a big mistake moving to Iowa from Lexington, Ky.
He was discovering that the capital city’s civil servants thought they were doing just fine without IT. Many of the 2,100 city workers were perfectly content to work with paper, pens and Post-it notes — even those who had access to the city’s antiquated desktop PCs. As Armstrong strolled past one department head’s office in September 1997, he noted that his computer monitor served as nothing more than an expensive frame for his children’s artwork.
In a department meeting, he butted heads with the assistant chief of police, who explained in no uncertain terms that he didn’t want the CIO telling him how to run his department. “It was gloomy,” Armstrong says.
Today, Armstrong has moved Des Moines from a mainframe to a distributed environment, installed a fiber-optic network to connect all facilities, and developed the city’s first systems standards. But winning over busy and technophobic police officers, city clerks and administrators was what kept Armstrong up at night. And in the end, he ranks it as his greatest achievement.
Almost every CIO can tell horror stories about her toughest users. Health-care CIOs would say that doctors are the most difficult users, while IT execs in the tech industry might argue that their techno-savvy employees are the most demanding. One truism emerges: The ability to handle tough users has become a vital skill for all CIOs, if only because the success of expensive enterprisewide IT projects ultimately hinges on user adoption.
There are a variety of reasons for user resistance. Some users may be technophobic or afraid of change, as in Des Moines’ City Hall. Some may be too busy or focused on their own priorities to see the importance of IT to their work. Michael Jones, corporate vice president and CIO of Children’s Health System in Milwaukee, faced challenges when he tried to introduce a computerized physician order entry (CPOE) system to doctors there. Still others, like CIO Terry Milholland’s user constituency at EDS, may be so knowledgeable about systems and business processes that they have their own ideas about what’s best for the enterprise.
“There are a lot of reasons users can be difficult, but what we’re really talking about is people that, for whatever reason, are blocking progress,” says Leigh Kelleher, global leader in the global learning practice at Braxton (formerly Deloitte Consulting) in New York City. “And it’s the CIO’s job to figure out who those people are and why they’re reluctant.”
Des Moines’ CIO didn’t know how to win his users over right away. In fact, his first attempt was a disaster.
Armstrong wanted to implement a PeopleSoft application for financials and HR. He decided to do the project in nine months and introduce the financials and HR pieces all at once, hoping to get the pain over quickly, somewhat akin to ripping off a Band-Aid. But during the course of the nine-month rollout, 40 percent of the employees in the finance department’s accounting division left; some involved in the implementation simply got burned out by the long hours while others were scared off by the changes to their jobs. The HR department also lost a few employees. And halfway through the project, Armstrong realized his staff wasn’t going to cut it in the new environment. He fired 60 percent of his workers.
“The implementation was incredibly disruptive. We pretty much blew up three departments,” Armstrong explains. “I was not prepared for the depth to which it would affect the organization.”
It was a potentially disastrous situation for a CIO hoping to build a solid relationship with his already wary users. In fact, a botched project is one of the major reasons users get turned off to technology. “The most phobic users are people who have been burned by poor implementations,” Braxton’s Kelleher says. “They may not be afraid of technology. They may not even be afraid of change. But they’re afraid of poorly managed change. And that’s the biggest concern that CIOs should have.”
Armstrong attempted to ease tensions by admitting he messed up. “The best thing you can do is take the heat,” he says. And he learned some valuable lessons in how not to introduce a huge, new system to reluctant employees. He had rushed the implementation, promised more than he could deliver and underestimated the amount of change the city could absorb at once.
Two years later, he applied those lessons as he attempted to introduce technology that would automate how Des Moines received, managed and resolved requests from its 200,000 citizens.
You Can Right City Hall
Armstrong knew that he needed buy-in from all 15 city departments to make the CRM system a success.
With that in mind, he plotted his strategy. First, two of his project managers spent a year talking to city workers to find out what they did when they received calls. Those conversations led to a useful outline of the more than 1,250 different types of calls the city received — from trash pickup and pothole patching to barking dogs and cats up trees. It also made the users feel important. “A lot of them were flattered because they had never been asked about what they did,” says Armstrong.
Based on the city’s needs and budget constraints, Armstrong decided to spend $300,000 on the whole project using Heat software from Colorado Springs, Colo.-based FrontRange Solutions.
To alleviate any potential alarm about lost jobs or reorganization, Armstrong decided against going to a central call center to operate the system. “We didn’t want people to feel that their jobs were being threatened, especially at a time when we’re trying to get knowledge from them,” Armstrong says. “And we didn’t want to have to reeducate the public, many of whom had gotten used to calling specific departments or even a specific person they knew by name, when they had a problem.”
At the same time, Armstrong worked to demonstrate the value of the system to those departments that were less than excited about the upcoming changes. The police didn’t see what the system would do for them that their 911 system didn’t. Their technology wasn’t broken, they argued, so why fix it? Armstrong pointed out that standardization would help with interdepartmental programs that were not strictly police activities, such as a project that offered concentrated police, fire and social services to distressed neighborhoods.
Armstrong began the implementation with the department where the work would be most intense: public works. He thought it was a good place to start for two reasons: It received the most calls, and the department head was an advocate of automating its processes.
But not everyone in public works was thrilled with the system. Greg Cloe, the department’s customer service supervisor, would have preferred a package solely designed for public works’ myriad needs instead of an enterprisewide system. “I knew it would require a significant dedication of resources to get it to work for us, and I was concerned about that,” he explains.
To address those concerns, Armstrong and his team worked closely with Cloe to customize the software. “Because of the IT team’s cooperation in listening to our needs, we’re pretty pleased with the overall product,” Cloe now acknowledges.
Armstrong brought on one department at a time, enlisting key people in each area to help him customize the system for that department’s needs and utilizing these “change evangelists” to help drive the implementation.
“That’s one of the things we’ve learned over the last few years: Involve people early and often,” Armstrong says. “And not just the department heads and line managers, but the actual people doing the work.”
Today, the citizen response system is up and running with 12 of the city’s 15 operating departments (including all major service providers) using it to handle 9,000 calls a month and automate processes previously managed with Post-it notes. The system provides a standardized way to take a complaint, store it in a central database accessible by any city worker and track the status of the associated task. It also generates automatic alerts for follow-up action and offers the capability to analyze the data for reports. In fact, the system was named one of the 10 most significant CRM implementations of 2001 by Boston-based consultancy Aberdeen Group.
But one of the best indications that Armstrong has tamed his tough users is the fact that the police department has agreed to let Armstrong and his team take over responsibility for its information systems. It signed on for a $5 million to $7 million IT upgrade covering everything from 911 systems and electronic records management to mobile data systems and radio improvements.
Why Doctors Are a Pain
When Children’s Health System’s Jones wants to get through to his most demanding group of users (the physicians), he goes to grand rounds. As he joins the residents, interns and attending physicians in the Milwaukee hospital’s auditorium, the topics range from neuroblastomas to psychological sequelae after pediatric trauma. But when Jones attends, the discussion includes IT.
Doctors are not technophobic. Quite the opposite, says Bradford Holmes, health-care research director at Cambridge, Mass.-based Forrester Research. “When it comes to clinical technology — new laparoscopic technology or a new defibrillator — lots of them are technology addicts,” he says. But when it comes to information technology, doctors, Holmes says, “have a limited desire to learn new software and applications, particularly if it will take them a lot of time.”
So when Jones decided to introduce a CPOE system at the hospital last year, “There were months of going to grand rounds, physician directors’ meetings, any open discussion that we could find,” he says. He had already built some credibility with these users shortly after his arrival in 1996, when he upgraded a hospital information system to handle administrative processes like registration and billing.
This time around, he enlisted the help of critical care pediatrician Dr. Carl Weigle, a 12-year veteran of Children’s Health. Since the doctors weren’t exactly clamoring for automated order entry, having a veteran physician touting the system definitely helped. Getting ardent users to advocate with their peers is the best way to get buy-in for big technology changes. “That’s just the way things work in the medical culture,” Holmes explains.
But that was just the first step. What draws doctors in are features that improve patient care, save time or generate revenue. Weigle and Jones found that their best selling-point for CPOE was patient safety. According to the National Institute of Medicine, avoidable medical errors kill between 44,000 to 98,000 patients a year, and automated order entry, which eliminates mistakes due to indecipherable handwriting, offers a powerful solution to that problem.
Jones recruited the most enthusiastic users to help in the selection and implementation of the CPOE system. As the new part-time medical director of information services, Weigle also tried to involve the users that were the most dubious about the project. “The ones that were asking the smart questions, the tough questions, I tried to recruit to our selection team because I knew they would ask the important questions,” Weigle says.
Among the unconvinced was Weigle’s boss, Dr. Thomas B. Rice, director of the pediatric intensive care unit. “I was skeptical of how the technology could help me as an end user,” says Rice, who has worked at the hospital for 27 years. According to Rice, the flexibility of the IT team in responding to his and other doctors’ concerns was critical. “Mike’s biggest strength is that he’s open,” Rice says. “But the key has been having [Weigle] involved; he understands the physician end of it.”
Once the interdisciplinary team decided to invest $6 million in the installation of the CPOE system from Boca Raton, Fla.-based Eclipsys, the next hurdle was training. For the busiest users, this can be the point of pain. You may have sold them on the benefits and given them all the right functionality, but if they don’t have time to learn how to use it, all is lost. So Jones decided to cut training time. “We limited it to one hour and just trained them in the basics,” says Jones. He also ended up training the most gung ho residents separately from the attending physicians, who were not as motivated to learn. “We had tried training the old guard and the new guard together in the first training session. The attendings were complaining and asking how is this going to work, while it was going too slowly for the residents,” Jones explains. “One approach did not fit all.”
He supplemented the hour-long intro to CPOE with ongoing support from users more familiar with the system. “Doctors learn according to ’see one, do one, teach one.’ You watch someone do an appendectomy, you do one, and then you teach someone else to do it,” Holmes explains. “You have to ditch the manuals and the long classroom sessions.”
Following the launch — half of the physicians were brought on board in June 2001 and the other half in September 2001 — Jones provided 24/7 user support the first two weeks after each rollout. The implementation has included a great deal of follow-up work. “Someone in IT makes the rounds once a week to all areas of the hospital to listen to and document complaints,” he says.
Adoption rate is now nearly 100 percent, according to Jones, although a certain number of surgeons tend to rely on residents to do their computerized order entry. He has resigned himself to the fact that some may never use the system.
But the successful introduction of CPOE has further enhanced the IT department and the CIO’s credibility among hospital users. Jones is considering several upcoming projects, including a new picture archiving communications system, a move to electronic medical records, updated operating room systems and a pharmacy robot. But he understands that each user group can handle only so much change. “We would get in trouble if we introduced too much change at one time,” says Jones.
Too Smart for Their Own Good
The people who work for EDS CIO Milholland love technology. And therein lies the problem. “I wouldn’t exactly say that I get second-guessed, but there are lots of people with opinions about what we ought to do in terms of technology and what we ought to use,” explains Milholland, who is also senior vice president and CTO.
Fortunately, Milholland has been dealing with smart, informed but often troublesome users for his entire career. He came to EDS, headquartered in Plano, Texas, after 21 years at Seattle-based Boeing. As a result, he understood that an autocratic approach would never work at EDS. “When you’re dealing with people that are technology savvy, you could stand there as a sort of dictator and say, I know best. And for a little while, you’d be successful,” Milholland explains. “But in the long run, it’s better to invite other opinions.”
To that end, all of the company’s 140,000 employees in 60 countries are permitted to weigh in on IT issues via a Web-based work space. EDS also has established operating councils that include users from various business groups. Milholland says he’s tried to create an open and flexible system — with one exception. “After there’s been a vigorous exchange of views and something is settled on, that decision must be enforced,” he explains. “Then the debate is over.”
When Milholland was looking for an ERP solution in 2000, he found that there were all kinds of users who had pet technologies they wanted to use. After soliciting input electronically and hashing out issues on the ERP operating council, the decision was made to upgrade to an SAP 4.6c system. “Along the way a lot of people came along and said they would prefer the latest package from this or that vendor. But in the end, we made the decision,” Milholland says. Thus far, all U.S. locations are upgrading, and the EDS offices in 23 countries have standardized on SAP for finance and HR.
Milholland says it’s often enough just to give users the opportunity to be heard. “If you provide that path, you actually reduce the amount of noise you have to deal with.”