Особенности управления проектами в функциональной оргструктуре

Особенности управления проектами в функциональной оргструктуре

М. Якубович

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

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

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

Рисунок 1 – Особенности функциональных структур

Реализация проектов в таких структурах затруднена.

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

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

Что происходит в таких проектах?

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

Очень сложно соблюсти плановые сроки в проекте, где Заказчик «втихую» пытается расширить содержание проекта. Например, в проекте по описанию бизнес-процессов Заказчик к середине проекта заявляет, что он ожидает помимо диаграмм процессов, получить процедуры и должностные инструкции. Или в проекте по внедрению корпоративной системы управления проектами (КСУП) Заказчик заявляет о необходимости разработать или модернизировать модели описания бизнес-процессов, хотя в Уставе проекта (документ, с момента подписания которого начинается проект. Подробнее читайте в статье Управление проектами – инструмент развития компании, журнал Организационное консультирование, N9-10, 2007 год) ничего про них не упоминалось. Но по мере развития проекта Заказчик решает, что неплохо было бы «причесать» модели процессов, а там, где их не было, стоит их разработать. Содержание проекта в обоих случаях увеличивается, объем работ растет, а сроки проекта при этом не меняются. Классический пример попытки выйти за рамки тройного проектного ограничения. Суть тройного ограничения заключается в том, что руководитель проекта не может по просьбе Заказчика проекта , к примеру, сократить бюджет проекта, не увеличив при этом сроки проекта или не пожертвовав частью продуктов проекта (нужно отказаться от некоторых целей проекта или его продуктов). Или другая ситуация: Заказчик проекта хочет сократить сроки, но у руководителя проекта есть всего несколько вариантов: увеличить бюджет (за счет привлечения дополнительных ресурсов сделать проект быстрее), сократить объем работ (отказаться от части целей) или снизить качество продуктов проекта (часть требований не будут удовлетворены).

Рисунок 2 – Проектный треугольник (тройное ограничение)

Как решать проблему нечетких требований?

На мой взгляд, эту проблему не надо решать на старте проекта, все что надо сделать – это обозначить ее вероятное возникновение в будущем (по сути – это риск проекта) и заложить резерв времени на уточнение требований по мере развития проекта.

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

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

Результатом рассмотрения запроса на изменение содержания должен стать анализ последствий изменения на сроки, стоимость и качество проекта. В примере с добавлением моделей процессов в содержание проекта по разработке ССП можно предположить, что сроки проекта увеличатся в полтора-два раза и Заказчик вынужден будет расставить приоритеты: содержание проекта или сроки. Если приоритетнее сроки, то от моделей процессов придется отказаться. Задача руководителя проекта в этом случае – во время отследить попытки «раздуть содержание» и написать запрос на изменение.

Руководители проекта, работающие в организации с функциональной структурой, находятся в очень сложном положении, потому что чем ниже их уровень в иерархии, тем меньше у них статус и меньше полномочий. Персонал в такой организационной структуре ориентирован на единоначалие и соблюдение принципа субординции. И если руководитель проекта находится на одном уровне иерархии с сотрудниками проекта, то ставить им задачи, а тем более осуществлять контроль выполнения этих задач, в рамках проекта, крайне сложно. С чем столкнется руководитель проекта, так это с постоянными возражениями типа: «у меня есть более приоритетные задачи», «я сегодня занят» и т.д. Решить проблему можно двумя способами: организовать постановку задач через функционального руководителя исполнителя, либо выделить на старте проекта минимальный уровень доступности исполнителя для работ в проекте. К примеру, в специальном документе - Лист согласования ресурсов - указывается, что Петров имеет доступность не менее 40%. Это означает, что ежедневно Петров может быть задействован проектным менеджером на работах проекта 3, 2 ч при 8-часовом рабочем дне.

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

Поэтому «первооткрывателям» проектного менеджмента в таких компаниях будет сложнее своих последователей – им нужно «прорубить окно». И здесь придется гораздо сложнее, чем в проектно-ориентированных компаниях: нужно уметь «вовлечь людей», иногда самому показать, как нужно делать, иногда выслушивать незаслуженные упреки Заказчика в недостаточном упорстве и т.д.

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

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

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