Risk Management

What is risk to you?

Risk is an uncertain event or set of events that, should it occur will have an effect on the achievement of project or operational objectives. We can further expand on this to say that uncertain event(s) can present an opportunity or a threat to achieving the organisation, portfolio or project objectives.

How is risk management best achieved?

Risk management is best achieved through a systems approach rather than a silo approach. The reason for this is that risks do not respect organisational boundaries.
Ideally there needs to be an organisation level policy and process guide for risk management, then for each programme and project organisation you can if necessary have a risk strategy that is tailored, while at the same time being aligned with the company/corporate risk management approach.

The illustration below will show the different perspectives from which risk management should be addressed. Each perspective has a different but complimentary set of objectives. By understanding the objectives of each perspective individuals and teams will be able to focus on managing risk in a structured and effective way.
Organizational perspectives for risk management

Use a common process

The illustration below represents a simple process that can be used across the organization for identifying and managing risk.
Simple process that can be used across the organization for identifying and managing risk

By following a simple process as illustrated here you will have a tremendous impact on reducing the threats to projects and maximising the possibilities of exploiting opportunities.
Communication is central to identifying new risks, and changes in existing risks. Effective risk management is dependent on participation, and participation in turn is dependent on communication.
Effective risk management will contribute to improving the realisation of strategic, programme, project and operational objectives through:

  • Reducing the number of surprises
  • More efficient use of resources
  • Reduced waste
  • More focus on doing the right things properly

By having a systems approach to risk management it easier to escalate or delegate risks and manage risks more effectively.

As a rule of thumb manage the risk from where it will have an impact. If the risk will have an impact outside the project but within a programme then the ownership of the risk will be at the programme level, it may well be that the risk actionee (the person who is delegated to take care of the risk) is in the project team, so the risk owner and risk actionee must collaborate to ensure that agreed actions are taken to manage the risk.

Objectively measure if your risk management is working

It is important that you have a well thought through set of performance indicators to determine if your risk management process is effective and working. Having risk management policies, processes and strategies does not mean that you have effective risk management. You also need an effective measurement process to prove your risk management is working.


Risk management from the project perspective:

The primary objective of a project is the output in the form of a product or service that will give the organisation the capability to achieve the desired outcomes and realise benefits.

The following objectives can be used to identify risks to the project.
Cost: (Deliver the project within the budgeted cost.)
Time: (Deliver the project within the budgeted time.)
Scope: (Deliver the project output with the required features so that we have the right capability.)
Quality: (Deliver the project with the quality mentioned in the project and product definition.)
Benefit: (Ensure that at the end of the project it is still feasible to realise the targeted benefits.)
Team work: (Have a well-functioning team, as a dysfunctional team will result in not achieving the above performance variables.)

Who should work with risk management at the project level?
Everyone who is involved in the project organisation. When necessary the project manager will raise risks to the programme or portfolio level.

Risk management is a theme throughout the project lifecycle. Everything you do has an impact on risk management. If you tailor the project processes and do everything correctly you minimise the possibilities of uncertain events occurring.

Risk management from the programme perspective

At the programme level you will want to be aware of and take ownership of risks that will have an impact across the projects within the programme. These risks are likely to affect the capability of the organisation and the realisation of benefits that the programme was set up to realise.

Who should work with risk management at the programme level?
Those who are in the programme board such as the programme executive or senior responsible owner, the programme manager, business change manager and personal in the programme office. The programme manager can raise risks to the programme sponsoring group or the portfolio if the risk(s) will have a strategic impact.

Risk management from the portfolio or strategic perspective

At this level risks that impact on the organisations objectives and critical success factors should be managed and monitored. We are talking about risks that impact on the organisations reputation, financial security, capability to continue supplying a relevant service or product to the market.

Who should work with risk management at the portfolio or strategic level?
At this level the portfolio manager will monitor risks on a day-to-day basis. The CEO, CFO, COO and other senior managers should be activly involved in risk management.

Examples how this model of Lean & Agile Project Management works with risk management.

The following examples will illustrate how this project management model has evolved to mitigate threats and exploit opportunities.
Risk: The product owner does not know exactly what output will be most suitable to achieve the business objectives.
The business case description highlights the business strategy that should be fulfilled and the outcomes and benefits that will be achieved as a result of the project delivering the most appropriate output.
The Product Based Planning structure combined with Rolling Wave Planning enables the product owner to create a high level Project Product Description and then progressively build up the detail through Component Product Descriptions and User Scenarios & Acceptance Tests. Each of these documents will specify quality expectations and acceptance criteria at the appropriate level of detail.

These processes reduce the risk of scope creep, time wastage and poor quality. At the same time we optimise the opportunity of learning from experience and exploiting new knowledge to develop an improved project product.

Risk: The product owner will not sign off on the final product.
The practice of allocating work in the form of work packages made up of User Scenarios & Acceptance Tests and time-boxing the development of each work package to a period between 1 and 4 weeks ensures that the product owner or a representative with the project manager must review the work packages and validate that change requests as well as deliverables meet the documented acceptance criteria. They also need to verify the work package deliverables include all the expected (documented) functionality.

The compounded result of signing off on each work package makes it easier to pin point and resolve any valid discrepancies related to signing off on the project, thus reducing the chance of the final project product not being accepted.

Risks:
The project will not deliver an acceptable working product within agreed time tolerances.
Re-prioritisation of projects will result in some project outputs not being usable and the time spent working on those projects does not contribute to achieving the business goal.

By using the Product Breakdown Structure to focus on defining the Component Products, we are then able to determine what combination of Component Products and Features using MoSCoW prioritisation and flow/network diagrams that can be built up iteratively to deliver the most business value as early as possible.

This gives us the possibility to exploit various opportunities;
• Deliver a good enough output that has business value early on so that users can test the output and give feedback on improvements.
• Deliver a good enough output that has business value early on so that when business interests favour a change in plan we can close the first project, yet still deliver business value by use the limited edition output. Start and deliver the second project the re-start the first project and deliver the fully specified output. This lets us change project prioritisation based on business value while at the same time maximising the value of the work done.
• Increase revenue generation or reduce operating expenses due to the benefits derived from the limited editions of working project outputs.

We avoid the following threats.
• A situation where projects are constantly being started and unacceptable amount of work is always in progress, but there is no output that can deliver business value.
• The business going bust because it cannot take payment for uncompleted work.

Risk: Late delivery of project products and cost overruns.

Critical Chain scheduling of prioritised activities and work packages enables the identification of the chain of activities that is a constraint on delivering the project in a shortest time frame. By identifying the critical chain you can verify that all activities in the chain are absolutely necessary. By using the concept of feed buffers and a project buffer to place the time related safety factor at the end of each chain of activities (or US&ATs) we remove time wastage related to Parkinson’s Law and Student Syndrome. Once this is done you ensure that the cost budget is in line with the work that needs to be done before starting the work.

The result of the above practices optimises the opportunity of delivering the project product within time and budget tolerances.

Risk: Not all stakeholders understand what is required or expected.
We handle this scenario from two angles.
The principle of “Defined Roles & Responsibilities” is followed and we have documented roles and responsibilities that are suitable for each project. At a minimum every person in the project will know which role is responsible for carrying out specific activities.

The use of templates (Management products) enables a consistent presentation of information and distinguishes management products. This means that those responsible for creating the management products can ensure they do not miss out important sections and stakeholders can quickly learn where to look for information. This reduces the threats from poor information distribution. It also reduces time wastage thus improving time management.
Sample for individual risk register
The “Defined Roles & Responsibilities” when implemented correctly will improve organisational structure leading to improved time management as individuals will be able to focus on work within their area of responsibility.
The templates will improve communication, quality assurance and quality control.

Comments are closed.