А что если сделать оценку выполненных в проекте вех (milestone review) и на оставшуюся часть проекта распределить? Или ход проекта такого не предусматривает?

Конечно когда клюнуло, срочно все распределили, но это шло уже со скрипом - от вопроса «почему я» до долгого входа

Зато теперь у Вас есть опыт внедрения проектного управления в сложных условиях💪 Вот только (как некоторые задаются здесь вопросом) что с этим потом делать?🤭

Разумный взгляд, особенно в разрезе конкретной команды, согласны.

А вот представим реальный кейс: в компании вводится проектное управление. Такое, что есть даже методологи. Проектных групп несколько и они, разумеется, разные. И как поступать:

• Определять подход к УП для каждой отдельной группы, или
• "Спускать" единую методу для всех?

И снова зависит от групп, их зрелости и связанности между собой. Кому-то спустим, а кто-то сам придумает (и эту практику можно будет тоже транслировать на всех). Единый подход при разных направлениях деятельности, рынках и сегментах - злое зло.

Иван, спасибо за развернутый ответ и новый термин "злое зло"🤭 Будем использовать в подобных ситуациях!

Не всегда нужен прям документ. Может быть достаточно договоренностей и общих подходов.

договоренности должны на что то ссылаться. Иначе человеческая память и предвзятость имеет тенденцию их искажать со временем.

Все-таки очень рискованно на устные договорённости полагаться....А если проект долгий? Если сменятся, добавятся участники? Лучше потратить вначале немного времени , чем потом разбираться с разными образами и пониманием зон ответственности.

Конечно, хорошо когда решение/договоренность записаны, но обратная сторона такого подхода это когда то, что не записано не исполняется.

Поэтому они должны быть зафиксированы, конечно

Искоренение формализма - самое важное и сложное в командной работе.

а потом приходит новый человек и вынужден вникать по сакральным песням жрецов

Бытуют мнения, что так (никак) в итоге дешевле, чем выстраиваить по уму. Проект рано или поздно закончится, а новый начнется с чистого листа. Набрали людей и погнали. Сложно убедить руководителей с таким мнением в обратном. Да и нужно ли...? Их деньги, в конце концов, и они их считают ведь.

С точки зрения проекта, безусловно с формализмом надо бороться. При этом замечено, что формалисты дольше всех остаются в игре, у них "больше жизней/аптечек". Т.е. чтобы искоренять формализм нужно сделать работу безопасной, а с кого тогда спрашивать? Большому начальнику надо с кого-то спросить...

Если руководству достаточно формальных отмазок, то либо решаем вопрос с руководством, либо идем в другое место, где метрики не являются инструментом порки.

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

для это существует PMO, который владеет документацией по стандартным процессам вне зависимости от проекта. Конечно некая кастомизация будет всегда, но это не повод не иметь стандартов.

У нас был кейс в одной организации, где сотрудникам потребовалось 1.5(!) года, чтобы принять факт, что им нужно и проектное управление и стандартные процессы. До уровня проектного офиса не доросли, остановились на PMBOK + СМК.

Обязательно нужно. Устные договорённости к делу не пришьёшь: человек может уйти, может прийти новый, что-то пропустят, форс-мажор..Распределять ответственность в проектной группе - обязательно на «берегу», потом зафиксировать,а вот какой подход - это уже от зрелости команды зависит.

Т.е. полагатьс на зрелость сотрудников утопия❓🥲

Одно другому не противоречит. Матрица ролей она же не про то, как сделать сотрудников зрелыми и самостоятельными. Если даже самый зрелый сотрудник будет участвовать в нескольких проектах, где своя специфика и часть участников другая, то обязательно должно быть на что опереться, в голове не удержишь. Матрица тут как некий чек-лист что ли)))

Спасибо за уточнение. В такой ормулировке точно удержится.