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

Risk and opportunity link innovation

This observation from one of my risk management students

I have found that many times that the occurence of a given risk results in the opportunity to solve a problem in a new way. We have developed a number of innovative solutions as a result of one risk occuring that required an innovative solution to mitigate the risk

Craig Ballenger

This is part of the ageless discussion about whether risk and opportunity are two sides of the same coin. Many academics say yes; most practitioners say no. Thus, practitioners have not accepted the leadership of the academics on this topic.

The PMBOK, to cite one reference, puts them together in one chapter. But they are handled completely differently from the perspective of management actions:

PMBOK risk responses:

Accept, transfer, mitigate, and avoid

PMBOK opportunity responses,on the other hand:

Exploit, share, enhance, accept

And, it's not just the PMBOK. Most projects put risk management in it's own stepped process: plan, identify, assess, respond, and then iterate based on results. Most projects put opportunity through some kind of change management and budget prioritization process, often requiring program or portfolio coordination.

Thus, two management paradigms and thus two attitudes about risk vs opportunity.


Bookmark this on Delicious

One plus One

You think that because you understand "one" that you must therefore understand "two" because one and one make two. But you forget that you must also understand "and." -Sufi teaching story

Donella H. Meadows. Thinking in Systems: A Primer

Bookmark this on Delicious

Four rules for business success

I've recently learned that Sam Palmisano, the retiring--and successful--C chief of IBM, has four rules for business success

1. “Why would someone spend their money with you — so what is unique about you?”
2. “Why would somebody work for you?”
3. “Why would society allow you to operate in their defined geography — their country?”
4. “And why would somebody invest their money with you?”

That's swell for IBM, but his successor--a lady C Chief in waiting--has been named, so most of those reading this blog are unlikely to lead IBM for at least the next 10 years. Thus, I move to the project management domain.

Caution: changing domains is often problematic. Some things just don't port from one to another. But try this for fit:

Why spend money with you is the grist of project PROPOSAL THEMES. If you ever written a proposal for competitive work, the first question to be asked is "what's the win theme?" The win theme, like its counter part, the project theme, is for the seller the way to win business; and is for the buyer the reason to buy from the seller. It's a bilateral theme to be viewed from both parties.


Why would somebody work for you is at the heart of TEAM RECRUITING. In the agile space, teams are recruited, not assigned. But if you've not got the elevator speech on why work for our team, you may have the right to recruit, but what if nobody wants to work with you? SOL!

Why would society allow you to operate is an obvious THREAT for the risk register. If you can't handle the politics, your project may be DOA and over before it begins!

And why would somebody invest their money with you is a question is all about BUDGET SCARCITY. Stakeholders have choices. It's a rare company that has more to invest than there are quality projects to fund. So, we're right back to competition, only this time we're competing for resources. Can you speak to NPV, IRR, and EVA? If you can't handle this alphabet challenge, you may find your project high and dry waiting for another opportunity.

Bookmark this on Delicious

Complexity and thinking

Jurgen Appelo has an interesting slideshare presentation on complexity and system thinking. As with all Appelo's stuff, it's humorously illustrated to offset the weighty topic.

Of course, I'm not the first to comment. You might want to click here.

At first glance, you may not want to wade through 191 slides (JA is notoriously  non-lean on slide count because he uses a lot of white space, but I like that because it's easier to catch the main point). But, what this presentation is about is what a dozen or some system thinkers think about systems and complexity.

In other words, there's about 160 pages of quotations, one per page. JA has grouped them nicely in several categories.

Here's a couple of points that caught my eye:

People in organizations do not normally follow the steps proposed by system practitioners .... Instead, the organizational reality is that engage in daily conversation, gossip, political negotiation, power plays, acts of resistance, and personal agendas; in short, local interaction.

Ralph Stacey, Complexity and Organizational Reality

The phenomenon Stacey describes is what Alstair Cockburn calls communication by osmosis. It's much richer than what you get virtually on the end of a phone circuit.  And, it explains a lot why it's hard to really get business benefits promised by business re-engineering, especially ERP projects.

A team is a complex adaptive system (CAS), because it consistes of parts (people) that form a system (team), and the team shows complex behavior as it keeps adapting to a changing environment

I have a little heart burn when people put the label "CAS" on inanimate systems because the definition of CAS is really the definition of the behavior of biological systems do adapt and mutuate in ways not possible with inanimate systems. But I'm ok with Apello's use with teams because the parts are biological who do adapt to circumstances.

Bookmark this on Delicious

The death of "shall" and "will"?

"Shall" and "will" have been my guys for a long time! From the moment I took Requirements 101 I learned a few things:

• The buyer "will" do this and that (for the seller) Seller = developer; or contractor if selling to a project office
• The seller "shall" do this and that (for the buyer) Buyer = customer; or project office if buying from a contractor
• Never put two required outcomes in the same statement; in other words, no compound requirements that confuse "or" and "and".

But  the agilists are push aside "shall" and "will" as relics of mid-20th century project doctrine. Now, we have "conversations":

"As a {role}, I want {some capability, feature, functionality, or performance capability/capacity} so that {something can be accomplished}"

And, the conversation, often written informally on a card posted on a wall in the war room is just the beginning. From the card ensues the real conversation, ultimately documented by developers in design level test scripts and by business analysts in business scenario scripts. The former are used for verification, and the latter for validation (The ole V & V of the "V" model).

The little card on the war room wall all but disappears; it not retained or maintained. What's the memorial to requirements? Test scripts.

Is this a bad thing? Actually, no. On large scale projects, like an ERP installation, I've found that the "shall" and "will" business is less effective than business scripts supported by process diagrams and workflow tables.

So, perhaps the time has come to retire "shall" and "will" from a whole class of projects.

  Bookmark this on Delicious

Defect tracker for Agile?

Tools linked to process, and process linked to tools, are always grist for debate in the agile space. Defect tracking is one of those processes that begs the question: to engage with a tool or not? Many say: put the defect on a card, put the card on a wall in the war room, and work it into the backlog as a form of requirement that is commonly labeled "technical debt".

 

For sure, that's one way to handle it. Of course, the cards are perishable. Many say: so what? Once fixed, there's no need to clutter things up with a bunch of resolved fixes.

 

Lisa Crispin and Janey Gregory, writing in their book "Agile testing: A practical guide for testers and Agile teams", have a few other ideas. From their experience, there are these reasons to use an automated tool to capture and retain trouble reports:

 

• Convenience: "If you are relying only on cards, you also need conversation. But with conversation, details get lost, and sometimes a tester forgets exactly what was done—especially if the bug was found a few days prior to the programmer tackling the issue.If you are relying only on cards, you also need conversation. But with conversation, details get lost, and sometimes a tester forgets exactly what was done—especially if the bug was found a few days prior to the programmer tackling the issue."

• Knowledge base: Probably the only reason to keep a knowledge base is for the intermittent problems that may take a long time and  a lot of context to work out. The tracker can keep notes about observations and test conditions

• Large or distributed teams: It's all about accurate communications. A large or distributed team can not use a physical war room that's in one place

• Customer suport: If a customer reports the defect, they're going to expect to be able to get accurate status. Hard to do with a card hanging on the wall if the customer isn't physically present. 

• Metrics: Agile depends on benchmarks to keep current and up to date team velocity.

• Traceability: It's always nice to know if a particular test case led to a lot of defects. Obviously, many defects will not come from a specific test; they'll be found by users. But it never hurts to know.

Of course, there a few reasons to be wary of a database-driven DTS tool.  Number one on my list is probably one that makes everyone's list:

• Communications: It's not a good idea to communicate via notes in the DTS. Communications belongs first face-to-face, and then in email or text if a record is needed. DTS is for logging, not for a substitute for getting up and talking to the counter-party.

• Lean: All tools have a bit of overhead that does not contribute directly to output. Thus, maximum lean may mean minimum tooling.

Bottom line: Use the tool! I've always had good results using tracking tools. It just take a bit of discipline to make them almost transparent day-to-day

Bookmark this on Delicious

Back to the real world?

In one of the myriad prognostications on "the future" we've read around here, we learn that in 2012 we begin the great migration back to the real office, where real people collaborate, innovate, and create. In fact, we are told to expect these behaviors:

• The landline, the jacket [for men], the commute, the handshake, and above all the office itself.
• Out of fashion will be the virtual office in which employees sit hunched over laptops in their local Starbucks, joined to their colleagues by webcam and e-mail.
• Employees will turn up to work at predictable hours five days a week, and will comport themselves with greater formality than before.
• Face-to-face meetings will be preferred to video conferences; ideas will be exchanged not by tweet, but by the coffee machine.

The Economist, December 2011

Well, that's great news for agilists.

Agile is built around person-to-person face-to-face collaboration. It's pretty hard to do what Alistair Cockburn calls "communication by osmosis"--that is, absorbing what's going on around you--if you're not there to absorb.

Communication by osmosis is sort of the body language of office communication. There's something in the air,perhaps in the water, and you have to be there to get a sense of it. Otherwise, you're out of loop on some of the best stuff.

But of course everyone is not doing agile, so what's driving "back to the real world". Three things:

1. Defense: people with jobs want to be seen, and be seen productively engaged.

2. Culture: Remote working has been disastrous for spreading corporate culture, and

3. Inheritance: Virtual working has made it difficult for younger workers to pick up the tricks of the trade. And, that sword has two edges: older workers can learn from the young--new tricks, and all that!

And, to top it off, Volkswagen has turned off corporate email for most of its workforce during off hours. Good grief! Does that mean returning to a regular work day when stuff got done in the work place?  What's next?

Bookmark this on Delicious