This blog post was written by Jeff Miller.
No matter what type of project you work on, risk is something that you should consider managing.
The Oxford English Dictionary defines risk as an uncertain event or condition that, if it occurs, has an effect on at least one project objective. What I have found over my years in our industry is that most project managers feel they have no control over risk because of its uncertainty. I have found, though, that managing risks is actually very rewarding and provides tremendous value to the bottom line of your project as well as the company for which you work. While it is true that risks are uncertain, many, if not all risks are easily managed if you can break them down to identify the drivers of the risks and address the actual drivers themselves.
As an example, let’s say that your project has liquidated damages associated with the substantial completion date of the project. If that is the case then obviously anything that could cause your schedule to slip could cost your project and your company a considerable amount of money. As I am planning the project and schedule my first risk review meeting one of my team members brings up the fact that they feel there is a large chance that the schedule is going to slip by a couple of weeks. If I was like most project managers I would do my due diligence and write that risk in my risk register, assign a value to is based on liquidated damages for two weeks, and then ask the team how probable this risk is to occur. The team would assign it a 90% probability. Now I begin the hope and wait game! I hope it will not happen and I wait to see if it does! That doesn’t seem much like “management” of risks though. Does it?
When I hear a risk like this I start asking the “Why” questions. “Why do you feel we have a possibility of the schedule slipping by two weeks?” What I find out are things like, “Well, we have worked with this GC before and they are always late on getting us the information we need to make design decisions.” Or “Well, I know that John is busy on another project and he won’t be freed up for two weeks.” After hearing the drivers of the risk I now have information on which I can actually act and address. If I know that the GC is always late in getting us information I need to start communicating very early with them about why it is important that we get Requests for Information answered quickly. I will also monitor them much more frequently and follow up with them more often. If John is really the holdup then we can begin working with the resource manager to free him up sooner rather than later. We could also consider whether it specifically needs to be John that works on this project and seek alternatives.
As you can see from this simple example, when you break the risks down to their drivers you start to see a picture of how you can actually manage the risks. By managing the risks you are now in the driver’s seat and not setting in the back seat letting the project manage you!
