УпрРазрИС / Блок_2 / Материалы / Рекомендации по построению ИСР

Иерархическая структура работ

На данный момент разработки проекта мы определили выходные результаты, соответ­ствующие всем заинтересованным сторонам. Но мы не можем планировать деятельность на основании этого перечня выходных результатов. Чтобы приступить к планированию проекта, мы должны превратить их в индивидуальные порции работы, которые должны быть выполнены для завершения проекта. Для этого нам требуется иерархическая струк­тура работ, ИСР (work breakdown structur, WBS).

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

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

В РМВОК структура декомпозиции работ проекта определяется как:

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

Работы, не входящие в ИСР, находятся вне границ содержания проекта. Из этого опре­деления ИСР мы можем извлечь метод выявления работ, которые надлежит выполнить для получения всех требуемых результатов поставки проекта. Как мы увидим ниже, этот метод во многих проектах позволяет определить около 95% необходимых работ.

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

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

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

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

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

Рассмотрим такой пример. В 60-е годы в США был реализован проект полета челове­ка на Луну с последующим возвращением на Землю. В этом очень крупном проекте уча­ствовали многие тысячи сотрудников. Менеджер этого проекта жил в Вашингтоне и тратил большую часть своего времени на взаимодействие с Конгрессом США и другими правительственными структурами.

Когда программа «Аполлон» достигла своего апогея, то действительно стала очень крупным проектом. В ее реализации единовременно оказались задействованы около 40 000 человек. В эту программу входил проект создания двигателя первой ступени ракеты-носителя «Сатурн-5». У проекта был свой менеджер и множество сотрудников. В проекте разработки двигателя ракеты-носителя участвовало несколько организаций, расположенных в различных частях страны. Проект разработки двигателя выполнялся в различных местах, и над ним трудились несколько тысяч человек. В рамках этого проекта были и другие проекты: проект тестирования двигателя, проект топливных систем, проект систем охлаждения и т. д.

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

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

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

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

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

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

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

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

Мои рекомендации заключаются в том, чтобы при построении ИСР ставить перед собой одну-единственную цель: определить всю работу, которая необходима для выполне­ния проекта. Если вы попытаетесь одновременно с ИСР разработать организационную диаграмму (organization chart), план счетов (chart о/ ассоипts) или решить какие-либо иные организационные задачи проекта, то весьма вероятно, что главной цели вам достичь не удастся. Эти элементы, организационная структура (ОВ5 organizational breakdown structure-) и план счетов (chart о/ ассоипts), должны быть отдельными от ИСР элементами, связанными через элементы ИСР более низких уровней.

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

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

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

Что же далее? Мы определили все работы по проекту. Но в действительности нам удалось определить примерно 90% от общего объема работ, которые необходимо проделать. Теперь у нас должна быть возможность более точно определить остальные необходимые работы.

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

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

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

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

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

Словарь ИСР

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

Дополнительные структуры декомпозиции проектов

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

ИСР необходимо отличать от других структур декомпозиции.

• Иерархическая структура работ по контракту (Contractual Work Breakdown Structure , CWBC). Эта структура декомпозиции используется для определения отчетной информации и расписания получения информации, которую поставщик предоставляет покупателю. Обычно она не такая детализированная, как ИСР, использующаяся для составления плана предстоящей работы.

• Организационная структура (Organizational Breakdown Structure, OBS). Основная задача данной структуры - показать организацию ресурсов и людей, работающих над проектом. В ОВS компоненты работы, представленные в ИСР, показаны связанными с группами сотрудников и ресурсами, обеспечивающими выполнение работы.

• Иерархическая структура ресурсов (Resource Breakdown Structure, RBS). Это более подробный вариант ОВS, в котором RBS обычно переходит на индивидуальный уровень.

• Ведомость материалов (Bill of Material, ВОМ). В данную структуру включаются компо­ненты различных продуктов в иерархическом порядке. Выпускаемые продукты, состав­ляющие их узлы и узлы более низкого уровня представлены как «ветви» иерархии.

• Иерархическая структура рисков (Risk Breakdown Structure, RBS). Она представляет собой иерархический перечень рисков проекта в соответствии с категориями рисков, разработанными для данного проекта.

Подтверждение содержания

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

Определение объема пакета работ (Правило отчетного периода)

Время выполнение любой из задач не должно быть больше промежутка времени между совещаниями, посвященными ходу выполнения проекта. Например, если совещания проводятся каждую неделю, то время выполнения ни одной из задач не должно быть больше недели. Это правило особенно полезно в случаях, когда наступает время отчитываться в выполнении расписания исполнения проекта, поскольку в этом случае вам уже не придется выслушивать доклады о том, что какая-то из задач выполнена на 25%, 30% или 80%. При регулярном проведении совещаний, посвященных ходу выполнения проекта, прогресс, достигнутый при выполнении той или иной задачи, может докладываться как «завершение» (100%), «выполнение» (50%) или «к выполнению не приступали» (0%). Ни об одной из задач нельзя докладывать как о находящейся в состоянии «выполнения» (50%) на двух следующих один за другим совещаниях, посвященных ходу выполнения проекта.