As a risk maven, I love encouraging organizations to build out a comprehensive risk register with all of the bells and whistles. Those bells and whistles?  Event, probability, impact, overall priority score, overall priority, risk owner, risk response, risk category… the list could go on and on. There are two tragedies that often happen; however, with this mountain of information:

1. The only person who knows what it all means leaves the organization

2. The information gets tucked deep in the bowels of SharePoint®, never to be heard of again

The risk register problem would likely go away entirely if every project had a project librarian or archivist, but that’s a luxury few organizations can afford. The somewhat amazing solution can be found in, of all places, Microsoft Project®. Most people don’t think of Project® as a risk tool, given that it doesn’t have all the flexibility of Excel® or other third-party add on’s. The real beauty with Project®; however, is that its limitations actually force better project management practice, particularly when its capabilities are flexed to serve as a home for the risk register.

In teaching risk management, I encourage participants to identify risk at both the project level and at the work package level. When using Project® in that regard, the opportunities are noteworthy.

As most advanced users are aware, Project® comes with 30 supplemental text fields, as well as 30 number fields. At best, most organizations use only a handful, but these should be any risk manager’s greatest friend. They can become the home for a task-specific risk register. They can also link out to risk register documentation elsewhere, if there’s a standard organizational “home” for that information.

So, What’s Different About Storing Risks in Project®?

If I asked you what the risks were on a home construction project, you could come up with a dozen quick responses and most likely they would all be completely unrelated. We could fail to get permits, stopping the project. We could have our master carpenter fall ill with some untreatable disease. We could decide to change the requirements, pushing back our ability to finish on time. With limited structure for the question, there is limited structure for the answer.

However, if we have a project plan carefully crafted and stored in Project®, we can now fill in the risk register on a task-by-task, work-package-by-work-package basis. Instead of looking at risks on the overall project, we can get down to where risks happen—in the specifics.

We are now asking at a detailed level—What are the risks associated with excavating the foundation?  We may fail to maintain the survey lines at the site, causing the excavator to dig the wrong hole. (And don’t think I just made that up. I asked a backhoe operator that exact question, and he shared that that happens on about every third project). If I have the columns for Event, Probability, Impact, Description, etc. set up within the tool, I capture risks for all of the work that’s being done. Not only that, I capture risks specific to the work and the work in progress. When work is actually done, I get to push back and say, “Can I now retire this risk?” and that’s not a question we often get to ask!

If we have gone so far to create labels for our Text17 and Number11 fields (by way of example), we can also create views. Views afford us the ability to create a standardized, up-to-date risk register, still related directly to the elements of work throughout the project or associated with work that remains in process or undone.

But, what if there are some global risks?  What about risks above the work packages?  Risks at the summary levels?

The same cells for the risk register exist at the higher levels of the WBS. Thus, it’s possible to have the conversation at both the micro- and the macro- levels.

If a more powerful, Excel®-driven, or Word®-formatted risk register is required, let us not forget the power of Paste-Link. By linking out to a risk register in another format, we are able to retain the information, tie it directly to the project (every time the file is opened), and not lose track of where we put those pesky risks.

Keeping risk information disassociated from project information is a tragedy waiting to happen. Many project managers would rather not deal with risks, particularly at a detail level. Many risk managers see themselves as oracles who should not be pestered to have a conversation about when and where the risks may transpire. With a simple connection between the conventional tool of a risk register and the tools afforded by Project®, we become more effective managers at all levels.

I invite you to watch my on-demand webinar, Those Darn Risk Register Boxes! What Really Goes in There?, to explore this topic more deeply.