Использование множества уровней сервиса (например, 25 уровней) и десятков условий выбора часто оказывается неоправданным, так как можно достичь эффективного баланса с меньшим количеством уровней и правил. Это снижает сложность поддержания SLA и минимизирует потери в качестве обслуживания.

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

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

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

По данным исследования Гартнера 2006 года, из 440 опрошенных организаций ITIL использовало всего 13% компаний, в то время как 33% организаций применяли собственный внутренний подход к организации управления ИТ-процессами. Это демонстрирует, что, несмотря на громкие заявления о глобальном распространении ITIL, на практике многие компании предпочитают разрабатывать свои собственные.framework'ы управления.

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

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

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

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

После начала предоставления услуг (Service Operation) BRM решает несколько важных задач. BRM должен убедиться, что заложенная ценность извлекается – заказчик достигает необходимых результатов и его ожидания оправдываются. BRM отвечает за мониторинг удовлетворенности заказчика, выявление и сглаживание острых углов. BRM также управляет процессом обработки жалоб, обеспечивая, что ни одна жалоба не остается без внимания, и каждая из них получает ответ. BRM анализирует жалобы как сигналы о явных или скрытых проблемах и организует процесс их устранения. BRM отвечает за предоставление отчетности заказчику и проверку соответствия формальным требованиям, обеспечивая прозрачность процесса эксплуатации услуги.