Results tagged “Michael Hatfield” from Voices on Project Management

It's finally time to expose the biggest myth as I close out my taking-on-the-myths series, hopefully generating plenty of lively responses.

Myth 2: Comparing your project's budget to actual costs is a natural way of assessing cost performance.

Truth: Comparing budgets to actuals is not only useless, it's misleading.

To back up this little piece of iconoclasm, I will invoke the widget example I use when teaching the subject of cost performance measurement.

Imagine you are a project management assigned to a project to make 2,000 widgets in two months with a budget of US$2,000.

You time-phase your budget US$1,000 in month one and US$1,000 in month two.

At the end of the month one your accountant tell you that you've spent US$1,100. How are you doing?

If you said "poorly" based on the fact that you have spent US$100 more than you budget, go to the back of the class.

If you said, "It depends on how many widgets you've made," go to the front of the class.

Because if you've made 1,300 widgets, and each widget is worth US$1, then the proper comparison is obviously the US$1,300 in earned value against the US$1,100 it took to make them.

A very simple example, I grant you, but it starkly supports my assertion.

The Biggest (in my opinion) Myth: Agile and scrum are novel improvements to traditional project management, tailored for the software industry.

Truth: Agile and scrum were developed to allow IT projects to indulge in all the scope creep they wanted.

My take is that the most lethal practice to project health is to allow informal changes to the technical baseline without changing the cost of schedule baselines--a practice commonly known as scope creep.

The IT industry is particularly susceptible to this, since changing the size of a building or the speed of a ship is hard to miss and affect. But changing the look, feel and capability of a software package may require little more than adding a few lines of code--and how hard that can be.

What started happening within the IT industry, on a common and costly basis, was that seemingly small changes in the various code modules created a configuration management nightmare.

So, we see the introduction of tactics that "max out" project team communications, including co-location and employee roles that define the nature of their interactions with their colleagues, customers, and the technical agenda.

But I have to ask: If the technical baseline was thoroughly and clearly defined at the project's start, and only changed formally, would any of this really be necessary.

So what do you think? Myth or reality?

Editor's note: PMI members who are interested in agile should check out PMI's new Agile Community of Practice.

Part four of my taking-on-the-myths series will challenge our statistically minded segments: the risk managers.
 
Myth 4: Using Monte Carlo simulations to generate contingency budgets or schedules is an appropriate approach and should be more widely adapted.
 
Truth: Monte Carlo simulations are needlessly complex and shouldn't be used.
 
Of the three most common risk analysis methods used in creating a contingency schedule or budget--risk classification, decision tree analysis or Monte Carlo analysis--the latter is by far the most complex, so naturally it has the reputation for being the most robust.
 
But is it really?
 
Consider the data points your Monte Carlo simulation driver asks of you: original budget (or duration), one or two "things-going-wrong" alternatives, their odds and costs, and at least one "things-go-great" scenario, with its odds and estimated costs.
 
This is the exact same data set that would support a single-tiered decision tree analysis, except that the Monte Carlo version invokes a random-number generator to fill in hundreds (or even thousands) of other data points, which can then be used to analyze confidence intervals--at least supposedly.
 
But all of these other data points are artificial! The ensuing confidence intervals are far from reliable, hoopla notwithstanding.
 
Myth 3: Risk management is so important to project management that it should be employed throughout the project's life cycle.
 
Truth: After the baseline is set, formal risk management is pretty useless.
 
This last assertion is guaranteed to invoke a passionate debate, but consider your personal performance. Do you function better when you are confident or when you are worried? And what does formal risk management bring to the table once the project is underway, other than institutional worrying?
 
Analyzing ominous trends or performance information indicating a problem in order to head off threats to project success is what project managers do on a daily basis. Spending excess time quantifying those threats doesn't improve your odds of success.

In my last post challenging project management myths, one responder noted that I was unclear about what part described the myth and what part described the challenge statement. Here are numbers 5 and 6 on the hit parade, with the parts a bit better defined.

Myth 6: Complete and detailed procedures are an essential part of a successful project control system implementation.

Truth: Writing procedures are generally a waste of time and they don't help advance project management maturity.

Think about it, is there anything in the universe easier to ignore than a document? But the myth persists that procedures by themselves can advance an organization's project management capability.

Usually these procedures are signed by  a high-ranking member of the organization, who is attempting to compel obedience or participation in the project control system.

But unless the organization has authorized someone to actually  fire or demote others for failure to comply with the document--which happens rarely if ever--then the procedures themselves won't help.

Myth 5: If a schedule based on the critical path method isn't available, a good interim step to manage a project's schedule is to create a list of milestones or action items and meet to review them on a regular basis.

Truth: Action item lists and milestone databases are essentially polls and have no place in legitimate management information systems.

I once worked on a major program in which participants entered project data into a milestone database and provided monthly updates to those milestones.

At the beginning of the year, all of the milestones were scored "green," meaning the milestone would be met on time.

Byabout the ninth month, a few "yellows" would show up in the status column, indicating a possible delay.

More yellows would show up in month 10, followed by even more in month 11 along with a few "reds," indicating the milestone would be missed for that fiscal year.

By the last month, easily half of the milestones were either red or yellow. Lots of scolding and badgering would then ensue, followed by a new "baseline" for the next fiscal year, and-- shazaam!--all the milestones would be green again.

Asking participants what they think of their performance is not a performance management system -- it's a poll. And polls are not substitute for real management information systems.

I look forward to your responses because I know a whole bunch of people are going to disagree with these two.

In my continuing series on commonly used, but invalid project management tactics and techniques, I simply could not let my traditional targets, the accountants, off the hook. I'm also going to wade back into a matter I began to address over a decade ago, but, since many of my readers are still not convinced, I simply must re-address it.

So, without further ado, here are my myths 8 and 7:

Myth 8: Nothing an accountant can do in general ledger space can produce cost or schedule performance information, or project at-completion costs or dates. Traditional management techniques are oriented toward "maximizing shareholder wealth," and all of the management information systems designed to support that goal--including generally accepted accounting practices--are based on managing assets.

Managing a project's scope, cost or schedule is a completely different animal. Unfortunately, the idea that all of an organization's information involving money simply has to come from the general ledger is a myth that dies hard, if at all, and accountants have absolutely no motive to correct that assumption.

Myth 7: Bottoms-up estimates at completion (EACs*) are more difficult, more time-consuming more expensive and less accurate than the calculated version.

According to the Association for the Advancement of Cost Engineering International, the most detailed estimate available is named, appropriately, a detailed estimate. It is generated by a professional estimator using off-the-shelf software and is so detailed that it can be handed off to a procurement specialist to begin the buying process. However, it is only accurate to within 15 percent of the project's final cost, at best. The most commonly used formula for calculating the EAC is based on the accuracy of the cost performance index (CPI) (EAC = Budget at Completion / CPI).

Dave Christensen has definitively established that the CPI virtually never changes more than 10 percent in either direction once a project has passed the 15 percent complete point. It follows, then, that the EAC calculated using that CPI is also accurate to within 10 percent and extensive analysis has borne this out.

That being the case, the calculated EAC can be derived from three data points, whereas the bottoms-up version needs literally hundreds. That version is also more expensive, if, for no other reason than it takes more professional time to produce. Finally, since within 10 percent is more accurate than within 15 percent, the calculated version just hit the trifecta.

Looking forward to your thoughts on these two myths.

(*A bottoms-up estimate is when you have already started the project, and you re-estimate all remaining work by work breakdown structures element. You take that number, add it to the cumulative actual costs, and you have a "bottoms-up" EAC.)

I'm going to spend the next several posts discussing commonly held, but, in my opinion, profoundly erroneous tenets of project management.

Two esteemed colleagues, David Hampton and Alice Skehan, PMP, rated my list of 10 assertions in order of contrariness to common project management precepts, as well as the extent with which even they disagreed.

Here, then, are my numbers 10 and 9:

Myth 10: Trying to leverage organizational power to implement project management in the macro-organization is futile. Oh, I know, people try it all the time, and in many cases the ultimate outcome bears a strong resemblance to a legitimately installed project management office (PMO).

As I discuss in my book, Things Your PMO Is Doing Wrong, the so-called coercive strategies don't work in the long run for the simple reason that people are being, well, coerced into doing project management.

The moment they can opt out of the system, they will, and no reason that can provide reasonable cover will be considered too silly. I once had a project team that tried to use a paperwork-reduction initiative as a reason why they shouldn't have to send along their earned value reports. Really.

Myth 9: There is no cost performance management without earned value. Period. No exceptions. And yet, the comparison of budgets to actual costs persists.

When I'm instructing new cost engineers in earned value, I like using the following scenario: You're a project manager, assigned to get 2,000 widgets created in two months, with a US$2,000 budget. You time-phase your budget US$1,000 in month one and US$1,000 in month two.

At the end of month one, your accountant comes to you and says that your project has spent US$1,100.

Then I spring the question: "How are you doing?"

Invariably, one of them will say "Poorly, because I'm overspent."

"What if I told you that you had made 1,300 widgets?"

Obviously, that little fact changes everything. In this instance, comparing the budgets to the actuals was not only useless, it was actually misleading. Management information systems can be forgiven for offering up the occasional jejune tidbit, but never for misleading. And yet that's all you're left with if you don't have an earned value management system.

Next up, I'll be taking on the capabilities of the general ledger and re-visiting the bottoms-up estimate at completion debate.

Most of my regular readers know I like to take accountants to task for pretending to be able to deliver cost performance or estimate-at-completion information to decision-makers based on generally accepted accounting principles. But that door swings both ways: Earned value practitioners are also guilty of trying to further their technical agenda using the resource managers' arguments and analysis, which, in my opinion, is profoundly flawed.

The most prominent of these tactics is to try to justify the cost--or even the existence--of the project management office by running some sort of ROI analysis. This is simply illogical if for no other reason than the ROI calculation pertains to assets, not capabilities.

Less notorious but every bit as pernicious is the tendency of earned value practitioners and accountants to compare the time-phased budget's basis of estimate document with its associated actual costs at the line-item level.

In the earned value world, comparing budgets to actuals is worse than useless: It's actually misleading.

And yet, some practitioners seem to think that if such an analysis were simply done at a very detailed level, it would suddenly become relevant. It doesn't.

Oh, they may try to make some lame argument about the need to benchmark the estimators' work, but this assertion lacks validity that can be demonstrated in the following scenario:

A US$100,000 task is estimated to require US$25,000 in heavy equipment and US$75,000 in labor. At task end, US$74,000 was spent in heavy equipment and US$25,000 was spent in labor. An earned value management system correctly--would not raise the red flag for cost performance, but the system that compares budgets to actuals would erroneously report a severe problem--never mind that the task came in under budget.

Any management information system that reports a phantom cost performance problem isn't good for very much.

Next up:  The absurdity of maintaining milestone lists in lieu of real schedules.

In my continuing series on commonly held but, in my opinion, highly suspect project management practices, I want to ask the question: Exactly what do the risk analysts do that improves a project's ability to come in on-time, on-budget?

Now, as the firestorm I've just ignited races to engulf me, let me be crystal clear about what I'm asserting. I am not saying that risk management is without value. What I am saying is, once the contingency budget and/or schedule have been baselined, the value of the information produced from risk-analysis techniques drops off dramatically.

U.S. General Dwight D. Eisenhower believed that once you're on the battlefield, all plans were out the window. And, while (most) projects don't approach the level of chaos and mayhem associated with a battlefield, I think his ideas are highly applicable in our works. That's what project managers do; they respond to the changes in circumstances, resources, demands, and hundreds of other parameters, every single working day.

The notion that project management decisions can be quantified and reduced to formulaic responses in most circumstances is absurd, and furthering that approach using excessive statistical jargon does not automatically make it legitimate.

As for the assertion that risk management includes an "upside risk" component--a.k.a. opportunity management--I would like to point to the Unabridged Webster's New International Dictionary, Second Edition. Its definition of "risk" reads, in part, "Hazard; danger; peril; exposure to loss, injury, disadvantage or destruction."

Indeed, nowhere in the definition will you find any reference to any possibility of a positive outcome or environ, much less opportunity. And yet, you see people make the comparison risk management equals opportunity management.

I know the risk management aficionados have had a lot of success re-defining the verbiage associated with their area of expertise in A Guide to the Project Management Body of Knowledge (PMBOK® Guide) space, but isn't there another way of furthering risk management notions without pounding away at the lexicon?

Within the realm of project management--or any other complex system, for that matter--accurately identifying failure is difficult to the extreme. There are simply too many parameters to isolate, which makes writing about management a precarious proposition.  

Oh, there are certainly those cases where a project manager insists that no cost or schedule management systems be used, and it doesn't take long to drive that project into the ground. But in most other areas the link between act and consequence is not nearly so stark.

Renowned psychologist, B.F. Skinner, wrote that a variable rate of reinforcement virtually guarantees a behavior will continue. If that is so--and I believe it to be--then it follows that a practitioner who has experienced success using a particular technical approach may be inclined employ that approach over and over--even when it fails over half the time. That same practitioner might also be inclined to join with like-minded project managers to advance a new model or structure for success.

Their assertions may be correct and insightful universally, in some specific environs, or completely off base.

I entitled this post "Part 1" because I intend to take a close look at some conventions that may have been adapted in that spirit and without the scrutiny of an iconoclastic wise guy such as me.  

Next up:  Does risk management really help bring in projects faster, cheaper or with higher quality?

See relevant research from Project Management Journal® as reported in PMI Community Post: Avoiding Project Failure by Managing Organizational Culture

Glen B. Alleman was kind enough to respond to one of my recent posts, taking exception to my assertion that a simple, calculated estimate at completion (EAC) is probably the most powerful underused tool at the project manager's disposal.

He laid out a scenario where a varied time-phased budget (Budgeted Cost of Work Scheduled, or BCWS) would introduce a sufficient level of error into the calculated EAC so as to significantly reduce its effectiveness.

I must disagree, if, for no other reason, than the time-phased budget isn't part of the calculation.

As I discussed in that earlier post, the classic cost performance index divided into the budget at completion formula can be algebraically simplified to dividing cumulative actuals by the estimated percent complete. With those two data points, remarkably accurate management information can be gleaned and used to avoid project catastrophe.

To support my argument, I would like to ask: What other options are out there? What other methods can rival the simple earned value management (EVM) version?

After suffering through semesters and semesters of accounting, and semesters and semesters of finance, I can say with a fair degree of certainty that there's nothing in the accountant's toolbox that can even come close to the accuracy of the simple EVM method.

As counter-intuitive as this may sound, the person who has been through a 40-hour EVM class is in a far superior position to relay accurate at-completion project costs than is the accountant, who, of course, needed years and years of post-secondary education.

I intend to speak on this at the EVM World 2009 conference being put on by the PMI College of Performance Management this week. If you're in attendance, look me up. Otherwise, leave a comment. I'll see it, I promise.

A lot of energy has been spent investigating the "value" of project management. My question is: value to whom? Doesn't it all boil down to what the projects' decision-makers do with their project management information?

Imagine a project manager who pays a very small amount for a very advanced cost and schedule control system, and the system reliably produces accurate information in a timely manner. If that project manager ignores that output, and instead acts out of impulse, then the value of the project management information system is zero.

And, to be blunt, no amount of eat-your-peas hectoring from our side of the debate will lead such a project manager to have an epiphany and turn away from his or her nefarious ways. Conversely, a project manager who pays a great deal for a system that barely reports projected costs at completion and forecasts completion dates, but uses that information to avoid a massive overrun or delay, has an extremely valuable system.

Not to abrogate the debate, but, in my opinion, the value of project management is like the macro-economists say: It's what somebody's willing to pay for it.

Experts on the assassination of U.S. President John F. Kennedy have come to a couple of conclusions: 1) the Warren Commission got it right and 2) many people have a hard time accepting that such a monumental, history-changing act wasn't the result of a massive, expensive, difficult-to-execute conspiracy.

So, when I started writing about how earned value management systems (EVMS) can accurately predict the future with some simple calculations, I received some responses that expressed varying levels of incredulity. It simply goes against intuition that an information element as important as at-completion project costs could quickly and easily fall out of an EVMS.

But since I've already firmly ensconced myself at the end of this limb, let me take it a step further: The estimate at completion (EAC)--the brass ring of management information systems--can be calculated without a baseline, a work breakdown structure or a formal change-control process--none of what we've been told are essential parts of an acceptable EVMS. None. Nada. Zilch.

Now, I'm well-aware that the previous sentence is the metaphorical equivalent of pulling the pin on a grenade and rolling onto the floor of a conference room full of EVMS experts, but I can explain.

The traditional formula for calculating an EAC (EAC = BAC/CPI) can be algebraically reduced to dividing cumulative actual costs by cumulative percent complete. That's right, we're talking two date elements, easily collected. And the resulting information is far, far more accurate than anything that the general ledger can produce. It's also much more accurate (and faster and easier) than re-estimating the remaining work and adding that to cumulative actual costs.

In fact, it's so much more accurate, faster and easier than any competing information stream, that I'm frankly flummoxed that the calculated EAC isn't the centerpiece of EVMS use everywhere.

I can't wait to see the responses to this one.

My earlier post, Our Biggest Unused Weapon, posited that the ability of even a basic earned value management system (EVMS) to predict when a project will be complete and how much it will cost at completion is unparalleled in the management information system world. But I also argued it was being under-used by most practitioners.

William Goelkel, PMP, responded with:

"EVM can lead us to make bad decisions, or forecasts, when the standard against which we measure everything is the plan we baselined at the point in the project's life cycle when we were most ignorant of its requirements."

And

"I'm not convinced a calculated EAC [estimate at completion] as you described is always useful."

I'd like to further my arguments to the contrary while responding to Mr. Goelkel's thoughtful comment.

Mr. Goelkel's main example concerns software projects, where "goals change and our understanding of the users' needs evolves." Either this understanding evolution is captured formally and introduced into the baseline, or it is not. If it is, then there's no problem. If it is not, then we have scope creep, the most pernicious attribute of managing projects.

Even so, EVMS have a remarkable ability to predict the future, even when the baseline has been turned to rubber.

Say you had a US$100,000 project, but "evolving" customer expectations will end up costing the contractor double that, or US$200,000. At the point that the project should be half-done (cumulative budget = US$50,000, and actual costs are at the same level) the task leader assesses that she is only 25 percent done. The calculated EAC will instantly indicate the real EAC of US$200,000, allowing for either elimination of the scope creep or a request for more money.

For a more real-world example, try to find a project that (impishly) has a "Project Managers' EAC" column right next to the calculated EAC in their cost performance reports.

Ninety-nine times out of 100, the project manager's version is lower than the calculated one and less accurate. It's like clockwork.

In my next post, I'd like to tackle how project management trends in the software world--like scrum or Agile--are actually attempts to accommodate the rampant scope creep that so often afflicts those projects.

For now, I'd like to hear what other EV practitioners have to say. I'd also like to thank William Goelkel for this discussion.

The primary capital ship of most blue-water navies is the aircraft carrier. According to Rob Stern, in U.S. Battleships in Action, Part 2 a pair of aircraft carriers can deliver around 35 tons to a target in one hour. A United States Iowa-class battleship can do the same job in 90 seconds.

The U.S. Navy has four of these battleships, but, fortunately for enemies of the United States, only one is in the reserve fleet, while the others have been converted to museums.

Why is such a clearly effective weapon not in use? It may be because of the relative ease with which aircraft carriers sank battleships during World War II, leading to the conclusion that the carriers were superior naval vessels in all respects.

In the epic struggle to advance project management capability within our organizations, I think it's important to recognize that we are in competition with other management approaches and information streams. And in this competition, we may be failing to use the most powerful weapon in our arsenal: the capability of an Earned Value Management System (EVMS) to predict the future.

Accurate prediction of the future is obviously a very useful capability. In the project management world, the key pieces of future information include: How much will this project end up costing, and how long will it take?

These twin brass rings of project management information are hotly pursued in a variety of ways--most of them incorrectly, in my opinion. The most common approach is to re-estimate the remaining costs and duration of an on-going project, and to then add that amount to cumulative costs or duration.

This method, despite being notoriously inaccurate and injecting hundreds (if not thousands) of purely subjective data elements into the mix, is often defended as the only appropriate approach.

Conversely, the best approach--calculating the estimate at completion (EAC)--is commonly derided by so-called project managers, even though it's faster, easier and demonstrably more accurate than its re-baselining counterparts.

The most familiar EAC formula, the Budget at Completion (BAC) divided by the Cost Performance Index (CPI), can be algebraically reduced to dividing the cumulative actual costs by the project's percent complete. This formula works with durations as well: Divide the cumulative duration by the percent complete, and you have an accurate idea of how long a given task will take.

With such an easy, simple and powerful weapon in our arsenal, why aren't we using it more?

Are you failing to rake in the respect, admiration and monetary recompense that are consistent with your advanced level of project management expertise? If so, you need your own business or management model, complete with its own slick-sounding acronym, in order to truly set you apart and make you stand out in a crowd of (otherwise) management equals.
    This is easier than it looks. For example, someone can, say, set up a traditional Responsibility/Accountability Matrix (RAM), deconstruct them into detailed instructions with lot's of fuzzy terms like "strategic," "engage" and "implement", slap an acronym on it--like RACI (Responsible, Accountable, Consulted, Informed)--and voila! They've developed their very own management model.
    I love reading the synopses in the management course catalogues I get in the mail (yeah, I know, I need to get out more). You can almost track the entire debate among the Agile management practitioners, the Scrum advocates and the more traditional Waterfall Model believers just by reading what the instructors or paper presenters believe they are bringing to the table.
    I know: I'm inviting a truckload of comments questioning my intelligence. But Agile management strikes me as little more than the practice of loosening up baseline change control parameters to the point of almost begging scope creep to hit your software project in a bid to acquire the kind of managerial latitude needed to deliver software faster. Throw in some trendy tactics, like re-arranging the desks in the office and bring along the ever-present admonition to achieve better communications (especially with stakeholders), and then you can profoundly influence the conversation on management theory around the globe.
    I first became aware of the practice of deconstructing already-existing management practices and trotting them back onstage re-packaged during the 1980s, when "Activity Based Costing" was suddenly a hot topic. For you gen-exers out there, Activity-Based Costing (note how easily the acronym falls off the tongue: ABC) was the idea that a project's basis of estimate should be created at the lowest level of the Work Breakdown Structure, or activity level, and "rolled up" to total project cost. Problem was, this was the way that valid estimates had been created since the dawn of project management. Besides, what's the alternative? Estimating based on the availability of the organization's resources? For manufacturing, process or asset management, that might be a workable approach, but it was never so in the realm of project manager. Nevertheless, a plethora of ABC-themed paper presentations' titles started appearing in project management and cost engineering seminars. True to form, of the ones I attended, the content was made up of deconstructing the act of generating the basis of estimate into some sort of process guide--almost like a recipe--and then sprinkling in vague but trendy management-speak terms to make it appear new, or more sophisticated.
    To engage in a bit of deconstruction myself, at the end of the day all management models are nothing more than formulaic attempts at telling other people how they should be managing their projects. I can see why such models are appealing to consultants. But, for the rest of us, do they really merit all of the books, articles and presentations devoted to them?

Project management practitioners who read the conventional wisdom on those things that threaten project success may be "getting sold a bill of goods" (a U.S. colloquialism meaning to be deceived).
    While project management-types usually don't stay in the industry for long before witnessing a project crash-and-burn firsthand, the ability to accurately identify and clearly articulate the proximate cause of that project failure is often elusive, with individual prejudices coloring analysis. Quality engineers tend to name a lack of quality capability as the main reason behind project failure, while estimators tend to believe inaccurate cost baselines or estimates at completion are the culprits.
    I have a pretty clear idea of the main, if not only, cause of project failure, but before I name it, let me tell you what it isn't:
•    No Six Sigma
•    Lack of Agile project management
•    Failure to engage stakeholders (see my previous post)
•    Inappropriate leadership style
•    Too few Project Management Professional (PMP®) credential holders
•    Insufficient procedures or written guidance
    I could go on, but this list should be sufficient to contradict the majority of management writers who are asserting the key causal factor in project failure.
    So, what is the main causal factor? The project manager and/or project team made bad decisions.
    This is not simply a semantic difference. The ability to make good decisions is absolutely critical to any and all project outcomes, including the ability to meet success criterion. This ability is influenced by several factors, including:
•    The education/capability of the project team
•    Some level of luck, certainly, but mostly:
•    The availability of adequate project cost and schedule performance information, which almost always clarifies the best project decisions
    So important is the generation and delivery of cost and schedule performance information that any manager who eschews such information has automatically signaled their incompetence, and inappropriate placement in any position of authority.
    I'm essentially calling out the anti-cost/schedule performance system crowd. (You know who you are.) If you have ever argued against the introduction of an earned value system on principle, stop calling yourself a project manager because you aren't one. Of course, I'd love to hear from anyone disagreeing with me on this, so, please leave a comment.

If I had a dime for every copy of every project management article that prodded the reader to further engage stakeholders, I wouldn't have to spend time writing this blog. I could probably buy New Zealand.
    Indeed, failure to engage stakeholders has become the cardinal sin of the project management industry if you read all the trade journals. I do believe that they are only a short distance away from requiring all managers of failed projects to wear a scarlet FES, for Failed to Engage Stakeholders, reminiscent of Nathaniel Hawthorne's novel of a very similar name. Being the hopeless iconoclast that I am, I can't help to make the opposite assertion: Project managers should eschew these all-wise, all-knowing stakeholders for the following reasons.
    First off, who are we talking about here? Which "stakeholder"? If it's the customer, then, of course, "engage" them (which, I assume means, you talk together). But keep in mind, customer involvement often involves their asking for additional stuff on your project or higher quality standards. The desire to accommodate these stakeholders is the most common cause of that most fatal of project-killers: scope creep. And, once a good dose of scope creep has wrecked your project, it won't do the culpable project manager any good to respond, "I was just engaging the stakeholders!"
    Then there are the stakeholders who are neither on your project team nor in your customer's organization: These are "nuisances." If the scope of your project involves doing something that provably impacts others in an adverse manner, that's your customer's problem, isn't it? They probably should have spent a little more time getting the appropriate permits before they ponied up the money for your baseline. And, if these stakeholders don't belong to your or your customer's organizations and aren't provably adversely affected, then they should probably shut up and go away. Does that sound harsh? Okay, they don't have to be ignored or exiled, but they absolutely should not be consulted on what should happen on your project. Indeed, to do so is akin to project management malpractice.
    So there. I was getting a little tired of nobody posting comments on my blogs, and I figure this piece will pretty much cure that.

In 1971, a Stanford University researcher conducted a psychological experiment where 24 student volunteers were divided into the roles of prison guards and prisoners, and played out their roles in a prison setup in a basement at the university. The experiment had to be called off early, as the students given the role of guards began to exhibit sadistic behavior toward the students playing the prisoners, who began to show signs of psychological trauma themselves.
    While the set-up and conduct of the experiment have drawn criticism, it's hard to evaluate the behaviors observed without a sense of astonishment and horror at what some people with a sense of authority can do to others. I believe that a valid conclusion that can be drawn from the Stanford University prison experiment is that, over time, anybody perceiving themselves in a morally or intellectually superior role with respect to another specific set of people, combined with a sense of authority, will manifest monstrous behavior.
    And now, on a completely different subject, I'd like to evaluate if the people who audit systems and subsystems are subject to influences that might lead them to believe that:

• They are in a position of intellectual or moral superiority over the ones being audited
• They are in a position of authority, and
• These perceptions are consistently held over time.

    Because, of course, if conditions were endemic to the auditors' world (they are), then it stands to reason that their sense of proportion and perspective might be twisted to a point where they could not avoid monstrous auditor behavior.
    What do I mean by monstrous auditor behavior? Well, if a multi-million-dollar program office is about to have its reputation demolished (or future work denied) on the basis of a finding that focuses on a minute, legalistic "violation" that has nothing to do with the genuine advancement of project management, then the people who wrote such findings might want to do a quick check to make sure those who put them up to the audit are not wearing white lab coats and holding clipboards.

Those project managers who have accepted the quest of advancing project management capability within your organization need to be aware of a very real threat on their path. Implementation Trolls are skulking all about you, ready to bring you down.
    For example, one favorite troll tactic is to lurk beneath a bridge and attempt to eat unwary travelers who attempt to cross. If we take the action of walking across a bridge as a metaphor for initiating any change, then the Implementation Trolls destroy you in transit, usually by ginning up to the organization's nominal resistance to change. While it is beyond debate that the amount of time and energy that goes into setting up a very simple earned value management system (EVMS) pays huge dividends in useful management information, the Implementation Trolls will complain long and loud about how even that small amount of effort is overly arduous. These beings complain so excessively about largely contrived grievances they should be made honorary members of the Trial Lawyers Association.
    Then, once you've crossed the bridge and approached the castle that serves as the keep for your sought-after treasure, an advanced project management information system, you will encounter an entirely different breed of Implementation Troll.
    Far from picking off your comrades for making people do stuff that's supposedly way to hard, these trolls will insist that anything you bring them is not good enough. These Implementation Trolls are invariably armed with clubs that have the infamous 32 EVMS criteria etched into them, and they take great pleasure in pummeling all those who approach. The infuriating thing about these trolls is that they will often present themselves as erstwhile allies to your cause, but will then gleefully destroy your efforts as being sub-standard. Like their notorious counterparts from Norse mythology, Implementation Trolls have what can only be described as bizarre senses of proportion and perspective, and will inflict their damage while pretending to occupy the intellectual high ground.
    I'm very interested in finding out what the project management blogosphere thinks about Implementation Trolls.

One of the most irksome debating techniques has to be the use of a straw man--the practice of misrepresenting an opponent's position and then attacking that misrepresentation. The straw man's first cousin in the management world is the device of writing a piece that supposedly overturns commonly held perceptions that aren't really commonly held at all.
    An associate of mine sent me an e-mail with a link to an article that purported to overturn project management myths, but I had never heard of any of them.
    One of these myths being overturned was that project managers are only concerned with scope, schedule and cost, and routinely ignore other parts of their projects, like stakeholders or resources. I must have read or heard hundreds of papers and classes on project management, and I've never, ever heard anything like this, but I suppose the article's authors felt such a perception was so widespread that they needed to spend a few hundred words correcting this wrong-headedness.
    I don't want to be left behind if this is where the management world is headed, so I'll do some my debunking myself. The commonly held perception that all accountants are weasels is provable false. I am familiar with many accountants, and I know for a fact that at least some of them have a minimum of one human parent.
    Another myth? The idea that risk managers are attempting to seize control of the project management world by baffling their opponents with statistical jargon until they give in for fear of looking ignorant simply can't be 100 percent true, as risk managers themselves would have to agree.
    The short answer here is that making a point about project management by overturning myths that nobody holds to involves a certain amount of making assumptions about readers' presumptions, and that is an unsatisfactory approach.
    Full disclosure: I once presented a paper entitled The Bottoms-Up Myth, where I argued against the practice of re-estimating the remaining work in a project, adding that figure to the cumulative actual costs, and declaring the result to be a better estimate at completion than the calculated version. I felt confident in describing such a practice as a myth, since almost everybody I've ever met in the estimating world seems to think that it's just great to do things that way, even when it's provably loopy. I'm interested in seeing what all of you think.

PMI editor-in-chief Dan Goldfischer and book editor Donn Greenberg colluded to bring me to PMI's North American Congress in Denver, Colorado, USA to participate in a book signing for Things Your PMO Is Doing Wrong. I must admit, I was somewhat apprehensive before arriving, having never participated in a book signing before. As it turns out, everything went swimmingly, just as Dan and Donn said it would.
    Well, almost everything.
    What was plain to me (and, presumably, every other congress participant) was that considerable energy and intellectual capital has been spent in support of a definitive study investigating the ROI of implementing project management. Of course, I would rather trim my fingernails in a Cuisinart than support such an undertaking. Why? Well, I have two reasons.
    One, ROI is an assessment tool for evaluating assets. Yes, that's right, it's something our old friends the accountants use and regular readers of The Variance Threshold know what I think of them. You may as well calculate the cost performance index (CPI) on a bulldozer. Taking an assessment tool out of the asset managers' toolbox and trying to use it in the project management domain doesn't work, in my opinion. Sorry about all the effort.
    Second, what's the practical application of a study like Researching the Value of Project Management? Does anybody really believe that we project management types can plunk a copy of this study down and exclaim, "See! Project management really is worth your while!" And have them answer, "You're right! Let me make room for you at the boardroom table?"
    It'll never happen. Cost performance information translates into sheer organizational power, and our suspender-clad brethren will not simply stand by and allow project management types to own that information stream.
    But hope springs eternal. Who knows, maybe I'm all washed up, and this ROI study will provide many a project manager with the leverage he or she needs to further the project management agenda within their organization, leading to the inescapable conclusion that I've become too cynical to have my writings taken seriously.
    But I don't think so.
   
Editor's note: You can purchase Michael Hatfield's new book, Things Your PMO Is Doing Wrong, in the PMI Marketplace. During the month of October it is available at the discounted rate. Or find out more about PMI's Researching the Value of Project Management study.