Improving Service Lifecycles with fewer surprises Chris Madden
Sydney Water Supplies water (1.4 billion litres a day), wastewater, recycled water and some stormwater services to over 4.6 million people each day Australia s largest water utility ($30 billion in assets spread over 12,700 2 km) 250 plus IT team members - CIO reports to the CEO Significant legacy (mainframe) systems, COTS (Siebel, Maximo, PeopleSoft, Oracle UCM etc.), SaaS (SABA, O365) and more Large program of work (POW) deals with high technical complexity Capability strategy: Mobility, Cloud, Integration, Identity & Security and Information
Fewer surprises in principle A newly delivered/updated service should: Do what you expect it to do Operate reliably and dependably over its life span Not require many unplanned changes to stay stable Functional changes don t require extensive redesign Cost-efficient to operate and support Deliver intended business outcomes Perform optimally even during periods of heavy use Scale to meet business need If these expectations are not met the quality is thought of as poor. This will be mainly due to: The service's design does not meet the business's needs. The way the service is managed does not meet the business's needs Adapted from Sharon Taylor 2011 How to build an IT Service Management strategy Challenge: Deliver services with no surprises despite cost constraints, vendor and method changes
STS-134 International Space Station after undocking - NASA
Fewer surprises - takeaway summary Begin with the end in mind - proper design of the services you will run Service Design Change the IT team/customer view and language (KE) Ensure your SMEs are engaged (by projects) Insist on early lifecycle management think Release and Change Management (needs ITSM expertise) You need ITSM foundations Project/program management/governance framework is essential
<Consider a Space Mission Control shot>
Initiation Planning Execution Delivery Service Strategy Service Design Service Transition Service Operations Strategic Plan Tactical Build Operational Run Portfolio Management Release Planning Pipeline Project and Delivery Management Release Authority (RA) Quality Assurance and Do-Ability Assessment RG1 RG2 RG3 RG4 RG5 Technical Delivery Release Delivery Delivery PRA for Large Projects Change and Configuration Management Release Go-Live Implementation ELS Small Release Medium Release Large Release Release Process Release Authority 2 Weeks Release Scoping 4 Weeks Release Scoping 6 Weeks Release Scoping Dimension Input to RA 5 Weeks Requirement, Analysis Build and Test 12 Weeks Requirement, Analysis Build and Test 15-20 Weeks Requirement, Analysis Build and Test Development Approach Input to RA 1 Week Go-Live Change Lead 2 Weeks Go-Live Change Lead Time 2 Weeks Go-Live Change Lead Time Service Design Input to RA RG Release Gates 1wk 2wks 4wks
Early Service Activation and Service Design Started this in 2008 (before the ITSM process and tools update)
isn t that just change management. This can be a short cycle (BAU) or a entire Service Lifecycle (and project)
Do standards and frameworks have the answer? Project Management - PMBOK/PRINCE2 Architecture TOGAF Development RUP/AGILE Governance COBIT ITSM ISO20000 and ITIL 2011 Risk Risk IT / ISO31000 All of the above help none deliver a set of coordinated Service Design and Transition functions and processes
Service change process and leverage of ITSM functions
Change, Risk and Issue Management Release Planning Persistent Documentation Operational Readiness Project Reporting and Governance A project/program management framework is essential
Service Lifecycle: Service Design and Acceptance view Define The Capability & Service Capacity Assessment Service Operating Transition Costs Plan Service Design is a key function! Support Model Operational Acceptance Service Support Documents Supportable & Maintainable Service!
-Confirm Service Level Requirements -Identify Service Owner(s), who becomes a major stakeholder -Understand the related Business and Technical Services Define The Service Capability & Capacity Assessment - Understand operational impacts early - Determine capability& capacity gaps -Identify operationalprocesses& technologiesthat will be impacted -Focus on mitigations & include as activitiesin project schedule - Reduce surprises down the track - Detail on activities required to mitigate capability & capacity gaps, & transition to a supportable Service -Scheduleof mitigation activities & which operational resources will be required when - Early Lifecycle Support model Service Transition Plan Operating Costs -Provide agreedoperational CAPEX & OPEX estimates for Business Case -Ensure operational resource, infrastructure, training, licensing& maintenance costs are included -Develop agreedsupport model & sourcing strategy -Align model to SLA & capabilities -Ensure roles & responsibilities are clear for business support team, operational teams, & support partners Support Model Operational Acceptance -Mechanism to checkservice is readyto be commissioned no surprises -Covers all transition requirements including operational readiness, resolution of operational risks & issues, & support documentation -Allows Service Owners to make informed decisions when accepting the Service - Detailed support& maintenance instructions -Agreed roles& responsibilitiesfor operational teams - Administration & incident resolution guides - Monitoring & proactive tuning guides Service Support Documents Supportable & Maintainable Service!
Release Management Release capability uplift commenced 2012 Driver - significant release complexity Service Activation/Design alignment Strong ITSM alignment (Release and Deployment / Configuration / Change) Production Readiness Authority Release Authority Release Management significantly aligned with ITSM foundation processes
Release Planning Release Elements Change Management Release Deployment Tactical Release Pipeline Management - Plan Release plans for multiple years for delivery of new or upgrade to technology, infrastructure, software and business practices Release Delivery Management - Build Understand the solution design, monitor the quality of the build, suitability of solution, manage the contention, complexity and dependencies for the overall release Governing Strategic Release Deployment Management - Run Deployment and rollback planning, business and operational readiness including communication of the overall release scope
Operational Readiness Lifecycle triggers used for SME engagement (ideally Release gating) Application and infrastructure reps needed Currently artefact preparation and review driven Agile/SCRUM requires SME imbedding Methods: Doc review discipline / Weekly meetings Ensuring SME engagement requires a method
Change - the path to the CAB Master changes Transition and implementation plans Acceptance testing (and OAT) Governance (Release Authority (PRA)) Change Advisory Board approval
Early Lifecycle Support Starts immediately after customer PVT Key process is daily triage meetings involving support/project and customer Needs quality ITSM tools and reporting support Feeds into service lifecycle via Known Errors
Lifecycle problems and known errors A common language - has been key to aligning infrastructure/ application / project and customer lifecycle collaboration Multiple lifecycle touch points: Release scope planning (including AGILE product backlog) Delivery (KEs addressed by release/change) Defect Register Defects transitioned to KEDBs ELS and BAU aggregation of KEs for next cycle Our interpretation of KEs for business acceptable workarounds and PKEs (Problem KE) KEDB Product Backlog
Initiation Planning Execution Delivery Service Strategy Service Design Service Transition Service Operations Strategic Plan Tactical Build Operational Run Portfolio Management Release Planning Pipeline Project and Delivery Management Release Authority Quality Assurance and Do-Ability Assessment RG1 RG2 RG3 RG4 RG5 Technical Delivery Release Delivery Delivery PRA for Large Projects Change and Configuration Management Release Go-Live Implementation ELS Small Release Medium Release Large Release Release Process Release Authority 2 Weeks Release Scoping 4 Weeks Release Scoping 6 Weeks Release Scoping Dimension Input to RA 5 Weeks Requirement, Analysis Build and Test 12 Weeks Requirement, Analysis Build and Test 15-20 Weeks Requirement, Analysis Build and Test Development Approach Input to RA 1 Week Go-Live Change Lead 2 Weeks Go-Live Change Lead Time 2 Weeks Go-Live Change Lead Time Service Design Input to RA RG Release Gates 1wk 2wks 4wks
Key roles view Project side: Project Manager Architect (ITSM aware) Release and deployment (manager and coordinator) Organisational Change specialists Once identified: the Service Owner Operations side: Service Designer Environment builder Operational Readiness (team) Early Lifecycle Support (team)
Toolkit summary Service Design: Service template Document review (service) Operational Acceptance Checklist (also SAC) Release: Complexity Assessment Gates Governance
Thinking about the cloud Often existing SaaS services - with very limited integration limited ITSM requirement Observations on moving to XaaS (Public & Hybrid): Service lifecycle must be formalised SLA management and governance essential Think NIST #4: Measured Service Service Design (and operational use cases) Release Management does not change IaaS and PaaS need ITSM built in
Thinking about DevOps Consider: value stream (where defined/where delivered) Deployment consistency across environments Dependency mapping (Change and Configuration) Checkpoints, certifications/approvals, documentation Apply: Service Lifecycle Management & Service Design The new Release and Deployment (including automation) ELS, KE management Must have the foundation processes
Fewer surprises - takeaway summary Begin with the end in mind - proper design of the services you will run Service Design Change the IT team/customer view and language (KE) Ensure your SMEs are engaged (by projects) Insist on early lifecycle management think Release and Change Management (needs ITSM expertise) You need ITSM foundations Project/program management/governance framework is essential
Action Plan Monday Morning Consider the level of surprises you have now or will have Consider legacy/large projects/bi-modal/cloud/agile/devops Release Mng Next 90 Days Management buy in!!!!!! Identify Designer/Analyst & Release talent consider building Transition team Review your end to end Service pipeline and identify target services Build and /or align Release and Deployment Select/create the suggested KIS methods and tools for Design and Release Next 12 to 24 months (or 3 to 12) Train and deploy Review metrics for Release and Service stability Value/Outcomes/Cost/Risk Assess, iterate
Additional Resources Presentations on this topic since 2009 - please write The key colleagues who built Service Design/Activation: o Phil Maher (Operations Manager original sponsor now ITSM Practice Lead Vitae Partners) o Tony Ashworth and Terry Wingrave (Infrastructure Management) o Roneel Datt (Service Design lead Operations Analyst) o Graham Wilson (Service Designer Operations Analyst) o Noemi Javier (End to End Release guru and ITIL Expert) o Graham Barker/Shaun Williams/Swati Purohit (Oakton team) chris.madden@vitaepartners.com.au