Tragedy of the Commons -- Extended

Are you familiar with "the tragedy of the commons"?

If not, in a few words: A common resource is overused until it fails, thus imperiling everyone who is using it. In other words, each user of the commons optimizes for themselves, ignoring the the larger consequences and advantages, until there is a total system failure.

The usual example given is a number of farmers grazing their cattle on a common pasture until the pasture fails entirely and endangers everyone's livestock.

In a posting entitled "The Tragedy of the Risk Perception Commons" Matthew Squair explains a behaviorial risk that is related:

A person, perceiving a risk, as a member of a group affected by the risk, has an obligation to speak up and direct attention to risk assessment and mitigation. But, if in doing so, the person is cast down by the group's members and made unwelcome or unproductive in the group, then the person faces the optimization dilemma in full force:

• Optimize on a personal level and withdraw the challenge to the group to address the risk, thereby re-establishing themselves with the group; or
• Sub-optimize on a personal level (in trade for optimizing on the larger level) by continuing to challenge the group to address the risk

I don't have the answer and neither does Squair or others who've studied the problem.

However, game theory, which I've talked about before, is a tool for just this situation. Two parties, seeming uncollaborative and even hostile in some scenarios, more or less muddle through with a suboptimum solution because they can't bring themselves to do better by joining their collective skills and reasoning.

In Game Theory 101, this is similar to the classic "prisoner's dilemma". The prisoners couldn't figure it out, and we aren't likely to do that much better unless everyone understands the tragedy of the commons.

 

Bookmark this on Delicious

Agile in the infrastructure domain

"They" say agile isn't for hardware. Perhaps so. But one of my agile project management students made this comment about agile in the IT infrastructure domain. He says he wants to:

...... incorporate a hybrid (traditional/agile) methodology in the IT infrastructure (servers, networks, etc) side of the business because I believe it is a huge competitive advantage in the managed services industry to show value earlier than traditional PM can do.

He goes on with this bit:

I have been finding that by incorporating the iterative, phased approach from agile allows each phase to use the traditional externally dependant waterfall method.

It shortens the original planning phase, since it is now distributed accross phases, reduces errors in estimating because each phase is estimate individually, handles change better, and delivers a better end result.

Could an agilist say it better? Of course this is not science; it's just one person's opinion with little benchmarking behind it. Nevertheless, it's instructive that agile ideas are not just about software where it's relatively easier to change things, and thus things get changed. In the more physical world of hardware, there is a place for agile ideas.

Bookmark this on Delicious

Monitor and Control

If there's one behavior that's almost an axiom in the project management business it's "monitor and control" the project

And the tool guys are all over this, offering all manner of tools for monitoring, and some tools for controlling.

So, what is the "monitor and control" agenda? Here's my list (without the usual references to project plans, earned value method, IMP/IMS, etc. All good practices to be sure, but too specific for the point I am trying to make):

Project monitoring (and monitoring tools and systems) has these functionalities:

• Sense, measure, and gather metric data
• Interpret data and compare to milestones, budget, goals
• Report data (meetings, dashboards, reports)

Project control

• Impose or remove constraints, to include authority, responsibilities, policies, standards, rules, work flow
• Allocate or de-allocate resources (money, staff, tools, environment)
• Plan and execute responses to monitoring data (act on the monitoring)

Monitor and control should form a closed loop (I'm all about closed loops. Open loops are dangerous because it means that whoever is in charge of input is clueless about outputs, and vice versa. You can't really control what you monitor if the loop doesn't close. And, of course it has to be timely: a poorly phased loop actually causes more trouble than it avoids)

• Plan
• Do
• Monitor the 'do'
• Control according to the monitor data
• Monitor the control activity

And go around this loop monitor-control-monitor as many times as necessary
Of course, at some point it may be necessary to re-plan the baseline

Bookmark this on Delicious

Good will

"Good will" is an accounting term. It means, in effect, the intangible worth of something that is given a monetized value. You won't find good will on the balance sheet.  It comes up all the time when valuing a company for sale. Good will is the value of the relationship that a company has in the market place.

So, we aren't accountants here, so what's the point?

The point is that intangible value appears a lot in the value proposition of projects. And, good will comes up a lot in change management exercises. We often call good will "soft benefits". Soft benefits have a dubious cause and effect. Yes, we know there's some correlation (things move together) but one always wonders if they are cause and effect (A moves because B moves). What's the alternative? The alternative is a 'confounding factor': A is moved by C, but so is B, thus A and B move together.

This may be more information than you need.

Here's a change management example of 'good will' from one of my students:

The strong success that we realized came through recognizing the organizational significance of the 'front-line, Level 1 operations guys', whose positions had at one time been considered prime for outsourcing.

Once we helped leadership to recognize the breadth of these guys' scope, and good work and goodwill that they had facilitated, we were able to make the strong case that thier roles were much more critical than had previously been understood.

Making the case for these guys helped to bring their loyal support in terms of understanding the 'as is' and helping to drive out and optimize the 'to be.' Transparency prevailed and the outcome was definitely a win-win situation.

Win-win! You gotta like it when a plan comes together

Bookmark this on Delicious

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

FOURTH OF JULY

---

This office is closed on 4 July due to circumstances beyond our control

Sign on British Consulate in the USA

Bookmark this on Delicious

That moral hazard thing

Moral hazard: we learn these from the knowledge base at wikipedia:

A moral hazard is a situation where there is a tendency [by a work package manager, for example] to take undue risks because the costs are not borne by the party taking the risk.

And, somewhat related, we are informed that "adverse selection" is described this way:

Adverse selection is a situation where an individual's demand for [relief from risk] is positively correlated with the individual's risk of loss (e.g. higher risks buy more insurance), and the [project manager] is unable to allow for this correlation in the [project plan]

---

This discussion about moral hazard came up with some of my students in my Agile PM class. We were discussing how tightly to schedule a project.

My thinking: a plan without slack is not really a plan; it's a hope.

Two ways to get slack planned into the project baseline:

1. Assume there's always going to be "labor loss"... That is, no one can really work 100% of the time they are schedule to work. It just doesn't ever seem to work that way. From dental appointments to coffee bar chat, some labor is lost. I always estimate 15%
2. Put in what I call "pipeline buffers", to allow some "breathing" in the schedule plan. (I may call it pipeline buffers, but others call it critical chain method) 

(Many reading this blog may have never seen an install of pipelines; nevertheless, I'll describe it by saying that what they do is put in expansion joints every few lengths by letting the pipe zig and then zag. These zig zags absorb the changing length of the pipe with temperature, something like an accordion, and something you have to worry about in the physical world)

So, now moral hazard: the team knows there is slack built-in. In the agile business, we don't schedule for more than 85% of velocity, and we always put in a zero activity iteration before every release (a release is some number of iteration's deliverables). If the team knows this, it creates a moral hazard. They know they can use the slack without having to pay the price of the longer schedule.

And, that creates the correlation of the adverse selection dilemma: a demand for schedule relief on the one hand, and a correlation with the propensity of work packages and iterations to run over.

What's a PM to do to fight moral hazard? Here are a few ideas:

• Incentives to do good, i.e. pay for performance (or 'show me the money')
• Penalties if the schedule is blown
• Keep the labor loss to yourself; that just happens. No point in offering it up to the general population
• Make it hard to use the buffer time (after all, the PM should be in charge of constraints, not the inmates)

In effect, any schedule that's going to work has got some slack (some room to zig and zag)

About architecture

I probably misnamed this posting. It's as much about architecture as it is about the architect.

In the fifteenth century, an architect was a liberal arts guy with an eye for structure, symmetry, and form. Consider this passage from a description of the time:

A true architect can't be just a master of his trade. He had to be a well-rounded person....let him be educated, skillful with the pencil, instructed in geometry, know much about history, have followed the philosophers with attention, understand music, have some knowledge of medicine, and be acquainted with astronomy and the theory of the heavens".

(Of course, the pencil was not invented until late 16th century, so this passage from 100 years earlier is translated from the Latin or the Italian with some flourish)
And then we learn this:

Architecture is the defining art. It creates civilization. It constructs homes and lays out cities...It designs temples, revealing the will of the gods...It produces machines, guaranteeing victory in time of war and prosperity in time of peace... It builds empire

---

I will say this: some of my best software people were music majors. The poetry of music fits well the poetry of software.

Someone who builds empire!
I always wanted one of those. (I got no closer than being someone's Vice President, and we didn't have much of an empire to speak of)

But on a serious note, you can see these passages at work in some of the world's most interesting buildings (See: Opera House, Sydney), but also in some of the most elegant digital processing, to say nothing of the beauty of the recent Apple products.

Architecture is alive and well all around us and in every project, whether we acknowledge it or not. Everything we design or build has architecture--no structure, tangible or intangible, is without it--and every structure, whatever it is, is probably for the better if an architect has weighed in.

And, I've always advocated an architect on the project team. Now, I'm wondering how I ever did without one.

---

Quotes taken from "Da Vinci's Ghost" by Toby Lester



Bookmark this on Delicious