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:
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!