Gary Hulkowich is one smooth operator -- when it comes to moving his company to a new IT infrastructure. Hulkowich believes IT operations professionals should ensure serene transitions by playing the crucial-but long-neglected-role of preparing their organisations to receive a new infrastructure.
That revelation occurred to him more than a year ago, when the electric transmission business unit of his company, Charlotte, North Carolina-based utility Duke Energy Corp., decided to move 1,000 corporate e-mail users from IBM Corp.'s Profs to Lotus Development Corp.'s Lotus Notes. Deregulation of the power industry was forcing Duke to respond to an increasingly competitive marketplace, and Duke senior management was determined to make the most of the company's information technology.
Hulkowich, who has been with Duke for 10 years, is part of the 23-person IT group that senior management created to serve the 700-person business unit. The group provides end user support and makes sure the computer infrastructure-servers, PCs, network, printers and the like-runs smoothly. As his business unit's IT infrastructure manager, Hulkowich focuses on previously overlooked aspects of the transition. "I prepare the organisation for receiving the new infrastructure products through training, communication and change management," he says.
In the past, according to Hulkowich, Duke's corporate information management (IM) group devoted its energies to deploying applications but paid scant attention to the needs of individual business units. "Training and change management-people tend to leave out these areas. But if you pay attention to these things, the costs of the deployment and the ultimate maintenance of the applications will drop.... The IM group isn't in a position to deliver these things because they're not close enough to the business unit," says Hulkowich.
Regrettably, Duke's attitude is not unique. IT operations professionals work closely with end users, but they get little credit for doing what they do.
Unless and until systems go haywire, everyone assumes the operations people are just doing their jobs, and few IT executives think to invite the operations staffs' participation when a new infrastructure is in the works: They are confident the operations people will support the new infrastructure just as they supported the old one. And that's that. Right?Wrong. The role of an IT operations professional varies from one organisation to another, but end user support is the common denominator. Enlightened IT executives now acknowledge that to execute a maximally efficient infrastructure change, operations people, whose duties position them to anticipate and forestall problems, need to play active roles in the process. And today, rather than simply handing finished systems to users and expecting the operations staff will automatically deploy their new applications, thoughtful developers are inviting operations' contributions right from the initial stages.
The payoff? Users are quick to embrace new systems, and by accelerating user enthusiasm, the organisation enjoys greater employee productivity and realises a prompt return on its investment.
In many companies, however, IT operations people are caught in a classic bind.
Although they are expected to support new applications and hardware, they lack the clout to participate in the planning process. "The operations group is seldom invited to participate," says Tom Walker, CIO at DecisionOne Corp., a computer maintenance and IT support outsourcer in Frazer, Pa. "Supportability, operability, [total cost of ownership of systems]-these things are never fully addressed. [The implementation team is] focused on delivering a solution; they're not thinking about what it takes to run that solution. But the operations group is ultimately held responsible for the supportability of the product."Training and TimingIn years past Duke Energy did not involve its operations people in the early stages of major systems migrations. "The applications developers [from the corporate IM department] were chartered with preparing the business units to receive the product," says Hulkowich. But since corporate IT management didn't hold developers accountable for that process, user preparation seemed unimportant. The implementation team simply imposed the new system on users, and IT operations dealt with the subsequent chaos.
A few years ago, prior to dedicating local IT groups to individual business units, says Hulkowich, "we had sloppy rollouts that were not timed right." Either users were trained so early they had forgotten the new system before it went online, or training was so late users swamped the help desk with calls.
And because the IM people in charge of rollouts commonly overlooked such tasks as performance monitoring and capacity planning, servers often crashed when new applications were turned on.
In all fairness, each rollout was so demanding that the IM department couldn't afford to make a full assessment of the business units' various training needs.
For example, Hulkowich's unit, electric transmission, employs many field engineers who simply don't have time to report to a central office for training. Unless the IM team arranged training for engineers in the field, they missed out.
For the transition to Notes, however, the electric transmission unit had its own IT group to protect its interests. At the start of the project, Hulkowich analysed the unit to determine what level of change it could tolerate and to optimise the transition schedule. To facilitate a low-impact switch to Notes, he planned just-in-time training, published newsletters and arranged such change-management activities as brown-bag lunches that doubled as training sessions. At noon, field engineers generally congregate in the crew rooms at the "tie stations," and Hulkowich held lunch-time training sessions there at shared workstations.
Hulkowich believes his group's efforts made a significant difference. "We got the users to accept this a little quicker than they would have. We set some deadlines for them, but we didn't shove it down their throats," he says. By scheduling training sessions well in advance, Hulkowich's team made sure all end users got Notes training the day they received the application. It was important for everyone to make a pain-free transition from the Profs mail system to the different capabilities of Notes. Users had to learn, for example, that although Profs allows senders to recall unread messages, Notes has no such provision. On the other hand, the Notes option of attaching Word documents and graphical files to messages added a significant e-mail capability.
Of course, Notes is not just an e-mail program. A much more powerful application, Notes has changed the way Duke employees work together. After years of exchanging documents in hard copy form, they have learned to use Notes's database and discussion-forum capabilities to collaborate electronically.
Hulkowich believes the extra training accelerated users' receptivity to Notes and enhanced their abilities to use it productively. "We didn't want just to train them. We wanted them to take advantage of the more advanced tools in the application in a shorter amount of time," he says.
Cecil Smith, CIO of Duke, agrees that users were more likely to accept the new technology from their local IT people-those with whom they work shoulder to shoulder every day-than they would have been if the rollout had been managed centrally by corporate IM. "Someone like [Hulkowich], who they see day in and day out is obviously one of them, one of their family," Smith says. "That's why we encourage this partnership with local IT. The remote and the central organisations can work hand in glove."Give It TimeUnion Gas Ltd. always had planned to involve the IT operations people when it changed its system architecture. The company's executives just hadn't realised that the operations staff would need more time than they were allotted to adjust to the new system. Union Gas was moving from a mainframe-based system to an Intel distributed environment with IBM's AIX servers for the back end, Microsoft Corp.'s Windows NT servers for the front end and 3,000 clients running Windows 95 or Windows NT. About halfway through that multimillion-dollar conversion, IT execs at the Chatham, Ontario-based utility began to reconfigure operations functions such as backup, disaster recovery and software distribution. At that point, the mainframe operations people were brought in to learn how their job responsibilities would be affected by the changes.
But the operations staff in this case were old-school mainframers who had no training on distributed systems, and they were frankly uneasy about the proposed changes. "They were sceptical of the distributed environment from the beginning. They didn't really believe in the technology," says Gord Lamb, then manager of systems management at Union Gas, who was in charge of developing and implementing the processes, procedures and tools to support the new infrastructure. "Their attitude was, 'This isn't going to work, and we're not going to help it work.' It was like pulling teeth to get them involved. The operators were doing exactly what they were told and nothing else."To address that problem, his boss, Manager of Infrastructure Steve Calhoun, suggested altering the organisational chain of command so that the operators would report directly to Lamb. Under the previous reporting structure, it had been "too difficult to get their buy-in," he says.
With the authority to direct the operations people, Lamb focused on making them less resistant to the new systems and provided them with training. He believed a fellow operator would be a more credible teacher than an outsider, and he "appointed one lead operator, one who had an open mind. We took him and did the train-the-trainer approach," he says.
In the three months it took for the operators to get used to the new system, they became its enthusiastic advocates. They knew they were uniquely positioned to uncover system weaknesses, and they actively offered fresh suggestions and insights. Noting what Lamb describes as "the logistical nightmare of rotating tapes," one operations person suggested replacing the daily offsite tape backups with one weekly offsite backup. "It brought common sense to the process," Lamb says. The revised protocol was not without some trade-offs, however. "We did increase the risk of problems if we had a disaster, but on balance we felt the logistics of doing it once a week were better," he says.
Simply put, Digital Equipment Corp. would never have made it through its 1996 IT hardware and software infrastructure change without the intense interaction and involvement of operations staff, both at home and in the field.
Tom Simmons, vice president of connectivity and computing services [Editor's note: Unless otherwise noted, all Digital employees have become Compaq Computer Corp. employees as a result of Compaq's acquisition and reorganisation of Digital. Employee responsibilities are generally the same.], and his team had 18 months to move more than 55,000 clients using All-In-1 or VMSmail e-mail in a proprietary OpenVMS DECnet environment to a Digital Alpha-Microsoft Windows NT environment running Microsoft Exchange mail. Digital Intel-based servers running Windows NT are also part of the new environment.
That immense labor required replacing systems at Digital locations in 40 countries. Time constraints alone made it unworkable to direct the companywide systems change from world headquarters. So gathering representatives from Digital's worldwide IT operations staff, the company formed a central team to oversee the deployment.
"The pace of change today requires you to have the IT operations people involved in the front end and have them assist in walking the other parts of the organisation through the changes," says Dick Fishburn, former vice president and CIO at Digital. "The local operations teams have to take an active role. They are the change leaders."Al Laude, mail/messaging service operations manager, explains, "We were looking at the big picture-all the pieces that go into the new infrastructure." He was one of three Digital managers who headed up groups that provided an interface between the central deployment team and the IS operations staffs at Digital outposts around the world. "We wanted to make sure we wouldn't fall into the trap of just throwing things over the wall."According to Simmons, "We wanted to deliver a highly stable and predictable environment from the start and then provide passionate and knowledgeable support.... By involving [operations people] at the beginning and making them accountable for the delivery of each of those processes, it improved our ability to be successful," says Simmons. In short, he maintains that failure to involve operations would be "like a coach wanting to win but not involving the players in the game plan."And Digital's operations staff proved to be most valuable players. For example, operations personnel devised a way to reduce the time it took to install and start up system software on desktop PCs-by 80 percent. The automated "gold disk" process, which refers to a CD with the software upgrade, replaced the conventional approach, which would have taken about five hours for each PC.
In Digital's far-flung offices, local IT operations people alerted the central deployment team to local differences that could have resulted in legal and other problems. For example, in Europe, the plan for assigning a unique identifier to each Digital network user might have run into serious roadblocks.
Both Germany and France have strict privacy rules that forbid the disclosure of identifying numbers or userpasswords outside the country. With advance warning from the German and French operations staff, Digital kept the issue manageable. "Operations has that on-the-ground perspective," Simmons says.
Keeping Digital's operations staff up-to-date did, however, exact its toll. The leaders of separate projects around the world insisted on communicating regularly with the company's 100-plus IT operations professionals and other team members involved in the overall rollout effort. Individual program groups organised their own calls to focus on their particular projects. For example, Joel Johnson, the program manager for the Windows NT rollout and later Digital's connectivity and computing services technology manager, scheduled one regular weekly call, Thursdays from 9 a.m. to noon, Eastern Standard Time. His people in Asia-Pacific exhibited true devotion to successful implementation: On Thursdays they capped off their normally crazed day with those three-hour conference calls, which for them started at 10 p.m.
Everyone's dedication paid off: 40,000 Digital users were on the new system by April 1997, two months ahead of the June 1997 deadline, and that number reached 55,000 by the deadline. "We haven't had the party yet, but everybody slept for a full night," says Laude.
(Lauren Gibbons Paul, a freelance writer in Belmont, Massachusetts, can be reached at firstname.lastname@example.org.)
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.