Kotter on leading change

John P. Kotter is a change guy. I've been going through his 1996 classic "Leading Change"

Here's my take: it's a good book, but a little long on the narrative since the essentials are right up front: 8 leadership steps towards change management.

Now, admittedly, this is more aimed at the business readiness swim lane, and the foreplay necesssary to get the business and the customer ready, than it is aimed at some of the change management tactics for scope control. Nevertheless, here's my paraphrase of Kotter's 8:

---

1. Put a value on short term versus long term
2. Gather a coalition of the willing
3. Develop the vision, goals, and strategy
4. Communicate
5. Push action to the practitioners
6. Be incremental
7. Consolidate gains
8. Leverage culture

---

Now, in Kotter's actual formulation for point #1, he wrote more about creating a sense of urgency than simply putting a value on the short term. But, actually, I'm not a fan of crying wolf on urgency just to get the team moving. Frankly, I'm more about finding a legitimate reason to value a short term goal; with that in hand, you should be able to get some action going.

His point about #5 was the ole "empowerment" thing. It was probably less worn in 1996 that it is 15 years later. The issue is that the empowered may not know how to use their power. That hasn't changed since power and empowerment were invented:

Those with the power have no experience

Those with the experience have no power

General Sir John Dill

Placentia Bay Conference, August 1941

I really like the last one about culture. We've mused on culture a few times here. Just click here to get a sense of where I'm coming from.

Bookmark this on Delicious

Pharma risk management

I don't often address industry-specific risks here at Musings, but an article about risks in the pharmaceutical industry caught my eye. Entitled "Risk Management for the Pharmaceutical Industry", it talks about the usual stuff, couched very nearly in PMBOK Chapter 11 vernacular of plans, identification and assessment, and risk responses. So, no news there.

But, given the life-safety issues of pharmaceutical projects, I thought this was a pretty good list:

A Risk Management Program starts with identifying the possible
risks (and benefits) associated with a product or with the process
used to develop, manufacture, and distribute the product. The following
questions should be asked at each stage of the product’s life cycle:

• What are the safety risks?
• Who is at the highest risk?
• What populations are at risk?
• Are the risks predictable?
• Are the risks preventable?

... an overall approach to RMP evaluation ideally would:

1. Select well-defined, validated metrics.

2. Use at least two different evaluation methods for key RMP goals
or objectives. Preferably, the different evaluation methods would be
both quantitative and representative to offset the biases that are intrinsic
to any single evaluation process.

3. Use qualitative data collected from a large and diverse group of
patients when quantitative data are either not available or not applicable
to the evaluation measurement. Qualitative data such as focus
group testing may be useful in assessing the effectiveness of education
and comprehension about safety and risk information.

4. Consider using evaluation methods to assess if each RMP tool is
performing as intended.

Now, it's point #2 that's worth a pause. There's no end of project management references to cognitive biases, the most compelling work done by Daniel Kahneman and Amos Tversky. And, there's wide acceptance of various estimating methods that use multiple estimators, like the Delphi method and its agile counterpart: planning poker. And, we all know the danger of the single point estimate: any single point is likely to be wrong, so better to estimate with multiple points in a range.

But, there's little literature that I've seen that recommends outright multiple methods to neutralize methodology bias: that's more aggressive than multiple evaluators. Multiple methods means approach the problem differently, and independently, and then see if a consensus can be reached on the risk.

This is sort of the RMP equivalent of having multiple contract designers work on a common requirement, each with their own methodology; no two independent designs will incorporate the same errors. So, when the two designs are applied against a common problem, it's not likely they will both experience an error at the same time. One or the other will always be successful.

It's conservative, it's expensive in the short run, but in the pharmaceutical domain, the long-term consequences of being wrong are too calamitous to put aside a short term expense.

Here's a nice lesson in risk and experiment evaluation using a pharmaceutical example from the Kahnacadey.org

Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

A. Hamilton on project management

Alexander Hamilton, one of America's founders, could have been one of the original thought leaders behind the governance of project management if he had been born a century and a half or so later.

Hamilton's main governing philosophy can be summed up in this simple idea:

---

Centralize goal setting and decentralize the means to accomplish them

---

Translated to project governance, Hamilton would have been in favor of a strong program office to set the rules and limitations of behavior, and to set the goals and vision of the larger ideas of the project, but at the same time he would have embraced a vigorous community of "do'ers" competing for the opportunity.

As a governance principle, Hamilton would oppose oversubscribing the powers and limitations of the program office, in the same he objected to the first ten amendments to the US constitution.

Instead of  writing many of the Federalist Papers that interpreted the constitution and gave rationale for many of its provisions, he might have written many of the supporting papers for the PMBOK and other project management standards. Perhaps he would be a modern day blogger.

Philosophically, he would support a professional cadre for project management. He made a distinction between the "consent of the governed" and governed by representatives. He felt that a professional group of governors would be required to master the complexity of a republican government, even as James Madison, another Federalist Papers author was concerned for scale and scalability of such a governance paradigm to a truly geo-distributed team (the States and the federal union)

Indeed, scale was on the mind of many. How do you convey a common culture, a common appreciation for the rule of governance (law), and a coordination of  seemingly independent actions such that there there is synergistic coherence towards the common goals?

In the United States, the importance of scale and integration was first grasped by Lincoln and his treasury secretary Salmon P. Chase as they approached a great war in 1861: the first problem was project funding--there was none. There wasn't even a national currency. So Lincoln and Chase, ever inventive as program managers, invented their own funding: they invented paper money and promised it was backed up by gold (it wasn't by the end of the war).

They invented creditor financing by selling war bonds, and they invented the supply chain on a national scale. They brought in new technologies and applied them to project execution for the first time: railroads for project mobility, and the telegraph for communications, earned value reporting, and marketing.

So, perhaps a rereading of the Federalist Papers as we put the finishing touches on V5 of the PMBOK might do us all a bit of good.

Photo: painting by John Trumbull, 1806

Bookmark this on Delicious

 

EBITDA?

Has everyone got a handle on EBITDA?

If not, in a few words, EBITDA is a measure of cash earnings from the real business, the day to day stuff that creates value for customers, users, and stakeholders: cash, as earnings, before any interest payments, taxes, or deductions for non-cash items like depreciation of tangile assets and amortization of intangibles.

---

Profit is an opinion; cash is a fact

---

Tom Pike

Fair enough. But since this a project management blog, why should we care?

Well, for one we PMs are in the value business; mostly we're in the earned value business. When the project is successful and earns its value, then it's ready for the business. The deliverables can go on to deliver on EBITDA.

What about NPV and EVA you ask? Haven't we PMs been told by CFOs that the way the business goes about measuring financial success in the business domain is with measures of discounted cash flow (DCF), like NPV (net present value) and EVA (economic value add). And, haven't we all seen the IRR (internal rate of return) calculations that demonstrate that this project can't miss (at least in terms of discount)?

I took up this very thing with a CFO in the private equity business with whom I've done business for many years, Steve McBrayer. He writes:

[Private equity] is ..." much more cash flow oriented than [publically traded businesses]. I think it is the nature of the private equity industry in general – Capitalism at its finest in my opinion – very investor focused.

• Our primary measure is EBITDA (basically a proxy for cash flow). Our focus is converting EBITDA into operating cash flow as efficiently as possible, while balancing the business needs (investments) against these demands.
• I like to see the business unit bonus program limited to about 5% of EBITDA (I don’t always get there, but that is a reference point)
• I use 10 % of EBITDA as my reference point for Cap-Ex (some business units get more if they have high growth potential and are more “value added” and some get less (for example a pure distribution business with little value add and lower growth prospects)
• At the end of the day, the primary responsibility of the CFO is to prioritize the various projects competing for the limited capital budget.  The valuation tools [EVA and NPV] ... are useful, but not the primary tool that I use...[which] is business judgment: does it make sense; who is responsible for the project; do I have confidence in them; is it critcal?

OMG! Business judgment: what will they think of next?

Bookmark this on Delicious

Teams (a mistake about a mistake)

Jurgen Appelo sometimes gets it wrong. In a recent blog post about teams, he asserts we're "making the same mistake all over" about teams and teamwork.

He writes this nonsense:

Teams are goal-oriented social units (Esther Derby’s definition). Their goal is not just to deliver a project.

• In an environment with continuous delivery and continuous improvement, it is very unclear what a “project” is! The concept of a “project” seems to me a convenient fiction that enables managers to spend budgets. That’s all.

I don’t know what the real goal of a team is. It depends on the team. But I do know that 3 people working together for only 2 months are probably not a team. They are just 3 people working together.

To that, I replied on his blog:

... you are wrong on all points: Esther's definition is wrong: that's the definition of a group, not a team A team is a higher order than a group, elevated by the collective and individual commitment to the goal. There is no personal success unless there is a collective success.

Yes, three months is quite enough time for a group to form into a team; what is required is intra-group trust to form, and for all three to be all in...one for all; all for one

Yes, a simple project is a project. What's a project? something with a specific start and end that delivers something of value to the customer. Yes, in the IT space, the transition to go-live and operations with follow-on bug fixes sometimes makes the "end" look a little murky, but that's management, not project definition.

For more on teams, read my book that you rated highly on your list of top 100: "Project Management the Agile Way,making it work in the enterprise."

Or, if you don't believe me, check out Glen Alleman's thinking on teams

Bookmark this on Delicious

Agile sailors

I recently gave a presentation to a PMI chapter on Agile project management using a sailing race analogy. I've used this analogy before, but this time there was some Q&A that was worth passing along.

 

The first thing is that audience was shocked (shocked!) to learn that agile projects have plans, and even more shocking that earned value concepts (that is: earning some value for the investment made) is also alive and well.

 

The second thing is that those from large companies lamented (I won't say complained because they didn't) that executive managers had little idea about the change in management paradigm that is the most pervasive aspect of agile. It's not the technical practices: those are largely like those in other software methodologies. But it's the change in management practices and thought that is different.

 

What's different?

• What's different is that best value is preferred over a fixed scope specification;
• what's different is that matrix management at the team level, sprint to sprint, must be put aside;
• what's different is that the team, in collaboration with someone holding the customer/users proxy has to be trusted to apply the available investment is the best possible way; and
• what's different is that the project manager manages to milestones that have user/customer/stakeholder value and not to the details of a networked CPM schedule.

 

Take a look and see if you don't agree

 

Agile for project managers - A presentation for PMI

View more presentations from John Goodpasture

Bookmark this on Delicious

Strategic planning v The Strategic Plan

Eisenhower once said: planning is everything; plans are nothing. He had in mind Von Moltke's famous statement: plans never survive first contact with the enemy.

And, although projects are not war, plans seem to suffer the same fate. Plans don't seem to survive the first touch with project reality, though perhaps project plans are a little more surviving than war plans.

In a recent post, "why small business should scrap strategic planning" we learn that small businesses can successfully do away with strategic plans altogether. They're too expensive, time consuming, and irrelevant to write and maintain.

Author Kaihan Krippendorff  says: "What fast-growing companies need is strategic thinking--not strategic planning". He offers three ideas for thinking:

1. Think in the hallway (casual conversations are sometimes very stimulating of new ideas; See A. Cockburn's osmotic communication)
2. Ask "why not" (this is probably the strategic adaption of the 'ask why 5 times' paradigm)
3. Try (something) and adjust (this is Franklin Roosevelt's "try something and if it doesn't work try something else, but don't just sit there" paradigm)

So, not exactly a paragon of original thinking, but perhaps there's something to Krippendorff's thesis, to wit:

• Too many strategic plans are just a three-year display of sales and market share... mostly a money plan and not a strategy per se, necessary but not sufficient
• Product road maps are closer to strategy if there's plan attached
• Three years may be too long for a small business; their horizon may be 6 months to some positive cash flow, or else
• And, if the product flops, do the Roosevelt thing. A lot of start-ups, like Group-on, start on Plan A but quickly shift to Plan B. The planning element "1" from the list above may be the best thing you've got. (Solyndra, anyone?)

But, in the end, Greg Githens told me: Where it’s weak: regardless of size, companies need a coherent strategy.  The article skips by that point.  Hustle and opportunism does not qualify as a competitive strategy.

Hmm...

Bookmark this on Delicious

Quiet (and the introvert thing)

The confluence of a couple of recent writings got me back on the "quiet" thing. One is the recent publication of the book "Quiet, the power of introverts in a world that can't stop talking" (which is much less about power and much more about it's ok to be an introvert) and an article about the architecture firm NBBJ that is promoting really open space office plans. One of their more recent engagements is the new home of the Bill and Melinda Gates Foundation for their 1000 or so employees.

Connecting the dots......

If you've ever taken the Myers-Briggs assessment, then you know a bit about the I's and E's (introverts and extroverts). The most profound thing I learned is that the I's are exhausted by interaction with people and need quiet isolation to recharge; the E's are just the opposite, exhausting themselves with quiet and needing people to recharge their batteries.

So, when I read about really open office plans with no cubes and no offices, I think first of the I's: what an exhausting day that's going to be. Then, I think of all the energy the E's will contribute.

Of course, many E's are closet I's. They have a professional E personality so they can compete in business (corollary: it's hard to be competitive with others if you've no working relationships with others, certain SME eccentrics excepted because we have to have them). The closet I's go home at the end of the day totally wasted; or after about 8-10 hours, there're not much good to anyone, including themselves.

On the other hand, I've been in a situation (for years) with an office I never used and an open plan I sat in so I could absorb the body language and other small stuff you can't get any other way. Alistair Cockburn calls this communication by osmosis (or osmotic communication).

And, I subscribe to the school that says that innovation is more likely to come out of colloboration than not. (Of course, one wonders about all the innovation that came out the Bell System Labs populated by all the I's with pocket protectors!). So, on balance, I think the I's (or professional E's) have to suck it up and be open!

Bookmark this on Delicious

Time zone bubbles

Sometimes, it's the simplest ideas that are the most effective. In the IT production control world, "bubble charts" are a common artifice to show the workflow of various scripts, user/operator interactions, and programs that have to run in sequence, or with dependencies, or a particular time (scheduler), or "on demand".

 

Fair enough, but no news there.

 

Then I read a blog post by agile guru Johanna Rothman about time zone bubble charts. So simple, but so effective as a communications device for the distributed team. It's a simple image, suitable for the war room or the background on some far flung work station.

 

 

 

Johanna offers six ideas for dealing with the myriad issues of time zones and teams. She writes:

1. Show the timezone bubble chart to your managers so they understand what you are attempting to manage.
2. Share the timezone bubble chart, so all the team members can participate in selecting planning and standup times.
3. Share the timezone pain. Do not make only one person or only one timezone delegate always arise early or stay late.
4. Know if everyone needs to participate.
5. Ask people if they will timeshift. Make sure you ask in advance, so people can make arrangements for their personal lives.
6. Make sure people either have necessary bandwidth to participate at home or food and beds to participate at work, if they need to participate outside of normal work hours.

 

My experience was [India west coast (UTC +5:30)] to [US East coast (UTC -5)]. That's 10:30 hours difference in time, and not all that uncommon among software teams.

 

Here's what we did:

• Dedicated phone room with open line for about 4-6 hours per day (anyone could walk in and talk or set up an offline conference)
• Time shift (mostly by the India workers)
• Alternate early/late conferences so that both US and India shared the inconvenience
• Real-time document sharing via shared resources
• Teleconferences by video on a case by case basis. (We didn't have Skype or Facetime at the time)
• More care with documentation to compensate for ESL (English as second language)

Hey! you can make it work
Bookmark this on Delicious

Road warriors

I've put in my time as a road warrior. Around the world on PANAM 1; 2 1/2 million miles domestically; and a lot of hotel nights. But, my experience is dated.

In a recent article on the changing accessories in business hotel accommodations we learn that "wireless is like air" to the millennials that are now part of the travelling business crowd.

But beyond a charging station at every chair and wall-to-wall wireless, we hear that iPads are now offered in every room, replacing conventional controls for lights and environment, but also serving up the morning paper.

The old days of carrying a case of dial-up phone connectors and adapters is sure a long way into the history books. But, some millennials were hardly born when that was de facto standard.

My own experience is similar: This summer, while on vacation along the Maine coast, I was simultaneously teaching an e-course, keeping up with student emails on a smart phone, and posting lesson commentary on a laptop by night.  (My observation of this work-play: not for those without an accomodating spouse)

Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Six risk practices

Pantelis Filippidis wrote this in reply to a question in my Risk Management class

Regarding risk management I have found the following techniques effective;
(1) For planning RM: Review lessons learnt & records from previous projects, and get advices from more expert team members
(2) For risk identification: Risk Breakdown Structure (RBS), Risk Assessment Questionnaire, Brainstorming, Delphi, setting up subject-matter expert team, and lessons learnt & records from previous projects
(3) For Qualitative Risk Analysis: Probability & Impact matrix using only 3 level “high” / “medium” / “low”
(4) For Quantitative Risk Analysis: Failure Mode, Effects and Criticality Analysis (FMECA - an extension of failure mode and effects analysis (FMEA)), past records, and expert judgment.
(5) Risk response planning: lessons learnt & records from previous projects, subject-matter expert team.
(6) Risk Monitor & Control: watch-list of high/medium risks, subject-matter expert team meetings
The main success factor was the early identification of major risks and correct risk cost & time impact estimation

Elsewhere, we learn that the risk questionaire is along these lines:

The use of a Risk Assessment Questionnaire - The questionnaire encompasses 6 key areas: Clarity of Expections, Cost, Schedule, Client relationship and Impact, Resources, and solution complexity. The outcome of this questionnaire is to initiate action towards increase communication in the problem areas and mitigation strategies

Of course, right of the blocks, practice (1) that invokes lessons learned and project records presumes a certain maturity, discipline, and commitment to the forward use of such materials on the part of the project office. We could all wish it were true more often than it is.

The questionaire, if made a routine part of the project plan, goes a long way toward setting the table for risk management. I salute that idea!

Bookmark this on Delicious

The risk matrix (again)

In 1711 Abraham De Moivre came up with the mathematical definition of risk as:

The Risk of losing any sum is the reverse of Expectation; and the true measure of it is, the product of the Sum adventured multiplied by the Probability of the Loss.

Abraham de Moivre, De Mensura Sortis, 1711 in the Ph. Trans. of the Royal Society

I copied this quote from a well argued posting by Matthew Squair on Dark Matter entitled Working the Risk Matrix.  His subtitle is a little more high brow: "Applying decision theory to the qualitative and subjective estimation of risk"

His thesis is sensible to those that really understand that really understanding risk events is dubious at best:

For new systems we generally do not have statistical data .... and high consequence events are (usually) quite rare leaving us with a paucity of information.

So we end up arguing our .... case using low base rate data, and in the final analysis we usually fall back on some form of subjective (and qualitative) risk assessment.

The risk matrix was developed to guide this type of risk assessments, it’s actually based on decision theory, De’Moivres definition of risk and the principles of the iso-risk contour

Well, I've given you De’Moivres definition of risk in the opening to this posting. What then is an iso-risk contour?

Definitions:
"iso" from the Greek, meaning "equal"
"contour", typically referring to a plotted line (or curve) meaning all points on the line are equal. A common usage is 'contour map' which is a mapping of equal elevation lines.

So, iso-risk contours are lines on a risk mapping where all the risk values are the same.

Fair enough. What's next?

Enter: decision theorists. These guys provide the methodology for constructing the familiar risk matrix (or grid) that is dimensioned impact by probability. The decision guys recognized that unless you "zone" or compartmentalize or stratify the impacts and probabilities it's very hard to draw any conclusions or obtain guidance for management. Thus, rather than lists or other means, we have the familiar grid.

Each grid value, like High-Low, can be a point on a curve (curve is a generalization of line that has the connotation of straight line), but Low-High is also a point on the same curve. Notice we're sticking with qualitative values for now.

However, we can assign arbitrary numeric scales so long as we define the scale. The absence of definition is the achilles heel of most risk matrix presentations that purport to be quantitative. And, these are scales simply for presentation, so they are relative not absolute.

So for example, we can define High as being 100 times more of an impact than Low without the hazard of an uncalibrated guess as to what the absolute impact is.

If you then plot the risk grid using Log Log scaling, the iso-contours will be straight lines. How convenient! Of course, it's been a while since I've had log log paper in my desk. Thus, the common depiction is linear scales and curved iso-lines.

Using the lines, you can make management decisions to ignore risks on one side of the line and address risks on the other.

There are two common problems with risk matrix practices:

1. What do you do with the so-called "bury the needle" low probability events (I didn't use 'black swan' here) that don' fit on a reasonably sized matix (who needs 10K to 1 odds on their matix?)
2. How do you calibrate the thing if you wanted to?

 For "1", where either the standard that governs the risk grid or common sense places an upper bound on the grid, the extreme outliers are best handled on a separate lists dedicated to cautious 360 situational awareness

For "2", pick a grid point, perhaps a Medium-Medium point, that is amenable to benchmarking. A credible benchmark will then "anchor" the grid. Being cautious of "anchor bias" (See: Kahneman and Tversky), one then places other risk events in context with the anchor.

If you've read this far, it's time to go.

Bookmark this on Delicious

A brief history of scheduling

Patrick Weaver gave a talk at Primavera06 about the history of scheduling. His talk is captured in an interesting paper: "A brief history of scheduling: back to the future"

Patrick is somewhat of a historian and prognosticator on matter such as these. He also has written:

• The Origins of Modern Project Management: www.mosaicprojects.com.au/Resources_Papers_050.html
• ‘Trends In Modern Project Management - Past Present & Future’www.mosaicprojects.com.au/Resources_Papers_061.html
• ‘Seeing The Road Ahead – The art of presenting schedule data effectively’www.mosaicprojects.com.au/Resources_Papers_106.html   

So, what is the history of scheduling? I certainly remember the days of yester-year before MSProject and its adult cousin Primavera; I remember when the only scheduling tool I had was graph paper, and I remember when the mainframe scheduling tools began to replace hand-drawn bar chart schedules and simple networks.

Weaver writes:

Modern schedule control tools can trace their origins to 1765. The originator of the ‘bar chart’ appears to be Joseph Priestley (England, 1733-1804); his ‘Chart of Biography’ plotted some 2000 famous lifetimes on a time scaled chart “…a longer or a shorter space of time may be most commodiously and advantageously represented by a longer or a shorter line.”

Priestley’s ideas were picked up by William Playfair (1759-1823) in his ‘Commercial and Political Atlas’ of 1786. Playfair is credited with developing a range of statistical charts including the line, bar (histogram), and pie charts

We learn these additional nuggets:

• The science of ‘scheduling’ as defined by Critical Path Analysis (CPA) celebrated its 50th Anniversary in 2007.
• In 1956/57 Kelly and Walker started developing the algorithms that became the ‘Activity-on-Arrow’ or ADM scheduling methodology for DuPont.
• The PERT system was developed at around the same time for the US Navy's Polaris missile program 
• PERT lagged CPM (Critical Path Analysis) by 6 to 12 months (although the term ‘critical path’ was invented by the PERT team).
• Later the Precedence (PDM) methodology was developed by Dr. John Fondahl; his seminal paper was published in 1961 describing PDM as a ‘non-computer’ alternative to CPM.

Of course, one of the most profound developments was the arrival and market penetration of the low cost PC-based personal scheduling tools like MSProject. In Weaver's view that made schedulers out of everyone, but everyone is not a scheduler, or can even spell the word.

In my personal opinion, the integration of Monte Carlo tools with low cost scheduling applications like MSProject was equally profound. The MC simulation "fixes" some of the most egregious problems with PERT and the simulation idea has largely run PERT into obsolescence. The main thing that PERT does not handle well is schedule joins or merge, and the statistical merge bias that goes with it.

On the dark side, MSProject has profoundly muddled the whole idea of the WBS. The fact that one of the fields in MSP is called "WBS" is most unfortunate. There are a whole generation of project analysts who believe they created a WBS by the simple act of making that field visible. Not so: schedule is the "verbs" of the project; WBS is the "nouns". Together, WBS + schedule = project narrative.

Now, in Weaver's view, we return to the future:

The changing role of the scheduler has been almost as interesting:
• The mainframe era saw scheduling as:

• o A skilled profession
• o Central to the success of projects

• Then came the PCs…… everyone and no-one was a ‘scheduler’ in the 1980s and 90s
• However, in the 21st century, the new ‘enterprise’ era sees scheduling as:

• o A skilled profession
• o Central to the success of projects

Bookmark this on Delicious

The Mann-gulch tragedy

The Mann-Gulch tragedy has been told many times. There are books and essays in abundance that tell about the 1949 forest fire in Montana that turned deadly.

One telling I like is in the book "How We Decide" by Jonah Lehrer.

In a few words, a fire team was caught when the fire suddenly turned and became an out of control conflagration. The team was led by an experienced fire fighter, but he was new to the team. When push came to shove, the team abandoned their new and untrusted leader and tried to make their own way. They all died.

The team leader and a couple of others improvised a heretofore unheard of practice: they set a backfire and hid in it, using their fire protection clothing and tools, accepting the lesser of two evils. They survived.

There are three stories within the Mann Gulch story:
1. A story of change: the fire suddenly changed character making known process, methods, and plans instantly obsolete
2. A story of trust and leadership: trust had not gelled between the relatively new leader and the fire team
3. A story of improvised methods driven by extreme need

Here are a few comments on point 2:

The Mann Gulch story is a poster child for unquestioning obedience to command, and the principle of command autonomy, perhaps more so than leader-follower which is different.

In life-safety situations, to include life-safety projects where failure is not an option, certain protocols need to be in place before hand. They must be practiced to the point of so-called system-1 "fast thinking" (See Daniel Kahneman, "Thinking Fast, Thinking Slow"), and embedded in the organization's culture.

At the moment of the event is too late to develop the intuition and trust. (Similar intuitive thinking examinations are in Malcolm Gladwell's "Blink")

Whether fueling the space shuttle, working in a level IV bio-hazard lab, leading a first responder team, or engaged in a military firefight, command must be unambiguous, and expected to change in an instant with the loss of the commander. Thus, obedience must transfer instantly to the new commander.

Many leader-follower scenarios are described as the followers giving permission to the leader to lead so long as the followers are satisfied. Effective in some situations, it will get people killed in a Mann-Gulch project.Thus, we make a clear distinction between command-obedience systems and leader-follower systems.

An excellent text on leadership is "Leadership without easy answers" by Ronald Heifetz

There are, of course, exceptions with prejudice to command-obedience. In military situations, this is called mutiny. Sometimes, mutiny is justified. Two fictional accounts illustrate the point well: "The Caine Mutiny", a story of a warship in danger of floundering in a hurricane; and "Crimson Tide", the story of a violation of nuclear launch code protocols.

On the bridge of the Caine, in the midst of "Halsey's Typhoon", in the Pacific in 1944, the captain is panicked and making life-threatening decisions. The XO mutiny's, takes countermeasures, and saves the ship.

On the bridge of the submarine, USS Alabama "Crimson Tide", the captain violates launch protocols; again the XO mutiny's, takes countermeasures, and in a courts martial, he is exonerated.

Bookmark this on Delicious