observation report-crp-22july-2014

2014

Observation Report

BSN CORE BANKING REPLACEMENT PROGRAM (CRP)

Rahmat Hashim (PMO, Core Banking Program, BSN)

OBSERVATION REPORT


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


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


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


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


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


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


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


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


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


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


11 July 22, 2014


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


12 July 22, 2014


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


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


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

observation report-crp-22july-2014

Documents

bsn crp project

project initiative

crp project lesson

project management verzuh

project delivery process

project stakeholders

good project plan

project goals b