Lesson LearnedBy David Strom | Posted 2010-06-28 Email Print
WEBINAR: Available On-Demand
Innovate and Thrive: How to Compete in the API Economy REGISTER >
Managing technology changes effectively can make the difference between satisfying users and dealing with chronic downtime.
David Goodman learned the hard way about how and when to involve his IT department in changes made at The International Rescue Committee, a relief organization based in New York City that runs dozens of offices around the globe.
“We had a recruiting package that was bought by another company, and our migration was handled by our HR department,” says CTO Goodman. “The upgrade didn’t go particularly well. The people running the project weren’t IT people, and they didn’t think things through. In the end, it was clear to them that you have to involve the systems people in systems upgrades.”
This doesn’t mean that IT needs to be involved in every project, he explains, but someone needs to ensure that the foundations of requirement-gathering and systems analysis are in place.
“When I was hired, we didn’t have much of an IT department, and many of our staff members didn’t understand the value IT could provide,” he says. “I purposely don’t come into meetings and try to take over a project. I take a more measured approach and have people come to us when they need something.”
Goodman believes getting a business degree and being more sensitive to the business processes helped him sell his services internally. “Our public-facing Website was languishing from a tech standpoint,” he recalls, “so my team and I helped to staff up the Web team and get it to a point where it didn’t need my attention anymore. It’s important to know when to step out of a project and let the end-user department take over.”
Sometimes, all it takes to make change more manageable is the right kind of documentation, something that Connie Dillard, the longtime IT manager for the city of San Carlos, Calif., knows all too well. In preparation for her retirement from the city this spring, she began an overhaul of their systems and network documentation last year.
“I wanted to make sure that there was an orderly transition when I retired, and it was also time to do a better job at keeping track of our procedures,” Dillard says.
Dillard began using Microsoft’s One Note software to compile electronic “notebooks” full of information, such as user-access lists, project purchase orders, and software- and network-configuration information. “It makes it easier to share this information with the other members of my IT staff, so they can easily and quickly find something when I’m not around. If you don’t document it, you have to relearn how to do some procedure—or call the vendor to walk you through it.”
Dillard uses Screensteps screen-capturing software from Blue Mango Learning Systems to document the process to set up a new server or user account. So everyone on her staff can replay these steps in the future. “This way, it is at our fingertips,” she says. “Since we are still using some software that is more than 10 years old, it’s critical to preserve this knowledge.”
Virtualization has made the city’s documentation requirements a lot more critical, Dillard adds, but not necessarily complex. She created an Excel spreadsheet that keeps track of when individual virtual machines on her host server are restarted, as well as when they need to be patched or updated.
“Not all of us are here all the time, and we needed some way to quickly share what we were doing,” she explains. “This works just fine for our purposes.”
Consolidating the physical servers, along with some other technologies, has made Dillard’s documentation duties a lot easier in some ways. “We used to have paper logs for each of our 31 servers,” she recalls. “That—and having backup tapes and doing the catalogs for them—was very painful. Now we use direct-to-disk backups, and with virtualized servers and automatic logging tools on some of our other software products, we save a lot of time.”
The key thing, Dillard stressed, is to review these activity logs each morning to make sure that any problems are resolved and that what was supposed to happen the night before actually transpired.
Sometimes, the hardest part about changing your applications is keeping your legacy data in a form that you can access once you perform your upgrades. Some upgrades can make this data inaccessible—either because data storage formats become obsolete (remember the eight-inch floppy disk?) or because the newer applications can no longer manipulate the older versions’ data.
That’s what the IT staff members at the Emory University library faced when they received several Apple Macs that author Salmon Rushdie used to write his novels. Software Engineer Peter Hornsby and Senior Engineer Ben Ranker had to develop ways to extract and preserve the machines’ data so that scholars could view Rushdie’s documents.
“That was the first time we had such a valuable collection of computers in our special-collections department,” Hornsby says. “We needed to preserve the context as well as the formatting of the documents.”
As the examples in this article illustrate, the path toward upgrades needs to be managed carefully and with appropriate policies and plans in place. So make sure you analyze at the start the impact your decisions will have on your enterprise and then carefully document all the changes you are making.