Skip to main content

Posts

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

The Great Divide

Historically there has been a divide between the Systems Administration (Operation folks) and Software development (Application folks). This divide often results in services being released that only partially meet customer/business requirements and leaves the organization with the perception that operations is often inefficient and ineffective. This riff is not of our own making. In the past it has been caused by a combination of conflicting goals, objectives, processes, and tooling.  Development-centric people tend to believe that change is good. As a matter of fact it’s the thing that they are paid to realize. The business depends on them to be agile to the changing business environment. Because of this correlation, they are often rewarded to create as much change as they can and do it as quickly as possible. Operational people on the other hand, have institutionalized the belief that change is the nemesis of who they are. The business depends on them to keep the lights

Your Process Is Either Improving or Deteriorating

Do you ever notice you can hear things over and over and then there is that one moment where a comment or phrase all of a sudden shouts at you with real meaning and significance? I’d like to share one of those aha moments with you. I recently took a class called Certified Agile Process Owner (CAPO). During that class the instructor, Donna Knapp responded to a learner and said …  “Remember that your process is either improving or it is deteriorating”.  For some reason while thinking about that from an Agile Service Management perspective I thought REALLY?! That is so very true. If we think about it, by the time we define, deploy and utilize any set of process activities the objectives could change, the technology used certainly has changed and the overall requirements for any one of those process activities or procedures could have changed. Today we all know that business requirements are dynamic. All the more reason for taking an iterative approach to process design. For

The 5 Principles of Lean Thinking

Value Lean starts with a defining value precisely from the perspective of the customer in the relationship to the features and characteristics of the organization’s product (goods or services) and other critical attributes. Value Stream A value stream contains all of the activities required to create customer value for a service product or family of products. This would include all of the processes needed from designing the product, building, testing, releasing and deploying it into the live environment, being able to support the use of the product by your customer and finally being able to improve it to meet the customers changing requirements over the lifetime of the product. Lean organizations wisely distinguish their value streams and arrange their operations to maximize the value created for the customer and minimize the waste in these processes. Flow and Pull Make the remaining value–creating steps flow. Lean organizations will seek to maximize the flow of materials, resource

Value Elements

When discussing the elements of value creation through the delivery of services we always talk about customer preferences, perceptions and the business outcomes they generate.  We also throw in the elements of utility and warranty.  These are all critical in ensuring our ability to create value for our customers and capture value for ourselves as service providers. The service relationship between service providers and their customers revolves around the use of and interaction of assets.   Assets are made up of both resources and capabilities and are provided by both the service provider and the customer.  These are critical value elements in the creation of usable, customer aligned services. Many of our customers utilize our services in conjunction with their own assets to then build and deliver services or products our customers then deliver to their customers. We, as the service provider, consider these customer assets.  Without these there would be no basis for defining th

Continuous Delivery

Continuous Delivery is a software development practice where software is always in a releasable state.   Teams produce software in short cycles, ensuring that the software can be reliably released at any time.  By relying on automated testing and deployment, as well as ensuring collaboration and communication between development and operational teams (DevOps), the goal of building, testing, and releasing software faster and more frequently can be achieved. This approach can help to reduce the cost, time and risk of delivering changes by allowing for more incremental updates to applications and configuration items (CIs) into production.  A straightforward and repeatable deployment process is important for continuous delivery and will be critical for operational processes such as Change Management and Release and Deployment Management to be agile and robust in the DevOps environments where continuous delivery will be part of best practices.   Continuous Delivery is sometimes co

Desktop as a Service

In today’s world of DevOps, development, deployment, operations and support are being done at lightning speed compared to methodologies employed just several years ago. With the implementation of “Infrastructure as Code” (IAC), a type of IT infrastructure, development and operations teams can automatically manage and provision through code rather than using a manual process.  A part of this movement includes, “Desktop as a Service” (DaaS) which is a cloud service where the back-end of a virtual desktop infrastructure (VDI) is hosted by a cloud service provider. The service is purchased on a subscription basis. In the DaaS delivery model, the service provider manages the back-end responsibilities of data security storage,   backup, and upgrades. DaaS has a   multi-tenancy   architecture which means a single instance of a software application can serve multiple customers at one time. Each customer is called a tenant. Tenants may be given the ability to customize some parts of t

Business and IT Strategy – 2016

As the New Year begins, most IT service providers already have their IT strategy in place.   A few decades ago we heard loud and clear… “You must align IT with the business”.  Then we heard in the next decade…  IT...”You must align with the business”.  Notice the focus was on what “IT” must do.  I believe that most IT organizations get that.  The real question when considering a strategy is how this can be achieved.  Or is it?   I hope that moving forward the new mantra will be “Hello business”… “You must engage IT in order to ensure success.”  If the strategy does not include how the business is going to consistently engage, plan and strategize with the IT organization it is possible that the business strategy will not ensure the type of success that is hoped for and could continue to miss the mark. A recent BizReport article by Kristina Knight states; "During 2016, the perception that developers are basement-dwelling, socially-awkward techies with no grasp on business

The Goals and Objectives of Agile Service Management

Part of the role of the Certified Agile Service Manager (CASM) is to ensure that ITSM processes engage and reflect agile values and that they are appropriately designed with “just enough” control and structure in order to effectively and efficiently deliver services that facilitate customer outcomes when and how they are needed. The goals and objectives of Agile Service Management include: Ensuring that agile values and principles are embedded into every service management process from design through implementation and continual improvement. Improving IT’s ability to meet customer requirements faster.  This includes process and process integration, capabilities, knowledge transfer and the use of appropriate technologies for automation. Being effective and efficient (lean).  It also means ensuring that we don’t bias too far in one direction.  I can be very effective but not efficient. On the other hand I can become too efficient but impact my effectiveness.  Either of these s