Управление жизненным циклом процесса в COBIT 5 включает универсальные задачи, которые применимы ко всем процессам, в отличие от хороших практик, которые специфичны для каждого конкретного процесса. Жизненный цикл процесса охватывает такие этапы, как планирование, создание/внедрение, использование/эксплуатация, мониторинг и обновление, которые можно упростить до цикла PDCA (планирование-делание-проверка-действие). Эти задачи включают постановку целей, создание плана, проведение измерений, оценку процесса и планирование его совершенствования. Управление жизненным циклом свидетельствует о зрелости процесса и проверяется в таких подходах, как CMMI-SVC, COBIT PAM и TIPA.

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

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

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

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

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

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

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

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

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