Risk Management

Executive summary

Risk Management

Software development is part of information technology (IT) projects. IT projects uses a variety of technological advancements and requires high levels of knowledge. Any IT projects will involve software development, whether they are the standard off-the-shelf application, custom-built application, mobile applications. Regardless of the method used to develop the applications whether they use PRINCE2 method or PMBOK® method, they are all part of IT projects. Software development today has the option to use Agile Scrum method or the most commonly used System Development Life Cycle based on waterfall method. Regardless of which method you choose, there are a number of uncertainties facing a software project. This uncertainty is known as risk. The success of a software development project depends quite heavily on the amount of risk that corresponds to each project activity. As a project manager, it’s not enough to merely be aware of the risks. To achieve a successful outcome, project leadership must identify, assess, prioritize, and manage all of the major risks. The risks may come from hardware, operating environment, database, network, people, and many other resources that make up the complete software solution. A large number of software projects failed to meet their intended objectives due to poor risk management. A project is classified as a failed project if it did not meet any of these i.e. failure to deliver within budget, failure to comply within the scope of the project, failure to meet the delivery schedule or failure to meet the quality requirements. Our unique consulting services is to guide client project team on the techniques and processes of managing risks for software development projects regardless of which development methodology you prefer.

The goal of most software development projects is to be distinctive often through new features, more efficiency, or exploiting advancements in software engineering. Any software project executive will agree that the pursuit of such opportunities cannot move forward without risk. Because risks are painfully real and quite prevalent on all software projects, it’s critically necessary that stakeholders work hard to identify, understand, and mitigate any risks that might threaten the success of a project. For projects that have time and cost constraints, our experience shows most clearly that successful software development efforts are those in which risk mitigation is a central management activity. Very simply, a risk is a potential problem. It is an activity or event that may compromise the success of a software development project. The risk is the possibility of suffering loss, and total risk exposure to a specific project will account for both the probability and the size of the potential loss. Guesswork and crisis-management are never effective. Identifying and aggregating risks is the only predictive method for capturing the probability that a software development project will experience unplanned or inadmissible events. These include terminations, discontinuities, schedule delays, cost underestimation, and overrun of project resources.

We can classify five main risk impact areas for software development projects, they are: New, unproven technologies – the majority of software projects entail the use of new technologies. Ever-changing tools, techniques, protocols, standards, and software development environment increase the probability that technology risks will arise in virtually any substantial software engineering initiatives. Training and knowledge are of critical importance, and the improper use of new technology most often leads directly to project failure; User and functional requirements – software requirements capture all user needs with respect to the software system features, functions, and quality. Too often, the process of capturing user and business requirements are lengthy, tedious, and complex. Moreover, requirements usually change with discovery, prototyping, and integration activities. Change in elemental requirements will likely propagate throughout the entire project, and modifications to user requirements might not translate to functional requirements. These disruptions often lead to one or more critical failures of a poorly-planned software development project.; Application and system architecture – taking the wrong direction with a platform, component, or architecture can have disastrous consequences. As with the technological risks, it is vital that the team includes experts who understand the architecture and have the capability to make sound design choices; Performance – It’s important to ensure that any risk management plan encompasses user and project stakeholders’ expectations on performance. Consideration must be given to benchmarks and threshold testing throughout the project to ensure that the work products are moving in the right direction; Organizational – organizational problems may have adverse effects on project outcomes. Project management must plan for efficient execution of the project, and find a balance between the needs of the development team and the expectations of the customers. Of course, adequate staffing includes choosing team members with skill sets that are a good match for the project.

There are many types of risks facing a project some of which can be controlled while others need a plan to mitigate them. Prior to managing and controlling these risks, a project team must have the knowledge and experience in identifying these risks at the early stage of the project whether it is a risk that everybody knows about or potential threats that they have no experience in handling them. The project team needs to compute the cost of each of these risk and feed this data into the project budget so the project sponsor and the executive management committee are fully aware of this cost. If the cost of risks is not known then the projected project profitability which has been developed during the project initiation stage is inaccurate.

Poor risk management, lack of knowledge and experience in the identification and quantification of the risks affecting a software development project, and the shortfall of the required expertise are some of the shortcomings facing IT organizations today. These are the fundamental issues that have contributed toward many failed projects since the early 1990s and still happening today. Failed projects are projects that do not meet the scope, cost, schedule, and quality requirements defined by the business user.

The objective of performing risk management for IT software projects is to enable your organization to accomplish its mission by: Better securing the IT software projects that store, process, or transmit organizational information; Reducing the number of failed projects through the establishment of a risk governance structure for IT software projects; Implementing project risk management processes that will support IT project team in the configuration of risks across the respective phases of the software development life cycle; Enabling management to make well-informed risk management decisions to justify the expenditures that are part of an IT budget; Assisting management in authorizing the IT software projects on the basis of the supporting documentation resulting from the performance of risk management; Implementing a structured budgeting framework for IT software projects in order to ensure that all high impact risk activities will be identified for tracking and accounting purposes; Providing training to the project team including the techniques of calculating project risks with the aid of a risk management tool; Identifying the risk and its associated cost which includes inflation charge, project liabilities, and contingencies; Monitoring and continuous reporting to risk management committee.

---

Service Methodology

The consulting services focus on managing risk for IT software projects that adopt the methods defined in the software development life cycle (SDLC). We shall embed the risk management processes into the SDLC processes that will allow the project team to act, monitor and control risks throughout the various phases of the software development life cycle. The SDLC comprised of six phases and the method used to achieve the service objectives are discussed in the following phases.

System Initiation phase is the first phase of any software project where the risks are highest because known and unknown threats are likely to hit the project. The business case and proposed solution developed during project origination phase are re-examined to ensure that they are still valid and address an existing organizational need. This validation effort provides the project team with the opportunity to discover the list of risks that may arise should the business team decide to proceed with the proposed solution. The primary focus is to develop the initial project plan, produce a preliminary budget, defining the scope of the project, and to develop a high-level project schedule. At this stage, we shall conduct risk planning activities and develop the risk management plan as the formal framework for risk management activities throughout the rest of the project.

System Requirement phase in which the needs of the business are captured in as much detail as possible. At this stage, the project manager has completed definition of some risks based on input from project business case. The project manager leads the project team to define what it is that the new system must do. By obtaining a detailed and comprehensive understanding of the business requirements, the project team can develop the functional specification that will drive the system design. Investment increases during System Requirements phase due to engagement of human resources to develop the project team and to produce the project management plan and project communications plan. During this phase, we shall conduct risk identification process to identify the list of risks and assist the project team in the development of the Risk Register.

System Design phase which builds upon the work performed during system requirements phase, and results in a translation of the functional requirements into a complete technical solution. This phase dictates the technical architecture, standards, specifications and strategies to be followed throughout building, testing, and implementation of the system. The completion of system design also marks the point in the project at which the project manager should be able to plan, in detail, all future project activities including the system testing and system acceptance plan. At this stage, we shall conduct an assessment of all risks using qualitative and/or quantitative techniques to identify the high impact risk, prioritize them and update the risk register. This includes high impact risks and contingencies that will impact development work during system development phase.

System Development phase where the project team builds and tests the various modules of the application, including any utilities that will be needed during System Testing and Acceptance phase. As system components are built, they will be tested both individually and in logically related groupings until such time when a full system integration testing will be performed to validate functionality. We will work with the project team to ensure that the development environment is secure, and there is no exposure that can be considered a major threat to the environment. The high impact risks identified in the system design phase will be closely monitored to ensure that they will not cause problems to the development effort. In cases where a particular risk occurred, the mitigation plan will be executed together with the appropriate risk response strategy. The risk monitoring and control activities will be extended into the System Testing and Acceptance phase as part of the validation cycle until the component is accepted by the end user.

System Testing and Acceptance during which the focus of system validation efforts shifts from those team members responsible for developing the application to those who will ultimately use the system in the execution of their daily responsibilities (the end users). This is the critical phase of the system development life cycle where all the components of the applications will be tested together following the system test plan developed during the system design phase. This process is commonly called the system integration testing (SIT). Any component that failed during SIT will be sent back to the development team for rectification and these components will be re-tested until they are error-free. One of the common risk facing SIT is the execution of the testing activities that are dependent upon the result of another testing that precedes it. Other risks include the readiness of the SIT environment, migration of test data, the technical configuration of the computer system need to be identical to the production environment, and much more. This phase also includes user acceptance testing (UAT which is the testing of the functional components of the system by the business users. A dedicated UAT environment needs to be installed prior to undertaking user acceptance testing. In addition to confirming that the system meets functional expectations, activities are aimed at validating all aspects of data conversion and system deployment.

System Implementation phase is the final phase of the SDLC which comprises all activities associated with the deployment of the application to the production environment. These efforts include installation of the system in a production setting and transition of ownership of the application from the project team to the customer. The final process is the closure of a project that should include contract closure, risk closure, and administrative closure. Contract closure ensures that all of the deliverables and agreed upon terms of the project have been completed and delivered so that the project can end. It allows resources to be reassigned and settlement or payment of any account, if applicable.

---

Service Options

Companies can elect whether they just require Appleton Greene for advice and support with the Bronze Client Service, for research and performance analysis with the Silver Client Service, for facilitating departmental workshops with the Gold Client Service, or for complete process planning, development, implementation, management and review, with the Platinum Client Service. Ultimately, there is a service to suit every situation and every budget and clients can elect to either upgrade or downgrade from one service to another as and when required, providing complete flexibility in order to ensure that the right level of support is available over a sustainable period of time, enabling the organization to compensate for any prescriptive or emergent changes relating to: Customer Service; E-business; Finance; Globalization; Human Resources; Information Technology; Legal; Management; Marketing; or Production.

---

Service Mission

To increase the rate of success particularly for software development projects through the establishment of the project risk governance structure at the system initiation phase of the software development life cycle. To introduce and implement a structured project risk and costing framework in order to ensure that all cost drivers will be identified and captured at the end of the system requirements phase of the software development life cycle. To introduce and implement project risk management processes in the client organization that will support client IT project team in the configuration of risks across the respective phases of the software development life cycle. To guide the project team on the techniques of calculating project risks with the aid of a custom-design tool, how to quantify the cost of handling each of these risks, what is the maximum risk a project can absorb, and how to balance the risk in order to stay within the project budget. To guide the project team in the development of the IT Risk Management plan for official tracking and reporting, during the system development phase of the software development life cycle. To ensure appropriate and continuous monitoring of risk to be conducted during system development and system acceptance phase of the software development life cycle.

Areas to focus on future consulting services: Provide risk management training to information technology personnel prior to the start of their duties or their participation, these include project managers, project team members, and representatives from the client business team who are involved with projects; To conduct client induction program for all new hires to be deployed for information technology projects has a risk education component that articulates their duty of care. Ensure that all committee members attend induction and if possible, attend more comprehensive risk education or training; To train and coach client project team in the structured process of defining and computing the risks affecting the project including labor, material, product licenses, expenses, liabilities, and contingencies.

---

Service objectives

The following list represents the Key Service Objectives (KSO) for the Appleton Greene Risk Management service.

1. Risk Planning
   The objective of risk planning is to produce the risk management plan which is a document that will define the framework for the risk management activities that is to be conducted by the project team throughout the respective phases in the system development life cycle. The risk management plan lays down the groundwork for how risk management will be carried out in a project. It serves as guidance for the risk process, its thresholds, its formats, defining the roles and responsibilities of stakeholders in governing the risk activities. It is notable that the risk management plan is not a listing of specific risks and is not used to establish the particular strategies for risks, once they are identified. The risk management plan is shared with project stakeholders to clarify their roles and responsibilities in the risk management process and to identify when specific potential risks are truly of concern to the organization. It also outlines the risk budgeting process, detailing how and when risk contingency funds may be allocated and applied. There are a number of steps involved in the development of the risk management plan. A risk management plan template will be easier to start with including the organization policies and the risk tolerance level of the stakeholders. The first step begins with having a firm commitment to the entire risk management approach from all project stakeholders. This commitment ensures that adequate resources will be in place to properly plan for and manage the various risks of the project. These resources may include time, people, and technology. Based on the size, impact, and priority of the project, a budget may need to be established for the project risk management activities. A project with high priority and no budget allotment for risk management activities may face uncertain times ahead. A realistic dollar amount is needed for risk management activities if the project is to be successful. The roles and responsibilities identify the groups and individuals who will participate in the leadership and support for each of the risk management activities within the risk management plan. The duties of project steering committee, project manager, and the project team must be clearly defined. Responsibilities may include information on who will identify risks, as well as who should evaluate them and develop strategies for those that are of the greatest significance. Stakeholders also must be committed to the process of identifying, analyzing, and responding to threats and opportunities. Too often plans are disregarded at the first sign of trouble, and instinctive reactions to situations can lead to perpetual crisis management. In addition to commitment, risk planning also focuses on preparation. It is important that resources, processes, and tools be in place to adequately plan the activities for project risk management. Systematic preparation and planning can help minimize adverse effects on the project while taking advantage of opportunities as they arise. The risk management process needs a schedule to determine how often and when risk management activities should happen throughout the project. If risk management happens too late in the project, then the project could be delayed because of the time needed to identify, assess, and respond to the risks. A realistic schedule should be developed early in the project to accommodate risks, risk analysis, and risk reaction. A clearly defined scoring system and interpretation of the scoring system must be in place. Altering the scoring process during risk analysis or from analysis to analysis can skew the seriousness of a risk, its impact, and the effect of the risk on the project. The project manager and the project team must have clearly defined scores that will be applied to the analysis to ensure consistency throughout the project. The risk management plan shall include detail on the frequency of risk identification, assessment, and response development, as well as the appropriate application of any tracking processes or documentation. As risk management activities are induced, they will need to be documented. The documented actions and their results will support ongoing decisions within the current project (as well as future projects) and will serve as information for management, the project team, the customers, and other stakeholders. The Risk Management Plan should provide the project steering committee with clear statements of the project risks and the proposed risk management strategies to enable ongoing management and regular review.
2. Risk identification
   Risk identification is the process of identifying the threats and opportunities that could occur during the life of the project along with their associated uncertainties. The life of the project means the complete life cycle of the project, not just the time the project team is in place, the time until the final acceptance by the customer, or even the end of the warranty period. Risks should be considered through the useful life of the product or service that we are providing by doing this project. The risk of corrosion causing a catastrophic product failure during the useful life of a product that we have designed and built should be considered, and corrective action should be taken in accordance with the seriousness of the threat. Risks can be identified in a large number of ways, and all of the productive and economical ways should be employed. We shall start with recognizing the areas of the project where the risks can occur. This means that we will have to investigate the following areas: Scope – we must look at the work of the project. The work breakdown structure (WBS) will be useful here. The project scope must be clearly defined in terms of both the deliverables and the work that must be done to deliver them. Errors and omissions on the part of the project team and the stakeholders must be minimized. As always, the WBS will be very helpful in doing this; Schedule – estimates for the duration of the project and the duration of the project tasks must be done accurately and reliably. The sequence of work must be identified, and the interrelationships between the tasks must be clearly defined; Cost – estimates for tasks must be done accurately and reliably. All associated costs must be considered and reported accurately. Life-cycle costs should be considered as well as maintenance, warranty, inflation, and any other costs. Customer expectations – estimates of project success must be considered in terms of customer needs and desires. The ability of the project to be scaled up or manufactured in different quantities or for different uses and sizes must also be considered; Resources – this involves the quantity, quality, and availability of the resources that will be needed for the project. Skills must be defined in the roles that will be necessary for the project; Organization – This is the ability to interface with the stakeholder’s organization in terms of communications and knowledge. The Risk Management plan developed earlier will be the primary input into this process, many people both inside and outside the project will also be useful input into this process. This includes input not only from the project team and all of the stakeholders but also from project managers who have managed this type of project before and even consultants who have special expertise about certain kinds of risks. It may be necessary to organize the types of risks into categories so that separate teams of people can be brought together more efficiently. Many of the risks that will affect the project are risks that have happened in one form or another on other projects of this type. Utilizing the information available in the previous project’s lessons-learned documents will be very helpful in identifying risks for this project. An organized review of past projects should be done as part of the risk identification process. Since much of the risk identification process will involve large numbers of people, formal group dynamics techniques should be used. It is, therefore, important that the project manager and team guide the risk management process. Risk identification should include the project team and other stakeholders who are familiar with the project’s goal and objectives. Using one or more of the following tools, the project risk framework introduced earlier in this course can provide direction for identifying the threats and opportunities associated with the project. Tools and techniques that will be applied to this process include brainstorming, Delphi technique, SWOT analysis, interviewing, and Ishikawa diagram.
3. Risk Assessment
   The framework introduced in the previous section provides tools for identifying and understanding the nature of risks to projects. The next step requires that those risks be analyzed to determine what threats or opportunities require attention or a response. Risk assessment provides a systematic approach for evaluating the risks that the project stakeholders identify. The purpose of risk assessment is to determine each identified risk’s probability and impact on the project and prioritizing them so that an effective risk strategy can be formulated. In short, which risks require a response? To a great degree, this will be determined by the project stakeholders’ tolerances to risk. Risk assessment is the process of evaluating the risks that have been identified and developing the data that will be needed for making decisions as to what should be done about them. Risk management is done from very early in the project until the very end. For this reason, the qualitative analysis should be used at some points in the project, and quantitative techniques should be used at other times. The objective of risk assessment is to establish a way of arranging the risks in the order of importance. In most projects, there will not be enough time or money to take action against every risk that is identified. The severity of the risk is a practical measure for quantifying risks. Severity is a combination of the risk probability and the risk impact. In its simplest form, the risks can be ranked as high and low severity or possibly high, medium, and low. At the other extreme, the probability of the risk can be a percentage or a decimal value between zero and one, and the impact can be estimated in dollars. When the impact in dollars and the probability in decimal are multiplied together, the result is the quantitative expected value of the risk.
   In short, which risks require a response? To a great degree, this will be determined by the project stakeholders’ tolerances to risk. There are two basic approaches to analyzing and assessing project risk. The first approach is more qualitative in nature because it includes subjective assessments based on experience or intuition. Quantitative analysis, on the other hand, is based on mathematical and statistical techniques. Each approach has its own strengths and weaknesses when dealing with uncertainty, so a combination of qualitative and quantitative methods provides valuable insight when conducting risk analysis and assessment.
4. Risk Strategy
   It is not feasible or advisable to respond to each and every threat identified because avoiding all threats or requires resources to be diverted away from the real project work. Furthermore, the cost that needs to be allocated for contingencies and mitigations will reach to the point where it will not make any sense to justify the implementation of the project. Risk strategies are the responses we can make to dealing with the risks we have identified and quantified during risk assessment. In the section on risk quantification, we discussed evaluating the risk in terms of its impact and probability in such a way that we would be able to rank risks in their order of importance. This is what we called severity, the combination of impact and probability. Risk response strategy is really based on risk tolerance. Risk tolerance in terms of severity is the point above which a risk is not acceptable and below which the risk is acceptable. There are many reasons for selecting one risk strategy over another, and all of these factors must be considered. Cost and schedule are the most likely reasons for a given risk to have a high severity. Other factors may affect our choice of risk strategy. For example, if a schedule risk is identified for a task in the project, and if this task has many other tasks depending on it, its severity may be calculated as being lower than is apparent, and the severity should be adjusted even though the schedule impact due to the disruption may be difficult to judge. The strategy should be appropriate for the risk it is intended for. The output of this process is the risk response plan which is a detailed plan that describes the actions that will be taken in regards to responding to a particular risk. It is also called the risk register and will include identified risks and descriptions, areas of the affected project, causes of identified risks, and impact on project objectives, risk owners and assigned responsibilities, results from the qualitative and quantitative risk analysis processes, agreed responses including avoidance, transference, mitigation, or acceptance for each risk in the risk response plan, the level of residual risk expected to be remaining after the strategy is implemented, specific actions to implement the chosen response strategy, budget and times for responses, contingency plans and fall back plans. The approach to developing this plan is through meetings with all project stakeholders and obtain project sponsor to sign off prior to approval by the project steering committee.
5. Risk Control
   Once the risk response plan is created, the various risk triggers must be continually monitored to keep track of the various project risks. In addition, new threats and opportunities may present themselves over the course of the project, so it is important that the project stakeholders be vigilant. The purpose of risk control is to determine whether or not risk responses have been implemented as planned, and risk response actions are as effective as expected, or if new responses should be developed. The process of monitoring and keeping track of the identified and unidentified risks is called risk control. In this process, we hope to identify risks that are no longer possible and risks that are coming due, as well as any new risks that may become evident. We will also monitor risk activity to make sure the risk plans have been carried out successfully. Problems that have been found out in the risk management plan can help us adjust the plans for future risk activities. Risk control is part of the risk management processes and must be started early in the project and continued until the end. As the project progresses, we will find that many of the risks will change, some will no longer be possible, others will happen and be disposed of, and new risks will be identified. The level of risk tolerance should be monitored as well. The attitude of the stakeholders will change during the course of the project. Communication with all stakeholders is important s