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

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

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

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

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

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

В 2010 году в магическом квадрате Гартнера по ITSM-продуктам свои позиции потеряли такие компании, как HP, CA и IBM, которые переместились из категории лидеров в категории претендентов или нишевых игроков. При этом BMC Remedy ITSM Suite осталась единственным лидером. Изменения позиций произошли преимущественно из-за переоценки маркетинговой активности, стратегического видения и способности поддержки долгосрочных партнерских отношений, нежели из-за фундаментальных изменений в продуктах.

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

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

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