observation report-crp-22july-2014
TRANSCRIPT
2014
Observation Report
BSN CORE BANKING REPLACEMENT PROGRAM (CRP)
Rahmat Hashim (PMO, Core Banking Program, BSN)
OBSERVATION REPORT
BSN CORE BANKING REPLACEMENT PROGRAM (CRP)
1 July 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
BSN CORE BANKING REPLACEMENT PROGRAM (CRP)
2 July 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
BSN CORE BANKING REPLACEMENT PROGRAM (CRP)
3 July 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
BSN CORE BANKING REPLACEMENT PROGRAM (CRP)
4 July 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
BSN CORE BANKING REPLACEMENT PROGRAM (CRP)
5 July 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
BSN CORE BANKING REPLACEMENT PROGRAM (CRP)
6 July 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
BSN CORE BANKING REPLACEMENT PROGRAM (CRP)
7 July 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
BSN CORE BANKING REPLACEMENT PROGRAM (CRP)
8 July 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
BSN CORE BANKING REPLACEMENT PROGRAM (CRP)
9 July 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
BSN CORE BANKING REPLACEMENT PROGRAM (CRP)
10 July 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
BSN CORE BANKING REPLACEMENT PROGRAM (CRP)
11 July 22, 2014
Critical Success Factor Normal Project 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
BSN CORE BANKING REPLACEMENT PROGRAM (CRP)
12 July 22, 2014
Critical Success Factor Normal Project 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
BSN CORE BANKING REPLACEMENT PROGRAM (CRP)
13 July 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
BSN CORE BANKING REPLACEMENT PROGRAM (CRP)
14 July 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 ---------------------------------------------