Pages

Monday, November 28, 2016

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.

When you don’t know what to do,don’tsit 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.

Monday, November 21, 2016

Chapter 14 from the GAO Cost Estimating Manual on "Cost Risk and Uncertainty" is a good read, easily understood, and very practical in its examples.

Here's one illustration that I particularly like. When you look at it, it's understood in a moment that the repeated random throw of two dice generates a probability density function [PDF] that has a bell-shape curve.

Statisticians call this phenomenon the Central Limit Theorem: random occurrences over a large population tend to wash out the asymmetry and uniformness of individual events, such that a "central tendency" occurs around the more probable outcomes. A more 'natural' distribution ensues. The name for this somewhat natural distribution is the Normal distribution, more commonly: the bell curve.Here's what it looks like to a project manager.
Regardless of the distribution risks in either cost or schedule as adopted by work package managers for each individual work package, in the bigger picture at the summation will tend to be a bell-shaped distribution of risk.

Consequently, the project manager's doesn't really need to understand the parameters of variation for each work package. The Central Limit Theorem does all the work. Triangles, Rayleighs, and even Binominal distributions are become bell shaped in the big picture.

This diagram is (again) from Chapter 14 of GAO's manual:

If the risk analyst generates these data from a simulation, like a Monte Carlo simulation, then the numeric statistics like variance and standard deviation are usually reported, along with the cumulative probability more commonly called the "S" curve. In the diagram, on the right side, we see the cumulative curve plotted and labeled on the vertical axis as the confidence level. With a little inspection, you will realize that the cumulative curve is just the summation of the probabilities of the bell curve that is adjacent on the left.

The GAO manual, and especially Chapter 14, has a lot more information that is well explained. Give it a read.

Thursday, November 17, 2016

First, we have "Brooks Law", as given in the classic case study "The Mystical Manmonth" by Dr. Fred Brooks:

"Adding staff to a late project makes it later"

I was no more thinking about that idea, than I read this missive in a history of the Civil War that I am engaged with:

“The veterans looked across the open ground at the newcomers with complete and unconcealed skepticism and hostility. In every line of their bearing—in the set of their jaws, the tilt of their heads, the look about their eyes peering out from under those valued hatbrims—they expressed for all to see the age-old, impersonal, unformulated feeling of the veteran for the recruit:

We have had it and you have not, and until you have been where we have been and have done what we have done we do not admit you to any kind of fellowship.”

Excerpt From: Catton, Bruce. “Glory Road.” This material may be protected by copyright.

OK, that might be tougher than the normal project team might be, but in my experience, until there is bonding over a common stress, there's not cohesion, and maybe not even functional integration.

So, as in war and most other things, to speed assimilation along, sometimes a bonding experience is needed. Thus, all the bonding games, etc, but it often works. Else, just put everybody in the deep end. Survival will do all that is necessary

And, did I mention virtual teams: there's really not a difference, not really.

Monday, November 14, 2016

Some years ago I picked up this nice summary image of agile planning over several time cycles. It came from a white paper at AgileConnection.com " entitled "Scaling Agile Processes: Five Levels of Planning

Fortunately, to give some credibility to his thesis, the author says right up front that agile methods don't scale to enterprise level without some changes! He is so right. Since 2014 when the paper was written, SAFe (Scaled Agile Framework) and other scaling methodologies have come along and acquired creds in the community

So, as agile has matured, acquired some common sense, and worked its way into mainstream project protocols, even large scale organizations, like DoD, have embraced some tenants of agile methods.

You can check out some of the references to DoD practises I've gathered from Glen Alleman and others. As well, read some background
in the white paper I wrote "back in the beginning" about agile in the DoD.

Thursday, November 10, 2016

Here's what Robert O. Work, Deputy Defense Secretary is quoted as having said:

You could “use the tactical ingenuity of the computer to improve the strategic ingenuity of the human,”

Authors Matthew Rosenberg and John Markoff write that ... "Work believes a lesson learned in [AI applied to ] chess can be applied to the battlefield, and he envisions a military supercharged by artificial intelligence. Brilliant computers would transform ordinary commanders into master tacticians."

Hmmm, does that mean that brilliant computers (a.k.a AI) can turn ordinary PM's into masterful tacticians, following along with their business' strategy?
It's a concept!

Monday, November 7, 2016

At Critical Uncertainties I read a post that I hope is meant in the best of humor, but actually it might be quite serious

Here's the setup:

Customer states requirement

Customer states requirement verification protocol

Project team implements protocol

But wait ... protocol is only statistically applicable

And here's what Critical Uncertainties writes:

".... one realises [SIC] that requirements are 'operationally' defined by their associated method of verification. ..... Now if you're in luck ..... you propose adopting a statistical proof (because it's such a tough requirement and/or there's variability in the process, weasel weasel) of compliance based on the median of a sample of tests. Using the median is important as it's more resistant to outlier values, which is what we want to obfuscate (obviously). As the method of verification defines the requirement all of a sudden you've taken the customer's deterministic requirement and turned it into a weaker probabilistic one."

This last thing is the key and merits repeating:

"As the method of verification defines the requirement all of a sudden you've taken the customer's deterministic requirement and turned it into a weaker probabilistic one."

OMG! Did you pull one off on the customer, or did you simply introduce the customer to the realism of the verification protocol?

"You" are the sponsor, and your context and objectives and measurements are different from "I".

I am the PMO; I respond to my measurements, incentives, and context.

We all notice: there is a gap. Sort of a Mars v. Venus thing. And, who is to manage the gap, a.k.a. the risk, between us? Well, that's why they pay PMO the big bucks! To manage all the risks, whether under their control and influence or not.

Project balance sheet
My icon for this is the "project balance sheet"

"You" are on the left

"I" am on the right

And, I have the risk (gap) on my side

"You" have a top-down more-or-less "fact free" vision of things. "I" do things stick by stick, bottoms up, dealing with the facts and estimates. "You" and "I" never actually agree. But we get the gap close enough to move ahead. And, that's the way it is on Mars and Venus

When a company buys an SRM from NIST, they are really buying all of the measurements and scientific expertise that went into determining its chemical or physical properties, as well as NIST’s level of certainty regarding those measurements.

(*) National Institute of Science and Technology
Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!