Free Article By Paul Glen of C2
Consulting
Every month we add to this collection of articles from the free monthly
newsletter IT Professionalism.
You are also free to print these articles in your newsletter or magazine if
you follow our Reprint Policy.
To subscribe to it, click here.
Are You Fixing Problems or Fixing Them in Stone?
(This article originally appeared in
Computerworld USA and on the websites of CIO Australia, CIO Germany, PC Welt
Germany, and Mac Welt Germany)
Tech people are steeped in the ways of problems. It's one of
the fundamental organizing principles behind nearly everything we do. We find
problems, define them, analyze them and solve them.
So it's not surprising that when we move into managerial
roles, we view ourselves as management problem-solvers. We fix people problems.
And that's often where the problems begin.
Managerial issues usually first manifest as some sort of
crisis: A project deadline is missed, a budget is blown, a client or user is
unsatisfied, or a business process is broken. And, as good problem-solvers, we
start looking for solutions.
Often, these solutions involve some sort of process or
policy. For example, if the breakdown was caused by a client's failure to share
information in a timely manner, we require the customer to submit requests in
writing two weeks before they need a service or product. If a client doesn't
like the way a system works, next time we ask him to physically sign off on the
requirements before any work begins on implementation. If IT staffers have
delivered unintelligible memos to clients, we require that the authors submit
them for editing before distribution.
These may seem like reasonable solutions, but in these
examples, are the problems actually solved? I think that these approaches merely
treat the symptoms rather than resolve the real issues at hand.
If customers aren't submitting requests in a timely manner,
there could be several underlying causes. They may hold IT staffers in low
esteem and either be deliberately trying to annoy them or, more likely, consider
IT's time to be less valuable than their own and see no reason to give more lead
time. The customer group may not understand the priorities or workload of the IT
group, either. Or they may not know their own needs long enough in advance to
make timely requests. But forcing a rigid timeline for formalized communication
doesn't ameliorate poor relationships between the two teams or improve planning.
It just annoys people and feels bureaucratic.
If a client doesn't like the way a system works at delivery,
he probably never really understood his own needs completely in the first place.
Forcing him to sign off on requirements probably won't help him to better
understand what he's trying to accomplish with the next system or envision how
the business process will flow. Often, requirements don't become entirely clear
until users have a chance to play with a real system or at least a prototype or
mock-up.
And if your IT staffers are delivering documents in poor
condition, either they are poor writers or they don't feel that it's worth their
effort to write well. While external editing can help (I know my editors at
Computerworld are a great help), poor writing is usually the result of unclear
thinking rather than an inability to string words together. Editors can't think
for writers, but they can encourage them to think for themselves.
These typical types of solutions not only treat symptoms while
ignoring the real issues, they actually reinforce the problems, making them more
enduring and intractable than before. Policies mandating how and when to
communicate usually result in formalized and narrow communications between
groups rather than relationships based on mutual understanding and trust.
Formalized requirements can't guarantee business value. And heavy-handed editing
usually causes writers to stop proofreading their own material. Why bother if
someone is going to do it for you?
When addressing managerial problems, always ask yourself, "Am
I fixing the problem (as in resolving it), or am I fixing the problem (as in
engraving it in stone)?"
© Copyright 2008 by Computerworld Inc., One Speen Street, Framingham, MA, 01701. Reprinted by permission of
Computerworld. All Rights Reserved.
