Метод EVM нельзя считать полноценной системой измерения успешности завершённых проектов, прежде всего из-за недостатка показателя SPI, который теряет информативность к концу проекта, автоматически становясь равным 1, что не отражает реального соблюдения сроков. Хотя EVM предоставляет ценные метрики для текущего управления проектом, особенно в части контроля бюджета через CPI, его структура не позволяет провести адекватную пост-оценку проекта по временным показателям, что критично для комплексной оценки успешности проекта, включающей качество, сроки и соответствие бюджету.

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

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

Граница ответственности — это четко определенная линия, которая разграничивает обязанности между поставщиком услуги и её потребителем. Эта граница определяет, какие элементы включены в предоставляемую услугу и за какие аспекты отвечает поставщик, а за какие — потребитель. Например, если речь идет об услуге печати в организации, граница ответственности может включать в себя не только физические принтеры и МФУ, но и инфраструктуру, такую как принт-серверы и системы мониторинга

Средний чек используется для вычисления количества транзакций, необходимых для выполнения плана продаж. Например, при плане на 1440 млн рублей и среднем чеке в 10 тысяч рублей потребуется выполнять 12 000 сделок в месяц. Зная, что каждый продавец обрабатывает в среднем 20 сделок в день, можно определить необходимое количество пользователей и спрогнозировать нагрузку на ИТ-системы. Это помогает планировать потребность в вычислительных ресурсах, сетевой инфраструктуре и поддержке со стороны Service Desk. На основании данных о количестве сделок и пользователей можно построить сервисно-ресурсную модель для оптимального распределения ИТ-ресурсов.

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

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

Тип ИТ-услуги напрямую определяет структуру процесса управления мощностями. Если услуга определена как предоставление ресурса, управление мощностями сводится к одному подпроцессу Resource Capacity Management. Если услуга ассоциирована с работоспособностью ИТ-системы, необходимы два подпроцесса: System Capacity Management и Resource Capacity Management. Если услуга ориентирована на бизнес-процессы, требуются все три подпроцесса: Business Capacity Management, System Capacity Management и Resource Capacity Management.

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

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