Приветы. Подскажите, пожалуйста, есть ли где-то готовые гайдлайны по управлению коммуникациями и управлению требованиями в agile? Ситуация патовая - ПМО поддерживает только водопад, но есть проект с неопределенным скоупом (brd от спонсора только грубыми мазками), но определенным сроком вчера. Пользователей результата несколько бизнес-подразделений, ресурсы интегратора ограничены.

Все слегка бесконтрольно и невпопад, хочется помочь коллегам

PMO - срочно на тренинг на перепрошивку mindset. Если не идут сами - через бизнесов.

Но обычно чтобы понять что нужно меняться - нужен более или менее крупный fail.

Приходите кому интересно. Чатик подзатих в последнее время, можно раскачать.

Хотя, поверьте мне, gosagile медленно но верно пускает корни в ряде мест. ))

Не очень понял кейс. Что за продукт? PMO на чьей стороне буянит - внутри заказчика? Какая модель сорсинга - за что отвечает заказчик, за что интегратор? Модель генподряда? Субчики есть?
Что будет если проект не будет сделан. Какие потери или кто и от кого именно получит люлей?
И собственно коллеги, которым надо помогать они на чьей стороне?

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

Ага, а ещё есть [технический] заказчик из градостроительного кодекса, который не совсем "заказчик"

Это не только в гос компаниях встречается. Была pm-ом на проекте, где в параллели оптимизации процессов показывали как можно работать по скраму.
Эти формулировки «принять к сведению», «рассмотреть к внедрению», «рекомендуем к согласованию» в протоколах портили мне всю малину. 😂😂😂
В результате я сама меняла формулировки, а отношение людей к задачам поменялось только месяцев через 5.
Мое мнение - такие фразы полностью снимают ответственность, и после встречи несогласные выходят с осознанием - так ничего ж не решили, значит делать не будем 🤦🏻‍♀️

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

Что значит "поддерживает только водопад"? Ну нарежте им водопад итерациями по 2 недели и идите по этапам аджайлом )

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

Потому как одна из частых причин провалов: «мы не в том домене!». То есть инструменты и подходы заведомо плохо работающие в запутанном домене тянут туда из структурированных доменов.


Ещё 10 лет назад можно было не сильно заморачиваться. Но потом все почувствовали VUCA-мир.

значит что формально к началу реализации все требования собраны и согласованы

Ещё раз: «они не в том домене» ))

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

Попробуйте применить к ним (этому PMO) метод «5 почему». Последовательно задайте им вопросы типа «почему к началу реализации все требования должны быть собраны и зафиксированы». И так далее, вглубь. Обычно очень занимательно проходят раскопки смысла.

Да не бывает же такого. Такое бывает только с внешними контрактами, когда в самом договоре жестко прописан Scope и этапы.
А так-то у любого водопадного ПМО принят Stage-Gate подход. Вот им и надо тогда нарезать Stage-Gate по 2 недели - если не побьют ))

Есть многое на свете, друг Горацио, что и не снилось нашим мудрецам

Ээээ....
Так это не работает. Не верите мне - почитайте нобелевского лауреата Канемана.
Не бывает правильных решений, если не покопаться в проблеме и не понять ее причины.

Бывают быстрые, всем понятные, иногда даже недорогие но НЕ ПРАВИЛЬНЫЕ решения. В смысле как раз не решающие проблему и делающие в конечном итоге только хуже.

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

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