Risk Management Plan

Risk Management Plan

Prepared by

PROJECT RISK MANAGEMENT

Instructor:

Term : November 2008 - December 2008

�

CONTENTS

Introduction…… ………………………………………………3

Project Description………………………………………….4

Work Breakdown Structure…………………………….4

WBS Critical Risk High Five…………………………...4

WBS High Five, Item 1…………………………….5

WBS High Five, Item 2…………………………….6

WBS High Five, Item 3…………………………….7

WBS High Five, Item 4…………………………….8

WBS High Five, Item 5…………………………….9

Risk Management and Monitoring Plan…………………. 10

Conclusion/Wrap-up/Summary……………………..…….. 14

Bibliography…………………………………………………..15

Introduction

The OBIEE Project is a conversion project that involves the entire company; right now we have our reporting applications set up in the Business Objects and the Crystal reporting environments; both environments are reaching their end of life and the reports need to be converted into a new environment. This project is driven by the fact that the company is now trying to standardize everything we do and they have decided that all reporting should now be done in the Oracle Business Intelligence Enterprise Edition environment.

Español: Ejemplo de WBS para proyecto cuyo foco e...

CMMI Project Planning – Meta-data model

The WBS Construction Technique employing the 100% ...

All of the other conversion projects have been marred with problems and compatibility issues. We are not sure if we will be able to replicate the old environment in OBIEE because the two platforms are completely different. We are expected to do our conversions within 8 months; which is when our Business Objects and Crystal Reports licenses are expected to expire. With the new environment we should be able to create reports in a timelier manner.

Project Description

The Business Object XI (BOXI) environment and the Crystal environment have both reached their end of life and all BOXI and Crystal reports will now be converted from their existing environments to the company reporting standard which is the Oracle Business Intelligence Enterprise Edition.

Work Breakdown Structure

1.1.3. Team Planning and Building

1.1.4. Planning & Design Phase I

1.1.4.4 Migration to Development

1.1.4.5 Migrate to UAT

1.1.4.8 Training & Communication

WBS High Five, Item 1.

This risk was found during the first project team's risk identification brainstorming session. It was brought to my attention that none of the (human) resources on my project team had any experience with the Oracle Business Intelligence Enterprise Edition environment. The sole purpose of this project is to convert reports from the Business Objects and Crystal Reports environment to the OBIEE environment. If my resources had no idea how to design the new reporting system we would definitely need an extra resource added to the project team who would be an expert in OBIEE.

During the initial stage of the project I presented this risk to the project owner who had previously told me that the project was running on a very limited budget. I presented the risk to him and showed him our work breakdown structure. The project calls for a meta data layer to be created in OBIEE before any conversions can be done. If the project team did not have any experience with OBIEE that meta data layer could not be created. I asked him for an additional resource which should be an OBIEE subject matter expert, but once again he told me that could not happen due to budget constraints because the OBIEE SME's were very expensive resources.

I eventually managed the impact of this risk by getting the project owner to agree to send both my resources to OBIEE training classes which would be specific on the creation of the meta data layer and the conversion of reports from one environment into the OBIEE environment.

The impact to the project turned out to be low; even though we spent time sending both resources to training we were able to spend less time than anticipated creating the meta data layer. It did not affect the project end date or the scope; it only affected the cost which was kept at a minimum. The task went over by one day and I was able to get back that day from another task which I had also over estimated as well.

WBS High Five, Item 2.

This risk was actually identified at one of the meetings that I had with the project owner when we were discussing the project and its scope. I also used a qualitative risk analysis which prioritized all my identified project risks and this risk was given a high priority. The project owner had mentioned that he wanted the new environment to mirror the old environments in order to give the end users a feeling of familiarity. The problem with this was that the project team (design team) did not know if this would be possible because they were unfamiliar with the OBIEE environment.

In order for this risk not to become an issue I have been sending the end users weekly project updates which entail what the new environment looks like versus the old environment. I have sent out communications to the end users, the stakeholders, and the project owner and posted it to the project dashboard the progress of every design feature, color and feel that we were unable to replicate. I have also done this for every design feature, color and feel that we have been able to replicate. I needed to do this so that when we present the end product to all involved in the project there would be no surprises as to what the design would look like.

This has worked out quite; because I am actually explaining how we went about trying to replicate and the reasons behind why it was unable to be done, I have been able to get everyone on board with the final design of the meta data layer as well as the final look of the application.

WBS High Five, Item 3.

This risk was also identified during one of the project team's risk identification meetings by one of my project members. I became aware that after the project team had created the meta data layer that it would have to go to the OBIEE team for a standards review. If the meta data layer did not pass the standards review then we would have to make the changes suggested and then resubmit for another review. If the standards were not met then, we would have to keep going through standards review until it does. I was also made aware that this review was done on the meta data layer as well as all of the converted reports.

This risk was assessed as being high due to the fact that if we failed the standards reviews we would impact the project end date as well as the budget. In order for this not to become an issue I set about asking the OBIEE team to furnish any and all documents they had pertaining to the standards review process. Anything that would show us what needed to take place, what can and cannot be done and I also asked for a member of the OBIEE team to be on call if we had any questions as to if something was an acceptable standard.

The meta data layer failed the standards review one time, it affected our task time but not the overall project end date. We have now finished the planning and design phase; the meta data layer was created and it has passed the standards review. We have learned much about the OBIEE standards review process and will use this along the way with our other phases.

WBS High Five, Item 4.

This is another risk that was identified during one of the project team's risk identification meetings. However, this risk was not identified until after the design phase was complete. We have QA (quality assurance) consultants that have been assigned to the department which we use for our entire departmental project needs.

The risk that was identified is what if we are ready to push to UAT and all the QA resources were unavailable. This risk is especially hard to manage because I do not know when and if the QA resources will be pulled away to do testing on one of our other projects. My qualitative risk analysis showed that this risk should get high priority.

To manage this risk I have continually placed the OBIEE project on the task list of the QA team since we started the design phase. This makes the QA team aware of the OBIEE project, even though we are not in the UAT testing phase as yet I keep the QA team updated on where we are with the project and when we are projected to go to UAT (User Acceptance Testing), what we will need from them and it will also give them an idea of how many resources they will need to place on our project when the time comes.

This risk has not yet made itself an issue and hopefully never will if I keep my lines of communication open to the QA team. I have also come up with a contingency plan just in case the QA team is called to do UAT on larger more important projects. I had taken this into account when I was doing the project work breakdown structure and factored in extra time to do UAT. I would then use our project team to conduct the UAT if necessary. This may take a couple days extra if not done by the QA experts but as I had said extra time had been added in the plan in anticipation of this risk. Therefore, this risk should not affect the project end date, cost or project budget.

WBS High Five, Item 5.

This risk was identified also during a brainstorming session; one our project team member experienced this on a past project. The end users were scheduled for training and no one showed up to the class or if they did they were extremely unruly and had nothing good to say about the end product.

Since this risk had turned into an issue on a similar project I wanted to make sure it would not become an issue on this project. What I have done in order to keep this from becoming an issue is to communicate everything to the end users (stakeholders). I have implemented a weekly or as needed communication plan to the end users which will keep them abreast as to where we are in the project and what else needs to be done. I have also set up meeting with the stakeholders prior to each phase of the project to gather information on what it is they would like us to do or change which allows them to kind of take some kind of ownership of the project.

If they believe that we as the project team are listening and we show them that their suggestions are being incorporated; when it comes time for training they will be more than happy to attend because it is almost like they worked on the project and it's something they would be proud of.

So far my plan seems to be working, I have not heard any complaints whether it be out right or through the grapevine. I have also put together an alternative plan just in case this one does not work. If this risk does turn into an issue my alternate plan would be to escalate the issue to the owner who would have the authority to force them into training or have him negotiate with them on our behalf.

Risk Management Plan

The Process for Risk Management will address, identify, evaluate, and develop steps to manage risks and track project risks.

Definitions

Risk Event - "a discrete occurrence that may affect the project for better or worse."

Risk Register - a tool that is used to identify risks by categories that may include risk owners, agreed-upon risk responses, specific implementation actions, symptoms and warning signs of risk, residual and secondary risks, and a watch list of low priority risks.

Risk Identification

The determination of which risks are likely to affect the project; also the documenting and the characteristics of each risk.

Risk Qualification and Quantification

Evaluating risks and risk interactions to assess the range of possible project outcomes is the process of risk quantification and qualification. The following criteria are used to define the probability and impact of a risk occurring on a project:

Risk Response Development

Risk response strategies fall into three categories:

Acceptance - The project will accept the consequences of the risk, by developing a plan to resolve the risk if it should occur.

Avoidance - Eliminate the impact, eliminate the cause.

Mitigation - Reduce the overall assessment value of a risk by reducing the probability of occurrence.

Risk Response Control

Risk should be monitored and tracked throughout the project. Risks will be tracked via the Risk Register and will be reviewed once a month during the project status meetings (the first meeting of every month or as required)

Reporting & Tracking

Risks will be assessed regularly at the beginning as well as during each phase of the project:

Planning, Design and Build.

Risk Management Process Flow

Identify Risks (Project Team)

Evaluate Risk (Project Team)

Document steps for addressing risks (Project Team)

Enter Risk into Risk Register (PMO Project Manager)

Execute steps for addressing risks (Risk Owner/Project Team)

Track Status and Monitor to Closure (PMO Project Manager)

Risk Tolerances

Risk tolerance areas are determined to be areas that the key stakeholders are willing to accept risk. Risk tolerance will be reviewed after the risks have been identified.

Conclusion

The OBIEE project has turned out to be a bit more complex than first anticipated. Everyone thought that this project would be easy and should only take a couple of months to complete. Unfortunately after talking to the project owner and the stakeholders I realized how much work really needed to be done in such a short period of time. This made me realize that there could be no mistakes and I would be better off over estimating my task durations to give me enough wiggle room just in case risks present themselves.

I have learned never to underestimate what you may think to be a small project. All projects small or large will have risks and being a project manager I will need to understand how to handle risks on a daily basis. Even though I have been able to keep these risks just that, risk monitoring and control is an ongoing task until the project ends. I have learned never to turn your back on a risk, no matter how much you may think it will never become an issue. I am constantly honing my skills so I can become a successful project manager. This class has made me realize that being a good project manager means being an excellent communicator. Communicating is one of the keys to project success; if you keep everyone informed, from project owner to end users you will most likely end up with a successful project.

REFERENCES

Campbell, Michael. G, and Baker, Sunny (2007). The complete idiot's guide to project management. New York, NY: The Penguin Group.

Mulcahy, Rita (2003). Risk management, tricks of the trade for project managers . Minneapolis, MN: RMC Publications, Inc.

Portny, Stanley. E (2007). Project management for dummies. Indianapolis, In: Wiley Publishing, Inc.

Rose, Kenneth. H (2008). Things your pmo is doing wrong. Project Management Journal. Volume 39 Issue 4.

Wrona, Vicki (2008). Your risk management process - a practical and effective approach. December, 12, 2008, from

http://hosteddocs.ittoolbox.com/VW040108.pdf