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

Ресурсы (персонал, оборудование, материалы) зачастую выступают внутренним вопросом проектной группы, а не ограничением, которое непосредственно относится к заказчику. Хотя ресурсы действительно могут влиять на выполнение проекта (к примеру, недостаток квалифицированных специалистов может замедлить работу), обсуждение и решение ресурсных вопросов часто не выносится на уровень клиента, в отличие от таких параметров как сроки, бюджет, качество и охват, которые понятны заказчику и напрямую влияют на его ожидания. Заказчик обычно не озабочен внутренним ресурсным обеспечением проектной команды, поэтому менеджеры проектов решают ресурсные вопросы самостоятельно, используя доступные деньги и возможности.

Концепция Definition of Done решает проблему неоднозначного понимания того, что считается завершенной работой. Отсутствие четких критериев завершения приводит к недопониманию между различными участниками процесса (разработчиками, тестировщиками, менеджерами), преждевременному объявлению задач завершенными и последующим проблемам в эксплуатации. Использование Definition of Done обеспечивает единое понимание завершения работы, повышает качество продукта, минимизирует риски и обеспечивает прозрачность процесса для всех заинтересованных сторон.

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

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

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

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

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

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

Современные компании формулируют свою ориентацию на клиента более профессиональным и структурированным языком. Например, одна компания указывает в своём описании: «Основное направление деятельности компании Х – наиболее качественное удовлетворение покупательского спроса». Это подчеркивает стремление к высокому качеству обслуживания, сохраняя суть клиентоориентированности, которая существовала и в девяностые, но в новой форме.