C-C-C

---

"They" say the first three rules of agile are:

1. Communicate
2. Communicate
3. Communicate

But, perhaps these three are better:

1. Collaborate
2. Communicate
3. Collaborate

Better? How so?

Although the best communication is bi-directional (because closed loop systems---listen.talk.listen--- are more predictable, and more likely to produce results that are faithful with intention), too often communcation is one way. And to merely say: Communicate! may well miss the whole point which is to both inform and to impart influence. After all, if you can't influence those you are communicating to, what is the point?

So, the collaborate-communicate-collaborate model is intended to convey influence:

• First, you draw your audience into the issue; (they might have a good idea)
• Then, you provide the message; (somebody has to come to a conclusion) and finally
• Test for impact, effectiveness, accuracy with follow-up collaboration

Of course, this model is prone to be degenerative to the communicate-communicate-communicate:

• Too little time to collaborate (urgency, importance)
• Too disparate an audience spread over hill and dale (language, time of day, access)
• No way to gather and process feedback from collaboration (volume, content, process)
• Autocratic outlook (my way or the highway, and I'm in charge anyway)
• Egocentric confidence (father knows best, and you couldn't possibly know)

SUMMARIZING:

---

Bookmark this on Delicious

A quote for the day

---

On projects, project management, and project success, we've been intrigued by this idea:

If the customer is not satisfied, he may not want to pay ..... If the customer is not successful, he may not be able to pay. If he is not more successful than he already was, why should he pay?

Niels Malotaux

---

Bookmark this on Delicious

Anchoring Mr Bayes

---

Anchor bias has been well described:

• Somebody sets an anchor (an initial estimate, or a desired outcome)
• You evaluate the anchor value (you didn't set the anchor, you evaluate whether it's a good thing)
• You make an adjustment if you decide the anchor value is a bit off

That is the way Tversky and Kahneman described it. Of course, in the real world, one adjustment may not do it:

• You might have to reevaluate the new adjustment in light of circumstances
• Perhaps another adjustment before declaring victory!

(By the way, who sets these anchors? In the project world, beware the anchors set by the sales or marketing staff! They always want it below the cost of the competition)

In a similar situation here's the way Thomas Bayes described it:

• Somebody makes an educated guess--call it a hypothesis--of what an initial outcome might be, and its probability
• You run an experiment, model, prototype, or some analytic process to get real data to see if it conforms to the educated guess
• If yes, you accept the initial guess as the anchor; if not, you make an adjustment of the hypothesis so the adjusted guess now conforms to the data; now the initial guess is more than a guess since there is data to back it up.

Of course, in the real world, one adjustment of the initial guess may not do it:

• You might have to run the experiment a few times in light of circumstances
• Perhaps you refine the hypothesis a few more times before declaring victory!

Now, in the modern vernacular, the initial guess is called the 'a priori' hypothesis and the improved guess based on actual data is call the posterior hypothesis. And, if you iterate, the posterior from the prior iteration becomes the a priori for the next iteration. And, around we go, improving the hypothesis with real data

So, both working with an anchor and working with the theorems of Thomas Bayes are very nearly the same thing. How convenient, since there is a lot of background and backup for Bayes and the work of others that came after him (He was a 18th century guy)

And, this is nice since for many projects, a guess is all we have to get started with. It's nice to see that folks have thought ahead how to work a genuine guess into something calibrated.

To see how this works in the real world with a rich description of many projects, check out and read:
"The theory that would not die" by Sharon Bertsch.  It's a great read for anyone managing under uncertainty.

---

Bookmark this on Delicious

Leadership v Management

---

What is leadership? What is management? Is one more superior than the other?

John P. Kotter has been a leading industry researcher on these questions. In a paper he wrote in 1990 he tells us this:

...leadership and management are two distinctive and complementary systems of action. Each has its own function and characteristic activities. Both are necessary for success ....

The Difference Between Management and Leadership

Management is about coping with complexity. ...Without good management, complex enterprises tend to become chaotic in ways that threaten their very existence. Good management brings a degree of order and consistency to key dimensions like the quality and profitability of products.


Leadership, by contrast, is about coping with change. ... Faster technological change, greater international competition, the deregulation of markets, overcapacity in capital-intensive industries, an unstable oil cartel, raiders with junk bonds, and the changing demographics of the work-force are among the many factors that have contributed to this shift. ... More change always demands more leadership.

"Systems of action"...I really do like that sentiment

Of course, no good thought goes unchallenged, so here's mine:

"Coping with change" and "coping with complexity" sound a bit weak to me. In fact, I'm not sure 'coping' sounds very leaderly or managerial.

For the change thing, a more agresssive idea might be 'making change work for the enterprise instead of against it'. And, to make that happen, you're going to need a big dollop of management to plan, measure, monitor, and direct resources

For complexity, how about resist complexity in favor of the simplest possible? (though that might actually be pretty complex)

Of course, Kotter is the expert here. I take his points even if I quible at the tone. Leadership and management are systems of action, so I'll end on that idea

---

Bookmark this on Delicious

Surveillance mode for decision makers

---

Decision makers often operate in a surveillance mode rather than a problem solving mode

--James G. March

I was recently rereading James G. March's paper entitled "How decisions happen in organizations" (1991)

Some time ago, I was put onto this by a posting at Eight2Late.

The thing that got my attention this time is March's description of the operating mode that decision makers fall into, either wittingly or witlessly:

"They do not recognize a problem until they have a solution". This is certainly bottom up, and closely aligned with the so-called wicked requirement (the solution defines the requirement)

"They scan their environments for surprises and solutions". Why wouldn't they scan for the information elements and then make decisions?

The answer may be in this bit of wisdom about enterprise information:

"Rarely innocent". That's one I'd not heard before, but there you are. I guess by corollary that makes information "guilty" of bias and misrepresentation.  Good grief!

---

Bookmark this on Delicious

When you come to a fork, take it

---

American baseball player Yogi Bera is well known for his witticisms, among them "When you come to a fork, take it". And, for project managers this means when you come to a probabilistic branch in the schedule, it's decision time.

The problem is: on paper it always looks like that there is plan for a decision to be made for which there's freedom of choice; whereas sometimes your hands are tied, your options have become limited, or the situational logic for one thing over another is overwhelming.

A biggie in this regard is time. Sometimes, we just run out of time to take the 'A' course despite its better strategic fit, the only practical choice then being 'B'. (Maybe we can't do 'A' if we can't make the decision before September 1st, as an example.)

Thus, we empathize with B.L. Hart when he explains:

It was the logic of events resulting from loss of time more than the logic of argument which swung the .... strategy

Basil Liddell Hart

How frustrating! The logic is on our side; the 'facts' seem to be on our side, but still we are compelled by circumstances to decide the other way.

This sort of stuff gives probability analysis and decision analysis a bad name, because in the end, the decision wasn't probabilistic at all; indeed, it really wasn't a decision.

We were propelled by the exigencies of the moment.

We had no choice!

---

Bookmark this on Delicious

A twist on innovation

---

In a recent article, we learn that the new head of the "Advanced Technology and Projects" group at Google's Motorola hires her people for only two years. That's a bit unusual, but apparently the commitment to the exit is real: when she was at DARPA leading a similar group, she had their exit date imprinted on their identity badge!

Speaking about her group at Google/Motorola, Regina Dugan says:

“It’s a small, lean and agile group that is unafraid of failure,” she said, and it will “celebrate impatience.”

She is hiring metal scientists, acoustics engineers and artificial intelligence experts. They will work for her for only two years so they feel a sense of urgency, she said, an idea she borrowed from Darpa, where people wear their resignation date on their name tags.

I've heard of exit strategies, and exit dates, but I don't think I ever got the memo on this one: taking your best and brightest and making them two-year temps. Maybe it instills a sense of urgency; maybe it defeats lethargy; maybe it drives innovation to the market faster.

And, maybe private industry is not government where a culture of 'temporary', even at the highest level, is not at all unusual. So, we'll have to see how this one plays out. I don't think this is the way that Apple, Pixar, and Intel play the game.

---

Bookmark this on Delicious