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

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

При отсутствии четкого определения ключевых характеристик ИТ-сервиса может возникнуть несоответствие между тем, как ИТ-отдел оценивает работу системы, и тем, как бизнес оценивает качество оказания услуги. Например, система может технически функционировать без сбоев (отправка электронной почты в момент нажатия кнопки 'отправить'), но при этом не выполнять свою основную задачу (доставка писем получателю в разумные сроки). Бизнес может быть недоволен, так как для него важен конечный результат — видимое клиентам выполнение сервиса, даже если все внутренние процессы формально работают. Также возможно длительное существование незамеченных ошибок, как в случае с рекламной стойкой, где сбойное окно оставалось месяцами, хотя реклама продолжала воспроизводиться.

Бизнес-подразделения и руководство могут создавать значительные ИТ-риски через отсутствие информирования о стратегии и планах развития, что приводит к неадекватному планированию мощностей, невозможности масштабирования и непредвиденным расходам. Еще один риск — принятие решений без консультации с ИТ-специалистами, например, при выборе аутсорсинга или покупке программного обеспечения. Это может вызвать конфликты с архитектурой и политиками безопасности, привести к появлению избыточной функциональности и создать трудности в интеграции систем и взаимодействии с подрядчиками по вопросам эксплуатации.

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

Service Owner отвечает за обеспечение соответствия предоставления и поддержки услуги заявленным требованиям. Это включает в себя постоянный мониторинг качества услуги, проверку выполнения условий SLA, участие в планировании и реализации улучшений, а также обеспечение того, чтобы услуги действительно отвечали бизнес-потребностям заказчиков. Это делает его ключевой фигурой в поддержании качества ИТ-услуг.

Руководящие принципы ITIL тесно связаны с практикой постоянного совершенствования, так как они призваны поддерживать постоянное улучшение на всех уровнях организации. Принципы, такие как "Действуйте итерационно, используя обратную связь" и "Оптимизируйте и автоматизируйте", непосредственно способствуют постоянному совершенствованию процессов и услуг. Система принципов ITIL помогает организациям определять направления для улучшения, оценивать текущее состояние и принимать обоснованные решения по внесению изменений. В частности, ITIL 4 включает в себя обновленную модель постоянного совершенствования, которая использует эти руководящие принципы как основу для планирования и реализации улучшений, что позволяет организациям гибко реагировать на внутренние и внешние изменения и непрерывно повышать качество предоставляемых услуг.

Регламент управления изменениями и релизами в контексте разработки и внедрения прикладного программного обеспечения состоит из двух основных компонентов: 1) Документ, определяющий основные стадии создания новой автоматизированной системы или выполнения доработок («Положение о разработке прикладного ПО»), который описывает состав работ, ответственных лиц, входные и выходные документы для каждой стадии. 2) Документ, определяющий порядок приёмки новых систем в эксплуатацию («Положение о внедрении информационных систем»), который включает порядок и охват тестирования, подготовку тестовых сред, опытную эксплуатацию и другие аспекты внедрения. Этот регламент может дополняться политиками релизов по информационным системам, что позволяет согласовать с бизнесом календарь релизов и определить необходимость и порядок выделения ресурсов на проведение пользовательского тестирования (UAT). В совокупности эти документы обеспечивают структурированный процесс управления изменениями и релизами при разработке и внедрении программного обеспечения.

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

Сервисный подход не всегда применим, потому что он нужен исключительно для решения задач взаимодействия ИТ-службы и заказчиков. Не все ИТ-службы взаимодействуют с заказчиками в формате поставщика услуг, и для множества стандартных задач управления деятельностью ИТ-службы сервисный подход не требуется. Задачи внутреннего управления могут быть решены и без него, поскольку они не связаны напрямую с потребностями и восприятием заказчиков.