Hi David, et al. Thanks for the thoughts. Here are some inputs:
1) I advocate use of the meta language tandem for risk because many people struggle with risk descriptions and this is the most useful way of helping, from a practical stand-point. We must articulate both risk and cause and it should be concise -- this tools facilitates that.
2) I understand why PMI uses the term positive risk for opportunities -- for it enables opportunities to be aptly covered within the risk discussion. This definition does, however, depart from the dictionary definition of risk, so I try to be as agnostic as I can, for most business people I know refer to risks and opportunities on a regular basis and I do not want to alienate (or argue with) them in any way by insisting upon the use of positive and negative risk. I thus use the term "risk (threat)" when communicating the negative impact, and "opportunity" when referring to the opposite -- a "practical" way of addressing this topic
3. I address the phased approach in Chapter 2 under Product Development Cycle (pg. 13), and clearly support this as a way of managing overall project risk. What this does, if implemented properly, is allow for resetting the project baseline at various stages, when progress has been made, risks have been either eliminated, mitigated or not (i.e. turned into issues), and a more solid go-forward plan is able to be constructed. The DoD has done this via breaking programs into projects and establishing continuation follow-on projects over time (e.g. maybe letting several Exploratory Development contracts, followed by a down-select to fewer Advanced Development contracts, followed by one or more Engineering Manufacturing Development contracts, etc.). Basically, this enables you to make some overall cost, schedule, scope and quality assumptions to take away some early risk, then re-baseline subsequent work based on the outcomes -- lower overall program risk.
Has anybody experienced a difficult project situation relative to expectation differences between executives (or functional management) and the project team, or situations where it seems like the team was in a no-win situation. Many of these types of issues can be addressed via holistic project risk management practices. If so, please share, and lets discuss. Thanks. Saving Changes...
In response to the post about expectation disconnect ... Currently running strategic projects / initiatives under a new 'epmo' model which calls for identifying specific financial improvements, such as margin improvements, for every strategic project.
The scope on most of these strategic initiatives is process improvements which 'should lead to' financial improvements, however, there are other influences outside of the project like market costs / market pricing from competitors that probably has more influence on things like gross margin than what the project will accomplish.
Executive leadership expects a specific number identified for the project, yet the project team knows that it is almost impossible to define a specific number improvement from the 1 process improvement / implementation. Often the process improvement starts as a limited pilot with a goal of deploying across the entire organization.
Looking forward to reading the book to glean how better to deal with this type of risk (eg. risk to having a 'successful' project outcome due to expectations & demand for a number) Saving Changes...
I've seen this type of situation way too often throughout my career. On one hand, the business needs to make money and executives feel that they can make these requests to push the project teams to perform better. On the other hand, the project team wants to have a fair chance of being successful, and not blamed for attempting to be heroic (good team players).
This type of situation is the reason I am such an advocate of Overall Project Risk Management (cost and schedule risks) via simulation and modelling. People, in general, have difficulty interpreting Individual Task Risks -- especially relative to what they mean at the overall project level. It takes knowledge, good tools and techniques, and reasonable back-up (bases of estimates), but if done well, can provide solid rationale that most people can understand. The risk output is articulated as % Confidence -- and most people understand what that means. 100% - % Confidence is the % Risk. Demands to hit certain numbers can be solved (as you imply) by absorption of and unreasonable amount of risk. So, provide that % Confidence, and let the stakeholders accept the risk. Do the best your team can do. If the confidence level is low, then it should not be a surprise to anyone if and when project commitments (costs and/or schedule and/or product quality/requirements) are missed -- at least it is explainable.
This type of scenario inspired me to write this book -- which goes into detail on the practical application of simulation and modelling. Hope it helps.
I'm checking up on things to see if there are any related questions or comments for me to field. I enjoy the dialog and will do my very best to be provide productive insights.
Bests, Mike Saving Changes...
Hi Mike, it seems an interesting book and i am looking forward to reading it!
I wonder if you talk about decision making and relate it to Prospect Theory. Executives normally are risk seekers when risk confidence is low. Thanks a lot! Saving Changes...
Hi Jose. I'm a big fan of probabilistic statistics and using them to improve both project and business success. The book focuses on project risk, but the principles definitely relate to Prospect Theory -- which I have used relative to business forecasting. Take a look at the content of Chapter 9. I first used modelling and simulation techniques to determine overall schedule confidence in the early 1990's. Figure 9.4 on page 100 shows historical data from a project I managed. This histogram was developed prior to the start of the project (2 years earlier, in 1994). Below is the story:
After completing negotiations for this FFP (Firm Fixed Price) two year development project/contract the President of the company brought in a new schedule support team. We were using an IMS (Integrated Master Schedule) already, but this support team introduced an add-on for performing Monte Carlo modelling and simulation. So I got the team together to establish 3-point estimates for risky tasks/activities and we cranked out the probabilistic results. To my surprise, I only had an 8% confidence level in meeting my final deliveries (on May 31, 1996) -- I was a bit surprised, and I knew that given we had about a month until project kick-off, I had to figure out what to do to improve that projection. Figure 9.4 was the result of that exercise. My corresponding critical path end-date in my IMS was April 10th 1996, and you can see from the cumulative probability S-curve that the critical path end date confidence level was less than 1%. Turns out, using this set of tools and EVM (Earned Value Management) we were able to make our final deliveries 1-1/2 weeks early. We never re-baselined, and not only made our profit, but received 94% of the award fee. I've been a true believer in this methodology ever since, and am delighted to have had the opportunity to help people rationalize it and consider its application.
Hope you enjoyed the story. Best of fortunes to you.