Управление проектами обеспечено мощной теоретической основой. Написаны международные стандарты, в России утвержден свой ГОСТ, специалисты проходят сертификацию. А вот на практике не все так радужно. Кто-то внедряет проектное управление и программное обеспечение для него только для соблюдения формальностей, а кто-то по-настоящему, но из-за нехватки знаний теряет деньги и время. Но стоит признать, что, несмотря на все неудачи, есть успешные кейсы внедрения управления проектами. Своим опытом управления проектами в области строительства, наиболее частыми проблемами и подходами к их решению с читателями «ЭЖ» делится Элла Тетерина, независимый эксперт по управлению проектами.
Проектное управление сейчас «в моде»: на уровне государства, глав регионов создаются проектные офисы, назначаются руководители проектов, кураторы, разработан и утвержден ГОСТ, написано множество книг и рекомендаций по управлению проектами (признанные мировыми сообществами), существуют специальные сертификации и многое другое. И если с теорией все хорошо, то с практикой дела не очень.
С проектом всегда связаны следующие ключевые вопросы:
-
во сколько обойдется его реализация;
-
сколько времени уйдет на реализацию;
-
что определит успешность проекта, какие характеристики эффективности (например, проект «Вавилонская башня» — можно ли считать успешным проектом?);
-
роль результатов проекта в операционном и стратегическом процветании компании.
Комплексный подход в управлении проектами — редкость
Менеджеры некоторых российских компаний считают, что их проекты будут более успешными, если приобрести и установить тот или иной программный продукт. Но информационная система управления проектами (ИСУП) — это всего лишь инструмент, которым нужно уметь пользоваться, чтобы он помогал в управлении, а не был лишней нагрузкой для линейных работников и руководства.
В большинстве случаев от приобретения специализированного программного обеспечения (ПО) ожидают: увеличения объема заказов, получения в сжатые сроки реальной комплексной аналитической отчетности о происходящих изменениях и этапах работ в определенный момент времени в удобной для руководителя форме, как за предыдущие периоды (в статике), так и в динамике по всем интересующим показателям.
Если задать вопрос спикерам на конференциях по управлению проектами: используется ли в их компаниях проектный подход, — то ответ всегда будет положительным. Однако если заглянуть вглубь, то окажется, что многие из них просто купили ПО, обучили сотрудников работе с ним, разработали собственными силами или с привлечением консультантов методологию (различные инструкции, положения, приказы, формы отчетности и т.д.), утвердили их и положили на полку. А в данный момент в системе работают несколько человек или ею вообще никто не пользуется, а все отчеты, как и прежде, делаются отдельно каждым подразделением, например в Excel. Проще говоря, ни о каком комплексном подходе речи вообще нет. Деньги и время потрачены впустую, а у работников и руководителей начинается отторжение от всего, что связано с этим подходом.
Одна из главных причин, по моему мнению, того, почему не приживается этот подход, — использование методологии, не подходящей компании.
Например, компания прибегает к услугам консультантов, они разрабатывают документы на свое усмотрение (чаще всего это просто стандартный набор документов, иногда даже не адаптированный под компанию). Если в компании есть сильный специалист по управлению проектами, знающий процессы компании, то работа с консультантами будет продуктивной. Если такого специалиста нет, то можно получить гору макулатуры, а с уходом консультантов весь процесс встанет и все вернется на круги своя. В подобной ситуации мало кто признается, но ее я видела неоднократно.
Еще одна причина — отсутствие заинтересованности руководства компании.
Например, когда руководитель не использует систему для получения информации. Более того, есть руководители, которые до сих пор рассматривают календарно-сетевые графики в распечатанном виде. То же относится к отчетности, которая делается вручную каждым подразделением. Прозрачная отчетность в таком случае становиться мифом. Не раз была свидетелем такой ситуации: руководитель видел сформированную реальную отчетность из системы с неудовлетворительными фактическими показателями. А когда руководитель проекта или другое ответственное лицо приносили отчет, сделанный вручную без динамических показателей, и настаивали на том, что данные в систему внесли некорректно, то руководитель очень часто верил именно этим табличкам. Психология: хочется верить, что все лучше, чем есть на самом деле.
Есть случаи и обратного эффекта, когда руководителя проекта наказывали за обман. Очень важно: человек, отвечающий за подразделение (проектный офис или аналогичное подразделение), в котором формируется вся отчетность, разрабатывается методология и происходит верификация данных, должен быть подчинен первым лицам компании, то есть он не должен зависеть ни от одного заинтересованного в проекте подразделения. А руководитель компании должен быть готов к переменам, к тому, что придется менять подходы и методы управления, иначе зачем тогда все это затевать?!
Другая причина, с которой тоже приходилось сталкиваться при поиске ответа на вопрос: почему компании начинают «внедрять проектный подход» и покупают дорогое специализированное ПО, — это когда обязательным условием договора и/или одним из критериев выбора на этапе конкурсных процедур со стороны инвестора/заказчика является использование проектного подхода и наличие специального ПО для управления проектами (касается проектных институтов, компаний генподрядчика и субподрядчика). В таком случае компании покупают ПО, берут в штат сертифицированного (-ых) сотрудника (-ов) только для того, чтобы соответствовать критериям и условиям контракта. С точки зрения управления ничего не меняется: в систему вносятся показатели, требуемые заказчиком, а внутри компания продолжает работать по-старому.
Ситуацию с использованием проектного подхода можно сравнить с использованием электронного документооборота: многие говорят, что ушли от бумаги, когда львиная доля ИТ-бюджета уходит именно на расходные материалы.
Итог: наличие специализированного ПО управления проектами должно быть лишь частью корпоративной системы управления проектами. И это не зависит от сферы деятельности и того, является ли компания заказчиком, генподрядчиком, субподрядчиком, генпроектировщиком или проектировщиком. Такой вывод основан на опыте работы в каждой из таких компаний, начиная от проектного института и заканчивая работой в компании — заказчике крупных инфраструктурных проектов г. Москвы.
Проект в строительной компании: как уменьшить проблемы
Давайте рассмотрим, как же исправить ситуацию на примере одной строительной компании, в которой автору довелось работать в Дирекции по управлению проектами. Компания (на тот момент у нее было около 42 объектов) имела территориально распределенные проекты. В начале работы прозвучало: в компании используется проектный подход и имеется специализированное ПО, сотрудники обучены, но почему-то не достигается желаемый результат. Приобретение конкретного специализированного программного продукта и его использование как раз было одним из пунктов договора с заказчиком по некоторым строительным проектам.
После проведения аудита все стало на свои места. Не вдаваясь в подробности, отмечу еще раз: при внедрении любой системы со стороны заказчика должен быть человек/руководитель проекта по внедрению, знающий, что нужно компании, понимающий ее бизнес-процессы и нацеленный на положительный результат.
Оставим за рамками статьи этапы создания проектного офиса и корпоративной методологии, предшествующие выбору, внедрению и работе в ИСУП.
В нашей ситуации есть ИСУП и основной задачей было внедрение полноценной корпоративной системы управления проектами (КСУП).
Были поставлены следующие цели:
-
оптимизация и автоматизация внутрикорпоративных бизнес-процессов;
-
формирование единого источника информации по всем проектам;
-
создание единого архива;
-
предоставление оперативной отчетности;
-
формализация требований к планированию, контролю и учету объемов работ;
-
эффективное распределение и управление ресурсами;
-
формирование базы знаний.
Для достижения целей были разработаны сценарии действий, с их выгодами и недостатками, сроками, стоимостью и т.д., в которые входили такие показатели, как: оценка компетенции сотрудников и их дальнейшего обучения управлению проектами и навыкам работы в ИСУП, вовлеченность в процесс, затраты, оценка результатов работ.
Обучение персонала — в фокусе внимания для успешного управления проектами
Совместно с руководством компании были выбраны оптимальный сценарий развития и пилотный проект по строительству. Проект выбирался тщательно, прорабатывался, выстраивались все процессы совместно с курирующими сотрудниками заказчика, то есть совместно разрабатывались документы, необходимые для взаимообмена, показатели отчетности, вносились данные в единую ИСУП, чтобы автоматизировать процесс обмена данными и минимизировать количество бумажных отчетов (касательно процесса строительства данного объекта). Организационная структура на тот момент была классической, вертикальной. Скажу сразу, мы не разрабатывали множество новых документов, а для развития существующей ИСУП до КСУП были задействованы:
-
ранний поиск сторонников (друзей) с «мест», вовлечение их в проект;
-
внутренний PR: встречи, презентации, информационные сообщения;
-
внутреннее обучение;
-
создание типового учебного курса;
-
обеспечение инструментами для «обратной связи»;
-
упрощенный план работ по использованию ИСУП и его применение на пилотном проекте;
-
постепенное закручивание гаек (уже живем по новым правилам, но ошибки пока прощаются).
Первый пункт из данного списка особенно важен, так как работники независимо от их влияния на проект должны понимать, какие плюсы они для себя могут извлечь от использования данного подхода и ИСУП в частности. Сотрудники в пилотный проект вовлекались постепенно, а основной движущей силой стала Дирекция по управлению проектами.
Для определения недостающих знаний и навыков работы в информационной среде было сделано следующее.
Сотрудники были разделены на несколько групп. Для тех сотрудников, кто ранее прошел обучение, была создана тестовая среда в ИСУП, выделено определенное время и дано задание создать в системе проект по ремонту квартиры с установленными сроками, ограничениями, бюджетом, ресурсами и т.д. Сначала это задание всем показалось легким, но уже в самом начале процесса выполнения появилось множество вопросов, как его делать. Результаты выполнения задания выявили «белые пятна» в знаниях и навыках сотрудников, и было проведено внутреннее обучение с использованием вышеупомянутого примера. Большинство сотрудников проявили большой интерес, так как каждый из нас в жизни делал ремонт, но далеко не все выполнили его с запланированными уровнем качества, сроками и бюджетом.
Сотрудники, которые не проходили обучение и не знали о своих предполагаемых ролях в проекте, были направлены на курсы или обучение, которые проводились собственными силами с заранее разработанными методическими материалами. Так, сотрудников, которые находились непосредственно на строительных площадках могли направить в центральный офис (если площадки расположены в г. Москве). А сотрудники дирекции по управлению проектами выезжали на объекты и проводили обучение непосредственно на строительной площадке. Кроме того, при обучении сотрудников использовались современные средства связи.
Каждый вариант просчитывался заранее с учетом предстоящей роли сотрудника в проекте и финансовых затрат. Также были подготовлены пошаговые инструкции по работе в ИСУП.
Регулярно проводился обмен опытом между работниками, задействованными в проекте. Например, сотрудник строительного отдела рассказывал про технологию строительства, сотрудник отдела закупок — про процесс закупочных процедур, сотрудник отдела календарно-сетевого планирования — про методы планирования и т.д. Через какое-то время даже у бухгалтеров появлялся интерес, и они готовы были поделиться своими знаниями. Данный подход хорош тем, что когда учишь других и рассказываешь про свою работу, то учишься сам плюс развиваешь свои навыки (soft skills), такие как подготовка презентации, умение публично выступать, грамотная речь и многие другие. Самый главный плюс, который осознали сотрудники компании: нет бесполезных отделов, у каждого своя роль и задачи, взаимосвязанные между собой, и сроки отставания по одному направлению могут критически сказаться на выполнении проекта в целом.
Структура команды проекта, единая терминология, планирование
Параллельно прорабатывались варианты формирования структур команды проекта. Для этого были проанализированы все должностные инструкции сотрудников и положения о структурных подразделениях. На выбор структуры команды проекта влияли такие факторы, как:
-
сложность проекта;
-
удаленность объекта;
-
объем работ;
-
определение проектных ролей: цель, показатели достижения цели, результаты, обязанности, полномочия и ответственность;
-
определение компетенции участников;
-
анализ текущей загрузки потенциальных участников.
После выбора структуры проекта следовал приказ о создании команды проекта (шаблоны приказов были также разработаны и утверждены руководством компании) и устанавливались сроки разработки необходимых документов. В первом приказе, в частности, назначался руководитель проекта (РП), который был уполномочен сформировать команду проекта, а также устанавливались сроки для РП по разработке карточки, устава и плана по проекту. В другом приказе устанавливались должностные лица по подразделениям, которые входили в состав команды проекта.
В компании осталась классическая организационная структура, но были дополнительно разработаны матрицы вовлеченности и загрузки сотрудников, регламенты взаимодействия, определена «важность проекта», система мотивации.
Прежде чем приступить к совместной работе, необходимо сразу же определиться с терминами и понятиями, что бы все сотрудники говорили на одном языке, так как один и тот же термин каждый может понимать по-своему.
Далее были приняты принципы календарно-сетевого планирования, отраженные в методике, разработаны и утверждены различные регламенты, сформированы в ИСУП шаблоны календарно-сетевых графиков в зависимости от типа строительного объекта. В графике учитывались как проектно-изыскательские работы, разработка и согласование рабочей документации, так и сроки изготовления материалов и их поставка на строительную площадку (среднее количество работ в шаблоне было порядка 1500). Также были сформированы пакеты работ, шаблоны шагов, базы ресурсов и материалов с расценками, кодировка глобальная и проектная, настроены отчетные формы и т.д.
Итоги реализации проекта
Планирование шло сверху вниз, начиная от инвестора, а вот отчетность, наоборот, формировалась снизу вверх. До того как каждый из этих регламентов был утвержден и принят к работе всеми ключевыми участниками, была проделана колоссальная работа, разработано несколько итераций каждого документа, проведены бесчисленные согласования, отработка регламентов на пилотном проекте, совместные совещания с командами проектов, обсуждения и отработка взаимодействия с сотрудниками заказчика и инвестора и многое другое. Отмечу, что вся эта работа шла параллельно, не в ущерб самому процессу строительства и выполнения обязательств по договорам.
Мы стремились к идеалу и к нему в итоге пришли через определенный промежуток времени: фактические данные стали попадать в систему непосредственно со строительной площадки (для этого потребовались как организационные меры, так и дополнительные финансовые затраты). В то же самое время работа сотрудников непосредственно на площадке имела ряд положительных моментов: вовлеченность их в проект (они работают в одной команде), всем виден результат, влияние отставаний на срок окончания проекта, сокращение срока передачи информации от одного сотрудника к другому, самостоятельная работа в одном информационном пространстве.
Сначала процесс сбора фактов и исполнения проекта был следующий.
Ввод фактической информации (использовались преднастроенные формы Excel):
-
физические объемы, трудозатраты — ответственное лицо с площадки;
-
работы, связанные с разработкой и выдачей на строительную площадку рабочей документации — инженер производственно-технического отдела;
-
информация о сроках изготовления и поставки материалов на объект — сотрудник отдела закупок, позднее данная информация загружалась из 1С;
-
стоимость вносилась вручную из смет, далее была сделана интеграция систем.
Контроль и анализ данных:
-
подгрузка в систему (для каждой закрытой работы) подтверждающих документов;
-
сравнительный анализ фактического выполнения на соответствие с утвержденным базовым планом;
-
анализ работ критического пути;
-
выявление причины отклонений, анализ влияния отклонений на дату окончания проекта и формирование мероприятий по их устранению;
-
управление изменениями.
Формирование еженедельной отчетности как по каждому проекту, так и по всему портфелю в целом (процесс формирования отчетности был автоматизирован).
Формирование ежемесячной отчетности.
Перепланирование в рамках отчетного периода.
Руководитель компании смотрел отчетность непосредственно в самой системе. Для этого ему были настроены формы отчетности, но он также мог самостоятельно погрузиться в любой проект (что он периодически и делал). На основании полученной информации руководитель уже принимал то или иное решение.
На что обратить внимание при разработке комплексной системы управления проектами
Обобщим ошибки и сложности при внедрении КСУП и работе в ИСУП:
1. Неточная и некорректная постановка задач, двойственность понятий в техническом задании на внедрение.
2. До формирования команды проекта внедрения необходимо оценить уровень компетенций в области управления проектами и навыков работы в приобретаемом программном продукте участвующих во внедрении работников.
Команды внедрения могут быть сформированы по разным критериям (совместная работа сотрудников заказчика и подрядчика по внедрению, привлечение только подрядной организации или временное «использование» сотрудников специализированной организации). Желательно, чтобы в компании-заказчике по внедрению был специалист с опытом внедрения систем и навыками работы в информационной среде.
3. Выбор программного продукта (их множество, и каждый выбирает под свои нужды, цели и задачи). Конечно, между ними существуют различия, начиная от функционала и заканчивая стоимостью, но важно именно то, чтобы вы могли его использовать именно как инструмент, помогающий компании/команде проекта анализировать, принимать решения, оценивать фактическую ситуацию в любой момент времени и привести свои проекты к успеху.
4. Адаптация действующих рекомендаций и существующих методологий непосредственно под вашу компанию.
5. Необходимость обучения сотрудников в области управления проектами.
6. Сопротивление руководителей среднего звена и линейных работников.
7. Сроки (все и сразу).
Главная рекомендация при внедрении: необходимость четкого понимания соответствия уровня зрелости компании поставленным целям и задачам в рамках управления проектами.
1 Об этом рассказывалось также на конференции по управлению проектами, см. http://www.pmsoft.pro/conf2014/conference/.