![]() A List Of Top 10 Don'ts F or DCNAs By Da ve Molta In my last column, I discussed some of the dynamics that can cause stressful and unproductive relations between central IT staff and departmental computer and network administrators (DCNAs). More specifically, I focused on common mistakes made by IT units in implementing and managing such a distributed computing environment. In this column, I'll turn the tables and look at some dysfunctional actions undertaken by DCNAs that result in diminished overall organizational effectiveness. In case you're not aware of it, I am part of the central IT technocracy at my site, so this column has been a bit easier for me to write. The downside to all of this is that a few people at my site, including those at the departmental level, read these columns. To them, I can only say that I am probably not talking about you! So without further ado, here's my take on the Top 10
things a DCNA can do to dampen relations with central IT staff.
· Rally the troops around the enemy. Many DCNAs, particularly those who are hired from outside the organization, come to their jobs with no preconceived negative feelings toward the central IT organization. However, they quickly discover that many users within their units have negative feelings about the central IT organization. A DCNA will quickly realize that he can enhance his popularity and credibility among his customers and superiors by going at it toe-to-toe with the IT staff. Departmental employees feel good that they finally have someone on their side who can hold his own in an argument with IT staff where every fifth word is an obscure acronym. · Establish your independence from standards tyranny. One of the major functions of a central IT organization seeking to improve the efficiency of the IS environment involves defining technology standards. Standards-based computing is genera lly viewed positively, but it can reduc e the flexibility of departments hoping to optimize their computing environment for their specific needs. DCNAs, therefore, sometimes find themselves in the awkward position of accommodating the particular needs of their internal customers with the most optimal technology solution or adopting one that is good enough to conform to IT standards. The worst scenario is a DCNA who seeks to avoid IT standards as a means of establishing her own independence or advancing her own career interests. · Complain, but don't participate. Do you want to be part of the problem or part of the solution? Most IT organizations face incredible obstacles as they plot their course toward the new millennium. New client/server technologies are infinitely more complex, but budgets aren't usually keeping pace. Even if they are, larger budgets can't always buy the knowledge and experience needed to implement production-quality systems. These dynamics lead to a lot of complaining at the departmental level, and it's easy for DCNAs to get in on the action. But how many of them are really willing to put their time on the line and help solve the problems? In many organizations, not nearly enough. · Prescribe simple solutions to complex problems. In most environments, there are three kinds of problems. One type looks simple to solve and is simple. The second set are problems that look complex and are complex. The third set of problems look simple, but are quite complex. These problems cause the most conflict between central IT and departments. Location-independent e-mail in a client/server environment is a good example. In the days of character-based mainframe terminals, accessing your e-mail over a decent dial-up connection wasn't much different than accessing it via a gateway on a LAN. Then client/server e-mail was introduced, and users couldn't understand why something that used to be simple wasn't quite so simple anymore. Central IT recognized that the long-term solution would be found in mo re sophisticated messaging systems d esigned with location-independence in mind. Some DCNAs refused to accept this, and adopted hacks like remote control that resulted in reliability and security problems. · Be seen but not heard. If there is anything that is more unnerving to a central IT manager than a DCNA who complains too much, it's a DCNA who doesn't complain at all. Perhaps complain is the wrong word. Let's try offer constructive input. A DCNA's most highly valued ability is to translate legitimate user dissatisfaction into recommended changes in technology or procedures. He sees problems every day, and he should have enough technical knowledge to know which ones can be solved and which ones can't. An effective DCNA has credibility with the central IT organization and is willing to use that credibility to raise concerns about problems. By Art Wittmann FreeWire By Bill Frezza Corprate View By Robert Moskowitz Networkologist By Patricia Schnaidt Updated October 8, 1997 |


In case you're not aware of it, I am part of the central IT technocracy at my site, so this column has been a bit easier for me to write. The downside to all of this is that a few people at my site, including those at the departmental level, read these columns. To them, I can only say that I am probably not talking about you! So without further ado, here's my take on the Top 10
things a DCNA can do to dampen relations with central IT staff.












