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