Global Delivery Center SOW.V1.5 - PDSB Review - 250823 Down

FPT Global Delivery Center Malaysia – Annexure for Partnership Agreement
Open
Page |1
Table of Contents
1. Overview.............................................................................................................................................5
2. Scope of Work.....................................................................................................................................6
2.1 Delivery Center Infrastructure & Processes..............................................................................12
2.1.1 In scope....................................................................................................................................12
2.1.1.1 Physical Infrastructure..............................................................................................................12
2.1.1.2 IT Infrastructure.......................................................................................................................13
2.1.1.3 Network Connectivity...............................................................................................................14
2.1.1.4 FPT (Redundancy) Environment for potential use by PETRONAS.............................................15
2.1.1.5 DC Certifications.......................................................................................................................19
Note: CMMI Level 5 require at least 1 year real world data for certification purposes.........................19
2.1.1.6 DC Capabilities..........................................................................................................................20
2.1.2 Plan & Timelines.......................................................................................................................26
2.1.3 Business Continuity Plan (BCP) and Disaster Recovery (DR).....................................................27
2.1.3.1 Emergency Response Team (ERT)............................................................................................28
2.1.3.2 Business Continuity Impact Analysis........................................................................................28
2.1.3.3 P0 – Communication Plan........................................................................................................29
2.1.3.4 P1 – People Treatment Plan.....................................................................................................29
2.1.3.5 P2 – Backup Working Places Plan.............................................................................................30
2.1.3.6 P3 – Networks / Infrastructure Plan.........................................................................................31
2.1.3.7 Emergency Response Procedures............................................................................................31
2.1.3.8 Maintenance and Awareness...................................................................................................32
2.1.4 Out of scope.............................................................................................................................33
2.1.5 Support team and Governance – Roles & Responsibilities.......................................................34
2.1.6 Critical Success Factors for Operationalization of GDC.............................................................45
2.1.7 PDSB Obligation........................................................................................................................45
2.1.8 Deliverables..............................................................................................................................46
2.1.9 KPIs/Measurements.................................................................................................................47
2.2 Skill and Talent Development...................................................................................................48
2.2.1.1 Fulfillment................................................................................................................................48
2.2.1.2 Competency Management and Development.........................................................................49
2.2.1.2.1 Onboarding (Resource Pool Arrival), Offboarding (Resource Pool Departure) flows.......51
2.2.1.2.2 Onboarding (Project Arrival), Offboarding (Project Departure) flows..............................52
2.2.1.2.3 Resource Rotation flow....................................................................................................53
2.2.1.2.4 Resource Development....................................................................................................54
2.2.1.2.5 Fresher Academy Program..............................................................................................55
2.2.1.2.6 Career Development Program.........................................................................................56
2.2.1.2.7 Training Approaches........................................................................................................56
2.2.1.2.8 Skill Training.....................................................................................................................56
2.2.1.2.9 On the Job Training (OJT).................................................................................................57
2.2.1.2.10 English Qualification........................................................................................................57
2.2.2 Out of scope.............................................................................................................................58
2.2.3 Roles & Responsibilities............................................................................................................58
2.2.4 PDSB Obligations......................................................................................................................58
2.2.5 Deliverables..............................................................................................................................58
Open
Page |2
2.3 PRODUCT and PROJECT Delivery framework............................................................................59
2.3.1 DELIVERY FRAMEWORK............................................................................................................59
2.3.2 GDC Engagement Process Commitment Conditions................................................................60
2.3.3 Project and Resource Demand Planning..................................................................................61
2.3.4 Agile Delivery Framework for Product/Application Development...........................................63
2.3.5 Frequent Communication.........................................................................................................65
2.3.6 In Scope:...................................................................................................................................66
2.3.7 Out of scope.............................................................................................................................66
2.3.8 Roles and responsibilities.........................................................................................................66
2.3.9 PDSB Obligation:......................................................................................................................66
2.3.10 Deliverables:.............................................................................................................................66
2.3.11 KPIs/Measurements -...............................................................................................................66
2.4 Application Support & Maintenance Framework.....................................................................67
2.4.1 In Scope....................................................................................................................................68
2.4.1.1 Production Support Services....................................................................................................69
a. Monitoring...............................................................................................................................69
b. Availability Management..........................................................................................................69
c. Incident Management by Application Management Service....................................................71
d. Minor Enhancements...............................................................................................................71
e. Release Management...............................................................................................................71
2.4.1.2 Service Automation..................................................................................................................72
1. Service Level Metrics and Performance...................................................................................73
1.1. Service Level Methodology and Measurement........................................................................73
1.2. Service Level Metrics Definition...............................................................................................73
2. Service Levels Continuous Improvement.................................................................................74
2.4.2 Out of scope.............................................................................................................................74
2.4.4 PDSB Obligations......................................................................................................................75
2.4.5 Deliverables..............................................................................................................................75
2.4.6.1 SLA Management:......................................................................................................................76
2.4.6.2 Knowledge Retention & improvement:.....................................................................................76
2.4.6.3 Improve Productivity:................................................................................................................77
2.4.6.4 Apply automation process:........................................................................................................77
2.4.6.5 Knowledge Retention & improvement:.....................................................................................77
2.5 Transition Framework..............................................................................................................77
2.5.1 Transition Considerations:........................................................................................................77
2.5.2 General Approach....................................................................................................................78
2.5.3 In-Flight Projects & Product.....................................................................................................80
2.5.4 Roles and Responsibilities .......................................................................................................82
2.6 Tools & Best Practices..............................................................................................................83
2.6.1 Best Practices* in Delivery Processes.......................................................................................83
2.6.2 FPT Tools and Delivery Systems...............................................................................................83
2.6.2.1 Agile Delivery Management.....................................................................................................84
2.6.2.2 Contract Resource Management..............................................................................................91
2.6.2.3 Contract Resource Management..............................................................................................93
2.6.3 PDSB Tools and Delivery Systems.............................................................................................95
Open
Page |3
2.6.3.1 Project Management................................................................................................................95
2.6.3.2 Product/Application Development...........................................................................................95
2.6.3.3 Application Support & Maintenance........................................................................................95
2.6.5 In Scope....................................................................................................................................95
2.6.6 Out of Scope.............................................................................................................................96
2.6.7 PDSB obligations.......................................................................................................................96
2.6.8 Deliverables..............................................................................................................................96
NA 96
3. Governance Framework....................................................................................................................97
5. Contract Change Management – Change Request..........................................................................100
6. GDC Contract Transition First 6 Months High Level Plan.................................................................101
Annexure A: Project Specific WORK ORDER/CHANGE ORDER Template.................................................103
Annexure B: KPI.......................................................................................................................................105
DC Level...................................................................................................................................................105
Project KPI...............................................................................................................................................109
Product KPI..............................................................................................................................................113
Annexure C: <Intentionally left blank>....................................................................................................115
Appendix A: Sample of Course Catalog....................................................................................................116
Appendix B: Sample of A Syllabus............................................................................................................118
Open
Page |4
1. Overview
FPT Malaysia will set up a Delivery Center (“DC”) in Malaysia for PETRONAS to achieve the following:
1. Setup Global Delivery Center (GDC) in Malaysia to provide end-to-end solution delivery services to
PETRONAS; and the region.
2. Develop digital capabilities for local talents.
3. Co-invest in Malaysia Digital Education, Tech & Social Entrepreneurship.
4. To leverage and co-invest in best-in-class tools, processes & methodologies.
5. To partner with and co-sell PETRONAS & FPT Products & Services
FPT will have 2 delivery centers in Malaysia, main office in Kuala Lumpur, another in Kuching for serving Borneo.
Figure 1: FPT's GDC in Malaysia
This SOW also incorporates the following related documents:

a) Annexure A. Project Specific Work Order & Change Order format
b) Annexure B. Metrices
Open
Page |5
2. Scope of Work
FPT will set up the Delivery Center and provide Product/Project development and Support services to PDSB.
The services provided will be predominantly for Software and Data Engineering streams in a Fixed Capacity
model for Product Development & Support (Product Squad) and Fixed Price model for Projects (Project) &
Application Support (Application Management Service AMS) as listed in section 4. The details will be listed in
the respective Product development or Support services Work Orders. Project-specific Work Orders will be as
per Annexure A.
The Product/Project development and Support Services provided by FPT will be classified as below:
 New Product Development and Support : FPT will develop, implement and support software
products on Agile model for PDSB based on PETRONAS business requirement as agreed in individual
Work Orders.
 New Project Development: FPT will develop and implement software applications for PDSB based on
PETRONAS business requirement as agreed in individual Work Orders.
 Application Support and Maintenance: FPT will ensure availability of PETRONAS application through,
but not limited to, incident and Service Request management, corrective and preventive actions, to
functionality enhancement, and performance improvement as agreed in individual Work Orders
 Inflight Products Development & Support : PDSB will transition current PETRONAS software
products that are already being developed by PDSB or others to FPT based on detailed Due Diligence
and Transition as agreed in individual Work Orders
 Inflight Projects : PDSB will transition current PETRONAS software applications that are already being
developed by PDSB or other vendors to FPT based on detailed Due Diligence and Transition as agreed
in individual Work Orders
To enable the above, FPT GDC will work like an extended team of SWE and DE chapters in PDSB, where it will
focus on areas below for PETRONAS benefit.
i. End-to-end Delivery which includes but is not limited to:
• Software Engineering & Testing
• Data Engineering
• Projects and Products Run & Maintain
• Project and Product Management & Business Analysis
• Agile Coaching & Change Management
• Artificial Intelligence & Machine Learning
• User Experience.
ii. Training & Skill Development
iii. Continuous Improvement
• Technologies
• Tools & Processes
• Methodologies & Best Practices
iv. Research & Innovation
Open
Page |6
Figure 2: GDC Scope Of Work
Open
Page |7
Definitions
In this SOW and each project-specific Work Order entered into hereunder, unless the context otherwise requires,
all capitalized terms and expressions shall have the following definitions:
No Abbreviation/Terminology Explanation
1 ADO Azure DevOps
A term that describes approaches to software development that
2 Agile emphasize incremental delivery, team collaboration, continual planning,
and continual learning.
Artificial Intelligence - It is the science and engineering of making
intelligent machines, especially intelligent computer programs. It is
3 AI
related to the similar task of using computers to understand human
intelligence
4 AMS Application Management Service
5 BAU Business As Usual
6 BCP Business Continuity Plan
The amount of work that can be completed within a given time frame
7 Capacity and is based on the number of hours a person or team has available to
complete that work
Closed-circuit television (CCTV), also known as video surveillance,[1][2] is
8 CCTV systems the use of video cameras to transmit a signal to a specific place, on a
limited set of monitors
9 Chapters A group or team members working within a similar group of capabilities
10 CMMI Capability Maturity Model Integration
FPT shall appoint the Core Team (Solution Architect, Project Manager
and/or Business Analyst, senior developer) to conduct solution activities,
11 Core Team (GDC) as well as PDSB engagement.
The Core Team is part of DC operational effort working with PDSB, and
the effort shall not be billed to PDSB.
FPT shall appoint Core Team to begin its delivery work for the assigned
12 Core Team (Project) project. The members are mainly customer facing and technical leading
roles but may differ by project.
12 CSI Customer Satisfaction Index
13 CSR Corporate Social Responsibility
14 CSS Customer Satisfaction Survey
the team responsible for designing, developing, testing, deploying and

15 Development Team otherwise performing development work required to create and deploy
releasable User Stories
A set of practices that combines software development (Dev) and IT
16 DevOps operations (Ops). It aims to shorten the system development life cycle
and provide continuous delivery with high software quality.
Open
Page |8
Delivery Excellence model - PETRONAS DEX model describes the
17 DEX Process processes and deliverables from lead to project closure, in order to better
manage the timeliness and quality of projects delivered.
18 Domain A set of websites on the internet that end with the same letters
19 DR Disaster Recovery
Endpoint Detection and Response - An endpoint security solution that
20 EDR continuously monitors end-user devices to detect and respond to cyber
threats like ransomware and malware.
End of Life - A product is at the end of its useful life (from the vendor's
21 EOL point of view), and a vendor stops marketing, selling, or sustaining it. The
vendor may simply intend to limit or stop support for the product.
End of Sale - The last day to order the product through the vendor’s
22 EOS point-of-sale mechanisms. After this date, the product is no longer for
sale.
23 ERT Emergency Response Team
24 FPT HQ FPT Headquarter
Full-time equivalent - a unit of measurement that indicates the workload
25 FTE of an employed person in a way that makes workloads comparable across
various contexts
Global Delivery Center / Delivery Center, a Delivery Centre set up to
26 GDC / DC
provide product and project development and support services.
27 HR Human Resource
28 IDE Integrated Development Environment
29 ISO 27001 An international standard to manage information security

Information Technology Infrastructure Library a set of detailed practices
for IT activities such as IT service management (ITSM) and IT asset
30 ITIL
management (ITAM) that focus on aligning IT services with the needs of
the business
31 KPI Key Performance Indicator
32 OJT On-the Job Training
33 PDCA Plan-Do-Check-Act
34 PDSB PETRONAS Digital Sdn Bhd
Project Management Office - A group or department that defines,
35 PMO maintains and ensures project management standards across an
organization
It's a project where some FPT staff deployed into in order to grow. For
36 Pracical Project example: universities collaboration, Hackathons, FPT internal projects,
international projects, etc.
37 QBR Quarterly Business Review
The function in charge of process development, process & product
38 Quality Assurance
compliance verification at FPT Software
39 RCA Root Cause Analysis
40 RPA Robotic Process Automation is a software technology that makes it easy
to build, deploy, and manage software robots that emulate humans
Open
Page |9
actions interacting with digital systems and software
41 SAFe The Scaled Agile Framework
42 SAS Team Statistical Software Suite
Product Owner, Scrum Master, Development Team: consists of
professionals who work together to deliver the product increment. They
43 SCRUM Team are responsible for designing, developing, testing, and delivering the
product according to the requirements and priorities defined by the
Product Owner.
44 SLA Service Level Agreement
45 SME Subject Matter Expert of FPT Software
46 SOE FPT Standard Operating Environment (defined in 2.1.1.2 IT Infrastructure)
47 SOW Scope of Work
48 SPOC Single Point of Contact
49 SR Service Request
Site reliability engineering (SRE) is a software engineering approach to IT
50 SRE operations. SRE teams use software as a tool to manage systems, solve
problems, and automate operations tasks
51 SRS Software Requirements Specification
52 SVP Senior vice presidents
53 SWE Software Engineering
A software contract type which provides for acquiring supplies or services
on the base on direct labor hours at specified fixed hourly rates that
54 T&M projects include wages, overhead, general and administrative expense, and profit
in such type of a contract, qualification of resource is to be verified and
validated by customer
55 TMMi Test Maturity Model Integration
56 TSL Technical Solution Lead

57 UAT User Acceptance Test
The UIUX is User Interface & User Experience Design. It is the process of
58 UIUX designing the look and feel of a computer system’s user interface to best
meet user needs.
59 VDI Virtual Desktop Infrastructure
60 VP Vice presidents
Virtual Private Network - Describes the opportunity to establish a
61 VPN
protected network connection when using public networks
62 Web proxy One method for hiding IP address from the websites visiting.
Contracting document between FPT & PDSB which describes the work to
63 Work Order
be performed within a stipulated time.
METRICS DEFINITIONS
Metrics organizations use to track, measure, and analyze the financial
1 Financial KPI
health of the company.
The process of acquiring, capturing, and retaining information and
knowledge within an organization over time, so that it can be preserved,
2 Knowledge Retention
used, and transferred in the future between different members of the
organization.
Lower specification limits represent the lowest limit that a measurement
or reading can reach and still be acceptable to the customer. It’s
3 LSL
important to compare with the lower control limit to determine if the
system is capable of meeting customer expectations over time
4 NPS Net Promoter Score - a customer loyalty and satisfaction measurement
Open
P a g e | 10
taken from asking customers how likely they are to recommend your
product or service to others on a scale of 0-10.
Promoters (score of 9 and 10) represent a company’s most enthusiastic
and loyal customers: these people are likely to act as brand ambassadors,
enhance a brand’s reputation, and increase referral flows, helping fuel the
company's growth.
Detractors (score of 0 to 6, included) are unlikely to recommend a
company or product to others, probably won’t stick around or repeat
purchases, and—worse—could actively discourage potential customers
away from a business.
Passives (score of 7 or 8) are not actively recommending a brand, but are
also unlikely to damage it with negative word of mouth. Although they
are not included in the NPS calculation, passives are very close to being
promoters (particularly when they give a score of 8), so it always makes
strategic sense to spend time investigating what to do to win them over.
Proof of Concept - A timely way to test project-defining ideas, decisions,
strategies, and methods. The main goal of PoC software is to shed the
7 PoC
light on the final product’s feasibility, i.e., decide whether it should be
fully implemented or not.
The grouping together of resources (assets, equipment, personnel, effort,
8 Resource Pool etc.) for the purposes of maximizing advantage or minimizing risk to the
users
9 SVIP (Severity) Come from high level: Head of Department.
A time in which IT systems are operational, system uptime also includes
10 System Up-time the accessibility of the system. When systems are up and accessible,
business can run smoothly.
Upper Specification Limit represents the highest limit a measurement or
11 USL reading can reach and still be acceptable to the customer. We need
specification limit, it helps to understand control limits.
Open
P a g e | 11
2.1 Delivery Center Infrastructure & Processes
FPT will carry out product and project development activities from its Delivery Center in Malaysia. The Delivery
Center will receive support from FPT HQ, where the majority of the existing capabilities are located.
FPT - PETRONAS Global Delivery Center aims to deliver a superior employee experience that ensures productivity
right from day one. The center will be equipped with state-of-the-art technology and infrastructure, enabling
global connectivity for improved access and collaboration. It will play a crucial role in executing mission-critical
projects and product development for PDSB and its group of subsidiaries. FPT policies and processes will guide the
operations of the FPT Delivery Center.
2.1.1 In scope
DC shall provide following infrastructure and facilities:
2.1.1.1 Physical Infrastructure

• Adequate standard office space to accommodate the workforce:
• Sufficient space for workstations, meeting rooms, and common areas.
• Comfortable and ergonomic furniture for employees.
• Proper ventilation and lighting.
• Reliable power supply and backup systems to ensure uninterrupted operations:
• Robust electrical infrastructure with backup generators or UPS (Uninterruptible Power
Supply) systems.
• Redundant power sources to minimize the risk of power outages.
• Efficient cabling and network infrastructure for seamless connectivity:
• Structured cabling system for data and voice communication.
• High-speed internet connectivity with appropriate bandwidth.
• Network switches, routers, and firewalls for secure and reliable network connectivity.
• Wireless access points (Wi-Fi) for convenient connectivity.
• 24 x 7 Physical Security Setup:
• Access control systems, such as key cards or biometric scanners, restrict unauthorized
entry.
• Security guards to monitor and control access to the facility.
• Intrusion detection and prevention systems to safeguard against unauthorized access.
• 24 x 7 CCTV Surveillance:
• Strategically placed surveillance cameras to monitor the office premises.
• Digital video recorders (DVRs) or network video recorders (NVRs) to store and review
recorded footage.
• Regular maintenance and monitoring of CCTV systems.
• Fire Alarm and Protection System:
• Smoke detectors, fire alarms, and fire suppression systems (e.g., sprinklers).
• Emergency exit routes and clear signage for evacuation.
• Regular inspections and maintenance of fire safety equipment.
• Employee-friendly facilities:
• Restrooms, pantry areas, and recreational spaces for employees' comfort.
• Breakout areas for relaxation and social interaction.
• Adequate storage facilities for personal belongings.
• Facilities for nursing mothers, if applicable.
• Cleanliness and maintenance of common areas.
• Training Facility for learning and upskilling:
• Dedicated training rooms equipped with audio-visual equipment.
• Training materials, whiteboards, and projectors for effective learning.
Open
P a g e | 12
• Access to online learning platforms and resources.
• Collaboration tools for remote or virtual training sessions, if necessary.
• An accessible workplace with transport connectivity:
• Proximity to public transportation hubs or major roads.
• Sufficient parking spaces for employees and visitors.
• Accessibility features for employees with disabilities (ramps, elevators, etc.).
• Transportation and Commuting:
• Encourage public transit, carpooling, and cycling.
• Offer remote work
• Energy Efficiency:
• Use energy-efficient lighting systems and natural light.
• Utilize energy-efficient appliances and encourage power-saving practices.
• Water Conservation:
• Install low-flow faucets, toilets, and urinals.
• Educate employees on water-saving habits.
• Waste Management:
• Set up recycling stations and promote paperless practices.
• Sustainable Materials and Furniture:
• Choose eco-friendly materials and sustainable furniture.
• Opt for certified products meeting sustainability standards.
2.1.1.2 IT Infrastructure
All Dev to Prod Environment belong to PETRONAS. Project data will be stored on PETRONAS environment and no
integration to FPT. FPT only offers secure laptop or VDI for the client device, along with a secure network
connection, to establish connectivity with the Petronas network and their software development & testing
environment (refer to Figure 3: GDC IT Infrastructure).
Facilities Provided to GDC Staff by PETRONAS:

• PETRONAS provides GDC staff access to PETRONAS accounts, email, and VPN for secure
connectivity to the PETRONAS environment.
• GDC staff have reasonable access to PETRONAS on-premises and cloud environments, as
well as PETRONAS Azure DevOps, for project engineering activities such as
development, deployment, testing, and PETRONAS-related training.
• GDC staff also have access to other PETRONAS-managed software necessary for
PETRONAS products, data and software engineering purposes, which can be installed on
FPT-managed laptops.
FPT Standard Operating Environment (SOE):

• Staff Device: FPT laptops are provisioned with Windows 10 or a newer version and
connected to the FPT Enterprise Domain, allowing GDC staff to utilize FPT-managed
laptops and PETRONAS-managed accounts to access the PETRONAS environment for
project work.
• Software: These laptops are also equipped with productivity and collaboration tools
such as Office 365 or similar software suites, facilitating efficient communication and
enhancing organizational productivity. Additionally, VPN or VDI software is installed on
FPT laptops to enable seamless connectivity to the FPT and PETRONAS environments for
project-related activities.
• Security (for laptop and VDI used to connect PETRONAS environment in Figure 3)
 The domain setup enables centralized management and control over security
policies, user access, and authentication.
 Regular antivirus updates and software patches are applied to detect and
prevent security threats and vulnerabilities.
Open
P a g e | 13
 Security controls such as EDR, DLP, disk encryption, web proxies, and hardening
are deployed as part of the SOE and can be applied on-demand
 Endpoint Detection and Response (EDR) tools monitor and respond to potential
security incidents can be applied on-demand
 Data Leakage Prevention (DLP) mechanisms prevent unauthorized transmission
of sensitive data and can be applied on-demand
 Disk encryption protects data stored on laptops in case of loss or theft
 Web proxies filter and monitor internet traffic for secure browsing.
 Hardening measures are implemented to minimize vulnerabilities through
secure configurations.
 Regular security reports provide visibility into laptop security status, including
patch levels, antivirus updates, and compliance.
Figure 3: GDC IT Infrastructure
2.1.1.3 Network Connectivity
The GDC utilizes existing PETRONAS infrastructure, including on-premises, cloud platforms, and Azure
DevOps, with secured access via FPT-managed laptops or VDI, ensuring business continuity, collaboration,
and flexibility through trusted connections and backup environments (ref. Figure 4 GDC Network
Connectivity to PETRONAS (Primary) and FPT (Redundancy) Environment)
• The GDC will utilize the existing PETRONAS infrastructure, including PETRONAS on-
premises and cloud platforms (AWS, Azure), and Azure DevOps for project engineering.
• Users will securely access the PETRONAS engineering environment using FPT-managed
laptops or VDI.
• Project data will be kept in PETRONAS Trusted SaaS (Azure DevOps), ensuring
availability, resilience, and recoverability for software development and deployment
processes, supporting Business Continuity Planning (BCP).
Open
P a g e | 14
• Trusted connections to PETRONAS partners can be established through site-to-site VPN
or any other methods permitted by PDSB.
• For potential use by PETRONAS: FPT also provide a backup FPT Corporate engineering
environment using its data center infrastructure in Vietnam for business continuity or in
case Petronas software development environment provisioned for the project is not yet
ready.
Figure 4 GDC Network Connectivity to PETRONAS (Primary) and FPT (Redundancy) Environment
2.1.1.4 FPT (Redundancy) Environment for potential use by PETRONAS
To strengthen the GDC's delivery capabilities, FPT provides a backup project engineering environment
through its Vietnamese data center for potential use by PETRONAS (ref. Figure 5, 6, 7, 8)
• FPT provides additional secure Virtual Desktop Infrastructure (VDI) service for staff and
vendors to access project workspaces and the FPT engineering platform (Figure 5,6)
• VDI ensures a controlled environment for project-related activities, with dedicated
workspaces for each project (Figure 5,6)
• Multiple cloud platforms, including hybrid setups, are supported to meet project
requirements and allow development, deployment, and testing flexibility.
• The FPT engineering platform and DevOps toolchain are accessible to the project team
and authorized partners (Figure 5)
• This access enables active participation in the software development life cycle, utilizing
collaboration, version control, CI/CD, and other development processes provided by the
platform and DevOps toolchain (Figure 5)
Open
P a g e | 15
• FPT's global network infrastructure ensures optimal connectivity for customers
worldwide, enabling GDC to serve clients across the globe (Figure 7,8)
Figure 5: Redundant FPT Engineering Environment for Business Continuity and for potential use by PETRONAS
Figure 6: FPT VDI Infrastructure for potential use by PETRONAS
Open
P a g e | 16
Figure 7: FPT Available Data Centers for potential use by PETRONAS - Total Capability: 7,540racks
FPT empowers GDC by providing a datacenter that ensures top-notch data security and availability for our
customers. This is achieved by implementing strict frameworks like TCVN 9250:2012, ISO 9001:2015, 27001:2013,
27001:2015, PCI-DSS, and Uptime Tier 3.
Figure 8: Network Infrastructure for Accessing Vietnam Data Center for potential use by PETRONAS
Open
P a g e | 17
Figure 9b: Network Infrastructure for Accessing Vietnam Data Center for potential use by PETRONAS
Figure 10c: Network Infrastructure for Accessing Vietnam Data Center for potential use by PETRONAS
Open
P a g e | 18
2.1.1.5 DC Certifications
Since Malaysia DC is at the beginning stages of its setup, FPT will be bringing certain certifications to the
Malaysia DC in order to make it globally recognized.
FPT plan to enable the Malaysia DC to receive the below certifications:
Year 2 Year 4+
 CMMI Level 3: The Capability Maturity  CMMI Level 5: the organization has
Model Integration (CMMI) helps achieved all the specific goals defined in
organizations streamline process maturity levels 2, 3, and 4
improvement and encourage behaviours
that decrease risks in software, product
and service development.
 TMMI Level 3: a worldwide standard for
test process improvement
 ISO 9001: the international standard that
specifies requirements for a quality
management system (QMS)
 ISO 27001: international standard for
information security
Note: CMMI Level 5 require at least 1 year real world data for certification purposes
The above certifications represent FPT's current intentions for enabling the GDC in Malaysia. In reference
to other certifications encompassing Health, Safety, and Environment (HSE), Service Management,
Business Continuity Planning (BCP), and related domains, it is noteworthy that FPT Vietnam possesses the
essential certifications, such as ISO 20000-1 and ISO 22301, among others. FPT Vietnam will provide
guidance for aligning GDC's processes and adopting best practices derived from these certifications, thus
contributing to the continuous enhancement of GDC's operations.
Open
P a g e | 19
2.1.1.6 DC Capabilities
For GDC, we will be focusing on technology stack below. However, if the need arises, FPT will be willing to
bring in additional Digital skillsets into the GDC with the support of FPT HQ.
a. Cloud
GDC will be mainly focused on two cloud technologies, namely AWS & Microsoft Azure. FPT has
global partnership with these two cloud giants which GDC can leverage with for expert advise.
Figure 11: Key Partnerships
Open
P a g e | 20
b. Software Development (Common Tech Stacks)
Below are some of the technology stacks that FPT commonly used for Software Development.
Some technologies like .NET, Angular, Flutter, React, ELK, SQLServer etc, are already part of current
GDC capabilities. If the need arises for other technologies in this list, GDC will receive support from
FPT HQ to build such capabilities.
Figure 12: SD Common Tech Stacks
Open
P a g e | 21
c. Data Engineering (Common Data Stacks)
Similarly, below are some of the technology stacks that FPT commonly used for Data Engineering
where some technologies like S3, ELK, Hadoop, PowerBI & SQL are already part of current GDC. If
the need arises for other technologies in this list, GDC will receive support from FPT HQ to build
such capabilities.
Figure 13: DE Common Tech Stacks
d. DevOps Engineering
Although PDSB mainly uses Azure DevOps, FPT also has capabilities on the surrounding tools under
DevOps engineering which will be extended to the GDC.
Figure 14: DevOps Engineering Solution
Open
P a g e | 22
e. Artificial Intelligence (AI) & Machine Learning (ML)
FPT has a unit dedicated to AI & ML in Quy Nhon province of Vietnam, with ~ 800 members as per
2023. This unit will be supporting GDC and bringing its expertise in various technology stack of AI &
ML to better serve GDC needs.
Figure 15: AI & ML Tech Stacks
f. AI & ML Algorithms & Models

FPT AI Unit in Quy Nhon province of Vietnam take pride in our diverse array of advanced AI
algorithms and models that drive innovation and empower businesses to make intelligent, data-
driven decisions. Below diagram show some examples of algorithms and models that FPT AI team
can bring to the GDC.
Figure 16: AI & ML Algorithms and Models
Open
P a g e | 23
The capabilities and partnerships that FPT has will enable PDSB to tap into FPT general capabilities and bring
them to Malaysia when there are demands for it.
During the stage of formation of GDC, for skillset which is not made available for FPT Malaysia DC, FPT will
leverage on FPT Global resources at beginning and replace those resources with local resource over time.
Following table demonstrates how does it work.
First 6 months Six months later Year 2 and Beyond
• Leverage FPT Global resources • Using FPT Global resources for • Will continue the
for up to 100% demands. up to 70% demands. capabilities planning
• Hiring Malaysian experience • Using FPT Malaysian using P4R and 3
resources to do On the Job resources for up to 30% months rolling
Training for up to 20% demands. capacity planning as
forecasted required • Hiring 20% Malaysian input.
skills/roles. Refer session 2.2 experience resource to do On • Will use input to
Skill and Talent Development the Job Training on forecasted further meet FPT
for training information. required skills/roles in order commitment of 60%
to meet FPT first year in Year 2, and 70% in
commitment of 50% Year 3.
Malaysians.
Note: the local composition % is based on the total DC resources engaged via the GDC contract. Please
refer to Section 2.2.1.1 (1b) for Local Composition commitment.
Training via Practical Projects
Practical projects provide a hands-on learning experience that allows individuals to apply their knowledge
and skills in a real-world context. Training people via practical projects offers a comprehensive learning
experience that combines theory with real-world application. It allows trainees to develop technical
expertise, problem-solving abilities, collaboration skills, and a deeper understanding of the work they will
undertake.
Practical projects facilitate a deeper understanding and retention of knowledge. Trainees have the
opportunity to practice and refine their skills, learn from their mistakes, and receive feedback for
improvement. This iterative learning process accelerates skill acquisition and fosters continuous growth.
Practical projects provide trainees with tangible work samples and project experience that can be
showcased in their portfolios. This hands-on experience enhances their employability and demonstrates
their ability to apply their skills effectively.
Open
P a g e | 24
As part of GDC, the unit dedicated to energy sector: Customization Energy Platform (CEP) will play a major
role. In fact, the Director of CEP will be heading the FPT GDC as well so that this GDC can leverage more
efficiently on their industrial practices such as expert advises and technical capabilities.
Customization Energy Platform (CEP) GDC
Director Dual Role

Head of Delivery Center
Figure 17: CEP Director as GDC Head
Open
P a g e | 25
2.1.2 Plan & Timelines
FPT proposes the 5 year DC journey as below with the different yearly focus areas:
 Year 1: Initialisation, Setup & Stabilisation and Quick Wins.
 Year 2 – 3: Business as Usual & Continuous Improvement.
 Year 4 – 5: Global Standards and Independent Operation.
Efficiency
Gains + Cost
Savings
Note: ¹ X = 3-5% , ² Y=3-5% , ³ Z=5-10% (Over 3 Years) for reference based on FPT other client’s DC statistics, subject to review of actual performance by FPT + PDSB
Figure 18: GDC Timeline
Open
P a g e | 26
2.1.3 Business Continuity Plan (BCP) and Disaster Recovery (DR)
BCP involves defining all risks that can affect the GDC's operations, making it an important part of the
organization's risk management strategy. The plan includes:
a) Identifying CRISIS AGENTS which directly affect the GDC’s operations.
b) Determining how those risks will affect operations.
c) Implementing safeguards and procedures to mitigate the risks.
d) Testing procedures to ensure they work.
e) Reviewing the process to make sure that it is up to date.
f) Training the process to ensure relevant people well acquire the BCP
Picture below summaries:

a) What are risks the BCP must mitigate (CRISIS AGENTS)
b) Subject which must be protected once risks happening (PROTECTED SUBJECTS)
c) TEAMS are responsible for executing the plan once risk happening to reduce disruption.
d) STRATEGIES and TOOLS show how BCP works.
Figure 19: BCP Overview
Open
P a g e | 27
2.1.3.1 Emergency Response Team (ERT)
ERT is responsible for executing the plan once risk happening to reduce disruption. In disaster, ERT,
especially ERT Lead is direct commander for continuity and recovery activities.
Figure 20: Emergency Response Team (ERT)
2.1.3.2 Business Continuity Impact Analysis

Table below identifies the effects of disruption of business functions and processes:
Agent Subject impacted Operation effected Recovery requirements

• Resource replacement plan must
be available not later than 3
hours since informing some
• People may panic,
resources cannot work.
lose control, and
• People cannot work • Network access cannot be
get serious injury.
because of health discontinued more than 12 hours.
Fire / Flood / • Network &
impact. • After 3 working days since
Earthquake / infrastructure may
• Working space are damage happening, at least 30%
Terrorism be damaged.
inaccessible. working in office employees must
• Premises may be
• Works are delayed. have office to work.
unable to access or
• After 3 months since damage
fully destroyed.
happening, 100% working in
office employees must have office
to work.
• People cannot work • Resource replacement plan must
• People may get
because of health be available not later than 3
infected, cannot
impact. hours since informing some
perform work as
Epidemic • Group gathering is resources cannot work.
usual.
prohibited. • Offline working plan must be
• Office may not be
• Working space are available not later than 3 hours
fully utilized.
inaccessible. since damage happening.
Open
P a g e | 28
Following plans are for responding recovery requirements:
1. P0 – Communication Plan. Refer session 2.1.3.3 P0 – Communication Plan on page 29
2. P1 – People Treatment Plan. Refer session 2.1.3.4 P1 – People Treatment Plan on page 29
3. P2 – Backup Working Places Plan. Refer session 2.1.3.5 P2 – Backup Working Places Plan on page
30
4. P3 – Networks / Infrastructure Plan. Refer session 2.1.3.6 P3 – Networks / Infrastructure Plan on
page 31
2.1.3.3 P0 – Communication Plan

Communication plan guides who would talk to whom in which matter and how communication would be
taken place.
Figure 21: BCP Communication Plan
2.1.3.4 P1 – People Treatment Plan

To ensure people have the best treatment in case of emergency, disaster, and pandemics, following
activities must be taken place:
When What Who How
• Training lead: • Training courses: First aid, fire
Train and test people to
ERT rescue
react smoothly with
• Trainee: • Fire drill and evacuation
emergency.
Employees practise every 3 months
Before disaster
• HR department
Protect people with proper • Make good deal with
to design
insurance plan in both insurance companies to treat
insurance policy
normal and crisis case. well people.
for employee
In disaster Establish shadowing plan • ERT • ERT evaluates people health
in project to ensure • Project Leads status.
workloads in working (RL) • PL and RM make backup plan
Open
P a g e | 29
When What Who How
in case resource cannot work
because of health problems.
• Resource See session 2.1.3.2 - Business
projects are not impacted.
Manager (RM) Continuity Impact Analysis on
page 28 for further
information.
2.1.3.5 P2 – Backup Working Places Plan

To have backup working places in case main working place cannot be accessed, following activities must be
taken place:
When What Who How
• Equip laptop to all employees.
Equip employees working • Must have feasible amount of
facilities which are backup laptops in case cannot buy
• Admin
adaptable for remote during disaster.
working. • Must ensure all employee have
workable home bandwidth.
• Have agreements with at least 2
coworking office suppliers for
backup office ready to align with
Before disaster requirements in session 2.1.3.2 -
Business Continuity Impact
Select possible places
Analysis on page 28. Some
where employees can
• Admin references:
gather for short meeting or
www.servcorp.com.my;
working.
www.regus.com.
• Maintain list of public areas such
as coffee shop which can be
recommended for project teams
to use for short meetings.
• ERT daily aligns with Team Leads,
• ERT Admin to make weekly schedule
Evaluate and activate
• Admin for temporary working places.
backup office with vendors
• Team Leads • Admin aligns with vendors to make
office available as scheduled.
• Admin and BOM as soon as
possible evaluate the situation to
In disaster make decision either to repair
current office or move to new
Evaluate and make plan for • Admin position.
recover office. • BOM • Make office recovery plan aligning
with BOM decision to satisfy
requirements in session 2.1.3.2 -
Business Continuity Impact
Analysis on page 28.
Open
P a g e | 30
2.1.3.6 P3 – Networks / Infrastructure Plan
To make it possible for employee access to IT working environments anywhere, as if they are working in
main office, following activities must be taken place:
When What Who How
• Estimate and make agreements
Using VDI for employees
• IT with VDI suppliers to buy VDIs
who are on works.
correspondingly.
• Have agreements and switching
plan with at least 1 backup VDI
Plan backup VDI suppliers
vendor to satisfy requirements in
Anytime just in case main supplier • Admin
session 2.1.3.2 – Business
got problem
Continuity Impact Analysis on page
28.
Continuously monitor,
evaluate, and solving • IT • Execute VDI operation procedures
problems
2.1.3.7 Emergency Response Procedures

Once emergency happens, follow procedures below correspondingly:
ID AGENT/ WHO WHAT WHEN HOW

TRIGGER
E01 FIRE ERT  Call 999 Immediately  Phone call
 Activate alarm system.  Alarm system
 Evacuate people in GDC’s  Evacuation
building to pre- guideline
identified assembly points.
 Activate P2 – Backup Working
Places Plan on page 30, P3 –
Networks / Infrastructure Plan
on page 31, if GDC building is
seriously damaged.
E02 FLOOD ERT  Evacuate people in GDC’s Immediately  Phone call
building to pre-  Evacuation
identified assembly points. guideline
seriously damaged.
E03 EPIDEMIC ERT  Evacuate people in GDC’s Immediately  Phone call /
building to pre- Email
identified assembly points.  Evacuation
 Activate P1 – People Treatment guideline
Plan on page 29, P2 – Backup
Working Places Plan on page 30
and P3 – Networks /
Open
P a g e | 31
Infrastructure Plan on page 31.
E04 EARTHQUAKE ERT  Activate alarm system. Immediately  Phone call
 Evacuate people in GDC’s  Alarm system
building to pre-  Evacuation
identified assembly points. guideline
seriously damaged.
E05 TERRORISM ERT  Call 999 Immediately  Phone call
 Follow instructions from
competent authorities
In the event BCP is triggered by PDSB, FPT will work with the relevant parties based on PDSB BCP
parameters, as well as the ones defined in the respective Work Order reduce downtime and recovery time.
2.1.3.8 Maintenance and Awareness

To ensure the BCP is implemented correctly, it requires compliance checks, training for awareness and
update the plan for improvement.
Following table displays required activities:
By
Compliance Manager ERT BCP Lead
Activity
Provides action plan to Commits and manages

Inspects and sends report
COMPLIANCE fix non-compliance to fix reported non-
regularly
items compliance items
Manages BCP awareness

training plan and status. Does BCP awareness
TRAINING
Does BCP awareness training training as plan.
as plan.
Updates processes and

CHANGES informs changes to relevant
parties
Training courses which will be conducted are shown in table below:
Trainee
ERT Project Key Member GDC Member
Course
CONCEPT
High level knowledge about GDC’s BCP.
Purpose of this course to let people be aware Optional Optional Compulsory
BCP and not be surprised once receive
related instructions.
DETAILS Compulsory Compulsory Not required

Knowledge about BCP in detail, which is
Open
P a g e | 32
necessary for implementing and reacting
during GDC operation.
CHANGES
Once there are changes in BCP, awareness Compulsory Informed Not required
activities must be conducted via trainings.
2.1.4 Out of scope

All non FPT GDC infrastructure, people, and processes are not in scope. For example, PDSB other vendor’s
staff, PDSB infrastructure, etc
Open
P a g e | 33
2.1.5 Support team and Governance – Roles & Responsibilities
FPT Malaysia Functional Organisation
FPT Malaysia organization structure, it is representation of the hierarchy and relationships of each business function.
Figure 22: FPT Malaysia Functional Organization
Open
P a g e | 34
Delivery Centre Organisation
This level describes the operational level of the DC with focuses on delivery.
Figure 23: GDC Organization
Open
P a g e | 35
Table: GDC role and responsibilities for leadership team
No Leadership Team(s) Responsible Report/Escalate to
1 Program Head For overall success of the program including revenue, growth, profit. Executive Sponsor
• Resolve escalation on relationship, solution and delivery.
• Enable investments from FPT.
• Participate in steering committee with customer.
• Manage business lead, provide guidance and support for the program
core team.
2 Head of DC • Drive intake process to setup growth engine. Executive Sponsor

• Enlisting right solutions team, delivery team and support team. Program Lead
• Drive revenue generation, pipeline building, mapping right talent with
right customer and stakeholders.
• Provide all enablement and support to the GDC rollout and operational
such as managing stakeholder relationship, delivery and solutioning.
• Ensure GDC governance and performance reporting to Working

Committee and Steering Committee are executed as planned.
• Resolve program level risks/ challenges both internally and with
customer.
• Drive value realization as agreed between FPT & PDSB.
• Responsible on all GDC deliveries.
3 Head of Client Engagement • Manage relationship with Corporate executives, Engineering SVPs, and Program Lead
VP level. Head of DC
• Manage relationship with VMO and procurement.
• Provide insights, competitive intelligence and guidance from Customer
to the team.
• Voice customer feedback to the team and help in resolution.
• Manage customer expectations on FPT.
• Liaison between FPT and Customer leadership.
Open
P a g e | 36
4 Head of Delivery • Set up portfolio management and program management processes. Program Lead
• Setup delivery models, work with offshore leadership for resource ramp Head of DC
and manage demand forecast.
• Setup KPIs and Metrices to measure delivery success and customer
satisfaction.
• Provide oversight on all program executions.
• Assess delivery risks and resolve leveraging FPT and delivery teams.
5 Global Solutions • Provide support for all technical solutions.

• Bring right technical experts from both FPT and customer to resolve
customer business/ technology challenges. Head of DC
• Coordinate between onsite offshore pre-sales teams across FPT & Head of Delivery
customer.
• Review all tech solutions and provide guidance to tech leads, solutions
architects in each large engagement.
6 Global Operation • Support DC to create resource plan for the program. Head of DC
• Guide Global Delivery on resource ramp up.
• Create code quality, delivery quality metrics and monitor metrics. Head of Delivery
• Enlist support from FPT extended delivery, pre-sales, VI and FSUs to
ensure smooth delivery.
• Key guide and advisor for overall delivery success.
• Participate in customer review sessions on delivery and incorporate
changes into the model.
7 Global Delivery • Function as offshore delivery leader for the program. Head of DC
• Responsible for resource ramp, resource quality and delivery.
• Act on client feedback on offshore delivery and resolve issues. Head of Delivery
• Assess offshore delivery risk and mitigate.
• Ensure software quality metrics as defined by client.
• Manage transition during engagement ramp, transition from vendors,
etc.
• Manage delivery teams, provide delivery review and team
improvements.
8 PMO Lead • Client engagement in PMO Lead capacity to ensure client satisfaction on Head of DC
delivery.
Open
P a g e | 37
• Act on client feedback on delivery and resolve issues. Head of Delivery
• Assess delivery risk and support mitigation.
• Responsible for leading the program office, setting the program
standards, establishing and enabling the program processes and tools.
• Supporting and guiding the Delivery Managers to ensure the meeting of
client expectations.
• Responsible for working with Finance, Legal and HR to enable
compliance and financial alignment.
Open
P a g e | 38
Table: GDC role and responsibilities for business and delivery team
The followings are the proposed GDC roles and responsibilities for delivery team, but not limited to:
No Role Responsible Who do they team Can be shared?

with?
1 Business line lead This individual will be a Delivery Manager for one of the • Organizationally the Yes, depending on team size,
engagements within the Solution Set (big program that other DM’s in that complexity of work. If the
includes many solutions); and take the role of Lead for the Solution Set will report programs have more than 1
other engagements within the Solution Set. to the Solution Set Lead, solution, it is recommended to
This role will be active in: who will report to the have business line leads to
• Supporting the DM’s to overcome hurdles and resolve issues Engagement Delivery manage.
(including managing scorecard metrics). Executive
• Maintaining delivery relationships with the Engineering and
Product leadership for the Solution Set.
• Supporting any solution efforts across the Solution Set.
• Onboarding of new DMs in the Solution Set to ensure
consistent understanding of CAPG and engagement success,
process, tools, etc.
• Supporting the Sales team with identifying opportunities,
threats and supporting solutioning.
Open
P a g e | 39
2 Delivery manager FPT’s accountable person for the delivery of the team • Point of contact for the Yes,depending on team size,
• A key role to ensure we are delivering at or above product manager and complexity of
expectations, quality, velocity, etc. product owner to ensure effort, and type of product
• Will be Agile experienced, and normally scrum master alignment on intent and activity
certified. prioritization
• They will be involved in the Epic to Feature to Story journey • Point of contact for the
… sometime hands on, sometimes as guide, depending on size Engineering lead
of team and level of activity. • Scrum master to
• On larger efforts, this role will be more management ensure velocity and
focused. Ensuring alignment between the product team and engagement challenges
the ngineering team, clearly setting expectations, and
coordinating/ blocking and tacking activities, including clearing
of hurdles/ barriers.
• On smaller proposals this role is more hands on technical …
e.g. Consumer Mobile Dev, the Delivery manager is also a
Flutter and Mobile developer and will drive architecture, use of
the platform, write complex code, conduct quality reviews and
guide the ffshore team.
• So this role will vary from ‘engagement manager’ to ‘scrum
master’ to ‘Lead developer/ architect’ … with a dose of PM on
the side.
3 Product owner • Understand the business intent, needs and priorities. • Product manager Yes. Within the same domain.
• Manages the stakeholder and sponsor expectations, • Delivery team
including technical feasibility. • Business analyst
• Focused on defining Epics and Features, including ensuring • Technical solution lead
they get to ‘Done’.
• Responsible for prioritizing and grooming the backlog.
• Responsible for developing and defining acceptance criteria.
• This role typically is from the client.
Open
P a g e | 40
3 Product manager • Understanding and representing user needs. • Product owner/ Yes, depending on technical
manager stack, team size, complexity of
• Monitoring the market and developing competitive analyses. • Delivery team effort, and type of product
• Defining a vision for a product. • Business analyst activity
• Technical solution lead
• Aligning stakeholders around the vision for the product.
• Prioritizing product features and capabilities.
• Creating a shared brain across larger teams to empower

independent decision-making.
Open
P a g e | 41
4 Technical solution lead • Responsible for overall technical solution. • Delivery team Yes, depending on team size,
• Focused on enabling the business intent, translating the • Technical architect/ complexity of effort, and type
intent to the development team, quality (code reviews) and technical leads of product activity
testing completion. • Offshore team lead
• Experienced in the technical stack, and experienced in Agile • Product owner/
approaches. manager
• Will play a role in the technical architecture, and be involved
in defining how to deliver the business intent from the
underlying technology.
• It’s one of the key ‘translation’ points between the onsite
and offshore teams, will be responsible for addressing the
offshore team’s questions, and setting the tone and direction
… and quality and testing review.
• Depending on size of team and type of work, can also play a
hands on developer role.
5 Business analyst • Elaboration of the Features and generation of the Stories. • Product owner/ Yes, depending on team size,
• Consult with the Product owner in terms of business needs manager complexity of effort, and type
and prioritization. • Technical solution lead of product activity
• Defining Stories at the technical level so that the offshore to agree tradeoffs
software engineers can develop code to meet the between intent and
expectations. technical possibilities
• Breakdown the product backlog to stories. • Offshore development
• Detail acceptance criteria (based on Product Owner team
definition).
• Proxy product owner for offshore team.
6 UI/UX • Responsible for the UX elements of a product. • Process owner/ No

• Interfacing with the relevant user communities to develop manager
personas, journey maps, develop wireframes and low/ hi • Business analyst
fidelity comps. • Technical solution lead
• Including AB testing and mind maps.
• Engaged in and preparing user interface design.
Open
P a g e | 42
7 Lead developer • Role responsible for leading the dev team. • Technical solution lead Yes can be shared across
• A key role that pair up with the onsite team, and manages • Delivery manager several smaller scrum teams
the offshore team … the other half of the translation equation. • Scrum master (can be a shared with the
• Typically a hands on developer, and part of the role is to be • Software engineer Lead Developer role,
the lead developer for the team, dependent on team size, • Testing/ QA depending on team size)
complexity of effort, and type of product activity. • Product owner/
• Typically our ‘Lead Engineer’. manager
8 Scrum master • Responsible for SCRUM ceremonies. • Technical solution lead No

• Lead developer
• Ensure the team work as per agreed Agile Scrum model. • Product owner/
• Assist the team to overcome impediments. manager
• Facilitate internal communication and effective

collaboration.
• Resolve conflicts and remove obstacles that occur.
• Guide development teams to higher scrum maturity.
9 Software engineer • Work with business analyst to understand the requirement • Lead developer
and deliver solutions through standard practices, incorporating • Scrum master
frameworks, development language and methodologies. • Business analyst
• Test automation
• Works on project life cycle from requirements through engineer
design, implementation, and support to ensure • QA analyst
implementation of appropriate technology in every stage
10 Data Engineer • Implementing all the processes from data collection, • Lead developer Can also be done by the
cleaning, and preprocessing, to training data set and deploying • Scrum master software engineer …
them to production, including but not limited to following • Business analyst depending on team size and
responsibilities: • Test automation tools in use
• Develop ETL (extract, transform, load) processes to help engineer
extract and manipulate data from multiple sources. • QA analyst
• Develop, construct, test and maintain data related
architectures.
• Managing analytical / integration tools, databases,
Open
P a g e | 43
warehouses.
• Performs data analysis required to troubleshoot data related
issues and assist in the resolution of data issues.
• Works closely with a team of frontend and backend

engineers, product managers, and analysts.
11 Test automation engineer • Ensure that all functions developed by the team are tested. • Lead developer No
• Combine automated/manual testing to efficiently cover • Scrum master
system functionality without compromising quality. • QA analyst
• Strives to automate and maintain comprehensive test sets
with a continuous improvement mentality.
• Actively participate in scrum ceremonies as needed to
provide clarification and resolve issues with the team.
12 QA analyst • Test to meet the criteria.

• Development of test strategy.
• Partners with development teams to identify key risk areas in
new solutions.
• Keeps up to date with best practices and industry standards
in testing.
• Definition of and execution of testing (auto or manual).
• Provide the team with detailed information about any
defects found and help the Agile Coach and PO prioritize the
backlog.
Open
P a g e | 44
2.1.6 Critical Success Factors for Operationalization of GDC
PDSB 1. PDSB and FPT Top Executives and Management commitment.

2. PDSB to view the GDC as a true extension of their own team.
3. Early establish and employ Agile process and DevOps practices.
4. Transparent business capacity planning with FPT.
5. Early knowledge acquisition by the GDC product team.
FPT 1. FPT to operationalize the DC as early as possible, as well as working with PDSB to
syndicating the GDC operating model with all the relevant stakeholders.
2. Frequent communication, well-defined reporting, project management efficiency and
escalation processes.
3. Deploy qualified personnel for GDC success.
4. Level up and upgrade Malaysia young IT talent.
5. Furnish GDC with globally recognized certifications.
6. Build Innovation Hub to partner with PETRONAS on Product Commercialization.
2.1.7 PDSB Obligation
1. Perform 3 months rolling capacity planning with FPT (detail in section 2.3.3).
2. In outcome-based engagement, FPT personnel will be engaged via FTE count, PDSB to accept FPT
team selection.
3. Allow FPT to be part of P4R or equivalent annual budgeting process.
4. Migrate a minimum of 40% of identified project engagements to outcome-based (capacity /
functional) in 1 year after GDC setup. Target of projects will be 80% in 2 years, subject to mutual
planning and agreement.
5. For outcome-based engagement, PDSB will only interview key personnel and not all the team
members.
6. Allow FPT teams to interface directly with PETRONAS Businesses for opportunity & product/
project with the facilitation of PDSB.
7. Allow FPT solutioning personnel to be involved since Gate A (Approved to Propose).
8. PDSB to provide work order to FPT within 2 weeks upon SOW signoff by business.
9. Gate B (Approved Solution Proposal) to Gate D (SOW Signoff) to complete within 2 weeks.
10. Focal personnel to work with FPT during project / product handover to DC.
11. Accept that healthy seniority ratio (e.g. 20% Seniors, 40% Mid, 40% Juniors) as per industry
standard for projects / products to be deployed into GDC, unless agreed otherwise by PDSB &
FPT for the particular engagement.
Open
P a g e | 45
2.1.8 Deliverables
FPT will be building the Delivery Center with the workings below:
Core Team will be formed to support the GDC as per defined in item 62 of Section 2: “Definitions”.
FPT HQ will support Malaysia in:

1. Capacity from offshore.
2. Training & Upskilling Malaysians.
3. Best Practices, Processes & Technologies.
Squad Teams will be created for the product portfolios encompassing various roles that will be required to
successfully deliver end to end of the solution.
PDSB Teams will be providing support (when reasonably required) to GDC for the purpose of successful
product and project delivery, including but not limited to:
1. PETRONAS Governance Standards & Procedures (EA, Tools, Change Management, Incident
Management etc)
2. PETRONAS Business Stakeholder Management
3. PETRONAS Enterprise Architecture Standards & Controls
4. PETRONAS Infrastructure (Cloud or On Prem) Provision & Access
5. PDSB Product & Project Research (Feasibility Studies, Market Research, etc)
6. PDSB Project & Resource Planning (FPT GDC Portion)
GDC
Figure 24: GDC Key Teams
Open
P a g e | 46
Open
P a g e | 47
2.1.9 KPIs/Measurements
Please refer to Annexure B, Metrices, DC Level Metrices, Category Delivery/Process/IT Infrastructure for
details
Open
P a g e | 48
2.2 Skill and Talent Development
FPT will provide Skill and Talent development for the workforce under the purview of the GDC to execute
product development and support services.
2.2.1 In Scope
2.2.1.1 Fulfillment
To fulfill GDC’s resource requirements, FPT is providing support using its current facilities, capabilities and
hiring abilities as below:
 Training capabilities:
o There are 4 campuses in Vietnam and 1 campus link (with UTP) in Malaysia which are
equipped with suitable infrastructure and are ready for GDC utilized as necessary.
o FPT has more than 20 training programs which are suitable for building software
development and related industrial knowledge to GDC’s resources. In which, fresher
training courses take 3 to 6 months to convert a fresher to productive resource.
o Each year, FPT is capable of training for more than 5,000 resources.
 Hiring abilities:
o Every month, GDC can hire more than 15 and 5 productive resources at West & East
Malaysia respectively. In which, 60% or more are Malaysian resources.
o Every year, GDC can enroll, train and hire 150 students from local universities and
international universities.
Figure 25: Training facilities, capabilities and Hiring abilities
1. Workforce Requirement and Forecast
FPT will work jointly with PDSB to create a 3 months rolling work force plan which will be based on the
demand plan and forecasted attrition as per projected volumetric targets.
Open
P a g e | 49
a) Workforce fulfilment will be done considering the below
1. Talent Requirement – FPT will plan for workforce requirement to meet the business goals.
2. Talent Pool – FPT Resource Manager will share internally available and trainable resources within
the FPT organization matching the Job description and will initiate approval for external hiring for
the pending targets.
3. Talent Fitment – skills and competencies of the FPT associates will be assessed to map the
associate to the right role and project. FPT appointed or selected talent resources will not be
subjected to PDSB’s interview as part of selection process except for key roles in T&M projects.
4. Talent release – in the event of release of a resource, FPT will communicate the same to PDSB to
initiate termination of PETRONAS id. For critical resources, FPT will identify a backup and also
plan for Knowledge Transition.
b) Composition: FPT will plan for fulfilment of workforce as follows in accordance to 2.1.2:
Year 1 Year 2 Year 3
Malaysian Fresher 30% 30% 30%
Malaysian Experience 20% 30% 40%
Global Experience 50% 40% 30%
c) Channels: FPT will be fulfilling the workforce requirements for the GDC projects through any of the
channels indicated below.
1. Hiring Local Malaysian Technical Talent on full-time permanent or contract employment basis;
2. Hiring local fresh graduates from Malaysian universities.
3. Hiring Expatriate Technical Talent on full-time contract engagement basis.
d) External Hiring Process: External hiring will be done, if skill availability is limited within FPT Malaysia,
as per below:
1. Resourcing Partnership
e) Demand Planning Process

1. FPT will adhere to the process as described in section .3.
2. PDSB will adhere to the demand planning obligation as per described in section 2.1.7
2.2.1.2 Competency Management and Development
The GDC builds its talents based on:

a) GDC resource planning
b) Project specific demands
Sources of talent come from:
a) Internal experience resources
b) Fresher from universities
c) Fresher from market
d) Experience resource from market
Open
P a g e | 50
GDC establishes a unit called Resources & Capabilities Center (RCC) to manage and develop its
resources. Picture below depicts the structure of the RCC:
Figure 26: Resources & Capabilities Center (RCC) Organization
The RCC is closely working with other units to plan and operate a resource pool which provides
resources for delivery activities.
Figure 27: Resource Pool's Operations
• Resource Pool is operated as a buffer-space to balance work demands (resource demands for
working teams) and supply-abilities of the DC. It enables DC’s scalability according to demands.
• Decisions to ramp-up or ramp-down size of the Resource Pool are based on long-term and mid-
term plan between PDSB and FPT.
• Resources are treated and developed as per Resource Pool’s policies which to be created during
the first 4 months using HQ policies as reference.
Open
P a g e | 51
• Resources who finish their mission in working teams (projects / products) will be returned to the
Resource Pool, ready for new assignments.
2.2.1.2.1 Onboarding (Resource Pool Arrival), Offboarding (Resource Pool Departure) flows
A resource from outside who are admitted to DC Resource Pool will have to go through the following
steps of Onboarding flow for Resource Pool Arrival:
Figure 28: Company Boarding Flow
Lead time for boarding a resource from outside to the Resource Pool, ideally, would not impact to lead
time for boarding a resource into working team. Example, to bring a non-Malaysian senior resource to
the Resource Pool taking 30 days in average. It doesn’t mean the project has to wait for 30 days to have
this type of resource joining the project. It would be much less than. See session 2.2.1.2.2. Onboarding
(Project Arrival), Offboarding (Project Departure) flows on page 53 for further information.
Once a resource wants to leave, or the DC manages to ramp-down the Resource Pool’s size, Offboarding
Flow for Resource Pool Departure will be executed:
Figure 29: Company Offboarding Flow
If the leaving resource is working in project/product, the flow described in session 2.2.1.2.2. Onboarding
(Project Arrival), Offboarding (Project Departure) flows on page 53 must be executed.
Open
P a g e | 52
2.2.1.2.2 Onboarding (Project Arrival), Offboarding (Project Departure) flows
The Onboarding (Project Arrival) flow describes steps to deploy a resource (from the Resource Pool or
Vendor) into a working team:
Figure 30: Project Boarding Flow
Provided facilities for resource to work including (but not limited): Access rights, Required machines,
hardware, software…
Onboard lead time (T&M Only) is summarized as following table:
CV Proposed Deployed2
(Not later than n days since client
(Not later than n days since a
Lead time1 confirms to accept the proposed CVs,
request is raised by client, the CVs
the resources must be ready to join
must be proposed accordingly)
the works)
Fresher 5d 5d
Malaysian Middle / Senior 15d 10d
Niche / Subject Matter 20d 30d
Fresher / Middle / Senior 10d 15d

Global
Niche / Subject Matter 20d 30d
Example, if client request a Malaysian senior developer, the GDC must submit CV not later than 15 days since
1
As norm, about 40% total T&M requests are really need resources staffed as fast as possible. This lead-time table
is assumed to serve for that 40% T&M requests. For the rest, it may need longer time, but not exceed double times
of given numbers in this lead-time table.
2
Suppose on-board procedures from client’s site were finished before deployment time.
Open
P a g e | 53
request raised and the resource must be ready to work not later than 10 days after client accept the resource.
Resources complete their assignment period in projects/products or to be released from work earlier
than scheduled end date, Offboarding (Project Departure) flow will be executed to bring the resources
back to the Resource Pool:
Figure 31: Project Offboarding Flow
2.2.1.2.3 Resource Rotation flow
Sometime, a resource is required to leave the current project for another one, it is not required to
return the resource to the Resource Pool and re-deploy his/her to new project. Instead, the Resource
Rotation flow enables projects to exchange the resource without execute heavy boarding procedure:
Figure 32: Rotation Flow
Open
P a g e | 54
2.2.1.2.4 Resource Development
Since boarding the Resource Pool, a resource is continuously developed via training programs designed
and executed by FPT. The basic flow to develop and upgrade a resource is described as diagram below:
Figure 33: Resource Development Flow
Normally, a Fresher takes about 2 to 4 months to become a Productive resource; and he or she must
take one year to upgrade to the next level.
Fresher Academy Program: referring to a training program which converts a Fresher resource into a
Productive resource. See session 2.2.1.2.5 Fresher Academy Program on page 56 for more details.
CAPABILITY ASSESSMENT: before upgrading a resource to the next level, an assessment for evaluating
resource’s capabilities must be taken place to find gaps between current capabilities and next level
requirements.
The assessment is based on predefined standards for the roles and using a) Previous skill training results;
b) Previous On-the-Job Training results; c) Work Experiences as key inputs for evaluation. The current
resource’s capabilities are compared with the standards to find the gaps. Hence, an appropriate training
plan will be designed for development. Following picture depicts an assessment result for a resource
who are being developed to level DEV04:
Open
P a g e | 55
Figure 34: A Sample of Abilities Assessment Results
Career Development Program: referring to a training program which fills capability gaps of a resource to
lift him/her up to the next level of career path. See session 2.2.1.2.6.Career Development Program on
page 57 for more details.
2.2.1.2.5 Fresher Academy Program
According to session 2.2.1.2.4 Resource Development on page 55, Fresher Academy Program is one of
two main training programs for developing a resource in the Resource Pool. The Fresher Academy
Program has following proprietaries:
1. Converting a Fresher resource into a Productive resource.
2. Requiring from 2 to 4 months to complete the program.
3. Admitting and training people who belong to the following groups: a) Newly graduated
students; b) Intern students; c) IT career switching talents.
Activities and milestones for the program is describe as chart below:
Figure 35: Fresher Development Flow
Open
P a g e | 56
2.2.1.2.6 Career Development Program
As another main training program mentioned in session 2.2.1.2.4 Resource Development on page 55,
Career Development Program is designed for filling the gaps of a resource’s capabilities (compared to
requirements of next level), making the resource ready for stepping to next level of his/her career by
conducting 2 months courses training and another 2 months for On-the-Job training.
The Career Development Program is for developing resources belonging to following groups:
1. Employees in development plan: those employees are planned to be developed to the next level
according to their career path.
2. Employees who are intentionally promoted by their leaders in work.
3. Employees who change career tracks.
Activities and milestones for the program is describe as chart below:
Figure 36: Career Development Flow
The course training activity conducted by this program can be classrooms or using online courses with
mentors. Whereas the Fresher Academy Program only conducts classroom training. See session 2.2.1.2.5
Fresher Academy Program on page 56 for more details.
2.2.1.2.7 Training Approaches
 There are 2 training types mainly used in GDC. Those are a) Skill Training and b) On-the-Job
Training.
 Those types of training cover several development dimensions including (but not limited):
a) Technical; b) Soft skills; c) Process; d) Domain; e) Business and Management; f) English.
 FPT design and implement training classes as well as using training partners such as:
coursera.org, udacity.com, udemy.com, and international.fpt.edu.vn.
2.2.1.2.8 Skill Training
• GDC uses either internal courses and trainer or online training partners: such as udacity.com,
udemy.com… as training platforms to develop technical skill for its talents.
• A Mentor is assigned to each trainee. The mentor is responsible for recommending learning
paths; periodically meeting with trainees to update progress; evaluating results when training
finished.
Open
P a g e | 57
• There are 2 types of developments:
o Single skill training: GDC maintains a course catalog. The mentor and project technical
lead use this list to recommend relative courses for training purposes. See session
Appendix A: Sample of Course Catalog for a sample.
o Role-based training: GDC designs and maintains syllabuses for its required roles. The
mentor and manager use those to develop their employees. See session Appendix B:
Sample of A Syllabus for a typical syllabus.
2.2.1.2.9 On the Job Training (OJT)

For OJT program, the trainees are assigned directly into one or more practical projects for observing
others and hands-on experience completing tasks under the supervision of a technical leader, coworker.
In OJT, the trainees are working as productive team members.
Training Course Trainer Duration Evaluation
General Project • BA leader Not exceed 0.5 day N/A

business and architect • Technical Leader
Role-based knowledge • Designated mentor 1 to 3 months After OJT period,
transfer: designated mentor,
Each project has its project leader issue
knowledge transfer evaluation report
plan for every role in about improvements of
project. OJT trainee will trainee.
be guided to go thru
the plan over time.
2.2.1.2.10 English Qualification
Resources in the Resource Pool must get qualified their English ability to ensure capability in work
communication.
The DC requests its non-native English-speaking employees3 must get certification from popular English
tests not later than 6 months since joining DC and must renew the certification properly.
Current standards for English certifications are as below:
 TOEFL iBT 53 and up
 TOEFL ITP ≥ 477 and up
 IELTS 4.0 and up
 TOEIC 550 and up
 APTIS B1 and up
Employees are eligible to reimburse testing fees if they get the certification which meets the standards.
Employees who are not meet English requirements may not be eligible for raising, serious cases can be
removed from the Resource Pool. Any reimbursement of training/testing fees shall not be billable to
PDSB unless it is specifically requested by PDSB.
3
Malaysian, Indian, Filipino employees are considered as native English-speaking employees.
Open
P a g e | 58
2.2.2 Out of scope
i. PETRONAS HR policies and processes shall not be applicable for FPT DC HR policies and
processes.
ii. The relevant training and certification expenses, unless otherwise agreed by PDSB and FPT.
2.2.3 Roles & Responsibilities

HR team from FPT shall be available for the smooth management of FPT DC. A regular cadence with
internal and external stakeholders will be established to ensure effective governance. Roles &
Responsibilities is as follows but not limited to:
Role Responsibilities
HR – Hiring & Responsible for sourcing, selection and onboarding of the right talent
Deployment for DC to create the talent pipeline
Please also refer to 2.1.5 for additional Roles & Responsibilities
2.2.4 PDSB Obligations
 PDSB will provide inputs in terms of resource and project demand forecast for FPT to create a
quarterly rolling demand in advance.
 PDSB shall provide the inputs to FPT to plan for training / upskilling.
2.2.5 Deliverables
 Resource fulfilment done as per PDSB project requirements and timelines
Please refer to Annexure B, Metrices, DC Level Metrices, Category HR/People Development for details
Open
P a g e | 59
2.3 PRODUCT and PROJECT Delivery framework
The delivery methodology for each project delivered as a part of the GDC would depend on the Project Types:
 Product and Project Development –. Agile Delivery Framework as explained in section 2.3.2 would be utilized for developing software product
/projects as agreed in individual Work Orders
 For Product Support and Maintenance projects, the framework would be as per section 2.4 and as agreed in individual Work Orders
2.3.1 DELIVERY FRAMEWORK
Overall engagement will follow and adopt PETRONAS DEX process as below. PDSB will notify FPT should there is any updates on PDSB’s delivery
framework from time to time.
Figure 37: End-to-End collaboration
Open
P a g e | 60
a. Gate 0 - A
(i) PDSB shall manage the funnel demand and the necessary cadence approvals and shall share with FPT the plannings and pipelines
accordingly at Gate 0 (Approved as Unqualified Request).
(ii) FPT will involve during the qualification stage and cadence preparation if required. If FPT is part of this process, FPT will assist in providing
feasibility analysis in the form of ballpark cost and timeline.
b. Gate A - B
(i) On receipt of Service Request(SR), FPT Project Core Team (Solution Architect, Project Manager and/or Business Analyst, and the leads role
if applicable) conduct solutioning activities.
(ii) FPT will identify and onboard core project resources within the agreed period upon cadence’s approval.
(iii) FPT will prepare the Solution Proposal and PDSB shall review the Solution Proposal and make necessary correction and recommendation if
required. PDSB and FPT shall jointly present the Solution proposal to business for further approvals.
c. Gate B - C
(i) Upon business review the Solution Proposal and provided greenlight to proceed, PDSB to complete the SOW development activities based
on the Solution Proposal submitted by FPT at Gate C (Approved to Submit).
(ii) FPT will identify and onboard the rest of the project team within the agreed period from SP developed:
Core Team – 2 weeks upon receipt of WO
The remaining team – Within 1 month after core team mobilization unless specified otherwise in the SP.
d. Gate C - D
(i) PDSB will provide a work order to FPT within 7 working days of SoW signoff
(ii) FPT will kick off the project with the core team two weeks from receipt of work order.
e. Execution & Closure

(i) FPT is to deliver project by necessary governance assessment including Project QA/QC and Cyber Security's Risk Assessment as detailed in
the work order.
(ii) Conduct handover activity to the Support team upon project closure
(iii) For product, FPT will manage the end-to-end product lifecycle with the same DevOps squad with support from PDSB if required.
2.3.2 GDC Engagement Process Commitment Conditions

Gate A - B: 25 Working Days
Gate D: 10 Working Days to mobilize core project members
FPT is able to commit to the target days for each Gate specified above with some conditions below:
1. Business & Tribe (Product Delivery)
a. Business PIC to participate workshops & meetings to allow FPT obtain areas for example but not limited to requirements, problem
statements, current processes, etc as per agreed timeline.
Open
P a g e | 61
b. Able to respond to Q&A in a timely manner from FPT solutioning team sending the inquiry.
c. During Gate 0, FPT will provide a ballpark timeline & estimation for cadence purposes.
d. During Gate A, FPT will provide solution proposal for approval with input from PDSB.
2. DE & SWE
a. Focal for FPT to work with on the opportunity during Gate 0 – D.
b. The focal can assign other PDSB personnel to assist FPT where applicable.
c. The focal work with FPT to manage Business personnel to provide reasonable commitment (Time & Effort) for solutioning.
3. Exclusions
a. KPI / Metrices might not be met if business couldn’t provide the clear and confirmed requirements and DE and/or SWE are not able
to provide commitment (Time & Effort) during Gate A – D.
4. Commitment
a. FPT can meet the SP aging 85% of the time.
b. FPT will identify the potential improvement area and work with PDSB to improve the Gate Ageing/duration together by 3 – 5%
annually.
c. FPT to review the aging baseline annually together with PDSB to seek opportunities for further improvement.
d. FPT shall improve the Solution Proposal turn around annually with the target to achieve less than 20 working days in Year 3 where
possible.
2.3.3 Project and Resource Demand Planning

Demand planning is applicable for all engagement types (i.e. Time & Material, Capacity Based, Fixed Price). In order for FPT to serve PDSB
efficiently, FPT & PDSB will be needed to perform demand planning as illustrated below:
1. Annual Demand Planning (P4R or Equivalent)

a. PDSB performs annual demand planning at least once per year, and FPT would like to join this session (where applicable)
2. 3 Months Rolling Demand Forecast

a. Every month, PDSB & FPT will relook at the annual plan and reforecast following three months of demand based on current and
historical demand data.
b. For example, during Jan, PDSB & FPT will forecast the demand needs of Feb, Mar, Apr.
Open
P a g e | 62
Figure 38: Demand Planning Timeline
Open
P a g e | 63
2.3.4 Agile Delivery Framework for Product/Application Development
Figure 39: 2.3.4 Agile Delivery Framework for Product/Application Development
FPT will adopt the Agile framework as the development approach for each project with active
participation from PDSB. The diagram above illustrates the areas and steps an Agile Scrum team
takes to complete a project / product.
FPT will adopt the Agile framework as the development approach for each project with active
participation from PDSB. The project will be executed in iterations with PDSB providing feedback and
inputs at every stage of the SDLC (Software Development Life Cycle). This will ensure that the end
product adheres to PDSB requirements.
a. FPT will drive the product delivery life cycle and shall work with PDSB and business in a
collaborative manner to achieve the Product Vision and Business Value for a given Product through
documented and prioritized EPICs in the relevant Product Backlog. The specific tasks to be
performed and the scope of the Work for a particular product will be detailed in the respective
Work Orders and are expected to evolve throughout the Contract Term based on business
priorities, technical feasibility, Product Vision, or end-user feedback.
The following is a summary of the overall framework that the Parties shall rely upon for the
delivery and management of the Product/Project Services:
b. Agile Product Development Life Cycle

i. Product Vision. PDSB/ Business Product Owner will establish an overall vision, including
a high-level description of the desired business and end-user objectives and intended
outcomes for the relevant Product(s), which is subject to change throughout the
product specific Work Order Term (the “Product Vision”). The Product Vision is
intended to guide the FPT Development Team to anchor the work they produce to the
intended business outcomes.
ii. EPICs. FPT is responsible for the EPICs and shall work with PDSB/Business to create and
prioritize EPICs to be developed and deployed by the FPT Development Team in
Open
P a g e | 64
furtherance of the Product Vision. The FPT Project Team will document such EPICs in the
Product Backlog.
iii. Product Backlog. FPT shall capture and maintain the product backlog, and work with
PDSB and Product Owner from business to refine the Product Backlog and prioritize
EPICs to support the achievement of the Product Vision. This shall be inclusive of
developing User Stories, or tasks they are broken down into, as applicable, such that
they meet the Definition of Ready. The User Stories will also be prioritized using best
practice like the MoSCoW method.
iv. Sprint Planning. The Scrum master is responsible for facilitating the Sprint Planning
where the Product Owner and the FPT Development Team will participate in preparing
for the upcoming Sprint. The project team determines the number of Story Points to be
allocated to each User Story, revisits the prioritization made during Backlog Grooming,
the Sprint Capacity, and selects User Stories for the sprint. PDSB will agree the scope of
Sprints as advised.
v. Daily Stand-Ups. The Scrum Team will participate in Daily Stand-Ups that is facilitated by
Scrum Master to remove any impediments to progress and allow the team to self-
organize around the highest priority work to be performed, including any necessary
pivots considering the prior day’s work.
vi. Sprint Execution. The FPT Development Team will execute the design, development,
testing, integration, and deployment of assigned User Stories per the Definition of Done.
vii. Sprint Review. The FPT Development Team will participate in a Sprint Review at the end
of every Sprint to present the User Stories that meet the Definition of Done to
demonstrate the increment of value that was created during the Sprint such that the
end user(s) and stakeholders of the Product can see, evaluate, and provide feedback on
the finished work. The Scrum Master will be responsible to facilitate the session, and
Product Owner is responsible for ensuring that all relevant stakeholders are
participating to provide feedback on the completed user stories.
viii. Release and Deployment. FPT Development Team and PDSB team will, as applicable,
engage in Sprint Release / Deployment planning for the release of the User Stories to
production.
ix. Sprint Retrospective.. The Scrum master conducts the Sprint Retrospection along with
the entire scrum team at the end of every sprint to Improve the processes, practices and
tools used in the Sprint. Also, to create a plan for improving efficiency, effectiveness and
quality.
x. Customer Feedback : As per DEX framework, project team will conduct a Project Closure
Survey upon completion of each project. FPT will also conduct a customer satisfaction
survey(CSS) online to collect a satisfaction index(CSI). This would be accomplished
quarterly and at the end of each project executed by FPT. Yearly feedback will be
collected at engagement level from senior leadership.
c. Acceptance Procedures for Deliverables:
 Acceptance of written Deliverables. FPT to submit the deliverables to PDSB/Business.

PDSB/Business shall review and provide feedback or approval for each Deliverable.
PDSB shall notify FPT if it determines the Deliverable is insufficient and describe in
reasonable detail any material deficiencies from the relevant Acceptance Criteria agreed
in the Work Order.
 Acceptance Testing (Software Deliverables). Upon completion of each User Story within
a Sprint, the Software developed for the associated User Story(ies) shall be delivered to
the PDSB end users, as part of the Sprint Review to review the User Story(ies) and to
Open
P a g e | 65
determine whether the User Story(ies) within the Sprint meets the Definition of Done
and is ready for deployment. Testing and acceptance sign off activities will be conducted
and executed.
If a User Story does not satisfy the Definition of Done, the development team shall log
the failures against such User Story for either immediate prioritization and remedy, re-
inclusion into the Product Backlog for the current, next Sprint, or a later Sprint, as
agreed with Product Owner. Causal analysis has to be done for any such cases.
Any efforts expended by FPT to remedy the User Stories that failed to satisfy the
Definition of Done shall be performed as Rework with no additional charge to PDSB.
b. Sprint Progress Aspects.

i. Where FPT cannot achieve the Sprint Deliverables in accordance with the requirements
and reasonably considers the inability to provide the Sprint Deliverables within that
Sprint, FPT will promptly notify PDSB and provide information regarding the causes of
the delay.
ii. If PDSB agrees that the circumstance or cause preventing the achievement of the Sprint
Deliverable(s) is outside FPT’ control, then PDSB will elect one or more of the following:
 That certain Sprint Deliverables will be removed from the Sprint in which case
such Sprint Deliverable(s) will be returned to the Product Backlog; and
 PDSB takes such other action to reprioritize the resources and User Story(ies).
iii. Residual User Stories. As aligned with Product Owner, Sprint User Stories not achieved
in a Sprint will be returned to the Product Backlog for re-prioritization in a subsequent
Sprint.
c. Process Improvement: Based on the nature and scope of work, the practices for each project
would be tailored from the framework mentioned in this document.
d. Project Closure
i. FPT to perform project closure as per DEX process.
ii. FPT to conduct delivery feedback via FPT online form at a set frequency
2.3.5 Frequent Communication

As a pre-requisite of successful Agile Delivery, frequent and clear communication is a must, which
the process can be described similarly as below:
Figure 40: 2.3.5 Frequent communications example
Open
P a g e | 66
2.3.6 In Scope:
 FPT shall adhere to PDSB DEX Process as described above.
 FPT shall use Agile Scrum methodology for all project / product unless otherwise agreed by both
FPT and PDSB.
2.3.7 Out of scope

Out of scope will be defined as per the product/project work order issued as per agreed by FPT & PDSB.
2.3.8 Roles and responsibilities

Roles & Responsibilities of the Product/Project Development Team is as follows but are not limited to
these:
Please refer to 2.1.5 for Roles & Responsibilities of the Product/Project Development Team.
2.3.9 PDSB Obligation:

 PDSB should not ramp down or up significantly (>15% of total GDC FTE OR >100 FTE) within 30
days. If PDSB would want to make such significant resource movements, PDSB would need to
notify FPT at least three months in advance. This is excluding the scenario should FPT didn’t plan
the demand/resource accurately where PDSB provided valid forecast during the 3 months rolling
demand forecast.
 All software required for product development will be provided by PDSB.
 PDSB will provide cloud environment for development and deployment.
 Facilitating session with business owners to ensure completeness and clarity of requirements if
required. PDSB and FPT will jointly review the Solution Proposal and submit it to business for
approval.
 PDSB to facilitate clarifications on queries at every product development stage (as required)
 Ensure participation of PETRONAS-required stakeholders in all Scheduled Meetings, Workshops
and Scrum ceremonies.
 Appoint a Product Owner /suitable SPOC (Single Point of Contact) to facilitate communication
with business and IT users of PDSB.
 Will enable License for ADO test suite for all developers and testers.
2.3.10 Deliverables:
The deliverables, acceptance criteria and milestones will be as per the specific product/project Work
Order.
2.3.11 KPIs/Measurements -
Project Metrices - Please refer to Annexure B, Metrices, Development Related Metrices for details.
Product Metrices - Please refer to Annexure B, Metrices, Development Related Metrices and Product
Metrices for details.
Warranty Period - Warranty is only applicable for fixed price & scope model; it will be for 3 months after
going live unless mutually agreed in the WO.
Open
P a g e | 67
2.4 Application Support & Maintenance Framework
An application Support & Maintenance Framework is a structured approach or methodology for managing
and supporting applications. It provides guidelines, processes, and best practices for efficient and effective
application management. Although AMS frameworks vary, it will follow with below method including four
steps Assessment & Evaluation, Service Design, Service Transition to Operation & Improvement:
Figure 41: Application Support & Maintenance Framework
This application management service framework could be used for applications and products at the end
stage of software development and need maintenance and support service.
After the transition phase, Application Management Service Model will include three support levels:
ü Level 2 - Monitoring, Operation and Support:
o Experienced and knowledgeable technicians assess issues and provide solutions for
problems that cannot be handled by Level 1.
o Level 2 support escalates the incident to Level 3 if no solution is available.
ü Level 3 - Maintenance, Enhancement, and Development:
o Access the highest technical resources available for problem resolution or new feature
creation. Level 3 technicians attempt to duplicate problems and define root causes,
using product designs, code, or specifications.
o Once a cause is identified, L3 decides whether to create a new fix, depending on the
cause of the problem.
o New fixes are documented for use by Level 1 and Level 2.
o Disaster recovery and business continuity.
Following are the activities that could be included in the incident management process.
Open
P a g e | 68
Figure 42: Key Activities for Incident Processing
During AMS Service running, some practical and matrix will be applied to monitor, measure, analyse, and
improve performance.
2.4.1 In Scope
PDSB will provide the list of applications and products at the end stage of the software development
lifecycle and need the maintenance and support service under GDC. The AMS service will be started by
conducting an assessment and knowledge transfer for each application or product as per below process:
Figure 43: AMS Enrollment Process
Product managers and project managers could discuss with the AMS manager to arrange the workforce as
needed and balance the team's workload if a product is in the development phase and requires support
from AMS.
Open
P a g e | 69
Since PDSB provides Customer Service at the L1 level, GDC proposes AMS service on L2, and L3 levels as
below:
Figure 44: Allocations of Support Level
We will utilize the exited AMS tools, which are used by PDSB team, such as:
 Ticket Management System: MyGenie+ or any relevant systems used by PDSB
 Knowledge Base: WSM; MILO (SharePoint site), or any relevant systems used by PDSB
 Service Catalogue
 Self-Service Portal: included some common features and functionalities as below:
o Account Management
o Asset Management
o Email Management
o QR Code 2FA
o User Guideline
In cooperation with PDSB, the GDC will maintain and enhance the above systems. A GDC will develop new
tools, features, and functions based on the demands of the PDSB if they don't already exist.
2.4.1.1Production Support Services
As part of Production Support Services FPT will perform the below activities as specified in the
individual Work Order
a. Monitoring
FPT will be using PDSB monitoring tools like: Dynatrace, ELK, Elastic APM, Amazon CloudWatch,
Azure Monitor, or ServiceNow to identify and resolve application issues before they can
adversely affect critical business processes.
Access to these PDSB applications will need to be provided to FPT so that FPT’s staff would be
able to perform the troubleshooting and analytical tasks efficiently.
b. Availability Management
FPT will collaborate with PDSB and utilize their infrastructure, software, and tools for project
development and management. PDSB has specific Availability Management requirements,
including measuring end-to-end service accessibility and usability within a specified time frame
(%), excluding approved maintenance as downtime. The scope covers applications, Tier 3 and
Open
P a g e | 70
Tier 2 data centers, public cloud, critical components, service chains, and user network sites.
Monitoring data will be sourced from the SolarWinds system. These contributions will help the
GDC achieves seamless service accessibility and reliability within the FPT and PETRONAS network.
Proposed Contributions by FPT:
 End-to-end Service Monitoring: Implement comprehensive monitoring for applications,
infrastructure, and critical components.
 Real-time Alerting: Set up alerts in SolarWinds or other equivalent systems for prompt
issue notification.
 Availability Reporting: Generate performance reports and compliance analysis.
 Capacity Planning: Collaborate on scalability assessments for peak demand handling.
 High Availability Solutions: Design redundancy and failover mechanisms.
 Business Continuity Planning: Develop robust plans for service continuity during
emergencies.
 Availability Improvement: Analyze data to propose strategies for better availability.
 SLA Compliance: Ensure alignment with agreed service levels.
Data Source
No Area Data Source
1 Availability Management SolarWinds
Service Level
Availability Performance Standard Performance Standard
Impact Level on Premise on Cloud Service Window
Severe
Major 99.50% 24x7 (Mon - Sun)
Moderate
Minor
Insignificant 95% 99% 7am - 7pm (Mon - Sun)
Compliance
The availability SLA in respect of the end-to-end critical service for the month is equal or above
the target value.
Service Level Breach

The availability SLA in respect of the end-to-end critical service for the month is below the target
value.
Disclaimer
Service Level only applies to system assets hosted at PETRONAS data center, public cloud and
common infrastructure supported by PDSB. FPT will only be responsible for the software
application side of things, and not the infrastructure unless it’s hosted by FPT. However, FPT is
responsible to work collaboratively with other teams to ensure service uptime remains as top
priority.
Open
P a g e | 71
c. Incident Management by Application Management Service
And below is the service flow for Application management service:
Figure 45: Incident Management
The customer will contact L1 Service, proving by PDSB Team, to report their incident. In case L1
cannot resolve the end-user’s problem, they will go to the MyGenie+ system to log a ticket and
assign to the L2 team to investigate and find the solution for the end user with the functional
support level.
In case L2 also cannot resolve the ticket by the functional level. L2 will escalate and assign the
ticket to L3 Team to find the resolution by technical support level.
GDC will take responsibility for L2 and L3 Support by calling directly to customers to clarify their
incident and what their expectation is. From that, team will find out and propose the optimized
solution at a reasonable time effort with high quality for them.
For product support, L2 & L3 are referring to product squad capacity.
d. Minor Enhancements
When applications/products are transferred to AMS Team, or in long-term development, if they
have requests for minor enhancements, we consider them Service Requests with a small effort of
less than 5 days. If they request a higher workload, the Product/Project Manager will discuss it
with the AMS Manager to request their support, and those tasks are not included in the SLAs and
KPIs for the AMS Team. In short, product SR requires more than 5 days effort will move into the
product backlog supported by Product DevOps Squad, whereas for application it shall treated as
Change request.
e. Release Management
The Process Release and Deployment Management has three main stages, Planning, Release
and Deployment and Closure. This process may be invoked from Change Management Process or
Design and Transition Process.
Open
P a g e | 72
Figure 46: Release & Deployment Process
Application Life Cycle Management scope for the application will be inclusive of and not limited
to regular patching, hot fixes, service packs, bug fixes, remediation of cyber security findings and
version upgrade (minor or major) due to EOL/EOS
The GDC release management shall align with PDSB release management process, guidelines, and
standards.
2.4.1.2Service Automation
FPT will undertake automation efforts with an objective to drive processes standardization,
digitization, optimization to improve productivity and achieve the end customer business metrics.
FPT shall work with PDSB to drive automation as per defined in 2.4.6.4
Figure 47: Service Automation
Open
P a g e | 73
To develop and implement Automation artifacts, FPT will explore and utilize but not limited to PDSB
processes, tools, and technologies.
Figure 48: Automation Tools
1. Service Level Metrics and Performance

1.1. Service Level Methodology and Measurement
Working environment is basing on MyGenie+ or other relevant service platform, FPT shall
retrieve the report from there to measure the effectives and performance of the Application
Management Service team.
Operational efficiency will be tracked and managed through KPI’s that are relevant to your
business, refer to “2.4.6 KPIs/Measurements” section.
1.2. Service Level Metrics Definition

Basing on the current operation and MyGenie+ system, we will define and apply the Service Level
as below:
SEVERITY DEFINITION
S1 Incidents with High Urgency & High Impact
SVIP Incidents impacting VIP
S2 Incidents with Medium Urgency & Impact
S3 Incidents with Low Urgency & Medium-High Impact
Incidents with High Urgency & Low Impact
S4 Incidents with Low-Medium Urgency & Low Impact
Open
P a g e | 74
2. Service Levels Continuous Improvement
KPI, mentioned on “2.4.6 KPIs/Measurements” to help drive continuous improvement of services
to meet priorities will be defined and tracked.
Beside that we also applied some automation process above to reduce the effort for AMS Team
and end-user also retrieves the support on time and right time without delay.
2.4.2 Out of scope

 Level 1 (Help desk/ service desk) support is out of scope.
 Support for the Infrastructure/Hardware platforms, which are not in the scope of SOE - FPT Standard
Operating Environment defined in 2.1.1.2, is out of scope. However, since FPT owns the application
support SLA, FPT is required to work end-to-end with the relevant party to ensure the
application/product services are resumed/recovered in a timely manner.
 Support for the applications, which has not transitioned to GDC, are out of scope.
 Troubleshoot and resolve the issue for 3rd party is out of scope, however FPT is required to work end-to-
end with the relevant party to ensure the application/product services are resumed/recovered in a
timely manner.
 The cost of using any cloud services, and 3 rd party license to accommodate services transition to GDC
unless specified in the Work Order.

Roles & Responsibilities is as follows but not limited to:
Open
P a g e | 75
＃ Role Responsibility range
 Review of estimate and proposal

1 Delivery manager (DM)  Expand issues and risk response and expand operational operations during project
implementation
 Project progress management

 Personnel management
2 Service manager
 Create a report and report/consult to the customer
 Understand and solve problems, issues and risks
 Operational design
3 Operation design team
 Operation migration (training (OJT) on operation and maintenance teams)
 Monitoring: Monitor alerts via tools and procedure (for example: As per
instance/batch restart, etc.), respond to the relevant department and contact the
relevant department
Operation and  Support for routine and regular work (eg: (Data extraction, log backup,
4
maintenance-L 2 team deployment, etc.)
 Service request response (eg: User registration, investigation, etc.)
 Incident management
 Enhancement
Operation and  Bug fixes
5  CR
maintenance-L 3 team
 Problem management
2.4.4 PDSB Obligations

 All hardware, software, and necessary access not in scope of SOE - FPT Standard Operating
Environment defined in 2.1.1.2 - IT Infrastructure required for support and maintenance services will
be provided by PDSB
 PDSB to share the list of existing applications and pipelines with FPT for planning purposes.
 PDSB to provide the necessary inputs and support for FPT to complete knowledge transfer if required.
 AMS will only be engaged as SLA Based / Outcome based model.
 The PDSB should ensure the availability of relevant stakeholders to provide inputs, including relevant
artifacts and the Transition to FPT.
 PDSB to provide detailed Service Request processes and procedures to FPT.
 FPT will need to have sufficient access to Production environment to perform operational support
efficiently.
 In the event an incident routed to FPT without logging the ticket by Level 1 support, Level 1 support
will log such ticket upon advice from FPT.
2.4.5 Deliverables
 Reports and Metrices as agreed in the respective project Work Order including apps availability,
incident, SR performance, RCA, service improvement.
After engagement and receiving the Knowledge Transfer from PDSB Team or Development Team based on
the proposed Application List. It is essential to establish key performance indicators (KPIs) and
measurements to track the performance of AMS Team. We can apply some KPIs as below:
KPI Metric Definition
Open
P a g e | 76
1. Keep SLA Follow the instruction and definition of Service level below (section
2.4.6.1).
2. Knowledge Retention & Follow the instruction and definition of Service level below (section
improvement 2.4.6.2).
2.4.6.1 SLA Management:

A Service Level Definition refers to the PDSB Team as follows:
 Incident Operation Hours (following FPT Malaysia Business Hours): 9:00 to 18:00
 Incident Management System: MyGenie+
 Response time will be counted from the time the incident is notified, and FPT initial response
 Resolution time will be counted from the time the incident is notified and FPT gets adequate
information to resolve the incident.
Please refer to Annexure B, Metrices, AMS Metrices
2.4.6.2 Knowledge Retention & improvement:

Response
Definition Objective Business Performance Unit Frequency
Hours (*) Standard
% resolved tickets are no. of resolved ticket are updated
documented / updated into into KB / total of no. of resolved 90% Upper is better % Monthly
Knowledge base tickets x 100
2.4.6.3 Improve Productivity:

Due to the lack of baseline data, FPT provides the below as reference target based on statistics of FPT
other client’s Delivery Centres.
% improvement vs
DC AMS KPI Metric
Baseline Data (Yearly)
5%
Average ticket resolution time by severity
Average effort spent by ticket 5%

10%
% of reopened incidents
Open
P a g e | 77
10%
% of incidents volume reduced
5%
User satisfaction rate
2.4.6.4 Apply automation process:

Due to the lack of baseline data, FPT provides the below as reference target based on statistics of FPT other
client’s Delivery Centres.
DC AMS KPI Metric Target (Yearly)
Automate top 5 incidents / service request area where 100%

automation is feasible.
% of transferred applications applied automation process. 5%
2.4.6.5 Knowledge Retention & improvement:

Due to the lack of baseline data, FPT provides the below as reference target based on statistics of FPT other
client’s Delivery Centres.
DC AMS KPI Metric Target
% attrition rate of key/core members in team 10%
2.5 Transition Framework

2.5.1 Transition Considerations:
As part of AMS (Application Management Service), transition considerations involve planning and
executing the transition from one service provider to another, or from a development phase to an
operational phase. To ensure a smooth transition without disruptions to application operations, these
considerations are crucial. The following are some key transition considerations in AMS:
I. Knowledge Transfer: Ensure that knowledge is transferred effectively between the existing
service provider and the new AMS team. In this process, information about the architecture,
infrastructure, configurations, known issues, and any other relevant details is documented and
shared. Training, workshops, and handover meetings can be conducted to transfer domain
knowledge and expertise.
II. Documentation and Process Review: Review and update existing documentation, including user
manuals, technical documents such as SRS; System Integration; Detailed Design; Development
Guide; Deployment Guide; Test cases; Test Plan; Knowledge Base, and other relevant documents.
Ensure the documentation is updated and reflects the current situation of the application.
Otherwise, we need to review and update them.
III. Development Environment: Ensure that the new AMS team has access to the necessary tools,
systems, and environments for managing and supporting the application effectively by providing
Account; Source Code; Database; System Integration Environment.
IV. Service Level Agreement (SLA) Transition: During the transition phase, PDSB defined SLAs shall
be preserved. The new AMS team should define its roles and responsibilities, including incident
management, problem resolution, change management, and service request handling. Align SLAs
with the capabilities and objectives of service delivery for the new team.
V. Communication and Stakeholder Management: Provide the list of stakeholders of the
applications for get support, confirmation on source code structure, requirement, and the
external systems.
Open
P a g e | 78
2.5.2 General Approach
Knowledge transfer in application/product transition typically refers to the transfer of information,
expertise, and understanding about an application from one team to another. Providing the necessary
knowledge to the receiving team ensures that the application can be supported and managed effectively.
FPT will work with PDSB GDC team to plan the commencement of individual application transition
activities and timeline.
In general, Projects will be transitioned to AMS team for support, while Products will be continued to be
supported by the Product Squad.
As part of the application/product transition, knowledge transfer can be included in 5 phases:
I. Initialization: Conducting training sessions and workshops is an effective method of transferring
knowledge. They should be scheduled, well-prepared documentation, mentors, and a practice
environment.
II. Knowledge Transition: Proceed with the transfer sessions which cover various aspects of the
application, including its functionalities, use cases, maintenance procedures, troubleshooting
techniques, and any specialized tools or technologies involved. Following the checklist to ensure
the transition has been completed.
III. Knowledge Retention: Facilitate Q&A sessions, seek clarification, and gain a deeper
understanding of the application. The receiving team should review and update existing
documentation related to the application to ensure that the documentation accurately reflects
the current state of the application.
IV. Application Shadowing: The receiving team will take the ticket from MyGenie+ System to resolve
under mentor’s review and approval. The work result should be reviewed by weekly to provide
the additional knowledge if need. And this phase shouldn’t apply Performance/SLA evaluation.
V. Steady State: The receiving team can resolve the ticket by themselves and take ownership of the
applications, from that team can be applied performance and SLA evaluation. Based on that, the
team will have a process improvement and optimization plan.
Figure 49: improvement and optimization plan
Open
P a g e | 79
Transition Time:
We define the complexity of application based on the application/product team size and the majority of
GDC on the transferred application/product.
Transition Time
Complexity Levels Team size Majority Not Majority
Handover: up to 3 wd Handover: up to 5 wd
Low Scrum Team ( < 5-9 FTE )
Shadowing: up to 5 wd Shadowing: up to 10 wd
Medium 2 Scrum Team ( 10-20 FTE )
High > 20 FTE Basing on the evaluation proposal
Note: Majority: >= 60% FTE from FPT
Transition Cost:
- Handover:
o Receive the transfer/training knowledge, document from the current team to the received
Team. For example, handover workshops, trainings, etc.
o Handover phases: “Knowledge Transition”, “Knowledge Retention”
o FPT bears cost.
- Shadowing:
o Shadow team takes responsibility for burning tasks under the supervision of the transfer
team. This will mean FPT deploys a certain number of personnel to shadow the existing
team.
o Shadowing phases: “Application Shadowing”
o PETRONAS bears cost.
Transition check list as following:
N
Application Transition Checklist
o
1 Has training and knowledge transfer been completed? (For more than 1 section training)
2 Class Agenda need to go through all.

3 Has the documentation relating to maintenance of the product(s) or service(s) been delivered; need to be
confirmed by PDSB and FPT
 HO1 (General Project Information);
 HO2 (Technical Handover Document);
 HO3 (User Manual and Training);
 Development Guide;
 Deployment Guide
Open
P a g e | 80
4 Has team receive transfer of database model from PDSB (Access database)?
Access to Source code:
 All Source code relating with document training
5  Build with no error
 Established connection to database
6 Test case (Test case of application created before for understanding functional)
Q&A Clarification
7
Common Issues List; Known Issues List
8 Access the application to Staging environment
9 Process receive/resolve/release incident or CR (In case for application special)
2.5.3 In-Flight Projects & Product
In order to handle the transition and handover/takeover of the inflight project/product efficiently, we can select
the appropriate approach based on the majority of FPT factor. “FPT has majority” means 60% of personel in the
project/product are from FPT.
Following are the four steps we will take with the project/product in which FPT has majority ownership:
Figure 50: Steps to Take Ownership
Otherwise, we need to do some additional activities for evaluation and take more time to prepare a proposal:
Open
P a g e | 81
Figure 51: Steps to Take Ownership (alternative case)
Our decision regarding the time for transition will be based on the complexity level of the project, which is
determined by 2 factors: team size and majority status:
Transition Time
Complexity Levels Team size Majority Not Majority
Low Scrum Team ( < 5-9 FTE )
Medium 2 Scrum Team ( 10-20 FTE )
High > 20 FTE Basing on the evaluation proposal
Note: Majority: >= 60% FTE from FPT
Transition Cost:
Evaluation & Proposal:
o FPT bears cost.
Handover:
o Receive the transfer/training knowledge, document from the current team to the received
Team. For example, handover workshops, trainings, etc.
o FPT bears cost.
- Shadowing:
Open
P a g e | 82
o Shadow team takes responsibility for burning tasks under the supervision of the transfer
team. This will mean FPT deploys a certain number of personnel to shadow the existing
team.
o PETRONAS bears cost.
2.5.4 Roles and Responsibilities
Below are some of (not limited to) the roles and responsibilities supplementing the ones described in section 2.1.5
＃ Role/Teams Detail
 Review of estimate and proposal

Delivery manager
1  Expand issues and risk response and expand operational operations during project
(DM)
implementation
 Project manager
 Solution architect
2 Assessment team  Technical lead
 Business Analysis.
 SWE and DE roles

3 Development team
2.6 Tools & Best Practices

2.6.1 Best Practices* in Delivery Processes
FPT internal quality framework/processes will be followed for project delivery. In addition, PDSB DEX
framework as applicable will be adhered to.
As a display of partnership spirit, below is an example of how DEX can be adapted to enable Agile
“Fail Fast” methodology for PDSB reference:
Open
P a g e | 83
2.6.2 FPT Tools and Delivery Systems
During FPT years of operation, FPT created a number of applications to better manage and improve
productivity and efficiency.
In the spirit of partnership, FPT is providing awareness on some of the tools FPT is using, and is
open to bring them to the table to help PDSB improving the same.
FPT will first use PDSB internal systems as now, but will start to propose new tools usage no later
than the end of year 1.
As a start, FPT will be bringing ADM into the GDC to manage GDC projects / products.
Figure 52: Tools recommended by FPT.
2.6.2.1 Agile Delivery Management (ADM)
Open
P a g e | 84
Agile Delivery Management (ADM) is an Agile project management tool pulling data from ADO, a
backlog management software. It helps teams standardize Agile delivery, processes, and leverage
Agile best practices and is designed to support Agile frameworks such as Scrum, Kanban, and SAFe.
ADM is a dynamic one-click Report Generating tool that allows Scrum Masters to effectively identify
insightful data through graphical visualization and monitor data, metrics of program delivery.
FPT will work with PDSB to comply with PETRONAS security governance.
As part of FPT GDC investment, only all projects & products managed in the GDC will be using this
ADM tool. Related PDSB personnel will be provided access to the tool for their project & product
upon FPT approval.
Agile delivery is a software development approach that emphasizes flexibility, collaboration, and
iterative development to deliver high-quality products efficiently. In an Agile framework, work is
divided into smaller, manageable units called iterations, typically 2 weeks. Each iteration follows a
cyclical process that can be divided into three key phases: Plan, Execution, and Closing. Our ADM
tool is connected to Rally to pull backlog information and its status then visualize to reports,
dashboards. ADM also support to input information that the Scrum Master and the team MUST DO
and SHOULD DO to have a successful iteration.
Open
P a g e | 85
Figure 53: Key phases of Agile Delivery
Figure 55: Detailed components in ADM tool
1. Iteration Plan:
During the planning phase of an iteration, the Agile team comes together to determine the goals,
establish capacity of the team by planning backlog, velocity, task estimation, quarter release plan, demo items,
follow-up actions from previous retrospective meeting and all that information are auto pulled from Rally, user
input to our Plan Report. Scrum Master are also able to input day-off plan of individual members in iteration and
highlight, risks, blockers or dependencies to stakeholders who will receive this report. After finishing input planning
info, Scrum Master can export report in image or PDF to send to stakeholders in one click.
Open
P a g e | 86
Figure 56: The Team Planning Report in ADM
2. Execution (Sprint Monitoring):

The execution phase is the heart of the iteration, where the development work takes place based on the
plan created in the previous phase. ADM collects key metrics and useful information the visualize into one page,
Scrum Master and the team can review it daily and take actions immediately. Any compliments, recognition, items
went well, should have done better, actions of the team/individual are able to track and note immediately instead
of waiting to the end of iteration.
Open
P a g e | 87
Figure 57: The Team Planning Report in ADM
3. Closing (Iteration Report)

The closing phase of an iteration focuses on evaluating the work completed, team’s performance during
the iteration and continuous improvement actions for the next one. The iteration report is a vital component of
the Agile methodology, providing a comprehensive overview of the work completed during an iteration. It serves
as a communication tool to update stakeholders, team members, and other interested parties about the progress
and outcomes of the iteration. The iteration report typically includes the following key elements:
 Highlights: Key accomplishments, successful outcomes, achievements, issues encountered: A discussion of
any challenges, obstacles, or impediments the team faced during the iteration, along with how we were
addressed or mitigated.
 Iteration Summary: metrics and progress of the team, individuals are visualized via charts Utilized Capacity,
Team Delivery, Velocity, Cumulative Flow Diagram (CFD), Iteration Burndown, Burnup, Work Committed vs.
Delivered, Work carried-over, etc.
 Quality Report: Test execution, test coverage, a summary of defects or issues identified and their status,
such as resolved, pending, or deferred. defect by state, by environment, root cause analysis and
Resolution, etc
 Effort and Work Distribution: Details on the effort expended by team members, highlighting their
contributions and collaboration.
 Sprint Review/Demo Feedback and compliments: Stakeholder Feedback: A summary of feedback received
during the sprint review meeting from stakeholders, clients, or end-users. Compliments, achievements of
the team and individual are also noted in the report
 Retrospective Insights: Key takeaways and insights from the sprint retrospective meeting, including
identified strengths, areas for improvement, and action items for the next sprint. ADM also support for
voting statistics, we recognize best performers and kudos to them.
Open
P a g e | 88
Figure 58: A Sample of Team Report
4. Team Overview
ADM have an overview page for each Agile team serves as a central hub for accessing important metrics
and data that provide insights into the team's performance, progress, and overall health. This page is designed to
be easily accessible and comprehensible to both team members and stakeholders. Here's how such a web page
might be structured and what type of metrics and data it presents:
 Team Introduction: to collaborate between teams, each team should provide their own information
about the business, what the team do, technical stacks, keyword, etc. ADM will link those relationships
and connect them together in an intuitive way
 Quarter Release Plan: visualize quarter’s features of the team and their status, size
 Metrics and Trends
 Stakeholder Register
 Top Performance & Compliments
Open
P a g e | 89
Figure 58: A Sample of Team Report
5. Ownership
An ownership evaluation tool for a team is a set of criteria that assesses and measures the level of
ownership and accountability demonstrated by team members toward their work, responsibilities, and the team's
goals. This tool aims to promote a culture of ownership, engagement, and proactive collaboration within the team.
Here's how such ADM’s ownership assessment be designed:
 Criteria and Categories: Define specific criteria or categories that contribute to ownership within the
team. These could include aspects like Strategy & Roadmap, Discovery & Continuous Planning,
Collaborative Delivery & Operational Excellence, Sustainable Success and Customer recognition.
 Scoring System: Create a scoring system that allows Scrum Master to rate their team based on each
criterion. We use the descriptive labels mapping with levels, the Scrum Master just choose the suitable
option for their team.
 Aggregated Scores and Visualizations: Calculate and aggregate the scores for each team based on the
assessments. Visualize the results using charts, graphs and heat map to provide a clear overview of
ownership strengths and areas for improvement.
The ownership evaluation tool should be adaptable to the team's needs and culture. It should promote
open and respectful discussions, foster a growth mindset, and ultimately contribute to a more accountable and
empowered team.
Open
P a g e | 90
Figure 59: The Ownership report visualization
6. Reports and Utilities
Reports and utilities are essential features that provide visibility, insights, and management capabilities
for management team throughout. These components assist teams in tracking progress, making informed
decisions, and optimizing their Agile processes. Here's how reports and utilities are designed for ADM tool.
Figure 60: Organization Chart, Iteration Report Summary and Program Overview
Open
P a g e | 91
2.6.2.2 Contract Resource Management
A power tool to manage all contracts and resource information in Program. Transparent program
information to all stakeholders. It manages from very early of project such as from prepare SoW, sign
contract, staffing, onboarding, developing till closing. Not only manage project, people information but
also finance, monthly invoice and helps to reduce operation time and work handling time significantly.
Figure 61: CRM’s product components
1. Opportunity Management:
This is a specialized tool designed to help the program not only store opportunities and projects
information but also operate, manage and collaborate with other stakeholders by sharing, exporting monthly
resourcing and billing info.
Figure 62: Opportunity Management
In each opportunity, we can know many aspects of an opp or project

 General information
 Budget models: role, rate, % allocation, duration, plan start/end, etc.
Open
P a g e | 92
 Member assignment: who are assigning to this project, detailed assignment and other information related
to each resource.
 Billing detail month over month, statistics between Plan and Actual
 Summary about staffing information and status of background check.
2. Staff & Subcontractor Management:

Staff and subcontractor management is a critical aspect of project and resource management within the
Program. It involves the coordination, allocation, monitoring, and optimization of both internal staff and external
subcontractors to ensure that projects are executed efficiently, deadlines are met, and work quality is maintained.
Figure 63: The list and detail of staff management screen
Here's a comprehensive overview of staff and subcontractor management:

 Staff information
 Resource assignment: Assigning appropriate staff members to projects based on their skills, expertise,
availability, and workload.
3. Reports
Currently, tool support many reports for management purpose such as
 Customer
 TCV (Total contract revenue)
 Monthly revenue
 Sourcing report
 Staffing summary
 Resource bench
 Resource offboard
 Background check
 Member assignment
 Monthly invoice detail
 Monthly Man-month detail.
4. Dashboard
Open
P a g e | 93
The dashboard provides a central hub for users to access key project and resource-related information at a glance.
It offers a visual and informative overview of various aspects of staff overview, resource allocation, opportunity
status, business, key metrics and more.
2.6.2.3 Contract Resource Management
A power tool to manage all contracts and resource information in Program. Transparent program
information to all stakeholders. It manages from very early of project such as from prepare SoW, sign
contract, staffing, onboarding, developing till closing. Not only manage project, people information but
also finance, monthly invoice and helps to reduce operation time and work handling time significantly.
Open
P a g e | 94
Figure 54: A Sample of Program Report
Figure 55: A Sample of Opportunity Managing
Open
P a g e | 95
Figure 56: A Sample of Resource Managing
2.6.3 PDSB Tools and Delivery Systems
2.6.3.1 Project Management

 FPT will use PETRONAS Project Management Workbench (PMW) for managing project lifecycle
within PETRONAS.
2.6.3.2 Product/Application Development

 Agile project management tools would be Azure DevOps.
2.6.3.3 Application Support & Maintenance

 The tools used for Application Support and Maintenance processes is as listed below, but not
limited to:
 Solarwinds and MyGenie+/Service Now
 Data/Reports from MyGenie for SLA calculation and reporting for governance purposes
 Notifications would be enabled by the tool and would be send to GDC AMS mail group.

FPT GDC Core team will work with PDSB on the tools and best practices.
2.6.5 In Scope
 Tools that are currently used by PDSB.
 FPT will provide recommendation on potential tools changes/ improvements at appropriate time,
ADM tool will be in use on Day 1.
Open
P a g e | 96
2.6.6 Out of Scope
 All FPT internal tools usage without cost unless agreed by FPT Leadership.
2.6.7 PDSB obligations

 All tools and necessary access required for product/application development and Application
support and maintenance services will be provided by PDSB.
 PDSB to walkthrough FPT on all tools relevant for the respective teams. FPT shall arrange the
knowledge acquisition and training with the relevant authorized training providers if required.
 PDSB to notify FPT team in case of any change in tools proposed as per the Work Order and
PETRONAS practices.
 For the abovementioned, PDSB shall provide training to FPT limited to internal-developed tools.
2.6.8 Deliverables
1. ADM Tool for GDC managed Projects & Products.
Please refer to Annexure B, Metrices, Tools and Best Practices Metrices for details.
3. Governance Framework
 PDSB and FPT will ensure the program governance implementation at strategic, Tactic & operational
levels. To facilitate effective management and control, the following communication model will be
established as per governance framework
 Daily/Weekly meetings between FPT and PDSB project teams;
 Monthly management review between FPT and PDSB stakeholders.
 Quarterly executive review between FPT and PDSB executives
 FPT Organization chart will be as defined in 2.1.5
GDC Governance Structure
FPT Software Malaysia CEO

DC Lead
DC Lead
Head of Delivery
Delivery Manager
Team Lead
Product Manager
Project Manager
Critical Roles
Figure 57: GDC Governance Structure
Open
P a g e | 97
Open
P a g e | 98
4. Time & Material, Capacity and Fixed Price Model
Figure 58: Engagement Models
1. Time & Material Model

FPT understands that PDSB may need resources on an ad hoc need basis and is willing to provide
resources on a time and material basis. FPT requires to follow the below process for time and material
based engagement. However, this practice should be kept within 20% of total engagements.
 PDSB will provide FPT 3 months rolling projection of the FTE requirement along with skillset and
years of experience.
 FPT will select suitable resources based on FPT rigorous selection process.
 FPT will provide resources based on agreed rates as per contract.
 PDSB shall interview the resources before resource acceptance.
 PDSB shall onboard the selected resource for their requirement and provide purchase order.
2. Fixed Price Capacity Model

FPT will develop, implement and support products in Fixed price capacity model. The price for product
development will be based on the DevOps squads as detailed in the individual work order.
 FPT will finalize suitable resources based on FPT guidelines for executing each of these projects.
FPT will share the profiles of key resources for strategic projects identified by PDSB and will be
discussed during the monthly cadence.
 PDSB shall onboard the finalized resources and provide access to all required hardware, software
and infrastructure as applicable for the project
 FPT will execute the project as defined in SoW, in collaboration with PDSB.
 Only critical members will open for interview selection process while the other members are
selected by FPT.
3. Fixed Price Scope Base Model

FPT will develop and implement new projects in Fixed price model. The price for the projects will be as
detailed as per the individual work order. This model is applicable for projects where PDSB/Business is
confirmed with requirements, as every change after project start will be subjected to Change Request
(CR).
Open
P a g e | 99
Open
P a g e | 100
5. Contract Change Management – Change Request
Either Party may request a change in the scope of the project but no such change shall be effective and
binding unless such changes are documented in a change control document and signed by both parties.
If PDSB desires to propose a change in a Work Order, PDSB shall deliver a change request to FPT in writing,
describing in changes proposed. Promptly following FPT’s receipt of the change request, FPT shall submit a
written change order proposal to PDSB. If FPT desires to propose any change, FPT shall submit to PDSB a
written description of the change in a form of proposed change order for PDSB’s review and approval. Any
change order document prepared by the parties shall include, among other items, an estimate of additional
charges to PDSB, if applicable, for the modified services, and additional software or other material required to
implement the change and any expected impact to the project schedule or service levels under the Work
Order.
On PDSB’s written approval of the change order document submitted by FPT, the parties shall sign the change
order whereupon the Work Order shall be deemed to have been amended by the change order. No change to
any Work Order shall be binding on the parties unless the change order has been signed by authorized
representatives of each party.
The process will include following steps but not limited to of which the processes should align with PDSB DEX
framework:
a. Register Request for Change
 A change request is received from a Change initiator. Based on the change request, a change
record is created by Change manager, Element owners or Change coordinator.
b. Assess Change Request
 The Element owners, Change manager, or Change coordinator performs an assessment of
the change impact, associated risks, priority and required resources.
 If needed, other subject matter experts may be involved.
 Assessment information is added to the change record.
c. Review and Approve the change
 The Change authority will review the change record and provides authorization based on the
assessment of risks, cost and timeline. If the change is not approved, it will be further
deliberated with the relevant stakeholders.
d. Create Change Plan
 Authorized changes are planned, included:
- Change schedule.
- Resources required.
- Back-out plan if required.
- Communication plan with interested parties.
e. Implement and Control
 The change should be implemented as scheduled.
 The progress and status of change must be controlled and report.
 If the change result is unsuccessful, back-out plan must be invoked to restore.
 If the change is successful, Change Manager informs result to interested party.
f. Review and Close
 After the change is complete, or if it fails to be completed in time, an agreed authority
reviews the change.
 Related information to this change must be updated.
 Change review reports should be made and sends to interested parties.
 Close the change when all required actions are completed.
Open
P a g e | 101
Open
P a g e | 102
6. GDC Contract Transition First 6 Months High Level Plan
GDC
Begins
GDC
Begins
Figure 597: High Level 6 Month Plan
Figure 57 shows high level plans for the GDC setup and 6 months transition of the inflight and support. FPT and PDSB shall work collaboratively to meet the
target timelines.
Open
P a g e | 103
SIGNATORIES
For and behalf of For and behalf of

PETRONAS Digital SDN BHD FPT Software Malaysia SDN BHD
Name: Name:
Designation: Designation:
Date: Date:
Open
P a g e | 104
Annexure A: Project Specific WORK ORDER/CHANGE ORDER Template
i- WORK ORDER TEMPLATE
Open
P a g e | 105
ii- CHANGE ORDER TEMPLATE
Open
P a g e | 106
Annexure B: Metrices
This addendum delineates the assorted metrics applicable to the Global Data Center (GDC). The primary objective of these metrics is
to establish quantifiable criteria for evaluating the GDC's performance. Periodic assessments of the metric scores will be conducted
collaboratively by PDSB and FPT, aimed at identifying and substantiating areas primed for enhancement.
DC Level Metrices
Category Metric Description Target Note
Keep important resources for FPT work with customer to define who are
GDC. the core team members
Core team retention 95%
= core team member at the end
of year / total core team of year
Resource Fulfillment rate = Just measuring on common skill/
Number of ontime staffing/Total Technology.
Resource Fulfillment 95%
resource requests
rate
FPT expect to successfully staffing
Customer to share resources ramp up plan
all resource requests, in some
and involve FPT right from the beginning
cases due to some reasons, we
of the opportunity.
may miss expected timeline.
T&M Only
Resource pool Build resource for ramp up plan. 5% ~10% of total deployed personnel Actual number will be defined base on
Need customer provide roadmap resource plan and opportunity pipeline .
and plan resource for 1 year.
Busy rate Total Allocated Headcount / Total 90% Exclude resource pool
HR
Billed Headcount * 100%
Knowledge retention 100% of applications developed 100% for new projects. Document Quality is also important (eg.
People Development
by FPT have documents (business For existing projects, customer and fpt Clear information, accuracy of
logic) useable to train new to discuss information, timeliness, etc) à rating by
members project members (4* up )
Training Foundation Foundational training like basic 100% GDC member deployed will be
tech, policies, ISMS, Processes, trained
Tools. Have quiz/exam after
training.
Project Knowledge Project Knowledge related like 100% GDC member deployed will be
DevOps, Project Background, etc trained
so that members do not go in
empty handed.
Open
P a g e | 107
Certificate Technical certificate At least 1 industrial recognized Year 1 – 100 members Certified. Certificates which are directly applicable
certificate for identified GDC Year 2 – 200 members Certified. to their roles in GDC, for example and not
members. Year 3 – 300 members Certified. limited to:
 Udemy Certifications
 Azure Cloud
 AWS Cloud
 OutSystem
 Mulesoft
 .NET
 Javascript Frameworks
 ETL Tools
 PMI
 PSM
 Amazon Web Services (AWS)
Certified Data Analytics
 Microsoft Certified Azure Data
Engineer
 Google Professional Data
Engineer
Timeline Timeliness 1. Deliverable is delivered on-time 95% FPT will not be responsible wholly or
if Actual release date <= Planned partially caused by any situation(s) outside
released date. FPT control. For example, and not limited
- OR Actual release date<= Re- to Non FPT managed Infrastructure,
Planned release date but project Missed commitments of PETRONAS
has reason for Re-plan such as: employees, etc.
+ Customer delay providing the Release mean Go Live and Milestones
device/input data (source code,
design, test case, test
environment, …)
+ Customer delay confirmation of
requirement.
+ Customer change requirement.
2. Total deliverables need to be
delivered up to the date of metric
calculation
3. Average timeliness of all
Delivery
projects in GDC
Time to start project from WO 2 weeks Customer to share resources ramp up plan
issuance and involve FPT right from the beginning
of the opportunity.
Open
P a g e | 108
Quality Defect Rate Total No of Defects of products 1.5 - 13 (Defects/MM) 1.5 – 13 Defects / MM are for
/Product size “Maintenance” – “New Development”
1. Total No of Defects of a projects respectively
product exclude bug from code
scan activities
2. Product size
Note:
Product size could be = Effort
usage (MM)
3. Average Defect Rate of all
projects in GDC
Leakage No of Defects detected after 0.05-0.2 (Defects/MM) Fix within one month and FPT bear cost.
delivery for acceptance
test/review of a product / Total FPT will not be responsible wholly or
effort usage partially caused by any situation(s) outside
Average Leakage of all projects in FPT control. For example, and not limited
GDC to Non FPT managed Infrastructure,
Missed commitments of PETRONAS
employees, etc.
Productivity Product size/Total Actual Effort increase 10%/year
Usage
1. Project size: Project can select

the any the unit of measure size
2. Total actual effort usage
3. Average productivity of all
projects in GDC
Onboard/Offboard All new comers must pass 100% Onboard/Offboard checklist will be
checklist onboard. Process to defined and get confirm from customer
offboard employee need to be before using
completed after offboard date (in
compliance with offboard
checklist)
Process compliance Measure the compliance of 100% project complied
Verification (Project) project activities as with the
defined
rule/standard/process/regulation.
As per PDSB’s DEX framework

Process
Open
P a g e | 109
System Availability A time frame when an end-to- Severe and major impact service 99.50% 24x7 (Mon-Sun) FPT will adhere to PDSB SLA.
end service accessibility and
usability according to its
Moderate and minor impact 95% 7AM-7PM (Mon-Sun) – On- FPT will only responsible for apps &
specifications
service Premise solutions that FPT has control over. For
(Measured in %). Approved
99% 7AM-7PM (Mon-Sun) – On-Cloud example, issues caused by PDSB
scheduled maintenance is not
infrastructure, or caused by PDSB
considered as service
personnel, will be out of scope.
downtime
Change The process responsible for Change Success Rate: Percent of 97%
FPT will not be responsible wholly or
management controlling the life cycle of all successful change implementation
partially caused by any situation(s) outside
changes – The addition, for central and region
FPT control. For example, and not limited
modification or
to Non FPT managed Infrastructure,
removal of anything that could
Missed commitments of PETRONAS
have an effect on ICT services,
employees, etc.
in the production environment.
FPT & PDSB will revisit the target for every
Incident Restores a normal service Incident Response Time: Time Service Level vs Hours vs Performance project/ product to align with the actual
Management operation as quickly as possible taken to respond and update the Standard numbers, and come up with plan together
and to minimize impact on incident ticket to a different S1: 0.5 vs 95% to meet the defined target.
business status after ‘Assigned’ from S2: 2 vs 90%
operations, thus ensuring the date/time ticket is created. S3: 3 vs 90%
best possible levels of service S4: 4 vs 90%
quality and availability are SVIP: 1 vs 90%
maintained. Incident Resolution Time: Time Service Level vs Hours vs Performance
Incidents that cannot be taken to resume a disrupted Standard
resolved quickly by the service service upon logging. Provision of S1: 4 vs 95%
desk will be assigned to a S2: 6 vs 90%
relevant service workaround for the disrupted S3: 8 vs 90%
provider within GDC service constitute incident S4: 12 vs 92%
closure. A stop clock will be SVIP: 6 vs 95%
applied
due to certain criteria.
Application Web based application response 5 seconds

Response Time time, reported by SolarWinds
IT Infrastructure
Open
P a g e | 110
Request Accepts and registers an Number of tickets resolved within 95%
Management operational service request targeted time/ Total of resolved
and directly handling it tickets)*100
according to the agreed
resolution time.
Open
P a g e | 111
Development Related Metrices
Norm
Metric Measure Objective LSL Target USL Unit Frequency Note
Agile Metric
Teams that track story
points can measure how
many points a team can
retire within a work
sprint. The team can
then use this to estimate
how long future projects
will take to complete. If a
project is worth 30 story
Velocity Total point accepted Point by Sprint - Target will be defined after 2 sprints. For predicting future
points, and the team
typically retires 10 story performance, use the average of the two previous sprints.
points in a 2-week sprint,
they know it will take
approximately three
sprints, or six weeks, to
complete. Average # of
story points a team has
retired per sprint
# Stories accepted/
total committed Tracking # Stories
Any abnormal trend will be analysed & take improvement
% Stories accepted Stories. (Exclude accepted/ total 90 95 100 % by Sprint
actions. Exclude stories pending due to dependency
stories pending due committed Stories
to dependency)
Sprint Productivity Total point Tracking member -- Point by Sprint Target will be defined after 2 sprints
completed/ >team productivity, it /
Engineering effort/ measures how many Mans
sprint point a member -->team print
could burn in within a
work sprint. This
performance baseline
will help us to do velocity
planning for various
Open
P a g e | 112
scrum team size.
It is measured by the
Total card or ticket
Throughput number of finished tasks Ticket Monthly Target will be defined after 2 months
accepted
each sprint
It is to find out how
Assuming PDSB ADO has the mechanism to obtain this data.
Number of times the many big a sprint
Sprint Volatility % By Sprint This is to be recorded and measured, as input for decision
scope has changed potentially need to be
making process later on at project steering committee.
abandoned
Tracking performance - SPI > 1, team ahead schedule with good performance
Total completed
SPI (Schedule index, total throughput - SPI <1, team behind schedule that need to speed up
tickets/ Total 90 95 100 % Monthly
Performance Index) actual completed against In Jira, they are tickets; in ADO, they can be Epics, User Stories
committed tickets
committed plan or Tasks.
Testing Metric
Total test cases Pass
rate
Note: Pass Rate is to
ensure the
Automation scripts
are reliable and
should pass while
getting executed.
Test Pass Rate
However, when these End of
(Automation 100 %
scripts get executed, Release
Regression)
these scripts will
identify the defects
and those have to be
fixed by development
team.
*Justification to be
provided for any
deviation
Coverage against plan
for Regression
automation
Test Automation *Justification to be
Coverage provided for any End of
100 %
(Regression Test deviation. All Release
Suite) dependencies for test
automation should be
resolved as pre-
requisite
Test cases executed
End of
% Test Scope against planned test 100 %
sprint
cases in each sprint.
%Test Pass Rate a) Overall Total test 95/10 End of SIT a) 95% = Total test cases Pass rate
%
(Manual (SIT cases Pass rate 0 & End of b) 100% = Test cases with Critical and High functionalities
Open
P a g e | 113
UAT
b) Test cases with performed
&UAT)) Critical and High before
functionalities productio
n release
Number of test
cases / scenarios
which are covered
during System
System Regression End of
Regression testing 100 %
Test coverage Release
(Manual)
*Justification to be
provided for any
deviation.
Quality Metric
Open defects before

deployment to UAT & Open defects before deployment to UAT
Production a) Critical and High: 0%
respectively b) Medium + Low: <=5%
Defect Severity (SIT
SIT & UAT will % Monthly
& UAT)
happen outside the Open defects before deployment to Production
sprint cycle. UAT will a) Critical, High & Medium = 0%;
start on completion of b) Low = <=5% with conditional signoff from users
SIT
Total number of defects detected in UAT should not be more

Calculated as
than 15% of total defects in the release
((number of defects
detected in UAT)/
(number of defects Condition 1: if total number of defects in a release is<= 30
Defect Leakage 15 % Monthly
detected in UAT + Critical: 0%, High: 5%, Medium: 15%, Low: 30%
total defects detected
in SIT) *100 per
Condition 2: if total number of defects in a release is > 30
release
Critical: 0%, High: 5%, Medium: 10%, Low: 20%
Open
P a g e | 114
Critical - maximum 1 day
Defect Aging Time span between
High - maximum 2 days
(SIT/UAT) in defect detection and Days Monthly
Medium - maximum 3 days
business days defect fixing
Low - maximum 4+ days
Defect Leakage %
Formula: ((number of
Defects detected in
prod) / (number of
Defects detected in
Post-delivery prod + total Defects End of
0% critical, 1% High, 5% Medium + Low
Defects detected in Release
development
[UAT+SIT])) *100
Applicable for stories
that are moved to
production
DevOps
Deployment Percentage of The desired deployment Higher is better.
Success Rate successful success rate should be as Deployment success means successful deployment to
Project
deployments close to 100% as possible Staging / Pre Production environment.
Target to be defined after 3 deployments
FPT and PDSB will
define quality gate.
Sonar Cloud Quality Need plan effort for Ensure quality of source
Project Follow PDSB standards
Gate team to implement code
this. Apply for new
project.
Team Satisfaction
Customer satisfaction
Team Satisfaction in scale from 1 to 10 Customer satisfaction in Every 2
7 Score
Score follow NPS scale from 1 to 10 months
methodology
Measures the Total point of customer

Customer satisfaction of survey point End of
85 90 100 Score
Satisfaction Survey customer Note: project
requirements. 1. Max is 100, Min = 0
Open
P a g e | 115
Product Metrices
Norm
Metric Measure Objective LSL Target USL Unit Frequency Note
User Adoption
Product Adoption is
defined as the percentage FPT & PDSB will revisit the target for every
of total active unique project/ product to align with the actual
60 80 100 % Quarterly
users against the = (Number of Active numbers, and come up with plan together to
addressable target user Users/Target Users Number) meet the defined target.
User Adoption Rate base *100%
Tracking the number of Count number of logged ticket (error, bug)

software errors, bugs, or = Number of bugs founds by and crashes are linked with Incident
End User Bug Reports crashes helps assess the user for each month ( after 3 5 8 Number Quarterly Management Tracking
product's stability, warranty time) We will revise the target after 3 months base
quality. on historical data.
Customer Satisfaction
score (CSAT) rating
indicates how well the
products meet
= Sum of all score values/ We will revise the target after 3 months based
CSAT Average expectations. The CSAT 3.75 4 4.25 Number Monthly
Total number of responses on historical data
survey is one simple
question with a scale of 1
to 5 to measure the
answers.
NPS = (total promoters - total

detractors)/ total survey
responses*100
Net Promoter Score is the
FPT & PDSB will revisit the target for every
percentage of customers
NPS: On a scale from 0 to 10, project/ product to align with the actual
NPS rating their likelihood to 60% 70% 80% % Quarterly
how likely are you to numbers, and come up with plan together to
recommend our service
recommend this meet the defined target.
to a friend
product/company to a friend
or colleague
Open
P a g e | 116
Promoters (score of 9 and
10)
Detractors (score of 0 to 6,
included)
Passives (score of 7 or 8)
AMS Metrices
Frequen
Item Measure Objective Target Unit
cy
1. Incident Severity SLA
Response Resolution
Severity DEFINITION
Business Hours Performance Performance
Business Hours
(*) Standard Standard
Reach President level, the whole (Responsed; Resolved Ticket) /
S1 0.5 100% 4 95% % Monthly
company cannot operate. Total ticket x 100
Come from high level: Head of (Responsed; Resolved Ticket) /
SVIP 1 95% 6 95% % Monthly
Department. Total ticket x 100
Not able to operate, has impact to (Responsed; Resolved Ticket) /
S2 2 95% 6 95% % Monthly
others. Total ticket x 100
(Responsed; Resolved Ticket) /
S3 Impact to the whole department 3 95% 8 92% % Monthly
Total ticket x 100
(Responsed; Resolved Ticket) /
S4 Individual impact only 4 95% 12 95% % Monthly
Total ticket x 100
2. Knowledge Retention
no. of resolved ticket are
% resolved tickets are documented /
updated into KB / total of no. of 90% Upper is better % Monthly
updated into Knowledge base
resolved tickets x 100
(*) A Service Level Definition refers to the PDSB

Team as follows:
 Incident Operation Hours (following FPT Malaysia Business Hours): 9:00 to
18:00
 Incident Management System: MyGenie+
Response time will be counted from the time the incident is notified, and FPT initial
response
Resolution time will be counted from the time the incident is notified and FPT gets
adequate information to resolve the incident.
Continuous Improvement Metrices
Open
P a g e | 117
Item Metric Target (Annually) Note
1 FTE Productivity 3 – 5% Annually
2 Application Stability 3 – 5% Annually
3 Reduction of similar business projects across the 5 – 10% Annually

group
4 SP Ageing 3 – 5%
5 Ticket Resolution by Severity 5%
6 Average effort spent by ticket 5%
7 % reopened incidents 10%
8 % incidents volume reduced 10%
9 User Satisfaction Rate 5%
10 Top 5 incidents / service request area where 100%

automation is feasible
11 % of transferred applications applied one or more 5%

automation process
12 % attrition rate of key / core members 10%
Open
P a g e | 118
Tools and Best Practices Metrices
Item Metric Target Note
1 Number of collaborations with PDSB on Continuous 1 per quarter Subject to availability of PDSB counterpart
Improvement Proposed for collaboration
2 % improvement proposals accepted by PDSB 50%
3 Workshop Sharing of FPT Best Practices or Tools to 1 per quarter Some presenter might join virtually
PDSB staff
Other Metrices
Item Metric Target Note
1 Local resources Year 1: 50%, Year 2: 60% Year 3: 70% The % is based on the total resources
deployed under The GDC contract
2 GDC Office Within 3 months after signing West Malaysia: Kuala Lumpur
East Malaysia: Kuching
GDC can start functioning within 4 weeks of
signing while pending physical
infrastructure to be ready.
3 GDC Core Team Within 2 months after signing Core team members to be defined by FPT
Annexure C: <Intentionally left blank>
Open
P a g e | 119
Appendix A: Sample of Course Catalog
The table below is an extraction from FPT’s course catalog for illustration purposes. Because of copyright reason, only FPT‘s
authorized person can access full catalog.
Nanodegree School Level Duration Pre-require Hardware/Software Required Learning Path
Machine Artificial Specialist 4 months Prior experience with Python and A 64-bit computer, at least 8GB of RAM Udacity Machine
Learning Intelligence Study 10 Machine Learning and administrator account permissions Learning Learning
DevOps hours/week sufficient to install programs including Path
Engineer Anaconda with Python 3.x and
supporting packages
Deep Artificial Intermediate 4 months Students should have experience NLTK, SKLearn, BeautifulSoup, Numpy Artificial
Learning Intelligence Study 10 working with and/or knowledge of Intelligence
hours/week the following topics: Learning Path
• Derivatives • Linear Algebra • Primary
Numpy, Pandas • Intermediate Python
• Jupyter notebooks
AWS Artificial Intermediate 5 months • At least 40 hours of programming Udacity Machine
Machine Intelligence Study 5-10 experience Learning Learning
Learning hours/week • Familiarity with data structures like Path
Engineer dictionaries
and lists
• Experience with libraries like
NumPy and pandas
• Knowledge of functions, variables,
loops, and
classes
• Exposure to Python through Jupyter
Notebooks
is recommended
• Experience with constructing and
calling HTTP API endpoints is
recommended
• Basic knowledge of machine
learning
algorithms
Open
P a g e | 120
AI Artificial Foundational 3 months Basic calculus knowledge, including Computer running OS X or Windows
Programmin Intelligence Study 10 how to calculate derivatives. Basic
g with hours/week algebra and programming knowledge
Python will shorten the time to mastery
Deep Artificial Specialist 4 • Intermediate to Specialist Python Computer running a 64- bit operating Artificial
Reinforceme Intelligence months/study experience. • Familiarity with object- system with at least 8GB of RAM, along Intelligence
nt Learning 10 hrs/week oriented programming. • Read and with administrator account permissions Learning Path
understand code. • Understanding of sufficient to install programs including Primary
probability and statistics. • Anaconda with Python 3.6 and
Intermediate knowledge of machine supporting packages.
learning techniques. • Ability to
describe backpropagation, and
knowledge of neural network
architectures (like a CNN for image
classification). • Experience with a
deep learning framework like
TensorFlow, Keras, or PyTorch
AI Product Artificial Foundational 2 months Basic computer skills and experience Access to the internet and a 64-bit
Manager Intelligence Study 10 navigating online computer
hours/week
Computer Artificial Specialist 3 months Significant experience with Python, A 64-bit operating system with at least Artificial
Vision Intelligence Study 10 and entry-level experience with 8GB of RAM, along with administrator Intelligence
hours/week probability and statistics, and deep account permissions sufficient to install Learning Path
learning architectures. Ability to write programs including Anaconda with Primary
a class in Python and add comments Python 3.5 and supporting packages.
to your code for others to read. Your netwoark should allow secure
Familiarity with the term “neural connections to remote hosts (like SSH)
networks” and differential math that
drives backpropagation
Natural Artificial Specialist 3 months Significant experience with Python, A 64-bit operating system with at least Artificial
Language Intelligence Study 10 and entry-level experience with 8GB of RAM, along with administrator Intelligence
Processing hours/week probability and statistics, and deep account permissions sufficient to install Learning Path
learning architectures. Ability to write programs including Anaconda with Primary
a class in Python and add comments Python 3.5 and supporting packages.
to your code for others to read. Your netwoark should allow secure
Familiarity with the term “neural connections to remote hosts (like SSH)
networks” and differential math that
Open
P a g e | 121
drives back propagation
Open
P a g e | 122
Appendix B: Sample of A Syllabus
Data Engineer Intermediate
Enrich Role-based Skills Training Program
1. Introduction
Data engineers work in a variety of settings to build systems that collect, manage, and convert raw data into usable
information for data scientists and business analysts.
2. Objectives 4. Program Information

Learn to develop a basic data pipeline using multiple  Duration: 2.5-03 months
tools to collect, manage and convert raw data into  Skills: 65% courses and 35% projects
usable data warehouse and visualize the data with  Time: 7~10 hours/week
Power BI.
 Approximate hours: 80~85 hours
At the end of the program, leaner will combine enriched
new skills by completing a capstone project.  Entry Level: Internship or Junior
 Achievement Level: Intermediate
Learners in this program will:
- Recap the knowledge about SQL by learning

5. Prerequisites
Prerequisites of foundation learner knowledge, skills
how to use the SQL language within Microsoft
and practices are included knowledge, skills and
SQL Server.
practices are required:
- Ingest the data from data sources and store into
 Fundamental of SQL
a data lake
 Fundamental of Database Technology
- Learn how to use Scala to manipulate with the
data and store into destination data warehouse.  Fundamental of Cloud platform
- Understand Directed Acyclic Graph  Docker Tool
- Understand data warehouse models and design
a data warehouse in the right way. 6. Required Technology Stack
- Visualize the data using PowerBI/Tableau  SQL
 Azure
3. Skills Take-Away  Docker
 SQL, Scala programing language
 Designing and implementing a data pipeline
 Directed Acyclic Graph
7. Mentor’s Contact Points
 Name: Nguyen Dang Duy
 Data Warehouse fundamental
 Mobile: +84 988997033
 Microsoft Power BI  Email: duynd4@fsoft.com.vn
Open
P a g e | 123
8. Training Syllabus
Program is providing work-in-progress courses and sections from the skills of the Data Engineer role includes but is
not limited to the following topics:
No. Role-based Skills Hours Service Course Name Lessons

Provider
Filte Section 1 23 Basic of SQL & Data ingestion
r
1 Microsoft SQL for 4 Udemy A comprehensive course to teach you how to All
Beginners complete SQL queries using Microsoft SQL
Server and the T-SQL language.
- SELECT Statement
- Filter data with WHERE clause
- Sorting data with the ORDER BY
- Query multiple tables with JOIN
- Aggregate functions
- Group data with GROUP BY
- Filter groups with HAVING
2 Azure Data Factory for 7 Udemy Real world project for Azure Data Engineers All
Data Engineers using Azure Data Factory, SQL, Data Lake
- Overviews
- Environment set-up
- Data ingestion from Azure Blob
- Data ingestion from HTTP
- Data flows – Cases & Deaths data
transformation
- Data flows – Hospital admissions data
transformation
- Prepare Data for HDInsight &
Databricks
- Databricks activity
- Copy data to Azure SQL
3 Practical Project 1 12 Self-paced Data ingestion using Azure Data Factory

II Section 2 30 Scala
1 Scala programming 6 Udemy Introduction to programming in the Scala All
language. language. Core syntax and concepts.
- Course introduction
- Starting Scala
- Scala 101 and worksheets
- Class, objects, apps and more
- Control structures in Scala
- Functions and Closures
2 Databricks Fundamentals 12 Udemy Learn how to process big-data using Databricks All
& Apache Spark Core & Apache Spark 2.4 and 3.0.0 - DataFrame API
and Spark SQL
Open
P a g e | 124
- Setup
- Introduction to Databricks and Apache
Spark
- The DataFrame API: Basic
- The DataFrame API: Transforming data
- Spark SQL & SQL Fundamentals
- Working with difference type of data
- Data Sources
3 Practical Project 2 12 Self-paced Process big data using DataFrame, Scala &
Spark
III Section 3 11 Directed acyclic graph, Data warehouse and

Data visualization
1 Data warehouse 5 Udemy Best Practices and Concepts for Architecture All
Fundamentals for and Dimensional Design
Beginners - Data warehousing concepts
- Data warehousing architecture
- Bring data into your data warehouse
- Data warehousing design: Building
blocks
- Design Facts, Fact tables, Dimension
and dimension tables
- Managing data warehouse history
through Slowly Changing Dimensions.
- Designing your ETL
- Selecting your data warehouse
environment
2 The Complete Hands- 6 Udemy Apache Airflow is an open-source platform to All
On Introduction to programmatically author, schedule and monitor
Apache Airflow workflows. If we have many ETL(s) to manage,
Airflow is a must-have.
- Create plugins to add functionalities to
Apache Airflow.
- Using Docker with Airflow and
different executors
- Master core functionalities such as
DAGs, Operators, Tasks, Workflows,
etc
- Understand and apply advanced
concepts of Apache Airflow such as
XCOMs, Branching and SubDAGs.
- The difference between Sequential,
Local and Celery Executors, how do
they work and how can you use them.
- Use Apache Airflow in a Big Data
ecosystem with Hive, PostgreSQL,
Elasticsearch etc.
- Install and configure Apache Airflow
- Think, answer and implement solutions
using Airflow to real data processing
Open
P a g e | 125
problems
3 Complete Introduction 7 Udemy A comprehensive guide on how to import, Optional
to Microsoft Power BI transform & visualize data with Power BI, with
practical exercises & case study.
- Sign up for Power BI
- The Power BI desktop
- Creating report in Power BI desktop
- Graphs & Visualizations
- Interactive dashboards
- DAX Formulars
- DAX Measures
- Relationships
- Power BI query editor
- Analyze data with Excel
- Corona virus case study
IV Final Practical Project 16 End-to-end data pipeline
Total hours 80
9. Practical Projects
In a practical project, you’ll create a database and build a data pipeline to extract, transform and load data into a
data warehouse on cloud using ETL tools. From that you will perform some machine learning techniques to predict
a dataset. After that you will end up building dashboards for end users to support their business decision making.
No. Practical Project Technical Stack Description
I Practical Project 1 MS SQL Server Ingest the data from SQL server by using
Azure Data Factory multiple technique and store the data to
Azure Data Lake Azure Data Lake. Transform the data using
Azure Databricks
Data Factory and copy to Azure SQL
Data sources: ERP, SQL ...
II Practical Project 2 Azure Databricks/Spark Develop a data pipeline by using Databricks

Scala or Sparks to filter, cleansing, merge the data.
S3/Azure Data lake/MinIO Data source: Az DataLake, HDFS...
III Final Practical Project MS SQL Server/Postgres Build full data pipeline by combine practical
(Azure/AWS/GCP) Scala project 1 & 2, store data to data warehouse,
Spark SQL ADF or AirFlow tool, and to be visualized by
Power BI/Tableau/Superset using Power BI/Tableau/Superset
Notes:
________________________________________________________________________________________________________________
___
________________________________________________________________________________________________________________
__________
Open
P a g e | 126
Open
P a g e | 127

Global Delivery Center SOW.V1.5 - PDSB Review - 250823 Down

Uploaded by

Document Information

Original Title

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

Global Delivery Center SOW.V1.5 - PDSB Review - 250823 Down

Uploaded by

Copyright:

Available Formats

FPT Global Delivery Center Malaysia – Annexure for Partnership Agreement

Figure 1: FPT's GDC in Malaysia

This SOW also incorporates the following related documents:

6 BCP Business Continuity Plan

14 CSS Customer Satisfaction Survey

the team responsible for designing, developing, testing, deploying and

28 IDE Integrated Development Environment

29 ISO 27001 An international standard to manage information security

31 KPI Key Performance Indicator

32 OJT On-the Job Training

55 TMMi Test Maturity Model Integration

56 TSL Technical Solution Lead

DC shall provide following infrastructure and facilities:

2.1.1.1 Physical Infrastructure

Facilities Provided to GDC Staff by PETRONAS:

FPT Standard Operating Environment (SOE):

Figure 3: GDC IT Infrastructure

2.1.1.3 Network Connectivity

2.1.1.4 FPT (Redundancy) Environment for potential use by PETRONAS

Figure 6: FPT VDI Infrastructure for potential use by PETRONAS

FPT plan to enable the Malaysia DC to receive the below certifications:

Figure 11: Key Partnerships

Figure 12: SD Common Tech Stacks

Figure 13: DE Common Tech Stacks

Figure 14: DevOps Engineering Solution

Figure 15: AI & ML Tech Stacks

f. AI & ML Algorithms & Models

Figure 16: AI & ML Algorithms and Models

First 6 months Six months later Year 2 and Beyond

Training via Practical Projects

Customization Energy Platform (CEP) GDC

Director Dual Role

Figure 17: CEP Director as GDC Head

Figure 18: GDC Timeline

Picture below summaries:

Figure 19: BCP Overview

Figure 20: Emergency Response Team (ERT)

2.1.3.2 Business Continuity Impact Analysis

Agent Subject impacted Operation effected Recovery requirements

2.1.3.3 P0 – Communication Plan

Figure 21: BCP Communication Plan

2.1.3.4 P1 – People Treatment Plan

2.1.3.5 P2 – Backup Working Places Plan

2.1.3.7 Emergency Response Procedures

ID AGENT/ WHO WHAT WHEN HOW

2.1.3.8 Maintenance and Awareness

Provides action plan to Commits and manages

Manages BCP awareness

Updates processes and

Training courses which will be conducted are shown in table below:

DETAILS Compulsory Compulsory Not required

2.1.4 Out of scope

FPT Malaysia Functional Organisation

Figure 22: FPT Malaysia Functional Organization

Figure 23: GDC Organization

No Leadership Team(s) Responsible Report/Escalate to

2 Head of DC • Drive intake process to setup growth engine. Executive Sponsor

• Ensure GDC governance and performance reporting to Working

5 Global Solutions • Provide support for all technical solutions.

No Role Responsible Who do they team Can be shared?

• Prioritizing product features and capabilities.

• Creating a shared brain across larger teams to empower

6 UI/UX • Responsible for the UX elements of a product. • Process owner/ No