Upcoming Events

Cloud Connect
Santa Clara
Feb 13-16, 2012

Cloud Connect brings together the entire cloud eco-system to better understand the transformation we're experiencing and promises to be the defining event of the cloud computing industry. Learn about the latest cloud technologies and platforms from thought leaders in Cloud Connect’s comprehensive conference.

Register Now!

F E A T U R E

Too Many Cooks in the IT Kitchen?

March 4, 2002
By Dave Molta


	Print Full Article Print This Page Download the PDF E-Mail This URL

Question: What's a giraffe? Answer: A horse designed by a committee. Our point? Most of you have a keen appreciation for the value of open standards. But if you've witnessed the standards-development process, particularly in venues like the IETF, you've probably found yourself closing your eyes or looking away now and then. When you involve a large number of people in standards development, it can be difficult to reach a consensus. But the end result, though often far from perfect, is usually broadly accepted.


		Everything You Always Wanted to Know About the Business of IT (but were afraid to ask) Start with Staffing Politics as Usual Managing Change School of Project-Management Wizardry Interview: Full Bore into Business Too Many Cooks in the IT Kitchen? Budget Management 101 Guest column: To Lead or Not to Lead ... That is the Question More Articles Hear Jonathan Feldman's tips and techniques on successfully conducting the Business of IT (requires RealPlayer)

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.