Foundation provides the building blocks of ITIL (Version 5) and is the first step in the ITIL learning journey.
Official Book
Intro
Table of Contents
Typo: Replace “Furher Reading” with “Further Reading”.
§ 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.2 About ITIL
I don’t get the diagrams (figures 1.1a, 1.1b, and 1.1c). What are they supposed to be explaining? Why is the dotted line between digital products and digital services on an angle?
§ 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. Consider question 12 in sample paper 2 (which I think has no correct answers).
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
The preliminary slide deck included Operating Model Canvas, a topic that is not in the official book.
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 not the Canvas POLISM diagram. It is an “ITILised” version of Operating Model Canvas (the ITIL 4D model doesn’t have a concept of location, especially in the world of digital products and services).
§ 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
Typo? In table 4.3, 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.
Typo? In table 4.4, 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
Phrasing. In table 4.5, in the key outputs row, I think “deployed” should be “deployed and released”, or maybe “deployed and perhaps also released”.
Phrasing. In table 4.5, 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.
§ 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.
In table 4.6, I think the key outputs section should be rephrased to maintain consistency with the purpose paragraph and with practice guides (that don’t use the term “performance record”).
Something like:
• Operating products and supporting systems.
• Product performance reports.
§ 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. This practice 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).
In table 4.7, in the key outputs section, 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 table 4.7, in the key metrics section, “agreed SLA targets” should be just “agreed targets”.
§ 4.9 Support
Typo: “Known error is problem that has been analysed but has not been resolved” should be “Known error is a problem that has been analysed but has not been resolved”.
In table 4.9, in the key outputs section, note the callback to the Operate and Deliver activities.
In table 4.9, in the key metrics section, “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 section we might also change “consumer” to “stakeholder”.
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.
§ 5.5 Practices
Note that version 5 has lost the “technical” group. The three practices that were in “technical” are now in the “product and service” group. The information security management and service financial management practices have moved from “general” to the “product and service” group.
§ 5.6 Continual improvement
§ 5.6.1.3 Where do we want to be?
(Small rant) I wish books would just say “a metric is a number and a success factor is a phrase”.
Chapter 6: Identifying, mapping, and managing value streams
§ 6.3 Value stream mapping
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 really 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.
General Comments
Bulleted Lists
(Slight rant) I don’t like the way PeopleCert uses capitalisation and punctuation in bulleted lists. Many of the practice guides have malformatted lists. The inconsistent use (or non-use) of bullet marks, capital letters, and periods makes it difficult to spot errors.
I think that bulleted lists should be formatted as follows.
• Organisations and people.
• Information and technology.
• Partners and suppliers.
• Values streams and suppliers.
Not as follows.
• organisations and people
• information and technology
• partners and suppliers
• values streams and suppliers.
Not as follows.
Organisations and people
Information and technology
Partners and suppliers
Values streams and suppliers.
The use of bullets is also badly inconsistent. Some tables use bullets even though there is only one item in the cell, some don’t. For example, compare tables 4.4 and 4.5. Some use bullets, some use a single paragraph. For example, compare the “when is it performed?” row in tables 4.1 and 4.2.