Как процесс управления проектами может повлиять на процесс управления продуктом?

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

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

Первым рычагом, который следует использовать, является управление рисками. Задокументируйте это:

• Проект X отстает на три месяца, потому что менеджер по продукту покинул компанию. Персонал проекта отвлекается на работу над проектами, в которых задействован и активен менеджер по продукту, и я их не виню. Это с вероятностью 90% задержит производство как минимум на шесть месяцев (три месяца на найма нового менеджера по продукту и три месяца на его ввод в курс дела). Мы не можем уменьшить этот риск на нашем уровне, и со временем он будет только ухудшаться.

• Проект Y отстает на две недели и продолжает отставать. Мы не можем начать проектирование, пока у нас не будет набора проверяемых и выполнимых требований. Менеджер по продукту YPM не смог их предоставить — у него высокие цели, но мы не смогли привязать его к тестируемым результатам. Если мы будем действовать без требований, проект потерпит неудачу, если мы не получим божественного вмешательства; мои сотрудники хороши, но они не умеют читать мысли. Я прошу у вас разрешения на реструктуризацию проекта, включив в него пользователей X, Y и Z, а также заинтересованных лиц, которым будут принадлежать требования. Мои сотрудники сядут с ними и разработают набор требований, которые мы отправим менеджеру по продукту YPM. Я бы также порекомендовал нам пересмотреть график поставки прототипа — это стандартный способ снизить риск нечетких требований. Что вы думаете?"

PMI говорит, что у вас есть право закрыть проект в одностороннем порядке; это не так в реальном мире, но это все еще рычаг, который вы можете использовать.

• «Босс, проект X потерпит неудачу через шесть-девять месяцев. Владелец продукта покинул компанию, и компания не назначила замену или даже эффективного действующего менеджера по продукту. Этот проект не имеет поддержки заинтересованных сторон, необходимой для успеха. Если вы не сможете убедить совет директоров назначить менеджера по продукту, я бы рекомендовал закрыть проект и перенаправить персонал на другие проекты».
• «Босс, проект Y потерпит неудачу через шесть-девять месяцев. План проекта определяет «требования» как следующий критический результат. У меня было три отдельных встречи с менеджером по продукту, и он не смог предоставить ни одного требования. Он имеет некоторые цели и видение проекта высокого уровня, но не предъявляет требования к тестируемым и достижимым результатам. Я встретился с ним и сказал, что планирую поговорить с вами и рекомендовать отмену, если мы не сможем преодолеть разрыв между целями и требованиями. Он не желает сдвинуться с места. Если этот проект важен для компании, я думаю, мне нужна поддержка, чтобы организовать саммит, на котором я смогу запереть своих сотрудников и его сотрудников в комнате, пока они не смогут построить мост между целями и требованиями».

Ключевым моментом является то, что во всех этих случаях (1) вы демонстрируете, что сделали все возможное, (2) вы просите конкретной поддержки и (3) ваши рекомендации относятся к нижней части компании. линия / наилучшие интересы. Но вы действительно проделали домашнюю работу и должны наладить отношения с начальником/заинтересованным лицом/кто угодно, что вызовет доверие, в котором вы нуждаетесь.

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

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

Если есть крайний срок, напомните всем, что проект не может начаться, пока требования (объем) не будут известны и доведены до команды. Часы не начнут тикать, пока это не произойдет.

Поговорка «Мусор на входе, мусор на выходе» применима как к вечеру, так и ко всему остальному. Если команде не предоставлено то, что ей нужно, нельзя ожидать, что она произведет желаемое.

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

Это не то, чего легко достичь. ИМХО, это сильно зависит от зрелости процессов на месте, а также от отдельных лиц.

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

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

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

Мое личное мнение — держать управление проектами и продуктом как можно дальше друг от друга:

• Управление проектами : делайте все вовремя и в рамках бюджета.
• Управление продуктом : делайте все правильно в течение следующих 10 лет.

Лучше использовать разных PM, разных разработчиков и желательно даже разные отделы.