|
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
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.