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

Принцип "клиент всегда прав" не работает в условиях слабой конкуренции, так как компании не зависят от лояльности клиентов из-за отсутствия альтернатив. Когда спрос превышает предложение, бизнес может позволить себе игнорировать требования клиентов — те всё равно вернутся, потому что некуда пойти. Например, в тексте отмечается, что компании не волнует, вернется ли клиент, потому что рынок не создает условий, где клиентский опыт влияет на выживание бизнеса. Это приводит к ситуации, когда даже негативный опыт не отпугивает клиентов, и компании не мотивированы следовать философии клиентоориентированности.

Совет по руководству информационными технологиями и телекоммуникациями (ICTGC) Бахрейна сгруппировал 37 процессов COBIT5 в 8 блоков: Стратегия и руководство, Управление финансами, Люди и ресурсы, Инфраструктура и эксплуатация, Управление приложениями, Планирование услуг и архитектура, Управление рисками и безопасностью, Управление портфелем и проектами. Эта группировка была сделана для лучшего управления ИТ в контексте развития электронного правительства.

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

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

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

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

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

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

С 2016 года команда разрабатывала курс "Основы DevOps", а с 2017 года начали его проведение. К концу 2017 года первая версия курса была полностью переработана, что позволило улучшить структуру и содержание программы. Это было связано с тем, что DevOps была относительно новой темой для команды и требовалось лучше понять, насколько она релевантна целевой аудитории.