Risk Management

Eric Verzuh notes that sometimes it seems that for every risk problem solved a new risk appears (Verzuh, 2012) and that can be so true. Perhaps the biggest risk to a project is when the team skips risk analysis because they consider it unnecessary.  Out of the 5 risk strategies described by Verzuh: Acceptance, avoidance, contingency planning, transfer and mitigate, he seems to have forgotten one…ignoring…hoping it goes away. What I will describe here, briefly, is where the team decided a possible event wasn’t going to be a risk, and there wasn’t much evidence to support it as a possible risk, yet it eventually turned into an issue.

Kendrick describes a risk as almost any uncertain event associated with work. It’s as the insurance industry characterizes risk as loss multiplied by likelihood. I was the project manager of a project that was developing an intranet system that the U.S. Navy would use to manage the recruits at three naval bases in the Midwest, south, and eastern parts of the country. The navy had a big interest in using current web technology to develop applications that could be used to manage recruits from boot camp to deployment. When I first started I was a one man team doing mostly proof-of-concept (POC) work.

Two years into the project, by then I had a team of 15, it was decided we should re-locate the web and data servers housing this system to a server farm located at Pensacola, FL. The navy has two bases located on the peninsula, virtually on opposite sides. While developing the requirements for this project we discussed some of the risks we would face. Most of the team was worried about working with servers located almost 1000 miles away. They felt a big risk was losing internet connectivity. They also felt that not having direct managerial control was a risk; basically we wouldn’t be in control of the box anymore and they were not happy about that.

The process I recommended we follow was basic PMBOK: Plan risk management; identify the risks; perform qualitative and quantitative analysis; plan the risk response; and control the risks. While identifying risk was ok with the team, they weren’t exactly thrilled with having to develop a response to each risk. One risk I identified was the possibility of a hurricane wiping out the entire server farm. Everyone disagreed with me. I had pointed out the bases, and both the main server farm and the back-up server farm, were located in Florida, on the Gulf of Mexico, and on a peninsula. They felt that there was sufficient protection that a hurricane could never wipe out the entire farm. I asked them to humor me, let’s develop a mitigation plan just in case. They said ok, but it was never completed. My resources were all working for different departments, only part of their time was devoted to this project.

Some of you may remember a hurricane named Ivan. Ivan, a category 5 hurricane, hit landfall just west of Pensacola back in 2004. Ivan had a surge wave that was reported to be 26’ tall. Ivan basically wiped out the back-up server farm first, and then the main server farm. And we had no back-up plan in which to keep the system alive. Or so they thought. I guess this is one reason why I’m a project manager. I had a back-up system created at Great Lakes just in case. Cost was minimal as I used the old servers we had used before to run the system. I had created a contingency fund and I had a program created to monitor the systems in Florida. If either one lost connectivity the spare servers would immediately back up the entire system.

The lesson learned here is that as a project manager I have to be prepared for any and all types of risks. If it’s difficult to get your team to prepare the plan, then do it yourself. In the end it’s your job on the line if a risk becomes a reality and you didn’t plan accordingly.

References:

Kendrick, T. (2009). Identifying and managing project risk: Essential tools for failure-proofing your project. New York: AMACON.

Project Management Institute. (2013). A guide to the project management body of knowledge (PMBOK guide), fifth edition. Newtown Square, PA: Author.

Verzuh, E. (2012). The fast forward MBA in project management, fourth edition. Hoboken, NJ: John Wiley & Sons.

Website Pin Facebook Twitter Myspace Friendfeed Technorati del.icio.us Digg Google StumbleUpon Premium Responsive

Author: Rich Garling

Successful results-driven experience in IT program/project management, focusing on collaborating with multiple businesses and IT workstreams to define detailed business process requirements into workable enterprise software solutions for retail, finance, pharmaceutical, and inventory processes. A successful proven track record in leading cross-functional international teams of project managers while managing expectations and delivering projects of greater than $10M within stakeholder expectations. Provided an in-depth knowledge of SDLC using Agile and Waterfall project management methodologies (Scrum Master (SMC)), MS IT Management/Project Management (AMU)), and a talent for developing business requirements delivering workable technology solutions. Rich holds a Bachelor of Science in Political Science from Northern Illinois University and a Master of Science in Information Technology/Project Management from American Military University. He is currently a Project Manager III for Bradford Hammacher Group in Niles, IL/