fbpx

Сучасні методи управління проектами

Печать

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

Всі проекти різні. Не існує ідеальної системи управління проектами, що підходить для кожного з видів проектів. Також не існує системи, яка б підходила кожному керівнику і була зручна для всіх членів команди. Однак за час існування проектного управління було створено чимало ефективних підходів, методів і стандартів, які можна взяти на озброєння.

На даному етапі розвитку науки управління проектами виділяють такі методи управління проектами:

  1. Класичний проектний менеджмент.
  2. Agile.
  3. Scrum.
  4. Lean.
  5. Kanban.
  6. Six Sigma.
  7. PRINCE2.

*Джерело: "Старченко Г. В. Управління проектами: теорія та практика : навч. посіб. / Г. В. Старченко. – Чернігів : видавець Брагинець О. В., 2018. – 306 с. " 

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

Найбільш очевидний шлях реалізації проекту – розбити його на фази або окремі завдання. Найпростіший інструмент проектного управління є чек-лист дій, які необхідно зробити для досягнення мети. Одним із інструментів, що дозволяє відстежувати часові витрати на кожен з елементів і час, коли вони повинні бути завершені є Діаграма Ганта (див. рис. 1).

 

 Рис. 1. Фрагмент діаграми Ганта 

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

Перший формат діаграми був розроблений Генрі Л. Гантом (Henry L. Gantt, 1861-1919) у 1910 році.

 

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

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

 

Рис. 2. Діаграма Ганта (MS Project 2016)   

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

Розглянемо докладніше основні методи управління проектами.

  1. Класичний проектний менеджмент. Найбільш широко поширений метод управління проектами, заснований на так званому «водоспадному» (Waterfall) або каскадному циклі, при якому завдання передається послідовно по етапах, що нагадує потік, схематично це зображено на рис. 3.

Рис. 3. Схема класичного проектного управління  

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

Зазвичай виділяють 5 етапів класичного проектного управління, але можна додавати і додаткові етапи, якщо того вимагає проект.

5 етапів традиційного менеджменту:

Етап 1. Ініціація. Керівник проекту і команда визначають вимоги до проекту. На даному етапі часто проводяться наради та «Мозкові штурми», на яких визначається що ж повинен представляти із себе продукт проекту.

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

Етап 3. Розробка. Дана стадія реалізується не для всіх проектів – як правило вона є частиною фази планування. У фазі розробки, характерною для технологічних проектів, визначається конфігурація майбутнього проекту і / або продукту і технічні способи його досягнення. Наприклад в ІТ-проектах на даному етапі вибирається мова програмування.

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

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

Для різних проектів потрібні різні фази реалізації – декому достатньо і трьох фаз, іншим набагато більше. Іноді використовується так званий «ітеративний водоспад», в якому кожен етап являє собою якийсь підпроект, в ході якого завдання реалізуються за фіксованими ітераціями. Але суть залишається одна – проект розбитий на етапи, які виконуються в строго певній послідовності.

Завдяки тому, що класичний проектний менеджмент строго прив'язаний до часу виконання завдань, як правило, заздалегідь визначеному на етапі планування, для реалізації проектів в рамках даного підходу відмінно підходять інструменти календарно-сітьового планування.

Найпоширенішим інструментом календарно-сітьового планування є вже згадана раніше діаграма Ганта. Існує безліч інструментів для її побудови – від простих таблиць таких як Excel до професійних програмних пакетів таких як Microsoft Project і Primavera.

Сильні сторони класичного проектного менеджменту

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

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

Слабкі сторони класичного проектного менеджменту

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

  1. Agile. Гнучкий ітеративно-інкрементальний підхід до управління проектами і продуктами, орієнтований на динамічне формування вимог і забезпечення їх реалізації в результаті постійної взаємодії всередині самоорганізованих робочих груп, що складаються з фахівців різного профілю. Існує безліч методів, які базуються на ідеях Agile, найпопулярніші з яких - Scrum і Kanban.

Не всі проекти можуть бути структуровані таким чином, щоб бути реалізованими за класичним проектним підходом. Наприклад, приготування однієї страви ідеально лягає на «водоспадний» підхід, а ось вчасно приготувати і подати вечерю з чотирьох страв буде практично неможливо, якщо доведеться кожного разу чекати закінчення приготування однієї страви, щоб приступити до приготування іншої. В такому випадку можна використовувати Agile. Відповідно до даного підходу, проект не розбивається на послідовні фази, він розбивається на маленькі підпроекти, які потім «збираються» в готовий продукт (див. рис. 4).

 

 

Рис. 4. Схема управління проектом по  Agile 

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

Свою нинішню назву сімейство гнучких методологій отримало в 2001 році з публікації Маніфесту Agile (Agile Manifesto), закріпив основні цінності і принципи гнучкої розробки програмного забезпечення, в основі яких – командна робота і адаптація, навіть «любов» до змін.

Сам по собі Agile – це скоріше набір ідей і принципів того, як потрібно реалізовувати проекти. Вже на основі цих принципів і кращих практик були розроблені окремі гнучкі методи або, як їх іноді називають, фреймворки (frameworks): Scrum, Kanban, Crystal, і багато інших. Ці методи можуть досить сильно відрізнятися один від одного, але вони використовують однакові принципи.

Сильні сторони Agile

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

Один із принципів Agile: «Реакція на зміни важливіша за проходження плану». Крім того, Agile добре підходить для проектів з «відкритим кінцем» – наприклад, запуску сервісу або блогу, розробка нових, інноваційних продуктів. У таких проектах висока частка невизначеності, а інформація про продукт розкривається по ходу проекту. В таких умовах реалізовувати проект по «водоспаду» стає неможливо.

Слабкі сторони Agile

Agile – це набір принципів і цінностей. Слабка сторона полягає в тому, що кожній команді доведеться самостійно складати свою систему управління, керуючись принципами Agile. Це непростий і тривалий процес, який потребує змін всієї організації, починаючи з процедур і закінчуючи базовими цінностями. Не всім організаціям він під силу.

  1. Scrum. Scrum розбиває проект на частини, які відразу можуть бути використані Замовником для отримання цінності, які називаються заділами продуктів (product backlog). Потім ці частини розбиваються за пріоритетом власником продукту – представником замовника в команді. Найважливіші «частини» першими відбираються для виконання в спринті (ітерації в Scrum), що тривають від 2 до 4 тижнів. В кінці спринту замовнику видається робочий інкремент продукту – найважливіші «частини», які вже можна використовувати. Наприклад, сайт з частиною функціоналу або програма, яка вже працює, нехай і частково. Після цього команда проекту приступає до наступного спринту. Тривалість у спринті фіксована, але команда вибирає її самостійно на початку проекту, виходячи з проекту і власної продуктивності.

Щоб упевнитися в тому, що проект відповідає вимогам замовника, які мають властивість змінюватися з часом, перед початком кожного спринту відбувається переоцінка ще не виконаного змісту проекту і внесення в нього змін. У цьому процесі бере участь вся команда проекту. Scrum Майстер покликаний допомогти учасникам проекту краще зрозуміти і прийняти цінності, принципи і норми практики Scrum. Він лідер і посередник між зовнішнім світом і командою. Його завдання – стежити, щоб ніхто не заважав команді самостійно і комфортно працювати над поставленими завданнями. Команда ж відповідає за те, щоб в кінці спринту всі необхідні завдання були зроблені, а поставки виконані (див. рис. 5).

Рис. 5. Схема процесу Scrum 

Основна структура процесів Scrum обертається навколо 5 основних зустрічей (фаз/процесів): упорядкування беклогу, планування спринту, щоденна літучка, підведення підсумків спринту і ретроспективи спринту.

Зустріч з упорядкування беклогу (Backlog Refinement Meeting, «Backlog Grooming»): ця зустріч аналогічна фазі планування в класичному проектному управлінні, і проводиться в перший день кожного спринту. На ній розглядається – що вже було зроблено по проекту в цілому, що ще залишилося зробити і приймається рішення про те, що ж робити далі. Власник продукту визначає, які завдання на даному етапі є найбільш пріоритетними. Даний процес визначає ефективність спринту, адже саме від нього залежить, яку цінність отримає замовник за підсумками спринту.

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

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

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

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

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

Сильні сторони Scrum

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

Слабкі сторони Scrum

Scrum дуже вимогливий до команди проекту. Вона повинна бути невеликою (5-9 чоловік) і кросфункціональною – тобто члени команди повинні володіти більш ніж однієї компетенцією, необхідної для реалізації проекту. Наприклад розробник програмного забезпечення повинен володіти знаннями в тестуванні і бізнес-аналітиці. Робиться це для того, щоб частина команди не «простоювала» на різних етапах проекту, а також для того, щоб співробітники могли допомагати і підміняти один одного.

Крім того, члени команди повинні бути «командними гравцями», активно брати на себе відповідальність і вміти самоорганізовуватися. Підібрати таку зрілу команду дуже непросто.

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

  1. Lean. Agile говорить нам, що необхідно розбивати на невеликі керовані пакети робіт, але нічого не говорить про те, як управляти розробкою цього пакету. Scrum пропонує нам свої процеси і процедури. Lean ж, в свою чергу, додає до принципів Agile схему потоку операцій (workflow) для того, щоб кожна з ітерацій виконувалася однаково якісно.

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

 

Рис. 6. Схема процесу Lean 

Етапи Lean і їх гнучкість дозволяють бути впевненими в тому, що кожна частина проекту реалізується так, як потрібно. У Lean не прописані чіткі межі етапів, як в Scrum прописані обмеження спринтів. Крім того, на відміну від класичного проектного менеджменту, Lean дозволяє паралельно виконувати кілька завдань на різних етапах, що підвищує гнучкість і збільшує швидкість виконання проектів.

Як і Agile, Lean це скоріше концепція, образ мислення, ніж щось висічене в камені. Використовуючи ідеї Lean можна самостійно створити систему, що задовольняє вимогам в управлінні проектами.

Сильні сторони Lean

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

Слабкі сторони Lean

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

  1. Kanban. Lean виглядає трохи абстрактним сам по собі, але в комбінації з Kanban його стає набагато простіше використовувати для побудови власної системи управління проектами. Створений інженером компанії Toyota Taiichi Ono в 1953 році, Kanban дуже схожий на схему промислового виробництва. На вході в цей процес потрапляє шматочок металу, а на виході виходить готова деталь. Також і в Kanban, інкремент продукту передається вперед з етапу на етап, а в кінці виходить готовий до постачання елемент.

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

Kanban не обмежує час спринтів, немає ролей, за винятком власника продукту. Kanban навіть дозволяє члену команди вести кілька завдань одночасно, чого не дозволяє Scrum. Також ніяк не регламентовані зустрічі за статусом проекту – можна робити це як зручно, а можна не робити взагалі.

Для роботи з Kanban необхідно визначити етапи потоку операцій (workflow). У Kanban вони зображуються як стовпці, а завдання позначають спеціальні картки. Картка переміщається по етапах, подібно деталі на заводі, що переходить від верстата до верстата, і на кожному етапі відсоток завершення стає вище. На виході ми отримуємо готовий до постачання замовнику елемент продукту. Дошка зі стовпцями і картками може бути як справжньою, так і електронною – навіть тут Kanban не накладає ніяких обмежень на користувачів.

 

Рис. 7. Схема процесу Kanban 

У Kanban є 4 стовпи, на яких тримається вся система:

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

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

Безперервний потік: Завдання з беклога потрапляють в потік в порядку пріоритету. Таким чином, робота ніколи не припиняється.

Постійне поліпшення «кайзен» (kaizen): Концепція постійного поліпшення з'явилася в Японії в кінці XX століття. Її суть в постійному аналізі виробничого процесу та пошуку шляхів підвищення продуктивності.

Сильні сторони Kanban

Як і Scrum, Kanban добре підходить для досить згуртованої команди з хорошою комунікацією. Але на відміну від Scrum, в Kanban немає встановлених чітких дедлайнів, що добре підходить для мотивованих і досвідчених команд.

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

Слабкі сторони Kanban

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

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

Спочатку метод розроблявся компанією «Motorola» та її інженером Білом Смітом (з 1986 року), але зараз ним користуються багато компаній. Значний вплив на його розвиток справили попередні концепції вдосконалення якості продукції, наприклад методології контролю якості, тотального управління якістю (Total Quality Management – TQM) та нульових дефектів.

Це більш структурована версія Lean ніж Kanban, в яку додано більше планування для економії ресурсів, підвищення якості, також зниження кількості браку і дефектів.

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

Для цього було запропоновано процес з 5 кроків, відомих як DMEDI:

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

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

Дослідження (Explore): на стадії дослідження менеджер проекту вирішує, яким же чином команда може досягти поставлених цілей і виконати всі вимоги в строк і в рамках бюджету. На даному етапі дуже важливо нестандартне мислення керівника проектів при вирішенні проблем, що виникли.

Розробка (Develop): на даному етапі реалізуються плани і рішення, прийняті на попередніх етапах. Важливо розуміти, що на даному етапі необхідний детальний план, в якому описані всі дії, які потрібні для досягнення поставлених цілей. Також на даному етапі вимірюється прогрес проекту.

Контроль (Control): ключовий етап в методології 6 сигм. Його основне завдання – довгострокове поліпшення процесів реалізації проектів. Даний етап вимагає ретельного документування витягнутих уроків, аналізу зібраних даних і застосування отриманих знань як в проектах, так у всій компанії в цілому.

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

Сильні сторони 6 сигм

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

 

Рис. 8. Схема процесу Six Sigma 

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

Слабкі сторони 6 сигм

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

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

  1. PRINCE2. Британський Уряд давно оцінив ефективність проектного управління, і в 1989 році була створена британська методологія PRINCE2. Назва походить від акрониму «PRojects IN Controlled Environments version 2», що перекладається як «Проекти в контрольованому середовищі версія 2». На відміну від гнучких методів, PRINCE2 не використовує ітеративний підхід до проекту. Якщо порівнювати PRINCE2 іншими методами, то його можна порівняти з гібридом класичного підходу до проектного управління та концентрації на якості з 6 сигм (див. рис. 9).

Методологія PRINCE2 на відміну від  PMBOK не містить:

– спеціалізованих аспектів управління проектом, наприклад, галузевих;

– конкретних практик та інструментів управління проектами, таких як діаграма Гантта, WBS і т.п.

PRINCE2 концентрується на управлінських сторонах проекту, виражених в 7 принципах, 7 процесах і 7 темах проекту.

 

Рис. 9. Схема процесу PRINCE2 

7 принципів визначають загальні правила управління проектами по PRINCE2, визначають базу методології;

7 процесів визначають кроки просування по проектному циклу;

7 тем – аспекти, за якими проводиться контроль для досягнення успіху проекту.

Крім того, PRINCE2 рекомендує адаптувати методологію під кожну конкретну організацію.

На початку проекту PRINCE2 пропонує нам визначити 3 основних аспекти проекту:

– Бізнес-аспект (Чи принесе цей проект вигоду?)

– Споживчий аспект (Який потрібен продукт, що ми будемо робити?)

– Ресурсний аспект (достатньо у нас всього, щоб досягти мети?)

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

Згідно PRINCE2 у кожного члена команди є своя чітка роль в кожному з 7 процесів (див. рис. 10):

– Початок проекту (Starting up a project): у ході даного процесу призначається менеджер проекту і визначаються загальні вимоги до характеристик продукту. Менеджер проекту, чиє основне завдання – увага до деталей, звітує перед керуючим комітетом проекту, який відповідає за загальне керівництво проектом. Саме керівний комітет стежить за тим, щоб проект не збився з курсу, і він же повністю відповідає за успіх проекту.

Ініціація проекту (Initiation a project): у ході даного процесу менеджер проекту складає «Документацію по ініціації проекту», в якій міститься план проекту за стадіями. Стадії можуть тривати різну кількість часу, але, як і в класичному підході, вони слідують строго одна за одною.

 

Рис. 10. Схема ролей в PRINCE2 

Керівництво проектом (Directing a project): даний процес надає можливість керуючому комітету нести спільну відповідальність за успіх проекту, не заглиблюючись в деталі, які знаходяться в межах повноважень менеджера проекту.

Контроль стадії (Controlling a stage): при реалізації проекту, навіть в ідеальних умовах, будуть вноситися певні зміни. Процес «Контроль стадії» реалізує один з принципів PRINCE2 – принцип управління за винятками. В обов'язки менеджера проекту входить відстежувати в ході виконання стадії відхилення від планових параметрів проекту щодо термінів, змісту, бюджету та ін. Якщо ці відхилення перевищують дані керівнику проекту керуючим комітетом повноваження (в термінології PRINCE2 – допуски), менеджер проекту зобов'язаний проінформувати комітет з управління та запропонувати шляхи виходу із ситуації.

Управління створенням продукту (Managing Product Delivery): процес управління виробництвом продукту є взаємодією менеджера проекту і менеджера команди зі створення одного з продуктів проекту. В обов'язки менеджера проекту в даному процесі входить делегування повноважень по створенню продукту менеджеру команди і приймання створеного продукту.

Управління кордонами стадії (Managing a stage boundary): у ході даного процесу менеджер проекту надає керуючому комітету всю необхідну інформацію для оцінки результатів пройденої стадії і прийняття рішення про перехід на наступну стадію.

Завершення проекту (Closing a project): одна з відмінностей PRINCE2 в тому, що процес завершення проекту не виділяється в окремий етап або стадію, як в класичному підході, а виконується в рамках фінальної стадії створення продукту. Мета процесу – підтвердити, що продукт проекту прийнятий, або проект не може принести нічого корисного.

PRINCE2 може бути адаптований для проектів будь-якого масштабу і будь-який предметної області. Методологія пропонує конкретні рекомендації щодо зміни життєвого циклу проекту, рольової моделі і набору обов'язкових документів відповідно до потреб проекту.

 

Сильні сторони PRINCE2

– Адаптованість до особливостей організації;

– наявність чіткого опису ролей і розподілу відповідальності;

– акцент на продуктах проекту;

– певні рівні управління;

– фокус на економічній доцільності;

– послідовність проектної роботи;

– акцент на фіксації досвіду і постійного вдосконалення.

Слабкі сторони PRINCE2

– Відсутність галузевих практик;

– відсутність конкретних інструментів для роботи в проекті.

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


При використанні матеріалів сайту обов'язково вказуйте джерело!