Wednesday, February 27, 2013

I won't take your call, either



Jurgen Appelo is sometimes spot on! In a recent posting (or fit of angst), he declares he won't take your call. I won't either. (If it's important, leave a message and I will call you back)

Here are his reasons (paraphrased), with which I associate myself:



  • I Need Flow, Not Interruptions
  • I Need Awareness, Not Stress
  • I Need Documentation, Not Synchronization
  • I Need Convenience, Not Hassle
  • I’m doing the job I really like the way I like to do it
  • You may work differently, but that's your choice
Sorry (so is he), but that's the way I get through my day. (Oh, and I won't answer the home phone either.. it goes to voice mail if it's important, and I'll call back)

Monday, February 25, 2013

Plausibility and probability


Ponder this for a moment:
Adding detail to the description of an uncertainty makes it less probable (than a more abstract version), though it makes it more plausible

Now move forward to that first tool of choice among risk managers, the risk register. The logic is this:
As detail abounds and abstraction abates, plausibility augments but probabilities must be adjusted; and, in general, probabilities go down.
Try this on for an example:
Scenario -- you are looking at number of interns or co-ops with an idea of placing them in various roles in your project, perhaps business analysis, engineering, or training and business readiness.

Adel is 22 years old, very smart, technically accomplished, studied (among many subjects) philosophy and music, has a strong sense of who she is, and is very detail oriented. She has leadership presence and personal charisma
 
Adel is a professional; she could be successful in some aspects of engineering, finance, business analysis, etc. or even marketing.

The question -- What do we think of Adel? Among those professional roles mentioned, which is the most likely? If engineering, then is she more likely a software designer/engineer who applies the female touch to typically qualitative requirements (needs and wants), or else is she a professional in some other aspect of engineering?

Most of us would look at it this way:
  • Music is a good segue to software; music has patterns, logic, rhythm, and detailed structure -- all attributes of software as well
  • Philosophy is about understanding beliefs, values, ways to think, and ideas -- all elements of human factors
  • And, she's technically accomplished
Most of us would conclude: Adel is very plausibly a software engineer; perhaps she would be very good at human factors engineering. Finance and business analysis seem just too dry for someone who's into philosophy and music. Of course, you can't dismiss marketing out of hand....

Yes! that's it. Adel is most likely a software designer/engineer. That's the highest probability in the distribution of plausible possibilities.

Not so fast
What about other engineering disciplines? Sure, it's possible, but is it probable? Look at how plausible the fit is to software design engineering.

Venn et al
Let's look at the Venn diagram:
  • Among all roles for women, Adel is a professional
  • Among all professionals, Adel is possibly an engineer
  • Among all engineers, Adel is possibly a software design engineer
  • Among all software design engineers, Adel is possibly a specialist in human factors engineering
Every time we add detail, the plausibility improves (given Adel's profile), but the share of the population goes down each time. If this were red balls in an urn with white balls, each level of detail would mean fewer red balls.

What if we are just comparing two abstractions of about equal detail, as in marketing v engineering? The rule does not apply: we've not changed the level of detail from one to the other. We're just comparing two possibilities.

Moving to the risk register
Every time we are challenged to add detail to the risk register, we may well improve plausibility (why else add detail?), but the rule is: that finer grain is less probable than the more abstract idea from which it was derived.

So, what's the problem here? The problem is we confuse plausible with probability. Just because an uncertain event seems very plausible doesn't correspondingly mean it is very probable.

Read more
This discussion is given in much richer detail in Daniel Kahneman's book: "Thinking fast and slow".

Saturday, February 23, 2013

Pipelines and flow 2nd thoughts


Ever notice that long pipelines are not built in a straight line? The bends and corners actually are there for a purpose: risk reduction.

The idea is that as the loads on the pipeline change, the attendant stresses need somewhere to go; and they often go into expanding the length of the pipe. So the bends et al allow the pipe to flex in without pushing the terminals out of place. And of course the pipe is either hung by flexible hangers or mounted on rollers, like the Alaska pipeline.

So it is in projects: the equivalent to bends and hangers and rollers for pipelines in our business -- see pipelines 1st thoughts in this space a few days ago --  are buffers and allowance for spikes (Agile terminology) where odd things can happen without busting the milestones.

Indeed, every schedule, release plan, budget, and milestone should be buffered so that unplanned debt (again, agile vernacular) has a place to go without putting in peril the whole project. Without reserves, initially unallocated, you've only got a hope and prayer, but not a plan.

Thursday, February 21, 2013

Pipelines and flow 1st thoughts

Pipelines and project management. Do these things go together? What are we talking about here?

We're talking about flow... Flow is something every project office manages at one time or another. Stuff moves through the pipe from requirements to deliverables. Sometimes, it needs a bit of help to move it along (We're from the project office and we're here to help!)

Fair enough, but how to help? .... Answer: do the math!

Look at this
Scenario: you've got to certify an object by testing it until you get 100 passes (of the test); or, you have 100 objects that need to pass a test. In this latter case, each object is similar (not identical necessarily) and thus the same test applies... thus, the same test parameters apply.

Expectations: From benchmarks or other calibrated input -- or from an educated guess that you will validate with actual observations -- you (your test manager) estimate -- because you can't know this for a certainty -- that:
  • On the first attempt at the test, 40% of the tests will fail (Yikes!)
  • On the second attempt at the test -- after some diagnosis and refactoring -- 20% of the original population will fail a second time, in this case 20 of the original 100. More work needed.
  • On the third attempt at the test -- after more fix and repair -- all 100 objects have passed. 
Do the math:

  • On the first attempt at the test, 60 objects pass, 40 fail and require rework
  • The second test is a test of the 40 reworked objects; 20 fail (by scenario estimate) and 20 pass. Now there are 80 passes total and 20 back in for a second rework
  • On the third test, all remaining 20 pass (Amen!)
Fair enough. But, how many objects passed down the pipeline? And how much effort did this take?
  • Pipeline flow: 100 + 40 + 20 = 160 objects
  • Test setup for a scope of 160 (resource commitment, test facility reservation, etc), NOT 100
  • 160 units of testing. Effort or flow multiplier of 1.6 on this object-testing process. (call it a 60-20-20 process). Other ratios will yield different multipliers.
  • 40 units of 1st order fix (1st order fixes may be easier than 2nd order fixes)
  • 20 units of 2nd order fix (the harder stuff to fix)
For the resource planner, you've now got the data estimates for all the pipeline processes, the flow parameters, and the monitor/control metrics at various inspection points. Nothing else needed. Time to test.

Tuesday, February 19, 2013

Large numbers and small

Most of us have heard about/read about the Law of Large Numbers, LLN. In a few words: given an unknown population of things, each thing independent of the other, we can deduce the average value of the 'things' by drawing a 'large' sample from the population.

Example: the age of male adults in the user population

Fair enough. Obviously, the project world, the LLN saves a ton of money and time. We only need a sample to figure out the population... this is what is behind a lot of testing but not an seemingly infinite amount of testing. Or, this is what supports polling of the user population rather asking every person in the population if they like this or that about the product we're developing.

Now comes the Law of Small Numbers, to wit: Small samples yield more extreme results than is typical of the population at large, and small samples produce these results fairly often. 

Who says this? Daniel Kahneman on page 110 of his recent book: Thinking Fast and Slow

Small numbers per se are not a causation of extremism; the extreme results are just an artifact of sampling. And, a small population may not be causative of extreme results either. In other words, just because a particular true population is small doesn't mean it's average value is an extreme situation.
.
Ok, now we know this... what's the issue here?

The issue is a bias in the way we tend to look at data.

It's the "bird in hand rather than the bush" thing.

We have a perfectly reasonable bias in favor of certainty over doubt. That is, given the certainty of the data from the small sample, we're more likely to go with it (because it's here and now and in front of us) than doubt it, throw it away, and redesign the experiment.

And, many times we'd be very wrong; perhaps extemely wrong depending on the extremes of the true population.

Bottom line: lies, damn lies, and statistics! Beware those with green eyeshades.

Sunday, February 17, 2013

Tactics v Strategy



Retreat hell! We're just advancing in a different direction
Major General Oliver Smith, US Marines
Battle of the Chosin Reservoir,
November 1950


You're the PM. You've set a strategy.  Fair enough.
And now you're faced with a situation that seems to require tactics at variance to the strategy. What to do?


A metaphor (less daunting than that faced by General Smith) is the sailing maneuver called tacking. Take a look at the picture below.

The lay line is the strategic direction. But sometimes the wind doesn't cooperate (if the wind is directly opposing the direction of the layline, you have to sail away from the layline to pick up some wind energy that's off the line).

It's necessary to tack across the line going way off the strategic course with a tactic nevertheless intended to make progress, albeit minimal, toward the strategic objective.

The 'input elements' are what you do tactically to make progress; the output is progress in the strategic direction. There's a lot more input than there is output, so this is a losing game re efficiency, but it will get you there... slowly.



How does this work in the project world?

Consider this:
  • Your strategy: you want to build an integrated system; you want it to interface to an existing system. (Maybe you're adding a room to your house)
  • Your issue: Doing everthing at once and delivering 'big bang' may be too disruptive and too risky to the customer base. (Your spouse)
  • Tactical response: You design and build "throw away" interfaces that allow a modular, temporary, build-out of capability.

Tactically, you're going way off the baseline, building stuff at extra cost, extra test and integration, extra training that you're only going to throw away and replace (later at some time) with a permanent interface that also has to be tested, integrated, and trained.

Is this an advance in a different direction? You betcha! In many situations, such a tactic -- at variance with the strategy -- is well worth it. Click here to see how it might be otherwise!

Friday, February 15, 2013

Change is a hard thing to do



Change is hard because people don’t only think on the surface level. Deep down people have mental maps of reality — embedded sets of assumptions, narratives and terms that organize thinking.

David Brooks

What struck me about Brooks' statement was the idea of 'mental maps' and 'terms that organize thinking'. Certainly there's no challenge to the idea of 'change is hard' -- this is accepted routinely and said often. But as a root cause, I'd never really thought of the organized thought thing.

Asking (or imposing on) someone to reorganize their mental map of values and beliefs is no small matter. As a matter of professional necessity, many are able to separate their personal map from the new/changed/different map given to them by their job/profession/organization/project -- but many are not, and they are left deeply conflicted and unhappy (perhaps, unproductive as well) ... or they leave.

Sometimes worse than re-mapping, change may trigger fear losing what we've got. To wit: it was too hard to get here to lose it now. (See: Prospect theory)

And, unfortunately fear is always an easy sell, possibly even layering on some elements of paranoia, but always driving resistance and defensive actions.

In short, change is hard!