Enhancing Project Delivery through Comprehensive Risk Management

Process Brief:

In our Organization, we had a centralized project management team for assigning projects called Project Management Office (PMO). PMO conducts Risk to Reward analysis for selecting the projects and assigns the projects to different functional teams based on the kind of projects undertaken. Each functional team had a Project Manager (PM). PMO assigns projects to PM, and PM is primarily responsible for all the project management activities during the project life cycle (a snapshot of the primary responsibilities are provided below).

People Also Read

• The Importance of Risk Management and Innovation for Small Businesses
• An In-depth Analysis Of Quantitative And Qualitative Research Methods
• A critical analysis of risk management in airport project: An empirical study of airport projects in Oman

Problem:

The risk management process is performed as an add-on rather than implemented as a formal, comprehensive risk management strategy. The risk management process is not implemented in a coordinated fashion resulting in Scope creep, Procurement issues, Resource Allocation issues, inaccurate Scheduling, and reduced project quality. There is no established infrastructure supporting the company’s overall risk management process. This leads to lost opportunities, cost overruns, and changes to corporate strategy.

Evidence for the problem:

The risk management process was performed in the Project Life cycle analysis phase. This involves identifying potential risks, their probability and impact, and the possible solutions for the risks. Only one resource contact from each department is involved in these meetings. Expert opinion was taken, but input was restricted as fewer resources were involved in these discussions. Some of the issues that are arising due to the informal risk management process are:

1. Scope creep: Initial Risk analysis done in the inception phase doesn’t consider the potential changes that the architecture team may propose in the analysis phase. Since the Business Requirement Document is baselined in the analysis phase, there is a greater chance for the Architecture team to come up with added requirements or changes to the scope based on the future end state (The end state for our application was provided by architecture team, which on achieving, will result in performance, scalability, availability and reliability benefits, resulting in increased revenue and fewer maintenance costs for the company) requirements. This leads to increased scope, thereby increasing the time the architecture team takes to provide the design documents.
2. Secondary risk: Due to increased scope, PMs tend to mitigate risk using automated tools and techniques to complete the project on time. This results in secondary risks like missing some requirements in the project scope. For example, we had a situation where unit testing was performed using an automated tool, which resulted in not testing some of the test cases due to the tool’s limitations.
3. Scheduling issues: Since the architecture team often delays the design documents due to scope changes, PM’s constants had issues meeting the milestones in the schedule. Frequent changes to the schedule are performed, resulting in delays in project deadlines.
4. Resource Allocation: PM’s always procured resources from different functional departments for completing the projects. Often, the resources are not immediately available due to their existing tasks and priorities, resulting in the wastage of already assigned resources as they wait until the other team resources join. This is causing poor resource allocation practices in the company.
5. Cost Overruns: Cost and time overruns are common in major projects due to scope creep, resource allocation issues, and other unforeseen issues.
6. Contract Procurement: Contractors for the project were provided by an external vendor. There have been instances in the past where contractors left the job before the contract was completed. This resulted in project delays, and sometimes, it takes more time than expected to get the resources from vendors and the learning curve for the new resources. This is due to the unavailability of the needed resources in the market for the technologies used in the projects.
7. Contingency reserves: For most projects, contingency reserves are a percentage of the initial Level 1 estimates. Qualitative risk analysis was not performed to identify the potential risks that may arise during that particular phase in the life cycle. This resulted in the improper assignment of contingency reserves for the projects.
8. Motivation: Since few team members will participate in the risk management meetings, the developers often complain about the issues that were not considered in the initial plan. This results in a lack of motivation for the resources, reducing the developers’ morale, and they are reluctant to commit to the deadlines.
9. Project quality: Quality is reduced as the PMs try to complete the projects on time with increased scope, thereby reducing the testing phase timelines, which results in more “production problems” (Issues that arise after the project is deployed in a production environment) than normal.
10. Reactive risk response: Most of the time, risks arising during the project development are handled using reactive response rather than being proactive in responding to potential risks. This results in failed risk responses for some risks, causing time and cost overruns. For example, we had a project where technical risks were not performed at the outset and resulted in reaching the maximum file size supported by the operating system. To resolve this during the development phase, it was decided to add a new file to the application for storing the data after the maximum file size was reached. This resulted in making changes to code in all systems that use that file.
11. Corporate Strategy: For major organizational projects, the business team often performs Return on Investment (ROI) analysis to identify profitable projects. Profitable projects are always prioritized for enhancements over other projects, as they directly influence corporate earnings and are aligned with the corporate strategy of “increasing revenues.” This resulted in slow down of some of the existing projects, as they are not performing as expected due to budget overruns and loss of business due to delays in deadlines.
12. Direct costs for risk management: PM’s often complained that risk management results in increased direct costs as it takes time and resources for Risk identification, Risk analysis, Risk response, and Risk control for the projects undertaken. This was always performed by Subject Matter Experts (SMEs) that were assigned to the project. This involves documenting the potential risks, their impact, and risk response strategies in excel spreadsheets and updating them during the project.

Project Management Lessons learned

Implementing a comprehensive Risk management approach will assist Project teams in managing risk more proactively. A formal process will enforce consistency in the Risk management process by providing the stages needed to complete the risk management plan. The common risk management process consists of five basic steps (Pinto, Morris, 2004):

1. Risk Strategy: This should determine how risk management will be undertaken on a project. The resultant Risk strategy plan has to be integrated with the Project strategy and the wider project management process. This plan should also describe how the risk management process would contribute to the project evaluation exercise that might take place after the project. The plan consists of the risk process’s scope and objectives, participants’ roles and responsibilities, process deliverables, review and reporting cycle, and tools used in the process.
2. Risk Identification: This should occur in the inception phase and include the classification scheme for likely risks (Pinto, 2007). According to the classification scheme, the primary categories of risk are Technical risk, Financial Risk, Commercial Risk, Contractual Risk, and Execution risk. Using this classification will assist in grouping the risks identified and resolving them in a coordinated manner by analyzing possible solutions for each kind of risk.

Several risk identification techniques are provided in this stage, like Research, Structured interviews, Checklists, and Brainstorming sessions. PM has to select the techniques needed for the project based on the resources available and the time allocated to perform the risk management process.

Risk registers can be maintained in the organization to document all the risks in the projects, how they are resolved, and their impact on the projects. This will enable easier access to project teams and makes it easier to conduct risk response based on the historical performance of similar risks.

1. Risk Analysis: This phase will help in achieving a better understanding of the risks identified in the above phase. Risks can be compared like-for-like basis, and this will assist in selecting the best approach to follow, to manage risk in the project. This phase is divided into two parts:
2. Qualitative risk analysis: Risks can be analyzed using probability and impact scale and building a matrix for all identified risks. When fewer resources are available, this matrix will allow attention to be focused on those risks that sit in the high-risk category of the matrix. The probability/impact matrix will assist in developing a risk profile for a project. If most of the risks fall in the high-risk category of the matrix, then that project is considered high-risk. This will assist management in deciding whether or not the project should be undertaken. This analysis chiefly relies on subjective data provided by the participants.
3. Quantitative risk analysis will allow project risks to be modeled by applying statistical theory to the risk management process. There are several simulation techniques available to perform these complex calculations. Some of them are Decision trees, Monte Carlo simulation, etc. Several software packages (For example, Microsoft Project) are available in the market to perform these techniques.
4. Risk Response: In this phase, the appropriate course of action has to be chosen based on available information. Risk responses generally fall into Avoid, Transfer, Mitigate, or Control categories. Caution should be taken to ascertain the full implications of the response strategy. Due to risk response implementation, there is potential scope for secondary risk to arise.

Several risk response tools and techniques can be primarily integrated with the project management process. Some of them are a Contract acquisition plan that ensures responses to risk are placed in relevant work packages, Contingency management that ensures money is released only if a predefined event occurs, and Project controls that allow the project to react to changing circumstances.

This process will make sure the risk management process is effectively implemented. This involves performing the iterative process of all four stages described above in various phases of the project life cycle.

Herman Bailey

With a student-centered approach, I create engaging and informative blog posts that tackle relevant topics for students. My content aims to equip students with the knowledge and tools they need to succeed academically and beyond.