Module 5. Risk and Agile project management
In Waterfall project management, the risk management occurs throughout the project, and the project manager plans in advance to anticipate events or risks occurring. Agile project team members and managers are aware of the specifics of what user stories are underway, what the quality requirements are, and who is involved in each activity (Hillson 2009; Moran 2014; Buganova and Simickova 2019; Tarvares et al. 2019). However, there can be a disconnect between knowing the finer details required to achieve the overarching project goals and how they relate to risk.
Therefore, an integrated risk management approach in Agile methods requires understanding the team member differences, the necessary feedback loops and common decision-making processes. By understanding these components, managers are better able to identify and respond to risks and embed the behaviours within their team.
Agile project management and the corresponding risk management process focuses on what happens now or in the immediate future. Agile project management deals with the delivery of work through iterations, where the highest priority work is completed to provide value to clients. Each iteration is based on developing a usable deliverable, so that the client can inspect or improve the product, project or process progressively.
An important component to consider when completing risk management, is that it is important to understand both the unknown and known events, to best plan for uncertainty (Harris 2008) and ensure that planning and mitigation is completed at the required level.
Agile risk management:
- is an iterative risk management approach, requiring changing the manner in which risk is understood within the organisation
- follows Agile project management principles (e.g., sprints) to break up the risk management response into smaller and more manageable components, while also encouraging collaboration across stakeholders, project team members and sponsors.
Therefore, a project manager must first consider these elements before deciding whether to use the Agile risk management method:
- Engagement: actively engaged risk managers and stakeholders can understand potential issues or risks as they arise.
- Collaboration: managing risks through team support and discussions.
- Dynamic: recognising that ongoing change needs to be considered and incorporated in risk management.
- Adaptable: rapid changes and adjustments are needed to respond to the new risks as they arise.
- Timely: all reports and documentation around risks need to contain the most up to date information.
- Future focus: focusing on what could occur in the future (e.g., triggers and risks) can help to identify emerging conditions early on.
- On the lookout for manners of working: introducing new ways of managing and responding to risks.
Agile risk management framework
The Agile project management approach helps integrate changes into a project that is underway. Project risks are the highest at the start of a project because of the overall uncertainty about the aims, objectives and deliverables for the project (Harris 2008). However, the risk level declines as more information is gathered or as development is carried out throughout the project planning process.
Agile risk management documentation requires developing 2 forms of risk registers: complex and simple. The complex risk register contains all of the relevant information and considers all of the data that can identify or respond to risk management plans. The simple risk register outlines only the pertinent information. It is easy to read and focuses attention on the key risks (e.g., high or medium exposure risks).
Agile risk management focuses on 3 areas:
- Strategic. These are risks which relate directly to organisational plans. This is where the majority of risks will occur.
- Operational. These are risks which can occur across specific business units (e.g., accounting).
- Project and organisational objectives. These are risks around the organisation, which can be impacted by environmental (or external) influences.
The Agile project management method can help minimise risks, as the risk management approach is built into the iterative process. As part of each sprint or iteration, the risk management processes are conducted to ensure that risk is given enough attention. Although the risk management plan is created at the start of the project, through each iteration the process is continually reviewed and updated as the project progresses.
Therefore, the Agile approach to risk management requires the iterative delivery of outcomes, incorporating changing requirements, stakeholder engagement and measuring performance of outcomes. An important component for Agile risk management is needing to complete outcomes on a frequent basis; where the project fails to achieve these outcomes (especially based on risks arising), the project may be cancelled early, to decrease the overarching cost of failure.
Agile project risk integration
The Agile project management approach supports the delivery of initiatives and products; however, this still requires the appropriate use of risk management to enable successful outcomes (Moran 2014; Tarvares et al. 2019). This includes using control functions to support alignment between organisational and project risk management, along with consideration of the environment, strategic objectives and stakeholder requirements. These are some of the key activities which need to occur throughout the Agile project life cycle:
- Challenges affecting objectives and goals: these include the functions of risk and compliance which can support risk management in setting standards across the organisation.
- Risk integration: being aware of risk across the organisation, along with understanding how to identify and respond to risks. Risk and compliance help with monitoring and reporting in real time.
- Continuous improvement requirements: using a change control framework for risk oversight. The framework help develop and implement business and technology changes
Risks are often complex and subtle, which makes them difficult to identify, respond to and manage. Some of the primary issues associated with Agile project and risk management require considering the following:
- How are threats and opportunities identified within the project?
- What is the risk appetite of the organisation and what is the level of risk tolerance within the project?
- What is the prioritisation process?
- How are risk mitigation or contingency plans created?
- Who is the owner of the risk and who takes action?
- Who reviews the risk management process?
Risk management within Agile projects needs to be outlined within all governance documents, through whichever form is being used for the project. Through the Agile process, risk visibility is promoted, along with collective ownership and risk response accountability. This process encourages informed and collaborative decision-making.
Agile risk identification and assessment
There are complexities around understanding and identifying risks. Within Agile projects the most common approach is the ‘what–why’ approach. This requires brainstorming with the project team members, key stakeholders and subject matter experts (Hillson 2009; Moran 2014; Buganova and Simickova 2019; Tarvares et al. 2019) about what may occur at different stages of the project, how it relates to the specific deliverables and why the event may occur.
Following the Waterfall project method, the Agile risk management approach uses a risk register. There is a similar need for the register to be visible to all key stakeholders and maintained through the life cycle of the project, and ownership must be allocated to ease identified risk. By keeping the register in a clear and visible place, the risks can be updated as new risks arise. Also, similar to the Waterfall process, the risk assessment is conducted to understand the risk exposure or ranking, based on the likelihood and consequence of a risk occurring. Depending on the risk level, they are prioritised to determine the risk response process (e.g., contingency and mitigation plans). Risk exposure scores are central to prioritisation as they indicate the urgency of actions that need to be completed. Agile risk treatment
The risk assessment process provides the inputs required to understand and respond to the risks (e.g., the appropriate level of treatment). Within the treatment process, specific activities or actions need to be undertaken to respond to risks (Hillson 2009; Moran 2014; Buganova and Simickova 2019; Tarvares et al. 2019). How risks are addressed should be in line with the Agile approach – as new requirements arise, risks change. Project teams are encouraged to understand the impacts of changes to user stories and the requirements of risk management, whereby the team identifies all activities and tasks which can trigger a risk.
Utilising a Kanban board to support the project management application can also support risk identification and documentation. This is referred to as a risk-modified Kanban board (as outlined in Table 16). It uses colour coding to identify specific components within the project. This approach helps us to visualise the specific risks, requirements, contingency and opportunities.
Table 16. Modified risk Kanban board
In addition to using the modified Kanban board, other Agile documentation processes can be employed. For example, Agile story mapping is a process of documenting relationships between the epics and the user stories. An epic is defined as the body of work within an Agile project. The body of work can be broken into specific tasks (also referred to as user stories), based on needs or requirements stipulated by stakeholders, clients or end users (Buganova and Simickova 2019; Tarvares et al. 2019). An example of Agile story mapping is provided in Table 17. This process provides a visualisation of the different risks, opportunities and contingencies which are active within an Agile project.
Table 17. Modified risk Agile story mapping
The treatment process involves identifying mitigation and treatment opportunities for risks that could occur throughout the life cycle. The risk treatment process is similar to that of traditional project risk management, which was outlined in earlier modules.
Agile risk monitoring
In Agile projects, risk assessments are conducted and the risk scores are assigned to measure the level of risk. This involves using a risk burndown chart; this is used to track the overall risk management efforts (Hillson 2009; Moran 2014). An example of a burndown chart is provided in Figure 6. The purpose of a burndown chart is to show the project team that there are still residual risks that occur over time. It shows the cumulative level of residual risk for each of the remaining user stories and corresponding risks associated with the remainder of the project.
Figure 6. Risk burndown chart example, by Carmen Reaiche, Samantha Papavasiliou and Frank Anglani, licensed under CC BY (Attribution) 4.0
The risk burndown chart shows the complexities of risk management that highlight secondary or future risks. This is also referred to as ‘risk walling’ which is used to co-locate the burndown of risks in comparison to other risk-related artefacts (which include the risk register, risk-modified Kanban or user story maps). These can be used to improve overall risk transparency and encourage collaboration across the project team in response to risks.
Common risks in Agile projects
There are many common risks which can occur in Agile projects, including:
- using Agile project management where not appropriate
- not following Agile principles
- reduced level of recommended governance and oversight
- insufficient communication and engagement throughout the project
- ignoring change management processes
- lack of forecasting or considering the future risks.
The following case study showcases the importance of Enterprise Risk management.
Case study
Enterprise risk management and its impact on project management
By Levi Mitchell
Overview
Enterprise Risk Management (ERM) is a tool to improve decision-making. Often it is poorly understood or poorly executed, resulting in the perception that risk management blocks business opportunities or impedes the business from progressing. In reality, effective risk management is a powerful tool.
Risk is commonly represented as the negative consequences of an event but more accurately should be described as the effect of unexpected deviations (good or bad) from objectives. The International Organisation for Standardisation (ISO) define risk as, ‘the effect of uncertainty on objectives’ (AS/NZS ISO 3100 Risk management). These objectives can have different aspects, including legal, reputational, workplace health and safety, financial, or environmental, and can apply at different levels, such as operational, strategic, project, product and process. Therefore, risk management is a critical area of responsibility for any board.
This case study provides a practical insight into the implementation of risk management from a board/non-executive director, risk oversight perspective. This is a key point of difference, as the board have oversight responsibility with respect to risk management and alignment with purpose and strategy.
Director’s duties and risk management implementation
In Australia, there are 3 sources of law which outline directors’ duties:
- Corporations Act 2001 (Cth) – the primary governing legislation for companies which includes setting out the obligations of companies, boards, executives and members.
- Fiduciary duties – these work alongside the Act and are developed over time, resulting from case law.
- Statutory duties – these legislative instruments impose additional duties and liabilities on directors and include laws such as workplace health and safety, consumer and competition, anti-bribery and corruption, and taxation.
The principle duties for directors are:
- duty of care, skill and diligence
- duty to act in good faith and in the best interests of the company
- duty to exercise powers and use information for a proper purpose
- duty to prevent insolvent trading
- duty to avoid conflicts of interest
- duties related to company records.
Each of these duties come with inherent risk and it is imperative that any business maintains comprehensive monitoring and effective control over material risks. How the monitoring and control takes place is separated clearly between the board and management. The board have a risk oversight responsibility – they set the risk appetite for the business and oversee and ensure the appropriateness of the business risk management framework. This means that the board ultimately is responsible for deciding the nature and extent of risk it is prepared to take to meet the business’ objectives. It is critical that the business’ risk appetite is aligned with the business purpose – if a business is not prepared to accept any risks it may become defective in pursuing its purpose, and conversely if the business accepts too much risk it may be exposed to negative consequences.
In contrast to the board, management have a responsibility to design and implement a risk management framework that is consistent with the board’s risk appetite. It is important to note that risk management is not a separate activity of the board – it is an integrated activity.
So, with that in mind – what is risk management? Risk management is the way in which the business considers uncertainty when making decisions and includes a series of coordinated activities to manage risk. ERM provides a framework for risk management which is perpetual and management-led (see Figure 7).
Figure 7. Enterprise risk management, by Levi Mitchell under CC BY (Attribution) 4.0
A common mistake is that risk must be eliminated through compliance. Risk management should be embedded into practices, processes and policies. If a business has properly defined their risk appetite and risk tolerance levels in conjunction with proper controls, then the business is able to take risks and capitalise on opportunities by making informed decisions in the pursuit of objectives. Where a business has built maturity around the management of risk, the business has a ‘risk-aware’ culture.
ERM is a tool for ‘risk optimisation’. It is a structured way to consider both the upside and downside of risk-taking activities to improve decision-making and meet existing and emerging challenges. Building a risk-aware culture is not an easy task – it takes a significant investment in time and resources for both the board and management and it starts with the board (Tone from the Top!). The board and relevant board sub-committees need to work with the management team to actively promote and grow a culture and environment that understands, implements and uses ERM to measure and reward success, rather than view it as a specialised corporate function.
In recent times, company shareholders/members have pushed for meaningful transparency and disclosures on boards, in particular with respect to risk oversight, which is one of the top governance priorities for shareholders/members. One of the ways in which management may look to build ERM into the business decision-making is through a risk management strategy that considers:
- the outcomes the business wants to achieve when it comes to management risk (e.g., legal/compliance programs and special consideration risks such as workplace health and safety, cybersecurity, and environmental/social/governance)
- the frameworks and processes the business will put in place to achieve those outcomes
- the culture the business wants to create
- resources allocated to the work of change
- how the business will monitor the progress of the strategy
- how the business will measure success.
These considerations (as examples) start to build risk management into how the business operates and how it measures success – be that in its day-to-day operations, projects, or strategy development. ERM is a constant and by ensuring a risk-aware culture the business will be able to appropriately identify risk and build contingencies/mitigation to manage and minimise risk and maximise the opportunity for success.
This case study provides a useful overview of the importance of ERM through the lens of a non-executive director by highlighting the focus of the board on risk oversight and the intersectional pieces between the board and management.
ERM has a significant impact on project managers, project team members and stakeholders within a project; therefore, it is vital to understand the end-to-end risk process within an organisation. The role of a company director or board member in the ERM process is different to that of a project manager. Project manager responsibilities are typically to execute strategic objectives; therefore, it is important to understand the board’s role in relation to risk oversight. There is a need for due diligence, an understanding of the environment and clear steps for implementing any risk management plans or responses. Although the legal requirements are different for directors, project managers benefit from understanding the legal parameters, end-to-end organisational risk processes and transparency of risks as they arise.
Now let’s revise our knowledge :
Key Takeaways
- Risk management in Agile projects occurs in cycles throughout each sprint.
- Agile projects require unique risk management and mitigation planning.
- Agile project teams take responsibility for risk management. The entire team owns the risks.
- Both active and proactive risk management need to be factored into daily activities.
- Transparency is key.
References
Buganova K and Simickova J (2019) ‘Risk management in traditional and agile project management’, Transportation Research Procedia, 40:986–993.
Harris E (2008) ‘Project risk and uncertainty: a longitudinal case study’, PMI Global Congress–EMEA.
Hillson D (2009) Managing risk in projects, Gower Publishing, UK.
International Organization for Standardization (2016) Risk management principles, ISO quality, Geneva Switzerland.
Moran A (2014) Agile risk management, Springer Verlag, Germany.
Tarvares BG, da Silva CES and de Souza AD (2019) ‘Practices to improve risk management in agile projects’, International Journal of Software Engineering and Knowledge Engineering, 29(3):381–399.
