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