Рекомендації з побудови ІСР
Ієрархічна структура робіт
На даний момент розробки проекту ми визначили вихідні результати, відпо-ціалу всім зацікавленим сторонам. Але ми не можемо планувати діяльність на підставі цього переліку вихідних результатів. Щоб приступити до планування проекту, ми повинні перетворити їх в індивідуальні порції роботи, які повинні бути виконані для завершення проекту. Для цього нам потрібно ієрархічна струк-тура робіт, ІСР (workbreakdownstructur, WBS).
Ієрархічна структура робіт є центральним пунктом в плануванні проекту. Без неї неможливо визначити роботи, які повинні бути виконані для завершення проекту. Не знаючи, яку конкретно роботу необхідно провести, ми не зможемо визначити вартість проекту або скласти розклад проекту.
Як ми зможемо контролювати виконання проекту або визначити обсяг коштів, необхідних для завершення проекту, не маючи при цьому даних про вартість або распи-саніі проекту? Обсяг ресурсів, необхідних для реалізації проекту, і терміни забезпе-ня ними не можна визначити без розкладу. Не можна скласти розклад надходження фінансових коштів для виконання проекту в потрібні терміни без розподіленого за часом бюджету. Не знаючи роботи, яку потрібно виконати для проекту, неможливо задовільно виконувати управління ризиками. Все це неможливо виконати без ієрархічної структури робіт.
У РМВОК структура декомпозиції робіт проекту визначається як:
Роботи, що не входять в ІСР, знаходяться поза межами змісту проекту. З цього визна-ділення ІСР ми можемо витягти метод виявлення робіт, які належить виконати для отримання всіх необхідних результатів поставки проекту. Як ми побачимо нижче, цей метод у багатьох проектах дозволяє визначити близько 95% необхідних робіт.
Скласти ІСР нескладно. Перш за все слід розбити проект на кілька подпро-тів. Кожен з підпроектів, в свою чергу, може бути розбитий на деяке число подподпроектов. Так, слід послідовно ділити проект на складові частини до тих пір, поки не буде досягнутий потрібний рівень деталізації. Його називають рівнем паку-тов робіт. Це найнижчий рівень управління, яким потрібно керувати менеджеру проекту. Разом з тим інші члени команди проекту можуть продов-жити розподіл своїх частин проекту на додаткові рівні.
Причина ефективності пропонованої методики в тому, що вона грунтується на принципі «розділяй і володарюй». Якщо ви спробуєте зібрати нараду, на якому запропонуйте скласти перелік всіх робіт проекту, результати навряд чи будуть удовле-орудний. На цій нараді буде спостерігатися невисока ступінь зосереджений-ності, увагу переміститься в одну область і добре буде визначено перелік робіт тільки для цієї області на шкоду іншим областям проекту.
Поставлена вище завдання може бути вирішена шляхом розбиття проекту на більш дрібні проекти або продукти проекту. Коли ми це робимо, то можемо вважати, що кожен з таких підпроектів створює один або більше результатів поставки проекту в цілому. Подоб-ним же чином ми можемо розглядати ІСР як орієнтовану на продукт декомпен-зицію. Це дозволяє управлінню проектами стати методологією, однаково добре робо-тане як в найбільших, так і самих малих проектах та програмах. На верхніх рівнях проектів, особливо великих проектів, іноді зручно розглядати такі ранні рівні декомпозиції як декомпозицію продуктів. Це можливо тому, що в більших проектах можна згрупувати результати поставки в більш великі результати поставки, які можна назвати продуктами.
Отже, спочатку проект розбитий на групу підпроектів. Ці підпроекти далі розбиваються на подподпроекти і т. Д. Таким чином, найбільший проект, який ми могли б собі уявити, можна було б розбити на підпроекти. Оскільки кожен з | підпроектів сам по собі може бути розглянутий як проект, будь-який великий проект може бути представлений у вигляді сімейства більш дрібних взаємопов'язаних проектів.
Проект може розглядатися як мікрокосм або ж як макрокосм. На будь-якому рівні даної ієрархічної структури з точки зору менеджера, відповідального за кон-конкретного частина проекту, є окремий проект, за який він несе відповідальність. Будь-який проект є частиною якогось більшого проекту, і будь-який проект має підпроекти. Все залежить від того, з якого місця дивитися.
Розглянемо такий приклад. У 60-і роки в США був реалізований проект польоту челове-ка на Місяць з подальшим поверненням на Землю. У цьому дуже великому проекті навчаючи-ствовали багато тисяч співробітників. Менеджер цього проекту жив у Вашингтоні і витрачав велику частину свого часу на взаємодію з Конгресом США та іншими урядовими структурами.
Коли програма «Аполлон» досягла свого апогею, то дійсно стала дуже великим проектом. В її реалізації одноразово виявилися задіяні близько 40 000 чоловік. У цю програму входив проект створення двигуна першого ступеня ракети-носія «Сатурн-5». У проекту був свій менеджер і безліч співробітників. У проекті розробки двигуна ракети-носія брало участь кілька організацій, розташованих в різних частинах країни. Проект розробки двигуна виконувався в різних місцях, і над ним працювали кілька тисяч чоловік. В рамках цього проекту були й інші проекти: проект тестування двигуна, проект паливних систем, проект систем охолодження і т. Д.
Хоча обсяг робіт в рамках проекту створення двигуна ракети-носія був дуже значним, він являв собою лише невелику частину програми «Аполлон». Тому в залежності від того, яке місце ви займаєте в ієрархії програми, можете вважати себе менеджером програми, менеджером проекту або навіть менеджером підпроекту.
У практичному плані менеджеру вищого рівня програми або менеджеру проекту немає ніякого сенсу стежити за всіма найдрібнішими складовими проекту. Йому, в суті-сти, немає необхідності навіть знати про них. Отже, ми можемо бачити, що надзвичайно великі проекти виражаються в більш дрібних проектах або підпроекти. Підпроекти самі по собі є окремими проектами зі своїми законами і власної ієрархічної струк-турою робіт. Кожен проект може бути частиною більшого проекту, або макрокосму, і кожен проект може мати більш дрібні проекти, або мікрокосм.
Важливо підкреслити, що дана методика є ефективною для проектів або програм будь-яких розмірів. Інструментарій і методологія для проектів будь-яких раз-мерів є однаковими. ІСР - засіб, що дозволяє розбити будь-який проект на більш дрібні проекти, якими легше управляти.
Кінцевим результатом розробки ІСР є визначення груп індивідуальних порцій робіт. Відповідальність за кожну таку елементарну роботу повинна бути доручена одному члену команди проекту. Першочергове завдання складання ІСР укладаючи-ється в поділі проекту на підпроекти до того рівня деталізації, коли з'явиться можли-ність розподілити елементарні роботи.
Якщо проект великий, складання ІСР може зупинитися на досить високому рів-ні. Це може бути рівень контролю для менеджера проекту. Як уже згадувалося, цей рівень в ІСР прийнято називати пакетом робіт. Слід зрозуміти, що на цьому високому рівні інші менеджери, зайняті в проекті, будуть здійснювати подальший поділ найнижчого рівня початкової декомпозиції аж до індивідуальних порцій роботи.
Отже, на самому нижньому рівні будь-якого проекту має бути опис інді-ального порції роботи, яка може бути виконана однією людиною (або групою людей). Ця людина (або група) дійсно буде виконувати цю роботу, а не керувати її виконанням. Цей рівень називається рівнем завдань (tasklevel) або рівнем операцій (activitylevel).
У цій області термінологія все ще змінюється, і РИВОК не зовсім чітко визна-ляет ці терміни. ІСР розбиває проект на керовані порції, але зупиняється на рівні пакета робіт. Самим нижнім рівнем вважається пакет робіт, який менеджер проекту повинен тримати під своїм безпосереднім контролем. Потім можливо даль-нейшее розбиття пакетів робіт, перед тим як здійснити прив'язку до виконавців конкретних дій. Пакети робіт можуть розбиватися на операції (activitiesy), які в свою чергу можуть бути розбиті на завдання (tasks).
У РМВОК йдеться, що самим нижнім рівнем ІСР є рівень пакета робіт. Менеджери пакетів робіт вже самостійно проводять подальший розподіл роботи по проекту на підпроекти і пакети робіт. У звичайному ж розумінні рівень завдань або операцій вважається самим нижнім рівнем кінцевої ІСР.
Мої рекомендації полягають в тому, щоб при побудові ІСР ставити перед собою одну-єдину мету: визначити всю роботу, яка необхідна для виконан-ня проекту. Якщо ви спробуєте одночасно з ІСР розробити організаціоннуюдіаграмму (organizationchart), план рахунків (chartо / ассоіпts) або вирішити будь-які інші організаційні завдання проекту, то досить імовірно, що головної мети вам досягти не вдасться. Ці елементи, організаційна структура (ОВ5organizationalbreakdownstructure-) і план рахунків (chartо / ассоіпts), повинні бути окремими від ІСР елементами, пов'язаними через елементи ІСР нижчих рівнів.
Системний підхід до складання ієрархічної структури робіт
На даний момент ми розбили проект на підпроекти і продовжили розбиття до тих пір, поки не досягли рівня пакетів робіт. Якщо проект невеликий, рівень пакетів робіт може збігтися з рівнем завдань або операцій, на якому дійсно виконується рабо-ту. У більших проектах у пакета робіт може бути свій менеджер, який продов-жит деталізувати роботу до тих пір, поки не дійде до рівня завдань або робіт.
Вкрай важливо, щоб на кожному з найнижчих рівнів декомпозиції було призначено тільки одну особу, що відповідає за роботу над даним компонентом, незалежно від того, чи йде мова про пакет робіт, задачі або операції.
Що ж далі? Ми визначили всі роботи по проекту. Але в дійсності нам вдалося визначити приблизно 90% від загального обсягу робіт, які необхідно виконати. Тепер у нас повинна бути можливість більш точно визначити інші необхідні роботи.
Відповідно до теорії управління системами вся робота розглядається як система, в якій робота є процесом перетворення вхідних елементів у ви-хідні. У застосуванні цієї теорії на рівні проекту ми можемо описати проект як процес перетворення вхідних елементів (ресурсів, грошей, трудовитрат) у вихідні еле-менти (результати поставки) проекту.
Якщо прикласти цю теорію до нашої ієрархічній структурі робіт, можна сказати, що кожна задача на найнижчому рівні ІСР є процесом, який перетворює вхідні елементи у вихідні. Вхідні елементи являють собою те, що виконай-тель завдання повинен отримати з якоїсь іншої частини проекту або з зовнішнього по відно-шенням до проекту джерела. Вихідні елементи повинні бути передані в якусь іншу частину проекту або являти собою результати поставки проекту або їх склад-рами.
Ми можемо застосовувати ці поняття щодо нашого визначення роботи. Кожна людина, що відповідає за виконання завдання, буде переглядати інші завдання в пошуках того, що необхідно для виконання даного завдання. Він також вивчатиме інші частини проекту, яким повинні бути передані вихідні елементи його завдання. Таким чином, кожен член команди проекту повинен подивитися на вхідні і вихід-ні елементи принаймні два рази. Всі вхідні елементи завдання повинні виходити від чогось всередині проекту або з зовнішнього джерела. Всі вихідні елементи повинні або бути передані в іншу задачу проекту, або безпосередньо бути частиною результатів поставки проекту.
Вхідні елементи, які не знайдені серед зовнішніх джерел або серед виходів інших завдань проекту, повинні бути додані як вихідні до інших завдань проекту. Вихідні елементи, які не повинні бути доставлені в інші частини проекту або не є вихідним результатом проекту в цілому, можуть розглядатися як зайва робота. Таким чином, можна виявити майже всі необхідні додаткові роботи, ще не включені до плану. Крім того, можна викинути з плану проекту все раніше включені в нього роботи, які можна розглядати як «зайві прикраси».
Нарешті, є можливість виключити роботи, що дублюють один одного. Коли викон нітелей завдання при пошуку вхідного елемента для неї знаходить кілька завдань, забезпечують-вающих одні й ті ж або майже однакові вхідні елементи, то можна виключити одну або кілька таких завдань.
Словник ієрархічної структури робіт використовується для розширення інформації про кожен елемент ІСР. Для кожного елемента він повинен містити опис елементів-тарної роботи, розклад і тривалість, бюджет, все пов'язані з нею елементи і операції, відповідальну організацію та пов'язані з нею ризики.
Додаткові структури декомпозиції проектів
Необхідно знати, що в проектах також використовуються інші типи декомпозицій. Тип ІСР, який ми щойно обговорили, повинен використовуватися тільки для виділення індивідуальних порцій роботи, яку потрібно виконати в проекті. Спроба викорис-товувати даний тип декомпозиції в інших областях може тільки призвести до плутанини, і визначення роботи буде не настільки ефективним, як потрібно.
ІСР необхідно відрізняти від інших структур декомпозиції.
Ієрархічна структура робіт за контрактом (ContractualWorkBreakdownStructure, CWBC). Ця структура декомпозиції використовується для визначення звітної інформації та розкладу отримання інформації, яку постачальник надає покупцеві. Зазвичай вона не така деталізована, як ІСР, що використовується для складання плану майбутньої роботи.
Організаціоннаяструктура (OrganizationalBreakdown Structure, OBS). Основне завдання цієї структури - показати організацію ресурсів і людей, які працюють над проектом. У ОВS компоненти роботи, представлені в ІСР, показані пов'язаними з групами співробітників і ресурсами, що забезпечують виконання роботи.
Іерархіческаяструктураресурсов (ResourceBreakdown Structure, RBS). Це більш детальний варіант ОВS, в якому RBS зазвичай переходить на індивідуальний рівень.
Відомість матеріалів (Bill of Material, ВВП). В дану структуру включаються компо-ненти різних продуктів в ієрархічному порядку. Випускаються продукти, склад-рами їх вузли і вузли нижчого рівня представлені як «гілки» ієрархії.
Визначення обсягу пакета робіт (Правило звітного періоду)
Час виконання будь-якої із завдань не повинно бути більше проміжку часу між нарадами, присвяченими ходу виконання проекту. Наприклад, якщо наради проводяться щотижня, то час виконання жодної із завдань не повинно бути більше тижня. Це правило особливо корисно у випадках, коли настає час звітувати у виконанні розкладу виконання проекту, оскільки в цьому випадку вам вже не доведеться вислуховувати доповіді про те, що якась із завдань виконана на 25%, 30% або 80%. При регулярному проведенні нарад, присвячених ходу виконання проекту, прогрес, досягнутий при виконанні того чи іншого завдання, може доповідатиметься як «завершення» (100%), «виконання» (50%) або «до виконання не приступали» (0%). Про жодну із завдань не можна доповідати як про що знаходиться в стані «виконання» (50%) на двох наступних один за іншим нарадах, присвячених ходу виконання проекту.
