Friday, May 17, 2013
Practitioner Radio 41 - The Evolution & Children Of Service Level Management
Customer Satisfaction Is All About Strong Positive Relationships!
As IT is emerging from its technology centric shell and stepping up to its role as a strategic partner and service provider within the business value system the roles required to manage this relationship have evolved over time.
The evolution of ITIL from its first versions to the recent release of the 2011 edition have seen major shifts in the practices and processes supporting customer engagement and relationship management. Join Chris and I as we discuss this evolution of Service Level Management as it has spun off necessary practices such as Business Relationship Management, Service Catalog Management and Supplier Management.
Show Notes:
- Good reactions to the last show on Scrum
- Biology and ITIL – two subjects you wouldn’t have thought go together
- Major change over last 3 versions of ITIL – what has happened?
- History of SLM – big shifts. In v2 service agreement was major part, also definition of a service, catalogue concept was there, customer engagement – used all to be part and parcel but was focused on process. Version 3 focused on service as the reason for all of this. In recent edition 2011e business relationship management was extracted but also promoted higher.
- What is the role of service level management now? Or is SLM a system comprised of 3 processes.
- Underpinning contracts still need to be done
- Become more of a back office supporting structure rather than on stage presence
- Processes seem to go from structural, to front & centre, to back office
- Gathering data, analysis, equipping the BRM by giving them the data they need to make decisions
- Should still be an accountable person (internal owner) for outsourced parts – accountability cannot be outsourced
- How do you get started? Start small. First agree that SLAs and BRM are important
- It’s all about leadership
- Don’t judge yourself too harshly for failing
- People sometimes don’t want to take on accountability because they think it’s an increase in workload – in fact it can be a reduction. It’s about clearly communicating your needs
- Brené Brown’s book on accountability: The gift of imperfection
Troy’s Thunder Bolt Tip of The Day: If all these things evolved over time within ITIL why not look at the same thing for your organization
For additional content on this subject:
Practitioner Radio Episode 3 - Service Level Management and SLAs
Practitioner Radio Episode 7 - The IT Service Catalog
Practitioner Radio Episode 15 - Business Relationship Management
“The more you engage with customers the clearer things become and the easier it is to determine what you should be doing.” ~John Russell, President, Harley Davidson
To subscribe to Pink’s Podcasts on iTunes
Thursday, April 18, 2013
Practitioner Radio 40 - Using Agile / SCRUM for ITSM Projects
Sometimes Rapid Incremental Improvement is More Important Than Game Changing Transformation
At Pink my team and I have the privilege of having several conversations a week with customers who want to improve their ability to deliver customer value via improved practices. However, before offering advice we have learned that it is important to ask questions and listen carefully to how organizations want to improve.
For example: In many cases the company we are talking to has a time sensitive goal of moving everyone in IT off a current tool or should I say collections of processes and tools onto a common process and 1 new ITSM tool in as short a time as possible. No matter how you look at this type of goal it represents a Major Transformation that will mean significant and rapid change for everyone within the scope of the project.
However, there are times where the focus is on achieving rapid incremental improvements (Quick Wins) focused and prioritized based on the “Customer Value Perspective” not internal IT efficiencies or major systems upgrades.
In the latter example a more Agile approach to change is perhaps a better fit. In fact the this scenario is a perfect fit for an AGILE / SCRUM approach to Process Improvement.
Join Chris and I in this episode of PR Radio where we look how organization’s can leverage this popular development and project methodology in respect to ITSM Projects.
NOTES:
- Pink-washed: overwhelmed, fun
- Scrum in 10 minutes video
- Scrum is a development methodology
- Agile is a principle in product development that looks at short sprints to get small packages print or production ready
- TLC told us in the 90’s - don’t go chasing Waterfalls!
- Prince2 says check back every big block but Scrum focuses on even smaller sets of tasks – sprints and releases
- Figure out your release then evaluate
- User stories drive product backlog and wish list
- Daily meetings – Kanban /scrum meetings
- Easier to measure success - quantifiable
- Focus on value – outcome for customer. What have you done for me lately?
- Prioritize tasks by customer need / pains
- Voice of customer is not usually a natural skill for IT people
- Outside-In thinking
- Assessment and recommendations should be written with customer in mind
- Look at short term, mid-term and long term releases
- Transformation is very different to incremental improvement – transformation is about fast, over-arching change, whereas incremental improvement is about getting better by making small changes
- Design, build & deploy in pieces rather than all at once
- Suits our ‘distracted’ society. We’re all in constant change
- Different people suit different methodologies – not necessarily either / or
- A sprinty spark (or a sparky sprint) can get you moving
- If it’s not about the customer it’s a waste of money
- See book Run, Go, Transform
- Dev and Ops aren’t used to thinking about end customer value – more asset optimization
- Could apply Scrum to personal human objectives
- Do we consider ourselves when putting customer first?
- Moving the family across the country is a transformation – moving schools, new house, address changes, insurance, jobs etc everything pretty much has to be done all at once. It would be possible to do it incrementally but it would take a lot longer. Some things are not suited to scrum approach.
- Scrum is good when you have little budget – make small changes you can do yourself, bit by bit, build momentum as it proves value and get buy in
Troy’s Thunder Bolt Tip of The Day: consider using an agile scrum methodology to achieve your continual service improvement goals, especially when you’re after incremental improvement
Troy’s and Chris’s Thoughts What Are Yours?
We must not, in trying to think about how we can make a big difference, ignore the small daily differences we can make which, over time, add up to big differences that we often cannot foresee. ~Mariam Wright
To subscribe to Pink’s Podcasts on iTunes
Saturday, March 09, 2013
Practitioner Radio 39 - Service Orchestration
All Good Orchestra’s Need A Common Score In Order To Play In Harmony Or Else They Delivery Cacophony
The power of a good analogy is that it allows someone to describe a complex and sometimes conceptual idea in a simple manner that most people can understand without interpretation or detailed explanation.
This is in essence the principle behind the term “Service Orchestration”. First: Consider the premise that today’s Enterprise IT functions are made up of a mixed group of diverse suppliers (internal and external) and becoming even more diversified and complex as we integrate cloud and online services. Second: Now ask yourself’s how in the world will an organization keep all these moving parts synchronized in order to play their designated part in the larger value service system or even get them moving in the same direction?
To achieve this desired result you need three key critical success factors:
- Strong IT Leadership that believes in the principle that all players in the IT value system need shared values, priorities and practices in order to deliver service in a harmonious fashion.
- A defined and shared IT Operating Model outlining they key elements of the Demand, Plan, Build, Run Value stream
- A set of Enterprise IT Governance Roles that will play the role of “Conductor” for all the various parties participating in the Service Orchestra Join Chris Dancy and I Live at Pink13 as we explore these key principles:
- Recorded in front of a live audience at Pink13
- PR - 19hours of audio!
- ‘Outcome Leasing’ is happening
- Need harmony between suppliers
- Even Enterprise Architecture is struggling
- Is information actually used?
- Essentials for an orchestra: 1 conductor 2 a common score
- Conductor must understand the full score
- Not everyone has to be involved in writing score
- Who is the conductor?
- Don’t blame the supplier when you haven’t got a common score
- Not likely to get this right first time
- Orchestras within orchestras but no-one wants responsibility for the entire picture
- Must be built for change
- The Service Lifecycle Value Stream is a ‘score’
- The IT Operating model is the score at a Management Practice level
- The Service Management Office has to be broad thinking
- Systems thinking essential – everything is related to everything
- Organizational Design Challenges stemming from the Industrial Revolution / task specialization
- CMDB is different now – it’s a system diagram of relationships
- Number 1 issue is lack of systems thinking
- Fixing the bigger problem creates the value
- No-one is managing above the domain level
- Without a common score and conductor you won’t make music anyone wants to hear
- And the band played on…
Troy’s Thunderbolt Tip of the Day: you have to understand and manage the larger system for generating value to delivery service orchestration
Troy’s and Chris’s Thoughts What Are Yours?
“Sometimes there is a 36-piece orchestra going off in my stomach.” ~Willie Nelson
To subscribe to Pink’s Podcasts on iTunes