RE: "One person per product"

Al, Don

Ya...  GREAT story with a multitude of lessons on how NOT to do things.  My
favorite lines:  "Top management was really quite ignorant of the details of
several departments under their authority. IT (me) was really quite ignorant
of what the company needed outside specific requests of me."

That pretty much sums up the place where I was DPM.  (Man...  ROFLMAO...!
Needed my Depends on that one, because it HURT.. being SO true...)


The thing about top management was mainly my fault, though...  (Never did
take on my role as top management, myself, come to think of it...)  I'd
noticed that my boss (the acting-CEO) spent almost all his time
concentrating on areas of the company that went FUBAR.  So I figured I was
doing a good thing to keep my department from being totally FUBAR...  To the
point that he and I had 2 or 3 or maybe a handful of meetings per year (one
being salary reviews).  BTW, we didn't have budgets, per se, until the last
few years I worked there, and Accounting handled that.  These situations are
probably pretty unusual in any company, let alone one in the $100M - $200M
range.  My boss kept it all together, somehow, which is part of the reason I
was in such awe of him.  I learned almost everything that I did, from him,
by observing the other department heads, rather than from my boss, directly.

But I neglected my duty to inform him of some of the details, by flying
under his radar for so long...  He willingly obliged, because a lot of
executives think of the computer area as being a breed completely apart,
within the company, which is only somewhat true.

This also heavily influenced my not knowing what the company needed...  I
worked extremely closely with the other department heads, and most of the
users.. but never really knew what my boss wanted.  And he didn't really
know what he wanted from IT, either.


Now I'll grant that most places are not quite so seat-of-the-pants as this
place.  (I'm thinkin' I could count the number of memos I wrote on my
fingers and maybe a couple toes, in 8 years...  And I was in the
bottom-middle of the pack, amongst the dept. heads...!)  But I really think
the kind of meeting you described, Al, is the rule rather than the
exception.

It comes about because you are attempting to discuss how the company
fundamentally works, at an /extremely/ detailed level.  This is
near-impossible, and is why I am strongly opposed to taking revolutionary
approaches to changing IT processes (let alone platforms).  Most of these
kinds of discussions are going to be extremely confusing.  Takes a long
while for both ends to finally meet somewhere towards the middle.

Again, contrary to Dilbert (which IS a freakin cartoon) it's not so much
that top management can't deal with details, or computer issues.  Al, you
saw how hard it was to deal with ALL the issues of what the company needed,
from your perspective within IT.  It's REAL hard to keep in mind how IT
affects Accounting, Warehouse/Distribution, HR, Marketing, Legal,
Engineering and/or Merchandising/Store Ops.  IT effects a lot of these
policies and procedures (not to mention it's own internal ones).  But the
top management is at a disadvantage because they CAN'T look at it from the
singular perspective of IT.  They have to be MORE familiar in ALL these
areas, than what you are...

This is what I mean by the difficulty of both ends meeting in the middle.


Sounds like you (all) did a REAL good job in a real tough situation...!


I agree with all Don's points, except the one about single point of
ownership.  In most respects, I've found it useful for IT to have primary
responsibility over the computer systems, and secondary responsibility over
the data.  Vice versa for the user community:  they were primarily
responsible for the data, and secondarily responsible for the systems.  The
primary responsibility probably needs little explanation.

The user's secondary responsibility for systems included telling IT what
they needed and training their own people how to use the systems.  IT's
secondary responsibility was for backing up the data, and keeping it
(relatively) clean and accurate.  Of course, that included fixes for user
FUBAR's, on occasion.  Which tended to make up for coder FUBAR's on the
user's data (usually mine ;-).

That's how we ran an IT shop of a $100M - $200M company with, at one time, 2
P/A's and a part-time high-school kid, and myself.  (BTW, I think I mispoke
and posted 1.5 P/A's, previously.)  Our user's presented the typical
frustrations (yada, yada) but they accepted this shared responsibility, for
the most part.  But as I said at the top, I neglected some of my other
duties, in the process...


Anyhoo, that's my .02 worth...;-)


jt

(From Selling eServer Solutions:) "When the going gets weird, the weird turn
pro."  Hunter S. Thompson


| -----Original Message-----
| From: midrange-l-admin@midrange.com
| [mailto:midrange-l-admin@midrange.com]On Behalf Of Schenck, Don
| Sent: Friday, December 07, 2001 12:02 PM
| To: 'midrange-l@midrange.com'
| Subject: RE: "One person per product"
| Importance: High
|
|
| I don't see this stuff as being that difficult:
|
| 1. Define requirements.
| 2. Assign ownership.
| 3. Trust.
|
|
| Use Cases and UML go a LONG WAY toward solving #1.
|
| Your story is great; it illustrates:
|
| No defined requirements.
| No single point of ownership.
| No trust.
|
|
| -- Don