Viewing Posts by Michael Hatfield
I'm linking the procurement and human resources chapters of A Guide to the Project Management Body of Knowledge (PMBOK® Guide) together for the simple reason that I have absolutely no idea why they're in there in the first place. I have never been in or encountered an organization of any size that lumps human resources and procurement departments under the head of project management.
PMBOK® Guide for the Trenches, Part 6: Quality
| We hear a lot about how quality can make a project management world full of butterflies and rainbows. But I have a bone to pick with quality.|
C.F. Martin has making guitars since 1833. The company's quality is legendary -- and so is its price.
It was Martin that developed the Dreadnought body style, so called because its size was increased dramatically to boost volume and bass response. The resulting models, the D-18 and D-28, became the standard by which all other acoustic guitars are measured.
Sir Paul McCartney played a D-28 at his recent White House performance. Elvis Presley started off with a D-18 and moved up to the D-28 as soon as he could afford to. And from the time I started playing acoustic guitar, I wanted one.
I finally scraped together enough for a D-28, and my obsession started before I even left the store.
The custom cases are so precisely made that you can't leave the strap on the guitar. So, I bought a quick-disconnect device for it.
Then, my salesman informed me that Martin's lifetime guarantee doesn't cover cracks for guitars because of low humidity. In my home state of New Mexico, that's a problem. So, I bought an advanced humidifier and after-market insurance.
And, of course, I needed new strings. (One does not put medium-grade strings on a D-28.)
The beginning of my enslavement to this highest of high-quality musical instruments had begun.
The first time I used it in public, I was aware of a certain sense of dread. I realized that I was walking around with US$2,300 worth of fragile wood strapped to my torso. Microphone booms, chairs and other instruments loomed dangerously close by. My proximity bubble -- that area around your person where you're not comfortable with others -- had just grown significantly.
In past writings I've been a tad harsh on the quality fanatics, primarily because they can (and often do) place project managers in a position of being vulnerable to cost and schedule variances should high standards prove elusive. Those project managers should take heart: The ultimate consumers of your projects are held hostage to these same high standards, as I have come to realize.
I tried playing my other guitars, but it's too late. I have been spoiled. I have also reached the conclusion that quality has a distinct downside.
| Frankly, I have no idea why or how the perfectly working lingo of the old cost/schedule control system criterion (C/SCSC, also known as "the C-Spec") has been superseded by the more recent, trendy jargon, but I am pretty sure project management, as a discipline, would be greatly enhanced if only we could go back to the way it was.|
When the C/SCSC came out in the United States in the late 1960s to early 1970s, the Department of Defense insisted that organizations with whom they did business had a fairly advanced project management information capability. Because this insistence was attached to large amounts of business, companies took notice and quickly put into place the codified project management practices called for in C-Spec.
Coming as it was from the United States Department of Defense, you just knew there would be plenty of acronyms.
The time-phased budgets were known as the budgeted cost of work scheduled, which quickly became BCWS and shortened again to just "S."
Similarly, earned value was the budgeted cost of work performed, abbreviated to BCWP and then "P."
Actual costs, being the actual cost of work performed, then ACWP, had the same last initial as earned value, so it became just "A."
Three of the most important concepts in project management information theory had been reduced to single letters. It could even be argued that this entered the realm of code: a code that only the true believers of project management knew by heart.
But there was no earthly reason to know what the project managers were talking about if you were a newly minted MBA or an accountant.
Their faces would likely assume aspects not unlike those of archeologists trying to understand hieroglyphics pre-Rosetta Stone.
Project managers could discuss their cost and schedule performance openly, even the ugly parts, without fear that the non-believers of project management had a clue what was being asserted.
Indeed, the folks in accounting took the opposite tack. Their communications lost their original precise definitions and are now mainstream. The "bottom line," originally the last line of information on a profit and loss statement, entered the business lexicon and eventually became synonymous with the final outcome of a process or event.
But you know you're in the company of project managers if you overhear a discussion on the merits of the CPI and SPI at the cume level (the reporting of the schedule performance index and the cost performance index at the cumulative, or life-cycle-to-date, level). The Defense Acquisition University actually publishes a "Gold Card," which is, in essence, our secret decoder ring, defining most of the commonly used project management acronyms and formulae.
At least we have the "Gold Card." What do y'all think?
| If PMI ever invites me to rewrite the risk section of A Guide to the Project Management Body of Knowledge (PMBOK® Guide) I think there are two things I would change.|
The first deals with the inclusion of "upside risk," or opportunity, as part and parcel of risk management. I don't think it belongs. As my exhibit A, I cite the Oxford English Dictionary definition of risk: 1 a situation involving exposure to danger. 2 the possibility that something unpleasant will happen. 3 a person or thing causing a risk or regarded in relation to risk: a fire risk.
As author Mark Twain said, "Beware the man who would win an argument at the expense of language." Beyond the semantics, though, let's consider the three most prevalent ways of analyzing risk and see if they apply in managing a proposal backlog (a listing of an organization's outstanding and upcoming job bids -- or opportunities).
The simplest (and crudest) risk analysis technique is classification, in which you basically go through your work breakdown structure at whatever level and assign high-, medium- and low-risk classifications to the tasks. Associate each classification with a percent, e.g. high may mean 50 percent, medium 25 percent and low 5 percent.
Multiply the percentages by the original budget/time estimate, and you've done a risk analysis (of sorts). Try this with the proposal backlog, and you'll inevitably look astonishingly inept.
Then there's decision tree analysis. For each activity, assign alternative endings, with their impacts and odds of occurrence. Unfortunately for "opportunity" management, the only two possible outcomes of a submitted proposal are that you either win the work or you don't. Data on the gray middle is pretty useless when there's no gray middle.
Finally, Monte Carlo analysis is essentially a decision tree on steroids, with lots of statistical chicanery thrown in.
My second objection has to do with the use of risk management after the cost and schedule baselines have been set. I agree that prior to the finalization of the baselines, risk analysis is crucial to identifying and quantifying cost and schedule contingency amounts. The risk analysis can lead to informed decisions on how much and what type of insurance to buy, and what sort of alternative plans should be in place if a contingency event occurs.
But once the baselines are final, persisting in risk management strikes me as institutional worrying expressed in mind-numbing statistical jargon. To what end? Unless the response to a contingency event (in-scope, uncosted) was to significantly change from how the project team would have reacted normally, what difference does it make if it was anticipated?
I'm looking forward to the responses to this, and not necessarily from just the risk management aficionados.
Update: Risk management experts and enthusiasts are encouraged to join PMI's new Project Risk Management Community of Practice.
| What would be your reaction if I told you there's a widely practiced profession out there that pays well, with (usually) nice working conditions, and it involves continuously providing its customers with the wrong answers? |
Welcome to the wonderful world of cost estimating.
Take for instance, the original estimate for the National Ignition Facility project--it was just over US$1 billion. The final budget was US$4.2 billion. The Central Artery/Tunnel Project, also known as the "Big Dig," was originally estimated at US$2.8 billion. Through 2006, US$14.6 billion had been spent (though to be fair, this is only US$8 billion in inflation-adjusted dollars).
The original estimate for the Sydney Opera House was US$7 million. The final cost was US$102 million, more than 14 times the original estimate.
Why is estimating so tough? It's not as if estimators are dumb or poorly trained in their profession. I've earned my estimating certification, and that was one hard test--it melted my brain. I took the examination on a Friday and couldn't participate in light conversation for the following weekend.
The reason that initial cost estimates seem to so rarely align with a project's final costs has nothing to do with the work quality of the estimators. It has to do with the work quality of everybody else on the project team. You see, comparing the final costs of a project to their original estimates is a way of making the cost baseline team somehow responsible for everything that went wrong in a project.
In the case of the Sydney Opera House, bad weather, incomplete plans and drawings, and a lack of information about the material and the structure of its now-famous roof all added dramatically to the cost. The estimators didn't make those errors--other members of the project team did.
I have to laugh every time I hear a project manager lament all that's really needed is a good cost estimate--as if a sufficiently prescient estimate would work as a talisman to ward off rate variances, contingency events, poor performance and scope creep.
For those estimators who are reading this and can't believe your eyes, I figured I've spent enough ink lambasting you for hanging around projects and continually re-estimating the remaining costs as a way of providing project control capability. You deserve a break.
I'm especially interested in hearing from those estimators and project controllers who somehow find themselves the scapegoat when their original cost baseline gets blown to smithereens.