The document provides an overview of managing complex projects. It discusses criteria for determining if a project is complex, areas that require scrutiny like program structure and governance. It also covers measures of success, potential pitfalls, and examples from managing a large IT transformation project. Specific topics covered include developing a project organization chart, establishing program governance, managing releases through tracking deliverables and dependencies, and overseeing vendors.

1. PMIMY EVENING TALK
MANAGING COMPLEX PROJECT
Suharti Mohd Ali
Program Director IT Transformation
Celcom Axiata Bhd

2. What I will Share Tonight
1 Criteria of A Complex Project
2 Areas of Work for Scrutiny
3 Measures of Success
4 Pitfalls to Look Out For
5 Question Time
2

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

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

5. Complex legacy landscape was a challenge in
supporting the HSBB agenda ..
• Numerous and disparate support systems • 30+ user communities to engage
catering to different products and lines of
businesses • 68 level 3 and 210 level 4 business
processes
• Legacy, custom-built applications and
point-to-point data transfers • 100+ systems interfaces to develop
• Increased complexity and time to
enhance for HSBB transformation
5

6. Numerous Vendors
PMO & Systems
Integrator
Software
Principals
Storage
Hardware
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
6 6

7. Areas of Work for Scrutiny
There are 8 critical areas of work that not only need to be
managed but need scrutiny to its most micro level
Program Structure & Governance
Release Management
Dependency Management
Deliverable Sign-Off Management
Risks and Issue Management
Change Request Management
Vendor Management
Tools
7

8. Project Organization Chart – Sample Structure
Project governance and reporting structure is set up to ensure roles and
responsibilities are established and lines of escalation are communicated
Supervise the overall project progress , ensure
Project Manager all scheduled milestones are completed on
time.
Solution Oversee and manage project level dependencies, risks
Authority for overall solution within project Release Management and issues, monitor delivery progress and vendor
program, manage and circuit break cross team Architecture
management.
issues, risks and dependencies
Vendor
Management
Application Teams
Migration Testing Tech. Arch. Business Integration
Order Order Team Team Team Team
Integration
Capture Mgmt
Design and develop required Design and implement
Product
Web Portal SR/TT migration tools. Coordinate technical architecture,
Mgmt and perform migration from infrastructure.
legacy into new systems.
Campaign Other
Analytics
Mgmt Apps…
• Perform analysis and maintain system and data integration User
through various functional designs. E2E Integration Performance Business
Acceptance Training Comms
• Design, build and test business capabilities based on the new Testing Testing Process
Testing
process and requirements
• Document and maintain integration requirements.
Perform Integration Coordinate and perform Coordinate and conduct Perform business Plan and perform Develop change
Test to ensure the end- User Acceptance Test to performance and volume process alignment required training. and communication
to-end solution ensure the solution is in test to ensure the by designing, Develop required plans for project.
conforms to the level of line with the solution performance is validating and training materials
quality set in the design. expectations of the acceptable within deploying the ‘to-
users. defined SLA. be’ business
processes
8
* Proposed structure to be validated & customized by each project team to suite specific project needs

9. Program Governance
Leadership must be planned in order to closely monitor the Program and keep two-
way communication channel open
• Objective - To provide update on progress of project.
• Frequency - 1 per quarter
Board • Participants - Board of directors, CIO, PMO team.
• Objective - Discuss project issues and agree upon next steps.
• Frequency - 1 per fortnight
Steering
Committee • Participants - CIO, Steering Committee, PMO team.
• Objective - To provide CIO with progress updates, highlight and
seek direction on project issues.
CIO updates • Frequency - 1 per fortnight
• Participants – CIO, Accenture Delivery Lead
• Objective - Review progress, and address key topics at a project
level.
Project Leadership • Frequency - 1 per week
Meetings • 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
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
9

10. Program Governance – External Meetings
A 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
• TM Leadership Team: Chee • To update TM leadership on the
overall program status
Systems Steering Weekly
Committee • To highlight issues and decisions
External (every
for Steering Committee guidance
Meeting Tuesday)
and direction
• • To update TM Systems
leadership on the overall program
Weekly status
CIO Systems
External (every
Update • To highlight issues and decisions
Friday)
for IT Leadership guidance and
direction
• Nova Leadership: • Internal Program meeting to run
through overall program status &
Nova IT Program Weekly potential impacts to the schedule.
Leadership External (every
Meeting Wednesday) • Any major escalations/issues
should be highlighted in the
Program Leadership meeting.
• Nova Leadership • Internal Program meeting to run
• TM Business: through overall program status &
Weekly potential impacts to the schedule.
iCarePrime Status
External (every
Meeting • Any major escalations/issues
Thursday)
should be highlighted in the
Program Leadership meeting.
10

11. Program Governance – Vendor Meetings
This structure is replicated with the various Vendors in order to discuss status and
escalate vendor specific issues
Meetings Type Frequency Key Attendees Purpose of Meeting
• Nova Leadership: • To review status of EMC status
Weekly • EMC Leads report
EMC Vendor
External (every • To discuss and escalate EMC
Status Meeting
Friday) issues and status
• Nova Leadership: • To discuss and escalate Oracle
issues and status
Weekly
Oracle Status
External (every
Meeting
Monday)
• Nova Leadership: • To review and escalate critical
Weekly • Oracle Leads: Oracle SRs
Oracle Critical
External (every
Account Call
Thursday)
11

12. Release Management
What components to be managed?
• Score Card
• Release Plan • Status
• System • Report of each • tracking
Each SDLC phase
Development phase in SDLC is tracked with
Lifecycle (SDLC) issues highlighted
detailed out in a •
waterfall chart •
•
12

13. Overall Release Plan
• 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)
13
13

14. Description of each phase within Release
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
14 14

15. Deliverables Management
• 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)
15
15

16. Status Tracking – Plan & Analyze
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.
16
16

17. Status Tracking – Design & Build
Plan Analyze Design Build Test Deploy
Overall Status Amber
Product Due Planned Application Actual
Date Siebel OSM Granite OBRM Portal
100%
14-Jan-11 100% 100%[100%] 100%[100%] 100%[100%] 100%[100%] N/A
[100%]
Direct
94%
25-Feb-11 100% 87.5%[84%] 89%[88%] 100%[100%] 100%[80%] N/A
[93%]
85%
IPVPN 25-Feb-11 100% 97%[95%] 99%[99%] 52%[51%] 94%[81%] N/A
[81%]
IPWholesale
GlobalIPVPN 50%
4-Mar-11 80% 74%[68%] 64%[59%] 36%[19%] 27%[13%] N/A
Last week’s % of [41%]
This week’s %
Global
4-Mar-11 0% 0% 0% 0% 0% completion
N/A Not Started
Ethernet of completion
HSBC 18-Mar-11 0% 0% 0% 0% 0% N/A Not Started
• 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.
17

18. Status Tracking –Test
Plan Analyze Design Build Test Deploy
• 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.
18

19. Status Tracking –Test
Plan Analyze Design Build Test Deploy
• 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.
19

20. Status Tracking – Deployment Check List
Plan Analyze Design Build Test Deploy
• 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.
20

21. Dependency Management
• 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.
21

22. Dependency Management
• A summary of dependencies is illustrated in Dependency Tree below.
• Overdue open dependencies are highlighted to the Steering Committee
22

23. Dependency Management
• 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
Traffic
# Description Status Actions
Light
1 RED Dorado Complete NBI Delivery Delay Due date: • Discussion conducted with Dorado. Dorado
28-Feb-11 confirm that delivery will be expedited. The
• Dorado Development team has initially 15-Apr-11 revised delivery of NBI is on 15-Apr TBD
reverted the NBI delivery date TBD
• Phase 1 (New Install): 1-Apr • Dorado PO issues – Dorado did not deliver
• Phase 2 (Modify): 15-Apr NBI on 1st Apr 2011 or 15-Apr as planned
• Both test lab and NBI is required to be fully
ready and deployed for NOVA SIT test by 1-
Apr
2 RED No onsite support identified for DORADO Due date: • Discussion still ongoing between DORADO
4-Apr-11 and TM.
• Dorado PO Issue – Dorado was unable to
provide support by 4-Apr-11
23

24. Change Request Management
• 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.
24

25. Vendor Management
A proper agreement must be made
between client and vendors to
ensure adequate support is provided
throughout project lifecycle and post
go-live
A good escalation model must be
established to ensure any critical
Critical
product defects that impact project
deadline, causes revenue loss and Accounts
production downtime is resolved
Escalation to Oracle
immediately Duty Manager/ Oracle
On-Site Support
Service Request Raised on Oracle
Hardware Metalink
Software Principals
25

26. Vendor Management
• 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.
26