Нет. Реализация "в лоб" закрытия gap приведет к значительному увеличению операционных издержек различных подразделений, что позволяет формально блокировать внедрение результатов проекта, если каким-то образом не будет повышено капасити этих подразделений (а оно не будет повышено, ибо макроцель организации как раз наоборот сокращение ФОТ). Понимая эти ограничения команда проекта была сложена с участием представителей таких подразделений, дабы выработать наименее болезненное решение. И тут начинаются проблемы, так как времени на детальную проработку требований не дали, а большинство разногласий касаются не технических вопросов, а процессных (которые впрочем тоже аффектят технику).
Понятно что в любой момент можно списать все на провал проекта, уволить ПМ, вызвать на ковер его руководителя и ещё кого угодно. Но Заказчику от этого не легче, ибо деньги потрачены и нужен результат - раз, во-вторых, последствий неисполнения мер никто не отменял

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

Я так понимаю она больше для операционной деятельности. Для проекта этот подход тоже применим?

Как инструмент разбора какой-то проблемы или риска - вполне

Да. В общем любой более менее рабочий способ декомпозиции подойдёт, но этот способ лучший

Спасибо, коллеги

PS Это правда не тот случай, когда "друг просит узнать" 😁

+1
Но не обязательно только или именно Исикава.

Есть другие способы декомпозиции - шаги процесса или часть-целое или причина-следствие или общий признак.

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

Если есть ограничения только на то, как исправить ситуацию через команду, а не стейкхолдеров учить жизни, то можно попробовать шаги такие: 1) внутри команды собрать ваш текущий скоуп, который известен на данный момент, положить его на таймлайн, учитывая людей, разные зависимости и что у вас там есть, будет понимание, где вы находитесь , возможно будет видно, чтотвам делать с этим скоупом дальше, резать, выяснять какие куски 2) внутри команды договорится по скоуп менеджмент процессу, ваше предложение по выделению областей и ключевого стейкхолдера и ответ из команды может сработать, вы по сути ввделяете продакт оунера и бизнес аналитиков, которые будут менеджить входящий поток требований. Хорошо бы начать или продолжить документировать требовпния хоть в стори и аксертанс критерии, минимально, и просите вашу команду писать follow ups  просто с ключевыми решениями, и где-то это трекать , чтобы не потерялось 3) пересмотрите комуникацию на проекте, вам точно не нужен поток требовпний на разных звонках и встречах,

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

Спасибо всем за ответы

Ребята неплохую базу знаний сделали. Вроде стало проще разбираться тем кто впервые сталкивается с гос-ПМ.

https://pm.center/bazaznaniy/

Hello

Возник вопрос о том, насколько люди используют в работе функционал аутлука в части задач.

Я вообще его не испольхую

В дополнение к сегодняшнему триумфу SpaceX

как выглядит аджайл в космической отрасли https://youtu.be/bvim4rsNHkQ

Вы используете Outlook в своей проектной деятельности?
anonymous poll

Да – 54
👍👍👍👍👍👍👍 71%

Нет – 22
👍👍👍 29%

👥 76 people voted so far.