Vous êtes sur la page 1sur 88

AIM for Business Flows

BT.070 PROJECT MANAGEMENT


FRAMEWORK
<Company Long Name>
<Subject>

Author: <Author>
Creation Date: April 26, 2007
Last Updated: April 26, 2007
Document Ref: <Document Reference Number>
Version: DRAFT 1A

Approvals:

<Approver 1>

<Approver 2>
BT.070 Project Management Doc Ref: <Document Reference Number>
April 26, 2007

Document Control

Change Record
1

Date Author Version Change Reference

26-Apr-07 <Author> Draft 1a No Previous Document

Reviewers

Name Position

Distribution

Copy No. Name Location

1 Library Master Project Library


2 Project Manager
3
4

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> Document Control ii


File Ref: 54683598.doc (v. DRAFT )
BT.070 Project Management Doc Ref: <Document Reference Number>
April 26, 2007

Contents

Document Control.............................................................................................ii

Introduction........................................................................................................1
Purpose.........................................................................................................1
Business Flow Implementations..................................................................2
Background..................................................................................................8
Scope and Application...............................................................................10
Implementation Decisions.........................................................................17
Selected Alternative...................................................................................17
Impact Assessment.....................................................................................18
Related Documents....................................................................................19
Scope................................................................................................................21
Scope of Project.........................................................................................21
Constraints and Assumptions.....................................................................22
Risks...........................................................................................................22
Business Flow Risks..................................................................................22
Interfaces, Integration, Data Conversion Risks.........................................23
Hardware, Network, Software Risks.........................................................25
Staffing Risks.............................................................................................27
Scope, Project Management Risks.............................................................30
Scope Control............................................................................................33
Relationship to Other Systems/Projects.....................................................33
Objectives........................................................................................................35
Mission Statement......................................................................................35
Critical Success Factors.............................................................................35
Project Objectives......................................................................................35
Approach..........................................................................................................36
Project Methods.........................................................................................36
Strategy......................................................................................................57
Century Date Strategies.............................................................................57
Plans...........................................................................................................58
Client Organization....................................................................................58
Locations and Network..............................................................................58
Acceptance.................................................................................................59
Project Administration...............................................................................59
Project Tasks, Deliverables, and Milestones...................................................60

<Subject> Document Control ii


File Ref: 54683598.doc (v. DRAFT )
BT.070 Project Management Doc Ref: <Document Reference Number>
April 26, 2007
Planning Approach......................60
Key Deliverables........................................................................................60
Milestones..................................................................................................60
Control and Reporting.....................................................................................61
Control and Reporting Standards and Procedures.....................................61
Risk and Issue Management......................................................................61
Change Control..........................................................................................62
Problem Management................................................................................63
Status Monitoring and Reporting...............................................................64
Reviews......................................................................................................64
Progress Reporting.....................................................................................65
Work Management...........................................................................................66
Work Management Standards and Procedures..........................................66
Communication Model..............................................................................66
Meeting Preparation...................................................................................67
Meeting Structure......................................................................................68
Workplan Control......................................................................................68
Financial Control.......................................................................................69
Resource Management.....................................................................................70
Resource Management Standards and Procedures....................................70
Staff Resources..........................................................................................70
Project Team..............................................................................................70
Project Roles and Responsibilities.............................................................71
Education and Skilling...............................................................................73
Physical Resources.....................................................................................74
Project Software/Tools..............................................................................74
Hardware....................................................................................................74
Project Environments.................................................................................74
Software Backup Procedures and System Administration........................75
Quality Management........................................................................................76
Quality Management Standards and Procedures.......................................76
Quality Reviewing.....................................................................................76
Quality Auditing........................................................................................77
Test Management.......................................................................................77
Test Strategy..............................................................................................77
Test Levels.................................................................................................77
Test Execution...........................................................................................78
Measurement..............................................................................................78
Configuration Management.............................................................................80
Configuration Management Standards and Procedures.............................80
Configuration Definition............................................................................80
Document Control......................................................................................80
Configuration Control................................................................................81
Knowledge Management...........................................................................81
Release Management.................................................................................81
Configuration Status Accounting...............................................................81
Configuration Audit...................................................................................81
<Subject> Document Control ii
File Ref: 54683598.doc (v. DRAFT )
BT.070 Project Management Doc Ref: <Document Reference Number>
April 26, 2007
Appendix A - Workplan....................82

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

<Subject> Document Control ii


File Ref: 54683598.doc (v. DRAFT )
Doc Ref:

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.

Document Control ii
File Ref: 54683598.doc (v. )
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
so that the success of the software and implementation is measured in terms of
achieving ROI instead of just getting the client “live”.

Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

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.

• 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.

Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

• 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.

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.

Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

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.

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.

Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

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
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.

Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

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
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-

Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

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

<Company Long Name> has the following business goals:

Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

<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

• 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

Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

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
• Objectives
• Approach
• Project Tasks, Deliverables, and Milestones
The following topics will address the standards and procedures to be followed on
the project:
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

• 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>
• <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.
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

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>:

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

Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

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

Application: Oracle General Ledger

Strategy: Manual

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

Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

Budgets

Application: Oracle General Ledger

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

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

Application: Oracle Payables

Strategy: No data conversion

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

Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

Payment History

Application: Oracle Payables

Strategy: No data conversion

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

Application: Oracle Purchasing

Strategy: No data conversion

PO history will be available for view in legacy system for a period of


<x> months.

Requisitions

Application: Oracle Purchasing

Strategy: No data conversion

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

Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

Asset Transaction History

Application: Oracle Assets

Strategy: No data conversion

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

Customers

Application: Oracle Receivables

Strategy: Manual

Data should be manually reviewed and ‘cleaned-up’ prior to manual


entry into the new system.

Scope: All active customers

Open Invoices

Application: Oracle Receivables

Strategy: Manual

Data should be manually reviewed and ‘cleaned-up’ prior to manual


entry into the new system.

Scope: All current invoices

Invoice History

Application: Oracle Receivables

Strategy: No data conversion

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

Payment History

Application: Oracle Receivables

Strategy: No data conversion

Customer payment history will be available for view in legacy system


for a period of <x> months.

Bank Statement History

Application: Oracle Cash Management


Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

Strategy: No data conversion

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 Triggering Event Frequency Data Volume
Transferred

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
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?

Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

Decisions Description

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 Rationale for Major Impact on Major Impact on Major Impact on Consequences of
Implementation Decision Technology Processes People Impact/Actions to Manage
Decision

Standardization improve production buy reduce approval adjust individual need to develop exception rules
control hardware/software requirements accountability specific custom applications
increase quality change hardware realize economies of adjust individual may be lost (for specific
enhance customer configuration scale performance organizations) - may lose data
focus change network adjust task reduce support related to that
improve decision measurements services to employees need intercultural negotiations
making and sharing create task to maintain improve resource need clear decision making
of information standards management process and determine
increase flexibility ___ number of process ___ number of people who/what scenarios have
based on consistency impacted impacted priority
speed up comparison need inventory of
reduce hardware/software
administration cost need a whole new reskilling
effort for the new
processes/roles
need new documentation
Vanilla or allow for outsourcing increase ease of determine drive: lose functionalities need to manage the perceived
customization optimize cost of upgrade technology or and customizations to loss of functions and
development/mainte reduce cost of upgrade business which people are customization
nance adjust change processes accustomed (sense of need to redeploy people
take advantage of hardware/software lose business loss, impacts (involved in
web platform, streamline requirements acceptance) development/customization)
ECommerce systems/platforms increase ease of lose perceived service
work with benchmarking level by the customer
availability of skills lose competitive edge
sets increase need for
reskilling
increase resistance
around “not invented
here”
reduce dependency on
internal
development/customiz
ation skill set
Distribution and enhance customer change develop new adjust decision need to increase computer
use of knowledge hardware/software information tracking making with ready literacy and general reskilling
information increase requirements (for process, for example, access to company- need to instill empowering
quality/ability to example, On-Line wider access to data wide information and model to support decision
customize Analytical Processing required client contact making expectations (might
relationship with [OLAP]) develop new increase people require adjustment of
customers (improve design a web/intranet information voice/input management culture)
customer service) site procedures ensure validity need to strengthen non-
improve error/defect give corporate-wide improve add responsibility and disclosure agreement
tracking access confidentiality rules accountability for data need to encourage sharing of
increase productivity increase security add new/replace tasks integrity information (let go of power of
requirements reduce redundancy give more information)
..... and mechanical tasks accountability for use need new performance
add support task of repository reinforcements
__ number of __ number of people need to increase security
processes impacted impacted measures

Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

Critical Rationale for Major Impact on Major Impact on Major Impact on Consequences of
Implementation Decision Technology Processes People Impact/Actions to Manage
Decision

Centralization or improve quality change reduce non-value add change nature of work need to empower people (in
decentralization control hardware/software tasks groups, for example, centralized or decentralized
(overall and by change number of requirements reduce delay between autonomous, self- roles)
function) people involved re-distribute hardware tasks directed need to change distribution of
reduce cost increase system modify approval flow change job power among
increase people security change task output requirements functions/business
involvement manage data modify procedures modify management units/management layers
replication __ number of approach need to adjust organizational
processes impacted modify skill profile structure to reflect new flows
__ number of people need to update job descriptions
impacted need to adjust compensation,
rewards and recognition
implement Wide Area Network
implement new access
procedures
Phased or “big adjust support release can increased maintenance impact scope/pace of instill more radical
bang” approach quality/regulatory change amount of requirements change (might reach maintenance program
compliance concurrent systems manage level of saturation) implement stress management
requirements increase data concurrent/redundant impact length of system
increase speed to synchronization issues processes project, for example, publish new procedures
market (duplication issues ) impact timing of loss of momentum accelerate knowledge
increase regulatory increase risk management program
competitiveness requirements level/stake document lessons learned
position (conform to) impact the ability to manage sense of urgency
organizational risk to data integrity benefit from lessons
requirements, for risk of the availability learned
example, of system impact learning curve
redeployment risk to customer impact end-user
service quality levels resistance/acceptance
Parallel systems impact perception of increase amount of maintain duplicate prolong “crutch” need to increase resources
risk (parallel systems reconciliation work procedures approach/increase need to lengthen time frame
might indicate risk lose economy of scale safety/reduce stakes
avoidance) duplicate workload,
impact customer resource requirements
service levels increase chance for
reduce ROI (Return resistors to sabotage
On Investment)
impact ability to
validate data
(automation of
verification process)
Outsourcing increase focus on lessen technology document procedures reduce skill set need to redeploy people
core competencies requirements increase need to requirements for (involved in
reduce cost increase compatibility justify requirements general use, development/customization)
requirements (because paying for maintenance and need to define and document
impact development them in more visible research and procedures and agreements
time way) development with outsourcing provider(s)
lose “historical” account for learning curve
knowledge
increase dependency
on exterior party
improve
training/familiarizatio
n/ramp up 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
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

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
File Ref: 54683598.doc (v. )
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- Re-engineering will ...


engineering

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
conversion: ...

Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

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 The delta between Set clear


Business Flow the current expectations
fit to client’s process (legacy regarding what
future process. system) and the the flows
future process provide at the
(oracle business onset.
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

flow(s)).
High Flow The project Training.
Implementatio team’s Effective
nExperience understanding, screening of the
experience, and Project Team
knowledge of before staffing
flow the project.
implementations
Medium Applying Strong
Patches/Patch configuration
Management 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 Address issue
Acceptance & early and at a
Support of high level with
Approach the client,
Consider using
AIM
Medium CRP Training,
Execution 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

Consequence: Delay the project (business process mapping)

Contingencies:

Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

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

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..

Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

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:

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

Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

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.

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.
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

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.

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.

Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

<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.

<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:

Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

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

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

Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

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.

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.

Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

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.

Early Mitigation: 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.

Early Mitigation: None.

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

Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

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

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

Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

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.

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

Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

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
File Ref: 54683598.doc (v. )
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
File Ref: 54683598.doc (v. )
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
File Ref: 54683598.doc (v. )
Doc Ref:

Iterative Testing and Revision Cycle


Prepare Mapping/CRP Environment

Conduct Conference Room Pilot

Identify Exceptions

Determine Exceptions Resolutions

Update Business Flows

Update Business Procedures

Update Application Setups

Update System Test Script

Prepare CRP Environment

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

Once all of the above deliverables are updated, a new application environment is
established, using the updated software tools for loading setup data, and
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

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

CRP I (Second Iteration) Map Business Flows to


the customer’s business
and identify exceptions

Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

Conference Room Pilot Objectives

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)

• Dataload Scripts

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

Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

• 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.

Phases -- What’s Changing?


Operations Analysis

Production
Transition
Definition

Design

Build

Elaboration

Production
Definition

Transition
Build

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.

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

Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

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:

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.

Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

Deliverable Description

Business Flows Mapped Initial mapping of the Oracle


to Customer’s Business Business Flows (and associated
business processes) being
implemented to the customer’s
business needs.

Listing of potential Documents exceptions/potential


changes to setups, changes to Business Flows,
procedures, process, or application setups, and/or gaps
custom extensions 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 Documents the conceptual


Architecture 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.

Project Readiness A plan for addressing the human


Roadmap 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

Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

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.

• 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:

Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

Deliverable Description

Disposition/resolution of Documents the disposition of


exceptions 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 Revised Business Procedures


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

Updated Application Revised definition of detailed


Setup Documents and setup parameters, reflecting
Data Load Scripts 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 A refinement of the Integration


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

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.

Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

Deliverable Description

Application and Provides a blueprint for the


Database Server logical and physical architecture
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 Describes the deployment of the


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

Application Extension This document summarizes the


Definition and Estimates 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 The mapping of the legacy


Mapping system files and data elements
to the target application tables
and columns.

Conversion Program The designs that detail the


Designs program logic and rules coded
in the conversion programs.

Updated System Test Revise the pre-defined System


Script 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.

Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

Deliverable Description

System Integration Test Develop the Systems Integration


Script 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

Attention: Key deliverables represent the culmination, end result, or


major milestone of activities performed during a phase

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

• 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

Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

• 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:

Deliverable Description

Listing of potential Documents exceptions/potential


changes to setups, changes to Business Flows,
procedures, process, or application setups, and/or gaps
custom extensions in functionality identified during
CRP II.

Disposition/resolution of Documents the disposition of


exceptions 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 Revised Business Procedures


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

Updated Application Revised definition of detailed


Setup Documents and setup parameters, which have
Data Load Scripts been proven to support the
system.

Integration Framework Describes procedures for using


User and Management and managing the Oracle 9iAS-
Procedures based framework integrating the
Oracle system with third-party
and legacy systems.

Validation-Tested The conversion programs that


Conversion Programs produce converted business
objects function correctly in the
target applications system.

Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

Deliverable Description

Link-Tested Modules The Link Test Script (TE.030)


is executed to test the detailed
interaction between related
application extension modules.

System-Tested The System Test Script


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

Integration-Tested The integration between the


System 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 The transition plan,


Contingency Plan implementation contingency
alternatives, and former systems
decommission plan are
developed.

Table 4 Build Phase Key Deliverables

Attention: Key deliverables represent the culmination, end result, or


major milestone of activities performed during a phase

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.

Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

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:

Deliverable Description

Converted and Verified Converted data in the


Data 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.

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 Activated operational


Infrastructure 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

Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

Attention: Key deliverables represent the culmination, end


result, or major milestone of activities performed during a phase

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.

Key Deliverables

The key deliverables of the Production Phase are as follows:

Deliverable Description

Effectiveness An assessment of how well the


Assessment production system and business
and organizational performance
meet the business objectives set
at the beginning of the project.

Business Direction The functional project team,


Recommendations along with senior management,
begins planning for future
improvement opportunities.

Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

Deliverable Description

Technical Direction The technical project team, the


Recommendations information technology staff,
and senior management begin
planning for using new
technologies.

Table 6 Production Phase Key Deliverables

Attention: Key deliverables represent the culmination, end result, or


major milestone of activities performed during a phase

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.

Processes -- What’s Changing?


Traditional AIM Processes Flow Approach Processes
 Business Process Architecture
 Business Requirements Definition Business Process Mapping
 Business Requirements Mapping
 Application & Tech Architecture Application & Tech Architecture
 Module Design & Build Module Design & Build
 Data Conversion Data Conversion
 Documentation Documentation
 Business System Testing Business System Testing
 Performance Testing Performance Testing
 Adoption & Learning Adoption & Learning
 Production Migration Production Migration

Minor Changes Required Significant Changes New Process or Large % Rewrite

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.

Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

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.

• 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.
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

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:

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
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

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
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-
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

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.

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.
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

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
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.

Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

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

• 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:

Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

Plans

Phase
Phase includes the implementation of ....

Phase
Phase includes the implementation of ....

Phase ...
Phase includes the implementation of ....

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 Product


Implemented

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:


Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

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:

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
File Ref: 54683598.doc (v. )
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 <task name> <deliverable name> <review <reviewer(s)> <approver(s)>


name> type>

Key: Review Type: I = Inspection, W = Walkthrough


Sign-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
File Ref: 54683598.doc (v. )
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.
• The project manager will make a recommendation that will be
documented in the Risk and Issue Log.

Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

• 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
File Ref: 54683598.doc (v. )
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
File Ref: 54683598.doc (v. )
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
File Ref: 54683598.doc (v. )
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
File Ref: 54683598.doc (v. )
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

The following standards and procedures are extensions to the Project


Management Framework for this project:


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/ Agenda Timing Responsibility Participants Input Output
Media

Management
Steering Progress against plan <Frequency> Executive Sponsor Steering committee Project Status Minutes/Action
committee Issues summary and Project Manager Report Summary Items
Meeting Change control status (and Project Leads)
Action item review
Future activities
Project Progress against plan <Frequency> Project Manager All Project Leads Project Plan Minutes/Action
Management Accomplishments/Next (and all project team) Resource Plan Items
Status Meeting steps Quality Plan Status Report
Issues summary Implementation Site Summary
Change control status Status Report
Action item review
Implementation Progress against plan <Frequency> Implementation Implementation Implementation Minutes/Action
Planning Issues summary Managers Managers Planning Status Items
Meeting Change control status Site Implementation Report
Action item review Managers Implementation Site
Future activities Status Report

Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

Meetings/ Agenda Timing Responsibility Participants Input Output


Media

Site Project Progress against plan <Frequency> Site Project Site Project Manager Implementation Site Minutes/Action
Management Issues summary Manager Technical and Status Report Items
Meeting Change control status Functional Leads Functional and
Action item review Technical Status
Future activities Reports
Stakeholder Progress against <Frequency> Change Team Lead Communication Team Communication Minutes/Action
Communication communication campaign (or Communication Executive Sponsor Measurements Items
Meeting Issue detail Team Lead) Communication Communication
Action item review Agents Agents’ Input
Future activities Sponsors’ Input
All stakeholders’
input
Shared Critical issues <Frequency> Project Manager Project Leads Status Reports Minutes/Action
Learning Lessons learned from Implementation Sites Issue Log Items
Meeting experience to assist others Leads

Development
Functional Progress against plan <Frequency> Project Manager Functional Team Leads Functional Status Minutes/Action
Review Issues summary Key Users Report Items
Meeting Change control status
Action item review
Future activities
Technical Progress against plan <Frequency> Project Manager Technical Team Leads Technical Status Minutes/Action
Review Issues summary Key Users Report Items
Meeting Change control status
Action item review
Future activities

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.
• 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

Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

◊ 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.
Thank attendees for their participation.

Workplan Control

Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

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
File Ref: 54683598.doc (v. )
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

The following standards and procedures are extensions to the Project


Management Framework for this project:


Staff Resources

Project Team

The project organization is shown in figure 1 below.

Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

N am e
T it le

Nam e Nam e Nam e


T itle T it le T it le

Nam e
Nam e Name
Nam e
Nam e Name
Nam e
Nam e Name
Nam e
Nam e Name
Nam e
Nam e 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
File Ref: 54683598.doc (v. )
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
• Identifying feasible alternative solutions that minimize the need for
custom development
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

• 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:

Client Staff Skilling Needs





Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

<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:


Project Environments

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

Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:



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
File Ref: 54683598.doc (v. )
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

The following standards and procedures are extensions to the Project


Management Framework for this project:

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:
• Moderator (leads the review)

Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

• 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 <Auditor> Coordinator Date or Milestone
Number

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
• Link Testing
• System Testing

Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

• 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)

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:

Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:




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
File Ref: 54683598.doc (v. )
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

The following standards and procedures are extensions to the Project


Management Framework for this project:


Configuration Definition

The following naming conventions will be used for configuration items:

Document Files

Type Format Extension Example

Word Files
Graphics
Spreadsheets
Application Specific
Other

Programs

Program Type Format Extension Example

Forms
Reports
C-Programs
Conversion programs
Read files
Interface Programs
Procedures

More detailed custom development standards will be documented in the Design


and Development Standards document later in the project.

Document Control

Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

Configuration Control

Knowledge Management

Release Management

Configuration Status Accounting

Configuration Audit

Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

Appendix A - Workplan

Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:

Appendix B - Roles and Responsibilities

Document Control ii
File Ref: 54683598.doc (v. )