Changing Oracle Project Management from Good to Great

 

 

Leigh-Anne McDonald, PMP

First Stage Consulting, Inc.

 

Abstract

 

No matter the size, complexity or type of project, risk management plays an integral role. Most stakeholders view risk a project negative.  Risk can also be a positive. Sometimes risks are really issues and concerns. If updating your risk register, discussing risk at every team meeting, and constantly keeping an eye out for risk is not part of your project management strategy, keep reading.  This white paper will discuss the ABCs of risk management, including development of a risk management plan, qualitative and quantitative risk analysis, selection of cause and effect tools, and maintaining a risk registry. 

 

What is Risk?

 

Webster defines risk as “someone or something that creates or suggests a hazard.” In project management terms, risk

is the recognition that a problem has the potential to occur.  This does not mean the problem will occur – that is the

purpose of risk management. Risks can either be negative or positive. Negative risks are events that, if realized,

may be problematic to the expected outcome of the project.  On the other hand, positive risks, if maximized, may

actually improve the value-add proposition for a project.

 

For example, an Oracle product implementation is potentially risky because it may be new to your organization. This in turn, introduces organizational change management challenges and increased resource requirements for post-implementation support and maintenance. It is assumed, however, the implementation will be beneficial to the organization and therefore it is a positive or calculated risk. This is also known as an opportunity.

 

Consider a second example. An Oracle project is experiencing setbacks as a result of technical challenges that are unsuccessfully addressed using an organization’s tried and true methods until now. The organization crashes the project schedule adding an experienced DBA from outside the project to the team. Is this a negative or positive risk?   The new resource offers a fresh perspective and presents an opportunity to approach the problem from a different viewpoint. However, the new resource is a negative risk because their acclimation period to the organization may impede timely resolution of the issue and in turn progress of the project.

 

Analyzing risk impact and defining response strategies are the key components of changing Oracle project management from good to great.

 

Risk Management Planning

 

Should risk be managed? Yes.  Why should you manage risk?  A better question is why would risk not be managed?  Risk management planning provides the opportunity to monitor and control the outcome of your project.   Great Oracle Project Managers carefully plan every aspect of the project with their team and obtain buy-in from the project stakeholders.  If risk management is not part of your planning process, not only have you missed a critical element in your project management plan but you are putting the project at risk.

 

Tip:        Lack of risk management is in itself a risk to a project. 

 

According to A Guide to the Project Management Book of Knowledge Third Edition (PMBOK Guide), herein referred to as PMBOK, a project management plan should include development of subsidiary plans, one of which is a risk management plan.  A risk management plan describes how risks will be identified, analyzed for impact, responded to, and monitored at every phase of the project.  A risk management plan is the blue print for responding to risk.  Like any good plan, it must be reviewed often and revised as needed to ensure its ongoing effectiveness as the project evolves.  Risk management allows you the opportunity to avoid problems.  Ignoring them does not typically make them go away or lessen their impact.

 

Tip:        Great Oracle Project Managers always remember risk management is part of the project which has many competing project priorities.  In other words, they do not allow risk management planning to become the project.

 

Are Oracle projects different than other projects when it comes to risk management?  Not really.  All projects have common risk factors, and all projects have risks unique to their scope.

 

Tip:        A risk common to all type of projects is organizational change management.  A great Oracle Project Manager is mindful that change is not always well embraced and can create elements of risk.

 

The approach for developing a risk management plan is consistent: Identification, Analysis and Response.  External factors such as the size, complexity, priority of the project, and stakeholder’s tolerance play an important role in defining the risk management plan.

 

Tip:        If your organization does not sponsor risk takers, your organization is risk adverse. A great Oracle Project Manager knows what the organization’s stakeholders tolerances are for risk, and develops a risk management plan in keeping with the organization’s strategic direction.

 

Risk Identification

 

Building a risk management plan starts by identifying the “who”, the “what” and the “how.” Who should participate in risk management planning? What are sources of potential risks?  How should risks be categorized?

 

A great place to start if by reviewing the organization’s history.  For example: Is this your organization’s first Oracle project?  If not, who was on the project team? What lessons learned were captured?  What were the project stakeholder’s tolerances if things did not go completely as planned?  Did a risk management plan exist?  How was the project implemented?

 

Consider the following scenario. Your organization currently uses Oracle General Ledger and your job is to implement Oracle Payables. Your organization has a well defined schedule for month end and year end fiscal reporting.  Historically the accounting staff has always taken 2-3 days for month end and 5-6 days for year end.  The addition of a sub-ledger may add to the time needed for the accounting staff to reconcile and close the books.  This is an example of stakeholder tolerance, i.e., how flexible is the defined schedule for fiscal reporting?  As an Oracle Project Manager, you assess the risk and impact of adding the sub-ledger reconciliation to the fiscal close process. Your mitigation strategy may include planning for defining new workflow processes which in turn creates a secondary risk of when to execute the new processes. A great Oracle Project Manager factors these considerations into project planning and the risk management plan.

 

Tip:        An organization’s historical performance for similar Oracle projects is a great source of risk identification.  This is an example of the risk identification tool called Checklist Analysis.

 

If this is your organization’s first Oracle project, I guarantee other organizations have gone before you.  Oracle Metalink (https://metalink.Oracle.com) the on-line issue tracking tool used by Oracle is an excellent place to start identifying known issues for the Oracle product your company is deploying. 

 

For example, a few years ago I implemented Oracle Receivables 11i. Through networking with other Oracle consultants, I learned that some of the AR and FND forms needed to be re-generated and re-linked to address navigation errors within the module. The problem and solution are well documented in Metalink. Wanting to avoid the problem I queried Oracle Metalink for a complete list of forms known to have this issue and requested the Oracle DBA regenerate all forms in advance of initial set-up, user acceptance testing, training and ultimately production deployment. Early identification of this known risk provided me the opportunity to allocate time within the project schedule to mitigate these events rather than responding as they happened.

Tip:        Oracle Metalink is not just an issue reporting tool, it is also an issue identification source.  This is an example of documentations review, a risk identification tool.

 

Who should identify risk?  Everyone!  The project manager, the project team, the project stakeholders.

 

Tip:        Remember stakeholders are both internal and external to a project.

 

Risk identification is a recurring event and not just performed as the on-set of a project and then forgotten.  New sources of problems will occur as the project progresses and matures.  A great Oracle Project Manager encourages the project team to openly and routinely discuss and analysis risk and includes the Risk Registry with the project status reports to maintain visibility to the stakeholders. The Risk Registry is a tracking tool for monitoring risk and the primary source for reporting and tracking.  It is discussed in detail later in this paper. Typically a spreadsheet is used.

 

How is risk identified?  Ideally, through brain-storming sessions with the project manager, project team, and stakeholders.  Once risks are identified, begin the process of elimination. Start with what are relevant to the project and more importantly what are not.  For example, inclement weather is a relevant risk if the production deployment of your project is scheduled to occur during the winter months, and you are located in a region known for blizzards that in turn cause power outages.

 

Another important tool for risk identification is SWOT analysis.  SWOT is an acronym for Strengths, Weakness, Opportunities and Threats.  Risk analysis is the method of identifying and evaluating opportunities and threats to projects, developing strategies for minimizing or eliminating consequences, or enhancing possibilities.  Including SWOT in your brainstorming, checklist analysis, documentation reviews and stakeholders interviews may improve risk identification.

 

Tip:        Don’t assume to have all of the answers. Allow and encourage out of the box thinking during risk identification but be as specific as possible. 

 

Oracle Project Managers are deliberately hard on themselves, always second guessing what they may have missed.  Give yourself a break but do your due diligence checking and re-checking your lists for risk identification.

 

Tip:        Don’t assume all risks have been identified. Risk identification will evolve and mature as the project progresses.  A great Oracle Project Manager is always on the lookout for risk.

 

Many Oracle Project Managers and especially those new to risk planning, like to categorize risks based on their origin which in turn helps to gauge their impact to the project.  For example is the risk technical or functional in nature? Is the risk external or internal? Is the risk a resource problem?

 

Diagramming techniques such as cause and effect diagrams, process flow charts and influence diagrams are all visual aids that help with identifying the origins of risk. They use a sequential approach to help analysis the output that results from various inputs including time and the relationship between events.

 

Considering the following example.  An Oracle Project Manager must determine which is more desirable for their organization: an Oracle database upgrade and or applying a one-off patch.  The use of a flowchart to document the “what if” scenarios allows a graphic presentation (Graph 1: Cause and Effect Diagram) of the inputs and outputs which in turn may aid with identifying sources of risk.

 

Graph 1: Cause and Effect Diagram

 

 

Table 1 illustrates an example of how to categorize risks for an Oracle project.  It is by no means exhaustive. Table 2 defines example of each risk category.

 

Risk Category

Technical

Functional

Business

Schedule

Hardware

ü   

 

 

 

Operating Software

ü   

 

 

 

Database

ü   

 

 

 

Oracle Applications

 

ü   

 

 

Development

 

ü   

 

 

People

 

 

ü   

 

Requirements

 

 

ü   

 

Budget

 

 

ü   

 

Delays

 

 

 

ü   

Table 1: Oracle Project Risk Categories

 

Risk Category

Definition

Hardware

§  Hardware Availability

§  Hardware Compatibility

§  Hardware Configuration Management

§  Hardware Maintenance and Support Agreements

§  Disaster Recovery

Operating Software

§  Software Version Compatibility

§  Software Licenses

§  Software Maintenance and Support Agreements

Database

§  Oracle Database Version Compatibility

§  Oracle Database Configuration and Management

§  Sizing and Tuning

§  Back Up and Recovery

§  Oracle Database Replication

§  Oracle Database Licenses

Oracle Applications

§  Oracle Applications Version Compatibility

§  Oracle Applications Licenses

§  Oracle Applications Configuration Management

§  Oracle Applications Set-Up

§  Oracle Applications Issues

§  Oracle Applications Seed Data

§  Oracle Applications Testing

Development

§  Custom Development Issues

§  Custom Development Integration

§  Custom Development Configuration Management

§  Custom Development: 3rd Party Interfaces

§  Custom Development Testing

People

§  Resource Availability

§  Resource Skill Sets

§  Sponsorship

§  Stakeholder Influence

§  3rd Party Vendors

§  Communication

§  Organization Change Management

§  Training

Requirements

§  Requirements Definition

§  Business Process Re-Engineering

§  Scope Creep

§  Change Management Process

Budget

§  Funding Availability

§  Procurement

§  3rd Party Contract Negotiations

Delays

§  Competing Project Priorities

§  Deployment

§  Project versus Program Management

Table 2: Oracle Risk Category Definitions

 

Risk Analysis

 

Developing a risk management plan, categorizing risks and identifying relevant risks is the half way mark to changing Oracle project management from good to great.  Analyzing the risks identified is critical to the end goal.

 

A great Oracle Project Manager knows assessing and analyzing risk will help them make informed decisions and improve likelihood of project success. Risk analysis helps an Oracle Project Manager turn raw data into decision making information.

 

Risk analysis asks the who, what and how questions. Who should analyze the risk? What could occur? What is the impact if it does occur? How probable is it that it will occur? How can the risk be mitigated to reduce the probability of occurring? How can the risk be enhanced to increase the probability of occurring?  What is the contingency if it does occur?”

 

Analyzed risks are documented and prioritized in the risk registry. Why risk prioritization?  Risk management planning factors the size, complexity and scope of the project, prioritizing risks helps ensure that management attention and project resource are effectively and efficient focused on the risks that represent the greatest impact to the project if not mitigated.

 

Tip:        The time required to diagnose a problem cannot be estimated in advance.  To avoid last minute panic, plan both resources and time for root cause analysis

 

There are two types of risk analysis: qualitative and quantitative analysis. Qualitative analysis is the subjective ranking of risk for impact and probability of occurrence.  Within an Oracle project team it is common for either everyone to have a different view point or for everyone to measure all risks as having critical impact. Quantitative analysis is the numerical analysis of the risk and probability.  Knowing the difference is key to changing Oracle project management from good to great. 

 

A great Oracle Project Manager knows that not every risk requires mitigation as it would be too costly and time consuming to manage.  They rely on the risk information to conduct analysis and to a large extent their own personal experience managing Oracle projects.  Only risks that can be well defined can be well analyzed. Useful is understanding the risk and its origin which indirectly relates to its quality and reliability.  Hearsay and speculation are not reliable when making risk impact decisions unless they can be validated through other sources and means.

 

Tip:        A great Oracle Project Manager knows qualitative risk analysis is subjective and often influenced by other stakeholders, i.e., the CEO believes this problem could never happen so ranks it low. An Oracle Project Manager evaluates risk based on quality of data not personnel preferences.

 

There are numerous tools available to conduct risk analysis. For example, Expected Monetary Value (EMV), Monte Carlo Analysis, Probability Distribution, Decision Tree Analysis and Probability and Impact Matrix.  Most projects will use one or more of these tools based in a large part on the Oracle Project Manager’s recommendation after careful analysis of what are the best fits for the project.

 

Tip:        Project managers make decisions under uncertainty.  Great Oracle Project Managers recognize this and use tools to help remove or diminish elements of uncertainty.

 

Of all the tools available, the Probability and Risk Impact Index Matrix is the most telling quantitative analysis tool because it provides an at-a-glance dashboard rating for known risks.  The PMBOK Guide considers high risks a red condition, medium risks a yellow condition and low risks a green condition.  Any number of scale values can be used to assign a numeric value to impact and probability.  The key is to ensure your project team understands the significance of each product. 

 

What is probability?  By definition, the likelihood that a problem may occur.  Table 3: Probability Index illustrates a

numeric ranking for each probability index.  For simplicity purposes 1 through 4 are used.

 

Index

Definition

1 – Low

Not expected to occur or occurs infrequently

2 – Medium

Not expected to occur or occurs frequently enough to be monitored

3 – High

Expected to occur

4 – Critical

Occurs more frequently than expected

Table 3: Probability Index

 

What is impact? By definition, impact is a numeric assessment the impact of the problem will have on the project if

it occurs.  Table 4: Impact Index illustrates a numeric ranking for each probability index. For simplicity purposes 1

through 4 are used.

 

Index

Definition

1 – Low

Insignificant impact

2 – Medium

Insignificant impact that requires mitigation

3 – High

Significant impact that requires mitigation

4 – Critical

Significant impact that requires immediate mitigation

Table 4: Impact Index

 

The product of multiplying the Probability Index by the Impact Index is a number which prioritizes risk.  The larger the number the greater the risk.  The risks can be sorted largest to smallest, and time can be factored in, i.e., when is the risk likely to be realized so that resources can be allocated for mitigation. 

 

Using PMBOK Guide’s recommendations, a dashboard rating is useful to address the timeframe element, i.e. red indicates immediate response whereas yellow would suggest management attention is required.  Table 5: Probability and Impact Matrix demonstrates the dashboard rating approach for prioritizing risks.

 

Probability

Impact

1 – Low

2 – Medium

3 – High

4 – Critical

1 – Low

1

2

3

4

2 – Medium

2

4

6

8

3 – High

3

6

9

12

4 – Critical

4

8

12

16

Table 5: Probability and Impact Index Matrix

 

Tip:        It is common to toggle between dashboard rankings especially as the project evolves, and mitigation strategies and contingency plans are executed. Great Oracle Project Managers are flexible with their analysis and avoid knee-jerk reactions. 

 

Risk analysis requires Oracle Project Managers to be mindful of low risk items but not spend too much time mitigating them as the goal is to manage and move risks from critical impact to low risk. A better approach is to be conscious of the impact if multiple low ranked problems occurred simultaneously as is typical in most projects.

 

Risk Response

 

Tip:        A great Oracle Project Manager knows not all identified risks require a response.

 

Risk response typically has one of four possible outcomes: acceptance, avoidance, mitigation and post-ponement.  Passive acceptance of a risk is not recommended nor is post-ponement unless is it formally scheduled to be addressed at a later time within the project schedule. The PMBOK Guide formalizes risk response as one of six actions as shown in Table 6: Risk Response.  Avoid, mitigate and transfer are strategies for responding to negative risks.  Exploit, enhance and share are strategies for strategies for responding to positive risks.

 

Risk Response

Example

Avoid

Take action to prevent the risk from occurring.  For example the risk may be the direct result of incomplete requirements or too tight a project schedule.  Qualifying requirements and extending the schedule may prevent the risk from occurring.

 

Mitigate

Accept the risk may occur and take steps to lessen its probability and / or impact.  For example plan for additional testing to identify issues earlier or engage a vendor with guaranteed performance.

 

Transfer

Assign the risk to a 3rd party.  Note risk transfer almost always involves paying the 3rd party to assume the responsibility for the negative impact of the risk. Insurance is an example of risk transference.

 

Exploit

Take action to make the risk occur which in turn may bring positive impact to the project.  For example, if the project schedule is too tight, adding more resources to complete all tasks n the assigned timeframe may improve the quality of the deliverables.

 

Share

Share the risk with a 3rd party, again for the purpose of taking advantage of an opportunity to improve the project’s outcome.

 

Enhance

Help the risk occur but taking steps to increase its probability and / or impact.

 

Table 6: Risk Response

 

Key to risk response is knowing if the risk is a threat or opportunity, and its impact on the triple constraint (project scope, schedule and cost).  Acceptance is a strategy for both negative and positive risks, largely because it is difficult to completely eliminate risk.  A great Oracle Project Manager can passively accept a risk, in other words do nothing, and allow it to happen, or actively accept the risk and develop responses. The best strategies are those that are well thought out, supported with empirical analysis and communicated to the stakeholders in advance for buy-in. Contingency plans are often the outcome of risk response when the risk is realized. 

 

Tip:        Every great Oracle Project Manager has one or more contingency plans for specific high impact risks. 

 

Consider the following example. Delivery of new hardware is delayed impacting installation of an Oracle product

which is a critical path task.  A great Oracle Project Manager would recommend using the existing legacy equipment

until the new equipment arrives or has a secondary vendor with inventory in stock.

 

Risk Monitoring

 

Monitoring risks is crucial to the risk management process and what makes good Oracle Project Managers great!  Great Oracle Project Managers know risks should have assigned owners.  Individuals responsible for monitoring risks and reporting status to the project team.  Risk owners are also typically responsible for assessing probability and impact and developing responses.

 

Where do you begin?  Rank the risks using the probability and impact matrix dashboard rating as your starting point.  Develop mitigation strategies for the medium and high risks. Remember high risks first.  Ask yourself, if the effectiveness of your strategies pass the reasonability factor or do they need to be re-visited?  Look for risk cues, i.e., those subtle or not so subtle hints an event may occur or has occurred.  If you do not recognize the cues, a risk may quietly materialize and, despite good contingencies, affect the project.

 

The risk registry is a very important result of risk management identification and qualitative and quantitative analysis.  The risk registry is the tool for tracking, monitoring and controlling risks.  It should be included in every Oracle Project Manager’s status report, reviewed and updated regularly. The risk registry tracks updates to risks, which in turn impacts risk response planning.  Table 7 is a risk registry for an Oracle project. Note, it combines the risk categories and the probability and impact matrix to quantify and prioritize risks and provide risk mitigation information.

Table 7: Risk Registry

 

Conclusion

 

Changing Oracle project management from good to great requires a risk management plan for the Identification, Analysis and Response to project risks.  

 

Using a combination of identification techniques including checklist analysis, documentation reviews, historic research, diagrams and brainstorming, risks can be identified and categorized. The SWOT approach aids the project team with the determination if identified risks are threats or opportunities.  Great Oracle Project Managers seek to maximize positive risks and minimize the impact of negative risks.

 

Risk analysis should use the Probability and Risk Impact Index to calculate risk exposure and prioritize responses based on the dashboard ranking.

 

Risk response is the informed development of mitigation strategies and contingency plans to address high and medium risks.  A great Oracle Project Manager does not passively accept risks and is always on the watch for new risks as the project evolves and matures.

 

The Probability and Risk Impact Index Matrix, in conjunction with the risk registry, aids in monitoring, controlling and mitigating risks by providing an at-a-glance dashboard view of potential and realized problems. It is an invaluable reporting tool for providing risk visibility to stakeholders.  Assigning an risk owner to every risk and managing their process is effective in the analysis, response and monitoring of a project to a successful conclusion.

 

About the Author

 

Leigh-Anne McDonald is a certified Project Management Professional (PMP) and Oracle e-Business functional consultant with 20 years experience in the field.  As a Management Consultant for First Stage Consulting, Inc. she uses her business knowledge, project management skills and consulting expertise to successfully deliver Oracle projects on time and within budget. Her core Oracle competencies are Financial, Human Resource and Self-Service applications.  Leigh-Anne can be contacted at lmcdonald@first-stage.net.

 

References

 

A Guide to the Project Management Book of Knowledge Third Edition (PMBOK Guide)

@ 2004 Project Management Institute