Voices on Project Management

by , , , , , , , , , , , , , , , , , , , , , ,
Voices on Project Management offers insights, tips, advice and personal stories from project managers in different regions and industries. The goal is to get you thinking, and spark a discussion. So, if you read something that you agree with--or even disagree with--leave a comment.

About this Blog

RSS

View Posts By:

Cameron McGaughy
Marian Haus
Lynda Bourne
Lung-Hung Chou
Bernadine Douglas
Conrado Morlan
Kevin Korterud
Peter Tarhanidis
Vivek Prakash
Cyndee Miller
David Wakeman
Jen Skrabak
Mario Trentim
Shobhna Raghupathy
Roberto Toledo
Joanna Newman
Christian Bisson
Linda Agyapong
Jess Tayel
Rex Holmlin
Ramiro Rodrigues
Taralyn Frasqueri-Molina
Wanda Curlee

Past Contributers:

Jorge Valdés Garciatorres
Hajar Hamid
Dan Goldfischer
Saira Karim
Jim De Piante
Geoff Mattie
sanjay saini
Judy Umlas
Abdiel Ledesma
Michael Hatfield
Deanna Landers
Alfonso Bucero
Kelley Hunsberger
William Krebs
Peter Taylor
Rebecca Braglio
Dmitri Ivanenko PMP ITIL

Recent Posts

Lead With Value

High-Performance Teams Are Purpose-Driven

The Benefits of Sprint 0

A Balanced Competency Model

Are Best Practices Really Possible?

Viewing Posts by Michael Hatfield

PMBOK®Guide for the Trenches, Part 7: Procurement and Human Resources

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.

I'm pretty sure this is because human resources and procurement should be understood as asset management, not project management. Asset and project management are completely different animals, with different objectives, tools and methods for attaining their respective goals.

Those differences were vividly illustrated for me when I was working on a software project for my organization's human resources department. I had loaded the schedule into a critical path network, pulled status and recalculated the projected end dates. When I was presenting the resulting Gantt chart to the human resources manager, I pointed out that one set of activities involving the software coders looked like it would be delayed, and, if it was, it would delay other key milestones.
 
"Tell everyone to come to work this weekend and maybe next," was his automatic reply. "Wait," I interjected. "These activities have nothing to do with your folks - it's the management information systems people who are involved here, and we don't even know what their difficulty is. It may not be fixable with more people working it." "No difference," he replied. "This project is so important that all of our assets must be performing optimally."

Of course, project management is not about the performance of assets. It's about attaining the scope that the customer is expecting, within the customer's parameters of cost and schedule.

I'm engaging in a little bit of hyperbole here, but most project managers don't concern themselves about whether they should have bought or rented a key piece of equipment. They care about whether or not the job gets done on time and within budget.

Procurement is in the same boat. Sure, it's important that the procurement professionals who work with you are very good at what they do. But they obtain assets and are similarly afflicted by the asset managers' mind set.

I just don't think we're kindred spirits. But, if there are any human resources or procurement heavy-hitters out there who think our managerial goals and techniques are completely compatible, I'd love to hear from you.

Posted by Michael Hatfield on: August 13, 2010 03:21 PM | Permalink | Comments (6)

PMBOK® Guide for the Trenches, Part 6: Quality

Categories: ROI

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.

Posted by Michael Hatfield on: June 29, 2010 01:17 PM | Permalink | Comments (3)

PMBOK® Guide for the Trenches, Part 5: Communication

Categories: Communication

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?
Posted by Michael Hatfield on: June 09, 2010 06:24 PM | Permalink | Comments (2)

PMBOK® Guide for the Trenches, Part 4: Risk

Categories: Risk Management

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

Posted by Michael Hatfield on: April 20, 2010 03:15 PM | Permalink | Comments (14)

PMBOK® Guide for the Trenches, Part 3: Cost

Categories: Project Failure

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. 
Posted by Michael Hatfield on: March 03, 2010 01:21 PM | Permalink | Comments (6)
ADVERTISEMENTS

A celebrity is a person who works hard all his life to become known, then wears dark glasses to avoid being recognized.

- Fred Allen