Like with many business processes, reflection is the key to growth and the success of your future projects. The same can be said for risk management within a project. In this topic, we will explore how to assess and review risk management outcomes, review policies and procedures and implement improvements for future projects.
By the end of this topic, you will understand:
- How to review project outcomes for the effectiveness of risk management processes and procedures
- How to develop recommended improvements for application in future projects
- How to identify and document risk management issues and recommended improvements for application for future projects.
Risk management is a never-ending process. Reaching some extent of completion during a risk management project only means it is time to review everything again. In the months it took to accomplish the project, there could have been enough change in one of the variables that you need to review and make changes to your plan.
When a risk management plan is initiated, the set of variables that outline the parameters are evaluated, and a course of action is taken. During that course, new variables are discovered, and new risks are uncovered.
Example
Take a bike race, for example. When the race commences, a biker has a given set of parameters for the race: personal capabilities, bike performance, race route etc. The racer may have even trained on the course during various climatic conditions to mitigate climatic conditions as a risk. As prepared as the racer is to face the known risks, other variables can emerge that create risk before and throughout the race. New race conditions, such as cracks in the asphalt or crowded conditions, may make a completely different set of risks that need to be identified, analysed and evaluated, and treated while on the course.
One of the key components of the risk management process is keeping an accurate record of documentation concerning the communications, justifications, analyses and relevant information about risk. Remember how we began the risk assessment process? With research relating to:
- Data or statistical information
- Information from other business areas
- Lessons learned from other projects or activities
- Market research
- Previous experience
- Public consultation
- Review of literature and other information sources.
Most organisations are constantly exploring new ways to give their projects the most effective chance to succeed. While effective project management remains crucial in achieving this, creating a nourishing project environment shouldn't be overlooked.
Many companies often use business scans to assess their environment with the aim of developing action plans to improve the impact of their projects. How this works depends on the different scenarios involved.
| Scenario: The organisation doesn’t have the flexibility to initiate new projects | Scenario: Project objectives are not rewarded |
|---|---|
| An organisation that desires to pursue new goals and projects needs the flexibility to try to do so. They must ensure that existing business and day-to-day work don’t take up all of their capacity. This ensures projects get allocated the necessary assets, and people have the time to attend to their projects. | An appraisal process determines how people’s performance is assessed while providing key moments for coaching to occur. When initiating projects, the objectives of the task descriptions need to be adjusted to reflect future effort and rewards. |
| In pursuing efficiencies, organisations often attempt to maximise the workload of employees and the use of assets. This reduces costs, but it also reduces employees’ ability to take on extra workloads when demanded. Then, projects place so much demand on organisations that initiating a project in such circumstances becomes unsustainable, leading to poor project execution and a lack of focus on existing job tasks and responsibilities. | Job descriptions and setting expectations on what needs to be delivered are key to people prioritising their work. In the absence of project objectives being incorporated in job descriptions, individuals do not have any option but to ignore these and concentrate on their official tasks. |
The Project Management Institute’s (PMI) Project Management Body of Knowledge (PMBOK) defines lessons learned as the learning gained from the process of performing the project. Formally conducted lessons learned sessions are traditionally held during project close-out, near the completion of the project. However, lessons learned could also be identified and documented at any point during the project’s lifecycle.
Lessons learned document the reason for issues and the reasoning behind any corrective action taken to deal with those issues. When collating lessons learnt, consider these sorts of questions:
- What was learned about the project in general?
- What was learned about project management?
- What was learned about communication?
- What was learned about budgeting?
- What was learned about procurement?
- What was learned about working with customers?
- What was learned about what went well?
- What was learned about what did not go well?
Lessons learned should draw on both:
- positive experiences — good ideas that improve project efficiency or save money, and
- negative experiences — lessons learned after an undesirable outcome has already occurred.
Each documented lesson learned should contain at least these general elements:
- Project information and contact information for additional detail
- A clear statement of the lesson
- A background summary of how the lesson was learned
- Benefits of using the lesson and suggestions on how the lesson may be used in the future.
At any point during the project lifecycle, the project team and key stakeholders may identify lessons. The lessons learned are compiled, formalised and stored throughout the project’s duration.
Upon project completion, a lessons learned session is conducted that focuses on identifying project success and failure and includes recommendations to enhance future project performance.
Issues Log
An issues log is a tool for reporting and communicating what is happening with the project. This ensures that issues are raised, investigated, and resolved quickly and effectively.
An issues log allows you to do the following:
- Have a safe and reliable method for the team to raise issues
- Track and assign responsibility to specific people for each issue
- Analyse and prioritise issues more easily
- Record issue resolution for future reference and project learning
- Monitor overall project health and status.
You can include the following information in an3.23.4 issues log:
Issue type
Define the categories of issues that you're likely to encounter. This helps you track issues and assign the right people to resolve them. Traffic lights are a common colour-coding technique used when reporting issues. This provides an easy-to-see indication of whether issues are under control. Traffic lights could be used as follows:
- Red - Cannot proceed before the issue is resolved
- Yellow - Resolution is in process, and you'll be able to proceed soon
- Green - The issue has been addressed
