Every program manager has run into the same situation at some point in their career. You put together your program plan with lots of spreadsheets, Gantt charts, requirements documents, resource requirements, risk management plan, etc. You present the plan to management and everything goes reasonably well until you start to talk about risks and how to mitigate them. We’ve all heard the same old arguments. Management says “Risk? What risk? We have the best and brightest people in the industry” and the team says anything we can’t control is a risk “What if someone quits in the middle of the project”. In my opinion, both extremes are wrong.
Why management is wrong: Seriously, new product development means that you are doing something that has not been done before (possibly in the world but at least in the company), which means that there are unknowns and unknown items equal risk. Of course the degree to which the project is truly revolutionary vs. evolutionary will impact the level of risk the program is exposed to. As for having the best and brightest people, if every company has the best and brightest then no company does.
Why the project team is wrong: Consider your audience. Management expects you and your team to do your job, which means they expect you to mange standard day to day “challenges”. Therefore, if you load your risk management plan up with issues like “resource conflicts might occur” they are simply going to say “tell me something I don’t know”.
What is the right way to address risk? There are many ways to address risks; this is what has worked for me. The simple truth is that you cannot account for every possible risk; if you did you would probably never get out of bed in the morning (of course that may increase the risk of being fired so you are forced to make a trade off). In other words, life is loaded with risk; that is the cost of living. Similarly, projects are full of risks, some will be acceptable (getting out of bed) and others will be unacceptable (getting fired). Focus your efforts on the unacceptable risks, the acceptable ones are the cost of doing business and it is your job to manage them on a day to day basis.
What to do? Address the unacceptable risks while acknowledging the acceptable risks and reevaluate the risks continuously throughout the life of the project. Here is my simplified view of risk identification and mitigation.
1) When putting your plan together it is always best to start at the beginning and define what success will look like. Don’t limit yourself to the traditional triple constraint of Schedule, Cost, and Resources. Consider the total product offering and the customer experience.
2) Once you have defined what success looks like you can put the development plan together (as a good friend once said “there’s nothing more frustrating than trying to solve a problem that hasn’t been defined”).
3) Now that you have your success criteria and development plan defined you can start addressing risks.
a. Develop a check list of risk areas to assess:
i. Schedule
ii. Cost
iii. Resources
iv. Technology
v. Manufacturing
vi. Quality
vii. Customer experience
viii. Historical issues
b. Remove ambiguous language from your goals and specifications, there is nothing worse than a specification that can’t be verified. My personal favorite is when the system specification says the “system availability shall be the same as the previous product”. Of course the previous product says the same thing.
c. Work with your team to identify the risks along with the probability of occurrence and the potential hit. Remember, your team is filled with experts in each area of the program, take advantage of them.
d. Risk Impact: A simple way to look at this is to say the risk impact = Cost if the risk occurs x Probability of occurrence.
e. Determine if the risk is acceptable or unacceptable. Go back to your success criteria, if the impact of the risk does not prevent you from meeting one of your success criteria it is “acceptable”. However, if it causes a success criteria to be missed you need to make a decision; do I tweak the plan to account for this risk or do I identify it separately and ask to implement a mitigation plan either up front or at a future date when some trigger occurs.
4) Change the culture. Most companies reward people who make great saves on the project. Unfortunately, most of the time the people putting out the fires are the same people who caused the fire in the first place. If you change the culture to one where fire prevention is rewarded you will likely find there are significantly fewer “fires” on your programs.
5) Accelerators: Managing a program is like playing chess, the best players use all their pieces in concert with each other and sometimes sacrifice a piece to attain a greater objective. Projects are no different many tasks can be moved around to optimize overall performance so look at the positives, perhaps you can accelerate some tasks in order to allow more time for the really gnarly issues that will pop up later.
Summary: Risk is a part of anything worth doing, you take care of the acceptable ones and get management focused on supporting you on the unacceptable ones. When you present the risks put them in terms that management will appreciate, in other words what is the ROI for mitigating the problem. Finally, be sure to evaluate risks throughout the program, if you stick the risk management plan in the drawer you are sure to miss the biggest risks until they bite you!
Pingback: Project Management Blog Posts You Can't Miss -
Change the culture as a risk mitigation strategy? Changing culture takes years and a lot of time/money/effort/leadership/communication. Change the metrics, change how people are measured and rewarded and you will change their behaviours. You get what you measure/reward. Changing the metrics for a project is a lot easier to do that changing the culture of an organization.
One trick for addressing risk is to front-load the project with the riskiest parts. For example, if you’re creating a high-cost, high-quality alternative to an existing product, your first step can be to see how many customers have the budget for a high cost. It’s easier with the low-cost alternative: see who will use a low-cost version for free, then figure out how to charge for it.
People tend to save the big news for last, but when they do that, the big news ends up being the bad news. It’s better to spend 10% of the cost on finding out you have to scrap a project than to spend 90% of the cost before realizing your cost estimate was really way too low.
Pandemic is something that can be managed. Now, global recession is something that all need to include within the profile. We have experienced two in the last 7 years. Oddly enough, the industry that helped “Get America Rolling” is the one that needs the help now.
Global recession is the answer to globilization. We all want to trade and profit from global operations, well the globe is a much more difficult beast to manage. We can not control hundreds of governments, cultures, or political parties.
Remember to put “pandemic” into your risk analysis. That’s one I missed when assessing the risks to my global consulting business. Oops! I guess I just don’t have a big enough imagination for disaster. – Kimberly in Osaka
I agree! Pandemics, terrorist attacks, gas shortages, bad ice storms…there are many forms of natural and man-made disasters that need to be considered when developing your risk mitigation plans. One excellent way to reduce the impact of such things is to develop and implement a telecommuting policy. Establish work-from-home standards and, if you don’t have people doing it regularly, you should practice doing it with your key personnel from all departments periodically.
Being able to work from anywhere, anytime is no longer something for the future, it is here now and easily done effectively. We all need to embrace and even encourage it as an excellent way to reduce risk from unpredictable events.