Skip to main content

Continual Service Improvement (CSI) and Survival

The systems, the processes, and the culture that worked for IT service providers 20 years ago will not work in today’s environment.  No big news here!  Most IT support staff will agree. The truth is that the same could be said for systems or methods that service providers used five years ago or even last year.  The dynamic and rapid change of business requirements demands that a service provider be dynamic and continuously adapt to evolving business needs and outcomes.

When you get into your car and turn the key or push the start button, most would expect that the car is going to start.  You might also expect that it has wheels, an engine, and all the elements necessary to drive this car, right?   This is the same expectation that a business operation expects.  When a service is provided the business expects that service is going to have all the working elements to ensure that it does what they need. The customer expects that the service is available and secure for day to day operation.

The systems, the process and the culture that worked for IT service providers 20, 10 or even five years ago is not likely to work in today’s ever-changing world.  We have all realized that whatever process, service or product you deploy today is already outdated by the time it is usable.  The truth is that the requirements are changing before we can ever even deploy.   This creates confusion, frustration and in some cases the Project Manager does not feel enabled for success.  Being over time and over budget becomes more of the norm than an anomaly.

What do all frameworks, methodologies and best practices have in common?

All of these frameworks and methods could be used and dovetailed together to provide value.  Frameworks do not stand alone.

Think about:
  • Agile and the focus on iterative design
  • Lean and how to remove waste
  • The culture to shift left
  • Agile Service Management and Minimum Viable Process (MVP)
  • ISO/IEC 9000, 9001, or ISO/IEC 20,000 that ensures an ongoing quality/managed service system
  • TQM and the Deming Cycle for Plan, Do, Check, Act…

At the core of these frameworks is the idea that Continual Service Improvement is necessary to deliver value.   If you are not growing, living, breathing and moving with the business than this becomes not only suggested but required for survival.  Educate and Inspire!


For more information on Continual Service Improvement:  https://www.itsmacademy.com/itil-csi/  

Comments

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…