Saturday, 24 November 2018

Enterprise Risk Management vs. Project Risk Management

If you are a history buff like myself, you have probably come across the following statement, “Tactics win battles, but strategies win wars” or something to that effect. While I often find that martial analogies tend to be overused in discussions on project management, but I do think it is applicable when the topic is Enterprise Risk Management . Like an army, companies must adopt specific tactics to ensure the success of specific battles (projects), but at the same time support the underlying capabilities of the army (company) through high level planning and execution of strategies to ensure they win the war, or in the case of companies, remain profitable.

In the project management world, project managers are the officers who execute activities and tactics, monitor progress and make adjustments as needed to increase probability of winning the battle of delivering  a successful project.  In reality though, a significant portion of the risks and uncertainties that project managers face is beyond their immediate control and are symptoms of underlying weaknesses/strengths in their organizations capabilities. This type of risk has to be assessed and managed at a higher management level in the company. In this way we can see that risks can form a hierarchy  within an organization, each can have varying effects on different levels (projects, programs, etc) of the company. With this in mind, the manner in which the impact of these risks propagate through the various levels of the enterprise, should dictate the level at which they are managed.

Enter a formalized process of how to manage risks within an enterprise, which can be characterized as a portfolio of programs and projects. Enterprise risk management allows organizations to optimize how and where they manage risks. Some risks, which are specific to a location such a local regulations are best managed at the project level as they may have unique  characteristics that cannot be effectively managed at a higher level.  Manage other risks, such as resources, capital budgets, or changes in market conditions have systemic effects upon the entire organization and therefore need to at higher level in organization.

What this means is a practical sense is you need the capability to manage multiple sets of risks (risk registers) that represent each level in your organization. For example, an enterprise risk register, could include all of those risks that are being managed by the head office, program risk registers would be used to manage program capabilities, and project risk registers would be include risks that can be controlled  at the project level.  In addition, the system should support the ability to modify where risks are being managed based upon their cumulative impact on the organization. A common example we see is resources. Often resource availability is a challenge for project managers whose resources shared across multiple projects. While resource availability may manifest itself in delays at the project level, an enterprise risk management system allows you to monitor the cumulative impact of these risks at a program level and apply appropriate actions to mitigate or alleviate the impacts. If a risk is critical enough, management of the risk can be transferred up to the  program level. This does not mean that a program risk will not have impacts on the underlying projects, but rather responsibility for reducing or resolving it will now be the responsibility of the program manager. In the example above, project managers would still have to account for the possible impacts of scarcity of resources, but would no longer be responsible for management of the risk.

The point of all of this is that Enterprise Risk Management allows you to address those underlying strategic or systemic issues that affect an organizations capability to deliver value, while delegating situation specific  actions or tactics to the level  at which they can be most effective.

Sunday, 4 November 2018

Project Risk Management Software Features

Here is a little experiment that you can try, type “Project Risk Management Software” into Google or other search engine. Not only will you get thousands of hits, but if you examine those that actually link to sites that are selling or marketing software, you will find that they offer a wide range of capabilities. Some are very simple, some quite complex, some look like they are purpose built, that is they are specifically designed for project risk management; whereas, others appear have been included tangentially and offer little clue as to why they were included in the list. With so many solutions available, it can be difficult for someone unfamiliar with this particular topic to separate true contenders from the pretenders. With that in mind, I will now present an overview of what capabilities project risk management software should have. Further, I will separate these out into Mandatory and Nice to Have categories.

Must Have Project Risk Management Software Features
Perhaps the single most important capability provides users a method to identify risks. This identification includes properties or additional data that each risk should include. This data includes: a unique ID, name, date identified, name of identifier, description or risk statement, threat or opportunity, and status (open or closed).

The next set of capabilities required is for risk assessment. Risk assessment requires the capability to add probability and impacts for each risk and impacts must be broken down into categories such as cost, schedule, or performance. The risk assessment should be flexible to support different risk scoring methodologies and algorithms.

You must be able to assign a plan to each risk. Plans can include a strategy that typically is broken out into four categories: transfer, avoid, mitigate, and accept. Risk plans should have steps or activities that will be used to control the risk that include planned date for completion, expected result or changes to the risk score, owner and status.

Each risk should include a record of changes that have a time stamp as well as who made the changes. This can be incorporated with the ability to add notes, comments, reviews, or additional information that can be added to each risk over the course of a project.

Finally, there should be a variety of customizable reports for either individual or multiple risks. Typically, this can include a risk register, risk matrix, and individual risk reports.
Nice to Have Project Risk Management Features
Integration with other project management software is extremely useful. For example, of the risk registers are saved in Excel. The ability to import Excel spreadsheets into your risk register is extremely helpful saving both time and money. If you are performing quantitative project risk analysis, integration with project scheduling and cost estimation tools is invaluable.

For quantitative risk analysis, Monte Carlo simulations are recommended. The Monte Carlo analysis should include the ability to model both risk events (risks) and uncertainties (3 pt. estimates) for cost and resource loaded schedules. The analysis should include a full slate of statistical reports including probability histograms, cumulative probability, and sensitivity analysis. Make sure that the Monte Carlo is designed to run project risk analysis; you should be able to run large schedules (e.g. 1000 activities) in under a minute. Comprehensive quantitative risk analysis should also include additional capabilities such as conditional and probabilistic branching and scenario analysis.

There are probably additional capabilities that we could add to the list, but this is a good starting point for evaluating the quality and capabilities of solutions when you are looking for project risk management software.