The preliminary application implementation project estimate is based on:
• What is the business objective?
• What is the vision for the project?
• How do Oracle Applications contribute to the vision?
• What is the scope of the project and how does it relate to the
overall vision?
• Who will participate in the project (employees, consultants, or
vendors)?
• What are the constraints affecting the project (timing, budget
limitations, or organization changes)?
• Which applications will be implemented?
• Which sites will be involved?
• Will a phased-deployment be employed? If so, in what
sequence will the applications be implemented?
• When will work commence?
• What experience does the organization have regarding the
technology that will be used?
Before creating a detailed work plan, develop the project scope, suggested approach, and preliminary budget. Use an iterative process where different project scenarios are defined at a summary level and then estimated.
Generally accepted industry practices include using experience and results from similar projects to develop estimates for the different scenarios.
The final budget should be developed using a detailed bottom-up estimating process based on the detailed work plan. This project plan should include:
• Task Listing
• Dependencies
• Deliverables
AIM includes a project workplan template in ABT Project Workbench and Microsoft Project. This template provides a starting point for developing the detailed work breakdown structure and contains all the AIM tasks with associated role type resource assignments,
dependencies, and deliverable names.
When estimating an Oracle Application implementation project, the following six steps should be taken:
1. Determine optional tasks to include in your project. 2. Change the role type resource assignments to the physical
resources that will be employed on the project.
3. Read the AIM Process and Task Reference and use your organization’s guidelines to determine the task level estimates, making sure you adjust your estimates based on the skill levels of the project resources.
4. Allocate reasonable contingency for unforeseen issues that will occur.
5. Review your workplan with project stakeholders and modify it as required.
6. Obtain approval for your project workplan.
Use the approved workplan to baseline the project, then use it to track the progress of the work on a day-to-day basis.
C H A P T E R
2
Definition
his chapter describes the Definition phase of AIM. The goal of the Definition phase is to determine the high-level business and information system requirements necessary to meet a set of defined business objectives. The Definition phase results in a clear definition of a project’s functional scope.
Definition Operations
Analysis Build
Business Process Architecture Business Requirements Definition Business Requirements Mapping
Module Design and Build Application and Technical Architecture
Data Conversion Documentation Business System Testing Performance Testing Adoption and Learning Production Migration
Solution Design Transition Production
Overview
This section provides an overview of the Definition phase.
Objectives
The objectives of the Definition phase follow:
• Obtain a clear understanding of the business processes,
functions, and information required to meet the project’s defined business objectives.
• Identify unifying vision and business objectives.
• Verify senior executives’ buy-in to the project.
• Create a leadership pattern across the organization.
• Initiate a sponsorship network.
• Facilitate crucial informed project startup decisions.
• Design an effective infrastructure for delegation.
• Build consensus around project direction.
• Review the organization’s existing processes and align them
with the capabilities of the relevant Oracle Applications modules and other software.
• 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.
• Examine the existing business processes and information
systems affected by the project’s defined business objectives.
• Design improved high-level business processes.
• Obtain management approval to proceed with Operations
Critical Success Factors
The critical success factors of the Definition phase are as follows:
• sponsorship of senior management that is clear and visible to
the project stakeholders
• clear definition of the business objectives
• active participation by key management and knowledgeable
users and technical representatives from the areas of the business affected by the project’s objectives
• access to information related to the existing business processes
and systems affected by the project
Prerequisites
Prerequisites for the Definition phase follow. You should use these prerequisites, if they exist, prior to beginning the project. Otherwise, you need to create them during this phase. Some of the prerequisites identified below are also deliverables produced within this phase. The reason they are included in this section is because they are used as input to other tasks within this phase.
Prerequisite Source
Organizational Chart Organization
Enterprise and BPR Strategy Studies (if available)
Organization
Existing Process Data Organization
Tender Documents Organization
Existing Reference Material Organization
Architecture Designs and Technical Documents from Application Acquisition Process
Prerequisite Source Existing System Architecture or
Technical Configuration Documents
Organization
Existing System Management Procedures Documents
Organization
Existing Systems Testing Strategy or Policy Documents
Organization
Existing Business Documentation Standards
Organization
Contractual and Business Agreement Organization and Oracle
Current Business Reports Organization and Oracle
Return on Investment (ROI) Analysis Oracle
Project Management Plan Project Management (PJM)
Control and Reporting Strategies, Standards, and Procedures
Project Management (PJM)
Work Management Strategies, Standards, and Procedures
Project Management (PJM)
Project Progress Report Project Management (PJM)
Project Orientation Guide Project Management (PJM)
Physical Resource Plan Project Management (PJM)
Prepared Infrastructure Project Management (PJM)
Quality Management Strategies, Standards, and Procedures
Project Management (PJM)
Business and Process Strategy Business Process
Architecture
Current Process Model Business Process
Prerequisite Source
Leading Practices Review Business Process
Architecture
High-Level Process Vision Business Process
Architecture
High-Level Process Designs Business Process
Architecture Current Financial and Operating
Structure
Business Requirements Definition
Current Business Baseline Business Requirements
Definition Architecture Requirements and
Strategy
Application and Technical Architecture
Preliminary Conceptual Architecture Application and Technical
Architecture
Application Extension Strategy Module Design and Build
Data Conversion Requirements and Strategy
Data Conversion
Documentation Requirements and Strategy
Documentation
Testing Requirements and Strategy Business System Testing
Performance Testing Strategy Performance Testing
Executive Project Strategy Adoption and Learning
Oriented Project Team Adoption and Learning
Project Team Learning Plan Adoption and Learning
Project Team Learning Environment Adoption and Learning
Prerequisite Source Business Unit Managers’ Readiness
Plan
Adoption and Learning
Project Readiness Roadmap Adoption and Learning
Table 2-1 Definition Phase Prerequisites
Processes
The processes used in this phase follow: Business Process Architecture (BP)
Define a strategy for changing the organization’s business processes and align them with the system to be implemented. Determine potential changes to the application and to the organization’s processes. Review leading practices and relevant processes material to create a high-level vision of the future, including High-Level Process Designs (BP.070). Business Requirements Definition (RD)
Gain a complete baseline understanding of current events and business processes.
Application and Technical Architecture (TA)
Identify the requirements that influence the architecture and define the strategy for satisfying those requirements. Create an initial integrated conceptual model of the application and technical architecture. Module Design and Build (MD)
Define a strategy for extending and customizing the applications and developing custom interface software.
Data Conversion (CV)
Identify the data conversion requirements and define the strategy for converting the legacy data.
Documentation (DO)
Define a glossary of terms for the project. Specify the documentation requirements and determine the documentation standards and procedures.
Business System Testing (TE)
Define a Testing Requirements and Strategy (TE.010) that encompasses all tasks in the testing process. Include an overview of the testing approach, the type of test scripts to be developed, the testing to be performed, a schedule of testing resources and responsibilities, the testing tools and environments required, and a discussion of the problem management process.
Performance Testing (PT)
Define the strategy for the performance testing process, including testing scope, objectives, measurements to make, testing methods, and testing tools.
Adoption and Learning (AP)
Define the high-level project strategy and expectations at the executive level. Conduct the initial project team orientation. Develop the learning plan, prepare the learning environment, and conduct the learning events for the project team. Initiate a change leadership model and define business performance improvement strategy with business unit managers. Assess the organization’s readiness for the project and develop a readiness roadmap. Plan and initiate the Communication Campaign (AP.080) for the project.