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

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

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

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

Совет по руководству информационными технологиями и телекоммуникациями (ICTGC) Бахрейна сгруппировал 37 процессов COBIT5 в 8 блоков: Стратегия и руководство, Управление финансами, Люди и ресурсы, Инфраструктура и эксплуатация, Управление приложениями, Планирование услуг и архитектура, Управление рисками и безопасностью, Управление портфелем и проектами. Эта группировка была сделана для лучшего управления ИТ в контексте развития электронного правительства.

Международные организации, занимающиеся развитием и обменом знаниями в области управления ИТ-услугами и аутсорсингом, включают IAOP (Международную ассоциацию профессионалов в области аутсорсинга, www.iaop.org). Эта организация разрабатывает такие своды знаний как «Outsourcing Professional Body of Knowledge (OPBOK)» — трехсотстраничное руководство по внедрению профессиональных стандартов аутсорсинга, содержащее подробную информацию о разработке, реализации и управлении аутсорсингом, а также многочисленные шаблоны для практического применения. Кроме того, существуют другие своды знаний и стандарты, такие как SIAM Foundation Body of Knowledge и стандарты серии ISO 37500, покрывающие основные этапы и процессы управления аутсорсингом.

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

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

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

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