An essential component of delivering any successful project, including an Oracle Applications Upgrade, is identification and effective mitigation of the risks and issues. The purpose of this article is to discuss some of the risks associated with an upgrade project with regard to different types of implementations and configurations. The article will then discuss some mitigation strategies available and their appropriateness to different implementations.
For the purpose of this discussion, risks have been divided into two different categories:
1) Project Risks
2) Technical Risks
The majority of this discussion will be around the technical risks associated with an 11I Upgrade Project and strategies for mitigation of those risks.
Standard project risks are those such as staffing, scope and the project management process itself which are common to most projects. They must be adequately addressed for any project, regardless if it is an upgrade or simply a new invoice layout, to succeed. The leading reasons for project “failure” are (disputably):
- Poor/inadequate planning
- Lack of attention to detail
- Insufficient support, guidance, commitment from management
- Setting of unrealistic schedules
- Lack of training in project management
- Poor selection of project team members
- Project manager and/or organisation not entirely clear on project goals
- Proper controls not put in place
- Lack of effective teamwork
So how does this translate to project risks? Specifically, the risks include such things as
- Key project personnel not available due to other commitments / workload
- Key project personnel do not have sufficient skills to undertake the work
- Retention of project team members during the project
- Subsequent analysis during the project drives significant not forecasted business process reengineering requirements
- Significant changes in the scope of the project
- Insufficient business involvement to enable acceptance
|Platform||Tier 1 platforms (Sun, HP, Compaq, NT, etc) have lower technical risk as patches are available immediately (no waiting for a port) and the number of customers live on 11i on these platforms is higher (better chance bug has already been found and resolved).|
|Applications||The more straightforward applications, such as Cash Management, are lower risk than more complex applications, such as Accounts Receivable.
Newer applications, such as Order Management, are higher risk than older, more established applications, such as Assets.
Applications used extensively by the majority of sites, such as General Ledger are lower risk than applications used by fewer sites, such as Service.
|Extent of functionality used||The more of a module you use, the more likely you are to encounter a problem. Additionally if you use functionality that is used by few applications sites, such as RFQs in Purchasing, you are more likely to be the first to encounter a particular problem.|
|Stability of the Release||The more sites that are live and happy on a particular point release (i.e. not in the cycle of weekly-patch-application) the more stable the release is considered to be. OAUG conferences & consulting firms are usually good sources of information on this.|
|Extent of Customisations||The more customisations you have the more complex the upgrade and re-work. Reports are lower risk than forms changes. Customisations in applications which have experienced substantial technical changes (such as Order Management and Receivables) may require a full re-write, those in applications which experienced minimal changes (such as Assets and General Ledger) will be ported more easily.|
|New Applications and / or Functionality||Taking the opportunity to implement new applications and/or functionality to ensure maximum business benefit from the upgrade also introduces technical risks in line with the complexity and popularity of the application or functionality being implemented. For example, iExpenses is low complexity, Project Accounting is high complexity; Leasing is not an extensively used application, whereas Cash Management is.|
|Extent of integration with other systems||The more integrated your Oracle Applications are with other business systems the more complex the upgrade process will be in terms of scheduling and cutover. Changes to the open interface tables have not (in general) been significant between 10.7 and 11.5.7.|
|Geographic Distribution of users||Release 11i is deployed using a browser (Forms based & self-service) and a browser plug-in (forms based interface only). The greater the geographic distribution of users, the more complex the network aspect of the technical architecture becomes.|
So these factors feed in to the technical risks for the project, essentially that the upgraded applications will not be accepted by the user community.
- Performance specifications are not met
- Functionality specifications are not met
Strategies for Mitigating Technical Risks
So now we know what factors subject our upgrade to higher and lower degrees of technical risk, what strategies are available to mitigate the risk to an acceptable level for the organisation?
|Increase Testing Time||The more complex the applications and functionality used the longer time needs to be allocated to test it.|
|Reduce the extent of functionality used||Since increased functionality increases the risk, conversely limiting the functionality being used will contain that risk. However, this is rarely acceptable to the business except in the case of delaying the implementation of new functionality or disabling functionality which is not, in reality, used. The less functionality used, the more time can be spent testing it.|
|Porting the applications to another platform||Porting to a more supported platform can be an option for customers on less popular hardware & operating system configurations. This is becoming less of an issue as Oracle increases the number of Tier 1 platforms and removes support totally for other platforms.|
|Removing customisations||The customisation hit-squad is often a celebrated by-product of upgrades both to reduce the risk and to reduce the effort associated with re-work and ongoing maintenance. Removing customisations, particularly those which do not comply with the customisation guidelines, can mitigate risks for the project as it makes the problem investigation and resolution process more straightforward.|
|Reassessing testing strategy||Ensuring an effective testing strategy, based on business requirements rather than a feature tick-and-flick approach, will mitigate the risk of going live with a system which cannot support business continuity.|
|Phasing in new applications following the upgrade||Where an upgrade is fairly complex in itself, phasing in new applications and / or functionality a few months after the actual upgrade can ensure that both phases are provided with their due attention and diligence. Basically, it reduces the complexity of the upgrade without abandoning the business requirements.|
|Ensure product stability||Upgrading to a release used by other customers with similar configurations to your own will minimise the risk.|
|Monitor performance during acceptance testing||Monitoring performance throughout the acceptance testing phase will ensure that the production hardware specifications are viable. Undertaking a perpetual detailed sizing process throughout the project as volumetrics become more evident is highly beneficial to mitigate performance risks, particularly with regard to differentiating between network, desktop & server performance issues.|
|Ensuring project team contains required skill set||A project team which comprises the appropriate technical skills and experience will significantly reduce the technical risks associated with the upgrade. For example, it is usually faster for an experienced DBA onsite to resolve an issue with autoupgrade than for it to be left completely in the hands of OWWS.|
|Manage user expectations||Effectively managing user expectations, particularly with regard to performance, is crucial in ensuring project success. In no universe will Release 11i forms display on the screen at the speed of 10.7 Character, and this is not really an entirely fair metric for performance measurement.|
Let’s look at a couple of scenarios to identify the amount of technical risk and some appropriate mitigation strategies.
|Company X||Company Y|
|Current Release||11.0.3||10.7 Character|
|Operating System||HP UX11||VMS|
|Applications||GL, AP, FA||GL, AP, AR, FA, PO, OE, INV|
|Customisations||8 – reports, interfaces to GL, periodic alerts on AP data||53 – reports, forms changes, interfaces to GL, AR, OE and PO, custom triggers in INV & OE|
|New Applications for implementation||Iexpenses||Cash Management
|Number of Users||20||400|
Current release is a similar technology stack – the architecture change is not as significant as it could be.
Current operating system is a tier one platform within plenty of other sites live on 11i so additional patch-porting issues are likely (assuming it is a certified OS/DB/Apps version configuration).
Applications used are quite low-risk as they are traditionally stable applications which do not undergo a significant amount of change (technically) from 11.0.3 to 11.5.7.
Implementing iExpenses is technically low-risk as the product does not contain a load of complexity.
So, overall, this upgrade would have a low technical risk.
Company Y is undergoing a much larger change – the architecture change is significant, the network and hardware usage patterns will be very different. The current operating system is not supported at the applications level for 11i (though it is at the database level) so a decision will need to be made whether to implement split-tier or to port to another platform, both options increase the complexity of the upgrade though porting far less so than splitting the tiers across two different platforms. Several applications are used, including Order Entry which was completely re-written in 11i, additionally it has been customised which increases the complexity of the upgrade. Implementing Cash Management is very straightforward, however Project Costing requires significantly more work effort and can be a complex application from the technical perspective. Overall this project would have a higher technical risk than the previoius one, and some mitigation strategies which might be appropriate could include removing customisations and phasing in the Project Costing implementation following the upgrade if required.
This article has discussed some of the risks associated with an upgrade project, particularly from the technical perspective, for different types of implementations and configurations. It also outlines a few mitigation strategies which may be appropriate to contain the technical risks to a level acceptable to the business. Each company has a different risk profile and as such an appropriate upgrade project strategy needs to be prepared.
Joanne Davis, OAUG Asia-Pacific, November 2001. Two Roads to 11i: Upgrade Versus Re-implementation.
Joanne Davis, OAUG Insight, January 2001. Ten Quick Tips for your Upgrade in a Cybersavvy World.
Shari R. Divone, MI Services Group, OAUG Europe 2002. Advanced Techniques for Upgrading to Release 11i.
Kent Noble, Oracle Corporation. 2001. Upgrading to Release 11i: A Technology Perspective.
Milan Rahman, Delinea Inc, OAUG Spring 2001. Upgrading from 10.7 to 11i – A Rough Guide.
Cyndie Sutherland, OAUG Spring 2001. Making R11i Reality! – A Project Management Perspective