Rush job

This is a general comment not particularly mapped to any one event (though links and some comments may appear to have a particular flavor).

We have all seen the types of things related to rushing to meet a deadline, usually as earned-value analysis fails to perform properly. Time for some deliverable starts to run out, things are done more quickly, perhaps corners get cut, the equivalent of the 'triage' of medicine becomes the modus operandi, and so forth.

Of course, in retrospect, after a rushed job a product may very well be okay since only value-added (in the lean terminology) tasks were performed. Others were bypassed. However, such an outcome, assuming that some effort at lean had already been done on the task definitions would essentially be miraculous. So, rushing may very much lead to errors (as probably most can attest).

That some errors only come to fore down the pike is how we learn. Usually, we expect that the cause is looked at and improvements made. Yet, the first pass through any process change ought to be consider experimental and hypothetical (this lesson seems to not have sunk in, in general, as much as will be necessary). Yet, things that only happen now and then need to be even more conditionally handled (say, new airplane program -in which case, the regime of testing in actuality and of correcting faults is the safety net if done correctly) than those things that recur regularly.

Skimping on process (such as, according to the book and not expecting to have to handle any unforeseen contingencies) is not what one would expect to be the prevailing attitude on a major product that is not only of high market value but also is high on the criticality scale (plus having roles related to the human imagination).

Part of it is our fault (yes) for not understanding technology (but how can we without the appropriate information?) and evaluating things on the surface (even though later analysis shows any problems with substance).

However, we also expect those that do and those that have the authority are taking their responsibilities seriously even it it causes schedule slides. But, again that's our fault: for not understanding that foresight is not 20-20; not knowing that any project that spans more than a limited time (whose cardinality may vary by several factors) needs course corrections (a flying metaphor is perfect; would you want to be on a plane where all the instructions for the whole flight were put in as an initial condition and then it just played out like a record? Silly, isn't it?).

Was there a missed chance the past year or so for a particular thing to be a good demonstration of extremely proficient project management? What glory is there for allowing a mindset that does not consider things in a balanced manner? This seems almost like 'look , ma, aren't I wonderful?'.

Let's see, what is one problem? Well, engineers who become managers say that they are 'recovering engineers' (for those manager who are not from engineering ask an engineer to explain). Indeed.

It's a case of a mind going from handling the specifics of nature to the generics of pseudo-control and from performing extremely difficult manipulations of our models of nature to another role that may or may not be as necessary as we think: playing well on the screen (talking heads), smoothing over troubled waters (back slapping), thinking of money (mostly how to keep it in the pocket - albeit that whole abstraction is something that we'll be looking at more closely - abstraction in the sense of what is a 'buck' exactly? - yet, this role can result in accumulations that could be considered obscene), worrying more about surface issues rather than substance (some might call this air brushing), and much more (oh, I forgot, decider).

Management may rule and control employees; they have not succeeded in taming nature. Also, not many have bridged well the ontologies that exist between those who are involved with the 'real' plus their lower-level managers who have a good sense of what's real and those who are in the highly abstracted world of the executive. Earned-value determination requires more than an accounting overview.

In the realm of technology, we will need to get management (and decisions) to more of an science/engineering stance than we see now; the computer will help; yet, the human element will still be a strong factor (and engineers are mostly of nerdish variety, many mindsets think - yet, how to get a better operational balance is still in the works, systems engineering is one of the new pegs); truth engineering needs attention; and so forth.

Yet, in the realm of imagination (motivation, etc.), which is a tremendous human trait, we may not get beyond the art (which insightful management strives to be very effective in) despite our best efforts to engineer the thing (in itself). Hence, expect that management will continue. Besides, the roles connected to management may be a necessity (they are never anywhere near sufficiency).

As one columnist noted recently, managers need to be leaders, rather than pirates, in order to help us through the complexities that we face.

Remarks:

01/19/2011 -- Update1 and Update2. The focus now will be mostly the idiots of economics/finance.

09/02/2009 -- Lean assumes a current framework which can be improved. That the process is still effective during the change can be checked easily. However, if it is not still effective or we do not have a stable framework, then we were, by necessity, in the undecidable state.

07/14/2009 -- Nope, confounding continues.

01/28/2009 -- Earned value issues continue to be of interest.

11/01/2008 -- Much has happened with regard to the schedule, the suppliers, and more. Boeing announced some insights about its 787 planning. Before that, the idiocy of a truncated (abbreviated) test cycle was changed.

Reminder: at this point last year (we can pinpoint the specific dates), there was still some talk about delivering in May 2008.

Modified: 01/19/2011