The Need for a New Knowledge Area
Table of contents for Opportunity Management
- The Need for a New Knowledge Area
- The Case for Opportunity Management
- Effective Opportunity Management for Projects
Is the Sky the Limit?
So I’m doing some PMP sample test questions today and ran into one where at the end, additional things were added and the customer is very happy. According to the answer, this project was unsuccessful because the additional features were “gold plating” which wastes time and probably cost. Primarily, I got this wrong because I read “the project has added [this and that]” as the [this and that] = intended product of the project.
But there’s a deeper insight here.
Gold plating. What is it? To me, it’s when you add features or functionality without going through the change process. It’s unapproved scope creep….usually created by the project team themselves when it comes to the term “gold plating”.
Why does gold plating happen? Here is a theory.
- A project team member comes up with an idea that will clearly add value
- The thought of elevating it to the project manager, sponsor, or customer and going through the change management process is too painful to comprehend
- This kind of thing is usually thought of as scope creep, and therefore it is bad
- It usually never occurs to the team member that this is a “risk”
- If it did occur to them, the word “risk” attached to it would give it a snowball’s chance - even more painful to bring with the project manager
- so the team member finds a way to “squeeze it in”
- This may mean that other tasks don’t get as much attention as they deserved
In the above scenario, there’s no checks and balances on what adds value or not. So what gets gold plated? Usually only things the team member finds “cool” and enjoys working on. To them, it adds value. Does it add value to the project? No one knows in this underground way of doing it. What if the team member decides to just forget about it? No scope creep, no gold plating. That’s good right?
Wrong! If the team member just forgets about it, the project just lost information about a potentially valuable opportunity.
We need Opportunity Management
In the PMBoK guide, opportunities on a project are dealt with as positive risks within the risk management knowledge area. I believe this is the wrong approach.
- In practice, when people hear the word “risk” they immediately think negative
- expertise and processes that need to come into play with opportunities versus risks can be very different, although there is definitely overlap with risk management also
- A whole range of communication and practices dealing with the rest of the business come into play when you are looking for opportunities
- Tools and techniques around quantifying the ROI of a potential opportunity and then seeking additional funding for it come into play
- Lessons learned documentation specifically geared towards discovered opportunities
- Increased focus and transparency in the process of discovering, evaluating, and executing on opportunities all stakeholders identify while planning, executing, and closing a project.
I mentioned this to Greg Balestrero, CEO of PMI when the New Media Council met with him recently in Denver, CO. He was discussing the need to make positive environmental and social impacts through project management, and I responded with this point. I’m not sure what he thought of the idea, or if that’s even a concern of his. I’m sticking to my guns so far in the call to add Opportunity Management as a new knowledge area in the PMBoK. Maybe it will make the 5th edition.
Think about your own project(s), current or in the past.
- Did you or someone else come up with an idea that would have added a lot of value for the customer or business?
- Did it get shut down or never communicated because it would have resulted in a change to the project scope?
- Do people thus have a fear of speaking up about opportunities they think of while executing projects?
Leave a comment and let’s have a good discussion!
Dec 6th, 2008 at 8:02 pm
Hi Glenn,
Thanks for this reference. I had not read Conrow before.
But getting back to the thread, not sure if I missed something, but isn’t Conrow saying the same thing I did? That an effective risk management process addresses both the threat and the opportunity? (And I did not mean to imply that each threat had a “mirror image” opportunity)
In my classes, I start the process of risk analysis applying brainstorming techniques to create a force field analysis. (I apply this to each element of the WBS)
As an aside, has anyone noticed that many of the tools used in quality analysis are also the same as those used in risk as well?
As another aside,being a fan of activity based management, I tend to embed or “bundle” risk, quality, time, resources and cost into each WBS element and eventually into each activity. Does anyone else take this approach?
BR,
Dr. PDG, Jakarta
Dec 6th, 2008 at 9:56 am
Paul,
Regarding Risk and Opportunity, read Dr. Edmund Conrows article in the March/April Defense Acquisition and Technology journal.
https://acc.dau.mil/CommunityBrowser.aspx?id=194306&lang=en-US.
When you get to the page that asks for certificate invalid just say proceed. All US DoD web site do this.
As well Ed’s book, Effective Risk Management: Some Keys to Success, is mandatory reading in the Aerospace and Defense world.
Many of the risk and oppotunity discussion are formed around dictionary definitions of “risk” and “opportunity,” The quantative aspects of mixing these two approaches in ignored. To the riks of the program.
Dec 5th, 2008 at 7:05 am
Hi Bill,
To answer your questions directed to me:
1) THIS asapm competency credential http://www.pmcert.org/Prog_Overview.asp . Isn’t asapm the IPMA representative in the USA? Isn’t IPMA’s multi-level credentialing system advertised as being competency based? (I recognize that not everyone agrees it truly IS competency based) But at least it does require a 360 degree assessment AND submission of evidence backing up the claims.
2) “Best Practices”- I don’t disagree with anything you have said. The reason I am pushing for “best practices” has to do with the professionalization of what it is we do for a living. IF we want to professionalize the practice of project management, then we MUST move beyond MPMT.
Now, at least in construction, one of the standard clauses we find in AIA, AGC and EJCDC standardized contracts is “best practices of the trades” which a legal term with legal definitions and legal consequences for not following them. Are they actually written down? Obviously not, but one of the questions always asked by expert witnesses is whether or not what was done represented a “best practice” and through years of case law, this has been fairly well defined. (Not perfectly, and there are now and probably always will be grey areas, but substantially, yes)
AACE has addressed this by publishing RECOMMENDED practices, which they have put into the “public domain” under their copyright, but have done so at no cost. http://www.aacei.org/technical/rp.shtml
Notice that “recommended” practices are a far cry from MPMT, and I can say from first hand experience that courts of law will accept them, when presented through the testimony of an expert witness as being “best” practices.
BR,
Dr. PDG, Jakarta
Dec 5th, 2008 at 5:49 am
Folks –
Guess I missed a couple of posts here. Let me try to catch up …
1. Paul. What asapm competency standards are you referring to?
2. Paul. “Best practices” by definition differ by project and application area. It is quite literally impossible to develop a cross-application area standard that addresses “best practices.” Let’s use HS&E as an example. The vast majority of IT PMs have ZERO responsibility for that topic. The vast majority of OD PMs have ZERO responsibility, etc. This is not an either/or question, but both. We should be documenting and describing both best practices and those that apply to MPMT.
3. Josh. I don’t see a need for separate treatment of opportunity. Several reasons. In my experience, most opportunities are business opportunities that are outside the PM’s responsibility. Second, many of the other “sample” opportunities that I have seen are really just risks in sheep’s clothing: an opportunity to decrease costs is often a response to a risk that costs may increase. And third, until I see most PMs identifying real risks (like lack of sponsor support) rather than fanciful ones (alien invasions), I don’t want anything to distract from risk management.
4. Martin. Actually, I do support those decisions. I was the head of the Standards Committee at the time as well as the primary writer for the original PMBOK Guide, so I proposed and advocated for many of the decisions that we made and the criteria we applied. I only wish that the folks who took over from me and my team had been as disciplined.
5. Alex. Benefits usually occur after the project is finished. They are what I call “outcomes” (as opposed to outputs). As such, benefits management is usually outside the control of the PM. The PM may be able to influence benefits, but cannot assure them. For example, if I am the PM developing a new netbook, and marketing changes its mind about spending on advertising, the benefits from my project evaporate.
6. Martin. I see value management is product-oriented. If you add that, why not add requirements management, design management, etc.? In addition, the activities that you describe would typically happen in an early phase of the project and be unlikely to be repeated in any disciplined way in a later phase, so this idea fails that criteria as well.
Whew.
Duncan
Dec 4th, 2008 at 1:08 am
I think this thread brings us back to the issue of nomenclature and lexicon.
If you look at the BoK for Industrial Engineering, Systems Dynamics, Systems Engineering, Construction Management (Civil Engineering), Organizational Management, 6 Sigma Quality Management, Program, Portfolio and Project management, I think we are going to find that we are like the 7 blind men describing the elephant. The underlying animal is very large. The only significant difference lies in our perspective. http://www.gather.com/viewArticle.jsp?articleId=281474976747670
If you can find a copy of Drucker’s 1993 book, “Management: Tasks, Responsibilities, Practices” you will be able to agree that we have come full circle, and that “management is management is management”. Period. Same tools, techniques, process and methodologies, each applied under changing conditions. The ONLY differentiator I see is in the time horizons and perspective of each of the “blind men”.
BR,
Dr. PDG, Jakarta
Dec 4th, 2008 at 12:34 am
Hey Alex,
I think your entire post refers to value management. This whole benefit management term you have coined really does coincide with VM. Value Management is the balancing act of cost, quality and procurement (or resource selection procedures). A Value Management Workshop is a part of the VM process in a project where a selection of stakeholders meet and discuss several project solutions and analyze their value and viability. This process of:
- defining the problem
- identifying potential solutions
- testing viability or ‘value’ of solutions
- selecting solution
is virtually identical to change management processes. I think this value management or ‘benefit management’ actually should have a place as a new knowledge area. For this post I have continually mocked stupid suggestions made by some people for a new knowledge agrea. But Alex, I think you have made the most logical case for a new PROJECT MANAGEMENT knowledge area. Here here.
Martin Gibson
University of Technology Sydney - Project Management
Dec 3rd, 2008 at 11:38 pm
Josh,
I would recommend talking about “benefit management” instead of “opportunity management”. Many of the responses have drifted into risk management, where “opportunity” has a specific definition, as in “opportunity” vs. “threat”.
Reading your original post, I think you are talking more about what economists might call the “utility” of the project. What is the benefit or business result obtained by the project? When you say “opportunity”, I do not think you are talking about a risk-related event, but instead the chance to deliver something more or better than what was originally planned.
I think that “scope management” in the PMBOK Guide partially addresses this issue. If a developer comes up with a great idea, they can submit a scope change request, which will be evaluated to see if it is included in the project or not. The change control process should evaluate the benefits of the change in many different ways, such as cost, revenue, client satisfaction, regulatory compliance, and more.
I would love to see “benefit management” broken out as a better-defined objective in the PMBOK Guide, though. PRINCE2 is much more explicit about measuring and managing project benefits, and the PMBOK Guide could benefit from taking on some of these ideas.
Personally, when I write about business strategy and projects, I come across this issue all the time. I think that benefit management is critical not only in these odd spots where someone has an idea for a change, but also at the beginning and end of a project, where there is an opportunity to launch new projects or to redefine the project so it adds more benefits. Sometimes there will be external events, like a merger or marketplace change, which should also trigger a re-evaluation of project benefits. The PMBOK Guide as written does not address these events very well. Strategy and marketing books do a better job with these critical events.
Thanks again for a great article. You write some great, pithy stuff, Josh.
–Alex
http://www.alexsbrown.com/
Nov 12th, 2008 at 1:05 pm
Hi Martin,
Given that project management is a process, and given that the process of project management is embedded in virtually all existing professions, as well as most jobs, professional or not; and given that we can agree the process to fly a plane or build a building or perform an appendectomy most likely will be different, then why can’t we or shouldn’t we be willing to accept that application specific versions of the various Bodies of Knowledge would be desirable and appropriate?
I guess my frustration evolves from the fact that SH&E on the projects I work on (mostly oil, gas, mining and telecommunications tower construction) is a MAJOR element, both in terms of time and costs, so why shouldn’t it be an OPTION, available for those who need or want it? The same with Configuration Management any other topic that is necessary for an industry specific application?
Asked another way, who are we (or anyone else) to function as “gate keepers”- determining what should or should not be formally included? I routinely include SH&E as a stand alone knowledge area, as it certainly requires WBS elements, risk analysis, cost and schedule considerations. As a contractor, I have no choice, as the contract documents (especially for oil, gas and mining contracts) contain significant requirements for SH&E.
Bottom line on this one- I think the original PMBOK, which identified both core and supporting knowledge areas was a better approach, which set the stage for easily adding “sector specific” knowledge areas, such as SH&E or Configuration Management. Why not revert back to that concept, allowing for more flexibility?
BR,
Dr. PDG, bright eyed and bushy tailed here in Jakarta
Nov 11th, 2008 at 8:02 am
I think the criteria used for the project management areas is a good one. I personally wouldn’t change one of those points.
And far out it was a good thing that HS&E was rejected by the standards committee. Can you not see that HS&E is all about risk, quality and stakeholder management. HS&E has absolutely no place as a project management area. If HS&E was an area well why shouldn’t we have ‘machinery breakdown’ as new project management area…come on that’s pathetic.
And look I agree with Dr. Paul D. Giammalvo about going past the BOK and look at best practices. But look you have to understand what the purpose of the PMBOK is. Every good project manager and I am sure the people who write the PMBOK realize that it is not the be all and end all of PM, it is simply a guide. The PMBOK’s purpose is to teach students like me the basic principles and structure of project management knowledge. Then from there when I go into a specific industry I will then learn Dr. Paul D. Giammalvo’s ‘best management practices’. Which might include emphasizing the RISK of HS&E in the construction industry for example. Notice how I said RISK…In most learning institutions project management is taught as a whole subject, rather than more specific industry courses like manufacturing project management or IT project management (although they do exist I know). So project management areas should be generalized to suit all industries, but in the more specific courses industry best practices should be taught.
I find it interesting Bill about how they debated whether to use the double barreled names for the areas. Parts of me would love to see the names in there extended version (especially to stop these stupid debates about whether opportunity management should be a new area…RISK AND OPPORTUNITY MANAGEMENT < full proper title), but that would mean I would have to remember double though haha. And also Bill wasn’t advocating what was done he was just stating what the standards committee decided upon.
Martin Gibson
University of Technology Sydney - Project Management
Nov 11th, 2008 at 7:31 am
Hi Bill,
Couple of points I know we generally don’t agree on.
1) HS&E- just because it was “rejected” by the standards committee does not mean the decision was a “right” one. I notice that in the latest asapm competency standards, HS&E is included.
2) “Most projects, most of the time”- IF we have any hope of “professionalizing” what we do for a living, we need to move away from the concept of what is or should be done on “most projects most of the time” and start to look at “Best Practices”.
Putting this in context, if you are going to have open heart surgery, would you prefer to have a cardiologist who uses tools and techniques which are used on “most operations, most of the time” or would you seek out the cardiologist who employs “best practices”?
Given the rather abysmal success rate of projects (see recent research by http://www.FMInet.com) I think some serious paradigm shifts are in order.
BR,
Dr. PDG, Shanghai, China
Nov 10th, 2008 at 7:00 pm
Thank you for the perspective Bill! I would like to know what you think about opportunity management though. Do you think risk management covers it, or would separate tools and framework be helpful?
Nov 10th, 2008 at 10:05 am
Hard to decide whether to stick my 2 cents in here or not, but I thought a historical perspective might be useful …
1. Any debate about a “new” knowledge area for the PMBOK Guide should apply some decision criteria. Those we used in 1996 for the first PMBOK Guide were:
– Applicable to most projects, most of the time
– Project-management oriented (defining and organizing the work of the project) rather than product-oriented (specifying and creating the product of the project)
– Unique or nearly unique to project management
– Applicable within every phase of the project life-cycle.
HS&E misses on the first criterion, and requirements management misses on the second. Of course we stretched the point a bit for project human resources management and project procurement management.
HS&E was NOT rejected by “the IT folks” but by a Standards Committee that included people from EPC, defense, pharmaceuticals, etc.
2. When we were working on the 1996 Guide, we seriously considered compound names for many of the knowledge areas: project risk and opportunity management, project time and schedule management, project cost and resource management, project procurement and contract management. I’m pretty sure we had compound names for the other knowledge areas as well, but I would have to check my files since my brain no longer retains as much as it once did. In the end, we decided the expanded titles had at least as much downside as benefit.
3. The splitting of risk analysis into quantitative and qualitative analysis came in the 2000 version when the project risk management chapter was rewritten by a group of project risk management consultants. In my opinion, they wrote a chapter from the perspective of “risk management on a large facilities development project.” I do NOT feel that the current materials apply to “most projects, most of the time.” The additional process is just one of the many errors that I see in that chapter.
Duncan
Nov 5th, 2008 at 5:12 am
Hey Dr. Paul D. Giammalvo,
Yeah haha I realised you were being facetious but I thought I would just clarify that as some people often say that in some of the classes I attend. I will check out that source you mentioned it sounds really interesting. As I said in my post I agree that areas of general management practice are definitely required to become a competent project manager and also that the line between project management and organizational management (or general management) are often very blurred. Thanks for your insight.
Martin Gibson
University of Technology Sydney - Project Management
Nov 5th, 2008 at 3:45 am
Hi Glenn,
Hmmmmmm…….. Your comment about risk and opportunity not being two sides of the same coin befuddles me…….
Rather than rely on jargon, I always like to start with definitions from a reputable dictionary of the English language. I tend to use Merriam Webster’s On Line Unabridged Dictionary, from which I extracted the following:
RISK-
1 : the possibility of loss, injury, disadvantage, or destruction
2 : someone or something that creates or suggests a hazard or adverse chance : a dangerous element or factor — often used with qualifiers to indicate the degree or kind of hazard;
OPPORTUNITY-
1 : a combination of circumstances, time, and place suitable or favorable for a particular activity or action
b : an advantageous circumstance or combination of circumstances especially when affecting security, wealth, or freedom (as from constraint) : a time, place, or condition favoring advancement or progress. OPPORTUNITY indicates a combination of circumstances facilitating a certain action or inviting a certain decision.
Just to double check, I also checked out the definitions of Risk http://www.answers.com/topic/risk and Opportunity http://www.answers.com/opportunity and both sources confirmed what Merriam Webster had to say…….
So if RISK is the appropriate term to use for an adverse chance, and OPPORTUNITY as defined by several reputable English language dictionaries is a favorable or advantageous chance, then how is it you say the two terms are not opposite sides of the same coin?
But getting us back to Project Management, given that decision trees are one of the major tools and techniques we are supposed to be using, if each branch of the decision tree represents an OPPORTUNITY, and any given decision entails a combination of potential RISKS (downside or negative outcomes) and possible upside or beneficial outcomes, how is it you can possibly conclude the two are not one and the same coin?
BR,
Dr. PDG, Jakarta
Nov 5th, 2008 at 2:47 am
Hi Martin et al,
Actually, I was being facetious about the additional knowledge areas.
My point was and remains that, like the story of the 7 Blind Men and the Elephant, depending on our perspective, we can make rational arguments for adding many elements to the body of knowledge.
If you can find a copy, Peter Drucker’s “Management: Tasks, Responsibilities and Practices” Harper International 1973 serves as an excellent retrospective look at what/where/how project management seems to be evolving and when we add in portfolio, program, asset and operations management with project management (which we cannot help but do if we want to increase the overall success rate)it is becoming more obvious than ever that we are coming full circle to the realization that project management is but one form of general management, applied to a situation that has a defined start and defined finish.
Don’t believe me? Pick up any decent books on asset management or operations management and you will be find at least a 90% over lap in the tools and techniques, with the primary difference between the three being the time horizon….
BR,
Dr. PDG, back in Jakarta
Nov 5th, 2008 at 2:05 am
Just some points,
I agree with Dr. Paul D. Giammalvo that the PMI has made too much distinction between qualitative and quantitative risk analysis. The application of semi-quantitative data (that is applying predefined numerical data to qualitative analysis) is not only extremely accurate and quick but is a great way to bridge this divide. I must emphasize the definition of what project management is. It is management of a project that has a definite start and finish. Anything else is really organizational management. The adoption of configuration and program management as a project management area is absurd as they are ongoing organizational matters. However I am not saying that the applications of these areas like six sigma etc. have no value to the project manager (they certainly do). There is always going to be a cross over not only between project management and standard management practices but also between the individual areas of project management. Configuration management really is instigated by good project quality and risk management mitigation strategies. Good quality analysis probes seen at the project level will then be adopted as a way an organization can hold some consistency in quality of design, performance etc.
In disagreement though with Dr. Paul D. Giammalvo is the adoption of safety, health and the environment as new project areas. These areas are already covered by risk, quality and communication management i.e. the risk of safety, the risk of health, quality standards to measure these effects and communication with stakeholders to ensure environmental impacts are ensured. Project management should never be bias towards one industry. Just because these issues have particular significance in construction it doesn’t mean it should be a new project management area. Just like in an IT project the risk of market competition and cost blow outs is relevant it doesn’t mean that they to should be added as areas. Otherwise every risk area would have a body of knowledge and we would have 50 knowledge areas.
Now, getting more on topic, in response to Glen B. Alleman. I tried understand what you said, but it seemed very vague and I couldn’t see how your arguments actually endorsed your advocation. You were talking about how the project plan must respond to opportunities? That’s called the risk register and mitigation strategies?…That has nothing to do with the risk management plan not being able to be applied to opportunities? We must view the process of risk management as identifying risks (positive or negative) analysing risks, evaluating risks and treating risks. Can someone please tell me how this strategy is not the perfect way to deal with opportunities? It’s the perfect way as it realizes that perhaps not all opportunities can be acted upon and that opportunities need to be evaluated on there value. Also another great reason to have opportunity and risk management together is when applying mitigation strategies/ways to enhance the opportunity, project costs and resources can be well balanced and managed easier in one go.
And can someone please give me a valid example of how the standard risk management process can’t be applied to solve project opportunities? I recommend the book ‘Risk Management in Projects’ by Martin Loosemore et. al. it gives a very valid structure as to how risks and opportunities can be managed successfully together.
Martin Gibson
University of Technology Sydney - Project Management
Nov 4th, 2008 at 9:50 pm
Josh,
I’ll wait for clarity on your position. BUT, I caution again several concepts:
1. Risk and Opportunity are NOT the two sides of the same coin. Opportunities must have a project structure that can take advantage of this opportunity. If this opportunity were to emerge, the project plan must be able to respond to this “opportunnity.”
During project execution, the mitigation and/or retirement of risk provides the means to maintain the cost, schedule and techncial performance of the project.
A similar “structural” analysis of opportunity needs to be developed. This means the connections between opportunity and the variables of the project (cost, schedule, and technical performance).
So as you develop your ideas, ask why opportunity and risk need to be connected. Here in A&D opportunity is a trade study role during the early stages of the program - Phase I, where the baseline requirements are evolved prior to the start of the Milestone C (development and deployment). Prior to that (Milstone B), evolution is the process to increasing maturity.
Nov 4th, 2008 at 8:12 pm
Thanks for the comment Dr. Paul. I can agree with you that Safety, Health, Environment, and Configuration Management are also areas that could/should be added to the body of knowledge.
To the point you made with Drucker, I think one of the challenges is to not add so much that it starts to become ominous and unusable in everyday work. I listen to a podcast called Manager Tools, which is an excellent show with lots of great info about managing people. Episodes focus on a specific aspect. People management has “knowledge areas” and so does project management. There is a LOT of overlap between the two. I find that using a theoretical framework/documentation like any body of knowledge that breaks down components into things like “knowledge areas” to be very helpful. This is true for me whether the topic be general management, project management,science, etc.
BTW on your earlier comment, I plan on getting deep into competency-based certifications very soon. Thanks!
Nov 4th, 2008 at 8:38 am
For my two cents worth before heading to bed in Kuala Lumpur, I have no problem with the principle of Risk being two sides of the same coin, but I do think PMI has over-done risk by separating qualitative and quantitative risk into two separate processes.
However, IF there is going to be any “new” knowledge areas, I think we should include Safety, Health and the Environment as Knowledge areas. Coming from a background in Construction, those areas are of eminent importance, and with the problems with carpal tunnel syndrome, the disposal of used CRT’s, peripherals and plastic non-biodegradable CD’s, I think SH&E should have been included in the ORIGINAL PMBOK Guide, which the IT folks insisted be taken out……
FWIW, there is or at least was, a large contingent of people who wanted to see CONFIGURATION MANAGEMENT upgraded to a full knowledge area.
Bottom line on this- when we add in SH&E, Opportunity Management, Configuration Management, Portfolio Management and Program Management, haven’t we pretty much come full circle to what Peter Drucker simply called “Management”?
Hmmmmmmm……….
Good night from KL……
BR,
Dr. PDG
Nov 4th, 2008 at 8:24 am
Thanks for the feedback Martin! I disagree with you at this point, but my mind is open to the possibilities so further research may change my mind.
Nov 4th, 2008 at 5:40 am
This idea of having a new project management area for opportunity management is ridiculous. All the points you raised as to why there should be a new area are already covered by risk management, when risk management is done correctly. Just because there is a stigma behind risk being negative doesn’t facilitate the generation of a new management area when the technical definition of risk is neither positive or negative. You could perhaps advocate for a name change of the risk management area to project uncertainty management.
Martin Gibson
University of Technology Sydney - Project Management
Nov 3rd, 2008 at 1:12 pm
Excellent article Glen, thanks for the link!
I’ve read it and I believe what the authors are discussing is not the same as what I describe. I will be writing another post specifically addressing this article and further fleshing out my proposal.
Nov 3rd, 2008 at 11:58 am
Josh,
Working in a domain where risks are physically real, care needs to be taken when combining risk and opportuity.
http://www.dau.mil/pubs/dam/2008_03_04/conr_ma08.pdf is an introduction to these issues. As well Edmund Conrow’s book is a seminal work on manging risk - both technical and programmatic.
In the IT world risk is a very vague thing. Heavy construction is frimer, and in manned space flight absoleutly critical.
Nov 3rd, 2008 at 10:29 am
Hi Josh,
Maybe the approach should be to have Risk Management renamed to Opportunity Management. A positive opportunity becomes a good thing if it occurs or is implemented. A negative opportunity is a risk which becomes an issue if it occurs. Also a positive opportunity introduced during the project could be considered a risk as it could sidetrack the project, extend the deadline, or cause other impacts which might not be considered properly at that point in the project.
Regards,
Iain Cruickshank, PMP
Toronto, ON, Canada
Nov 2nd, 2008 at 8:52 am
Josh,
In order to pass your PMP exam (why bother, but that is a different story) you need to know that gold plating is the client getting something that he/she neither needs nor wants. Implicit in this is the fact the client PAID for it, directly or indirectly.
Speaking pragmatically, at least from the perspective of a CONTRACTOR (seller) IF I have a really great feature or idea and IF the client agrees it has value and is willing to pay for it, then we issue a change order and both the client and the contractor walk away happy.
But in my 40+ years of experience in project management, “scope creep” and “gold plating” are two very different animals. Normally scope creep comes from the CLIENT (buyer or owner) making seemingly small requests which grow ever larger over time, and which the contractor (seller), unless he is ever diligent, in trying to make the owner/client/buyer happy, ends up bankrupting himself…..
Bottom line here Josh- Given you already have a BS in Project Management, instead of wasting your time on what is nothing more than an entry level, knowledge based credential, why not challenge yourself by obtaining a competency based credential in Project/Program Management or better yet, assuming you have chosen project management as a career path, why not go for your Masters or PhD in Project Management?
BR,
Dr. PDG, from Kuala Lumpur, Malaysia