Abf BT070 Project MGMT Framework
Abf BT070 Project MGMT Framework
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
Reviewers
Name Position
Distribution
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.
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........................................................................................
<Subject> Document Control ii
File Ref: 54683598.doc (v. DRAFT )
BT.070 Project Management Doc Ref: <Document Reference Number>
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...................................................................
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
Organization
Infrastructure
Acceptance
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
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.
Improved communications
Reduced customizations
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.
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
For most customers, Oracle’s pre-defined business flows will serve as a starting
point, or baseline, for developing a tailored solution. While the pre-defined
business flows may be suitable for some smaller clients without modification,
most customers, particularly large enterprise customers, will likely “personalize”
the flows to meet their unique requirements.
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.
KPIs – each flow is associated with a standard set of KPIs which can be
reported on throughout the implementation using standard application/BI
reports
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:
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.
A KPI focus
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.
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.
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
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.
Scope Control
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
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.
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
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
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.
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
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
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.
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:
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.
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>:
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>:
Company
Cost Center
The cost center segment will be 3 characters in length, alpha-numeric and will
be displayed in the 2nd position.
Account
Future
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
Strategy: Manual
Strategy: Manual
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
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
Strategy: Manual
Employees
Strategy: Manual
Open Invoices
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
Strategy: Manual
PO History
Requisitions
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
Asset Base
Strategy: Manual
Asset history will be available for view in legacy system for a period of
<x> months.
Customers
Strategy: Manual
Open Invoices
Strategy: Manual
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
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
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
Selected Alternative
Decisions Description
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:
Critical Rationale for Major Impact on Major Impact on Major Impact on Consequences of
Implementation Decision Technology Processes People Impact/Actions to Manage
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:
Critical Rationale for Major Impact on Major Impact on Major Impact on Consequences of
Implementation Decision Technology Processes People Impact/Actions to Manage
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
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
Scope
Scope of Project
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.
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
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.
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.
Contingencies:
1. Hire external resources to facilitate completion
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
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
Implementation of this Project will Impact <Company Short Name>’s other Current System
Initiatives
Risk: Low
Contingency: Modify source systems or interface from the new financial system
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
Risk: Low
Contingency: None.
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
Oracle Release Upgrades are not Transparent (i.e.,. Installation Implications not Easily Managed)
Risk:
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
Contingency: Additional contracted efforts will address any issues in this area.
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
Contingency: None.
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
Availability of Systems
Loss of the development, or production systems environment due to hardware,
software failure or errors in operations during work hours will impact the
fulfillment of project tasks.
Risk: Medium
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
Risk: Moderate
Contingency: None.
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
<Company Short Name> Personnel Required will not be Available Due to other
Commitments/Workload
Critical to the success of the project, is the appropriate constituent representation
of key users from the business areas. The participation must be consistent, and
through the entire life of the implementation project. Without key decision
makers being available and participating in the appropriate project activities,
decisions require additional circulation and agreement occurs at a higher cost to
the project and the timeline.
Risk: Low.
<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
<Company Short Name> Technical Personnel Inexperienced with UNIX System Admin and Oracle
Database Admin
Risk: Low
Early Mitigation:
Risk: Moderate
Risk: Low
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
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.
Contingency: None.
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
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
Contingency: None.
Risk: Low
Contingency: None.
Risk: Low
Contingency: None.
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
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
Risk: Low
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.
Risk: Low
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:
Risk: Moderate
Contingency:
Risk: Low
Contingency: None.
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.
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
Objectives
Mission Statement
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
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:
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:
Identify Exceptions
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:
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
Application Setup documents, and associated software tools for loading the
modified setup data
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.
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.
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
Dataload Scripts
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.
Production
Transition
Definition
Design
Build
Elaboration
Production
Definition
Transition
Build
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
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.
Key Deliverables
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
Deliverable Description
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
Deliverable Description
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
Deliverable Description
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
Deliverable Description
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
Deliverable Description
application extensions
Propose a transition strategy for moving from the current system to the
new application system.
Key Deliverables
Deliverable Description
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
Deliverable Description
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
Verify that all aspects of the system are ready for transition.
Key Deliverables
Deliverable Description
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
Deliverable Description
Key Deliverables
Deliverable Description
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:
Review Business Flows representing best use of the applications for the
industry and other industries with relevant processes.
Define the audit and control requirements for the business information
generated.
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.
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.
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
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.
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.
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.
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.
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).
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.
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
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.
Define, construct, and execute one or more performance test on the entire
implemented system or particular components of the system.
Establish a performance test model and environment that can be used for
continuing performance regression testing throughout the implementation
project and into production operation.
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
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.
executives
functional managers
users
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.
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
Strategy
The project management strategies for the project are defined later in the Project
Management Framework.
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 includes the implementation of ....
Phase ...
Phase includes the implementation of ....
The detailed tasks and deliverables are defined in the Project Tasks, Deliverables
and Milestones section of this document. A project Workplan is included in
Appendix A.
Client Organization
Listed below are the Strategic Business Units (SBU) of <Company Long
Name>:
There are <Number of Sites> number of sites that comprise the <Company
Short Name> information network.
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:
Project Administration
The following administrative arrangements have been made for this project:
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
Planning Approach
Key Deliverables
This section defines the tasks and key deliverables for each phase described
above.
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:
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.
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
Change Control
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:
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
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.
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.
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:
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.
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:
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:
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.
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.
Financial Control
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.
Staff Resources
Project Team
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
Name
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 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:
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
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.
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:
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
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.
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.
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.
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
Quality Auditing
Test Management
Test Strategy
Test Levels
System Testing
Integration Testing
Acceptance Testing
Test Execution
Measurement
The following project metrics will be collected during the project and used as part
of progress reporting:
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:
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 Definition
Document Files
Word Files
Graphics
Spreadsheets
Application Specific
Other
Programs
Forms
Reports
C-Programs
Conversion programs
Read files
Interface Programs
Procedures
Document Control ii
File Ref: 54683598.doc (v. )
Doc Ref:
Document Control
Configuration Control
Knowledge Management
Release Management
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:
Document Control ii
File Ref: 54683598.doc (v. )