You are here

Take Charge

To succeed at change management, these feds say take the lead and guide rather than ride the IT-change beast.

The National Centers for Environmental Prediction is where America’s climate and weather services begin for the National Weather Service. It’s where the weather service collects and analyzes global meteorological data so that environmental scientists can then generate predictive guidance — information that can save lives.

“We can’t break anything,” says Ben Kyger, director of NCEP Central Operations, referring to an IT infrastructure at the weather service facility in Camp Springs, Md. NCEP is the technology heart of NWS, feeding data to servers worldwide at organizations such as the Storm Prediction Center and Aviation Weather Center, to name just a few. It refreshes its supercomputers about every two years with technology that’s often three times faster.

NWS has an unlimited appetite for computer and networking horsepower, and the continual refresh of technology results in an evolutionary upgrade of the IT infrastructure throughout NCEP. So it should come as little surprise that change management is something that NCEP practices regularly — continuously, in fact, according to Kyger.

Change in the organization’s IT infrastructure runs the gamut, from the mundane (upgrading a power supply in the data center or revising a rule on a single firewall) to the sublime (recoding a model on a supercomputer). Either way, the underlying change management involves identifying technology needs, prioritizing requests and risks, making the decision to change and communicating that decision proactively.

When it comes to implementing technology, points out Walter Besecker, a former senior executive at the Veterans Affairs Department, it’s easy to get wrapped up in hardware, software and big ideas. “Choosing the right software, the right configuration, the right technology only accounts for 20 to 30 percent of the job,” says Besecker, who now is a leadership coach with the Council for Excellence in Government in Washington, D.C. “Success or failure ultimately depends on people and processes.”

What’s required is a way for IT to harness technology change and drive it, say Kyger, Besecker and others who work in federal IT programs. IT managers who spoke with FedTech highlight four best practices that help them stay ahead of change rather than chasing it: constant communication, thorough testing and evaluation, detailed documentation and embedded user controls.

Begin, Follow Up and End With Communication

NCEP toes the line when it comes to best practices for change management, Kyger says. He recommends that IT teams avoid the distractions of fancy tools until they master the basic processes of managing technology change. For him, the most basic is communication.

“Many people think it’s about the tools, and they spend years trying to implement a tool and put all their energy into troubleshooting rather than discipline and communication,” Kyger says.

To discuss technology needs, NCEP Central Operations conducts a weekly conference call that includes about 30 people representing forecasting organizations across NWS. Meeting participants also discuss any tech challenges they are encountering, Kyger says.

In addition, the agency also reviews technology projects quarterly so it can link IT with the business side of the house to ensure that every change — down to the slightest modification in a line of software code — has some scientific benefit, he says. NCEP also does post-mortem reviews to check that technology changes had the anticipated results.

EXTRA TIP #1:

Build some flexibility into the process. Change management should keep projects moving but not be so rigid that it stifles innovation. For example, extend a deadline if adoption of a software feature really sought by users will mean a program misses its deadline by a day or two.
— NCEP’s Ben Kyger

Throughout, Kyger recommends, IT must keep pushing out information about what technology upgrades are coming, when they will occur, why they are needed and what effect they will have on users. “That’s something a lot of organizations talk about but few do,” he says. Never wait until after an implementation has begun to start getting the word out, he adds, because by then it’s too late.

Test, Test and Test Again

Without some formal validation process, there’s no way to introduce technology changes into the production landscape in a safe and controlled manner, says Spencer Bessette, program manager for IT line of business initiatives at the Interior Department’s National Business Center in Denver.

NBC maintains a robust automated regression and performance testing infrastructure that it relies on to test not only new releases of applications but also new technologies. “This capability allowed the NBC to thoroughly test multiple platforms for re-hosting its Oracle databases and easily determine the optimum platform,” he says of the center’s recent efficiency-improvement project.

Based on that testing, the center’s managers had little trepidation about going through with needed procurements, Bessette says. “Formal change management is a cornerstone of our infrastructure and has enabled the NBC to manage IT-related change for the last 30 years.”

Include Details in the Fine Print

If you’ve informed everyone about a change and you’ve tested the technology, then it’s time to spell out what’s expected, says Bessette. Service-level agreements are integral to change management, he says, whether they are used by the IT shop to define arrangements with a vendor or with its own customers within government. And they need to be dense, he says, including details on the specifics — everything from acceptable maintenance windows to the frequency of patch applications.

SLAs get plenty of talk, he notes, but other documents also help keep technology projects moving forward. At NBC, Bessette’s team relies on Standard Operating Procedure (SOP) guides to help its federal customers further understand how IT manages change. The SOPs explain the procedures for particular projects and offer insights on areas such as backup, monitoring, auditing and retention, patch management, and configuration management.

Provide Help Tools in the Technology

Think about how to help the last person touched by a technology change, suggests Michael W. Carleton, CIO at the Health and Human Services Department, which typically has 70 IT projects going on at any one time.

EXTRA TIP #2:

Consider ways to use business intelligence applications or dashboards to help visualize measurement data and help model the impact and outcome of IT actions.
— Council for Excellence in Government’s Walter Besecker

At HHS, where a financial management system implementation has been under way for a few years, an important practice is building controls into the new software that ultimately help users learn the latest methods for entering information into the financial system. Setting such controls inside applications can make the end users more productive, improve data integrity and also help avoid system disruptions, Carleton says.

This particular practice has come to the forefront at HHS because the department uses off-the-shelf software as often as possible. “Just because technology is proven doesn’t mean it’s familiar,” says Carleton. Change controls help users adopt new technology while minimizing downtime, he says.

The Payoff

The benefit of following change-management best practices, says NCEP’s Kyger, is that in spite of the constant turmoil of replacing technology (that’s close to bleeding-edge at his organization), IT can deliver 99.9 percent of what its customers are looking for.

Plus, these practices can help IT avoid wasting money, adds the Internal Revenue Service’s Rob Bedoya.

“Change management allows us to focus on de­livering the most return on investment to the organization,” says Bedoya, director of the Customer Account Data Engine for the Business Modernization Office within the IRS Wage and Investment Division.

Smart project leaders will bring together IT, users and team trainers from project concept through design and delivery, says Besecker. “If major stakeholders aren’t involved and IT developments are spearheaded or are done in isolation, users will see it as a problem and a challenge.”

 

Dec 31 2009

Comments