BSN Core Banking Replacement Program Observation Report

2014
Observation Report
BSN CORE BANKING REPLACEMENT PROGRAM (CRP)
Rahmat Hashim (PMO, Core Banking Program, BSN)

OBSERVATION REPORT
1July 22, 2014
TABLE OF CONTENT
1 EXECUTIVE SUMMARY ..........................................................................................................2
2 PROJECT MANAGEMENT METHODOLOGY & PROCESS............................................................3
3 GAPS IN THE CRP PROJECT ..................................................................................................10
4 LESSON LEARNED................................................................................................................13

OBSERVATION REPORT
2July 22, 2014
1 EXECUTIVE SUMMARY
This report serves as my feedback pertinent to the above project i.e. BSN CRP project for the past 3
months involved as PMO in the project.
I was assigned to BSN CRP project by Infinite Computer Solution Sdn. Bhd. (hereinafter referred as
Infinite) as PMO since Infinite is a ‘body-shop’ company providing professional contract workers in areas
requested by their clients and BSN is Infinite’s client.
In summary, the contract for BSN CRP project was signed in April 2012 between BSN and HeiTech Padu
(hereinafter referred to as HTP) as the prime contractor and SI (system implementer) to deliver the Core
Banking solution to replace BSN’s present banking system. The solutions proposed by HTP are BML ICBS
Core Banking System (hereinafter referred to as ICBS) and Juris Loan Management System (hereinafter
referred to as JURIS). Both ICBS and JURIS are products of BML Istisharat (a Lebanon company) and Juris
Technologies (a Malaysian company), respectively. Both companies are responsible to perform
customization development on their product based on BSN’s user requirements.
This report is divided into the following structure:
 Project Management Methodology & Process
 Gaps in the CRP Project
 Lesson Learned
The purpose of this Observation Report is to highlight some of the gaps existed in the project and
though may be too late to recover but at least, they will be recorded as lesson learned and treated as
risks for future IT project initiative in BSN.

OBSERVATION REPORT
3July 22, 2014
2 PROJECT MANAGEMENT METHODOLOGY & PROCESS
Project management plays important part in the project delivery. Having a good methodology and
processes will ensure the delivery of end product is within scopes, time, costs and expected quality as
per stakeholders’ aspiration.
As highlighted by Eric Verzuh in his book The Fast Forward MBA in Project Management (Verzuh, 2011),
there are 5 critical success factors for a project to be successful:
a) All stakeholders must agree on the project goals;
b) Having a good project plan that shows overall path, clear responsibilities, and can be used to
measure progress during project execution;
c) Constant and effective communication among project stakeholders;
d) A controlled scope; and
e) Management support.
In general, there are 4 significant components in project delivery process which comprise of:
a) Project Management Process
b) Project Governance and Authority
c) Project Resources
d) Project Organization
The most important component is Project Management Process as it will ensures project activities are
defined and performed accordingly to achieve the objective of delivering successful project within the
triple constraints (i.e. Scope, Time and Cost).
2.1 PROJECT MANAGEMENT PROCESS
The project management process involves activities such as project initiation, planning, execution,
monitoring & control, and closing. By fragmentizing project into several group processes will help the
project team determine at which stage they’re in. Thus, progress can be measured accordingly and the
remaining time to complete the project can be well-estimated and established.
2.2 PROJECT GOVERNANCE & AUTHORITY (G&A)
We cannot execute effectively all project processes, managing project resources and controlling project
organization without putting in place the Governance and Authority (G&A). In this component, the
project rules and level of authority governing the rules are defined and highlighted during the project
launching session.

OBSERVATION REPORT
4July 22, 2014
Any amendment to project delivery timeline, scopes and cost will go through the required level of
authority to obtain approval and sign-off. The mechanism on governance and level of authority must be
agreed upon and adhered by all parties in the project.
2.3 PROJECT ORGANIZATION
Organizing a project team will be a challenge when we do not have proper organization structure
established prior to commencing the project. We may determine the number of required people or
resources to be assigned to the project but without the organization structure being established, it will
be difficult to instruct these resources to perform their job as each resource may need to produce result
and deliverables based on the function and roles assigned to them. The project organization structure
will be the basis for Project Manager to establish the reporting structure within the project team.
Furthermore, there should not be any restructuring in the project organization during project
implementation as it will impact to project delivery activities due to changes in reporting structure. The
project team morale will be affected and the result will be a high turnover in project team due to
confusion and dissatisfaction.
2.4 PROJECT RESOURCES
Resources will be another significant factor in project. Resources can be in a form of people, machinery,
documentations, systems, software, peripherals and other components required to complete the
project. Without resources in place, implementing project will be impossible. As such, planning the
required resources and managing them effectively will ensure project is delivered in accordance to the
expected timeline.

OBSERVATION REPORT
5July 22, 2014
PROJECT MANAGEMENT PROCESS
What is a project? A project is a temporary endeavor undertaken to create a unique product, services,
or result. (PMI Global Standard, 2008). It means that it has a definite beginning and end date. The
standard project management practice (i.e. PMBoK1
) divided the project management process into 5
group processes. These group processes are:
 Project Initiation
 Project Planning
 Project Execution
 Project Monitoring and Control
 Project Closing
The integrative nature of project management requires the Project Monitoring and Control process
group to interact with the other group processes. The following diagram illustrates the 5 group
processes implemented in a project.
1
PMBoK – Project Management Body of Knowledge. A methodology established by Project Management Institute
(PMI).
Initiation Planning Execution Closing
Monitoring & Control

OBSERVATION REPORT
6July 22, 2014
Based on my experience from previous software development projects, the following group processes are
implemented and key deliverables are produced to indicate the completion of each respective group
process. A list of deliverables produced from each group process is shown below.
Group Process Activities Deliverables2
1. Project Initiation  Identify & perform Stakeholders Analysis
 Develop Project Charter
 Conduct Project Kick-Off Meeting
 Project Charter
2. Project Planning  Establish Project Team Organization
 Establish Project Communication Plan
 Establish Risk Management Plan
 Develop Project Management Plan
 Contract negotiation and preparation
 Project Management
Plan (PMP) Document
 Risk Profile & Risk Log
 Contract document
3. Project Execution  Procurement initiation
 User requirements specification
 Design solution / product
 Develop solution
 Quality Assurance/Quality Control
 User Training and Technical Training
 Live Run
 Purchase Order (PO)
 URS document
 SRS document
 SAD document
 SIT document
 UAT document
 Training Manual
 User Manual
 Technical Manual
4. Project Monitoring
and Control
 Execute communication plan
 Develop project update report
 Conduct project update meeting
 Update risks profile and risks log
 Execute risks mitigation plan
 Conduct acceptance sign-off
 Change request management
 Problems and issues resolution
 Progress Report
 Risks Profile & Logs
 Change Request Logs
 Issue & Resolution Logs
 Revised Project
Timeline (Actual vs.
Baseline)
2
URS – User Requirement Study;
SRS – Systems Requirement Specification;
SAD – Systems Architecture Design;
UAT – User Acceptance Test;
SIT – System Integration Test

OBSERVATION REPORT
7July 22, 2014
5. Project Closing  Develop Lesson Learned Report
 Conduct Post Implementation Review
session
 Conduct Handover Session
 Execute Warranty Support
 Lesson Learned Report
 Handover Document
 Final Acceptance
Document
The sign-off on Project Management Plan (PMP) document marked the commencement of Project
Execution process. The Project Manager will need to execute all planned tasks in accordance to the
implementation strategy and the timeline stated in the PMP document.
A standard software development life cycle (SDLC) is shown below.
The software development life cycle is divided into 4 stages as illustrated above.
Requirement & Design Stage
In this stage, it involves gathering of user requirements and scopes confirmation. User expectations of
the end-product will be determined and captured in the User Requirements Specification (URS)
document. Any dispute pertinent to project scope will be highlighted to PWC (Project Working
Committee) for further decision.

OBSERVATION REPORT
8July 22, 2014
Once the URS document is finalized, it will be submitted for acceptance and sign-off. The URS
documentation is a configuration item. All requests for requirement change after they have been
formally accepted must go through the Project Change Control Board for review and approval before
changes can take effect.
System Design activities commences after the users have accepted and signed-off the URS document. It
involves designing the entity relationships (ERD), data dictionary, systems architecture, user interface
screens, operational reports, the workflow process, the integration with external systems and other
matters related to the end-product. The deliverables from these activities will be:
 System Requirements Specification (SRS) document; and
 System Architecture Design (SAD) document.
Once finalized, these documents will be submitted for acceptance and sign-off. Both SRS and SAD are
configuration items. Any request for change to these documentations will be subjected to review and
approve by the Project Change Control Board.
Development Stage
The actual development activities commence upon SRS and SAD have been accepted and signed-off.
Development tasks involve program scripting, configuring the database and creating the physical data
structure. At this stage, the technical resources will be deployed to do specific technical work. The
development work will be based on the approved design stipulated in the SRS and SAD.
The technical project team will perform unit testing on each module they’ve completed prior to
submission to QA Team for testing and acceptance. Unit testing will be done in the development
environment i.e. within the development team control.
Once the Solution Architect (SA) satisfied with the end result of unit testing, he will inform the Project
Manager that system is ready for QA review and acceptance. The Project Manager will coordinate
further with QA Team for the next stage i.e. QA and Acceptance Stage.
QA and Acceptance Stage
Normally, the system will be reviewed for quality assurance in 2 stages i.e. SIT (System Integration
Testing) and UAT (User Acceptance Testing). Prior to these stages, a proper SIT Plan and UAT Plan
documents will be developed by the QA Team.
These documents will be submitted to QA Committee for review and acceptance. In these documents,
QA Team defines the test scripts and quality metrics for the end-product compliance.
The metrics will be based on the requirements set forth in the scope of delivery, for example the system
response time must not exceed 3 seconds during data updating process in every maintenance screen
functions.
Testing will be performed in the QA environment whereby the development team will not have any
authority to make amendments to the end-product. The outcome from this stage will be signed-off for
end-product live run.

OBSERVATION REPORT
9July 22, 2014
Product Live Run
Once the end-product has gone through the QA and Acceptance stage, it’s ready to be ported over to
production environment. Review on the result of this stage will be presented to QA Committee for
acceptance. The QA Committee will give feedback to PWC on the readiness of the end-product and the
Live Run date will be determined.
Prior to Live Run, various tasks will be executed. For example, User Training session will be conducted
and data migration exercise will take place. These activities are important so that the end-product
readiness for Live Run is addressed. At this juncture, necessary documentations such as Training Manual
and User Guide must be ready. Sometime, the Live Run strategy may involves deployment to certain
sites for pilot implementation. Anyway, the project team will have contingency plan in term of handling
users at the pilot sites should there be any hiccup during the live run. This again will depend on the
strategy required by the project owner and users.
During Live Run, the Project Manager must be ready with mitigation plan for risks of end-product failing
the implementation. Failing at the end of project delivery can bring down the users’ confident level since
they have been waiting for some time for the end-product to Live Run. As such, the Project Manager will
need to ensure issues and problems being resolved amicably to retain users’ confident level on the
delivered product.
The following technical documents are the deliverables in the Project Execution stage.
 URS – User Requirement Specification document
 SRS – System Requirement Specification document
 SAD – System Architecture Design document
 SIT – System Integration Test document
 UAT – User Acceptance Test document
 Training Manual
 User Guide (Manual)
 Technical Manual

OBSERVATION REPORT
10July 22, 2014
3 GAPS IN THE CRP PROJECT
My assessment on gaps in CRP Project is based on 5 critical success factors for a project to be successful
which are:
a) All stakeholders must agree on the project goals;
b) A project plan that shows overall path, clear responsibilities, and can be used to measure progress
during project execution;
c) Constant and effective communication among project stakeholders;
d) A controlled scope; and
e) Management support.
Critical Success Factor Normal Project
Mitigation Plan
Gaps in CRP Project
a) All stakeholders must
agree on the project
goals
 Establishing the Project
Charter, and Project
Management Plan
(PMP) document. A
Project Charter is a
document develop
during Project Initiation
Stage prior to PMP
document which will
be the input to the
development of PMP
document in Project
Planning Stage.
 Produce Functional
Specs. document (FSD)
to baseline the scope
for user requirements
 The PMP document prepared by HTP.
The document was signed-off and
accepted by BSN but the document
was not updated although there is a
restructuring in the project
organization structure to adapt the
new ‘Blended Module’ approach
approved by PSC (Project Steering
Committee).
 The PMP document is a living
document which any changes to
project operations, rules and strategy
must be updated in the document. It
must contains latest information
pertinent to project as it is the
project reference document for
project team and stakeholders to
refer.
 The FSD is a technical document that
describe the high-level design
pertinent to system functional
requirements. This document should
show data flow diagram (DFD), Entity
Relationship (ERD), Data Model, Data
Dictionary, and Process Spec. for
each module in Data Flow Diagram.
 The FSD for ICBS solution only
describe process specification for the
amendment requirements in ICBS.

OBSERVATION REPORT
11July 22, 2014
Mitigation Plan
Gaps in CRP Project
It does not shows the total ICBS
solution purchased by BSN for this
project in term of logical design and
data model. Determining the
relationship between modules and
functions in ICBS is a gap and it will
be difficult to conduct impact analysis
should there be any change request
raised.
 The FSD is also a document that can
be referred to when conducting
transition activities to Operation
Team prior to Live Run.
b) A project plan that
shows overall path,
clear responsibilities,
and can measure
progress during project
execution
 Project Timeline that
has been baseline and
agreed by all
stakeholders
 Resource Planning and
definitive Roles &
Responsibilities of each
resource
 Official project
assignment letter from
Management to
project team members
 There’s frequent changes to project
schedule baseline due to dependency
on BML developers to provide their
development activities timeline.
 Estimation on project activities
duration is a challenge due to new
change requests (CRs) popping up in
the UAT cycle activities and also BSN
new products defined by the BSN
Business Team.
 Engagement of resources from ‘body-
shop’ companies are based on ad-hoc
basis. Resource Planning should be
done in the Planning Stage whereby
the number of resources in every
activities should be forecasted earlier
rather than ad-hoc. It gives cost
impact to project.
c) Constant and effective
communication among
project stakeholders
 Project Progress Report
 Checkpoint Meeting,
Working Committee
Meeting, Sponsor
Meeting, Steering
Committee Meeting,
and Change Control
Board Meeting
 In terms of communication, CRP PMO
has established effective project
communication channels via various
meetings such as:
o PWC (Working Committee)
o PSC (Steering Committee)
o IRRC (Issues, Risks Resolution
Committee)

OBSERVATION REPORT
12July 22, 2014
Mitigation Plan
Gaps in CRP Project
o CRMC (Change Requests
Management Committee)
o BAC (Business Advisory
Council)
o Sponsor Update Meeting
o TKE Update Meeting
o PMO Weekly Meeting
d) A controlled scope  Level of Authority to
govern project rules
and scope changes
 Requirement
Traceability Matrix
(RTM) to cross-
reference Tender
Requirement Specs.
 Configuration
Management and
version control
 Legalizing project
scope via Contract
Agreement
 Additional requirements being raised
despite decision from Project
Steering Committee (PSC) to stop any
new requirements from Business
Users.
 Policy changes in the approval
workflow between KL and Selangor
branch which resulted in the new
request being raised.
 Controlling vendors as per contract
commitment is lacking and vendors
(especially BML) is taking advantage
of this situation.
e) Management Support  Perform Stakeholders
Analysis and develop
RACI (Responsible,
Accountable, Consult,
and Inform) matrix to
determine the
respective high-level
management
involvement in project
decision making and
endorsement.
 Management
representative as
stakeholders in the
Project Steering
Committee (PSC).
 CRP Project has full-support from the
BSN Management since this is a mega
project for BSN. The Sponsor for the
project is the Deputy CEO of Retail
Banking.
 The CEO, and both Deputy CEOs
(Corporate Support, and Retail
Banking) have specific update
meeting with Program Director of
CRP Project to review the project
status and issues that require Higher
Management decision.

OBSERVATION REPORT
13July 22, 2014
4 LESSON LEARNED
Based on my observation, I can conclude the Lesson Learned as follows:
Category Areas of Improvement
a) Vendor Management  Managing vendor should be based on the contract
commitment agreed between BSN and the respective
vendors.
 Deliverables submitted by vendors must be checked and
verify as per metrics set forth by QA team prior to approval
sign-off.
 A proper project team structure must include Subject Matter
Expert (SME) from vendor to ensure full comprehension of
the end-to-end process and to avoid misunderstanding on
the user requirements.
 Prime Contractor or the System Integrator (SI) vendor
should take full responsibilities of project delivery and
conduct conflict management between solution vendors
since the Solutions was proposed by the SI vendor.
 The vendors’ performance should be evaluated for the first 3
months after launching of the project in order to ensure that
they are able to perform their project tasks accordingly.
There should be a clause in the contract to allow assessment
on vendor performance.
b) Risk Management  Project risk analysis should be conducted prior to changes to
the project implementation strategy e.g. the Blended Model
approach.
 Potential risks in every milestones tasks need to be
identified and presented to Project Working Committee
(PWC) so that the respective stakeholders are aware of the
grievous impact on the project timeline.
 Risks management is a continuous effort and all risks need
to be logged and maintained properly. Ineffective risks
management will result in the absent of mitigation plan.
Thus, project will be impacted due to the emerging risks
beyond project team radar.

OBSERVATION REPORT
14July 22, 2014
Category Areas of Improvement
c) Scope Management  Scope needs to be baseline based on the Statement of
Compliance (SOC) in Tender Document. A proper tool can be
used to cross-reference the requirements e.g. the
Requirement Traceability Matrix (RTM) document.
 Any new requirement raised during project scoping should
be captured in the RTM document. This document should be
used as term of reference in all stages of product
development to avoid ‘scope creeps’ during SIT, UAT and
Training.
 Proper Configuration Management need to be deployed to
ensure versioning control on all configuration items such as,
Functional Specification Document (FSD), System Design
Document (SDD), QA Plan, Software patches, and etc.
d) Resource Management  Resource Planning should be done at earlier stage i.e. the
Project Planning stage.
 Resource Planning should be based on the Project
Organization Structure as defined in the Project
Management Plan document. Roles and responsibilities of
each resource must be defined accordingly prior to the
mobilization of resources.
 Resource should be deployed based on the number of
resources allocated to each project tasks stipulated in the
project timeline.
 If possible, local software developers should be made
available to ease the turnaround time of resolving
development issues.
------------------------------------ End of Report ---------------------------------------------

BSN Core Banking Replacement Program Observation Report

Recommended

Recommended

More Related Content

Similar to BSN Core Banking Replacement Program Observation Report

Similar to BSN Core Banking Replacement Program Observation Report (20)

BSN Core Banking Replacement Program Observation Report