Surprises

I’m using the word surprises here because that’s how unanticipated risk events will appear to you. Not only will they be surprises, they will be nasty surprises; the kind that will cause your project sponsor to ask "….why on earth didn’t you foresee this happening?” Nasty surprises usually happen for 1 of 3 reasons:

1. Risks were not properly identified initially, during the planning phase of the project.
2. Risks which became apparent from learning during the construction phase weren’t properly identified or managed.
3. Changes to the project introduced new risks to the project which were not properly identified.

Project managers sometimes fail to identify risks because they assume all the responsibility for identifying the risks themselves and they are not the best qualified resources in the project to identify all the risks. Risks that are the result of the hardware or software chosen for the system are particularly susceptible to this failing. You won’t be an SME on technology unless you were a programmer or filled some other technical role immediately previous to your current role. Even if you are capable of identifying a risk event in this area, you don’t have all the knowledge you need to select the best mitigation strategies.

Project managers also fail to keep their risk registerscurrent. They may update the registers as they gather information during the course of the project but this won’t be sufficient to identify and mitigate all the risks of the project. Not having the SMEs on the team participate in risk identification and the development of risk mitigation strategies on an ongoing basis is leading cause of nasty surprises, especially on software development projects.

Failure to analyze approved change requests for any new risks they will introduce is another cause of nasty surprises. Changes are analyzed and the pros and cons identified that enable a good decision, and if that decision is to approve the change the project manager will update the project plans accordingly. Then a risk event that was introduced by the new feature and not mitigated will happen. Without a contingency plan the project manager is forced to go to the customer or sponsor and ask for relief.

Project managers frequently fail to ask for and manage a contingency reserve to manage the risks that no-one could have foreseen. The project manager will create buffers in their schedule to deal with risks that can be foreseen for tasks and deliverables in the plan, but these buffers will not be sufficient when a risk event happens that those buffers aren’t sufficient to handle. Imagine having to deal with a flood in the middle of the build phase of a project which shuts down the project for 2 weeks. You lose 2 weeks from the entire schedule which you didn’t count on. Unless you are able to make up the 2 weeks without an increase in budget or reduction in scope, your project changes.

Avoidance Strategies

Avail yourself of the best information available when you identify your project risks. That means that you must identify SMEs on the project team who are in the best position to identify all the risks to your project. These SMEs are usually the most experienced practitioners in the given discipline. For example, your senior business analyst for requirements gathering and specification writing, a senior programmer for developing software, and a senior tester for QA testing. Your Risk Management Plan should identify these people and assign risk management tasks to them.

Running a risk workshop at during the planning phase of your project is a good way to leverage all the knowledge of your identified SMEs. Risks are frequently identified in a brainstorming session that would not be identified otherwise. The shared knowledge can also trigger new thinking in the area of risk mitigation strategies. Avail yourself of the information from previous projects your organization has delivered. Examine all the artifacts, including issue logs/action registers, not just the risk register because the "nasty surprises” that hampered past projects may not be captured in the register.

Make risk identification and risk mitigation strategy development a regularly performed part of project activities. You don’t need the full-blown risk workshop approach for these on-going activities, you can make risk identification a part of each project status review meeting with the team. Don’t simply identify a meeting agenda item for risk identification and expect your team to contribute. You will have to work to solicit the information. Ask probing questions, such as "Your deadline for that task is ….. What could happen that would prevent you from delivering on time?” One advantage of making risk identification a part of your status review meetings is the focus on the on-going work. You will typically only have the team members involved in the on-going work attending the meetings. You may also want to conduct phase specific workshops towards the end of the current phase and before beginning the next one. These workshops should only involve SMEs who are involved in the work of the upcoming phase. For example you could hold a mini-workshop at the conclusion of the planning phase and before the build phase of your project.

Make the inclusion of a contingency reserve a part of your project plans. This should be negotiated with the project’s sponsors, or the executive steering committee. The contingency reserve idea may be easier to sell if you explain that any reserve not used will be returned to the funding organization. The reserve does not necessarily have to be defined in monetary terms; you can also use time as a reserve. If your planning identifies the 1^stof June as the final delivery date, add a month for a contingency reserve and plan to deliver on the 1^st of July. Make sure that you can take advantage of an early delivery date should you be able to deliver on the 1^stof June.

Every analysis for change requests should include the identification of new risk events. This includes those change requests which do not require your involvement. New risks identified should be managed in accordance to your Risk Management Plan. They should be captured in the risk register and then tracked. Once a risk event has been identified, you must follow up with the SMEs and develop an appropriate risk mitigation strategy. An SME who is capable of deciding on the acceptability of a change request should also be able to identify a suitable mitigation strategy for risks they identify. Ensure that the SMEs are trained to identify risks, evaluate the likelihood and impact and then report them to you. This part of risk management could form part of your Change Management training sessions. As you accumulate new risk events in your register you need to follow up with the SMEs to identify appropriate mitigation strategies.

There is another side to the identification of new risks that are introduced by project changes and that is the obsolescence of risks that were introduced by work that has been replaced. Make the identification of obsolete risks a part of the analysis of change requests. Retiring the risk mitigation strategies developed to address these risks will free up resources for addressing the new risks.