Tag: Risk Management

The 6 steps to Risk Management Analysis

Risk in projects is inevitable, and it is how they are treated and mitigated which can influence success. Risk management is a routine used by project managers to minimize potential problems that can affect the project.

Risks are possible events that can impact resources, processes, technology, or project participants during the system development lifecycle (SDLC).

The results of risk are often unclear before it strikes. Through risk management, threats can be estimated beforehand and control measures put into place if necessary. Risks can arise from anywhere in the SDLC. Even as organizations venture into new projects, there is a need to monitor the ones in operation. For this reason, risk management is continuous.

Risk assessment and management can be made less tedious by creating a risk management protocol. It may comprise of a consistent set of tools and templates as well as training of project participants. By embedding risk management into a daily routine, the company can assume better health and overall performance.

The 6 steps to risk management is outlined below, they can be eliminated, mitigate its impact, or accept if the consequences can be accommodated. However, the course of action should be a result of careful consideration and collaboration.

1. Risk Identification

It’s impossible to solve a problem that can’t be pinpointed. Risks can be identified in different ways, via interviews, brain-storming, root analysis, and more. Visualize the project as if it’s complete and running. Think about what could go wrong and note any fears down. Historical data should be analysed, lessons learnt is a great way in reducing the impact of a risk, and record any deficiencies found.

Set up interviews with the help of the project team, colleagues, and stakeholders to gather information on issues to emphasize. Consider inviting people known for critiquing. Their opinions can divulge essential insights which could have easily slipped through the cracks.

2. Risk analysis

After populating a list of potential problems, the next step is to determine the likelihood of each. Fill this information in the risk register and think about the possible consequences if the risk came true. Some questions to ask at this stage would be:

  • Can the risk lead to project failure or delay?
  • Will it raise regulatory issues?
  • Is there a likelihood of legal disputes?
  • How does it relate to various compliance standards?

Evaluate all possible outcomes if the risk happens no matter the magnitude. The process can be tricky because there is never enough information. Find out if the organisation the risk assessment is being performed for has a checklist. Compute the risk factor associated with each risk to estimate the severity of the probable impact. Qualitative and quantitative analysis techniques and tools are useful in risk analysis.

Once various risks have been analysed, a picture of their effect on the budget, scope, and the timeline of the project should be formed. At this stage it could be defined how the risks can affect the quality of your project.

3. Prioritization of Risks

Risk levels are different, and there is a need to distinguish them based on severity. Without this knowledge, appropriate control measures cannot be put in place to tackle the threat. Unpreparedness often leads to project failure or over expenditure when fixing issues.

An extensive list of risks can be intimidating, but they can be handled by classifying risks as either low, medium or high. Address high risks as soon as possible, an e.g. in IT projects is poor data integration between two technologies.

Medium-priority risks are worth attention, they’re impact can be mitigated with appropriate controls. Low risks may have little to zero influence so they can either be controlled or accepted.

4. Risk Assignment

For tracking purposes risks should be assigned to someone, look for talented individuals within the team and let them oversee risks. Apart from monitoring, they should spearhead the resolution efforts for the uncertainties. Failure to assign risks negates the effort of identification and prioritization. The project would ultimately suffer the maximum impact, accumulate more risks, and likely fail.

5. Response to Risk

Once the threats are known and they are ready for resolution, before any action is taken, separate positive risks from negative ones. The latter represents events which threaten to cause harm. A positive risk is an unplanned situation that can be exploited to benefit the project. Some people look at it as a condition that produces too much of the desired deliverables. Decide the action to take.

Create a plan to mitigate all risks that can hurt the project. The strategy can be through preventative measures or a contingency plan. Together with the risk owners, decide which approach solves the problems best.

6. Risk monitoring

The risk owner will continue tracking the risk to see how it responds, and determine any new threats that might develop. It’s crucial for all parties in the project to understand risk management measures. When they are transparent, the team will be proactive as they will know what to do. Set up different channels for efficient communication with the team.

How Risk Management Relates to Compliance

Modern SDLC relies on agile development, a methodology based on the 12 principles of the Agile Manifesto. Agility, in this case, means that the software product can adapt to changes through its lifecycle, as compliance projects are assuming the shape of agile development.

Government compliance regulations are continually developing. Therefore, these policies affecting the organization and implement should be known within the project. These include standards established with the industry as well as external regulations that touch the business. Compliance can be accommodated by planning project management to identify risks emanating from the outside.

Automation for Agility in Compliance Projects

Since compliance mimics software development projects, automation can enable organizations to meet standards effortlessly. For vendors to satisfy the needs of their customers and protect their information, they must be compliant. They can generate and monitor customer risk profiles and act accordingly to maintain trust.

By providing communication tools and motivating stakeholders, promote compliance in the organization. Self-assessment and audits inform the compliance department whether their controls are adequate.

Businesses should provide compliance officers with the tools they need for compliance projects. By so doing, customers and partners will rest assured organizations are at par with standards.

The Challenges of Risk Management in Projects

Good risk management seems to be a challenge in most projects and can affect its delivery. The subject is often taught, analysed, spoken about, and reported within organisations EPMO’s. It then comes as a surprise when projects and programs fall well below their key delivery benchmarks and, more often than not, the reason is an unidentified risk manifesting itself into an issue that impacts adversely on delivery. Considering the number of projects conducted and the documents associated to risk, the effort that goes into quantifying the risks of a project should not be missed, but they still do.

The following are possible reasons why risks are still not always adequately identified, understood and how they can negatively impact projects large and small alike.

Emphasis on regular outcomes

Project teams are hard-wired to deliver, and never more so than in the current delivery environment that heavily favours agile techniques whereby delivery is an on-going cycle. This emphasis upon regular outcomes drives a delivery focused mentality within many teams. This focus can, however, have a negative impact on risk management as it is exercised within the team.

As agile continues to propagate the emphasis on continual delivery can make risk management seem like a handbrake to the speed with which teams are now working at and as such it gets put to one side in the rush to hit delivery deadlines.

Experience

IT Project Management within the business and IT world is relatively new, unlike the construction industry whereby project management has been taught and valued since ancient civilisations. The relatively recent introduction of project management within the white-collar sector has led to the rise of tertiary qualifications. There are also many stand-alone bodies providing varying degrees of project management qualifications and risk management.

The mechanics of managing risk can seem straight forward from the comfort of a textbook or course. The reality of the effective application of risk management can be varied when delivering a project. Possibly for two reasons;

Firstly, good risk management requires the ability to identify potential risks. This requires imagination or experience which is often formed heavily by past experiences of what can happen in certain situations.  The lack of imagination or experience can and normally does affect the risk assessment. For example, when laying fibre cable, time should be added when dealing with Government bodies, such as councils or heritage listed environments, all adding time to project delivery.

The second issue and how to avoid potential risk, is the input or buy-in from a wide range of people. Some of whom may be time poor or they may actually be hostile to the project. This is where stakeholder management becomes critical. If a project manager does not have the ability or experience to get all the right people engaged then running through the risk management process per the textbook will not be enough.

Only positive news

Many organisations expect or want only good news, which is valued by the executive over the ‘real’ news. This drives certain sub-optimal behaviours in an organisation that will work its way down into project delivery. Calling out risks frequently and possible issues can be seen as antagonistic to an executive who just wants to hear about what is going well.

This dynamic can lead to the less experienced or robust project manager to prioritise the good news over the possible bad news and keep the risk and issues toned down or off the agenda altogether. This is a head in the sand mentality that does not promote good risk management practices.

The list above is not exhaustive but is a good indicator of why risks continue to surprise some projects to their detriment. Of course, identifying the risk is just the beginning and does not mean they will manifest themselves into significant issues. If nothing else it provides the team with the ability to have robust mitigation plans for them if they occur.