(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. Converting data into the production environment during project transition phase is not only a risky business but costly and time-consuming task. This effort will have to be provided by internal resources however it may be outsourced to an IT vendor depending upon the sensitivities of the data. The technical support for the data conversion effort must be planned and monitored closely. By working closely, the client will have a good idea that what is happening is accurate. Ultimately, the client will have to sign off to validate that the conversion was done correctly. All support activities must be included in the project plan and WBS. The more involved conversion effort will require a greater amount of time and should be planned accordingly. All support activities should be closely tracked, and issues should be raised if any of these activities are not completed in a timely manner. In this workshop, via “Define Conversion Risk” process, we will discuss the list of potential threats from data conversion activity that have a colossal impact on projects schedule, budget, and quality.
7. Part 2 Month 7 Project Expenses – Any project will incur expenses, information technology project is no exception. There is a large number of expense items related to project activities so it is not possible to make provisions for each of them in PRISM. The expense data may be extracted from available spreadsheets and loaded into PRISM tool or otherwise, they will be manually captured into PRISM and grouped according to high-level work packages. The project implementation schedule is the ideal place to start since it represents all the activities in delivering a project. Furthermore, the project schedule is commonly developed using a project management tool such as Microsoft Project, hence making the extraction process simpler. How project expenses will be captured depends on the policies of the client organization, and also the project sponsor requirements for tracking and reporting on project performance. Expense item may include meal allowances, rental of equipment, stationaries, accommodation, mileage expenses, et cetera. It is important to capture the complete project expenses in order to obtain accurate reporting on project profitability. Furthermore, the cost of risk contingencies that impacted project expenses will be known. At the end of this workshop, after execution of the “Define Project Expenses” process, additional functionality will be added into PRISM that helps to determine the budgeted cost of project expenses that has been reserved for risk management.
8. Part 2 Month 8 Product Licenses – In any IT project implementations, whether it is infrastructure development, software development, or cloud computing project, there will be a number of product licenses that your client or your company need to purchase. Off-the-shelf accounting software, anti-virus software, Microsoft office products, database, all these are product licenses that a customer needs to purchase and installed in the development environment, test environment, and the production environment. Although some of these products may be acquired from vendors that provide hosting services i.e. Infrastructure-as-a-Service or Platform-as-a-Service, the cost of engaging these services need to be defined since they have already included the cost of licensing in their service offering. There are potential threats that may involve these product licenses, therefore it is important to identify the cost of these product licenses especially those that are installed in the development environment, and test environment i.e. where the usage of these products falls within the life of the project. At the end of the project lifecycle, after full acceptance of the project outcomes, the risk management process ends, the project will transition to the production environment where the cost and maintenance of these product licenses are within the jurisdiction of the customer’s operation and maintenance. At the end of this workshop, through the “Define Product Licenses” process, additional functionality will be added into PRISM that helps to determine the cost of product licenses that has been purchased for the project.
9. Part 2 Month 9 Project Liabilities – Project delivered beyond the agreed schedule has been experienced by many businesses and customers especially for custom-built software development projects despite late penalties imposed to the IT vendor or supplier. The penalty charges could be a percentage of the contract amount or a fixed fee depending on the criticality of the deliverable to the business and the financial impact to the customer organization. This is one of the examples of contractual liabilities that an IT vendor has to provide for in their project budget. Another measurement of vendor’s performance is based on the delivery of the entire project as committed in the project scope of work. In this situation, the client usually requests for a performance bond as a form of assurance that the vendor will deliver the entire project as per the agreed scope, schedule, cost, and quality requirements. The sum of the performance bond shall be mutually agreed upon between the IT vendor and their client which will become the IT vendor’s financial liability. The process “Define Project Liabilities” that will be discussed in this workshop will reveal all the list of project liabilities in an IT project including software development project, IT infrastructure project, and cloud computing-based projects. At the end of this workshop, additional functionality will be added into PRISM that helps to determine the project liabilities that needs to be factored into an IT project.
10. Part 2 Month 10 Contingency Reserve – The contingency plan describes the procedures and processes that would allow the project team to continue to work should its present workplace become unusable or unavailable. What will be the budgeted amount of execution of this contingency plan? Which project objectives will be most likely affected as a result of this risk? Knowing this information will help a project manager to be more proactive in managing risk and also in controlling project cost. A contingency reserve is usually controlled and released within specific guidelines by the project manager when a particular risk occurs. The alternative plan can be initiated in the situation where risk mitigation plan has been exhausted. Although these types of plans are viewed as plans of last resort, they can be useful in a variety of ways. For example, should a production environment installation is delayed due to unforeseen circumstances, the project team shall allocate an alternate solution in order to allow the project to continue to run within the agreed implementation schedule. In another example, a project team could have a disaster recovery plan in place should a natural disaster, such as a hurricane or earthquake. A contingency reserve is usually included in the project’s budget that is parked under a dedicated project contingency reserve account. The contingency reserve is the budgeted cost of executing a contingency plan which is sometimes called an alternative plan. At the end of this workshop, via the “Define Contingency Reserve” process, additional functionality will be added into PRISM that helps to compute the sum of all contingencies that need to be allocated in the project, and also the breakdown of the contingency cost provided for labor, material, services, expenses, and product licenses.
11. Part 2 Month 11 Inflation Charge – Purchasing an item from a local distributor or a value-added reseller will not guarantee that the price of the item will remain fixed unless there was a clause in the sales order form that indicates that the price is fixed regardless of the currency fluctuations. Based on past project experiences, the supplier usually indicates in the terms and conditions of purchase that the pricing will be subject to the prevailing currency exchange rates and the final price inclusive of customs duty will be revealed when the goods have safely arrived into the country. This is mostly the case for imported material or equipment. As a buyer, the inflated cost of these goods or services due to fluctuations in foreign currency need to be accounted for in the project budget. This can be achieved by defining an accurate estimation of the foreign currency exchange rate. The rates for inflation charges need to be defined in cases where human resources are acquired from overseas. The resources are usually booked several months ahead of their required placement, however, the actual disbursement will only take place when they have reported for duty. The rates for inflation charges need to be allocated for IT equipment and software product licenses should these are purchased from international vendors. For instance, Oracle database licenses may be quoted in local currency since there is already a local distributor or a direct representative office based in that country that is authorized to transact in the local currency. Different companies apply different policies, products from other vendors may not work the same way as Oracle products. The project manager must be vigilant in the procurement process specifically for products or services from international suppliers. Project expenses too will be subject to inflation charge for staff traveling expenses that are incurred for jobs performed in a foreign country. At the end of this workshop, via “Define Inflation Charge” process, additional functionality will be added into PRISM that helps to determine the rates for inflation charges that need to be allocated for labor, material, services, expenses, and product licenses.
12. Part 2 Month 12 Risk Dashboard – The primary objective of developing a tool like PRISM is to allow for ease of use, and the flexibility in customizing the tool added with functional-rich features that can easily be understood by an average person with little background in project management. You do not need to have in-depth budgeting or project costing experience in order to understand to use or develop PRISM. The information captured by PRISM as a result of the processes executed from the respective workshops are processed and the calculated results are posted automatically onto the Cost-Risk Dashboard. The simplified and concise information makes project risk reporting quick and easy. The Cost-Risk Dashboard represents the comprehensive analysis of the risk situation of the project. The information presented includes details of the project budget that comprised of project prime cost (labor, material, services, expenses, and product licenses), liabilities, and contingency reserve. You may link this data with your executive support systems to provide alert reporting should the project expenditure exceed this value. Also included on this dashboard is the provisions for liabilities against the total project budget. Your project expenditure should not exceed the permitted liabilities else it will trigger an email alerting your project sponsor. By defining the sales price, PRISM will automatically display the profitability of the IT project, which is a common functional requirement of any bid managers and accountants. PRISM is not just a tool for risk managers or project managers, it is also a cost and risk modeling tool that assists pre-sales team and sales team in the bid management process. A cost-profitability analysis can be performed quite easily by updating the prime cost variables, including cost related to liabilities, and cost allocated to contingencies. Any changes you make that involved changes affecting labor, material, expenses, services, product licenses, liabilities, or contingencies will refresh the results of the dashboard automatically. In addition to the Cost-Risk Dashboard, a graphical representation of the project cost breakdown is available. The Cost-Risk Dashboard presentation format can be easily customized to accommodate each enterprise executive management needs. Any changes made to labor, material, services, expenses, and product licenses are updated to the Cost-Risk Dashboard interactively. A mobile application can be easily developed to download the Cost-Risk Dashboard data for online and real-time monitoring of risk performance for any of your IT projects, anywhere and at any time.

---

IT-Risk Management– Year 3

1. Part 3 Month 1 System Requirements – The purpose of System Requirements workshop is to obtain a thorough and detailed understanding of the business need as defined in project conceptual phase and captured in the project business case and to break it down into discrete requirements, which are then clearly defined, reviewed and agreed upon with the customer decision-makers. The project conceptual phase is not part of the system development life cycle, it is the phase where the project feasibility study was conducted which resulted in the production of the project business case. During system requirements phase, the framework for the application is developed, providing the foundation for all future design and development efforts. System requirements can be a challenging phase because all of the project stakeholders and their interests are brought into the process of determining requirements. The quality of the final product is highly dependent on the effectiveness of the requirements analysis process. Since the requirements form the basis for all future work on the project, from design and development to testing and implementation, it is of the utmost importance that the project team create a complete and accurate representation of all requirements that the software must accommodate. Accurately identified requirements result from effective communication and collaboration among all members of the project team, that provide the best chance of creating a system that fully satisfies the needs of the customer. Determining business requirements requires eliciting, analyzing, specifying, prioritizing, verifying and negotiating business functions that the system must deliver and support. During this process, it is important to have all of the stakeholders involved. Since this is the process in which all business and processing requirements are determined and agreed to, it is critical that all parties understand the ramifications of including or excluding requirements from project scope. Business requirements may include introducing new business processes into the enterprise or changes to existing business processes including constraints and potential risks associated with the implementation of these business processes. Changes to business requirements are quite common in large enterprise software projects, if not properly controlled will introduce colossal risk which resulted in project cost overrun and schedule slippage. This workshop will discuss the list of high priority risks during system requirements phase of a software development project and identify the risk response strategies and contingency plans to address these threats. The “Project Risk Identification” process defined in risk planning will produce a list of risks classified under “System Requirements Risk” which will later be used as input into PRISM for further evaluation.
2. Part 3 Month 2 System Design – The purpose of System Design is to create a technical solution that satisfies the functional requirements of the system. At this point in the project lifecycle, there should be a functional specification, written primarily in business terminology, containing a complete description of the operational needs of the various organizational entities that will use the new system. The challenge is to translate all of this information into technical specifications that accurately describe the design of the system, and that can be used as input to system development. The functional specification produced during system requirements is transformed into a physical architecture. System components are distributed across the physical architecture, usable interfaces are designed and prototyped, and technical specifications are created for the application Developers, enabling them to build and test the system. System design document that provides a technical solution to the functional requirements will address some of the risks that could be associated with the technology behind the proposed solution. There are risks associated with the proposed system architecture that could impact the development, testing, and commissioning of the software. To define the technical architecture of the new system, the project team must perform a thorough assessment of the organization’s existing infrastructure, standards, and information capabilities. Assuming that the technical platforms already in place can adequately support the new system, a design that leverages these existing platforms results in clear advantages in terms of increased productivity, decreased in costs, and reduced learning curves. There could be risk related to security in the development environment, using a different version of an operating system across development and testing environment, or instability of the testing environment that need to be addressed. Due to budget limitations or cost constraints, some client chose to engage external vendors that offer the computing resources during the development and testing phase, by doing so would relieve them of the huge cost of installing these devices not to mention the ongoing maintenance and risks. Although the risks are transferred to a third party via the Infrastructure-as-a-Service model or Platform-as-a-Service model, there are other risks that need to be addressed. This workshop will discuss the list of high priority risks during system design phase of a software development project and identify the risk response strategies and contingency plans to address these threats. The “Project Risk Identification” process defined in risk planning will produce a list of risks classified under “System Design Risk” which will later be used as input into PRISM for further evaluation.
3. Part 3 Month 3 System Construction – System construction often occurs at a point in the project schedule when the pressure of meeting deadlines increases. Shortcuts, whether intentional or not, may appear to provide attractive alternatives to meeting commitments. The need to adhere closely to defined procedures is even more important than ever before. It should begin in the early stages of system construction with the education of the team in the processes to be followed. The start of system construction marks a point in the project where the overall technical environment becomes more complex, more risky, and more critical than in prior phases. Due to the scope of activities required to construct and test an application, having access to applicable tools such as automated software development tools, software configuration management tools, testing tools, and defect tracking tools can be extremely valuable to support these development and testing efforts. Due to an increased dependence upon development tools, and the breadth and variety of technical environments that need to be established and supported, sufficient time must be taken at the start of this phase to make sure that these technical environments are correctly installed and configured. What will happen if they are not correctly configured? This marks the first phase in which it is necessary to install multiple, distinct technical environments to accommodate the various construction and unit testing efforts. In order for application developers to be able to code and perform unit testing for each module, they must have access to the Technical Specification associated with that module. Since it is likely that some of the developers may not have been involved in creating these specs, which present a risk itself, the business analyst should be available to answer questions dealing with the desired functionality and the customer’s intent behind the specs. Similarly, the technical lead should provide the technical background and expertise that the application developers may lack. There are a number of risks during system construction that should not be taken lightly, they are the development environment, development tools, development database, communication management, and many others that will impact the software development effort. This workshop will discuss the list of high priority risks during system construction phase of a software development project and to identify the risk response strategies and contingency plans to address these threats. The “Project Risk Identification” process defined in risk planning will produce a list of risks classified under “System Construction Risk” which will later be used as input into PRISM for further evaluation.
4. Part 3 Month 4 System Integration – The purpose of System Integration Testing (SIT) is to continually validate larger combinations of software modules until the entire system is operating correctly as a single unit. Having validated individual software components during system construction phase, it is now time to begin validating the interaction among these components. The sequence and manner in which these software modules are combined should be defined in detail in the system integration test plans that were built during System Design workshop. Where unit testing focused on the individual elements as decomposed in the Technical Specifications, integration testing now needs to “roll up” the elements into logical groupings and sub-systems as identified in the Functional Specification. Much of system construction involves an iterative set of processes where the results of one activity may seed efforts in related activities. Results of system integration testing may identify components of the system with defects that require re-execution of the system development and unit testing process; and once software modules have been modified and retested at the unit level, regression testing of the modules and any subsystems to which they pertain will again be required. This workshop will discuss the list of high priority risks during the system integration testing phase of a software development project and to identify the risk response strategies and contingency plans to address these threats. This workshop will discuss the potential list of high priority risks during the system integration testing phase of a software development project and to identify the risk response strategies and contingency plans to address these threats. The “Project Risk Identification” process defined in risk planning will produce a list of risks classified under “System Integration Risk” which will later be used as input into PRISM for further evaluation.
5. Part 3 Month 5 System Acceptance – System Acceptance is the point in the lifecycle at which every aspect of the application being developed, along with any supporting data conversion routines and system utilities, is thoroughly validated by the customer representatives prior to proceeding with system implementation. This entire phase is focused on gaining sufficient evidence of the application software accuracy and functionality to be able to proceed to system implementation with the highest level of confidence possible in the success of the system. This phase differs from system construction in that acceptance testing is the final opportunity to establish that the system performs as expected in an environment that mimics production environment as closely as possible. The customer now needs to exercise the system in the same way that they will once the full system is implemented. With the user acceptance testing roadmap established in earlier project lifecycle phases, the customer now takes responsibility for implementing the system through its operations. One of the risky project activity to be observed in the preparation of User Acceptance Testing (UAT) environment is to ensure that the testing environment to be used during System Acceptance is ready and operational, and to take any steps needed to prepare the acceptance testing team to successfully achieve their testing goals. The project schedule will be affected should the preparation of this UAT environment is delayed. In addition to confirming the operation of the system and its conformance to the business needs that it is intended to satisfy, System Acceptance is also the point in the lifecycle during which all supporting documentation and reference materials are updated to ensure their consistency with the final delivered system. This workshop will discuss the list of high priority risks during system acceptance phase and to identify the risk response strategies and contingency plans to address these threats. The “Project Risk Identification” process defined in risk planning will produce a list of risks classified under “System Acceptance Risk” which will later be used as input into PRISM for further evaluation.
6. Part 3 Month 6 System Implementation – During System Design, the Project Manager formulated and documented 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. During System Construction, this Implementation and Transition Plan (ITP) will be more fully developed as the product of the project is developed, and as specific activities in the project management plan are executed. During System Construction, the project team will gain a better understanding of the impact the resulting product will have on the customer and the end users. The Implementation and Transition Plan include activities that are required to prepare the end users to use the product, along with the tasks to prepare the customer to support the product after the transition period. Implementation and Transition Plan involve managing the steps that need to be taken to ensure end users will be ready to use the product once it is implemented. These steps must be coordinated with the organizational change management plan and will include training and orientation on the use of the product. Any training for customers or end users must be provided according to the plan and coordinated with other aspects of the implementation of the product. It is critical to ensure that the end users and customer are equipped with the knowledge required to use and support the product or services, otherwise the transition management process will be a disaster. The purpose of transition management is to formally acknowledge that all deliverables produced during System Acceptance have been completed, tested, accepted, and approved by the project’s customers and the project sponsor and that the product or service the project developed was successfully transitioned from the project team to the customer. Formal acceptance and approval also signify that the project is essentially over, and is ready for system implementation. There are a number of high-risk activities during the system implementation that will be discussed in this workshop. The “Project Risk Identification” process defined in risk planning will produce a list of risks classified under “System Implementation Risk” which will later be used as input into PRISM for further evaluation.
7. Part 3 Month 7 Scope Management – A project scope is a description of the work required to deliver the product of a project. The project scope defines what work will, and will not, be included in the project work. A project scope guides the project manager on decisions to add, change, or remove the work of the project. The project scope defines all of the required work, and only the required work, to complete the project. Scope management is the process of ensuring that the project work is within the scope and protecting the project from scope creep. Scope creep refers to increasing feature or additional functionality that is not included in the original Project Scope but the additional functionality is very important to the Customer, adding small yet time and resource-consuming features to the system once the scope of the project has been approved. The Project Scope Statement is the baseline for all future project decisions, as it justifies the business need of the project. Control Scope is a process that concerned with ensuring that any changes to the project scope will be managed through the change control process and to verify that the output from the project meets the requirements defined in the Project Scope Statement. A scope change procedure will be in place before the actual work on the project commences. It can be part of or at least referenced in, the project charter so that it is communicated to all project stakeholders. This procedure should allow for the identification and handling of all requested changes to the project’s scope. Scope change requests can be made, and each request’s impact on the project can be assessed. Then, a decision whether to accept or reject the scope change can be made. If the scope change request is accepted, a mitigation plan or a contingency plan needs to be defined should the scope changes impact the project budget and the project schedule. The process “Identify Scope Changes”, in association with “Project Risk Identification” process discussed in Risk Identification workshop, will ensure that any changes to project scope or product scope are registered in PRISM for further assessment of its impact to project schedule, project budget, and project quality requirements.
8. Part 3 Month 8 Issues Management – Risk, if not managed, will become issues, however, not all issues are derived from the Risk Register. For example, when a particular project work package is lacking the required resources, it is classified as a project issue that needs to be addressed immediately. It is not identified as a risk because it is mandatory to ensure adequate resources are assigned to all project activities. It is classified as a risk in a situation where the resources are complete but they may lack the skills necessary to perform the job. The probability of the project not meeting its expected schedule is definitely going to happen if this work package is delayed. Management of project issues focuses on monitoring, reviewing and addressing issues or concerns as they arise through the life of a project. Issues can be raised by anyone involved with the project, including the business owners, steering committee members, reference or working group members, the project manager, project team members and other key stakeholders. For small projects, a brief scan and ongoing monitoring may be all that is required. In large and/or more complex projects, it is advisable to maintain a Project Issues Register. From this register, the issue, current status, and resolution, where appropriate, should be reported regularly to the steering committee as part of the project status report. A Project Issues Register should be established as part of the ongoing risk management activities. The project manager and team need to have a process for capturing issues as they arise, updating and reviewing them so that they can be managed and resolved as the project moves forward. Once a resolution is agreed on, the appropriate activities are added to the project work plan to ensure the issue is resolved, and to the project budget if appropriate. If the project is medium to large or quite complex, separate Project Issues Register might be established for each of the major outputs as they are being developed. Small projects also will benefit from the establishment of a Project Issues Register, as it is low maintenance and high value in terms of keeping the project on track and managing the issues. The process “Identify Project Issues” will ensure that project issues are registered in Project Issues Register for a closer tracking and control. In the example introduced earlier in this section, the issue raised for not having sufficient resources may be posted into the project Risk Register and to be classified as a risk for not having the required skilled resources.
9. Part 3 Month 9 Transition Management – Transition Management process is to formally acknowledge that all deliverables produced during System Acceptance have been completed, tested, accepted, and approved by the project’s customers and the project sponsor and that the product or service the project developed was successfully transitioned from the project team to the customer. The project team will be guided by the project Transition Plan developed earlier during the planning phase. During System Design, the project manager formulated and documented 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. During System Construction, this Transition Plan will be more fully developed as the product of the project is developed, and as specific activities in the Project Management Plan are executed. During System Construction, the project team gains a better understanding of the impact the resulting product or services will have to the customer and consumers of the finished product or services. Activities that are required to prepare the consumers to use the product, along with the tasks to prepare the customer to support it. Managing implementation and transition includes monitoring and ensuring timely completion of all facilities issues, such as acquiring the necessary physical space, installing appropriate software and obtaining the appropriate building permits for cases where a new data center is constructed. Coordinating customer acceptance testing, including logistics of when and how customers will test the product to confirm that it meets requirements before it is formally implemented and transitioned. Customer testing is one of the last opportunities for necessary changes to be identified and made to the product before rollout. Time for sufficient customer testing and any resulting rework that will affect the project team must be incorporated into the project schedule. Managing the steps that need to be taken to ensure consumers will be ready to use the product once it is implemented. These steps must be coordinated with the Organizational Change Management Plan and will include training and orientation on the use of the product or services.
10. Part 3 Month 10 Communications Management – Since stakeholders can have a significant impact on decisions made, it is important that their perceptions of risk be identified and documented, with the underlying reasons for the perceptions understood and documented. Communication and consultation with all key stakeholders should be an ongoing process and not just part of the initial risk identification and analysis process. This process can be tied in with the overall communication strategy for the project and need not be a separate activity. Information technology projects historically have demonstrated a poor track record for a variety of reasons. Often unrealistic Risk Management plans are created from inaccurate estimates, and, as a result, projects have little chance of achieving their objectives. Although various tools and techniques for estimating IT projects exist but consistently developing accurate and realistic estimates remain a challenge. Much of an organization’s capability to consistently and accurately estimate IT projects lies with well-defined processes, experience, and an information base of past projects. Still, developing a realistic and effective Risk Management plan is only part of the solution. Formalized regular reporting on the status of the project is an integral part of the quality management of the project. In order to make appropriate decisions, the steering committee, project sponsor or senior manager needs to be informed properly about the risk status of the project. The project manager should establish this reporting as part of the management activities for the project. In this workshop, you will learn about developing effective communications plan to better track, monitor, and report the project’s progress. Communications management is important in ensuring project team, project sponsor, and all project stakeholders are involved in the risk management processes and the decisions made related to the contingencies and mitigation plan. After completion of this workshop, you should understand and be able to identify the processes associated with project communications management, which includes project communications planning, information distribution, and risk reporting.
11. Part 3 Month 11 Executive Reporting – Risk management process sits across the four pillars of project objectives which are cost, scope, schedule, and quality. In order to make appropriate decisions, the steering committee, project sponsor or senior manager needs to be informed properly about the status of the risks in the project. The project manager should establish risk management reporting as a primary component of the communication management activities for the project. The purpose of the Risk Management Report is to indicate any changes to the major risks identified since the previous report, and modification to the strategies put in place to manage them including any new risks that have arisen since the last report. Risk monitoring and control is a continuous activity throughout the life of the project. We have discussed in previous workshops regarding the integration of risk management processes with the respective phases of the system development life cycle. The risk monitoring cycle starts from system development phase until the product of the project has been transitioned completely to the customer in the final milestones of the system implementation phase. It is important to keep the risk management report focused, and to report against the risk exposure limit defined in PRISM Risk-Profile section. The total budgeted risk represent the maximum cost related to risk mitigation and contingencies that the project can sustain, while the total budgeted liabilities represent the maximum compensation and damages the project can afford to pay. Some of the questions raised by project sponsor are: What are the expenses that have been incurred for risk management effort and involving which project work packages? Is the currently available budget for contingency-related effort sufficient to keep the project going until completion? What are the remaining risks that the project team needs to be aware of, and how are their preparations in handling these threats? If the project team failed to manage either risks or liabilities, it could be a danger sign that the project will not be completed within the specified budget. In this workshop, we shall develop the Risk Management Report that will provide a comprehensive reporting of the ongoing risk status of the project, which becomes very useful in terms of tracking progress, evaluation, and review. You will be able to apply the concept of how the expected monetary value provides a means of tracking and monitoring contingencies. Risk Management Report form part of the project review processes, both during and after completion of the project.
12. Part 3 Month 12 Implementation Review – A project is considered complete when it has been successfully implemented and transitioned to the customer and approved by the project sponsor. At this point in the project management lifecycle, the responsibilities of the project manager are to assess how closely the risk management processes met customer needs, highlight what worked well, learn from mistakes made during the project, identify patterns and trends, derive ways to improve upon processes executed throughout the project, and, most importantly, communicate results. The purpose of conducting project risk implementation review is to assess the result of the implementation of risk management processes on your IT project. The positive outcomes of the assessment should include meeting the goals of the project budgeted expenses particularly cost of managing project risks, cost of managing liabilities, and cost of managing project contingencies. The most important measures of the success of a project are whether the product was developed and delivered successfully and how well the needs of the customers have been met. The most effective way to determine these measures is to solicit feedback. That is well and good based on the perspective of the project outcome. What about the expectations from the executive management that are constantly looking for methods to reduce cost, eliminate wastage, and maximize profits? They will be interested to know how much has been spent and which department manage to keep their expenses within the allocated budget. A positive financial outlook meeting the targeted margins after project closure is a strong indication that the IT project risk management framework and the implementation of the risk management processes are working successfully. A Risk Evaluation Review Report will be prepared for submission to the executive management that highlight the budgeted expenses against actual risk expenses. The report will include the critical success factors of a successful risk management program, which include reliance on senior management’s commitment; the full support and participation of the IT team; the competence of the risk assessment team, which must have the expertise to apply the risk assessment methodology to a specific site and system, identify mission risks, and provide cost-effective safeguards that meet the needs of the organization; the awareness and cooperation of members of the user community, who must follow procedures and comply with the implemented controls to safeguard the mission of their organization; and an ongoing evaluation and assessment of the IT-related mission risks.

---

Methodology

IT-Risk Management– Program Planning

Developing the IT Project Risk Management Plan is the primary output of the Risk Planning phase. A formal IT Risk Management Plan is a detailed plan of action which involved a number of business processes that will be used for the identification, execution, monitoring, and control of risk in an IT project. What are these business processes, how will they be used, and when will you apply these business processes in IT project? Who will be using these processes and is there any controlling mechanism or organization that will be governing the use of these processes? Are these business processes generic or are they customized specifically to focus on risk in IT project? Identifying and understanding the risks that will impact an IT project is not always a straightforward task. Many risks can affect an IT project in different ways and during different phases of the project lifecycle. Therefore, the process and techniques used to identify and manage risks must be tailored to each specific industry so that the real value can be achieved with the result meeting with the corporate project objectives. There are a number of processes that need to be executed In order to develop the IT Project Risk Management Plan. The first step is to establish the IT project risk management framework that includes the definition of the measurable organizational value of the enterprise i.e. the key performance targets that the IT project need to achieve. For example, one of the targets is to deliver the IT project within the allocated budget, while target set by other organization could be to ensure risk exposure does not exceed a certain percentage of the project budget. The next step in this methodology is to establish the risk management committee that represents the governance structure to oversee the implementation of the risk management processes. The risk management processes include the processes to identify risk, to evaluate and prioritize risk, to respond to a specific risk, and to track and control risk throughout the project lifecycle. Identifying risk for an IT project requires a comprehensive examination of the customer’s computing environment that plays a significant role in the risk assessment process later. The IT project risk management framework is not complete without a detail examination of the potential threats associated with the project transition activities. We have included a thorough review of the Project Transition Plan to ensure there is no major threat while preparing the users to take over the operation and maintenance of the finished product or services. One of the methods to achieve a smooth transition is to ensure that adequate training has been provided to the customer end users. We foresee some degree of risk during this process, hence a review of the Organizational Change Management Plan is included as one of the important element of the IT Project Risk Management framework. All these will be included in the development of the IT Project Risk Management Plan.

---

IT-Risk Management– Program Development

Developing a cost and risk modeling tool is the main objective of the Risk Development phase. After the establishment of the risk management processes during risk planning phase, they need to be tested so that the processes defined earlier can be verified during Risk Implementation phase. The best method to achieve this is to develop a tool that can integrate with the risk management processes. Past experiences revealed that there is no one tool that can fit all types of project. The risk development phase of this training program will guide you through a step-by-step process of developing this tool to ensure that participants will learn the importance of the various functions of this tool and how these functionalities will be used in association with the risk management processes that you have learned earlier. Project Risk for Information Systems Management (PRISM) is a cost and risk modeling tool that will be developed during the risk development phase of this training program. This tool that will facilitate the application of the risk management processes so that the output from these processes can be captured and stored in digital form and makes it accessible to project stakeholders. PRISM benefits the team by allowing the data to be processed for analysis, budgeting, reporting, and decision-making. Why is PRISM important in this training program? It is primarily because project cost management is traditionally a weak area of IT projects for most project managers. We have come across many IT projects failed to meet the targeted project objectives because of failure to control cost. 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 a project. It is difficult to manage risks in a project if you do not know its cost implications to the project objectives. Tools, processes, technology and the people who are sufficiently trained to use them will certainly make PRISM the important tool for the execution of the project risk management processes during risk implementation.

---

IT-Risk Management– Program Implementation

The primary objective of the Risk Implementation phase is to apply the risk management processes which have been identified during Risk Planning across the respective phases of a system development life cycle (SDLC), these include system requirements, system design, system development, system testing, system acceptance, and system implementation. PRISM tool will be involved throughout the implementation of the processes to register the outcome or the result of the processes for executive reporting and project-profitability analysis. For instance, the project team may choose to apply the brainstorming technique in order to identify risk associated with system development since the project team is familiar with this technique after they have learned this method in the risk identification workshop. The team could use the IT risk management framework and the project work breakdown structure WBS to identify risks (i.e., threats and opportunities) starting with the phases of the project lifecycle and working towards the framework’s core or the measurable organizational value. For example, the team discovered that there is a high possibility of a delay in setting up the development environment and the brainstorming session provided a number of risks that will affect the development work as a result of this delay. By applying the Qualitative Risk Analysis process, the risk which scored the highest rank based on its impact to project objectives were selected, so this risk was classified under “System Development Risk”. In this scenario, the project team registered this risk into PRISM to determine the mitigation cost, contingency cost, and other liabilities that may be incurred as a result of this risk. SDLC is a subset of the project management lifecycle, it imperative to include other project management processes that are involved in risk management. Project Scope management deals with risk related to the scope of the project and scope of the product. Project Issues management are important for the project team to be proactive on issues that originated from Risk Register. Project Transition management is to assist in overseeing risks that may arise while shifting the responsibilities for the operations and future maintenance of the product to the customer. Project Communications management is required to ensure that all project stakeholders are being kept informed of the risk management status via the Risk Management Report that will be produced monthly.

---

IT-Risk Management– Program Review

The purpose of conducting project risk implementation review is to assess the result of the risk management processes that have been used during the respective stages of the system development lifecycle. The positive outcomes of the assessment should include meeting the goals of the project budgeted expenses particularly cost of managing project risks, cost of managing liabilities, and cost of managing project contingencies. The most important measurement is whether the product was developed and delivered successfully and how well the needs of the customers have been met. The most effective way to determine these measures is to solicit feedback. That is well and good based on the perspective of the project outcome and customer’s expectations. What about the expectations from the executive management that are constantly looking for methods to reduce cost, eliminate wastage, and maximize profits? The executive management will be interested to know how much has been spent on the project and which part of the project organization manage to keep their expenses within the allocated budget. A positive financial outlook meeting the targeted margins after project closure is a strong indication that the IT project risk management framework and the implementation of the risk management processes are working successfully. By comparing the results represented in PRISM “Risk Dashboard” against the budgeted accounts, the financial performance can be easily measured. A Risk Evaluation Review Report will be prepared for submission to the executive management that highlight the budgeted expenses against actual risk expenses. The report will include the critical success factors of a successful risk management program, which include reliance on senior management’s commitment; the full support and participation of the IT team; the competence of the risk assessment team, which must have the expertise to apply the risk assessment methodology to a specific site and system, identify mission risks, and provide cost-effective safeguards that meet the needs of the organization; the awareness and cooperation of members of the user community, who must follow procedures and comply with the implemented controls to safeguard the mission of their organization; and an ongoing evaluation and assessment of the IT-related mission risks.

---

Industries

This service is primarily available to the following industry sectors:

Banking & Financial Services

A traditional bank provides the opportunity to develop a personal relationship with that bank. Getting to know the people at your local branch can be an advantage when you need a loan or a special service that is not normally offered to the public. A bank manager usually has some discretion in changing the terms of your account if your personal circumstances change. They can help you solve problems such as reversing an undeserved fee or service charge. Your banker will also get to know you and your unique needs. If you have a business account, this personal relationship may help if you need capital to expand. It’s easier to get the bank’s support if there is someone who understands your business and can vouch for your operating plan. Back then, the traditional bank has a number of banking applications like deposit system, mortgage, hire purchase loans, and others to serve the needs of their customers. There were other wholesale banking applications to cater for the needs of their corporate businesses. During the 1990s, banks were only concerned with the functionalities of the application. Since control processes were already embedded into the applications and the security access was within the control of their personnel, there were less concerned about risk. Risk management for IT projects was not being given special priority as compared to the bank enterprise risk management which focuses on the bank’s exposure on its portfolio of products and services. It was not a surprise to read about the vast number of IT projects that failed to complete within budget and schedule.

Times have changed since the 21st century. The number of IT projects that failed to complete within budget and schedule still remains high although the number has declined marginally. A recent study detailed that the financial services industry spends the most on information technology than any other industry. Last year, this amounted to an estimated $500 billion across the globe. As a result, customers did not have to be tied to a certain bank to make deposits or withdrawals. Online banking is one of the many examples of how technology spending has helped push banking and financial services forward. Market coverage is important in this type of industry, as it allows fixed costs to be spread over a larger number of locations and customers. Again, money center banks have many advantages over regional