книги / Управление проектами

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

Подобное разбиение в науке называется декомпозицией работ или иерархической структурой работ (work breakdown structure – WBS).

Согласно PMBOK, WBS – это организационный инст-

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

WBS предоставляет следующие возможности:

–структурированное видение проекта;

–отслеживание хода выполнения проекта;

–формирование проектной команды, так как WBS создается совместными усилиями всех участников проекта;

–получение точных оценок затрат и расписания проекта. По сути, WBS разбивает всю работу проекта на отдельные

задачи. В WBS могут быть представлены два вида задач – суммарные задачи и пакеты работ. Суммарная задача представляет собой суммирование подчиненных пакетов работ. Пакет ра-

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

Существует несколько подходов к декомпозиции:

–на основании задач проекта (констатации содержания);

–на основании получаемого продукта;

–по фазам жизненного цикла проекта;

–смешанный подход.

51

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

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

♦Могут ли реалистично и точно быть оценены пакеты работ с точки зрения финансовых и временных затрат, затрат человеческих ресурсов?

♦Могут ли быть завершены пакеты работ без прерываний (без необходимости получения дополнительной информации, привлечения дополнительных участников и ресурсов)?

♦Может ли быть однозначно истолковано действие конкретного пакета работ, понятно ли оно участникам проекта?

♦Легко ли контролировать выполнение пакета работ?

В локальных проектах рекомендуется WBS разбивать на пакеты работ, которые включают от 4 до 40 часов работ. Проекты средней величины могут иметь пакеты работ от 8 до 80 часов. Большие проекты могут содержать пакеты работ значительно больше, чем предыдущие, например, они могут включать 300 часов работ.

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

52

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

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

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

3.1. ПРАВИЛА ПОСТРОЕНИЯ WBS

WBS – это фундамент проекта. Это означает, что почти все, что будет осуществляться на этапе планирования, после создания WBS имеет отношение к WBS.

В PMBOK обозначены следующие правила создания WBS:

♦WBS создается с помощью команды;

♦WBS включает только результаты, которые требуются

врамках проекта;

♦результаты, которые не указаны в WBS, не являются частью проекта.

В ГОСТ Р 54869–2011 «Проектныйменеджмент. Требова-

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

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

б) определены, согласованы с заказчиком и документированы ключевые данные по продукту проекта, а именно:

53

1)назначение, свойства и характеристики продукта;

2)критерии и методы приемки продукта проекта и его составных частей;

3)допущенияиисключения, касающиесяпродуктапроекта;

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

Данные правила можно дополнить следующими:

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

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

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

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

5)Важное правило при разработке WBS: детализировать деятельность полезно до уровня, обеспечивающего возмож-

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

54

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

Наиболее распространенными ошибками, допускаемыми

впроцессе структуризации проекта, являются:

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

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

3)излишняя или недостаточная детализация;

4)наличие задач, допускающих множество толкований.

3.2. СЛОВАРЬ WBS

После составления WBS каждому элементу присваивается уникальный идентификатор. Затем пакеты работ WBS рекомендуется описать в словаре.

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

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

55

3.3. РАСПИСАНИЕ ПРОЕКТА

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

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

Любое реалистичное расписание:

– предполагает доскональное знание предстоящей работы (для этого используется WBS);

56

–предполагает правильное выстраивание последовательности задач (для этого строятся сетевые диаграммы);

–учитывает действие внешних ограничений, неподконтрольных команде;

–учитывает цели и задачи проекта.

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

♦вероятную продолжительность выполнения работ и длительность всего проекта;

♦стоимость работ и возможные размеры экономии времени или денежных средств;

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

♦взаимозависимость всех пакетов работ;

♦параллельные задачи – задачи, которые могут быть выполнены одновременно.

Сетевое планирование является также базой для распределения ресурсов проекта.

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

инелогично.

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

F-to-ST. Это стандартная последовательность, при которой предшествующая задача должна завершиться до начала последующей.

57

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

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

St-to-F. Этот тип используется редко, но он может быть полезен, когда при планировании требуется задержать окончание работы на как можно более длительный срок, связав ее окончание с началом другой работы. Такая связь, например, может быть использована, когда нужно спланировать поставку дорогого оборудования и подготовительные работы должны вестись все имеющееся до поставки время.

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

Рис. 3.1. Сетевая диаграмма

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

58

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

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

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

Жесткая зависимость (Mandatory dependency, Hard logic) –

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

Нежесткая зависимость (Discretionary dependency, Soft logic) – последовательность работ может быть изменена командой проекта. Такая зависимость важна, когда есть необходимость сжать расписание и уменьшить длительность проекта.

Внешняя зависимость (External dependency) – последова-

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

Внутренняя зависимость (Internal dependency) –последо-

вательность работ определяется потребностями проекта и может контролироваться командой проекта.

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

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

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

59

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

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

–продолжительность критического пути определяет общую продолжительность проекта;

–критических путей может быть несколько;

–критический путь может меняться в течение проекта;

–временные резервы бывают отрицательные. Это означает отставание от расписания;

–в процессе выполнения проекта, если операции из кри-

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

Выстраивая логическую цепочку событий, целесообразно выделять контрольные события. Согласно PMBOK, контроль-

ные события (вехи) – это важные события в расписании про-

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

вустав проекта и содержание проекта. Руководитель проекта может также установить вехи для контроля проекта. Если контроль-

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

Основные контрольные события:

–старт и финиш проекта;

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

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

Следующим шагом в составлении расписания является оценка времени выполнения каждого пакета работ. Когда ме-

60