The Red Curve

People with a background in TOC know about the red and green curves. In this blog entry I describe those curves and point to a new blog I have started on Wordpress.

What are the red and green curves of TOC?

As the story goes, years ago Eli was describing the kind of growth that was possible for organizations.  I believe this was at a conference in Cambridge, England, but I could be mistaken.

The first curve he drew was the green curve.  The green curve represents a kind of improvement, but it's asymptotic improvement.  Yes, the company is still improving, year after year, but with each year the improvement becomes less and less.  Never zero, but always less.

Eli refers to this as "stagnating at a higher level."

The other curve is the so-called "red curve."  It represents a qualitatively different kind of improvement: exponential growth.  Eli happened to be using a red pen when he drew this curve and so that name has stuck.

The figure on the right shows these two curves.  The black line that divides them represents linear growth for the organization.

Most people find the red curve as unrealistic.  They don't think their organization can grow in this way year after year.

And yet, if you expect 30% growth each year, what kind of curve would you expect to see?  One that flattens out, as the green curve has done, or one that grows exponentially, like the red curve?

For grins, I wrote a little model in Python, where a company grows at 30% per year for ten years.  Net Profit starts out at $100,000 on the first day of the first year of the simulation.  After plotting the data in Excel I had the chart you see on the right.

And so, if your CEO is demanding 30% growth year after year, he or she is demanding red-curve performance.  Do you believe you can achieve it?  If you can achieve it, can you sustain it?

I believe red-curve performance is achievable and sustainable.  But not according to the means most often used today.

I have started a new blog for discussions on exactly this topic.  That blog is redcurve.wordpress.com. 

It's meant to provide a place for meaningful discussion of the issues that block us from obtaining red-curve growth from the many different human-based systems most important to us.  I went to Wordpress for a few different reasons, but primarily because blogging their is significantly less cumbersome than the Plone-based blogging engine I use here.

Mac And PC Meet Linux; Linux, Meet Mac And PC

Unless you have been living in a cave the last year or so you have probably seen the Mac vs. PC ads on television or at apple.com. They are a riot. Well, now there are at least three new ads featuring a third party -- Linux. Check it out!

I found these ads on Digg. I don't know if these ads will run on television or not. I read that they were shown at a recent developer conference, however.

And if you sometimes find yourself watching "American Chopper" from time to time you really need to check out the "Geek My Sled" series of marketing videos created by Novell.

_____
tags: fun

The Physicist And The Amazingly Stupid Business People

Here's an article from Maverick magazine on Eli Goldratt. It's a hoot and well worth a read!

A friend sent me an interesting article about Eli that was published in Maverick magazine fairly recently.

I have an objection (of course) regarding the title.  In my experience I haven't run into many stupid people in business.  What I have run into is scores of people that were blocked by dilemmas in one way or another.  But stupid people -- not so many.

At any rate, the article itself is quite good.  Enjoy!

_____
tags: theory-of-constraints

A Rare Freebie

Here's a chance to get a glimpse of the Total Matrix material at no charge.

On  Saturday afternoon, 3/24/07, I am presenting a 1/2 day session on multi-project management based on material from Tony Rizzo's Total Matrix workshop. 

Total Matrix is an engineered approach to Enterprise Project Management created by PDI.  Total Matrix includes CCPM and then extends it with the other attributes necessary for success, such as robust project planning and appropriate measures of performance.

You can download a PowerPoint presentation on Total Matrix if you wish.

The presentation will include use of the Total Matrix simulator and will be held in Bothell, Washington, USA.  I have room for only two more people in this workshop.  If you would like to attend please contact me to make arrangements.

Because this is a 'dry-run' session, there is no charge for attending.

_____
tags: project management

Talk To The Hand

Most of us have learned that we should be very careful in how we respond to ideas brought to us by others. As might be expected the presence of a conflict is responsible for the need for care in handling such situations. In this article I present the conflict -- as I understand it -- that Eli recognized so long ago. My hope is that by learning how to respond much better to ideas from others we can avoid wasting the many opportunities that surround us -- if only we will do the work necessary to seize them.

Many years ago my oldest daughter once told me to "Talk to the hand, 'cause the face ain't listening."  It caught me by surprise, but pretty quickly, everyone in the house was having fun with it.

The saying is terribly out of style now, but knowing how to respond appropriately to other people's ideas is -- in my view -- a critically important skill.

Further, I have been writing about Opportunity Wasting Behaviors recently.  I am continuing that thread today. In my view one of the ways in which organizations -- and individuals -- waste opportunities available to them is by being horribly ineffective in responding to ideas from others.

Many of you will have seen the Goldratt Satellite Program tapes.  On tape #7, Eli describes how a conflict -- a dilemma -- often causes us to respond poorly to ideas brought to us by others for consideration.

On the GSP tape, Eli presents a CCRT that describes how we often react poorly when people bring ideas to us for evaluation and, frequently, seeking permission to implement them.

Figure 1, below, is an Evaporating Cloud diagram of the conflict.  I have used my own words here, so if there is an error, it is mine rather than Eli's.

In text, this cloud could be read as follows: "When someone brings me an idea, I want to respond in the best way.

To respond in the best way, one of the things I must ensure is that my relationship with the inventor is protected.  And in order to protect this relationship, I have to be avoid raising the issue of negatives that I perceive as following from the implementation of the idea.

On the other hand, in order to respond in the best way, I must also protect the system in which the idea will be implemented.  To protect the system in this manner, I must raise negatives that I believe will follow if the idea is implemented as is.

And so, I'm in a dilemma.  I have to both raise and not raise the negatives that I perceive as following from the implementation of the idea.  And clearly, I can't do both."

On the video, Eli appears to challenge an assumption on the conflict arrow (the D-D' connection).  That is assumption is "We can't do both."

In fact, we can. 

Breaking this conflict begins with giving the inventor (the person bringing the idea) what they are seeking -- praise.  But understand this very carefully.  There is a world of difference between "plastic politeness" and genuine praise.

Then, once the inventor knows that he has been heard he is emotionally able to listen to a proper response to the idea.

The response to the idea has to be carefully crafted and based on cause-effect logic.  So, shooting from the hip is out for most of us (certainly for me.)  Much better to develop the negative branches that you see in the privacy of your own office.

Once the negative branch(es) have been built, it's time to schedule a meeting with the inventor to communicate them.  But again, it's not just a matter of dumping a bunch of logic twigs on the inventor and then bailing out.  The goal is to really prepare the inventor to understand your concerns.

In this article I can't give you the full logic that Eli develops on the GSP tape.  There are many subtle aspects to this subject matter and to "get it" you should view the tape (probably several times) and/or work with someone that really understands it.

Let me now get to my larger point, however.

Once you understand this aspect of TOC, you look at situations in an entirely new light.  It's another of the many paradigm shifts that we must make in order to fully exploit the many opportunities that surround us.

For example, consider in the software world the humble code review.  In many companies, developers cannot commit code to a shared development branch or view without first having another developer inspect or review the code.

Have you considered that a code review is, essentially, one developer saying to another developer "I have an idea.  Let's change our code to work like this."

In code reviews, design reviews and other meetings where one engineer is sharing a set of ideas with other engineers, the dynamics Eli describes on tape #7 are fully in play (in my view.)

Is it any wonder that when we attend these kinds of meetings we often find ourselves both wanting and not wanting to comment on some aspect of the proposal?  If so, we are experiencing the conflict that Eli has identified.

There are many other ways in which people suggest ideas to others.  For example, when someone sends their resume to someone else, it's a way of saying "I have an idea.  Let's explore whether we might be able to do business."

Finally, I want to tie all of this back to the idea of Opportunity Wasting Behaviors.

Not knowing how to properly respond to ideas from other folks is a guaranteed way to waste opportunities.

As Eli shows, responding to someone's idea in the common manner often leads to hard feelings on the part of both parties.  And when that happens "Kiss goodbye real collaboration."

So let me close with this recommendation.  Take the time to learn how to respond to the ideas of others the TOC way.  It's more work than what you're doing today, but it's far more effective in the long run.

And it's all about the long run.

_____
tags: management|  project management|  theory-of-constraints|  worklife

Made To Stick

A free introduction to the book "Made To Stick" is available on-line. I found it interesting and wanted to share it.

In the Critical Chain group on Yahoo, Jason Week published a link to some introductory material (ok, a teaser) for the book "Made To Stick."  It's had the intended effect on me -- I ordered my copy from Amazon this morning!

_____
tags: management

Premature Parallel Development

In the last few posts I have been writing about what I call "Opportunity Wasting Behaviors" or "OWBs." Continuing that thread, this article is about "Premature Parallel Development."

I use the term "parallel development" to refer to the situation where an organization divides its development resources into teams and puts them to work developing two or more products concurrently.

Sometimes, this is done as a response to the reality of shrinking product lifetimes.

Let's say that a given product has a lifetime in the market of six months.  That is, once it is introduced to the market it is expected to be viable for only about six months.

If the development of products of this type takes about one year then the company must begin the development of the replacement product for this market at least six months before the first product is launched.

Not only that, but the development team assigned to the development of the first product will have to begin development of the third product in this line as soon as it has launched its first product.

So this is one example of how the need for parallel development arises.  When the product development lead time exceeds the product lifetime in the market, parallel development usually becomes a necessity.

Companies may embark on parallel development efforts for other reasons as well.

For example, the desire to enter a wholly new market with a significantly different product offering may spur the company to fork its development resources.  One group will continue to develop the existing products, while the other will embark on the development of the product offering for the new market.

Alternatively, a company might take a fraction of its development resources and put them to work on a project that is designed to improve the company's product development process itself.  This is also a kind of parallel development.

It seems clear that there are many reasons why a company may wish to undertake parallel development efforts.  But I suggest that we should look a bit deeper before taking such a leap.

Consider the following.

JSoft is a leader in application servers.  In this case, an application server is software that enables web-based enterprise applications to run on a server computer.

JSoft is in a highly competitive market.  They are currently the market leader and are consistently releasing new products far more quickly than their nearest competitors.  As such, most of their competitors are constantly forced to play "catch up" with JSoft.  JSoft is also taking the hefty premiums that are paid for being first to market with problems that solve customer's serious problems.

One day, at a meeting of the JSoft Board of Directors, two of the directors point to a potential new market -- application servers for embedded devices.  This is a significantly different market for JSoft and not one in which it has any significant expertise.

The issue is debated and, reluctantly, JSoft's CEO agrees that the company will investigate this new market.

Over the next few months, JSoft investigates the market.  As the work proceeds, the investigation team becomes more and more invested in the idea.  For some reason they have trouble seeing the "negative branches" that they are about to create for JSoft.

Eventually, a decision is made that JSoft will make the necessary investments to get into this market.  Meetings are held and a new parallel development effort is launched.

The development teams are split into two groups.  The largest of the groups will continue to develop and maintain the original product line.  The smaller group -- consisting of about 30% of the development resources -- will begin work on the new product, "JSoft For Embedded."

Development proceeds and both teams eventually ship their products.

The team maintaining the original product shipped a couple of months late.  This was expected as 30% of the resources assigned to the project were no longer available.  There were also the effects of the reorganization of the Product Development group into the two teams.  This was said to account for some lost time.

The team developing JSoft For Embedded also shipped its first release later than expected -- and with a reduced set of capabilities.  In the post-mortem, the consensus was that the learning curve for this new area was larger than expected.

Over the next year both groups seemed to settle in to their new roles.  Sadly, the market for JSoft For Embedded did not develop as quickly as forecast.  The sales of JSoft For Embedded were somewhat disappointing and this business was not yet profitable.

Fortunately, the main business was still profitable, but it was also clear that some negative trends were developing.  JSoft's nearest competitor, ASI (Application Servers, Inc.) was gaining ground in the market and had recently surprised JSoft by releasing a new version of their software that contained several features that JSoft's product did not have.

Over the next year the situation became even worse.  The market for embedded application servers was not developing as hoped and JSoft was struggling to get sales in this space.  From time to time, members of the JSoft For Embedded team were "borrowed" to help out on the development of the main product line.  As this multitasking became more and more common the situation seemed to deteriorate even further.

Eventually, JSoft's management shelved the JSoft For Embedded project and reassigned the developers to the main product development team.

However, by this time, ASI had a firm lead in the market and it was JSoft that was forced into second-tier status.  JSoft was also sued by some of its early customers in the embedded application server domain, when it could no longer honor the support agreements for JSoft For Embedded that it had extended to these customers.

Hopefully, the example given above makes clear the dangers of embarking on a parallel development effort before the company has the resources necessary to fully support it.

In the above example, JSoft did not have sufficient capacity to staff two large development efforts at the same time.

By diluting their efforts, they wound up delivering two new products, but their deliveries were so late that in their primary market they gave up the "high ground" of being consistently faster than their competitors.  This gave their primary competitor, ASI, the chance they needed to take over first place.

The bottom line is this.  Parallel development is ofen the right choice for an organization.  It can and does make perfect sense under certain conditions.

One of those conditions, however, is that by embarking on a parallel development the company will not be forced to give up its leadership position in any significant markets.  If this condition is not met then it is almost certainly only a matter of time before reality will catch up with the organization and force it into a situation where it is "CTD" -- a term paramedics sometimes use with a seriously ill patient who is said to be "Circling The Drain."

_____
tags: dilemmas|  flow|  management

Multitasking As An Opportunity Wasting Behavior

Multitasking is common in product development and other organizations. But I claim it's a behavior that often causes us to waste the business and other opportunities that we recognize and want to exploit. In this article I present a simple Gantt chart that supports this claim.

In a previous post I suggested that I thought it would be useful to begin building a catalog of common behaviors within businesses that either caused opportunities to be wasted, or caused opportunities to be more fully exploited.

I called these behaviors "Opportunity Wasting Behaviors (OWBs)" and "Opportunity Exploiting Behaviors (OEBs)."

In that post, I suggested that multitasking is an example of a Opportunity Wasting Behavior.  In this post, I want to discuss my understanding of the mechanism by which multitasking typically causes (business) opportunities to be wasted.

At a high level, multitasking can cause opportunities to be wasted by causing product (or service) development to take longer than would otherwise be necessary.  As a result, the company is not able to fully exploit the opportunity.

Note, this assumes that the opportunity only exists for some finite period of time.  That is, we assume that in order to exploit an opportunity the company has to respond with its product or service (its "offer") within the temporal confines of a "market window."

For example, consider a company that makes accessories for MP3 players.  Before the Apple iPod was introduced there was no market for iPod accessories.  When the iPod was hot, the market for iPod accessories was also hot.  As the iPod wanes in popularity, however, so does the market for iPod accessories.

So, if we agree that opportunities can be wasted when the creation of a company's offer takes too long, let's look at multitasking in more detail.  How does multitasking inflate development times?

The figure on the right is a screenshot from a demo version of the Merlin project management software.  Please have a look at this figure now.

From the figure, notice that there are two sub-projects.  The first, summarized in row 1, shows a project ("Without Multitasking") that is planned to take 30 days to complete.

The second sub-project is named "With Multitasking."  It is summarized in row 6.  It is also planned to take 30 days to complete.

So here we have a first observation: Multitasking, by itself, doesn't increase the total time required to complete a given *set* of projects.

(Note that I'm assuming "task switches" are instantaneous.  Of course, this isn't reality, but time-consuming task switches would only make the case against multitasking stronger, so no harm is done by making this assumption.)

So if multitasking doesn't increase the total time required to complete a given set of projects, what is there to carp about?  What's the big deal?

The big deal is that while the total time required to complete a set of projects isn't increased, the time required to complete every individual project is increased when multitasking is present.

Have a look at the figure again.  When multitasking is present, the time required to complete Project A is increased by 10 days (from 15 days to 25 days.)  The time required to complete Project B is also increased by 10 days.  Both projects took longer to complete.

Why?

The answer is that projects only move closer to completion when we actually work on them.  I know, this is a startling conclusion, but it's true!

When we are multiasking, we have the sense that we have more tasks "in progress" than when we are not multitasking.  In reality, we have more tasks "open" or "started" but not "in progress."

Look again at Figure 1.  Can you find any interval where work is being done on more than one task?

The answer, of course, is no.  In the example, whenever Project A is being worked, Project B is standing still.  And whenever B is making progress, A is stalled.

So the net effect is that both projects take longer to complete.

If a project could be "making progress" when no one was working on it then the situation would be different.  If a project or process has some kind of "cook time" associated with it we must be more careful in our analysis.  (But I still wouldn't immediately jump to the conclusion that multitasking wasn't harmful, even in that situation.)

But in knowledge-work companies, how many projects are "making progress" when no one is working on them?  Not many, in my experience.

So, lets cut to the chase.

Multitasking increases the time required to complete projects and by so doing it puts us at great risk of missing the "market windows" associated with the various business opportunities we recognize.

For this reason, we should be concerned that multitasking in our organizations is very likely to be an Opportunity Wasting Behavior.

_____
tags: critical chain|  flow|  management|  project management

Opportunity Affecting Behaviors

Over the last few weeks I have been focusing my efforts on preparing for an upcoming presentation of Tony Rizzo's "Total Matrix" two-day workshop. So, I apologize for the relative dearth of posts on this blog. In this post, I want to open a new topic -- that of "Opportunity Wasting Behaviors (OWBs)" and "Opportunity Exploiting Behaviors, (OEBs)."

In my view, there are many possible behaviors that we may manifest in the business world.  If we are interested in exploiting business opportunities to the greatest possible extent, then it seems useful to attempt some kind of classification of common behaviors into two major groups.

The first group I call "Opportunity Exploiting Behaviors", or OEBs.  These good behaviors are the ones that help us exploit opportunities that we have recognized as available to us.

The second group is the mirror image -- these are the "Opportunity Wasting Behaviors", or OWBs.  These are the behaviors that cause us to waste opportunities that are available to us.

In some sense the development of a catalog of Exploiting and Wasting behaviors feels a lot like the development of a set of software patterns.  Patterns are important in the software world.  They improve our productivity by providing us with a ready-made guide for completing significant aspects of our work.

My hope is that I can develop a reasonable catalog of these behaviors.  While such a catalog would be valuable in its own right, it could also be the knowledge-base for interesting computer applications.

But I'm getting ahead of myself here.  Let's come back down to Earth.

In Figure 1, below, I am making the claim that our business behaviors ultimately sort into one of two categories -- either the behavior helps us to exploit an available opportunity or it causes us to in some sense waste the opportunity.

So this triggers the question of whether there are behaviors that are somehow neutral with respect to opportunities.

In my view, there is no middle ground.  Yes, we may have to do an arbitrarily large amount of analysis to decide whether some given behavior actually helps us to exploit or causes us to waste opportunities.  And yes, reasonable people may disagree as to whether some given behavior causes us to waste or enables us to exploit our available opportunities.  But these realities are not enough to cause me to conclude that "opportunity neutral" behaviors exist.

Of course, I could be wrong.  Perhaps there are behaviors that are neutral with respect to the opportunities available to us.  I would appreciate receiving examples of such behaviors if they can be found.

In subsequent posts, I will be sharing some thoughts about various opportunity wasting and opportunity exploiting behaviors. 

The first one on my agenda is a real heavy-hitter in causing us to waste opportunities available to us.  That heavy-hitter is the relatively common behavior of multitasking.

_____
tags: management

Paul Graham

I enjoy essays that are well-written and though provoking. And I'm trying to learn from the masters. Paul Graham strikes me as such a master. In this article I share some information on Paul's work and his essays.

I first came to know of Paul Graham while hacking Common Lisp.

Paul is an accomplished hacker and has impressive credentials in the Lisp community.  His macros are widely used and his book "On Lisp" is essentially required reading. 

Paul is also known for building a company (along with Robert Morris) that was eventually sold to Yahoo for about $50M.  The software that Paul and Robert wrote that made the company, Viaweb, such an impressive company was actually written in Common Lisp.  So naturally, every other Lisp hacker, myself included, points to Viaweb as some kind of existence proof that we aren't completely insane.

Paul has also written about about another language I enjoy hacking in -- Python.  In his essay 'The Python Paradox' Paul writes:

In a recent talk I said something that upset a lot of people: that you could get smarter programmers to work on a Python project than you could to work on a Java project.

I didn't mean by this that Java programmers are dumb. I meant that Python programmers are smart. It's a lot of work to learn a new programming language. And people don't learn Python because it will get them a job; they learn it because they genuinely like to program and aren't satisfied with the languages they already know.

Which makes them exactly the kind of programmers companies should want to hire. Hence what, for lack of a better name, I'll call the Python paradox: if a company chooses to write its software in a comparatively esoteric language, they'll be able to hire better programmers, because they'll attract only those who cared enough to learn it. And for programmers the paradox is even more pronounced: the language to learn, if you want to get a good job, is a language that people don't learn merely to get a job.

Only a few companies have been smart enough to realize this so far. But there is a kind of selection going on here too: they're exactly the companies programmers would most like to work for. Google, for example. When they advertise Java programming jobs, they also want Python experience.

You can find Paul's published essays on his website.

In closing, I have to say that I find it more than a bit creepy that when I'm working in Python and googling for information to keep getting AdSense hits from Google telling me about how their Kirkland office is looking for Python programmers.  The really scary part was that if I didn't already have a great gig going on, I'd probably give them a call!
_____
tags: plone|  problem-solving|  python|  software-development

Good Multitasking vs. Bad Multitasking

In my view, the debate over "good" multitasking vs. "bad" multitasking is just like the debate that used to rage over whether inventory is an asset or a liability. If this is correct, then perhaps we can look to that debate for guidance with respect to multitasking

Over in the Critical Chain group a debate is raging over the concept of "good" multitasking vs. "bad" multitasking.  This is a debate that comes up frequently.  Which to me means only one thing -- there is an underlying dilemma that is not being addressed.

From my observations, one group says that we must treat multitasking with a heavy hand -- we should drive it out of our organizations, and (I guess) not admit that there are ever any situations where multitasking is appropriate.

The other group says "No, we must distinguish between good and bad multitasking.  There are cases where multitasking serves us, and so we can't just declare multitasking as always bad."

In my view, the situation seems a lot like the debates that used to rage (and probably still do, from time to time) over inventory: "Is inventory an asset or is it a liability?"

Here I think the question itself is wrong.  In my view, "asset" or "liability" isn't a property of inventory itself, but of the larger context of the effect it has on the system in which it resides.

For example, in the case of a clothing store, having no inventory is clearly insane -- potential customers will show up, want to look at some merchandise, only to be told that "Sorry, we don't have anything to show you, because inventory is always a liability, so we've eliminated all inventory.  If you place an order, however, we can have it here in a few days."

On the other hand, and considering again the same clothing store, it would be equally insane to have so much inventory on hand that no one could get in the front door.  Potential customers would show up, not be able to shop easily, and would rightfully decide to take their business elsewhere -- to a store where they can easily walk around as they do their shopping.

So, clearly, there is some appropriate range of inventory for the clothing store.  It seems equally clear that it's not that inventory itself is bad, but rather, the amount of inventory that is on hand at any one time.

Now, let's consider multitasking.  There are cases where multitasking is appropriate.  Over on the Critical Chain group, some folks have posted examples of limited multitasking allows projects to complete more quickly than when multitasking is never allowed.

On the other hand, it is equally clear that rampant multitasking will extend the duration of projects, rather than allowing them to complete more quickly.  When this happens, we see the negative face of multitasking.

So how do we decide whether a given instance of multitasking is good or bad?

This is where we have to get back to basics.  I think we can only answer this question by judging the impact to the organization as a whole.

How do we do this?

In the Critical Chain group, I proposed a hypothetical function, f().  The hypothetical f(), when evaluated, gave the perfect order in which to execute the outstanding tasks across all projects that the company is currently working.

I also wrote why I believed real organizations can never implement a true f() function, and so, they are forced to develop proxies for it.

By proxy, I mean an implementation of a function that can stand in for f(), but necessarily gives answers that are less perfect than a true implementation of f(). 

The reason for using a proxy is that you can implement a proxy f(), whereas you cannot implement a true f().

In the Critical Chain group, Vladimir suggested that "expected NPV" is a reasonable proxy for f().  I think he's correct, and I expect that many project organizations use this, or something like it.

So, given this, how can we decide whether a given multitasking case is "good" or "bad" multitasking?  I think we must consider the impact on future expected NPV -- we should evaluate our proxy f() function, and see if its output either confirms multitasking as the proper choice or refutes it.

_____
tags: critical chain

Software Archeology

Often, software development isn't so much about new development as it is about maintaining existing software. But few of us have any real experience in maintaining very old software. Recently, my interest in the history of the Apollo project brought me to discover a complete working simulation of the Apollo Guidance Computer.

As I suppose is somewhat common for technical folks of my age (47 years) I have an interest in the history of the Apollo program. 

As a child, I remember camping in front of our large RCA "entertainment center" (television, radio and record player) whenever NASA was launching a space shot of any kind.  While I have vague memories of some of the earlier program launches (probably Gemini, probably not Mercury) it was really during the Apollo program that I became much more aware of what was going on.  Fortunately, my parents would let me "camp out" for days at a time in front of the television to watch the launches.  It was fantastic.

So for the past few years I have, from time to time, spent enjoyable evenings surfing the web and reading up on the Apollo program.  It is wonderful how much history remains and is accessible on line.  It is at the same time sad how much history has been lost.

Recently, I stumbled onto a site with a working simulation of the Apollo Guidance Computer, or AGC.

This is remarkable in itself, but it gets better:  The programs which ran on the Apollo AGCs is also available!

So this evening I'm downloading the pre-built binaries for the simulator.  It seems even more of a miracle that such binaries should exist for Mac OS X, but I guess tonight is just my night to win big.

I also found a link to another engineer (also from my era) who has built a working hardware replica of the Apollo Guidance Computer.  It's a simply amazing project!

As you may know, the descent of the Apollo 11 Lunar Module ("Eagle") to the surface of the moon was not without its software problems.

During the descent, the software running in the AGC in the LEM encountered a number of fault conditions, or "alarms" in the terminology of the project.

The image on the right is a scan of a document that one of the Apollo 11 controllers kept under Plexiglas at his work station.

I don't know about you, but if you want a definition of "Works well under pressure" for a resume, please consider the following scenario.

After more than a decade of work by tens of thousands of people, two men are attempting to land on the surface of the moon.  Literally, the whole world is watching and listening and holding its breath.

While this landing is in progress, you and a few other people are responsible for monitoring the flight control software running in the LEM.

While the landing is in progress your worst nightmare starts to come true:  The software begins to give signs of malfunctioning.

You and your peers have only about 30 seconds to decide whether to continue the attempt to land on the moon or to abort the attempt.

By the way, you're 24 years old, and almost everyone in the room has been chain-smoking and drinking coffee for the last eight hours!

I simply cannot get my head around what it must have been like.

I guess this is my way of saying I have a great deal of respect for the people who came before me in my career in software engineering.  And I am grateful for the opportunity to make my own contributions to the practice of software engineering.

Should you have an interest in any of this I can suggest a few starting points:

• The Project Apollo Archive
• Audio Files of the Apollo 11 Air - Ground Communications
• "Tales From The Lunar Module Guidance Computer"
• "Recovery from Transient Failures of the Apollo Guidance Computer"

_____
tags: embedded-systems|  software-development

A Touch of Grey

Recently, I have seen several articles on the aging population of engineers in the USA. This will likely require the development of some new rules for managing. But how can we find these rules?

I've been reading more and more articles about the aging population of engineers in the USA.

Recently, both David Anderson and Jack Ganssle have written about this. Jack provides some good data in his article while David's article contains an excellent challenge for all of us.

Quoting from David's article:

We need new management rules for old geeks (like me). These rules mean establishing processes to insure a good work life balance. Old geeks want their capacity to produce balanced against the demand from the business. They won't be death marched. They already regret missing out on their 20's. The gallus geek of yesteryear who talked disdainfully of process, carried his compiler in a holster slung low from his hips and treated management as the pointy haired boss to be ridiculed, now sees process as his friend and his boss as the facilitator of professional success balanced against the demands of real life.

The challenge for us managers is to give management a good name by putting in place lean processes that facilitate rather than hinder, that deliver productivity and work life balance, that lead to great code and healthy coders, that continue to delight customers without the all night code merges and death march schedules.

To which I say, "Amen, Brother!"

In my work with clients I see plenty of Dilbert cartoons posted on the cube walls of engineers and engineering managers. Many of these folks are in their 40's and up. I'm sure you have seen these comics too. They are pervasive.

Now, have you noticed that people who post these cartoons most often post them on the outside walls of their cubes? Presumably, if they enjoyed the cartoon a lot, they'd post it where it was easy for them to see. But more often than not, they post it outside their cube where they can't easily see it.

Why?

I believe it's because they're making a statement, albeit in a very low-key and oblique way. They're sharing a message with other members of the tribe. They have an idea.

At a minimum, their idea is "Let's not be like this." And, if you can engage them in a safe way, you will find out that they have many, many ideas.

These folks want change. The fire within them still burns. We can still reach them. It's not too late -- yet.

It's when they stop posting Dilbert cartoons that our already difficult jobs as managers (and yes, we are all managers, even if you think you are not) will become practically impossible.

So I believe we still have some hope, but also that we very little time to waste. What should we do?

I agree with David about the need for new rules. We do need new rules.

But if we develop these new rules via the same methodologies that we used to develop the current set of rules, how will the new rules be any better than the old rules?  Unless we have made some kind of "calculation error" in formulating the old rules, our new rules will be essentially identical to the old rules.

I'm going to suggest that the development of a new set of rules needs to be based on the development of a new level of understanding -- a new way of looking at the systems we are responsible for managing well.

One way to foster the development of this new understanding is to invest some time and effort in understanding systems-based improvement methodologies.  TOC is one such methodology; Lean is another.  Consider also the work in the area of System Dynamics.

Another way to foster the development of new rules is to identify and correct existing rules that are in somehow in conflict with the system's goal.  Rules that conflict with the system's goal "self-identify" and send out "signals" that we can detect.  But we must first have receivers that are capable of detecting these signals.  Today, these signals are almost always lost in the corporate background noise.

Finally, we should be prepared for the possibility that any new set of rules may result in lower system performance.  To me this implies that we have a set of operational measures that will help us judge the impact of the new rules.

All of these are interesting topics.  But they will have to wait for another day.  You see, I am also subject to a set of rules, those imposed by the lovely Mrs. Sambrook.  And Mrs. Sambrook says I have some work to do around the house.
_____
tags: management|  worklife

Twenty Science Attitudes

The Theory of Constraints isn't just about businesses and bottlenecks. The Theory of Constraints is also a set of core values based on beliefs about reality.

I came across this article a few years ago and was immediately struck by how closely it reflected my understanding of the core values of TOC.  I guess that's no surprise, as Eli Goldratt is a physicist by training.

I have been thinking that these twenty attitudes might be a good starting point for an introductory presentation on "What Is This Thing We Call The Theory of Constraints?"  I think it would help to show how TOC -- which can have a kind of cult-like flavor at times -- emphasizes these twenty science attitudes.
_____
tags: theory-of-constraints

Critical Chain Pilot Projects

Is it reasonable to consider evaluating Critical Chain via a pilot project? In this article I discuss a few of the issues that I believe can affect the integrity of Critical Chain pilot projects.

Following a link from the Critical Chain group on Yahoo, I recently started reading Jack Dahlgren's valuable blog as well surfing a bit on his website.

(In particular, you can find a Monte Carlo simulator for use with MS Project and Excel on his website.  I'm looking forward to evaluating this component for possible use on a side task.  Note also that the value of Monte Carlo simulation was recently beaten to death on the Critical Chain newsgroup as well.)

Jack and I are currently discussing whether it's useful to investigate Critical Chain via pilot projects, or whether one has to completely embrace Critical Chain in an all-or-nothing approach.  Said differently, how can we conduct a valid experiment with Critical Chain in our organizations?

I think Jack and I are on the same side of this issue, in that we both seem to agree that Critical Chain can be evaluated by pilot projects.

That being said, I believe there are a number of caveats that have to be considered in order for the pilot to be a generally valid indicator of what will happen when and if the use of Critical Chain is scaled up.

I also want to burn a few words on the question of wholesale adoption of TOC by the organization, but I'm going to put that in a different blog article, so please stay tuned.

I think David Laffineuse points to a valid concern in this article on the Critical Chain group.  I also found David's distinction between unit tests and system tests helpful in understanding his suggestion.

David points out that there is a risk that the pilot project is likely to be testing single-project Critical Chain.  While there can be real value in that, a test of single-project Critical Chain is not a test of multi-project Critical Chain.  So, even if the pilot is a success, there can still be surprises when the attempt to scale up to multi-project Critical Chain is made.

On the (excellent!) podcast that triggered my discussion with Jack, Allen Elder suggests that "Pilots don't work." I believe I understand Allen's reasoning, but I think there is an opportunity for some clarification as well.  Of course, I don't speak for Allen.

I believe Allen is suggesting that pilots don't work because we often cannot adequately separate one group of resources from another.  So, resources assigned to the pilot will likely be assigned to other projects as well, and because these two (or more) projects are being managed according to significantly different rules (different policies, measures and behaviors, or "PMBs") then this will necessarily affect the outcome of the pilot.

I think Allen is correct in this -- assuming I'm correctly interpreting his concern.  If you cannot arrange a pilot where the pilot team is able to follow the PMBs of Critical Chain -- which are hugely different from the PMBs of conventional project management -- then your pilot project is not really evaluating Critical Chain but something else.

However, as Jack suggests, I do think there are cases where the pilot project team could be sufficiently isolated from the other project teams such that they were able to follow the Critical Chain PMBs, rather than the existing PMBs of the organization.  But there first must be recognition that achieving this separation is critical to protecting the integrity of the pilot project as an experiment.

In my view what it all comes down to is doing good design of any experiment that purports to be an evaluation (a pilot) of Critical Chain.  With work, I think it's possible to design an experiment that is a "good enough" predictor of what will happen when and if Critical Chain is scaled up.  Without that work, I think the results could easily be misleading and could cause the organization to miss out on the significant value that Critical Chain offers to organizations doing project work.

The Picture Says It All

Sometimes, a picture is worth much more than a thousand words ...

I came across this picture on one of the Internet news services a while back.

If memory serves, this is a picture of a traffic jam in a city in China.  As you can see, no one is moving.

Now, why did I save this picture?

I saved it because it is -- for me -- evocative of how I view the projects in many organizations.  They are stuck in "traffic" and not moving anywhere near as quickly as they should be moving in order to create a decisive competitive edge for the company.

This is a system that could really benefit from a better set of controls on the amount of "work in process" in the system.  In a previous article I asked the question "Who's Controlling The Valve?"  In this system, no one, apparently.

The picture is also evocative from a software perspective.  As an embedded developer I have some experience with deadlock situations (sometimes, creating them, but more often, finding and fixing them) in computer code.  Deadlock issues can be difficult to debug.  A system can also have latent deadlocks that are not exposed until exactly the right set of circumstances arises.

From the picture, it's pretty clear that this situation is not far from a true deadlock.  All we need is a little more density in the inner circle and you'll have a real lock-up.

At any rate, I thought this picture was interesting and wanted to share it with you.  Don't be surprised if you see it again on some of my materials.  I think it's a keeper.

_____
tags: embedded-systems|  flow

Got Dashboard?

Would you buy a car that didn't have a dashboard? Would you fly on a plane that had no instruments? Probably not. I think that most of us agree that in order to manage a complex system, we need to know how that system is performing, and when it might be in trouble in some way. With the TOC Thinking Process tools, we can build dashboards for the systems we most care about.

Let's start from the following premise.

All systems are subject to certain necessary conditions. Airplanes have to maintain certain minimum airspeeds in order to continue flying. Businesses must have the cash required in order to pay their expenses. Family members must maintain certain levels of respect for each other in order that a peaceful, loving home can be established and then maintained.

When necessary conditions are not met, the system is at risk of