Continuous Integration/Continuous Deployment (Of Guidance)

The new definition of Problem appears in the glossary only. The main text in the Foundation book has not been changed at this stage. So for the time being, please keep the following in mind:

1. Exam candidates – Keep the old definition in mind... For the exam!
2. Practitioners and ITSM professionals – Understand the spirit and the intention behind the updated definition, and look to apply it in your daily work.
3. The glossary entry of Mission Statement was changed to Mission, and the definition was shortened to “A short but complete description of the overall purpose and intentions of an organization”.
4. The definitions of sponsor, consumer, and user have been corrected to say “the role THAT” rather than “the role WHO.”

Original post begins here

It is October 2019. We are in the middle of the ITIL 4 refresh programme, having launched ITIL 4 Foundation in February and ITIL 4 Managing Professional Transition module at the beginning of this month. We are also about to launch two more Managing Professional books and certifications in November. Yet, as we have continued to move forward we have kept an eye on improving what has already been released. To that end, I would like to talk about some of the small improvements happening to ITIL 4 Foundation.

Ch-ch-ch-changes!

The teams at AXELOS take pride in the quality of work that they do, whether it is product development (guidance, exams, translations, etc.) to internal functions and business operations. In product development, we subject our guidance to rigorous reviews by both internal and external SMEs. If I remember correctly, ITIL 4 Foundation lists over 70 contributors from a variety of IT domains; from academics to practitioners, consultants, and trainers. While the purpose of change control was understood by all, a few cautioned against the use of the word ‘control’ but the vast majority did not flag it as a concern.

Following the release of ITIL 4 Foundation, we have heard from several people around the world that the practice was being misinterpreted or misunderstood as focused on ‘controlling changes’ or ‘controlling teams’, rather than ‘controlling the rate of changes’. The word ‘control’ is toxic to many IT teams, and I am curious how IT governance professionals feel about this development. Nonetheless, we listened to the feedback, we tested options, including reverting back to ‘change management’, and decided to change the name of this practice from ‘change control’ to ‘change enablement’.

This decision was not taken lightly! We recognize that there is an impact to the community, from trainers who have to adjust their courseware, consultants who have to update their toolkits and templates (and perhaps make their current clients aware of this decision), to practitioners who have taken the plunge with ITIL 4 and have become comfortable with the term ‘change control’. However, it is best to make the change as early, and as quickly, as possible.

The term change enablement is used throughout the ITIL 4 Managing Professional books and exam question bank (including in the Transition course).

What have we learned from this? Well, two things; firstly, we need to assess who is reviewing our guidance, and we are working hard to find ways to increase the number of reviews, or change the mix of subject matter expertise and background within the reviewer pool. Secondly, small changes to guidance can be made quickly within AXELOS, but communicating the message across our ecosystem takes time, so we need to diversify the channels we use to reach various groups (and hence this blog!)

So … what else is, er … changing?

Apart from grammatical corrections and clarifications to the examples in the Appendix, there are a few other things to highlight:

• The definitions of sponsor, customer, and user (section 2.2.2, and the glossary) now says that these are “roles who (do something)” as opposed to “people who (do something)”.
• The activities of supplier management (section 5.1.13.3) now lists “contract renewal or termination” instead of “contract renewal and/or termination”.
• The definition of a problem (section 5.2.8 and the glossary) has been expanded to read “a cause or potential cause of prior, current, or future incidents”. The same section goes on to clarify that “it can be more valuable to make significant progress on the highest-priority problems than to investigate every minor problem that the organization is aware of”.
• Software asset management procedures (callout box in section 5.2.6) now focus on the “effective management control and protection of software assets across their lifecycle”.
• IT asset management (section 5.2.6) clarifies that audits may be “easier to do” if an accurate asset register exists.
• The key message of monitoring and event management (section 5.2.7) clarifies that the practice “identifies and prioritizes infrastructure, services, business processes, and information security events; it also establishes the appropriate response to those events, and conditions that indicate potential faults or incidents”.
• Heatmap changes:
  • The heatmap for incident management now highlights plan activities as a low contribution, rather than no contribution, with the accompanying text that “Incident records are a key input to planning activities, at tactical and operational level”.
  • The heatmap for software development and management now highlights engage activities as a low contribution, rather than no contribution, with the accompanying text that “software development and management often requires ongoing collaboration and coordination with stakeholders”.
  • The heatmaps for infrastructure and platform management, and for software development and management, have changed the contribution to deliver and support to high (it is currently medium)
  • The heatmap for service level management has changed the contribution to improve activities from medium to high.
• The glossary has also been reviewed and revised. In addition to the change to the definitions of sponsor, customer, and user, the following changes were also agreed:
  • Modifications:
    • Mission: The overall purpose and intentions of an organization.
    • Resource: Personnel, material, finance or other entity required for the execution of an activity or the achievement of an objective. Resources used by an organization may be owned by the organization or used according to an agreement with the resource owner.
    • Process: A set of interrelated or interacting activities that transform inputs into outputs. Processes define the sequence of activities and their dependencies.
    • Customer Experience (CX): The sum of functional and emotional interactions with a service and service provider as perceived by a customer.
  • Additions:
    • User experience: The sum of functional and emotional interactions with a service and service provider as perceived by a user.
    • ITIL value chain activity: A step of the value chain that an organization takes in the creation of value.

We have included many other requests to clarify published guidance in our backlog that we have not worked on yet. We will be looking for the next window of opportunity to make more edits, and we will make sure we keep the community engaged and aware of any changes in the pipeline.

As always, if you have any questions, comments, or concerns about what has been discussed in this blog post, please do leave a message below. We read and consider every single comment, even if we cannot respond to each one.