10 commandments times 5

At QuantmLeap there was a recent posting of the 10 commandments of project management. Only there were actually 5 sets of 10, some 50 in all, albeit some duplication. And, to be clear, QL actually gathered four sets from other authors and then added the fifth.

But for my money, there's something to be said for simplicity and clarity. Albert Einstein: "make is as simple as possible, but not simpler"

For my money, instead of 50 how about 5? This is the way Glen Alleman puts it, and the greatest of these is "Done". What does DONE look like?

Bookmark this on Delicious

Of chains and funnels

What to make of chains and funnels? And, if I also stick in anchors, does it help?

What I'm actually talking about is conjunctive events, disjunctive events, and anchor bias:

The general tendency to overestimate the probability of conjunctive events leads to unwarranted optimism in the evaluation of the likelihood that a plan will succeed or that a project will be completed on time. Conversely, disjunctive structures are typically encountered in the evaluation of risks. A complex system, such as a nuclear reactor or a human body, will malfunction if any of its essential components fails.

Daniel Kahneman and Amos Tversky

Judgment Under Uncertainty: Heuristics and Biases

• Conjunctive events are chains of event for which every link in the chain must be a success or the chain fails. Success of the chain is the product of each link's success metric. In other words, the chain's success probability degrades geometrically (example: chain of 'n' links, each with probability 'p', has an overall probability of p*p*p* .... for 'n' p's.)
    
• Disjunctive events are independent events, all more or less in parallel, somewhat like falling in a funnel, such that if one falls through (i.e, failure) and it's part of a system, then the system may fail as a whole. In other words, if A or B or C goes wrong, then the project goes wrong.

Fair enough. Where does the anchor come in?

Anchoring refers to the bias introduced into our thinking or perception by suggesting a starting value (the anchor) but then not adjusting far enough from the anchor for our estimate to be correct. Now in the sales and marketing game, we see this all the time. Marketing sets an anchor, looking for a deal in the business case; the sales guy sets an anchor, hoping not to have to give too much away post-project. The sponsor sets an anchor top down on the project balance sheet, hoping the project manager will accept the risk; and the customer sets anchors of expectations.

But in project planning, here's the anchor bias:

• The likely success of a conjunctive chain is always less than the success of any link
• The likely failure of a disjunctive funnel is always greater than the failure of any element.

Conjunctive chains are products of numbers less than 1.0.

• How many of us  would look at a 7 link chain of 90% successes in each link and realize that there's less than one 1 chance in 2 that the chain will be successful? (probability = 0.48)

Disjunctive funnels are more complex. They are the combinations (union) of independent outcomes net of any conjunctive overlaps (All combinations of OR less all AND). In general the rules of combinations and factorials apply.

• How many of us would look at a funnel of 7 objects, each with likely 90% success (10% failure) and realize that there's better than 1 chance in 3 that there will be 1 failure among 7 objects in the funnel? (probability = 0.37 of exactly 1 failure)*

 The fact is, in the conjunctive case we fail to adjust downward enough from 90%; in the disjunctive case we fail to adjust upward from the 10% case.  Is it any wonder that project estimates go awry?

*This is a binomial combination of selecting exactly 1 from 7, where there are 6 conjunctive successes and 1 conjunctive failures: factorial (7 take 1) *conjunctive failure * conjunctive success

Bookmark this on Delicious

My five favorite rules for risk management

A lot of people read PMBOK Chapter 11 Risk Management and say: I've got it!

Not so fast! Point -- Counter Point: it wouldn't hurt to read Hubbard: "The Failure of Risk Management: Why It's Broken and How To Fix It"

And, the US General Accounting Office, the US DoD, and NASA all have pretty good free references.

And, to step up your game, how about McGrayne: "The Theory that would not die: how Bayes’ rule cracked the enigma code, hunted down russian submarines, & emerged triumphant from two centuries of controversy"?

Well, I've read all of this stuff and come up with my five favorite rules for risk management, conveniently available at slideshare.net/jgoodpas, and in the embed below:

Five risk management rules for the project manager

View more presentations from John Goodpasture

Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

What does complexity achieve?

Glen Alleman posted a very instructive piece on the point: "what does complexity achieve?"

The basic argument in favor of complexity is that it begets robustness, in effect redundancy, such that complex systems, whether physical or biological are more likely to survive.

I agree; point taken.

But wait, no less an eminence than brother Einstein counsels:

Everything should be as simple as possible by not simpler

The fact is: complexity comes at a cost that is perhaps unaffordable. Complex systems are prone to chaotic behavior: relatively minor stimulus provokes multiple diverging responses. Is it possible to predict such stimulus-response: yes, physical systems always act according to their design. But, how do we know to do the predicting? There's no way to know, so largely it's not done, and the latent threat is always there, to cause a reaction at what cost? There's no way to know. Reducing complexity to the Einstein level is the only generic preventive strategy.

Bookmark this on Delicious

Collaboration or cubicle?

Collaboration is in; cubicles are out. But, should they be?

“Most inventors and engineers I’ve met are like me ... they live in their heads. They’re almost like artists. In fact, the very best of them are artists. And artists work best alone .... I’m going to give you some advice that might be hard to take. That advice is: Work alone... Not on a committee. Not on a team.”

Steve Wozniack

Well! what to think of Mr Wozniak? Could it be that natural introverts--Mr Wozniak readily admits this of himself--need some separation? Yes! It's well known by the Meyer-Briggs crowd that extroverts are charged up by the energy of other people.

But introverts are exhausted by that same energy, and need solitude to charge.

So, I'm all for collaboration, and team areas for common work. But the ISTJ's, INTJ's, and other I's need time away.

So it's somewhat shocking to learn  that brainstorming of all things can be counterproductive, and so also--gasp!--team work. Is this project management heresy? Who among us has not participated in some team work training, and had it demonstrated to us that the team always does better than the individual?  But, what about this?

The “evidence from science suggests that business people must be insane to use brainstorming groups,” wrote the organizational psychologist Adrian Furnham. “If you have talented and motivated people, they should be encouraged to work alone when creativity or efficiency is the highest priority.”

Good grief! Back to the drawing board and the open space plan. Perhaps I'll put in that order for cubes after all! And, maybe I'll take another look at virtual teams. Maybe there's something there I've been missing. And that eccentric SME loaner is not looking too bad either!

Bookmark this on Delicious

It's risk management in any form

Everyone knows the basic steps of risk management:
Identify, assess, plan a response, control and monitor responses. And the traditional four response plans: accept, transfer, mitigate, and avoid.

I call this "risk register risk management". The main purpose of the process is to get ahead of the future.

But, what if I actually want to take a risk? Now, instead of the four steps of traditional risk management, I need a decision policy and a process to implement it. Do I make or buy? Do I bet on this technology or another? Do I take on this project partner or another? I still the assessment practices, and I still need the monitor and control practices, but my orientation is not towards a risk register.

Different still, what if I want to forecast performance? Shouldn't I look at the undercertainties that are attendant to the estimates I've been given? Isn't history--that is, efficiency--a factor? Sounds like earned value. Could it be that EVM is risk management in disquise? Again, though I really don't need a risk register, I can borrow some of the assessment practices. But controlling and monitoring the performance measurement baseline is a bit different than keeping a watch on the future

Actually all of this is risk management:

Estimate threats, including threats off baseline
Purposefully take a risk
Forecast outcomes from estimates leavened by uncertainties

When managers tell me that they can't get buy-in to the formality of the stepped process to build a risk register and so they can't do risk management, I say "baloney",or words to that effect.

Just driving to work is risk management on a risk you choose to take. And, through insurance, some driving risk you've already transferred. Making a decision is taking a risk on uncertain outcomes; thus risk management. Forecasting next week is risk management. It's only a matter of applying a little common sense, analytical thinking, and some rationalization to be in the game of risk management.

Bookmark this on Delicious

On program management

James T Brown writes:

A program manager needs to have an ingrained sense of organizational mission, must lead and have the presence of a leader, must have a vision and strategy for long-term organizational improvement, must be a relationship builder, and must have the experience and ability to assess people and situations beyond their appearances

"The Handbook of Program Management"

Some say: yes, but so do project managers. And, they are right. The difference is the complexity of the politics, the scale being managed, the amount at stake (too big to fail?), the ability to speak truth to power, and the willingness to take a risk that is consequential to the business (bet the business?)

General Sam Phillips, when taking over the Apollo program deep into the time line, saw that the moon would not be achieved in 1969 with the sequential test schedule proposed by Huntsville for the Saturn 5. The traditional approach: test each stage; get it working; mate them one-by-one; test each stack, and then the whole stack.

General Sam said: stack it all up and light the candle. He took a huge risk. If it worked, the US would make the moon; if it didn't, General Sam would retire and the challenge of JFK would be missed.

That's program management (and the rest is history)

Bookmark this on Delicious