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

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

В статье подробно описан эксперимент Дэна Ариели, проведённый в 2005 году и опубликованный в 2008 году. Участникам предлагалось собирать роботов LEGO Bionicle за деньги, причём оплата за каждого следующего робота снижалась на $0,11 после первого, за который платили $2. Каждого участника относили к одной из двух групп: «Работа со смыслом» и «Сизифов труд». В первой группе участники ставили собранных роботов на стол перед собой, формируя отряд, а во второй группе ведущий сразу разбирал только что собранных роботов, объясняя это нехваткой материалов. В результате участники первой группы в среднем собрали 10,6 роботов, а второй — только 7,2. Когда оплата опускалась ниже доллара, 65% участников первой группы продолжали работу, тогда как во второй группе продолжали только 20%. Этот эксперимент показывает, что осознание значения своей работы значительно повышает мотивацию и трудовую отдачу.

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

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

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

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

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

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

Три основные причины, почему "заложенные" в процесс KPI не очень хорошо работают: 1. Авторы KPI спроектированного процесса часто слепо копируют рекомендации из "умных" книг (ITIL, COBIT и другие), не учитывая, что приведенные там метрики являются лишь примерами для иллюстрации, а не готовыми решениями, подходящими для конкретной организации. 2. При внедрении KPI часто игнорируется здравый смысл, когда стремятся измерить всё подряд и отвергают субъективные данные (например, опросы удовлетворенности пользователей), хотя некоторые аспекты управления можно и нужно оценивать через удовлетворенность. 3. KPI отдельных процессов проектируются изолированно, без учета их взаимосвязей и места в общей системе управления ИТ. Это создает фрагментарную картину вместо комплексной системы оценки деятельности ИТ-подразделения.