Wednesday, March 30, 2011

Possible but not probable?

“We can only work on precedent, and there was no precedent,” .
Tsuneo Futami
Former Tokyo Electric nuclear engineer
Director of Fukushima Daiichi in the late 1990s
As reported March 27, 2011

One of the problems likely encountered in the risk management and assessment of possibilities is a phenomenon called 'anchor bias'.  The essence of anchor bias is be influenced by an initial condition, fact, or assessment, and then be inhibited from making radical adjustments, even in the face of counter information. 


Once they made the proclamation that this was the maximum earthquake, they had a hard time re-evaluating that as new data came in.
Greg S. Hardy,
Structural engineer
Specialist in nuclear plant design and seismic risk
As reported March 27, 2011

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

Monday, March 28, 2011

FINAO and punishment

I was reading Dennis Brandl's blog about the "Seven Habits of Unsuccessful Projects" and I stopped on #4:

Project management has a “failure is not an option” mentality. While this is a good motto for a mission statement when your team is going to the moon, it leads to bizarre behavior in IT projects. If failure is to be punished, then people don’t report failures and management is often blissfully unaware of major problems. Similar unproductive project mottos are “right the first time” and “there are no problems, only opportunities.”

I've spent 10 years in back-office IT projects. From my experience, I don't buy that one. "Failure is not an option", aka FINAO, is not a succeed or punishment paradigm. It's succeed because there's a lot at stake, and failure is not to be accepted if humanly possible to avoid. But is most assuredly not "fail and you are punished".

If it comes to such a extreme, the operating plan goes out the door, but then in comes a new plan. Of course, the new plan may be only a sketch and it may depend on very agile working by all concerned, but no one was thinking punishment in that engineering shop in Ohio that came up with the rescue capsule for the Chilean mining rescue. Far from it!

Check what else I've written about the original source, Gene Kranz, for more explanation.

Coincidentally, I am reading the novel "Child 44". The setting is Stalinist Russia. The theme that underlies much of the story line is "fail and you are punished". Thus, fear permeates all activity. And fear defeats trust. Without trust, there is no team work.

If you've got a fail/punishment paradigm, my advice: change it now!

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

Saturday, March 26, 2011

Metaphorical arguments

At Eight to Late, there's an interesting post on metaphors that show up in arguments. And, from the metaphors come the action verbs. Here are a few examples, in the form of metaphor category followed by action verb:

  • War: win, counter, defend, attack
  • Art: craft, perceive, express
  • Cooperation: contribute, share, complement, achieve
  • Journey: step-by-step, go and going
  • Quest: explore, look, examine

Of course, the word 'argument' often carries a bit of baggage.  Argument could be as benign as stating a propositon, as in debating: one makes the argument for a point of view.  But I don't think that was the context for the posting at Eight to Late. If war is the metaphor, then argument is about disagreement.

 Instead of argument, how about 'discussion'?  'Discussion' seems to lighten the load; discussion generally carries the context of extended conversation, perhaps even reinforcing and informative.  Certainly that's the case for the 'art' metaphor, perhaps even the journey.  And so perhaps we argue like warriors, but otherwise have discussions like diplomats.

And, what about 'negotiation'?  Maybe 'negotiation' is a part of cooperation.  Is getting to 'yes' a discussion, argument, or negotiation?  Does it matter? 

It matters in tone and it may matter in outcome.  My experience is that most things start well enough as discussions, may evolve to a negotiation if there is something to be decided, and degrade to argument [war] as failure in the original context, but perhaps as an extension in another.  After all, von Clausiwitz said ".... war is just the continuation of policy by other means."

Does von C's view mean argument is just discussion and negotiation by other means?  Perhaps.  But, I don't recall a successful negotiation achieved by war-like argument.  So, perhaps the metaphor breaks down, as most metaphors do.

The bottom line to this, if there is a bottom line, is be conscious of the action verbs.  You'll know when things are moving toward war.

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

Thursday, March 24, 2011

Risk management meets climate change

What will they think of next?

In a report issued last month, a number of leading scientists wrote a report that they are sending to Congress recommending that risk management, modeled on the practices of the DoD, other national security guardians, and the intelligence community, be applied to climate change concerns.

Titled "Degrees of Risk: Defining a Risk Management Framework for Climate Security", the report recommends that risk management might be a good tool for assessing and managing perceived climate risks.

Forgive me, but isn't this blindingly obvious, no matter what you think the science of climate is portending? How could it be otherwise?

Hopefully, Congress and others will embrace the idea that risk management is what you look to for managing risk.

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

Sunday, March 20, 2011

Three quantitative risk concepts

Repetition and review are good--Malcom Gladwell says it takes 10,000 hours to be expert at anything--so here's a few words that will take a few minutes on three important quantitative concepts every risk manager should know:

Concept 1: Centrality
Most phenomenon of interest to projects, particularly naturally occuring phenomenon, tend to cluster around a central value, given enough samples or examples. Obviously, this let's out the so-called long-tail 'black swans', but project managers can go a long way if they understand that central clustering is the norm ... in effect, the default.

The measures are average and expected value. The former is applicable when the data is known; the latter when the data is probabilistic and the numerical value is not known until an event occurs. In calculating the average, each value is equally weighted; in calculating the expected value, each value is weighted by its probability.

Concept 2: Variation
Yes, things cluster, but that simply means that around the central value there is a range within which things are nearby the center, but not exactly on the center.

It's more likely things are close to the center than not: that's an effect of centrality on variation

The measures of variation are variance and standard deviation.  Variance is a figure-of-merit related to the distance, or error, between a point in the range and the central value. Standard deviation is a more direct measurement of distance, having the same dimensions as the points in the range.  Engineers refer to the standard deviation as the root-mean-square, or RMS value.

Concept 3: Position
Sometimes it's enough to know just the position of a data value in the range.  Names associated with position are quartile and percentile, and the so-called 'Z' position. 

Z is just a value in the 'standard range' divided by the standard deviation.  [A 'standard range' has a '0' average] For project management purposes, the 'Z-position' extends +/- 3 units from the average or expected value for most situations.

Dividing a range into 4 quartiles requires defining 3 boundary points: Q1, Q2, and Q3.  Quartile is all about count, not value per se.  Just rank all the values in the range in ascending order.  Divide the count into quarters.  Q1, Q2, and Q3 are the count values that divide the range.

If a value is in the first quartile, that means that 75% of all the values in the range are greater than the Q1 value, and by extension 75% of all the values are greater than any value in the first quartile.

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

Friday, March 18, 2011

More agile in the government

Last month, Glen Alleman had a post on 'agile is coming', and so it is to a Government near you.

Recently announced in the UK for instance:
Monday, February 7, 2011 The United Kingdom Department for Work and Pensions recently announced it plans to employ the Agile project management framework for all future development programs, according to a recent report.

The department is often required to provide end-users and partners with reliable custom software applications. According to the report, completing development on time and within the allocated budget is often challenging.

Stever Dover, delivery director for the DWP, told the decision to adopt Agile project management does not indicate a belief that all of the department's previous projects were done wrong. "The old way, provided it was supported by effective collaboration, worked and did deliver, but not as efficiently," he said.

According to Dover, Agile offers the department a method of producing higher quality software in a shorter period of time. "Agile is delivering for us, and it is our intention not to use the old style of project management for new projects in the future," he stated.

Of course, agile in the enterprise, or enterprise agile, is not exactly the animal you read about on most blogs, hear about in much agile training, or read about in the many books on the subject. For real projects in a real business, there still needs to be a business case....after all, someone needs to pay for this stuff... and of course most enterprise projects are not a hand full of developers living on pizza. So, there needs to be attention to the project people network that will extend far beyond what can be supported by eye-to-eye contact, a requirements backlog system that will support requirements maintenance, and independent system test that verifies and validates.

I've written a book on this subject, drawn from my own experience, but Scott Ambler at is a good source for other points of view.

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

Wednesday, March 16, 2011

For I have Linked

Has networking really come to this, that we need to pray for deliverance?
Our Father, who art in pixels,
linked be Thy name,
Thy Web site come, Thy Net be done,
on Explorer as it is on Firefox.
Give us this day our daily app,
and forgive us our spam,
as we forgive those
who spam against us,
and lead us not into aggregation,
but deliver us from e-vil. Amen.

I did not author this; another poet did. 

I'm not sure there's a message here for project managers, other than to recognize--not that managers don't already--that for many on the team electronic networks, and the access and functionality they convey, are a religion. 

So perhaps my advice is: Beware the culture mismatches between those that are so committed, and those that are not.  The former relish minutiae, precision if not accuracy, and scheduling and timing in small increments; whereas the latter may be strategic, abstract, and approximate.

In the words of yet another poet: "It takes a village..."

 Bookmark this on Delicious  

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

Monday, March 14, 2011

Oxygen Rules

Laszlo Bock said: "My first reaction was, that's it?"

As recently reported, Bock was commenting on Google's "rules" on how to be a good manager, something that grew out of an internal project begun in 2009.  Bock runs 'people operations' at Google, what is HR to the rest of the corporate world.

And a glace at the rules, below--a result of data mining thousands of data items at Google about team and individual performance, and manager performance in a project named "Oxygen"--are not exactly earth-moving in their insight.  On the other hand, there is a certain elegance in their simplicity and completeness. And certainly anyone who has struggled to be a good manager, or has worked for a good manager, or has worked for a bad manager, will recognize the universal wisdom of these 'rules,.

Not that this stuff hasn't been written down before and can't otherwise be found in sources.  Indeed, there's a lot of common sense in what's written down.  But it never hurts to take a moment and review and reflect:

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

Saturday, March 12, 2011

The Kepler project sample

Project KEPLER, a NASA project to survey the galaxies and locate new planets that could possibly sustain life, had an initial data dump from its on-orbit satellite detector-collector last month, about which it was written
.... statistical tests of a sample suggest that 80 to 95 percent of the objects on it are real, as opposed to blips in the data, [although] .... new results represent only four months’ worth of data on a three-and-a-half-year project ....

Well now: what about samples? Is 'sampling' something project managers need to know about have a bit of understanding?

I know the answer to this one: Yes, sampling is a technical practice that can translate into cost and schedule savings, and potentially reduce other risks in the project.

Here's why I think sampling belongs in many projects:
  • Often not economical to obtain and evaluate every data point in a population
  • Usually not practical to reach every member of the population.
  • Often not possible to know every member of the population.
  • May take too much time to observe, measure, or interview every member of the population
  • May result in too much data to handle even if every member of the population were readily available–to include the expense of large volume data handling, and timeliness of large volume data handling

Of course it's always good to check with the experts, and in the modern era--that is, since 1953--William G. Cochran has been at the pinacle of experts.  His book, Sampling Techniques, first published in 1953 and now in it's 3rd edition is more less the defining word on the subject.  To the reasons above, Cochran would add:
  • Greater accuracy because, he says a few people of the highest degree of training can concentrate on getting it right with only a limited amount of data to look at, and
  • Greater scope because without sampling some problems would just be too hard to tackle.  Sampling brings them within reach.

On the other hand:
Sampling introduces risk into the project:
  • Risk that the information derived from the data sample may not accurately portray the population–there may be inadvertent exclusions, clusters, strata, or other population attributes not understood and accounted for.
  • Risk that some required information in the population may not be sampled at all; thus the sample information may be deficient and may misrepresent the true condition of the population.
  • Risk that in other situations, the data in the sample may be outliers and misrepresents the true relationship to the population; the sample may not be discarded when it should be
There are two risk assessments to be made.
  1. “Margin of error”, referring to the estimated error in the measurement, observation, or calculation of statistics related to the sample data
  2. “Confidence interval”, referring to the probability that true population statistics are within the range of the estimated statistics as calculated from the sample data 
Tensions in the project
Sampling introduces a tension between the budget managers and the risk managers. Tension is another word for risk.
  • Budget managers want to limit the cost of gathering more data than is needed–in other words, avoid oversampling–and thereby limit cost risk
  • Risk managers want to limit the impact of not having enough data--risking an error of interpretation--and thereby limit functional, feature, or performance risk.
Project policies
The risk plan customarily invokes a project management policy regarding the degree of risk that is acceptable in samples:  [Nation: this not the land of Six Sigma!]
  • “Margin of error” is customarily accepted between 3 and 5%
  • “Confidence Interval” is customarily a fixed percentage between 80 and 99%, most commonly 95% or 99%
My opinion: project managers should make the investment to understand what they're getting into and what the policy implications for the project really are.

Sampling protocols:
Don't try this at home.  But, given that you have access to someone trained in statistical protocols, the project's sampling protocol is designed by the risk manager to support the project manager's policy objectives.

Photo: Jet Propulsion Laboratory of NASA
Are you on LinkedIn?    Share this article with your network by clicking on the link.

Thursday, March 10, 2011

Agile reality v rhetoric

Scott Ambler posted his ideas about whether agile reality is keeping up with agile rhetoric. He listed seven specific examples that he thought needed some explanation in a 'X v Y' format, with X being the rhetoric and Y being the reality as he sees it from his view of what practices should be.

Among the seven, here's the one I liked the best:
Simple designs are best BUT the architecture should be thought out early in the lifecycle. Too many developers interpret the advice to focus on simple designs to mean that they should build everything from scratch. Yet more often than not the simplest design is to take advantage of what is already there, and the best way to do that is to work closely with people who understand your existing technical infrastructure. Investing in a little bit of architectural envisioning early in the lifecycle enables your team to identify existing enterprise assets that you can leverage, to identify your architectural options, and to select what appears to be the best option available to you. The details will still emerge over time, and some decisions will be deferred until a later date when it’s more appropriate to make them, but the bottom line is that disciplined agilists think before they act.

So why do I like this one the best?

Because architecture is a part of every project deliverable schema, whether or not it's acknowledged or not. Architecture is the definitional framework that holds all the disparate pieces together and gives rise to the value of the whole over the parts.

I say that every project needs the role of architect, and every project needs to start with architecture, even if it's only called storyboarding or some such.

In another recent post here at Musing's, I discussed the management hazard of not concentrating on the bigger picture. It's all part and parcel of the same thing.

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

Tuesday, March 8, 2011

Throwing darts at Monte Carlo

Kailash Awati writes the blog Eight to Late; in a recent post, he makes a humorous but quite informative explanation of the Monte Carlo process by analogy with a drunk throwing darts at a target.  Entitled "A drunkard's dartboard: an intuitive explanation of Monte Carlo methods", he addresses a paradox that may have occurred to many, to wit:
.... that one can get accurate answers via random numbers. 

Permit me to comment:
'accurate' only in the sense that a Monte Carlo will provide distribution of possible outcomes [answers] weighted by the probability [strictly: the probability density.  That is, probability per unit of output], and the accuracy of this range of answers is highly dependent on the inputs provided to the simulation tool.  So, it's still a matter of guarding against "garbage in/garbage out"

Nevertheless, in his clever post, Awati uses simple geometric shapes to demonstrate the answer to that paradox. In the end, I was convinced!

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

Sunday, March 6, 2011

Cost-schedule v Value

Most of the time, I call myself a program manager, and if occasion demands: a project manager. In this post my mantle is 'Value Manager'.

Is there a difference?

To some, yes. Project managers put cost and schedule on the front burner, whereas value managers may turn that burner down a bit. Whether value or project, scope and performance, the other two legs of the four-legged 'iron triangle' are priorities regardless of labels.

Most of my experience over a life-long career has been managing value. Ten years ago, I wrote a book about it, just after my first ERP program--a portfolio of about 10 projects, including PeopleSoft.

Here's the way it's gone for me:

Mission first: As a DoD engineer in the Vietnam and cold war era, I was instructed that mission trumped all else.  In fact, a 2-star general once told me: "If it's not in the plan, then I will personally change the plan!".  Posted to the 'outpost of freedom', Berlin, during the cold war, I arranged for a C-5 to put a sensitive cargo down in Templehof.  C-5--the largest cargo plan in the world--into Templehof?  Wasn't that built in the '30s for the DC-3 era? If'd you've stood on the tarmac at Templehof, you know what I mean.  Was this in the plan? NO, but...

Contractual commitment: I moved on to the aeropace and defense industry.  There, I signed onto contracts pledging to meet cost-schedule-scope in about as much of an iron triangle as you can get.  And our team moved heaven and earth to meet those commitments, cost-schedule-and scope.

Cost/Benefit: Having won the cold war, I took on back-office IT with my first ERP project.  The sponsor made it clear: I could have whatever money I needed so long as it was paid for.  Cost/Benefit was the metric.  Obviously, there's no benefit if you don't deliver on the scope, the performance, and the value for the user.  It's a complex dynamic, more complex than just meeting a cost or a schedule because you hold business value in your hands.

P&L: I took on executive responsibility for a business unit having IT, application development, and business operations.  We produced documents from an electronic database under court order for discovery.  My imperative from my boss: never blow a court-mandated schedule, but make a profit--or else!  My project managers were given two orders:  never blow a schedule; keep expenses under control, but deliver all the documents.  Expense control is the secret to profit on the bottom line of a P&L.

The WEB: I managed an agile, or agile-like shop for 18 months.  Our shop reflected the sponsor's sense of value: Be quick!  Don't fall behind the competion.  And  don't let the vision of the future get in the way of the present--thus, be incremental.  And so we were.  Our backlog was constantly changing; we met and bettered the competition with quick strikes targeted to maintain our market lead, and kept ahead of customer expectation.  Fortunately, ours was a business-to-business shop, so we had very sophisticated customers who were enormously helpful.

So, is value manager different from project manager? (GoTo TOP)

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

Friday, March 4, 2011

More on Agile and the DoD

Close upon the heels of PMI's announcement of their embrace of Agile, the US DoD is stoking the fire as well, evidenced by the industry conference in April, to wit:

According to their marketing release:
Why Attend —The Value Proposition

Agile development and test will improve DoD’s acquisition of IT applications leveraging cloud computing and service oriented architectures used by information sharing applications such as collaboration (strategic and tactical intelligence) analysis, ISR sensor “fusion” processing, coalition and joint tactical operations, logistics and sustainment support, transportation functions, geospatial and decision support apps, medical or health care record sharing, etc.,).

The new paradigm is significantly different and should not be confused by today’s spiral development process. Agile sprints are comprised of (smaller line-of-code) projects, month not years time driven release commitments with integrated development, operational, interoperability and user acceptance testing.

Once implemented, DoD user approved requirements tailored for each sprint (vice large Requirement comprised Major Programs of Record) will create a new “partnership” relationship amongst industry and government users, developers and testers.

Yea verily, and press on!

Of course, I'm not an unbiased commentator.  I've written a book on agile in large scale organizations, and I've written papers on the topic of DoD and Agile.  I've worked as a Program Manager within DoD, and as contractor for DoD.  So, count me among those who hope their initiative succeeds.

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

Wednesday, March 2, 2011

When Normal isn't normal

Jurgen Appello is, by his own description, "a Dutch guy" who is somewhat of a humorist, an illustrator, and a proponent of Agile. He also writes a lot about complexity, and the effects of complexity on systems and projects.

A recent posting, "The Normal Fallacy", takes on both misconceptions and lazy thinking, and reinforces the danger of thinking everything has a 'regression to the mean'.

Before addressing whether Appello's explanation of a fallacy is itself falacious, it's worth a moment to review:
Complex systems differ from simple systems from the perspective of how we observe and measure system behaviour. 

It's generally accepted that the behaviour of complex systems can not be predicted with precision; they are not deterministic from the observer's perspective.

[I say observer's perspective, because internally, these systems work the way they are designed to work, with the exception of Complex Adaptive Systems, CAS, for which the design is self-adapting]

Thus, unlike simple systems that often have closed-form algorithmic descriptions, complex system are usually evaluated with models of one kind or another, and we accept likely patterns of behaviour as the model outcome.  ["Likely" meaning there's a probability of a particular pattern of behaviour}

Appello tells us to not have a knee jerk reaction towards the bell-shaped Normal distribution.  He's right on that one: it's not the end-all and be-all but it serves as a surrogate for the probable patterns of complex systems.

In both humorous and serious discussion he tells us that the Pareto concept is too important to be ignored. The Pareto distribution, which gives rise to the 80/20 rule, and its close cousin, the Exponential distribution, is the mathematical underpinning for understanding many project events for which there's no average with symmetrical boundaries--in other words, no central tendency.

His main example is a customer requirement. His assertion: 
The assumption people make is that, when considering change requests or feature requests from customers, they can identify the “average” size of such requests, and calculate “standard” deviations to either side. It is an assumption (and mistake)...  Customer demand is, by nature, an non-linear thing. If you assume that customer demand has an average, based on a limited sample of earlier events, you will inevitably be surprised that some future requests are outside of your expected range.

In an earlier posting, I went at this a different way, linking to a paper on the seven dangers in averages. Perhaps that's worth a re-read.

So far, so good.  BUT.....

Work package pictureThe Pareto histogram [commonly used for evaluating low frequency-high impact events in the context of many other small impact events], the Exponential Distribution [commonly used for evaluating system device failure probabilities], and the Poisson Distribution, which Apello doesn't mention, [commonly used for evaluating arrival rates, like arrival rate of new requirements] are the team leader's or work package manager's view of the next one thing to happen.

Bigger pictureBut project managers are concerned with the collective effects of dozens, or hundreds of dozens of work packages, and a longer time frame, even if practicing in an Agile environment.  Regardless of the single event distribution of the next thing down the road, the collective performance will tend towards a symmetrically distributed central value. 

For example, I've copied a picture from a statistics text I have to show how fasts the central tendency begins.  Here is just the sum of two events with Exponential distributions [see bottom left above for the single event]:

For project managers, central tendency is a 'good enough' working model  that simplifies a visualization of the project context.

The Normal curve is common surrogate for the collective performance.  Though a statistician will tell you it's rare that any practical project will have the conditions present for truly a Normal distribution, again: It's good enough to assume a bell shaped symmetric curve and press on.

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