Допустим, вы строите что-то для Олимпийских игр. У проекта очень строгий дедлайн, что делает управление сроками очень важным. Так ли это?

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

Вы слышали о знаменитом случае, когда президент Кеннеди встретил уборщика в NASA и спросил его, что он делает? Уборщик ответил: «Я помогаю посадить человека на Луну». Разве такие люди в проекте не помогают выполнить его в срок?

Продолжая, вы замечаете, что каждый отдельный домен в проекте способствует управлению сроками, и вы не можете уложиться в срок с приемлемым уровнем вероятности, если не уделяете внимание всем доменам.

Когда вы думаете о доменах, будьте осторожны, чтобы не пропустить ни один из них. Кстати, что это за домены? Если вы проверите основополагающие ресурсы, вы получите разные ответы; и все же, ни один из них не является полной правдой.

Темы PRINCE2^® — это домены, но это только те домены, которые играют ключевую роль в методологии. Другие домены только подразумеваются. Руководство PMBOK^® не является методологией и может сформулировать ответ гораздо лучше с помощью десяти областей знаний. Однако это интерпретации всех доменов, основанные на точке зрения руководства PMBOK^® на проект, а не на нейтральной (нейтральная точка зрения существует не всегда). Например, человеческие аспекты не получают большого внимания в Руководстве PMBOK^®.

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

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

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

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

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