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

Існує певна кількість методів управління проектними активностями, включаючи Еджайл (англ. Agile), інтерактивні, послідовні та методи розподілу на етапи.

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

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

Типові етапи виконання проекту

1. Ініціювання.
2. Планування та розробка.
3. Виконання та впровадження.
4. Моніторинг та контроль.
5. Завершення.

Не всі проекти проходять кожен з етапів, так як проект може бути припинений до того як буде завершений. Деякі проекти не мають етапів структурованого планування та/або моніторингу. Деякі проекти проходять стадії 2, 3 і 4 декілька разів.

Багато галузей використовують варіації зазначених етапів. Наприклад, будівельні проекти зазвичай проходять через приблизно такі етапи: Попереднє планування, Концептуальне проектування, Схематичне проектування, Розробка проекту, Будівельні креслення (або Договірні документи) та Управління будівництвом. В розробці програмного забезпечення цей підхід відомий під назвою, дослівно, «модель водоспада», (англ. waterfall model), наприклад, друга група завдань виконується після першої в лінійній послідовності. Для «моделі водопада» використовуватимемо назву «послідовна модель». З метою адаптації послідовної моделі при розробці програмного забезпечення багато організацій використовують методологію Раціональних уніфікованих процесів (англ. Rational Unified Process - RUP). RUP не вимагає та однозначно не вказує на необхідність використання послідовної моделі. Використання послідовної моделі управління проектами ефективне для невеликих, визначених проектів, але для більш великих, невизначених та нових проектів зазначена модель часто призводить до негативних результатів. «Конус невизначеності» (англ. Cone of Uncertainty) пояснює таке явище тим, що планування, яке виконується на початкових етапах проекту є не ефективним через значний ступінь невизначеності. Це особливо актуально для розробки програмного забезпечення, оскільки така розробка часто є новим продуктом. В проектах, де вимоги не були завершені і можуть змінюватися, використовується управління вимогами з метою розробки точного і повного визначення поведінки програмного забезпечення, що може бути базисом для його розробки.^[17] Тоді як визначення можуть змінюватися в залежності від галузі, фактичні етапи зазвичай відповідають загальним крокам вирішення проблем (англ. problem solving) — «ідентифікація проблеми, оцінювання варіантів вирішення, вибір шляху вирішення, впровадження та оцінювання».

Критичний шлях управління проектом (англ. Critical Chain Project Management - CCPM) — це метод планування та управління проектами, який на перше місце ставить управління ресурсами (фізичними та людськими), необхідними для виконання завдань проекту. Фактично це доповнення Теорії обмежень (англ. Theory of Constraints - TOC) для проектів. Головним завданням є підвищення продуктивності (або збільшення відсотку завершених завдань) проектів в організації. Застосовуючи перші три з п'яти основних кроків TOC, системні обмеження для всіх проектів визначаються як ресурси. Щоб використовувати обмеження, завдання на критичному шляху отримують пріоритет вищий ніж інші активності. Загалом, проекти плануються та управляються таким чином, щоб ресурси були доступні, коли завдання критичного шляху мають розпочатися, підпорядковуючи усі інші ресурси завданням критичного шляху.

Незважаючи на тип проекту, план проекту має визначати розподілення ресурсів на рівні (англ. Resource Leveling). Найдовша послідовність ресурсно-обмежених завдань має бути визначена, як критичний шлях. В середовищах, що мають декілька проектів, розподілення ресурсів на рівні використовується в усіх проектах. Часто, досить визначити (чи просто обрати) один наскрізний ресурс — ресурс, що виступає як обмеження в усіх проектах та послідовно розташувати проекти відповідно до доступності цього ресурсу.

Цикли планування та зворотного зв'язку в Екстремальному програмуванні (анг. Extreme Programming — XP) з часовими межами повторюваних циклів.

В критичних оглядах Управління проектами зазначалося, що декілька методів управління проектами, які базуються на методиці Програми оцінки та контролю (англ. Program Evaluation and Review Technique – PERT), не в повній мірі відповідають мульти-проектному середовищу сучасних компаній. Більшість з таких компаній орієнтовані на масштабні, єдино разові, не повторювані проекти, в яких усі види управління використовують інструменти проектного управління.

Використання проектної моделі для «проектів», чи скоріше «завдань», що тривають декілька тижнів, на практиці призводить до непотрібних витрат та слабкої гнучкості. Замість використання класичного управління проектами, фахівці з управління проектами намагаються знайти різні «полегшені» методи (моделі), такі як методологія управління проектами Еджайл (англ. Agile Project Management — дослівно «швидке, рухливе» управління проектами), включаючи Екстремальне програмування (англ. Extreme programming) для розробки програмного забезпечення, а також техніки Скрам (англ. Scrum — дослівно, натовп, скупчення).

Узагальнення Екстремального програмування для застосування в інших видах проектів отримало назву Екстремальне проектне управління, що може бути використане разом з Побудовою процесів (англ. Process modeling) та принципами управління взаємодією людьми (англ. Human interaction management).

Управління послідовністю подій (англ. Event chain methodology) — це ще один метод, який доповнює методи критичного шляху (англ. Critical Path Method - CPM) та метод управління критичним шляхом (англ. Critical Chain Project Management - СCPM).

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

· Ймовірний момент ризику: Активність (завдання) в більшості реальних процесів не є тривалим безперервним процесом. На завдання впливають зовнішні події, які можуть виникнути на одному з етапів посередині виконання завдання.

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

· Критичні події або послідовності подій: Одиночні події або послідовності подій, що найбільш ймовірно зможуть вплинути на проект вважаються «критичними подіями» або «критичними послідовностями подій». Вони можуть бути визначені шляхом аналізу.

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

· Відображення послідовності подій: Події та послідовності подій можуть бути відображені, використовуючи діаграми послідовності подій на діаграмі Ганта.

Проекти в контрольованому середовищі (англ. Projects in controlled enviroments - PRINCE) — це структурований підхід до управління проектами, який був створений в 1996 році, як типовий метод управління проектами. ^[18] Фактично це комбінація методології PROMPT (що еволюціонувала в методологію PRINCE) з методологію IBM MITP (англ. Managing the implementation of the total project - MITP) — Управління впровадженням усього проекту). PRINCE2 пропонує метод управління проектами в рамках чітко визначеної структури організації. PRINCE2 описує процедури координації людей та активностей в проекті, як розробляти та контролювати проект та що робити, якщо необхідно внести зміни до проекту у зв'язку з відхиленням від плану впровадження.

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

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

Подальший розвиток концепції контролю в проектному управлінні призводить до об'єднання методик процесного управління (англ. Proces-based management). Ця сфера розвивається завдяки використанню Моделей зрілості (англ. Maturity models), таких як CMMI (англ. Capability Maturity Model Integration) — дослівно, Інтеграція моделі можливостей зрілості) та ISO/IEC15504 (англ. Software Process Improvment and Capability Estimation – SPICE), дослівно, Покращення процесу розробки програмного забезпеченя та оцінки можливостей). Підходи управління проектами Еджайл (англ. Agile project management) базуються на принципах управління взаємодією людей (англ. Human interaction management), що засновані на процесному підході до співпраці людей. Цей підхід дуже сильно відрізняється від традиційного. Розробка програмного забезпечення Едажайл чи Гнучка розробка продукту (англ. Flexible product development) розглядають проект, як послідовність невеликих завдань, які виникають та виконуються ситуативно, відповідно до вимог обставин. Ініціація та виконання є скоріше адаптивними до зовнішніх обставин, ніж завчасно повністю спланованим процесом.