NEED HELP WITH PROJECT RISK MANAGEMENT

Table of Contents Project Outline. ……………………………………………………………………..…………………………………………… 3 Risk Management Justification……………………………………………………………………………………….…….…5 Project Risks Identification……………………………..……………………….……………………………………….…….7 Project Risks Assessment…………….…………………………………………………………….………………………….12 Project Risks Response Strategy…………………………………………………………………………………………... 15 Project Risks Responsibility Plan..…………………………….………..………………………………………………….19 Project Risks Monitoring &Control Plan………….…………………………………….………………………………..20 Project Risks WBS & Budget Updates……………………………………………………………………………………21 Project Risks Communication Plan…………………………………………………………………………………………22 References…………………………………………………………………………………………………………………………….20

Project Outline

The institution that I will be focusing my individual project on is that of the Scotia Bank Institution. Scotia Bank is a world-renowned banking institution founded over fifty years ago. The company whose headquarters are in California has many divisions of business, the most profitable being banking, insurance and stocks. The company features over one hundred and seventy branches that are all connected to one platform and database. The institution has sought to give their clients some degree of unlimited access focusing on alternate means of updating and accessing multiple accounts at once regardless of location.

The information technology department of the scotia bank group has recently launched the development of a mobile application that will increase client relations through the use of improved mediums and levels of access for everyday business transactions. It has come to the attention of the business segment of the. The board of directors that the level of productivity within the organization is rapidly depreciating and as such reevaluation of both software and employee

Personnel have been put in place to identify the reason, risk and solution for the dip in productivity following the implementation of the latest software tactic.

The department of information technology software and development protocols currently uses an agile methodological approach in developing all software. The pros and cons of this approach have long been preferred based on the ever-changing needs of the company. However stakeholders involved would prefer a complete overview of this approach to determine the degree of success or possible need for change as such the a project manager has been selected to provide through detailing on the process of evaluating human and software elements affecting the cooperation as it regards to production.

The company has one branch in every state of the United States as well as twenty branches in the Caribbean and the remaining branches are located in Europe and Asia. The branches hold a little over three hundred employees total with an Information technology of two per branch .The information technology department is focused on developing software and maintaining existing software needed for the day to day processing and activities of the bank. The department places strong emphasis on the security of client data and innovative methods of improving the quality of service within each establishment. Currently the company has just completed the development of the mobile app and has incorporated its use accessing the main database of the company. While implementing further measure in attempt to improve the application, the information technology department is now seeking to expand the application to include the access to view existing stocks and purchase available stocks.

The purpose of this document is to go in to detail assessing the varied risks and how they will affect the overall productivity of the software .Not only will the project go into detail regarding the different risks that can and will affect the production of the company, but also the implications whether positive or negative must be document and solutions prepared in the event of such an occurrence to ensure continuance of business. .

Risk Management Justification

A project risk is defined in the book “A guide to the project management body of knowledge: as an uncertain event or condition, that if it occurs has a positive or negative impact on numerous project objectives such as scope schedule cost and quality. When considering the amount of time and resources that have me been put towards a project it would be fool hardy not consider the different risks that may face the project at every stage. Risk Management is one additionally and important step necessary to ensure that even in the event of unforeseen difficulties and changes to the master plan, the project must still be able to run successfully and there must always be an adequate and efficient back up plan. A risk can occur from a range of different reasons and as such can be impacting in more than one area. Risk management therefore is the process by which risks are identified, analyzed and resolved in order to keep the project running successfully. Project risks must be taken seriously as they have the potential to fail a project however the effective manipulation of risks can make all the difference in a project. Identification of risks is just one major aspect of risk management, as identifying alone will not solve the problem, rather steps must be taken to find means of resolving the risks in such a manner that even if they do occur they will have little or more positive impact on the project as possible.

Risk Management helps the project management team to avoid major project pitfalls by acting as looking glass as it were and identifying risks that may or may not direct the project in a direct way. It also fuels proactive development as opposed to reactive damage control. Planning for a crisis before one occurs allows for open minded clear thought processing rather than trying to resolve a present crisis. Risk Management fuels objective cohesive and comprehensive planning in order to combat unforeseen and foreseen risks that may occur.

Risk Management takes place at every aspect of the project management process during initialization when the project is just being defined and it is necessary to define the scope of the project, risk management is utilized that the pros are more than the cons in the project. This is a critical stage in the risk management process as it is important to thoroughly identify if the project being taken into consideration will be worth time and resources, if it will be effective and if there are too much unresolved risks present that will jeopardize the success ratio of the project. In this phase risks are evaluated and the design of the project if approved takes into consideration major risks to avoid ensuring that the project does what is desired. The project manager, team and sponsors are key in identifying the different risks that will affect the project during the development of the project. Remembering that a risk can be something deemed as minute as the schedule to something as critical as the budget, risks will have impacts no matter how inconsequential they are viewed. During the project planning phase, when the project is being explained and a schedule and budget are agreed upon risk management once again comes into place to ensure that the plans made for the project are adequate, while evaluating the decisions made to determine the likelihood of a risk being face. Throughout the execution and control phase these same risk management plans are continuously updated, reviewed and if needs be executed. Include a risk management plan in any software development plan increases the sturdiness of the plan, reduces the amount of loopholes for error and significantly improves the efficiency of the plan. A diagrammatic representation of the risk management process is shown below.

Project Risk Identification

According to the MITRE corporation risk identification is the critical first step of the risk management process, the main objective therefore of the risk identification process is the early and continuous identifying of events that may occur and pose a threat to the overall success of the project Risks as the term would suggest are negative in perspective. Negative referring to an event that would cause some degree of fiscal loss indirectly or directly. Most individuals don’t see the sense of risk identification or analysis, however the famous saying prevention is better than cure applies to the development plan as well .It is better to identify potential problematic issues than to search to find a solution after the fact. Risk identifications offers potential positive outcomes by exploring tentative negative ones.

. Risk identification is just one aspect of the problem. The next phase of the project is to mitigate these risks. The ability of the development team to look at these issues and risks and ensure that the qualified personnel are given the job so as to ensure that they best possible job is done with a degree of accuracy that will cover potential risks and increase efficiency.

It is important to note that individual project risks are different from overall project risks. An overall project risks represents the varying uncertainty that faces the project as a whole. It acts as a sum of the individual project risks within the project .The overall project risks takes into consideration, issues that may be considered risks to stakeholders and project managers alike and takes into consideration implications of outcomes both positive and negative.

Organizations perceive risks as the effect of uncertainty within a project now these risks can or may be accepted based on the degree of implications that they may pose to the overall project.

The risk identification process starts with the project team gathering the project's risk events. The identification process wills may differ from scenario to scenario depending on the nature of the project and the degree of capability of the team members, but most identification processes begin with an examination of issues and concerns created by the project development team. These issues and concerns can come from an analyzing the project description, work breakdown structure, cost estimate, design and construction schedule, procurement plan, or general risk checklists. By creating a database of recurring risks the risk management team can seek to organize a method or noting and solving recurring issues faced throughout the project as well as getting a head start on how best to deal with complex situations. The best way to create a database that is detailed enough to identify the basis of the most recurring of risks, this is done by reducing each risk into a basic detail that permits the person evaluating to understand the significance of any risk and identify its causes, that is the varying risk drivers This is an effective way of addressing the large and varying numbers of potential risks that often occur throughout design and software development projects.

After the risks are identified, they should be classified into groups of like risks. Classification of risks helps reduce redundancy and provides for easier management of the risks in later phases of the risk analysis process. Classifying risks also provides for the creation of risk checklists, risk registers, and databases for future projects.

There are a few notable risks that have been identified within this project the first of which has to do with the requirements phase. Not having access to all the requirements can prove to be a challenge for the development team, as a new requirement may change the dimension, direction of focus of an existing software development plan. Failure to have an accurate requirements list results in inflated budget, inaccurate timelines and schedules, missing deliverables for the final project. Requirements are designed or decided on by the various stakeholders within the project .It is therefore the responsibility of the stakeholders to ensure that they primarily have a good understanding of what they want from the project in order to relay that information to their project team in such a way that their interpretation fits the requirement. In order to mitigate the effect of this risk at each phase the requirements listing must be reevaluated with the stakeholders, in an attempt to verify any existing requirement as well as to re-evaluate and ensure that the plan is going in the right direction and that everyone understand what is needed as a deliverable from the project. With each progressive phase there are multiple risks that will present themselves. Similarly so, in the methodology phase the agile methodology relies on frequent communication through the right channels to ensure that everyone is processing information in the right manner. Communication is a very big aspect of this methodology, and is imperative that the programmers know how to communicate effectively so as to ensure that the correct information is passed and not misinterpreted and that the people that have been chosen for the job are quite capable of handling the requirements in such a way that they can actively provide high class type of work and ensure that the quality of the task is beyond expectations.

The design phase also has a multiplicity of risks associated with the architectural design of the software project, the performance associated with the design structure and ensuring that the testing whether it be black or white box testing capture most if not all the errors that may occur in the development and integration phases. Having poor specifications such as not adequately defining the software architecture, performance requirements and constraints will create numerous flaws in the design structure of the document. Project design specifications are well documented and defined in the SDS document. The development team needs to ensure that the criteria, such as the architecture, constraints, requirements and performance, and so on are documented correctly in order to conserve time, effort, and costs for the project. Risks such as these can be mitigated through the use of careful planning

Risk identification is critical to the overall success of the project. It is important to ensure that each identified factor that can be considered a risk is brought to light and dealt with. Having capable individuals working on the assignment increases the ratio for success by improving on efficiency and responsibility in helping identify additional factors that could increase risk. Preparing for the worst increases chances of success. The table below highlights the different risk identification tools and techniques that can be used within this process

Table 1: Risk identification tools and techniques

The risk identification process seeks to find and categorize risks that may affect the project. By documenting theses risks, they can be best handled by divisional focused where groups are segmented to target a risk factor. This is a continual process and must be continuously updated in an attempt to keep the database of risks accurate and complete. As long as new risks are always being incorporated into the process, the database and thus the back up plans for risk identified will be useful and up to date when the time comes for the incorporation of such methods.

Project Risk Assessment

Both the impact and likelihood of risks are calculated from 1-10 with ten being the highest and one being the lowest. The risks with the highest impact would be those with a high likelihood and impact for example. In order to determine the severity of the risk the likelihood and possibility of impact are multiplied by each other. This way the project team can gage just how serious a risk is to be taken. The project team will all have an active role in the identification and analysis of the risks highlighted in the table above. Through the means of questionnaires, and cause and effect diagrams as well as interviews and analysis. The members of the project team can take part in providing solutions to some of the risks that are likely to be faced. The first risks in the table are described as schedule flaws and this has to do with activities being completed in timeframe that is contradictory to their dependence. An example of this is if a particular task is dependent on a nether task but the deadline for the dependent task is before that of the first task that is a schedule flaw, which will lead to delays and errors in the development strategy. Another very popular error that is faced in the development of software is poor productivity; this risk actually goes hand in hand with the risk of employee turnover rate. If there is a high turnover rate, the employees will not have a good chance to learn the products and the individuals in the software development process will not be equip to adequately perform the tasks needed. In addition if there are a lot of employees leaving that means that there will not be enough hands on deck to get the work done. Fewer individuals to do the same amount of work increases the pressure on the remaining levels leading to a drop in the quality of work because it lacks the proper resource it needs to be done properly and in addition to that the productivity level declines rapidly because even after hiring to replenish the human resource additional time and resource has to be applied to train the newer individuals and arm them with the right tools needed to be successful in the work environment.

Requirement inflation is another major risk that can be faced within the project .To fully understand how requirements inflation affects the project one must consider the resources available. Resources allocated are based on the amount and extents of the requirements of the project deliverables. Each time additional requirements are added to a project already in development, the result is the project members need to utilize more resources, time and effort to review completed phases to see how the new requirement will affect the existing software as well as reevaluating risks, direction and scope. Similarly so is the specification risk associated with the breakdown of the project, just as it is important to properly identify the scope to determine which direction the project is going towards. In order to properly assess the direction and progress of the project the specifications need to be properly broken down and discussed to ensure that communication and direction is clear and understood by all parties. If this is not done then there will be confusion as it regards to what is expected and what is priority in the development of the project then the project can easily fall off track and be developed while missing key milestones.

Even after the project has been developed there are still risks that can be faced throughout the project .In the testing phase of the project it is critical that all aspects of the project be tested to ensure thorough evaluation and responses are obtained. Failure to do this in the right stage of the project will lead to additional costs and expenditure, delayed timing in terms of the implementation of the system into the working environment.

Budgeting issues and insufficient resources are continuous risks that are faced from the onset of the project throughout the very and both are correlated to the other with the same degree of impact and likelihood. Having too little resources will result increase expenditure and delays. Once there is not enough resources for the project then the budget becomes inaccurate and so has to be revised to take into consideration the lack or need thereof or additional resources. Typically the coders and testers of the project team are responsible for identifying risks related to the development of the code itself such as requirements inflation, and testing failures, while the stakeholders are responsible for the fiscal and budgeting management of the project .It is up to the project manager to oversee all these areas and ensure that all timelines and deadlines are met as well.

Below is an example of the diagrammatic tool that will be used to identify the various risks within the project. Note that it evaluates the environment, materials processes and people that may have a cause or effect on identified risks.

(1) Impact is low Likelihood is low

(2) Impact is low Likelihood is High

(4) Impact is high Likelihood is high

(3) Impact is high Likelihood is low

Project Risk Response Strategy

Each risk has to be handled in a particular fashion too ensure that the best possible response is garnered from a situation. Generally there are four different options one will have when it comes to handling a risk. The first option is to avoid the risk altogether, this is usually advised in a situation with a high impact ratio as well as a high degree of likelihood. To avoid a risk would mean that the threat it poses is to great to even try to mitigate. The next option is a step down from avoiding a risk totally and that is to mitigate the effect, Mitigating is the form of action taken when avoiding is not a choice and is usually the approach taken regarding risks of a medium severity. Another option that is sometimes used within the scope of risks and their handling is the transference of risks. This option is trickier and cannot be used in all situations as sometimes the risk genuinely cannot be transferred and so it is dependent on the situation and the options available. The last available option is to accept the risk, usually this is the unfamiliar option as accepting a risk means no alternate course of alternate action will be taken to avoid or mitigate the risk.

For he purpose of this project, different approaches have been taken towards the identified risks .The first risk is that of scheduling flaws, which has a severity flaw of medium. The decision was taken by the project team that this is a risk that should be avoided all together as not only was it preventable but the likelihood of occurrence would be based on neglect and carelessness on the part of the preparer. In order to ensure this risk is avoided all together the schedule should be prepared and reviewed at every phase of the project and just to ensure that there are no preventable errors in the scheduling a timetable that highlight dependent activities and their due date and processing times should also be printed and discussed with the project team. It has been advised that two days be allowed at the end of every activity just in case that particular task goes over schedule so as to prevent clashes and inter dependencies that will result in scheduling flaws. Overall however this is a risk that can be avoided.

The next risk in question is that of requirements inflation which is tricky in that in any project there is a likelihood of an increase in the requirements of the project however, there has to be some level at which the line is drawn to prevent the project from going over budget, over time and utilizing more resources that is available. A risk such as this can be transferred, to expound on this one must take into consideration that software for example have multiple releases and updates and developers seek to improve on past versions of perfection. If a requirement is not absolutely critical to the existing design infrastructure it must be evaluated to see if it can be accommodated or must be transferred to the design team for future releases of the project. In this way the risk of requirement inflation getting way above what can be done in a give time frame and existing budget.

Employee turnover is an issue that plagues every administration of every company. The rate of turnover of employees affects the level of productivity as well, so it is crucial that the employee turnover rate be as low as possible. The best way to handle this risk is avoid it completely and the best way to do this would be to put the critical assets of the human resource, that is individuals who are hands on and instrumental to the design and coding of the project on a contract, that will pay sixty percent up front and forty percent when the job is completed, that way not only does the employee have motivation to work to the best of their ability but they will also have reason to complete the job, rather than leaving in the middle of the design or coding stage .Doing this will remove the risk of employee turnover as they would financially and legally lied to the project through its duration.

Poor productivity has to deal with the motivational levels and the capacity of the workers to provide the quality of work that is expected. The response to this would be to mitigate. Based on the fact that to avoid employee turnover, vendors and critical members of the project team have been placed on contract, there is no way to transfer the risk, and accepting it will cost the company in the end as the software will be poorly developed .The best course of action would be to mitigate, in a two step approach. Firstly by providing the team with the training necessary to get the job done properly and clearly defining what needs to be done and then by adding motivational prizes and rewards for meeting goals and deadlines. This method will boost the employee’s capability to provide excellent quality work and increase their enthusiasm to improve the productivity level.

Risks such as budget estimation and insufficient resources go hand in hand and in both cases the response chosen was to mitigate the risks. In a software development project, there is no way to complete avoid the risk but by properly handling the resources and careful tracking spending these two risks can be mitigated, close monitoring and review can lead to a more accurate budget by having a variance of the product chosen, its cost as well as the most expensive version of the product .By doing this one can determine the absolute most any Item will cost and will be able to distinguish an accurate budget. Similarly so by discussing alternatives the project can determine the best utilization techniques to manage resources so as to have them stretch as far as possible. In addition having a tracker to map the utilization of the resources will help to reduce the waste or improper use of resources.

Testing documents unclear for acceptance testing is another critical risk. In a situation such as this with a software development project to consider and the stakes pretty high .in order to ensure that the maximum quality is maintained and that testing is thorough and accurate this risk can be transferred to a third party to ensure that all loop holes are explored and accounted for .If the original testing group cannot provide conclusive documents and testing results then it is up to the project team to get a third party to do that testing with coders and end users and ensure that the software is ready for acceptance and integration

The last risk that the project has taken into consideration is that of specification breakdown, the best way to address this risk is to avoid it. Each member of the project team must be provided with detailed technical documentation an outline, and a timetable of the requirements and deliverables and specifications regarding these deliverables .In addition, prior to the start of each phase of the project, meetings should be held to discuss the course of action relative to the upcoming phase and the steps that will be taken in order to ensure that the specifications are met. This way there is no confusion as to what is needed for the project and the route that will be taken to achieve these specifications.

Project Risks Responsibility Plan

Project Risks Monitoring & Control Plan

Project Risks WBS &Budget Updates

Project Risks Communication Plan

References

Risk Management within an Organization Retrieved from https://campus.ctuonline.edu/courses/MPM344/p1/hub1/5787.pdf on 5.24.2015

Risk Identification Retrieved from http://www.palisade.com/risk/risk_analysis.asp on 05.11.2015

A Guide to the Project Management Body of Knowledge (PMBOK Guide) – Fifth Edition Retrieved from http://wow.coursesmart.com/9781935589679/firstsection on 5.24.2015

Risk Identification Retrieved from http://international.fhwa.dot.gov/riskassess/risk_hcm06_02.cfm#stab4 on 5.24.2015

Risks faced within Software Development Project Retrieved from http://www.projectsmart.co.uk/top-five-software-project-risks.php on 6.1.2015