ON THE EDGE

Do We Really Need the Second Decimal?
The Demystification and Re-mystification of Project Management


by Carl Pritchard, Pritchard Management Associates



After a recent Advanced Risk class, a student stopped by the front of the auditorium and shared one of the greatest compliments the instructor could have received. You did a great job on that Monte Carlo stuff. I always thought it was beyond me. That was a really clear example that just made good simple sense. More people should teach it that way.

What a kind and reaffirming statement. Ideally, we should shoot for this in project management. But there's a seeming effort afoot to do what I refer to as the remystification of project management.

In a recent team exchange, when I suggested that our effort in spreading the project management gospel should be simplification and clarification, one team member shot back with an H.L. Mencken quote—For every complex problem there is an answer which is clear,simple and wrong. I have pondered that extensively since the day my team member shared it, and now feel comfortable in my own position on this. There may be clear, simple and wrong answers, but there are also clear, simple and correct explanations.

For the past 20 years, authors, researchers and practitioners have been striving to make project management accessible to the masses. The titles of books published in that period provide evidence of that effort: The Dummies Guide to Project Management, CommonSense Project Management, and Project Management–The Briefcase Series are but a few.

But in the last two or three years, I've noted a shift from efforts to make project management more accessible to efforts to make it more challenging. There's a proliferation of standards (portfolio management, risk management, earned value management and program management). There are more and more organizations and associations. And each of these groups seems to be attempting to out-think the other with escalating levels of depth and complexity.

Best practice project management is not rooted in complexity. The goal of effective PM is to simplify and clarify. The work breakdown structure—the very core of an effective project plan—is an object lesson in simplicity. It takes work and defines it down to manageable chunks. And even there, arguments are brewing about the semantics in WBS development, the scale and scope of work packages and the increased need for zealous adherence to progressively more complex thought in dealing with this.

The problem with this more academic approach to project management is that the true, business-friendly nature of project management becomes lost in a sea of arguments about the fine-grain details. For example, consider some of my recent experiences in risk management:

  1. Is PERT a sound tool to gather data about durations for task estimates?
  2. Is it practical to do a qualitative assessment of the risk level for the project as a whole?
  3. Is it reasonable to quantitatively evaluate individual risks?

If you answered "yes" to all three, you and I share a common vision. I'm wed to the notion that almost any time you are doing more analysis of a project than you otherwise might, it's a good thing. But I've been told recently that to share or promote such notions is heresy. Quantitative analysis is the exclusive province of whole-project analysis. Qualitative is the exclusive province of task or work package analysis. And PERT?! You'd think it was a four-letter word. Asking people to gather the optimistic, pessimistic, and most likely durations and apply them consistently in their projects? Such a notion doesn't stand the test of statistical rigor, and without that rigor, the tool should never be promoted, let alone used.

Project management is best practiced inclusively, welcoming other strategies and approaches and keeping an open mind about their application.

I once had a project manager in an organization ask me to review his work breakdown structure. His work packages were roughly 6–8 hours of effort. His lowest level was activities, rather than work packages. The whole thing was task- and organization- oriented. Technically speaking, he had broken a host of rules. But, his effort was flawless in its decomposition (there was a clear breakdown of every bit of the work). The background information in each of his work packages was dreamy. The elements were described with a clarity that any novice could have easily interpreted.

So, was it a good WBS? Yes. It simplified and clarified the work to be performed and arranged it in a fashion that supported the organization. Some would contend that because it went down to "activities," it's not even a WBS anymore. Such semantic arguments are fine, but as professionals we need to be braced for the backlash from the hard-working, real-world, "in-the-trenches" community.

How do we then blend the need for rigor with the need for practicality and understanding? We include. We include approaches in common accepted practice. We identify their pros and cons. We include what works; and if there's a potential limitation associated with it, we include that, too. Project offices that want to appear responsive will include new angles, approaches and ideas along with the old ones, as long as they won't harm the project and still support the organization's goals. Project offices that want to appear responsive will respect the existing approaches, not arbitrarily declare them wrong or obsolete because they don't pass some new, statistically derived muster.

A vendor selling me a software package recently argued against one of his competitors by saying the other software would lose credibility on setting duration "past the second decimal." I clarified that he meant "point-00," and he said yes. As I walked away, I reflected on my concern for the profession. Project standardization and clarification of standards does not mean we all have to adhere to second-decimal management. Most organizations would be thrilled if we could accurately predict cost or schedule to a whole number. Would a second-decimal prediction be more desirable? Sure. But will it lead to greater adherence? I think not. If we can expand the tool kit, and be open to broader application of the tools, we can show project management for what it is—an in-the-trenches practice where we draw on the people, skills, and expertise available to make deliverables happen.








©Copyright 2000-2018 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail info@projectconnections.com
Terms of Service and Privacy Policy