Skip to main content

Posts

Minimum Viable IT Service Management (MVITSM)

The aim of Minimum Viable IT Service Management (MVITSM) is to put in place “just enough” process to meet your organizations, needs, goals and circumstances. Minimum Viable Product To understand this concept let’s take a look at some of the origins.  The term Minimum Viable Product (MVP) originated in software development.  If we research the definition we find that in product development, the MVP is a product which has just enough features to gather validated learning about the product and its continued development. Gathering insights from an MVP is often less expensive than using a product with more features which increase costs and risk in the case where the product fails, for example, due to incorrect assumptions. Minimum Viable Process In a recent workshop Donna Knapp from ITSM Academy indicated that the Minimum Viable Process is really a matter of looking at what are the minimum critical activities that need to be performed in a process.  Complex bureaucratic processes

Business Relationship Management (BRM)

Business Relationship Management (BRM) is the process and role that allows us, as a service provider, to establish a strategic and tactical relationship with our customers. This will be based on ensuring we understand the customer and the business outcomes they are trying to create and how and what services are engaged by the business to meet those defined goals and objectives. A key activity of the BRM process is to ensure that as business needs change over time, we as a service provider, are able to translate these needs into requirements through the use of a Service Level Requirements document (SLR) which then manifests itself into the portfolio in the form of defined services.  The BRM will assist the business in articulating these requirements and the value of these services that the business places on them. In this way the BRM process is executing one of its critical success factors, which is to safeguard that the customer’s expectations do not exceed what they are

The Best of the Professor for DevOps #1 – Resources to “Educate and Inspire”

If you are a strategist, manager or practitioner working in service management today you will probably be working on ways to improve lead time, cycle time and overall flow of work through the lifecycle of delivery.   Business demand requires speed and dynamic business requirements force us to look at ways to bust out of silos for cross functional integration.  Time to market, customer satisfaction and the need for secure robust systems are being optimized by many service providers as a result of successful DevOps initiatives.  When considering where and how to optimize the flow of work from ideal to end of life for a service , managers and IT staff frequently have a subjective view of what DevOps is all about and will often get into war room discussions around what certain terms mean.  Over the last year there have been many papers written by the ITSM Professor that clarify terms, concepts and methods current in the industry for service providers.   For clarification, and to ensur

Death by Meetings

So I assume everyone has heard the phrase “death by meetings”, that fear that you are going to be in a series of meetings and that no matter how hard everyone tries, you seem to come out of these meetings with the same to do list or a larger one.  I know your all shaking your head yes or saying “been there done that and have the tee shirt to prove it”.  We at ITSM Academy recently had our yearly strategic meetings and I want to say up front, Best Strategic Meetings in the eight years I have been with the organization. Now that it is not to say that we haven’t had great Strategic Meetings in the past, because we have.  And that is not to say that I wasn’t heading into these meetings with a bit of trepidation, as I think most of us do. I recently read an article called Managing Yourself, Learn to Love Networking*. It defined four strategies that you can engage to help you network with other people even if you really don't enjoy it.  I thought, why can’t I take these 4 approaches

The Technical Catalog

As most of us are already aware, the business of IT has become even more critical in ensuring the overall success of an organization.  In today’s fast pace and fluid environments the statement that “every business decision triggers and IT event” is becoming increasingly true for those of us who operate in the world of ITSM. One of the most valuable tools that we can employ is our service catalog.  In a mature ITIL organization we can have two views of this catalog. The first being the Business/Customer catalog where we connect our customers/users to the standard IT services that we offer, deliver and support.  The second view is the Technical/Supporting service catalog, which when appropriately maintained is a very powerful tool that allows us to relate IT services to our supporting services and the underlying supporting infrastructure.  It is this second view that we will review here. Our service catalog provides us with a central source of information on all of the IT servi

FAIL

We all know failure!  If a deployment for a critical service fails and negatively impacts business partners and consumers that can not be good.   One would have to consider why did this happen?  And even more critical is, why does it happen more than once? There are times when failure can be viewed as good. That of course is when we admit and then correct the reason or the cause of that failure.  Many organizations struggle with a culture that fosters hiding failure.   It is very difficult in this type of stringent culture to be effective and even more difficult to be efficient and innovative.   Not being able to admit or to discuss failure generally will lead to repeated and more disruptive failure.    What is a service provider supposed to do?  Do we fire individuals who drop the ball and fail?  If so, what size of failure would instigate such an action?  Do we restrict staff from elements or areas of the value stream so that their failure does not have the opportunity to impact u

To Collaborate or To Compromise … Which Is Best?

The people factor and your ability to absorb change could and does make all the difference for IT service providers.  Most IT practitioners will agree that “change” requires some organizational change management.  Organizational Change Management (OCM) is the process of preparing, motivating and equipping people to meet new business challenges.  Conflict can be looked upon as good!  Embrace conflict don’t ignore or avoid it because it is necessary to listen to conflicting opinions that may not have been considered.  Learning to use different conflict modes helps to move forward and increase engagement that could make your organizational change a success. The   Thomas-Kilmann Conflict Mode Instrument   is a tool for helping people understand how different conflict-handling styles affect interpersonal and group dynamics and for empowering them to choose the appropriate style for any situation.  I was studying this in preparation   for an “Organizational Change Management” workshop an

Failing Forward

In the introduction of her book The ITSM Process Design Guide, Donna Knapp writes “In today’s competitive business climate it’s not enough to do things right; Information Technology (IT) organizations have to do the right things right.”  Well what happens when we don’t? Remember New Coke?  Not every decision we make, every new design or redesign we engage in goes according to plan.  What happens when we fail?  One of the most important and most deeply entrenched reasons why established companies struggle to grow is fear of failure. In fact in a 2015 Boston Consulting Group survey, 31% of the respondents identified a risk adverse culture as a key obstacle to innovation. (1)  ITSM processes for strategy, design, transition, operation and CSI are all based on efficiency and effectiveness.  It’s about being in control of our IT environments and that we must do everything we can to prevent failures.  Now this may go against many of our strongly held beliefs but Pixar’s president, Ed Ca

The Service Portfolio and Portfolio Management

The Service Portfolio represents the complete set of services that is offered and managed by a service provider.  It corresponds to the entire lifecycle of all services and is made up of three sections.  The first, the Service Pipeline (proposed or in development) denotes the future stance the organization is going to take in meeting customer requirements and aligning to the future business strategy. Next is the Service Catalog (live or available for deployment) which is what the service provider is currently delivering and maintaining to meet the organizations current and near future goals and objectives.  Finally we have the Retired Services, which have been deemed no longer valuable enough to sustain their continued delivery, but may need to be continued to be supported for some defined time to meet some regulatory or legal requirement. The Service Portfolio is an integral tool in helping us define perspective and position. It is a tool for our customers/business and ac

Metrics and Business Value

IT managers gather and distribute metrics that reflect their group’s performance on a regular and timely basis.  But outside of their immediate organizations do these metrics have any real meaning or impact? Do these measurements really define the value that IT is delivering?  Business executives shouldn’t have to work to see the positive impact of IT performance.  It should be made readily visible, in language they can grasp quickly and easily.  In many IT organizations there is a continued focus of their reporting towards the performance of the technology and not the value being delivered to the business.  This emphasis continues to create a gap between IT and the rest of the organization. (1) What metrics do you employ?  Service metrics, measuring the end to end performance of your services, based on your technology metrics.   Technology metrics, performance of your components and applications. Are they available when needed? Do you have the correct levels of capacity to meet d

Shift Happens: How?

Demand is increasing.  Dynamic or changing business requirements are a norm.  Business and customers must have quality services provisioned fast.  Ok … we get that.  Now let’s think about the service provider and what their condition or state is.  Some service providers are stuck in an organizational structure and management style that propagates an isolated us vs. them type of culture.  Others have legacy overburdened outdated systems.  Disparate and replicated tools between networking, storage and other functional teams including service desks generally create more havoc than business value.  Many efforts including data center transformation, new sourcing models, cloud computing and more have helped to some extent.  Even after these very costly initiatives many service providers experience a resistance to change and find they are working within a very rigid environment. Rigid structures, rigid process or rigid anything will not enable a service provider for success.  Some organi

Cloud is Here… Is CMDB Dead?

The question about how to manage virtualization and configuration items pertaining to the Cloud continues to challenge service management practitioners and managers who are trying to strategize and architect a working solution to provision business services.  Some would say the idea of the CMDB (Configuration Management Database) is dead because we use the infamous “Cloud”. Let’s start with a refresher about the structure and purpose of a CMDB and system and then move into how that relates to the management of virtual Configuration Items or Cloud services. Configuration Management System The key to a CMDB, or the sets of data that comprise your broader Configuration Management System (CMS), is “Relationships”.  When provisioning a service, the service provider must be able to manage and control all of the items necessary to produce “Value” to the consumer.  All elements in the end to end service that need to be managed and controlled are referred to as a Configuration Item

How Does ITIL Help in the Management of the SDLC?

I was recently asked how ITIL helps in the management of the SDLC (Software Development Lifecycle).  Simply put... SDLC is a Lifecycle approach to produce the software or the "product".  ITIL is a Lifecycle approach that focuses on the "service". I’ll start by reviewing both SDLC and ITIL Lifecycles and then summarize: SDLC  -  The intent of an SDLC process is to help produce a product that is cost-efficient, effective and of high quality. Once an application is created, the SDLC maps the proper deployment of the software into the live environment. The SDLC methodology usually contains the following stages: Analysis (requirements and design), construction, testing, release and maintenance.  The focus here is on the Software.  Most organizations will use an Agile or Waterfall approach to implement the software through the Software Development Lifecycle. ITIL  -  is a best practice for IT service management (ITSM) that focuses on aligning IT services with the

Deployments Failing? What about STRATEGY?

A lot of organizations today are focusing on improving their time to market and also looking at tactical ways to be able to deliver services without causing massive "All Hands on Deck" outages.  How can we deliver quality services faster at the least amount of cost? Varied methods such as Agile, Lean, Six Sigma and other service management process activities and methods have been attempted.  Why are we missing the mark?  Why does the business not see the type of returns that are touted?  Perhaps if there was more of a focus on the strategy, or at least as much time and effort as is put forth in the tactical and operation space, we would see better results.   Is it time to shift the focus? Having a clear strategy will help your organization to be able to link tactical plans and operational activities to outcomes that are critical to customers and to the business as a whole.  With clear strategic initiatives, governance and best practice principles, the service provid

Event Management

Event Management is the process that monitors all events that occur throughout the   IT   infrastructure. It provides the basis for normal operation (service assurance) and also detects, reports on and escalates exception conditions. An   event   can be defined as any detectable or discernible occurrence that has significance for the management of the IT Infrastructure or the delivery of IT service and evaluation of the impact a deviation might cause to the services. Events are typically notifications created by an IT service,   configuration item (CI)   or monitoring tool. It is unusual for an organization to appoint an “event manager” as most events tend to occur for many different reasons and will in most cases be managed by the technical or application management team whose technology or application is impacting the delivery of an associated service.  However, it is important that Event Management procedures are well defined documented and coordinated among ITIL processe

Access Management

Access Management sometimes also referred to as ''Rights Management'' or ''Identity Management'' provides authorized users the right to use a service, while preventing access to non-authorized users. Because Access Management essentially executes policies defined in IT Security and Availability Management, these two processes will likely be responsible for defining the appropriate roles within Access Management. It is critically important that well defined interfaces between the business and Access Management are seen as vital to achieving high security standards. Typically, responsibilities of both sides are defined in a dedicated Information Security Policy. As an example, policy may specify that HR will inform Access Management in a timely fashion about employees entering or leaving the company. This should lead to having a single set of policies related to managing rights and access.   The Service Desk may be used as a means to request access to

Knowledge Management

Knowledge Management provides value to all stages of the service lifecycle by providing secure accurate and up to date knowledge, information and data that is needed to manage and deliver services. Knowledge Management is particularly important within Service Transition since current and applicable knowledge is one of the key service elements being transitioned.  Effective Knowledge Management is a powerful tool for people in all roles across all stages of the service lifecycle. It is a best practice method for individuals and teams to share data, information and knowledge about all components of an IT service. Having the right information in the right place at the right time will enhance all stake holder’s ability to make informed decisions based on the most current knowledge about their environments. Successful management of data, information and knowledge will enable the service provider staff to have a clear understanding of who uses the services, how they use those servic

You Can’t Automate Chaos

In a recent DevOps Foundation Certification class one IT executive said “You can not automate Chaos”! Another learner spoke up and said “Yes you can… that is what we are doing”!   Although that was meant as a LOL moment, it is true that when it comes to velocity and improving cadence all too often service providers jump the gun and look at automation as the silver bullet.  While recognizing that tools, technology and automation are key elements, process and governance must also be considered. Automating before we get management control of these is likely to lead to bigger and faster CHAOS! Executive buy in and support is rewarded when the business and IT are integrated to the point that IT alignment with the business is a given.  Properly designed and well governed process will enable any automation initiative.  Remember we are talking about “Just enough process” and “Just enough governance”.  If your process is the roadblock then you might have created exactly what you are t

Your Comfort Zone is NOT Comfortable

We have all heard mantras and messages like “If it’s not broke, don’t fix it”. Some might still cling to values like “We have always done it that way” but great leaders in contrast will see a different vision and say “There is a better way to do this”. IT service providers in today’s industry need to get uncomfortable. This is especially true for executive management. Some of the best leaders in the world make it their business to experiment, get creative and challenge the status quo. Whether your needs and interests correspond with the early stages of innovation, like education and professional enhancement, or at a later stage like funding and business development, Innovation is key and cannot be propagated by cynics whose horizons are limited by the obvious realities. So how do we manage the naysayers? Successful DevOps, Agile, ITIL and ITSM all require cultural change. One thing we can all agree on: Change is Hard. However, with the right knowledge your team can be

The Year of Shattering Silos

This is the year to shatter the silos.  Consider any best practice, method or standard that you have or are thinking of implementing.   In any DevOps, ITSM, ISO or Lean initiative the biggest challenge that any CIO or organization as a whole will have to address is how to meet the rate of demand and the dynamic business requirements.  Dynamic business requirements are a norm not an exception and the service provider will need to ensure fluidity throughout the value stream.  Shattering Silo’s will be a prerequisite to achieving end-to-end workflow and agility.  Functional Silos When talking about silos most practitioners immediately think of integrating departments or functional teams.  One of the more obvious silos to address here is the division between development and operational teams (DevOps).  While there is a lot of buzz in the industry on how to bridge that great divide, the real chasm that hinders efficiency and optimization is that between the business and IT.  Bus