Dec 2012 Evening Talk - Managing Complex Project

PMIMY EVENING TALK

MANAGING COMPLEX PROJECTSuharti Mohd Ali Program Director IT Transformation Celcom Axiata Bhd

2

What I will Share Tonight

Criteria of A Complex Project

Areas of Work for Scrutiny

Measures of Success

Pitfalls to Look Out For

Question Time

1

2

5

3

4

3

What is a Complex Project?

Budget used to be the sole determinant of complexity, but not anymore

� any project with more than 3 parties to be managed

�any project with more than 3 systems to be retired in the process

�any project which impact more than 3 divisions in the organization totaling more than 300 people

�Any project which require a team structure of more than 150 people

�any project introducing more than 3 new applications to the business………

4

What Makes a Project Complex?

There is now an Institute of Complex Projects who is in the midst of devising a tool to assess complexity and complexity levels to help delivery teams put a structure in place

But the science of determining if a project is complex or otherwise is the simplest task – the real test is HOW do we deal with it.

Complex legacy landscape was a challenge in supporting the HSBB agenda ..

5

• Numerous and disparate support systems catering to different products and lines of businesses

• Legacy, custom-built applications and point-to-point data transfers

• Increased complexity and time to enhance for HSBB transformation

• 30+ user communities to engage

• 68 level 3 and 210 level 4 business processes

• 100+ systems interfaces to develop

66

Numerous Vendors

PMO & SystemsIntegrator

HardwareStorage

SoftwarePrincipals

Jointly managed with a single lead SI/PMO (Accenture) to deliver a full-suite of integrated, end-

to-end BSS/OSS/SDP capabilities …

▪ … under a unified program structure focusing on end-to-end deployment of systems, processes

and organization as a business capability, and

▪ … with the right operational and knowledge transfer activities to form a full business solution

for TM

7

Areas of Work for ScrutinyThere are 8 critical areas of work that not only need to be managed but need scrutiny to its most micro level

Tools

Vendor Management

Change Request Management

Risks and Issue Management

Deliverable Sign-Off Management

Dependency Management

Release Management

Program Structure & Governance

8

Project Organization Chart – Sample StructureProject governance and reporting structure is set up to ensure roles and

responsibilities are established and lines of escalation are communicated

Release ManagementSolution

Architecture

Application Teams

Campaign Mgmt

AnalyticsOther Apps…

MigrationTeam

TestingTeam

Tech. Arch.Team

Business Integration Team

Business Process

Training

Project Manager

* Proposed structure to be validated & customized by each project team to suite specific project needs

CommsE2E Integration

Testing

User Acceptance

Testing

Performance Testing

Order Capture

Order Mgmt

Integration

Web Portal SR/TTProduct Mgmt

Supervise the overall project progress , ensure

all scheduled milestones are completed on

time.

Oversee and manage project level dependencies, risks

and issues, monitor delivery progress and vendor

management.

Authority for overall solution within project

program, manage and circuit break cross team

issues, risks and dependencies

• Perform analysis and maintain system and data integration

through various functional designs.

• Design, build and test business capabilities based on the new

process and requirements

• Document and maintain integration requirements.

Coordinate and perform

User Acceptance Test to

ensure the solution is in

line with the

expectations of the

users.

Perform Integration

Test to ensure the end-

to-end solution

conforms to the level of

quality set in the design.

Coordinate and conduct

performance and volume

test to ensure the

solution performance is

acceptable within

defined SLA.

Design and implement

technical architecture,

infrastructure.

Design and develop required

migration tools. Coordinate

and perform migration from

legacy into new systems.

Perform business

process alignment

by designing,

validating and

deploying the ‘to-

be’ business

processes

Plan and perform

required training.

Develop required

training materials

Develop change

and communication

plans for project.

Vendor Management

Board

Steering Committee

CIO updates

Project Leadership Meetings

Team Meetings • Objective – Team leads to review progress of their teams, and any

issues which their team is facing.

• Frequency - 1 per week

• Participants - Team leads with team members

• Objective - Review progress, and address key topics at a project

level.

• Frequency - 1 per week

• Participants (Internal Meeting ) – PMO Team, Delivery Lead,

Leads from different work streams, HR contact (when required)

• Participants (External Meeting ) – Accenture leadership teams and

client leads

• Objective - To provide update on progress of project.

• Frequency - 1 per quarter

• Participants - Board of directors, CIO, PMO team.

• Objective - Discuss project issues and agree upon next steps.

• Frequency - 1 per fortnight

• Participants - CIO, Steering Committee, PMO team.

• Objective - To provide CIO with progress updates, highlight and

seek direction on project issues.

• Frequency - 1 per fortnight

• Participants – CIO, Accenture Delivery Lead

9

Program GovernanceLeadership must be planned in order to closely monitor the Program and keep two-

way communication channel open

Meetings Type Frequency Key Attendees Purpose of Meeting

Systems Steering Committee

Meeting

ExternalWeekly(every

Tuesday)

• TM Leadership Team: Chee • To update TM leadership on the overall program status

• To highlight issues and decisions for Steering Committee guidance and direction

CIO Systems Update

ExternalWeekly(every Friday)

• • To update TM Systems leadership on the overall program status

• To highlight issues and decisions for IT Leadership guidance and direction

Nova IT Program Leadership Meeting


Wednesday)

• Nova Leadership: • Internal Program meeting to run through overall program status & potential impacts to the schedule.

• Any major escalations/issues should be highlighted in the Program Leadership meeting.

iCarePrime Status Meeting


Thursday)

• Nova Leadership• TM Business:

• Internal Program meeting to run through overall program status & potential impacts to the schedule.

• Any major escalations/issues should be highlighted in the Program Leadership meeting.

10

Program Governance – External MeetingsA structure was setup with the Client in order to highlight issues and report status of

the overall progress

Meetings Type Frequency Key Attendees Purpose of Meeting

EMC Vendor Status Meeting

ExternalWeekly(every Friday)

• Nova Leadership: • EMC Leads

• To review status of EMC status report

• To discuss and escalate EMC issues and status

Oracle Status Meeting

ExternalWeekly (every

Monday)

• Nova Leadership: • To discuss and escalate Oracle issues and status

Oracle Critical Account Call


Thursday)

• Nova Leadership: • Oracle Leads:

• To review and escalate critical Oracle SRs

11

Program Governance – Vendor MeetingsThis structure is replicated with the various Vendors in order to discuss status and

escalate vendor specific issues

12

Release ManagementWhat components to be managed?

• Report of each phase in SDLC

•

• Each SDLC phase is tracked with issues highlighted

•

• Release Plan• Score Card

• Status

tracking• System Development Lifecycle (SDLC) detailed out in a waterfall chart

•

13

Overall Release Plan

13

• In order to monitor various releases and phases within the release, an overall release plan is

created.

• This will indicate the start & end dates , the duration of each phase, and an RFS date for each

Release

• Each release is depicted by

a Waterfall diagram which

shows the various phases of

the Software Delivery

Lifecycle (SDLC)

14

Description of each phase within Release

14

Phase Description

Plan • Identify key people within organization and vendors and establish the roles and

responsibilities that they play within HSBB program

• Identify key sponsor from vendors for escalation purpose

• Establish clear governance model between Telekom Malaysia and other vendors

Analyze• Identify high level requirements, current capabilities and to-be process

• Identify application requirements

Design• Design end to end solution for business processes

• Define detailed hardware and software requirement in technical design

Build • Configure and customize modules based on solution blueprint.

• Organize and execute system test as well as end to end testing between

applications, external and legacy systems.

Test • Integrate and test build components

• Ensure robustness of system built before go-live

• Identify, document and correct end-to-end defects encountered during testing

Deploy• Conduct performance verification test

• Coordinate and communicate complete deployment and migration plan

15

Deliverables Management

15

• A standard user confirmation agreement is

obtained with the users at the start and end

of each phase

• This is important to ensure

� Deliverables are complete within each

phase

� The system and related documentation

is at the right readiness and quality

level before transitioning to next phase

� All functional groups are aware of the

coming phase transition so they can

weigh in on whether the system and

documentation for the next phase is

indeed ready.

Lessons Learnt

� Sessions organized to walkthrough

deliverable (group and even 1-on-1)

� Keep user signoffs to relevant

stakeholders (minimal number)

16

Status Tracking – Plan & Analyze

16

Plan Analyze Design Build Test Deploy

• An Excel spreadsheet is used to track all requirements raised by stakeholders

• Each requirement is tagged to an Application team that will review and provide

feedback based on

• whether requirement can be met using Out-Of-The-Box approach or requires

customization

• time and cost required to implement all requirements

• Requirements are then prioritized according to the impact they have on the

fulfillment of the stakeholders need.

Product Due

Date

Planned Application Actual

Siebel OSM Granite OBRM Portal

Direct

14-Jan-11 100% 100%[100%] 100%[100%] 100%[100%] 100%[100%] N/A100%

[100%]

25-Feb-11 100% 87.5%[84%] 89%[88%] 100%[100%] 100%[80%] N/A94%

[93%]

IPVPN

IPWholesale

GlobalIPVPN

25-Feb-11 100% 97%[95%] 99%[99%] 52%[51%] 94%[81%] N/A85%

[81%]

4-Mar-11 80% 74%[68%] 64%[59%] 36%[19%] 27%[13%] N/A50%

[41%]

Global

Ethernet4-Mar-11 0% 0% 0% 0% 0% N/A Not Started

HSBC 18-Mar-11 0% 0% 0% 0% 0% N/A Not Started

Status Tracking – Design & Build

17

Amber

This week’s %

of completion

Last week’s % of

completion

• Weekly Status Tracking on Design Documents and code for Build deliverables.

• Design or Build phase progress is tracked by specific Telecom Products and across different

Application Teams

• Each team reports this week % completion versus last week’s % completion to ensure

continuous progress

• % completion is monitored against % planned to ensure Application team can meet due date

• The various application team status is compiled to determine overall status of phase

• An overall status of Red, Amber or Green is determined for the phase based on Actuals vs

Planned.


Overall Status

Status Tracking –Test

18


• Test scenarios are categorised into different domains

• Test scenarios executed is tracked against planned to monitor progress of testing

• Number of passed, failed and blocked test conditions due to defects are tracked

on daily basis.

Status Tracking –Test

19


• Issues that cause delay in the actual progress is reported and addressed.

• Trends of test execution status (e.g. catching up, fallen further behind, progressing

steadily) is monitored using Test Execution Progress graph.

• An overall status of Red, Amber or Green is determined for the phase based on

Actuals vs Planned.

Status Tracking – Deployment Check List

20

• In preparation for release RFS,

production deployment check list is

communicated to all teams.

• Ownership of each check point is

clearly assigned and status

monitored on daily basis.

• Issues to be escalated in a timely

manner.



21

• Due to various external parties involvement, dependencies are created to track all tasks/activities that

requires these parties to complete.

• All Program Dependencies are managed in a central location and the status of each dependency is

monitored daily.

• An Excel spreadsheet is used to record area of dependency e.g. CSM, description of dependency and

dependency due date.

• Person-In-Charge (PIC) must be indicated to ensure responsibility and accountability.

22

• A summary of dependencies is illustrated in Dependency Tree below.

• Overdue open dependencies are highlighted to the Steering Committee


23

#Traffic

LightDescription Status Actions

1 RED Dorado Complete NBI Delivery Delay

• Dorado Development team has initially

reverted the NBI delivery date

• Phase 1 (New Install): 1-Apr

• Phase 2 (Modify): 15-Apr

• Both test lab and NBI is required to be fully

ready and deployed for NOVA SIT test by 1-

Apr

Due date:

28-Feb-11

15-Apr-11

TBD

• Discussion conducted with Dorado. Dorado

confirm that delivery will be expedited. The

revised delivery of NBI is on 15-Apr TBD

• Dorado PO issues – Dorado did not deliver

NBI on 1st Apr 2011 or 15-Apr as planned

2 RED No onsite support identified for DORADO Due date:

4-Apr-11

• Discussion still ongoing between DORADO

and TM.

• Dorado PO Issue – Dorado was unable to

provide support by 4-Apr-11

• The impact of each overdue dependency is further elaborated.

• Team will discuss with the PIC of the dependency on actions moving forward, and revised due date

• The outcome of the discussion will be then shared with the Steering Committee


Change Request Management

24

• Over the course of the project

lifecycle, changes to the original

scope of work is inevitable.

Change Requests must be

managed to reduce risk of time

extension

• Roles and Responsibilities of all

partiess must be clearly defined ,

agreed and communicated.

• Process depicted ensures CRs

raised are collected, reviewed,

approved and implemented

following a structured practice.

Vendor Management

25

A good escalation model must be

established to ensure any critical

product defects that impact project

deadline, causes revenue loss and

production downtime is resolved

immediately

A proper agreement must be made

between client and vendors to

ensure adequate support is provided

throughout project lifecycle and post

go-live

Critical

Accounts

Escalation to Oracle Duty Manager/ Oracle

On-Site Support

Service Request Raised on Oracle MetalinkHardware

Software Principals

Vendor Management

26

• A weekly meeting with the Vendors should be scheduled.

• This is necessary in order to summarize the key product defects which have been

raised by the Program and to ensure that the vendors are fixing defects

adequately.