Одним из потенциально спорных моментов, упомянутых мною в предыдущей статье, был тезис о том, что название методологии управления проектами не очень важно, оно скорее выступает в роли единого терминологического пространства для всех участников.
Сейчас в меня полетят гнилые помидоры от руководителей проектов, но я продолжу стоять на своем. 🙂
Условно все проекты можно разделить на 3 большие группы:
⁃ мы знаем, что мы хотим получить в конце проекта, и понимаем, что для этого надо сделать и сколько времени это займет. Пример: открытие склада, посадка нового клиента и подобные вещи, происходящие в реальном мире;
⁃ мы знаем, что хотим получить, но не понимаем, что нужно для этого сделать, либо не представляем объем работ/ресурсов, необходимых для достижения цели. Пример - почти все проекты по разработке ПО;
⁃ мы не знаем чего мы хотим добиться, но очень хотим (или должны) что-то сделать. Пример - почти все проекты по устранению проблем в операциях и проекты непрерывного улучшения.

Вот в зависимости от задачи и следует выбирать методологию управления проектами, а не из личных предпочтений РП.
У вас проект первого типа? Вы знаете, что именно вы хотите получить в итоге, и ваши задачи как РП:
1. убедиться, что в проекте учтены все требования всех заинтересованных сторон (исполнителя, клиента, ваши, подрядчиков, регуляторов);
2. составить четкий план исполнения, который будет учитывать все необходимые этапы и зависимости (как пример: не начинать работы по установке стеллажей, если не готов пол и крыша, или не арендовать строительную технику, пока нет разрешения на строительство и на объекте не появились строители и т.д.);
3. спланировать расходы так, чтобы не переплатить за срочность и не задержать следующие этапы из-за несвоевременных оплат;
В данном случае у вас четкий каскадный проект.
Для каскадных проектов у меня есть хорошее определение того, что должен делать РП - у вас есть дорога, вы должны ее разметить, расставить светофоры и дальше следить, чтобы никто не ехал на красный свет и не нарушал разметку.

У вас проект второго типа? Вы разрабатываете софт, но на первом этапе не понимаете, какие именно инструменты вам понадобятся и сколько времени займет разработка? Режем весь проект на минимально обоснованные итерации и в конце каждой сверяемся, что у нас получается. Это нужно для того, чтобы не просрать зря время и ресурсы. Всегда лучше понять, что что-то идет не так через 3 дня, а не через месяц разработки. Ну и программеров нужно в тонусе держать, а то ишшь, сидят там по кофейням в наушниках…
Микроменеджмент как он есть, ставим небольшую задачу, через 3-5-10 дней или сколько вы там решили спринт делать, и в зависимости от полученных результатов или пинков раздаете, или методы меняете, или говорите какие все зайки.
Итерационные методологии - ваше все, Аджайл/Скрам и вся когорта подобных.

Третий тип самый интересный. На сцену гордо выходит 6Sigma, великая и ужасная. У вас линия генерит слишком высокий % брака? Клиент хочет увеличить производительность? Вы чуете подвох, но не знаете в чем? Садимся на берегу и созерцаем. Потом рисуем. Потом считаем. Потом проверяем расчеты. Потом опять созерцаем с учетом посчитанного. Потом решаем, что собственно делать. Считаем что получится, если мы это сделаем. Перепроверяем расчеты. Созерцаем с учетов выбранного решения. Делаем. Созерцаем. Считаем. Проверяем. Если все сошлось - проект окончен. Если нет - созерцаем. Потом считаем. Потом ищем ошибку. Потом перепроверяем. Потом ищем оправдания, почему не нашли ошибку раньше. Отмазались - проект окончен. Нет - готовимся к казни.

Естественно, в реальной жизни это все перепутано и сплетено. В каскадных проектах на определенных задачах используется Аджайл, некоторые итерации требуют каскадных подходов. Внутри каскадных моделей одни проекты требуют 5 этапов, а другие - 3. У кого-то спринт 2 недели, у кого-то 2 часа. Кто-то казнит за 2 часа простоя и перерасход в 100 долларов, кто-то прощает 2 миллиона спущенных в ненужный металлолом денег.

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

Второе большое следствие из вышенаписанного:
Всегда помните, что волк, серый волк, Canis lupus, собака серая, волчара позорный - это одно и тоже животное.

Если вам пытаются впарить что-то, называя это инновационной, отечественной методологией за много денег, то посмотрите не прячется ли там обычный каскад, в котором вместо 5 этапов сделали 3. Или 12. Или назвали спринт циклом, неважно.
Если у кого-то стоячие уши, серая шерсть, много острых зубов, длинная морда, оно жрет мясо, опасается людей, оставляет ровную дорожку следов и не умеет лазать по деревьям, то скорее всего это волк обыкновенный, как ты его не назови.

P.S. Вы спросите, почему я всегда называю 6Sigma великой и ужасной? Это детская травма. Это была первая методология, которой я начал учиться. И когда речь зашла о математическом аппарате анализа, количестве этапов разных расчетов и проверок и все это на 300+ англоязычных слайдов, необходимых для сертификации, то если описать степень моего удивления словом «охуел» - значит очень сильно ее преуменьшить.