Top Banner
#LEADit Chris Madden Improving Service Lifecycles with fewer surprises
30

Improving Service Lifecycles with fewer surprises€¦ · • Project Management -PMBOK/PRINCE2 • Architecture –TOGAF • Development –RUP/AGILE • Governance –COBIT •

Apr 24, 2020

Download

Documents

dariahiddleston
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: Improving Service Lifecycles with fewer surprises€¦ · • Project Management -PMBOK/PRINCE2 • Architecture –TOGAF • Development –RUP/AGILE • Governance –COBIT •

#LEADit

Chris Madden

Improving Service Lifecycles with

fewer surprises

Page 2: Improving Service Lifecycles with fewer surprises€¦ · • Project Management -PMBOK/PRINCE2 • Architecture –TOGAF • Development –RUP/AGILE • Governance –COBIT •

#LEADit

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

Page 3: Improving Service Lifecycles with fewer surprises€¦ · • Project Management -PMBOK/PRINCE2 • Architecture –TOGAF • Development –RUP/AGILE • Governance –COBIT •

#LEADit

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

Page 4: Improving Service Lifecycles with fewer surprises€¦ · • Project Management -PMBOK/PRINCE2 • Architecture –TOGAF • Development –RUP/AGILE • Governance –COBIT •

#LEADit

STS-134 International Space Station after undocking - NASA

Page 5: Improving Service Lifecycles with fewer surprises€¦ · • Project Management -PMBOK/PRINCE2 • Architecture –TOGAF • Development –RUP/AGILE • Governance –COBIT •

#LEADit

Fewer surprises - takeaway summary

• You need ITSM foundations

• Project/program management/governance framework is essential

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

Page 6: Improving Service Lifecycles with fewer surprises€¦ · • Project Management -PMBOK/PRINCE2 • Architecture –TOGAF • Development –RUP/AGILE • Governance –COBIT •

#LEADit

• <Consider a Space Mission Control shot>

Page 7: Improving Service Lifecycles with fewer surprises€¦ · • Project Management -PMBOK/PRINCE2 • Architecture –TOGAF • Development –RUP/AGILE • Governance –COBIT •

#LEADitRelease Process

Strategic“Plan”

Tactical“Build”

Operational“Run”

Initiation Planning Execution Delivery

ReleasePlanning“Pipeline”

Change and Configuration Management

Service StrategyService

DesignService Transition

Service

Operations

Portfolio Management

Release Go-Live“Implementation”

ELS

Project and Delivery Management

Technical Delivery

Release Delivery“Delivery”

Release Authority (RA) – Quality Assurance and Do-Ability Assessment

Release Authority

Dimension Input to RA

Development Approach Input to RA

Service Design Input to RA

Small Release

Medium Release

Large Release

1wk

2wks

4wks2 Weeks Go-Live

Change Lead Time

2 Weeks Go-LiveChange Lead Time

1 Week Go-LiveChange Lead

5 Weeks Requirement, Analysis Build and Test

12 Weeks Requirement, Analysis Build and Test

15-20 Weeks Requirement, Analysis Build and Test

2 Weeks Release Scoping

4 Weeks Release Scoping

6 Weeks Release Scoping

PRA for Large Projects

RG1 RG2 RG3 RG4 RG5

RG Release Gates

Page 8: Improving Service Lifecycles with fewer surprises€¦ · • Project Management -PMBOK/PRINCE2 • Architecture –TOGAF • Development –RUP/AGILE • Governance –COBIT •

#LEADit

Early Service Activation and ‘Service Design’

Started this in 2008 (before the ITSM process and tools update)

Page 9: Improving Service Lifecycles with fewer surprises€¦ · • Project Management -PMBOK/PRINCE2 • Architecture –TOGAF • Development –RUP/AGILE • Governance –COBIT •

#LEADit

“isn’t that just change management”.

This can be a short cycle (BAU) or a entire Service Lifecycle (and project)

Page 10: Improving Service Lifecycles with fewer surprises€¦ · • Project Management -PMBOK/PRINCE2 • Architecture –TOGAF • Development –RUP/AGILE • Governance –COBIT •

#LEADit

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

Page 11: Improving Service Lifecycles with fewer surprises€¦ · • Project Management -PMBOK/PRINCE2 • Architecture –TOGAF • Development –RUP/AGILE • Governance –COBIT •

#LEADit

Service change process and leverage of ITSM functions

Page 12: Improving Service Lifecycles with fewer surprises€¦ · • Project Management -PMBOK/PRINCE2 • Architecture –TOGAF • Development –RUP/AGILE • Governance –COBIT •

#LEADit

• Change, Risk and Issue Management

• Release Planning

• Persistent Documentation

• Operational Readiness

• Project Reporting and Governance

A project/program management framework is essential

Page 13: Improving Service Lifecycles with fewer surprises€¦ · • Project Management -PMBOK/PRINCE2 • Architecture –TOGAF • Development –RUP/AGILE • Governance –COBIT •

#LEADit

Service Lifecycle:Service Design and Acceptance view

Capability & Capacity

Assessment

Capability & Capacity

Assessment

Define The Service

Define The Service

Service Transition

Plan

Service Transition

Plan

Operating Costs

Operating Costs

Operational AcceptanceOperational Acceptance

Support Model

Support Model

Service Support

Documents

Service Support

Documents

Supportable &

Maintainable Service!

Supportable &

Maintainable Service!

Service Design is a key function!

Page 14: Improving Service Lifecycles with fewer surprises€¦ · • Project Management -PMBOK/PRINCE2 • Architecture –TOGAF • Development –RUP/AGILE • Governance –COBIT •

#LEADit

Capability & Capacity

Assessment

Capability & Capacity

Assessment

- Understand operational impacts early

- Determine capability & capacity gaps

- Identify operational processes & technologies that will be impacted

- Focus on mitigations & include as activities in project schedule

- Reduce surprises down the track

Define The Service

Define The Service

Service Transition

Plan

Service Transition

Plan

- Develop agreed support model & sourcing strategy

- Align model to SLA & capabilities

- Ensure roles & responsibilities are clear for business support

team, operational teams, & support partners

Operating Costs

Operating Costs

Operational AcceptanceOperational Acceptance

- Mechanism to check Service is ready to 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

Support Model

Support Model

Service Support

Documents

Service Support

Documents

- Provide agreed operational CAPEX & OPEX estimates for Business Case

- Ensure operational resource, infrastructure, training, licensing & maintenance costs are included

Supportable &

Maintainable Service!

Supportable &

Maintainable Service!

- Confirm Service Level

Requirements

- Identify Service Owner(s), who

becomes a major stakeholder

- Understand the related

Business and Technical

Services

- Detail on activities required to mitigate

capability & capacity gaps, & transition

to a supportable Service

- Schedule of mitigation activities &

which operational resources will be

required when

- Early Lifecycle Support model

- Detailed support & maintenance

instructions

- Agreed roles & responsibilities for

operational teams

- Administration & incident resolution

guides

- Monitoring & proactive tuning guides

Page 15: Improving Service Lifecycles with fewer surprises€¦ · • Project Management -PMBOK/PRINCE2 • Architecture –TOGAF • Development –RUP/AGILE • Governance –COBIT •

#LEADit

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

Page 16: Improving Service Lifecycles with fewer surprises€¦ · • Project Management -PMBOK/PRINCE2 • Architecture –TOGAF • Development –RUP/AGILE • Governance –COBIT •

#LEADit

Release Planning

Change Management

Release Deployment

Tactical

Governing

Strategic

Release Elements

Release Deployment Management -“Run”

Deployment and rollback planning, business and operational readiness including communication of the overall release scope

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

Release Pipeline Management - “Plan”

Release plans for multiple years for delivery of new or upgrade to technology, infrastructure, software and business practices

Page 17: Improving Service Lifecycles with fewer surprises€¦ · • Project Management -PMBOK/PRINCE2 • Architecture –TOGAF • Development –RUP/AGILE • Governance –COBIT •

#LEADit

• 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

Operational Readiness

Page 18: Improving Service Lifecycles with fewer surprises€¦ · • Project Management -PMBOK/PRINCE2 • Architecture –TOGAF • Development –RUP/AGILE • Governance –COBIT •

#LEADit

Change - the path to the CAB

• ‘Master changes’

• Transition and implementation plans

• Acceptance testing (and OAT)

• Governance (Release Authority (PRA))

• Change Advisory Board approval

Page 19: Improving Service Lifecycles with fewer surprises€¦ · • Project Management -PMBOK/PRINCE2 • Architecture –TOGAF • Development –RUP/AGILE • Governance –COBIT •

#LEADit

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

Page 20: Improving Service Lifecycles with fewer surprises€¦ · • Project Management -PMBOK/PRINCE2 • Architecture –TOGAF • Development –RUP/AGILE • Governance –COBIT •

#LEADit

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)

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

Defect Register KEDB

Product Backlog

Page 21: Improving Service Lifecycles with fewer surprises€¦ · • Project Management -PMBOK/PRINCE2 • Architecture –TOGAF • Development –RUP/AGILE • Governance –COBIT •

#LEADitRelease Process

Strategic“Plan”

Tactical“Build”

Operational“Run”

Initiation Planning Execution Delivery

ReleasePlanning“Pipeline”

Change and Configuration Management

Service StrategyService

DesignService Transition

Service

Operations

Portfolio Management

Release Go-Live“Implementation”

ELS

Project and Delivery Management

Technical Delivery

Release Delivery“Delivery”

Release Authority – Quality Assurance and Do-Ability Assessment

Release Authority

Dimension Input to RA

Development Approach Input to RA

Service Design Input to RA

Small Release

Medium Release

Large Release

1wk

2wks

4wks2 Weeks Go-Live

Change Lead Time

2 Weeks Go-LiveChange Lead Time

1 Week Go-LiveChange Lead

5 Weeks Requirement, Analysis Build and Test

12 Weeks Requirement, Analysis Build and Test

15-20 Weeks Requirement, Analysis Build and Test

2 Weeks Release Scoping

4 Weeks Release Scoping

6 Weeks Release Scoping

PRA for Large Projects

RG1 RG2 RG3 RG4 RG5

RG Release Gates

Page 22: Improving Service Lifecycles with fewer surprises€¦ · • Project Management -PMBOK/PRINCE2 • Architecture –TOGAF • Development –RUP/AGILE • Governance –COBIT •

#LEADit

Key roles view

• Project side:

– Project Manager

– Architect (ITSM aware)

– Release and deployment (manager and co-ordinator)

– Organisational Change specialists

• Operations side:

– Service Designer

– Environment builder

– Operational Readiness (team)

– Early Lifecycle Support (team)

Once identified: the Service Owner

Page 23: Improving Service Lifecycles with fewer surprises€¦ · • Project Management -PMBOK/PRINCE2 • Architecture –TOGAF • Development –RUP/AGILE • Governance –COBIT •

#LEADit

• Service Design:

– Service template

– Document review (service)

– Operational Acceptance Checklist (also SAC)

Toolkit summary

• Release:

– Complexity Assessment

– Gates

– Governance

Page 24: Improving Service Lifecycles with fewer surprises€¦ · • Project Management -PMBOK/PRINCE2 • Architecture –TOGAF • Development –RUP/AGILE • Governance –COBIT •

#LEADit

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

Page 25: Improving Service Lifecycles with fewer surprises€¦ · • Project Management -PMBOK/PRINCE2 • Architecture –TOGAF • Development –RUP/AGILE • Governance –COBIT •

#LEADit

Page 26: Improving Service Lifecycles with fewer surprises€¦ · • Project Management -PMBOK/PRINCE2 • Architecture –TOGAF • Development –RUP/AGILE • Governance –COBIT •

#LEADit

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

Page 27: Improving Service Lifecycles with fewer surprises€¦ · • Project Management -PMBOK/PRINCE2 • Architecture –TOGAF • Development –RUP/AGILE • Governance –COBIT •

#LEADit

Fewer surprises - takeaway summary

• You need ITSM foundations

• Project/program management/governance framework is essential

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

Page 28: Improving Service Lifecycles with fewer surprises€¦ · • Project Management -PMBOK/PRINCE2 • Architecture –TOGAF • Development –RUP/AGILE • Governance –COBIT •

#LEADit

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

Page 29: Improving Service Lifecycles with fewer surprises€¦ · • Project Management -PMBOK/PRINCE2 • Architecture –TOGAF • Development –RUP/AGILE • Governance –COBIT •

#LEADit

Additional Resources• Presentations on this topic since 2009 - please write

• The key colleagues who built Service Design/Activation:

[email protected]

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)

Page 30: Improving Service Lifecycles with fewer surprises€¦ · • Project Management -PMBOK/PRINCE2 • Architecture –TOGAF • Development –RUP/AGILE • Governance –COBIT •

#LEADit