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

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

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

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

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

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

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

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

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

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