Даже простое перечисление этих процессов свидетельствует о том, что их состав применительно к нашему виду деятельности должен претерпеть существенные изменения. В частности, в условиях портфеля проектов целый ряд процессов регламентируются, а зачастую и выполняются на уровне всего портфеля. Кроме того, поскольку, как мы видели в главе 3, портфель в нашем случае не имеет четко выраженных начала и конца, некоторые процессы планирования фактически относятся к группе инициации проекта и выполняются в составе процесса инициации (А1).
Примечательно, что в четвертом издании РМВОК такие процессы, как «Разработка плана управления содержанием», «Разработка плана управления сроками», «Разработка плана управления стоимостью» входили как части в процесс «Разработка плана управления проектом». Учитывая масштаб наших проектов, нам будет удобнее следовать именно такой структуре процессов.
Опишем теперь перечисленные процессы из РМВОК (с некоторой «оглядкой» на ISO 21500), рассматривая их особенности применительно к нашему виду деятельности.
1. РАЗРАБОТКА ПЛАНА УПРАВЛЕНИЯ ПРОЕКТОМ
План управления проектом, согласно РМВОК, является основным источником информации о том, как будут планироваться и исполняться все шаги в проекте, как будет вестись его мониторинг, управление и завершение. Содержание плана существенно зависит от прикладной области, в которой осуществляется проект.
В практике проектных организаций, учитывая условия портфеля проектов, отдельный документ, который называется планом управления проектом, не разрабатывается. Необходимые положения такого плана (управление исполнением проекта, управление работами проекта, управление изменениями и управление завершением) обычно описаны в корпоративных стандартах организации или системе менеджмента качества. Поэтому в отдельном их описании применительно к конкретному проекту обычно нет надобности. Основные же характеристики будущего проекта, а именно - состав будущей проектной документации (как процесс управления содержанием), график выполнения проекта (как процесс управления расписанием), основные ресурсы, необходимые для выполнения проекта, в том числе стоимостные показатели (управление стоимостью) – описываются в отдельных документах, относящихся к конкретному проекту. Среди таких документов - состав проекта, задание ГИПа участникам проекта, график выполнения проектных работ, распределение объемов работ. Все эти документы разрабатываются (или, по крайней мере, инициируются) ГИПом.
Состав проектной документации в полном объеме определяется Постановлением Правительства РФ №87 от 16.02.2008 «О составе разделов проектной документации и требованиях к их содержанию» (с последующими изменениями); состав рабочей документации в общем виде описан в ГОСТ 21.101-97, п.3. В том случае, когда организация выполняет неполный состав проектной документации, ГИП должен оговорить необходимость выпуска соответствующего набора документов. При наличии в организации системы технического электронного документооборота состав будущей проектной документации формируется ее средствами и служит своего рода каркасом, который в дальнейшем детализируется и наполняется соответствующими документами.
На практике важнейшей частью плана управления проектом является определение состава участников и объемов работ для них. Учитывая деятельность организации в условиях портфеля проектов, объемы работ должны определяться в виде показателей, принятых по всему портфелю. В противном случае как сопоставление проектов между собой, так и суммирование объемов для определения загрузки участников проекта станут невозможными. Кроме того, по той же причине для всех проектов, входящих в портфель, объемы работ должны определяться на одном и том же уровне иерархии (например, отдел, группа, специальность). Эти параметры – показатель и уровень иерархии – должны быть оговорены в соответствующих корпоративных стандартах или документах СМК.
Что касается управления расписанием проекта, то основные опорные позиции такого расписания представляют собой этапы календарного плана, которые сопровождаются выпуском определенной части документации; к срокам их завершения привязываются сроки выполнения отдельных проектных операций и обмена информацией между участниками проекта. Эта часть плана управления проектом находит свое воплощение в графике выполнения проектных работ.
2. СБОР ТРЕБОВАНИЙ
Согласно РМВОК, сбор требований состоит в определении и документировании потребностей инвестора и заказчика проектной документации. В условиях нашего вида деятельности эти потребности зафиксированы в задании на проектирование, которое является приложением к договору на выполнение проектных работ, а также в технических условиях и других видах исходно-разрешительной документации. Поэтому этот процесс является составной частью процесса инициации проекта (А1), вне зависимости от его варианта. В этой связи не случаен тот факт, что в составе процессов этой группы по ISO 21500 этот процесс отсутствует.
3. ОПРЕДЕЛЕНИЕ СОДЕРЖАНИЯ
РМВОК определяет этот процесс как разработку подробного описания проекта и продукта. Как проект (т.е. процесс разработки проектной документации), так и продукт (сама проектная документация) в нашем случае исчерпывающе описаны в задании ГИПа исполнителям (см. 5.2.1). На основе этих данных, а также действующего законодательства в области строительного проектирования, ГИП определяет состав проекта. Первоначально он определяется на уровне разделов и входит в состав первичного задания ГИПа исполнителям. Впоследствии состав каждого раздела уточняется руководителями подразделений (или субподрядчиков), выполняющих разработку соответствующих разделов.
Помимо состава проекта, в процессе определения содержания выявляются ограничения, которые должны быть предъявлены к будущим техническим решениям. Тем самым могут быть уточнены требования, которые были сформулированы при выполнении предыдущего процесса («Сбор требований»), к какой группе бы этот процесс ни был отнесен.
4. СОЗДАНИЕ ИЕРАРХИЧЕСКОЙ СТРУКТУРЫ РАБОТ
Основным методом получения иерархической структуры работ (ИСР) является декомпозиция. РМВОК предлагает два принципа декомпозиции: по фазам проекта (в нашем случае – это стадии проектирования или этапы календарного плана) и по основным результатам; в качестве последних в нашем случае выступают разделы проектной документации. Декомпозиция по фазам, как правило, возникает естественным образом, и набор работ, входящих в каждый этап, можно рассматривать как отдельный проект. Декомпозиция по основным результатам позволяет на верхнем уровне рассматривать совокупность работ, выполняемых для создания одного раздела проектной документации; практически всегда такой набор оказывается работами, выполняемыми одним подразделением. Это удобный способ, потому что он попутно отражает соотношение объемов работ между исполнителями, которое является важным показателем экономики проекта.
Оба принципа декомпозиции в случае сложных (обычно – промышленных или транспортных) объектов могут иметь еще один или даже несколько уровней иерархии. Например, сложный объект может делиться на конструктивные элементы, каждый из которых может в составе необходимой документации иметь различные разделы (например, конструкцию, электрику, автоматику и т.д.). Документация каждого такого элемента может произвольным образом входить в состав отдельных этапов календарного плана и быть одновременно частью общего раздела документации на весь проект. Такое структурирование проекта очень полезно с точки зрения накопления управленческого опыта, выработки необходимых внутренних нормативов для использования в дальнейшем. Однако его довольно трудно совместить со структурированием по фазам проекта, поскольку иерархическая структура оказывается многомерной, что сильно усложняет планирование и управленческий учет.
Декомпозиция работ должна продолжаться до тех пор, пока определение работы на нижней ступени не будет позволять надежную оценку объема и длительности входящих в нее операций. Вместе с тем факт завершения работы должен позволять его однозначную фиксацию и поддаваться контролю.
По вопросу о том, что считать работой, в практике разработки проектной документации существуют разные суждения, и от ответа на него существенным образом зависит построение всей системы управления.
Некоторые специалисты считают единицей работы совокупность действий, обеспечивающих выпуск одного проектного документа. Такой подход можно было бы принять, если бы проектные документы разрабатывались бы строго последовательно: например, приступить к разработке очередного чертежа можно было бы только после того, как закончен предыдущий. На самом деле так не происходит: многие проектные документы разрабатываются параллельно, содержащаяся в них информация вырабатывается постепенно и претерпевает несколько итераций, и измерить степень готовности раздела проекта по количеству готовых проектных документов невозможно. Поэтому такой подход не годится для эффективного управления разработкой проектной документации.
Более приемлемым вариантом структурирования работ следует признать метод, основанный на понятии события. Под событием будем подразумевать момент обмена информацией между участниками проекта, имея в виду группы специалистов разных специальностей. Эти специалисты обычно структурно разделены в проектной организации, возможно также, что часть из них представляют собой субподрядчиков. В частности, событием можно считать выдачу задания ГИПа участникам проекта, а также выпуск готовой проектной документации. В традиционной технологии проектирования событием является момент обмена заданиями между участниками проекта; в случае трехмерного проектирования таким событием является момент предоставления доступа участников в к определенным массивам проектной информации.
У такого подхода есть несколько несомненных достоинств. Во-первых, момент обмена информацией может быть четко зафикисирован, что упрощает мониторинг проекта. Во-вторых, работой в этом случае является совокупность проектных операций, выполняемых специалистами в промежутках между моментами обмена информацией. В-третьих, такое структурирование работ позволяет построить внутренние нормативы их относительной трудоемкости, и это позволяет строить модели разработки проектной документации для объектов определенного типа на определенных стадиях проектирования.
Недостаток у этого подхода только один: среди событий невозможно ввести иерархию – они все одинаково важны, среди них невозможно выделить более или менее важные. Впрочем, один дополнительный уровень иерархии выделить всегда можно: это группа событий, выполняемых одним и тем же подразделением (или субподрядчиком).
Читайте продолжение здесь.
