Необходимость новой метрики определяется через ответы на три вопроса: 1) Решает ли она конкретную управленческую задачу? 2) Можно ли изменить действия команды на основе ее значений? 3) Соизмеримы ли затраты на сбор данных с ожидаемым эффектом? Например, метрика «доля обращений с некорректной классификацией» оправдана, если данные искажения приводят к ошибкам в отчетности или ухудшению качества сервиса. Если улучшение метрики не влияет на другие показатели, от нее стоит отказаться.

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

Серверное ПО редко становится приоритетом, потому что его установка и настройка обычно централизованы и контролируются ИТ-отделом, что снижает риск неучтённых копий. В отличие от клиентского софта (например, Microsoft Office или Photoshop), который сотрудники могут устанавливать самостоятельно, серверные продукты часто имеют чёткие процедуры развёртывания и лицензирования. Поэтому основные проблемы и нарушения чаще возникают именно с «прикладным» ПО, которое люди копируют на рабочие станции без согласования.

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

Совместимость и правильную компоновку компонентов RBAC регулирует стандарт INCITS 459-2011 «Information Technology - Requirements for the Implementation and Interoperability of Role Based Access Control». Этот стандарт описывает допустимые сочетания компонентов (функциональных наборов) и интерфейсы, что обеспечивает правильную интеграцию различных элементов системы RBAC. В то время как INCITS 359-2012 определяет референтную модель и INCITS 494-2012 расширяет её возможностями по обработке динамических ограничений, INCITS 459-2011 отвечает за то, чтобы все эти компоненты могли работать вместе корректно и обеспечивать совместимость между различными реализациями систем управления доступом на базе RBAC.

В области IT эффект Даннинга-Крюгера проявляется в нескольких аспектах. Например, существуют проекты разработки программного обеспечения, где команды считают нормальным писать «лучший в Галактике код», но при этом не могут выйти на продуктивную эксплуатацию в течение 3-5 лет. Есть команды, которые выпускают релизы раз в месяц, игнорируя современные практики ежедневных релизов. Также встречаются разработчики, которые не понимают CI/CD и настаивают на ручном тестировании, администраторы, считающие всех разработчиков некомпетентными, и консультанты, которые без глубокого понимания процитируют Agile-литературу. Все эти ситуации указывают на то, что многие профессионалы неадекватно оценивают свои знания и навыки.

Учет времени необходим для объективной оценки рабочей нагрузки, потому что субъективные оценки и попытки вспомнить затраченное время часто приводят к серьезным искажениям. Как показано в примере, сотрудник сначала заявил о 215% загрузки, которая после проверки снизилась до 85%. Только точный учет позволяет получить реальную картину распределения времени и нагрузки, что критически важно для планирования, распределения задач и оценки продуктивности.

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

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

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