(CLP) Programs

Appleton Greene corporate training programs are all process-driven. They are used as vehicles to implement tangible business processes within clients’ organizations, together with training, support and facilitation during the use of these processes. Corporate training programs are therefore implemented over a sustainable period of time, that is to say, between 1 year (incorporating 12 monthly workshops), and 4 years (incorporating 48 monthly workshops). Your program information guide will specify how long each program takes to complete. Each monthly workshop takes 6 hours to implement and can be undertaken either on the client’s premises, an Appleton Greene serviced office, or online via the internet. This enables clients to implement each part of their business process, before moving onto the next stage of the program and enables employees to plan their study time around their current work commitments. The result is far greater program benefit, over a more sustainable period of time and a significantly improved return on investment.

Appleton Greene uses standard and bespoke corporate training programs as vessels to transfer business process improvement knowledge into the heart of our clients’ organizations. Each individual program focuses upon the implementation of a specific business process, which enables clients to easily quantify their return on investment. There are hundreds of established Appleton Greene corporate training products now available to clients within customer services, e-business, finance, globalization, human resources, information technology, legal, management, marketing and production. It does not matter whether a client’s employees are located within one office, or an unlimited number of international offices, we can still bring them together to learn and implement specific business processes collectively. Our approach to global localization enables us to provide clients with a truly international service with that all important personal touch. Appleton Greene corporate training programs can be provided virtually or locally and they are all unique in that they individually focus upon a specific business function. All (CLP) programs are implemented over a sustainable period of time, usually between 1-4 years, incorporating 12-48 monthly workshops and professional support is consistently provided during this time by qualified learning providers and where appropriate, by Accredited Consultants.

---

Executive summary

IT-Risk Management- History

In the past three decades, billions of dollars have been spent by millions of organizations around the world in software development projects in order to achieve a number of goals, some of these include enhancement in operational processes, increasing productivity, cost reduction, security compliance, conformance to regulatory requirements, and many other strategic reasons. Usually, the vast majority of information technology projects were outsourced to IT vendors, while others were developed by the internal IT departments. The project manager is responsible for the development of the project budget where typically the approval needs to be secured from the project sponsor. A typical IT project budget will indicate the number of resources required for the project where the cost of labor can be easily determined based on the project work activities specified in the project schedule. The cost of equipment or materials that are required for the project will also be listed together with the cost to be incurred for services that are to be acquired from external vendors and/or contractors. The procurement department will then solicit the qualified vendors based on the approved budget. Whether the customer chooses to acquire the services of internal IT organization or engaging external vendors, there was one common thing behind these colossal project investments i.e. details of the cost associated with risk management were not known. There are project risks in any project, information technology (IT) project is no exception. It is common not to find details of the project risk in an IT project budget especially during the development of the project charter. This happened decades ago and still happening today. Past analysis revealed that many of the IT projects today have failed to meet the project objectives, they failed because the project management team failed to identify the major risks early in these projects! If these risks are not identified at the early phase of the project, they are unlikely to be considered during the planning phase of the project. When developing the project cost management plan, the project budget will not include the details of the cost of mitigating the risks because these risks are not captured earlier in the project. Any IT project should have project contingencies where these are defined alongside the risk mitigation process. Past project experiences revealed that the project budget did not indicate the cost of implementing the effort associated with project contingencies. The effort involves people (generally referred to as “labor”), besides the cost of labor we need to look at the cost of equipment or material associated with the work, the third party cost from external contractors, cost of licenses related to products, and any expenses related cost to perform the work. As we all know, there are many kinds of risk threatening an IT project which include among others technology risks, risk due to inflation, the risk associated with currency control, risk related to project liabilities, where all these risks pose a direct impact to the project profitability. The project managers may be aware of these risks but lack the knowledge or expertise to compute the cost of managing and controlling these risks. The project stakeholders, specifically the project sponsor need to be aware of this cost so that an accurate and comprehensive preliminary project budget can be presented to the executive management committee prior to initiating a project. Past project experiences also revealed that project managers do not have sufficient resources on the project team who are expert in identifying and qualifying the risk in the early stages of the software project life cycle and most probable reasons behind this was due to lack of training in IT risk management. Without a proven methodology, it is highly unlikely that an IT project can be successfully delivered within budget, scope, schedule, and quality.

---

IT-Risk Management– Current Position

Project risk management is becoming an important sub-discipline of software engineering. It focuses on identifying, analyzing, and developing strategies for responding to project risk efficiently and effectively. It is important, however, to keep in mind that the goal of risk management is not to avoid risks at all costs, but to make well-informed decisions as to what risks are worth taking and to respond to those risks in an appropriate manner. Executive management is looking at cost reduction that needs to be realized through efficient management of risk in IT projects. Project risk management provides an early warning system for impending problems that need to be addressed or resolved. Although risk has a certain negative connotation, project stakeholders should be vigilant in identifying opportunities. Although many IT project managers associate uncertainty with threats, it is important to keep in mind that there is uncertainty when pursuing opportunities, as well. It is unfortunate that many projects do not follow a formal risk management approach. Because of their failure to plan for the unexpected, many organizations find themselves in a state of perpetual crisis characterized by an inability to make effective and timely decisions.

The digital environment that surrounds us today has resulted in the proliferation of mobile applications that always need to establish a constant communication with a number of cloud computing systems. It is an internet-based computing application where all the shared resources, software, and information are provided to the computers and devices on demand. Users can access the information from anywhere and anytime, therefore, it is imperative to ensure that appropriate project risk management processes and tools are being used in e-commerce and cloud-computing related projects. A common problem cited was that few companies try to anticipate problems once systems are implemented. For example, security is a common threat to many e-commerce systems; however, few companies can actually say what impact security risk would have on their customers. As it turns out, crisis management is much more expensive and embarrassing than risk management.

Mobile application and e-commerce developers must be knowledgeable in the processes used to manage risk in their software projects. It does not matter whether a particular company is involved with software-as-a-service (SAAS) business, operating a platform-as-a-service (PAAS) provider, or a business process outsourcing provider, the process of managing and controlling risk stays the same. One of the primary issues facing software companies today is how to reduce the cost of software development that will directly contribute towards boosting project profitability.

While there is no shortcut to success, the first step is to look at the existing business processes and initiate a program to acquire new processes that will help to reduce the development cost. The obvious cost drivers are the cost of labor, cost of materials, cost of product licenses, cost of subcontractors, and the expenses associated with the people executing the work. The hidden cost drivers are the cost of unknown risks that can make up a reasonably large percentage of the entire project cost. For instance, if the requirements specification is subject to changes of x percent of the project cost, then the mitigation plan for this known risk can be easily factored into the Risk Management Plan. On the contrary, should there be any regulatory changes in the course of implementing the project, the cost of managing the hidden risks may exceed beyond the available budget and will soon eat into your project profitability. Early adoption of project risk management processes will help to minimize the impact of this hidden cost since these risks will be detected in the early stages of the project lifecycle. As soon as they are detected during the course of the project development, the appropriate action against these risks will be taken based on the response strategy defined in the Risk Management Plan. Identifying risks associated with project liabilities can help the project manager to manage the overall cost of software development. For instance, if you know the cost as a result of a late delivery of a software project, you will ensure that your project team delivers the project within the agreed schedule in order to avoid paying the penalty. Based on current assessment of IT project implementations across all industry sectors, project managers still lack the required skills in the management and control of project risk, a situation that is critical as more new technologies are being utilized in the near future and more stringent control measures need to be in place to manage the potential threats associated with the adoption of these new technologies.

By applying project risk management processes for your organization, your chances of project success increases by minimizing and eliminating negative risks so projects can be completed within budget, schedule, scope, and quality. When you don’t have risk management strategies in place, your projects get exposed to problems and become vulnerable. Effective risk management strategies allow your company to maximize profits and minimize expenses on project activities that don’t produce a return on investment.

---

IT-Risk Management– Future Outlook

The objective of performing risk management is to enable the organization to accomplish its mission by better securing the IT systems that store, process, or transmit organizational information; by enabling management to make well-informed risk management decisions to justify the expenditures that are part of an IT budget; and by assisting management in authorizing or accrediting the IT systems on the basis of the supporting documentation resulting from the performance of risk management.

Managing risks in an information technology project is a complex, multifaceted activity that requires the involvement of the entire organization, from senior leaders and executives providing the strategic vision and top-level goals and objectives for the organization; to mid-level managers who are involved in planning, executing, and managing projects; to individuals on the front lines operating the information systems supporting the organization’s missions and business functions. The advancement in information technology has resulted in the creation of many products and services where risk management sits at the center of these developments. To successfully execute organizational missions and business functions that are related to these information system-dependent processes, senior leaders and executives must be committed to making risk management a fundamental mission of the company’s business requirement. The top-level executives are always remained committed to ensuring that sufficient resources are available to develop and implement effective, organization-wide information systems risk management programs. Understanding and addressing risk is a strategic capability and an enabler of missions and business functions across organizations. Accountability by senior leaders for their risk management decisions are important to drive the implementation of effective, organization-wide information systems risk management programs.

Demands for risk management training has increased in the past thirty years and continue to increase for many years ahead especially from individuals or consultants with responsibilities for conducting organizational information security implementations; vendors with responsibilities for implementing information technology products, services, or application software; service providers offering outsourced services including Software-as-a-Service, Infrastructure-as-a-Service, and Platform-as-a-Service. Whenever there is an adoption of technology in products or services, there will be risks associated with the use of these inventions and so will be the knowledge and the skills required to manage the risks. Another group of individuals who need to embrace risk management processes in IT system is the software testers who perform penetration and regression testing for systems and applications. Systems integration testing can be used to complement the review of security controls and ensure that different facets of the IT system are secured. Systems testing, when employed in the risk assessment process can be used to assess an IT system’s ability to withstand intentional attempts to circumvent system security. Its objective is to test the IT system from the viewpoint of a threat-source and to identify potential failures in the IT system. The people who manage the IT infrastructure which include servers, network systems, databases, storage systems, et cetera need to ensure that there is minimal risk associated with each of these components. These people will need to apply the risk management processes during and after the installation of these components to ensure that they are operating at the optimum level otherwise the business operations will be severely affected, and as a consequence, the enterprise will incur a colossal loss of revenues. The risk management framework and the processes in this corporate training program have been designed to specifically manage and control risk that will certainly be applied in future IT systems and projects. Although new business processes will be introduced to support the requirements of future technologies, however, it will not affect the methodology and the underlying risk management processes that govern the implementation of these new applications.

---

Curriculum

IT-Risk Management – Part 1- Year 1

1. Part 1 Month 1 Risk Framework
2. Part 1 Month 2 Governance Structure
3. Part 1 Month 3 Risk Identification
4. Part 1 Month 4 Vulnerability Identification
5. Part 1 Month 5 Qualitative Assessment
6. Part 1 Month 6 Quantitative Assessment
7. Part 1 Month 7 Risk Strategy
8. Part 1 Month 8 Risk Monitoring
9. Part 1 Month 9 Risk Repository
10. Part 1 Month 10 Risk Plan
11. Part 1 Month 11 Transition Plan
12. Part 1 Month 12 Organizational Plan

---

IT-Risk Management – Part 2- Year 2

1. Part 2 Month 1 PRISM Tool
2. Part 2 Month 2 Labor Services
3. Part 2 Month 3 Project Material
4. Part 2 Month 4 Professional Services
5. Part 2 Month 5 Cloud Services
6. Part 2 Month 6 Conversion Risk
7. Part 2 Month 7 Project Expenses
8. Part 2 Month 8 Product Licenses
9. Part 2 Month 9 Project Liabilities
10. Part 2 Month 10 Contingency Reserve
11. Part 2 Month 11 Inflation Charge
12. Part 2 Month 12 Risk Dashboard

---

IT-Risk Management- Part 3- Year 3

1. Part 3 Month 1 System Requirements
2. Part 3 Month 2 System Design
3. Part 3 Month 3 System Construction
4. Part 3 Month 4 System Integration
5. Part 3 Month 5 System Acceptance
6. Part 3 Month 6 System Implementation
7. Part 3 Month 7 Scope Management
8. Part 3 Month 8 Issues Management
9. Part 3 Month 9 Transition Management
10. Part 3 Month 10 Communications Management
11. Part 3 Month 11 Executive Reporting
12. Part 3 Month 12 Implementation Review

---

Program Objectives

The following list represents the Key Program Objectives (KPO) for the Appleton Greene IT-Risk Management corporate training program.

IT-Risk Management – Part 1- Year 1

1. Part 1 Month 1 Risk Framework – The risk planning phase comprised of a number of workshops that will facilitate the development of the project Risk Management Plan. The first step is to establish the appropriate IT project risk management framework that will administer the management of risk activities throughout the life of the IT project. Why do we need to establish the IT project risk management framework? The IT project risk management framework is required in order to effectively integrate the process for managing risk into an organization’s overall project management and reporting processes. Risk management has always been a part of software development project, IT outsourcing services project, IT infrastructure projects, system migration projects or any IT-related project. A formal IT project risk management process, supported by effective methods in the individual process steps, needs to be implemented regardless of the size of the project, it could be a single stand-alone project or group of highly complex projects. A project manager with the assistance of a risk consultant within the project team, shall monitor, maintain and control risks in an IT project to ensure that the project can be delivered within budget, scope, schedule and meeting the quality requirements defined in the Project Management Plan. In order to achieve this, we need to set up a framework that defines the approach the project team will take in managing risk throughout the life of the project. At the core of the IT project risk management framework, stood the measurable organizational value that defines the goal of the project that defines the measurable value the organization expects from the project. It is both a measure and definition of project success. The next layer of the framework includes the project objectives in terms of scope, quality, schedule, and budget. Although these objectives are not by themselves sufficient conditions for success, together they do play a critical role in supporting the measurable organizational value. The following layer focuses on the sources of IT project risk. Risks can arise as a result of the various people or stakeholders associated with a project, legal considerations, the processes, the environment, the technology, the organization, and others. The project manager needs to secure a commitment from all project stakeholders to ensure that adequate resources are in place to properly plan and manage the various risks within the boundaries of the agreed risk management framework. Upon completion of the “Establish Risk Framework” process, the IT project risk management framework will be defined and ready to be applied to the project.
2. Part 1 Month 2 Governance Structure – In any project there exist a number of project organization structures. A project steering committee that reports to the executive management is responsible for the full completion of the project and ensure that the project outcomes will meet the business strategy and the organizational goals agreed upon during the project feasibility study. There is also a project quality management team that is responsible for ensuring that the project will be delivered based upon the quality requirements defined in the quality management plan. The project working committee will ensure that the project will be delivered within the boundaries of the scope, schedule, and budget requirements as agreed by the project sponsor. The project management team headed by the project manager will execute the tasks defined in the project schedule and continuously observe the risk while performing the work. A risk management consultant may be part of the project management team as is usually the case for smaller to medium size projects, whereas a dedicated Risk Management Committee (RMC) is usually set up to oversee risk activities for a number of concurrent projects. This is the case for matured organizations that view risk as the primary critical success factor in project management. Whether the size is large or small, the primary purpose of the risk consultant or the RMC is to ensure that the risk will be monitored and controlled throughout the life of the project following the prescribed organizational policies. The RMC is only active for the duration of the project with direct reporting to the project sponsor and indirectly to the enterprise risk management board. The roles and responsibilities of each of the project organizations described above will be explicitly defined to ensure that any actions or work to be undertaken shall comply with the rules and regulations defined by the corporate executives. The risk governance structure needs to be installed prior to defining the IT project risk management framework. Once the risk governance structure has been established, the relevant information associated with the project that includes the project charter, the organization risk management policies, the breakdown of project activities, and other relevant data will be made available as inputs into the establishment of the risk management framework. The process “Establish Governance Structure” that will be formed in the planning phase of the project lifecycle is an important step toward establishing a solid foundation for the efficient management of risk in subsequent phases of the project.
3. Part 1 Month 3 Risk Identification – This workshop deals with the tools and techniques to assist the project team in identifying risk. The Project Risk Identification process involves tasks that include many of the project stakeholders, and require an understanding of the project’s goal, as well as the project’s scope, schedule, budget, and quality objectives. Historical information can be extremely helpful in determining potential project risks. Data and documentation from previous projects or interviews with team members or other subject matter experts from past projects provide excellent insight into potential risk areas and ways to avoid or mitigate them. Once a particular risk has been identified, it is important to classify and categorize that particular risk into a specific risk category. By classifying the risk into its relevant category, it helps to accelerate the process of evaluating the risk later. For example, risks categorized under “Technical risk” may include quality or performance-related risks such as reliance on unproven or complex technology, unrealistic performance goals, or changes to the technology used. Risks categorized under “Organizational risks” may include risk associated with cost, time, and scope objectives, inadequacy or interruption of funding, and resource conflicts with other IT projects in the organization. External risks may include risk such as regulatory environment, labor issues, changing owner priorities, and weather. SWOT technique (strength, weaknesses, opportunities, threats) allows the project team to identify threats and opportunities as well as their nature in terms of project or organizational strengths and weaknesses. Brainstorming is likely the most common approach to risk identification. It is usually completed together as a project team to identify the risks within the project. The Delphi Technique is an anonymous method to query experts about foreseeable risks within a project, phase, or component of a project. The results of the survey are analyzed by a third party, organized, and then circulated to the experts. There can be several rounds of anonymous discussion with the Delphi Technique without fear of backlash or offending other participants in the process. There are a number of techniques to be considered, the project management team will decide the appropriate tools and techniques to be used with the “Project Risk Identification” process.
4. Part 1 Month 4 Vulnerability Identification – The analysis of the threat to an IT project must include an analysis of the vulnerabilities associated with the system environment. Identifying risk requires a comprehensive understanding of the customer’s computing environment. The person who conduct the risk assessment must therefore first collect system-related information, which comprised of hardware, software, system internal and external connectivity, data and information, persons who support and use the product or services of the IT project, the processes performed by the IT project, the system’s value or importance to an organization, and system and data sensitivity. Additional information related to the operational environmental of the IT project and its data includes the functional requirements of the information systems, users of the system e.g. system users who provide technical support to the IT system, and application users who use the IT system to perform business functions, system security policies governing the IT system that includes organizational policies, federal requirements, laws, industry practices, system security architecture. Other areas that need to be examined are the technical controls used for the IT project e.g., built-in or add-on security product that supports identification and authentication, discretionary or mandatory access control, audit, residual information protection, encryption methods, management controls used for the IT project (e.g., rules of behavior, security planning), operational controls used for the IT system (e.g., personnel security, backup, contingency, and resumption and recovery operations; system maintenance; off-site storage; user account establishment and deletion procedures; controls for segregation of user functions, such as privileged user access versus standard user access The “Examine System Vulnerability” process is part of the risk management framework that needs to be formalized in the Risk Management Plan.
5. Part 1 Month 5 Qualitative Assessment – Risks can be analyzed according to the likelihood they will be realized and the level of seriousness or impact they will have if they do occur. That is, risks are classified whether there is a low, medium or high likelihood they will occur, and according to whether their level of seriousness/impact will be low, medium or high if they happen. From this classification, a priority listing for evaluation and action can be developed, separating the acceptable risks from the unacceptable ones. This workshop will guide participants through the qualitative risk analysis process, one of the techniques commonly used in risk assessment to prioritize risks. This process is intended to prioritize risks according to their potential effect on project objectives i.e. those risks that affected the scope of the project, the budget allocated, the time that the project is scheduled to complete, and the quality of the product or output that meet the quality requirements. The primary input into the “Qualitative Risk Analysis” process is the Risk Register which is the result of the risk identification process. A thoroughly developed register of risks that may affect project objectives, is helpful. We sometimes find ourselves in situations where moving forward is difficult because of indecision. Identifying, describing, and assessing project risks allow us to prioritize risks. Prioritization can free us from indecision by providing specific, documented risk events that we can act on to shift the odds in favor of project success. Prioritizing risks gives project managers the information required to schedule work against the availability of project resources and within the project constraints. The qualitative risk analysis is one way of determining the importance of addressing specific risks and guides risk response measures. An evaluation of the quality of the available information also helps modify the assessment of the risk. Qualitative risk analysis requires that the probability and impact of the risks be estimated using qualitative methods and tools. Using these tools helps correct biases that are often present in a project plan. The “Qualitative Risk Analysis” process will be conducted regularly during the project’s life cycle to stay current with changes in project risks. This process can lead to further analysis using quantitative risk analysis or directly to risk response planning process.
6. Part 1 Month 6 Quantitative Assessment – Following identification and analysis of project risks, project managers and project teams must take action in response to the identified project risks, focusing on risks of most significance, in order to shift the odds in favor of project success. This workshop focuses on the risk assessment process using a quantitative analysis method. The quantitative risk analysis process aims to analyze numerically the probability of each risk and of its impact on project objectives, as well as the extent of overall project risk. This process uses techniques such as decision tree analysis to determine the probability of not achieving a specific project objective. The “Quantitative Risk Analysis” process will quantify the risk exposure for the project and determine the size of cost and schedule contingency reserves that may be needed. This process helps to identify risks requiring the most attention by quantifying their relative contribution to project risk, and by identifying realistic and achievable cost, schedule or scope targets. Quantitative risk analysis generally follows qualitative risk analysis. The quantitative risk analysis processes can be performed separately or together. Considerations of time and budget availability, and the need for qualitative or quantitative statements about risk and impacts will determine which method to use. The risk assessment process is well suited to a structured and systematic approach. For complex or more widespread issues a facilitated workshop format involving participants with different perspectives is often helpful and more effective with the aid of an experienced facilitator to lead the discussion that can provide another objective perspective. The “Quantitative Risk Analysis” process will be conducted regularly during the project’s life cycle to stay current with changes in project risks
7. Part 1 Month 7 Risk Strategy – After we have identified and analyzed the risks we know where to focus our efforts. The output from the analysis provides a ranked risk register with the risks of greatest significance to project objectives determined. Response actions to significant risks must be cost-effective and realistic. Critical risks must be met with vigorous response actions, lower ranking risks should receive response actions commensurate with their significance. The purpose of risk analysis and assessment is to determine what opportunities and threats should be addressed. It is not feasible to respond to each and every threat or opportunity identified because avoiding all threats or chasing after every opportunity requires resources to be diverted away from the real project work. As we continue through project development the project risk profile will change. Typically as we successfully respond to risks and our project knowledge increases our risk exposure will diminish. In effect, we can retire risk reserve as risk events are successfully avoided or mitigated or we have passed the time during which the risk is active and it becomes retired. This workshop focuses at the several types of responses which a project manager can opt for a particular risk event depending on the outcome of the risk assessment conducted earlier including other factors such as cost, schedule, scope, and quality. Risk strategies define how the project stakeholders will respond to risk. In general, risk strategies include accepting or ignoring the risk, avoiding the risk, mitigating or reducing the likelihood and/or impact of the risk, and transferring the risk to someone else. A set of risk metrics should be defined to act as triggers, or flags when a particular risk event occurs. The risks, the risk triggers, risk owners, and strategies should be formalized in a risk response plan. For instance, a particular project activity may be appropriate to be outsourced to a sub-contractor in anticipation of resource constraints that may occur during the development phase could be the ideal strategy in responding to this kind of risk event. The process “Define Risk Strategy” will discuss the types of risk and the appropriate responses that should be taken for each risk in this workshop.
8. Part 1 Month 8 Risk Monitoring – Risk monitoring and control is the process of monitoring identified risks for signs that they may be occurring, controlling identified risks with the agreed responses, and looking for new risks that may creep into the project. Risk monitoring and control also is concerned with the documentation of the success or failure of risk response plans, and keeping records of metrics that signal risks are occurring, fading, or disappearing from the project. We may have little or no control over the external environment but we do have control over how we interact with it. We do have control over our state of readiness, we can look ahead and improvise and adapt. We can control the robustness of our response to identified risk events and the quality of our documentation. We have control over how earnestly we integrate risk management into our project management plans. As we continue through project development the project risk profile will change. Typically as we successfully respond to risks and our project knowledge increases our risk exposure will diminish. In effect, we can retire risk reserve as risk events are successfully avoided or mitigated or we have passed the time during which the risk is active and it becomes retired. After we have implemented response actions, we must track and record their effectiveness and any changes to the project risk profile whether the response actions have a positive or negative effect on achieving the project objectives. This workshop is devoted to measuring project risk management per performance and determining whether a project is tracking to plan or deviating in a negative manner. This will require a blend of qualitative judgments and quantitative measures to determine the “health” of the project. Document the response action by describing the action, the work activities it will affect and the cost of the response action. Identify the person responsible for successful implementation of the response action. Included in this workshop is consideration of the time impacts of the response action and how the risk response may affect the overall project objectives. The “Monitor and Control Risk” process requires participation from the project manager, the project team, key stakeholders, and, in particular, risk owners within the project. As the project progresses, risk conditions may change and require new responses, additional planning, or the implementation of a contingency plan.
9. Part 1 Month 9 Risk Repository – The preliminary set of risks derived from Risk Identification workshop need to be documented. Information about each risk needs to be registered in a document that is accessible to all project stakeholders for the purpose of ease of maintenance, monitoring, and reporting. This document that is commonly called the “Risk Register” will be the central repository for risks throughout the project management lifecycle. The mitigation plan will be assigned to each risk that includes preventative and contingency plans. Preventative plans are planned actions to reduce the likelihood of a particular risk occurring. Contingency plans are planned actions to reduce the impact of the risk to the project objectives if it does occur. These plans of actions need to be incorporated into the project implementation schedule. Through the process “Develop Risk Register”, the Risk Register documents risk mitigation strategies in response to the identified risks and their grading in terms of likelihood and seriousness. It provides the project sponsor, project steering committee with a documented framework for standardized reporting of risks within the approved risk governance framework. It ensures the communication of risk management tracking and updates with key project stakeholders. It provides a mechanism for seeking and acting on feedback to encourage active participation from the key project stakeholders. It helps to track the mitigation actions and the implementation status of the risk the contingency plans. As the Risk Register is integrated into the status reporting process, this review and re-evaluation should take place automatically with the preparation of each new status report. Because the Risk Register places risks in order of their severity level, it is important to update all quantifiable fields to portray an accurate risk landscape. The risk probabilities may have changed; the expected level of impact may be different, or the date of impact may be sooner or later than originally anticipated, all of these variables determine which risks the project team will concentrate on first.
10. Part 1 Month 10 Risk Plan – Developing the project risk management plan is the primary focus of this workshop. A formal project risk management plan is a detailed plan of action for the management of project risk. The Project Manager evaluates the results of the previous task to determine an appropriate response for each risk: avoidance, mitigation or acceptance. Each case will require a decision by the Project Team. The Project Manager is then responsible for communicating the steps necessary to manage the risk and following up with team members to ensure those steps are taken. Since each risk may have more than one impact, the Risk Management Plan must describe the actions to be taken to avoid, mitigate or accept each risk impact, including contingency plans. It should also specify the individual responsible for the mitigation actions or contingency plan execution. Attention should be directed to those risks most likely to occur, with the greatest impact on the outcome of the project. On the other hand, a conscious decision can also be made by the Project Team to accept or ignore certain risks. These decisions must be documented as part of the Risk Management Plan for subsequent re-evaluations. The Risk Management Plan represents the risk management processes the project management team will use to identify, manage, and control risk throughout the life of the IT project. Based on the data collected in the previous workshops, the Risk Management Plan will be tailored according to the specific requirements of the customer organization. The risk management plan lays down the groundwork for how risk management will be conducted throughout the project. It serves as the official guidance for the risk process, its thresholds, its formats, and the roles and responsibilities of the project stakeholder in managing risk. Risk management must be partnered with a well-organized and properly documented project base cost estimate. Risk management introduces reality into our project management processes by recognizing that every project has a risk of cost overrun and also exceeding the agreed implementation schedule. This does not mean cost overrun is inevitable, it means it is possible. This workshop will guide in the development of the project Risk Management Plan that will include the construction of risk governance, defining the risk management framework, processes related with risk identification, IT-system environment, risk assessment, risk strategy, and processes related with controlling risk. The Risk Management Plan needs to be constantly re-evaluated and ensure that the right people are still assigned to mitigation actions and that the actions still make sense in the context of the latest project developments
11. Part 1 Month 11 Transition Plan – The project manager must formulate and document a plan for implementing or deploying the product of the project and for transitioning the responsibility for the outcome of the project from the project team to the customer. The Transition Plan must include all the necessary activities to perform and procedures to follow to ensure a smooth and satisfactory hand-off. When planning the implementation and transition, the Project Team must consider the impact the resulting product will have on the customer and consumers. The end users must be prepared to use the product and the customer must be prepared to support it. What needs to be done to ensure the organization will be ready to receive the product or the services of the project? These steps may include acquiring the necessary physical space, installing appropriate software, obtaining the appropriate building permits. How and when the customer will test and accept the product and confirm and authorize its implementation. Procedures to ensure consumers will be ready to use the product once it is transitioned. These steps must be coordinated with the Organizational Change Management Plan and will include training and orientation on the use of the product. It is mandatory to develop a plan to transition the ongoing support of the product to the customer and to ensure that the appropriate individuals are ready to support the product once it has been implemented and is in use. There are risks during project transition, through “Identify Transition Risk” process, the project team can determine the expected threats the project team will have to manage during the course of the transition process. Risk identified must be defined in the Risk Register including special attention given to contingency planning and risk mitigation. This transition is achieved by comparing the current business process with a clear understanding of what will change in the new business process. For example, does the project deliver a new tool or an IT application or a re-structured organization or modified policies or procedures? Any foreseeable risk should be incorporated into the transition planning process in order to achieve a successful project implementation.
12. Part 1 Month 12 Organizational Plan – When planning the project, the project manager and customer must consider the impact the resulting product will have on the customer. The organization must be prepared to accept and use the product once it is implemented. The Project Manager needs to define and document a plan to manage the changes to the organization that could occur as a result of implementing the product. This Organizational Change Management Plan becomes part of the Project Management Plan. Organizational change management must be explicitly planned if it is to be effective. The plan must consider how the individuals using the product will be affected by its implementation. The organization may initiate reductions or expansions in the workforce, and shift rote clerical activities to automated processing; decision-making power may be distributed further down the chain of command, or even regionally. If specific job duties are being added or removed, staff reductions or increases are anticipated, or the organizational structure itself will change, the plan must identify the steps to be taken. For example, the human resources manager in the customer organization must be involved in planning and performing many of these change management tasks. The plan must consider how the product of the project will affect already existing business processes in the customer. Business processes may take advantage of streamlined workflows to reduce the flow of paper, or technology advances may enable electronic communications to more quickly deliver information. Procedures will need to be redesigned to align with the change. The new procedures may effect changes in the way the customer develops, documents, and trains staff, and must be addressed in the Organizational Change Management Plan, which formed part of the IT risk management framework.

---

IT-Risk Management – Part 2- Year 2

1. Part 2 Month 1 PRISM Tool – PRISM is the acronym for Project Risk for Information Systems Management, a cost and risk modeling tool that will be developed in the next several series of this training program. Project cost management is traditionally a weak area of IT projects. IT project managers must acknowledge the importance of cost management and take responsibility for understanding basic cost concepts, cost estimating, budgeting, and cost control. Project managers must understand several basic principles of cost management to be effective in managing project cost. It is difficult to manage risks in a project if you do not know its cost implications of the project objectives. For example, if you are expecting the scope of the project to change during the planning phase as advised by your customer, you will probably allocate some buffer in the project schedule in anticipation of this change, so the project schedule will not be affected by this change. This could be one of the risk response strategies but what about the additional cost related to labor, material, expenses, and others as a result of the changes in project scope? How will you provide an accurate estimation of this cost and how will you make provision for this additional cost in the overall project budget? What are the mitigation plans to control scope creep and what will be the contingency plans should the changes need to be accepted and the functionalities included in the finished product? If you are not familiar with risk management and cost management process then you will most likely unable to control the project capital expenditure. In this example, not knowing the cost as a consequence of scope changes will result in high probability of this project failing to complete according to the agreed budget. PRISM is a specially designed risk-modeling tool for project managers to prepare a balanced project budget through modeling of project budget, contingency reserve, project liabilities, and risk provisions. You define all cost into PRISM, the risk affecting the project activities, the project selling price, and let PRISM generate the profitability report and risk analysis automatically. With PRISM, you can model your project costing and risk appetite to suit your margin requirements. A complete overview of the PRISM framework will be discussed in this workshop to facilitate the development of the respective functionalities. In addition to the sleek dashboard that displays a brief and concise overview of the entire breakdown of project prime cost, the breakdown of project cost including risk, and project profitability, PRISM is a user-friendly tool for ad-hoc reporting of project performance.
2. Part 2 Month 2 Labor Services – Using “Define Labor Services” process, cost of labor services can be easily captured into PRISM. This is the first part of several series of workshops that will be focusing on developing the project risk management tool called “PRISM”, this tool will be used throughout the risk management process. The Project Manager may use manual or automated tools to generate a preliminary project budget. The Project Manager calculates the preliminary budget that will be required to complete project activities. All aspects of the project, including the cost of human resources, equipment, travel, materials, and supplies, should be incorporated in the subsequent workshops. Labor cost will be defined based on the project activities in the work breakdown structure. The Project Manager must also have a general understanding of the cost of both the human resources and the equipment and materials required to perform the work. The method by which human resources will be acquired for the project will directly affect the risk budgeting process. PRISM will assist the project manager and project team to manage project risk from the System Requirements phase until System Transition phase of the system development life cycle. As for other projects not associated with software development, PRISM will manage the risk according to the phases of the project management life cycle i.e. from Project Initiation phase until Project Closure. Although the cost of labor will be captured for all work packages, PRISM is flexible enough to accommodate your preferred method of capturing the cost of labor. The objective of capturing the cost of labor is to facilitate PRISM to compute project budget associated with risk mitigation, the cost associated with contingencies, and other costs that affected the project budget. In this workshop, we shall develop PRISM to capture the cost of labor that will later be used to compute the cost of contingencies for all high impact risks identified in the Risk Register. PRISM tool will be further developed in subsequent workshops when we perform cost budgeting associated with risk mitigation, cost budgeting associated with project liabilities, and cost budgeting associated with project contingencies.
3. Part 2 Month 3 Project Material – There are many types of equipment that include computer hardware, applications, database, tools, storage, networking devices, and many other materials used in an IT project. It is imperative to capture information associated with all the materials in the project so we can determine the cost of managing this risk should plan contingencies are in place that involved a particular material. There are a number of project documentation that describes the list of equipment used in a project including equipment that is leased for the duration of the project. Project procurement management plan and the project schedule is the ideal place, to begin with for purchases of equipment required for the project. The equipment used in all the phases of a software development lifecycle need to be captured into PRISM. The development environment consists of application servers, database servers, communication and network equipment are common equipment in any enterprise IT project. These types of equipment will most likely be replicated in the production environment with a much larger scale in configuration i.e. typically in size and performance. The capital cost of these items will be used in a number of project financials, e.g. project contingency reserve involving these types of equipment can be determined when the cost of all materials impacted by the risk event is captured. The process “Define Project Material” will add an important functionality to the PRISM tool to record information on project materials and equipment used in the project. A particular risk event may impact these materials or equipment, there will be some mitigation cost or contingency cost that need to be accounted for and computed as part of the project risk allocations.
4. Part 2 Month 4 Professional Services – This cost of services discussed in this workshop is related to the cost of manpower services, and the cost of application management and implementation services that are usually provided by a third party or external vendors. It is imperative to discuss the cost of manpower that is directly related to the human resources who are involved in providing professional services to the project. A professional service is the services that a contractor or product vendor sells to help a customer manage the specific part of the project development. A resource vendor supply people for specific skills and for a specific duration of time. Vendors that provide these services may have issues in delivering their committed services. There are uncertainties that are beyond the control of the IT vendor, for example, external factors that include regulatory changes, force majeure, and other unknown threats and these threats will directly impact your project implementation. There are many types of IT services and they must be captured into PRISM, this will help the project manager to determine the cost of these services against the overall project budget. Application management and implementation services include the cost of services a vendor provides in delivering a software product, which includes the cost of implementation together with the cost of any customization effort. The primary objective is to determine the budget that needs to be reserved for risk impacting these professional services. There are mitigation cost, contingency cost, the cost associated with liabilities that may be incurred as a result of using the vendor’s professional services, and many other types of risk associated with professional services. At the end of this workshop, via “Define Professional Services” process, additional functionality will be added into PRISM that helps to determine the budgeted cost of professional services that need to be allocated for risk management, and most important to the project team is to determine which professional services are expected to cause the highest risk impact on the project budget, scope, and schedule.
5. Part 2 Month 5 Cloud Services – Taking advantage of the latest development in cloud computing technology, vendors are offering infrastructure management services to assist organizations in reducing the cost of software development projects. The colossal cost to build a specific development and testing environment for the interest of a group of users in a large enterprise is no longer practical. It is cost-effective to rent the computing resources from a reputable hosting provider that provides most of the IT resources required including database, tools, storage, network, and other services at a fraction of the actual cost. Of course, there are issues like information security that remains to be a challenge but the attractive cost of the services outweigh this risk. Outsourcing services that are commonly subscribed today are Software-as-a-Service, Infrastructure-as-a-Service, and Platform-as-a-Service. The services provided may be suitable for selective IT projects only where the majority of them are not sensitive to data privacy. The services may be in high demand in specific industry and least popular in financial services and banking industry where data security and protection is extremely high. While many of these outsourced providers are established, they cannot provide a 99.99% guarantee for the availability of the services, so there is obviously some degree of risks that need to be seriously considered prior to engaging these type of services. In this workshop, via “Define Cloud-computing Risk” process, we will discuss the list of potential threats from the use of these type of services with data security leading the top of this list.
6. Part 2 Month 6 Conversion Risk – There are a number of risks associated with the conversion of existing data, where these data are required before implementation of a new software product. Existing data may not be complete, even if they are complete there are spelling errors, formatting errors, and many other problems with the data. One way to handle this situation is as follows. Determine the state of the data being converted. Is it a straight one to one conversion or is it combining the inputs of multiple files? Will the data need to be “cleaned up” before the new files are constructed, i.e., are there known problems with the existing data that will need to be fixed before the new databases are constructed? What is the risk if the data do not cleanse and updated? We need a data migration plan to handle this situation. The plan must address how to handle these and other situations unique to the project. Support from the client must be negotiated and planned as a part of the work breakdown structure (WBS). This is crucial in situations where data from the old files must be cleansed to create the new databases. The data cleansing exercise is a major effort and poses a major threat to the project during system testing and user acceptance testing. A lot of time needs to be allocated to troubleshoot a software error that is caused by a bad test data. Mitigation plan involving data conversion activity need to be put in place to ensure resources and infrastructure are available to support data conversion process. A contingency plan needs to be defined to ensure that the affected project activities will not be impacted due to unavailability of live data in the production environment.