Two doors for risk managers

---

A narrative*

Imagine two doors to the same room: One labeled risk manager; the other labeled decision maker.
Though the risk manager's door, entry is for the inductive thinker: facts looking for a generality or integrating narrative
Through the decision maker's door, entry is for the deductive thinker: visionary with a need to connect specifics to the vision

And, consider this:

• Pessimists with facts enter through the risk manager's door
• Optimists with business-as-we-want-it enter through the decision maker's door

Then what happens?
Each needs to find the other. In the best of situations, they meet in the middle of the room where this is buffer space and flexibility.

How does the inductive and deductive interact?

Risk management does not set policy for the project office; it only sets the left and right hand boundaries for the vision, or for the project policies.
The space in between is where the decision maker gets to do their envisioning, moving about, perhaps even bouncing off the walls, constrained only by the risk boundaries.

Sound familiar? I hope so. You'll find a similar explanation known as the "project balance sheet" in Chapter 6 of "Maximizing Project Value: A project manager's guide". (Oh -- the book cover is shown below!)

In that balance sheet metaphor, the right side is for the fact-based inductive manager; the left side is for the visionary. And, since those two never agree fully, there is a gap.

And the gap is where the risk is. Risk is the balancing element between the vision and the facts. And who is the risk manager: the project team -- not the visionary. (That's why we pay the PMO the big bucks: to manage the risk!)

---

*This narrative adapted from "Playing to the Edge", pg 428

---

Buy them at any online book retailer!

Linus Torvalds

---

Here's a good TED talk with Linus Torvalds, the geek of geeks, and an early inventor of LINUX and Git

Linus Torvalds transformed technology twice — first with the Linux kernel, which helps power the Internet, and again with Git, the source code management system used by developers worldwide.  "I am not a visionary, I'm an engineer," Torvalds says. "I'm perfectly happy with all the people who are walking around and just staring at the clouds ... but I'm looking at the ground, and I want to fix the pothole that's right in front of me before I fall in."

• 
  

---

Buy them at any online book retailer!

Very short course in risk management

---

Need a quick introduction to risk management? Don't have much time for this?

Try this very short course on risk management (no math required!)

Risk management short course from John Goodpasture

---

Buy them at any online book retailer!

So, you've got to write an RFP

---

Spoiler alert! This posting may be dry to the taste...

Ever been asked to write an RFP (request for proposal)?
It may not be as easy as you think.

My metric is about 2-3 hours per finished page, exclusive of specifications. Specs are normally just imported from an engineering, marketing, or product team. So, it could take you the best part of a week to put an RFP in place.

My outline is given in the Slideshare presentation below

Beyond the outline, here's a few things to think about.

Source identification: Sources, per se, are not part of the RFP, but sources are its audience. And the RFP is written for a specific audience, so sources certainly influence the RFP

Source identification, or better yet: source identification and validation (vetting), is both a science and an art. The science part is an objective list of source attributes; the art part is judgment, admittedly not objective.

Among sources, there's sole source (the only one in the world who can do it) or selected source (the only one in the world you want to do it), but more often an RFP regulates competition among multiple sources.

Award criteria: How are you going to decide who wins?

• Lowest cost, technically acceptable (pass/fail) is the easiest and most objective.  Just open the envelop of all those with passing technical grades and take the lowest cost -- no questions, no fuss
• Best value is not easiest and not entirely objective, but it might get you the most optimum solution. Rather than pass/fail, you get to consider various innovations and quality factors, various management possibilities, what the risk is to you, schedule, and, of course, cost.
  
  Best value may not be lowest cost. That's always controversial, since cost is the one value proposition everyone understands. No one wants to spend more than the value is worth.
  
  The flexibility of best value (or, glass half empty: lack of objectivity) comes with its own risk: the award, if in the public sector, is subject to protest about how the best value was determined.

Risk transfer: what technical, functional, and business risks are you going transfer to the contractor, and are you prepared to pay for that transfer? In effect, you're buying insurance from the contractor.

All other risks are your to keep; you can be self-insured, or pass them off to an insurance party.

Risk methods: Here are some risk methods you can put in the RFP:

• Contract incentives, penalties, cost sharing, and other contract cost-schedule-scope controls: all are forms of risk management practises.
• Liquidated damages: you get paid for your business losses if the contractor screws up
• Indemnity: your contractor isolates you from liabilities if something goes wrong
• Arbitration: you agree to forgo some of your legal rights for a simpler resolution of disputes

Statement of work (SoW): This is the part most PMs know something about, so a lot of words aren't needed. It may be the first thing an interested contractor reads.
The SoW answers this question: what is it you want the contractor to do? A top-level narrative, story, WBS, or vision is usually included.

The SoW is where you can say how agile can the contractor can be interpreting the vision. Think about how anchored to your story you are.

Typically, unless you are pretty confident you are right, you don't tell the contractor how to do the job, but only what job needs to be done.

Specifications: How's and what's for compliance: It is certainly necessary to speak about how something is to be measured to prove compliance; or you can speak to what is to be measured to verify compliance to the specification.

Requirements: And last but not least, the book of requirements is tantamount to the infamous Requirements backlog.

Give these ideas about requirements some thought

• Are they objective, that is: having a metric for DONE
• Are they unambiguous? ... almost never is the answer here. Some interpretation required. 
• Are they complete? ... almost certainly never is the answer here. But, can you admit the requirements are incomplete? In some culture and context, there can be no such admission. Or, you may be arrogant about your ability to obtain completeness. My take: arrogant people take risks and make mistakes...the more arrogance, the larger the risks... etc
  
  But, where you can say: Not complete, then presumably the contractor can fill out the backlog with new or modified requirements as information is developed?
• Are they valid? Can you accept that some requirements will be abandoned before the project ends because they've been shown to be invalid, inappropriate, or OBE (overtaken by events)?
• Are they timely? Can you buy into the idea that some requirements are best left to later? ... you really don't have enough information at the beginning. There will be decision junctions, with probabilistic branching, the control of which you simply can't

RFP template from John Goodpasture

---

Buy them at any online book retailer!

Agile and R/D

---

I was recently asked if Agile and 'R/D' go together.

Good question! I'm glad you asked.

The issue at hand: how do you reconcile agile's call for product delivery to users every few weeks with the unknowns and false starts in a real R/D project?

Let's start with OPM ... Other people's money ... And the first question:
What have you committed to do with the money?
There are two possible answers:

1. Apply your best efforts; or 
2. Work to "completion".

Of course, (1) may be embodied in (2) -- why wouldn't you always apply your best efforts?
But in the R/D domain, (2) is often not a requirement and may be a bridge too far: -- example: got a completion cure for cancer?

"Completion" means more than just effort; it has elements of accomplishment and obtained objectives. You can calculate an ROI applying OPM to "completion"

"Completion" is problematic in the R/D domain: completion implies a reasonable knowledge of scope, and that may be impractical depending on the balance of the "R" with the "D". Heavy "R" implies very limited idea of the means to accomplish; "D" is the flip of that.

The most constraining example of "completion" is Firm Fixed Price -- whether by contract or just project charter. FFP is almost never -- dare I say never? -- appropriate for R/D. Scope is assumed well enough known so that the price can be "firm" and "fixed".

Poor scope definition? Then, ask for "best effort".
The best example of "best effort" is "Time and Materials" -- T/M. If you're working T/M your obligation -- legally at least -- is best effort, though you may feel some higher calling for completion.

And, of course, ROI is problematic with T/M. The money may, or may not, develop anything with a dollarized business return.

And so now let's layer on Agile ... what's in and what's out vis a vis R/D:
Among the agile practises that are "IN" (in no particular order)

• Conversational requirements ("I want to cure cancer")
• Prototypes, models, and analysis (even, gasp! Statistics and calculus, though some would argue that no such ever occurs in an agile project)
• Periodic reflection and review of lessons learned
• Small teams working on partitioned scope
• Trust and collaboration within the team
• Skills redundancy
• Local autonomy
• Persistent teams, recruited to the cause
• PM leadership to knock down barriers (servant leadership model)
• Lean bureaucracy
• Emphasis on test and verification
• Constant refactoring
• Frequent CI (integration and regression verification with prior results)

And, among the agile practises that are "OUT"

• Definite narrative of what's to be accomplished (Nylon was an accident)
• Product architecture
• Commitment to useful product every period
• Intimate involvement of the user/customer (who even knows who they might be when it is all "DONE"?)

There may be a longer list of "OUT"s, but to my mind there's no real challenge to being agile and doing R/D.

---

Buy them at any online book retailer!

Hey, it's OK

---

A few weeks ago, I posted about "they" as the new gender-neutral singular pronoun, as in this usage:

"When the project manager establishes a schedule, they really mean it"

Fair enough

But now, here's news you can use: OK has new partners

• For the older set, it's still ok to use OK in text and email
• For the younger set, KK often replaces OK, but sometimes K replaces KK

Got it? It's only a matter of a simple mapping and substitution code. OK maps to KK, which in turn maps to K, thus OK can also map to K, and the reverse holds as well.

Such coding has been going on for awhile, but now it's been long enough that we can say that the usage is mainstream with many people, even if not with the OK traditionalists!

---

Buy them at any online book retailer!

Through the doors

---

A narrative

Imagine two doors to the same room:
One labeled risk manager; the other labeled decision maker.

Though the risk manager's door, entry is for the inductive thinkers: those armed with facts looking for a supporting generality or an integrating narrative

Through the decision maker's door, entry is for the deductive thinkers: those visionaries with a capacity to envision specifics facts or conclusions that flow from the vision

And, consider this:

• Pessimists with facts enter through the risk manager's door
• Optimists with business-as-we-want-it-to-be enter through the decision maker's door

Then what happens?

Each needs to find the other. In the best of situations, they meet in the middle of the room where there is buffer space and flexibility.

How do the inductive and deductive thinkers interact?

Risk managers do not set policy for the project office; risk managers only estimate the left and right hand boundaries.

The space between the boundaries is where the decision makers get to do their envisioning, moving about, pushed back only by the risk boundaries.

Balance sheet metaphor

Sound familiar? I hope so. You'll find a similar explanation known as the "project balance sheet" in Chapter 6 of "Maximizing Project Value: A project manager's guide". (Oh -- the book cover is shown below!)

In that balance sheet metaphor, the right side is for the fact-based inductive manager; the left side is for the visionary. And, since those two never agree fully, there is a gap.

And the gap is where the risk is. Risk is the balancing element between the vision and the facts. And who is the risk manager: the project team -- not the visionary. (That's why we pay the PMO the big bucks: to manage the risk!)

---

Buy them at any online book retailer!

If the customer is not satisfied .....

---

If the customer is not satisfied ...
First question: How would you know if the customer is not satisfied? Is customer satisfaction one of your project metrics? Good grief, I hope so! If not, you might want to consider this little ditty:
 

• If the customer is not satisfied, they may not want to pay.
• If they are not successful, they cannot pay.
• If they are not more successful than they already were, why should they [pay]?

Niels Malotaux

Paraphrased a bit

---

Buy them at any online book retailer!

Rules to communicate by

---

I've always subscribed to the notion that the top three things for a PM to do are:

1. Communicate often
2. Communicate effectively
3. Communicate widely

Perhaps I should have made "effectively" the first thing on the list. In any event, at every occasion (often, widely), here are the workflow rules for effective communications:

Two rules	Remember this
Rule 1	•       Tell them what you’re going to tell them •       Tell them •       Tell them what you told them
Rule 2	If “they” don’t get it, it’s not their fault

Re Rule 2:

• If at first you don't convey it, back out and reformulate
• You can't show frustration
• You can't show irritation
• You can't blame it on the audience if they don't get it
• You can take it off-line to try again

---

Buy them at any online book retailer!

Council for the product owner

---

I got this idea from a student; I think it has merit, so I'll pass it along here:

The POC
Our backlog is managed by our Product Owners Council (POC), made up of 7 voting members representing the users in the global markets. The voting members are responsible for translating their constituent user requirements into user stories for review by the council.

The council members bring their user stories to council meetings where they are reviewed using a specified criteria before admission to the backlog.

Backlog
We have a large backlog that is prioritized by the POC for each release based on the velocity the development team can deliver, usually 100 points per sprint per scrum team - there are multiple sprints and scrum teams per release.

.... in our case, there are constant trade offs taking place in what gets developed from the backlog. When functional requirements are the focus of a release, the POC meetings become very political with each member arguing for their backlog of stories.

Impacts
The final vote includes a consolidated view from each POC member on the user story's impact on our customer, regulatory environment and user productivity along with a hi, medium, low ranking.

Priorities
When the global deployment was in progress, all user stories that enabled the countries to go-live on the system where prioritized ahead of functional requirements, including some less critical defects.

Standards
Our current direction from executive stakeholders is to standardize our cloud based systems and any requirement that enables the standardization will have precedence over functional requirements.

---

Buy them at any online book retailer!

Hey, we can put it off until .....

---

Are you a procrastinator?
Do you procrastinate and still try to manage schedule?
Do you think of yourself as a procrastinator who can manage risk?
Do you understand that managing schedule risk is tantamount to managing the concept of schedule buffers and the critical chain methodology?

Then, you'll understand that handling your tendency to put things off, and thereby forcing upon you managing slack and schedule buffers are not that much different.

In fact, what I see most of the time is managers wasting slack by doing a "latest start".
At the other end, they've got no buffer or slack to work with.
That is all wrong.
In spite of the risk of incomplete information, getting over the inertia of getting started and getting going on addressing the issues that will inevitably arise is paramount.

So, if you need some help on this, this humorous video is for you!

---

Buy them at any online book retailer!

Job done?

---

Agile Principle 5: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Trust them to get the job done. What job?

• Is it the job described in the business plan and in subsequent project plans, albeit lean plans consistent with the Agile Manifesto?
• Is it the job that has been estimated and scheduled?
• Is it the job as interpreted in near real time by the functional user?
• Is it the job that evolves over several iterations and is adapted to the emergent value proposition?

Trust them to get the job done. What’s the definition of “DONE”?

• Is it done when time/money runs out?
• Is it done when the backlog is fully exhausted?
• Or, is it done when the customer says it's done, or someone else says it is done?

If you can't give a 30 second elevator speech on each of these to the satisfaction of sponsor, product owner, and customer/user, you are not ready for prime time

---

Buy them at any online book retailer!

About 'positive'

---

Keep your thoughts positive
because your thoughts
become your words

Keep your words positive
because your words
become your behavior

Keep your behavior positive
because your behavior
becomes your habits

Keep your habits positive
because your habits
become your values

Keep your values positive
because your values
become your destiny

--Mahatma Gandhi

---

Buy them at any online book retailer!

The new "they"

---

Pronouns are problematic
I've said before pronouns should be banned in technical and official writing .... Why? because people screw up or unwittingly mess up the antecedents.

But, if pronouns are to be used, take note that the rules -- such as rules are want to be -- are changing as a matter of culture and usage, not because the rulebook has been rewritten.

About you
Dating from the 16th century, "you" was plural, with "thee" and "thou" as singular mates. But today "you" is singular most of the time .... but not so fast! "You" can refer to an audience of unknown size, as in the first sentence of my second paragraph. (I'm putting aside "y'all" as not distinguished enough for official correspondence, but hey! here in the South, y'all is just good talkin')

We, of course
And. of course, from about the same time (16th century), or even earlier, the so-called royal "we" has been a singular form of what is traditional thought to be a plural form.

He/she
For the past 30 years or so "his/her" or "he/she" form has replaced the dominant masculine "his or he".

Who is "they"?
The latest news is that "they" is now somewhat like "you". It can be understood to be singular, handily replacing "he/she". Thus, (royal) we might have written:

"When a project manager directs an action, he/she must be cognizant of the teamwork necessary for the task"

 But, now (royal) we can write less awkwardly:

  "When a project manager directs an action, they must be cognizant of the teamwork necessary for the task"

 ESL
 This stuff is hard enough for the native speaker; just think of the ESL's! (English as a second language)
 

---

Buy them at any online book retailer!

Statistics does not require randomness

---

Do you buy this?

"Statistics does not require randomness.

The three essential elements of statistics are measurement, comparison, and variation.


Randomness is one way to supply variation, and it’s one way to model variation, but it’s not necessary.

Nor is it necessary to have “true” randomness (of the dice-throwing or urn-sampling variety) in order to have a useful probability model."
Andrew Gelman 

How about this one?

" ... the #1 neglected topic in statistics is measurement "

All this, and the image, are what Andrew Gelman asserts in his posting here.

Statistics does not require randomness (just variation) --- an arresting statement to be sure. It's what caught my eye.

Gelman is on to a different agenda, however. His point is that in his experience -- which may be more academic than empirical -- measurement is given a back seat, almost neglected in some respects. (Measurement occurs here; lets press on)

But of course, if you are going to stand in front of your team or sponsor and spout statistics, it would be good if you had real observations to back you up. And, shocking as it may seem, you have to take measurements of real events and phenomenon in order to have back-up data

In turn, that leads toward accuracy and precision, cause and effect, and correlation. Perhaps all that is a bridge too far for one posting. I am leaving the building now...

---

Buy them at any online book retailer!

Confidence that feels like knowledge

---

Going back a bit to 1999, psychologist David Dunning, PhD, and his graduate student, Justin Kruger, published their research that in their own words revealed, "incompetent people ... cannot recognize just how incompetent they are."

Now, this isn't to suggest that most, or even a lot of us, are incompetent. That's not the point. The point is we all suffer from cognitive bias. We all believe we are smarter and more capable than we really are. (*)

Incompetence doesn't leave individuals with empty thoughts. They don't feel disillusioned or even cautious. [editorial: Yikes! incompetent and not cautious .... bad karma!]

Stephens goes on:

Inappropriate confidence
Dunning explained that instead, the incompetent are filled with inappropriate confidence that feels to them like knowledge.

The result is people tend to overestimate their skill. They fail to recognize their own mistakes or lack of skill.

They are also poor judges of genuine skill or the expertise of others

Sum it up
So, let's see. If your manager or leader is "full of knowledge", not cautious about risky adventure, and seems to pick poorly equipped or skilled people, then you conclude: Incompetent!


(*) Extracted from an article on "MedPage Today" by Phillip Stephens, DHSC, PA-C

---

Buy them at any online book retailer!

Micrometers, chalk, and axes

---

On a recent aircraft restoration project I learned this 3-step process of mechanics (who knew? You can't make this stuff up!), which in three short statements illustrates the axiom that a process, viewed end-to-end, is not better than it's worst component, and also ...

Precision and accuracy, no matter how diligent, are wasted on the poorest resolution of the process

1. Measure with a micrometer
2. Mark it with chalk (in our case, Sharpie marking pens), and
3. Cut it with an axe! (in our case, shears of one kind or another, or (gasp!) the band saw)

The high precision guess
Ooops! This very process shows up in project management. See: accuracy vs resolution and the spreadsheet -- estimates that are just a bit better than a guess (the axe) are entered into cells with zillions of digits of resolution (the micrometer). Nonsense.

Domain distortion
And, we see it as domain distortion when the defined process crowd with six sigma control limits wants to port their ideas into the domain of the one sigma program office. Again, nonsense (except for the problems defining process in six sigma that is quite portable and worthy)

Small stuff gets washed out in the big picture
It seems I'm constantly explaining why/how the precision of a estimate in a work package more or less washes out at the PMO level in a Monte Carlo simulation of all the work package effects.

Monte Carlo is the 3-step process micrometer-chalk-axe writ large:

1. Agonize over every work package estimate (micrometer, but the WP manager does this step)
2. Enter all the WP data into a simulation package using 3-point estimates and benchmarks (chalk, likely applied by the project analyst)
3. Run the simulation to get the "big picture" (axe)

What I find is those in the PMO wielding the axe seem to get inordinately excited about an outlier estimate here or there. If you're the axe-person, don't sweat the micrometers!

---

Buy them at any online book retailer!

Thoughts on "change"

---

I ran into a blog item on change the other day, at a blog site called Rule of Thumb.

The posting entitled "The Change Curve", depicts a project management adaption of the change model proposed by Elisabeth Kubler-Ross in her book "On Death and Dying" when she described the "Five Stages of Grief"

Rule of Thumb proposes this adaptation for project management of the Five Stages into these six ideas:

•Satisfaction: Example – “I'm happy as I am.”
•Denial: Example – “This isn’t relevant to my work.”
•Resistance: Example – “I’m not having this.”
•Exploration: Example – “Could this work for me?”
•Hope: Example – “I can see how I make this work for me.”
•Commitment: Example – “This works for me and my colleagues.”

Of course there are many other models of both change and change resistance. One useful model of change (not change resistance) is by Kurt Lewin; I like it because it's similar to Deming's PDCA (plan, do, check, act). Lewin's model is three steps:

1. Unfreeze previous ideas, attitudes, or legacy
2. Act to make the change
3. Freeze the new way in order to institutionalize the change.

And, A.J. Schuler, a psychologist, has his 10 reasons about why change is resisted in a paper entitled "Overcoming Resistance to Change: Top Ten Reasons for Change Resistance". His lead-off idea is "doing nothing" is often perceived as less risky than "do something"--in other words, Plan A (do nothing) trumps Plan B (do something). 

But the one I like is that people fear the hidden agenda behind the reformers ideas! Amen to that one.

---

Buy them at any online book retailer!

Backlog management

---

Yikes! My backlog is blocked! How can this be? We're agile... or maybe we've become de-agiled. Can that happen?

Ah yes, we're agile, but perhaps not everything in the portfolio is agile; indeed, perhaps not everything in the project is agile.

In the event, coupling the culprit

Coupling? Coupling is system engineering speak for transferring one effect onto another, or causing an effect by some process or outcome elsewhere. The coupling can be loose or tight.

• Loose coupling: there is some effect transferrence, but not a lot. Think of double-pane windows decoupling the exterior environment from the interior
• Tight coupling: there is almost complete transferrence of one effect onto another. Think of how a cyclist puts (couples) energy into moving the chain; almost none is lost flexing the frame.

In the PM domain, it's coupling of dependencies: we tend to think of strong or weak corresponding roughly to tight or loose.

The most common remedy is to buffer between effects. The effect has to carry across the buffer. See Goldratt's  Critical Chain method for more about decoupling with buffers

But buffers may not do the trick. We need to think of objects, temporary or permanent, that can loosen the coupling from one backlog to another (agile-on-agile), or from the agile backlog to structured requirements (agile-on-traditional).

With loose coupling, we get the window pane effect: stuff can go on in environment A without strongly influencing environment B; this is sort of a "us vs them" approach, some might say stovepiping.

Obviously then, there are some risks with loose coupling in the architecture that bear against the opportunity to keep the backlog moving, to wit: we want to maintain pretty tight coupling on communication among project teams while at the same time we loosen the coupling between their deliverables.

There are two approaches:

• Invent a temporary object to be a surrogate or stand-in for the partner project/process/object. In other words, we 'stub out' the effect into a temporary effect absorber.
• Invent a service object (like a window pane) to provide the 'services' to get from one environment to another.

Of course, you might recognize the second approach as a middle layer, or the service operating system of a service-oriented-architecture (SOA), or just an active interface that does transformation and processing (coupling) from one object/process to another.

With all this, you might see the advantages of an architect on the agile team!

---

Buy them at any online book retailer!

Communication, communicating

---

"They" say that the three most important tasks of project management are:

1. Communicate
2. Communicate, and
3. Communicate

To that end, I recently had an opportunity to try out my skills. My neighbor, a very nice young woman, had to travel on business and asked me to keep watch on her cat.

After a few days she called from the road to check on the cat:
She asked: "How is Millie doing?"
I responded: "Millie is dead"

A pause

She scolded: "You could have let me down more easily; you could've said Millie is on the roof. 
Then later you could tell me she fell off the roof and died"
With contrition, I responded: "Yes, I was insensitive. A lesson learned, to be sure"

A pause

She asked: "And, how is my mother?"
Confidently, I responded: "She's on the roof!"

---

Buy them at any online book retailer!

Sometimes, you have to fire your client

---

Are you an independent practitioner? In the US, 1/3rd of the workforce are independents. An amazing proportion to my way of thinking.

One of the advantages -- and at the same time, one of the hazards -- is that you get to fire your boss; and, you even get to select your boss.

This essay gives a few pointers for the newbie independents -- know when to hold'em; know when to fold'em. You know you've got a bad client when:

• They try to set up the deal at 10pm at night or a weekend... unless you want to work 24x7
• They say it's an easy job they can do themselves.. unless you want to be micromanaged
• They want to talk about themselves instead of the job task... unless you want to be their counselor
• They say they've tried to get the job done with many others, and they all failed.. so might you!
• Rude, insensitive behavior.. unless you like the bad-ass type
• Those that ask for a miracle, or an unlimited commitment.. unless you give up your independence

One suggestion is to beef up the contract; guard your intellectual property rights (something I really pay attention to) and get a non-refundable down-payment. That one has been a sorting parameter for me. Don't forget the non-poaching clause: your client shouldn't have the freedom to hire your staff.

What's the right wording: "We're not a good fit", or "This job is not a good fit for my skills" (I use that one a lot)

And, if they really insist you take the job, add on a premium for your anticipated trouble!

---

Buy them at any online book retailer!

Agile down the ages

---

In the beginning, there was pre-history Agile, almost prehistoric era:

• Before 2000 and the meeting in Utah that birthed modern Agile
• Rogue developers trying various "light weight" and "rapid" prototyping and coding practises. In the SEI world, a ghastly level 1 operation of different strokes for different folks
• Everyone else slaving to command and control -- SEI maturity model uber alles!

And then came the 'our way or the highway' era

• Passionate, almost hysterical, disciples of the paradigm handed down from the Utah mountain
• There is no God but the one Agile God
• "You just don't get it" if you question us
• Push back from the money crowd: "I'm not going to put money into something that has no plan"

And now, the common sense era

• Distinguished Agilists are writing and coaching for the real world where every sprint does not put code into production (shocking!)
• Every deliverable with value is not necessarily code (imagine! other stuff has value-add)
• You're actually allowed to not have a retro session after every sprint; some stuff does not need to be completed after every sprint
• The product owner and customer/user can be surrogates for large organizations
• Plans can be drawn, and a business case for the money guys!
• Stories can be detailed out as requirements

What will they think of next?

---

What more on agile? Available now! The second edition .........

---

Buy them at any online book retailer!

Need help with Monte Carlo analysis?

---

For many years, I've preached the benefits of the Monte Carlo simulation (MCS). For many reasons, it's superior to other analysis paradigms. In network analysis, for instance, it handles the parallel join or 'gate' as no other method will.

In fact, it's this very capability that renders the Monte Carlo superior to other risk adjusted ideas, like the PERT method in scheduling. PERT suffers from an inability to handle the 'merge bias' at gates because PERT does not handle the mathematics of multiplying distributions (required at gates); PERT only provides a means to calculate a statistic for each task.

Architecturally, gates are the weakest construct in schedules, so any failure to handle them is a show stopper in my mind

Quantitative methods schedule from John Goodpasture

I get questions
But, my students ask me invariably: how can the MCS be any better than the 3-point estimates that go into it; if the 3-pointers are guesses, isnt' the whole MCS thing just a crap shoot?

And, the second thing they ask is: who's got the time to triple the estimating problem (from the most likely single point estimate to the trio of optimistic, pessimistic, and most likely) especially in a network of many hundreds, if not thousands, of tasks?

My answer is this: it depends; it depends on whether or not your are the work package leader concerned for a handful of tasks, or the project manager concerned for a network of hundreds (thousands in some cases) of tasks.

If the former, then you should not guess; you should take the time to consider each estimate, based on benchmarks, so that each estimate is has some auditable calibration to the benchmark.

But if the latter, then let the Central Limit Theorem do the work. A few bad estimates, indeed a lot more than a few in most cases, have negligible impact on the MCS results. In other words, the good, the bad, and the ugly tend to cluster around a central value--a phenomenon called central tendency. Thus, at the PM level, you can live without completely solid calibration. Only a few estimates need to be pretty well thought out vis a vis the O,P,ML triplet.

Calibration?
This may sound like heresy to the calibration crowd, but as a politician recently said: arithmetic! Actually, calculus is the better word, since we have to deal with functions. And it's calculus that gives us the tools to understand that a few bad estimates, even really bad estimates, are largely discounted for effect by the integrated effects of all the other estimates. So, let's not get uptight about a few bad eggs!

Nevertheless, to do a MCS, you do need estimates of O, P, and ML. Where do they come from?  All the tools allow for defaulting in a trio to every task. Is that a good idea?

Here's my counsel:

• Take the time to estimate the most likely critical path. The MCS tool will identify other near-critical paths, and may even find an alternate path that is critical (not the one you thought)
• Establish, in the risk management plan, a policy about the defaults values (for % of ML)
  The policy may have several elements: hardware, software, administration, and process tasks. Each of these will have hard, medium, and easy tasks.
  The policy can be a matrix of O, ML, and P defaults for each (Example: for hard software, the policy is to estimate O = 80% ML and P = 200% ML).
  These generally come from experience, and that means from actual results elsewhere, so the defaults are not just picking values out of thin air....there's usually back-up

---

Buy them at any online book retailer!

Fidelity

---

Fidelity, faithfulness, and commitment often seem to be the tension between:

• What the customer/sponsor/user want, and
• What the project charter/scope calls for.

Why so? Why isn't it straightforward? The business case begets the project charter; the charter begets the project plan; and then the project team is off to do the deliverables. Simple, right?

Wrong!

It's never that simple -- though on paper that's the way it should be.

What is reality is a challenge between "fidelity to user expectation" and "fidelity to user specification".

Expectation v specification. How to manage this? First, it's should always be a decision and not just a consequence of wandering off track; and second:

• If you have the latitude to shift "loyalty" from specification to expectation, you are in what the community generally calls an "agile" environment.
• If the decision process takes into account expectation as well as specification, then both of these should be on the list of "inputs" to the decision. And,
• Indeed, there may be two decisions, one for each criteria, with the customer as the referee: does the customer want to honor the spec, or shift to expectation? (Does the customer have the latitude to make this decision?)

Keep this thought close by: what is really at stake is a "best value" outcome: "the most useful and important scope that's affordable."

---

Buy them at any online book retailer!