Introduction
The interactions between tasks in a project create dependencies between individual and multiple tasks. With such dependencies come risks that need to be managed. The higher the number of tasks in a project, the greater the chance that there will be a failure somewhere along the way. As a result, risk management in projects is an important factor and needs to be proactive, not reactive. The risk in projects is highest in the early stages and then diminishes over time. However, the cost to fix a risk event increases the longer a project progresses. The following graph demonstrates this concept.
Figure 1: Risk Event Graph
Larson and Gray (2020)[1] also includes a flow chart for the Risk Management Process showing the stages that a Project Manager would go through in assessing and managing risk.
Figure 2: Risk Management Process
Risk Identification
Recognising that there are risks associated with any project is the first step towards managing those risks. One such method of management is having contingency plans in the event that one of the activities is facing failure. Where people are concerned, they can be sick for example on the day they are required. With machinery, there can be a breakdown. These are the type of risks that need to be managed.
The first place to start with risk identification is the work breakdown structure (WBS). Consideration of each task should highlight the potential for risk. Some tasks carry considerable slack in a project and these tasks do not carry the same amount of risk as critical tasks. As long as a task that has slack does not become critical due to a failure, it can be managed.
From the work breakdown structure, a risk breakdown structure (RBS) can be developed. The text gives the example that because of Covid, this will feature as a risk now in many projects due to potential further breakouts and lockdowns.
A risk profile for a project identifies the risks of a project overall. Risks associated with several different types of projects such as house building and event planning are reasonably well known and can be allowed for.
Risk Assessment
A list of risks is obviously not enough. The severity of the risk is important and to assess this we need to know what the impact of the risk occurring would be. Any risks that turn into a real event would have the result of impacting on the time, the cost and also the quality of a project.
Larson and Gray (2020)[1] discuss three modes of risk assessment. The easiest, Scenario Analysis, considers the level of risk on the basis of probability and impact. The image below provides an example of a scoring scale in order to rate risks of a project based on their impact.
Figure 3: Numeric Scale of Risks
The second method of risk assessment is the Risk Severity Matrix which is colour coded into red, yellow and green zones to reflect the severity of the risk. The identified risks are then plotted on the matrix. The image below demonstrates a Risk Severity Matrix. It should be noted however that these matrices will vary in size depending on the number of risks to be plotted.
Figure 4: Risk Severity Matrix
The third model of risk assessment is Failure Mode and Effects Analysis (FEMA) model. This model is an extension of the Risk Severity Matrix and applies an equation to each of the risks. The equation used is:
Impact x Probability x Detection = Risk Value
The process is to identify each risk, which to some extent would be subjective, on a rating of 1 to 5. Detection is rated as the ability of the project team to identify the risk with 1 being very simple to 5 being very difficult where detection is after the event and too late to avert the problem. The same scales apply to Impact and Probability. So a risk with an Impact of 2 and a Probability of 1 with a Detection of 2 would rate at a 4.
Although Program Evaluation and Review Analysis (PERT) is discussed, it appears from anecdotal comments that this is rarely used in the real world and perhaps only on extremely large projects.
Risk Response Development
Risk response development is no different in project management to corporate governance and other fields of risk management. Generally speaking, there are four ways of dealing with potential risks. These are to mitigate, avoid, transfer or retain the risk.
Contingency Planning and Funding
A part of risk management is to have contingency plans and funds in place in the event of a risk occurring. Although contingency planning is straightforward, the implementation of the plans can be complex because you may not have covered everything, when should it be implemented. Larson and Gray (2020)[1] mention four different types of risk and the contingency plans. These are:
- Technical risk
- Schedule risk
- Cost risk and
- Funding risk.
Contingency plans, just like tasks, have estimated costs and time frames. This is where buffers are important, particularly with time. Reserves are established for these contingencies, but note there is a difference between budget reserves and management reserves. The former relate to specific tasks on the WBS and management reserves relate to the project level itself.
Risk Response Control
Risk management cannot obviously be done on an ad hoc basis and requires the process to be documented by way of a risk register. Larson and Gray (2020)[1] state that the risk register will include all details of the identified risk such as:
- Description
- Category
- Probability
- Impact
- Resources
- Responses
- Contingency Plans
- Ownership or Responsible party
- Current Status
The result of this is that risks can be controlled by enabling the risk response strategy and monitoring any events that occur that might trigger a risk event. This would then provide for the implementation of contingency plans and reviewing for any new risks that may have arisen.
Change Control Management
Change control as a result of unforeseen circumstances can be both significant and complex. A project manager needs to be able to implement contingency plans to manage such change. Larson and Gray (2020)[1] identify three categories that most changes fall within:
- Scope changes involving design or major additions
- Contingency plans being implemented which incur changes in costs and time frames
- Improvements to the project suggested by team members can be another category.
The only thing certain in life is change, so project managers must always be ready to adapt.
Managing Project Teams
A successful project demands a project team that is skilled, competent and dedicated to the success of the project. It is critical that the team communicate with each other and collaborate effectively to ensure the project’s success. Operating at these levels improve the chance of success and are often best achieved using first rate project management software.
Development of Teams and Situational Factors
As mentioned above, a high performing and skilled project team is vital for successful project completion. Project teams are no different to other teams when it comes to being successful. Larson and Gray (2020)[1] suggest that it all revolves around synergy where team members interact effectively with each other. The text goes on to the model of five stage team development involving the forming, storming, norming, performing and adjourning of the team.
Figure 5: The Five Stage Team Development Model
The text then further illustrates successful team development by referring to nine situational factors that impact upon teams. These are:
- There are 10 or fewer members per team.
- Members volunteer to serve on the project team.
- Members serve on the project from beginning to end.
- Members are assigned to the project full time.
- Members are part of an organization culture that fosters cooperation and trust.
- Members report solely to the project manager.
- All relevant functional areas are represented on the team.
- The project involves a compelling objective.
- Members are located within conversational distance of each other.
Not all conditions will apply to all projects or all teams, but these factors provide a guide as to what may be present in an effective team.
The Building of High Performance Project Teams
High performance teams are not only the wish of every project manager, but every manager and building such teams is a project unto itself. In many cases, the first step is recruiting the right people to the team or reviewing the team that has been assigned to you.
Figure 6: Creating a High Performance Project Team
The above diagram is a somewhat simplistic view of creating a high performance project team. As mentioned however, the principles apply to all types of teams and a read of Five Dysfunctions of a Team by Patrick Lencioni provides a deeper insight into successful team management.
Management of Virtual Project Teams
Virtual teams are becoming more and more of a reality these days and present their own complications and challenges. Project managers need to be aware of these and adapt their management style to suit the changing environment. There are benefits in being able to recruit specialists from all corners of the globe, but then there can be challenges of cross culture integration, time zones and managing the cohesion of the team. Two of the biggest challenges are the establishment of trust and effective communication.
Pitfalls of Project Teams
A highly successful team is certainly to be desired, but also can come with issues of which to be aware. One of these is that the team can become so integrated and synergistic that they adopt what is known as “groupthink” first coined by Janis (1982). This is where the team thinks as one and critical analysis is not always applied.
Another issue identified by Larson and Gray (2020)[1] is “Bureaucratic Bypass Syndrome” where project teams go on their merry way to achieve project completion without regard for organisational policies and procedures being taken into account. Sooner or later, such behaviour will result in conflict within the organisation.
The third issue identified in the text is that of “team infatuation”, a rather interesting term. It describes the situation where team members are so energised by the project and the people around them they become totally preoccupied with the project. As a result, they can leave many broken personal and business relationships in tatters that can also contribute to burnout on completion of the project.
Conclusion
This module has provided considerable perspective on the management of risk within projects. Risk is always a factor to be considered in many environments, not just project management and the tools for managing such risk and determining it in the first place are very similar. Likewise, management of project teams is really a microcosm in my view of team management overall. One difference of course with a project and a project team is that there is a start and finish date whereas that is not the case with a general management team.
References
