Каренов Р.С.
Задачи и методы структуризации проектов
Структуризация, суть которой сводится к разбивке проекта на иерархические подсистемы и компоненты, необходима для того, чтобы проектом можно было управлять.В терминах управления проектами структура представляет собой «дерево» ориентированных на продукт компонентов, представленных оборудованием, работами, услугами и информацией, полученными в результате реализации проекта.
Структура проекта призвана определить продукцию, которую необходимо разработать или произвести, и связывает элементы работы,
которые предстоит выполнить, — как между собой, так и с конечной
целью проекта [1; 98].
Суть структуризации проекта (WBS – Work Breakdown Structure) состоит в следующем: проект делится на поддающиеся управлению элементы работ, для которых легко определить затраты и построить графики исполнения. Должным образом подготовленная и составленная структура проекта должна удовлетворять требованиям менеджера проекта и заказчика. Структуризация проекта помогает менеджеру наделить участников проекта ответственностью за выполнение конкретных технических заданий. Она также позволяет создать простую систему отслеживания хода реализации проекта [2; 56].
Формирование структуры начинается с разделения целей проекта на значительно меньшие блоки работ вплоть до достижения самых мелких позиций, подлежащих контролю. Такая древообразная структура позволяет разбить общий объем работ по проекту на поддающиеся управлению независимые блоки, которые будут переданы под управление отдельных специалистов, несущих ответственность за их завершение. Таким образом, устанавливается логическая связь между ресурсами компании и объемами работ, которые предстоит осуществить.
Основные задачи структуризации проекта
Применительно к реальным проектам структура разбивки проекта (рис. 1) должна сочетать разделение на: компоненты продукции; этапы жизненного цикла проекта; элементы организационной структуры.
Рисунок 1 – Структура разбивки применительно к реальным проектам
(Примечание – данные работы [2; 58])
Осуществление процесса структуризации проекта относительно легче применительно к так называемым «осязаемым проектам», связанным, к примеру, со строительством, нежели к проектам, связанным, например, с разработкой программного обеспечения.
Основными задачами структуризации проекта являются следующие [1; 98]:
– разбивка проекта на поддающиеся управлению блоки;
– распределение ответственности за различные элементы проекта и увязка работ со структурой организации (ресурсами);
– точная оценка необходимых затрат – средств, времени и материальных ресурсов;
– создание единой базы для планирования, составления смет и контроля за затратами;
– увязка работ по проекту с системой ведения бухгалтерских счетов в компании;
– переход от общих, не всегда конкретно выражаемых, целей к
определенным знаниям, выполняемым подразделениями компании;
– определение комплексов работ/подрядов.
При структуризации проектов часто допускаются разнообразные ошибки. Наиболее типичными являются следующие ошибки [2; 59]:
– пропуск «неосязаемых» конечных продуктов, таких как услуги, информационное или программное обеспечение;
– такой вариант структуризации проекта, результаты которого
невозможно обработать на компьютере;
– излишняя или недостаточная детализация разрабатываемых структур;
– отсутствие интеграции структуры проекта с системой ведения бухгалтерских счетов;
– повторение одних и тех же элементов структуры;
– непонимание того, что структура проекта должна охватывать весь его жизненный цикл (как правило, пропуск начальной и конечной фаз проекта);
– использование в качестве основы структуризации только
функциональных областей или фаз проекта, либо организационных подразделений компании, вместо ориентации на конечные продукты или используемые проектом ресурсы;
– пропуск стадии структуризации проекта и попытки непосредственного перехода к анализу и решению проблем реализации проекта.
Стандартные шаги при структуризации проекта
Процесс структуризации проекта может быть представлен в виде последовательности действий, осуществляемых поэтапно. Эта последовательность имеет следующий вид [2; 65 - 68]:
1. Определение целей проекта. Должны быть четко определены характер, цели и содержание проекта, а также все конечные продукты проекта с их точными характеристиками. В данной ситуации очень полезно использовать иерархию целей, показывающую полную цепь конечных результатов и средств их достижения.
2. Нахождение необходимого уровня детализации проекта. Нужно обдумать различные уровни детализации планов и количество уровней элементов в структуре разбивки проекта.
3. Разработка структурных схем проекта. Процесс разработки структурных схем проекта может быть представлен в виде набора действий, выполняемых параллельно. Последовательность таких действий имеет следующий вид:
) изучение структуры процесса (этапов жизненного цикла). Должна быть подготовлена схема жизненного цикла проекта;
) изучение организационной структуры проекта (окружение проекта, участники, распределение ответственности). Организационная схема проекта должна охватывать все группы или отдельных лиц, которые будут работать на проект, включая лиц, заинтересованных в проекте, из внешнего окружения проекта;
) анализ структуры продукции (как проекта в целом, так и его подсистем и компонентов). Структура продукта – это схема разбивки по подсистемам или компонентам, включая машины и оборудование, программное и информационное обеспечение, услуги, а также, если это важно, географическое распределение;
) анализ системы бухгалтерских счетов компании. План бухгалтерских счетов в организации – это система кодов, применяемых при структурировании проекта; должна основываться на существующем в организации плане бухгалтерских счетов или на возможности его корректировки.
4. Построение единой структуры проекта. Единая структура проекта объединяет в себе структуру процесса, организационную структуру и план бухгалтерских счетов.
5. Подготовка генерализованных (общих) планов управления проектом. Процесс подготовки генерализованных (общих) планов управления проектом может быть представлен в виде набора действий, выполняемых параллельно. Последовательность таких действий имеет следующий вид:
) подготовка сводного плана проекта. Генеральный сводный план проекта может быть в дальнейшем детализирован в процессе поиска критического пути. В ходе реализации проекта сводный план может использоваться для докладов высшему руководству;
) подготовка матрицы распределения ответственности. В результате анализа взаимоотношений между элементами структуры проекта и организацией строится матрица, где элементы структуры проекта становятся строками, а элементы схемы организации компании – столбцами (или наоборот). В ячейках матрицы уровни ответственности тех или иных действующих лиц обозначают при помощи различных условных обозначений или кодов;
) разработка системы бухгалтерской разбивки проекта, соответствующей принятому в компании плану счетов. В рабочем плане бухгалтерских счетов при необходимости следует проработать систему субсчетов, «стыкующихся» с основным планом счетов.
6. Составление детальных планов реализации проекта. Процесс подготовка детальных планов управления проектом может быть представлен в виде набора действий, выполняемых параллельно. Последовательность таких действий имеет следующий вид:
) подготовка детального сетевого графика и плана использования ресурсов. Разработка детализированного сетевого графика включает в себя выполнение временных и ресурсных оценок по каждой из работ;
) разработка системы наряд-заданий. Система наряд-заданий вытекает из предварительной структуры разбивки проекта и матрицы распределения ответственности. На этом этапе задания должны быть абсолютно конкретны во времени и ресурсах;
) установление системы отчетности и контроля. Контроль за ходом работ осуществляется на протяжении всего цикла выполнения проекта. Периодичность контроля обычно определяется менеджером проекта и зависит от продолжительности проекта.
Методы структуризации проекта
Методы структуризации проекта принципиально сводятся к двум основным типам [1; 100]:
) метод «сверху-вниз» – определяются общие задачи, на основе которых далее осуществляется детализация уровней проекта;
) метод «снизу-вверх» – определяются частные задачи, а затем происходит их обобщение.
Для структуризации проекта используют ряд специальных моделей, как-то:
1. Дерево целей и результатов - первая по времени разработки структурная модель декомпозиции цели проекта на составные части. Дерево целей можно построить в соответствии со структурой проекта. В вершине дерева ставится общая (генеральная) цель, на последующих ярусах ветвей располагаются в иерархической соподчиненности декомпозированные цели соответствующего уровня, вплоть до целей самого нижнего уровня, соответствующих элементарным мероприятиям и действиям в проекте.
2. Дерево задач – разработка структурной модели проекта по декомпозиции задач проекта на составные части. Состав задач проекта определяется из целей проекта, конечного результата и предпроектного состояния предметной составляющей проекта – продукта, бизнес-функции или услуги. Системный подход в определении задач проекта аналогичен подходу в определении целей, используя технологии иерархических декомпозиций в виде дерева. В вершине «дерева» располагается сверхзадача проекта, в основании – элементарные задачи (работы, мероприятия) нижнего уровня. Такие методики – разбиение проекта на более мелкие задачи – позволяют представить его в виде вполне управляемых компонентов [4; 168 - 169].
3. Дерево работ. На каждой стадии планирования необходимо разделить работы по проекту на части. Например, на стадии технического проектирования основные части проекта, как правило, очевидны. В дальнейшем, когда станет известно больше деталей, эти части могут быть расчленены на соответствующие разделы. Наконец, могут быть определены подразделы и отдельные группы («пакеты») работ. Эта процедура, как указывалось выше, известна как составление дерева работ проекта (WBS – Work Breakdown Structure). Такое дерево является средством расчленения большого, сложного проекта на его компоненты или хозяйственной программы на составляющие проекта.
По мере получения дополнительной информации на последующих стадиях проектирования плановик может добавить новые уровни к дереву работ проекта. Нижний уровень дерева соответствует пакетам работ. Это – последние элементы подразделов, за которые ответственны подрядчик или соответствующий отдел организации-заказчика. Пакет работ не следует отделять от других работ проекта, но связи этого пакета с остальной частью проекта должны быть четкими. Эти связи не следует усложнять настолько, чтобы затруднялась координация.
Пакет работ является также самостоятельной финансовой единицей. Он должен иметь отдельную смету, бюджет и отчет о расходах. Вычленение пакетов работ представляет большое удобство при разработке сетевого графика проекта. Гораздо легче планировать отдельные пакеты и затем собирать сетевой график проекта из фрагментов, нежели разрабатывать сетевой график в целом без дерева работ проекта [2; 69].
Кроме того, WBS служит и другой важной цели, а именно разработке структурной схемы для административного управления проектом. Таким образом, разделение проекта на пакеты работ удовлетворяет двум задачам: планирования и оперативного управления. Поэтому одновременно с WBS необходимо развивать организационно-административное дерево и увязывать его структурные единицы с пакетами работ. Отсюда станет ясной степень пригодности разработанного дерева WBS.
Структурная модель проекта по фазам
жизненного цикла
Основные подходы к построению структурной модели проекта таковы [4; 169 - 170]:
1. Структурная модель организации проекта (организационная структура исполнителей или проектный офис), представляющая иерархическую декомпозицию организационной и производственной структуры проекта.
Для обеспечения эффективного управления проектом при разработке проекта необходимо:
) учесть в плане все разделы, этапы и работы проекта;
) учесть в плане все организации, участвующие в проекте;
) обеспечить действенность управления путем распределения ответственности.
Первое требование может быть удовлетворено разбивкой проекта на пакеты работ с помощью WBS. Для выполнения последних двух требований плановик должен указать, какая организация ответственна за каждый пакет или уровень дерева работ. Другими словами, он должен четко определить уровни и объемы ответственности в организационной структуре. Это может быть сделано с помощью схемы организационной структуры проекта (OBS – Organisation Breakdown Structure).
В этой схеме руководитель проекта находится на ее верхнем уровне, а на более низких уровнях последовательно располагаются отделы, требуемые для функционального управления работами. Эти уровни иногда соответствуют уровням WBS. Например, отдел главного энергетика будет ответственным за пакет работ «Линии электропередачи».
Цель OBS состоит в указании не только исполнителей работ для каждого пакета, но и в определении отделов организаций, ответственных за выполнение соответствующих работ.
2. Матрица ответственности связывает пакеты работ с организациями-исполнителями на основе WBS и OBS. В матрице ответственности определяются основные исполнители по пакетам работ.
3. Сетевые модели. По мере продвижения работы над проектом создаются деревья WBS и OBS, т. е. выделяются пакеты работ с назначенными для них исполнителями, что дает возможность подготавливать сетевой график узловых событий. Наконец, становится возможным разработать детальные сетевые графики, соответствующие узловым событиям и целям. Поскольку эти сетевые графики представляют не проект в целом, а его отдельные пакеты работ, они называются сетевыми блоками или подсетями. Если работа по нескольким взаимозависимым пакетам осуществляется одновременно, причем для каждого из них требуется разработать отдельное расписание, то каждый пакет представляется отдельной подсетью.
Подсеть может составлять часть сетевого графика либо быть автономной. Расчленение сетевого графика на подсети позволяет персоналу, ответственному за проект, концентрироваться на своих собственных работах. Каждый руководитель на своем уровне может вести работу независимо от других в соответствии со своей подсетью, что освобождает его от необходимости иметь дело с полным сетевым графиком. Для руководства разделение проекта на подсети обеспечивает возможность эффективного контроля. Оно может в целях экономии времени уделять больше внимания управлению наиболее важными (критическими) подсетями, вместо того чтобы постоянно контролировать весь сетевой график. Таким образом, структура, выявленная при создании WBS, OBS и сетевого графика узловых событий, сохраняется и при разработке подсетей. Важное значение при разработке подсети имеет планирование операций в пределах совокупности узловых событий.
4. Структура потребляемых ресурсов. Для анализа средств, которые необходимы для достижения целей и подцелей проекта, осуществляется структуризация ресурсов различных типов. Иерархически построенный граф фиксирует необходимые на каждом уровне ресурсы для реализации проекта. Например, на первом уровне определяются материально-технические, трудовые и финансовые ресурсы. Затем материально-технические ресурсы дифференцируются на строительные материалы, машины, оборудование. Строительные материалы – на складируемые и нескладируемые и т. д.
5. Структура затрат. Методика структуризации затрат аналогична используемой в процессе разработки структуры потребляемых ресурсов.
6. Структурная декомпозиция контрактов по работам проекта.
7. Дерево распределения рисков проектов.
На основе композиции различных структурных и информационных моделей можно построить и другие дополнительные композиционные структурные модели, необходимые для решения задач управления проектом различными его участниками.
Принятая структура проекта с выделенной в ней иерархией устойчивых элементов и образует основу информационного языка проекта, на котором общаются все участники проекта и ведется документирование. Поэтому принятая структура, и только она, должна использоваться на протяжении всего жизненного цикла проекта, хотя сама структура и может претерпеть изменения в ходе выполнения проекта. В этом случае должны быть внесены связанные с этим изменения во всей документации проекта.
Литература:
1. Шеремет В.В., Павлюченко В.М., Шапиро В.Д. и др. Управление инвестициями: В 2 – х томах. Том 1. – М.: Высшая школа, 1998. – 416 с.
2. Проектный менеджмент: Учебно-консультационный курс. – М.: ГУ «МИВТ - Центр»; Лаборатория Базовых Знаний, 2007. – 287 с.
3. Мазур И.И., Шапиро В.Д., Ольдерогге Н.Г. Управление проектами: Учебное пособие. – М.: Омега – Л, 2005. – 664 с.
4. Информационный менеджмент / Под научной редакцией Н.М. Абдикеева. – М.: ИНФРА-М, 2009. – 400 с.