Про связь работы менеджера проекта и системного инженера

В РМВОК (в PRINCE2 тоже, Р2М не читал еще) крайне замылен вопрос о том, что делает РП. Все эти знания нужны для принятия трех типов решений:
1) Добавить ресурсы (какие, сколько, когда, по какой цене, откуда взять, вопрос вторичный)
2) Как распределить работу между ресурсами
3) Определить, какие требования надо снять с проекта (обеспечивающей системы, не целевой). Они же ограничения.

Беда в том, что РМВОК прямо говорит, что команда проекта, выполняющая практики управления проектом, полностью отвечает за его успех. При этом стандарт чуть менее, чем полностью практики системной инженерии и архитектуры предприятия игнорирует. Если держать в голове, что РМВОК лишь часть ОРМ (не оперативно-розыскные мероприятия, а organizational project management), то ситуация улучшается ровно в области альф "стейкхолдеры" и "возможности", плюс альфа "технологии", за счет того, что в PgM St. есть фаза Infrastructure set-up. Целевая система при этом описывается только процессами/практиками "Управление требованиями" и "Управление изменениями". "Управление содержанием" и "Управление качеством" - это какой-то микс из целевой системы, обеспечивающей да еще и с прихватом операционного окружения.

Другими словами, увеличилась связность модулей PMBOK и SEBOK, и если раньше логика PMBOK была очень простой и понятной - определи объем работ, который должен протечь, посчитай, какие ресурсы нужны, для того, чтобы поток работ протек к определенному сроку и в пределах бюджета, и отслеживай, насколько реальность соответствует построенной модели, то сейчас во время чтения все больше приходится прыгать мыслью между двумя подходами, несоответствий между подходами вылезает все больше. И это еще один аргумент в пользу PRINCE2.

Anatoly Levenchuk Главная альфа проектного управления -- "Работы". А само оно -- это "Технологии". Дальше можно обсуждать различие as is (с шовинизмом) и to be (именно операционный менеджмент) проектного управления.