Я новичок в управлении проектами, но я пытаюсь применить свои знания в одном направлении своей работы.
У меня есть результат, который можно удовлетворить двумя решениями: одним более желательным и одним менее эффективным. Однако выбор не в моей власти.
Я попрошу одобрения более желательного варианта, но если он будет отклонен, мне придется реализовать альтернативу. Как смоделировать это в WBS?
Мы используем PM-решение, разработанное местной компанией (PM3 от Result), которое выглядит как MS Project, но не совсем то же самое. Поэтому я ищу ответ, который не слишком зависит от программного обеспечения.
Спасибо за любую помощь!
В настоящее время у вас есть проблема X/Y, потому что ваши рабочие пакеты зависят от бизнес-стратегии, которая в настоящее время не определена . Это приводит к необходимости разрабатывать ответвления для «альтернативных путей» в вашем плане проекта. Если вы с самого начала правильно определите стратегическую бизнес-цель, вам не придется решать вопросы, связанные с ответвлениями в вашем программном обеспечении или в плане проекта.
Заставьте высшее руководство зарабатывать свою зарплату, приняв стратегическое решение о том, какие результаты они действительно хотят. Это значительно упростит ваше планирование, и это действительно «правильный» способ планирования любого проекта: в первую очередь спланировать правильный план.
Если вы проигнорируете этот мудрый совет, то у вас еще есть варианты. Вместо того, чтобы пытаться представить несколько планов, представляющих разные цепочки на критическом пути , вам следует реорганизовать свои пакеты WBS, чтобы у вас был единый график с настраиваемой областью действия.
Часть вашей проблемы заключается в том, что вы не участвуете в активном общении с бизнесом. Выбор между «лучшим» (как бы вы его ни определяли) решением и решением, создание которого занимает больше времени или которое будет стоить дороже, является стратегическим решением, которое принадлежит высшему руководству . Это не ваша работа и не ваша ответственность. Однако, если вы эффективно общаетесь и заказываете правильный проект, вам не придется тратить время на планирование функций или вех, которые могут быть совершенно неуместными после принятия бизнес-решения.
Итак, иди и сделай это первым. Объясните руководителям возможные варианты, в том числе возможные последствия для графика, бюджета, масштаба и качества, а затем позвольте им выбрать стратегию. Как только они это сделают, вы сможете составить правильный план проекта для удовлетворения потребностей бизнеса.
Независимо от того, следовали ли вы совету по общению с бизнесом, давайте посмотрим, что на самом деле представляет собой структура декомпозиции работ. Википедия определяет WBS следующим образом:
Структура декомпозиции работ (WBS) в управлении проектами и системной инженерии представляет собой декомпозицию проекта, ориентированную на результат, на более мелкие компоненты.
Ваша проблема на самом деле не в том, как создать WBS; ваша проблема заключается в том, как создать рабочие пакеты, соответствующие ключевым элементам критериев INVEST, чтобы высшее руководство могло выбирать, какие пакеты относятся к критическому пути.
Другими словами, если ваши рабочие пакеты хорошо декомпозированы и в значительной степени автономны (чтобы уменьшить зависимости между пакетами), то вы можете рассматривать включение или исключение конкретных пакетов как проблему области действия.
Хотя несколько планов проектов могут содержать полностью идемпотентные рабочие пакеты, если ваши рабочие пакеты достаточно малы, чтобы их можно было легко оценить и протестировать, и достаточно независимы, чтобы их можно было добавлять или удалять из области действия, не создавая огромного каскадного эффекта для зависимых пакетов, то даже не Agile-проект может выиграть от того, что область действия станет регулируемым ограничением .
Допустим, ваш проект носит кодовое название WonderWidget™. У вас есть несколько вариантов создания виджета:
Мы априори предполагаем, что один метод включает больше ручных операций и более высокие затраты на рабочую силу/материалы, в то время как другой метод имеет потенциальные проблемы с качеством. Какой из них «лучше» — это бизнес-решение, которое в значительной степени не имеет отношения к планированию проекта.
WonderWidget™, для сборки которого требуется 53 шестеренки, вероятно, имеет точно такие же рабочие пакеты на любом пути, за исключением этапов производства или покупки шестерен. Если для ручного изготовления каждой шестеренки требуется 47 ручных шагов, содержащихся в 12 тесно связанных рабочих пакетах, но только два рабочих пакета задействованы в заказе шестерен у вашего поставщика — что ж, это, безусловно, набор соображений по графику, бюджету или качество. Однако с точки зрения объединения проектных действий в цепочку эти два варианта по сути взаимозаменяемы, потому что то, как производятся винтики, может иметь очень мало общего с рабочими пакетами, связанными со сборкой виджетов.
Рабочие пакеты, основанные на INVEST, могут принести пользу даже самым сложным планам проектов. Требуется ли одна стратегия, чтобы вы увеличили штуковину, в то время как другая требует, чтобы вы уменьшили что-то? Отлично! Поменяйте местами пакеты или представьте оба варианта в виде выбора «или/или».
План проекта со скромным количеством ответвлений, необязательных пакетов/вех или точек принятия решений вполне разумен. Однако, если вы обнаружите, что ваш план становится достаточно сложным, чтобы выглядеть как тарелка спагетти, вам нужно остановиться и пересмотреть свои основные предположения о том, что проект должен принести.
В приведенном выше примере вопрос о том, передавать производство шестеренок на аутсорсинг или нет, вероятно, является разумным ответвлением плана проекта. Однако решение о том, создаете ли вы Widget of Awesomeness™ или Widget of Mediocrity™ , нужно определить в самом начале проекта, а не обнаруживать его как эмерджентный дизайн в какой-то неопределенный момент жизненного цикла проекта.
Независимо от того, является ли ваш процесс гибким или традиционным, вам нужно построить правильную вещь. Если у вас недостаточно информации о том, что является «правильным», вернитесь к бизнесу и спросите их .
Я не думаю, что это трудно решить. Как это написано, я предполагаю, что решение между альтернативой A или B принимается через некоторое время после начала проекта, поэтому необходимы две разные WBS. Просто создайте вторую структуру контрольной учетной записи. Например, WBS 1.0 содержит пакеты, которые являются общими, и я предполагаю, что они будут запущены до того, как будет принято решение. WBS 2.0 содержит альтернативу A. WBS 3.0 содержит альтернативу B. И 2.0, и 3.0 будут планироваться с соответствующими значениями в долларах, продолжительности и времени, оба будут базовыми, оба могут быть смоделированы с собственным критическим путем, т. е. показать два из них . В то время, когда решение принято, выполните изменение и уменьшите любую альтернативу, которая не была выбрана, и удалите ее из базовой линии.
Я не думаю, что это должно быть сложнее, чем это. Немного больше работы, поэтому убедитесь, что вам платят за это.