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!

Kill the messenger?

---

The messenger: “Unfortunately, my King … here I am, unwilling and unwanted … because I know that no one ever welcomes a bearer of bad news.” —Antigone by Sophocles, circa 442 BC
 

The surprise: “It is pardonable to be defeated, but never to be surprised.” —Frederick, the Great

Who's listening?
Pedro C. Ribeiro, writing in NASA's ASK magazine, has a nice posting on risk perception. He reports on a study that tells us that nearly 3/4ths of all those that report a risk condition to the PMO feel as they are not heard or listened to.

The messenger of bad tidings is not welcome! Hello! No news there, to be sure!

Failure of leadership:

Postmortem analyses, inquiries, and audits of failed projects often uncover streams of unheeded warnings in the form of letters, memos, e-mails, and even complete reports about risks that were ignored, past lessons not learned, and actions not taken—a failure of leadership that creates the conditions for a “perfect storm” of problems that could and should have been prevented, but nevertheless catch leaders by surprise.

Who's to see?
Remember: even Nassim Taleb defines a black swan from the eye of the beholder. What's a calamitous surprise to some may be foreseeable to others. 

So, even though the PMO may not be able to see around the next corner, they may be some with extraordinary powers of sight that need to be listened to. Ignore them at your peril!

---

Buy them at any online book retailer!

Beware common sense!

---

This bit comes to us from Neil deGrasse Tyson from his book "Accessory to War"

"What separate great scientists from ordinary scientists ... is the capacity to .... not let common sense dictate or constrain their thinking.

The formidable English physicist Issac Newton, for instance, questioned the the fundamentals of light and color. Who in their right mind would have thought that ordinary light -- white light -- was composed of colors at all?"

In contemporary parlance, this is "thinking outside the box", a meme of behavior and mindset which Tyson might have us believe separates the really good from the only adequate.

Of course, there is a case for "only adequate" which probably describes the bulk of practitioners since the truly gifted and great are out on the tails, as it were. "Only adequate" gets us safe and sturdy, risk averse, tried and true, and free of controversy. The ball does not advance very far, but then it's not supposed to.

On the other hand, "only adequate" isn't going to get you "E = mC2" and all the rest. If you are going to try to convince the world of space-time warp, best to avoid common sense!

---

Buy them at any online book retailer!

Percent complete -- Boo!

---

Perhaps I've said this before. I certainly intended to. But, percent complete is a worthless metric

Not a value measurement:

Percent complete is a ratio. The ratio is dimensionless, whereas value has a dimension; it can be measured.

Percent complete is not only not a measure of value completed; it’s really not even a measure of completeness, even if some things are "completed" at less than 100%.

I say this because, as a ratio, both the denominator and numerator are in play. Thus, “percent complete” is a moving baseline.

What about Agile?
In the Agile space, percent complete is replaced entirely with “remaining effort”. In other words, the Agile management focus is on three questions:

1. How much do I have to do—to wit: backlog for the iteration, release, or project
2. How much have I done already—backlog burned and done, and
3. How much do I have left to do? Note: how much left includes the WIP.

Since the backlog is dynamic—some new things added, some things abandoned, some things left over as debt from prior iterations—you can see that percent complete is meaningless.

The backlog at any given moment is the denominator (burned, WIP, and not started); the numerator is the backlog burned. Both numerator and denominator change from moment to moment, rendering the metric useless for management purposes.

---

Buy them at any online book retailer!

Excel is watching you!

---

If you've ever managed a project with a really large data set, say the payroll for a bunch of 1099 developers, or the sales records that you're trying to translate and import to a spreadsheet, you may need to watch a couple of important cells to let you know what's really going on:

• Summary totals; 
• error codes; 
• record totals, etc. 

Excel gives the PMO a convenient tool in the Watch Window, found on the tool ribbon with Formulas/Formula Auditing

To use it, just open the watch window by clicking the icon, then click on Add Watch in the Watch Window, and then select some cells.

Thereafter, every time you click on Watch Window in the Formula ribbon, it brings up your list with the latest values. My only irritation with the functionality is that the change is not time tagged. Nonetheless, pretty convenient to use.

---

Buy them at any online book retailer!