Showing posts with label Lean. Show all posts
Showing posts with label Lean. Show all posts

Monday, January 28, 2008

Middle and out

This little blurb is part of a continuing pro-log leading to explicit analysis of the problems related to earned value in the situation of globalized organizations, abstracted models, and a gaming-based ontology.

Most engineers will be familiar with the concept of the middle. Good projects work middle-out.

To see this, let's use the computer as an example. In the modern era when computers are everywhere (are we tired of ubiquitous, yet?), we can think of the interfaces between hardware and software. At the boundary, there are always problems. Who drives? Software? Hardware?

In a project that is defining a new 'system' both the hardware and the software must gel at some point. Of course, the latter is more malleable (we like to think; changes have consequences, though). But, hardware can change. Analysis at the middle-out position has allowed successful convergence many times. Though, one must remember that iterations may be necessary in order to really optimize a design.

Now, in projects, middle-out makes a lot of sense as a means to describe what goes on between levels and organizations. It is hard to attain such a balance for many reasons, not the least of which is that the analytical demands that need to be met are operationally-based from current work (when doing something for the first few times).

Systems engineering was developed to look at these types of issues. But, it needs to work with a whole lot of other disciplines.

In modeling, we like to use top-down and bottom-up. That top-down world loves power, and the exhibitions that result through the use of power. The bottom-up? Well it's not so easily described given the morass of the pits.

That is, the top-down involves a movement from the one to the many. The particular spread as things fan out can vary widely. Throughout the modern realm, there have been experiments with depth and breadth of this fanning.

Perhaps, the emphasis on the top-down has come about through its efficacy in many situations. It has been shown to work if there is a sufficient number of willing effectors (with characteristics as being healthy, cared for, etc.) at the levels below the top-most node (CEO, etc.).

That brings up an aside that the top-down view that doesn't try to keep its lower levels healthy is more than suspect; it is the major bane preventing an economic expansion that is our right. To wit, a whole lot of problems related to pay (hugh imbalance), motivation (hands-on needs to get respect back - how do we do this?), etc.

Also, technology requires a different balance. The top-down view does not, nor can it, know detail (SOX notwithstanding, which is basically financial in motivation). This is something to look at; abstraction has a purpose; things-in-themselves, well, some have purpose prior to any of our wanglings, but they can out-rule abstractions.

So, what are we to do? Well, for one thing, be aware of the dynamics and manage accordingly.
At the top, let the Board of Directors be more than figure-heads. Get a CTO involved who really knows and isn't just a gamer. Elsewhere, don't expect that the military model of command-control applies everywhere.

At the bottom (and between), work for innovation and trust. Preserve performers. Provide mechanisms for continuing improvements. Nothing new. Except, don't expect to be a company that people will flock to if you don't apply your principles (don't just talk them).

In a new product, who would support the middle-out position between the business views driving the motivation and the end-of-the-chain (poor slob, getting all the grief; trying to manage expectations that are possibly not realizable?) people?

Well, if one is going to argue for systems engineering, it would have to be independent of, and not accountable to, those driving the requirements, would it not? That is, technical projects get in trouble due to too few technical resources of an integrative nature being at hand as they are needed. Lean is partly a culprit (it works ex post facto in making improvements).

Remarks:

01/15/2012 -- A new wrinkle: perhaps, the middle way toward the unfolding of potential for all.

11/30/2011 -- Of late, there has been an OWS movement. It seems to not be hierarchical; that irritates the top-downers who like to think that their controlling viewpoint is truth. Have we ever seen a true middle out that respects the bottom up? I don't know. Even in science, you have those who think that theory trumps. Engineers are smart enough to know better. Ah, people and their foibles.

09/14/2010 -- Must and may. Two important concepts.

09/02/2009 -- Lets face it, folks, undecidability needs to be discussed and adopted in any complex situational setting, especially if computers are involved. Only hubris pushes us to make loud exclamations about what we're going to do in the future.

08/31/2009 -- We're going to look at this, again, from the finance view as we expand theoretics and technicals via an econoblog.

07/05/2009 -- We have to see how the computer (and computerism) influences this.

06/15/2009 -- Globalization, and capitalism, now a dirty word, according to one in private equity.

Modified: 01/15/2012

Wednesday, January 23, 2008

What can we know?

Well, the Fed has done it again, with an unusual twist. 'Emergency' save of the morally hazardous? Gosh, the Greenspan put lives.

Well, the Fed deals with a system that can only be described as 'dismal' to now (the system can change for the better). So, they have to experiment as they go along. We can allow a little leeway for error since the heart seems to be in the right place.

One might argue that this 'moral lack' is not unlike an OEM who might try to 'change' along almost all decision axises simultaneously with consequences that become more apparent through time though one could also argue that any new apparency might be forced rather than insightful in terms of real 'earned value' analysis.

An OEM can plan to have a test period that is sufficient to prove both product and process, and our learning how really is of the essence. With the economy, where is the test bed? In a sense, what we see is the old problem of knowing what is real versus expected.

The economy could have a test bed, or sand box might be a better concept. Why is this needed and how to do we do it?

Well, with the growing opaqueness of the financial instruments, all are exposed to the playings of the financial gamesters. The computer and applied mathematics enabled all sorts of variations on creativity.

But, 'hey you guys, get your hands off our money' is something that they need to hear more.

Mind you, the opaqueness does not imply malfeasance necessarily (rather, it's an issue related to the quasi-empirical). What has happened, folks, is that what we learned from studying nature has migrated over to the money area. Finance has given big bucks for physicists and mathematicians to come play games.

Well, in science, nature knocks people down when they are wrong. In the economy what happens? Well, the fat cats land on their blubber; those who suffer are the poor unfortunates who have been leaned to the bone.

Just as an OEM cannot control through a wide-expanse of time toward 'real' earned-value, and we see many instances of this, we cannot expect anyone to control that which is studied via the 'dismal' sciences.

But, we can be thoughtful and control risk. In the OEM arena, that implies heavy focus on testing and process proving through 'real' experience rather than too much reliance on analysis and parametrics (or, we might add, letting the other guy handle the difficulties while basking in anticipated glory).

In finance, we need to think of how to put out the sand box. Then, the gamesters can play to their hearts content. We might even throw in more money as needed. Or, extract, to boot.

Stay tuned, as truth engineering involves many things, but one of the consequences will be knowing how such a 'sand box' might look and work.

One new factor?

Well, the baby boomers are going to get to where they don't want games played with their hard-won assets. That might be enough motivation for a slight start toward the right direction. After all, we are not all gaming teens forever, though some might like to think thusly.

The Fed needs to show more maturity. Of course, that whole position covers only one (monetary) of many aspects of a difficult issue.

Remarks:

08/01/2013 -- Ben cannot unwind or taper down; he has too many Doves. We'll have to get back to the king thing (yes, the divine rights of the CEO, new royalty, in other words) and dampening of these types by a new outlook (Magna-Carta'ísh).

09/09/2009 -- Alan's reign will be looked at, in time.

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.

08/24/2009 -- Last year, Ben blinked and panicked. He frantically pulled out all stops as if with no thought for tomorrow. Now, he has no use for 'mea culpa' big daddy that he is. Ben, start to unwind now. The Vienna School's view that these things are undecidable (which is a computational issue) is right on.

Modified: 08/01/2013

Thursday, January 10, 2008

Before and after

New poll, 01/11/08.
One wonders about the games played in a 'market' economy, though 'games' might just be some type of human proclivity with which we'll always need to cope.

Today, the FED (the money printers who want to support 'moral' hazards in the market, it seems) said that it would reduce the rate which drives those parts of the investment realm that are favored by the more conservative who don't like having so many hands trying to remove whatever money is there in the pocket. Some analysis seems to indicate that the present trouble was due to too much liquidity from the rate being too low.

Why always this bail out of frivolity? Recently, I read where some manager said that risk analysts had told him that they could calculate to within a couple of decimal points. My reaction was: what? in what universe? dreamland? Of course, they can provide numbers; what reliance can we place on them?

In another realm, in May of 2007, Business Week had an article related to 'crunch time' at Boeing. A reader comment there noted that the 7/8/07 looked to be a 'show and tell' (AWatcher May 22, 2007 3:26 GMT) (or as Leelaw #50594 likes to say 'potemkin' in regard to the hugely publicized affair).

Yet, we have about that same time comments from the CEO saying that "problems in the Dreamliner production won't prevent Boeing from delivering the 787 on time", though there were various mentions about experts doubting that Boeing could pull this thing off in the time frame planned years ago. Also, polls seem to indicate that most who participated thought that there would be delays (long before Boeing announced the schedule shift).

So today, more rumors are coming about in regard to another delay; of course, some of this just might be mongers getting into their 2008 stride.

Where are the mature heads that want an exuberant, yet controlled, economy while at the same time wanting 'wise' project management?

The May 22, 2007 comment asked these questions which are still apropos with some unanswered.
  • That the program is allowing pieces to be shipped without all the 'stuffing' reeks of a 'show and tell' event for 7/8/7 (well, marketing is running the game - could be the practice assembly that wasn't scheduled?). [yes, a practice put together, but the hoopla continued unabated]
  • Can this plane hit May 08 even if there are some delays (however slight) getting the test vehicle off the ground? [well, we found out that it would not]
  • There are so many new factors, how can there be such an abbreviated test period? [that talk of an abridged test has gone away, we hope]
  • If a time-line re-adjust now would produce a better plane, why not bite that bullet and do so (After all, Boeing must know a lot more now than 2-3 years ago; to keep asserting that things are fine will look worse later.)? [someone needs to carry forward a more wise way to handled these things - now, it looks like a cat-and-mouse play - what is believable?]
  • Why doesn't the 'Mythical Man-Month' principle apply here? [open question]
  • Also, why doesn't Lean say "stop the line" when there is a problem (don't push defects downstream)? [well, the line did eventually stop or slowed to a snail's pace]
Well, all the things asked by these posts, beginning with the Seed post still apply.

Slogan: modus operandi involves 'blog and truth' and minimizing 'hogwash' in all affairs.

Remarks:

08/01/2013 -- Ben cannot unwind or taper down; he has too many Doves. We'll have to get back to the king thing (yes, the divine rights of the CEO, new royalty, in other words) and dampening of these types by a new outlook (Magna-Carta'ísh).

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.

05/18/2009 -- Testing in flight is within sight.

Modified: 08/01/2013

Friday, September 28, 2007

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

Thursday, September 6, 2007

Unknowns and unknowns

Generally, our progress involves adding to what we know and what we can do; engineering is a fairly systematic application of what we know about what we can control. Yet, there are unknowns which may vary in importance from 'of no consequence' to 'we better pay some attention.'

There was some mention yesterday (09/05/07 conference call, see flightblogger) about not knowing what-is-what until you get to where you have to deal with what. This sort of suggests that part of a schedule would be actually giving time to work several things through a process before trying to lean-and-efficient the thing. Otherwise, you're talking only in the abstract and allowing those things-in-themselves to have little ground. This can bite one.

Which brings up not knowing what we don't know. The financial types have been discussing the 'black swan' theory as it pertains to our inclination to over layer what we don't know with what we have known. That is, do we need to be better about expecting the real unexpected?

This issue does apply to engineering, as well, in particular when what we know is either relaxed or we make mixes of what we know in a new fashion. In the first sense, unknowns will be more problematic in less stable domains; in the second sense, using lab results and making sure that extreme values are tested are a couple, of many, techniques that we have come up with.

In any case, time is usually not of overriding importance unless you're heading toward a crash in the wall. But, under such conditions, one wouldn't be experimenting with fundamental control issues. 'However long it takes' is the real key for handling unknowns.

Remarks:



04/07/2012 -- Flightblogger ends, as least, Jon's watch. Some issues raised five years ago are still apropos. The context may have changed a little, yet, perhaps now is time to re-address the themes.


09/02/2009 -- Lets face it, folks, undecidability needs to be discussed and adopted in any complex situational setting, especially if computers are involved. Only hubris pushes us to make loud exclamations about what we're going to do in the future.

09/02/2009 -- We need to assess wind direction, many times.

05/27/2009 -- That we have topsy-turvy needs to be addressed more fully in both an epistemologic and an operational sense.

01/27/2009 -- Lessons to be learned (as opposed to learnt), including, by necessity, Ponzi.

06/14/2008 -- Early posts were related to engineering, but the tone of the blog now covers the gamut. What we see with engineering can be tested since science is available; what we see with finance and marketing will continue to be more problematic and therefore of interest.

Modified: 04/07/2012

Monday, September 3, 2007

That seductive abstract

As mentioned in the earlier list, abstraction has a lot of modern appeal thanks, in part, to computation. It's also very seductive in the drive for minimum costs or for the most lean effort or any other quest for the optimal.

Yet, an experienced engineer will tell you that no amount of modeling prowess replaces the thing-in-itself. That is, even an advanced 'second world' (or call it holodeck) experience is not reality. Just like a simulator experience is not the real thing.

So, how does this problem play in the stacked deck that we see with CAD and CAE (CAx to some) in the context of a complicated product? Well, given a product with new material, process, and configuration, are we to believe that the analytics are so strong so as to push us to think that we can ignore risks that may be inherent (will be discussed further)?

One thing of importance here will be quasi-empiricism versus a focus on foundations. The latter seems to take hold when the less 'hard' come to fore (finance, etc.).

Stay tuned, as this topic will keep reappearing.

Slogan: a new product, even though engineered by computer, is a hypothesis that needs to be proven (not hyped).

Remarks:

01/17/2013 -- Grounding due to fire.

11/02/2010 -- This post is 3 years old. Originally, the context dealt with engineering. But, finance soon came to fore with its importance to capitalism. We need to redo money, essentially.

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.

05/27/2009 -- That we have topsy-turvy needs to be addressed more fully in both an epistemologic and an operational sense.

01/23/2009 -- At the time of this post, engineering was the main focus. Then, other areas become of interest due to overlaps in the problems: map-territory, computation and being, and much more. There will be more integrating posts to bring some cohesion, such as leveraging and fiction.

Modified: 01/17/2013