Re: What is analysis?

From: paul c <>
Date: Wed, 05 Dec 2007 21:04:11 GMT
Message-ID: <fnE5j.166$iU.50_at_pd7urf2no>

David Cressey wrote:
> The problem with comparing a methodology with cooking Boullabaise is that
> once you have successfully coooked a Boullabaise, your goal is to get the
> same result over and over again.
> ...

I don't mean to overcook and no, I'm not stewing about this. I worked for one product development boss who was enforcing rapid prototyping in very small chunks almost twenty years ago, even though the result was about a million lines of code. He dictated the components and enforced strict interfaces between them as well as the staging and timing of features to various integration levels. That was his design talent but he had other skills, like doing much of that remotely, out of the office most of the time handling a bigger secret which was his absolute domination of political and marketing forces in an organization that liked to say that its (big-ticket) customers were always right. This allowed him to cut features that didn't make his grade before each release, without explanation to anybody. He knew that customers knew what they wanted, but that most didn't know what they needed. People in charge of components quickly learned that if you violated a soft interface, you'd get a lecture. If you did it a second time without a damn good reason, you were gone. Nobody had nine lives there.

He was a bit of a dictator, but mostly I liked working for him. He depended a lot on an early company email system, but was scrupulous about not cc'ing the world. At first I balked about this, complaining that I didn't need to read the stuff since people would 'phone me anyway, eg: "Did you get my email?" - "no, what does it say?" - "well, it says ...". I used up one of my imaginary nine lives before I agreed to see it his way. He used what worked, nothing but, and always had a strong reason for trying anything new, unlike other VP's who would throw money at anything that looked like it could allow them to avoid thought.

"Small" varies in meaning according to person, budget, blah, blah. When AT&T had an IT budget of half-a-billion dollars, it was notorious for scraping ten-million dollar projects. Forget the other skills, no matter the official job function, I think the rarest talent I've seen in outfits with less money to waste is the ability to discard any work at all the organization has spent time and money on. Seems that half the time the result of a failed project is a new department with the old sponsor, who didn't have that talent, at its head. It depends more on the ability of an individual than his responsibility in the hierarchy. Most people I've worked with always copped-out as soon as anybody else leaned on them.

It only worked for ten years, after that the other VP's overwhelmed him so much by hiring whole departments of attack dogs that he had to duplicate all their organization positions in his own. I thought ten years was a pretty good demonstration. I concluded that having only a methodology doesn't get one very far when it comes to the big picture. Received on Wed Dec 05 2007 - 22:04:11 CET

Original text of this message