My experience in recently implementing a project peppered with risks has reminded and convinced me that having a solid risk management plan is not a luxury, it is a necessity.
And what have I learned? To substantially increase your changes of project success, you must develop and communicate
your risk plan before you actually execute your project.
My project started when I was handed the classic “”looks like I am doomed before I start”” type project. The go-live date could not be moved, the project was already five weeks late in starting and the two previous attempts to implement the desired results had failed.
In other words, the light at the end of the tunnel was clearly an inbound train.
The project was to implement time tracking across a 300 person IT department and, at the same time, upgrade 45 project managers to a new scheduling tool: MS Project 2002 Server. This was the new edition of MS Project that requires detailed project plans to reside on a server and to have about 250 I.T. personnel enter their time weekly. So, with 90 working days until the go live, there was no time for a pilot. It was clearly a case of fasten your seatbelts, because the system was going in big bang style.
First up, I created a risk management plan. Tip for Success: Don’t go it alone — pull in your project team, and use their experience to identify project risks. Have them brainstorm how to manage those risks. Encourage them to be part of the solution also increases their confidence. After the discussion on risk, the team’s confidence went from 74 per cent to 88 per cent. There is a solid correlation between a team’s commitment and confidence and a project’s success.
Most of the project risks centered around organizational change. Tip: Visualize that your project actually ends six months after it is implemented, this way you will be sure to consider the operational risks that your project may face once the go-live has occurred.
For example, the biggest risk was that the 250+ individuals would not accept the system. We managed this risk by transferring the responsibility to the various functional areas. Thus, the onus was placed on the functional managers to ensure their team members complied with the new systems and processes.
Finally, your risk plan must be communicated to your sponsors. A well-documented risk plan is your way of telling your sponsors:
1. This project has dangers;
2. There are choices available on how to steer clear of those dangers; and,
3. Individuals beyond the project team have some ‘skin in the game’ in terms of managing some of the risks.
So, involve your team to identify risks and to find solutions, then reach beyond your project team to those who have the authority to best resolve the risks. Your well-developed risk plan will guide you through the rough waters ahead, so refer to it weekly as you navigate through your project.
