IT managers can learn a valuable lesson from the open-standards process. Years ago, when information technologies were new and mysterious, technology managers operated largely in isolation. If systems needed replacing or upgrading, a few key internal people developed a plan and made it happen. If in-house expertise didn't exist, you brought in a vendor to tackle the job. But today, the dynamics are different: Everyone's a computer expert, more than willing to second-guess you when new systems don't deliver on their promises. These "experts" exist not only in other divisions of the IT organization -- think application developers who believe they know a thing or two about networks -- but outside the IT organization at the business-unit level -- think power users and departmental IT support staff. If new systems are poorly designed and implemented, without adequate consideration given to budgetary realities and user needs and input, IT management deserves all the criticism it gets.
Everyone's Invited
The obvious solution is to involve stakeholders in the system-design process early. That may sound simple, but if you've ever tried to do it, you more than likely have been frustrated. Generally, the stakeholders either express no opinions whatsoever or express opinions so bizarre that you aren't really sure you're living on the same planet. The secret to garnering meaningful input is to maintain control of the agenda and present logical alternatives for discussion.
I'll offer a specific example that I experienced several years ago while managing the Syracuse University network. It was 1996, and we needed to upgrade our backbone, a routed Ethernet network that was limping along under increasing load. Some of you may recall this as an era when many large organizations were adopting ATM at the core. We weren't very enthusiastic about ATM, preferring to follow the evolution of Ethernet to 100 Mbps and gigabit. However, a number of people within our organization felt, by virtue of their knowledge of what other universities were doing, that ATM was the only logical choice. Yes, we could have ignored their input, but to do so would have reinforced the conception that the central IT organization was out of touch with its user community.
Rather than taking a defensive posture, we went on the offensive, developing a preliminary plan we called an internal request for comments, or IRFC. In that document, we did our best to analyze current and future needs objectively; provide information related to significant technologies; assess major alternatives along key criteria such as performance, cost, reliability and supportability; and propose what we considered the most rational solution. We made a special effort to ensure that the document was less than 20 pages, and we included an abbreviated summary for those who wouldn't have time to digest all the details. We circulated the IRFC throughout the organization and provided appropriate mechanisms for feedback.
RSS
