Foundation provides the building blocks of ITIL (Version 5) and is the first step in the ITIL learning journey.
Official Book
Intro
§ 1.1 Evolving IT service management
Industry 5.0.
https://research-and-innovation.ec.europa.eu/research-area/industrial-research-and-innovation/industry-50_en
I think that the pillars of industry 5.0 (human-centricity, sustainability, and resilience) are important and should be boldfaced in the first paragraph.
§ 1.5 The ITIL Car Rental Scenario
That purple note is important. We should “adopt and adapt” frameworks.
Chapter 2: The ITIL Four Dimensions of Product and Service Management
§ 2.1 Introduction
I think that
“The Four Dimensions and external factors should be considered holistically and collectively, in no specific order or hierarchy.”
is important and could be boldfaced or called out somehow.
§ 2.2.1 Culture
That’s a nice definition of culture.
§ 2.2.2 Leadership
Perhaps discuss servant leadership here? See Create, Deliver and Support § 2.3.5.3.
§ 2.2.3 Organizational structure
It might just be a New Zealand English thing, but in my experience the described technique for dealing with Conway’s Law is more commonly referred to as an Inverse Conway Manoeuvre (ICM) than a Reverse Conway.
§ 2.2.4 Skills and competencies
I really like the explicit mention of universal skills.
§ 2.2.5 Organizations, people and AI
Delivery hint: Talk about the AI Governance extension module.
§ 2.3.1 Workflows in ITIL
TODO: I’m not happy with the way the terms value chain and value chain activities are defined, though I’m not sure what the issue is or how to better phrase it. I think the use of articles is confusing the issue. An organisation’s value chain is the superset of all activities the organisation performs. Each organisation has one value chain, in the same way we would say each organisation has one mission.
There was a great point made in one of the PeopleCert webinars:
A lifecycle is what is happening to a product and/or service.
A value chain is what we do as an organisation.
§ 2.3.2 Optimizing workflows for complexity
(Rant) PeopleCert should just teach the Cynefin framework here, not make up their own framework based on 3/4 of Cynefin.
There is no value in combining Cynefin’s clear and complicated domains into one called ordered.
I disagree with narrowing chaotic down to “crisis situations requiring immediate action” (which seems to be Snowden’s “accidental chaos”). Complexity thinking is not concerned with immediacy - crisis situations could cover all five domains. The point of the chaotic domain is that the only way to respond appropriately is to act (then sense, then respond).
Delivery hint: As well as Cynefin, I’d mention VUCA here.
§ 2.3.2 Optimizing workflows for complexity
I like the callout “Organisations should embrace the varying complexity…”. The world is only getting more complex, and it is futile to fight it. We shouldn’t be scared of complexity — we should embrace it, deal with it, and thrive in it.
§ 2.4.1 Technology
Note that here in New Zealand and Australia, we almost always use the term “ticketing system” for what ITIL calls a “workflow management and collaboration system”. Similarly, we use “ticket” for the ITIL term “record”.
§ 2.4.1.1 Artificial Intelligence
As an aside, I wish PeopleCert had used “correlation” instead of “cognition”. AI is a technology for which “correlation does not imply causation” strongly applies. The AI system can find trends, patterns, and anomalies but it can’t determine if those anomalies and patterns are causative or coincidental or if there is a confounding variable.
§ 2.4.2 Data, information, and knowledge
This is the DIKW Pyramid. Many versions of this model don’t include all four components (and some models use more, for example DIKIWI, which is data, information, knowledge, insight, wisdom, impact).
Chapter 3: Key concepts of digital product and service management
§ 3.1.2 Digital services and digital products
Note that the transfer of goods does not necessarily include transfer of ownership. For example, ITIL Car Hire transfer goods (the car) to consumers, but ownership is not transferred as well.
§ 3.2.3 Service journey
Note that UX and CX include objective and subjective measures.
§ 3.2.4 Service quality
Note sustainability. It’s new in version 5.
§ 3.2.5 Service level agreements
I think the phrasing of the definition of SLA could be tightened. SLAs do not “identify” the services provided and the agreed level; they define and/or document them. The service catalogue lists all the products and services the provider offers, then the SLA documents with of them the provider agrees to provide to the consumer, and the expected levels of service. This might just be a New Zealand English thing, however.
It is important to distinguish between expected levels of service (which are documented in the SLA) and achieved levels of service (which are documented in service review reports). See the service level management practice guide § 2.4.3.
Chapter 4: ITIL Product and Service Lifecycle
General Comments
I like how many of the key metrics in this book (and in the practice guides) include “number and impact”. Both the number of errors and the impacts of them should be measured.
I like the use of “deliver services” instead of “deliver products” in many of the sections in this chapter. Outcome-based thinking.
Operating Model Canvas
This is a highly-regarded tool to understand or design the operating model of an organisation. It was written by Andrew Campbell, Mikel Gutiérrez and Mark Lancelott. See https://operatingmodelcanvas.com/ for the blog and videos, as well as links to purchase the book and course.
The diagram on slide 136 is an “ITILised” version of the Operating Model Canvas POLISM diagram.
§ 4.2 Discover
Should “product level” be “product and service level”, for consistency with elsewhere in the book?
Roadmap is not defined in this book. Atlassian.com defines is as follows.
A product roadmap is a shared source of truth that outlines the vision, direction, and progress of a product over time.
Product and service portfolio is defined in the glossary.
product and service portfolio: A complete set of products and services that are managed throughout their lifecycles by an organization.
Note that a product and service portfolio is different from a portfolio. See the portfolio management practice guide § 2.1.
portfolio: A collection of assets into which an organization chooses to invest its resources in order to receive the best return.
§ 4.3 Design
Human-centred design
https://en.wikipedia.org/wiki/Human-centered_design
Two books I own, both of which are very good.
IT service by design by Mark Smalley and Catherine Zuim. Note that Mark Smalley is one of the contributors to the Foundation official book.
The Design of Everyday Things by Don Norman (one of the pioneers of HCD).
§ 4.4 Acquire
Table 4.3
Typo? In the key metrics row, should “timelines” be “timeliness”?
SCM, ITAM
The slide deck includes a definition of CMDB but should also include CMS, as well as IT asset register. See the service configuration management practice guide § 2.2.2, and the IT asset management practice guide § 2.2.3.
Configuration management system (CMS): A set of tools, data, and information that is used to support the service configuration management practice.
Configuration management database (CMDB): A database used to store configuration records throughout their lifecycle. It also maintains the relationships between configuration records.
IT asset register: A collection of information about IT assets that includes their ownership, cost, and other key characteristics. The IT asset register makes it possible to quickly understand the lifecycle stage of all IT assets.
§ 4.5 Build
I really like that the key output is a solution that has been both built and tested.
Table 4.4
Typo? In the key metrics row, should “building cycle” be “build cycle time”?
CICD
That’s a nice definition of continuous integration. Many books miss out the central repository concept of the term. One of our trainers here describes CI as “making sure that programmers are not trampling over each other’s code”.
Testing
See the service validation and testing practice guide § 2.1.1 and § 2.1.2.
§ 4.6 Transition
Table 4.5
In the key outputs row, I think “deployed” should be “deployed and released”, or maybe “deployed and perhaps also released”.
In the key outputs row, I think “negative impact of transition” should be “negative impact of changes” to maintain consistency with other sections. See sample paper 1, question 25.
CICD
I think that the definition misses the point that continuous delivery automates development to the point where software is in a deployable state. Actual deployment and release activities are manual.
https://www.redhat.com/en/topics/devops/what-is-ci-cd
§ 4.7 Operate
Operate activity starts the minute Transition activity completes (or maybe earlier) and continues for the entire lifetime of the product.
For more information on reliability, maintainability and observability, see the infrastructure and platform management practice guide § 2.2.5.
Event, incident and change are from (respectively) the monitoring and event management, incident management, and change enablement practice guides.
What is a performance deviation and how is it different from an incident? A deviation is where the performance of a component is outside baseline limits. It may or may not indicate a failure but can often be a symptom of a future incident.
§ 4.8 Deliver
The first paragraph in 4.8.1 is great and could do with being boldfaced or called out.
Communication between the provider and the customer is (mostly) covered by the service level management practice, which defines the term service level agreement.
Communication between the provider and the user is covered by the service desk practice. Incoming communications will mostly be either requests for pre-agreed services (service requests, probably triggering Deliver activities) or notifications that something is not working (incidents, probably triggering Support activities).
Table 4.7
In the key outputs row, I think “user feedback” should be “consumer feedback” or maybe “user and customer feedback” to maintain consistency with the purpose paragraph.
I know I’m being picky here, but I think that in the key metrics row, “agreed SLA targets” should be just “agreed targets”.
In the key metrics row, should "Adherence to the product and service strategy and other relevant guidelines" be "Adherence to the product and service roadmap and other relevant guidelines"?
§ 4.9 Support
Table 4.9
In the key outputs row, note the callback to the Operate and Deliver activities.
In the key metrics row, “customer and user satisfaction” should be “stakeholder satisfaction” (or at least “consumer satisfaction”). The sponsor will certainly have an opinion on outages, as will other stakeholders (for example, an incident might have a reputational effect on organisations other than our consumers). In the why do we do it section we might also change “consumer” to “stakeholder”.
In the key metrics row, should "Adherence to the product and service strategy and other relevant guidelines" be "Adherence to the product and service roadmap and other relevant guidelines"?
Incident, Disaster
An incident is an interruption or reduction in quality of the service the the provider is providing to the consumer. Incidents need to be resolved; by resuming full service (abbreviations for this include RTO and RTS). Incidents could be minor or major. The incident management practice covers incidents.
A disaster is something that causes massive damage. It possibly involves evacuations, engagement with emergency services, and major disruption to operations. The service continuity management practice covers disasters.
There is a huge overlap between the two. A major incident is likely to be a disaster, and a disaster is almost certainly a major incident (unless our availability management is really, really good). The difference is the focus. Incident management is about returning to service, disaster management is about maintaining some level of service during the disaster as well as engaging with emergency services.
ITIL suggests that the business develops criteria for an event to be formally classed as a disaster and/or major incident, which formally kicks off disaster recovery procedures.
As an aside, I’d like to see major incident defined here in the book, not just in the glossary.
Problem
Problems and known errors are part of the problem management practice, which establishes if there are actual root-causes of incidents (problems), analyses those problems (a known error is a problem that has been analysed but not yet resolved) and then fixes them or develops workarounds.
Fixing a problem (hopefully) improves things, so the problem management practice works closely with the continual improvement practice. Problems are risks, so the risk management practice also applies.
Error
To be honest, I don’t understand this term or why it was added to ITIL (Version 5). Why do we need two terms for a cause of incidents?
Chapter 5: The ITIL Value System
§ 5.2 The ITIL Guiding Principles
FITSOCK :-)
§ 5.3 Governance
Note that version 5 discusses governance in a lot more depth than ITIL4 did.
The ISC2 CC course has great advice about governance: "Say What You Do, Do What You Say." It also recommends explicit statements, and making sure that operational procedures align to policies.
§ 5.4 Value Chain
§ 5.5 Practices
PeopleCert said in an AMA that the groupings of practices have no purpose other than avoiding a 34-row single-column table in the book.
§ 5.6 Continual Improvement
Chapter 6: Identifying, mapping, and managing value streams
§ 6.3 Value stream mapping
Picky Criticism :-): This should be a numbered list, not a bulleted list.
§ 6.4 Value stream management
This section (or perhaps section 6.1) should define the term artifact.
Chapter 7: Next steps
Appendix A: Practice Quick Reference Cards
I can’t overestimate how good it is to have information on all 34 practices in the Foundation book. PeopleCert added them to the ITIL 4 Foundation official book at some point, and it was a highly valuable addition.
Sample Paper 2
Question 12
Technically none of the answers are correct. The question includes “expected and achieved service quality” but none of the answers include any information on achieved service quality. A service level agreement (the designated correct answer) only includes expected service quality – service reviews establish a shared understanding of achieved service quality.
However, always be mindful of the process of answering of multi-choice questions - pick the best answer. In this case, B is clearly the best.
Question 34
Phrasing. Answer A (the designated correct answer) doesn’t really answer the question. Value chain activities don’t “translate the organisation’s purpose into activities”; they are the activities. Service design is the process of translating purpose into activities.
In the answers and rationales document, the rationale for answer A has a chapter reference of 4.8.2. I think it should be 5.4.1.