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

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

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

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

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

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

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

В DevOps важно учитывать не только плановую, но и неплановую работу при распределении ресурсов, потому что операционная часть (тот самый 'Ops') требует постоянного внимания к текущим системам и их поддержке. Неплановые задачи, такие как инциденты, исправление дефектов и срочные запросы, являются неотъемлемой частью операционной деятельности и могут возникать в любой момент. Если выделить все ресурсы только на плановую работу, команда не сможет оперативно реагировать на проблемы в эксплуатации, что приведет к снижению надежности системы и удовлетворенности пользователей. Разделение ресурсов позволяет поддерживать баланс между внедрением новых функций и поддержанием стабильности текущих систем.

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

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