Abf BT070 Project MGMT Framework

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 )
April 26, 2007
Contents
Document Control................................................................................................
Introduction..........................................................................................................
Purpose...........................................................................................................
Background....................................................................................................
Scope and Application...................................................................................
Implementation Decisions.............................................................................
Selected Alternative.......................................................................................
Impact Assessment.........................................................................................
Related Documents........................................................................................
Scope....................................................................................................................
Scope of Project.............................................................................................
Constraints and Assumptions.........................................................................
Risks...............................................................................................................
Interfaces, Integration, Data Conversion Risks.............................................
Hardware, Network, Software Risks.............................................................
Staffing Risks.................................................................................................
Scope, Project Management Risks.................................................................
Scope Control................................................................................................
Relationship to Other Systems/Projects.........................................................
Objectives............................................................................................................
Mission Statement..........................................................................................
Critical Success Factors.................................................................................
Project Objectives..........................................................................................
Approach..............................................................................................................
Project Methods.............................................................................................
Strategy..........................................................................................................
Century Date Strategies.................................................................................
Plans...............................................................................................................
Client Organization........................................................................................
Locations and Network..................................................................................
Acceptance.....................................................................................................
Project Administration...................................................................................
Project Tasks, Deliverables, and Milestones.......................................................
Planning Approach........................................................................................
April 26, 2007
Key Deliverables............................................................................................
Milestones......................................................................................................
Control and Reporting.........................................................................................
Control and Reporting Standards and Procedures.........................................
Risk and Issue Management..........................................................................
Change Control..............................................................................................
Problem Management....................................................................................
Status Monitoring and Reporting...................................................................
Reviews..........................................................................................................
Progress Reporting.........................................................................................
Work Management...............................................................................................
Work Management Standards and Procedures..............................................
Communication Model..................................................................................
Meeting Preparation.......................................................................................
Meeting Structure..........................................................................................
Workplan Control..........................................................................................
Financial Control...........................................................................................
Resource Management.........................................................................................
Resource Management Standards and Procedures........................................
Staff Resources..............................................................................................
Project Team..................................................................................................
Project Roles and Responsibilities.................................................................
Education and Skilling...................................................................................
Physical Resources.........................................................................................
Project Software/Tools..................................................................................
Hardware........................................................................................................
Project Environments.....................................................................................
Software Backup Procedures and System Administration............................
Quality Management............................................................................................
Quality Management Standards and Procedures...........................................
Quality Reviewing.........................................................................................
Quality Auditing............................................................................................
Test Management...........................................................................................
Test Strategy..................................................................................................
Test Levels.....................................................................................................
Test Execution...............................................................................................
Measurement..................................................................................................
Configuration Management.................................................................................
Configuration Management Standards and Procedures.................................
Configuration Definition................................................................................
Document Control..........................................................................................
Configuration Control....................................................................................
Knowledge Management...............................................................................
Release Management.....................................................................................
Configuration Status Accounting...................................................................

April 26, 2007
Configuration Audit.......................................................................................
Appendix A - Workplan......................................................................................
Appendix B - Roles and Responsibilities............................................................

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
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
so that the success of the software and implementation is measured in terms of

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

A business flow is a sequence of related business processes designed to achieve a
critical objective. Business flows often cross organizational and application
boundaries. A business process is a planned series of work activities with defined
inputs and results.
Oracle Business Flows are crucial process flows that deliver measurable value to
Oracle customers. Flows reflect standard business practices for an industry, and
are optimized for Oracle Applications. They represent a leading practice
approach to employing Oracle’s E-Business Suite to satisfy common business
requirements, which can be used as a standard in implementations to
communicate the future process model.
Beginning the implementation with a pre-defined future process model, makes it

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

In addition to the Future Process Model (BP.080), which depicts the Business
Flow and its collection of business processes, a number of other deliverables will
typically be built to complement each business flow, these may include:
 KPIs – each flow is associated with a standard set of KPIs which can be
reported on throughout the implementation using standard application/BI
reports
 Business Procedures – these Oracle Tutor-built procedures, based on the

business processes contained in a given Business Flow, explain how to
execute each business process within the Oracle Applications Suite.
 Test Scripts – these pre-seeded System Test Scripts (TE.040) document the
steps necessary to verify proper functioning of each business process
contained in a given Business Flow. These test scripts are also useful in
walking customers through the business processes to familiarize them with the
overall Business Flow.
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
 Business Flow/Application Product Cross-reference – the Business

Requirements Mapping document (BR.030) provides a listing of all
Application products that must be configured to support a given Business
Flow. It may also document the specific features or functions within those
products required to enable the associated business processes.
 Operational Management Reporting – this deliverable (TA.060) describes the

various standard reporting and query tools available within the Oracle E-
Business Suite, that can be used to manage the operations addressed by a
given Business Flow.
These pre-seeded materials, and others that may be built to support Business
Flows, will be leveraged throughout a flow-based implementation to
communicate with the customer, validate the business solution, and help to
accelerate the overall implementation timeframe.
How a Flow-Based approach differs from a Traditional AIM Approach

A flow-based implementation approach differs from a traditional AIM approach
in several ways. The chief differences include:
 A business process focus
 A KPI focus
 A predefined Future Process Model as a starting point
 Follows Dynamic Systems Development Method (DSDM) principles
 Early introduction of hands-on testing
 Iterative testing cycles
 Requirements Mapped to Business Flows
A Business Process Focus
While AIM 3.0 incorporates the use of pre-defined process models as a

starting point for modeling current and future business processes, this aspect
of our current method has not been widely adopted. In practice, most project
teams continue to conduct engagements with an emphasis on implementing
products, features and functions, rather than business processes.
A flow-based implementation approach, by contrast, has integrated business

processes as its central focus. The emphasis is on communicating how the
business can be managed using predefined business flows representing
leading-practice employment of Oracle Applications, rather than on the
implementation of product features and functions.
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
A KPI Focus
Most implementations at Oracle are deemed “successful” after all the data has
been converted, and the process can be run end to end with no errors – i.e. we
have taken the client “live”. This perception of success is not always shared
by senior executives in the client organization. Senior executives are
typically looking for a defined return on investment manifested by measurable
improvements in specific areas of the business.
In a business flow implementation achievable targets are set for specific KPIs
associated with each flow. As the implementation progresses, test scripts are
executed as part of an iterative testing cycle which measure these KPIs.
Strategies are in turn developed which allow the customer to achieve the
anticipated targets. Sometimes these strategies may go beyond the
implementation cycle and into the post production phase.
A Predefined Future Process Model as a Starting Point
In a traditional AIM, “assemble to order” engagement, the future process

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

starting point for defining the future business processes. By positioning
business flows from the start as leading-practice use of Oracle Applications,
and employing iterative, hands-on testing cycles to refine the model rather
than traditional process modeling work sessions, it’s possible to eliminate
both the current business process review and future process modeling
activities, thereby achieving significant timesavings.
Effectively demonstrating how the customer can operate the business using
Business Flows through hands-on experience also increases the likelihood that
the Application software will be implemented without customizations or
extensions.
Follows Dynamic Systems Development Method (DSDM) Principles
AIM currently follows a traditional information systems engineering

approach. This approach, commonly referred to as a “waterfall” approach
because it relies on the uninterrupted cascading of information from one phase
of the development cycle to another, is embodied in AIM’s phased structure
consisting of Definition, Operations Analysis, Solution Design, Build,
Transition, and Production. One characteristic of the ‘waterfall” approach is
its susceptibility to delays and cost overruns when new or changed
requirements are identified late in the process.
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
The flow-based implementation approach will adopt the DSDM principles of

rapid prototyping and iterative development, among others, to help ensure that
cost and schedule are effectively managed should requirements change during
the engagement. Through repetition and active user involvement, the flow-
based approach should reduce risk and more quickly converge on a suitable
business solution for the customer.
Early Introduction of Hands-on Testing
In a traditional AIM approach, a good deal of time is spent early in the

engagement (i.e., Definition and Operations Analysis phases) reviewing
current business processes, defining future business processes, documenting
business requirements, and mapping those requirements to the Application
functionality. It often can be weeks, or even months, before the customer has
the opportunity to work in an environment that reflects the customer’s
proposed solution.
With a predefined Future Process Model (i.e., Business Flows) serving as the
starting point for a flow-based approach, there is no need to invest time and
effort in those activities. The new system solution is already defined to a
great extent. An environment reflecting that proposed solution can quickly be
established, and the customer can begin working with the system at a very
early point in the implementation.
The early introduction of hands-on testing and experimentation by the

customer is key to accelerated progress. Providing the customer with the
opportunity to work with the new system early in a Conference Room Pilot
setting helps to build confidence in the solution, and begin the
validation/refinement process sooner.
Iterative Validation Cycles
In a traditional AIM approach, Business System Testing, commonly referred

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

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

test/validation cycles serve the same function as process modeling and
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
business requirements mapping sessions do in an AIM engagement. They

define/validate the future business process model, and verify that the
customer’s business requirements are being met through hands on use and
validation of the system, as configured.
Requirements Mapped to Business Flows
In a traditional AIM approach, detailed business requirements are typically

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

to the business flows through refinement of the pre-defined configuration of
the baseline system. By mapping requirements to the pre-defined, integrated
flows, the end-to-end integrity of the flow, and therefore the resulting
solution, is preserved. Where required, detailed requirements may be mapped
to features in the software, but this should always be done in the context of
the flow-based solution.
Risk Mitigation Benefits
A flow-based approach, by its nature, provides a number of benefits that serve

to mitigate risks associated with software implementation engagements.
These benefits include:
 Rapid Installation and Stabilization of a Certified Implementation

Environment
 Scope Control
 Improved Issue Resolution
 Iterative Testing/early hands-on experience for customers
 Performance Testing is Built-In

Rapid Installation and Stabilization of a Certified Implementation
Environment
By employing implementation environments containing the entire E-Business
Suite certified on the same release level, such as Platinum e2 environments,
the customer and delivery team are assured of a stable environment that can
be used for initial hands-on testing/validation (CRP I) within days of the start
of the engagement. Delays normally associated with software installation,
patching, and establishment of a stable software environment in which to
begin work are therefore minimized/avoided.
Scope Control
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
Because a flow-based approach begins with one or more pre-defined business

flows, which prescribe the solution to significant degree, the ability to control
scope and limit “scope creep” is greatly enhanced. Flows have been optimized
for Oracle software and provide a much stronger, even optimal, starting point
from which to begin experimentation. With requirements measured against
the pre-defined flows, rather than against business processes defined in open-
ended modeling sessions, the effort focuses on “personalizing” the flows
instead of building a solution from scratch.
With flows to guide the definition of an overall solution, and with no need to
explore current business processes/practices, there is less need to customize or
extend the standard software, which also contributes to improved scope
control.
Improved Issue Resolution
With thirty percent, or more, of TARs submitted eventually being attributed
to setup issues, significant improvement in issue reduction/resolution can be
achieved by starting the implementation from a working, certified, pre-
configured, and fully tested environment.
When used, e2 environments also expedite issue resolution because of the

direct involvement available from Product Development. Because
Development is aware of issues nearly at the same time Consulting is, they
can act proactively to resolve the problem, and improve the overall experience
for the customer.
Iterative Testing/early hands-on experience for customers
The early introduction of hands-on testing contributes to improved buy-in by
the customer. Seeing the software working early on builds confidence and
helps to control scope by keeping the focus on how flows support the business
needs of the enterprise.
Because testing starts early, user involvement begins much earlier also. Early
engagement by users tends to lessen their concerns about introduction of a
new system. This contributes to building confidence among users, that there
will be no surprises when the system is promoted to production status.
Performance Testing is Built-In
Because flows are pre-defined and pre-tested, the high volume transactions
can be identified up front. Consequently, performance testing related to those
transactions can be incorporated early on to help ensure satisfactory
performance in a production environment.
Background
<Company Long Name> is
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
<Company Long Name> has the following business goals:
<Company Long Name> has engaged Oracle Consulting to execute the

<Project Name> project. The <Project Name> is intended to
The objectives of the project are:

 to implement an information system that provides information in a timely
manner to support management
 to implement an integrated system that provides access to all appropriate
users of business information
 to standardize internal reports that deliver relevant information to the end
user
 to implement a system that is flexible and can be upgraded as necessary
 to improve efficiency through the automation of manual processes
 to achieve a high ROI (return on investment)
In order to meet these objectives, the following Oracle Business Flows will be
implemented:
The AIM for Business Flows methodology will be used as the overall approach to
project implementation. AIM for Business Flows incorporates the use of Oracle
Business Flows, associated software environments, and tools, to keep the focus of
an implementation on business processes and benefits, instead of software
features and functions.
Some hallmarks of the AIM for Business Flows approach include:
 A Business Process Focus
 Use of pre-configured Oracle Business Flows and associated pre-

configured delivery assets as the starting point for the Future Process
Model
 Rapid establishment of a pre-configured software environment, based on

Oracle Business Flows, for use in mapping Flows to the customer’s
business
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
 Early introduction of iterative hands-on testing cycles
Central to the AIM for Business Flows approach is the use of a pre-configured
environment and software tools for quickly establishing, and reestablishing, a
fully configured, working environment at predetermined points during the
project. It is important to recognize that the use of a pre-configured environment
does not restrict the implementation of a final solution that is fully tailored to the
customer’s requirements. Instead, the pre-configured environment serves as
“starting point” for mapping Oracle Business Flows to the customer’s business,
and the identification of changes needed to “personalize” the environment to suite
the customer’s needs.
Critical success factors are key elements that need to be in place to facilitate
successful achievement of project objectives.
The critical success factors for meeting the above stated implementation
objectives are:
 to have <Company> adopt where ever possible the applications
features/functionality supported by the standard business flows being
implemented
 to have <Company> project team members accept ownership and
accountability for the success and implementation of the Oracle
Applications
 to establish clear and measurable project objectives and business process
requirements
 to implement and execute project scope control procedures
 to provide ongoing progress monitoring ( for example, compare progress to
project workplan, project milestones, and objectives)
 to adopt a strategy of developing or modifying business policies and
procedures based on the standard core functionality of the Oracle
Applications
 to identify and secure the appropriate individuals for the roles and
responsibilities of the project team
 to avoid customization of the Oracle Applications
 to reduce reliance on external consulting resources and provide a successful
transition to <Company> end users
 to address and close issues rapidly
 to review and accept project deliverables in a timely manner
Scope and Application
This Project Management Framework defines the following topics for Project
Management of the <Project Name> during the <Project Phase>:
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
 Scope
 Objectives
 Approach
 Project Tasks, Deliverables, and Milestones
The following topics will address the standards and procedures to be followed on
the project:
 Control and Reporting (issue management, scope change control, progress
reporting, etc.)
 Work Management (management of tasks and project budget information)
 Resource Management (management of staff including Roles and
Responsibilities, as well as physical resources)
 Quality Management (reviews of deliverables, testing, Healthchecks, etc.)
 Configuration Management (how project intellectual capital and software
are to be managed.)
The plan will be applied to both Oracle and <Company Short Name>
responsibilities across the project.
The Project Management Framework defines the implementation of the project

for the defined scope as well as how to meet the defined objectives using the
defined approach.
Named Users
The customer has forecast <x> named users initially, with an additional <y>
users planned subsequently.
Technical Architecture
<Company> is implementing a 3 tier network computing architecture that
includes the following components:
 <Hardware Servers>
 <Operating System>
 Oracle Applications Release x
 Oracle RDBMS Version x
 Applet Viewer Version x
 Netscape Browser Version x
 3 RDBMS environments Demo, Test & Production
 2 installations of the Oracle Applications against the following
environments:
 Test
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
 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.
Deployment Site
Deployment will principally focus on users at the <Company>’s headquarters
location. There may be additional users connected via the company WAN, but
there will be no distributed processing or multiple applications environment
across sites.
Applications
The following Oracle Applications are included within the scope of <Project
Name> during the <Project Phase>:


Refer to the BR.030 for each flow for more detail.
The implementation is targeted to commence <date> and complete <date>.
Plus Functionality/Applications
Each Oracle Business Flow implements a discrete set of Core applications
functionality as defined in BR.030 Business Requirements Mapping
(Core/Plus) document. This document provides a detailed description of core
functionality that is included in the solution and plus functionality which is
not included. This document resides with the solution deliverables.
The following plus items are included within the scope of <Project Name>
during the <Project Phase>:


Business Process Reengineering

<Company> acknowledges that business process reengineering is not within the
scope of the <Project Name> during the <Project Phase>:
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
Customizations
The following (including custom reports) are included within the scope of the
<Project Name> during the <Project Phase>:
Chart of Account Design

<Company> is going to implement the following COA design:
Company
The company segment will be 2 characters in length, alpha-numeric and will

be displayed in the 1st position.
Cost Center
The cost center segment will be 3 characters in length, alpha-numeric and will
be displayed in the 2nd position.
Account
The account segment will be 6 characters in length, alpha-numeric and will be

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

displayed in the 4th position.
Data Conversions
The following data conversions of pertinent and valid business objects will be
necessary in order for the final solution to be operational. Manual conversions
will be done by the <Company>’s project team:
Chart of Accounts
Application: Oracle General Ledger
Strategy: Manual
Scope: A new COA will be developed and will be entered manually.
Prior Period Activity
Strategy: Manual
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
Utilize a spreadsheet based mapping process (map old COA segment

values to new COA) - prior period activity can then be entered as
manual journals.
Scope: Closing balances for the prior fiscal year will be entered as well as
period summary activity for the following periods:
 periods 1-12
Budgets
Strategy: Manual
Utilize a spreadsheet based mapping process (map old COA segment

values to new COA) - current fiscal period budgets can then be entered
as manual budget journals.
Scope: Budget journals will be entered for the following periods:

 <period 1>
 <period 2>

Vendors
Application: Oracle Purchasing/Payables
Strategy: Manual
Data should be manually reviewed and ‘cleaned-up’ prior to manual

entry into the new system.
Scope: All current vendors
Employees
Application: Oracle Payables/Purchasing
Strategy: Manual
Scope: All current employees
Open Invoices
Application: Oracle Payables
Strategy: No data conversion
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
Open invoices can be paid out of legacy system while invoices received
subsequent to production cut-over will be processed into Oracle
Payables.
Invoice History
Invoice history will be available for view in legacy system for a period
of <x> months.
Payment History
Payment history will be available for view in legacy system for a period
of <x> months.
Open PO Lines
Application: Oracle Purchasing
Strategy: Manual
PO lines that have remaining quantities for receipt will be entered

manually into Oracle Purchasing to support subsequent invoice
matching.
Scope: All current open PO lines
PO History
PO history will be available for view in legacy system for a period of

<x> months.
Requisitions
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
Requisition history will be available for view in legacy system for a

period of <x> months.
Asset Base
Application: Oracle Assets
Strategy: Manual
Active assets will be manually entered into Oracle Assets at calculated

net book value and depreciated over the remaining months of their life
cycle - due to the nature of the depreciation calculations (for example
declining balance calculations), minor rounding differences will occur.
Scope: All active, material assets
Asset Transaction History
Application: Oracle Assets
Asset history will be available for view in legacy system for a period of
<x> months.
Customers
Application: Oracle Receivables
Strategy: Manual

Scope: All active customers
Open Invoices
Strategy: Manual

Scope: All current invoices
Invoice History
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
Customer invoice history will be available for view in legacy system for
a period of <x> months.
Payment History
Customer payment history will be available for view in legacy system

for a period of <x> months.
Bank Statement History
Application: Oracle Cash Management
Customer bank statement history will be available for view in legacy

system for a period of <x> months.
Interfaces
Below is a list of interfaces between Oracle and existing systems that have been
identified:
Source Application Destination Application Mechanism Business Objects 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
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
effort, all customizations, legacy data conversions, and custom interfaces need to
be reviewed for Century Date compliance.
The initial, and on-going, planning efforts associated with this applications
implementation project will take into account the impact that previous and current
coding standards have on the current implementation project underway. These
considerations should address areas, such as custom extensions, data conversions,
and interfaces to other applications within the overall system.
Implementation Decisions
The critical implementation decisions applicable to this project are:
Selected Alternative
Decisions Description
Will processes be standardized?

Will we implement the “vanilla” system or
will we customize?
How far will information be distributed and
used?
Will we apply centralization or
decentralization (overall and by function)?
Will the technology be implemented by
phases or a “big bang” approach?
Will we run parallel systems or not?
Impact Assessment
Critical 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
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
Decision
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
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
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
Decision
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
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: ...
Testing Testing will include only ...
Funding Project funding is limited to ...
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
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.
flow(s)).
High Flow The project Training.
Implementatio team’s Effective
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
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:
1. Hire external resources to facilitate completion
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
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.
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
Early Mitigation: Develop disaster recovery processes to minimize downtime

and offset risk.
Availability of Systems
Loss of the development, or production systems environment due to hardware,
software failure or errors in operations during work hours will impact the
fulfillment of project tasks.
Risk: Medium
Consequence: Possible delays in project tasks, possible impacts to project

milestones and/or additional costs to project to make up lost time use additional
resources.
Contingency: Additional staffing to address loss in time.
Early Mitigation: Ensure that hardware/software environment is administered

“as-production” during the implementation process, complete with extensive
backups and high-availability..
Network Availability
Network outages would impact the ability of project team members to carry out
scheduled and planned work.
Risk: Low
Consequence: Loss of the network during work hours will impact the fulfillment
of project tasks.
Contingency: None.
Early Mitigation: Ensure that network provider understands and agrees to the
high availability requirement
Staffing Risks
<Company Short Name> Personnel Required are not Approved by Management

Senior management support for the availability of key project personnel is
critical. If management support is not available, or the nominated project
personnel are not available due to business issues, the project will be impacted.
Risk: Moderate
Consequence: Project commencement will be delayed as alternate personnel are

sought or the project objectives including milestones are reexamined.
Contingency: None.
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
Early Mitigation: Seek executive level commitment and support, request

communication of this support throughout the organization.
<Company Short Name> Personnel Required will not be Available Due to other
Commitments/Workload
Critical to the success of the project, is the appropriate constituent representation
of key users from the business areas. The participation must be consistent, and
through the entire life of the implementation project. Without key decision
makers being available and participating in the appropriate project activities,
decisions require additional circulation and agreement occurs at a higher cost to
the project and the timeline.
Risk: Low.
Consequence: Scheduled project activity may be delayed, potentially impacting

project milestones or budget.
Contingency: Should personnel be unavailable the proper level of authority

should be informed of the situation and steps should be taken to make the
personnel available as required.
Early Mitigation: <Company Short Name> personnel should have the

appropriate approvals and a clear mandate to be available as required.
<Company Short Name> Personnel that are Required do not have Sufficient Skills to Undertake
the Work
Assessment is made during the project planning process as to the training
requirement, aptitude and capacity to contribute for all project personnel. From
time to time, this assessment may be incorrect.
Risk: Low
Consequence: Slippage in deliverables due from <Company Short Name>

personnel, or inadequate level of participation in decision making.
Contingency: Initial coaching, following by escalation to the <Company Short

Name> Project Manager or Management Committee for direction.
Early Mitigation: On project commencement, review with each individual the

expectations for their involvement. Seek agreement with the individual.
<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

Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
Early Mitigation:
Retention of Project Team Members during the Implementation

From time to time, key project personnel may be reassigned to other enterprise
initiatives or leave the corporation.
Risk: Moderate
Consequence: Possible significant impact to project tasks, key deliverables,

project milestone achievement and subsequently budget. Loss of key skills
during critical time frames.
Contingency: Replace personnel as quickly as possible, seek transition when

possible.
Early Mitigation: Ongoing initiative to augment user and technical procedures,

and prepare an in-house training program.
Availability of <Consultant> Resources for Previously Scheduled Work

Like <Company Short Name>, from time to time <Consultant> may have to
deal with unavailability of its resources to the project.
Risk: Low
Consequence: Possible impacts to project tasks, timelines, or milestones
Contingency: <Consultant> to seek alternate resources when available, or

reasonable notice is give to allow rescheduling without impacting project costs or
milestones.
Early Mitigation: Ensure that <Consultant> Resources are scheduled well in

advance and avoid alterations to these schedules
Availability of <Consultant> Resources on Short Notice for Non-Scheduled Work

From time to time, the project may require additional non-scheduled participation
from <Consultant> personnel. As <Consultant> is motivated to schedule its
personnel in advance, <Consultant> may not be in an optimum position to
respond as required.
Risk: Moderate - High
Consequence: Possible delays in project tasks
Contingency: Utilize methods such as video conferencing, fax, telecommuting,

email, teleconference or after hour meetings.
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
Early Mitigation: Schedule <Consultant>’s participation in advance, and set

expectations with respect to <Consultant>’s requirement for advanced
scheduling
Availability of Adequately Trained and Experienced, Low-Cost Alternate Contract Resources in

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

resources available in the marketplace resulting in additional costs and/or delays
in project milestones.
Contingency: Use additional <Consultant> resources at additional higher costs

to the project.
Early Mitigation: Review CV s of all nominated personnel, and select only

those with direct experience with the tools, methods or applications as
appropriate. Seek vendor commitment to cover any such circumstances as above.
Scope, Project Management Risks
Subsequent Analysis during the Project drives Significant not Forecasted BPR
Requirements
The project proceeds with a basic understanding of the degree of Analysis and
Re-engineering of Business Process that is required. From time to time further
requirements or cost savings potential drives opportunities which will rationalize
additional BPR as being required.
Risk: Additional staffing, delays and/or costs to the project
Consequence: Possible delay in achievement of project milestones, possible

additional cost to the project
Contingency: None.
Early Mitigation: None.
Significant Changes in the Scope of the Project

Risk: Low
Consequence: Possible recasting of project objectives, costs and /or milestones.
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
Contingency: Move non-critical project components into subsequent phase.
Early Mitigation: Ensure that all principals agree on project scope at time of
project initiation.
Ability to Define and Achieve a Consistent Series of Business Processes Across all Business Units
Risk: Low
Consequence: Additional project costs incurred as well as costs associated with

supporting the different business processes.
Contingency: None.
Early Mitigation: Executive commitment to a mandate to define a single set of

unified business processes, requirements and reporting across all business units.
Selected Applications Adaptable to Meet Business Requirements with Little

Customization
The project assumes that the business requirements of the enterprise can be met
with a minimum of customization of the base packages.
Risk: Low
Consequence: Additional cost to the project, possible additional unforecasted on-

going maintenance costs.
Contingency: None.
Changes to Business Processes are Achievable and Completed Prior to Affected

Project Activities
There will be some degree of changes to existing business processes within the
enterprise. The assumption is that these changes will be identified during the
solution design phase, and completed by he business in time to avoid impact to
subsequent project activities.
Risk: Low
Consequence: Potential impact on completion of project tasks, time lines or

milestones.
Contingency: None.
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
Unacceptable Degree of Field Support (User Acceptance)

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

accommodate pockets of requirement. Possible lack of input from some business
units or user communities resulting in mis-defined business requirements.
Contingency: None.
Early Mitigation: Deploy a standard project review process and input methods
to support an adequate level of field support for the project. Field representatives
should be appointed to participate in project activities
Project Decisions are Timely, and On-Time

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

ultimate impact on project milestones.
Contingency: None, outside of standard escalation.
Early Mitigation: Seek a clear project charter sponsored by all members of the
management and project committees. The charter should mandate clear and
timely decision making.
Review of Project Deliverables and Sign-Off is Timely

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

ultimate impact on project milestones.
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
Early Mitigation: Seek a clear project charter sponsored by all members of the
management and project committees. The charter should mandate clear and
timely review and approval of project deliverables.
Contingency: None, outside of standard escalation
Tight Time-Frames, Minimal Slack Between Dependent Tasks

Risk: Moderate
Consequence: Delay in dependent tasks; potential delay in go-live
Contingency:
Go-Live Date Accommodates Only One (1) Round of Integrated Testing

To remedy significant deficiencies not discovered during the implementation, an
additional round of comprehensive testing is required (not accommodated for).
Risk: Moderate
Consequence: Additional project cost and/or delay in go-live
Contingency:
Project Milestones are not Achievable (Project Schedule)

Often business dynamics within an enterprise may prevent or work against an
implementation schedule. The assumption being made is that the milestones as
set out are achievable.
Risk: Low
Consequence: Missed milestones, possible delay in go-live/cut-over and

additional project costs incurred.
Early Mitigation: Frequent project monitoring and review
Contingency: None.
Potential Move of <Company Short Name>’s Facilities

Risk: Moderate
Consequence: Disruption to scheduled project activities; disruption in dependent

project activities; potential delay in go-live; additional costs to project
Contingency: None.
Early Mitigation:
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
Scope Control
The control of changes to the scope identified in this document will be managed
through the Change Control procedure defined later in the Project Management
Framework, using Change Request Forms to identify and manage changes, with
client approval for any changes that affect cost or schedules for the project.
Relationship to Other Systems/Projects
It is the responsibility of <Company Short Name> to inform <Consultant> of

other business initiatives that may impact the project. The following are known
business initiatives:



Document Control ii
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
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
Once all of the above deliverables are updated, a new application environment is
established, using the updated software tools for loading setup data, and
preparations for the next test iteration are begun– incorporating changes from the
previous iteration, with the exception of custom extensions. Because of the
longer lead time required to design, build and test custom extensions, they
typically will not be integrated into an environmen until later in the iterative
process.
Conducting a Conference Room Pilot

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

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

setting, in another setting where the testers are physically co-located, or in a
“virtual” conference room setting, where the testers are physically separated, but
are conducting the test in the same test environment. The most important criteria
is that the test scripts employed emulate actual business processes that cross
functional or departmental lines accordinf to the documented business flow, and
that the transaction data is inter-related and builds on itself (e.g. PO is entered for
a Supplier created in an earlier script, receipt is subsequently recorded against the
PO, etc.)
The following table lists the Conference Room Pilots normally included in an
AIM for Business Flows project. Please note that each of these are intended to be
iterated as many times as necessary to achieve the desired objectives.
Conference Room Pilot Objectives
CRP I (First Iteration) Demonstrate and

familiarize the customer
with the Business Flows
being
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
Conference Room Pilot Objectives
CRP I (Second Iteration) Map Business Flows to

the customer’s business
and identify exceptions
CRP II Validate customer Chart

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

tailored solution including
custom extensions and
sample converted legacy
data. Refinement of
solution is still an option
at this point, but the scope
of changes should be
small by this time.
Significant changes at this
point may indicate the
need for an additional
CRP.
Table 1 Conference Room Pilots by Phase
Business Flow Assets

The AIM for Business Flows approach incorporates the use of pre-defined
deliverables, software tools and other assets to accelerate implementation
activities. These Business Flow Assets are prepared in advance for each Business
Flow, and can be leveraged by delivery teams during a project. Some of the
Business Flow Assets include:
 Pre-defined Future Business Model (BP.080 in AIM 3.0 terms)
 Pre-defined Oracle Tutor Procedures
 Pre-defined Application Setup Documents (BR.100 in AIM 3.0 terms)

Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
 Dataload Scripts
 Pre-defined Business System Test Scripts (TE.040 in AIM 30 terms)
 Additional assets will be developed over time. The assets listed above for
existing Business Flows can currently be accessed from the E-Business Suite,
Non-Industry Specific Offerings folder on GlobalXchange.
 In a future release of AIM for Business Flows, all of the Business Flow Assets
will be accessible through an iProjects Workspace utilizing a guided portal
user interface.
Phases
Projects using the AIM for Business Flows approach are conducted in phases.
Phases provide quality and control checkpoints to coordinate project activities
that have a common goal. AIM for Business Flows has five phases as opposed to
AIM 3.0’s six phases. The figure below shows the change in the method’s phase
structure.
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.
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
Definition Phase Overview

The goal of the Definition phase is to plan the project, and rapidly establish a
pre-configured and tested environment for familiarizing the customer with the
Business Flows being implemented. During Definition, workshops are conducted
to educate the customer on critical decsions to be made regarding application
architecture components, such as the Chart of Accounts Structure, Multi-Org
Structure and Trading Community Architecture. These workshops are also
intended to assist the customer in defining those entities.
A second iteration of CRP I is conducted using the same environment, with the
dual objectives of mapping the Business Flows to the customer’s business, and
identifying exceptions/changes that are required to “personalize” the system to
better fit the customer’s needs.
Definition Phase Objectives
The objectives of the Definition phase follow:
 Verify senior executives’ buy-in to the project.
 Facilitate crucial informed project startup decisions.
 Build consensus around project direction scope, objectives, and approach.
 Familiarize customer with Business Flows
 Perform initial mapping of Business Flows to the business
 Develop the Preliminary Conceptual Architecture (TA.030).
 Determine the high-level architectural, technological, and configuration

requirements to support the functional and information needs of the
application system.
 Define the project scope clearly.
 Obtain management approval to proceed with Elaboration.
Key Deliverables
The key deliverables of the Definition Phase are as follows:
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
Deliverable Description
Flow Educated Customer All members of the customer’s

organization who have
participated in CRP I (First
Iteration) – intended to
educate/familiarize them on the
Business Flows being
implemented.
Business Flows Mapped 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.
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
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
Elaboration Phase Overview

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

technical architecture design, and a number of Data Conversion and Performance
Testing preparatory activities.
Elaboration Phase Objectives
The objectives of the Elaboration phase follow:
 Conduct CRP II to refine the solution
 Validate customer’s decisions regarding Chart of Accounts, Multi-Org

and Trading Community Architecture structures
 Refine the technical architecture of hardware and software.
 Develop performance testing models and scenarios.
 Design the security architecture of the new system.
 Develop functional and technical designs for custom extensions,

interfaces, conversion programs, and database extensions.
 Develop unit, link, system, and system integration test scripts.
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
 Design performance test scripts, test transaction programs, and test data
load programs.
 Analyze user learning needs and develop the User Learning Plan
(AP.140).
Key Deliverables
The key deliverables of the Elaboration Phase are as follows:
Disposition/resolution of 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
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.
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
Conceptual Architecture A refinement of the preliminary

conceptual architecture
developed earlier, following
reviews by key members of the
project team and the further
gathering of information during
the progressing project.
Application and 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.
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
Updated System Test Revise the pre-defined System

Script Test Scripts (TE.040) as
required, based on changes
Iteration). The Updated System
Test Script will be utilized
during CRP II.
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

Build Phase Overview

The goal of the Build phase is to confirm that the overall solution meets the
customer’s business needs. During the Build phase, the CRP III environment is
prepared incorporating custom extensions for the first time, and also
incorporating sample converted legacy data. Application configuration changes
resulting from CRP II are also validated during this test cycle. Only minor
changes should be identified, if any, during this test evolution.
Build Phase Objectives
The objectives of the Build phase follow:
 Prepare the Development Environment (MD.090).
 Develop, test, and accept custom software, including:
 application extensions
 data conversion software
 custom application subsystems integrated with Oracle Applications

Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
 Propose a transition strategy for moving from the current system to the
new application system.
 Create, test, and accept database extension and installation routines.
 Finalize the solution in preparation for transition to production
 Conduct CRP III with focus on validating custom extensions and

converted legacy data, in addition to all other aspects of the application
environment
 Develop performance test components, execute performance tests, and

prepare a report.
Key Deliverables
The key deliverables of the Build Phase are as follows:
Listing of potential 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.
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
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.
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

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

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

Transition is a demanding experience for the project team, and in particular, for
the users who have to maintain exposure to two systems until a new production
system is declared.
Transition Phase Objectives
The objectives of the Transition phase are:
 Install data conversion programs and automated utilities.
 Convert and verify legacy data.
 Perform acceptance testing.
 Skill user personnel.
 Prepare the production environment and configure the applications.
 Implement the production support infrastructure.
 Verify that all aspects of the system are ready for transition.
 Begin to use the Production System (PM.080).
Key Deliverables
The key deliverables of the Transition Phase are as follows:
Converted and Verified 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.
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
Skilled Users Prepared users that have learned

what they need to succeed in
their new roles, including
system literacy, procedural
skills, and business skills.
Production Support 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

Production Phase Overview

Production begins immediately with the production cutover. It marks the last
phase of the implementation and the beginning of the system support cycle. A
series of refinements and performance measurement steps is included in this final
phase.
Production Phase Objectives
The objectives of the Production phase follow:
 Provide agreed upon levels of user support.
 Measure system performance and enhance as required
 Maintain the Production System (PM.080).
 Decommission the former systems.
 Propose and plan the future business and technical direction.
 Improve organizational knowledge and skills for the new environment.
 Improve organizational effectiveness through continuous improvement

programs.
 Devote attention to post-implementation issues like user acceptance,

productivity, and human performance support.
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
Key Deliverables
The key deliverables of the Production Phase are as follows:
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.
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

Processes
Processes are also changing in the new approach. The new approach contains
nine processes, as compared to AIM 3.0’s eleven. The most significant change
involves the replacement of three AIM processes (i.e. Business Process
Architecture (BP), Business Requirements Definition (RD), and Business
Requirements Mapping (BR)), with a single new process – Business Process
Mapping.
The graphic below shows the changing process landscape, and highlights where
the changes are significant.
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
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.
Business Process Mapping Overview

Business Process Mapping addresses the activities surrounding the customer’s
initial familiarization with Oracle Business Flows, and the initial mapping of the
Flows to the customer’s business. It also encompasses the definition of customer
data needed to “personalize” the system for the customer, including the Chart of
Accounts, Multi-Org, and TCA structures. Iterative revision activities related to
Business Flows, procedures, and application setups, which are completed after
each CRP cycle, are also part of Business Process Mapping.
The objectives of Business Process Mapping are:
 Review Business Flows representing best use of the applications for the
industry and other industries with relevant processes.
 Understand and document the organizational and financial structure of the

business.
 Quantify the transaction and data volumes required by those
 Define the audit and control requirements for the business information
generated.
 Document the reporting requirements of the organization.

Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
 Establish each Business Flows fit to business needs.
 Identify exceptions and propose initial alternatives; propose feasible bridges

to gaps.
 In corporate changes in systems definition documents and software tools
Application and Technical Architecture Overview

The objective of Application and Technical Architecture is to design an
information systems architecture to realize the business vision. The process takes
the business and information systems requirements and develops a blueprint for
deploying and configuring:
 Oracle, third-party, and custom applications
 supporting application server environments
 critical integration and data distribution mechanisms between applications,

servers, and sites
 computing hardware, including servers and client desktop platforms
 networks and communications infrastructure
The major change in this process involves the in corporation of new integration
techniques available through Oracle 9iAS. The establishment of an Integration
Framework Infrastructure, and related activities are now included in this process
area.
The objectives of Application and Technical Architecture are:
 Define a systems framework to realize the business and information systems

vision of the corporation, where the circumstances and scale of the legacy
systems replacement project warrant it.
 Confirm that the architecture for the replacement systems is compatible with
the existing information systems framework and vision, where the scale of the
replacement is more limited.
 Design an architecture for the replacement systems that is compatible with the
detailed business requirements.
 Design a technical architecture to support the immediate processing capacity

of the new system and for some specified period of future growth.
Module Design and Build Overview

The objective of Module Design and Build is to focus on the design and
development of customizations to satisfy functionality gaps identified during the
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
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
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.
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
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-
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.
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
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.
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
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
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.
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.
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
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:



Plans
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
Phase
Phase includes the implementation of ....
Phase
Phase ...
The detailed tasks and deliverables are defined in the Project Tasks, Deliverables
and Milestones section of this document. A project Workplan is included in
Appendix A.
Client Organization
Listed below are the Strategic Business Units (SBU) of <Company Long
Name>:
SBU Name Current Software Current hardware Oracle 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:



Acceptance
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
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.
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
 The project manager will make a recommendation that will be documented

in the Risk and Issue Log.
 Recommendations will be reviewed at progress meetings and Change
Request Forms raised if client authorization is required, or issues
transferred to Problem Reports if changes to documentation or software are
required as a result of issue resolution.
 If change control is required then the Risk and Issue Form will be submitted
for background information as part of the Change Control process.
 If the issue can be resolved without impacting contractual obligations then
the Project Manager will sign-off the Risk and Issue Log.
 If no action is taken this fact must be clearly indicated in the Risk and Issue
Log.
Change Control
The Change Control procedure is documented below:

 Any modification to or deviation from the agreed functionality, or changes
to the time or costs agreed upon in the contract will be subject to the
following procedure.
 Change requests may be initiated by <Consultant> or the client whenever
there is a perceived need for a change that will affect the contract of work,
such as schedules, functionality, or cost.
 Agreement to a Change Request Form signifies agreement to a change in
overall costs, functionality, or schedules.
Propose Changes
 A change can be identified to both <Consultant> and client project
managers by a resolved problem or issue, document, conversation, or other
form of communication.
 The person who is functionally responsible (from <Consultant>) for the
area of change will:
 Complete a Change Request Form (CRF) for the proposed
changes and submit copies to the relevant parties (possibly
including subcontractors, and technical input) for assessment.
 Record the CRF in the change control log.
 Investigate the impact of the proposed change.
 Evaluate the impact of not performing the change.
 Prepare a response to the proposed change.
 File the CRF original in the project library. This MUST NOT
BE removed except to copy.
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
 Agree with the client whether the change should be performed

and obtain authorization sign-off of the CRF.
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.
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
Investigate Problem
 The project manager or a delegate will assign the problem for investigation.
 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:
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
 Client Project Manager

 Client IT Manager
 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




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
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
Meetings/ Agenda Timing Responsibility Participants Input Output

Media
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
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.
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
 Invitees who cannot attend a meeting should inform the meeting

coordinator or chairperson and assign an attendee to speak to their specific
issues.
 Project meetings should address at a minimum the following:
 accomplishments and upcoming activities
 progress against plan (including resourcing and budget
expenditures, as applicable)
 project dependent deliverables
 issues and resolution
 change control review
 action items
Meeting Structure
The beginning and the end of the meeting are critical times. A strong Open and
Close will provide the structure needed to keep participants focused, clear on key
issues, and ready to take action after the meeting.
In light of the agenda, preparatory materials and instructions, participants should

have a clear understanding of the purpose of the meeting and the expectations for
participating and follow up.
Typical Meeting Opening

Use the following opening:
 Introduction of each participant by name and role (unless all participants
know one another). Provide a project organizational chart so all
participants can relate to the roles described.
 As time allows, a short “ice breaker.”
 Review purpose, objectives and format of the meeting. Confirm agenda.
 Recognize facilitator (for meetings with more than 5 attendees) and meeting
scribe/recorder.
 Briefly review progress from previous meeting’s close (if regular meeting).
Typical Meeting Closure

Use the following close:
 Summarize key issues with related levels of urgency.
 Ensure participants have a clear understanding of next steps.
 Review action items and follow up steps/contacts.
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
 Conduct a brief meeting process review: what went well and what needs
improvement for next meeting.
Thank attendees for their participation.
Workplan Control
The Project Workplan will be updated from project staff timesheets on a weekly
basis. At monthly intervals the latest status will be reported to <Company Long
Name> and <Consultant> management as part of Status Monitoring and
Reporting (see the Control and Reporting section).
Each week the Project Workplan will be baselined by saving it to a file with the
week number coded in the filename, so that it is possible to trace project data
back to previous versions of the Workplan.
An initial baseline for the Project Workplan is included in Appendix A to this

plan.
Financial Control
The Finance Plan is maintained by the project with financial reporting to

<Consultant> as part of Status Monitoring and Reporting (see the Control and
Reporting section).
Document Control ii
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




Staff Resources
Project Team
The project organization is shown in figure 1 below.
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
Name
Title
Name Name Name

Title Title Title
Name
Name Name
Name
Name Name
Name
Name Name
Name
Name Name
Name
Name Name
A
separate Organization Plan (wall chart) with named individuals is maintained and
updated for the project as a communication tool. Assignment Terms of Reference
for staff assigned to the project are maintained in the associated Staffing and
Organization Plan.
Project Roles and Responsibilities
Project Manager
The project manager is responsible for:
 Developing project plans
 Assigning tasks to other project personnel
 Monitoring staff and project
 Managing risks and escalated issues from project teams
 Controlling budgets, scheduling resources, and recommending
implementation approaches
 Assuming overall responsibility for the successful conclusion of the project
 Measuring project success against budget, original scope, business
objectives
Project Management directives include:
Document Control ii
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
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
 Identifying feasible alternative solutions that minimize the need for custom
development
 Reviewing existing work practices in order to recommend modifications or
enhancements that enable the company to derive maximum benefits from
the products
 Identifying any external data requirements and defining phased data load
and validation procedures
 Assisting with the specification of representative data sets and business
scenarios for acceptance testing
 Transferring the appropriate business and technical skills to other project
team members
The individuals who fulfill this role are likely to have the following
qualifications:
 Accounting, Manufacturing, Distribution, or Human Resources
Management Systems background
 Thorough understanding of the applications
 Experience in implementing application systems
In general, the assigned persons will be responsible for tasks requiring specific
skill sets. When <Company Short Name> resources change, the client project
manager will ensure that these project team members transfer sufficient
knowledge and ensure that coverage exists for any outstanding assignments. If
resource changes occur within the <Consultant> staff, the project manager will
use the same approach to maintain continuity and avoid unnecessary delays in
progress.
Some tasks will require representation from various <Company Short Name>
functional areas. The client will provide all necessary resources to support these
tasks.
Education and Skilling
Refer to the Project Team Learning Plan (AP.030), Project

Readiness Roadmap (AP.070), and Learning Plan (AP.140)
deliverables for more detailed information about the project team
and end-user skilling requirements for the project.
The staff involved with this project (including client staff) are all suitably
qualified in terms of background, experience, and skills in the tasks to be
undertaken, with the following exceptions that will be catered to during the
course of the project as defined below:
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
Client Staff Skilling Needs




<Consultant> Staff Skilling Needs




Physical Resources
Project Software/Tools
The software supplied will be in accordance with the contract and the schedules
to contract or as amended under formal Change Control. This includes:
Oracle Software



Operating and Other System Software




Software Tools



Hardware
The hardware and operating software to be used will be that specified in the
contract or schedules to contract or as amended under formal Change Control.
This includes:


Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
Project Environments
The project <process name> environment is located at <location> and consists of:



Refer to the Architecture Requirements and Strategy (TA.010)
deliverable for more detailed information about the strategy for the
project environments.
Software Backup Procedures and System Administration
Backups and basic system administration (machine start-up, shutdown, and

recovery) of the working environment software installation will be performed
<daily> by <Consultant> staff/client staff.
Database sizing and instance synchronization will be performed by

<Consultant> staff/client staff.
Document Control ii
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

Quality Management Standards and Procedures




Technical Standards



Quality Reviewing
Reviews will be carried out for each deliverable (documentation and software)
using the technique nominated in the Deliverables sub-section of the Scope
section of this plan or the Project Management Framework document. A record
of all deliverable reviews will be kept as an audit trail for resolution action.
Techniques and responsibilities are as defined below:
A Technical Review focuses not just on looking for errors and incompleteness
(as is the purpose of any Review), but evaluates the technical aspects of a
deliverable e.g., elegance of code, functionality, etc. A Technical Design Review
is a special type of Technical Review (see below). A Technical Review is
usually conducted as part of a Walkthrough or an Inspection.
A Walkthrough (individual or group) is a review whereby the reviewer(s) step

through a deliverable to check for errors, inconsistencies, incompleteness, etc.
The findings and actions of the Walkthrough must be documented. For group
Walkthroughs someone should lead the review.
An Inspection has the same purpose but is a more formal version of a

Walkthrough. Formal roles are assigned to reviewers. These roles are:
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
 Moderator (leads the review)

 Author (of the deliverable being reviewed)
 Reader (reads out the part currently being reviewed)
 Recorder (documents findings)
 One or more reviewers who may also be role-playing (e.g., the customer
view, the <Consultant> technical view, <Consultant> PM view, etc.).
These types of reviews are extremely thorough since role-playing ensures that the
deliverable is evaluated from many different angles and there is a great deal of
preparation before the Inspection itself. It is therefore the most expensive type of
review to run, and should be used when appropriate (e.g., for end of phase
deliverables, for mission-critical deliverables).
Quality Auditing
Audits of Quality Management will be conducted during the project by

<Auditor> at the following points:
Audit <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
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
 System Testing
 Integration Testing
 Acceptance Testing
Test Execution
The following project roles are responsible for test execution:




The following methods will be used to document the results of test execution:



Measurement
The following project metrics will be collected during the project and used as part
of progress reporting:
Project Metrics Collection

1. Time to design and build modules of all types
2. Number of modules under development
3. Percentage of effort spent on reviews
4. Percentage of effort spent on rework
5. Effectiveness of reviews
6. Effectiveness of system testing
7. Number of problems encountered during System Test
8. Average hours to fix a defect during development
9. Percentage of bad fixes for development
10. Variances between estimates and actuals (effort and time)
11. Number of problems at Acceptance
Reporting
1 to 8 during the project, 9 to 11 on project completion (in the project end report)
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
Business Processes Metrics Collection

The business process metrics that will be measured in the Effectiveness
Assessment (AP.180) at the end project are as follows:



Refer to the Business Unit Managers Readiness Plan (AP.060) and
the Managers Readiness Plan (AP.090) deliverables for more
detailed information about the metrics to be captured for the project.
Document Control ii
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

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

Abf BT070 Project MGMT Framework

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Abf BT070 Project MGMT Framework

Încărcat de

Drepturi de autor:

Formate disponibile

AIM for Business Flows

BT.070 PROJECT MANAGEMENT

Date Author Version Change Reference

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

Copy No. Name Location

<Subject> Document Control ii

<Subject> Document Control ii

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

<Subject> Document Control ii

The purpose of this Project Management Framework is to define the approach to

Commonly referred to as the “Scope, Objectives and Approach” (SOA)

The bulk of he document is dedicated to a detailed discussion of the overall

 Methods and Strategies

 The planning approach – Tasks, Deliverables and Milestones

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

 Work Management – meetings, communication, workplan and financial

 Resource Management – staffing, project team organization, roles and

 Quality Management – quality reviews, testing, etc.

 Configuration Management – document control, release management, etc.

Business Flow Implementations

Oracle Consulting (OC) has developed an implementation strategy designed to

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

 Accelerated implementation timeframes

 Improved quality of solutions

 Improved ROI for Customers

With every investment in technology undergoing greater scrutiny in today’s

so that the success of the software and implementation is measured in terms of

Business Flow Defined

Beginning the implementation with a pre-defined future process model, makes it

Business Flow Content

 Business Procedures – these Oracle Tutor-built procedures, based on the

 Business Flow/Application Product Cross-reference – the Business

 Operational Management Reporting – this deliverable (TA.060) describes the

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

 A business process 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

A flow-based implementation approach, by contrast, has integrated business

A Predefined Future Process Model as a Starting Point

In a traditional AIM, “assemble to order” engagement, the future process

In a flow-based implementation, predefined Business Flows are used as the

Follows Dynamic Systems Development Method (DSDM) Principles

AIM currently follows a traditional information systems engineering

The flow-based implementation approach will adopt the DSDM principles of

Early Introduction of Hands-on Testing

In a traditional AIM approach, a good deal of time is spent early in the

The early introduction of hands-on testing and experimentation by the

Iterative Validation Cycles

In a traditional AIM approach, Business System Testing, commonly referred

In a flow-based approach, business system testing also serves to validate the

In a flow-based implementation approach, iterative business system

business requirements mapping sessions do in an AIM engagement. They

Requirements Mapped to Business Flows

In a traditional AIM approach, detailed business requirements are typically

In a flow-based implementation approach, business requirements are mapped

Risk Mitigation Benefits

A flow-based approach, by its nature, provides a number of benefits that serve