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

CAAS - это условная аббревиатура (Choco-as-a-Service), используемая для объяснения концепции сервиса в ITIL. Она демонстрирует, что при продаже услуги клиенту предоставляется не просто товар, а комплексное решение, включающее сам товар, ресурс и сервисные операции. 'C' в CAAS означает 'chocolate', а 'aaS' (as-a-Service) указывает на то, что клиент получает не просто физический продукт (шоколадку), а доступ к услуге, которая включает в себя доставку, обеспечение регулярности поставок, решение проблем с доступностью и т.д. Это помогает понять, что в случае с услугой клиент перекладывает на поставщика определенные риски и затраты, что не происходит при простой покупке товара.

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

Предложенная метрика создаёт несколько положительных мотивационных эффектов: 1) Стимулирует группы оперативно обрабатывать инциденты, даже если они получены близко к окончанию срока или уже просроченными, так как любая оперативная работа повышает общий KPI. 2) Формирует правильное понимание того, что нарушение сроков – это общая проблема поставщика услуг, а не вина конкретной группы. 3) Поощряет сотрудничество между группами поддержки, так как эффективная передача и совместная работа помогут минимизировать долю каждой группы в общем времени обработки и улучшить показатели. 4) Помогает избежать практики быстрого перенаправления инцидентов ('футбола') без реальной обработки.

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

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

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

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

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

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