What errors have you found in PMI’s PMBoK Guide?

Several discussion threads on LinkedIn have suggested that one problem with project management today is that people are following the guidance in PMI’s PMBoK Guide, and that the guidance contained therein is “wrong.” Basically, they are suggesting that following that guidance leads to disaster.

My personal opinion is that they’re all wet. I do think there are some errors: heck, I’m responsible for some of them due to some things I messed up in the 1996 version that still haven’t been corrected. And I’ve identified some other things that I think are wrong in previous posts (e.g., the inclusion of requirements as a project management process and the use of process groups as project life-cycle phases).

Now as the primary author of the first PMBoK Guide, I’m obviously biased because much of what I wrote for that version remains in the 4th edition. So if the document is wrong, that may imply that my understanding of project management is also wrong. And if so, I’d really like to correct that understanding and make it right.

So here is your chance to prove me wrong. If you think there are errors in the 4th edition, please post a comment below and describe what you think is wrong. As well, try to identify the magnitude of the wrongness: wrong for all types and sizes of projects? Or just wrong for some?

Exclusions: critiques of the document as a whole; anything related to the PMP credential or the PMP exam; comments related to whether or not project management is a profession; and anything else that I judge to be not germane. 🙂

And to keep the lawyers happy … PMI and PMBoK are trademarks of the Project Management Institute, Inc. I have no connection whatsoever to PMI. None of the information presented here will be shared with PMI by me. Your posts become part of the public domain unless you place a copyright notice on them.

Is “requirements” a project management process?

This is another post from the NewGrange listserve … I made a comment that I didn’t think “requirements” should be included as a project management process in “A Guide to the Project Management Body of Knowledge.” One person replied as follows:

Surely some level of requirements analysis is required in order to ensure that the objectives are stated in such a way that they can be met.

I argued that there were several weaknesses in this position … my post follows.

First and most significant weakness … it doesn’t comply with the definitions:

• Project management processes are concerned with describing and organizing the work of the project.
• Product-oriented processes are concerned with specifying and creating the project product.

Requirements does not fit the first. It does fit the second. There is an inconsistency that is neither explained nor justified.

Second and almost equally significant weakness … it [“A Guide to the Project Management Body of Knowledge”] says that each process repeats in each phase of the project life-cycle. So you now have “requirements” being repeated in the design phase, the development phase, the turnover phase, and in however many phases your project life-cycle has. Just how does that work?

You could argue that the requirements need to be reconfirmed or tested in each phase, but the same is true for many other aspects of the product of the project. To be sure, any construction team is going to spend time verifying the design before it begins work, and the fundamental purpose of many turnover/transition phases is to verify that the outputs of the development or construction phase are accurate and correct, so why limit the iteration to requirements?

Third weakness … if the link between the customer and the project manager is the requirements, how do they interface during the later phases such as design and development? The team’s understanding of what has to be done can change without the requirement changing. The whole idea behind the project life-cycle is to generate additional detail about what has to be done. That requires constant communication with the customer. Again, how and why are requirements special?

Fourth weakness … how do you handle something like a construction project? There are no requirements: there is a detailed specification. If you argue that those specifications are the requirements for that project, then your argument that requirements are an early version of the design with special status is no longer valid.

Fifth weakness … how are design and development “entirely part of the product world”? Are you saying that the project manager isn’t responsible for planning and managing the design work? Isn’t responsible for planning and managing the development work? Wow. How is the project manager’s responsibility for requirements any different than their responsibility for other product-oriented deliverables?

Sixth weakness … it would appear that there is no longer any need for a requirements phase in anyone’s project life-cycle since that work is now part of the project management process. So all of a sudden, there is a set of project management processes that is performed in the absence of any technical phase. This just wreaks havoc with pretty much everything else in the document.

The advocate for including requirements did not offer any counterarguments.

Once again on the Project Life-Cycle

This is from an exchange on the NewGrange listserve …

When phases are called “initiating, planning, executing, and closing,” how do you know where to do requirements, design, development, testing, and turnover? If you are going to do requirements as part of initiating, why not call it that? How can you possibly plan for the development activities when you don’t even have a design in place yet? Why have a planning phase when you know that most of the planning will not be done as part of that phas

These terms only work as “phase” names when you are actually dealing with a single phase. For example, they work fine for the construction phase of a real estate development project, or for the coding and testing phase of a software development project. But they don’t work when you try to use them for a development project that’s starts with a problem statemen

In my experience, IT project teams using these phase names are forced to commit to schedules and budgets that are mostly fantasy. Management doesn’t understand why they can’t accurately predict the cost of the project at the end of the planning phase, so they try to do requirements in the initiating phase … and don’t do any real planning to support requirements. Then they squeeze their design activities into the planning “phase,” and again, they try to develop an adequately detailed design document without any real planning.

Phase names need to be product-oriented.

Top Ten Signs Your Project Is Failing

Someone on LinkedIn posted an article with the above title, but the actual post was about why projects fail rather than signs that it is failing. These are two very, very different concepts.

So I took a few minutes to come up with my own list of Top Ten Signs:

10.  Your client doesn’t answer the phone when you call.

9.  Your team members are spending more time on job interviews than on their assignments.

8.  Your boss keeps asking you explain (again) why he funded your certification.

7.  Your client doesn’t return your messages.

6.  MSP crashes every time you try to print a status report.

5.  HR calls twice a day to ask you to update your skills inventory.

4.  Your team members don’t reply to your emails.

3.  Your controls analyst calls to ask if it’s possible for CPI and SPI to go negative.

2.  Your have more in-process scope change requests than completed work-items.

And the number one sign that your project is failing …

1.  Your mother doesn’t answer the phone when you call.

Principles of Project Management?

This is in response to a question on LinkedIn. I wrote this about a dozen years ago building on some work done by (I think) Max Wideman, Bob Youker, and others.

1.0            Introduction.

Project management principles are the foundation on which the profession of project management is built. Conformance to these principles is a prerequisite for successful project management.

2.0            Definitions.

Principle.  A basic truth, law, or assumption; a rule or standard, especially of good behavior; a basic or essential quality or element determining intrinsic nature or characteristic behavior. (American Heritage Dictionary)

Project.  A unique, temporary endeavor undertaken to create a product or service.

Project management.  The application of knowledge, skills, tools, and techniques to project activities in order to meet or exceed stakeholder needs and expectations from a project. (PMBoK Guide, first edition)

Stakeholders.  Individuals or organizations who may help or harm the project.

3.0            Project Management Principles.

3.1            There must be a project. Project management is best applied to the management of a project, and all projects should be managed with project management. The usefulness of some project management tools and techniques outside the project context does not mean that project management is a substitute for general management. Likewise, the fact that project management borrows heavily from general management does not mean that general management skills and knowledge will be adequate for successful management of a project.

3.2            Projects must be properly authorized. Each project should be formally authorized by a level of management commensurate with the resource needs of the project: the greater the needs, the higher the organizational level which should authorize the project. Unauthorized projects are likely to be unsuccessful no matter how well-managed.

3.3            The project sponsor(s) must provide adequate resources. Resources include tangibles such as financing, people, and material as well as intangibles such as time and support. The need for the sponsor to provide adequate resources does not absolve the project management team of the responsibility (a) to communicate the impact of receiving inadequate resources or (b) to identify alternative courses of action that may be possible with fewer resources.

3.4            There must be an integrated project plan. The plan must be documented and distributed to appropriate stakeholders and must include:

• Scope, schedule, cost, and responsibilities defined at an appropriate level of detail for the size, complexity, and phase of the project.
• A defined process for dealing with uncertainty in scope and work definition.
• Success criteria defining how the project will be judged and measured.
• A defined process for dealing with changes to the plan.

3.5            There must be periodic assessments of performance against the plan. Periodic assessments are necessary to ensure that the project will achieve its purpose. Projects which no longer support the purpose for which they were undertaken should be cancelled or significantly redirected.

Scheduled Cost?

In the beginning … the promoters of earned value management used FLAs (Four Letter Acronyms) for the 3 basic measures:

• BCWS = Budgeted Cost of Work Scheduled
• ACWP = Actual Cost of Work Performed
• BCWP = Budgeted Cost of Work Performed

But four letters seemed excessive in the world of TLAs (three letter acronyms), especially when two of them (CW) were the same in all cases. So ’round about 2000, some promoters of earned value management began to advocate for two letters:

• PV = Planned Value (instead of BCWS)
• AC = Actual Cost (instead of ACWP)
• EV = Earned Value (instead of BCWP)

As you can see, it seemed that the promoters wanted to emphasis “value” because … value is GOOD!

Unfortunately, these two measures represent “value” mostly from the perspective of the project team, and most especially if the project team is composed of contractors:

• Planned value = the contractor’s plans for getting value by getting paid
• Earned value = the contractor’s actual value from earned payments

But if you are the customer/ client/ user/ owner/ sponsor of the project, your value usually comes after the project is over. There is no business value to you in either planned value or earned value.

But no one really wants to go back to the bad old days of FLAs, so what should we do? In an IJPM article in 2005, Denis F. Cioffi suggested the following:

• SC = Scheduled Cost (instead of BCWS)
• AC = Actual Cost (instead of ACWP)
• EC = Earned Cost (instead of BCWP)

I like it. Makes sense. More accurate. More descriptive. Everyone should start using this nomenclature. Now.

Thank you. That is all.

Three types of projects?

Digging through my files in preparation for updating my presentation on “The Future of Project Management,” I came across an email I wrote to a colleague in 2001. I’ve never done anything with this idea, but it still rings true.

I think there are three major categories of projects:

• New product development projects. The justification for these projects is to develop something that will be sold: they are undertaken to solve someone else’s problem. The product of the project is the thing that will be sold. The product might be software, an airplane engine, the airplane itself, a camera, a training program, whatever. From a financial perspective, the profit to be generated from the product is a key decision in project selection decisions.
• Project-is-the-product projects. There is no direct justification for these projects: they are undertaken to provide support to someone else’s project. The product of the project is the work of the project. Most consulting projects fall into this category as do non-profit fund-raisers. From a financial perspective, the profitability of the project itself is a key decision in project selection decisions.
• Infrastructure projects. The justification for these projects is to fix a problem that prevents the organization from doing something as well as it could (this includes creating the capacity to do something it can’t). The product of the project is infrastructure: the ability to do something. Most internal projects fall into this category: IT, organizational development, strategic planning, etc. From a financial perspective, it is often hard to justify these projects since they deliver no direct benefits.

Let me know if you can think of any projects that don’t fit into one of these categories.

Project Success

This is an update of an article on my website.

Most people have an intuitive appreciation for what success is, but defining it and measuring it is a bit tougher. If you’re from Arkansas, Success is a small town not far from the Missouri border. If you’re an actor, Tom Hanks is a success while Tom Arnold is not … or is he?

If we define acting success in terms of critical acclaim, Tom Hanks wins over Tom Arnold every time. If we define acting success as steady, above average pay for work that you enjoy, then Tom Arnold is quite successful.

Projects are not so very different from actors. In order to measure success, we must first define it.

But how should we define it? To the extent that the project management literature of the 1960s and 1970s dealt with project success at all, the definition was usually limited to meeting cost, schedule, and scope constraints – was the project finished within budget, on time, and according to the specifications? Later, both quality and stakeholder satisfaction were often called out separately rather than being subsumed within scope.

The common theme in all cases was that project success was defined in ways that could be measured the day the project was finished. But what about the Sydney Opera House? It cost sixteen times as much to build and took four times as long to complete as the original estimates. A project management disaster produced an enduring and inspiring civic symbol. Was this project really a failure?

Dimensions of success. In the same way that quality requires both conformance to the specifications and fitness for use, project success requires a combination of product success and project management success:

• Was the project well-managed?
• Was the product (service, result, or outcome) of the project a success?

Simple yes-or-no answers will not suffice. We should not be asking “was your project a success?” We should be asking “how successful was your project?”

Different stakeholders will use different measures. The health and safety officer wants no injuries. The manufacturing manager wants a product that is easy to build. The ISO 9000 compliance team cries “success” if the documentation is complete. The VP of Marketing will be delighted if you get to market before your competition.

Beyond “On Time.” Project teams are fond of defining schedule success as on time. A lovely concept to be sure, but essentially useless from a management perspective. Here are some very basic questions that this phrase doesn’t answer:

• Is it okay to be one day late? one week? one month?
• If we finish early, is that bad?
• Are we measuring against the original schedule or the current baseline?
• Do individual activities have to be on time as well?

To help overcome the tendency to oversimplify, try using a structured format for developing project success criteria. For example:

• Stock intro: “one key success measure for this project is to have …”
• Measurable item: “the completion date of every major milestone”
• Comparison statement: “within”
• Some number: “one week of the baseline schedule date”

Most projects will have at least four measures of project management success – one each for scope, cost, schedule, and stakeholder satisfaction. Larger projects may have more (e.g., separate measures of stakeholder satisfaction for the customer and the team), but four is the minimum.

Product Success. Many of the potential measures of product success such as revenue and cost savings are beyond the direct control of the project team and will not be measurable until long after the project is finished. Nevertheless, the project team must know what they are so that project decisions don’t jeopardize the expected benefits. Product success criteria will generally fall into one of the following categories:

• Bottom line impact — revenue generation, cost reduction
• Operational impact — performance measures
• Market impact — share, potential, reputation
• Intellectual value — patents, knowledge, experience

Conclusions. As with any other tool or technique, project success measures can be overdone. Use the following checklist to help ensure that your measures are good measures. They should be:

• Complete—anything unmeasured is likely to be compromised.
• Relevant—variances clearly indicate a need for corrective action.
• Valid—measuring what you intended to measure.
• Easy to understand—so that people will accept them.
• Economical to obtain—know the value of the information.
• Timely—in comparison to the result measured.

They should also be subject to change control since they are likely to change during the project.

The bottom-line is this. Your project will be measured. Your stakeholders will decide whether it was well-managed. Someone will decide whether or not the project of your project was a success. Do yourself, your team, and your organization a favor and get these measures documented and agreed to right from the start.

Follow-up to Rant #3

I’ve just agreed to write a book about project life-cycles. I posted a request for sample project life-cycles to the NewGrange list server, and someone there sent me the list below.

None of these are project life-cycles. The first one, from Minnesota, inverts the relationship between process groups and project life-cycle phases with 100% of the technical work done in a “managing stage” that occurs after a WBS has been developed. How do they plan to develop a WBS before they have done any analysis for the system to be developed?

Are the project managers from all these states really that ignorant? Do they actually try to apply these concepts? Or do they just ignore them? Did anyone actually try to manage a project using this guidance before this junk was published?

Minnesota PMO project management Methodology

http://www.state.mn.us/portal/mn/jsp/content.do?subchannel=-536890651&programid=536910279&id=-536890276&agency=OETweb

Tasmania Project management methodology
http://www.egovernment.tas.gov.au/project_management

Virginia Commonwealth Project Management
http://www.vita.virginia.gov/oversight/projects/default.aspx?id=551

Michigan – Project Management Methodology (PMM)
http://www.michigan.gov/dit/0,1607,7-139-30637_31101-58009–,00.html

NY State OFT: Program and Project Management (CIO/OFT)
http://www.oft.state.ny.us/Policy/projectmanagementindex.htm

State of Oregon Project Management Office
http://egov.oregon.gov/DHS/admin/pmo/index.shtml

Words from Vic: On being heard

The NewGrange listserve (www.NewGrange.org) was my introduction to online interchange about 10-12 years ago. It remains one of my favorites because of both the erudition and the professionalism of the exchanges. One of my favorite posters is a gentleman named Victor Rosenberg who seems to have both read and retained virtually every book ever written on management. As well, he has an incredibly diverse background that ranges from Program Manager at PARC to CEO of a fair-sized insurance company. Vic has given me permission to post his NewGrange comments here on my blog which I will do from time to time. I will correct typographical errors, but other than that, these posts will be unchanged.

“I am not asking professionals to look for ways to hide their opinions — I am asking them to actually wrap their minds around the perspective that their opinions are not as objectively superior as they think. As they say — sincerity is not something you should try to fake. Nor is humility, cooperation, or respect.

“The professional’s position may be of value (for that matter, so might the cab driver’s), and it is reasonable to look for ways to interject the opinion — but all of the many successful ways I know fail if they are used as a ruse rather than as a sincere recognition that they are only opinions and that the target’s opinions are as valid.

“When I teach politics my starting point is get the student to wrap hisorher mind around the pressures facing hisorher target — how they are different from (and often more valid than) hisorher pressures. Only by understanding this can one also understand how to slip a new idea into the discussion without having it be ignored or attacked.

“Remember my adage ‘no body listens.’ The task is to address that phenomenon. Speaking is easy — being heard is hard.”