Oracle Project Suite Best Practices

Oracle Project Manage Suite Best Practices 

Oracle Projects is an extensive, potentially complex suite of applications that at first glance may appear only suitable for large, multinational organizations. However, when a “business need” led approach is taken to configuring and implementing Oracle Projects, it can provide benefits to organizations of many different types and scale. The following article provides an overview of the structure and purpose of Oracle Projects, and includes some thoughts from two recent implementations at very different companies.

Its purpose is to provide anyone considering the use of this Application with a broad understanding of how Oracle Projects works and to illustrate that despite its potential size and complexity, it can be tailored to meet the needs of the business, no matter what its scope and scale. However, successful implementation relies as much on winning hearts and minds at all levels during integration and transition as it does on the fitness for use of the technology.

What is Oracle Projects?

Oracle Projects (OP) is a suite of applications designed to assist organizations in the planning and management of various types of projects. In this context a project is a sequence of linked, often dependent, activities that when delivered over a specific time period, result in a pre-planned outcome or benefit, either to the organization that created the project or to an external organization on whose behalf the project is being run. During the life of the project, the activities will consume resources of various types and thus incur costs and often, but not always, generate revenue for the organization carrying out the project. The purpose of Oracle Projects is to allow the organization to capture and apply costs and revenue against individual projects and to match these against budgets, to plan and monitor progress and to determine, locate and assign human resources to projects. In order to do this, Oracle Projects interfaces with, and heavily relies upon other Oracle applications such as Human Resources (HR), Accounts Payable (AP), Accounts Receivable (AR), Inventory Management etc. In addition, OP can interface with 3^rd party applications, specifically Microsoft Project with which it can share financial, planning and progress information. Oracle Projects comprises a suite of applications, Costing, Billing, Resource Management (Human as well as Materials) etc., which when applied in full, are suited to Organizations that continually manage multiple, complex projects that: 

• • Are for external, chargeable clients
• • Are international, using multiple currencies
• • Use a wide range and high number of different resources, both internal and external
• • Require structured and auditable change control
• • May involve capital and/or service activities
• • Need to be formally controlled, monitored against formal budgets and plans, and reported at multiple levels and locations
• • Interface with other non-Oracle project management applications
• • Have formal security and authorization structures.

For Organizations requiring less than the above capability there is a value balance to be achieved between the resource needed for implementation and maintenance and the resulting business benefits. However, provided that sufficient care and attention is paid to understanding the reasons for implementing Oracle Projects, and the desired business benefits, and to capturing and understanding the business processes that OP is being asked to support, OP can be configured to provide benefits regardless of the scope and scale of the project management activities of the organization.

What Does It Do?

As shown in the following illustration, Oracle Projects uses data from, and feeds information to, other Oracle applications. As this suggests, it is perfectly possible for organizations to manage projects using existing Oracle applications together with 3rd party tools such as Microsoft Project and Excel. However, OP can provide significant benefits in increasing the visibility of financial and task information against individual projects and can also be an effective means of communicating policy towards project management and ensuring that such policy is adhered to. Examples of such policy include how budgets are constructed and authorized, the stages in a project’s life when costs may be allocated, who may allocate costs, and, importantly in these days of ever increasing governance, when revenue may be recognized. 

Thus there is a strong link between the way in which Oracle Projects is configured and the governance and control policies of the organization. Use of a structured system that applies fiscal rules that are consistent over time, people and geographies can be of invaluable assistance compliance with its governance policies. The effort expended in establishing Oracle Projects can pay dividends at audit time, when myriad spreadsheets, held in various places, in different formats, and most probably not up to date are replaced by compliance through design. Putting aside the need to keep auditors happy, OP can also provide an organization with business benefits with regard to the timeliness and relevance of, and access to financial and progress information across projects. It is easy to say that for any organization running projects it is no more than “table stakes” that at any time the appropriate people should know how well a project is proceeding against time and budget. However, the reality is often a disconnect between the departments creating and managing projects and the finance departments who are responsible for collecting and reporting costs; sometimes this problem can also exist within the areas managing the projects, to the extent that managers can have difficulty knowing which of the projects undertaken in their departments met their original aims in terms of cost, revenue (if applicable) and time. When properly implemented, Oracle Projects can address these issues and greatly increase managers’ visibility of project performance, allowing them to take remedial action at the appropriate time, reallocate resources as appropriate and assess future direction based on facts. Of course, such increased levels of visibility can create change management issues of their own!

Change Management

The implementation of Oracle Projects can be the catalyst for a root and branch review of how the organization manages its projects and leads to fundamental change. Thus implementation does not merely represent a change to the systems that people use (traumatic enough!) but may also coincide with the imposition (I use this somewhat emotive term advisedly!) of policy and procedure that is either new or may have always been the – quietly ignored – theory of “how we do things”. The transition period can be critical as users in different countries with different cultures pass through the transition of losing systems and methods with which they are familiar, manage the uncertainty of the neutral zone when they are using both old and new systems before they are able to move into the new start and fully own the new ways of working. One of the key benefits of Oracle Projects is that it can greatly improve visibility of project performance and costs throughout the organization. This may not be regarded as a benefit by those managing the projects! 

Borrowing from Peter to pay Paul becomes less easy for the Project Manager to do without having to explain his or her reasons to higher management (not that the Author ever indulged in such nefarious activity of course!); suddenly Project Managers find it slightly more difficult to save time by starting work early and thus incurring costs ahead of full project authorization. So as with any change of this sort, care has to be taken in ensuring that all users can take sufficient benefit from it to ensure ownership and use in spirit as well as by the letter of the law. Every change represents a threat and opportunity and often organizations will appoint a change manager to ensure that, at all levels, the benefits so far as possible outweigh the perceived penalties. It is in this key aspect of Oracle Projects development and implementation that use of an Integrator/Transition Management specialist organization such as iTrain Education, who focuses as much on the people issues as on the technology, can make the difference.

The Project Lifecycle

Oracle Projects is a very large suite of Applications and can appear somewhat daunting. So, to put it all into some kind of context, the following summary shows a typical process. In common with other IT systems, the greater the effort that is put in to understanding the processes and configuring the system accordingly, the simpler becomes the appearance and use of the finished product.

You Create a Project

This is done by selecting a pre-designed Template, from a choice of many, few or even just one, and by following a succession of prompts, populating that initial project information that allows the project to proceed. The type of information provided, whether it is mandatory or optional, the status of the project at creation, the types of tasks it contains, and the type of project (revenue or cost) are amongst the attributes that are set at the design stage. As is the case with many systems, Oracle and others, a very large and somewhat bewildering list of possibilities may be boiled down to an extremely simple, menu-driven activity at the user level. Straightaway, the way in which OP is configured is used to enforce company policy regarding the possible status of projects on creation, and the possible types of project that may be created. 

You Enter a Budget

The Template from which projects are created contains a budget and this is brought into the new project. The user then amends the budget with data specific to the new project and, depending again on how OP is configured, submits the budget for approval (known as “Baselining”) often using the Oracle Workflow capability, which can be an email-based method of routing approval requests. Separate budgets may be established for Cost and Revenue. A similar principle is used for creating cost and revenue Forecasts. Budgets and Forecasts may be subsequently amended and, according to business policy, submitted for re-approval.

You Find Some Resources

In smaller organizations, it may be a fairly simple task to decide who should be used for various projects; it may also be the case that the charge rate structure is fairly simple and stable. However, for larger organizations, the pool of possible resources may be very large and possibly international. It may also be the case that charge rates vary. The Resource capability of OP allows users to identify what the role requirements are for a specific project and, using competencies and cost data held in other Oracle Applications such as HR, OP will then match those requirements against suitable resources. Once again the system is configured to require the user to seek the appropriate authorization before resources are committed.

You Capture Costs

In many cases, the correct allocation and reporting of costs is the main or even sole raison d’etre of OP within the organization. Task planning and progress is managed using, say, MS Project and it may well be that the projects are not revenue-generating. Thus the main effort is concentrated on capturing expenditure, be that for external purchases or (more typically) the labor costs of the human resources used on the project. As in the case of Resources, OP relies on other Oracle applications, such as AP and Purchasing to obtain the cost data and allocate it to the appropriate tasks. At the same time, expenditures may be entered directly into OP. 

One of the important business decisions to be taken concerns the manner in which total costs are to be managed. Oracle Projects can be configured to apply a “mark-up” against expenditures to account for shared costs such as SG&A that need to be amortized across all projects. This principle, known as “Burdening” allows reasonably sophisticated cost models to be created and, if required, over-written at local level as business needs require and allow. However, even large organizations will often choose not to apply this aspect of OP, preferring instead to manage shared costs elsewhere within their financial systems and content to have OP report on actual (“Raw”) project costs. Often the expenditures will be linked through to the General Ledger, creating double-entry records from OP that may be traced back using various “drill-down” capabilities. This is clearly a powerful capability, providing organizations with high levels of expenditure traceability. However, once again, not all organizations choose to use it and are happy to operate OP separately from their General Ledger. It’s all a question of understanding the business needs and only doing what is necessary to meet those needs.

You Measure Progress

Although many organizations are happy to use OP solely to measure expenditure and/or revenue against budget, it possesses the capability to provide users at many levels with information on the state of completion of projects. There are a number of ways in which progress can be captured and it is also possible to restrict who can record progress. Typically the method of recording progress is selected from one of the following:

• Duration

How long has a task been running compared to the total anticipated duration?

• Cost

What has been the cost so far compared to the total anticipated cost?

• Effort

How many hours have been expended compared to the total anticipated?

• Work Quantity

How many jobs are completed compared to the total required?

Another business decision that needs to be made concerns who is allowed to record progress. “Collaborative” progress reporting allows many people within the organization to enter project progress, as opposed to “Centralized”, which as the name suggests provides a greater degree of control over who may record progress. As has been mentioned above, many organizations choose to continue to plan and manage progress using Microsoft Project and use Oracle Projects for cost collection and reporting. However it also possible to link OP and MS Project, exchanging information related to budgets, costs, progress and resources. Clearly a key need here is to ensure synchronicity between the two systems and careful consideration should be given to how each Application is to be used. A feature of interest is the way in which MS Project can provide a greater level of task hierarchies (“granularity”) than OP whilst still maintaining links. 

Thus a task in MS Project may have 5 levels of detail, only three of which are reported through to Oracle Projects. This ability to mix and match levels of required detail and task hierarchies can be very useful. However, it of course means that MS Project has to be kept current – not always the case in this author’s experience! 

Training – A Holistic Approach

When developing training plans for Oracle Projects, in addition to the usual considerations of who is to be trained, where, how and when, the particular nature of Oracle Projects can, and indeed should, influence the design of the training. The aspects of OP that can distinguish it from other Oracle Applications are: 

1. Projects have a definite start and end, and there is a sense of a journey through the different stages of creation, management and conclusion of a project, with each stage being dependent upon previous stages.

2. Oracle Projects is strongly linked to, and heavily dependent upon, other Oracle Applications and training cannot exist in total isolation from those links.

3. Company policy will strongly influence how OP is used and often the implementation phase will involve the development, or at least formal capture of, policies and procedures that hitherto were perhaps partially or inconsistently applied; training will very often include the need to communicate and explain policy and process rather than merely “which buttons to push”. 

Thus, although it is quite possible to provide training in “stand-alone” modules and this approach can make best use of people’s time, consideration should also be given to the merits of training structured around the life cycle of a project, which will dip in and out of various Oracle Applications as the need arises. Whilst this can mean that people’s time may not be optimized, it can provide a far deeper understanding of the way in which the project process works and is supported by the various Oracle Applications. As ever, there is no one answer for everyone. The important point is to be aware of the different approaches that can be taken and to properly assess the merits of each.

Some thoughts from Recent Implementations of Oracle Projects

Finally it would be instructive to summarize here some observations from some recent implementations. Two examples have been chosen that hopefully exemplify the way in which OP can support very different organizations.

The first was a medium size manufacturing organization, vertically integrated with its own design and development division and based at a single site in the US. This organization already had certain Oracle applications installed and was seeking to extend its use of Oracle by implementing Projects in its R&D division. The aim was to provide greater levels of cost and progress control over its internal, product development projects that in the past relied on stand-alone spreadsheets and MS Project files for their control. The business case for doing these using Projects was based on the opportunity offered by the acquisition of Projects as part of a bundle of Oracle Applications. Implementation was to be managed in-house and the subsequent use of Projects was likely to be restricted to very few people, the emphasis being on entering hours and also payments to suppliers, and linking OP to existing MS Project applications. Because the organization had yet to fully capture their processes and needs, training in this instance focused on education in the structure and capabilities of OP to enable those concerned to subsequently develop their implementation model.

Some of the characteristics:

• OP was to be used by a handful of people within one Division of a US-based organization – although during consultation the possibility of extending its use into other areas of the Company was raised and debated

• Configuration and Implementation was to be done in-house

• A key aim was to be able to identify costs against individual projects and thus to assess their effectiveness

• Strong interest was expressed in linking OP to MS Project – although during consultation that started a debate regarding the extent to which MS Project was reliably maintained by individuals during the life of a project

• 

Large, Car Manufacturing Company, head-quartered in the Japan seeking to roll out OP and associated Oracle Applications across its North America, European, Middle East and Africa region

In this instance the configuration and design of OP had been managed by an external consulting organization and the requirement was to compile manuals and other reference materials for use in the different countries as a support for training and for later reference. 

Some of the characteristics: 

• 8-person implementation team working with multiple contacts within the organization over many weeks to formally map processes and procedures

• Roll-out across many countries over several months

Full suite oracle Project modules 

Project Resource Management and Project collaboration

Project Intelligent 

Integration with Product Development Life Cycle

Integrated with Oracle Shared HR system and PeopleSoft

Managed all resource allocation, forecast, utilization in Oracle modules

• Strong emphasis on using OP to achieve consistency in the application of company policy and governance

• Focus on capturing costs and feeding through to GL

• Extensive integration with Oracle HR, AP, AR, Fixed Assets etc.

• Use of Workflow to authorize Budgets, Forecasts, Resource Assignments

• MS Project Integration with Oracle Project
• MS Excel Integration with Oracle Project

Concluding Thoughts

Oracle Projects is a potentially large and very powerful tool that nevertheless relies on other Oracle Applications to work. As with any IT system, the amount of care and effort that is invested prior to implementation will greatly influence the success of that implementation both in terms of its function but probably more importantly in terms of its ownership and use across the Organization. The first and hopefully most obvious point from the above case studies is that the two organizations shown are very different; different in size, operation, geography and requirements. Yet both found a business need for Oracle Projects and developed ways of making it work for them.

The second point is that no matter what the scope or scale of the operation, the starting points are always the same:

1. Why do we want Oracle Projects?

2. What are the business processes and procedures that we are seeking to support with Oracle Projects?

If the answers to these questions are not clearly and universally understood at all levels, and reviewed during the life of the project as with any IT-supported change, the risks of a possibly expensive failure and Disappointment are greatly increased.

Keys to Success

There are a number of reasons why this group has been able to successfully deliver a high volume of significant projects over the last few years. Some of these projects are unique in the industry due to the broadness of their scope, time scales, the data volumes, or the number of users impacted. These reasons include:

Senior Management Buy In. • from the early days of the Consolidation Program it was recognized that Senior Management buy in is essential for any significant initiative to have a chance for success. All of our individual projects have been, and continue to be part of a strategic goal and plan, and as such are supported by the Management team at the appropriate level. 

Ownership. • It is essential to ensure ownership and accountability is agreed in advance and at the right level. Decision making and escalation channels need to be clearly laid out at the start of the project, not later when issues may be raised. 

Management Focus for the Key Initiatives. • Within CLIENT, there is a weekly meeting that provides the AIT Management team with updates on key CLIENT projects. This forum provides an excellent way to enhance communications and decision-making between the project team and the Management team. Regular updates to Senior Management have also helped reduce escalations on major projects, as issues can be raised to management an early stage. 

Prioritization. • CLIENT has put significant effort in ensuring that the projects are prioritized across all LOBs and that these priorities are communicated throughout the company. 

CLIENT Structure Mirrors the Business Structure. • Organizational alignment between CLIENT and the various LOBs ensures that everyone understands and is working on the same set of priorities. 

GPO / GSO - Decisions at the Right Level. • The introduction of Global Process Owners within the business and Global Solution Owners within CLIENT has ensured that the individuals that make decisions at the process flow level have enough detailed knowledge of their area globally to make the right decisions. 

Documented Processes. • These are key to our ability to consistently and repeatable test the impact changes may have on our systems and processes. Clear ownership assigned by prior agreement from documented processes helps decision-making when exceptions to the standard are handled.

Communication.• Focused communication ensuring the right information gets to the right people, at the right level and at the right time, is essential for a successful delivery. Early business engagement (also in system testing) ensures no last minute surprises. 

Planning. • Flexibility needs to be built into the plan with the minimum number of activities aligned to the critical path for each project, to reduce the risk of the project slipping its dates. The transition plan needs to be a validated and a repeatable plan with a sufficient amount of test cycles, started early in the project. 

Issues Handling. • Constant review of activities on the project’s critical path (and scope control). For example, if there is an issue (such as loss of an environment or loss of a key user), does this impact the critical path and, if so, how can we recover and do we need to alter the plan? In these cases a change management plan should be an integral part of the project plan.

Learning from Mistakes. • A lot of what we do in CLIENT is based on years of experience, not just of the individuals involved, but also the experience of the organization collectively. Post Implementation Reviews are taken seriously to ensure a culture of continuous improvement is in place.