August 24, 2004, 12:00 AM — Let us break the crust of this weeks wholesome article with an anecdote.
On a table, there sits a glass tumbler, half of which is filled with
water, the other half is empty air.
An optimist stops by and remarks "that glass is half full!".
A pessimist stops by and remarks "that glass is half empty!".
An engineer stops by and remarks "that glass is twice the size
it should be!"
I would like to add another entry into this list:
An IT professional, specializing in e-business applications
stops by and remarks:
"We need to look at the workflow that lead to the
creation of that glass as the process is clearly broken.
With a little bit of work we could arrange a
more optimal filling process. In fact, we should also do a
historical analysis of previous glasses. We may be able to
create a positive feedback loop in the software so that the
glass filling gets progressively better! It might be worth
looking at how the water is poured as well. There may be scope
for increasing the yield by optimizing the algorithm. While we
are looking at that, we should take a look at the new Faucet
Query Expression language which is in last call at standards
organization XYZ. It may allow us to create cleaner
applications for monitoring the water flow. It shouldn't
be too much work."
Does any of that ring a bell? What about that last phrase? "It shouldn't
be too much work." How many times do you hear that in a week? How many
times does it turn out to be true? Not very many? Same here.
It is notoriously, fantastically difficult to gauge how long IT projects
will take. Some of that difficulty is endemic to the problem space.
Building IT products - hardware and software - is not, and never will
be, amenable to the sort of linear progression required for tight
timescale management. There is nothing much we can do about that.
Having said that, there are some contributing factors that we can do
something about. The one I would like to tackle is the problem of
hyper-optimism - a dysfunction that many IT fold (myself included)
suffer from.
IT people by and large like their jobs. You have to in order to stay
sane in this crazy business. IT people like to solve problems. Therein
lies both a blessing and a curse for IT project management. On the plus
side, you need people who like to solve problems because every IT
project serves them up by the boatload. On the downside, IT people are
terrible at estimating how long it will take to solve any particular
problem.
This lack of an ability to accurately estimate how long it will take to
solve a problem is not a failing per-se. Programmers do not willfully
underestimate task times unless they feel that they need to make up
something to keep the project manager happy. It is simply that the fun
of problem solving leads to what I call "breakthrough syndrome".
The syndrome affects all walks of IT professional life but is most acute
in software developers. Here is what happens. The developer "wraps their
head" around a problem. This can take anything from minutes to days.
From that moment of immersion onwards, ideas for solving the problem
come thick and fast. From that moment on, the developer gets a sense
that a triumphant breakthrough is not far away. They loose all track of
time. They bark at anybody who interrupts them. Empty caffeine
receptacles and pizza boxes start to pile up under the desk. They take
natural breaks only when their systems are at bursting point.
Does any of that sound familiar? Now what you have there is a valuable
employee, doing a difficult job to the best of their ability. Often way
beyond the call of duty. However, what you also have there is a project
management nightmare. That person is likely to feel - really and
truthfully - that a breakthrough is just around the corner.
It may be, but it probably isn't.
Factor that into your project plan.
