Project Management Central
|
Please login or join to subscribe to this thread
|
||||
|
||||
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 
Network:648
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
ADVERTISEMENTS
|
"Always do right. This will gratify some people and astonish the rest." - Mark Twain |
