ABF_BT070_PROJECT_MGMT_FRAMEWORK

AIM for Business Flows

BT.070 PROJECT MANAGEMENT FRAMEWORK

<Company Long Name>

<Subject>

Author: <Author>

Creation Date: May 3, 2006

Last Updated: April 27, 2007

Document Ref: <Document Reference Number>

Version: DRAFT 1A

Approvals:

<Approver 1>

<Approver 2>

BT.070 Project Management

Document Control

Change Record

1

Date Author Version Change Reference

3-May-06 <Author> Draft 1a No Previous Document

Reviewers

Name Position

Distribution

Copy No. Name Location

1 Library Master Project Library2 Project Manager34

Note To Holders:

If you receive an electronic copy of this document and print it out, please write your name on the equivalent of the cover page, for document control purposes.

If you receive a hard copy of this document, please write your name on the front cover, for document control purposes.

<Subject> File Ref: document.doc (v. DRAFT )

Document Control ii

Doc Ref: <Document Reference Number> April 27, 2007


Contents

Document Control............................................................................................

Introduction......................................................................................................

Purpose.......................................................................................................Background.................................................................................................Scope and Application................................................................................Implementation Decisions...........................................................................Selected Alternative....................................................................................Impact Assessment......................................................................................Related Documents.....................................................................................

Scope................................................................................................................

Scope of Project..........................................................................................Constraints and Assumptions......................................................................Risks...........................................................................................................Interfaces, Integration, Data Conversion Risks............................................Hardware, Network, Software Risks...........................................................Staffing Risks..............................................................................................Scope, Project Management Risks...............................................................Scope Control.............................................................................................Relationship to Other Systems/Projects.......................................................

Objectives.........................................................................................................

Mission Statement.......................................................................................Critical Success Factors..............................................................................Project Objectives.......................................................................................

Approach..........................................................................................................

Project Methods..........................................................................................Strategy.......................................................................................................Century Date Strategies...............................................................................Plans...........................................................................................................Client Organization.....................................................................................Locations and Network...............................................................................Acceptance..................................................................................................Project Administration................................................................................

Project Tasks, Deliverables, and Milestones.....................................................

Planning Approach......................................................................................


Document Control ii



Key Deliverables.........................................................................................Milestones...................................................................................................

Control and Reporting.......................................................................................

Control and Reporting Standards and Procedures........................................Risk and Issue Management........................................................................Change Control...........................................................................................Problem Management.................................................................................Status Monitoring and Reporting................................................................Reviews......................................................................................................Progress Reporting......................................................................................

Work Management...........................................................................................

Work Management Standards and Procedures.............................................Communication Model................................................................................Meeting Preparation....................................................................................Meeting Structure........................................................................................Workplan Control.......................................................................................Financial Control........................................................................................

Resource Management......................................................................................

Resource Management Standards and Procedures.......................................Staff Resources...........................................................................................Project Team...............................................................................................Project Roles and Responsibilities...............................................................Education and Skilling................................................................................Physical Resources......................................................................................Project Software/Tools................................................................................Hardware....................................................................................................Project Environments..................................................................................Software Backup Procedures and System Administration...........................

Quality Management.........................................................................................

Quality Management Standards and Procedures..........................................Quality Reviewing......................................................................................Quality Auditing.........................................................................................Test Management........................................................................................Test Strategy...............................................................................................Test Levels..................................................................................................Test Execution............................................................................................Measurement...............................................................................................

Configuration Management...............................................................................

Configuration Management Standards and Procedures................................Configuration Definition.............................................................................Document Control.......................................................................................Configuration Control.................................................................................Knowledge Management.............................................................................Release Management...................................................................................Configuration Status Accounting................................................................


Document Control ii



Configuration Audit....................................................................................

Appendix A - Workplan....................................................................................

Appendix B - Roles and Responsibilities..........................................................


Document Control ii


Introduction

The purpose of the Scope, Objectives, and Approach document is to serve as an overall reference point for an Oracle business flow based implementation, defining project components such as scope, objectives, organization, architecture, and roles and responsibilities for resources to manage project tasks and deliver appropriate business solutions critical to project success.

Purpose

The purpose of this Project Management Framework is to define the approach to project management and quality control that will be applied to the <Project Name> project for <Company Long Name>.

Commonly referred to as the “Scope, Objectives and Approach” (SOA) document, this document details the overall scope of the project, including key assumptions, constraints, and risks. It outlines how scope will be controlled and managed and it discusses any relationships this project may have on other initiatives within the organization. The document also is intended to gain consensus around the key objectives of the project – the project mission and critical success factors.

The bulk of he document is dedicated to a detailed discussion of the overall implementation approach. The major topics include:

Methods and Strategies

Organization

Infrastructure

Acceptance

The planning approach – Tasks, Deliverables and Milestones

Control and Reporting – status, risks, issues, problems, etc.

Work Management – meetings, communication, workplan and financial controls, etc.

Resource Management – staffing, project team organization, roles and responsibilities, training and skills requirements, physical resource requirements, etc.

Quality Management – quality reviews, testing, etc.

Configuration Management – document control, release management, etc.

File Ref: document.doc (v. )

Document Control ii

Doc Ref:

Business Flow Implementations

Oracle Consulting (OC) has developed an implementation strategy designed to minimize complexity and, instead, focus on key business flows and the integrated internet applications that support them. Leveraging internet business practices inherent in Oracle's integrated E-Business Suite, the Business Flow Implementation delivers module feature/functionality using predefined business flows as a vehicle from which to start the implementation process.

This approach uses predefined business flows and processes, applications setups, test scripts, training documentation, and delivery templates as a means of accelerating and simplifying the implementation.

Potential benefits to be derived from a new approach based on Business Flows include:

Improved communications

Accelerated implementation timeframes

Improved quality of solutions

Reduced customizations

Improved ROI for Customers

Because Business Flows are expressed in neutral business language, they improve our ability to communicate with customers about how they can manage their business using Oracle Applications. They provide a leading practice approach, which can be used as a standard from the very outset of an engagement, to communicate the future process model and reduce time, cost and risk.

Since the business processes incorporated in Oracle Business Flows are pre-tested, proven, and represent complete end-to-end solutions, there is less likelihood that problems will be encountered with implementations based on them. Business Flows also demonstrate how customers can manage their business using standard functionality only, providing an effective counterweight to arguments in favor of non-critical customizations/extensions.

With every investment in technology undergoing greater scrutiny in today’s environment, it’s more important than ever to realize faster return on investment from new software systems. The combination of accelerated implementation timeframes, and reduced overall cost attainable with a flow-based implementation approach increases the probability that we can deliver improved ROI for customers. Furthermore, each flow is delivered with an associated set of predefined KPIs and standard application/BI reports that measure them. Using these accelerators, the implementation team works with the client to determine achievable targets. Subsequently, the actual implementation is focused on achieving the defined targets. In this way, ROI is surfaced in the implementation


Document Control ii

Doc Ref:

so that the success of the software and implementation is measured in terms of achieving ROI instead of just getting the client “live”.

For most customers, Oracle’s pre-defined business flows will serve as a starting point, or baseline, for developing a tailored solution. While the pre-defined business flows may be suitable for some smaller clients without modification, most customers, particularly large enterprise customers, will likely “personalize” the flows to meet their unique requirements.

Business Flow Defined

A business flow is a sequence of related business processes designed to achieve a critical objective. Business flows often cross organizational and application boundaries. A business process is a planned series of work activities with defined inputs and results.

Oracle Business Flows are crucial process flows that deliver measurable value to Oracle customers. Flows reflect standard business practices for an industry, and are optimized for Oracle Applications. They represent a leading practice approach to employing Oracle’s E-Business Suite to satisfy common business requirements, which can be used as a standard in implementations to communicate the future process model.

Beginning the implementation with a pre-defined future process model, makes it unnecessary to spend valuable time reviewing current business processes, developing future process models, and defining detailed business requirements, resulting in significant savings in time and cost for the customer. Flows provide a baseline solution that is then personalized for each customer through the flow-based implementation approach.

Business Flow Content

In addition to the Future Process Model (BP.080), which depicts the Business Flow and its collection of business processes, a number of other deliverables will typically be built to complement each business flow, these may include:

KPIs – each flow is associated with a standard set of KPIs which can be reported on throughout the implementation using standard application/BI reports

Business Procedures – these Oracle Tutor-built procedures, based on the business processes contained in a given Business Flow, explain how to execute each business process within the Oracle Applications Suite.

Test Scripts – these pre-seeded System Test Scripts (TE.040) document the steps necessary to verify proper functioning of each business process contained in a given Business Flow. These test scripts are also useful in walking customers through the business processes to familiarize them with the overall Business Flow.


Document Control ii

Doc Ref:

Business Flow/Application Product Cross-reference – the Business Requirements Mapping document (BR.030) provides a listing of all Application products that must be configured to support a given Business Flow. It may also document the specific features or functions within those products required to enable the associated business processes.

Operational Management Reporting – this deliverable (TA.060) describes the various standard reporting and query tools available within the Oracle E-Business Suite, that can be used to manage the operations addressed by a given Business Flow.

These pre-seeded materials, and others that may be built to support Business Flows, will be leveraged throughout a flow-based implementation to communicate with the customer, validate the business solution, and help to accelerate the overall implementation timeframe.

How a Flow-Based approach differs from a Traditional AIM Approach

A flow-based implementation approach differs from a traditional AIM approach in several ways. The chief differences include:

A business process focus

A KPI focus

A predefined Future Process Model as a starting point

Follows Dynamic Systems Development Method (DSDM) principles

Early introduction of hands-on testing

Iterative testing cycles

Requirements Mapped to Business Flows

A Business Process Focus

While AIM 3.0 incorporates the use of pre-defined process models as a starting point for modeling current and future business processes, this aspect of our current method has not been widely adopted. In practice, most project teams continue to conduct engagements with an emphasis on implementing products, features and functions, rather than business processes.

A flow-based implementation approach, by contrast, has integrated business processes as its central focus. The emphasis is on communicating how the business can be managed using predefined business flows representing leading-practice employment of Oracle Applications, rather than on the implementation of product features and functions.


Document Control ii

Doc Ref:

A KPI Focus

Most implementations at Oracle are deemed “successful” after all the data has been converted, and the process can be run end to end with no errors – i.e. we have taken the client “live”. This perception of success is not always shared by senior executives in the client organization. Senior executives are typically looking for a defined return on investment manifested by measurable improvements in specific areas of the business.

In a business flow implementation achievable targets are set for specific KPIs associated with each flow. As the implementation progresses, test scripts are executed as part of an iterative testing cycle which measure these KPIs. Strategies are in turn developed which allow the customer to achieve the anticipated targets. Sometimes these strategies may go beyond the implementation cycle and into the post production phase.

A Predefined Future Process Model as a Starting Point

In a traditional AIM, “assemble to order” engagement, the future process model is defined during the course of the engagement. While pre-defined process models, can be used to help focus process modeling activities, the possibilities are typically open-ended, and the time and effort required to finalize the model, and reach consensus, can be significant. Additionally, the open-ended nature of such modeling activities, coming shortly after a review of current business practices, often results in future business processes that require customizations/extensions to the standard Application software.

In a flow-based implementation, predefined Business Flows are used as the starting point for defining the future business processes. By positioning business flows from the start as leading-practice use of Oracle Applications, and employing iterative, hands-on testing cycles to refine the model rather than traditional process modeling work sessions, it’s possible to eliminate both the current business process review and future process modeling activities, thereby achieving significant timesavings.

Effectively demonstrating how the customer can operate the business using Business Flows through hands-on experience also increases the likelihood that the Application software will be implemented without customizations or extensions.

Follows Dynamic Systems Development Method (DSDM) Principles

AIM currently follows a traditional information systems engineering approach. This approach, commonly referred to as a “waterfall” approach because it relies on the uninterrupted cascading of information from one phase of the development cycle to another, is embodied in AIM’s phased structure consisting of Definition, Operations Analysis, Solution Design, Build, Transition, and Production. One characteristic of the ‘waterfall” approach is its susceptibility to delays and cost overruns when new or changed requirements are identified late in the process.


Document Control ii

Doc Ref:

The flow-based implementation approach will adopt the DSDM principles of rapid prototyping and iterative development, among others, to help ensure that cost and schedule are effectively managed should requirements change during the engagement. Through repetition and active user involvement, the flow-based approach should reduce risk and more quickly converge on a suitable business solution for the customer.

Early Introduction of Hands-on Testing

In a traditional AIM approach, a good deal of time is spent early in the engagement (i.e., Definition and Operations Analysis phases) reviewing current business processes, defining future business processes, documenting business requirements, and mapping those requirements to the Application functionality. It often can be weeks, or even months, before the customer has the opportunity to work in an environment that reflects the customer’s proposed solution.

With a predefined Future Process Model (i.e., Business Flows) serving as the starting point for a flow-based approach, there is no need to invest time and effort in those activities. The new system solution is already defined to a great extent. An environment reflecting that proposed solution can quickly be established, and the customer can begin working with the system at a very early point in the implementation.

The early introduction of hands-on testing and experimentation by the customer is key to accelerated progress. Providing the customer with the opportunity to work with the new system early in a Conference Room Pilot setting helps to build confidence in the solution, and begin the validation/refinement process sooner.

Iterative Validation Cycles

In a traditional AIM approach, Business System Testing, commonly referred to as a Conference Room Pilot, takes place in the Build Phase. This often times is the first opportunity a customer has to work in an environment that simulates their future production system. While a system test may be repeated to verify correction of a problem encountered in an earlier test cycle, the purpose of the testing is primarily to validate the solution crafted during the Definition, Operations Analysis, and Solution Design Phases.

In a flow-based approach, business system testing also serves to validate the solution. However, it begins earlier in the project, and two or more cycles of testing/validation are planned in advance. There is also an expectation that certain refinements will be made to the baseline solution at the conclusion of the first, and possibly second, test iteration. The changes identified during the first test/validation iteration are applied to the system environment before commencement of the second test cycle, and this updated environment then becomes the baseline for the second iteration.

In a flow-based implementation approach, iterative business system test/validation cycles serve the same function as process modeling and


Document Control ii

Doc Ref:

business requirements mapping sessions do in an AIM engagement. They define/validate the future business process model, and verify that the customer’s business requirements are being met through hands on use and validation of the system, as configured.

Requirements Mapped to Business Flows

In a traditional AIM approach, detailed business requirements are typically mapped to features and functions in the application software. While features and functions are built into the Applications specifically to address customer requirements, a requirements mapping exercise that neglects to consider the integrated nature of business processes may result in a disjointed solution, which lacks the integration needed to maximize efficiency.

In a flow-based implementation approach, business requirements are mapped to the business flows through refinement of the pre-defined configuration of the baseline system. By mapping requirements to the pre-defined, integrated flows, the end-to-end integrity of the flow, and therefore the resulting solution, is preserved. Where required, detailed requirements may be mapped to features in the software, but this should always be done in the context of the flow-based solution.

Risk Mitigation Benefits

A flow-based approach, by its nature, provides a number of benefits that serve to mitigate risks associated with software implementation engagements. These benefits include:

Rapid Installation and Stabilization of a Certified Implementation Environment

Scope Control

Improved Issue Resolution

Iterative Testing/early hands-on experience for customers

Performance Testing is Built-In

Rapid Installation and Stabilization of a Certified Implementation Environment

By employing implementation environments containing the entire E-Business Suite certified on the same release level, such as Platinum e2 environments, the customer and delivery team are assured of a stable environment that can be used for initial hands-on testing/validation (CRP I) within days of the start of the engagement. Delays normally associated with software installation, patching, and establishment of a stable software environment in which to begin work are therefore minimized/avoided.

Scope Control


Document Control ii

Doc Ref:

Because a flow-based approach begins with one or more pre-defined business flows, which prescribe the solution to significant degree, the ability to control scope and limit “scope creep” is greatly enhanced. Flows have been optimized for Oracle software and provide a much stronger, even optimal, starting point from which to begin experimentation. With requirements measured against the pre-defined flows, rather than against business processes defined in open-ended modeling sessions, the effort focuses on “personalizing” the flows instead of building a solution from scratch.

With flows to guide the definition of an overall solution, and with no need to explore current business processes/practices, there is less need to customize or extend the standard software, which also contributes to improved scope control.

Improved Issue Resolution

With thirty percent, or more, of TARs submitted eventually being attributed to setup issues, significant improvement in issue reduction/resolution can be achieved by starting the implementation from a working, certified, pre-configured, and fully tested environment.

When used, e2 environments also expedite issue resolution because of the direct involvement available from Product Development. Because Development is aware of issues nearly at the same time Consulting is, they can act proactively to resolve the problem, and improve the overall experience for the customer.

Iterative Testing/early hands-on experience for customers

The early introduction of hands-on testing contributes to improved buy-in by the customer. Seeing the software working early on builds confidence and helps to control scope by keeping the focus on how flows support the business needs of the enterprise.

Because testing starts early, user involvement begins much earlier also. Early engagement by users tends to lessen their concerns about introduction of a new system. This contributes to building confidence among users, that there will be no surprises when the system is promoted to production status.

Performance Testing is Built-In

Because flows are pre-defined and pre-tested, the high volume transactions can be identified up front. Consequently, performance testing related to those transactions can be incorporated early on to help ensure satisfactory performance in a production environment.

Background

<Company Long Name> is


Document Control ii

Doc Ref:

<Company Long Name> has the following business goals:

<Company Long Name> has engaged Oracle Consulting to execute the <Project Name> project. The <Project Name> is intended to

The objectives of the project are:

to implement an information system that provides information in a timely manner to support management

to implement an integrated system that provides access to all appropriate users of business information

to standardize internal reports that deliver relevant information to the end user

to implement a system that is flexible and can be upgraded as necessary

to improve efficiency through the automation of manual processes

to achieve a high ROI (return on investment)

In order to meet these objectives, the following Oracle Business Flows will be implemented:

The AIM for Business Flows methodology will be used as the overall approach to project implementation. AIM for Business Flows incorporates the use of Oracle Business Flows, associated software environments, and tools, to keep the focus of an implementation on business processes and benefits, instead of software features and functions.

Some hallmarks of the AIM for Business Flows approach include:

A Business Process Focus

Use of pre-configured Oracle Business Flows and associated pre-configured delivery assets as the starting point for the Future Process Model

Rapid establishment of a pre-configured software environment, based on Oracle Business Flows, for use in mapping Flows to the customer’s business


Document Control ii

Doc Ref:

Early introduction of iterative hands-on testing cycles

Central to the AIM for Business Flows approach is the use of a pre-configured environment and software tools for quickly establishing, and reestablishing, a fully configured, working environment at predetermined points during the project. It is important to recognize that the use of a pre-configured environment does not restrict the implementation of a final solution that is fully tailored to the customer’s requirements. Instead, the pre-configured environment serves as “starting point” for mapping Oracle Business Flows to the customer’s business, and the identification of changes needed to “personalize” the environment to suite the customer’s needs.

Critical success factors are key elements that need to be in place to facilitate successful achievement of project objectives.

The critical success factors for meeting the above stated implementation objectives are:

to have <Company> adopt where ever possible the applications features/functionality supported by the standard business flows being implemented

to have <Company> project team members accept ownership and accountability for the success and implementation of the Oracle Applications

to establish clear and measurable project objectives and business process requirements

to implement and execute project scope control procedures

to provide ongoing progress monitoring ( for example, compare progress to project workplan, project milestones, and objectives)

to adopt a strategy of developing or modifying business policies and procedures based on the standard core functionality of the Oracle Applications

to identify and secure the appropriate individuals for the roles and responsibilities of the project team

to avoid customization of the Oracle Applications

to reduce reliance on external consulting resources and provide a successful transition to <Company> end users

to address and close issues rapidly

to review and accept project deliverables in a timely manner

Scope and Application

This Project Management Framework defines the following topics for Project Management of the <Project Name> during the <Project Phase>:

Scope


Document Control ii

Doc Ref:

Objectives

Approach

Project Tasks, Deliverables, and Milestones

The following topics will address the standards and procedures to be followed on the project:

Control and Reporting (issue management, scope change control, progress reporting, etc.)

Work Management (management of tasks and project budget information)

Resource Management (management of staff including Roles and Responsibilities, as well as physical resources)

Quality Management (reviews of deliverables, testing, Healthchecks, etc.)

Configuration Management (how project intellectual capital and software are to be managed.)

The plan will be applied to both Oracle and <Company Short Name> responsibilities across the project.

The Project Management Framework defines the implementation of the project for the defined scope as well as how to meet the defined objectives using the defined approach.

Named Users

The customer has forecast <x> named users initially, with an additional <y> users planned subsequently.

Technical Architecture

<Company> is implementing a 3 tier network computing architecture that includes the following components:

<Hardware Servers>

<Operating System>

Oracle Applications Release x

Oracle RDBMS Version x

Applet Viewer Version x

Netscape Browser Version x

3 RDBMS environments Demo, Test & Production

2 installations of the Oracle Applications against the following environments:

Test

Demo & Production

<PC/NC workstation configuration>


Document Control ii

Doc Ref:

<network information>

Implementation Site

Implementation will occur at <Company>’s headquarters in <location> for the project duration. Any key customer staff required to participate will be expected to travel to the customer’s headquarters site.

Deployment Site

Deployment will principally focus on users at the <Company>’s headquarters location. There may be additional users connected via the company WAN, but there will be no distributed processing or multiple applications environment across sites.

Applications

The following Oracle Applications are included within the scope of <Project Name> during the <Project Phase>:

Refer to the BR.030 for each flow for more detail.

The implementation is targeted to commence <date> and complete <date>.

Plus Functionality/Applications

Each Oracle Business Flow implements a discrete set of Core applications functionality as defined in BR.030 Business Requirements Mapping (Core/Plus) document. This document provides a detailed description of core functionality that is included in the solution and plus functionality which is not included. This document resides with the solution deliverables.

The following plus items are included within the scope of <Project Name> during the <Project Phase>:

Business Process Reengineering

<Company> acknowledges that business process reengineering is not within the scope of the <Project Name> during the <Project Phase>:


Document Control ii

Doc Ref:

Customizations

The following (including custom reports) are included within the scope of the <Project Name> during the <Project Phase>:

Chart of Account Design

<Company> is going to implement the following COA design:

Company

The company segment will be 2 characters in length, alpha-numeric and will be displayed in the 1st position.

Cost Center

The cost center segment will be 3 characters in length, alpha-numeric and will be displayed in the 2nd position.

Account

The account segment will be 6 characters in length, alpha-numeric and will be displayed in the 3rd position.

Future

The future segment will be 4 characters in length, alpha-numeric and will be displayed in the 4th position.

Data Conversions

The following data conversions of pertinent and valid business objects will be necessary in order for the final solution to be operational. Manual conversions will be done by the <Company>’s project team:

Chart of Accounts

Application: Oracle General Ledger

Strategy: Manual

Scope: A new COA will be developed and will be entered manually.

Prior Period Activity


Strategy: Manual


Document Control ii

Doc Ref:

Utilize a spreadsheet based mapping process (map old COA segment values to new COA) - prior period activity can then be entered as manual journals.

Scope: Closing balances for the prior fiscal year will be entered as well as period summary activity for the following periods:

periods 1-12

Budgets


Strategy: Manual

Utilize a spreadsheet based mapping process (map old COA segment values to new COA) - current fiscal period budgets can then be entered as manual budget journals.

Scope: Budget journals will be entered for the following periods:

<period 1>

<period 2>

Vendors

Application: Oracle Purchasing/Payables

Strategy: Manual

Data should be manually reviewed and ‘cleaned-up’ prior to manual entry into the new system.

Scope: All current vendors

Employees

Application: Oracle Payables/Purchasing

Strategy: Manual

Scope: All current employees

Open Invoices

Application: Oracle Payables

Strategy: No data conversion


Document Control ii

Doc Ref:

Open invoices can be paid out of legacy system while invoices received subsequent to production cut-over will be processed into Oracle Payables.

Invoice History



Invoice history will be available for view in legacy system for a period of <x> months.

Payment History



Payment history will be available for view in legacy system for a period of <x> months.

Open PO Lines

Application: Oracle Purchasing

Strategy: Manual

PO lines that have remaining quantities for receipt will be entered manually into Oracle Purchasing to support subsequent invoice matching.

Scope: All current open PO lines

PO History



PO history will be available for view in legacy system for a period of <x> months.

Requisitions




Document Control ii

Doc Ref:

Requisition history will be available for view in legacy system for a period of <x> months.

Asset Base

Application: Oracle Assets

Strategy: Manual

Active assets will be manually entered into Oracle Assets at calculated net book value and depreciated over the remaining months of their life cycle - due to the nature of the depreciation calculations (for example declining balance calculations), minor rounding differences will occur.

Scope: All active, material assets

Asset Transaction History

Application: Oracle Assets


Asset history will be available for view in legacy system for a period of <x> months.

Customers

Application: Oracle Receivables

Strategy: Manual


Scope: All active customers

Open Invoices


Strategy: Manual


Scope: All current invoices

Invoice History



Document Control ii

Doc Ref:


Customer invoice history will be available for view in legacy system for a period of <x> months.

Payment History



Customer payment history will be available for view in legacy system for a period of <x> months.

Bank Statement History

Application: Oracle Cash Management


Customer bank statement history will be available for view in legacy system for a period of <x> months.

Interfaces

Below is a list of interfaces between Oracle and existing systems that have been identified:

Source Application Destination Application Mechanism Business Objects Transferred

Triggering Event Frequency Data Volume

Century Date Compliance

In the past, two character date coding was an acceptable convention due to perceived costs associated with the additional disk and memory storage requirements of full four character date encoding. As the year 2000 approached, it became evident that a full four character coding scheme was more appropriate.

In the context of the Application Implementation Method (AIM), the convention Century Date or C/Date support rather than Year2000 or Y2K support is used. It is felt that coding for any future century date is now the modern business and technical convention.

Every applications implementation team needs to consider the impact of the century date on their implementation project. As part of the implementation


Document Control ii

Doc Ref:

effort, all customizations, legacy data conversions, and custom interfaces need to be reviewed for Century Date compliance.

The initial, and on-going, planning efforts associated with this applications implementation project will take into account the impact that previous and current coding standards have on the current implementation project underway. These considerations should address areas, such as custom extensions, data conversions, and interfaces to other applications within the overall system.

Implementation Decisions

The critical implementation decisions applicable to this project are:

Selected Alternative

Decisions Description

Will processes be standardized?Will we implement the “vanilla” system or will we customize?How far will information be distributed and used?Will we apply centralization or decentralization (overall and by function)?Will the technology be implemented by phases or a “big bang” approach?Will we run parallel systems or not?

Impact Assessment

Critical Implementation Decision

Rationale for Decision

Major Impact on Technology

Major Impact on Processes

Major Impact on People

Consequences of Impact/Actions to Manage

Standardization improve production controlincrease qualityenhance customer focusimprove decision making and sharing of informationincrease flexibility based on consistencyspeed up comparisonreduce administration cost

buy hardware/softwarechange hardware configurationchange network

reduce approval requirementsrealize economies of scaleadjust task measurementscreate task to maintain standards___ number of process impacted

adjust individual accountabilityadjust individual performancereduce support services to employeesimprove resource management___ number of people impacted

need to develop exception rulesspecific custom applications may be lost (for specific organizations) - may lose data related to thatneed intercultural negotiationsneed clear decision making process and determine who/what scenarios have priorityneed inventory of hardware/softwareneed a whole new reskilling effort for the new processes/rolesneed new documentation


Document Control ii

Doc Ref:







Vanilla or customization

allow for outsourcingoptimize cost of development/maintenancetake advantage of web platform, ECommercework with availability of skills sets

increase ease of upgradereduce cost of upgradeadjust hardware/softwarestreamline systems/platforms

determine drive: technology or businesschange processeslose business requirementsincrease ease of benchmarking

lose functionalities and customizations to which people are accustomed (sense of loss, impacts acceptance)lose perceived service level by the customer lose competitive edgeincrease need for reskillingincrease resistance around “not invented here”reduce dependency on internal development/customization skill set

need to manage the perceived loss of functions and customizationneed to redeploy people (involved in development/customization)

Distribution and use of information

enhance customer knowledgeincrease quality/ability to customize relationship with customers (improve customer service)improve error/defect trackingincrease productivity

change hardware/software requirements (for example, On-Line Analytical Processing [OLAP])design a web/intranet sitegive corporate-wide accessincrease security requirements.....

develop new information tracking process, for example, wider access to data requireddevelop new information proceduresimprove confidentiality rulesadd new/replace tasksreduce redundancy and mechanical tasksadd support task__ number of processes impacted

adjust decision making with ready access to company-wide information and client contactincrease people voice/inputensure validityadd responsibility and accountability for data integritygive more accountability for use of repository__ number of people impacted

need to increase computer literacy and general reskillingneed to instill empowering model to support decision making expectations (might require adjustment of management culture)need to strengthen non-disclosure agreementneed to encourage sharing of information (let go of power of information)need new performance reinforcementsneed to increase security measures

Centralization or decentralization (overall and by function)

improve quality controlchange number of people involved reduce costincrease people involvement

change hardware/software requirementsre-distribute hardwareincrease system securitymanage data replication

reduce non-value add tasksreduce delay between tasksmodify approval flowchange task outputmodify procedures__ number of processes impacted

change nature of work groups, for example, autonomous, self-directedchange job requirementsmodify management approachmodify skill profile__ number of people impacted

need to empower people (in centralized or decentralized roles)need to change distribution of power among functions/business units/management layersneed to adjust organizational structure to reflect new flowsneed to update job descriptionsneed to adjust compensation, rewards and recognitionimplement Wide Area Networkimplement new access procedures

Phased or “big bang” approach

adjust quality/regulatory compliance requirementsincrease speed to marketincrease competitivenessposition organizational requirements, for example, redeployment

support release can change amount of concurrent systems increase data synchronization issues (duplication issues )

increased maintenance requirementsmanage concurrent/redundant processesimpact timing of regulatory requirements (conform to)risk to data integrityrisk of the availability of systemrisk to customer service quality levels

impact scope/pace of change (might reach level of saturation)impact length of project, for example, loss of momentumincrease risk level/stakeimpact the ability to benefit from lessons learnedimpact learning curveimpact end-user resistance/acceptance

instill more radical maintenance programimplement stress management systempublish new proceduresaccelerate knowledge management programdocument lessons learnedmanage sense of urgency


Document Control ii

Doc Ref:







Parallel systems impact perception of risk (parallel systems might indicate risk avoidance)impact customer service levelsreduce ROI (Return On Investment)impact ability to validate data (automation of verification process)

increase amount of reconciliation work

maintain duplicate procedureslose economy of scale

prolong “crutch” approach/increase safety/reduce stakesduplicate workload, resource requirementsincrease chance for resistors to sabotage

need to increase resourcesneed to lengthen time frame

Outsourcing increase focus on core competenciesreduce cost

lessen technology requirementsincrease compatibility requirementsimpact development time

document proceduresincrease need to justify requirements (because paying for them in more visible way)

reduce skill set requirements for general use, maintenance and research and developmentlose “historical” knowledgeincrease dependency on exterior partyimprove training/familiarization/ramp up curve

need to redeploy people (involved in development/customization)need to define and document procedures and agreements with outsourcing provider(s)account for learning curve

Related Documents

1. Oracle Proposal for <Project Name>

2. <Contract> (full title of contractual documentation, plus document reference number and version)

3. WM.020 Workplan

4. BP.080 Process Diagram

5. BR.030 – Flow/Applications Mapping (Core/Plus)

6. TE.040 – Test Script

7. CV.010 Data Conversion Requirement and Strategy

8. PT.010 Defining Performance Testing Strategy


Document Control ii

Doc Ref:

Scope

Scope of Project

The scope of this project is to:

Implement the functionality of the identified Oracle Application modules as defined by the Oracle Business Flows (BF) in scope of this engagement.

The scope of this project includes a number of areas. For each area, there should be a corresponding strategy for incorporating these areas into the overall project.

Business Flows In order to meet the target production date, only these business flows will be implemented:

Applications In order to meet the target production date, only these applications will be implemented:

Sites These sites are considered part of the implementation: ...

Process Re-engineering

Re-engineering will ...

Customization Customizations will be limited to ...

Interfaces The interfaces included are:

Architecture Application and Technical Architecture will be three single or multi-node environments either on the client hardware or on hosted hardware sourced from Oracle’s latest version of Platinum. Patching of all environments will only be for issue resolution. No new functionality patches will be applied. Maintenance of all environments will be provided by Oracle resources.

Conversion Only the following data and volume will be considered for


Document Control ii

Doc Ref:

conversion: ...

Testing Testing will include only ...

Funding Project funding is limited to ...

Training Training will be

Education Education will include ...

All of the above-listed elements comprise the scope of the project. These will be included in the Project Workplan and appropriate resources will be provided by the executive sponsors.

Constraints and Assumptions

The following constraints have been identified:

The following assumptions have been made in defining the Project Management Framework:

The standard Oracle Business Flows will be used as the basis (starting point) for definition of the future process. Analysis of client current process will be limited or will not occur.

Risks

The following risks have been identified that may affect the project during its progression. These and any other risks identified later will be tracked through the Risk and Issue Management process defined later in the Project Management Framework.

Business Flow Risks

Impact Name Description Mitigation Strategy

High Lack of Business Flow fit to client’s

The delta between the current process (legacy

Set clear expectations regarding what


Document Control ii

Doc Ref:

future process. system) and the future process (oracle business flow(s)).

the flows provide at the onset.

High Flow ImplementationExperience

The project team’s understanding, experience, and knowledge of flow implementations

Training. Effective screening of the Project Team before staffing the project.

Medium Applying Patches/Patch Management

Strong configuration management, good regression testing plan, understand what the patch affects on the flows, start with certified environments whenever possible, effective communication with development

Medium Customer Acceptance & Support of Approach

Address issue early and at a high level with the client, Consider using AIM

Medium CRP Execution

Training, clearly plan the CRP’s and set expectations, experience, clearly communicate customer’s obligations

Interfaces, Integration, Data Conversion Risks

Delivery of the Design of <Integrated System or Technology Solution>

Risk: High


Document Control ii

Doc Ref:

Consequence: Delay the project (business process mapping)

Contingencies:

1. Hire external resources to facilitate completion

2. Build Temporary links to legacy systems

3. Modify the design of the <integrated system or technology solution> so that the project is not delayed.

Early Mitigation: <Consultant> involvement to review design to date and periodically throughout the operations analysis phase.

Changes may be Required to the Feeder Systems

Risk: High

Consequences: Project delay

Contingencies:

1. Devise workarounds

2. Allocate additional resources required to accommodate changes

Early Mitigation: Attempt to identify where changes may be required as early as possible

All Required Conversion Data may not Exist in the Current Legacy Systems which are being Replaced by Oracle Cooperative Applications

Risk: High

Consequence: Functionality of Oracle Cooperative Applications (with regard to accessing history) may be comprised

Contingency: Must be controlled by aggressive project management

Early Mitigation: Same as contingency solution

Implementation of this Project will Impact <Company Short Name>’s other Current System Initiatives

Risk: Low

Consequence: Some functionality will be lost and potential non-compliance with <Company Short Name>’s information architecture

Contingency: Modify source systems or interface from the new financial system

Early Mitigation: Maintain open communications with other project teams


Document Control ii

Doc Ref:

Data Conversion of Existing Data to the New Applications is in Error or Inadequate

Data in existing legacy systems to be converted will require clean up in some cases. Assumptions will need to be made during data conversion with respect to the consistency and accuracy of this cleaned up data. Often, on-going problems with converted data will occur following conversion..

Risk: Low

Consequence: Possible on-going problems with converted data in new environment resulting in additional maintenance of data following go-live.

Contingency: None.

Early Mitigation: Early identification of data problems and cleanup on the legacy side prior to conversion to the new applications.

Hardware, Network, Software Risks

Hardware Server(s) not Available for Business Mapping Purposes <date>

Risk: High

Consequence: Delay operational analysis phase

Contingency: Utilize a third party server

Early Mitigation: IS will investigate existing capacity and will order new server(s) by <date>

Planned Oracle Cooperative Applications Releases are not Available to Support the Workplan

Risk:

Consequences:

1. Required functionality may not be delivered

2. Users may need retraining

3. Additional resources may be consumed with upgrades

Contingency: Go live on a predecessor version and upgrade at later date

Early Mitigation: Need an early as possible decision as to what version will be implemented for production (e.g. cut-off date - confirmation of scope, technology and objectives task)

Oracle Release Upgrades are not Transparent (i.e.,. Installation Implications not Easily Managed)

Risk:


Document Control ii

Doc Ref:

Consequence: Anticipated functionality not available and business processes may need to be re-mapped.

Contingency: Continue to use predecessor version

Early Mitigation: Upgrades must be managed aggressively and thoroughly researched before implementing

Performance Specifications are not Met

Risk: Moderate

Consequence: Unsatisfied users and increased processing costs

Contingency: Upgrade server capabilities

Early Mitigation: Monitor performance during acceptance testing and manage User expectations

Hardware and Operating System Environments not Available when Required

Risk: Low

Consequence: Delay the implementation or testing of applications.

Contingency: Additional contracted efforts will address any issues in this area.

Early Mitigation: Obtain required developmental environment as well as the stand alone equipment required for the financial applications

The Selected Hardware is not Large Enough to Handle the Production Load

Although preliminary sizing has been undertaken, an actual determination of the specific volumetrics for the applications will only be known after the appropriate application configuration options are selected. At that time, it will be possible to model forward the impacts on volumes and the resulting consumption of disk, CPU and memory resources.

Risk: Moderate

Consequence: Unacceptable performance in the field.

Contingency: Acquire additional hardware

Early Mitigation: Undertake a perpetual detailed sizing process thought the project as volumetrics become more evident. Determine production hardware environment as part of the technical Solution Design phase.

No Hardware Hot Backup Environment as a Result of a Major System Failure

At the present time, there is no hot-backup hardware site established to support the project or the resulting production environment.


Document Control ii

Doc Ref:

Risk: Low - Moderate

Consequence: Loss of systems availability while alternate environments are located, delay to project, possible additional costs.

Contingency: None.

Early Mitigation: Develop disaster recovery processes to minimize downtime and offset risk.

Availability of Systems

Loss of the development, or production systems environment due to hardware, software failure or errors in operations during work hours will impact the fulfillment of project tasks.

Risk: Medium

Consequence: Possible delays in project tasks, possible impacts to project milestones and/or additional costs to project to make up lost time use additional resources.

Contingency: Additional staffing to address loss in time.

Early Mitigation: Ensure that hardware/software environment is administered “as-production” during the implementation process, complete with extensive backups and high-availability..

Network Availability

Network outages would impact the ability of project team members to carry out scheduled and planned work.

Risk: Low

Consequence: Loss of the network during work hours will impact the fulfillment of project tasks.

Contingency: None.

Early Mitigation: Ensure that network provider understands and agrees to the high availability requirement

Staffing Risks

<Company Short Name> Personnel Required are not Approved by Management

Senior management support for the availability of key project personnel is critical. If management support is not available, or the nominated project personnel are not available due to business issues, the project will be impacted.


Document Control ii

Doc Ref:

Risk: Moderate

Consequence: Project commencement will be delayed as alternate personnel are sought or the project objectives including milestones are reexamined.

Contingency: None.

Early Mitigation: Seek executive level commitment and support, request communication of this support throughout the organization.

<Company Short Name> Personnel Required will not be Available Due to other Commitments/Workload

Critical to the success of the project, is the appropriate constituent representation of key users from the business areas. The participation must be consistent, and through the entire life of the implementation project. Without key decision makers being available and participating in the appropriate project activities, decisions require additional circulation and agreement occurs at a higher cost to the project and the timeline.

Risk: Low.

Consequence: Scheduled project activity may be delayed, potentially impacting project milestones or budget.

Contingency: Should personnel be unavailable the proper level of authority should be informed of the situation and steps should be taken to make the personnel available as required.

Early Mitigation: <Company Short Name> personnel should have the appropriate approvals and a clear mandate to be available as required.

<Company Short Name> Personnel that are Required do not have Sufficient Skills to Undertake the Work

Assessment is made during the project planning process as to the training requirement, aptitude and capacity to contribute for all project personnel. From time to time, this assessment may be incorrect.

Risk: Low

Consequence: Slippage in deliverables due from <Company Short Name> personnel, or inadequate level of participation in decision making.

Contingency: Initial coaching, following by escalation to the <Company Short Name> Project Manager or Management Committee for direction.

Early Mitigation: On project commencement, review with each individual the expectations for their involvement. Seek agreement with the individual.


Document Control ii

Doc Ref:

<Company Short Name> Technical Personnel Inexperienced with UNIX System Admin and Oracle Database Admin

Risk: Low

Consequence: Potential project delays as result of loss of technical environment.

Contingency: Assistance from Oracle technical resources for recovery

Early Mitigation:

Retention of Project Team Members during the Implementation

From time to time, key project personnel may be reassigned to other enterprise initiatives or leave the corporation.

Risk: Moderate

Consequence: Possible significant impact to project tasks, key deliverables, project milestone achievement and subsequently budget. Loss of key skills during critical time frames.

Contingency: Replace personnel as quickly as possible, seek transition when possible.

Early Mitigation: Ongoing initiative to augment user and technical procedures, and prepare an in-house training program.

Availability of <Consultant> Resources for Previously Scheduled Work

Like <Company Short Name>, from time to time <Consultant> may have to deal with unavailability of its resources to the project.

Risk: Low

Consequence: Possible impacts to project tasks, timelines, or milestones

Contingency: <Consultant> to seek alternate resources when available, or reasonable notice is give to allow rescheduling without impacting project costs or milestones.

Early Mitigation: Ensure that <Consultant> Resources are scheduled well in advance and avoid alterations to these schedules

Availability of <Consultant> Resources on Short Notice for Non-Scheduled Work

From time to time, the project may require additional non-scheduled participation from <Consultant> personnel. As <Consultant> is motivated to schedule its personnel in advance, <Consultant> may not be in an optimum position to respond as required.

Risk: Moderate - High


Document Control ii

Doc Ref:

Consequence: Possible delays in project tasks

Contingency: Utilize methods such as video conferencing, fax, telecommuting, email, teleconference or after hour meetings.

Early Mitigation: Schedule <Consultant>’s participation in advance, and set expectations with respect to <Consultant>’s requirement for advanced scheduling

Availability of Adequately Trained and Experienced, Low-Cost Alternate Contract Resources in Marketplace

To reduce project costs, <Company Short Name> may elect to staff some of the project roles with external contractors. It is critical that these contractors have prior experience in the tools and methods required to undertake their respective roles without further cost to the project for training, rework or orientation.

Risk: Moderate to High

Consequence: Additional training and management costs and/or shortage of resources available in the marketplace resulting in additional costs and/or delays in project milestones.

Contingency: Use additional <Consultant> resources at additional higher costs to the project.

Early Mitigation: Review CV s of all nominated personnel, and select only those with direct experience with the tools, methods or applications as appropriate. Seek vendor commitment to cover any such circumstances as above.

Scope, Project Management Risks

Subsequent Analysis during the Project drives Significant not Forecasted BPR Requirements

The project proceeds with a basic understanding of the degree of Analysis and Re-engineering of Business Process that is required. From time to time further requirements or cost savings potential drives opportunities which will rationalize additional BPR as being required.

Risk: Additional staffing, delays and/or costs to the project

Consequence: Possible delay in achievement of project milestones, possible additional cost to the project

Contingency: None.

Early Mitigation: None.


Document Control ii

Doc Ref:

Significant Changes in the Scope of the Project

Risk: Low

Consequence: Possible recasting of project objectives, costs and /or milestones.

Contingency: Move non-critical project components into subsequent phase.

Early Mitigation: Ensure that all principals agree on project scope at time of project initiation.

Ability to Define and Achieve a Consistent Series of Business Processes Across all Business Units

Risk: Low

Consequence: Additional project costs incurred as well as costs associated with supporting the different business processes.

Contingency: None.

Early Mitigation: Executive commitment to a mandate to define a single set of unified business processes, requirements and reporting across all business units.

Selected Applications Adaptable to Meet Business Requirements with Little Customization

The project assumes that the business requirements of the enterprise can be met with a minimum of customization of the base packages.

Risk: Low

Consequence: Additional cost to the project, possible additional unforecasted on-going maintenance costs.

Contingency: None.


Changes to Business Processes are Achievable and Completed Prior to Affected Project Activities

There will be some degree of changes to existing business processes within the enterprise. The assumption is that these changes will be identified during the solution design phase, and completed by he business in time to avoid impact to subsequent project activities.

Risk: Low

Consequence: Potential impact on completion of project tasks, time lines or milestones.

Contingency: None.


Document Control ii

Doc Ref:


Unacceptable Degree of Field Support (User Acceptance)

Critical to the success of both the project and acceptance of the end result is a high degree of field support. Managed input in to project processes and deliverables driven by clear executive mandate is recommended. This includes a willingness to seek a common enterprise-wide business systems solution.

Risk: Low - moderate

Consequence: Additional costs to the project as a result of having to accommodate pockets of requirement. Possible lack of input from some business units or user communities resulting in mis-defined business requirements.

Contingency: None.

Early Mitigation: Deploy a standard project review process and input methods to support an adequate level of field support for the project. Field representatives should be appointed to participate in project activities

Project Decisions are Timely, and On-Time

From time to time, groups in session or individuals will require decisions from other members of the user community, management committees. Most decisions will carry two dates: a target date and an impact date. It can be assumed that some other linked dependent task will be delayed if an impact date is missed.

Risk: Low

Consequence: Delays in project tasks, possible additional cost to the projects or ultimate impact on project milestones.

Contingency: None, outside of standard escalation.

Early Mitigation: Seek a clear project charter sponsored by all members of the management and project committees. The charter should mandate clear and timely decision making.

Review of Project Deliverables and Sign-Off is Timely

Frequently, project deliverables such as team decision recommendations, workshop documents and specifications will require approval (sign-off) prior to a subsequent task commencing. This is to ensure that we understand requirements, and subsequent effort is not wasted on misunderstood requirements. Most of these sign-offs will carry two dates: a target date and an impact date. It can be assumed that some other linked dependent task will be delayed if an impact date is missed.

Risk: Low


Document Control ii

Doc Ref:

Consequence: Delays in project tasks, possible additional cost to the projects or ultimate impact on project milestones.

Early Mitigation: Seek a clear project charter sponsored by all members of the management and project committees. The charter should mandate clear and timely review and approval of project deliverables.

Contingency: None, outside of standard escalation

Tight Time-Frames, Minimal Slack Between Dependent Tasks

Risk: Moderate

Consequence: Delay in dependent tasks; potential delay in go-live

Contingency:

Go-Live Date Accommodates Only One (1) Round of Integrated Testing

To remedy significant deficiencies not discovered during the implementation, an additional round of comprehensive testing is required (not accommodated for).

Risk: Moderate

Consequence: Additional project cost and/or delay in go-live

Contingency:

Project Milestones are not Achievable (Project Schedule)

Often business dynamics within an enterprise may prevent or work against an implementation schedule. The assumption being made is that the milestones as set out are achievable.

Risk: Low

Consequence: Missed milestones, possible delay in go-live/cut-over and additional project costs incurred.

Early Mitigation: Frequent project monitoring and review

Contingency: None.

Potential Move of <Company Short Name>’s Facilities

Risk: Moderate

Consequence: Disruption to scheduled project activities; disruption in dependent project activities; potential delay in go-live; additional costs to project

Contingency: None.


Document Control ii

Doc Ref:

Early Mitigation:

Scope Control

The control of changes to the scope identified in this document will be managed through the Change Control procedure defined later in the Project Management Framework, using Change Request Forms to identify and manage changes, with client approval for any changes that affect cost or schedules for the project.

Relationship to Other Systems/Projects

It is the responsibility of <Company Short Name> to inform <Consultant> of other business initiatives that may impact the project. The following are known business initiatives:


Document Control ii

Doc Ref:

Objectives

Mission Statement

<Company Long Name> ‘s project mission is to:

Critical Success Factors

The critical success factors to meeting the goals stated in the mission statement are:

Strong executive sponsorship and management support of the project mission and project team

Adequate project staffing for the expected goals and timeline to be met

Clear roles and responsibilities defined for the project in order to assure accountability, ownership, and quality

A committed and well-informed project manager and project team having a thorough understanding of the project mission, goals, and milestones

A comprehensive project workplan and Project Management Framework

A defined and maintained project infrastructure throughout the project duration

A thorough understanding of known project risks and assumptions throughout the executive committee and project team

Project Objectives

The objectives of the project are to:

<Objective 1> and will be measured by the timeliness and accuracy of key deliverables and.

<Objective 2>


Document Control ii

Doc Ref:

Approach

The approach includes the following main areas:

Project Methods

Strategy

Plans

Client Organization

Acceptance

Project Administration

Project Methods

Important Concepts

There are several key concepts that are important to understand in order to fully appreciate the AIM for Business Flows approach. These concepts include:

Iterative testing and revision cycles

Conducting a Conference Room Pilot

Business Flow Assets

Iterative Testing and Revision Cycles

One of the most important concepts to understand is the use of iterative testing and revision cycles throughout the project lifecycle. The graphic below depicts the the set of tasks/activities that are repeated several times in the course of an AIM for Business Flows project – once for each testing iteration.


Document Control ii

Doc Ref:

Figure 2 Iterative Testing and Revision Cycle

For each test iteration with an objective of refining the solution to better fit the customer’s business, the tasks shown above are performed. Each test iteration identifies exceptions/changes to the pre-configured environment. These are documented and categorized according to priority. Each of the exceptions is then analyzed and a resolution determined. Resolution of exceptions may include any of the following alternatives:

change in application configuration

manual workaround

custom extension, or

a decision to forego (or postpone) a change and adopt the standard Business Flow, as defined

Based on the resolutions agreed upon, the following deliverables are updated as appropriate:

Business Flows

Business Procedures (Oracle Tutor Procedures)

Application Setup documents, and associated software tools for loading the modified setup data

System Test Scripts


Document Control ii

Doc Ref:

Once all of the above deliverables are updated, a new application environment is established, using the updated software tools for loading setup data, and preparations for the next test iteration are begun– incorporating changes from the previous iteration, with the exception of custom extensions. Because of the longer lead time required to design, build and test custom extensions, they typically will not be integrated into an environmen until later in the iterative process.

Conducting a Conference Room Pilot

The iterative testing cycles utilized in the AIM for Business Flows approach are conducted in a Conference Room Pilot, or CRP, style. A Conference Room Pilot (CRP) refers to the technique and activities surrounding the planning and execution of one or more formal test scripts aimed at validating the application system against the client’s business needs. The origin of the term comes from the practice of placing workstations in a conference room and arranging them in a particular order (usually by logical process or Business Flow) for testing. Test scripts were then passed down the line from one tester to the next according to the natural flow of the business process.

A CRP usually involves performing tests to check the validity of application setups, the integration of business flows within the target application system, the validity of converted data, and the adequacy of end-user procedural documentation. Additionally, a CRP may be employed to determine the degree to which a defined Business Flow matches a customer’s business need, and to identify changes that are necessary and appropriate for the customer scenario. It is important to establish the goal of each CRP ahead of time and to then review the execution of the CRP to determine whether or not the gaol was achieved.

A Conference Room Pilot may be conducted in the traditional conference room setting, in another setting where the testers are physically co-located, or in a “virtual” conference room setting, where the testers are physically separated, but are conducting the test in the same test environment. The most important criteria is that the test scripts employed emulate actual business processes that cross functional or departmental lines accordinf to the documented business flow, and that the transaction data is inter-related and builds on itself (e.g. PO is entered for a Supplier created in an earlier script, receipt is subsequently recorded against the PO, etc.)

The following table lists the Conference Room Pilots normally included in an AIM for Business Flows project. Please note that each of these are intended to be iterated as many times as necessary to achieve the desired objectives.

Conference Room Pilot Objectives

CRP I (First Iteration) Demonstrate and familiarize the customer with the Business Flows being


Document Control ii

Doc Ref:

Conference Room Pilot Objectives

CRP I (Second Iteration) Map Business Flows to the customer’s business and identify exceptions

CRP II Validate customer Chart of Accounts, Multi-Org Structure, TCA structure and other “personalized” setups following CRP I (Second Iteration). Refine mapping of Business Flows to the customer’s business and identify any remaining exceptions. The conclusion of the CRPII iterations should result in a frozen solution scope.

CRP III Business System Test of tailored solution including custom extensions and sample converted legacy data. Refinement of solution is still an option at this point, but the scope of changes should be small by this time. Significant changes at this point may indicate the need for an additional CRP.

Table 1 Conference Room Pilots by Phase

Business Flow Assets

The AIM for Business Flows approach incorporates the use of pre-defined deliverables, software tools and other assets to accelerate implementation activities. These Business Flow Assets are prepared in advance for each Business Flow, and can be leveraged by delivery teams during a project. Some of the Business Flow Assets include:

Pre-defined Future Business Model (BP.080 in AIM 3.0 terms)

Pre-defined Oracle Tutor Procedures

Pre-defined Application Setup Documents (BR.100 in AIM 3.0 terms)


Document Control ii

Doc Ref:

Dataload Scripts

Pre-defined Business System Test Scripts (TE.040 in AIM 30 terms)

Additional assets will be developed over time. The assets listed above for existing Business Flows can currently be accessed from the E-Business Suite, Non-Industry Specific Offerings folder on GlobalXchange.

In a future release of AIM for Business Flows, all of the Business Flow Assets will be accessible through an iProjects Workspace utilizing a guided portal user interface.

Phases

Projects using the AIM for Business Flows approach are conducted in phases. Phases provide quality and control checkpoints to coordinate project activities that have a common goal. AIM for Business Flows has five phases as opposed to AIM 3.0’s six phases. The figure below shows the change in the method’s phase structure.

Figure 3 AIM for Business Flows Phase Structure

Most of AIM’s Operations Analysis Phase activities, involving the review of current business processes and procedures, have been eliminated in the new approach. A new phase called “Elaboration” includes many Design phase activities from AIM 3.0, but its new name better conveys the emphasis on refining the starting environment. Other phase names remain unchanged from AIM 3.0.


Document Control ii

Doc Ref:

Definition Phase Overview

The goal of the Definition phase is to plan the project, and rapidly establish a pre-configured and tested environment for familiarizing the customer with the Business Flows being implemented. During Definition, workshops are conducted to educate the customer on critical decsions to be made regarding application architecture components, such as the Chart of Accounts Structure, Multi-Org Structure and Trading Community Architecture. These workshops are also intended to assist the customer in defining those entities.

A second iteration of CRP I is conducted using the same environment, with the dual objectives of mapping the Business Flows to the customer’s business, and identifying exceptions/changes that are required to “personalize” the system to better fit the customer’s needs.

Definition Phase Objectives

The objectives of the Definition phase follow:

Verify senior executives’ buy-in to the project.

Facilitate crucial informed project startup decisions.

Build consensus around project direction scope, objectives, and approach.

Familiarize customer with Business Flows

Perform initial mapping of Business Flows to the business

Develop the Preliminary Conceptual Architecture (TA.030).

Determine the high-level architectural, technological, and configuration requirements to support the functional and information needs of the application system.

Define the project scope clearly.

Obtain management approval to proceed with Elaboration.

Key Deliverables

The key deliverables of the Definition Phase are as follows:


Document Control ii

Doc Ref:

Deliverable Description

Flow Educated Customer All members of the customer’s organization who have participated in CRP I (First Iteration) – intended to educate/familiarize them on the Business Flows being implemented.

Business Flows Mapped to Customer’s Business

Initial mapping of the Oracle Business Flows (and associated business processes) being implemented to the customer’s business needs.

Listing of potential changes to setups, procedures, process, or custom extensions

Documents exceptions/potential changes to Business Flows, application setups, and/or gaps in functionality identified during CRP I (Second Iteration)

Mapped Business Data Verification that the underlying target application modules, business objects, and attributes will support business processes.

Preliminary Conceptual Architecture

Documents the conceptual architecture designs for the new system. It may contain several designs, if there is more than one possible conceptual architecture, but also indicates the conceptual architecture model that is preferred. If there is only one possible conceptual architecture model, it only describes one model.

Skilled ProjectTeam All members of the team who have participated in the learning events intended to give them the knowledge and skills they need to perform their roles on the team.


Document Control ii

Doc Ref:


Project Readiness Roadmap

A plan for addressing the human and organizational factors that impact the success of the implementation. It includes a readiness strategy, implementation decisions, a communication strategy, and a learning strategy for users.

Table 2 Definition Phase Key Deliverables

Attention: Key deliverables represent the culmination, end result, or major milestone of activities performed during a phase

Elaboration Phase Overview

The goal of the Elaboration phase is to refine the solution through a second iterative testing (CRP) cycle. This second Conference Pilot provides the first opportunity to validate the customer’s tailored Chart of Accounts structure, Multi-Org structure and Trading Community Architecture. It also provides an initial look at some of the other changes resulting from changed identified during CRP I (Second Iteration).

Elaboration also encompasses the design of custom extensions, refinement of the technical architecture design, and a number of Data Conversion and Performance Testing preparatory activities.

Elaboration Phase Objectives

The objectives of the Elaboration phase follow:

Conduct CRP II to refine the solution

Validate customer’s decisions regarding Chart of Accounts, Multi-Org and Trading Community Architecture structures

Refine the technical architecture of hardware and software.

Develop performance testing models and scenarios.

Design the security architecture of the new system.

Develop functional and technical designs for custom extensions, interfaces, conversion programs, and database extensions.

Develop unit, link, system, and system integration test scripts.


Document Control ii

Doc Ref:

Design performance test scripts, test transaction programs, and test data load programs.

Analyze user learning needs and develop the User Learning Plan (AP.140).

Key Deliverables

The key deliverables of the Elaboration Phase are as follows:


Disposition/resolution of exceptions

Documents the disposition of potential changes to Business Flows, application setups, and/or gaps in functionality identified during CRP I (Second Iteration).

Updated Business Flows Revised Business Flow diagrams reflecting changes identified during CRP I (Second Iteration).

Updated Business Procedures

Revised Business Procedures Documentation (e.g. Oracle Tutor Procedures), reflecting changes identified during CRP I (Second Iteration).

Updated Application Setup Documents and Data Load Scripts

Revised definition of detailed setup parameters, reflecting changes identified during CRP I (Second Iteration). These changes are also incorporated into the related Data Load scripts for use in preparing the CRP II environment.

Integration Framework Infrastructure (Final)

A refinement of the Integration Framework Infrastructure (Initial) developed earlier, reflecting the Oracle 9iAS, infrastructure to support the customer’s systems integration requirements.


Document Control ii

Doc Ref:


Conceptual Architecture A refinement of the preliminary conceptual architecture developed earlier, following reviews by key members of the project team and the further gathering of information during the progressing project.

Application and Database Server Architecture

Provides a blueprint for the logical and physical architecture of the application and database servers. These servers are used in two of the three tiers of the architecture. This deliverable also details the configuration of these servers.

Platform and Network Architecture

Describes the deployment of the key hardware platform and network components of the new system and their relationship to the application and server architecture.

Application Extension Definition and Estimates

This document summarizes the business need that Oracle Application features cannot meet and proposes application extensions to meet that business need.

Approved Designs Provides management approval of the functional and technical designs for the application extensions reviewed and indicates management’s agreement to proceed with development.

Conversion Data Mapping

The mapping of the legacy system files and data elements to the target application tables and columns.

Conversion Program Designs

The designs that detail the program logic and rules coded in the conversion programs.


Document Control ii

Doc Ref:


Updated System Test Script

Revise the pre-defined System Test Scripts (TE.040) as required, based on changes identified during CRP I (Second Iteration). The Updated System Test Script will be utilized during CRP II.

System Integration Test Script

Develop the Systems Integration Test Script (TE.050) to test the integration of interfaces between the Oracle application system and third-party and legacy systems.

User Learning Plan Describes a customized approach for reskilling those employees whose knowledge, skills, and aptitudes need to change so the full benefit of the new technology can be realized.

Table 3 Elaboration Phase Key Deliverables


Build Phase Overview

The goal of the Build phase is to confirm that the overall solution meets the customer’s business needs. During the Build phase, the CRP III environment is prepared incorporating custom extensions for the first time, and also incorporating sample converted legacy data. Application configuration changes resulting from CRP II are also validated during this test cycle. Only minor changes should be identified, if any, during this test evolution.

Build Phase Objectives

The objectives of the Build phase follow:

Prepare the Development Environment (MD.090).

Develop, test, and accept custom software, including:

application extensions

data conversion software

custom application subsystems integrated with Oracle Applications


Document Control ii

Doc Ref:

Propose a transition strategy for moving from the current system to the new application system.

Create, test, and accept database extension and installation routines.

Finalize the solution in preparation for transition to production

Conduct CRP III with focus on validating custom extensions and converted legacy data, in addition to all other aspects of the application environment

Develop performance test components, execute performance tests, and prepare a report.

Key Deliverables

The key deliverables of the Build Phase are as follows:


Listing of potential changes to setups, procedures, process, or custom extensions

Documents exceptions/potential changes to Business Flows, application setups, and/or gaps in functionality identified during CRP II.

Disposition/resolution of exceptions

Documents the disposition of potential changes to Business Flows, application setups, and/or gaps in functionality identified during CRP II.

Updated Business Flows Revised Business Flow diagrams reflecting changes identified during CRP II.

Updated Business Procedures

Revised Business Procedures Documentation (e.g. Oracle Tutor Procedures), reflecting changes identified during CRP II.

Updated Application Setup Documents and Data Load Scripts

Revised definition of detailed setup parameters, which have been proven to support the system.


Document Control ii

Doc Ref:


Integration Framework User and Management Procedures

Describes procedures for using and managing the Oracle 9iAS-based framework integrating the Oracle system with third-party and legacy systems.

Validation-Tested Conversion Programs

The conversion programs that produce converted business objects function correctly in the target applications system.

Link-Tested Modules The Link Test Script (TE.030) is executed to test the detailed interaction between related application extension modules.

System-Tested Applications

The System Test Script (TE.040) is executed to validate that the system meets defined business requirements and supports execution of business processes.

Integration-Tested System

The integration between the target application system and other systems is tested.

Performance Test Report Summarizes the work done in defining the performance test and presents the results from performance testing. It includes the testing approach, the test models, test hardware and software configuration, test results, and conclusions.

Transition and Contingency Plan

The transition plan, implementation contingency alternatives, and former systems decommission plan are developed.

Table 4 Build Phase Key Deliverables



Document Control ii

Doc Ref:

Transition Phase Overview

During Transition, the project team deploys the new system into the organization. All the elements of the implementation must come together to transition successfully to actual production. The project team trains the users while the technical team configures the Production Environment and converts data.

During Transition, users perform an acceptance test of the new system. Transition is a demanding experience for the project team, and in particular, for the users who have to maintain exposure to two systems until a new production system is declared.

Transition Phase Objectives

The objectives of the Transition phase are:

Install data conversion programs and automated utilities.

Convert and verify legacy data.

Perform acceptance testing.

Skill user personnel.

Prepare the production environment and configure the applications.

Implement the production support infrastructure.

Verify that all aspects of the system are ready for transition.

Begin to use the Production System (PM.080).

Key Deliverables

The key deliverables of the Transition Phase are as follows:


Converted and Verified Data

Converted data in the production database that has been reviewed and verified.

Acceptance Test Results Documented evidence that the new system meets the acceptance criteria as defined in the Project Management Framework.


Document Control ii

Doc Ref:


Skilled Users Prepared users that have learned what they need to succeed in their new roles, including system literacy, procedural skills, and business skills.

Production Support Infrastructure

Activated operational infrastructure including support personnel, procedures, and other support services for the new business system.

Production System Verifies that all aspects of the system are operational and production status is achieved.

Table 5 Transition Phase Key Deliverables


Production Phase Overview

Production begins immediately with the production cutover. It marks the last phase of the implementation and the beginning of the system support cycle. A series of refinements and performance measurement steps is included in this final phase.

Production Phase Objectives

The objectives of the Production phase follow:

Provide agreed upon levels of user support.

Measure system performance and enhance as required

Maintain the Production System (PM.080).

Decommission the former systems.

Propose and plan the future business and technical direction.

Improve organizational knowledge and skills for the new environment.

Improve organizational effectiveness through continuous improvement programs.

Devote attention to post-implementation issues like user acceptance, productivity, and human performance support.


Document Control ii

Doc Ref:

Key Deliverables

The key deliverables of the Production Phase are as follows:


Effectiveness Assessment

An assessment of how well the production system and business and organizational performance meet the business objectives set at the beginning of the project.

Business Direction Recommendations

The functional project team, along with senior management, begins planning for future improvement opportunities.

Technical Direction Recommendations

The technical project team, the information technology staff, and senior management begin planning for using new technologies.

Table 6 Production Phase Key Deliverables


Processes

Processes are also changing in the new approach. The new approach contains nine processes, as compared to AIM 3.0’s eleven. The most significant change involves the replacement of three AIM processes (i.e. Business Process Architecture (BP), Business Requirements Definition (RD), and Business Requirements Mapping (BR)), with a single new process – Business Process Mapping.

The graphic below shows the changing process landscape, and highlights where the changes are significant.


Document Control ii

Doc Ref:

Figure 4 Process Structure of AIM for Business Flows

In addition to the new Business Process Mapping process, a major change is being made to the Business System Testing process to reflect the changes required by the iterative CRP activities. Updates are also being made to the Appplication and Technical Architecture, Module Design and Build, Performance Testing, and Adoption & Learning processes.

Business Process Mapping Overview

Business Process Mapping addresses the activities surrounding the customer’s initial familiarization with Oracle Business Flows, and the initial mapping of the Flows to the customer’s business. It also encompasses the definition of customer data needed to “personalize” the system for the customer, including the Chart of Accounts, Multi-Org, and TCA structures. Iterative revision activities related to Business Flows, procedures, and application setups, which are completed after each CRP cycle, are also part of Business Process Mapping.

The objectives of Business Process Mapping are:

Review Business Flows representing best use of the applications for the industry and other industries with relevant processes.

Understand and document the organizational and financial structure of the business.

Quantify the transaction and data volumes required by those

Define the audit and control requirements for the business information generated.

Document the reporting requirements of the organization.


Document Control ii

Doc Ref:

Establish each Business Flows fit to business needs.

Identify exceptions and propose initial alternatives; propose feasible bridges to gaps.

In corporate changes in systems definition documents and software tools

Application and Technical Architecture Overview

The objective of Application and Technical Architecture is to design an information systems architecture to realize the business vision. The process takes the business and information systems requirements and develops a blueprint for deploying and configuring:

Oracle, third-party, and custom applications

supporting application server environments

critical integration and data distribution mechanisms between applications, servers, and sites

computing hardware, including servers and client desktop platforms

networks and communications infrastructure

The major change in this process involves the in corporation of new integration techniques available through Oracle 9iAS. The establishment of an Integration Framework Infrastructure, and related activities are now included in this process area.

The objectives of Application and Technical Architecture are:

Define a systems framework to realize the business and information systems vision of the corporation, where the circumstances and scale of the legacy systems replacement project warrant it.

Confirm that the architecture for the replacement systems is compatible with the existing information systems framework and vision, where the scale of the replacement is more limited.

Design an architecture for the replacement systems that is compatible with the detailed business requirements.

Design a technical architecture to support the immediate processing capacity of the new system and for some specified period of future growth.

Module Design and Build Overview

The objective of Module Design and Build is to focus on the design and development of customizations to satisfy functionality gaps identified during the iterative CRP testing cycles. There are two accepted approaches to extending the functionality of the applications:


Document Control ii

Doc Ref:

Extension — new forms, reports, programs, tables, interfaces and triggers that add functionality without changing the base application code

Configurable Extension — addition of functionality through flexfields, alerts, and other configuration options provided by the Applications

Module Design and Build tasks are only required if the project team identifies gaps that cannot be satisfied with an acceptable combination of application features, manual steps, and procedural changes. Many projects begin with the goal of using the applications in their vanilla configuration, with no customizations. However, even configurable extensions, such as flexfields and alerts should be designed, implemented, and tested with the same rigor as other customizations.

The objectives of Module Design and Build are:

Design customizations to satisfy business needs not met with the standard applications.

Design application extensions that you can easily maintain and upgrade to future releases of the applications.

Build modules according to the design specifications.

Data Conversion Overview

The objective of Data Conversion is to convert and test all necessary legacy data for the operation of the new system. The first step is to explicitly define the data as business objects to be converted, along with their source systems. A business object is a physical or logical object of significance to a business. Examples of business objects include customers, vendors, items, invoices, credit memos, orders, and payments. You may need this data for business system testing, performance testing, acceptance testing, and user learning, as well as for production.

The project team then determines an overall strategy to meet the conversion requirements, defining both automated and manual methods. The process includes designing, coding, and testing any conversion modules that are necessary, as well as the conversion itself.

The objectives of Data Conversion are as follows:

Convert essential business information from the legacy system to the new applications.

Verify that converted data is accurate and supports the needs of the business.

Documentation Overview

Oracle Application manuals are the foundation of implementation documentation. The objective of Documentation is to augment the standard Oracle Applications


Document Control ii

Doc Ref:

manuals with specific information about the organization’s application extensions and specific business procedures. Using plans, procedures, and detail documents from the project, the writing staff develops supplemental user and technical materials that are tailored to the implementation. Quality documentation is a key factor in supporting the transition to production, achieving user acceptance, and maintaining the ongoing business process.

The objectives of Documentation are:

Produce a reference that shows the users how to use application functionality (User Reference Manual - DO.060).

Assemble the documents that describe the technical details of the application for the maintenance staff (Technical Reference Manual - DO.080).

Produce a set of procedures for managing the system (System Management Guide - DO.090).

Business System Testing Overview

The objective of Business System Testing is to test the quality of all of the elements of the application system. Business System Testing emphasizes a common planning approach for all types of testing and advocates the reuse of deliverable components to test successively larger aspects of the application system. Changes in this process area are related to the introduction of iterative hands-on testing evolutions and use of Conference Room Pilot techniques.

Business System Testing starts at the smallest element — the unit test (TE.070) — and expands to include the link test (TE.080), Conference Room Pilot II (TE.110), and the systems integration test (TE.120). For those environments where there are no custom extensions and no integration with legacy or third-party systems, there is no need to perform unit, link, and systems integration testing.

Finally, Business System Testing supports utilizing common testing information, including data profiles, to promote testing coordination and minimize duplication of test preparation and execution effort.

The intent of Business System Testing is to provide a formal approach to the challenge of testing. The testing approach is integral to the entire implementation effort and is structured to build upon itself. The primary deliverable of the testing process is high quality application systems that include both packaged applications and custom extensions.

Attention: Business System Testing does not address performance testing or the testing of data conversion programs; the Performance Testing (PT) and Data Conversion (CV) processes address these issues.


Document Control ii

Doc Ref:

Performance Testing Overview

The objective of Performance Testing is to define, construct, and execute a performance test on an entire system or on a particular component of a system. By implementing the process, you can establish the performance of the system or component under test and use the results to make decisions on whether the performance is acceptable for the business. If the performance characteristics you measure in the test prove to be unacceptable, you can implement tuning efforts to improve the performance quality, or more drastically, propose a change in the architecture of the system to provide the dramatic improvement you desire. Performance Testing is closely related to Application and Technical Architecture (TA) and both are mutually interdependent.

You can manage the performance quality of the system you are implementing through various project practices and methods, but the only means of getting direct information about the likely performance characteristics of your new system is to implement a performance test.

The objectives of Performance Testing are:

Define, construct, and execute one or more performance test on the entire implemented system or particular components of the system.

Provide a direct means for assessing the performance characteristics of some aspect of the new system.

Complement the functional testing performed in Business System Testing (TE) with a method for managing the performance quality in the implementation.

Encourage the use of a structured performance testing approach as a means to mitigate the performance risks in a project.

Establish a performance test model and environment that can be used for continuing performance regression testing throughout the implementation project and into production operation.

Adoption and Learning Overview

Adoption and Learning focuses on the use and acceptance of new applications by all users and the optimization of organizational performance.

Inherent in every technology change is the opportunity to become a stronger, more cohesive organization; a more efficient performer; a more agile competitor. The benefits are great, but the challenges are many. Organizations who implement new technology cannot afford to neglect key areas that might ultimately compromise the value of the technology investment. The goal is for full adoption of the new business system.

The human and organizational aspects of an implementation are often the decisive factors in its success. Adoption and Learning provides a structured approach that


Document Control ii

Doc Ref:

addresses the human and organizational acceptance and use of new applications. Adoption and Learning increases the organization’s return on investment by reducing the risks of implementing applications, increasing the productivity of all user groups, and assisting the organization to reach peak performance with the new business system.

The more quickly and effectively the business can adopt new technology, the more productive and competitive is the organization.

Adoption and Learning impacts the following five major audiences:

executives

implementation project teams

functional managers

users

information technology groups

Each of these audiences has a stake in the expected performance of the new system and can impact the success of the implementation. However, the audiences are not mutually exclusive. For example, functional managers or members of the information technology groups may also be users or on the implementation project team.

The objectives of Adoption and Learning are:

Establish a measurement system that provides an evaluation of organizational performance to determine whether expectations were met during implementation and after production cutover.

Establish executive sponsorship and management advocacy.

Increase stakeholder commitment to the new technology and resulting changes; build support for the implementation by informing, involving, and including stakeholders throughout the process.

Production Migration Overview

The objective of Production Migration is to migrate the organization, systems, and people to the new enterprise system. Following production cutover, additional objectives include monitoring and refining the production system and planning for the future.

Production Migration includes the following activities:

assessing readiness for transition to production

executing cutover to the new system


Document Control ii

Doc Ref:

conducting post-production support activities

The objectives of Production Migration are:

Prepare the production environment according to the transition plan.

Move to the production environment.

Establish support for the production environment.

Measure actual performance against expectations and plans.

Refine and tune the system to reflect business process change.

Determine future direction for business and technology opportunities.

Strategy

The project management strategies for the project are defined later in the Project Management Framework.

The following additional product delivery process strategies include:

Century Date Strategies

Century date compliance must be considered for all application implementation projects, and you will need to develop an approach for attaining century date compliance.

The following Century Date compliance strategies for the project include:

Plans

Phase

Phase includes the implementation of ....


Document Control ii

Doc Ref:

Phase


Phase ...


The detailed tasks and deliverables are defined in the Project Tasks, Deliverables and Milestones section of this document. A project Workplan is included in Appendix A.

Client Organization

Listed below are the Strategic Business Units (SBU) of <Company Long Name>:

SBU Name Current Software Current hardware Oracle ProductImplemented

Locations and Network

There are <Number of Sites> number of sites that comprise the <Company Short Name> information network.

These sites are connected by way of

The pilot site is <Pilot Site Name>. The choice of <Pilot Site Name> as the first site for implementation considers the size, risk, and resources assembled for the project. The primary reasons for selecting this site for the pilot are:

Acceptance

The <Project Name> will go through acceptance by <Company Long Name> when all deliverables are completed. The procedure to be used for this is as follows:


Document Control ii

Doc Ref:

On completion of acceptance the client will be asked to sign an Acceptance Certificate as a record of the successful completion of the project to its defined scope.

Project Administration

The following administrative arrangements have been made for this project:


Document Control ii

Doc Ref:

Project Tasks, Deliverables, and Milestones

Planning Approach

Oracle's <Oracle Method Name> will be used on this project. The methodology covers the following phases:

<phase name>

Key Deliverables

This section defines the tasks and key deliverables for each phase described above.

Phase Task Key Deliverable Review Type Reviewers Sign-Off

<phase name>

<task name> <deliverable name> <review type>

<reviewer(s)> <approver(s)>

Key: Review Type: I = Inspection, W = WalkthroughSign-off: C = Client PM = Project Manager

Milestones

The target milestone dates for producing the deliverables are summarized below:

Contract Deliverable Milestone Dates


Document Control ii

Doc Ref:

Control and Reporting

The Control and Reporting process determines the scope and approach of the project, manages change, and controls risks. This process reports progress status externally and controls Project Management Framework preparation and updating.

Control and Reporting Standards and Procedures

The following standards and procedures are extensions to the Project Management Framework for this project:

Risk and Issue Management

The risks to project success were evaluated during the proposal development and updated during project start-up as summarized earlier in this document. To manage the risks and other issues that arise during the project, a Risk and Issue Management Procedure will be implemented. Risks and issues will be managed through the project using a maintained Risk and Issue Log discussed at progress meetings.

During the project, issues will occur which will be outside the boundaries of the project team to be able to resolve. The procedure described below will be used to address these problems to enable the development process to continue.

Record Risk and Issue Details

Any team member or client staff may raise an issue or discover a risk and get it added to the Issue Register as it arises. (From here on, risks and issues are referred as issues)

The project manager will investigate the issue and, if necessary, will update the Risk and Issue Log with background information to place the issue in perspective.

Resolve Issue or Develop Risk Containment

For complex issues the progress of resolution will be recorded in detail on a Risk and Issue Form.

Alternative solutions to the issue will be discussed and documented in the Risk and Issue Log at progress reviews.

The impact on schedules and costs will be estimated for each solution.


Document Control ii

Doc Ref:

The project manager will make a recommendation that will be documented in the Risk and Issue Log.

Recommendations will be reviewed at progress meetings and Change Request Forms raised if client authorization is required, or issues transferred to Problem Reports if changes to documentation or software are required as a result of issue resolution.

If change control is required then the Risk and Issue Form will be submitted for background information as part of the Change Control process.

If the issue can be resolved without impacting contractual obligations then the Project Manager will sign-off the Risk and Issue Log.

If no action is taken this fact must be clearly indicated in the Risk and Issue Log.

Change Control

The Change Control procedure is documented below:

Any modification to or deviation from the agreed functionality, or changes to the time or costs agreed upon in the contract will be subject to the following procedure.

Change requests may be initiated by <Consultant> or the client whenever there is a perceived need for a change that will affect the contract of work, such as schedules, functionality, or cost.

Agreement to a Change Request Form signifies agreement to a change in overall costs, functionality, or schedules.

Propose Changes

A change can be identified to both <Consultant> and client project managers by a resolved problem or issue, document, conversation, or other form of communication.

The person who is functionally responsible (from <Consultant>) for the area of change will:

Complete a Change Request Form (CRF) for the proposed changes and submit copies to the relevant parties (possibly including subcontractors, and technical input) for assessment.

Record the CRF in the change control log.

Investigate the impact of the proposed change.

Evaluate the impact of not performing the change.

Prepare a response to the proposed change.

File the CRF original in the project library. This MUST NOT BE removed except to copy.

Agree with the client whether the change should be performed and obtain authorization sign-off of the CRF.


Document Control ii

Doc Ref:

If the change is not agreed to:

The project manager will discuss and document the objection with the client project manager

The proposed change will be re-negotiated if possible, or withdrawn if it is agreed to be non-essential. In such a case, the reasons will be documented on the CRF.

Monitor Changes

Once the CRF has been signed then work may begin.

The project manager will adapt project plans to incorporate agreed changes and present them at progress meetings for approval.

Progress on the change controls will be reported at progress meetings. Both <Consultant> and client project managers must sign the CRF once the change has been completed.

The CRF is returned to the originator who will update the Change Request Log with the date completed.

The Change Request Log will be reviewed at progress meetings to check on changes that have not been completed.

Problem Management

The Problem Management Procedure to be used on this project is defined below:

This procedure provides a mechanism by which either party to the contract can raise for discussion any problems that occur during the course of the project. Issues raised by visiting specialist <Consultant> personnel will initially be documented in a Site Visit Report and discussed at the monthly progress reviews.

A problem will normally be something that needs to be tracked in order to monitor its status and whether or not it has been resolved or is still outstanding. This might include problems found with documentation, software or during testing. Problems are distinguished from issues in that they apply to perceived deficiencies in deliverables of this project.

Record Problem Details

A project member will complete a Problem Report (PRT) when a problem is experienced with a deliverable document or software item.

The originator will the send PRT to the project manager.

The project manager will allocate a PRT number and will add it to the Problem Report Log.

Investigate Problem

The project manager or a delegate will assign the problem for investigation.


Document Control ii

Doc Ref:

The investigator will classify the level of change, if a change is required (see levels of change section).

Findings of investigations will be reviewed by the <Consultant> and client project managers.

If no action is to be taken, an explanation must be provided on the PRT and the project manager must sign off the PRT marked with 'NO ACTION REQUIRED'.

Resolve Problem

For complex problems the progress of resolution will be recorded in detail.

The PRT will be forwarded to the relevant person for corrective action.

On completion the PRT must be signed off by the project manager or a delegate.

Return the PRT to the project manager who will close the log entry.

Status Monitoring and Reporting

Reviews

Team Progress Reviews will be held on a weekly basis to assess the progress of each team member and to plan for the following week(s). They will also include a discussion of any issues and problems. Workplans are updated weekly in preparation for the team review based on completion of timesheets by staff.

Project Progress Reviews are held at monthly intervals and a report is given as input by the project manager summarizing progress, problems, and any proposed changes. An updated project Workplan prepared by the project manager will be a key input to the meeting. Minutes of these meetings will be recorded and state what actions are to be taken, by whom and by when. The actions will be discussed for resolution during subsequent meetings.

The project steering committee meets quarterly to review overall project progress, risks, and issues.

Site visit reports will be produced on a regular basis by all visiting specialists and reviewed by the project manager. They will then be collated and any unresolved issues will be discussed at Project Progress Reviews held on individual sites and added to the Risk and Issue Log when appropriate.

The project board will meet at monthly intervals to review the progress reports and other data relating to the project. The project manager will represent the project team at these meetings. Other members of the project board are as follows:

Client Project Manager

Client IT Manager


Document Control ii

Doc Ref:

Client User Manager

<Consultant> Business Manager

Actions will be identified in the minutes of all of the above reviews and will be filed in the project file. The Risk and Issue Log will be updated as a result of discussions during the reviews.

Progress Reporting

On a monthly basis the project manager prepares a Project Progress Report for input to the progress reviews and a detailed Internal Progress Report for feedback and project monitoring by <Consultant> management. Financial information is input as part of this Internal Progress Report (see also the Finance Plan for this project).


Document Control ii

Doc Ref:

Work Management

The Work Management process is responsible for defining, monitoring, and directing all work performed on the project. In addition, it must maintain a financial view of the project for <Consultant> management review.

The Workplan for this project is maintained in ABT Project Workbench. Initial work breakdown as summarized in the “Project Tasks, Deliverables and Milestones “ section was derived using the <Oracle Method Name>

The project deliverables and milestones for this project are listed in a previous section.

Work Management Standards and Procedures


Communication Model

The following table defines the recurring communication requirements within the project team, with the steering committee and all other stakeholders who have an active involvement in the management of the project. It is recommended that communications be open and informal to promote transfer of knowledge between all parties interested. This model reflects the recurring communications the project leaders see as critical to make sure there is the right level of information, involvement, buy-in and overall effective management of the project. The communication model is complemented by a communication campaign to reach all stakeholders who are impacted by the project but who are not actively involved in its management.

Meetings/ Media

Agenda Timing Responsibility Participants Input Output

ManagementSteering committee Meeting

Progress against planIssues summaryChange control statusAction item reviewFuture activities

<Frequency> Executive Sponsor Steering committee and Project Manager (and Project Leads)

Project Status Report Summary

Minutes/Action Items

Project Management Status Meeting

Progress against planAccomplishments/Next stepsIssues summaryChange control statusAction item review

<Frequency> Project Manager All Project Leads(and all project team)

Project PlanResource PlanQuality PlanImplementation Site Status Report

Minutes/Action ItemsStatus Report Summary


Document Control ii

Doc Ref:

Meetings/ Media

Agenda Timing Responsibility Participants Input Output

Implementation Planning Meeting


<Frequency> Implementation Managers

Implementation ManagersSite Implementation Managers

Implementation Planning Status ReportImplementation Site Status Report


Site Project Management Meeting


<Frequency> Site Project Manager

Site Project ManagerTechnical and Functional Leads

Implementation Site Status ReportFunctional and Technical Status Reports


Stakeholder Communication Meeting

Progress against communication campaignIssue detailAction item reviewFuture activities

<Frequency> Change Team Lead (or Communication Team Lead)

Communication TeamExecutive SponsorCommunication Agents

Communication MeasurementsCommunication Agents’ InputSponsors’ InputAll stakeholders’ input


Shared Learning Meeting

Critical issuesLessons learned from experience to assist others

<Frequency> Project Manager Project LeadsImplementation Sites Leads

Status ReportsIssue Log


DevelopmentFunctional Review Meeting


<Frequency> Project Manager Functional Team LeadsKey Users

Functional Status Report


Technical Review Meeting


<Frequency> Project Manager Technical Team LeadsKey Users

Technical Status Report


Meeting Preparation

Distribute the agenda for each meeting, at least 24 hours in advance. Chose as an initial topic a subject that is relatively easy and short and likely to build consensus; organize the rest of meeting topics by order of importance. Allocate duration for each topic.

Distribute preparation materials in advance along with the agenda and preparation instructions.

Communicate meeting logistics in advance, such as location, time, and conference phone number.

It is the responsibility of all project team members to ensure that project meetings are attended and the preparation work completed to participate fully in the meeting.

For meetings of five participants or more, the meeting chairperson names a facilitator to ensure that the objectives of the meeting are being met and that the meeting is kept on track and managed effectively.

The meeting chairperson names a recorder to take the minutes/action items and distribute as planned.


Document Control ii

Doc Ref:

Invitees who cannot attend a meeting should inform the meeting coordinator or chairperson and assign an attendee to speak to their specific issues.

Project meetings should address at a minimum the following:

accomplishments and upcoming activities

progress against plan (including resourcing and budget expenditures, as applicable)

project dependent deliverables

issues and resolution

change control review

action items

Meeting Structure

The beginning and the end of the meeting are critical times. A strong Open and Close will provide the structure needed to keep participants focused, clear on key issues, and ready to take action after the meeting.

In light of the agenda, preparatory materials and instructions, participants should have a clear understanding of the purpose of the meeting and the expectations for participating and follow up.

Typical Meeting Opening

Use the following opening:

Introduction of each participant by name and role (unless all participants know one another). Provide a project organizational chart so all participants can relate to the roles described.

As time allows, a short “ice breaker.”

Review purpose, objectives and format of the meeting. Confirm agenda.

Recognize facilitator (for meetings with more than 5 attendees) and meeting scribe/recorder.

Briefly review progress from previous meeting’s close (if regular meeting).

Typical Meeting Closure

Use the following close:

Summarize key issues with related levels of urgency.

Ensure participants have a clear understanding of next steps.

Review action items and follow up steps/contacts.

Conduct a brief meeting process review: what went well and what needs improvement for next meeting.


Document Control ii

Doc Ref:

Thank attendees for their participation.

Workplan Control

The Project Workplan will be updated from project staff timesheets on a weekly basis. At monthly intervals the latest status will be reported to <Company Long Name> and <Consultant> management as part of Status Monitoring and Reporting (see the Control and Reporting section).

Each week the Project Workplan will be baselined by saving it to a file with the week number coded in the filename, so that it is possible to trace project data back to previous versions of the Workplan.

An initial baseline for the Project Workplan is included in Appendix A to this plan.

Financial Control

The Finance Plan is maintained by the project with financial reporting to <Consultant> as part of Status Monitoring and Reporting (see the Control and Reporting section).


Document Control ii

Doc Ref:

Resource Management

The Resource Management process provides the project with the right level of staffing and skills and the right environments to support them. It does not cover purchasing, recruiting, and accounting procedures; these are practice management issues and are therefore outside the scope of this Project Management Framework.

Resource Management Standards and Procedures


Staff Resources

Project Team

The project organization is shown in figure 1 below.


Document Control ii

Doc Ref:

NameTitle

NameTitle

NameTitle

NameTitle

Name

Name

Name

Name

Name

Name

Name

Name

Name

Name

Name

Name

Name

Name

Name

A separate Organization Plan (wall chart) with named individuals is maintained and updated for the project as a communication tool. Assignment Terms of Reference for staff assigned to the project are maintained in the associated Staffing and Organization Plan.

Project Roles and Responsibilities

Project Manager

The project manager is responsible for:

Developing project plans

Assigning tasks to other project personnel

Monitoring staff and project

Managing risks and escalated issues from project teams

Controlling budgets, scheduling resources, and recommending implementation approaches

Assuming overall responsibility for the successful conclusion of the project

Measuring project success against budget, original scope, business objectives

Project Management directives include:


Document Control ii

Doc Ref:

Assisting <Company Short Name> in the timely implementation of Oracle Applications

Assuming responsibility for planning resource requirements and coordinating the daily tasks of all project team members in conjunction with contract resources

Ensuring that all resources and their respective skills are optimally utilized

Providing quality assurance of work undertaken by staff assigned to the project

Identifying and managing all product-related training requirements for <Company Short Name> staff

Representing <Company Short Name> in meetings with vendors and other representatives associated or involved with the implementation

Providing the principal point of contact between <Company Short Name> and <Consultant>

Preparing and delivering regular reports on the project progress and outstanding issues

Encouraging the transfer of product knowledge and skills to the appropriate staff within the organization

Team Leader

The team leader is responsible for:

Managing tasks for a specific process, functional or application area

Supporting the daily tasks for the assigned team

Monitoring and reporting the progress of the assigned team

Application Product Specialist

The application product specialist’s responsibilities include:

Advising, guiding, and supporting the project team on the use, implementation, and maintenance of Oracle Applications

Ensuring that <Company Short Name> derives the maximum benefits from the application products

Completing tasks and deliverables assigned by the project manager

Keeping the project manager informed of progress and issues in a timely manner

The application product specialist’s directives include:

Advising and assisting in the development of a generic model

Evaluating specific requirements and recommending how each can be incorporated in the generic model


Document Control ii

Doc Ref:

Identifying feasible alternative solutions that minimize the need for custom development

Reviewing existing work practices in order to recommend modifications or enhancements that enable the company to derive maximum benefits from the products

Identifying any external data requirements and defining phased data load and validation procedures

Assisting with the specification of representative data sets and business scenarios for acceptance testing

Transferring the appropriate business and technical skills to other project team members

The individuals who fulfill this role are likely to have the following qualifications:

Accounting, Manufacturing, Distribution, or Human Resources Management Systems background

Thorough understanding of the applications

Experience in implementing application systems

In general, the assigned persons will be responsible for tasks requiring specific skill sets. When <Company Short Name> resources change, the client project manager will ensure that these project team members transfer sufficient knowledge and ensure that coverage exists for any outstanding assignments. If resource changes occur within the <Consultant> staff, the project manager will use the same approach to maintain continuity and avoid unnecessary delays in progress.

Some tasks will require representation from various <Company Short Name> functional areas. The client will provide all necessary resources to support these tasks.

Education and Skilling

Refer to the Project Team Learning Plan (AP.030), Project Readiness Roadmap (AP.070), and Learning Plan (AP.140) deliverables for more detailed information about the project team and end-user skilling requirements for the project.

The staff involved with this project (including client staff) are all suitably qualified in terms of background, experience, and skills in the tasks to be undertaken, with the following exceptions that will be catered to during the course of the project as defined below:


Document Control ii

Doc Ref:

Client Staff Skilling Needs

<Consultant> Staff Skilling Needs

Physical Resources

Project Software/Tools

The software supplied will be in accordance with the contract and the schedules to contract or as amended under formal Change Control. This includes:

Oracle Software

Operating and Other System Software

Software Tools

Hardware

The hardware and operating software to be used will be that specified in the contract or schedules to contract or as amended under formal Change Control. This includes:


Document Control ii

Doc Ref:

Project Environments

The project <process name> environment is located at <location> and consists of:

Refer to the Architecture Requirements and Strategy (TA.010) deliverable for more detailed information about the strategy for the project environments.

Software Backup Procedures and System Administration

Backups and basic system administration (machine start-up, shutdown, and recovery) of the working environment software installation will be performed <daily> by <Consultant> staff/client staff.

Database sizing and instance synchronization will be performed by <Consultant> staff/client staff.


Document Control ii

Doc Ref:

Quality Management

This section defines how the quality of the project processes is to be determined (audits) and how the quality of deliverables produced during the project are to be determined (reviews). This section also defines how deliverables will be physically assessed for functionality (testing), and what measurements will be collected during the project.

Quality Management Standards and Procedures


Quality Management Standards and Procedures

Technical Standards

Quality Reviewing

Reviews will be carried out for each deliverable (documentation and software) using the technique nominated in the Deliverables sub-section of the Scope section of this plan or the Project Management Framework document. A record of all deliverable reviews will be kept as an audit trail for resolution action. Techniques and responsibilities are as defined below:

A Technical Review focuses not just on looking for errors and incompleteness (as is the purpose of any Review), but evaluates the technical aspects of a deliverable e.g., elegance of code, functionality, etc. A Technical Design Review is a special type of Technical Review (see below). A Technical Review is usually conducted as part of a Walkthrough or an Inspection.

A Walkthrough (individual or group) is a review whereby the reviewer(s) step through a deliverable to check for errors, inconsistencies, incompleteness, etc. The findings and actions of the Walkthrough must be documented. For group Walkthroughs someone should lead the review.

An Inspection has the same purpose but is a more formal version of a Walkthrough. Formal roles are assigned to reviewers. These roles are:


Document Control ii

Doc Ref:

Moderator (leads the review)

Author (of the deliverable being reviewed)

Reader (reads out the part currently being reviewed)

Recorder (documents findings)

One or more reviewers who may also be role-playing (e.g., the customer view, the <Consultant> technical view, <Consultant> PM view, etc.).

These types of reviews are extremely thorough since role-playing ensures that the deliverable is evaluated from many different angles and there is a great deal of preparation before the Inspection itself. It is therefore the most expensive type of review to run, and should be used when appropriate (e.g., for end of phase deliverables, for mission-critical deliverables).

Quality Auditing

Audits of Quality Management will be conducted during the project by <Auditor> at the following points:

Audit Number

<Auditor> Coordinator Date or Milestone

Test Management

Test Strategy

The test strategy for this project is to:

Refer to the Testing Requirements and Strategy (TE.010) deliverable for more detailed information about the testing strategy for the project.

Test Levels

The following levels of testing will be used for this project:

Module Testing


Document Control ii

Doc Ref:

Link Testing

System Testing

Integration Testing

Acceptance Testing

Test Execution

The following project roles are responsible for test execution:

The following methods will be used to document the results of test execution:

Measurement

The following project metrics will be collected during the project and used as part of progress reporting:

Project Metrics Collection

1. Time to design and build modules of all types

2. Number of modules under development

3. Percentage of effort spent on reviews

4. Percentage of effort spent on rework

5. Effectiveness of reviews

6. Effectiveness of system testing

7. Number of problems encountered during System Test

8. Average hours to fix a defect during development

9. Percentage of bad fixes for development

10. Variances between estimates and actuals (effort and time)

11. Number of problems at Acceptance

Reporting

1 to 8 during the project, 9 to 11 on project completion (in the project end report)


Document Control ii

Doc Ref:

Business Processes Metrics Collection

The business process metrics that will be measured in the Effectiveness Assessment (AP.180) at the end project are as follows:

Refer to the Business Unit Managers Readiness Plan (AP.060) and the Managers Readiness Plan (AP.090) deliverables for more detailed information about the metrics to be captured for the project.


Document Control ii

Doc Ref:

Configuration Management

The Configuration Management process identifies the items that form the configuration that will be developed for the project, baselines these items at intervals, and manages changes to the items. Status reports of configuration items are produced during the project and releases prepared for testing and for delivery to the client.

Configuration Management Standards and Procedures


Configuration Definition

The following naming conventions will be used for configuration items:

Document Files

Type Format Extension Example

Word FilesGraphicsSpreadsheetsApplication SpecificOther

Programs

Program Type Format Extension Example

FormsReportsC-ProgramsConversion programsRead filesInterface ProgramsProcedures

More detailed custom development standards will be documented in the Design and Development Standards document later in the project.


Document Control ii

Doc Ref:

Document Control

Configuration Control

Knowledge Management

Release Management

Configuration Status Accounting

Configuration Audit


Document Control ii

Doc Ref:

Appendix A - Workplan


Document Control ii

Doc Ref:

Appendix B - Roles and Responsibilities


Document Control ii

Doc Ref:

ABF_BT070_PROJECT_MGMT_FRAMEWORK

Documents

Transcript of ABF_BT070_PROJECT_MGMT_FRAMEWORK