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

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

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

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

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

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

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

Наиболее часто встречающиеся ошибки при расчёте Incident Rate — это неверный учёт пользователей (например, включение технических учётных записей или уволенных сотрудников), игнорирование сезонных колебаний при анализе данных за короткий период, а также включение в числитель инфраструктурных инцидентов или сервисных запросов. Чтобы избежать искажений, рекомендуется использовать годовые данные с разбивкой по месяцам и проверять качество данных в ITSM-системе.

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

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