Business-Provider Maturity Model

In today’s business climate it is imperative that the IT Service Provider not only understand what the business strategy is, but be able to initiate and deliver services that not only support it, but help to shape it.  This can be successfully accomplished by ensuring that the service portfolio remain aligned to the business needs.  Over time these requirements and demand for services change and mature.  The Business / Provider Relationship is integral in keeping the demand and supply of these services and capabilities appropriately and continuously aligned.  One of the tools engaged for this task is the “Business-Provider Maturity Model”.

The Business-Provider Maturity Model is a way to help surface and understand the growth in maturity of business demand for Provider services and capabilities, and a Provider organization’s maturity of supply capabilities needed to both satisfy and shape that demand. Many maturity assessments are very IT centric assessing the ability of the Service Provider to satisfy demand from the business. The key difference here is that we also need to understand the businesses ability in being able to exploit the IT Service Providers capabilities to enhance the business strategy. It is a means of driving dialog about business demand and Provider maturity and how these elements continue to mature and grow. The model can be used for the entire enterprise or for a particular business unit or Provider capability.

In its simplest form, the model is an S-shaped learning curve—the business learning to exploit technology and the Provider organization learning to become efficient and effective in delivering services and, especially as maturity increases, shaping business demand.  Business executives find the model’s simplicity appealing. They can easily interpret the concepts behind business demand maturity and are able to use the model to analyze how their demand maturity is evolving over time. This enables them to engage in meaningful dialogue with Provider leadership about the business implications of both demand and supply maturity.  In most cases a basic three level model is utilized, however the number of levels is arbitrary. In some cases a 5-level model can be engaged, which can be useful because it represents a finer-grained approach.

To the left of the S-curve are the characteristics of business demand at each of 3 the levels. To the right are the corresponding goals of Provider supply.  It is important to understand this is a developmental model.  That means it is cumulative.  The demand at lower levels never goes away, the business always wants the lights kept on.  A Service Provider that fails to supply against this demand will lack credibility and the capability to move up the maturity curve.  As business demand matures to Level 2, Level 1 demand does not go away, it becomes a fundamental expectation.

Level 1 business demand is typically generated from functional and geographic silos which means it is often fragmented. This can be frustrating for the Service Provider, who are able to look across the enterprise and see many opportunities for cross functional processes and collaboration, but are often unable to communicate these concepts.

Level 1 demand is to provide basic services and solutions while ensuring stabilized operations and support, with an overarching goal of reducing the costs of doing business.

Level 2 demand, which continues to include Level 1 demand, focuses on enabling business partnerships, enterprise integration and consolidation of management information. Level 2 supply is focused on establishing common infrastructure and management information enterprise solutions. Level 2 supply also focuses on building credibility, improved service/ solution delivery, with attention to portfolio management, service management and getting faster at delivering solutions.

Level 3 demand, which now includes Level 1, 2 and 3 demand, addresses strategic and technology capabilities, which enable the convergence of business and IT capabilities which in turn enable business growth and innovation. It tends to be much more externally focused than Level 1 and 2, interested in business intelligence, rapid experimentation and collaboration with other business units, customers and suppliers.

http://www.itsmacademy.com/resourcecenter

Nine Guiding Principles for ITSM or… for Everyday Life

ITIL Practitioner focuses on nine guiding service management principles that distil the core message to facilitate improvement and success at all levels.   The principles not only guide providers who want to adopt a good approach for successful products and services but can also be applied to ensure our day to day success.  Yes, that’s right!  These principles could be applied to buying a car, ordering food and more.    

Example:  I want to purchase a car.

Guiding Principles

1) Focus on VALUE-  I need a car but I don’t want to exceed my budget for this.  Value for me means awesome performance and that this car looks amazing. It must be a good fit and be cost effective. Good luck, right?   Value is determined by price but also by performance and perception.

2) Design for Experience –  Here I would be looking for something that is durable, has lots of techno gadgets built into the dash and if it is luxurious  when I get into it… even better.   If it just looks good but is not functional than it is not fit for the experience.   The provider of this vehicle will have to know their audience and who their customer base is. They will have to know the customer needs for such a car and ensure that they are able to meet them viewing the customer experience holistically. Value can only be determined by the consumer, NOT by the designer or the sales rep.

3) Start Where You Are. – Leverage what is already available.  ITIL sayslLook objectively at the current state. Of course I will have to look at any risk involved too. The Engine, carburetor, and overall functionality is a must but I should also have the color and model that deliver value to me.

4)  Work Holistically – All elements must work harmoniously together to deliver results. As with any service the outcome must be fit for purpose and fit for use.  Addressing only one element without looking at the overall product with features could result in a very expensive frustration.  I must focus on the bigger picture rather than just one element.  If I have a great engine but the vehicle is rusted and ugly, that is not an option.  Example:  Let’s say that I have selected a great performing vehicle and then decide that a sun roof is a required element for me.  If the reviews show many consumers are unhappy due to leaks from this then the warranty or assurance of value from that overall vehicle is diminished; even if the engine, carburetor, and all other functional requirements are there.  I not only want the functionality of a good performing car, the beauty and warranty or assurance that it will not cause trouble must also be there to deliver true value.

5)  Progress Iteratively- I have the big picture now and the look I am going for. OK so maybe I won’t be able to get all of the nice to have features or all of the techno gadgets.  Price matters.  I will need to separate my must haves from nice to haves.  Once that is done then I can begin to add elements accordingly to complete this vision.  My minimum viable product is the functionality of the engine, good gas mileage, and performance.

6) Observe Directly – While it is true that some things can only be understood through observing and measuring, direct observation is the first and preferred option.  Although the car that I have now selected looks right I know that I am going to have to take this for a test drive to observe how it feels and runs on the road.  The reviews and historical data (metrics) alone might not give a true picture of what I thought this car really is.  I do not want to make assumptions here.  Try it on for size.

7) Be Transparent – Best practice for service providers state that leaders at various levels should provide appropriate information relating to the quality or the improvement in their communication with others.  Therefore, I am bringing with me my friend the mechanic.  Before I invest I want a qualified recommendation from someone I know will be open and transparent.

8) Collaboration – Although I value the input from others, my preferences and perceptions must be considered so that the end results are a win/win. Another aspect of transparency and collaboration is that accomplishments are communicated and celebrated so I am sure we will have to leave the dealership and celebrate our decision.   This will emphasize the importance and value of my friend and a sense of pride for participating. 

9)  Keep it Simple – As an IT Service provider we know that when analyzing a process, service or improvement, we have to consider “Does it create value?”.  As it relates to purchasing a car, if I get sidetracked and start looking at too many features in lieu of the functionality and performance that really deliver value I will regret this purchase. 

OK, buying a car not your thing?   Take these nine ITIL practitioner principles and apply them to any purchase or day to day service.  They work.  You might want to have fun and ask your staff to do the same.  It is a fun way to embrace these simple yet critical principles for the provisioning of services.

For ITIL Practitioner Training and Certification -  click here

The Business Relationship Maturity Model

The Business Relationship Maturity Model (BRMM) is a way to help surface and understand the maturity of the relationship between a Provider (internal IT organization) and their Business Partner. This is not about the maturity of the BRM role or process.  This is about the maturity of the Provider/Business Partner relationship and therefore must take into account the perspectives of each party. The BRMM is made up of 5 levels, each with a descriptive tag, and represents a relationship maturity continuum. Level 5 is the highest and described as strategic partnering, Level 4 is trusted advisor, Level 3 is service provider, Level 2 is order taker and Level 1 being the lowest or ad hoc.

Level 1 Ad Hoc: From the Business Perspective (BP) it’s, can’t even get my providers attention, results cost too much, delivers too little and takes too long.   From the Provider’s Perspective (PP) it’s: I’m too busy to think about anything other than I’m too busy.   Characteristics of relationship (COR) are: unmanaged demand, unclear rules of engagement and no clear sense of value. To move to the next level the Business must embrace the reality of the existing capabilities and the Provider must establish demand management principles.

Level 2 Order Taker:  (BP) I engage my provider when I need something so they stay out of my way when I don’t need them. (PP) We are asked to be predictable but there is no way to forecast demand so we know we disappoint our business partners more often than not.  (COR) Frequent misperceptions build distrust and reactive course changes.  Prioritized demand based upon weak data, we/they relationship (antagonistic) and provider is completely reactive.  To move to the next level Business must embrace the BRM role and Service MGMT.  The provider must establish BRM and Service MGMT excellence.

Level 3 Service Provider: (BP) My provider prevents me from making big mistakes but I’m not always sure which direction we are heading. (PP) Our business partners help set priorities, but we are always behind. (COR): The routine is routine but innovation is a challenge, services are stable but major project deliverables are inconsistent, costs are transparent but value is subjective. To move to the next level the business must engage the provider in strategic thinking.  The provider must pursue Portfolio and Transition MGMT excellence.

Level 4 Trusted Advisor: (BP) My Provider is helpful and reliable. (PP) Our business partners understand our capabilities, works with them and helps to improve them.  (COR) Mutual understanding of capabilities and needs, portfolio is aligned to business needs and sense of value from investments. To move to the next level the business must embrace business value realization.  The provider must embrace continuous improvement.

Level 5 Strategic Partner: (BP) My provider is integral to business success and growth and helps me succeed.  (PP) We work together with our business partners to survive and prosper.  (COR) Shared goals for maximizing value, shared risks and rewards, quality data is being produced, innovation is cultural, complete convergence.

There are several ways to engage this model in helping your organization build a more agile business. It can be used to assess the current maturity level of your business/provider relationship and create and established an agreed baseline.  You can then incorporate this baseline to establish a strategic plan to identify improvement opportunities and create a timeline for maturing your organization through the 5 levels of the model. It provides the information to educate your BRM team and provider leaders on what the current state is and how they can engage to elevate business relationship maturity. It can also help to shape your approach on how the business & the provider can become strategic partners and move the organization forward and thrive.

For more information: http://www.itsmacademy.com/brmp

Rugged DevOps

Rugged DevOps is a method that includes security practices as early in the continuous delivery pipeline as possible to increase cybersecurity, speed and quality of releases beyond what current DevOps practices can yield alone. (1) “Rugged “describes software development organizations which have a culture of rapidly evolving their ability to create available, survivable, defensible, secure and resilient software. (2)

As business increasingly relies on agile software development, the absence of matching fast-moving security methodologies in the delivery pipeline will essentially increase the risk of a security breach or a cyberattack. Security staff must be imbedded into cross functional teams to ensure a more sustainable and less risky continuous deployment value chain (continuous integration, continuous delivery and continuous testing). The bad guys have already acquired these skills and the use of automation to engage in a continuous attack on our defenses.

Security was named as the number one DevOps obstacle by 28 percent of enterprises. (3)  Security needs to be engaged early and often.  If the Dev organization is at a maturity level where daily builds and releases are common, come up with a suite of models that allow you to do some level of testing and can conform to the condensed cycle times. By moving away from a waterfall set of security methodologies and adopting and adapting scrum practices, security can engage earlier and more often in the development lifecycle.  If you are not part of the solution people will go over or around you.  

DevOps is a cultural movement.  Changing the way we think and do things takes time. Culture doesn’t change until the way think changes.  Think about the things that you may have in common with development and operational teams and try to build on those commonalities.  We are more alike than we are different.

As with any DevOps initiative automation is key.  Reliance on manual testing just doesn’t enable the kinds of delivery speeds businesses are looking for today.  It doesn’t mean that some of that manual testing methodology goes away, but it may be used as a back up to the automated testing when necessary.  Security teams should be thinking about ways to automatically integrate manual testing results back into the pipeline. (4)

Security must be engaged at the strategy and design stages of the lifecycle.  Security concerns and perspectives have to be incorporated into requirements before any code or design work is done.  This way we can ensure that available, survivable, defensible, secure, resilient software and architecture get created.

DevOps is all about security “shifting left” to find security issues as early in the development life cycle as possible. By integrating security tools into your continuous integration process, security teams can engage their highly effective skills to uncover and eliminate vulnerabilities early in the development cycle. The earlier you find an issue the cheaper and easier it is to fix, creating big wins for both the provider and the business.

For more information:  http://www.itsmacademy.com/resourcecenter

(1)    Forrester Research

(2)    Rugged Software.com

(3, 4) Ericka Chickowski

KPIs and SLAs

A short while ago I was asked this question from one of our reader: “I want to set a KPI around how much of the time we meet the SLA. Like 'meeting the SLA x% of the time'. Can someone advise what would be that 'x'? What is the common practice?  Is there an industry standard around this?”  I’m going to have to go with the consultant answer and say it depends.   First, are we talking about a single service to a single customer? Are we talking about multiple services to multiple customers or somewhere in between those two extremes?

Your SLAs should include details of the anticipated performance that your customer expects.  First thing you need to do is discuss with your customer what are the levels of utility and warranty they are expecting? Then document and agree these targets are reachable given the resources that are at your disposal and any constraints that may be discovered. The requirements for functionality (utility) should be defined by your BRM process and documented in the SLR document.

When you say that we want to meet SLA x% of the time, there are many factors that could have an impact on your ability to meet or not meet that target. How well are these services documented in your service portfolio and catalog? How mature is your Service Level Management process, Incident and Problem Management processes?  How often do you have to allow for changes to services, which could possibly impact the availability of your service?   These and other factors can have a distinct impact on meeting SLAs.  So here are a couple of KPIs you might want to explore:

• KPI: Total number and percentage increase in the number of SLAs in place
• KPI: Percentage increase in SLAs agreed against operational services being run
• KPI: Frequency of service review meetings
• KPI: Reduction in average response time to outages and incidents
• KPI: Reduction in outstanding (unresolved) problems for services being delivered
• KPI: Percentage increase on issues being raised at service and SLA review meetings that are being followed up on and resolved
• KPI: Increase in number of services with timely reports and active service levels

I hope this will be enough to get you started and stay busy for a while.  Good luck! 

For more information on KPIs and SLAs, consider ITSM Academy's ITIL Foundation and check out our Free Resource Center

Site Reliability Engineering

Site Reliability Engineering (SRE) is a discipline that incorporates aspects of software engineering and applies that to operations with the goal of creating ultra-scalable and highly reliable software systems.  Google’s mastermind behind SRE, Ben Treynor, describes site reliability as “what happens when a software engineer is tasked with what used to be called operations.”

Historically, Dev teams want to release new features in a continuous manner (Change). Ops teams want to make sure that those features don’t break their stuff (Reliability). Of course the business wants both, so these groups have been incentivized very differently leading to what Lee Thompson ((formerly of E*TRADE) coined the “wall of confusion”.  This inherent conflict creates a downward spiral that creates slower feature time to market, longer deployment cycles, increasing numbers of outages, and an ever increasing amount of technical debt.

The discipline of SRE can begin to reduce this dilemma by introducing multiple analytics and statistical analyses for green- or red-lighting launches and help to resolve the extreme focus of stability vs. agility, operational work vs. software engineering and proactive vs. reactive work. These SRE teams are staffed with developer/sys-admin hybrids who not only know how to find problems, but according to Googles Melissa Binde “figure out why it happened, what was the root cause, figure out how to detect it sooner and ideally insure that it doesn’t happen again”.  Sounds a lot like ITIL’s Problem Management process only on steroids.

So at a basic level here is how I understand this works.   As we all know from years of experience, and just being human, nothing is perfect. None of our services ever really achieve 100% uptime; it’s why we invented SLAs. Take it from someone who used to write them.  This is the concept I think is just so cool.  If a team agrees to a 99.8% SLA, it gives them an “error budget” of 0.2%.  This is the maximum allowable threshold for service interruptions. The production team can utilize this error budget however they see fit and in turn release whenever and whatever they want given they are within the SLA.  They get green-lighted based on past performance. If they are operating at or below the defined SLA, all launches are red-lighted until they reduce the number of errors to a level that allows the launch to proceed. SREs (Ops) and developers (Dev) have a strong incentive to work together to minimize the number of errors. This ties completely into the cultural and professional movement known as DevOps, which stresses communication, collaboration and integration between software developers and operational professionals while automating the process of software delivery and infrastructure changes. 

For more information; www.itsmacademy.com/devops

What’s New in IT?

What isn’t? With the internet of things there are so many options available to consumers that were not available even one month or one week ago.   With technology and job role functions evolving so fast, the best way to stay current is to become educated.  Here are just a few bits of interesting information.

New for Every Day Consumers:

In a recent update Google’s Virtual Globe has introduced a feature called "Voyager." No longer will you be limited to only exploring places you've heard about, nor will you have to resort to randomly clicking on areas of the planet in hopes of finding a gem. Instead, "Voyager" presents you with dozens of curated journeys around the globe. Each voyage is centered around a theme. “Museums Around the World” will take you to a Street View of museums in every corner of the globe. If natural formations are more your speed, "Earth View" will show you "the most striking and enigmatic landscapes available in Google Earth." And… if that does not excite your there are 3d glasses to use with Google Earth that will really make your view realistic.  Not only is the world evolving but how we view it is evolving too.

New Uses for Technology:

Drones. You have probably seen them and heard of them being used for espionage and for research.  I found it interesting to know that drones armed with sensors helped researchers study a volcanic eruption in Guatemala. Now think about the technology that supports services for your organization. Not only is there a lot of legacy hardware and software that doesn’t fit for today’s products and services, new ways to utilize the technology are continuously evolving, like the drone.

New IT Jobs:

New demand for new types of jobs and skillsets are evolving as you read this. Many include titles that would have been meaningless only a year or two ago:

Augmented Reality Designer

Internet of Things Architect

Container Developers

DevSecOps Engineer

Info World reports that it is no surprise, given that the IT job market is in constant flux with new technologies emerging so quickly, that hiring managers struggle to define those positions - let alone give them a title. IBM, for example, has a Director of Blockchains, and Ford Motor is among many companies looking for GPU Cluster Engineers.

New Education:

For more information regarding ITIL Best Practice, Agile Service Management (Agile and beyond), DevOps certification and more, look here!