Abi Project Risk Management Plan

Running head: ABI PROJECT RISK MANAGEMENT PLAN

ABI Project Risk Management Plan

Your Name Here

University of Phoenix

ABI Project Risk Management Plan

The recent acquisition of the ABI company by FAFS mean that ABI needs to change many of their internal processes to coordinate and be accessible by both entities. The union of these banking companies means a merging of databases and software applications. The challenge is to implement the fusion of these companies in a timely cost efficient manner.

With the VP of FAFS guiding two ABI executives and one FAFS executive, the CEO of ABI needs to come up with a plan to integrate the companies and manage the project throughout the process. Weighing the risk of decisions and implementing these choices becomes more challenging than expected. With unforeseen resource barriers, and changes in scheduling, the team had to work together to bring these financial institutions into a bigger better banking entity

Management Responses

"An important manifestation of effective risk management is getting a handle on the scope, volatilities, and severities of the risks one's company faces, then tailoring an appropriate set of risk responses. Risk managers have many types of risk treatments at their disposal. Every company's risk management "solution" will be unique because the exposures and risk appetites all differ. The key is to have a reasonable under-standing of how each treatment option works, alone and in combination with others, so that decisions are informed and results are less influenced by luck than by reason (McCarthy, Flynn, and Brownstein, 2004)."

The executive team in relied on history and the current situation to asses the risk of different decisions. Placing weight on their experience in the backgrounds they came from, they gave advice accordingly. Many times each of them had his or her own idea on how to move forward, but generally there was common theme that assisted on choosing the right way to proceed with the project.

A tool throughout was the process of using a formula to asses the risk. "Risk analysis consists of risk identification, probability assessment, and impact estimate. Start by identifying all the risk events that can occur on your project. Then estimate the probability of each event happening (Chapman, 1997)." Using this formula, more basically written: "Project Risk = ∑(Events * Probabilities * Consequences) (Chapman, 1997)," the team would base their decisions on the outcome of this formula. The key points of the risk formula were: Resource Constraints; skill and Competency Gaps; Dependency on FAFS for Design Inputs; Availability of Network Equipment; Legacy Systems and Standards.

The project was running smoothly until the database specialists began to miss deadlines. It seems the database specialists who were to only work part-time on the "Project Integration", the projects name, but began to ignore the part-time work that was to be done for FAFS. The lack of effort put FAFS behind on deadlines and made apparent the need to make a change. FAFS then took two of the four assigned to the project to meet deadlines.

The lack of two database specialist helped form a decision to move ahead. Each of the executive had ideas on moving forward. Their ideas made moving forward a challenge. One suggested training some of the FAFS people to do the job; the second thought by checking on the progress more and spending a little on outsourcing testing could help; the final leaned completely to outsource and suggested that the FAFS people could not be adequately trained to do the job. The only theme through all the suggestions was that training of the FAFS people would be a challenge and there may be another option.

By taking their views and finding middle ground of cost and the ultimate goal of finishing in time, the option to "Create a design review team including both project sponsors and FAFS experts, arrange for onsite meeting at FAFS, and depute Sid for coordinating any pending inputs."

The decision to select the option to create a design review seems to appease the need to accomplish the job of the database specialists. This option was not obvious from the reading but ultimately makes sense. Unfortunately, the options were limited to three, but there were other possibilities to solve the dilemma.

The executive team may have put more preventative measures in that could have overcome the problem from the start. This could have been achieved by taking the four database specialist trying to balance work from the Project Integration and FAFS by changing their work schedules. Instead of putting the four on a part-time basis on both projects, two could have put a full-time effort in Project Integration and two could put full time on the FAFS project. This way the database specialists could have had a directed focus and not been distracted by the difference in the competing projects. Using FAFS experts to review and give input to each project would maximize the efforts of both database teams and keep them from falling behind on the workload.

The second major stumbling block in the process was a new FAFS management scope of the timeline. Basically they needed the implementation process done a month earlier, so the work load has increased to make the deadline. A decision to move specialists off of no essential processes to more important areas of concern then to outsource the non-essential processes was the decision made.

Executives in the decision making discussion did not directly all move to the decision made, but were on the same page that some changes needed to be made. A combination of their views made this decision clearly the best scenario to move ahead. Though the change in timeline could not have been preemptively avoided, a stronger push throughout this project to get done sooner could have helped. Projects have timelines to give guidance, sometimes people view them inadvertently as restriction that limit the project to that same timeline. An open effort on accomplishing the project early is a better way to get a better scope of a project.

Though speeding the process is not always an option, it can aid in finding problems sooner and avoiding time delays later. "Another reason for reducing project time occurs when unforeseen delays--for example, adverse weather, design flaws, and equipment breakdown--cause substantial delays midway in the project. Getting