Проектное управление

Чем руководит РП

Прежде всего мы ассоциируем РП с необходимостью руководить проектами, но само понятие «проект» довольно часто используем неправомерно. Конечно, общие признаки проекта можно найти практически в любой деятельности, но то, что проект ограничен во времени и должен давать уникальный результат, никак не является достаточными условиями для него, а только необходимыми^[1].

Каковы же достаточные условия для того, чтобы какую-либо деятельность считать проектом в полноценном смысле слова? Тайны тут никакой нет, достаточное условие — это правильная его организация и выделение необходимых полномочий РП, что на практике выполняется крайне редко.

Отсюда можно сделать вывод, что чаще всего мы (РП) играем роль не руководителя проекта, а администратора, роль статиста, но при этом наши KPI часто зависят от результатов этой так называемой «проектной деятельности». Да и сам проект назвать проектом с методологической точки зрения нельзя. Скорее всего это некоторые разрозненные куски операционной деятельности.

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

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

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

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

Администратор проекта: по указаниям и распоряжениям РП выполняет техническую работу, связанную с управлением проектом. Является основной точкой коммуникаций в проекте. Отвечает за коммуникации и документирование проекта.

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

Должен ли РП знать предметную область

Мне не раз приходилось слышать о том, что РП должен хорошо знать предметную область проекта, в котором участвует. То есть опыт в строительстве требуется в строительных организациях, а опыт работы в ритейле — для ведения ИТ-проектов в торговых компаниях. Чаще всего с этим сталкиваешься при приеме на работу. Многие компании ищут РП, которые работают или работали в какой-то конкретной области бизнеса, и это является основным условием принятия сотрудника в штат.

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

Начнем с того, что управление проектом — это самостоятельная область знаний, которая требует отличной подготовки, практики и сдачи весьма нетривиальных экзаменов международного уровня. Много ли у нас в организациях ролей / должностей, требующих подтверждения компетенций на уровне международного сертификата? Более того, не каждый ИТ-директор имеет за плечами такое образование, хотя я считаю, что у CIO оно должно быть в обязательном порядке.

В настоящий момент существует далеко не одна методика проектного управления. К самым популярным я отношу PMBoK (Project Management Body of Knowledge, США), AFW (AFW Wirtschaftsakademie Bad Harzburg GmbH, Германия) и PRINCE2 (Projects in Controlled Environments, Великобритания). Уверен, что читатели знают как минимум одну из них, а многие даже имеют сертификаты разных методологий. К слову сказать, ни в одной из них нет указания на предметную область, в которой данная методология работает лучше или применяется чаще. Проектная технология не завязана на предметные области, т. е. может быть применена для любых областей знаний — и для строительных, и для ИТ-проектов, и для проектов в производстве.

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

Фактически мы противоречим сами себе: с одной стороны мы хотим иметь РП, который будет делать проекты в истинном, широком значении этого слова, с другой — говорим, что он должен знать предметную область и как следствие ограничен рамками своих знаний. Думаю, не лишним будет напомнить, что при реинжиниринге бизнес-процессов в команде проекта обязательно должны быть специалисты, не представляющие детальную ситуацию. Делается это для того, чтобы иметь возможность отойти от сложившихся стереотипов и шаблонных решений. Фактически от РП мы хотим того же — выполнить проект вне зависимости от внешних и внутренних условий в установленные сроки и как минимум в рамках имеющегося бюджета. Отраслевой же опыт, если таковой имеется, сознает это его обладатель или нет, ограничивает профессиональное мышление и, таким образом, не позволяет использовать всю широту возможных решений. Вот тут-то и появляется вопрос — у вас проект или что-то другое? Вам нужен РП или администратор?

И еще один момент. Анализируя проекты, можно сделать следующее наблюдение: чем меньше проект, тем сильнее потребность того, чтобы РП знал предметную область. Связано это, на мой взгляд, только с экономической эффективностью и целесообразностью. В небольших проектах скудные бюджеты и скоротечность работ не позволяют развернуть полноценный проект, сформировать полноценную команду и вести необходимое документирование. На всем этом принято экономить. Для контраста давайте посмотрим на проект «Сочи­2014». Это без сомнения проект, и у него был руководитель, — как вы думаете, в какой предметной области он должен был быть специалистом?

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

Из всего сказанного можно сделать следующий вывод: если у вас действительно проект, если в нём работает грамотный РП (который имел опыт по соответствующему направлению), чьих полномочий достаточно для корректного ведения проекта, то знание предметной области не является обязательным условием его хорошей работы. Если перефразировать старую театральную фразу: «Сначала умный король окружает себя умной свитой, а потом свита делает короля», — то получится вполне приемлемое правило: вначале РП подбирает компетентную команду (и это в его прямых обязанностях), а затем команда делает «проект».

Влияет ли проект на организацию?

Еще один миф, даже не миф, а просто заблуждение связано с восприятием проектной деятельности руководителями высшего звена. В этой среде принято считать, что проекты — это нечто оторванное от операционной деятельности организации. Соответственно они не влияют ни на саму организацию, ни на общие результаты ее деятельности, а влияют только на результат конкретного сегмента активности, к которому имеет непосредственное отношение реализуемый проект. Именно этим объясняется тот факт, что проекты зачастую организуются в областях, либо малопонятных руководителям, либо проблемных. Например, если в компании падает прибыль, то внедряется ERP, чтобы увидеть, кто сколько тратит… Давайте посмотрим, насколько это может быть справедливо.

Говоря о проектах, мы косвенно говорим об изменениях внутри организации. Если мы говорим про ИТ-проекты, то говорим о том, как изменится организация с внедрением новой технологии. Изменение — это переход от одной ситуации к другой, перемена. А значит, проект — это всегда изменения. Попробую обосновать это на примере ИТ-проекта по внедрению ERP-системы, хотя сейчас трудно предположить, что у кого-то ее еще нет (я имею в виду средние и крупные предприятия).

Первоначально мы осознаем проблему как таковую. Сегодня мы понимаем, что коль скоро у нас нет ERP-системы, мы не можем оценить затраты по подразделениям и как следствие — посчитать себестоимость продукции или работ.

Затем мы осознаем проблему как разрыв. В текущий момент у нас нет такой возможности, но в будущем, после внедрения ERP-системы, эта возможность появится и мы сможем все посчитать. Надо сделать проект, устраняющий разрыв, т. е. внедрить ERP-систему.

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

Изменение (переход) будет включать в себя:

• изменение процессов работы сотрудников;
• изменение ИТ-инфраструктуры, ИТ-ландшафта и проч.

Для того чтобы произвести эти изменения, будет организован проект внедрения ERP системы, цель которого — расчет себестоимости.

Если проект сложен, то его, возможно, придется разделить на несколько подпроектов, например:

• подготовка ИТ-инфраструктуры;
• перепроектирование процессов;
• изменение организационной структуры;
• внедрение ERP-системы;
• ипрочие подпроекты.

Чтобы провести свой проектный корабль через все мели и выполнить поставленные цели, РП должен обладать огромным разносторонним опытом и знать большое количество различных инструментов, а не только основной свод правил.

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

Нам не нужен свой РП?

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

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

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

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

Обратите внимание, что во всех методиках проектного управления существует только одна роль руководителя проекта и одна рабочая группа проекта. В нашей действительности мы часто сталкиваемся с тем, что у нас в проектах есть РП от заказчика и РП от исполнителя, а что еще хуже — это две разные команды: команда исполнителя и команда заказчика. К чему приводит такое положение дел, все мы хорошо знаем, и описывать эту проблематику нет смысла.

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

На первый взгляд кажется, что этот вариант намного лучше и интереснее, чем другие, но это не всегда так. Давайте посмотрим, в чем заключаются основные функции офиса управления проектами:

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

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

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

Что же касается подчиненности ОУП, то она может быть разной в зависимости от основных задач, решаемых данным подразделением. Например, если это только создание единой методологии, то скорее всего подчинение должно быть в рамках директора по развитию. Если это контрольные функции конкретного направления, например ИТ, то ОУП подчиняется соответствующему курирующему заместителю (в случае ИТ это может быть заместитель по экономике и финансам). Ну а если задачами ОУП являются вопросы портфельного управления или контроля всех проектов организации, тогда он подчиняется, как правило, первому лицу, т. е. генеральному директору. Для правильного построения организационной структуры и подчинения ОУП нужно четко представлять два основных момента:

• основные функции подразделения;
• основные потребители информации.

Давайте подытожим

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

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

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

Что лучше, ОУП или РП в каждом подразделении? Наверное, в этом как раз и состоит та уникальность, которая присуща проектной деятельности. Решить, какова организация должна быть в будущем, обосновать, спланировать и выполнить намеченное — это и есть ваш проект, проект изменений.

Примечания