Управління проектами

Матеріал з Вікіпедії — вільної енциклопедії.
Перейти до: навігація, пошук

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

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

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

Історія управління проектами[ред.ред. код]

Римські солдати будують фортецю, Колона Траяна 113 р. н.е.

Управління проектами практикувалося з початку виникнення цивілізації. До 1900 року творчі архітектори та інженери управляли інженерними проектами самотужки. Наприклад, Вітрувій (1 століття до н. е.), Кристофер Рен (1632–1723), Томас Телфорд (1757 — 1834) та Ісамбард Кінгдом Брюнель (1806 −1859).[6] З 1950 організації почали систематично використовувати інструменти та техніки проектного управління для керування складними проектами.[7]

Генрі Гант (1861–1919), батько технік планування та контролю

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

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

Мережева діаграма PERT для семимісячного проекту з п'ятьма ключовими подіями

В той час, коли розроблялися моделі планування, техніки для оцінки вартості проектів, завдяки проривним роботам Ганса Ланге та інших виникло Управління вартістю та Інженерна економіка. В 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 - IPMA) була заснована в Європі в 1967 р.,[13] як об'єднання декількох національних асоціацій проектного управління. IPMA й сьогодні зберігає федеральну структуру і зараз складається з членів-асоціацій на кожному континенті за виключенням Антарктиди. IPMA пропонує програму сертифікації, що складається з чотирьох рівнів, яка базується на основних компетенціях IPMA (англ. IPMA Competence Baseline - ICB).[14] Компетенції ICB включають технічні компетенції, контекстуальні компетенції та поведінкові компетенції.

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

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

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

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

Традиційний метод[ред.ред. код]

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

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

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

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

Багато галузей використовують варіації зазначених етапів. Наприклад, будівельні проекти зазвичай проходять через приблизно такі етапи: Попереднє планування, Концептуальне проектування, Схематичне проектування, Розробка проекту, Будівельні креслення (або Договірні документи) та Управління будівництвом.

В розробці програмного забезпечення цей підхід відомий під назвою, дослівно, «модель водоспаду», (англ. waterfall model),[16] наприклад, друга група завдань виконується після першої в лінійній послідовності. Для «моделі водоспаду» використовуватимемо назву «послідовна модель». З метою адаптації послідовної моделі при розробці програмного забезпечення багато організацій використовують методологію Раціональних уніфікованих процесів (англ. 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 - CCPM).

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

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

Проекти в контрольованому середовищі[ред.ред. код]

Модель процесів PRINCE2

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

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

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

Процесне управління[ред.ред. код]

Модель можливостей зрілості, попередник моделі CMMI

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

Групи процесів управління проектами[ред.ред. код]

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

Етапи виконання проектів.[19]

Групи процесів зазвичай включають:

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

Ініціювання[ред.ред. код]

Група процесів ініціювання.[19]

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

Етап ініціювання має містити план, що висвітлює такі питання:

  • Аналіз бізнес-потреб / вимог в вимірюваних показниках.
  • Огляд існуючих процесів.
  • Фінансовий аналіз витрат і доходів, включаючи бюджет.
  • Аналіз зацікавленими сторонами, включаючи користувачів, працівників підтримки проекту.
  • Устав проекту, включаючи витрати, завдання, результати та календарний план впровадження.

Планування та розробка[ред.ред. код]

Група процесів планування.[19]

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

Планування проекту загалом складається з:

  • Визначення «як планувати?» (наприклад, за рівнем деталізації чи етапами впровадження).
  • Розробка документу, що визначає зміст та межі проекту.
  • Визначення групи відповідальних, що плануватимуть проект.
  • Визначення результатів проекту та створення структури декомпозиції робіт.
  • Визначення завдань, які необхідно виконати для досягнення цілей проекту, та логічне послідовне об'єднання таких завдань.
  • Оцінка вимог до ресурсів для забезпечення виконання завдань.
  • Оцінка часу та витрат на виконання завдань.
  • Розробка календарного плану-графіку.
  • Розробка бюджету.
  • Планування ризиків.
  • Отримання формального погодження початку роботи.

Додаткові процеси, такі як планування комунікацій, визначення ролей та рівня відповідальності, закупівель в рамках проекту, а також проведення попередньої зустрічі учасників проекту (англ. Kick-off meeting) загалом є рекомендованими.

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

Виконання[ред.ред. код]

Група процесів виконання.[19]

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

Моніторинг та контроль[ред.ред. код]

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

Група процесів моніторингу та контролю.[19]

Моніторинг та контроль включає:

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

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

Підтримка проекту — це постійний процес, що включає:

  • Постійну підтримку кінцевих користувачів.
  • Виправлення помилок.
  • Оновлення програмного забезпечення.
Цикл моніторингу та контролю.

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

Наприклад, протягом впровадження будь-якого будівельного проекту зміст та межі проекту можуть змінюватися. Зміни — це нормальна та очікувана частина процесу будівництва. Зміни можуть бути результатом необхідних модифікацій конструкції, відмінностях будівельного майданчика, доступності матеріалів, змін за вимогою підрядної організації, впливом третіх сторін і т. д. Окрім впровадження змін, вони мають бути закріплені в документах, щоб відобразити кінцевий результат. Описаний процес отримав назву Управління змінами (англ. Change management ). Зазвичай власник вимагає остаточне документування змін, щоб зафіксувати усі зміни, а іноді, будь-яку зміну, що змінює матеріальні пакети завершеної роботи. Документування здійснюється за допомогою договірних документів, зазвичай, але не обов'язково, обмежуючись кресленнями. Кінцевий продукт такого процесу отримав назву, дослівно, «креслення, як побудовано» (англ. As-built drawing), чи більш спрощено, «Як побудовано» (англ. As built). Вимога щодо надання таких креслень є нормою будівельних договорів. Коли зміни внесені до проекту, життєздатність проекту має бути оцінена ще раз. Важливо не втратити початкових цілей та завдань проекту. Коли усі зміни зібрані, прогнозований результат може не виправдати інвестиції у проект.

Завершення[ред.ред. код]

Група процесів завершення проекту.[19]

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

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

Системи контролю проектів[ред.ред. код]

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

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

Теми з управління проектами[ред.ред. код]

Менеджер проекту[ред.ред. код]

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

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

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

Трикутник управління проектами[ред.ред. код]

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

Як будь-яке починання, проект виконується та завершується відповідно до певних обмежень. Традиційно такими обмеженнями вважаються «зміст та межі» (англ. Scope), «час» (англ. Time) та «вартість» (англ. Cost).[1] Такі обмеження отримали назву «Трикутник управління проектами», де кожна сторона є певним обмеженням. Одна сторона трикутника не може бути змінена, щоб не вплинути на інші сторони. Подальше уточнення обмежень відділяє «якість» (англ. Quality) чи «продуктивність» впровадження проекту від «змісту та меж» і перетворює якість в четверте обмеження.

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

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

Структура декомпозиції робіт[ред.ред. код]

Приклад Структури декомпозиції робіт, що використовується в структурі звітності NASA.[20]

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

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

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

Структура управління проектами[ред.ред. код]

Приклад структури управління IT проектами.[19]

Життєвий цикл Програми (Інвестиції) включає управління проектом та життєві цикли впровадження системи разом з активностями, пов'язаними з розгортанням системи та експлуатацією. Відповідно до концепції, управління експлуатацією системи та пов'язані активності, що виникають після завершення проекту, не визначені в цьому посібнику.[19]

Наприклад, див. діаграму, у Департаменті управління справами ветеранів Сполучених Штатів (англ. US United States Department of Veterans Affairs - VA) життєвий цикл управління програмою визначений та описаний в Структурі управління IT проектами VA, щоб інтегрувати проектні (інвестиційні) активності та проект в цілому в процес бюджетування. Діаграма «Структура управління проектами» ілюструє Етап 4, який виникає після розгортання системи та закриття проекту. Активності етапу закриття проекту в VA продовжуються протягом розгортання системи та переходять в етап експлуатації системи з метою відображення активностей, які вважаються частиною проекту. Діаграма показує дії та пов'язані артефакти процесу Управління IT проектами та програмами в VA.[19]

Міжнародні стандарти[ред.ред. код]

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

  • Модель Можливостей Зрілості (англ. Capability Maturity Model) — Інститут інженерів програмного забезпечення (англ. Software Engineering Institute).
  • Світова спільнота з Стандартів Ефективності Проектів (англ. Global Alliance for Project Performance Standards - GAPPS) — відкритий стандарт, що описує компетенції для менджерів проектів та програм.
  • Посібник з Управління проектами (англ. A Guide to the Project Management Body of Knowledge).
  • Метод Гермес (англ. HERMES method) — загальний метод управління проектами у Швейцарії, обраний для використання в Люксембурзі та міжнародних організаціях.
  • Стандарти ISO, ISO 9000 — сім'я стандартів щодо систем управління якістю, ISO 10006:2003, Системи управління якістю та посібник з управління якістю в проектах.
  • Prince2 (англ. Project in controlled Environments) — дослівно, проекти в контрольованих середовищах.
  • Процес розробки програмного забезпечення командою (англ. Team Software Process - TSP) — Інститут інженерів програмного забезпечення (англ. Software Engineering Institute).
  • Структура управління загальними витратами (англ. Total cost management framework) — міжнародна методологія AACE для Інтегрованого портфелю, Прграм та Управління проектами.
  • V-модель — метод розробки систем.
  • Метод логічної структури (англ. Logical framework approach) — метод, популярний в міжнародних девелоперських організаціях.
  • P2M (англ. A Guidebook of Project and Program Management for Enterprise Innovation) — стандарт по управлінню проектами, що базується на інноваційних програмах.

Управління портфелем проектів[ред.ред. код]

Зростаюча кількість організацій використовує так зване управління портфелем проектів (англ. Project portfolio management - PPM), як інструмент вибору пріоритетних проектів, після чого використовуються методи управління проектами,[21] як засіб узгодження ресурсних конфліктів (у випадках, коли кілька проектів конкурують за доступ до спільних ресурсів) і як засіб досягнення результатів у формі найкращої вигоди для організацій в цілому.

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

Програмне забезпечення для управління проектами[ред.ред. код]

Див. також[ред.ред. код]

Примітки[ред.ред. код]

  1. а б в Chatfield, Carl. «A short course in project management». Microsoft. 
  2. *The Definitive Guide to Project Management. Nokes, Sebastian. 2nd Ed.n. London (Financial Times / Prentice Hall): 2007. ISBN 978-0-273-71097-4
  3. Paul C. Dinsmore et al (2005) The right projects done right! John Wiley and Sons, 2005. ISBN 0-7879-7113-8. p.35 and further.
  4. Lewis R. Ireland (2006) Project Management. McGraw-Hill Professional, 2006. ISBN 0-07-147160-X. p.110.
  5. Joseph Phillips (2003). PMP Project Management Professional Study Guide. McGraw-Hill Professional, 2003. ISBN 0-07-223062-2 p.354.
  6. Dennis Lock (2007) Project management (9e ed.) Gower Publishing, Ltd., 2007. ISBN 0-566-08772-3
  7. Young-Hoon Kwak (2005). «A brief history of Project Management». In: The story of managing projects. Elias G. Carayannis et al. (9 eds), Greenwood Publishing Group, 2005. ISBN 1-56720-506-2
  8. David I. Cleland, Roland Gareis (2006). Global project management handbook. "Chapter 1: «The evolution of project management». McGraw-Hill Professional, 2006. ISBN 0-07-146045-4
  9. Martin Stevens (2002). Project Management Pathways. Association for Project Management. APM Publishing Limited, 2002 ISBN 1-903494-01-X p.xxii
  10. Morgen Witzel (2003). Fifty key figures in management‎. Routledge, 2003. ISBN 0-415-36977-0. p. 96-101.
  11. David I. Cleland, Roland Gareis (2006). Global project management handbook. McGraw-Hill Professional, 2006. ISBN 0-07-146045-4. p.1-4 states: «It was in the 1950s when project management was formally recognized as a distinct contribution arising from the management discipline.»
  12. Booz Allen Hamilton — History of Booz Allen 1950s
  13. Bjarne Kousholt (2007). Project Management‎ -. Theory and practice.. Nyt Teknisk Forlag. ISBN 87-571-2603-8. p.59.
  14. http://www.ipma.ch/publication/Pages/ICB-IPMACompetenceBaseline.aspx
  15. F. L. Harrison, Dennis Lock (2004). Advanced project management: a structured approach‎. Gower Publishing, Ltd., 2004. ISBN 0-566-07822-8. p.34.
  16. Winston W. Royce (1970). «Managing the Development of Large Software Systems» in: In: Technical Papers of Western Electronic Show and Convention (WesCon) August 25-28, 1970, Los Angeles, USA.
  17. а б Stellman, Andrew; Greene, Jennifer (2005). Applied Software Project Management. O'Reilly Media. ISBN 978-0-596-00948-9. 
  18. OGC — PRINCE2 — Background
  19. а б в г д е ж и к VA Office of Information and Technology (2003) Project Management Guide US DEPARTMENT OF VETERANS AFFAIRS. March 3, 2005.
  20. а б NASA (2001). NASA NPR 9501.2D. May 23, 2001.
  21. Albert Hamilton (2004). Handbook of Project Management Procedures. TTL Publishing, Ltd. ISBN 0-7277-3258-7

Посилання[ред.ред. код]