adaptiman.com

Author: adaptiman

  • Taxonomy of Work in DPSM: A Revision

    Taxonomy of Work in DPSM: A Revision

    This morning, I got in my car to go to work and the battery was dead <groan>. I had two choices. I could use my 15-passenger van to get to work (not the most stylish choice), or bite the bullet, run to Wal-Mart, and get a new battery. Fortunately, I’m in the habit of building slack time into my morning, so I had about an hour before I REALLY needed to be on my way. Slack time helps when the unexpected happens. Do unexpected things ever happen in technology management?

    As I was driving to the store, I starting thinking about unplanned work. I first heard the term when I read The Phoenix Project by Gene Kim, Kevin Behr, and George Spafford. Understanding unplanned work was a game changer for our organization. Everyone gets handed stuff from their boss with the predictable epigraph, “I know you’re busy, BUT…” Unplanned work comes up all the time. But until you name it, it doesn’t become visible, and you can’t manage it. A lack of work visibility is the crux of most (if not all) DPSM problems.

    The Phoenix Project divides technology work into four categories.

    • Business Projects
    • Internal Projects
    • Changes
    • Unplanned Work

    Since the book was written, we’ve had some time to consider this taxonomy of work and refine it. With the publication of ITIL Transformation, we’ve become more aware of the difference between the “day-to-day” work we do and other types work. The first category can be termed “business as usual” or BAU. The second can be termed transformations.

    Business as Usual

    BAU includes all of the stuff we do on a day-to-day basis. It includes all work to support the products and services we currently deliver.

    Change

    Based upon this, change would fall into BAU because it is necessary for continued product and service delivery. Change (i.e., Change Enablement ala ITIL), is not a type of project because it is doesn’t meet the definition – it is not unique and usually doesn’t require the creation of a temporary organization.

    Operational

    However, change is not the only type of BAU work we do. We do lots of day-to-day things that are not changes. For example, incident management, service request management, asset management, etc. This work may result in changes (in the change enablement sense) but is not, strictly speaking, change. So what do we call this? I would call it “operational work.”

    Unplanned

    But what about unplanned work? An organization I worked for was struggling to get a handle on the work it was doing. We were always operating in “pants on fire” mode, reacting to the emergency of the day. A good portion of the work was unplanned. We recognized that this was a lack of work visibility. ( Making work visible is, I think, the biggest problem we have in technology, and it always has been.) So we started tracking time on a quarterly basis – NOT the unplanned work time – but the project and operational work each team did. Our deduction was that the the sum of operational and project work would allow us to calculate how much unplanned work each team was doing (minus a fudge number for non-productive time).

    What we found was that each team had a predictable percentage of unplanned work. There was predictable variation (i.e., a standard deviation) in the unplanned work and also cyclical variation over the year. Even so, within six quarters, we had enough data to calculate percentages of unplanned work for each team and calculate the mean unplanned time per team per quarter. Essentially, we had proven that we could plan for unplanned work. And this meant that unplanned work was a category of BAU.

    Transformations

    According to ITIL, a transformation is a “programme/project/effort that the owner/sponsor(s) needs to carry out successfully, consisting of many activities, usually divided between many workstreams.” I’m not a big fan of this definition so let’s simplify and clarify:

    A transformation is a project or program that improves a product, service, value stream or organization.

    Projects

    Let’s look at this definition a little closer. First, transformations are always projects or a collection of related projects (i.e., a program). Because transformations are projects, they have the characteristics of projects. They are unique, time-limited, and outcome-focused. They are the antithesis of BAU.

    Internal vs. Business Projects

    There is functionally no distinction between business and internal projects – both are projects, exhibit the characteristics of projects, and fall under the category of transformations. There is a categorical difference, though. Business projects are those that are forward-facing, that is, projects that will improve a product or service destined for an external stakeholder. Their outcomes are within the band of visibility of the customer journey. Examples would be new or improved lines of business. Internal projects are the opposite – they seek to improve a something that external stakeholders don’t see. Examples would be improvements in the value chain, reorganizations, and organizational change management efforts.

    I understand why the distinction was originally made. We used these categories as a way to determine which governance path a project fell under. Business projects were governed by the business, while internal projects fell under the auspices of the CIO. However, both of these work types can be considered transformations under our definition.

    How BIG Are Transformations?

    There is another difference between the ITIL definition and the new one. Last year, the ITIL Transformation authoring team wanted to denote the idea that transformations are big. It’s why the ITIL definition of transformation uses the word “many” – many activities, many workstreams. But I think there is a fundamental error with this type of thinking. All projects seek to change something, whether the change is big or small.

    Transformations seek to improve products, services, value streams or the organization itself. This list is the known ‘universe’ of work in an organization, which is another way of saying that transformations apply to all types of work. But there is also a hidden cost here. Once the transformation is over, many transformations inflate BAU because they increase the future operational, change, and unplanned work of the organization.

    Successful projects are like missiles shot into the BAU. Each successful project results in BAU inflation. Be careful you don’t get eaten.

    In Summary

    Based upon these points, we have two high-level categories of work defined – transformations and BAU. All projects are transformations. We subdivide transformations into internal and business projects, mainly to facilitate governance and portfolio management. Transformations can result in future inflation of BAU. BAU work consists of three sub-categories; operational, change, and unplanned. Taken together, these five categories of work define the universe of what we do in DPSM.

    Bibliography

    Kim, G., Behr, K., Spafford, G., & Safari, an O. M. Company. (2013). The Phoenix Project / Kim, Gene. (1st edition.). IT Revolution Press. (amul.7ca7a398.1f4e.35cb.af33.0bf0fc7e74c4). https://research.ebsco.com/plink/dcd4d451-5d77-3b11-87f9-6194db00a1b6

    PeopleCert (2025). PRINCE2® Project Management Version 7. (2025). PeopleCert.

    PeopleCert (2026). ITIL® Transformation (Version 5). PeopleCert. https://ebook.peoplecert.org/books/9789925391745

  • Maintenance

    Maintenance

    My house requires maintenance.
    It truly vexing is.
    The front door paint is peeling,
    The flower beds need weeding,
    The parched brown grass needs feeding,
    The ice machine is leaking,
    And rotted floorboards weeping –
    Their damp somehow escaping
    To stain the kitchen ceiling.
    It all creates much feeling.
    It truly vexing is.

    And so, reluctantly, I rise
    To effort ere it’s vain.
    The left hip aches and creaks a bit,
    And bunyans cause my teeth to grit.
    Arthritis makes my fingers knit
    And falter donning my outfit.
    My cracking body must submit
    To effort ere it’s vain.

    And then, I realize in a flash
    My anger is misplaced.
    This house has carried me so far –
    My earthly temple meets the bar
    So to complain would seem bizarre.
    My anger is displaced.

  • How To Balance Human and Agentic Effort in Four Basic Rules

    How To Balance Human and Agentic Effort in Four Basic Rules

    Humans have a natural bias for human-generated content. Why? Does this bias ultimately serve them? Using AI as a collaborator to aid the authoring process can be tricky. Clarifying your stance on the value of AI will help you move from a default position of fear to a collaborative approach in using AI appropriately and effectively.

    Let’s face it. People are afraid AI will replace their jobs, and there’s no question that AI is a gamechanger in many industries. The use of AI-generated content across all media domains is becoming common. “Deepfakes” on social media are one dark example of AI-generated creative content. AI-generated celebrity voices are another. Concern about AI replacing human pursuits is real but is it as bad as they say? The problem is that humans are just at the beginning of their journey to determine how to use AI appropriately and responsibility. In this article, I will examine potential reasons why people value human created content more and solutions to balance AI and human generated content.

    • Examples of human bias towards AI
    • The value of artistic struggle
    • The philosophy of AI
    • AI doesn’t play fair
    • How to balance human and agentic work

    Examples of human bias towards AI

    I had an interesting conversation with a group of AI experts who are working on a book. One of the criticisms of the book was that it appeared a large part of it was written by AI and some in the group didn’t like that. The inference was that AI-written content is inferior to human-written content. But is it?

    As another example, several months ago, there was a story about Michael Caine selling the rights to use his voice likeness to Elevenlabs for an audio recording of the Odyssey. Elevenlabs received significant pushback from early consumers that the voice was too mechanical, without emotion, and other criticisms. I thought the voice was pretty good, so listen for yourself and make your own judgement.

    Objectively, AI-generated content might be better than human-generated content, but humans have started to unconsciously discriminate against it. As the talk reverted to “markers of AI” and “AI slop”, it was apparent that many in the group were trying to label the material as “AI-authored” in order to discount it. Interesting. Why do people judge human writing as something that is more valuable? Does philosophy offer an answer to the bias for greater effort?

    The value of artistic struggle: TIME

    Two thoughts occurred to me. First, value is subjective. It is defined by the consumer and subject to change with context. So in the case of a written product, the consumer would be the reader. My small sample of contributors (probably not a representative sample) were inferring that the value of the AI-authored material was less. Indeed, I saw the same “markers” they did – the repetitive prepositional phrasing, the consistent tone and structure, formulaic transitions (i.e., In summary…) and suspiciously clean but slightly “off” language. But the content of the material was logical, ordered, and clear, in many ways, much clearer than something I would write. Of course, these “faults” in the text can be controlled with clear and complete style prompts to keep AI in check. So a skilled AI consumer could mitigate many of these issues. Even so, all or part of the material would be AI-generated. It seemed the bias was more about the manner the material was created, not the material itself. Something else was at work here.

    The philosophy of AI

    The second thought was that this phenomenological bias for human-created text probably had been addressed by a philosopher somewhere along the way. So I asked AI if there were applicable philosophical constructs.

    People tend to value human-written work more because they see effort, intention, and a conscious inner life behind it, and they treat those “behind-the-scenes” features as part of what they are really buying or engaging with—not just the surface text. In philosophy, this connects to a cluster of ideas: effort-based value (the “effort heuristic”), theories of achievement, and views like Kant’s that locate value in rational agency and good will rather than just in outcomes.

    AI on Us

    There is empirical support for this. Several studies report that when the same or similar output is labeled “AI” instead of “human,” people report it as less creative, less labor-intensive, and less valuable, even if they admit the quality is comparable. In art experiments, participants valued works labeled as AI-generated up to 60% less than those labeled as human-made, mainly because they associated human works with more labor, passion, and a personal narrative (Bellaiche et al., 2023).

    Aristotle describes a flourishing life as exercising excellences of character and intellect through activity over time—habits, training, and deliberate practice. From this perspective, written products are valuable not just as an object but as the visible tip of a long iceberg of cultivated character, judgment, and practical wisdom. AI can produce similar products, but it does not live the journey of excellences. Is this the soul? Is the ether of our soul the sum of the experiences and struggles we have in this life?

    Subscribe to DPSM Education to get more stories like this.

    AI doesn’t play fair

    Another truth I’ve realized about using AI is that my time is valuable. AI doesn’t operate in time like humans do (was Einstein right?). And this is its main advantage. The “cost” of AI is measured in tokens, not minutes. What a wonderful tool to reduce the human time it takes me to research a topic from days to hours. That seems to me to be valuable use of my time – assuming that what I consume is not too overly biased or incomplete – a big assumption.

    As for myself, for technical writing, I follow the 20-60-20 advice. I spend 20% of my time in prompt engineering so I’ll get a good result. Let AI do 60% of the heavy lifting. Then edit and polish for 20% of my writing. The net result is that I’m much faster and more productive than I used to be. So is everybody else. So is it worth it?

    If we treat an AI model as a drafting tool—like a very powerful thesaurus or research assistant—but hold ourselves to high standards of judgment, originality, and ethical responsibility, what part of the book’s value really depends on the keystrokes being human?” That keeps the focus on the message and on the genuinely human intellectual work, rather than on a purity test at the sentence level.

    AI on Us

    I couldn’t disagree more. At the end of the day, there is something about my fingers flying over the keyboard as I write this sentence that gives me a sense of pride that I wrote this – not some soulless machine. And so it comes down to this. People value human-generated content more because of the time and effort it takes to create it. Call it creative suffering, the artistic soul, or whatever you want. The only difference is time, really. AI doesn’t operate within human time. This leaves us with two choices. We can see AI generated content for what it is – a transformational tool that gives us back the most precious resource humans have. Or we can view AI as a usurper, stealing the glory of our artistic blood, sweat, and tears and therefore less than us. Here’s the truth – AI is a tool. And humans can create more with AI than without.

    How to Balance Human and Agentic Work

    Considering all of this, here’s a set of considerations to guide authors in appropriate collaboration with AI.

    Humans do the thinking

    “AI slop” is most often a function of “human slop.” Vague prompts produce vague responses. You have to know what you’re doing before approaching AI, otherwise, you risk Narcissus’ mirror. AI will simply tell you what you want to hear.

    Before ever entering a prompt, write down the purpose and general structure of your piece. If you use AI to mine for ideas, don’t expect the responses to be useable. Do your own thinking and use AI to confirm or contradict your ideas.

    AI does the heaving lifting

    AI doesn’t operate within time as humans do. Since our time is more valuable, AI should be used to do the monotonous tasks such as research, proofing, editing, and evaluating. Follow the 20-60-20 model. This creates a collaboration, not a crutch.

    Don’t compete

    Don’t try to write like AI. Let your own voice shine through. If you like to tell stories, tell them. If you like to use emotional words, do it.

    Nothing goes out without being reviewed

    It goes without saying that you shouldn’t copy and paste AI generated content into anything, unless there is a specific reason to do so (such as some of the “AI on Us” examples above). When you do, make sure the reader knows what is created by AI and what is created by you.

    For my own process, I may read AI answers, but always author those ideas tempered with my own and within the context of my article. Context is the great marker of human vs. agentic authored content. Make sure you are the sole author contextually.

    Subscribe if you like DPSM Education
    The purpose of ITSM Education is to bring the professional Digital Product and Service Management community together. I write about digital product and service management, organizational maturity, and leadership. Published articles appear every month for free. If you’re a professional technical manager, considering subscribing to DPSM Education.

    Bibliography

    Bellaiche, L., Shahi, R., Turpin, M. H., Ragnhildstveit, A., Sprockett, S., Barr, N., Christensen, A., & Seli, P. (2023). Humans versus AI: whether and why we prefer human-created compared to AI-created artwork. Cognitive Research: Principles and Implications, 8, 42. https://doi.org/10.1186/s41235-023-00499-6

  • Beloved Son and Daughter

    You’re leaving.
    The blue van recedes down the driveway and I wonder if the kids have shut their eyes yet.
    I walk back to the house, conscious of the pain of the rocks under my feet.
    I don’t know why I didn’t put on my shoes.
    The house, which moments ago was draped in the warm cacophony of shouts and giggles, now lies silent and horizontal.
    I distract myself.
    The first egg breaks too soon and the golden yolk slides toward me and down on the floor.
    I pour salt on it and wait for it to mend into something I can grasp.
    Tears stream.
    When will you return?

  • ITIL Service Clears the Path

    ITIL Service Clears the Path

    ITIL Service (Otubela et al, 2026) represents the latest stage in the evolution of ITIL from a process-oriented framework into a model for managing digital products and services in complex environments. The “big ideas” in this book are not entirely new, but they are reframed and integrated in ways that reflect the realities of complex, fast-moving, and technology-driven organizations. Earlier versions of ITIL established the foundations of service management through standardization and control. ITIL 4 introduced a shift toward value, collaboration, and adaptability. However, these changes often left practitioners with a broad set of principles but less clarity on how to apply them coherently in practice. ITIL Service can be understood as an attempt to clarify the path forward—translating these ideas into a more explicit, connected, and operational model. It does not abandon ITIL’s heritage but instead organizes it into a clearer route from strategy to execution, helping organizations navigate the increasing complexity of digital service management.

    The first major shift is from process-centric thinking to activity-based, flow-oriented service management. Earlier versions of ITIL organized work into discrete processes such as incident, change, and problem management, often leading to siloed execution. ITIL Service instead structures service management around interconnected value chain activities that can operate concurrently and iteratively. These activities emphasize flow across the lifecycle rather than handoffs between functions, reflecting a deeper alignment with value stream thinking and modern operational models . This marks a move away from procedural compliance toward enabling continuous movement of work and value.

    A second key idea is the full integration of product and service thinking. Historically, ITIL treated services as the primary object of management, with product management largely outside its scope. ITIL Service recognizes that in a digital economy, products and services are inseparable: products provide capabilities, and services enable their consumption and value realization. By embedding service management within a broader product and service lifecycle, ITIL Service aligns itself with contemporary organizational structures where cross-functional teams manage both product evolution and service delivery together. This closes a long-standing gap between ITIL and product-centric approaches.

    The third idea is the extension of value co-creation into a broader ecosystem model. While value co-creation was introduced in ITIL 4, ITIL Service deepens this concept by emphasizing the complex networks of providers, partners, vendors, and consumers involved in delivering modern services. Value is not simply co-created between a provider and a consumer but emerges from interactions across an entire ecosystem of stakeholders. This reflects the increasing interdependence of organizations and the need to manage shared responsibilities, integration points, and collective outcomes across service relationships . The concept evolves from principle to practical operating reality.

    …in a digital economy, products and services are inseparable: products provide capabilities, and services enable their consumption and value realization.

    Another important shift is the emphasis on end-to-end lifecycle responsibility. Earlier ITIL lifecycle models defined stages such as design, transition, and operation, but these were often implemented in organizational silos. ITIL Service operationalizes the lifecycle as a set of continuously interacting activities, supported by feedback loops from operations, delivery, and support. This reinforces the idea that services are never “finished” but are continuously shaped by real-world use, performance data, and stakeholder feedback . The lifecycle becomes a living system rather than a sequence of phases.

    ITIL Service also elevates experience as a core dimension of value. Traditional ITIL focused heavily on service quality in terms of availability, performance, and reliability. While these remain important, ITIL Service explicitly incorporates experience alongside utility, warranty, and sustainability as a determinant of value. This reflects the growing importance of user perception, usability, and satisfaction in digital services, where technical correctness alone is insufficient. Service success is therefore defined not just by whether it works, but by how it is experienced by users and customers .

    Another defining characteristic is the alignment of service management with modern engineering practices. ITIL Service explicitly integrates concepts from Agile, DevOps, and site reliability engineering, positioning service management as part of the delivery system rather than an external control function. This represents a significant cultural and operational shift from earlier ITIL versions, which were often seen as bureaucratic or resistant to change. In ITIL Service, service management supports speed, automation, and continuous delivery while maintaining reliability and governance .

    Closely related is the recognition of complexity and non-linear work. Earlier ITIL guidance implicitly assumed relatively stable and predictable environments where processes could be predefined and optimized. ITIL Service acknowledges that modern service environments are dynamic, with work triggered by events, feedback, and changing conditions. Activities are not strictly sequential and may occur in parallel or be revisited repeatedly. This reflects a more realistic understanding of how digital organizations operate and aligns ITIL with contemporary complexity thinking.

    Finally, ITIL Service incorporates AI and automation as foundational capabilities. While previous versions of ITIL treated tools as enablers, ITIL Service positions AI as integral to service management across the lifecycle, supporting prediction, automation, and decision-making. This reflects the increasing role of data-driven and AI-enabled systems in managing scale, complexity, and speed in digital services . Automation is no longer optional optimization but a core component of effective service management.

    ITIL Service does not radically redefine ITIL so much as it clarifies the path that ITIL has been moving along for years. The core ideas—value co-creation, lifecycle thinking, integration with modern practices, and continual improvement—are largely inherited from earlier versions, particularly ITIL 4. What this book contributes is a clearer structure for applying these ideas in real-world contexts, connecting them into a coherent model that reflects how work actually flows in modern organizations. In that sense, ITIL Service earns its place in the ITIL canon not by introducing entirely new concepts, but by making the direction of ITIL more visible, actionable, and aligned with the realities of digital product and service management.

    Bibliography

    Otubella, G., .(2026) ITIL Service [Book]. PeopleCert.

  • Big Ideas That ITIL® Product Brings to the Table

    Big Ideas That ITIL® Product Brings to the Table

    With the imminent release of ITIL® Product (Gray et al, 2026), PeopleCert has expanded the scope of traditional Service Management by combining Digital Product and Service Management. While product concepts are present throughout all of the new books, ITIL® Product reframes product development as an end‑to‑end lifecycle that runs from discovering opportunities to operating and continually improving digital products and services, rather than as a narrow “build” phase inside projects. This mirrors the historical shift from early brand management, where a single manager was accountable for a product’s commercial performance over time, to modern product management, which owns outcomes across discovery, design, delivery, and operations. By explicitly structuring the lifecycle into activities such as Discover, Design, Acquire, Build, Transition, and Operate, ITIL® Product codifies the same holistic view that has gradually emerged in the history of product development as organizations moved away from one‑off project thinking toward continuous product stewardship.​

    A second big idea is the strong emphasis on aligning product work with vision, strategy, and portfolio, which reflects the evolution from “feature factories” to outcome‑driven product organizations. In the Discover and Design chapters, ITIL® Product repeatedly stresses the need to understand context and inputs, agree direction and objectives, and ensure that product roadmaps stay anchored in organizational strategy and value creation. Historically, this echoes the move from reactive, sales‑driven roadmaps toward strategic product management, where decisions are guided by portfolio trade‑offs, positioning, and long‑term customer value rather than just near‑term delivery capacity.​

    ITIL Product® also embeds cross‑functional collaboration and agile ways of working as core success factors, which parallels the industry’s shift from siloed development and operations to integrated product teams. The Build and Operate chapters highlight critical success factors such as strong collaboration between engineering, product management, design, and quality assurance; agile cadences; automated CI/CD pipelines; and incremental delivery with feature toggles and safe rollouts. These practices track closely with the historical rise of Agile, DevOps, and empowered product teams that own the full lifecycle, breaking down the old handoffs between development, operations, and service management.​

    Another major theme is the product‑and‑service value chain: ITIL® Product systematically ties product decisions to the realities of cloud sourcing, service providers, and operational environments, including activities like acquiring cloud services, planning transitions, and coordinating responsibilities between vendors and service providers. This reflects how modern product development history has moved from shipping boxed software or discrete projects to operating live digital services in complex ecosystems. As organizations adopted SaaS, cloud platforms, and managed services, product management had to expand its remit to include sourcing, deployment, and long‑term operability—precisely the terrain ITIL® Product formalizes.​

    Finally, the book’s focus on metrics and continuous improvement—such as delivery velocity, cycle time, defect leakage, and team health—as part of each lifecycle activity reflects the historical maturation of product development into a data‑driven discipline. ITIL® Product treats these measures and their associated “critical success factors” as integral to managing products effectively, not as optional reporting after the fact. This aligns with the broader trajectory from intuitive, craft‑driven product development to modern product operations and analytics practices, where teams continuously learn from production feedback and telemetry to refine products and processes over time. ITIL® Product is definitely a contribution to the field and connects to the broader concepts of ITIL® nicely.

    #ProductManagement #ITSM #PeopleCert

    Bibliography

    Gray, V., Konageski, W., & McDonald, S. (2026). ITIL Product [Book]. PeopleCert.

  • I’m BAAAACK

    I’m BAAAACK

    You may have noticed that I haven’t been active on my blog site (https://adaptiman.com) for some time. Good news – nothing happened to me, I’m not sick, or burned out. I spent the last year working with PeopleCert on the authoring team writing the newest version of ITIL®. The authoring and editorial team at PeopleCert is unbelievable and worth a longer description. In the coming days, I will share my insights on new ITIL®, the authoring process, and how the new version will affect our profession moving forward.

  • The New ITIL is Here

    The New ITIL is Here

    Three weeks ago, PeopleCert released the latest version of ITIL® Foundation . This is the fifth version of ITIL® released since 1989 and, in my opinion, could be the best yet. I was one of the authors for the new version. The experience was eye-opening on a number of levels, which I will describe below. But first, most colleagues want to know what is different with this version – why would I want to spend money to get certified for version 5?

    What’s New?

    There are three main changes to Foundation with a number of smaller but meaningful updates. Most importantly, ITIL® has expanded its scope beyond IT Service Management (ITSM) to include Product Management. The language in Foundation has changed from “ITSM” to “DPSM” (Digital Product and Service Management). This shift, while subtle, is seismic. The product management community has had a long run operating outside the scope of ITSM and created their own tribe. Product managers have their own way of looking at the world of digital products and services. So for PeopleCert to expand into their territory feels a little like stolen land without an acknowledgement. Even so, the purpose in doing this is mainly to address criticism that ITIL® has been too “operational” over the years, not focused enough on the product and service strategy, creation, design, and transition. I agree with this criticism and believe it’s the right thing to do to provide greater more comprehensive coverage of “this thing we do.”

    Pasted image 20260303223628.png

    This shift becomes apparent in a number of changes. The new ITIL® Digital Product and Service Lifecycle represents the Service Value Chain as a cycle of activities that move from the product management side of the model (Discover, Design, Acquire, Build, Transition) to the service management side of the model (Transition, Operate, Deliver, Support). This is a redux of the ITIL® version 3 Service Lifecycle within the context of the Service Value Chain Activities. I think it’s a more complete way of looking at the whole.

    Another notable shift is a greater focus on role capabilities rather than organizational capabilities. This is apparent in the new course designations: Product, Service, Experience, Strategy, and Implementation. The first four are focused more on organizational roles than previous version of ITIL® while Implementation address the need for clear “how to” advice – a frequent criticism of ITIL® over the years. Developing best practices around role-based capabilities helps practitioners answer the question, “Where do I fit?”

    Lastly, new ITIL® is “AI Native.” This is not a recommendation of specific AI technologies, but the development of recommendations that help organizations become disruptors rather than disrupted within increasingly VUCA environments. As with most ITIL® practices, the material related to AI provides solid recommendations that are designed to be timeless.

    The Editorial Process

    The process to create the books belonging to this version of ITIL® took more than a year of our time to complete. The authoring teams, led by two to three lead authors for each book, would write each version of the material in short two-week sprints. At the end, the version would be reviewed by the larger team for feedback and revision. Key ideas and concepts would be discussed in detail with decisions on what and what not to include going back to the core team. Surveys on contested ideas would be distributed between authoring sprints to settle sticky questions.

    Between these sprints, the excellent PeopleCert editorial team would prepare the versions, clean them up, format them, and redistribute to the authoring teams. This process was very efficient, bringing to bear the collective wisdom of the experts around the room. Even though I’ve been in ITSM for three decades, I was in awe of the expertise. The process resembled a modified Delphi research model with the world’s leading experts in our field shaping the collective direction.

    All of this adds up to a reshaping of our profession to broaden IT Service Management into Digital Product and Service Management – a long overdue upgrade to the venerable compendium of best practices we all know and love.