Управління проектами: сутність та історія розвитку

Управління проектами: сутність та історія розвитку

 

Управління проектами — це область знань з планування, організування, мотивування, контролювання та регулювання, а також управління ресурсами з метою успішного досягнення цілей та завершення завдань проекту. Іноді ототожнюється з управлінням програмами, але програма — це фактично більший високий рівень: це група пов'язаних та взаємозалежних проектів.

У більшості літературних джерелах існують розбіжності між поняттями «управління проектами» та «проектний менеджмент». Так, фахівці інституту управління проектами (США) запропонували таке трактування терміну «управління проектом»: це мистецтво керувати і координувати людські та матеріальні ресурси протягом життєвого циклу проекту, застосовувати системи сучасних методів і техніки управління та мінімізації ризиків для досягнення визначених результатів за складом і обсягами робіт, вартістю, часом, якістю та задоволенням учасників. За функціональним підходом під управлінням проектом слід розуміти конкретну функцію менеджменту, яка реалізується через загальні функції як планування, організування, мотивування, контролювання та регулювання. Проектний менеджмент - це привнесення додатково до робіт проекту знань, навичок, методів і засобів для задоволення або перевищення потреб і бажань зацікавлених осіб проекту.

За допомогою методів управління проектами визначають цілі проекту, обґрунтовують і оцінюють його життєздатність; виявляють структуру проекту (підцілі, завдання, роботи, які необхідно виконати); визначають необхідні обсяги та джерела фінансування; підбирають виконавців, зокрема за допомогою торгів і конкурсів; готують і укладають контракти; визначають терміни реалізації проекту; складають графік виконання робіт; розраховують необхідні ресурси; кошторис і бюджет проекту; планують і враховують ризики; забезпечують контроль за реалізацією проекту.

Проект — це обмежений часовими рамками процес, що має визначений початок та кінець, зазвичай обмежений датою, але також може обмежуватися фінансуванням або досягненням результатів, який здійснюється для реалізації унікальних цілей та завдань, зазвичай, щоб призвести до вигідних змін або створення доданої вартості. Тимчасова природа проектів контрастує з бізнесом (процесами), які є повторюваною, постійною або частково постійною діяльністю з виробництва продуктів або послуг. На практиці, управління вищезазначеними двома системами часто різниться і таким чином вимагає розвитку окремих технічних навичок та використання розподіленого управління ними.

Головним завданням проектного управління є досягнення всіх цілей та виконання завдань проекту, одночасно виконуючи зобов'язання щодо наперед визначених обмежень проекту. Типовими обмеженнями є межі та зміст проекту, час, бюджет. Другорядним завданням, але більш амбіційним, є оптимізація, розподілення та інтеграція завдань, необхідних для досягнення наперед визначених цілей.

Управління проектами практикувалося з початку виникнення цивілізації. До 1900 року творчі архітектори та інженери управляли інженерними проектами самотужки. З 1950 організації почали систематично використовувати інструменти та техніки проектного управління для керування складними проектами.

Як наука, управління проектами виникло з декількох прикладних наук, таких як будівництво, інженерія та оборонна діяльність. Засновником проектного управління вважають Генрі Ганта, якого називають батьком технік планування та контролю. Він відомий завдяки використанню діаграми Ганта, як інструменту управління проектами. Також засновником проектного управління вважають Анрі Файоль, завдяки створенню ним 5 функцій управління, що формують засади знань управління проектами та програмами. Гант та Файоль були прихильниками теорій з наукового управління Фредеріка Уінслоу Тейлора. Його робота — це попередник сучасних інструментів управління проектами, включаючи декомпозицію робіт та розподілення ресурсів.

1950-ті розпочали епоху сучасного проектного управління. Управління проектами почали визнавати, як окремий напрям, що виник з науки про управління. В Сполучених Штатах до 1950-их проектами управляли ad hoc, використовуючи діаграми Ганта, неформальні техніки та інструменти. В той час, було розроблено дві математичні моделі проектного управління. Метод критичного шляху (англ. Critical Path Method - CPM) був розроблений, як спільний проект між корпораціями Дю Понт (англ. DuPont Corporation) та Ремінгтон Ренд (англ. Remington Rand Corporation) для управління та підтримки проектів. Програма оцінки та контролю (англ. Program Evaluation and Review Technique - PERT) була розроблена Буз-Ален та Гамільтон (англ. Booz-Allen & Hamilton) разом з Корпорацією Локхід (англ. Lockheed Corporation), як частина програми військово-морського флоту Сполучених Штатів для підводних човнів, — Ракети Поляріс. Ці математичні техніки швидко поширилися між багатьма приватними підприємствами.

В той час, коли розроблялися моделі планування, техніки для оцінки вартості проектів, завдяки проривним роботам Ганса Ланге та інших виникло Управління вартістю та Інженерна економіка. В 1956 р. першими практиками проектного управління та суміжними спеціалістами з календарного планування (проектного контролю), оцінки вартості та її контролю була створена Американська асоціація інженерів з управління вартістю (англ. American Association of Cost Engineers) зараз, дослівно, Міжнародна асоціація з просування управлінням вартістю англ. Association for the Advancement of Cost Engineering - AACE International). AACE продовжувала дослідницькі роботи і в 2006 р. випустила перший інтегрований процес для портфельного, програмного та проектного управління: Система повного управління вартістю (англ. Total Cost Management Framework).

Міжнародна асоціація проектного управління (англ. International Project Management Association - ІPMA) була заснована в Європі в 1967 р., як об'єднання декількох національних асоціацій проектного управління. IPMA й сьогодні зберігає федеральну структуру і зараз складається з членів-асоціацій на кожному континенті за виключенням Антарктиди. IPMA пропонує програму сертифікації, що складається з чотирьох рівнів, яка базується на основних компетенціях IPMA (англ. IPMA Competence Baseline - ICB). Компетенції ICB включають технічні компетенції, контекстуальні компетенції та поведінкові компетенції.

В 1969 р. в Сполучених Штатах був створений Інститут проектного управління (англ. Project management institute - PMI). PMI опублікував Довідник з управління проектами (англ. A Guide to the Project Management Body of Knowledge - PMBOK Guide), який описує практики управління проектами, що є однаковими для «більшості проектів у більшості випадків». PMI також пропонує різноманітну сертифікацію.

СІТКОВЕ ПЛАНУВАННЯ В ПРОЕКТНОМУ МЕНЕДЖМЕНТІ

Сіткове планування виникло у 50-х роках, коли почали розвиватися комп’ютерні засоби. Його методи мають таку відому міжнародну назву та абревіатуру, як метод критичного шляху — СРМ (Сritical path method), або аналіз критичного шляху — СРА (Сritical path analysis), або метод оцінки й огляду програми — РЕRT (Рrogramme evaluation and rewiew technique). У нашій практиці ці методи мають назву «сіткові графіки». Зараз вони застосовуються дуже широко, особливо у великих і складних проектах, за допомогою обчислювальної техніки і програмного забезпечення.

Сіткове планування полягає у створенні логічних діаграм послідовності виконання проектних робіт — сіткових графіків — і визначенні тривалості цих робіт та проекту в цілому з метою подальшого контролю.

Застосування сіткового планування допомагає відповісти на такі запитання:

1. Скільки часу потрібно на виконання усього проекту?

2. У який час мають розпочинатися та закінчуватися окремі роботи?

3. Які роботи є «критичними» і повинні виконуватися точно за графіком, аби не зірвати строки виконання проекту у цілому?

4. На який термін можна відкласти виконання «некритичних» робіт, щоб це не вплинуло на строки виконання проекту?

Сіткове планування полягає передусім у побудові сіткового графіка та обчисленні його параметрів.

Сітковий графік — це графічне подання робіт проекту, яке відбиває їх послідовність та взаємозв’язок. Для його побудови потрібно мати таку інформацію: список робіт; логічні зв’язки між ними.

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

Подіями називаються кінцеві результати попередніх робіт. Подія являє собою момент завершення планової дії. Події бувають початковими, кінцевими, простими, складними, проміжними, попередніми, наступними і т.д.

На всіх сіткових графіках важливим показником є шлях, що визначає послідовність робіт чи подій, в якій результат однієї стадії збігається з початковим показником наступної за нею іншої фази. На будь-якому графіку прийнято розрізняти декілька шляхів:

- повний шлях від початкової до кінцевої події;

- шлях, що передує даній події від початкової;

- шлях, наступний за даною подією до кінцевої;

- шлях між декількома подіями;

- критичний шлях від початкової до кінцевої події максимальної тривалості.

Сіткові графіки будуються зліва направо графічним зображенням проектних робіт та означенням логічних зв’язків між ними. Залежно від способу зображення їх розрізняють два види сіткових графіків:

• стрілчасті;

• графіки передування.

Першими у сітковому плануванні почали застосовувати саме стрілчасті графіки (Метод стрілкових діаграм - ADМ). Для них характерним є зображення роботи у вигляді стрілки (звідси й пішла назва цього графіка), а логічні зв’язки між роботами встановлюються так званими подіями, які зображаються у вигляді кіл, що свідчать про початок і закінчення тієї чи іншої роботи.

 

Рис.1 Стрілчастий графік

Графіки передування (Метод попередніх діаграм - РDМ) отримали свій розвиток із широким застосуванням програмного забезпечення і сьогодні потіснили стрілчасті графіки. В них, на відміну від попередніх, роботи подано у вигляді прямокутників, а стрілками позначаються логічні зв’язки.

Діаграма РDМ включає чотири типи залежності або співвідношення передування:

• «фініш-старт» - попередня робота повинна фінішувати раніше, ніж стартуватиме наступна робота;

• «фініш-фініш» - попередня робота повинна фінішувати до того, як фінішуватиме наступна робота;

• «старт-старт» - попередня робота повинна стартувати перед тим, як стартуватиме наступна робота;

• «старт-фініш» - попередня робота повинна стартувати перед тим, як фінішуватиме наступна робота.

 

 

 

Рис.2 Графік передування

Ці обидва види графіків використовуються у сучасному програмному забезпеченні.

Щоб визначити тривалість проекту та календарні терміни початку і завершення його робіт за допомогою сіткового планування, потрібно виконати такі кроки:

1-й крок. Визначення переліку й послідовності виконання робіт.

2-й крок. Графічна побудова сіткового графіка.

3-й крок. Означення тривалості робіт.

4-й крок. Визначення ранніх термінів початку і завершення проектних робіт «прямим проходженням».

5-й крок. Визначення пізніх термінів початку і завершення робіт «зворотним проходженням».

6-й крок. Визначення критичного шляху і запасу часу по роботах.

МЕТОД ОЦІНКИ І ПЕРЕГЛЯДУ ПЛАНІВ

Program (Project) Evaluation and Review Technique (скорочено PERT) техніка оцінки і аналізу програм (проектів), яка використовується при управлінні проектами. PERT - це спосіб аналізу завдань, необхідних для виконання проекту. Особливо, аналізу часу, який потрібно для виконання кожного окремого завдання а також визначення мінімального необхідного часу для виконання усього проекту.

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

Найпопулярнішою частиною PERT є Метод критичного шляху що спирається на побудову мережевого графіку (мережевої діаграми PERT).

Даний метод був розроблений в 1958 році консалтинговою фірмою "Буз, Ален і Гамильтон" спільно з корпорацією "Локхид" за замовленням Підрозділу спеціальних проектів ВМС США у складі Міністерства Оборони США для проекту створення ракетної системи "Поларис" (Polaris). Проект "Поларис" був відповіддю на кризу, що настала після запуску Радянським Союзом першого космічного супутника.

Основними компонентами методу PERT є:

1) події, які визначають істотні моменти в ході реалізації проекту, є початком або закінченням якої-небудь роботи і не вимагають витрати часу або ресурсів;

2) операції які є реалізацією конкретної роботи, вимагають витрати часу і ресурсів;

3) мережа, яка визначає відношення між подіями і операціями, що зв'язують ці події.

Основною характеристикою операції в методі PERT є час, необхідний для її виконання. Подія не може статися, поки не виконані усі операції, що ведуть до неї, а операція не може бути розпочата, поки не стануться усі попередні їй події.

Суть методу полягає у виконанні наступних етапів:

1) оцінка групою експертів тривалості кожної операції;

2) розрахунок очікуваної тривалості кожної операції;

3) визначення найбільш раннього часу настання кожної події;

4) визначення найбільш пізнього часу настання кожної події;

5) обчислення резерву часу для кожної події;

6) визначення критичного шляху.

Тривалість кожної операції може мати наступний вигляд оцінок:

·- оптимістична (t1i) - цей мінімальний час у течії якого i -а операція може бути виконана за сприятливих умов;

- вірогідна (t2i) - найбільш вірогідний час виконання i -ої операції

- песимістична (t3i) - максимально можливий час, в течії якого i -а операція може бути виконана за найсприятливіших умов.

Очікувана тривалість i -ій операції визначається за формулою ti=(t1i+t2i+t3i)/6.

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

Як зазначає А. Ільїн, існує близько 100 різновидів методу PERT, але всі вони мають і загальні характеристики. Особливостями застосування цього методу є те, що:

Ø система дозволяє ретельно планувати проекти, для яких він застосовується;

Ø ПЕРТ дає можливість моделювати та експериментувати;

Ø застосування методу розширює участь в плануванні спеціалістів нижчого рівня;

Ø підвищує ефективність контролю;

Ø метод застосовується для вирішення різних планових задач;

Ø для складних сіток вартість застосування системи PERT є значною, що являється обмеженням в застосуванні її на невеликих об’єктах;

Ø неточність оцінок знижує ефективність методу;

Ø якщо час здійснення подій неможливо передбачити (як, наприклад, в наукових дослідженнях), то система не може бути використана

 

Управління командою проекту

Управління командою проекту ставить за мету забезпечення найбільш ефективного використання потенціалу осіб, які залучені до виконання проектних робіт. Від того, наскільки злагоджено буде працювати команда, багато в чому залежать кінцеві результати впровадження бізнес-ідеї у життя.

Звісно, що ефективна роботи КМП закладається на етапі її формування. Про вимоги до формування КМП йшлося у главі 15 посібника. Однак навіть якщо вдасться дібрати найбільш оптимальний склад команди, завдання керування командою не тільки не стають більш простими, а навпаки — ускладнюються. Керувати справжніми фахівцями набагато складніше ніж пересічними спеціалістами. Вони більш амбітні, незалежні в судженнях, менш дисципліновані, не дуже сприймають командний тон та характеризуються іншими якостями, які ускладнюють діяльність менеджера проекту.

Крім того, інколи у менеджера проекту бувають обмежені повноваження щодо добору членів команди. Особливо коли проект має велику кількість зацікавлених осіб, вони наполягають на включення в команду своїх представників. Робота з КМП може ускладнюватися внаслідок того, що окремі її члени підпорядковуються як функціональному менеджеру, так і менеджеру проекту. Ефективне управління в умовах такого подвійного підпорядкування часто є критичним чинником успіху впровадження проекту. Це також потребує від менеджера проекту чималих навичок у галузі управління персоналом.

Ефективну команду можна визначити загальними критеріями ефективності будь-якої організаційної структури. Але при цьому можна вказати на деякі специфічні риси, притаманні тільки команді.

Дослідники практики проектного менеджменту виділяють такі риси, якими характеризуються ефективні команди:

неформальна атмосфера;

завдання, які ставляться перед членами команди, добре зрозумілі;

члени команди прислухаються один до одного;

в обговоренні завдань беруть участь усі члени команди;

її члени не тільки відкрито висловлюють свої думки, а й виражають свої почуття;

конфлікти й розбіжності обов'язково мають місце, але пов'язані виключно з ідеями, а не з особистостями.

Команда припускає спільну роботу її членів. Залежно від характеристик проекту, фахового рівня виконавців, індивідуальних здібностей менеджера проекту можливі такі типи спільної діяльності:

тип спільної взаємодії;

спільно-послідовний тип;

спільно-індивідуальний тип;

спільно-творчий тип.

Спільна взаємодія характеризується обов'язковістю участі кожного члена команди у вирішенні проектних завдань. Цей тип передбачає приблизно однаковий фаховий рівень членів команди, а також однаковий рівень інтенсифікації праці. Для учасників організації цього типу характерна висока схильність до роботи в групі. Це дає добрі результати, коли члени команди добре розуміють один одного, довгий час працюють разом. Щодо видів проектів, у яких доцільно використовувати цей, то їх коло обмежується невеликими проектами з великою часткою невизначеності.

Спільно-послідовний тип організації роботи команди характеризується розподілом вступу членів КМП у роботу за часом. Тобто спочатку в роботу вступає один чи кілька членів команди, які передають виконану роботу іншим і т. д. Такий "естафетний" тип організації роботи відрізняється тим, що взаємодія між членами команди зводиться до процедур приймання та здавання послідовних проектних робіт. Для членів команди спільно-послідовного типу характерні висока технологічна дисциплінованість, чітке дотримання норм та правил.

Спільно-індивідуальний тип вирізняється зведенням до мінімуму взаємодії між членами групи. Члени такої команди вище за все висувають власні цінності, схильні до самостійної розробки шляхів досягнення мети та спроможні ефективно діяти в умовах внутрішньої конкуренції. Кожен з таких виконавців виконує свій обсяг завдань і подає результати своєї праці у встановленому вигляді та у визначений час.

Останнім часом у проектному менеджменті великої популярності набув спільно-творчий організаційний тип. Цей тип організації колективної діяльності сприяє високим кінцевим результатам там, де предметом проекту є щось нове, унікальне, що неможливо створити за наявними технологіями та діючими правилами. В таких командах створюється особливий тип діяльності, коли кожен їх учасник є рівноправним творцем нового. Для колективів, які належать до такого типу, основною метою стає отримання нових знань, їх приваблюють створення умов для індивідуального розвитку.

 

 

Системи контролю проектів

Контроль проекту — це елемент, який забезпечує відповідність проекту графіку виконання та бюджету. Контроль проекту починається з планування та закінчується звітом з виконання проекту, пронизуючи кожен елемент процесу управління проектом. Кожен проект має бути оцінений щодо рівня необхідного контролю: забагато контролю означає втрату часу, замало контролю означає збільшення ризиків. Якщо контроль проекту впроваджений не вірно, вартість для бізнесу пояснюється у термінах помилок, виправлень та додаткових витрат на аудит. Системи контролю необхідні для витрат, ризиків, якості, комунікацій, часу, змін, закупівель та людських ресурсів. До того ж аудитори мають визначити наскільки проекти впливають на фінансову звітність, наскільки достовірну інформацію отримують замовники і скільки точок контролю існує. Аудитори мають розглянути процес розробки та процедури на предмет способу впровадження. Процес виробництва та якість кінцевого продукту також може бути оцінений, якщо така потреба виникає. Бізнес може забажати від аудиторської фірми фіксування проблем на ранніх етапах з метою зменшення зусиль необхідних на виправлення. Аудитор може виступати як консультант з контролю, частина проектної команди або як окремий аудитор, частина аудиту. Бізнес іноді використовує формалізовані процеси розробки систем. Це допомагає підтвердити успішність розробки. Формальний процес більш ефективний у створенні сильних точок контролю. Аудитори мають перевірити такий процес та підтвердити його якісну організацію та відповідність практиці. Гарний формальний план впровадження системи характеризує:

· Стратегія, задля приведення розробки до більш загальних цілей організації.

· Стандарти для нових систем.

· Політики управління проектом щодо часу та бюджету.

· Процедури, що описують процес.

· Оцінка якості змін.

Важливе місце в системі контролювання займає процес звітування.

Для організації відповідної системи звітування потрібно додержуватися таких принципів:

1. Система звітування має бути побудована таким чином, аби подавати менеджеру кожного рівня інформацію, релевантну його функціям і відповідальності, — не більше і не менше. При підготовці звітів слід давати більш детальну додаткову інформацію та аналіз по тих показниках, де є відхилення від плану.

2. Систему інформування і звітування треба будувати у розрізі WBS i OBS. Більш докладна інформація надається по відхиленнях для того, щоб сконцентрувати увагу і зусилля на проблемах, які справляють значний вплив на витрати й час виконання проекту.

3. Система інформування і звітування має ґрунтуватися на чіткій системі кодування у розрізі WBS, OBS, CBS. Це дає змогу у подальшому комбінувати і консолідувати необхідні показники (у розрізі робіт або підрозділів).

4. Основним елементом системи інформування і звітування під час здійснення контролю має бути звіт про витрати.

5. Потрібно побудувати систему звітів. Завдяки цьому керівництво компанії одержує консолідовані звіти по всіх проектах, що виконуються, замовники і партнери — звіти по відповідних проектах, менеджер групи креслень — по всіх проектах, у яких задіяно цю групу, і т. ін.

6. Система звітування має бути пристосованою до відстеження і виявлення джерела негативних відхилень.

Друга проблема — контроль за змінами у проекті. Зміни в обсягах проекту — чи не одна з найголовніших причин зростання вартості проекту і збільшення часу його виконання. Дуже часто ці зміни підвищують витрати на 50 % і більше. Тому однією з найважливіших і, на жаль, не дуже приємних функцій менеджера проекту є контроль за змінами у проекті.

Ці зміни впливають на виконання проекту таким чином: підвищують затрати; спричиняються до затримки виконання проекту; знижують продуктивність праці виконавців робіт; погіршують стосунки між членами команди.

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

Зміни можуть виникати на будь-якій стадії виконання проекту і мати такий зміст і наслідки:

1. Зміни у конструкції або обсягу проекту на стадії розроблення. Це природно, але дуже часто вони приймаються без належної оцінки наслідків у розрізі часу і вартості. Після затвердження конструкції ці зміни виявляються надто дорогими.

2. Пізні зміни у конструкції. Це зміни, які коштують найбільш дорого. Вони виникають як наслідок помилок на стадії розробки конструкції або намагань замовника відповідно до вимог часу використати новітні досягнення у технології, що призведе до збільшення обсягу робіт.

3. Зміни на вимогу безпеки або законодавства. Їх керівники проекту зобов’язані робити.

4. Зміни для підвищення прибутковості та фінансової віддачі від проекту (результати їх досить проблематичні). Питання про доцільність цих змін вирішується вищим керівництвом компанії відповідно до її політики. Дуже важко точно обчислити вартість змін і майбутні грошові потоки, NPV та IRR.

5. Зміни — це значна сфера конфліктів, особливо всередині компанії. Менеджери з виробництва прагнуть внести свої зміни, інколи доцільні, інколи надмірні; конструктори — свої (наприклад, у розмірах устаткування). Зусилля менеджера проекту спрямовані на усунення недоцільних змін і встановлення чіткої межі між «повинно» і «бажано», запровадження тільки тих змін, які необхідні для виконання визначених обсягів і вимог безпеки.

Для контролю за змінами і послаблення конфліктів усередині та між компаніями потрібно домагатися того, щоб: вище керівництво підтримувало менеджерів проекту у забороні бажаних, але необов’язкових змін; менеджери проекту чітко визначали початкову конструкцію та обсяги робіт за проектом; на певній стадії проекту припинялися будь-які зміни, тобто «заморожувався» проект; що раніше це відбудеться, то меншими будуть витрати і часові наслідки внесення змін; була запроваджена система контролю за змінами.

Система контролю за змінами вирішує такі завдання:визначає зміни відносно початкового обсягу;прогнозує витрати, час і вплив цих змін на інші роботи;фіксує інформацію щодо їх запровадження; інформує про них вище керівництво; запроваджує систему вирішення суперечностей з мінімальними конфліктами.

Систему контролю за змінами інколи називають «прогнозуванням трендів», «контролем відхилень», «контролем за формами». Дуже важливо запровадити її якомога раніше. За цією системою готуються тижневі або місячні огляди на стадіях конструювання і постачань. Контроль здійснюється за допомогою оперативного звітування щодо змін та обговорювання їх необхідності і наслідків (стосовно затрат і часу) у колі провідних спеціалістів. Для створення системи контролю за змінами треба зробити такі кроки:

Встановити початковий обсяг, специфікацію, параметри, визначити графік виконання проекту.

Визначати зміни стосовно до початкових показників, повідомляти про них тих, кого це стосується, й оцінювати їхні наслідки.

Аналізувати, приймати або відхиляти ці зміни.

Запроваджувати ці зміни.

РОБОЧА СТРУКТУРА ПРОЕКТУ

Структура декомпозиції робіт (англ. Work breakdown Structure - WBS) — це деревовидна структура, що показує розподіл завдань необхідних для досягнення цілі / виконання завдання; наприклад, програма, проект та контракт. WBS може бути орієнтована на апаратну частину, продукт, сервіс чи процес.

WBS може бути розроблена шляхом послідовного поділу кінцевої цілі / завдання на компоненти, що підлягають управлінню, з огляду на розмір, тривалість та відповідальність (наприклад, системи, підсистеми, компоненти, завдання, під завдання, пакети робіт), та містять усі кроки необхідні для виконання завдання.

Структура декомпозиції робіт забезпечує основу для природного впровадження загального планування та контролю контракту, та є базисом для поділу роботи на етапи з яких можуть бути виділені завдання і може бути впроваджена технічна, календарна, витратна звітність та звітність на підставі людино-годин.

WBS створюється за допомогою поділу проекту на основні елементи, частини, послуги на логічній основі. Ці елементи, в свою чергу, поділяються на свої елементи, і цей процес повторюється доти, доки на нижчому рівні WBS елемент можна поділити на роботи, які мають виконуватись окремими групами. Кожного разу, як проект і його елементи поділяються, створюється так званий рівень. Таким чином, WBS — це ієрархічна структура, побудована з метою логічного розподілу усіх робіт з виконання проекту і подана у графічному вигляді. Це сукупність декількох рівнів, кожний з яких формується в результаті розподілу роботи попереднього рівня на її складові. Елементом найнижчого рівня є група робіт, або так званий робочий пакет (work package).

Для одного й того самого проекту можна створити декілька WBS з різною кількістю рівнів та елементів на кожному рівні. Тому для фірми доцільно створити для окремих типів проектів стандартні формати їх WBS.

Основні принципи застосування WBS полягають у такому:

Кожний елемент WBS є таким підрозділом проекту, до якого можна застосувати управління, планування і контроль. Це дискретна частина проекту зі своїми власними постачальниками, планами, системою контролю й аналізу виконання з погляду витрат, ресурсів, дотримання графіка.

Проект розбивається на кілька рівнів. Найнижчий рівень WBS створюється найменшими дискретними частинами проекту, які потребують планування і контролю як інтегрованого цілого. Елементи цього найнижчого рівня WBS не мають подальшої структуризації, хоча під час виконання вони можуть бути розподілені на роботи для окремих груп виконавців, кожна з яких планується і контролюється як окрема одиниця.

Немає необхідності ділити кожний основний елемент проекту на однакову кількість рівнів. Цей поділ має служити розумним цілям і виконуватися помірковано.

Кожний елемент вищого рівня WBS є складовою проекту, яка планується і контролюється як інтегроване ціле. Це потребує поєднання планування і контролю елементів нижчого рівня («дітей») та елементів більш високого рівня (їхніх «батьків»).

Кожний рівень у структурі — це рівень, на якому управління проектом потребує збору й аналізу контрольної інформації і кожний елемент цього рівня має свій аналіз виконання і звіт.

На практиці не потрібно ділити проект знову і знову, щоб створювати велику кількість рівнів заради самої структури. Кожний рівень має бути значним, логічним і необхідним для управління, планування і контролю проекту. Тому існує обмеження у глибині розбивки для користі управління проектом. Кожний рівень запроваджує інформацію на інтегровану частину проекту, можливо, для різних людей на різних рівнях управлінської ієрархії. Ця інформація має розглядатися як необхідна для ефективного управління проектом. Кожний додатковий рівень WBS значно збільшує обсяг інформації, яка збирається, роботи з паперами і потрібними звітами, але скорочує обсяг діяльності функціональних груп.

Для більшості проектів характерною є кількість рівнів від чотирьох до шести. У простих випадках достатньо двох рівнів. Розбивка до трьох рівнів може бути у разі, якщо це слугує справі. Це може бути при реалізації великих проектів, де кожний елемент третього рівня є значним за розміром або важливим і менеджер вважає, що потрібно мати інтегровані планування і контроль для елементів цього нижчого рівня проекту.

У великих проектах, до основних елементів яких залучаються окремі компанії-виконавці або організаційні одиниці, можуть бути дві групи WBS: одна — для проекту в цілому, і одна або більше — для індивідуальних виконавців (компаній) або організаційних одиниць.

Інтегрована робота, яка є спільною для більш ніж одного елементу WBS на будь-якому одному її рівні, постає як окремий елемент WBS. Проте робота, що є унікальною для одного елементу, включається у цей елемент як його складова на нижчому рівні.

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

Основні етапи розробки WBS:

• визначення ступеня деталізації проектних робіт (так, щоб вони піддавались оцінці);

• визначення кількості рівнів (як правило три-чотири, для сучасних компаній — чотири оптимально);

• розробка структури кожного рівня (формуються горизонтальні рівні);

• підготовка опису елементів WBS (стисла назва кожної складової WBS);

• формування системи кодування (кодуються всі блоки);

• проведення зворотних обчислень (затрати знизу догори за принципом: відділ локалізації — субпідрядник).

Як зазначалося, для одного і того самого проекту можна створити кілька WBS із різною кількістю рівнів та елементів на кожному рівні залежно від принципу, який покладається в основу розбивки проекту на його складові. Тому фірмі доцільно створити для окремих типів проектів стандартні формати їх WBS.

WBS формуються:

за продуктами або субпроектами (субпроект 1 — субпроект 2 — субпроект 3);

за фазами проекту (проектування — будівництво — приймання);

за місцем виконання робіт (фундамент — зовнішні роботи — внутрішні роботи);

за центрами затрат (компанія 1 — компанія 2 — компанія 3).

Для створення WBS структуризація може провадитися за такими рівнями:

рівень 1 — проект;

рівень 2 — стадії або субпроекти;

рівень 3 — системи або блоки;

рівень 4 — робочі пакети.

На нижчому рівні робочої структури проекту знаходиться робочий пакет (work package, табл.). Він являє собою групу робіт чи операцій, які піддаються оцінці з погляду визначення затрат і наділення ресурсами, тривалості виконання та призначення відповідального і має такі характеристики: обсяг і перелік робіт, які треба виконати; відповідального за виконання робочого пакету; бюджет; потрібні ресурси; дати початку і кінця.

На рис. наведено приклад трирівневої робочої структури проекту зі створення комп’ютерного центру в організації. Перший рівень — це сам проект, другий — це субпроекти, сформовані за продуктовим принципом: забезпечення кадрами, технічне забезпечення, програмне забезпечення і управління проектом. На третьому рівні WBS перебувають робочі пакети для перших трьох субпроектів, а управління проектом не деталізується. Тобто слід підкреслити, що глибина розбивки за певними блоками може бути різною.

 

WBS може застосовуватися для поєднання робіт, які необхідно виконати, організаційних структур і відповідальності за роботу з підсистемами планування, оцінки, розподілу витрат і ресурсів, аналізу, контролю і звіту в єдину взаємопов’язану інтегровану систему управління проектом.

 

 

Діаграма Ганта

 

Діаграма Ганта (англ. Gantt chart, також стрічкова діаграма, графік Ганта) - це популярний тип діаграм, який використовується для ілюстрації плану, графіка робіт за будь-яким проектом. Є одним з методів планування та управління проектами.

Перший формат діаграми був розроблений Генрі Л. Гантом у 1910 році.

Діаграма Ганта представляє собою відрізки (графічні плашки), розміщені на горизонтальній шкалі часу. Кожен відрізок відповідає окремому завданню або підзадачі. Завдання і підзадачі, складові плану, розміщуються по вертикалі. Початок, кінець і довжина відрізка на шкалі часу відповідають початку, кінцю і тривалості завдання. На деяких діаграмах Ганта також показується залежність між завданнями. Діаграма може використовуватися для представлення поточного стану виконання робіт: частина прямокутника, що відповідає завданню, заштриховується, відзначаючи відсоток виконання завдання; показується вертикальна лінія, що відповідає моменту «сьогодні».