Leadership the Admiral's way

---

Nearly 10 years on, it doesn't get old -- or obsolete:

In the November 2010 issue of the Harvard Business Review, there is an interview with Admiral Thad Allen, the retired Coast Guard commandant and the former "National Incident Commander" for the Gulf oil spill of 2010.

Entitled "You have to lead from everywhere", it's a good read for those interested in how an experienced manager with a proven track record approaches different situations under different degrees of urgency and stress.

Interviewer Scott Berinato took the title from a reply Allen made to the question: "In a major crises...do you think it's more important to lead from the front or from the back?", to which Allen replied: "You have to lead from everywhere".

Mental models
Here's the point that struck me: Allen says he approaches every assignment with a number of different mental models of how command might be exercised....Allen is an admirer of Peter Senge, noted MIT advocate of mental models....and may change models as events unfold.  In many situations he has faced, he states that the chain of command model simply doesn't exist!

OMG! No chain of command?!

What he's saying is that in some situations there is no single manager is in charge.

OMG! No one in charge?!

But, Allen can work this way and make it effective. He calls for "unity of effort" rather than "unity of command"

Unity of Effort vs Unity of Command
Allen makes a very interesting distinction in those cases where the organizational model simply does not converge....parallel lines rather than a pyramid, or multiple pyramids with a loosely layered level of federation and coordination:

In what I would call a “whole of government response”—to a hurricane, an oil spill, no matter what it is—that chain of command doesn’t exist. You have to aggregate everybody’s capabilities to achieve a single purpose, taking into account the fact that they have distinct authorities and responsibilities. That’s creating unity of effort rather than unity of command, and it’s a much more complex management challenge.

Admiral Thad Allen, USCG [Retired]

Program management lesson
So, what's the program management lesson here? Well, of course, the lesson is right in the word 'program' that implies multiple projects ostensibly working toward a common objective.

And, of course, the objective may change, forced by unforeseen events.

And if some of the effort is in the government, and some is in contractors and NGO's, and even within the government there are state and federal, or USA and ROW, there's a lot to be learned by studying the methods Allen has championed.

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Agile and Plan-Do-Check-Act

---

This is not as stuffy as it sounds:

Plan-Do Check-Act --

• Plan-do-check-act (PDCA) envisions planning--just enough, and gasp! perhaps an estimate as well--for what is to be done, then doing it—that is the plan-do.
• Next, measure results—measuring is the check activity (did someone say: accountability?)—and
• Then act on the measurement results. To act in the PDCA sense means to reflect upon lessons learned and provide feedback for corrective actions to the next iteration of the plan.

Seems intuitive, of course, but in its written form, perhaps only 70 years old (only!) W. Edwards Deming gets most of the credit. Deming--working in Japan and else where in the mid-20th century--introduced very practical ideas of process control as a means to limit variations in product quality.

And, who's not all about product quality?

Deming was a product guy; he came at product quality from the point of view of the product:

Make the product the same way each time and make it work within limits that are acceptable to the customer. But, developing software is not a repetitive cycle (make it the same way each time) although processes are repetitive and they can be somewhat the same quality each time.

The modern poster child for defined process control is Six Sigma, but let's not go there; let's go to Agile

Agile Thinking

Ken Schwaber—a leading SCRUM methodologist—objecting to defined process control, puts it this way, “[defined process control] is based on processes that work only because their degree of imprecision is acceptable… When defined process control cannot be achieved because of the complexity of the intermediate activities; something called empirical process control has to be employed.”

In Schwaber’s view, software is too complex to expect defects to be contained within predefined error limits. Empirical control is the answer; empirical control is derived from observed facts, adapted to the situation, and not determined by preplanned limits from previous projects.

Edwards Deming's impact on agile projects
A project management tip: Deming introduced the PDCA cycle, which is can be wholly embraced by agile teams
• The cycle really applies to all agile iterations. The plan-do is equivalent to the planning session followed by development, test, and integration.
• Especially relevant is the check-act that provides measurement and feedback for continuous improvement.
• Deming focused on eliminating unsatisfactory results before they reached the customer. In agile parlance, every object must pass its unit, functional, and system test, and be acceptable to the customer's idea of quality in the large sense: function, accuracy, available, and appealing

Read my contribution to the Flashblog

Of myth and mystique

---

I've always held that the key to power and influence is to have and maintain a certain mystique that provides some remoteness ( think: access control ), unpredictability, and mystery about the leader. (Too much familiarity reveals too many weaknesses, etc)

Now comes myth, to add to the mystique:

"In theory, if some holy book [perhaps the body-of-knowledge of the PMO] misrepresented reality, its disciples would sooner or later discover this, and the text’s authority would be undermined. Abraham Lincoln said you cannot deceive everybody all the time.

Well, that’s wishful thinking. In practice, the power of human cooperation networks depends on a delicate balance between truth and fiction. If you distort reality too much, it will weaken you, and you will not be able to compete against more clear-sighted rivals.

On the other hand, you cannot organise masses of people effectively without relying on some fictional myths. So if you stick to unalloyed reality, without mixing any fiction with it, few people will follow you. "

"Homo Deus: A Brief History of Tomorrow" 

by Yuval Noah Harari

Hmmm -- sounds like he's talking about the messaging required to motivate; the justification for certain means to achieve ends; and the fact that the truth -- unvarnished -- maybe unattractive. But, beware: as Harari says it's a delicate balance, with risk as the balancing element. Too much fiction, and you're not credible

But, consider this also from Mr Harari:

"... creating stable human hierarchies and mass-cooperation networks [is possible] as long as people believe [in the myth]

All large-scale human cooperation is ultimately based on our belief in imagined orders.

These are sets of rules that, despite existing only in our imagination, we believe to be as real and inviolable as gravity ..... making it easy to predict the behaviour of strangers and to organise mass-cooperation networks."

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

All all PMs capitalists?

---

Capitalism is not as popular as it once was. Nonetheless, it's still relevant.

We ask:
Are PMs all capitalists? Should we be? We could be: we work for money, and we spend other people's money (OPM) to drive outcomes, reaching for "success" all the time, and fearful of failure (consequence: we may not get another chance to be the leader)

But, do we have a conscience? Do we care what we are working on? If we were asked to build the first "bomb" would we do it for the science and engineering, and leave the policy and philosophy to others?

I've certainly had friends who've "opted out" of some programs. When I worked in the US DoD as a program manager, there things that gave me pause. Likely, most of us have paused at the juncture of capitalism and society at large.

McKinsey has a post on more or less this topic. Here's a thought that goes to the PM business:

Human creativity develops a variety of ways to solve ... problems, but some inevitably work better than others, and we need a process for sorting the wheat from the chaff. We also need a process for making good solutions widely available.

Capitalism is the mechanism by which these processes occur. It provides incentives for millions of problem-solving experiments to occur every day, provides competition to select the best solutions, and provides incentives and mechanisms for scaling up and making the best solutions available.

Meanwhile, it scales down or eliminates less successful ones. The great economist Joseph Schumpeter called this evolutionary process “creative destruction.”

The orthodox economic view holds that capitalism works because it is efficient. But in reality, capitalism’s great strength is its problem-solving creativity and effectiveness. [emphasis added] It is this creative effectiveness that by necessity makes it hugely inefficient and, like all evolutionary processes, inherently wasteful.

Capitalism inevitably leads to the dichotomy of "win-win" or "win-lose": Solve everyone's problems, but each less optimally; or solve one problem optimally and let the others suffer. Classic game theory! (See Chapter 12 of my latest book on Maximizing Project Value").

Clearly, as PMs we don't relish "pulling our punch" and serving up the less optimum knowingly.

McKinsey -- somewhat unhelpfully -- leaves us with this issue but no real solution:

.... the solutions capitalism produces are what creates real prosperity in people’s lives, and that the rate at which we create solutions is true economic growth, .... entrepreneurs and business leaders bear a major part of both the credit and the responsibility for creating societal prosperity.

But standard measures of business’s contribution—profits, growth rates, and shareholder value—are poor proxies. Businesses contribute to society by creating and making available products and services that improve people’s lives in tangible ways, while simultaneously providing employment that enables people to afford the products and services of other businesses. It sounds basic, and it is, but our economic theories and metrics don’t frame things this way

Here's another way to frame this that is familiar to PMs who read this blog: the focus of projects should be on outcomes first, inputs (like cost, schedule, specifications, shareholder value etc) second.

As "outcomists" we can be cognizant of the larger landscape. As "inputists" we can be responsible for being good stewards of resources. But, outcome dominates input... in my opinion.

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

"Off the cuff" is a better style

---

Every project manager speaks to groups in public... it goes with the territory. But, what happens if someone drops in unexpectedly and an off the cuff briefing or speech or speaking opportunity portends?

If this is not your strong suit, here's some worthy advice from John Coleman writing at the hbr.org network blog:

1. Define a structure: The pressure of extemporaneous remarks comes from their ambiguity. What do I say? What do I not say? The worst and most stressful business speeches are those that ramble without purpose. In forensics we’d tackle this issue by quickly drafting a structure on a note card to support our main point — often an introduction, two or three supporting points, and a conclusion.

2. Put the punchline first: When I worked in consulting, one of the cardinal rules of communication was “punchline first.” Any presentation should have a clear thesis stated up front so that listeners can easily follow and interpret the comments that follow.

3. Remember your audience: All it takes is a few lines to make an audience feel acknowledged and a speech feel fresh. Tie the city in which you are speaking into your introduction. Draw parallels between the organization you’re addressing and one of the stories you tell. Mention someone by name, connecting them to the comments you’re offering.

4. Memorize what to say, not how to say it: How many times have you practiced exactly how to say something in your head then frozen up or completely forgotten in the moment? The trick was this: We’d focus on memorizing key stories and statistics, rather than practicing our delivery. If you spend your time on how to say something perfectly, you’ll stumble through those phrasings

5. Keep it short: Blaise Pascal once famously commented, “I have only made this letter rather long because I have not had time to make it shorter.” While it seems like the challenge of speaking with limited preparation would be finding enough to say, the opposite is often true. When at a loss for words, many of us underestimate the time we need — cramming in so many stories and points that we run well over our time and dilute our message. No one will appreciate your economy of words more than your listeners, so when in doubt, say less.

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Some "$10 words" in Risk Management

---

When you get into risk management a bit, there are some biggies that get thrown around -- I call them $10 words -- and there are two that more or less divide risk management along the lines of

1. The unknown that is possibly knowable with some legwork
2. The unknown that is likely to remain unknowable

First case
For the first case, this is all about knowledge, the nature of knowledge, and how better to improve knowledge. Generally, this is called "epistemology" (ka-ching: $10 please) -- understanding the nature and scope of knowledge.

Risks that are subject to a better understanding by simply (I say simply, but often it's not simple) digging out more information are called "epistemic risks"

More simply yet, epistemic risks are those you can do something about -- they are actionable by nature of greater understanding and knowledge development.

In other words, epistemic risks are those for which the uncertainty can reduced -- if you spend the money to try.

And here's another opportunity to make $10: epistemic risks can be set in an organized framework of knowledge, said knowledge frameworks are called ontologies, and so epistemic risks are sometimes called ontological risks (OMG! this just gets better and better)

Second case
For the second case, it's all about the hidden, latent, unknowable (you may not find out what you don't know to ask, etc) that just happens by chance. For example, games of chance, like dice, you simply have no way of knowing what is going to come up next. There's no question you can ask to find out. And, the games are "memoryless" and thus independent; the former outcome has no bearing -- seemingly -- on the next outcome.

Such risks are called aleatoric risks, from the word aleatory meaning "related to random choice or outcome"

The good news, if there is any, is that aleatoric risks have probability distributions that is quantitative description of their random outcomes. If you can discover something about the distribution, you have something to work with re mitigating effects.

Operationally, you can't really reduce the uncertainty surrounding aleatoric risks, but you can immunize your project to the random or chance outcomes -- within limits of course -- by providing slack, buffers, redundancy, loose coupling, etc. In other words, to make the project less fragile and susceptible to the shock of a such a risk outcome.

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Fixed price contracting and Agile

---

In my book, Project Management the Agile Way, now in its 2nd Edition, I make this statement in the chapter on contracts:

Firm Fixed Price (FFP) completion contracts are inappropriate for contracting agile.

I got an email from a reader challenging that assertion, to which  responded:

I always start by asserting that agile is a "fixed price" methodology. But, there is a big difference between a contract for your best effort at a fixed price, and a fixed price contract for working product, to wit: completion (agile manifesto objective)

There's no problem whatsoever in conveying best effort at fixed price through a contract mechanism; it's quite another thing to convey fixed price for a working product.

Agile is a methodology that honors the  plan-driven case for strategic intent and business value; but agile is also a methodology that is tactically changeable -- thus emergent in character -- re interpretation of the plan.

Using the definition that strategic intent is the intended discriminating difference to be attained in the "far" future that has business value, a project can be chartered to develop the product drivers for that discriminating difference. Thus,  think of agile as iterative tactically, and plan-driven strategically. The sponsor has control of the strategy; the customer has control of many of tactics.

Re FFP specifically, I was aiming my arguments primarily at the public sector community, and particularly the US federal acquisition protocols. The public sector -- federal or otherwise -- usually goes to a great deal of trouble to carefully prescribe contract relationships, and the means to monitor and control scope, cost, and schedule.

In particular, in the federal sector, only the "contracting officer" -- who is a legal person usually -- has the authority to accept a change in the written description of scope, a change in the cost obligated, or a change in the delivery schedule and location. The CO ordinarily has one or more official "representatives" (CORs) or technical representatives (COTRS) that are empowered to "interpret" changes, etc,

In the commercial business domain, the concepts of contract protocols are usually much more relaxed, starting with the whole concept of a CO and COR -- many businesses simply don't have a CO at all... just an executive that is empowered to sign a PO or a contract. Thus, there are many flexibilities afforded in the private sector not available to public sector

When I say "fixed price", in effect I am saying "not cost reimbursable". Cost reimbursable is quite common in science and technology contracts in the public sector, but almost never in the "IT" sector, public or private. So, I find that many IT execs have little understanding why you might write a contract for a contractor to take your money and not pledge completion.

Working from the perspective of "not cost reimbursable",  I make the point about a FFP completion contract as distinct from other forms of fixed price arrangements, like best effort. In my opinion, agile is not an appropriate methodology for a completion contract in the way in which I use the term, to wit: Pass me the money and I will "complete the work" you describe in the contract when we sign the deal.

However,  there are FP alternatives for a traditional completion effort, the best of the lot in my opinion being a FP framework within which each iteration being a separate and negotiated fixed scope and fixed price job order wherein the job order backlog is planned case by case.

However, even in such a JO arrangement, the customer is "not allowed" to trade or manage the backlog in such a way that the business case for the strategic value is compromised. The project narrative must be "stationary" (invariant to time or location of observation); although the JO nuts and bolts can be emergent.

Typically if the agile principle of persistent team structure is being followed, where the team metrics for throughput (velocity x time) are benchmarked, then the cost of a JO is almost the same every time -- plus or minus a SME or special tool -- and thus the "price" of the contract is "fixed" simply by limiting the number of JOs what will fit within the cost ceiling.

There are other factors which are vexing in the public sector in a FP contract arrangement:
1. Agile promotes a shift in allegiance from the specification being dominant to the customer needs/wants/priorities being dominate. Try telling a CO you are not going to honor the spec as the first precedence!

2. Following on from a shift in allegiance, what then is the contractual definition of "done". Is the project done when the money runs out (best effort); when the backlog is exhausted (all requirements satisfied); or the customer simply says "I've got what I want"? This debate drives the COs nuts.

3. How does a COTR verify and validate (V and V)? In the federal sector, V and V is almost a religion. But, what's to be validated? Typically, verify means everything that is supposed to be delivered got delivered; validated means it meets the quality standard of fitness for use. If the scope is continuously variable, what's to be verified? What do you tell the CO?

4. Can the "grand bargain" be contracted? I suggest a "grand bargain" between sponsor and PM (with customer's needs in the frame) wherein for a fixed investment and usually a fixed time frame the PM is charged with delivering the best value possible.

Best value is defined as the maximum scope (feature/function/performance) possible that conforms to the customer's urgency/need/want as determined iteratively (somewhat on the fly). Thus requirements are allowed to be driven (dependent) by customer's direction of urgency/need/want and available cost and schedule (independent).

Where the customer doesn't usually get a vote is on the non-functional requirements, especially those required to maintain certifications (like SEI level or ISO), compliance to certain regulations (particularly in safety, or some finance (SOx)), or certain internal standards (engineering or architecture)

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog