Are best practices "best"?

---

"Creativity requires letting differences make a difference"

Stanley Deetz

2003 Becker Lecture

My take: Mr Deetz is profoundly obvious.

But as many have warned, in the zeal to adopt best practices and accepted principles in the pursuit of productivity, efficiency, and global competitiveness, sometimes an over-rigidity sets in, wiping out the differences, thereby reducing creativity to "me too, with immaterial differences"

In the world of Kano Analysis, this is a "decay" from 'ah-hah!' to 'must not be missing'.

Remember when cars didn't have cup holders? Hey, this is important stuff! Once cup holders reach a tipping point, everybody expects cup holders. (I'm frustrated my new car does not turn off the headlights automatically, something my 8-year old Explorer does easily)

So, if it's a best practice to do something in one methodology or culture or situation, is it always a best practice? Well, if it's cup holders, perhaps yes (you can throw in the headlights control also), but if it's project methods and practices, then you've got all the non-linearities of people; cognitive biases of the sponsors; and the complexities of new and untested situations. "Best" does not always port well

In fact, "best" may be poor and there may well be something more appropriate. The issue for the PM is having the flexibility and the authority to invent. Principles of subsidiarity, in other words, should apply. "Do only that which you alone must do" is the watch word. Let others discriminate and find the differences that make a difference.

---

Bookmark this on Delicious

Program success probability

---

Glen Alleman had a recent posting that linked to John Higbee's presentation about "Program Success Probability".

On page 5 of Higbee's slides, you'll find this image:

I find this cognitively satisfying: all is in order as my German friends would say. It's a risk register of sorts. On the right are all the external factors/metrics that have material impact; on the left side are the internal risks and issues.

This presentation is intended as a dashboard. The colors are dynamic on a Red-Green-Yellow-Gray (not evaluated) scale. The scale has to be defined (calibrated) for each program in order for management to be able to get a proper take-away.

Trends are shown in each block with arrows. Again, trends must be defined for each program, i.e. what is the meaning for an up-pointing arrow?

Of course, Higbee goes on in the presentation with more detail and more examples of dashboard presentations, for example the more-or-less standard presentation of sliding bars to show progress vs plan

Since this presentation is for a government audience, it includes dashboards for contractor performance and even contractor business success (P/E ratios, for goodness sake... does the market really affect contractor performance?  If the P/E is in the tank, there are probably other more pressing problems)

Bottom line: an interesting suggestion for dashboards are in this presentation, along with at least one gov'y's idea of what's important.

---

Bookmark this on Delicious

Modular contracting

---

From the White House in Washington we get this news:

There is to be "Greater Accountability and Faster Delivery Through Modular Contracting"

And good news that is, indeed. In a document helpfully titled: "Contracting Guidance to Support Modular Development" we learn that it is US policy to encourage:

agencies to shift away from the bloated, multi-year projects so common in the past to a more nimble approach. The guidance provides our IT, acquisition, finance, and program officials practices for how they can, working together as part of an integrated program management team, break investments into more manageable chunks; eliminate the costly lag between when the government defines its requirements and delivers solutions; and begin delivering workable solutions shortly after contract award. By requiring frequent deliverables, agencies will also be better able to hold contractors accountable for keeping projects on track and delivering solutions that truly meet agency needs. And by breaking investments into smaller chunks, agencies may be able to drive more competition – including small businesses that might not have been equipped to compete for the massive, multi-year projects of the past. And more competition means a better value for the American people

Agile government projects, anyone? :)

---

Bookmark this on Delicious

Unfunded mandates

---

Unfunded mandates (off-baseline requirements without money attached) are no fun to deal with, but they may come at you at any time.

In project vernacular, call them changes (usually from "the high command") approved by "them", sometimes using the change management process (hopefully, there is a CMP at work for you) and sometimes not.

In the event, you can object (and often we do), but usually to no avail ("We have to do this, so find a way").

Was this on the risk register? Likely not; but there you have it, so what's to do?

A handful of strategies:

• Tax everybody: (In the USA, we call this the 'tea party' approach) Every work package is levied with a small tax to create a reserve to cover the mandate. Usually, this is taxation without representation. Caution: as in Boston in 1773, this approach may engender resistance. WP managers cover the tax by doing the same with less, pushing for economies and gifts of 'free time'.
• Tap into the the project budget reserves (budget slack). This strategic reserve is supposed to be for the crisis that can't be otherwise resolved. Often, the mandate meets this requirement.
• Be a rebel: exceed the budget and ask for forgiveness after the fact. This is the "they wanted it, so they got it" approach, but sometimes it  works.
• "Hope is a plan" (and prayer may work also). Just push ahead and hope for a compensating gift from some activity.

Was this helpful?
I've tried them all.

Frankly, the 'tea party' approach has worked best for me (followed by "be a rebel").

W.D. Cooper. "Boston Tea Party.", The History of North America. London: E. Newberry, 1789.

---

Bookmark this on Delicious

The business made me do it!

---

Is this the ultimate angst of micromanagement?

First, you push on your territories [work packages] where you have no business to be, and where you had promised not to go; secondly, your intrusion provokes resentment, and resentment means resistance.

Thirdly, you instantly cry out that the people [teams] are rebellious ...

Fourthly, you send out a force [PMO helpers] to stamp out rebellion; and fifthly, having ... spread confusion... you declare .... that [business] reasons forced you to stay....

Viscount John Morley

State Secretary for India

1905 - 1910

Of course, Morley said it slightly differently; he actually didn't mention work packages and PMOs (Shocking!) You can find Morley's more complete quote on the first page of David Ignatius' spellbinder "Bloodmoney"

Jeff Foxworthy probably has never said "you know you're a micromanager when...", but if he had, he might have said: you know you're a micromanager when you say:

a. I'm not a micromanager; I let my people make the decisions
b. I'm not micormanaging; I'm mentoring the team
c. Some people simply can't accept input
d. I can't let this happen on my watch, so I have to be involved.

The Viscount couldn't have said it any better than Foxworthy!


Bookmark this on Delicious

Agile and the DoD (again)

---

David F. Rico has a presentation about Agile in the DoD. He presents a compelling case for agile in large scale systems and in enterprises steeped in traditional methods, and those highly regulated for quality and compliance to standards.

There is both a video of his presentation, and a slide set. You can get all the details for accessing the video at Herding Cats. Once you're into the video, you can click on the right-side panel for another window to open with just the slide set.

---

If you're interested in other perspectives, search for 'agile' in the online journal for DoD software engineering "Crosstalk"; there are dozens of good articles there on DoD projects and process.

---

Another summary of things going on is given to us by Jeff Sutherland on his "DoD goes Agile" posting. He (Jeff) quotes from the 2010 Defense budget authorization bill:

The key language is this:

(2) be designed to include—

(A) early and continual involvement of the user;

(B) multiple, rapidly executed increments or releases of capability;

(C) early, successive prototyping to support an evolutionary approach; and

(D) a modular, open-systems approach.

Basically, for the DoD at least, Agile became the law. Here's the report the DoD returned to congress

Or, for my perspective, you can read here or below:

Agile and the DoD

View more documents from John Goodpasture

Bookmark this on Delicious

Three strategies for strategic actions

---

In a recent issue of Strategies+Business, authors Tim Laseter and Saras Sarasvathy tell us about three different approaches to strategic actions. After reading through it, I understand their three points, but I think their first one is academic filler... but you judge for yourself:

Approach 1: Planning and Positioning. Characterized by knowledge of the probabilities and impacts of risk events. Decisions to maximize strategic value are made on the basis of expected value. Typical tool is the classic decision tree

Approach 2: Organizational Learning: Probabilities (and therefore probability distributions) are unknown, so risks are now "uncertainties". Events, conditions, and perhaps impacts can be estimated, but not their frequency. This has been termed Knightsian Uncertainty, named for its conceptualizer, Frank Knight who wrote it all down in in book: "Risk, Uncertainty, and Profit".

One really important idea here is that the first step in assessing uncertainty is to estimate whether the downside is affordable. If not, then that's to be taken care of first. Then, choices can be made about the strategic upside of opportunity. Expected value usually doesn't enter the picture since there's no knowledge of probability.

Approach 2 has buried in it our natural avoidance of ambiguity. When the stakes are small, we may choose strategies that are vague but probably doable. But as stakes change, so do attitudes.. bigger stakes, more conservative, eschewing ambiguity for more clarity; in effect, a violation of utility. An understanding of this is generally credited to Daniel Ellsberg, and called the Ellsberg Paradox.

Approach 3: Constructive Transformation. In this strategic formulation, you more or less take what live gives you and then make something out of it. In other words, you don't lead with vision; rather, you lead with process (and tools, and talented people). So, this is something like what Lou Gerstner said when he took over IBM. In effect, when asked about his vision for IBM, he said he didn't need one. What he needed to do was to get the machinery of IBM working again. This, of course, he did, and he did it quite well.

Constructive Transformation is something akin to abductive reasoning: that is, you hypothesize what might be possible that could link many disparate events, objects, or conditions.

So, what do you think? For my money, approach 2 or 3 are close to the way it really works. Approach 1 is theoretically correct, but generally impractical because the information simply isn't available to drive the decision tree.

Bookmark this on Delicious