Tag Archives: management

Deming and Rocketdyne

Sometime in late January of 1987, almost one year to the day after the Space Shuttle Orbiter Challenger was destroyed as it ascended to orbit, I was assigned by the temp agency I was using at the time to begin work on the Space Shuttle Main Engine team at Rockwell International’s Rocketdyne Division in Woodland Hills, CA.

Prior to that fateful date I had, with one exception, never worked at a company with more than a dozen employees. My family’s wholesale food business, at its peak, was only my father, brother, me, and one employee and most of the numerous jobs I had held over the previous 20 years or so were similarly small.

Rocketdyne employed several thousand people, most of whom labored at our campuses in Woodland Hills and Canoga Park, CA. It was a division of Rockwell International, which employed over 100,000 people world-wide. It was a jarring transition to go from small (really small) businesses to a multi-national aerospace conglomerate. However, having been somewhat of a space-cadet, i.e. enthusiast most of my life, I was thrilled with the opportunity.

A year later on 1 February 1988, I was hired to work in Engineering Computing on the Flight Ops team – a position I would not have dared to dream of filling. Nevertheless, there I was helping our nation’s space program get back on track. It was truly a dream come true.

At the same time, I was becoming aware of the unique way in which large organizations conduct themselves. Some of it wasn’t pretty. I first encountered the business philosophy of W. Edwards Deming soon after I was officially hired as I was lucky enough to have a colleague who was a student of his. Deming had written a book (he wrote many) in which he laid out a fourteen-point explication of his concept of TQM (Total Quality Management).

I was enamored of his positions, as they coincided with my growing understanding how things worked in virtually any organization. I had long been someone who looked for and found ways in which to improve the processes and procedures of any organization I was involved with, and Deming’s philosophy made a great deal of sense to me.

At the same time, I was becoming increasingly aware of the reality that many companies, including Rocketdyne, were honoring those principles in their breach, not their adherence to them. As I was studying Deming’s 14 points I began to realize just how thoroughly many of the managers I encountered were oblivious to the virtues Deming laid out.

Somewhere around 1990 I decided to see if I could capture the differences between what Deming offered and how Rocketdyne was actually doing things. I captured Deming’s 14 points and then created Rocketdyne’s 14 counterpoints. I’ve kept them over the years and am here sharing my understanding with two screenshots of those differing points of view. Please keep in mind not all managers were as controlling as the worst of them. I was lucky to work under the supervision of several truly wonderful managers in my nearly quarter century of employment there. Regardless, I think my analysis was reasonable, even after over 34 years. You?


Don’t Call Me a Guru, Dammit!

NB: I published this article sometime in 2010, around the time I accepted an early severance package from Pratt & Whitney Rocketdyne and retired. It was published using WordPress’s old classic editor and didn’t render well any longer, so I’ve upgraded it to their current block editor format. This should explain why the date associated with it is May 16, 2023.


This article is a few years old, but there’s so much good stuff in here I’m thinking I should post it every other week for the rest of my life. Seriously, with all the talk lately about how you need to be careful of people who hold themselves out as Social Media Experts, Russ’s words are even more impactful.

This October Russ will have been gone for a year. I’m willing to bet I speak for a lot of people when I say he is sorely missed. He is surely not forgotten. Read the whole article; then get the book f-Laws.

Update (Thanksgiving, 2013) This post was originally published from www.telegraph.co.uk using Amplify, a curation service that no longer exists. Below is the excerpt as Amplify prepared it.

Anti-guru of joined-up management

Published: 12:01AM GMT 08 Feb 2007

My Last Visit With Russ
I was fortunate to spend Russell’s 90th birthday with him in Philly, I took this photo when Bill Bellows and I had dinner with Russell and his wife, Helen

If you were asked to picture what a management guru should look and sound like, you might come up with a description of someone very like Russ Ackoff. Grey-haired, distinguished, softly spoken, Ackoff fits the bill. And also, since he turns 88 on Monday, he can claim the benefit of wisdom earned over the course of six decades studying and working with businesses and organisations.

Except, of course, that “guru” is not a label that Ackoff is keen to accept.

“A guru produces disciples, and a discipline, and a doctrine,” he says. “If you are a follower of a guru, you don’t go beyond his thoughts, you accept his thoughts. He gives you the questions and the answers – it’s an end to thought. An educator is exactly the opposite,” he says. “You take off where he sets you up for the next set of questions. One is open-ended, the other is closed. Most consultants are gurus. They are ‘experts’, not educators.”

So please don’t refer to Ackoff’s body of work as gurudom and please don’t describe his work with clients as management consulting.

“We don’t call it consulting,” he states firmly. “We make a distinction between consulting and being an educator. A consultant goes in with a solution. He tries to impose it on a situation. An educator tries to train the people responsible for the work to work it out for themselves. We don’t pretend to know the way to get the answer.”

In his distaste for gurudom, Ackoff is of a mind with his old friend and colleague, the late Peter Drucker. Drucker famously once observed that the only reason people called him a guru was that they did not know how to spell the word “charlatan”.

“Peter Drucker made a great distinction between doing things right and doing the right thing,” Ackoff says. “All of our social problems arise out of doing the wrong thing righter. The more efficient you are at doing the wrong thing, the wronger you become. It is much better to do the right thing wronger than the wrong thing righter! If you do the right thing wrong and correct it, you get better.”

Read more at www.telegraph.co.uk (I don’t believe you can see the entire article without accepting a “free” monthly subscription, which you will have to cancel if you don’t want to be charged.)


Program Management By Ouija Board

image

Going back to work after nearly five years of “retirement” has been both interesting and instructive. When I was asked if I would be willing to do scheduling, which is something I had done many years ago, I happily said “yes”. I would have probably agreed to almost anything they wanted me to do, as I was anxious to supplement my meager retirement income. Actually, I first learned scheduling software using a mainframe tool called Artemis. Shortly afterward, we were introduced to a PC version of Artemis which, if memory serves, was called Schedule Publisher and, within another very short period, it was spun off into a product from Advanced Management Solutions, called AMS REALTIME Projects.

This was somewhere around 1994 and, at the time, Microsoft Project was comparatively bare bones and nowhere near as useful (in my opinion at the time) as REALTIME Projects. Having long been very much a visual person, I find the visualization provided by Gantt charts to be particularly useful when looking to see how the logic in a schedule affects downstream activities as time, and the work contemplated in the schedule, moves forward. Until Project introduced the Timeline view, which allows quick zooming and panning, I was not terribly happy with it compared to the AMS product, which offered a useful timeline capability.

So . . . since I had done scheduling for a few years during the 90s, I readily accepted the challenge and, upon my return on January 19, 2015, I was amused to see the company was still using Project 2002 which, although newer than the version I had struggled with, was still well over a decade old. The main reason for this, I was told, was because a set of macros had been developed over the years that allowed schedules to be matched up with the organization’s earned value management system, which is Deltek MPM.

Unfortunately, using such an old piece of software presented some interesting problems. One of the most egregious, from my point of view, was its inability to run in any of the conference rooms in my building. This was — and still is — due to an IT rule put in place that won’t run software in conference rooms if it’s more than two versions older than the most current one available. In the case of MS Project, the latest version available when I returned was 2013. Also, MS had released a 2007 and a 2010 version, which put the one in widespread use more than two versions behind and, as a result, clicking on the tool (which was installed in all the conference rooms) invoked Project but, instead of seeing the tabular data alongside a Gantt chart, all one got was an empty box with a small red “x” in the upper lefthand corner.

In my experience, scheduling is an activity that absolutely must be done collaboratively. A good, useful schedule requires (at the very least) a great deal of understanding of not only the work to be done, but the ways in which the logic of its progression needs to be modeled in order to accurately reflect how downstream activities are impacted by small changes as work progresses . . . and changes are absolutely unavoidable, especially in large, complex projects such as rocket engine design, manufacture, and test.

Since it was impossible to use the tool in a conference room, where I could sit with the Program Manager, one or more Control Account Managers, and various Engineers (Design, Quality, Manufacturing, etc.) developing schedules became somewhat difficult and inordinately iterative, requiring dozens of communications back and forth between me and the Program Manager, as well as others who we needed input from. As work progressed, I was able to get IT to agree to allow me to log into my computer remotely from any one of the conference rooms, which made working on the schedule much easier. However, the resolution in the conference rooms was far less than that available to me on my Dell all-in-one. Its screen is 23″ diagonally, plus I have an extension display that gives me another 19″ off to the side. What I see on screen in conference rooms is not as inclusive as what I normally work with and it takes a bit of adjusting, which cuts into the speed with which I can get things done.

As I both refamiliarize myself with the scheduling process and learn how the tools have advanced, I’m learning a lot about how best to do it. Perhaps more importantly, I’m also learning how little most people know of the power of a good piece of scheduling software. There are people here who still use Excel spreadsheets and date functions to create schedules. Maybe I’m missing something, but MS Project and other similar tools provide not only calendaring functionality, but also the kind of logic necessary to accurately model the interplay between design, quality, procurement, operations, testing, and numerous other ancillary and important processes that make up the entirety of a program.

Inasmuch as Project also provides for highly detailed resource loading (quite literally down to the gnat’s ass, if one is so inclined), I’m unclear as to why we don’t use it for at least first cut proposal activity. Were we to do so, I’m convinced it would not only speed up the initial process of pricing a decent proposal but, when completed, there would be no need to then create a schedule from scratch, which is generally the way it’s done now. I suspect there are some people out there who actually do what I’m suggesting but, for all I know at this point, my perception could be wildly innacurate.

So . . . I’m kind of hedging my bets and, while I’m agitating for people to consider using MS Project more widely and for deeper resource planning, I’m mostly looking to understand the tool a little more each day. It, like many tools available to organizations of all kinds and sizes, is far more powerful than most individuals understand or are interested in learning. I’m constantly finding myself believing we are crippling ourselves by not using it far more extensively but, as many have pointed out, changing direction in a reasonably large organization, especially one which depends largely on government contracts and oversight, is like turning an aircraft carrier with a canoe paddle. On the bright side, it could keep me working for another decade, the prospect of which does not bother me in the slightest.