Skip to main content

Posts

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