Project Management

Project Management Central

Please login or join to subscribe to this thread
Questionable PMBOK Definitions
It's great to see PMBOK 7th edition finally evolving away from the (in my opinion) very dry and uninspiring "Inputs, Tools & Techniques, and Outputs" model into a more pragmatic and systems focussed guide.

However, there are still a few definitions carried over from previous editions that have yet to be updated. Two definitions in particular, I feel, are not quite correct. The first is PMBOK's definition of a project. Here they state that a project is, "A temporary endeavor undertaken to create a unique product, service, or result". This, I feel, needs to be corrected so as not to make the reader believe that the outcome of every project is unique. It is not. The Oxford dictionary definition of the word unique is, "being the only one of its kind; unlike anything else". While each project itself may well be unique, their outcomes are not necessarily so (although they may be). A project may be undertaken to create a carbon copy of something else. Therefore the outcome of this project is not unique, it is just new. Therefore, to be technically correct, I feel that PMBOK should revise their definition of a project to state that a project is, "A temporary endeavor undertaken to create a new product, service, or result".

The second definition that I feel needs to be corrected, is PMBOK's definition of risk. Here, they state that a project risk is, "An uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives". In my opinion, this is not a bad definition, but for one error and one omission. The error and the omission are both contained in the phrase, "has a positive or negative effect on one or more project objectives".

The phrase, "has a positive or negative effect" implies there is 100% certainty in the occurrence of an effect on project objectives. Now, while there is no denying Newton's 3rd law, in that for every action, there is an equal and opposite reaction, meaning that for every risk event that occurs, there will certainly be some effect. This does not mean there will be a guaranteed effect on project objectives. For example, there may be a risk event of bad weather disrupting project construction activities, resulting in health & safety, cost, and schedule impacts to the project. However, the bad weather risk event may equally have absolutely no effect on project objectives. It may just result in the construction site becoming a bit wet, while still keeping the project objectives of no injuries, no cost increases, and no delays completely intact.

The omission in the risk definition is where the phrase, "has a positive or negative effect on one or more project objectives" only considers project objectives, and not project values. It may be argued that one of the objectives of every project should be to protect its values. However, I have seldom seen a project charter, or scope of work ,that documents the need for protection of the project's values as one of its objectives. Objectives are normally defined as the project deliverables, such as a new product, service, or result. Project values, such as regulatory compliance, codes of conduct, human & environmental welfare etc.are equally important and integral components of any project and, as such, I feel need to be clearly included in the risk management process.

Taking these two important risk factors into account, I would very much like to see PMBOK revise its definition of risk to state that a risk is, "An uncertain event or condition that, if it occurs, may have a positive or negative effect on one or more project objectives or values".
Sort By:
I do not agree with some of your ideas. However, you better share them with PMI. They will take them into consideration for the next revision.
Michael -

I disagree with the first change as it would result in normal operational activities such as producing a quarterly financial report as being a project when it is just a process repeated on a regular basis.

I do agree that the degree of uniqueness varies project to project, so one clarification might be to call out uniqueness in the context of the project as opposed to the endeavor itself.

For the second definition, while I'd agree that dropping the "on one or more project objectives" might make it more generally applicable, if we consider Dr. Hillson's definition of risk as "uncertainty that matters", then the PMI definition incorporates the point that we want to focus on material risks and not those which "won't matter".

Kiron
Michael,

welcome to the community with your first posting.

Your suggestions may become roots for discussion and input of perceptions by other experts. In this view it probably is more effective to post them separately.

For the definition of a project, I agree with you it has been carried over from previous PMBoK editions.

Unique has been the wording for a long time, for the product or output of the project (the WHAT) and at times for the process of the project (the HOW). You offer to extend it to the values to be supported (the WHY).

I personally prefer the latest wording from ISO:
a project is a temporary endeavour to achieve one or more defined objectives (and they changed this from to produce agreed deliverables).

And I do not think that a PMs influence generally applies to the WHY. Means while some PMs might be able to create value, effect value, I do not not think that this is true for most projects, most of the time.

Hence also I would stick with the current definition of a risk and not add value.

Thomas
Although I have heartburn over some definitions in the PMBoK, I would argue that both definitions are correct as they are.

A temporary endeavor to create a carbon copy of a product occurs in operations as well. If however you are replicating an existing product such as reverse engineering, or creating it with new part definition, manufacturing planning, tools, or using a different vendor then the end product is unique because the product definition is unique, and the paperwork that produced the product is part of the deliverables.

As an example of what unique can mean, in large scale manufacturing, I can deliver a replica of a $200M airplane with no project even though it is 3 years in the making simply by energizing existing paperwork in business management systems. I can add one requirement to the next copy that does not physically change that product whatsoever, but a project is then required to verify the product already meets the requirement. The new product is unique because it is the first applicability of a new requirement.

This kind of distinction may seem pedantic, but in the world of configuration control including change management the definition of "change" becomes very important and doesn't necessarily mean any physical change to the thing produced.

As for risks, there are an infinite number of uncertainties in the world, but the definition of risk in the PMBoK must be taken in context of a project. If the risk of rain does not have some potential impact on a project at all, it may be a risk to someone else but not in the context of the project. It is merely an event. Risks are often probabilistic as well. The cost of something may be +/- 25%. The risk is not the uncertainty which may result in zero cost variance. The risk is the variance may be enough to matter. Likewise, the risk is not that it will rain. That is merely an uncertain event. The risk is that some level of rain will impact construction. "May" is integral to the uncertainty in the event occurance. I think adding the word "may" wouldn't hurt the definition, but the definition itself is correct.
I've worked on many projects that may have seemed identical, such as upgrading a client to the same version of a company product. Even though the implemented product was the same, the environment in which was it was implemented was different. Every time, I had a unique project and a unique result.
As for the definition of risk, I'm constantly reminded of the Wheel of Time's Law of Unintended Consequences: "Whether or not what you do has the effect you want, it will have three at least you never expected, and one of those usually unpleasant."

Please login or join to reply

Content ID:
ADVERTISEMENTS

"Always do right. This will gratify some people and astonish the rest."

- Mark Twain

ADVERTISEMENT

Sponsors