«ПРОЕКТНЫЙ МЕНЕДЖМЕНТ В ПРОЕКТНОЙ ОРГАНИЗАЦИИ (вторая редакция) Москва 2013 Проектный менеджмент в проектной организации СОДЕРЖАНИЕ 1. ВВЕДЕНИЕ 2. ОСОБЕННОСТИ ПРОЦЕССА РАЗРАБОТКИ ПРОЕКТНОЙ ДОКУМЕНТАЦИИ. 8 3. ОСОБЕННОСТИ ...»

Б.М.Азимов, В.В.Бучацкий, И.В.Бучацкий, В.Х.Отман

ПРОЕКТНЫЙ МЕНЕДЖМЕНТ

В ПРОЕКТНОЙ ОРГАНИЗАЦИИ

(вторая редакция)

Москва 2013

Проектный менеджмент в проектной организации

СОДЕРЖАНИЕ

1. ВВЕДЕНИЕ

2. ОСОБЕННОСТИ ПРОЦЕССА РАЗРАБОТКИ ПРОЕКТНОЙ ДОКУМЕНТАЦИИ......... 8

3. ОСОБЕННОСТИ УПРАВЛЕНИЯ РАЗРАБОТКОЙ ПРОЕКТНОЙ ДОКУМЕНТАЦИИ...

4. ПРЕЖДЕ ЧЕМ СТРОИТЬ МОСТ…

4.1. СТАТУС ОПИСАНИЙ ПРОЦЕССОВ

4.2. НЕКОТОРЫЕ ОСОБЕННОСТИ РМВОК И ISO 21500

4.3. СРЕДСТВА ОПИСАНИЯ ПРОЦЕССОВ. ПОСТ-НОТАЦИЯ

5. ПРОЦЕССЫ УПРАВЛЕНИЯ ПРОЕКТАМИ

5.1. ГРУППА ПРОЦЕССОВ ИНИЦИАЦИИ

5.1.1. РАЗРАБОТКА УСТАВА ПРОЕКТА

5.1.2. ОПРЕДЕЛЕНИЕ ЗАИНТЕРЕСОВАННЫХ СТОРОН ПРОЕКТА

5.1.3. СОЗДАНИЕ КОМАНДЫ ПРОЕКТА

5.1.4. ПРОЦЕСС ИНИЦИАЦИИ (А1) В ПРОЕКТНОЙ ОРГАНИЗАЦИИ

5.2. ГРУППА ПРОЦЕССОВ ПЛАНИРОВАНИЯ

5.2.1. РАЗРАБОТКА ПЛАНА УПРАВЛЕНИЯ ПРОЕКТОМ

5.2.2. СБОР ТРЕБОВАНИЙ

5.2.3. ОПРЕДЕЛЕНИЕ СОДЕРЖАНИЯ

5.2.4. СОЗДАНИЕ ИЕРАРХИЧЕСКОЙ СТРУКТУРЫ РАБОТ

5.2.5. ОПРЕДЕЛЕНИЕ ОПЕРАЦИЙ

5.2.6. ОПРЕДЕЛЕНИЕ ПОСЛЕДОВАТЕЛЬНОСТИ ОПЕРАЦИЙ

5.2.7. ОЦЕНКА РЕСУРСОВ ОПЕРАЦИЙ

5.2.8. ОЦЕНКА ДЛИТЕЛЬНОСТИ ОПЕРАЦИЙ

5.2.9. РАЗРАБОТКА РАСПИСАНИЯ

5.2.10. ОЦЕНКА СТОИМОСТИ

5.2.11. ОПРЕДЕЛЕНИЕ БЮДЖЕТА

5.2.12. ПЛАНИРОВАНИЕ КАЧЕСТВА

5.2.13. РАЗРАБОТКА ПЛАНА УПРАВЛЕНИЯ ЧЕЛОВЕЧЕСКИМИ РЕСУРСАМИ....... 5.2.14. ПЛАНИРОВАНИЕ КОММУНИКАЦИЙ

5.2.15. ПЛАНИРОВАНИЕ УПРАВЛЕНИЯ РИСКАМИ

5.2.16. ИДЕНТИФИКАЦИЯ РИСКОВ

5.2.17. КАЧЕСТВЕННЫЙ АНАЛИЗ РИСКОВ

5.2.18. КОЛИЧЕСТВЕННЫЙ АНАЛИЗ РИСКОВ

5.2.19. ПЛАНИРОВАНИЕ РЕАКЦИИ НА РИСКИ

5.2.20. ПЛАНИРОВАНИЕ УПРАВЛЕНИЯ ЗАКУПКАМИ

5.2.21. ПРОЦЕСС ПЛАНИРОВАНИЯ ПРОЕКТА (А2) В ПРОЕКТНОЙ ОРГАНИЗАЦИИ.

5.3. ГРУППЫ ПРОЦЕССОВ ИСПОЛНЕНИЯ, МОНИТОРИНГА И УПРАВЛЕНИЯ.... 5.3.1. РУКОВОДСТВО И УПРАВЛЕНИЕ ИСПОЛНЕНИЕМ ПРОЕКТА

5.3.2. МОНИТОРИНГ И УПРАВЛЕНИЕ РАБОТАМИ ПРОЕКТА

5.3.3. ОСУЩЕСТВЛЕНИЕ ОБЩЕГО УПРАВЛЕНИЯ ИЗМЕНЕНИЯМИ

5.3.4. ПОДТВЕРЖДЕНИЕ СОДЕРЖАНИЯ

5.3.5. УПРАВЛЕНИЕ СОДЕРЖАНИЕМ

5.3.6. УПРАВЛЕНИЕ РАСПИСАНИЕМ

5.3.7. УПРАВЛЕНИЕ СТОИМОСТЬЮ

5.3.8. ОБЕСПЕЧЕНИЕ КАЧЕСТВА

5.3.9. КОНТРОЛЬ КАЧЕСТВА

5.3.10. НАБОР КОМАНДЫ ПРОЕКТА

Проектный менеджмент в проектной организации 5.3.11. РАЗВИТИЕ КОМАНДЫ ПРОЕКТА

5.3.12. УПРАВЛЕНИЕ КОМАНДОЙ ПРОЕКТА

5.3.13. РАСПРОСТРАНЕНИЕ ИНФОРМАЦИИ

5.3.14. ПОДГОТОВКА ОТЧЕТОВ ОБ ИСПОЛНЕНИИ

5.3.15. УПРАВЛЕНИЕ РИСКАМИ

5.3.16. ОСУЩЕСТВЛЕНИЕ ЗАКУПОК

5.3.17. УПРАВЛЕНИЕ ЗАКУПКАМИ

5.3.18. УПРАВЛЕНИЕ ОЖИДАНИЯМИ ЗАИНТЕРЕСОВАННЫХ СТОРОН. УПРАВЛЕНИЕ

ЗАИНТЕРЕСОВАННЫМИ СТОРОНАМИ

5.3.19. ПРОЦЕСС УПРАВЛЕНИЯ ИСПОЛНЕНИЕМ ПРОЕКТА (А3)

В ПРОЕКТНОЙ ОРГАНИЗАЦИИ

5.4. ГРУППА ПРОЦЕССОВ ЗАВЕРШЕНИЯ

5.4.1. ПРОЦЕСС ЗАВЕРШЕНИЯ ПРОЕКТА ИЛИ ФАЗЫ

5.4.2. ЗАКРЫТИЕ ЗАКУПОК

5.4.3. ПРОЦЕСС ЗАВЕРШЕНИЯ ПРОЕКТА (А4) В ПРОЕКТНОЙ ОРГАНИЗАЦИИ....... 5.5. ЗАКЛЮЧИТЕЛЬНЫЕ ЗАМЕЧАНИЯ

6. ПРОЦЕССЫ УПРАВЛЕНИЯ ПОРТФЕЛЕМ ПРОЕКТОВ

6.1. ГРУППЫ ПРОЦЕССОВ ОПРЕДЕЛЕНИЯ И ВЫРАВНИВАНИЯ

6.1.1. «СТРАТЕГИЧЕСКИЕ» ПРОЦЕССЫ

6.1.1. РАЗРАБОТКА ПЛАНА УПРАВЛЕНИЯ. ОПРЕДЕЛЕНИЕ ПОРТФЕЛЯ

6.1.2. ОПТИМИЗАЦИЯ ПОРТФЕЛЯ

6.1.3. РАЗРАБОТКА ПЛАНА УПРАВЛЕНИЯ ИСПОЛНЕНИЕМ ПОРТФЕЛЯ.

ОТЧЕТНОСТЬ ПО ПОРТФЕЛЮ

6.1.4. РАЗРАБОТКА ПЛАНА УПРАВЛЕНИЯ КОММУНИКАЦИЯМИ ПОРТФЕЛЯ.

УПРАВЛЕНИЕ ИНФОРМАЦИЕЙ ПОРТФЕЛЯ

6.1.5. РАЗРАБОТКА ПЛАНА УПРАВЛЕНИЯ РИСКАМИ ПОРТФЕЛЯ. УПРАВЛЕНИЕ

РИСКАМИ ПОРТФЕЛЯ

6.1.6. УПРАВЛЕНИЕ СПРОСОМ И ПРЕДЛОЖЕНИЕМ. УПРАВЛЕНИЕ ЦЕННОСТЬЮ

ПОРТФЕЛЯ

6.1.7. ПРОЦЕССЫ УПРАВЛЕНИЯ ПОРТФЕЛЕМ ПРОЕКТОВ В ПРОЕКТНОЙ

ОРГАНИЗАЦИИ

6.1.8. ПРОЦЕСС ПЛАНИРОВАНИЯ ПОРТФЕЛЯ (ПРОЦЕСС В)

6.1.9. ОТЧЕТНОСТЬ ПО ПОРТФЕЛЮ (ПРОЦЕСС С)

6.2. ГРУППА ПРОЦЕССОВ АВТОРИЗАЦИИ И КОНТРОЛЯ

6.3. КАЧЕСТВО УПРАВЛЕНИЯ ПОРТФЕЛЕМ

7. ВЗАИМОДЕЙСТВИЕ ПРОЦЕССОВ УПРАВЛЕНИЯ В ПРОЕКТНОЙ ОРГАНИЗАЦИИ

8. НОВЫЕ ФОРМЫ ОРГАНИЗАЦИИ ПРОЕКТИРОВАНИЯ

8.1. СЛИЯНИЕ СТРОИТЕЛЬНЫХ И ПРОЕКТНЫХ ОРГАНИЗАЦИЙ

8.2. УЧАСТИЕ ФРИЛАНСЕРОВ В ПРОЕКТИРОВАНИИ

9. ЗАКЛЮЧЕНИЕ

ЛИТЕРАТУРА

ПРЕДИСЛОВИЕ АВТОРОВ

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

Во-первых, это знакомство и сотрудничество с (к сожалению, покойным) профессором МГСУ, д.т.н. И.П.Беляевым, который сумел привить авторам аналитический подход к управленческим процессам. Он же вооружил нас наглядным и понятным инструментом описания управленческих процессов – ПОСТ-нотацией. Во-вторых, это внимательное изучение мировых стандартов управления проектной деятельностью, прежде всего – наиболее распространенных в мире стандартов PMI (Project Management Institute) и нового стандарта ISO 21500:2012.

Еще одним источником, значительно обогатившим наши представления о методах управления портфелем проектов, стали две книги А.С.Козлова [3],[4], вышедшие в 2009 и 2010 гг. в издательстве «Проектная практика». Эти книги помогли нам систематизировать подходы к управлению портфелем проектов в практике проектных организаций и, в конечном счете, классифицировать системы управления разработкой проектной документации, дали понимание преимуществ и недостатков сложившихся систем.

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

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

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

Усилия по автоматизации разработки проектной документации насчитывают уже без малого полвека. Они начались во второй половине 60-х годов XX века, с появлением в крупнейших проектных организациях СССР «больших» машин (Минск-22, Минск-32, БЭСМ-2М, позднее – ЕС ЭВМ) и первоначально концентрировались на сложных инженерных расчетах, затем – на расчетах смет. В последние 20 – 25 лет, с появлением и широким распространением персональных компьютеров и сетевых технологий, бурно развивается машинная графика в сочетании с базами данных. К настоящему времени процесс разработки проектной документации достиг высокого уровня автоматизации;

коренным образом изменился он сам, изменились и лежащие в его основе информационные технологии.

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

Между тем в мире копился и систематизировался опыт управления проектами.

Первым обобщением этого опыта явилось «Руководство к своду знаний по управлению проектами» (Руководство РМВОК) [1], выпущенное в 1996 г. Project Management Institute (основан в 1969 г.) после нескольких циклов публикаций различных докладов и дискуссий по ним. С тех пор это руководство вышло уже пятым изданием (2013 г.) и приобрело фактический статус мирового стандарта по управлению проектами, несмотря на то, что многие страны разработали и утвердили свои национальные стандарты, впрочем, во многом похожие на РМВОК.

Следующий серьезный шаг к мировой стандартизации процессов управления проектами предприняла ISO – международная организация по стандартизации, выпустившая в 2012 г. стандарт ISO 21500, утвержденный США, Евросоюзом и Россией [5]. Этот стандарт наследует схему процессов РМВОК, которую PMI добровольно передал ISO.

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

Вопрос первый: применимы ли к сфере их деятельности процессы управления проектами, описанные в вышеупомянутых документах? Если да, то - в какой мере?

Вопрос второй: какие особенности их сферы деятельности и каким образом отражаются на процессах управления проектами?

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

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

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

Рассмотрим, как определено понятие «проект» в стандартах. РМВОК (цитируем по четвертому изданию): «Проект – это временное предприятие, предназначенное для создания уникальных продуктов, услуг или результатов». Ключевое слово здесь – «уникальных». Результатом работы проектной организации является комплект документации на объект строительства. Насколько он уникален? Ровно настолько же, насколько уникален сам будущий объект. Является ли процесс создания этого комплекта документации временным предприятием? Безусловно.

Ситуация несколько меняется, если посмотреть в стандарт ISO 21500:2012. Здесь проект определен так: «Проект состоит из уникального набора процессов, включающих координированные и контролируемые операции с датой начала и завершения, предпринимаемые для достижения цели». Как видим, здесь уникальность относится уже не к результату, а к процессам; результатом же является достижение цели. Иначе говоря, это определение только расширяет понятие проекта; если, например, применение (привязка) типового проекта согласно определению РМВОК могло лишь с большой натяжкой трактоваться как проект, то здесь привязка типового проекта – лишь один из способов достижения цели. А упоминание дат начала и завершения уже само по себе говорит о проекте как о временном предприятии.

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

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

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

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

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

В «Руководстве РМВОК» в главе 3 читаем:

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

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

Менеджеры проектов и их команды должны тщательно исследовать каждый процесс и присущие ему входы и выходы…. Такие действия называются адаптацией.»

Аналогичные идеи звучат и в ISO 21500:2012:

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

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

Кстати, в приложении D к Руководству РМВОК прямо указано на необходимость учета особенностей прикладных областей при использовании методов проектного менеджмента. Там даже прямо предлагается разрабатывать дополнения к РМВОК, и разработка таких дополнений оговаривается определенными процедурами, принятыми в PMI. Однако практика и традиции разработки проектной документации и управления такой разработкой в России имеют определенные особенности. Эти особенности таковы, что если на основе российской практики разработать подобное дополнение, то вряд ли оно было бы применимо в общемировой практике. Поэтому мы и не ставим перед собой задачу создать такое приложение, которое было бы принято PMI. Однако мы считаем, что адаптировать положения РМВОК и стандарта ISO 21500 к условиям деятельности российских проектных организаций необходимо – во избежание тщетных усилий их руководителей следовать рекомендациям этих документов буквально, не считаясь с российскими особенностями своего вида деятельности.

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

Так, в профессиональном стандарте «Архитектурно-строительное проектирование» среди необходимых умений руководителя проектной организации значится и такое:

«Организовывать и осуществлять программно-проектные модели организации работ на предприятии». Аналогичные требования предъявляются и к ГИПам: «Применять программно-проектный подход в системе организации и управления работами».

Кроме того, в России есть свои национальные стандарты управления проектами – ГОСТ Р 54869-2011 и ГОСТ Р 54870-2011. По структуре эти стандарты похожи на стандарты PMI, однако они содержат требования только к результатам процессов, а не к самим процессам. Поэтому в нашем анализе от них было бы немного пользы.

Таким образом, перед нами стоит задача – построить «мост» между положениями стандартов проектного менеджмента и практикой управления разработкой проектной документации. Поэтому - кладем перед собой (или ставим на экран) руководство РМВОК и стандарт ISO21500:2012, берем на вооружение свой опыт анализа систем управления в проектных организациях – и вперед… Проектный менеджмент в проектной организации

2. ОСОБЕННОСТИ ПРОЦЕССА РАЗРАБОТКИ ПРОЕКТНОЙ

ДОКУМЕНТАЦИИ

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

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

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

- он направлен на получение уникального результата – проектная документация уникальна в меру того, насколько уникален сам проектируемый объект. И даже, если, в соответствии с определением в стандарте ISO 21500:2012, рассматривать как признак проектной деятельности достижение результата – готовая проектная документация для проектной организации есть результат производственного процесса.

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

Действительно, в п.1.2 РМВОК читаем:

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

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

Однако это не так. В дальнейшем изложении будем под словом «проект»

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

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

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

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

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

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

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

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

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

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

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

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

4. Разработка проектной документации – во многом случайный процесс.

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

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

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

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

Проектный менеджмент в проектной организации Проектный менеджмент в проектной организации

3. ОСОБЕННОСТИ УПРАВЛЕНИЯ РАЗРАБОТКОЙ

ПРОЕКТНОЙ ДОКУМЕНТАЦИИ

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

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

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

Поэтому рассматривать специально особенности управления программами проектов в наших условиях нет необходимости.

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

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

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

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

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

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

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

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

Эта особенность очень важна, поскольку «Стандарт управления портфелями рассматривает портфель как «набор проектов… или иных работ, объединенных вместе… для достижения стратегических целей бизнеса». Получается, что портфель не является основной деятельностью организации, а служит развитию или совершенствованию основной деятельности. Более того, во многих местах прямо говорится об инвестиционном характере проектов, т.е. речь идет об инвестициях самой организации в ее развитие, а не о выполнении проектов для сторонних заказчиков. Это различие в роли портфеля иллюстрирует рис. 3.2, где в одном случае портфель служит средством совершенствования основной операционной деятельности, а в другом – сам является основной деятельностью.

4. Масштаб проектов, входящих в портфель проектов, который выполняет проектная организация, как правило, относительно невелик. Это следует из того обстоятельства, что жизненный цикл проекта в проектной организации является достаточно малой частью жизненного цикла строительства объекта, который, в свою очередь, является небольшой частью жизненного цикла самого проектируемого объекта (рис.1.1). Действительно, ни по объемам работ (в среднем 5 – 10% от объема строительных работ), ни по длительности (как правило, несколько месяцев, редко – 1 - года) проекты в проектной организации не могут сравниться по масштабу с такими проектами, опыт управления которыми лежит в основе положений проектного менеджмента. Это обстоятельство важно иметь в виду, когда речь идет о трудозатратах на процессы управления проектами в проектной организации. В частности, нередко в команду управления проектом, которая управляет выполнением работ по определенному проекту, входит только ГИП. По той же причине не должна быть чрезмерной степень детализации работ, используемая в управлении. Кроме того, именно масштаб проектов Проектный менеджмент в проектной организации позволяет рассматривать программу проектов как единый большой проект, о чем говорилось выше.

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

привлекаются дополнительные ресурсы. Это обеспечивается как путем набора временных сотрудников, так и путем передачи части объемов работ на субподряд.

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

Это обстоятельство позволяет уяснить, почему использование универсальных систем управления проектами (Microsoft Project, Primavera, Spider и т.д.) редко бывает Проектный менеджмент в проектной организации успешным в проектных организациях. Действительно, они избыточны для целей управления отдельными проектами, но их версии, предназначенные для управления портфелями проектов, чрезвычайно дороги и требуют достаточно сложной адаптации к реалиям проектных организаций.

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

Проектный менеджмент в проектной организации 4. ПРЕЖДЕ ЧЕМ СТРОИТЬ МОСТ… Напомним, что нашей задачей является построение «моста» между практикой управления разработкой проектной документации в проектных организациях и процессами проектного менеджмента. Выше мы выявили особенности процессов управления в проектных организациях. Теперь можно анализировать эти процессы с точки зрения выполнения требований стандартов PMI и/или ISO 21500. Для этого надо описать эти процессы.

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

Действительно, документы СМК подлежат утверждению, они подвергаются аудиту (в том числе внешнему). Если при этом аудит исследует соответствие описаний не только стандартам ИСО9001:2008, но и стандартам проектного менеджмента, с учетом особенностей сферы деятельности – это логичный путь совершенствования проектного управления в организации.

Выполняя сравнение процессов РМВОК и ISO 21500 с реальными процессами, протекающими в проектных организациях, необходимо учитывать ряд принципиальных моментов, свойственных структуре процессов в РМВОК.

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

Более того, опыт управления разработкой проектной документации свидетельствует о том, что в этой сфере деятельности группы процессов «организация и контроль» и «мониторинг и управление» (эти группы процессов в стандарте ISO называются соответственно «Исполнение» и «Управление») практически неразделимы.

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

При рассмотрении входящих в эти группы процессов РМВОК мы в этом убедимся.

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

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

Проблема облегчается тем, что стандарт ISO имеет множество параллелей с РМВОК именно пятого издания.

4.3. СРЕДСТВА ОПИСАНИЯ ПРОЦЕССОВ. ПОСТ-НОТАЦИЯ

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

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

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

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

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

Существуют и средства автоматизации, обеспечивающие разработку и поддержку диаграмм процессов в методологии IDEF, например, Bpwin.

Среди других методологий можно отметить ARIS (Architecture of Integrated Information System) компании IDS Sheer, объединяющую описания различных аспектов функционирования систем, в частности, выполняемых ими процессов, в виде единых диаграмм.

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

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

В основе ПОСТ-нотации лежат всего пять графических элементов (табл. 4.1).

Пример описания процесса с помощью ПОСТ-нотации показан на рисунке 4.1. В левой части рамки диаграммы расположены входные документы процесса, необходимые для его выполнения, а в правой части - выходные документы. Заметим, что это могут быть как измененные входные документы (например, утвержденные), так и созданные “с нуля” в результате выполнения процедур процесса. Содержание диаграммы представляет собой описание процесса, при выполнении которого на основе входных документов создаются выходные.

Для увязки элементов диаграммы в единую технологию применяют линии связи.

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

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

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

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

- буквенное обозначение процесса;

- порядковый номер диаграммы в схеме процесса на верхнем уровне;

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

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

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

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

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

В последующих схемах и таблицах используются следующие обозначения:

ОУП – офис управления портфелем проектов;

ГИП –главный инженер проекта;

AT – адиминистратор Timesheet;

РП – руководство подразделения;

ГМ – главный менеджер (руководитель, непосредственно управляющий производственным процессом);

ДИС – диспетчер (как правило – сотрудник ОУП);

С – сотрудник производственного подразделения.

Обозначения процессов построим следующим образом: процессы управления проектами будем обозначать буквой А с последовательными номерами (А1, А2, А3…), а процессы управления портфелем проектов – последующими латинскими буквами (В, С, D и т.д.).

Проектный менеджмент в проектной организации

5. ПРОЦЕССЫ УПРАВЛЕНИЯ ПРОЕКТАМИ

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

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

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

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

1) в одно и то же время выполняется несколько таких процессов (в этом – суть управления портфелем проектов);

2) процессы управления проектами не имеют жесткой привязки к календарю.

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

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

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

Группы и функции процессов. Проектный менеджмент (PMBОK, 4-е издание, а также ISO 21500) рассматривает пять основных групп процессов управления проектом:

- планирование;

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

- мониторинг и управление (управление);

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

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

Кратко опишем эти функции применительно к нашей сфере деятельности.

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

Заинтересованные стороны (в четвертом издании РМВОК этой функции нет, ее процессы распределены по другим функциям) – вопросы взаимодействия с внешними участниками проекта (заказчиком, инвестором и т.д.).

Управление содержанием – процессы и процедуры, направленные на включение в проект всех необходимых составных частей, т.е. на выполнение требований к составу проектной документации.

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

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

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

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

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

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

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

Состав функций и групп процессов приведен на рис. 5.1.

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

1. Проектная организация постоянно имеет дело с портфелем проектов.

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

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

3. На распределение функций (точнее – на соотношение функций, выполняемых командой управления проектом, и централизуемых функций) существенно влияет структура проектной организации.

Это последнее обстоятельство заслуживает более серьезного рассмотрения.

Производственные подразделения в проектных организациях формируются по одному из двух характерных типов. Будем называть эти типы «функциональный отдел отдел» и «мастерская» соответственно.

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

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

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

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

При структуре мастерских (эта структура в РМВОК называется «проектной») каждый проект целиком или почти целиком выполняется в пределах одной мастерской. В этом случае координация работ замыкается внутри мастерской, а функции ГИПа выполняет либо начальник мастерской, либо один из высококвалифицированных сотрудников той же мастерской.

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

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

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

эти функции выполняют руководители и ведущие специалисты комплексных отделов.

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

Иначе говоря, изменение положения и функций ГИПов, как правило, следуют за изменением структуры производственных подразделений (рис. 5.2). На этом рисунке красным цветом показано название соответствующей структуры, принятое в РМВОК.

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

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

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

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

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

При структуре мастерских картина несколько иная (рис. 5.4).. Здесь практически все участники проекта – сотрудники одной мастерской, поэтому участников команды управления проектом можно перечислить. Поэтому в этом случае можно говорить о команде управления проектом. Однако это не столько команда управленцев – то, что подразумевается под командой управления проектом в РМВОК, - сколько совокупность участников проекта.

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

При структуре функциональных отделов распределение функций примерно таково (табл. 5.1):

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

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

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

5.1. ГРУППА ПРОЦЕССОВ ИНИЦИАЦИИ В эту группу, согласно РМВОК, входят два процесса:

- разработка Устава проекта;

- определение заинтересованных сторон проекта.

В стандарте ISO 21500 к этим процессам добавляется еще один – создание команды проекта.

Этот процесс относится к функции «Управление интеграцией».

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

Результатом этого процесса, как следует из РМВОК, является документ, который содержит следующую информацию:

1. Описание работ по проекту (в нашем случае – основные характеристики объекта проектирования). Эта информация содержится обычно в задании на проектирование – составной части договора на выполнение проектных работ;

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

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

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

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

5. Активы процессов организации. Естественно, что эти активы также являются едиными для всех проектов, выполняемых проектной организацией. Поэтому они описаны в корпоративных стандартах, положениях, приказах и других внутренних документах организации.

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

5.1.2. ОПРЕДЕЛЕНИЕ ЗАИНТЕРЕСОВАННЫХ СТОРОН ПРОЕКТА

Этот процесс относится к функции «Заинтересованные стороны», хотя еще в четвертом издании РМВОК этой функции еще не было, и процесс входил в функцию «Управление интеграцией».

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

5.1.3. СОЗДАНИЕ КОМАНДЫ ПРОЕКТА С точки зрения РМВОК этот процесс является составной частью предыдущегог процесса. В ISO 21500 он фигурирует отдельно. Важнейшим для нас содержанием этого процесса является назначение менеджера проекта, т.е. главного инженера проекта.

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

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

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

- знания (в том числе в области управления проектами);

- результативность (способность достигать результата в своей деятельности);

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

Подробно требования к личным качествам менеджеров изложены в приложении G к РМВОК, и особенности вида деятельности, за исключением, возможно, масштаба проектов, здесь практически никакого влияния не оказывают.

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

- выигрышем в конкурсе или тендере (а еще ранее – своим участием в них);

- появлением заявки (предложения) от заказчика;

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

Соответственно можно рассматривать три варианта процесса (рис. 5.5, 5.6, 5.7).

Во всех трех схемах процедура назначения ГИПа не указана.

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

Основные процедуры. Рассмотрение схем процессов показывает, что в каждой из них есть только одна процедура, которая является содержательной и требует детализации по уровням иерархии. Это процедуры «Подготовка и подача заявки на участие» (РА1. в варианте «Участие в конкурсе»), «Подготовка договорной документации» (РА1.2 в варианте «Заявка заказчика») и «Подготовка соглашения» (РА1.1 в варианте «Распоряжение вышестоящей организации»). Содержание этих процедур может быть очень разнообразно. В них может входить или не входить сбор исходно-разрешительной документации, формирование таких документов, как сметы на проектные и изыскательские работы, календарный план выполнения работ, а также самого текста договора.

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

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

5.2. ГРУППА ПРОЦЕССОВ ПЛАНИРОВАНИЯ

Эта группа в РМВОК состоит из 24 процессов, в ISO 21500 – из 16. Их распределение по функциям приведено в таблице 5.3.

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

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

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

Опишем теперь перечисленные процессы из РМВОК (с некоторой «оглядкой» на ISO 21500), рассматривая их особенности применительно к нашему виду деятельности.

Проектный менеджмент в проектной организации Проектный менеджмент в проектной организации Проектный менеджмент в проектной организации Проектный менеджмент в проектной организации Управление интеграцией Разработка плана управления проектом Разработка плана управления проектом Управление содержанием Разработка плана управления содержанием * Определение содержания Управление ресурсами Разработка плана управления человеческими Оценка ресурсов Управление сроками Разработка плана управления сроками * Определение последовательности операций Управление стоимостью Разработка плана управления стоимостью * Оценка стоимости коммуникациями Управление рисками Планирование управления рисками Определение рисков Управление закупками Планирование управления закупками Планирование закупок Заинтересованные План работы с заинтересованными сторонами стороны * В четвертом издании РМВОК эти процессы входили в состав процесса «Разработка плана управления проектом».

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

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

Состав проектной документации в полном объеме определяется Постановлением Правительства РФ №87 от 16.02.2008 «О составе разделов проектной документации и требованиях к их содержанию» (с последующими изменениями); состав рабочей документации в общем виде описан в ГОСТ 21.101-97, п.3. В том случае, когда организация выполняет неполный состав проектной документации, ГИП должен оговорить необходимость выпуска соответствующего набора документов. При наличии в организации системы технического электронного документооборота состав будущей проектной документации формируется ее средствами и служит своего рода каркасом, который в дальнейшем детализируется и наполняется соответствующими документами.

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

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

Согласно РМВОК, сбор требований состоит в определении и документировании потребностей инвестора и заказчика проектной документации. В условиях нашего вида деятельности эти потребности зафиксированы в задании на проектирование, которое является приложением к договору на выполнение проектных работ, а также в технических Проектный менеджмент в проектной организации условиях и других видах исходно-разрешительной документации. Поэтому этот процесс является составной частью процесса инициации проекта (А1), вне зависимости от его варианта. В этой связи не случаен тот факт, что в составе процессов этой группы по ISO 21500 этот процесс отсутствует.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Любопытно, что процесс «Определение операций», отнесенный в РМВОК к функции «Управление сроками», в ISO 21500 относится к группе «Управление содержанием» (под названием «Определение состава работ»), что представляется логичным.

5.2.6. ОПРЕДЕЛЕНИЕ ПОСЛЕДОВАТЕЛЬНОСТИ ОПЕРАЦИЙ

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

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

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

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

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

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

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

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

Поэтому потребные ресурсы определяются на основе косвенных нормативов:

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

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

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

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

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

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