Vra Bp90 Oraclehrms III v2.1

Doc Ref: GEN/CR.010/PTC/1.
CR.010 PROJECT MANAGEMENT

PLAN
PUBLIC TELECOMMUNICATION
COMPANY. LTD (PTC)
ERP Implementation Project
Author: Alaa Elattar

Creation Date: June 20, 2005
Last Updated: June 20, 2005
Document Ref: GEN/CR.010/PTC/1.0
Version: 1.0
Approvals:
PTC Representative
GIZASYSTEMS
Representative
File Ref: 413663190.doc Scope 1

Company Confidential - For internal use only
Doc Ref: GEN/CR.010/PTC/1.0
Document Control
Change Record
42
Date Author Version Change Reference
June 20,2005 Alaa Elattar 1.0 Initial Document
Reviewers
Name Position
PTC Project Sponsor

PTC Project Manager
Alaa Elattar GIZASYSTEMS Project Manager
Distribution
Copy No. Name Location

1
Library Master Project Library
2 PTC PTC Office Library
3 GIZASYSTEMS GIZASYSTEMS Office Library
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...................................................................................................................2
Introduction..............................................................................................................................5
Purpose...............................................................................................................................5
Background........................................................................................................................5
Scope and Application.....................................................................................................5
Related Documents..........................................................................................................6
Scope..........................................................................................................................................7
Scope of Project.................................................................................................................7
Constraints.........................................................................................................................9
Risks....................................................................................................................................9
Scope Control....................................................................................................................9
Relationship to Other Systems/Projects.......................................................................9
Objectives................................................................................................................................10
Mission Statement..........................................................................................................10
Critical Success Factors..................................................................................................10
Project Objectives............................................................................................................11
Approach.................................................................................................................................12
Project Methods..............................................................................................................12
Strategy.............................................................................................................................12
Project Work plan...........................................................................................................12
Acceptance.......................................................................................................................13
Project Administration...................................................................................................13
Project Tasks, Deliverables, and Milestones.....................................................................14
Planning Approach.........................................................................................................14
Key Deliverables.............................................................................................................14
Control and Reporting..........................................................................................................16
Risk and Issue Management.........................................................................................16
Change Control...............................................................................................................17
Problem Management....................................................................................................18
Status Monitoring and Reporting................................................................................19
Team Reviews.................................................................................................................19
Work Management................................................................................................................20
Communication Model..................................................................................................20
Meeting Preparation.......................................................................................................21
Meeting Structure...........................................................................................................21
Work Plan Control..........................................................................................................22
Financial Control.............................................................................................................22
Resource Management..........................................................................................................23
Project Team....................................................................................................................23
PTC - Project Roles and Responsibilities....................................................................24
GIZASYSTEMS - Project Roles and Responsibilities................................................26
Education and Skills.......................................................................................................27
Physical Resources..........................................................................................................28
Project Environments.....................................................................................................29
Software Backup Procedures and System Administration......................................29
Quality Management.............................................................................................................30
Quality Management Standards and Procedures.....................................................30
Quality Reviewing..........................................................................................................30
Quality Auditing.............................................................................................................31
Test Strategy....................................................................................................................31
Test Levels.......................................................................................................................31
Test Execution.................................................................................................................31
Test Procedure................................................................................................................32
Measurement...................................................................................................................32
Configuration Management.................................................................................................33
Configuration Definition...............................................................................................33
Appendix A – Work Plan.....................................................................................................34
Appendix B - Risks, Risk and Issue Form and Register..................................................35
Risks..................................................................................................................................35
Scope, Project Management Risks................................................................................36
Organization and Management Risk...........................................................................38
Staffing Risks...................................................................................................................38
Interfaces and Integration Risks...................................................................................39
Technical Risks................................................................................................................40
Hardware, Network, Software Risks..........................................................................41
Appendix C – Change Request Form and Log.................................................................44
Appendix D – Oracle Application Implementation Methodology Introduction........47
AIM Methodology..........................................................................................................47
Overview of System Components Implementation Methodology.........................48
Appendix E – Problem Report Form and Log..................................................................50
Appendix F – Meeting Minutes & Progress Report.........................................................53
Appendix G – Acceptance Certificate................................................................................57
Appendix H – Project Team Contact Information............................................................59

Introduction
Purpose
The purpose of this Project Management Plan is to define the scope and objectives of
the project and to define the approach to the project management and quality
control that will be applied to the ERP project for Public Telecommunication
Company (PTC).
This document is also a reference point for the ERP project implementation, defining
project components such as scope, objectives, organization, and roles and
responsibilities for resources to manage project tasks and deliver appropriate
business solutions critical to PTC’s success.
Background
PTC has decided to automate the functions related to the Modules and selected to
implement a complete ERP Package that includes Oracle Financials, HR and Payroll.
The project objective is to implement the ERP Modules within scope using a sub-set
of Oracle’s implementation methodology attached in Appendix D tailored to meet
PTC’s business requirements and the agreed upon scope of work of this project.
Scope and Application

This Project Management Plan defines the following topics for Project Management
of the ERP Project as follows:
 Scope
 Objectives
 Approach
 Testing Process and Quality Criteria
 Business System Acceptance Criteria
 Project Administration
 Project Tasks, Deliverables, and Milestones
The following topics will contain the standards and procedures that should be followed
for this project:
 Control and Reporting (issue management, scope change control, progress
reporting, etc.)
 Status Monitoring, Reporting and Communications
 Work Management (management of tasks and project budget information)
 Resource Management (management of staff including Roles and
Responsibilities, as well as physical resources)
 Physical Resources
 Quality Management (reviews of deliverables, testing, Health-checks, etc.)
 Configuration Management (how project intellectual capital and software
are to be managed)
 Project Assumptions
The plan will apply to both PTC and GIZASYSTEMS staff involved in the project; it
defines the scope of the project, the implementation approach and the project-
controlling framework.
Related Documents
1. GIZASYSTEMS’s Contract for Professional Services to PTC.
2. PTC ERP Project Plan

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. This project scope includes the ERP implementation.
ERP Scope
Applications The following applications are included in the

implementation:
 General Ledger
 Accounts Payable
 Accounts Receivable
 Fixed Assets
 Cash Management
 HRMS & Payroll
 Integration with CBOSS
The implementation of the English version of
the Oracle Applications is not within the scope
of this project. The Oracle Applications that
are within the scope will be, configured to
include English with Arabic character sets.
However, the Arabization of certain reports
such as the trial balance is not included within
the scope of this project.
Implementation Site Implementation will occur at PTC’s

Headquarters in Riyadh for the project
duration. Any key customer staff required to
participate will be, expected to travel to the
Headquarter site.
Process Re-engineering Not Applicable
Customization Customizations are usually required in two

different areas. The first is for reports and the
second is within the Application’s
functionality and sessions. The above
customizations are called soft and hard
customizations respectively.
The project scope does not include any of

these customizations as the standard Oracle
Application reports will be used. PTC should
have a trained “Champion Report Writer” to
perform soft customizations as and when
needed in the future and through,

GIZASYSTEMS’s scope to provide additional

reports, limited to only 10 reports, provided,
that such reports are based on the fields and
functions built in the core application. PTC
should identify the 10 reports prior to the
completion of implementation period.
Interfaces SQL files from PTC’s billing system will be,

imported into the Oracle Application(s)
through a batch process. The type, nature and
extent of the data imported will be determined
during the solution design phase.
PTC Architecture Technical Architecture for the ERP

implementation will be based on the high-level
design document TA.020.
PTC is implementing a 3 tier network
computing architecture that includes the
following components:
 <Hardware Servers>
 <Operating System>
 Oracle Applications Version 11i release
 Oracle RDBMS Version
 Internet Explorer Version 5.5 or above
 2 RDBMS environments Test &
Production
 2 installations of the Oracle Applications
against the following environments:
 Test
 Production
 PC workstation
 Network
It is the responsibility of PTC to ensure the
availability and connectivity of PC
Workstations and Networks to all locations
that should be connected to the above
applications.
Testing and Acceptance Full business system testing will be,

performed based on the approved test scripts
during the Solution Phase. The User
Acceptance and sign-off will be based on each
individual module.
Training Training will be, conducted on the job for the

functional personnel within PTC. That is, for
PTC’s functional team members, hands-on
training will be, conducted by our team while
testing the future requirement processes in the
test system through, the use of the test scripts.
It should be noted that PTC’s technical team

members should undertake an official training
covering the following functions/areas:
 Data Base administration
 Application administration
The extent and type of training will depend on
the current skill sets at PTC’s IT Department
and the level of knowledge in Oracle
Applications.
Constraints
The following constraints have been, identified:
 Availability of the network infrastructure
 Availability of the hardware
1. Test server
2. Production Server
 Quality of internet connections for Oracle support purposes
 Data gathering on a timely basis
 Availability of the key functional users during the project implementation
period
Risks
Certain 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 Plan.
An addendum of agreed risks and their associated contingencies are included in
Appendix B.
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 Control and Reporting’
section of this document. Change Request Forms should be used be used to identify
and manage changes, with PTC/GIZASYSTEMS approval for any changes that
affect cost or schedules for the project.
Relationship to Other Systems/Projects

There may be some projects that PTC is currently undertaking or might undertake in
the near future that would impact the ERP Implementation project. GIZASYSTEMS
should be aware of such projects or initiatives although they are not within
GIZASYSTEMS’s ERP Project scope.

It is the responsibility of PTC to inform GIZASYSTEMS on the above projects or

initiatives that may impact the project – failure to do so will have an adverse impact on
the project.

Objectives
Mission Statement
The project mission is to implement a financial management information system
(ERP) to meet accounting, reporting requirements and to enhance the business
process for PTC with the goal of achieving the predetermined objectives of the
scope, cost, time, quality and participant satisfaction
. The system incorporates Oracle Financials’ (General Ledger, Accounts Payable,
Accounts Receivable, Fixed Assets and Cash Management), and HRMS (HR &
Payroll) modules based on the Company’s business requirements and the agreed
upon scope of work.
Critical Success Factors

Critical success factors are key elements that need to be in place to facilitate
successful achievement of project objectives.
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;
 User input into the design of the system, especially around business
processes;
 Clear roles and responsibilities defined for the project team in order to
assure accountability, ownership, and quality;
 Fast and informed decision making throughout the project cycle at all levels,
with quick approval and sign-off of project documentation;
 Prompt addressing and rapid closure of issues;
 A committed and well-informed project managers and project team
members having a thorough understanding of the project mission, goals,
and milestones;
 A comprehensive project Work Plan and Project Management Plan tightly
controlled throughout the project;
 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, with contingency
plans in place;
 A no-modification policy for the implementation;
 Strong end-user commitment to learning, using and taking responsibility for
the new applications.

Project Objectives
The objectives of the project are to facilitate change and provide PTC with
significant and lasting business benefits through:
 Implementing Oracle ERP Software package that provides information in a
timely manner to support management, and provides access to all
appropriate users of business information;
 Going live with financial and other modules within the expected time frame;
 Sufficiently trained key users capable of using the new applications;
 Coordinating all activities required to achieve these changes, with particular
focus on managing the impact of change on PTC’s people.

Approach
The approach includes the following main areas:
 Project Methods
 Strategy
 Plans
 Client Organization
 Acceptance
 Project Administration
Project Methods
This project will be managed using Oracle’s Implementation Methodology (AIM)
tailored to meet PTC’s business requirements and the project scope of work. The
details of the above methodology are attached in Appendix D.
Strategy
The strategy for the project will be to implement the base accounting (GL, AP, AR,
FA, and CM). As well as HR, Payroll, at PTC’s Head Office in Riyadh. The
implementation will be, performed in parallel for all modules based on the detailed
project work plan in Appendix A.
All modules will be, implemented, with no customization and based on the scope of
work section of this manual.
The project strategy will also focus on ensuring that there are no redundancies
between Oracle Applications and the existing systems at PTC.
Acceptance testing and sign-off will be, performed for each module before going
live. The testing process will take place at Head Office through, the use of test
scripts that are, based on the future business requirements.
Training will be, conducted during testing due to the nature and timing of the
project. Following the approval of the scripts, the production system setup will be,
configured ready for going live.
All functional training related to key users will be, performed at the Company’s
Head Office. Users from remote offices and / or regions are, expected to travel to
the Head Office for training purposes.
Project Work plan
In this implementation
The detailed tasks and deliverables are defined in the Project Tasks, Deliverables
and Milestones section of this document. A detailed project Work Plan is included
in Appendix A.

Acceptance
Upon the completion acceptance of the project, PTC will be asked to sign an
Acceptance Certificate as a record of the successful completion of the project to its
defined scope. There will be one acceptance certificate for each module. Please refer
to Appendix G.
Project Administration
All administrative equipment needed for this project is listed under the physical
resources section of this manual.

Project Tasks, Deliverables, and Milestones
Planning Approach
This project will be, managed using Oracle’s Implementation Methodology (AIM)
tailored to meet PTC’s business requirements and the scope of work of this project.
The methodology covers all phases of the project. The methodology covers the
following phases:
 Definition
 Operations Analysis
 Solution Design
 Build
 Transition
 Production
Key Deliverables
This section defines the tasks and key deliverables for each phase described in the
Project detailed Work Plan in Appendix A. All deliverables will be produced with
input from all parties but in general the generation of paper-based deliverables will
be the responsibility of GIZASYSTEMS consultants. The deliverables and milestones
outlined below will be reviewed and possibly reduced or expanded during the
project life cycle.
These tasks and milestones cover the following in connection with the project scope:
 General Ledger
 Accounts Payable
 Accounts Receivable
 Fixed Assets
 Cash Management
 HRMS (Personnel)
 Payroll
 Self Service
 Integration with CBOSS

ERP Implementation
Task Key Deliverable Review Type Reviewers Sign-Off
Project Management
Create Project Management Plan, CR.010 Inspection and Alaa Elattar & Alaa Elattar &
detailed work schedule covering Sign-off PTC Project PTC Project
tasks, milestones and deliverables Manager Manager
Definition Phase
Delivery of Hardware and Test Servers Installed
installation of NT operating System Responsibility
Install Oracle Applications (Test Software installation Not Applicable Not Applicable Not Applicable
Servers) completed
Current Business Baseline – RD.020 Inspection and PTC Project Alaa Elattar &
Understand and document current Sign-off Manager & PTC Project
business practices relative to the Team Leader Manager & Key
Oracle Applications within scope Users
Design Chart of Accounts Segments RD030A Inspection and PTC Project Alaa Elattar &
and Values Sign-off Manager & PTC Project
Team Leader Manager & Key
Users
Technical Architecture and TA.020 Inspection and PTC IT Alaa Elattar &
production server sizing document Sign-off PTC Project
Manager
Business Requirement
Develop future processes based on BP.080 Inspection and PTC Project Alaa Elattar &
Oracle’s standard processes Sign-off Manager & PTC Project
Users
Operation Analysis
Conduct reporting fit analysis based BR.0 70 Inspection and PTC Project Alaa Elattar &
on to-be-processes Sign-off Manager & PTC Project
Users
Design and document security BR.110 Inspection and PTC Project Alaa Elattar &
profiles based on the approved to-be Sign-off Manager & PTC Project
processes Team Leader Manager & Key
Users
Solution Design & Build
Develop Set-up (Application BR.100 Draft Walkthrough PTC Project N/A
Configuration) Document for each and Sign-off Manager &
Module PTC Sysadmin
Business System Testing
Develop testing scenarios based on TE.040 Inspection and PTC Project Alaa Elattar &
to-be processes and current Sign-off Manager & PTC Project
transactions. Team Leader Manager & Key
Users
Transition Phase
Set up production environment BR 100 Final Walkthrough PTC Project N/A
and sign-off Manager &
PTC Sysadmin
Production Phase
Final Acceptance and go-live Final Acceptance Walkthrough PTC Project Alaa Elattar &
and sign-off Manager & PTC Project
Team Leader Manager
Note 1: The above tasks and deliverables will be per module/application

Note 2: Team Leaders are the key users per module/application other than normal system users.

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 the Project Management Plan preparation and updating.
Risk and Issue Management

The risks to project success were evaluated during the proposal development and
updated during project start-up, as summarized in Appendix B of this manual. 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. See Appendix B for samples of the relevant forms.
During the project, issues will occur which will be outside the boundaries of the
project team to be able to resolve. The procedure described should 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)
 Issues might include problems found with documentation, software or
during the testing process.
 The respective team member’s project manager will investigate the issue
and raise it to the other Project Manager. The Project Managers will discuss
the issue and if necessary, submit the issue to be entered into the Risk and
Issue Log together with any background and supporting information. If it is
estimated that the risk could have a significant impact on the project it will
undergo the procedure described below.
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.
 Project Managers’ recommendations will be documented in the Risk and
Issue Log.
 Recommendations will be reviewed at progress meetings and Change
Request Forms raised, if necessary. Change Request Forms should be
authorized by GIZASYSTEMS & PTC before the change can take place.
 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 originating Project Manager will sign-off the Risk and Issue Log after
agreement with the other Project Manager.
 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; see Appendix C for the
relevant forms:
 Any modification to or deviation from this Project Plan, 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 GIZASYSTEMS or PTC 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 PTC and GIZASYSTEMS Project
Managers by a resolved problem or issue, document, conversation, or other
form of communication.
 The Project Manager of the party responsible for the area of change
(originating Project Manager) 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.
 The originating Project Manager submits the CRF to GIZASYSTEMS
for entry into the change control log.
 The originating Project Manager manages the investigation for the
impact of the proposed change.
 The originating Project Manager evaluates the impact of not
performing the change.
 The originating Project Manager prepares a response to the
proposed change.
 The original CRF and supporting documentation is filed in the
project library. This MUST NOT BE removed except to copy.
 If a change is required, the originating Project Manager seeks
agreement with GIZASYSTEMS to make the change and the CRF is
signed-off accordingly by all Project Managers.
If the change is not agreed to:
 The originating Project Manager will discuss and document the objection
with the other Project Manager
 The proposed change will be re-negotiated if possible, or withdrawn if it is
agreed upon to be non-essential. In such a case, the reasons will be
documented in the CRF. Accordingly, the change request will be submitted
to the steering committee for review, and further action.
Monitor Changes
 Once the CRF is signed, then work may begin.
 The Project Managers will adapt respective project plans to incorporate
agreed changes.

 Progress on the change will be monitored by the Project Managers and

reported at progress meetings
 GIZASYSTEMS and PTC project managers must sign the CRF once the
change is 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 that should 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, which occur during the course of the project. Issues
raised by visiting specialist GIZASYSTEMS personnel will be, documented, in a Site
Visit Report and discussed at the progress review meeting with the steering
committee.
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. Please refer to Appendix C for sample of the forms.
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 send PRT to the project manager.
 The project manager will allocate a PRT number and will add it to the
Problem Report Log.
Investigate Problem
 The project manager or a delegate will assign the problem for investigation.
 The investigator will classify the level of change, if a change is required.
 GIZASYSTEMS and PTC project managers will review findings of
investigations.
 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 project manager or a delegate must sign off the PRT.
 Return the PRT to the project manager who will close the log entry.

Status Monitoring and Reporting

This procedure defines the way in which project status, is monitored and reported.
The project progress will be, reported by the project managers or designates to the
steering committee once every two weeks.
The procedures are as follows:
1. Project Progress Reports should be, prepared by project team members and
submitted to the respective project managers or designates on a weekly
basis.
2. Project managers or designates will summarize and distribute to the steering
committee as appropriate (include updated project Work Plan if
appropriate) 2-days prior to the steering committee meeting that is
scheduled for month.
3. Project Progress Reviews to the steering committee are, held every month,
and a report is, given as input by the project manager summarizing
progress, problems, and any proposed changes. An updated project Work
Plan prepared by the project manager will be a key input to the meeting.
Minutes of these meetings will be, recorded by GIZASYSTEMS and state
what actions are to be, taken, by whom and by when. The actions will be,
discussed for resolution during subsequent meetings.
4. 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.
Team Reviews
Team Progress Reviews will be held on a on an on-going basis to assess the progress
of each team member and to plan for going forward. They will also include a
discussion of any issues and problems. Tasks & deliverables are up-dated on a
weekly basis in preparation for the team review based on completion of tasks by
staff.

Work Management
The Work Management process is responsible for defining, monitoring, and
directing all work performed on the project.
The Work Plan for this project will be, maintained, in Microsoft Project, project
management tool. Initial work breakdown as summarized in the “Project Tasks,
Deliverables and Milestones “ section is, derived using Oracle’s implementation
methodology (AIM) tailored to meet PTC’s business requirements and the scope of
work for this project.
The project deliverables and milestones for this project are listed in the previous
section of this manual.
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
interested parties. This model reflects the recurring communications the project
leaders see as critical to make sure there is the right levels 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.
Meeting / Responsibility Suggested Purpose
Activity Frequency
Sponsor Meeting PTC / As Required  Resolve Critical
GIZASYSTEM issues
S  Make strategic
decisions
Steering PTC / Every month  Resolution of
Committee GIZASYSTEM business issues
Meeting S  Review overall
project deliverables
 Direction and Issue
Resolution
Core Project Team PTC / As required  Report on team
GIZASYSTEM status
S  Review progress,
upcoming
activities, and
outstanding issues
 Make operational
decisions
Internal Project Project On-going  Conduct individual
Teams Managers team status
monitoring
 Review progress
for update at the
Core Project Team
meeting

Meeting / Responsibility Suggested Purpose

Activity Frequency
Information Project Ongoing  File all internal
Sharing Managers / meeting minutes.
Team Members  Distributed project
related meeting
minutes and
memorandum
should be, filed in
the Project Library.
Meeting Preparation
 Distribute the agenda for each meeting, at least 24 hours in advance.
Choose as an initial topic a subject that is relatively easy, 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 distributes as planned.
 Invitees who cannot attend a meeting should inform the meeting
coordinator or chairperson and assign an attendee to speak to their specific
issues.
 Project meetings should address at a minimum the following:
 Accomplishments and upcoming activities
 Progress against plan
 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
participation 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.
 Review purpose, objectives and format of the meeting. Confirm agenda.
 Recognize facilitator (for meetings with more than 5 attendees) and meeting
scribe/recorder.
 Briefly, review progress from previous meeting’s close (if regular meeting).
Typical Meeting Closure
Use the following close:

 Summarize key issues with related levels of urgency.
 Ensure participants have a clear understanding of next steps.
 Review action items and follow up steps/contacts.
 Conduct a brief meeting process review: what went well and what needs
improvement for next meeting.
Work Plan Control

This procedure defines how the Work Plan will be, maintained throughout the
project management life cycle. The procedures also detail the entry of actual and
estimate, to complete and reporting work progress. The Work Plan Control
Procedure assumes the use of Microsoft Project.
The procedures are as follows:
1. Commence project with baseline project Work Plan;
2. Review tasks and resource allocations on a daily basis;
3. Update project plan on at least a weekly basis by entering percentage
completion for each started task;
4. Make back-up copy of plan after updating 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 Work Plan;
5. Attach to weekly status report, if necessary;
6. The latest status will be, reported to PTC and GIZASYSTEMS management
every month as part of Status Monitoring and Reporting (see the Control and
Reporting section).
An initial baseline for the Project Work Plan is included in Appendix A to this plan.
Financial Control
Each party will maintain their own Financial Plans. Any issue, which affects the
project finance in terms of the agreed contract price, will be handled under the
Change Control Process.

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 policies and procedures; these are practice
management issues and are therefore outside the scope of this Project Management
Plan.
Project Team

PTC - Project Roles and Responsibilities

PTC Project Sponsor
 Provide direction for the project;

 Ensure that the project produces the required solution to the required
standard of quality and within the specified constraints of time and cost;
 Ensure project objectives fit with the overall PTC program strategy;
 Maintain a thorough liaison throughout the project with PTC management
team;
 Ensure internal and external communications are efficient;
 Ensure a cost conscious approach to the project;
 Balance the demands of business, users and suppliers;
 Conflict management;
 Ensure adherence to quality assurance standards;
 Ensure the management of projects related risks;
 Secure resources and monitor project progress;
 Approve the project plans and the project deliverables;
 Chairs the project Steering Committee meetings;
 Manage and resolve contractual issues with the vendors;
 Ensure a proper strategy for technology transfer;
PTC Project Manager
 Provide direction for all IT related issues for the project;

 Ensure that the project produces the required solution to the required
technology infrastructure;
 Ensure that IT strategy is aligned with PTC business strategy;
 Ensure that the system (H/W and S/W) is set up and installed in a proper
manner;
 Review the project plan and all project deliverables;
 Assign tasks to team members, schedule resources and coordinate tasks;
 Ensure that the right staff are being involved at the appropriate stages of
the project;
 Build the groundwork for the implementation;
 Monitor the project team performance and ensure that all team members
are completing their assigned duties in accordance with the project plan;
 Monitor the project progress according to plan and raise any issues that
impact the project progress;
 Take effective action to recover the original plan, or to minimize the
variance;
 Arrange to gather all required information for the project progress and
ensure that any changes in the information is promptly and properly
circulated;
 Ensure that user needs and expectations are being met or managed;
 Ensure that all PTC 's project documents (hard-copy and electronic
formats) are filed and archived;
 Prepare a transfer of technology program, report on the progress against
that program and recommend any improvements;
 Prepare a newsletter on the progress of the project and ensure its proper
circulation in a timely manner.
Data Base Administrator (DBA)
 Ensure data shared by business areas is modeled by a common data

structure that satisfies the functional requirements of those areas;
 Perform a similar function for the system data model, and identifies
common areas of functionality;
 Responsible for producing the logical and physical database designs –
based on GIZASYSTEMS advise and assistance;
 Responsible for designing backup and recovery strategies;
 Review the module designs to ensure efficient access to the database;
 Understand the technical architecture and required functionality of the
system so that compromises in the design can be made;
 Install the applications and oracle databases required to run the
applications.
System Administrator
 Define privileges for the database objects;

 Maintain applications, such as users’ profiles and authorities;
 Defines and implements application backup and recovery procedures;
 Defines and implements full System backup and recovery procedure;
 Monitors the performance of data files maintenance operations, memory
and CPU resources;
 Tunes database parameters (such as: control log and PTC archive files
sizes, deadlocks, and memory buffers) to get optimized performance;
 Defines and implements shutdown and maintenance procedures for the
production server periodically (Oracle Database, Applications and NT
System);
 Plans to install and upgrade to new versions of applications;
 Plans to install and upgrade to new versions of NT Operating System;
Applications Specialist
The application product specialist’s responsibilities include:

 Provide knowledge and guidance regarding application functionality;
 Supports and provides interpretation for tools, templates and methods;
 Conducts interviews and working sessions;

 Identifies detailed business requirements and creates business
requirements scenarios;
 Advising, guiding, and supporting the project team on the use,
implementation, and maintenance of Oracle Applications;
 Ensuring that PTC derives the maximum benefits from the application
products;
 Completing tasks and deliverables assigned by the project manager or
Team Leader;
 Keeping the project manager informed of progress and issues in a timely
manner;
 Identifying feasible alternative solutions that minimize the need for custom
development;
 Transferring the appropriate business and technical skills to other project
team members.
PTC Key Users
 Complete tasks as assigned by the PTC /GIZASYSTEMS Project Managers

and report on the progress of these tasks to the Project Managers;
 Collect information required for their respective area of focus;
 Attend training and provide support during system setup;
 Provide input to process design;
 Provide input to the development of test scripts and perform acceptance
testing;
 Provide support in their respective area of focus to the company.
GIZASYSTEMS - Project Roles and Responsibilities
Project Manager
The project manager is responsible for:
 Developing project plans and Work Plan with input from other Project
Managers in the project;
 Ensuring the contents of the Project Plan are adhered to throughout the
course of the project;
 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;
 Developing, documenting and implementing PJM Configuration

Management plans and procedures;
 Establishing baselines and determining the content of project release;
 Ensuring that no unauthorized changes are made to a project baseline
 Assisting in the Change Management process;
 Enforcing Configuration Management procedures across all project
processes.
Project Management directives include:
 Assisting PTC 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
PTC staff.
 Representing PTC in meetings with vendors and other representatives
associated or involved with the implementation.
 Providing the principal point of contact between PTC and GIZASYSTEMS.
 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.
GIZASYSTEMS/GIZA Functional Team
 Manage tasks for a specific process, functional or application area;

 Manage and supporting the daily tasks for the assigned team;
 Monitor and reporting the progress of the assigned team;
 Provide knowledge and guidance regarding application functionality;
 Support and provides interpretation for tools, templates and methods
 Conduct interviews and working sessions;
 Identify detailed business requirements and creates business requirement
scenarios;
 Support the Project Manager on a daily basis whenever it is required;
 Keep the Project Manager informed of progress and issues in a timely
manner.
GIZASYSTEMS/Giza Technical Consultant
The Technical Consultant is responsible for:

 Analysis of business and technical requirements;

 Producing design specifications to meet business and technical

requirements;
 Producing working code that meets the design specifications;
 Diagnoses and corrects faults found by unit testing;
 Proposes solutions and technical assumptions and develops data profiles
in support of testing;
 Adhere to standards for use of technology to other team members;
 Participation in reviews of the use of technology.
In general, the assigned persons will be responsible for tasks requiring specific skill
sets. When PTC resources change, PTC’s 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
GIZASYSTEMS 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 PTC functional areas. The client
will provide all necessary resources to support these tasks.
Education and Skills

The staff involved with this project, (including PTC staff) is assumed to be suitable
and 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:
PTC Staffing Skills Needs

GIZASYSTEMS’s approach to the functional training allows project team members
to become effective users of the Oracle Applications in a rapid manner. The scope of
the training provided to PTC’s project team members includes the standard
application functionalities for Oracle General’s Ledger, Accounts Payable, Accounts
Receivable, Fixed Assets, Cash Management, Self Service, Payroll and HRMS.
Key-User Skill Requirements
GIZASYSTEMS is responsible for all end-user training and shall develop and train
the key users on the job due to the nature, timing and project approach and will
ensure that the Application training meets the requirements of the implementation.
A highly effective and suggested approach is to allow the key-users to participate in
the system Acceptance Testing activities performed during the implementation of
the Oracle Applications. Implementation participation will also instill a sense of
‘ownership’ over the new system.
Key-users participating in the system Acceptance Testing will require some form of
advance preparation to function effectively. Some aspects to consider are:
 Providing an overview of the Oracle Applications being implemented;
 Providing an introduction to navigating the Oracle Applications;

Physical Resources
The following physical resources comprise the project infrastructure components
and are required to be in place prior to the commencement of on-site project
activities:
 Project room equipped with work stations, desks, guest chairs, book cases,
locking cabinets
 Telephones
 Outbound analogue telephone lines
 Photocopier
 Fax machine
 White boards
 Markers
 Access to meeting room w/ table, chairs
 General office supplies
 E-mail facilities
 Data Show (for training and presentation)
 Screen
Project Environments
The project environment(s) are located at PTC and consist of:
 Test - used to test business solutions and serve as a post-production test
environment;
 Production - used only for production data.
Software Backup Procedures and System Administration

Back-ups and basic system administration (machine start-up, shutdown, and
recovery) of the working environment(s) software should be performed daily by
PTC staff.
PTC’s database administrator will back up the project environment(s) as follows:
 Take initial backup immediately after the Oracle Applications have been
successfully installed;
 A 2nd backup should be taken immediately after the Oracle Applications
have been setup for the business system testing environment;
 Daily backups should be taken during the business system testing activities
and upon completion;
 A final backup should be taken after the Production environment has been
setup prior to entering any data.
Database sizing and instance synchronization will be performed by GIZASYSTEMS
/ PTC staff for the Production Servers only.

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

 All project deliverables should be reviewed by an appropriate project team
resource other than the author(s);
 Review feedback should be provided on a timely basis (e.g. generally within
1 business day);
 All deliverables prepared by GIZASYSTEMS will be reviewed and signed-
off by the appropriate members of PTC’s project team staff when accepted;
 Copies of all project documentation will be maintained by PTC’s project
team staff;
 Key project deliverables must at a minimum, be reviewed by the project
managers.
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 Plan document. A record of all deliverable
reviews will be, kept as an audit trail for resolution action. Techniques and
responsibilities are as defined below:
A Technical Review focuses not just on looking for errors and incompleteness (as is
the purpose of any Review), but evaluates the technical aspects of a deliverable e.g.,
elegance of code, functionality, etc. A Technical Design Review is a special type of
Technical Review (see below). A Technical Review is usually, conducted as part of
a Walkthrough or an Inspection.
A Walkthrough (individual or group) is a review whereby the reviewer(s) step

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

Walkthrough. Formal roles are, assigned to reviewers. These roles are:
 Moderator (leads the review)
 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 GIZASYSTEMS technical view, GIZASYSTEMS 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
GIZASYSTEMS will conduct audits of Quality Management during the project at the
following points:
GIZASYSTEMS Coordinator Date or Milestone
Quality Manager GIZASYSTEMS Project CR.010, BP.080, TE.040

Manager
Test Strategy
PTC’s project team staff will be responsible for executing the business system tests
and documenting test results. GIZASYSTEMS will provide support and guidance in
using pre-defined test scripts and in the execution of testing.
Test Levels
The following levels of testing will be used for this project:
 Module Testing
 Cycle Testing
 Acceptance Testing
Test Execution
The following project roles are responsible for test execution:
 Each process team is responsible for developing their unit test scripts and
executing the unit test.
 GIZASYSTEMS will be responsible for performing the cycle test. The cycle
test will be performed with modified unit test business scripts.
The following methods will be used to document the results of test execution:
 Issues will be categorized and assigned for resolution.
 Team meetings will be scheduled at the end of each test phase to evaluate
testing results.
 Approval will be noted through the use of acceptance certificates per testing
script.
 User acceptance and certification will be demonstrated by successful
completion of all test scripts.

Test Procedure
Acceptance testing will be structured using the following guidelines:
1. PTC/GIZASYSTEMS will supply the business conditions to be tested.
2. Business conditions to be tested as expected results compared with actual
results, if applicable.
3. PTC testers will discuss the results of the business test with the Project
Managers and decide whether the functional requirements have been met.
The appropriate project team resources will compile an action plan to
rectify any deficiencies.
4. All corrections will be re-tested based on this acceptance process.
Measurement
The following project metrics will be collected during the project and used as part of
progress reporting:
1. Length of time for review of deliverables
2. Number of problems encountered during acceptance testing
3. Number of revisions a document is going through before sign-off
4. Length of time to resolve hardware and software support

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
All paper-based project deliverables will have a control reference assigned.

Primarily this assists to identify the type of deliverable and can be used by project
staff to reference the deliverable in future documentation. The control references
will have the following format:
[Module Area]/[Deliverable Short Name]/[Company Reference]/[Version
Number]
Where,
[Module Area] = two or three character code for the module relating to the
deliverable
Examples: GL, AP, GEN (for General i.e. Project Plan)
[Deliverable Short Name] = Three or Four-character code to describe the purpose of
the deliverable
Examples: ‘SETU’ for Application Setup documents
‘ABRQ for Additional Business
Requirements document
[Company Reference] = Three-character company code to identify which
company referenced by the deliverable
Example: PTC for PTC Company
[Version Number] = In the format ‘9.0’
Examples: 1.0, 1.1 and 1.2
Control Reference example:

GL/BR.100/PTC/1.2
This is Version 1.2 of the GL Application Setup document for PTC Company.
PTC’s project Team will be responsible for the filing of all deliverables (electronic
and paper format). An agreed directory structure will be setup for all
deliverables. This directory structure will be initially setup on the network in the
project room in PTC.
Programs
More detailed custom development standards will be documented in the Design

and Development Standards document later in the project.

Appendix A – Work Plan
Was sent before

Appendix B - Risks, Risk and Issue Form and Register
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 Plan.
Source of Risk Potential Risk Event Risk
Project Scope
and Business
Risks
Significant potential changes in the scope of Medium
the project
Selected applications are not adaptable to Low
meet business requirements with no
customization
Unacceptable degree of field support (Key Low
User Acceptance)
Project decisions are not made on timely basis Medium
Review of project deliverables and sign-off are Medium
not made on a timely basis
Project milestones are not achievable (project Medium
schedule)
Organizational
and
Management
Rapid deliverable approval structure not in Medium
place
PTC personnel required are not available due High
to other commitments/workload
PTC personnel that are required do not have High
sufficient skills to undertake the work
PTC technical personnel in-experienced with Medium
Oracle’s application and database
administration
Retention of project team members during the Medium
implementation
Availability of GIZASYSTEMS resources on Medium
short notice for non-scheduled work
Interfaces,
Integration
Requirements for Interface between the

existing Billing System and Oracle are not Medium
defined
Reconciliation of data entry of backlog of
existing data to be entered into Oracle GL, AR High
and AP applications
Source of Risk Potential Risk Event Risk
Technical
Hardware & operating system is not available Low
when required
No hardware hot backup environment Medium
available
Hardware,
Network, and
Software
Hardware server(s) not available for business Low
mapping purposes and going live
Non-availability of Network Low
Scope, Project Management Risks
Significant Potential Changes in the Scope of the Project
The project scope and deliverables are fairly defined in the proposal and contract.
Risk: Medium
Consequence: Possible recasting of project objectives, costs and /or milestones
Contingency: Move non-critical project components into subsequent phase (future
initiative).
Early Mitigation: Ensure that all principals agree on project scope at time of project
initiation.
Selected Applications Adaptable to Meet Business Requirements with No

Customization
The project assumes that the business requirements of the enterprise can be, met
with no customizations of the base packages.
Risk: Low
Consequence: Additional cost to the project, possible additional un-forecasted on-
going maintenance costs.
Contingency: Include additional requirements outside of the scope into subsequent
phase (future initiative).
Early Mitigation: Ensure that the functionality of the vanilla package is clearly
identified and understood.
Unacceptable Degree of Field Support (User Acceptance)
Critical to the success of PTC 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

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 Not Made on Timely Basis
From time to time, groups in sessions or individuals will require decisions from
other members of the user community and 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: Medium
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 are not made on a Timely Basis
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: Medium
Early Mitigation: Seek a clear project charter and mandate 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
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. Also, the nature and timing of the project based on the fact that
renders the project tasks, milestones and deliverables as highly sensitive to any
delays owed to unplanned additional work or delays in signoff’s.
Risk: Medium
Consequence: Missed milestones, possible delay in go-live/cut-over and additional
project costs incurred.

Early Mitigation: Frequent project monitoring and review. Accountability and

responsibility should be tightly monitored and controlled by PTC and
GIZASYSTEMS Executive Management Teams.
Contingency: None.
Organization and Management Risk
Rapid Deliverable Approval Structure not in Place
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: Medium
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.
Staffing Risks
PTC Personnel Required are not 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: High
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: PTC personnel should have the appropriate approvals and a clear
mandate to be available as required.
PTC 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: High

Consequence: Slippage in deliverables due from PTC personnel, or inadequate level

of participation in decision making.
Contingency: Initial coaching, following by escalation to the PTC Project Manager or
the Steering Committee for direction.
Early Mitigation: On project commencement, review with each individual the
expectations for their involvement. Seek agreement with the individual.
PTC Technical Personnel Inexperienced with NT System Administration and Oracle Database
Administration
Risk: Medium
Consequence: Potential project delays as result of loss of technical environment.
Contingency: Assistance from GIZASYSTEMS technical resources for recovery
Early Mitigation: Hands on training from GIZASYSTEMS Partners and off-site
training.
Retention of Project Team Members during the Implementation
From time to time, key project personnel may be re-assigned to other enterprise
initiatives or leave the company.
Risk: Medium
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: On-going initiative to augment user and technical procedures,
and prepare an in-house training program.
Availability of GIZASYSTEMS Resources on Short Notice for Non-Scheduled Work
From time to time, the project may require additional non-scheduled participation
from GIZASYSTEMS personnel. As GIZASYSTEMS is motivated to schedule its
personnel in advance, GIZASYSTEMS may not be in an optimum position to
respond as required.
Risk: Medium
Consequence: Possible delays in project tasks
Contingency: Utilize methods such as video conferencing, fax, telecommuting,
email, tele-conference or after hour meetings.
Early Mitigation: Schedule GIZASYSTEMS’s participation in advance, and set
expectations with respect to GIZASYSTEMS’s requirement for advanced scheduling.
Interfaces and Integration Risks
Requirements for Interface between existing CBOSS System to Oracle not Defined
Without proper requirements defined it is unknown if the CBOSS system can supply
the required data to the Oracle applications.
Risk: Medium
Consequence: Possible delays in project tasks

Contingency: Early identification of business requirements in the definition and
solution design phases, appropriate design and swift turnaround time for approvals
by PTC is a critical success factor.
Early Mitigation: The requirements need to be, defined early in the project life cycle
in order to determine the level of interface that is required.
Reconciliation of Data Entry of backlog of existing data to be entered into Oracle
This is a manual process and subject to Data entry errors, and can be difficult to
reconcile. Also mapping exercise can be very lengthy.
Risk: High
Consequence: Possible delays in project implementation and tasks
Contingency: None
Early Mitigation: Carefully plan and strategize the go-live strategy and reduce
backlog reconciliation efforts.
Technical Risks
Hardware and Operating System 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
No Hardware Hot Backup Environment Available
At present, there is no hot-backup hardware site established to support the project or

the resulting production environment.
Risk: Medium
Consequence: Loss of systems availability while alternating environments are located,
delay to project and possible additional costs.
Contingency: Early design by PTC of Disaster Recovery Plans
Early Mitigation: Develop disaster recovery processes to minimize downtime and offset
risk.

Hardware, Network, Software Risks
Hardware Server(s) not Available for Business Mapping Purposes
Risk: Low
Consequence: Delay operational analysis and production phases
Contingency: Utilize a third party server
Early Mitigation: None
Non-availability of Network
Risk: Low
Consequence: Direct impact to fulfill project tasks.
Contingency: None.
Early Mitigation: Ensure that network is completed and properly commissioned in
due course of the implementation.

CR.010 Project Management Plan Doc Ref: GEN/CR.010/PTC/1.0
RISK AND ISSUE FORM

Ref: ___/___/ RIF/ ___
Originator's Name: Priority: Critical/High/Medium/Low

Phase/Process: Date Raised:
Functional Area: Assigned to:
Type: Risk/Issue Target Resolution Date:
Status: Open/Assigned/Investigated/Resolved/Approved/Deferred/No Action (Circle one)
Description:
Possible action:
Estimated Impact:
Possible action:
Estimated Impact:
Possible action:
Estimated Impact:
Recommendation:
Accepted (GIZASYSTEMS): Accepted (PTC):Date:
Date:
Associated Problem Report: Problem Report Date:
Associated Change Request Form: Change Control Accepted on:
Form 71/V2 Page __ of ___
File Ref: 413663190.doc Appendix B - Risks, Risk and Issue Form and Register 43
RISK AND ISSUE LOG Ref: ___/___/ RIL/ ___

Expected
RIF Assigned Resolution Impact on other Risks/ Current
No. Description to Type Priority By (date) Issues Status Resolution
Status: O=Open A=Assigned I=Investigated R=Resolved A=Approved D=Deferred N=No Action

Type: R=Risk I=Issue Priority: C=Critical H=High M=Medium L=Low
File Ref: 413663190.doc Appendix B - Risks, Risk and Issue Form and Register 44
Appendix C – Change Request Form and Log
File Ref: 413663190.doc Appendix C – Change Request Form and Log 45

CHANGE REQUEST FORM

Ref: ___/___/ CRF/ ___
Originator's Name: Priority: Critical/High/Medium/Low (Circle one)

Functional Area: Date Raised:
Phase/Process: Assigned to:
PTC Request?: YES/NO (Circle one) Date Resolution Required:
Status: Open/Assigned/Investigated/Resolved/Approved/Deferred/No Action ( Circle one)
Change Details (description of proposed change, the reason for the proposed change, the impact of the
proposed change and the implications of not performing the proposed change):
Investigation:
Estimated Impact: Effort: Cost:
Schedule:
Possible Action (list changes):
Actual Impact: Effort: Cost:
Schedule:
Accepted (GIZASYSTEMS): Accepted (PTC ):
Date: Date:
Completion Verified By: Completion Date:
Associated Problem Report: Associated Risk and Issue Form:
Form 18/V2 Page __ of ___

CHANGE REQUEST LOG Ref: ___/___/ CRL/ ___

CRF No. Description Originator Date Raised Current Status Date Approved Date Closed
Status: O=Open A=Assigned I=Investigated R=Resolved A=Approved D=Deferred N=No Action

Appendix D – Oracle Application Implementation Methodology

Introduction
AIM Methodology
The Applications Implementation Methodology (AIM), is a tried and tested, comprehensive tool
kit, developed by Oracle that provides a framework in which to deliver application
implementation projects. With predefined process work flows and software templates for rapidly
creating project deliverables. AIM is a structured approach that, is tailored to the organizations,
unique requirements. AIM encompasses all essential project steps to minimize risk and assist a
fast, high-quality implementation. In addition, by using AIM, future changes in the corporate
structure can be, incorporated more readily into the business systems. AIM is a clear and concise
method of implementing business applications that can be, adopted by any organization. AIM will
give considerable benefit during the project and most importantly will provide for longer-term
ownership of the systems.
File Ref: 413663190.doc Appendix E – Problem Report Form and Log 48

Overview of System Components Implementation Methodology
This section describes the methods that GIZASYSTEMS/GIZA will use to ensure a successful
implementation.
Definition Operations Solution Build Transition Production

Analysis Design
Business Requirements Definition (RD)

Business Requirements Mapping (BR)
Application & Technical Architecture (TA)
Module Design & Build (MD)
Data Conversion (CV)
Business Testing (BT)
Training (TR)
Production Migration (PM)
1. Definition Phase
During the definition phase, the project team confirms the Project Management Plan that defines the
scope of the implementation. The team also interviews members of the organization to gain an
understanding of the current business processes and reviews financial, operational, technical, and
administrative processes. The information gathered in these interviews provides input to downstream
activities in subsequent phases. One of the goals of the definition phase is to identify the application
and information technology architecture requirements and strategy. In addition, the testing
requirements and strategy are determined during this phase. Finally, the project team learning plan is
developed and the project team learning events commence.
2. Operations Analysis
During operations analysis, the project team modifies the proposed future process model and
performs activities to further develop the business requirements for the organization. The Business
Requirements document are prepared and defined based on deliverables from the definition phase.
These Business Requirement documents are, used to map the detailed business requirements and the
standard application functionality. A reporting fit analysis is conducted using the standard report
tracking list. This list includes the standard reports for the applications. Any custom reports are,
considered outside the scope of this type of implementation approach. Finally, a transition approach
is, developed for migrating the organization from the current system to the new production system.

3. Solution Design
The purpose of the solution design phase is to define the Oracle Application setups for the
optimal solutions to meet the future business requirements. During this phase, project team
members complete the application setup templates, design security profiles and create detailed
system test scripts that confirm the business solutions developed during the operations analysis.
The project team performs the conversion mapping of business objects to prepare for the manual
data conversion that will be executed.
4. Build
In this phase, the testing is, performed in an environment that is, configured to closely resemble
production. During the business system test, the key users are prepared for the production
cutover and are involved in the execution of the system test scripts.
5. Transition
During the Transition phase, the project team performs the acceptance test and deploys the
finished solution into the organization. All the elements of the implementation must come
together to transition successfully to actual production. The project team is responsible for
performing the final acceptance test, training the users, configuring the production environment,
and manually converting the necessary production data. Transition ends with the cutover to
production, when users start performing their job duties using the new system.
6. Production
Production begins immediately with the production cutover. It marks the last phase of the
implementation and the beginning of the system support cycle.

Appendix E – Problem Report Form and Log

PROBLEM REPORT
Ref: ___/___/ PRT/ ___
Originator's Name: Investigator's Name:
Date:
Problem Details (including items affected, if applicable):
Investigation:
Suggested / Actual Action:
Estimate of Required Work:

Authorization to Proceed (GIZASYSTEMS): Authorization to Proceed (PTC ):
Date: Date:
Person who Tested the Change: Date change Tested:
Problem Closed by: Associated Change Request Form:
On: Raised On:

Associated Risk/Issue Form:
Form 17/2 Page __ of ___

PROBLEM REPORT LOG Ref: ___/___/ PRL/ ___
PRT No. Description Originator Date Raised Priority Status Date Closed
Priority: I=Immediate U=Urgent R=Routine Status: O=Open A=Assigned I=Investigated R=Resolved C=Closed N=No Action

CR.010 Project Management Plan
Appendix F – Meeting Minutes & Progress Report
File Ref: 413663190.doc Appendix F – Meeting Minutes & Progress Report 54

MEETING MINUTES
Ref: ___/___/ MM/ ___
DATE: 28 March 2019
FROM: <From Name>
PROJECT: <Project Name>
SUBJECT: <Subject of Meeting>
ATTENDEES: <Attendees>
DATE/LOCATION: <Meeting Date> at <Meeting Location>
Item Minute Action

PROJECT PROGRESS REPORT

Ref: ___/___/ PPR/ ___
Client: PTC
Project: ERP Implementation Project
Project <insert project description>
Description:
Project Manager: Project Manager Date
Country: Region
1 Progress/In Progress
2A Work Progress
2B Deliverables and Milestones
Contract ID Description Baseline Plan Forecast or PTC

or CRF Date Actual Date Approval
(Y/N)
3 Problems and Issues
Outstanding
From Last Period Closed this Period New this Period Outstanding
Quantity of Problems
Summary of Outstanding Problems/Issues:
4 Change Requests for This Period - Current

1.
Any new changes requested by PTC? Y, N
2. Any new changes requested by GIZASYSTEMS? Y, N
3. Any new quotations made? Y, N
4. Any new quotations required? Y, N
5. Any quotations awaiting PTC Decision? Y, N

5 List of Change Requests
CRF Date Description Days/Fees Fixed Price Work in GIZASYSTE PA

or T&M Progress MS/ PTC Reference
Approvals
Y, N Y/N
Y, N Y/N
Y, N Y/N
6 Major Activities for Next Period
7. Audit, Review and Healthcheck Schedule
Type Date Scheduled Performed by Date Performed

Healthcheck (Initial)
8 Next Project Sponsor Meeting/Progress Meeting
Date: Venue:

Doc Ref: Doc Ref:
Appendix G – Acceptance Certificate
File Ref: 413663190.doc Appendix H – Project Team Contact Information 58

Doc Ref: Doc Ref:
ACCEPTANCE CERTIFICATE Ref: ___/___/ ACC/ ___
Client: PTC
Project: <Project Name>
Initiated by: Date:
Deliverable Reference: Type:  Proposal

 Plan
 Specification
 Form
 Manual
 Other ________________________
Deliverable Description:
The above deliverable has been reviewed by PTC and fully meets the objectives expressed by PTC and
GIZASYSTEMS and passes the acceptance criteria specified by PTC.
Acceptance will be complete when the Problem Reports attached have been cleared.
Problems during testing have shown that acceptance is not complete. I undertake to inform <Consultant> of
these problems in writing within two working days, or else I understand that acceptance will be deemed
complete.
Signed for PTC Date
____________________________________________ ___________________
____________________________________________ ___________________
Signed for GIZASYSTEMS Date
____________________________________________ ___________________

Doc Ref: Doc Ref:
Appendix H – Project Team Contact Information
PTC Project Team Contacts List
Name Work Mobile Email
GIZASYSTEMS Project Team Contacts List
Name Work Mobile Email
Alaa Elattar +2027608801 +20101140547 Alaa.elattar@gizasystems.com

Doc Ref: Doc Ref:

Vra Bp90 Oraclehrms III v2.1

Uploaded by

Copyright:

Available Formats

Vra Bp90 Oraclehrms III v2.1

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Vra Bp90 Oraclehrms III v2.1

Uploaded by

Copyright:

Available Formats

Doc Ref: GEN/CR.010/PTC/1.

CR.010 PROJECT MANAGEMENT

ERP Implementation Project

Author: Alaa Elattar

File Ref: 413663190.doc Scope 1

Date Author Version Change Reference

June 20,2005 Alaa Elattar 1.0 Initial Document

PTC Project Sponsor

Copy No. Name Location

File Ref: 413663190.doc Scope 2

File Ref: 413663190.doc Scope 4

Scope and Application

File Ref: 413663190.doc Scope 6

Applications The following applications are included in the

Implementation Site Implementation will occur at PTC’s

Process Re-engineering Not Applicable

Customization Customizations are usually required in two

The project scope does not include any of

File Ref: 413663190.doc Scope 7

GIZASYSTEMS’s scope to provide additional

Interfaces SQL files from PTC’s billing system will be,

PTC Architecture Technical Architecture for the ERP

Testing and Acceptance Full business system testing will be,

Training Training will be, conducted on the job for the

It should be noted that PTC’s technical team

Relationship to Other Systems/Projects

File Ref: 413663190.doc Scope 9

It is the responsibility of PTC to inform GIZASYSTEMS on the above projects or

File Ref: 413663190.doc Scope 10

Critical Success Factors

File Ref: 413663190.doc Scope 11

File Ref: 413663190.doc Scope 12

Project Work plan

File Ref: 413663190.doc Scope 13

File Ref: 413663190.doc Scope 14

Project Tasks, Deliverables, and Milestones

File Ref: 413663190.doc Scope 15

Task Key Deliverable Review Type Reviewers Sign-Off

Note 1: The above tasks and deliverables will be per module/application

File Ref: 413663190.doc Scope 16

Control and Reporting

Risk and Issue Management

Record Risk and Issue Details

Resolve Issue or Develop Risk Containment

File Ref: 413663190.doc Scope 18

 Progress on the change will be monitored by the Project Managers and

Record Problem Details

File Ref: 413663190.doc Scope 19

Status Monitoring and Reporting

File Ref: 413663190.doc Scope 20

File Ref: 413663190.doc Scope 21

Meeting / Responsibility Suggested Purpose

File Ref: 413663190.doc Scope 22

Typical Meeting Opening

Use the following opening:

Typical Meeting Closure

Use the following close:

Work Plan Control

File Ref: 413663190.doc Scope 23