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

Наиболее часто встречающийся подход к описанию потоков ценности включает работу конвейера CI/CD, начиная со сбора требований в бэклог и заканчивая доставкой 'ценности' до продуктивной среды и получением обратной связи от потребителя. Такой подход сформировался в ходе эволюционного развития идей гибкой разработки и часто фокусируется только на прямых разработческих процессах создания ценности.

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

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

Согласно результатам опроса, в 50% компаний сервисно-ресурсная модель охватывает все ключевые услуги, то есть для всех ключевых услуг в CMDB занесены все составляющие элементы и зарегистрированы все связи. Это указывает на высокий уровень внедрения и поддержки сервисно-ресурсной модели в организациях, участвовавших в исследовании.

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

График предоставления услуги определяет периоды времени, когда недоступность учитывается в расчетах уровня доступности. Например, отказы, произошедшие ночью или в выходные, праздничные дни, могут не учитываться, если это согласовано в SLA. Также исключаются из расчета периоды планового обслуживания. Таким образом, график предоставления услуги помогает отделить временные окна, когда доступность критична, от тех, когда сбои не влияют на бизнес-процессы.

Устранением последствий разового негативного события занимается практика управления инцидентами. Она направлена на оперативное восстановление нормального функционирования услуги после её прерывания или ухудшения качества, вызванных реализовавшимся риском.

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

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