Skip to main content

ITIL 4 Guiding Principles – Keep It Simple

Keeping it Simple is one step towards creating a world where people get up in the morning and are inspired to go to work and love to do the work that they do. The more complex something is, the more there are ways for it to go wrong. We as an industry of service providers must become educated and stop the insanity! Getting the education and the certification is a wonderful first step but once qualified we must adapt those learnings to make it simple and “Keep IT Simple” 


“Keep it Simple”, one of the seven ITIL 4 Guiding Principles is a topic we have written about many times over the years.  It is anything but simple. We must acknowledge that IT services are comprised of many complex systems and if there is a way to make them even more complex IT Professionals in general seem to have that idea down to an ART. 

So; How did we get that way. Business requirements are dynamic and are consistently evolving even as you read this line. Over a period of years and in many cases decades the systems that support those requirements have evolved. Historically IT professionals adapted to the bureaucracy that they were wedged into in order to survive. A bureaucracy typically refers to an organization that has multi-layered systems and processes. These systems processes and procedures were designed to maintain uniformity and control. Keep it simple! We need just enough process, just enough governance, and just enough incremental ongoing improvements to make it simple and to keep it simple. Processes overtime in many cases became over-engineered and while they might gain the control needed for compliance and regulatory demands, they tend to slow down the flow of work, create roadblocks and sometimes become a major impediment to getting quality and value delivered on time. It really hurts our capability when the process becomes the goal rather than the outcomes that generate real value! Monolithic applications, legacy systems, and siloed cultures all add the complexity for the delivery of services to customers. 

DevOps and Agile professionals are adapting to new ways to remove waste and to increase the flow of work for all value streams using LEAN practices. Applying one "ity bitty" micro improvement (simple) can sometimes have an extreme impact to the agility of your value streams and to the overall value potential. Notice the ity bitty?! Take one small improvement opportunity to simplify a process or system and break that into many other small increments of improvement. Prioritize and pick one. Work fast to integrate that change into the process and then start again. Remember you can not implement a process. It is an ongoing emerging set of activities which hopefully evolve with the dynamic needs of the business and customer. 

Deming says: Plan, Do, Check Act! Agile says “one increment “or iteration of work at a time. ITSM best practice says that with Continual Improvement you must “Keep The Momentum Going”. All will require an outside-in perspective with ongoing feedback loops to help us prioritize the next step towards “Keeping IT Simple” one of the DevOps Principles is “Shortened and Amplified feedback loops. The sooner the better. If a process, service, metric, report or anything that is in play today does not add value, take corrective action or eliminate it! Keep it simple and adopt ITIL practices and then adapt keeping it simple and speaking "simple" as you co-create with others.

Make it Simple and Keep it Simple! … Keep the Momentum going and inspire others to greatness!

...educate and Inspire 

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…