КОГДА нужны руководители проектов
Наконец-то добрался до основной темы. Итак, когда же на самом деле нужны руководители проектов?
Я, честно говоря, сильно удивлен, что мои читатели не стали сильно отстаивать необходимость такой специальности как руководитель проекта. Более того, в историческом очерке я даже описал когда они появились и для чего были нужны. Что же, повторюсь.
Руководители проектов, как лидеры матричной структуры, появились во времена Второй Мировой в составе диверсионных подразделений, когда для определенной задачи объединялись разноподчиненные функционально бойцы.
Итак, основные предпосылки появления РП: неповторяемость задачи, разрозненность ресурсов, конечность процесса. Если не присутствуют все три фактора одновременно - руководитель проекта не нужен. Точнее, он никакой не руководитель проекта. Он выполняет функции секретарши, перекладчика бумажек, информационной системы и триггера рисков. Это функция той самой материализованной лени собственника.
А когда же действительно появляется необходимость в РП?
Во-первых, сам проект внедрения процессов, отработки функционала сотрудников, первоначальной обкатки последовательностей работы, требует высококлассного руководителя. В большинстве случаев, РП может быть подменен собственником, но это полноценный РП. Но только в процессе становления. Как только процессы отлажены - власть должна целиком переходить к функциональному руководителю.
Во-вторых, транснациональные проекты, например, по постройке завода, требуют РП. Но РП требуется со стороны заказчика, чтобы синхронизировать работу субподрядчиков, управлять бюджетом, графиком. Проект постройки завода для заказчика единичен, основной бизнес не в строительстве заводов, а в результатах их деятельности. Как только завод сдан, РП больше не требуется.
Здесь есть еще одна ловушка - именно на таких крупных проектах назначать РП любят исполнители. Хотя это их основная работа, для них это должен быть не проект, а процесс. И опять РП превращается в непонятно кого, кто вынужден биться внутри своей же компании за ресурсы этой же компании, добиваться от внутренних исполнителей соблюдения бюджетов. Короче, модерировать внутренний бардак. Короче говоря, опять материализованная лень собственника.
И в-третьих, РП может появиться в проектных организациях, ассортимент товаров и услуг которой настолько велик, что любое решение, собранное из этих товаров и услуг не может быть стандартным. В этом случае, по-моему, у компании серьезные проблемы, но существование РП в данном случае обоснованно.
Все. В остальных случаях руководитель проекта - это громкое название "единой точки ввода-вывода информации". Очень любят назначать руководителей проектов в разработке софта. Не смотря на то, что все современные методологии разработки даже не предполагают такой роли. Разработка - это стандартный процесс для разработчиков. Нет уникальности - цепочка процессов всегда одинакова для любого разрабатываемого софта. Нет разрозненности ресурсов - в большинстве случаев есть выделенная группа, которая работает исключительно над текущим проектом. Есть только конечность процесса. Один фактор из трех. Не густо.
И последний мой любимый пример - системная интеграция. Вот где, казалось бы, засилие руководителей проектов. И разрозненность ресурсов на лицо - все специалисты по разным отделам. И конечность процесса - есть четко (или не очень) составленное ТЗ, вроде как есть неповторимость задачи - каждому клиенту нужно что-то свое. Но вот в последнем и кроется ловушка, на которую попадаются все системные интеграторы. Неповторимость задачи весьма условна. Вполне возможно формализовать отдельные процессы внутри функциональных подразделений и свести энтропию проекта к минимуму. Такому минимуму, что РП становится не нужен. Но удобнее с РП. Потому что всегда есть крайний. Наверно, это очень удобно.
Я, честно говоря, сильно удивлен, что мои читатели не стали сильно отстаивать необходимость такой специальности как руководитель проекта. Более того, в историческом очерке я даже описал когда они появились и для чего были нужны. Что же, повторюсь.
Руководители проектов, как лидеры матричной структуры, появились во времена Второй Мировой в составе диверсионных подразделений, когда для определенной задачи объединялись разноподчиненные функционально бойцы.
Итак, основные предпосылки появления РП: неповторяемость задачи, разрозненность ресурсов, конечность процесса. Если не присутствуют все три фактора одновременно - руководитель проекта не нужен. Точнее, он никакой не руководитель проекта. Он выполняет функции секретарши, перекладчика бумажек, информационной системы и триггера рисков. Это функция той самой материализованной лени собственника.
А когда же действительно появляется необходимость в РП?
Во-первых, сам проект внедрения процессов, отработки функционала сотрудников, первоначальной обкатки последовательностей работы, требует высококлассного руководителя. В большинстве случаев, РП может быть подменен собственником, но это полноценный РП. Но только в процессе становления. Как только процессы отлажены - власть должна целиком переходить к функциональному руководителю.
Во-вторых, транснациональные проекты, например, по постройке завода, требуют РП. Но РП требуется со стороны заказчика, чтобы синхронизировать работу субподрядчиков, управлять бюджетом, графиком. Проект постройки завода для заказчика единичен, основной бизнес не в строительстве заводов, а в результатах их деятельности. Как только завод сдан, РП больше не требуется.
Здесь есть еще одна ловушка - именно на таких крупных проектах назначать РП любят исполнители. Хотя это их основная работа, для них это должен быть не проект, а процесс. И опять РП превращается в непонятно кого, кто вынужден биться внутри своей же компании за ресурсы этой же компании, добиваться от внутренних исполнителей соблюдения бюджетов. Короче, модерировать внутренний бардак. Короче говоря, опять материализованная лень собственника.
И в-третьих, РП может появиться в проектных организациях, ассортимент товаров и услуг которой настолько велик, что любое решение, собранное из этих товаров и услуг не может быть стандартным. В этом случае, по-моему, у компании серьезные проблемы, но существование РП в данном случае обоснованно.
Все. В остальных случаях руководитель проекта - это громкое название "единой точки ввода-вывода информации". Очень любят назначать руководителей проектов в разработке софта. Не смотря на то, что все современные методологии разработки даже не предполагают такой роли. Разработка - это стандартный процесс для разработчиков. Нет уникальности - цепочка процессов всегда одинакова для любого разрабатываемого софта. Нет разрозненности ресурсов - в большинстве случаев есть выделенная группа, которая работает исключительно над текущим проектом. Есть только конечность процесса. Один фактор из трех. Не густо.
И последний мой любимый пример - системная интеграция. Вот где, казалось бы, засилие руководителей проектов. И разрозненность ресурсов на лицо - все специалисты по разным отделам. И конечность процесса - есть четко (или не очень) составленное ТЗ, вроде как есть неповторимость задачи - каждому клиенту нужно что-то свое. Но вот в последнем и кроется ловушка, на которую попадаются все системные интеграторы. Неповторимость задачи весьма условна. Вполне возможно формализовать отдельные процессы внутри функциональных подразделений и свести энтропию проекта к минимуму. Такому минимуму, что РП становится не нужен. Но удобнее с РП. Потому что всегда есть крайний. Наверно, это очень удобно.