h2g2 The Hitchhiker's Guide to the Galaxy: Earth Edition

"Everyone now views business problems as the result of an old, outdated paradigm, and the solution as a new paradigm which will better allow understanding of the marketplace. Thus, what was once obscure linguistic jargon is now obtuse business jargon due to a long a convoluted route through history and science."

Amen. I've been out of the rat race for a while, but my company of several thousand people went through all this when I was there. The new paradigm (sold to us by expensive consultants) was basically "quality", meaning we should get our product right before we ship it. What a thought! (One of my favorite corporate comics was the sign reading "Good. Cheap. Fast. Pick Two.")

Another one was "empowerment", meaning I was "empowered" to do whatever was needed to do my job. But of course one still had to get a dozen approvals to do anything ... "Dilbert" belongs in the non-fiction section of the bookstore.

Sadly a little bit of analysis of many business paradigm shifts reveal that the change is in the cover of the book, while the contents have been left pretty much the same.
Not too surprisingly, these "dramatic changes" fail to work when taken out of the carefully structured classroom examples and applied to the real world.

then sometimes when a real paradigm shift comes along, the value of it is lost because the label is applied to all sorts of changes, but not the practise. I know from painful experience that this can often be the case when the label "Six Sigma Process Improvement" is stuck on aproject

Places plug for his own article on "six sigma" (which includes a now defunct link to a dilbert cartoon in a reply) here --->http://www.bbc.co.uk/dna/h2g2/brunel/A18107048

" ... common reasons for failure of a Six Sigma project are: poor definition of requirements during Define, failure to identify all of the contributing factors which affect the quality of the output during Analyse ..."

I am not familiar with Six Sigma methodology, but it sounds similar to what my company tried in an effort to improve quality. Basically, we attempted to avoid "rework" (downstream work being redone when upstream mistakes are corrected). Control Data Corp. (CDC), a computer company, was our consultant.

My company provides designs for large refineries and chemical plants, mostly one of a kind. Because of business slowdowns, many senior engineers had left, then during an upturn many young graduates were hired. The "work flow" was basically just defined by the documents passed down the chain, from initial client requirements and process design to construction piping isometric drawings. This worked OK for many decades when the receiving group knew enough (and were allowed) to challenge the incoming documents, but "efficiency" and lack of experience made that unlikely.

Punch line: The quality consultants could not help because we could not tell them how the system should work. At least not in enough detail that it could all be mapped out. They told us we had to figure that out, "Don't automate a mess". So there we were ...

I actually had a good experience as a project engineer in the middle of all this. For a number of complicated reasons, I got a dozen key people who knew what they were doing, damn the "new system". They talked to each other (after some refereeing on my part in a few cases), and the project came off without any big hitch. I think a contributing factor was that it was a relatively small project that did NOT get a lot of pointy haired "management" attention.