> > i accept my share of the responsibility for not staying on top
> > of what Anitha was doing, but in extenuation, there are half a
> > dozen other projects which i'm supposed to be mentoring, not to
> > mention the code of my own -- which the elves and faeries have
> > so far steadfastly refused to write overnight. i let Anitha
> > choose her own direction as a way of letting her get familiar
> > with the existing code, and the product requirements.
>
> Management Error: direct-line supervisor over-tasked.
yes.. i've drilled that point home a few hundred thousand times by
now. the month that i spent saying "who do you want me to take off
of what project" any time there was a complaint about not getting
things done seems to have gotten the basic message across.
the key problem is that my superiors don't know how to plan for
development. they get an idea for something that would be desirable,
but don't sit down to plan how it will be done. and i think even
that's a symptom of a more fundamental communications problem.
one of the things which has continually baffled me is the way these
guys think about priorities. the first thing i did upon learning
that the division was under a heavy workload was to ask for a
prioritized list of things we were supposed to do.
what i got back was a list of some fifteen items.. numbered one through
three.
to this day, i haven't been able to communicate the difference between
priorities and categories. they're willing to do the easy work of
carving the incoming demands into hot/warm/cold partitions, or
whatever the labels are for the day. they just aren't willing to do
the hard work of choosing the single task which bumps all the others.
i think that stems from their unwillingness.. to the point of
inability.. to say 'no' except in open warfare. having priorities
automatically implies a lot of 'no'-saying, much of which ends up
being fairly arbitrary. if item 1 sort of needs one thing, but item
5 really needs something else, it's awfully tempting to bump item 5 up
a little. if you do that regularly, though, your priority list goes
straight to hell, you get whipsawed from pillar to post, and
ultimately your schedule is set by whoever's yelling loudest today.
the same thing happens, in smaller form, in planning meetings. if
all the players aren't willing to make decisions -- and then stick to
them -- you can't create a realistic development plan. even a single
'please everybody' junkie can kill a plan unless the rest of the team
can shut them up.. or more likely, shout them down. what you end up
with is a document that doesn't commit anyone to anything that can't be
renegotiated later with sufficient whining.
the difficulties there cascade to the development process itself. in
the absence of either a clear development plan or the communication
needed to create one, all the planners can do is promise vaporware,
and wait to see who'll get impatient and start whining first. that
turns into an obsession with 'quick wins' that keep the crowd
marginally satisfied for the time being.
by that time, even if the actual development hasn't begun, the project
is as good as dead. the odds are vanishingly small that a project
without adequate planning will be able to hit a series of small
victories that lead anywhere but straight into the tar pits. in
fact, the whole idea is contrary to the model of how a well-run
project should go.
in a project of any size, there's a lot of 'invisible' work that has
to be done before you can start showing tangible results. you have
to close off a lot of false leads, and make sure you've done adequate
preparation for the time when things will be moving fast & hot. from
a clueless spectator's point of view, that looks a lot like spending
time and money, and having nothing to show for it. you can't have
the progress later without building the infrastructure now, just like
you can't become a concert pianist without spending a lot of years
running scales. and that's precisely where the 'please everybody'
environment will fall apart.
> Safe Option: blame contractor when task fails. (Do not use too
> often.)
unacceptable, for the reasons above. if the project fails, it's the
manager's fault. if the contractor was doing such a heinous job that
it put the project at risk, somebody should have spotted it before
they killed the project. if there was no way to spot it, the
development plan sucked rocks.
mike stone <[EMAIL PROTECTED]> 'net geek..
been there, done that, have network, will travel.
____________________________________________________________________
--------------------------------------------------------------------
Join The Web Consultants Association : Register on our web site Now
Web Consultants Web Site : http://just4u.com/webconsultants
If you lose the instructions All subscription/unsubscribing can be done
directly from our website for all our lists.
---------------------------------------------------------------------
