That agile governance thing

---

We always overestimate the change that will occur in the next two years and underestimate the change that will occur in the next ten. Don't let yourself be lulled into inaction.

Bill Gates

I wonder if Bill's quote is on Ballmer's wall somewhere next to MS's strategic plan for mobile computing?

You have to wonder if their governance, given their size, is open enough to innovation? Surely, all the look-ahead trend setters are not exclusively in Silicon Valley.

Maybe they need to be more agile?

Governance and agile methods may seem like an oxymoron—but not so. A means to govern is essential for orderly project functioning. Without governance, the advantages of adaptive and evolutionary methods could be overwhelmed by functions bolted together haphazardly and rendered operationally ineffective, expensive to maintain, and not beneficialdisadvantageous to customers and stakeholders

Governance 'should's'
•A governance program should be purposeful about maximizing the business potential of a project.

•Governance should be dedicated toward minimizing the risks to business performance.

•A governance program should enable and promote innovative and imaginative solutions, and

•Governance should deter behavior that strays too far from norms.

In short, a governance program exists for five reasons that are in effect the governance mission statement:

Governance Mission

1. To oversee and approve investment on behalf of business beneficiaries;

2. To codify decision-making rights to enable make it possible for teams to have autonomy and freedom of maneuver;

3. To enable and promote innovation, evolution, and technical excellence within the framework of architecture and operating norms;

4. To be the ultimate arbiter of risks that affect business performance and accountability; and

5. To provide accountability for compliance to mandatory standards.

Governance is built on quality principles. Four principles guide an effective governance implementation:

Governance Principles

1. Proportionality: Governance should be applied proportionately to the amount at stake.

2. Clarity: Governance should provide clarity for mission and purpose, scope boundaries, decision-making authority, and decision rights.

3. Subsidiarity: Governance should respect the principle of subsidiary function: governance should not intrude into the management of functions that are best left to functional and project managers.

4. Lean: Governance must be lean, timely, and responsive, respecting agile principles to provide enough, but ‘just enough’, oversight and control to accomplish the governance mission.








A project management tip: Decision policy for the project manager

• The simplest policy for decision making is... always make a best-value decision based on the collective value of the risk-weighted factors

• When deciding among alternatives, pick the alternative that informs the business most favorably, even if there is suboptimum result for the project

Bookmark this on Delicious

Wicked isn't evil

---

I've been thinking about some unreasonable problems. Some call them 'wicked'. The wicked problem isn't evil. The wicked problem is one where the issues interlock and become interdependent, perhaps even circular: the infamous Catch 22. There's no definitive statement of the problem. In fact, until the problem a solution is proposed, you may not know what the problem is!

In a wicked situation, the solution defines the problem

Climate change may be the ultimate wicked problem of our age. Where do you start? Where do you end? Everyone has a stake, and so everyone is going to be touched; some will lose and others won't.

Actually, in the public policy domain, wickedness is all too common. So, what does a project manager do?

There are a few things that seem to work

• Assemble a coalitionn of the willing. Keep the number of stakeholders as small as possible
• Lead with a solution rather than the problem; solve things bottom up. The solution finds its problem, as it were
• Create a sense of urgency so momentum builds
• Keep the scope contained; do small-ball things to get started

Some get at this problem with the IBIS, the issue based information system. You can learn more by viewing my IBIS slide share (below) or take a read through this posting from Eight to Late. You'll read this:

IBIS consists of three main elements:

• Issues (or questions): these are issues that need to be addressed.
• Positions (or ideas): these are responses to questions. Typically the set of ideas that respond to an issue represents the spectrum of perspectives on the issue.
• Arguments: these can be Pros (arguments supporting) or Cons (arguments against) an issue. The complete set of arguments that respond to an idea represents the multiplicity of viewpoints on it.

There are some graphical tools that go along with this, and they are discussed and displayed in the posting.

The Wicked Problem

View more PowerPoint from John Goodpasture

Bookmark this on Delicious

Central vs decentralized change management

When I talk to project managers about protocols for change management, they all gravitate to central management. The reasoning is consistent: they see a need for a holistic systems consideration of any project change. Who can blame them for that?

And, when I talk to team leaders, they tell me the workflow through central management is too slow, the experts are not "up there", and we (team leaders) have to explain it all to 'them' anyway. They make the same decision we would, so where's the value add?

And, of course, as in all things like this, the answer is: YES.

It's all a matter of judgment about impact. Of course there's a place for the systems view, and of course the team is very capable of trapping many small changes before they clog the workflow to the high command.

But I'm really surprised at the few PMs or team leaders who see it this way. It seems all or nothing in their mind. I wonder what's in the water there're drinking. To me, it's all about reasoned delegation--do only what only you can do.

Bookmark this on Delicious

Must do vs Should do

In my classes about agile methods and risk management, I entertain discussions about requirements management, and specifically whether or not students buy into Must Do/Should Do requirements--either in the RTM or the backlog

This is another way of talking about MoSCoW (except I've shorted this discussion to just the M and S)

• M - MUST: Describes a requirement that must be satisfied in the final solution for the solution to be considered a success.
• S - SHOULD: Represents a high-priority item that should be included in the solution if it is possible. This is often a critical requirement but one which can be satisfied in other ways if strictly necessary.
• C - COULD: Describes a requirement which is considered desirable but not necessary. This will be included if time and resources permit.
• W - WON'T: Represents a requirement that stakeholders have agreed will not be implemented in a given release, but may be considered for the future.

So, most of my hardward project students say: Once the customer has decided on the RTM, there's no debate and no M vs S; everything's a M;

And, most of my software project students say just the opposite: there's room for the S's in the backlog; and

Most of my students who deal in the public sector or work through contracts, regardless of the technology, say: a contract is a contract... there's no room for the S's.

What do I say? I say requirements (a synonym for scope) need slack just like the schedule. A plan without slack is more a hope than a plan. If both scope and schedule have slack, then by extrapolation the budget has some slack. The payoff for slack is predictability.

Some may call it sandbagging: fair enough, sometimes there are sandbaggers that give the slackers a bad name. But nobody can predict with anything other than prayers where a no-slack project is going to wind up.

I used to build hardware; a lot of it and complicated stuff. I never met a RTM that didn't have some flexibility in it, even with a contract. Now, an enlightened contract will be an award fee contract. An award fee contract rewards (with an award of fee) thinking and innovation. What's not to like about that?

I never accept "never" in the project business. We're not doing six-sigma production; we're doing stuff for the first time, and so we can expect 'stuff' to happen. That's where slack comes in... to handle the 'stuff'

Bookmark this on Delicious

EVM and disjunction

The situation is disjunctive when everything must go right; nothing must fail. To say it another way: either failure or success is possible, but not at the same time. And disjunctive congnition occurs when one thing is given two distinctly different appearances or interpretations (we call it a 'success' but it's really a failure).

So much for the dictionary. Why should project managers care?

Well, for one thing, there's a cognitive bias to be concerned with that can affect many project situations:

Disjunctive bias: There is a bias towards the understating the likelihood of at least one failure and thereby overstating the likelihood of complete success

What's the usual countermeasure, the usual risk response? Make every single constituent very reliable so that nothing is allowed to fail.

Feel comfortable? Well, the problem here is that the math is against you.

The probability of at least one failure among a number of independent components (call them work packages, for convenience) is a binominal problem in probabilities, given by this messiness (click to see).

So, for example, consider this table of trouble, where
N = number of components
K = number of successes
N-K = number of failures

N	K	N-K	Prob of success	Prob failure	Prob at least N-K failures
6	5	1	90%	10%	35%
4	3	1	90%	10%	29%
2	1	1	90%	10%	18%
6	5	1	99%	1%	6%
4	3	1	99%	1%	4%
2	1	1	99%	1%	2%
60	59	1	90%	10%	1%
60	59	1	99%	1%	33%
60	57	3	99%	1%	2%

The last couple of rows appear counter-intuitive. But, remember this is about a least 1 failure (or 3).

• Third from the bottom tells us the likelihood of only one failure is not good
• Second from the bottom tells us the likelihood of only one failure is good
• The bottom row tells us that 3 failures is pretty improbable.

But still, with the high reliability, it's remarkably probable to get at least one failure in 60 objects, even though not three!

So, what if these objects are work packages, and the success/failure is 0/100% evaluation of the earned value?

What the table tells us is that even with hugely reliable work package managers, the likelihood of at least one failing is much higher than the individual failure rate, but the likelihood of more than one such failure is quite low. To wit: at least one failure: 33%; but three failures: only 2%

Thus, the cognitive disjunctive bias: who would have predicted 1 chance in 3 of getting a WP failure (on a WBS of 60 objects) when there is only 1 chance in 100 that a WP will fail?

If you want more about how this is calculated, visit the Khan Academy.org

Bookmark this on Delicious

Safety Cases

There's a case to be made for the 'safety case', so says Matthew Squair.

---

“A safety case is a documented demonstration

by an organisation of the way in which hazards at

a facility (read: weapon system) are managed”

IEAUST, 2002

“A documented body of evidence that provides a

convincing and valid argument that a system is

adequately safe for a given application in a given

environment”

Adelard

---

Ok, that's what it is, but why do we need it?

– You may need a tool for managing the safety of a plant or system
• Identifying and managing the safety impacts of change
• Setting safety targets
• Confidence in meeting safety targets

– To address and reduce legal liability:
• Statute (COMCARE)
• Common law (Negligence)

– To make a reasoned argument that a system is (or will be) safe

– It may be a direct or implied regulatory requirement

– To organise and structure a project or plants safety data,
information and logical argument

– To identify constraints and where tradeoffs of safety against
mission effectiveness have been made

– To identify aspects of operational risk management

Good grief! I didn't know I needed it, but now I do...

Bookmark this on Delicious

What part of delegation do you not understand?

---

"...He only does what only he should do"

Anonymous

The utter simplicity of this thought is its power: "He only does what only he should do". What else is there?

But, though simple as it is, this statement is a source of constant frustration to those being micro-managed. Why can't "he" (and, not to leave out 'she') just go away and let us get our job done? Perhaps he/she doesn't have enough to do, or worse: he/she doesn't know what to do.

Maybe we should make it more complicated so that "he" will pay more attention. Let's cite the Principle of Subsidiarity :

---

It is a fundamental principle of social philosophy, fixed and unchangeable, that one should not withdraw from individuals and commit to the community what they can accomplish by their own enterprise and industry

---

The 'community' in this case is the project office and the project manager; or the portfolio office and manager. Or worse: the project sponsor and (aghast!) the stakeholders. (Who among us wants to managed by the stakeholders? ... barbarians at the gate, to be sure!)

Here's the general idea and criteria of 'good' un-delegation:

• The action (un-delegation) must be necessary because actions of individuals or teams alone will not achieve the objectives of the action (the sufficiency criterion)
• The action must bring added value over and above what could be achieved by individual or teams alone (the benefit criterion).
• Decisions should be taken as closely as possible to the project team or individual (the close to the individual criterion)
• The action should secure greater freedoms for the individual (the autonomy criterion).

Sufficiency, benefit, closeness, and autonomy: Words to delegate by!

Bookmark this on Delicious

War is hell

---

The Korean War was planned to last only a few days so we did not plan anything in case things might go wrong. If you plan a war without planning for failures then you are asking for trouble

Yoo Sung Chul

North Korean general

1950

Well hello!!

I hope this is news only to the war planners at work in North Korea in the spring of 1950. (I threw in the date to refresh the memory of those who have forgotten the "forgotten war")

Most projects aren't war; not remotely close. But all projects have one thing in common with war: uncertainty. And, to plan a project without planning for failures seems as nonesensical as General Yoo's statement.

Which is another way of saying: a plan without slack is a hope, but not a plan.

---

If you have forgotten Korea (1950-1953), an excellent telling is in the 2007 book "The Coldest Winter" by notable author David Halberstam

Bookmark this on Delicious

If then, why not now?

Our theme today is "If then, why not now?", suggesting that if by waiting we think things will get better (or be better), why don't we take the actions to make things better now?

We see this in risk management with the "Cone of Uncertainty", something that Dr Barry Boehm--more famous for the CoCOMO model and the Spiral model--wrote about in his book "Software Engineering Economics" (though he called it a funnel).

A temporal dimension is built into the Cone of Uncertainty. In other words, the cone is "uncertainty vs time"; the mouth of the cone is in the far future. It's in the far future that we're optimistic. Things are bound to be better "then". In the present and near future, we're more pessimistic (there's less time to deal with issues that are upon us), though pessimism and optimism may be symmetrically distributed (it's as likely to go well as to go bad)

So, it's not as good "now" as we think it will be "then". That sets up the uncertainty of the future. Boehm called it a funnel because in his metaphor lots of uncertain events were scooped up or allowed to enter the wide front-end of the funnel, but only a few risks actually materialized and found their way all the way through.

So, back to the opening question: what can we do now that will make things better than if we waited for the funnel to do its magic? We could cast the question another way to stimulate a thought: if we spend time and energy now optimizing for "then", wouldn't there be some benefit to optimizing for a result closer to now?

(In essence, this is part of the agile thought process: instead of waiting all the way to the end ("then"), let's start getting some of the project benefit now.)

Of course, the then/now question is rhetorical: there's no answer for it outside a specific project context. Nonetheless, is there ever a case for procrastination? Why not get on it now, take some actions now, to get a better effect now, rather than waiting?

Or, to ask it the agile way: why put all the effort into optimizing for an end result... why not redirect some of the effort toward benefits closer to now?

Bookmark this on Delicious

Sample ACP questions

LeandingAnswers has a posting on sample ACP questions for those thinking of taking the exam. I don't have an independent assessment of how accurate these questions are, but they seem reasonable for the purpose.

The sample questions cover the landscape, from the Agile Manifesto and Principles, through burn charts and teams, to velocity calculations and SCRUM ideas.

To answer accurately, you should know stuff like Principle #2, honoring change, is about the time period: early in development vs late in development.

And, would you know where the business investment in the backlog is best applied?  If not, you should review how agile involves the business in the requirements business. After all, business holds the proxy for stakeholder interests in the project, and really no one else does.

Some questions are framed such that the idea is to look for something to eliminate. Sometimes, it's a matter of eliminating the worst of the possibilities, even though all may be possible.

Of course, LeadingAnswers is not an exclusive place to look for help on the ACP. A Google search turns up all kinds of help... as you would expect with something with this much interest (and need I say money?) behind it?

---

For those of you who read this blog regularly, you know I am one of PMI's instructors for their eSeminarWorld course on Agile Project Management. So, now you know (disclosure)

Bookmark this on Delicious

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