Dec 2012 Evening Talk - Managing Complex Project
2 likes1,273 views
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.
![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](https://image.slidesharecdn.com/eveningtalk131212managingcomplexproject-121216035158-phpapp02/85/Dec-2012-Evening-Talk-Managing-Complex-Project-17-320.jpg)
Dec 2012 Evening Talk - Managing Complex Project
- 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