Как сделать проектный отдел

Обновлено: 05.07.2024

ПРОЕКТНЫЙ ОФИС / PROJECT OFFICE / ПРОЕКТНОЕ УПРАВЛЕНИЕ / PROJECT MANAGEMENT / СТРОИТЕЛЬНАЯ ОРГАНИЗАЦИЯ / CONSTRUCTION ORGANIZATION / ОРГАНИЗАЦИОННОЕ ПРОЕКТИРОВАНИЕ / ORGANIZATIONAL DESIGN / СОЦИОТЕХНИЧЕСКАЯ СИСТЕМА / SOCIAL AND TECHNICAL SYSTEM

Аннотация научной статьи по экономике и бизнесу, автор научной работы — Фадеев Александр Александрович

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

Похожие темы научных работ по экономике и бизнесу , автор научной работы — Фадеев Александр Александрович

Creating a Project Office of Construction Organization

Creating a project office in A construction organization is a kind of managerial revolution. At least, that is a transition to a new level of management. Why? This topic is covered in the article.

создание проектного офиса строительной организации

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

Ключевые слова: проектный офис, проектное управление, строительная организация, организационное проектирование, социотехническая система _

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

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

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

дел по Нижегородской

строит Не можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

Applicant, Nizhny Novgorod State University of Architecture and Civil Engineering, Member of the Main Department for Internal Affairs in the Nizhny Novgorod Region

Creating a Project Office of Construction Organization

Creating a project office in A construction organization is a kind of managerial revolution.At least, that is a transition to a new level of management. Why? This topic is covered in the article.

Keywords: project office, project management, construction organization, organizational design, social and technical system

Сегодня, 16 ноября, т.е. в день проектировщика, было бы уместнее всего поговорить именно о проектных организациях, инжиниринговом бизнесе или об инженерах-проектировщиках вообще. Проектировщики, часто вполне заслуженно, называются интеллектуальной элитой строительного комплекса, а потому, особо учить их чему-то труднее всего! Особенно если речь идет о вполне себе избитых темах, типа Проектного Управления, которые уже набили оскомину многим руководителям и собственником строительных компаний вообще и проектных организаций - в частности. Одна из таких банальных задач - как организовать эффективное проектное управление в проектных организациях?

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

Наиболее распространённой ошибкой проектных организаций является т.н. "линейное" проектное управление, когда и ГИПами (Главными Инженерами Проектов) и Начальниками проектных отделов руководит один производственный менеджер, чаще всего - Главный Инженер проектной организации. С одной стороны, под одним техническим менеджером замыкаются две противоборствующие задачи - лучшие и дорогие проектные решения (Центр финансовой ответственности по прибыли) с одной стороны, и выполнение проектных работ в срок с нужным качеством в нужном объёме (Центр финансовой ответственности по выручке). Объединение этих контр функций под единственным техническим руководителем (даже если у него есть много заместителей по проектам и направлениям проектирования) приводит к трагическому внутреннему когнитивному расстройству, что очень заметно у возрастных главных инженеров проектных институтов - они мастерски умеют говорить долго ни о чем! С другой стороны, генеральный директор остается заниматься вопросами общего управления с 20% персонала, т.к. основной производственный коллектив уже находится в подчинении главного инженера. У него тоже происходит управленческий перекос. В лучшем случае, генеральным директором может стать бывший главный инженер и тогда он никому не даст работать вообще. Говорить в такой ситуации о качественном проектном управлении нет смысла в принципе.

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

Есть и другая типичная ошибка. В качестве примера можно рассказать об одной проектной организации, которая решила внедрить у себя проектное управление и ничего лучше не придумала, как создать должность 1-го заместителя генерального директора по управлению проектами и подчинила ему специально созданный отдел - Проектный офис. В этот офис сразу набрали молодых менеджеров проектов с сертификатами и экономическими дипломами, которых назначили РП - Руководителями Проектов. Как эту новость встретили ГИПы? Кто-то думает, что они обиделись и взбунтовались? Нет, они с радостью решили передать свои организационно-управленческие задачи новым РП и занялись привычным им сведением проектных решений в ПСД. Еще они наивно полагали, что теперь все договорные и сдаточные моменты с Заказчиками будут решать эти самые РП. Радость их, как вы понимаете, была недолгой! Все Заказчики повыгоняли этих РП из своих кабинетов после первой же встречи и потребовали ГИПов для разъяснения тех или иных проектных решений. На этом внедрение проектного управления закончилось ничем. Очевидно, что такое внедрение проектного менеджмента тоже абсурдно!

Как же найти ту самую золотую середину и создать эффективную корпоративную систему управления проектами в проектно-инжиниринговом бизнесе?

22deb6b22d42b8d217eb36c33ba05755.JPG

Рис.1 Классическая сильная матричная структура для проектной организации.

Давайте попробуем начать поиск эффективного проектного управления с классификации и анализа самих проектов проектной организации. Очевидно, что ПРОЕКТОМ в проектной организации мы называем уникальный контракт с Заказчиком на производство проектно-сметной документации (ПСД) или проектной продукции в том или ином объеме. Уникальный результат такого контракта - это полученная маржинальная доходность, обеспечивающая интересы собственников и персонала по развитию бизнеса. Но такие проекты в компании не все, а только часть. С точки зрения типов проектов можно выделить (см. Рис.1):

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

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

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

4. Долгосрочные проекты. Это как раз модель проектного управления в проектных институтах, где проектируются крупные объекты и сооружения достаточно ответственные и требующие больших уникальных проектных команд на долгий срок. Здесь ГИП становится уже не просто одним из специалистов отдела реализации проектов, а начальником специального отдела, созданного под данный проект (на рисунке, ОСП - Отдел специального проекта). Более того, он сам вправе подбирать в свой отдел и специалистов по другим главам и разделам ПСД на постоянной основе (красные малые звездочки на рисунке), не обращая внимания на функциональные задачи аналогичных производственных отделов. Просто потому, что постоянное присутствие конкретного проектировщика в данной проектной команде важнее, чем функциональное подчинение. Именно так строились отношения во многих советских проектных институтах, которые по сути имели по 2-3, а то и 5 одинаковых по продукту отделов, но занимающихся разными проектами, а сам проектный отдел становился такой мини-семьёй. Для больших проектов такой подход приемлем, но для малых и средних - опасен и вреден в силу инертности и очевидных простоев специалистов.

41e5c0072d324e2211fd5cae32aaa1be.JPG

Рис.2 Специальные типы проектов в проектной организации.

Очевидно, что напрашивается простое резюме: прежде чем выстраивать проектное управление, проанализируйте свою рыночную нишу, свой отраслевой сегмент и типовые проекты в портфеле. После этого имеет смысл акцентироваться на ровне зрелости проектного управления и степени его матричности. Но не стоит забывать и о других возможных проектах в любой проектной организации, для которых представленные выше модели могут не подойти. В любом случае надо предполагать, что в проектной организации есть и "узкие" проекты, где назначение классического ГИПа - не совсем правильное решение. Давайте посмотрим на такие проекты (см. Рис.2):

1. Тендерные проекты на одну главу или раздел ПД. Такое бывает, когда Заказчику, например, требуется сделать только инженерные изыскания, хоть геологические, хоть геоклиматических или иные. В данном проекте прочие отделы не задействованы вообще или некоторые отдельные специалисты. Стоит ли на такой отдел выделять ГИПа, тем более, если это работа не в его квалификационном поле. Здесь, скорее всего, ГИПом надо назначать или самого начальника производственного отдела, или заместителя главного инженера по направлению (например, по изысканиям), или просто главного специалиста отдела, специализирующегося на таких задачах. Разумеется, для их работы следует прописать и соответствующие методологические особенности в Положении о проектном управлении в рамках СМК компании.

2. Краткосрочные проекты по главе ПСД. Один из распространенных типов проектов, когда на уже построенном объекте или сооружении надо что-то перепроектировать. Например, на ГЭС надо сделать реконструкцию ЗРУ, ОРУ или КРУЭ. Разумеется, такой проект не требует системного ГИПа, а скорее - классного специалиста ЭТО - электротехнического отдела. Разумеется, и небольшая работа для АО и ОСК. В такой ситуации удобнее просто назначать ГИПом того или иного специалиста-электрика отдела без перевода его в проектный блок и без изменения его статуса в трудовой книжке или в штатном расписании. Еще бы неплохо ему за это доплатить!

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

4. Долгосрочные исследовательские проекты. Наконец, вполне бывают, в т.ч. в нашей практике, долгосрочные исследовательские проекты, которые, по своей сути, не являются проектами по разработке ПСД, но являются проектами по разработке методик, рекомендаций, сбору данных, статистических наблюдений и мониторинга надежной эксплуатации зданий и сооружений. Здесь тоже вопрос ГИПа не стоит так, как при разработке ПСД, но поскольку проекты являются доходными, требуется специальный класс РП в составе управлений или как заместитель начальника соответствующего производственного отдела или даже - главного инженера. Очевидно, что назначить его как РП - это полдела, важнее создать устойчивую систему контроля реализации такого проекта в рамках нишевой специфики компании и превалирующей проектной структуры.

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


13 сентября 2019

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

Ильнар Фархутдинов

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

Что считается проектом

Выделим основные факторы, которые могут обосновать целесообразность обособленного контроля за группой задач, объединенных одной целью (см. рисунок 1).

ris1.jpg

Рисунок 1. Условия выделения группы задач в проект

Отдельного пояснения заслуживают два признака для выделения задач в проект:

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

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

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

Инструментарий управления проектами

Управление проектами – это деятельность, в ходе которой определяются и достигаются цели проекта, при этом соблюдается баланс между объемом работ, ресурсами, временем, качеством и рисками. Наиболее популярными подходами к управлению проектами являются:

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

Таблица 1. Общее сравнение наиболее популярных подходов проектного управления

Подход PMI PRINCE2 SDLC Agile Lean Six Sigma
Типы управляемых проектов Все, в основном крупные Все, в основном крупные Сложные IT-проекты В основном IT-проекты Повышение качества производства
Региональная популярность Северная Америка Европа, Азия Глобально, крупные компании Глобально, в основном стартапы Глобально, крупные компании
Ключевые преимущества Хорошо структурирован под реализацию больших проектов Хорошо структурирован под реализацию больших проектов Хорошо структурирован под реализацию больших проектов Идеально для небольших проектов или проектов с часто меняющимися условиями Идеально для проектов по повышению качества продукции
Ключевые недостатки Излишне затратен для небольших проектов или для проектов с повышенной степенью неопределенности Излишне затратен для небольших проектов или для проектов с повышенной степенью неопределенности Излишне затратен для небольших проектов или для проектов с повышенной степенью неопределенности Вероятны отклонения от ожиданий заказчика проекта Неприменим для всех видов проектов
Сертификация для исполнителей Требуется Требуется Не требуется Не требуется Требуется

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

  1. Использование инструментария проектного управления в операционных или несущественных для деятельности компании задачах. Например, один из проектов на крупной производственной компании предполагал создание уникального IT-продукта сотрудниками IT-департамента. Однако возможная выгода от реализации этого проекта измерялась крайне малыми суммами. В этой ситуации раскрутка маховика проектного управления обошлась компании значительно дороже, чем выгода от реализации проекта.
  2. Стремление к излишней гибкости (возможности внесения изменений в одобренный бенефициарами план) или, наоборот, отказ от изменений при очевидном наличии такой необходимости. Стремление упрощать процессы планирования и контроля и оперативно реагировать на возникающие обстоятельства могут привести к результату, отличному от ожиданий заказчика.

Основные этапы проекта

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

ris2.jpg

Можно выделить группы процессов, которые свойственны каждому проекту (см. рисунок 2).

Рисунок 2. Группы процессов проекта

Далее рассмотрим их подробнее.

Инициирование проекта

Инициирование проекта можно разделить на две части:

  1. Формирование устава проекта.
  2. Формирование команды проекта.

Устав проекта – это относительно небольшой по объему документ (6–7 слайдов максимум). Напомню, что мы говорим о внутренних проектах, где исполнитель и заказчик работают в одной компании. Устав проекта преследует следующие цели:

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

Устав проекта резюмируется в небольшую таблицу (см. таблицу 2).

Таблица 2. Резюме проекта.

Наименование проекта: Улучшение процесса обслуживания покупателей

Предпосылки:

Участники проекта:

  1. Спонсор проекта:
  2. Заказчик проекта:
  3. Куратор проекта:
  4. Руководитель проекта:
  5. Команда проекта:
  1. Обеспечить ответ на каждый запрос.
  2. Сократить средний срок решения запроса покупателя на 60%.
  3. Сократить количество повторных обращений на 80%

Критерии оценки:

  1. Среднее время реагирования на запрос покупателя.
  2. Количество повторных запросов.
  3. Результаты ежегодного опроса покупателей

Периметр проекта: подразделение Южного-Федерального округа

Документация проекта будет рассмотрена не позднее20 декабря 2019 г.

Проектная команда будет утверждена в предложенном составе

Ключевые вехи:

Утверждение проекта – январь 2020 г.

Анализ и протоколирование источников – февраль 2020 г.

Утверждение рекомендаций – апрель 2020 г.

Внедрение рекомендаций – май 2020 г.

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

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

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

Этап должен ответить на следующие вопросы:

  1. Что планируется сделать?
  2. Как планируется сделать?
  3. Какие события являются критериями завершения проекта?

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

ris3.jpg

Рисунок 3. Структура плана проекта

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

Два других раздела итогового плана, о которых стоит упомянуть отдельно – это финансовая модель и план мероприятий. Приведем несколько основных тезисов, обязательных при формировании этих разделов.

  1. Финансовый план и план мероприятий должны быть синхронизированы.
  2. Финансовый план должен рассчитывать объем необходимых инвестиций и бюджеты проекта. Бюджеты могут быть разбиты по времени и подразделениям, но в сумме они должны быть сопоставимы с объемом запрошенных инвестиций.
  3. Финансовый план должен учитывать именно те ресурсы, которые будут предоставлены для его реализации. Из этого тезиса, например, возникает необходимость разделения учета расходов на персонал на операционную деятельность и непосредственно на реализацию проекта.
  4. Оба плана должны допускать возможность внесения изменений в рамках утвержденных процессов.
  5. Финансовый план и бюджет проекта должны быть синхронизированы с текущей учетной политикой компании. Неэффективно планировать расходы и доходы без возможности последующего сбора соответствующих фактических значений.

Планирование проекта – это сложный и порой дорогостоящий процесс. Самое важное на этом этапе понять два ключевых момента:

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

Исполнение проекта

Из всего, что важно для успешного исполнения задач проекта, можно подчеркнуть следующее:

  1. Необходимо защищать периметр проекта. Желание расширить его границы возникает практически всегда. И здесь важно донести до заказчика и спонсора необходимость внесения соответствующих изменений в утвержденные планы или о воздержании от внесения таковых.
  2. Основная роль руководителя проекта – это коммуникации. Важно ограничивать свое желание уйти в исполнение, разработку продукта, проектирование и т.п. Коммуникации на предприятии могут стать настоящим кошмаром проектного управления, если им не уделять большую часть своего внимания.
  3. Согласованные в проектной документации ресурсы должны быть реально предоставлены.
  4. Мотивация персонала для проектных и операционных задач должна быть разной. Проектные задачи – это всегда умение работать с неопределенностью. Здесь важно избегать формальных решений, и отдельная мотивация является одним из наиболее эффективных инструментов. Она может быть выражена в виде премий, доли в проекте и в виде любых других поощрений.

Мониторинг и контроль проекта

Этап контроля реализуется параллельно с этапом исполнения. Эффективным инструментом контроля станут различные процедуры контроля для разных ступеней иерархии проектов (см. рисунок 4). Функции контроля за портфолио может исполнять совет участников или акционеров общества. При этом отдельные проекты и программы проектов можно контролировать на уровне совета директоров или проектного офиса. Важно обеспечить контролирующий орган полномочиями и инструментами мониторинга и контроля за ходом реализации проекта, программы и портфолио.

ris4.jpg

Рисунок 4. Иерархия проектов

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

Закрытие проекта

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

ris5.jpg

Рисунок 5. Варианты закрытия проекта

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

Заключение

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

Безусловным минусом внедрения проектного менеджмента в компании являются дополнительные расходы и бюрократизация процессов. В малых масштабах оно не окупается.


За последнее время пришло столько с писем с запросом “расскажите о проектном офисе”, что пришлось потратить выходной и все-таки написать статью про проектный офис.

На истину в последней инстанции не претендую, мой опыт – только практический. Я второй год руковожу проектным офисом, который отвечает за реализацию проектов, участвовала в его внедрении “с нуля”. С остальными видами знакома в теории и по рассказам друзей, которые также руководят проектными офисами в других компаниях и решают задачи, отличные от моих. Поехали!

Что такое проектный офис

Для понимания того, что же такое проектный офис, надо начать с определений, как бы скучно это не было. Все определения по памяти, поэтому если что – сильно не бейте и поправьте в комментариях.

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

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

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

А что же такое проектный офис и как он соотносится с понятиями выше?

Цели проектного офиса, или зачем вообще нужен проектный офис

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

Виды проектных офисов

PMBoK предлагает следующие виды проектных офисов:

  • Поддерживающий проектный офис (Supportive PMO) – предоставляет методологию, шаблоны, ведет базу извлеченных уроков, поддерживает КСУП (корпоративную систему управления проектами), если она есть. Ход проектов не контролирует, максимум – собирает статистику по их ходу и по применению тех самых методик и шаблонов, и жалуется куда надо. Прямо на проекты не влияет и потому, в большинстве случаев, бессмысленнен и никем не уважаем. Обратная ситуация возможна только при очень сильной поддержке топ-менеджмента, но ни в одной компании в бытностью свою в консалтинге я успешного поддерживающего проектного офиса не видела.
  • Контролирующий проектный офис (Controlling PMO) – выступает не только в качестве методолога, но и в качестве центра экспертизы и контроля: участвует в принятии решений о продолжении проекта, учит РМов, помогает в каких-то сложных ситуациях, обеспечивает соответствие принятым проектным практикам и больно бьет за их несоблюдение, иногда – даже обеспечивает интегрированное планирование работ и ресурсное управление. Вот это уже более живой вариант, его все в меру боятся и уважают.
  • Управляющий проектный офис (Directive PMO) – непосредственно управляет проектами: распределяет РМов и другие ресурсы, определяет приоритеты, несет ответственность за ход и результаты проектов, отчитывается перед менеджментом. Иногда даже отвечает за соответствие проектов и стратегии организации (Strategic PMO), хотя это на самом деле уже про управление портфелем проектов (в английском языке есть термин Project Portfolio Management Office, PPMO). Я как раз таким руковожу.

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

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

Функции проектного офиса

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

Например, функции проектного офиса могут включать:

  1. Управление ресурсами и их распределение;
  2. Управление зависимостями между различными проектами, программами и портфелями;
  3. Обучение и аттестация РМов и других участников проектов практикам проектного управления;
  4. Внедрение, адаптация и администрирование информационной системы для управления проектами, обучение пользователей;
  5. Контроль за правильностью применения принятой проектной методологии;
  6. Консолидация информации о текущих проектах для топ-менеджмента;
  7. Экспертная поддержка РМов;
  8. Приоритезация проектов;
  9. Участие в управляющих комитетах или комитетах по управлению изменениями;
  10. Ведение базы извлеченных уроках, помощь в управлении рисками, т.е. управление знаниями организации в области проектного управления;
  11. Разработка шаблонов проектной документации;
  12. Аудит идущих проектов;
  13. Развитие методологии, изучение новых и лучших практик;
  14. И т.д.

Проектный офис и Портфель проектов – в чем отличие

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

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

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

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

Проектный офис и КСУП – в чем отличие

КСУП – это методология проектной работы на уровне всей компании. Именно в рамках КСУП определяется, как именно мы решаем, что это – портфель проектов, что этот проект нам действительно нужен, и что проектный офис у нас будет поддерживающего типа. В рамках внедрения КСУП, как правило, происходит организация проектного офиса (если его не было ранее) и внедрение информационной системы управления проектами. Т.е. проектный офис – это часть КСУП, но никак не сама КСУП и вполне может существовать без нее. Более того, даже КСУП технически вполне может существовать без проектного офиса. Т.е. также как в случае с портфелем проектов – эти понятия очень близки и идут рука об руку, но уж никак не тождественны.

Внедрение проектного офиса

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

Кстати, как минимум для старта необходимы следующие вещи:

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

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

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

Выводы

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

Опытные руководители проектных офисов, добавите что-нибудь?

Читайте также: