Составление подробных нормативов на выполнение работ является сложной задачей, потому что требуется создать и постоянно обновлять свод всех атомарных операций, из которых могут формироваться любые комплексные задачи. Это требует значительных ресурсов и времени, сопоставимых с работой специализированных институтов, как в строительной отрасли. Кроме того, в условиях постоянно меняющихся технологий и процессов поддержание актуальности такого свода нормативов представляет собой непрерывный и трудоемкий процесс.

В ITIL указывается, что если изменение является частью релиза, то его построение, тестирование и развёртывание координируются процессом управления релизами. Это означает, что процесс управления релизами берёт на себя общее руководство всеми изменениями, входящими в состав данного релиза. В результате, при планировании и реализации нескольких связанных изменений, которые должны быть внедрены одновременно, управление релизом становится центральным процессом, обеспечивающим успешное внедрение всех компонентов в согласованном порядке. Координация происходит на уровне процесса в целом, а кто конкретно выполняет эту координацию, зависит от внутренней структуры организации.

Различные культурные установки, на которых строятся языки, влияют на восприятие терминологии ITIL. Это создает барьер для не-англоговорящих специалистов, так как термины и их интерпретации могут не иметь прямых аналогов в других культурах и языках, что усложняет понимание методологий.

Концепция Definition of Done решает проблему неоднозначного понимания того, что считается завершенной работой. Отсутствие четких критериев завершения приводит к недопониманию между различными участниками процесса (разработчиками, тестировщиками, менеджерами), преждевременному объявлению задач завершенными и последующим проблемам в эксплуатации. Использование Definition of Done обеспечивает единое понимание завершения работы, повышает качество продукта, минимизирует риски и обеспечивает прозрачность процесса для всех заинтересованных сторон.

Проблема размытости границ между работой и личной жизнью заключается в том, что в современных условиях с гибким графиком и работой по душе становится сложно провести чёткую грань между профессиональной и личной сферами. Автор отмечает, что когда люди находят работу, которая им нравится, они полностью в неё погружаются, постоянно совершенствуются и устанавливают гибкий график, который не имеет чётких временных рамок начала и завершения рабочего дня. В результате люди часто выполняют семейные обязанности в будни и занимаются работой по выходным, при этом ожидается, что они успеют выполнять как профессиональные, так и личные обязательства на высоком уровне.

Динамические роли - это комбинация ролевой модели с динамическими атрибутами, например, временем суток. Набор ролей пользователя определяется динамически системой управления доступом. В зависимости от реализации, система может полностью динамически определять набор ролей пользователя либо присваивать один из заранее определенных наборов авторизованных ролей. Это позволяет значительно сократить количество необходимых ролей при сохранении гибкости системы.

Главный недостаток традиционных метрик заключается в том, что они не дают полного ответа на вопрос, насколько действительно быстро устраняются инциденты. Доля своевременно решенных инцидентов оценивает выполнение установленных сроков, а не максимальную возможную скорость реагирования. Среднее время устранения не учитывает, в частности, время ожидания в очереди до начала работы над инцидентом, что может составлять значительную долю общего цикла решения.

Существует два основных типа функциональной эскалации: с произвольным маршрутом и с фиксированным маршрутом. При эскалации с произвольным маршрутом специалист, отвечающий за обработку инцидента, самостоятельно выбирает следующий шаг в зависимости от результатов диагностики. При эскалации с фиксированным маршрутом для каждой ИТ-услуги заранее определен состав линий поддержки и ответственность каждой линии. Фиксированный маршрут представляет собой строгую последовательность передачи инцидента между уровнями поддержки (например, L2-L3-L4), где каждый уровень имеет конкретные полномочия и зону ответственности.

В роль-ориентированном подходе окончательный набор прав пользователя формируется в результате пересечения двух множеств: прав, предоставляемых выбранной ролью, и прав, которые допустимы в текущем контексте согласно атрибутным правилам. Система сначала определяет роль пользователя (или набор ролей), получая базовый набор прав, затем проверяет этот набор против атрибутных правил, отфильтровывая те права, которые запрещены в текущих условиях (например, в определенное время суток или при определенном местоположении). В результате пользователь получает только те права, которые разрешены как его ролью, так и контекстом выполнения операции.

Игра Grab@Pizza демонстрирует несколько ключевых аспектов взаимодействия бизнеса и ИТ: важность эффективной работы связки Business-SLM-Change для успеха бизнеса, сложность оценки и приоритизации ИТ-инициатив без их обоснования бизнес-выгодами, необходимость активной позиции технической поддержки в получении информации о предстоящих изменениях, а также использование финансовой системы координат как общего инструмента для согласования позиций бизнеса и ИТ. Игра также показывает, что успех бизнеса во многом зависит от способности ИТ-отдела управлять инцидентами и поддерживать стабильность инфраструктуры.