Skip to main content

The State of ITSM: One Company’s Assessment!

Here is an article I thought you might find interesting.  It was first published in itSMF USA's Source EJournal, April 2017.  

The State of ITSM: One Company’s Assessment!
By Keith D. Sutherland and Lawrence J. “Butch” Sheets

Educators and consultants operating in the formal practice of IT service management (ITSM) have largely been doing so since the mid-90s. Even though the best, codified practices of the IT service management framework, ITIL®, is now just over 30 years old, there remains a large number of organizations still in initial adoption of ITIL. 

And of those service providers with longer histories of using ITIL, many still have a significant need to increase maturity, or more fully implement their ITIL practice. The need in these companies for structured education, assessments, and roadmaps still abounds, even while multiple approaches for these practices are available for each. Beyond ITIL (and in many cases, alongside), are the many other evolving and emerging options of frameworks, standards, methodologies, and movements, including IT4IT™, DevOps, lean IT, agile, COBIT 5, simulations, not to mention SDLC, TOGAF®, PMBOK®, PRINCE2 Agile®, CMMI®, ISO/IEC 20000, USMBOK™, Six Sigma and others.

Information technology most would agree, is barely more than fifty years old. Today, mobile, cloud, analytics, IoT, digital, and other technologies dominate the IT landscape. At the same time, a company’s system of record (or legacy) capability could still be based on COBOL programming (and we first saw COBOL in 1973!). IT services emanate from all of these “point” solutions, whether legacy or emerging.

Although the intent of this article is not to understand all of the options for ITSM and IT, governance and the “center of gravity” concept help service providers ensure customers receive services that both provide value and support business outcomes at acceptable costs and risks.

The Need for Governance
Both ITSM and IT will and should continue to undergo transformational change. The real continual challenge for IT service providers lies in how to integrate ITSM and IT to help customers meet business outcomes. Most customers understand the concept of business outcomes or lagging indicators, but there is significant evidence that:
  • Internal customer-facing services are often left undefined. Without quantifying IT effort against business outcomes, it is difficult to express the value that an IT service provider contributes or identify the associated budget needed to support those outcomes.
  • Shadow IT (IT systems built without explicit organizational approval) continues to be pervasive, and it doesn’t matter the industry: internal IT is perceived as operational but not strategic (i.e., as a business partner).
  • Technical debt abounds. There is a trend in lessening investment in the operational aspects (leading to deficiencies in code, documentation, and computing environments), resulting in the overall inefficiency and ineffectiveness of the IT footprint. This lack of investment has resulted in not being able to keep up with the demand for IT services.
The impact of these three trends can be mitigated through stronger governance of ITSM (not to be confused with the governance of IT), value capture and a rolling ITSM roadmap. If the strategy is “beginning with the end in mind,” then a defined, documented, and a published plan needs to be understood and executed with defined roles and activities, trusted dates, and supported actions all of which constitute governance.

Download full article.


Popular posts from this blog

What is the difference between Process Owner, Process Manager and Process Practitioner?

I was recently asked to clarify the roles of the Process Owner, Process Manager and Process Practitioner and wanted to share this with you.

Roles and Responsibilities:
Process Owner – this individual is “Accountable” for the process. They are the goto person and represent this process across the entire organization. They will ensure that the process is clearly defined, designed and documented. They will ensure that the process has a set of Policies for governance.Example: The process owner for Incident management will ensure that all of the activities to Identify, Record, Categorize, Investigate, … all the way to closing the incident are defined and documented with clearly defined roles, responsibilities, handoffs, and deliverables. An example of a policy in could be… “All Incidents must be logged”. Policies are rules that govern the process. Process Owner ensures that all Process activities, (what to do), Procedures (details on how to perform the activity) and the policies (r…

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 needs …

Incidents when a Defect is Involved

Question: We currently track defects in a separate system than our ticket management system. With that said, my question is does anyone have suggestions and/or best practices on how to handle incidents when a defect is involved? Should the incident be closed since the defect is being worked on in another defect tracking system if it is noted in the incident ticket? I am considering creating an incident statuses of 'closed-unresolved' so the incident can still be reported on in our ticket management system but know it is being worked on/tracked in the defect system. With defects, it is possible that we may never work on them because they are very low priority and the impact is low to the user. However, in some cases a defect is being worked on. Should we create a problem ticket instead?
Thanks, René W.

Answer: René. In ITIL, the activity you are describing is handled by the Problem Management process. ITIL does not use the term “defect” but it does use the term “known error” to…