Руководство проектом со стороны заказчика

Содержание:

1.       Работа руководителя проекта от заказчика. Кто он вообще такой (образование, характер, компетенции)

2.       Компетенция руководителя проектов со стороны Заказчика и что нужно подтянуть

3.       Зачем для управления проектами руководитель со стороны Заказчика, и что, если его нет?

1.      Работа руководителя проекта от заказчика. Кто он вообще такой (образование, характер, компетенции)

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

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

2.      Компетенция руководителя проектов со стороны Заказчика и что нужно подтянуть

a)      Коммуникатор между командой проекта и пользователями системы.

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

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

b)      Контролер сроков по проектным задачам.

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

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

c)      Приёмщик результатов проектных задач.

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

Все результаты по проекту так или иначе проходят утверждение у РП со стороны Заказчика. В функции руководителя проектов входит решение конфликтов при приемке результатов проектных задач пользователями системы.   

3.      Зачем для управления проектами руководитель со стороны Заказчика, и что, если его нет?

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

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

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

Для продуктивной деятельности руководитель проекта со стороны Заказчика должен обязательно иметь административный ресурс в рамках проектных задач.

Не стоит экономить на повышении компетенций руководителя проектов. По окончании проекта такой сотрудник станет основным носителем знаний по внедрённой системе и её популяризатором.

Специалист компании «Кодерлайн»

Евгений Еленко

  • Главная
  •  > 
  • Продукты и услуги
  •  > 
  • Комплексное внедрение системы
  •  > 
  • Методика внедрения

Методика внедрения

Для успешного достижения целей проекта по внедрению ERP-системы действия всех его участников регламентируются согласованной Методикой внедрения.

Организационные принципы управления Проектом

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

Высшим органом управления Проекта является Координационный Совет Проекта, в состав которого входят:

  • назначенные представители руководства как со стороны Заказчика, так и Исполнителя;

  • Руководитель Проекта (РП) со стороны Заказчика;

  • Руководитель Проекта (РП) со стороны Исполнителя.

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

    Функции Заказчика и зона его ответственности

    Заказчик и лично Руководитель Проекта со стороны Заказчика принимает на себя функции и ответственность в следующем:

    • Четкое определение Целей Проекта и их однозначное формулирование в Плане Проекта;

    • Определение ролевого и персонального состава сотрудников со стороны Заказчика, включаемых в Рабочую группу Проекта;

    • Следование всех участников Проекта со стороны Заказчика настоящей методике управления Проектом;

    • Выделение Рабочей группой необходимых ресурсов и управление выделенными ресурсами для решения задач в соответствии с Планом Проекта;

    • Выполнение решений, принимаемых на совещаниях Рабочей группы и Координационного совета, и отнесенных к компетенции Заказчика;

    • Своевременное вынесение на Координационный совет проблем, угрожающих выполнению задач Проекта;

    • Координацию рабочей группы со специалистами технической службы для обеспечения принятых в компании стандартов и правил и администрирования;

    • Обеспечение конфиденциальности проектной информации.

    Функции Исполнителя и зона его ответственности

    Исполнитель и лично Руководитель Проекта со стороны Исполнителя принимает на себя функции и ответственность в следующем:

    • Определение ролевого и персонального состава сотрудников со стороны Исполнителя, включаемых в проектную группу;

    • Следование всех участников Проекта со стороны Исполнителя настоящей методике управления Проектом;

    • Разработку концепции реализации Проекта, обеспечивающей достижение поставленных задач;

    • Определение состава используемых средств и гранул ERP-Системы, концептуальных и технических средств ее интеграции с внешними приложениями и базами данных;

    • Выполнение настройки и необходимых доработок ERP-Системы в ходе ее внедрения;

    • Проведение необходимого обучения пользователей;

    • Выделение необходимых ресурсов и управление выделенными ресурсами для решения задач в соответствии с Планом Проекта;

    • Определение потребности в ресурсах Заказчика для решения задач интеграции с внешними приложениями и базами данных и согласование их использования с Заказчиком;

    • Выполнение решений, принимаемых на совещаниях Рабочей группы и Координационного совета, и отнесенных к компетенции Исполнителя;

    • Своевременное вынесение на Координационный совет проблем, угрожающих выполнению задач Проекта.

    Принципы работы участников Проекта

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

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

    • Решения Руководителя Проекта со стороны Заказчика являются обязательными для исполнения членами Рабочей группы со стороны Заказчика.

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

    • При невозможности выполнения поставленных задач или соблюдения сроков их выполнения любым участником Рабочей группы Проекта, информация об этом обязана быть доведена до сведения Руководителя Проекта.
    • Документы, согласованные сторонами Заказчика и Исполнителя, подлежат хранению в электронном виде. Любые изменения, вносимые в такие документы должны проходить установленную процедуру внесения изменений, с формированием новых версий документов.

    Порядок разрешения рабочих споров в ходе Проекта

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

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

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

    Хочу сказать про такую важную позицию в любом проекте, как руководитель проекта (PM — по ненашенски project manager) со стороны заказчика. По  опыту (не скажу что он очень обширен, но кое-что бывало в моей профессиональной жизни), бывают такие вот проблемы и проблемки:

    1. Если он слишком слабый…

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

    2. Если он слишком сильный…

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

    3. РМ, нанятый со стороны, под проект Я встречался и с таким подходом. Когда в компании-заказчике понимали, что людей, которые могли бы заниматься проектом с достаточным погружением нет, и нанимали внешнего специалиста, которому ставилась конкретная задача — вести проект и внедрить систему. Мотивация самая простая: оклад + бонус. Оклад на время контракта (планируемый срок проекта + 20% времени), бонус в размере чуть ли не половины оклада за весь этот срок. Бонус — только в случае, если проект будет запущен. По большому счету, вариант отличный. Для большой компании хороший ход. Один минус — руководитель проекта человек чужой, он с одной стороны не в курсе многих особенностей работы компании, и не может ответить на вопросы сам. С другой стороны — у него нет авторитета, наработанного уважения в организации, поэтому ему очень сложно влиять на сотрудников компании, требовать с них выполнения сроков и так далее.

    4. Если он слишком высоко

    Встречался я и с такой ситуацией — руководителем проекта себя провозглашал владелец компании (при этом совсем не маленькой). Проект важный, стратегический, поэтому «командовать парадом буду я».

    С одной стороны, здорово конечно — возможности влияния, все рычаги воздействия на коллектив, всё в наших руках. Какие минусы? Ну, во первых — многие участники испытывают робость, общаясь «с сами». Пусть даже «сам» дал свой личный номер сотового, и уверил что можно звонить ему в любое время дня и ночи, и все равно — и все равно, все себя чувствуют слегка некомфортно. Ну еще бы — грузить своими рабочими момента солидного дядечку, лет за 50, владельца большой компании, занятого и делового. А рабочих моментов, текучки, гораздо больше, чем по настоящему стратегических вещей, требующих вмешательства птицы такого высокого полета.

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

    Важное! Есть малые проблемы — будут и большие. Одним из самых сложных этапов в проекте является внедрение — это кульминация всего, что было сделано. В этот момент происходит столкновение двух реальностей — системы, которую сделал исполнитель, и ожиданий от системы, которые есть в голове у заказчика. В этот момент очень много требуется от людей, влияние человеческого фактора огромно. Сотрудникам предприятия надо переучиваться, осваивать что-то новое (а этого ведь никто не любит). На этом этапе им будет сложнее всего, и если на ранних этапах проекта (обследование, интервью, подготовка задания на разработку), были проблемы — на этом этапе проблемы будут с вероятностью 100%, все что раньше происходило, усилится.

    Если подвести итог, главные требования к PM (сугубо мое личное мнение):

    Он должен быть!

    Ага, именно так ) Без него проект будет идти абы как, и исполнитель не может взять на себя его функции. Так же как не может руководить сотрудниками заказчика в стиле «ну ты им скажи, чтобы они все делали». На каком основании — ведь исполнитель, не начальник в чужом доме (у клиента), исполнитель будет командовать и распоряжаться?

    Он должен быть один. Несомненно, проект может состоять из серии работ, которые между собой слабо связаны. Или не связаны вообще (тогда это, скорее, пул проектов). Но за каждый конкретный проект должен отвечать ОДИН человек. Вне зависимости от качества коммуникации между участниками, если со стороны заказчика за проект отвечают несколько, он будет хромать. С одним обсудили и договорились, другой не в курсе. Письмо прочитал, но не все понял однозначно. Принимает работу другой — и видит совсем не то что считает правильным. Все поправили — вернулся первый, «ой, все не то».Ситуация абсолютно недопустимая, только  один PM должен быть, только один.

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

    .

    Организационные задачи Заказчика на проекте

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

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

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

    Практический опыт показывает, что  внедрение автоматизированной ERP-системы – это на 80% проект организационных изменений на предприятии, и только на 20% – проект установки, доработки и настройки программ!

    Распределение трудоемкости проектных работ (в абсолютном выражении) на стадиях:

    • Функциональное моделирование: Исполнитель 50%, Заказчик 50% (выработка требований, анализ и согласование результатов).
    • Функциональные требования на доработки: Исполнитель 70%, Заказчик 30% (выработка требований, анализ и согласование результатов).
    • Реализация: Исполнитель 90%, Заказчик 10% (участие в испытаниях, анализ результатов испытаний).
    • Ввод в действие (пусконаладка): Исполнитель 30%, Заказчик 70% (ввод и выверка исходных данных).
    • Опытная эксплуатация: Исполнитель 20%, Заказчик 80% (работа пользователей в системе).

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

    ГОСТ Р 57363-2016

    НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

     УПРАВЛЕНИЕ ПРОЕКТОМ В СТРОИТЕЛЬСТВЕ. ДЕЯТЕЛЬНОСТЬ УПРАВЛЯЮЩЕГО ПРОЕКТОМ (ТЕХНИЧЕСКОГО ЗАКАЗЧИКА)

     Project management for real estate development (construction). Project manager (client’s technical representative) activities

    ОКС 91.010.30

    Дата введения 2017-06-01

     Предисловие

    1 РАЗРАБОТАН Акционерным обществом «Центральный научно-исследовательский и проектно-экспериментальный институт промышленных зданий и сооружений» (АО «ЦНИИПромзданий»)

    2 ВНЕСЕН Техническим комитетом по стандартизации ТК 465 «Строительство»

    3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 16 декабря 2016 г. N 2043-ст

    4 ВВЕДЕН ВПЕРВЫЕ

    5 ПЕРЕИЗДАНИЕ. Ноябрь 2019 г.

    Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. N 162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ежемесячном информационном указателе «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

          1 Область применения

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

    Требования настоящего стандарта распространяются на управление любыми проектами в строительстве и могут быть применены при строительстве зданий и сооружений различного функционального назначения, их реконструкции и капитальном ремонте, за исключением объектов определенных в соответствии со статьей 48.1 Градостроительного кодекса как особо опасные и технически сложные, линейные объекты железнодорожного транспорта, объекты культурного наследия.

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

          2 Нормативные ссылки

    В настоящем стандарте использованы нормативные ссылки на следующие стандарты:

    ГОСТ Р 51901.4* Менеджмент риска. Руководство по применению при проектировании

    ________________

    * Действует ГОСТ Р МЭК 62198-2015.

    ГОСТ Р 52807 Руководство по оценке компетентности менеджеров проектов

    ГОСТ Р 54869 Проектный менеджмент. Требования к управлению проектом

    ГОСТ Р 54870 Проектный менеджмент. Требования к управлению портфелем проектов

    ГОСТ Р 54871 Проектный менеджмент. Требования к управлению программой

    ГОСТ Р ИСО 21500 Руководство по проектному менеджменту

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

          3 Термины и определения

    В настоящем стандарте применены следующие термины с соответствующими определениями:

    3.1 инвестиционно-строительная деятельность: Деятельность, направленная на привлечение, вложение и управление инвестициями (инвестирование) для целей строительства, реконструкции и капитального ремонта, организацию (планирование), ввод в действие объектов производственного и непроизводственного назначения, а также линейных сооружений.

    3.2 оптимизация проектных решений (value engineering): Модификация проектной или рабочей документации, направленная на определение и принятие проектных решений, снижающих стоимость капитальных затрат, затрат на эксплуатацию, улучшающих эффективность строительства и качество объекта.

    3.3 предпроектная подготовка строительства: Комплекс работ, проводимых в целях обоснования градостроительной деятельности на территории и получение права на ее проведение [1].

    3.4 проект в строительстве (инвестиционно-строительный проект): Комплекс взаимосвязанных мероприятий, направленных на создание объекта (основных фондов), комплекса объектов производственного или непроизводственного назначения, линейных сооружений в условиях временных и ресурсных ограничений.

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

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

    Примечание — Управляющий проектом представляет управляющую компанию или непосредственно организацию застройщика (инвестора).

    3.7 управление строительством (construction management): Организация строительного производства на объекте, включая: планирование, контроль, оценку и управление рисками, координацию работ подрядных и строительно-монтажных организаций, авторского надзора, строительного контроля, других участников строительства, реконструкции или капитального ремонта.

          4 Общие положения. Управление проектом в строительстве

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

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

    4.3 Стандарт содержит рекомендуемые унифицированные подходы по деятельности управляющего проектом, его основные функции и задачи, в которые может входить весь комплекс организационно-управленческих работ, обеспечивающих строительство «под ключ», в том числе:

    — организация реализации инвестиционно-строительного проекта;

    — сбор и подготовка исходных данных;

    — предпроектная подготовка строительства;

    — анализ участников инвестиционно-строительного проекта, их компетенций, финансово-хозяйственного состояния, репутации и соответствия их возможностей предъявляемым требованиям;

    — оценка и управление рисками;

    — обеспечение функции технического заказчика и строительного контроля;

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

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

    — сдача-приемка объекта в эксплуатацию.

    4.4 Взаимодействие управляющего проектом в строительстве с другими участниками инвестиционно-строительного проекта осуществляется на основе договорно-правовых отношений и установленных ему застройщиком (инвестором) полномочий.

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

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

    4.7 Методология управления проектом в строительстве разработана в соответствии с отечественными и международными стандартами и практиками по управлению проектами. Основные этапы управления проектом в строительстве приведены на рисунке А.1 приложения А.

    4.8 Принципиальная схема управления проектом в строительстве приведена на рисунке А.2 приложения А.

          5 Организация управления проектом в строительстве

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

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

    5.3 Организационная структура управления проектом в строительстве зависит от сложности проекта, его специфики, объема инвестирования, сроков реализации, региональных и климатических особенностей, таких как работа в условиях Крайнего Севера, значительная удаленность от населенных пунктов, а также прочих неблагоприятных условий.

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

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

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

          6 Этапы реализации проекта в строительстве

          6.1 Инициирование проекта в строительстве

    На данном этапе определяется необходимость и возможность инвестиционного проекта в строительстве, его бизнес-планирование.

    6.1.1 Инвестиционная деятельность в Российской Федерации осуществляется в соответствии с Федеральным законом N 39-ФЗ «Об инвестиционной деятельности в Российской Федерации, осуществляемой в форме капитальных вложений» [2], а также в соответствии с Федеральным законом N 160-ФЗ «Об иностранных инвестициях» и другими нормативно-правовыми документами [3].

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

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

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

    6.1.5 В процессе принятия решения о целесообразности и возможности инвестирования в строительство предприятий, зданий и сооружений на соответствующей территории, а также для получения предварительных исходных данных, наличии земельных участков для строительства, условий присоединения объекта к источникам снабжения, инженерным коммуникациям и сетям необходимо разрабатывать Ходатайство (Декларацию) [4] о намерениях инвестирования в строительство предприятий, зданий и сооружений на территории Российской Федерации. При разработке Ходатайства (Декларации) [4] следует руководствоваться законодательными и нормативными актами Российской Федерации, субъектов Российской Федерации и другими государственными документами, регулирующими инвестиционно-строительную деятельность.

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

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

    — определение состава работ (содержания) проекта, предпроектные проработки, предварительный выбор земельного участка (объекта строительства/реконструкции);

    — планирование коммуникаций — обмен информацией и документацией в проекте;

    — планирование бюджета проекта;

    — планирование закупок для проекта;

    — планирование качества проекта;

    — планирование кадровых ресурсов проекта;

    — определение рисков проекта и вероятных путей снижения их воздействия;

    — планирование и управление сроками (графиком) реализации проекта;

    — планирование работы с возможными изменениями проекта;

    — определение ключевых показателей эффективности и результатов проекта в строительстве.

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

    6.2.1 Определение состава работ (содержания) проекта

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

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

    6.2.2 Планирование коммуникаций в проекте, обмен информацией и документацией между участниками проекта

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

    6.2.3 Планирование бюджета проекта в строительстве

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

    — расчет стоимости планируемых работ и услуг;

    — сведение всех элементов и операций для планирования бюджета проекта, а также определение источников его финансирования;

    — проверку предъявляемых к оплате документов организаций за выполненные работы, поставленную продукцию и оказанные услуги;

    — обеспечение своевременного финансирования и своевременной оплаты работ по договорам с исполнителями работ;

    — определение стоимости необходимых изменений, предложения по оптимизации бюджета;

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

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

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

    Одним из инструментов управления проектами является планирование закупок материалов, оборудования, работ и услуг для оптимизации стоимости закупаемой продукции и сроков ее поставки.

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

    Отдел закупок может входить в структуру застройщика (инвестора).

    6.2.5 Планирование и управление качеством проекта в строительстве

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

    6.2.6 Планирование и управление кадровыми ресурсами проекта

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

    6.2.7 Планирование и управление рисками проекта в строительстве

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

    6.2.8 Планирование и управление сроками (графиком) реализации проекта в строительстве

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

    6.2.9 Планирование работы с возможными изменениями проекта в строительстве и управление ими

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

    6.2.10 Определение ключевых показателей эффективности и результатов проекта в строительстве

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

    — проект закончен в срок, в рамках бюджета;

    — требуемое (проектное) качество объекта достигнуто;

    — ресурсы проекта распределены максимально эффективно;

    — проект соответствует бизнес-плану.

    Ключевые показатели эффективности для каждого проекта разрабатывают управляющий проектом совместно с застройщиком (инвестором).

          6.3 Реализация проекта строительства

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

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

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

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

    Управляющий проектом координирует, в случае необходимости, взаимодействие проектных, изыскательских и прочих организаций — участников проектной подготовки строительства, контролирует обеспечение требуемого уровня качества проектных решений в процессе разработки и реализации проектной и рабочей документации, определяет целесообразность вариантного проектирования и оптимизации (value engineering) предлагаемых проектных решений.

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

    6.3.4 На стадии согласования проектной документации (permission management), управляющий проектом обеспечивает рассмотрение и согласование в установленном порядке проектной документации в государственных органах, муниципальных образованиях и прочих заинтересованных организациях, в том числе в органах экспертизы, для чего определяет органы экспертизы (в случае негосударственной экспертизы) и принимает участие в заключении соответствующих договоров. Управляющий проектом организует утверждение и переутверждение проектной документации, а также внесение в проектную документацию изменений по требованиям экспертизы.

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

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

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

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

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

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

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

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

          6.4 Мониторинг и контроль за реализацией проекта в строительстве

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

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

    6.4.3 Деятельность строительного контроля регламентирована действующим законодательством Российской Федерации, может осуществляться только при наличии допуска саморегулируемой организации.

          6.5 Завершение проекта, приемка объекта в эксплуатацию

    6.5.1 Управляющий проектом:

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

    — проверяет исполнительную документацию, передает документацию по приемке объекта в эксплуатацию на хранение пользователю объекта, если иное не предусмотрено нормативными документами местных органов власти и/или договором с застройщиком (инвестором);

    — представляет приемо-сдаточной комиссии необходимые документы по законченному строительством объекту;

    — создает от имени и по поручению застройщика (инвестора) приемо-сдаточную комиссию и проводит приемку от исполнителя работ, законченного строительством объекта;

    — взаимодействует с авторским надзором для получения заключения по объекту в случае необходимости;

    — согласует сроки устранения дефектов и недоделок в рамках договора с подрядной организацией;

    — готовит документы для обращения в соответствующие органы исполнительной власти за получением разрешения на ввод объекта в эксплуатацию;

    — готовит документы для осуществления ввода объекта в эксплуатацию и его последующей регистрации в местных органах власти, в установленном ими порядке;

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

    — готовит и передает застройщику (инвестору) отчет о выполнении договорных обязательств и о достижении проектом необходимых параметров по результатам строительства.

          6.6 Эксплуатация объекта, гарантийный период, его капитальный ремонт, реконструкция и ликвидация

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

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

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

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

          7 Основные права управляющего проектом в строительстве

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

    7.2 Управляющий проектом в строительстве имеет право:

    — представлять интересы застройщика (инвестора) в учреждениях, организациях и на предприятиях по вопросам реализации инвестиционно-строительного проекта, в рамках своей компетенции и условий, определенных договором;

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

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

    — оценивать риски и влияние на проект изменений, предлагаемых застройщиком (инвестором), своевременно доводить рекомендации до ответственного представителя;

    — принимать решения в рамках своих полномочий и компетенций, по всем вопросам планирования и реализации проекта в строительстве;

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

    — при необходимости приостанавливать работу по реализации проекта, в том числе производство отдельных видов строительно-монтажных работ;

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

    — требовать в установленные сроки утвержденными планами работ отчеты, информацию, а также получать материалы и документы по возникающим оперативным вопросам;

    — вносить предложения застройщику (инвестору) о наложении в установленном порядке взысканий и других мер административного воздействия на виновных в несвоевременном или некачественном выполнении работ, заданий и поручений управляющего проектом;

    — предоставлять отчеты куратору (ответственному представителю) застройщика (инвестора);

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

    7.3 Обязанности и ответственность управляющего проектом в строительстве определяются договором, в зависимости от сложности объекта, и объемом работ управляющего проектом, определенным сторонами.

    Приложение А

    (справочное)

    Основные этапы управления проектом в строительстве

    А.1 Основные этапы управления проектом в строительстве приведены на рисунке А.1.

    Рисунок А.1

    А.2 Принципиальная схема управления проектом в строительстве приведена на рисунке А.2.

    Рисунок А.2

    Приложение Б

    (справочное)

    Состав основных участников команды проекта в строительстве

    В состав организационной структуры (команды) проекта в строительстве могут входить:

    1 управляющий проектом в строительстве (руководитель проекта, менеджер проекта/project manager); обеспечивает общее руководство и управление процессами и работами, отвечает за получение результатов проекта, управляет командой проекта;

    2 руководитель по проектированию (design manager); координирует выполнение работ по проектированию в рамках проекта, контролирует соответствие выполняемых рабочих документов проектных работ — ранее утвержденной предпроектной и проектной документации, отвечает за внедрение эффективных решений, вариантное проектирование и оптимизацию проектных решений (value engineering);

    3 руководитель по строительству (construction manager); координирует все виды работ, выполняемые на строительной площадке, контролирует выполнение работ в соответствии с рабочей документацией, техническими регламентами и сводами правил;

    4 руководитель по согласованиям (permission manager); координирует все вопросы, связанные с оформлением градостроительной и иной исходно-разрешительной документацей, получением технических условий и специальных технических условий, согласованием проектной и рабочей документации в установленном порядке;

    5 руководитель по финансово-учетным вопросам (cost manager); координирует своевременность и полноту оплат по договорным обязательствам и прочим расходам в соответствии с графиком финансирования и фактом выполнения работ, контроль налоговых выплат, соответствие фактических затрат бюджету проекта, внесение необходимых корректировок в процессе реализации проекта;

    6 руководитель по закупкам и поставкам материалов и оборудования (procurement manager); координирует все виды закупок и поставок на этапах реализации проекта в строительстве;

    7 координатор по планированию (scheduling control coordinator/planner); отвечает за разработку графика реализации проекта и регулярный контроль его исполнения, внесение необходимых корректировок и изменений по ходу реализации проекта;

    8 координатор по договорно-правовым вопросам (contract manager); осуществляет контроль за исполнением договорных обязательств, отвечает за соблюдение процедур по внесению изменений в договора, претензионную работу;

    9 координатор работ по подготовке к эксплуатации и гарантийной эксплуатации; отвечает за организацию и проведение эксплуатационных испытаний, подготовку объекта к эксплуатации, передачу эксплуатационной и гарантийной документации застройщику (инвестору), поддержку застройщика (инвестора) в период гарантийной эксплуатации;

    10 администратор проекта (document control coordinator); координирует и контролирует документооборот, а также вспомогательную деятельность, обеспечивает необходимые условия для работы команды проекта.

     Библиография

    [1]

    Рекомендации по деятельности Управляющего проектом при разработке и реализации проектной и рабочей документации на строительство предприятий, зданий и сооружений, МДС 11-2.99 (утверждено письмом Госстроя РФ 10 июня 1999 г. N ЛБ-1992/5)

    [2]

    Федеральный закон от 25 февраля 1999 г. N 39-ФЗ «Об инвестиционной деятельности в Российской Федерации, осуществляемой в форме капитальных вложений»

    [3]

    Федеральный закон от 9 июля 1999 г. N 160-ФЗ «Об иностранных инвестициях»

    [4]

    Типовое положение по разработке и составу Ходатайства (Декларации) о намерениях инвестирования в строительство предприятий, зданий и сооружений (утверждено Минстроем РФ 7 марта 1997 г*.)

    УДК 721.013:006.354

    ОКС 91.010.30

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

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

    author__photo

    Содержание

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

    Оптимизируйте маркетинг и увеличивайте продажи вместе с Calltouch

    Узнать подробнее

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

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

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

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

    Чем отличается проектное управление от традиционного менеджмента

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

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

    Зачем нужно управление проектами

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

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

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

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

    caltouch-platform

    Технология
    речевой аналитики
    Calltouch Predict

    • Автотегирование звонков
    • Текстовая расшифровка записей разговоров

    Узнать подробнее

    platform

    Стандарты управления проектами

    Это рекомендации и советы, на которые нужно ориентироваться при организации работы. Какие стандарты бывают:

    • Общественные. Разрабатывают и применяют в обществах специалистов.
    • Корпоративные. Разрабатывают и используют в рамках одной компании.
    • Частные. Создают специально для определенных проектов.

    Есть международные стандарты управления проектами – правила организации работы в разных странах. Один из самых известных стандартов – PMBOK (A Guide to the Project Management Body of Knowledge). Это руководство по управлению проектами, где есть вся терминология и базовые принципы. Его применяют в более 160 странах мира.

    Стандарты управления проектами

    Роли в проекте

    Роль в проекте – это набор функций и полномочий для разделения обязанностей между членами команды. Стандарт PMBOK выделяет следующие роли:

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

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

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

    Состав идеальной команды зависит от специфики и целей проекта: можно привлекать дополнительных специалистов или наоборот, исключать лишних.

    Кто такой руководитель проекта

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

    Требования к проект-менеджеру

    Какие компетенции понадобятся руководителю проектов в работе:

    • Знания в области управления проектами, включая стратегическое мышление, умение прогнозировать и планировать.
    • Опыт. Чем больше у проект-менеджера кейсов, тем лучше он понимает как распоряжаться бюджетом, решать разные проблемы, взаимодействовать с командой.
    • Техническая подготовленность. Эффективный проект-менеджер – это не просто управленец, а компетентный специалист. Он может грамотно настроить все процессы, потому что разбирается в специфике проекта: IT-сфере, строительстве, архитектуре или других областях.
    • Умение работать с людьми. Способность сформировать и отладить работу внутри команды – половина успеха проекта.
    • Личностные качества: ответственность, коммуникабельность, аналитический склад ума, стрессоустойчивость, многозадачность и оптимизм.

    Преимущества проектного метода управления и его недостатки

    Плюсы проектного управления:

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

    Минусы формата:

    • Недостаток ресурсов. Часто у маленьких компаний не хватает средств на перераспределение бюджетов и других ресурсов между несколькими проектами.
    • Высокие требования к квалификации руководителя. На рынке недостаточно проект-менеджеров с нужными навыками и опытом.
    • Сложности перехода. Изменить традиционную систему управления на проектную сложно и занимает много времени.

    Преимущества проектного метода управления и его недостатки

    Основные этапы управления проектом

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

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

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

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

    Теперь нужно определить, как именно будет выполняться проект:

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

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

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

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

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

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

    Контролировать работу легче с помощью автоматизированных систем: CRM и других сервисов. Например, сквозная аналитика от Calltouch поможет проанализировать эффективность интернет-рекламы. Система объединяет данные со всех площадок в одном окне. С помощью наглядных отчетов можно сделать выводы об эффективности, оптимизировать затраты и выстроить полноценную воронку продаж.

    caltouch-platform

    Сквозная аналитика Calltouch

    • Анализируйте воронку продаж от показов до денег в кассе
    • Автоматический сбор данных, удобные отчеты и бесплатные интеграции

    Узнать подробнее

    platform

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

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

    Подходы к управлению жизненным циклом проекта

    Жизненным циклом можно управлять: от этого зависит результативность проекта. По подходам к управлению жизненные циклы делят на:

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

    Подходы к управлению жизненным циклом проекта

    Какую выбрать методологию

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

    Waterfall

    Эту модель еще называют каскадной или водопадной. Главный принцип метода – последовательное и четкое соблюдение всех этапов по заранее продуманному плану. Например, этапы разработки IT-продукта по методологии Waterfall:

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

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

    Agile

    В отличие от Waterfall, Agile – целый набор гибких методик. Его главная ценность – это качество продукта, поэтому agile-команды постоянно поддерживают контакт с заказчиком и готовы к любым изменениям и доработкам. Обычно методология используется в IT-сфере при работе небольших групп сотрудников, занятых творческой работой.

    Scrum

    Scrum – это часть методологии Agile. Здесь тоже в приоритете результат и удовлетворение запросов заказчика, поэтому его максимально вовлекают в процесс. Работа состоит из коротких периодов – спринтов. В рамках спринта создается часть продукта, которую тестируют демонстрируют клиенту. По обратной связи от клиента команда улучшает эффективность.

    Kanban

    «Kanban» переводится как «доска объявлений». Это тоже часть Agile-философии, включающая ее базовые принципы. Методологию используют для равномерного распределения обязанностей между сотрудниками, чтобы не перегрузить команду.

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

    Какую выбрать методологию

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

    Чтобы руководителю было проще выстраивать и контролировать процессы, разработчики создают специальные сервисы и ПО, которые автоматизируют часть работы. Самые популярные:

    • Битрикс24 – российский сервис для управления бизнесом: поддерживает работу с Kanban, диаграммой Ганта, обеспечивает продвинутую фильтрацию в задачах.
    • Jira – это система отслеживания ошибок в программном коде. При этом множество компаний использует ее инструментарий для управления проектами. Подходит для работы по Scrum и Kanban.
    • Asana – это приложение для управления командными проектами. Есть система удобных тегов, можно анализировать эффективность и управлять несколькими проектами в рамках одной команды.

    Заключение

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

    Предложения от наших партнеров

    kt.team

    Между клиентом и командой: как проджект-менеджер берет огонь на себя и упрощает жизнь разработчиков

    Содержание

    • Труд разработчиков и оценка его сложности
    • Функции проджект-менеджера: качественная постановка задачи
    • Функции проджект-менеджера: коммуникации
    • Функции проджект-менеджера: управление проектами
    • Наставник по качеству, бизнес-аналитик, системный аналитик
    • Резюме: плюсы работы в большой команде

    Легко ли живётся разработчикам? В разных компаниях — по-разному. Давайте посмотрим, как это вообще можно оценивать и как в kt.team строят команды, работать в которых легко и приятно.

    Труд разработчиков и оценка его сложности

    Если вы читаете эту статью, скорее всего, вы прекрасно знаете, чем занимаются разработчики. Уточним на всякий случай: они создают и поддерживают прикладное программное обеспечение (web-сайты, мобильные приложения, системы распознавания документов, BI-системы, B2B-бизнес-порталы и многое другое).

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

    Чтобы узнать, какими бывают разработчики, воспользуемся методом оценки должностей Эдварда Хэя.

    Факторы оценки должностей по методу Хэя:

    • Необходимые знания и опыт (know-how)

      это практические навыки, теоретические знания и опыт, необходимые для выполнения должностных обязанностей.

    • Решение задач (problem solving)

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

    • Уровень ответственности (accountability)

      ответственность сотрудника (за личный и/или командный результат труда).

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

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

    По методу Хэя:

    • Необходимые знания и опыт: нужны узкоконкретизированные.

    • Решение задач: низкий уровень. Задачи приходят разбитыми на мельчайшие шаги — до атомарного уровня, без доли неопределённости.

    • Уровень ответственности: низкий (близкий к нулю).

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

    Если в формулировке задачи ему не написали, что нужно обработать возможные исключения, или указали их не все, кодер не будет учитывать то, о чём его не предупредили. При этом он скажет: «Я не знал, что здесь могут быть исключения». Или: «Вы не описали все исключения, какие ко мне претензии?»

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

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

    Все три фактора оценки сложности его труда будут на значительно более высоком уровне, чем у кодера.

    Функции проджект-менеджера: качественная постановка задачи

    На рынке труда есть и кодеры, и инженеры: и те и другие востребованы, просто в разных компаниях. Но, кроме разработчиков, в команде может быть ещё один очень важный человек — это проджект-менеджер. Нужен ли он там, где уже есть инженеры? С их высоко развитыми навыками решения задач, знаниями, опытом и высоким уровнем ответственности…

    Попробуем ответить на этот вопрос

    Основополагающая философия в IT — это Agile, гибкое управление проектами.

    Сам Agile не делит людей по ролям. Структура команды здесь плоская, и ответственность за результат несёт вся команда.

    В Agile есть product owner (заказчик, который принимает бизнес-решение и говорит, насколько эта фича значимая — при постановке задачи, есть ли от неё нужный эффект — после выполнения) и команда, в которой все участники равны. Роли проджект-менеджера не предусмотрено. Но в жизни не всё так просто.

    kt.team — это системный интегратор, то есть подрядчик, который разрабатывает сложные IT-решения для внешних заказчиков.

    У Agile-интегратора на принципы Agile накладывается парадигма TQM (total quality management, или всеобщее управление качеством).
    Правила TQM:

    • я не делаю брак;
    • я не пропускаю брак;
    • я не принимаю брак;

    Правила TQM можно изобразить в виде пирамиды, на каждом уровне которой — свои ответственные за качество.

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

    Например, есть задача: разработать простую форму регистрации на сайте с единственным полем — «Год рождения».

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

    Проблема в том, что задача может быть поставлена некорректно (вы тоже наверняка с этим сталкивались). Бракованная задача — та, что плохо описана, и для её выполнения недостаточно данных.

    В нашем примере с формой регистрации: если человек укажет возраст пять лет, это нужно считать ошибкой или следует разрешить ему регистрацию? Где верхняя граница отсечения — 65 лет или 100 лет? Чтобы это понять, простого здравого смысла мало — нужно узнать особенности бизнеса клиента.

    Другой пример: клиент предлагает внедрить избыточное решение (например, новые маркетинговые фичи). Возможно, идея не самая лучшая, реализация уменьшит объём продаж, или мы потратим на неё слишком много времени в ущерб более важным задачам. Представляете, если всё это должен проанализировать разработчик или тимлид? Ему нужно разбираться в маркетинге, думать о рентабельности и напрягаться по поводу не только качества своего кода, но и общих бизнес-показателей проекта. Сколько времени нужно, чтобы сначала научиться этому, а потом выполнять изо дня в день?..

    В команде с проджект-менеджером за уровень качества постановки задачи отвечает именно он!

    На этом промежуточном уровне между владельцем продукта и разработчиком стоит проджект-менеджер, который является тем самым барьером «я не пропускаю брак» на уровне постановки и ранжирования задач. Он добивается высокого качества постановки задачи (вместе с заказчиком) и высокого качества готового продукта (вместе с разработчиками).

    Мы не можем сказать: «Знаешь что, клиент, какая-то у тебя не такая задача, иди-ка подумай и приходи с нормальным требованием». Поэтому проджект-менеджер принимает любые пожелания клиента и доводит их до качественного состояния: анализирует, отсекает ненужное, описывает разработчику, что нужно сделать, зачем, на какую ценность «ложится» эта задача. Для этого используем метод INVEST (или SMART) и impact mapping: это метод описания задач, который позволяет максимально глубоко продумать задачу со стороны пользовательской ценности, и методика, согласно которой конкретная задача ложится на улучшение конкретных показателей.

    В задаче, описанной по INVEST, есть ответы на вопросы:

    • кто (роль);
    • где (место нахождения);
    • что делать;
    • для чего это всё нужно.

    Сценарий по INVEST всегда должен включать бизнес-требование (что конкретно и в каком контексте требуется).

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

    За INVEST отвечает владелец продукта, это уровень бизнес-требований, и это уровень качества владельца продукта (только он владеет нужными данными, и он будет принимать готовый результат). А прийти к нужным формулировкам ему помогает проджект-менеджер.

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

    Функции проджект-менеджера: коммуникации

    Важная часть обязанностей проджект-менеджера — управление коммуникациями.

    Алексей

    Проджект-менеджер

    «Менеджер проектов отвечает за коммуникации с заказчиком и, если возникают какие-то спорные ситуации, вызывает огонь на себя. До команды доходят только конструктивные комментарии: что не так, почему, как надо».

    Перевод с языка клиента

    Сами проджект-менеджеры называют себя переводчиками с языка клиента на язык разработчиков и обратно. Если просто «бросить» команду разработчиков наедине с клиентом, они не поймут друг друга, потому что разговаривают на разных языках: клиенту нужно объяснять технические тонкости, а команде — переформулировать задачу от клиента в понятном для них виде.

    Общение по принципу «одного окна»

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

    Удобно и разработчикам: не нужно выпрашивать и ждать от заказчика нужные данные, искать того, кто может их предоставить.

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

    Объективное планирование времени (никаких невыполнимых обещаний)

    Для исполнителя очень сложно правильно оценить, сколько времени ему понадобится на выполнение задачи. Это психологическая ловушка — он будет стремиться назвать заказчику минимальный, невыполнимый срок («я же профессионал, эта задача лёгкая для меня») или, наоборот, планировать время механистически, закладывая слишком большой одинаковый резерв на все задачи. Проджект-менеджеру со стороны легче объективно оценить требуемое количество времени, а значит, команде будет легче не профакапить сроки и не допустить при этом перерасхода средств клиента.

    В kt.team проджект-менеджер запрашивает оценку времени на выполнение задач от тимлида и команды и с учётом этой оценки и имеющихся ресурсов клиента даёт итоговый план.

    С одной стороны, мнение тимлида и сотрудника всегда учитывается (не будет невыполнимых суперсжатых сроков), а с другой — проджект-менеджер может варьировать приоритеты, чтобы клиент получал выполнение важнейших для него задач быстрее.

    Большие затраты времени на коммуникацию и протоколирование

    Из восьмичасового рабочего дня около 4 часов проджект-менеджер тратит на общение с клиентом! Команда избавлена от этого — общение проджекта с разработчиками обычно ограничивается коротким утренним совещанием (daily meeting).

    Проджект-менеджер общается с клиентом через большое количество каналов связи: email, телефоны, мессенджеры; на некоторых проектах также приходится отслеживать данные в ПО заказчика (например, в Jira). Иногда проджект-менеджерам приходится ездить в командировки, на территорию клиента, тратить время и силы на перелёты. Разработчик и тимлид имеют дело только с Jira (нашей внутренней системой). Побывать на большом конференц-колле с клиентом (на 1–2 часа) и выудить оттуда два абзаца ценной информации — это задача проджекта, а тимлид и команда получат эти данные в концентрированном виде за пять минут. Представляете, какая экономия времени?

    Проджект-менеджер много работает с документами:

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

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

    Приём готовой задачи

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

    Вывод

    Может ли всё это делать тимлид? Ведь у него высокий уровень soft skills и он неплохо умеет общаться.

    Тимлиды периодически общаются с клиентом даже при наличии проджект-менеджера. Но если бы менеджера проектов не было, тимлид был бы вынужден:

    • тратить минимум половину рабочего времени на выяснение бизнес-требований клиента;

    • дёргаться каждые пять минут от входящих сообщений в мессенджерах, email’ов, звонков;

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

    • добывать нужные данные со стороны заказчика, организовывать их регулярное поступление;

    • вести протоколы, отчёты, рассылать их всем участникам;

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

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

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

    Функции проджект-менеджера: управление проектами

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

    • гибкая (Agile);
    • разработка по требованиям (waterfall).

    Метод выбирается по согласованию с заказчиком и очень от него зависит. Например, для крупной корпорации, где нужно решить заранее согласованную задачу, больше подойдёт waterfall. А если проект отличается высокой степенью неопределённости (что часто встречается в разработке ПО), то чаще всего выбирают Agile.

    Алексей

    Проджект-менеджер

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

    Что делает проджект-менеджер каждый день для управления проектом:

    • контролирует своевременный запуск и ход работ;
    • проводит ежедневные совещания с командой (daily meeting);
    • воздействует на команду (или руководителя команды), чтобы факт соответствовал плану и выполнял требования клиента;

    • всегда держит в фокусе сроки, бюджет и качество и разумно управляет ими;

    • ведёт документацию по проекту (уставы проектов, интеллект-карты, отчёты и т. д.);

    • участвует в демонстрациях функционала клиенту.

    Вывод

    Если переложить эти функции на тимлида, они отнимут у него много сил и времени. А, как мы уже говорили, у тимлида достаточно своих задач.

    Наставник по качеству, системный аналитик, бизнес-аналитик

    Кто ещё помогает командам, облегчая жизнь тимлидам и разработчикам? Делимся опытом kt.team.

    Наставник по качеству

    Нас иногда спрашивают: «Почему у вас так мало тестировщиков?» Их у нас действительно нет, вместо них — двое наставников по качеству. Это соответствует парадигме Agile: работа идёт в «плоских» командах, где нет отдельной функции качества. Помним здесь и о TQM — за качество исполнения задачи отвечает каждый разработчик.

    Отсутствует

    Если в команде есть тестировщики, это меняет весь ход работ.

    Разработчики могут негласно перекладывать ответственность за качество своей работы на них. Цикл работы становится рваным — «я сделал задачу, а проверил её кое-как — тестировщик проверит лучше». Качество падает.

    Тестировщик проверяет и возвращает работу на дебаггинг, и так много раз, много итераций.

    А разработчик в итоге не может погрузиться глубоко ни в одну задачу, потому что к нему постоянно возвращается пул старых задач. Теряется фокус, работа идёт менее продуктивно, в рваном режиме.

    Присутствует

    Поэтому наши наставники по качеству начинают тестировать проект, только когда команда не может сама обеспечить высокое качество. Причина одна — это слишком жёсткие сроки, настолько сжатые, что нужна дополнительная помощь (например, запуск интернет-магазина с нуля за три месяца, как было у нас в «ТВОЁ», и мы буквально жили в офисе у клиента; это было несколько лет назад, и больше мы не делаем проекты с такими экстремальными сроками).

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

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

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

    Бизнес-аналитик

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

    Бизнес-аналитик может также:

    • самостоятельно настроить продукт, если какая-то часть бизнес-требований может быть выполнена настройками;
    • составить техническое задание на разработку за клиента, если ему это нужно

    Системный аналитик

    На некоторых проектах команде помогает системный аналитик. Часто его функции выполняет техлид (технический лидер).

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

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

    Резюме: плюсы работы в большой команде

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

    Кроме менеджера проектов, вместе с разработчиком работают и поддерживают его другие участники команды. Это тимлид — руководитель рабочей группы; техлид, или системный аналитик, который может проработать техническую сторону задачи; наставник по качеству, который не только проконтролирует качество кода, но и проведёт анализ, почему задача была поставлена неверно; бизнес-аналитик (часто в одном лице с менеджером проектов), который декомпозирует задачу на мельчайшие подзадачи, а при необходимости поможет клиенту составить техническое задание.

    У нас в компании пять проджект-менеджеров, каждый ведёт несколько проектов.

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

    Поделиться

    Читай также


    Процесс обучения в IT бесконечен, как лента Мёбиуса. Технологии обновляются, меняются фреймворки, и разработчики постоянно учатся чему-то новому даже в рамках одного стека.


    Где разработчику выгоднее и удобнее развивать свою карьеру: на фрилансе или в офисе? Рассматриваем опыт фриланса и работу в kt.team.


    Почему мы используем маркетинговый подход в web-дизайне (data-driven design) и как UX-исследования от Baymard помогают нам улучшать юзабилити интернет-магазинов.


    Скандал на «Стачке» и удаление сексистского спикера. А что на самом деле происходит с женщинами в IT? Наш опыт.


    Примеры дизайна и организации пространства в офисах IT-компаний. Что и зачем нужно программистам в офисе? Сравнение мировой практики и опыта kt.team.


    Понравилась статья?

    Подпишись на нашу рассылку — стань первым, кто узнает о наборе
    на обучающие курсы, митапах и новых открытых вакансиях!

    Елена Филипова, руководитель корпоративного проектного офиса «Адванта Консалтинг», сертифицированный специалист Project Management Institute, квалификация Project Management Professional (PMP), автор книги «С чего начать внедрение проектного управления? Готовая методология контроля проектов организации»:

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

    Состав корпоративного Проектного офиса

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

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

    Исходя из представленных компетенций для ПрОф важно выделить несколько ключевых ролей:

    • Руководитель проектного офиса (Проектный директор)
    • Методолог
    • Администратор проектов/программ
    • Администратор ИСУП

    Другие роли:

    • Тренер
    • Менеджер по ресурсам
    • Координатор программ
    • Координатор портфеля
    • Аналитик

    Роль: руководитель Проектного офиса (Проектный директор)

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

     Как правило, функциями этой роли являются:

    • Контроль соответствия проектов целям организации;
    • Контроль процессов управления портфелем и программами;
    • Организация и контроль процесса приоритезации портфеля;
    • Обеспечение представления сводной отчетности по исполнению портфеля;
    • Контроль применения корпоративной методологии и инструментов управления;
    • Контроль сроков и качества ключевых проектов;
    • Обеспечение Проектного комитета и руководителей портфеля/программ необходимой информацией для принятия решений;
    • Организация работы ПрОф.
    Роль: методолог Проектного офиса

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

    Основные функции методолога:

    • Формирование корпоративных стандартов и методологии их применения, в том числе описание процессов проектного управления;
    • Интеграция инструментов управления проектами с другими системами менеджмента;
    • Проектирование корпоративной базы знаний по проектам;
    • Разработка корпоративной системы отчетности;
    • Выполнение аудитов проектов;
    • Внутреннее обучение и сертификация.

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

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

    Роль: администратор проектов/программ

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

    Основные функции администратора проектов/программ:

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

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

    Основные функции администратора ИСУП:

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

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

    Дополнительные роли

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

    Принципы построения эффективного Проектного офиса

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

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

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

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

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

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

    1. Правильно провести проект внедрения КСУП. Именно проект – с фиксацией целей, результатов, планом коммуникаций, реестром рисков и прочими приемами управления.
    2. Выбрать правильную методологию и внедрять ее, обязательно пилотируя использование документов и методик.
    3. Использовать информационную систему управления проектами в соответствии с уровнем зрелости проектного управления, сложностью проектов и компетенциями пользователей.
    4. Разработать единую систему мотивации для Руководителей проектов/программ и сотрудников Корпоративного Проектного офиса.
    5. Непрерывно совершенствовать процессы управления: анализировать применение практик проектного управления, убирать неиспользуемые и лишние инструменты и добавлять необходимые процедуры для поддержки проектов.

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

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

    Понравилась статья? Поделить с друзьями:
  • Aquilea vigor el инструкция на русском
  • Учебник руководство по тех эксплуатации
  • Intel 80486 dx набор поддерживаемых инструкций
  • Диротон инструкция по применению таблетки от чего помогает взрослым
  • Фенилин инструкция по применению цена отзывы аналоги таблетки