|
Bill, Thank you for following my posts at all...! Let alone closely. I saw Al answered the question pretty much like I would have. I added a few thoughts, to his post, and hope you caught those. I think what I was referring to as the 50/50 rule makes little sense, outside of the context of where I worked. Some might think the following is excessively verbose. <chit-chat> I was drug into a supervisor role, when I was promoted to the position of Asst DP Manager. I was drug into management when I became DP Manager about 6 months later. Few companies would take that kind of risk. I posted once that this was a "fluke o' nature" but I think it was a cost-cutting move. Nobody ever even *hinted* this to me. But both the DPM and his Asst. were transferred to the $B parent company that was half-owner of this business. After I became DPM, our Business Analyst, who was also our entire PC expertise, was transferred, too. I'd always assumed he made more money than I did, even after my promotion. He was always on the "Executive PR" so I never knew what he made, even though he worked for me. </chit-chat> I think any IT department both is shaped by, and shapes, the corporate culture of the business. So I think the stuff that follows reflects the organization of the company I worked for: The President and half-owner was in charge of the Merchandising Dept. I consider my boss, the VP-Finance, to be "acting-CEO" because all other depts. reported to him. The company was in the $25M - 50M range when he started. This is a reference I allude to in what follows. So the org chart of my dept in this company was: the CEO, me, and my Analyst/Programmers. This worked well in this company (if I do say so, myself). The company sustained it's (grammar?) first and only layoffs (25% of the office). It recovered and grew to $200M while I was there. As my Wife and I were consulting back to the company for 6 years, the company grew to $600M, IIRC, based on the systems we developed using the departmental structure. While we consulted back, these systems were just barely maintained by 1 person, and not enhanced at all. Maybe I'm just bragging, but I think this signifies. I think it shows the inherent value of a flat management structure. It's not so just a matter of reducing management layers. It's a methodology that allows systems to be designed which very closely model the business. I was using the term "50/50 rule" as a send-off of the 80/20 rule, tongue-in-cheek. But, as it turns out, this actually is an accurate designation of something I learned long ago. ===> Any computer system is 50% code and 50% the people that use the system. Matching a system with the needs of the business is easier when there are fewer layers between the users and the coders, IMV. The acting CEO had essentially no involvement in the IT department after the first 3 months I was the head. So it was department heads and users --> me --> my analyst/programmers. We used both rapid prototyping and Extreme Programming methodologies. I started using what is now called Extreme Programming in 1988. We used whiteboards to lay out projects, but never actually spent much time "specing" a system out. We delivered iterations of code, to keep the spec fluid. Most projects were done in days or weeks. If a project drug on for a month or more, a "hot item" almost invariably would come up and the "long" project would get bumped from the active projects list. We had a couple projects that went a month or more, when I first started as dept-head. But after the first year, the only project, IIRC, that ran more than a month, and was successfully completed was implementation of a new cash-register system and simultaneous implementation of PLU. Hope this reply was worthy, Bill. jt > -----Original Message----- > From: midrange-l-admin@midrange.com > [mailto:midrange-l-admin@midrange.com]On Behalf Of > bill.reger@convergys.com > Sent: Friday, November 16, 2001 10:00 AM > To: midrange-l@midrange.com > Subject: RE: Oh where has my disk space gone? > Importance: High > > > > JT, > > I follow your postings closely since (in a previous position) I worked for > many years (22+) in the retail sector as do you. Usually I can relate to > most of your musings on working in retail, but this last one has me > scratching my head: > > "In Retail, it's more like the 50/50 rule, because everything seems to be > done half-a'd. It's an experimental approach, as opposed to Manufacturing > companies where the tendency (probably due to corporate culture) > is to spec > out IT projects to a lot more detail" > > I'd say my experience is that the 50/50 rule relates to the half of the > applications that are changing at any one time (retail business is ALWAYS > changing). But we ALWAYS spec'd things out to a great detail although we > generally tried to anticipate as much change as possible and design in a > lot of flexibility. > > Bill > > -- > > NOTICE: The information contained in this electronic mail transmission is > intended by Convergys Corporation for the use of the named individual or > entity to which it is directed and may contain information that is > privileged or otherwise confidential. If you have received this > electronic > mail transmission in error, please delete it from your system without > copying or forwarding it, and notify the sender of the error by > reply email > or by telephone (collect), so that the sender's address records can be > corrected. > > > _______________________________________________ > This is the Midrange Systems Technical Discussion (MIDRANGE-L) > mailing list > To post a message email: MIDRANGE-L@midrange.com > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l > or email: MIDRANGE-L-request@midrange.com > Before posting, please take a moment to review the archives > at http://archive.midrange.com/midrange-l. >
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.