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

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

Минимальная схема измерения доступности ИТ-услуг в бизнес-терминах включает следующие шаги: 1) выделение функциональных блоков (направлений) на стороне заказчика; 2) сопоставление ИТ-систем с функциональными направлениями заказчика; 3) определение критериев доступности для компонентов ИТ-услуг; 4) реализация сбора данных о (не)доступности ИТ-услуг и их компонентов; 5) расчёт доступности ИТ-обеспечения функциональных блоков на основе данных о доступности соответствующих ИТ-услуг и компонентов. Эта схема рассматривается как отправная точка, от которой можно постепенно двигаться к более детализированному учёту критических бизнес-функций (VBF).

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

Референтная модель стандарта INCITS 359-2012 состоит из двух частей: референтная модель и административная функциональная спецификация. Референтная модель определяет множества элементов, которыми оперирует стандарт: пользователи, роли, права доступа, операции и объекты (доступа). В её состав входят четыре компонента: Ядро (Core RBAC), Иерархичность (Hierarchical RBAC), Статическое разделение обязанностей (Static Separation of Duty) и Динамическое разделение обязанностей (Dynamic Separation of Duty). Ядро является обязательным компонентом при использовании подхода RBAC и определяет минимально необходимый набор элементов и связей для построения целостной системы.

Для определения идеальных качеств менеджера для конкретной компании необходимо провести собственное исследование, подобное тому, что провела Google в рамках Project Oxygen. Это включает в себя проведение интервью с сотрудниками, анализ данных по методу «360 градусов», опросы уходящих сотрудников и оценку эффективности деятельности текущих руководителей. На основе полученных данных можно выявить, какие именно качества и компетенции наиболее влияют на результативность работы подчинённых в вашей организации. Полученный список может содержать разное количество пунктов, от двух до двадцати, и будет уникален для каждой компании, так как зависит от специфики её деятельности, культуры и целей.

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

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

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

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