Getting to done from "yes"...

---

Jurgen Appelo wrote a recent blog that touched a nerve with me.

• He reported that he kept a log of all the people who volunteered to red team his latest book (that is, those that said: Yes, they would be on the red team), and
• Then he made note of the subsequent "down select" to those that actually could make a commitment when the time came, and
• Finally he logged those that actually showed up and did the work... Done!

Needless to say, the down select from the first group was pretty dramatic. As author of several books, I can say my experience was just the same. And, the behavior Jurgen laments is not exclusive to reviewing books... we see it all too often in all aspects of project life.

What's the lesson here?
Getting to yes is easy. Getting to done is hard.
Sometimes, you have to drag the team to the winner's circle!

Turning passion into action is one of the traits of great leadership

---

Bookmark this on Delicious

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

Getting your story out.. with data

---

Tom Davenport tells us that there are 10 good ways to tell a story with data.

Fair enough. You'll find his ideas well known and familiar, but there's nothing like a bit of taxonomy to organize thinking.

The first idea is three dimensions of time:

Time: Analytical stories can be about the past, present, or future time

And, then there are two more, addressing depth of detail, or not:

Depth: There is also a depth dimension to analytical stories ... akin to "CSI" forensics.
The alternative I call “Eureka” stories, which involve long, analytically-driven searches for a solution to a complex problem

Tom calls the next three matters of focus, but you could easily say "motivation", the ever popular what, why, and how:

Focus: Are you trying to tell a what story, a why story, or a how to address the issue story

Let us not leave out cause and effect, sometimes called root cause analysis, or it's close cousin -- correlation:

Methods: Finally, there are different types of stories based on the analytical method used. Are you trying to tell, for example, a correlation story—in which the relationships among variables rose or fell at the same time—or a causation story, in which you’ll argue that one variable caused the other

---

Bookmark this on Delicious

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

Telling a story with data

---

Jim Stikeleather, writing on the HBR Blog Network, has five useful and usable ideas about applying data to weave a narrative and tell a story.

This comes up all the time in project management, starting with the business case, but going all the way through to test scenarios for user validation.

His points are good ones because, frankly, they're actionable by project managers, not just blah, blah:

Find the compelling narrative.  You are competing for the viewer’s time and attention, so make sure the narrative has a hook, momentum, or a captivating purpose. ... encourage examining relationships among and facilitate interacting with the data – think gameification.

Think about your audience.  The visualization needs to be framed around the level of information the audience already has, correct and incorrect:

• Novice: first exposure to the subject
• Generalist: aware of the topic
• Managerial: in-depth, actionable understanding of intricacies and interrelationships with access to detail
• Expert: more exploration and discovery and less storytelling with great detail
• Executive: only has time to glean the significance and conclusions

Be objective and offer balance.  Even if it is arguing to influence, it should be based upon what the data says–not what you want it to say. Viewers and decision makers will eventually sniff out inconsistencies which in turn will cause the designer to lose trust and credibility, no matter how good the story.

 

Don’t Censor. Don’t be selective about the data you include or exclude, unless you’re confident you’re giving your audience the best representation of what the data “says”.

 

Finally, Edit, Edit, Edit. Also, take care to really try to explain the data, not just decorate it.

---

Bookmark this on Delicious

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

Looking for an honest debate?

---

Are you looking for an honest debate? It's actually not a rhetorical question. Sometimes, we want to play with loaded dice, and we don't want the other guy to know.

But, for now, let's say you want to get an honest debate on some trade you have to make in the project. And so, you put up the trade space and ask for the debate.

How to proceed?

Michael Schrage, writing in the HBR Blog Review, posits this:

If your organization is having an important argument that gets everybody hot and bothered, don’t encourage compromise or collaboration. Insist that the most passionate and articulate advocates from each side make the other’s case.

Force the best and the brightest to publicly demonstrate just how well they understand the other.  

Does this really work? Schrage gives us Gladwell as an example:

Malcolm Gladwell of bestselling Tipping Point and Outliers fame proposed a delightfully provocative way to begin his onstage debate with Sports Gene author David Epstein about whether practice or genetics is the better guarantor of professional success.

But instead of launching directly into argument, said Gladwell, they’d start by summarizing their opponent’s best arguments. The exceedingly careful, precise and thoughtful characterizations of each other’s position that followed proved remarkably entertaining and informative.

And finally, Schrage tells us:

Managers and executives confronting serious strategic, operational or cultural disagreements on issues that matter should insist that their people be able to convincingly make their opponents’ case. This is not a joke, a gimmick or an intellectual exercise. It’s a public declaration of integrity: Fairly presenting a 360-degree view — both sides of a polarizing argument or wedge issue — is essential to honest and honorable discussion.

---

Bookmark this on Delicious

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 the U.S. DoD... more info

---

Jeff Sutherland, an agile thought leader, brings us the latest news about agile practices in the U.S. DoD, which is important not because of the military utility of agile, but for the acceptance in a large organization accustomed to strong command and control in project processes. Jeff writes:

"Since I briefed the Coordinating Task Force at the Pentagon on how to report back to the Congress on progess, we've talked a lot about how the US Department of Defense (DoD) is going Agile.

We've also shared some ideas on how to do it from SEI. Here is some real concrete guidance about how to do it from the DoD. We've also been corresponding with four-star General Barry McCaffrey, my former classmate at West Point.

He was very clear in his comments on our new book, Scrum: The Art of Doing Twice the Work in Half the Time. “Scrum is mandatory reading for any leader, whether they’re leading troops on the battlefield or in the marketplace. The challenges of today’s world don’t permit the luxury of slow, inefficient work. Success requires tremendous speed, enormous productivity, and an unwavering commitment to achieving results. In other words success requires Scrum.”

In the process of writing our online course Agile Defense we read with great interest the Interim DoD Instruction 5000.02. This document shows at least one way the DoD is thinking about doing, Agile development in software.

We also get this:

"This [new agile] model is distinguished from the previous [traditional] model by the rapid delivery of capability through several limited fieldings in lieu of single Milestones B and C and a single full deployment.

Each limited fielding results from a specific build, and provides the user with mature and tested sub-elements of the overall capability. Several builds and fieldings will typically be necessary to satisfy approved requirements for an increment of capability.

The identification and development of technical solutions necessary for follow-on capabilities have some degree of concurrency, allowing subsequent increments to be initiated and executed more rapidly."

---

Bookmark this on Delicious

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

Ooops! Right data; Wrong answer

---

It is certainly true that when working with incomplete or uncertain data sets, even qualitative data sets, it's quite possible to draw a wrong inference from a correct data set.

That is: the data could be correct and true in all respects, but a false conclusion is drawn or a false cause is assigned in the cause-effect relationship.

Of course: how would you know you're drawing a wrong conclusion?

Really, only by experimentation or prototyping. If an experiment, developed from your (false)
conclusion yields inconsistent data that does not fit with the original data set, then you can reasonably conclude that a wrong inference has been drawn.

John Mandel, writing in "The Statistical Analysis of Experimental Data" (now available as an e-book) tell us:

..... inferences drawn by induction from incomplete information may be entirely wrong, even when the information given is unquestionably correct.
... the dependence of inductive inferences [is] not only on the correctness of the data, but also on their completeness.  

A simple example is this one:

if one were given the ... pressure and volume of a fixed mass of gas, one might infer, by induction, that the pressure of a gas is proportional to its volume, a completely erroneous statement. The error is due, of course, to the fact that another important item of information was omitted, namely that each pair of measurements was obtained at a different temperature,

So, we must be cautious about how we reason with incomplete data. Mandel goes on: "A. Fisher, one of the founders of the modern science of statistics, has pointed to a basic and most important difference between the results of induction and deduction":

In the latter [deduction], conclusions based on partial information are always correct, despite the incompleteness of the premises, provided that this partial information is itself correct.
For example, the theorem that the sum of the angles of a plane triangle equals 180 degrees ... does not necessitate information as to whether the triangle is drawn on paper or on cardboard.... If information of this type is subsequently added, it cannot possibly alter the fact expressed by the theorem.
On the other hand, inferences drawn by induction from incomplete information may be entirely wrong, even when the information given is unquestionably

Wikipedia puts it this way:

While the conclusion of a deductive argument is supposed to be certain, the truth of the conclusion of an inductive argument is supposed to be probable [or, at least credible], based upon the evidence given

---

Bookmark this on Delicious

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

And, who did you say had responsibility for customer?

---

One of my students offered this strategy for establishing, maintaining, and leveraging relationships with the customer. I thought it was pretty good, so here's the idea:

1. Customer Account Responsible (ACR) -- who ... is the Account Manager
for the domain, market or dedicated to the customer (big accounts) responsible for:

• Account relationships,
• Opportunity identification,
• Commercial management,
• Communication management.

Normally the SPOC for a business development effort.

2. Customer Solution Responsible (CSR) – This role is held by various people
depending on the company type – Solution Architects, Solution Consultants,
Solution Managers etc – and they have the responsibility of:

a. End-to end solution integrity
b. Collection of and documentation of requirements from the customer – Executive,
Business, Technical and Users requirements – Securing the sign off on the
requirements scope with the ACR and CFR to the customer.
c. Prioritization of the requirements with the respective customer responsibilities,
in order of increasing importance, and determining the “fit to need” alignment of
the requirements
d. Map solution requirements to the vendor solution/product portfolio, and
determine the Delta, and how to fill those Delta.
e. Hand off complete solution design documentation to the project execution team,
and provide input to the executing team (CFR) for project execution planning.
f. Including and manages SME’s , Product Owners etc and their deliverables as
needed in various verticals that are needed to address the solution design and
product lifecycle

3. Customer Fulfillment Responsible (CFR) – this is normally the PMO organization that turn the solution into reality inside the customer organization/premises/site:

• Project management team,
• Service Delivery team,
• System Integration team,
• Field Engineers,
• Technical Architects etc

PMO is are responsible for:

• System Integration and Final Acceptance testing
• Validation with the customer, and
• Finished Product Handover to the customer Project/Service Operations team.

At this stage the solution ceases to be a project, and is included into the Customer Operational and Support Lifecycle Management.

---

Bookmark this on Delicious

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

Diversity webinar

---

A lot of webinars are hardly worth the time; frankly, there are too many consultants pushing an agenda or a product. But here's one I can recommend from the PMI Risk Management Community of Practice: "Diversity and Risk Management"

And, in case you are puzzled by the title, this is not about diversification of assets or risk; rather, it's about cultural and situational diversity as risk drivers on the project.

Bob Mahler is the presentation leader, and he's pretty good at this... frankly, better than most webinar leaders. I like the offline viewing simply because you can move along at your pace. Of course you miss some of the online participation, but that's a trade I'm willing to make.

In any event, try this one and earn 1.5 PDU.

---

Bookmark this on Delicious

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

Action Required!

---

What is leadership in tight spaces? (You probably won't get credit for Mr/Ms Nice Person when leading from a tight spot with a lot on the line)

Here's an answer (given to me by another)

Willingness and ability to act depend on three factors

• Leverage
• Interests
• Values

Leverage: Get more out than you put in; or, a little effort yields a big response. Don't hesitate to use your leverage to gain advantage; find a way to get the long end of the bargain. Leverage is not win-win; it's I win more than you do. And, leverage is "don't ask a question you don't know the answer to" in an adversarial setting. Q&A is for the classroom, not the competition.

Interests: Don't cloud the bargain with friendship, or look for friendship in all the wrong places. In business and politics, there are interests but few friends. (In Washington, if you want a friend, get a dog!). Interests are those outcomes or relationships which are advantageous to me. But, you have interests also. If we can find a common interest in a transaction, we can probably do business

Values: What I believe in and accept as truth or beauty largely without proof. It just is, and it is because I believe it to be so. Values are what I defend, what I will fight for, what I won't compromise.

---

Bookmark this on Delicious

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

This one is free, and it works

---

I use google docs a lot. I like the idea of cloud storage and easy sharing.

Fair enough

But, then comes the desktop. Sometimes, it's just easier to use the desktop. So, enter Microsoft Office, all stuff I've used for years: Word, Excel, Powerpoint, Access, and the integrated project tools Project and Visio.

But, alas: Microsoft is not free, though various cloud services are (though not SharePoint). Dropbox serves me well here

So, when it was suggested that I try LibreOffice I gave it a go.
It's good, and free (donations accepted, and well deserved)!

Fast, complete enough for project management, and includes the requisite 'word', 'powerpoint', and 'excel' analogs, as well as an Access-like database, math module for formulas, and a separate draw package for simple drawings. Only the presentation module is a little lacking, and so you might want to keep your PowerPoint around until you vet the presentation module.

Some caution advised: the default format for all the applications is variations of "open document". For the most part, this works ok, but not if you are going to routinely work back and forth with Office: PowerPoint won't open an open document presentation; Excel and Word won't honor all the formats; and in the case of Excel, some text entry may not convert at all.

And, if you are going from google doc's to 'open docs', some of the same problems persist.
Thus, my advice: work in one domain or the other; expect problems and inefficiencies of you intend to work back and forth.

---

Bookmark this on Delicious

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

I, the expert!

---

This video captures the project kickoff from hell -- and with humor we can all relate to!

The scope is simple: Deliver 7 red lines.

Then, customer, sponsor, project manager, and SME all go to work on it. You'll love it.

---

Bookmark this on Delicious

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 from the oddest corner

---

I read a recent posting about agile from a very odd corner of the PM space for an agile conversation to be: CriticalUncertainties, a (conservative) blog about critical safety and failure (or fail safe) requirements in complex systems.

But, nonetheless, we get this input from critical systems safety expert Mathew Squair:

When you don’t know what to do, don’t sit down and plan what you don’t know, get people moving, talking, collaborating and making stuff. Then out of that activity you’ll find the information will emerge that will allow you to make decisions.

As Tom Peters points out we need to understand whether our methodologies have an inherent bias for action or a bias for planning, and then whether the situation is complex (but understood and stable) where planning will pay off or uncertain (with high novelty and volatility) where talking, thinking and looking at the small grain issues to build a picture of where we are is what we ought to be doing.

---

Bookmark this on Delicious

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

First the design, then the narrative....

---

Matthew Squair, and others, have raised the issue of the "false narrative" to the level of project management and system engineering. Thus, it got my attention. Here's the set-up as given in a posting on "LessWrong" :

Essentially, the narrative fallacy is our tendency to turn everything we see into a story - a linear chain of cause and effect, with a beginning and an end. Obviously the real world isn't like this - events are complex and interrelated, direct causation is extremely rare, and outcomes are probabilistic. Verbally, we know this - the hard part, as always, is convincing our brain of the fact.

The big deal for project managers and system engineers is the ageless issue of sequencing, to wit: the proper order of the horse and cart. Do we:

• Start with the narrative and design the system of parts
• Or, do we start some parts, conceive a narrative to link them, and then fill out the system?

Squair, Taleb, and others say all too often we see a few facts, jump on them with a plausible narrative, and go off designing, only to wind up building the wrong thing.

Squair gives it his name: Design as a false narrative

But, Nassim Taleb got there first -- it might even be better titled the "false understanding" (the allusion of understanding when there really isn't any":

The narrative fallacy addresses our limited ability to look at sequences of facts without weaving an explanation into them, or, equivalently, forcing a logical link, an arrow of relationship upon them. Explanations bind facts together. They make them all the more easily remembered; they help them make more sense. Where this propensity can go wrong is when it increases our impression of understanding.

Nassim Taleb. The Black Swan.

One is led immediately to think of the agile backlog and its stories. I wonder how many of them are false narratives that are leading to the wrong place, perhaps even led by unwitting customers?
 

---

Bookmark this on Delicious

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