Управління проєктами (англ. project management) — область знань з планування, організації та управління ресурсами з метою успішного досягнення цілей та завершення завдань проєкту. Іноді ототожнюється з управлінням програмами, але програма — це фактично вищий рівень: група пов'язаних та взаємозалежних проєктів.
Проєкт — це обмежений часовими рамками процес, що має визначений початок та кінець, зазвичай обмежений датою, але також може обмежуватися фінансуванням або досягненням результатів, який здійснюється для реалізації унікальних цілей та завдань, зазвичай, щоб призвести до вигідних змін або створення доданої вартості. Тимчасова природа проєктів контрастує з бізнесом (процесами), які є повторюваною, постійною або частково постійною діяльністю з виробництва продуктів або послуг. На практиці, управління вищезазначеними двома системами часто різниться і таким чином вимагає розвитку окремих технічних навичок та використання розподіленого управління ними.
Головним завданням проєктного управління є досягнення всіх цілей та виконання завдань проєкту, одночасно виконуючи зобов'язання щодо наперед визначених обмежень проєкту. Типовими обмеженнями є межі та зміст проєкту, час, бюджет. Другорядним завданням, але більш амбітним, є оптимізація, розподілення та інтеграція завдань, необхідних для досягнення наперед визначених цілей.
Історія управління проєктами
![image](https://www.wikidata.uk-ua.nina.az/image/aHR0cHM6Ly93d3cud2lraWRhdGEudWstdWEubmluYS5hei9pbWFnZS9hSFIwY0hNNkx5OTFjR3h2WVdRdWQybHJhVzFsWkdsaExtOXlaeTkzYVd0cGNHVmthV0V2WTI5dGJXOXVjeTkwYUhWdFlpOW1MMlkxTDFSeVlXcGhiaVV5TjNOZlEyOXNkVzF1WHlVeU9GSnZiV0Z1WDFOdmJHUnBaWEp6WDBKMWFXeGthVzVuWDJGZlJtOXlkSEpsYzNNbE1qa3VjRzVuTHpJME1IQjRMVlJ5WVdwaGJpVXlOM05mUTI5c2RXMXVYeVV5T0ZKdmJXRnVYMU52YkdScFpYSnpYMEoxYVd4a2FXNW5YMkZmUm05eWRISmxjM01sTWprdWNHNW4ucG5n.png)
Управління проєктами практикувалося з початку виникнення цивілізації. До 1900 року творчі архітектори та інженери управляли інженерними проєктами самотужки. Наприклад, Вітрувій (1 століття до н. е.), Кристофер Рен (1632–1723), Томас Телфорд (1757 — 1834) та Ісамбард Кінгдом Брюнель (1806 −1859). З 1950 року організації почали систематично використовувати інструменти та техніки проєктного управління для керування складними проєктами.
![image](https://www.wikidata.uk-ua.nina.az/image/aHR0cHM6Ly93d3cud2lraWRhdGEudWstdWEubmluYS5hei9pbWFnZS9hSFIwY0hNNkx5OTFjR3h2WVdRdWQybHJhVzFsWkdsaExtOXlaeTkzYVd0cGNHVmthV0V2WTI5dGJXOXVjeTkwYUhWdFlpOWxMMlU0TDBobGJuSjVYMGRoYm5SMExtcHdaeTh4TlRCd2VDMUlaVzV5ZVY5SFlXNTBkQzVxY0djPS5qcGc=.jpg)
Як наука, управління проєктами виникло з декількох прикладних наук, таких як будівництво, інженерія та оборонна діяльність. Засновником проєктного управління вважають Генрі Ґанта, якого називають батьком технік планування та контролю. Він відомий завдяки використанню діаграми Ганта, як інструменту управління проєктами. Також засновником проєктного управління вважають Анрі Файоль, завдяки створенню ним 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), як частина програми військово-морського флоту Сполучених Штатів для підводних човнів, — Ракети Полярис. Ці математичні техніки швидко поширилися між багатьма приватними підприємствами.
![image](https://www.wikidata.uk-ua.nina.az/image/aHR0cHM6Ly93d3cud2lraWRhdGEudWstdWEubmluYS5hei9pbWFnZS9hSFIwY0hNNkx5OTFjR3h2WVdRdWQybHJhVzFsWkdsaExtOXlaeTkzYVd0cGNHVmthV0V2WTI5dGJXOXVjeTkwYUhWdFlpOWlMMkk1TDFCbGNuUmZZMmhoY25SZlkyOXNiM0psWkM1bmFXWXZNalF3Y0hndFVHVnlkRjlqYUdGeWRGOWpiMnh2Y21Wa0xtZHBaZz09LmdpZg==.gif)
В той час, коли розроблялися моделі планування, техніки для оцінки вартості проєктів, завдяки проривним роботам Ганса Ланґе та інших виникло Управління вартістю та Інженерна економіка. В 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 р., як об'єднання декількох національних асоціацій проєктного управління. 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 також пропонує різноманітну сертифікацію.
Методи управління проєктами
Існує певна кількість методів управління проєктними активностями, включаючи Еджайл (англ. Agile), інтерактивні, послідовні та методи розподілу на етапи.
Попри метод, що використовується, необхідно дуже уважно розглядати загальні цілі проєкту, календарний план, вартість (витрати), одночасно з ролями та відповідальністю усіх виконавців та зацікавлених сторін.
Традиційний метод
Традиційний метод поділу на етапи передбачає визначення послідовності дій, що мають бути завершені. В «традиційному методі» можливо визначити 5 складових проєкту (4 етапи та контроль) розвитку проєкту:
![image](https://www.wikidata.uk-ua.nina.az/image/aHR0cHM6Ly93d3cud2lraWRhdGEudWstdWEubmluYS5hei9pbWFnZS9hSFIwY0hNNkx5OTFjR3h2WVdRdWQybHJhVzFsWkdsaExtOXlaeTkzYVd0cGNHVmthV0V2WTI5dGJXOXVjeTkwYUhWdFlpOWhMMkV3THpGZlZVRmZVSEp2YW1WamRGOU5ZVzVoWjJWdFpXNTBYeVV5T0hCb1lYTmxjeVV5T1M1d2JtY3ZNell3Y0hndE1WOVZRVjlRY205cVpXTjBYMDFoYm1GblpXMWxiblJmSlRJNGNHaGhjMlZ6SlRJNUxuQnVadz09LnBuZw==.png)
Не всі проєкти проходять кожен з етапів; проєкт може бути припинений до його завершення. Деякі проєкти не мають етапів структурованого планування та/або моніторингу. Деякі проєкти проходять стадії 2, 3, 4 або декілька разів.
Багато галузей використовують варіації зазначених етапів. Наприклад, будівельні проєкти зазвичай проходять через приблизно такі етапи: , , , , (або ) та .
В розробці програмного забезпечення цей підхід відомий під назвою, дослівно, «модель водоспаду», (англ. waterfall model), наприклад, друга група завдань виконується після першої в лінійній послідовності. Для «моделі водоспаду» використовуватимемо назву «послідовна модель». З метою адаптації послідовної моделі при розробці програмного забезпечення багато організацій використовують методологію Раціональних уніфікованих процесів (англ. Rational Unified Process - RUP). RUP не вимагає та однозначно не вказує на необхідність використання послідовної моделі. Використання послідовної моделі управління проєктами ефективне для невеликих, визначених проєктів, але для більш великих, невизначених та нових проєктів зазначена модель часто призводить до негативних результатів. «Конус невизначеності» (англ. Cone of Uncertainty) пояснює таке явище тим, що планування, яке виконується на початкових етапах проєкту є не ефективним через значний ступінь невизначеності. Це особливо актуально для розробки програмного забезпечення, оскільки така розробка часто є новим продуктом. В проєктах, де вимоги не були завершені і можуть змінюватися, використовується управління вимогами з метою розробки точного і повного визначення поведінки програмного забезпечення, що може бути базисом для його розробки. Тоді як визначення можуть змінюватися в залежності від галузі, фактичні етапи зазвичай відповідають загальним крокам вирішення проблем (англ. problem solving) — «ідентифікація проблеми, оцінювання варіантів вирішення, вибір шляху вирішення, впровадження та оцінювання».
Критичний шлях управління проєктом
Критичний шлях управління проєктом (англ. Critical Chain Project Management - CCPM) — це метод планування та управління проєктами, який на перше місце ставить управління ресурсами (фізичними та людськими), необхідними для виконання завдань проєкту. Фактично це доповнення Теорії обмежень (англ. Theory of Constraints - TOC) для проєктів. Головним завданням є підвищення продуктивності (або збільшення відсотку завершених завдань) проєктів в організації. Застосовуючи перші три з п'яти основних кроків TOC, системні обмеження для всіх проєктів визначаються як ресурси. Щоб використовувати обмеження, завдання на критичному шляху отримують пріоритет вищий ніж інші активності. Загалом, проєкти плануються та управляються таким чином, щоб ресурси були доступні, коли завдання критичного шляху мають розпочатися, підпорядковуючи усі інші ресурси завданням критичного шляху.
Попри тип проєкту, план проєкту має визначати розподілення ресурсів на рівні (англ. Resource Leveling). Найдовша послідовність ресурсно-обмежених завдань має бути визначена, як критичний шлях. В середовищах, що мають декілька проєктів, розподілення ресурсів на рівні використовується в усіх проєктах. Часто, досить визначити (чи просто обрати) один наскрізний ресурс — ресурс, що виступає як обмеження в усіх проєктах та послідовно розташувати проєкти відповідно до доступності цього ресурсу.
![image](https://www.wikidata.uk-ua.nina.az/image/aHR0cHM6Ly93d3cud2lraWRhdGEudWstdWEubmluYS5hei9pbWFnZS9hSFIwY0hNNkx5OTFjR3h2WVdRdWQybHJhVzFsWkdsaExtOXlaeTkzYVd0cGNHVmthV0V2WTI5dGJXOXVjeTkwYUhWdFlpODJMell3THpGZlZVRmZXSEF0Ykc5dmNGOTNhWFJvWDNScGJXVmZabkpoYldWekxuQnVaeTh4T0RCd2VDMHhYMVZCWDFod0xXeHZiM0JmZDJsMGFGOTBhVzFsWDJaeVlXMWxjeTV3Ym1jPS5wbmc=.png)
Екстремальне управління проєктами
В критичних оглядах Управління проєктами зазначалося, що декілька методів управління проєктами, які базуються на методиці Програми оцінки та контролю (англ. 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).
Метод управління послідовністю подій — це техніка управління невизначеністю та аналізу структури і плану виконання робіт (завдань), що сфокусована на визначенні та управлінні подіями та послідовностями подій, які впливають на план реалізації проєкту. Управління послідовністю подій допомагає зменшувати негативний вплив досвіду взаємодії та особистих якостей, одночасно допомагаючи моделювати невизначеності в планах виконання проєктів. Управління послідовністю подій базується на наступних принципах:
- Ймовірний момент ризику: Активність (завдання) в більшості реальних процесів не є тривалим безперервним процесом. На завдання впливають зовнішні події, які можуть виникнути на одному з етапів посередині виконання завдання.
- Послідовність подій: Події можуть викликати інші події, що будуть створювати послідовності подій. Такі послідовності подій можуть суттєво впливати на шлях проєкту. Кількісний аналіз використовується для визначення кумулятивного ефекту таких послідовностей подій на план виконання проєкту.
- Критичні події або послідовності подій: Одиночні події або послідовності подій, що найбільш ймовірно зможуть вплинути на проєкт вважаються «критичними подіями» або «критичними послідовностями подій». Вони можуть бути визначені шляхом аналізу.
- Письмове відображення проєкту разом з подіями: Навіть якщо проєкт частково завершений і тривалість проєкту, вартість, а також інформація про події, що сталися, вже відомі, існує можливість уточнення інформації про майбутні можливі події, що дозволяє спрогнозувати ефективність майбутнього виконання проєкту.
- Відображення послідовності подій: Події та послідовності подій можуть бути відображені, використовуючи діаграми послідовності подій на діаграмі Ґанта.
Проєкти в контрольованому середовищі
![image](https://www.wikidata.uk-ua.nina.az/image/aHR0cHM6Ly93d3cud2lraWRhdGEudWstdWEubmluYS5hei9pbWFnZS9hSFIwY0hNNkx5OTFjR3h2WVdRdWQybHJhVzFsWkdsaExtOXlaeTkzYVd0cGNHVmthV0V2WTI5dGJXOXVjeTkwYUhWdFlpOWpMMk16THpGZlZVRmZVSEpwYm1ObE1sOXdjbTlqWTJWelgyMXZaR1ZzTG5CdVp5OHlOREJ3ZUMweFgxVkJYMUJ5YVc1alpUSmZjSEp2WTJObGMxOXRiMlJsYkM1d2JtYz0ucG5n.png)
Проєкти в контрольованому середовищі (англ. Projects in controlled environments - PRINCE) — це структурований підхід до управління проєктами, який був створений в 1996 році, як типовий метод управління проєктами. Фактично це комбінація методології PROMPT (що еволюціонувала в методологію PRINCE) з методологію IBM MITP (англ. Managing the implementation of the total project - MITP) — Управління впровадженням усього проєкту. PRINCE2 пропонує метод управління проєктами в рамках чітко визначеної структури організації. PRINCE2 описує процедури координації людей та активностей в проєкті, як розробляти та контролювати проєкт та що робити, якщо необхідно внести зміни до проєкту у зв'язку з відхиленням від плану впровадження.
Кожен процес визначено з ключовими вхідними та вихідними даними, а також цілями та активностями, які необхідно виконати для досягнення таких цілей. Це дозволяє автоматично контролювати будь-яке відхилення від плану. Розподілення на етапи, якими можливо управляти, забезпечує ефективний контроль ресурсів. Впровадження проєкту відбувається структуровано та контрольовано, завдяки інтегрованому контролю за виконанням.
PRINCE2 надає єдину термінологію усім учасникам проєкту. Різноманітні ролі управління та сфери відповідальності, що задіяні в проєкті, повністю описані та можуть бути адаптовані, щоб відповідати складності проєкту та можливостям організації.
Процесне управління
![image](https://www.wikidata.uk-ua.nina.az/image/aHR0cHM6Ly93d3cud2lraWRhdGEudWstdWEubmluYS5hei9pbWFnZS9hSFIwY0hNNkx5OTFjR3h2WVdRdWQybHJhVzFsWkdsaExtOXlaeTkzYVd0cGNHVmthV0V2WTI5dGJXOXVjeTkwYUhWdFlpODRMemcyTHpGZlZVRmZRMkZ3WVdKcGJHbDBlVjlOWVhSMWNtbDBlVjlOYjJSbGJDNXdibWN2TWpRd2NIZ3RNVjlWUVY5RFlYQmhZbWxzYVhSNVgwMWhkSFZ5YVhSNVgwMXZaR1ZzTG5CdVp3PT0ucG5n.png)
Подальший розвиток концепції контролю в проєктному управлінні призводить до об'єднання методик процесного управління (англ. 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) розглядають проєкт, як послідовність невеликих завдань, які виникають та виконуються ситуативно, відповідно до вимог обставин. Ініціація та виконання є скоріше адаптивними до зовнішніх обставин, ніж завчасно повністю спланованим процесом.
Групи процесів управління проєктами
Традиційно, управління проєктами включає наступний перелік елементів: чотири групи процесів та систему контролю. Незалежно від методології чи термінології, що застосовується, використовуються одні й ті самі базові процеси управління проєктами.
![image](https://www.wikidata.uk-ua.nina.az/image/aHR0cHM6Ly93d3cud2lraWRhdGEudWstdWEubmluYS5hei9pbWFnZS9hSFIwY0hNNkx5OTFjR3h2WVdRdWQybHJhVzFsWkdsaExtOXlaeTkzYVd0cGNHVmthV0V2WTI5dGJXOXVjeTkwYUhWdFlpOWpMMk5tTHpGZlZVRmZVSEp2YW1WamRGOWtaWFpsYkc5d2JXVnVkRjl6ZEdGblpYTXVjRzVuTHpFNE1IQjRMVEZmVlVGZlVISnZhbVZqZEY5a1pYWmxiRzl3YldWdWRGOXpkR0ZuWlhNdWNHNW4ucG5n.png)
Групи процесів зазвичай включають:
- Ініціювання
- Планування чи розробка
- Експлуатація чи виконання
- Завершення
У проєктному середовищі з дослідницьким нахилом (наприклад, Дослідження та проєктування, (англ. Researsh and Development)) зазначені етапи можуть доповнюватися точками прийняття рішень, де вирішується чи потрібно продовжувати чи припинити впровадження проєкту.
Ініціювання
![image](https://www.wikidata.uk-ua.nina.az/image/aHR0cHM6Ly93d3cud2lraWRhdGEudWstdWEubmluYS5hei9pbWFnZS9hSFIwY0hNNkx5OTFjR3h2WVdRdWQybHJhVzFsWkdsaExtOXlaeTkzYVd0cGNHVmthV0V2WTI5dGJXOXVjeTkwYUhWdFlpOHhMekUwTHpGZlZVRmZTVzVwZEdsaGRHbHVaMTlRY205alpYTnpYMGR5YjNWd1gxQnliMk5sYzNObGN5NXdibWN2TWpRd2NIZ3RNVjlWUVY5SmJtbDBhV0YwYVc1blgxQnliMk5sYzNOZlIzSnZkWEJmVUhKdlkyVnpjMlZ6TG5CdVp3PT0ucG5n.png)
Процес ініціювання визначає зміст та межі проєкту. Якщо зазначений етап виконується не повною мірою, то здебільшого проєкт не буде відповідати вимогам бізнесу. Ключовими контрольними індикаторами для зазначеного етапу є розуміння бізнес середовища та включення усіх необхідних контрольних індикаторів в проєкт. Усі невідповідності, проблемні питання мають бути розглянуті та рішення щодо таких питань мають бути прийняті з метою їх усунення.
Етап ініціювання має містити план, що висвітлює такі питання:
- аналіз бізнес-потреб / вимог в вимірюваних показниках.
- огляд існуючих процесів.
- Фінансовий аналіз витрат і доходів, включаючи бюджет.
- аналіз зацікавленими сторонами, включаючи користувачів, працівників підтримки проєкту.
- статут проєкту (project charter) - підсумковий документ ініціації, який включає витрати, завдання, результати та календарний план впровадження.
Планування та розробка
![image](https://www.wikidata.uk-ua.nina.az/image/aHR0cHM6Ly93d3cud2lraWRhdGEudWstdWEubmluYS5hei9pbWFnZS9hSFIwY0hNNkx5OTFjR3h2WVdRdWQybHJhVzFsWkdsaExtOXlaeTkzYVd0cGNHVmthV0V2WTI5dGJXOXVjeTkwYUhWdFlpOWlMMkpoTHpGZlZVRmZVR3hoYm01cGJtZGZVSEp2WTJWemMxOUhjbTkxY0Y5QlkzUnBkbWwwYVdWekxuQnVaeTh5TkRCd2VDMHhYMVZCWDFCc1lXNXVhVzVuWDFCeWIyTmxjM05mUjNKdmRYQmZRV04wYVhacGRHbGxjeTV3Ym1jPS5wbmc=.png)
Після етапу ініціювання, проєкт заплановано з необхідним рівнем деталізації. Головне завдання - спланувати час, витрати та ресурси з метою адекватної оцінки роботи, яку необхідно виконати, та ефективного управління ризиками протягом впровадження проєкту. Аналогічно групі процесів ініціювання, недостатньо розроблений план значно знижує шанси проєкту успішно завершити поставлені перед ним завдання.
Планування проєкту загалом складається з:
- визначення «як планувати?» (наприклад, за рівнем деталізації чи етапами впровадження).
- розробки документу, що визначає зміст та межі проєкту.
- визначення групи відповідальних, що плануватимуть проєкт.
- визначення результатів проєкту та створення структури декомпозиції робіт.
- визначення завдань, які необхідно виконати для досягнення цілей проєкту, та логічне послідовне об'єднання таких завдань.
- оцінки вимог до ресурсів для забезпечення виконання завдань.
- оцінки часу та витрат на виконання завдань.
- розробки календарного плану-графіку.
- розробка бюджету.
- планування ризиків.
- отримання формального погодження початку роботи.
Додаткові процеси, такі як планування комунікацій, визначення ролей та рівня відповідальності, закупівель в рамках проєкту, а також проведення попередньої зустрічі учасників проєкту (англ. Kick-off meeting) загалом є рекомендованими.
Для проєктів з розробки нових продуктів, концептуальна розробка продукту може проводитися одночасно з активностями з планування, які можуть допомогти групі з планування, шляхом інформування про визначені результати проєкту та заплановані завдання.
Виконання
![image](https://www.wikidata.uk-ua.nina.az/image/aHR0cHM6Ly93d3cud2lraWRhdGEudWstdWEubmluYS5hei9pbWFnZS9hSFIwY0hNNkx5OTFjR3h2WVdRdWQybHJhVzFsWkdsaExtOXlaeTkzYVd0cGNHVmthV0V2WTI5dGJXOXVjeTkwYUhWdFlpOHhMekZsTHpGZlZVRmZSWGhsWTNWMGFXNW5YMUJ5YjJObGMzTmZSM0p2ZFhCZlVISnZZMlZ6YzJWekxuQnVaeTh5TkRCd2VDMHhYMVZCWDBWNFpXTjFkR2x1WjE5UWNtOWpaWE56WDBkeWIzVndYMUJ5YjJObGMzTmxjeTV3Ym1jPS5wbmc=.png)
Виконання складається з процесів, необхідних для завершення робіт, визначених в плані проєкту, з метою виконання вимог проєкту. Процес виконання включає координування людей та ресурсів, одночасно з інтеграцією та виконанням завдань проєкту відповідно до плану управління проєктом. Результати проєкту є результатами виконання завдань проєкту відповідно до плану проєкту.
Моніторинг та контроль
Моніторинг та Контроль складається з процесів, що виконуються з метою огляду стану виконання проєкту, щоб потенційні проблеми були визначені вчасно і коригуючі дії можливо було виконати, з метою контролю виконання проєкту. Головним здобутком є регулярний огляд та оцінювання процесу виконання проєкту з метою визначення відхилень від плану управління проєктом.
![image](https://www.wikidata.uk-ua.nina.az/image/aHR0cHM6Ly93d3cud2lraWRhdGEudWstdWEubmluYS5hei9pbWFnZS9hSFIwY0hNNkx5OTFjR3h2WVdRdWQybHJhVzFsWkdsaExtOXlaeTkzYVd0cGNHVmthV0V2WTI5dGJXOXVjeTkwYUhWdFlpODRMemd4THpGZlZVRmZUVzl1YVhSdmNtbHVaMTloYm1SZlEyOXVkSEp2Ykd4cGJtZGZVSEp2WTJWemMxOUhjbTkxY0Y5UWNtOWpaWE56WlhNdWNHNW5MekkwTUhCNExURmZWVUZmVFc5dWFYUnZjbWx1WjE5aGJtUmZRMjl1ZEhKdmJHeHBibWRmVUhKdlkyVnpjMTlIY205MWNGOVFjbTlqWlhOelpYTXVjRzVuLnBuZw==.png)
Моніторинг та контроль включає:
- вимірювання поточного виконання завдань проєкту (де ми є зараз?).
- моніторинг змінних складових проєкту (зміст та межі проєкту, витрати тощо) в порівнянні до плану управління проєкту та базового плану виконання проєкту (де ми маємо бути?).
- визначення коригуючих дій, з метою правильного вирішення відкритих питань та ризиків (Як ми можемо привести фактичний стан виконання до планового виконання?).
- вплив на фактори, що можуть призвести до порушення інтегрованого контролю змін, для того щоб лише погоджені зміни впроваджувалися.
В багатоетапних проєктах процеси моніторингу та контролю забезпечують зворотний зв'язок між етапами проєкту, задля забезпечення коригуючих чи превентивних дій з метою приведення проєкту у відповідність з планом управління проєктом.
Підтримка проєкту — це постійний процес, що включає:
- постійну підтримку кінцевих користувачів.
- виправлення помилок.
- оновлення програмного забезпечення.
![image](https://www.wikidata.uk-ua.nina.az/image/aHR0cHM6Ly93d3cud2lraWRhdGEudWstdWEubmluYS5hei9pbWFnZS9hSFIwY0hNNkx5OTFjR3h2WVdRdWQybHJhVzFsWkdsaExtOXlaeTkzYVd0cGNHVmthV0V2WTI5dGJXOXVjeTkwYUhWdFlpOWhMMkV5THpGZlZVRmZVSEp2YW1WamRGOU5ZVzVoWjJWdFpXNTBYeVV5T0hCeWIycGxZM1JmWTI5dWRISnZiQ1V5T1M1d2JtY3ZNakV3Y0hndE1WOVZRVjlRY205cVpXTjBYMDFoYm1GblpXMWxiblJmSlRJNGNISnZhbVZqZEY5amIyNTBjbTlzSlRJNUxuQnVadz09LnBuZw==.png)
На цьому етапі, аудитори мають звертати увагу на ефективність та швидкість вирішення проблем користувачів.
Наприклад, протягом впровадження будь-якого будівельного проєкту зміст та межі проєкту можуть змінюватися. Зміни — це нормальна та очікувана частина процесу будівництва. Зміни можуть бути результатом необхідних модифікацій конструкції, відмінностях будівельного майданчика, доступності матеріалів, змін на вимогу підрядної організації, впливом третіх сторін і т. д. Окрім впровадження змін, вони мають бути закріплені в документах, щоб відобразити кінцевий результат. Описаний процес отримав назву Управління змінами (англ. Change management). Зазвичай власник вимагає остаточне документування змін, щоб зафіксувати усі зміни, а іноді, будь-яку зміну, що змінює матеріальні пакети завершеної роботи. Документування здійснюється за допомогою договірних документів, зазвичай, але не обов'язково, обмежуючись кресленнями. Кінцевий продукт такого процесу отримав назву, дослівно, «креслення, як побудовано» (англ. As-built drawing), чи більш спрощено, «Як побудовано» (англ. As built). Вимога щодо надання таких креслень є нормою будівельних договорів. Коли зміни внесені до проєкту, життєздатність проєкту має бути оцінена ще раз. Важливо не втратити початкових цілей та завдань проєкту. Коли усі зміни зібрані, прогнозований результат може не виправдати інвестиції у проєкт.
Завершення
![image](https://www.wikidata.uk-ua.nina.az/image/aHR0cHM6Ly93d3cud2lraWRhdGEudWstdWEubmluYS5hei9pbWFnZS9hSFIwY0hNNkx5OTFjR3h2WVdRdWQybHJhVzFsWkdsaExtOXlaeTkzYVd0cGNHVmthV0V2WTI5dGJXOXVjeTkwYUhWdFlpODFMelZtTHpGZlZVRmZRMnh2YzJsdVoxOVFjbTlqWlhOelgwZHliM1Z3WDFCeWIyTmxjM05sY3k1d2JtY3ZNalF3Y0hndE1WOVZRVjlEYkc5emFXNW5YMUJ5YjJObGMzTmZSM0p2ZFhCZlVISnZZMlZ6YzJWekxuQnVadz09LnBuZw==.png)
Завершення включає формальне прийняття проєкту та відповідно його закриття. Проводяться адміністративні активності, включаючи передачу до архіву робочої документації та документування здобутого досвіду. Цей етап складається з:
- закриття проєкту: Завершення усіх активностей у всіх групах процесів з метою формального закриття проєкту або етапу проєкту.
- закриття договору (контракту): Завершення та оплата кожного договору, включаючи вирішення будь-яких відкритих питань, та закриття кожного договору, що стосується проєкту в цілому або певного етапу проєкту.
Системи контролю проєктів
Контроль проєкту — це елемент, який забезпечує відповідність проєкту графіку виконання та бюджету. Контроль проєкту починається з планування та закінчується звітом з виконання проєкту, пронизуючи кожен елемент процесу управління проєктом. Кожен проєкт має бути оцінений щодо рівня необхідного контролю: забагато контролю означає втрату часу, замало контролю означає збільшення ризиків. Якщо контроль проєкту впроваджений не вірно, вартість для бізнесу пояснюється у термінах помилок, виправлень та додаткових витрат на аудит. Системи контролю необхідні для витрат, ризиків, якості, комунікацій, часу, змін, закупівель та людських ресурсів. До того ж аудитори мають визначити наскільки проєкти впливають на фінансову звітність, наскільки достовірну інформацію отримують замовники і скільки точок контролю існує. Аудитори мають розглянути процес розробки та процедури на предмет способу впровадження. Процес виробництва та якість кінцевого продукту також може бути оцінений, якщо така потреба виникає. Бізнес може забажати від аудиторської фірми фіксування проблем на ранніх етапах з метою зменшення зусиль необхідних на виправлення. Аудитор може виступати як консультант з контролю, частина проєктної команди або як окремий аудитор, частина авдиту. Бізнес іноді використовує формалізовані процеси розробки систем. Це допомагає підтвердити успішність розробки. Формальний процес ефективніший у створенні сильних точок контролю. Авдитори мають перевірити такий процес та підтвердити його якісну організацію та відповідність практиці. Гарний формальний план впровадження системи характеризує:
- Стратегія, задля приведення розробки до загальніших цілей організації.
- для нових систем.
- Політики управління проєктом щодо часу та бюджету.
- Процедури, що описують процес.
- Оцінка якості змін.
Теми з управління проєктами
Менеджер проєкту
Менеджер проєкту — це фахівець у сфері управління проєктами. Менеджер проєкту може бути відповідальним за планування, виконання та завершення будь-якого проєкту, зазвичай в будівельній галузі, прокладанні кабельних мереж, телекомунікаціях або розробці програмного забезпечення. У галузях виробництва та надання послуг також існують менеджери проєктів.
Менеджер проєкту — це особа відповідальна за виконання визначених завдань проєкту. Головними завданнями менеджера проєктів є визначення чітких та реалізовних завдань проєкту, визначення вимог до проєкту та управління трьома обмеженнями проєкту: вартістю, часом, межами та обсягом завдань.
Менеджер проєкту досить часто є представником замовника і має визначити та сформулювати чіткі потреби / вимоги замовника, базуючись на знаннях про організацію, яку він представляє. Вміння використовувати внутрішні процедури підрядника та створювати тісні зв'язки з призначеними представниками замовника є життєво необхідним для забезпечення виконання ключових завдань щодо ціни, часу реалізації, якості та задоволення вимог замовника.
Трикутник управління проєктами
Як будь-яке починання, проєкт виконується та завершується відповідно до певних обмежень. Традиційно такими обмеженнями вважаються «зміст та межі» (англ. Scope), «час» (англ. Time) та «вартість» (англ. Cost). Такі обмеження отримали назву «Трикутник управління проєктами», де кожна сторона є певним обмеженням. Одна сторона трикутника не може бути змінена, щоб не вплинути на інші сторони. Подальше уточнення обмежень відділяє «якість» (англ. Quality) чи «продуктивність» впровадження проєкту від «змісту та меж» і перетворює якість в четверте обмеження.
Обмеження за часом — це час, за який необхідно завершити проєкт. Вартість — це розмір бюджету, який виділений на реалізацію проєкту. Обмеження за змістом та межами — це завдання, які мають бути завершені для досягнення кінцевого результату проєкту. Зазначені три обмеження досить часто взаємопов'язані: збільшення меж та обсягів завдань, зазвичай призводить до збільшення часу та вартості, обмежений час може означати збільшення вартості чи зменшення змісту та меж проєкту.
Наука про управління проєктами забезпечує інструменти та методи, що надають змогу команді проєкту (не лише менеджеру проєкту) організувати свою роботу таким чином, щоб виконати вимоги щодо обмежень.
Структура декомпозиції робіт
![image](https://www.wikidata.uk-ua.nina.az/image/aHR0cHM6Ly93d3cud2lraWRhdGEudWstdWEubmluYS5hei9pbWFnZS9hSFIwY0hNNkx5OTFjR3h2WVdRdWQybHJhVzFsWkdsaExtOXlaeTkzYVd0cGNHVmthV0V2WTI5dGJXOXVjeTkwYUhWdFlpOWpMMk0xTHpGZlZVRmZUa0ZUUVY5T1JsODFNek5mY21Wd2IzSjBhVzVuWDNOMGNuVmpkSFZ5WlM1d2JtY3ZNalF3Y0hndE1WOVZRVjlPUVZOQlgwNUdYelV6TTE5eVpYQnZjblJwYm1kZmMzUnlkV04wZFhKbExuQnVadz09LnBuZw==.png)
Структура декомпозиції робіт (англ. Work breakdown Structure - WBS) — це деревоподібна структура, що показує розподіл завдань необхідних для досягнення цілі / виконання завдання; наприклад, програма, проєкт та контракт. WBS може бути орієнтована на апаратну частину, продукт, сервіс чи процес.
WBS може бути розроблена шляхом послідовного поділу кінцевої цілі / завдання на компоненти, що підлягають управлінню, з огляду на розмір, тривалість та відповідальність (наприклад, системи, підсистеми, компоненти, завдання, під завдання, пакети робіт), та містять усі кроки необхідні для виконання завдання.
Структура декомпозиції робіт забезпечує основу для природного впровадження загального планування та контролю контракту, та є базисом для поділу роботи на етапи з яких можуть бути виділені завдання і може бути впроваджена технічна, календарна, витратна звітність та звітність на підставі людино-годин.
Структура управління проєктами
![image](https://www.wikidata.uk-ua.nina.az/image/aHR0cHM6Ly93d3cud2lraWRhdGEudWstdWEubmluYS5hei9pbWFnZS9hSFIwY0hNNkx5OTFjR3h2WVdRdWQybHJhVzFsWkdsaExtOXlaeTkzYVd0cGNHVmthV0V2WTI5dGJXOXVjeTkwYUhWdFlpODJMelkzTHpGZlZVRmZWa0ZmU1ZSZlVISnZhbVZqZEY5TllXNWhaMlZ0Wlc1MFgwWnlZVzFsZDI5eWF5NXdibWN2TXpZd2NIZ3RNVjlWUVY5V1FWOUpWRjlRY205cVpXTjBYMDFoYm1GblpXMWxiblJmUm5KaGJXVjNiM0pyTG5CdVp3PT0ucG5n.png)
Життєвий цикл Програми (Інвестиції) включає управління проєктом та життєві цикли впровадження системи разом з активностями, пов'язаними з розгортанням системи та експлуатацією. Відповідно до концепції, управління експлуатацією системи та пов'язані активності, що виникають після завершення проєкту, не визначені в цьому посібнику.
Наприклад, див. діаграму, у Департаменті управління справами ветеранів Сполучених Штатів (англ. US United States Department of Veterans Affairs - VA) життєвий цикл управління програмою визначений та описаний в Структурі управління IT проєктами VA, щоб інтегрувати проєктні (інвестиційні) активності та проєкт в цілому в процес бюджетування. Діаграма «Структура управління проєктами» ілюструє Етап 4, який виникає після розгортання системи та закриття проєкту. Активності етапу закриття проєкту в VA продовжуються протягом розгортання системи та переходять в етап експлуатації системи з метою відображення активностей, які вважаються частиною проєкту. Діаграма показує дії та пов'язані артефакти процесу Управління IT проєктами та програмами в VA.
Міжнародні стандарти
Було декілька спроб розвитку стандартів Управління проєктами, такі як:
- ISO_21500 - серія стандартів Міжнародної організації зі стандартизації (ISO), які застосовуються при управлінні проєктами, програмами та портфелями організацій.
- Модель Можливостей Зрілості (англ. 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), як інструмент вибору пріоритетних проєктів, після чого використовуються методи управління проєктами, як засіб узгодження ресурсних конфліктів (у випадках, коли кілька проєктів конкурують за доступ до спільних ресурсів) і як засіб досягнення результатів у формі найкращої вигоди для організацій в цілому.
проєктами використовуються для того, щоб «правильно впроваджувати проєкти», а PPM використовується для того, щоб «впроваджувати правильні проєкти». В багатьох галузях PPM стає методом вибору та пріоритезації серед проєктів, що використовують одній й ті ж ресурси (конфлікт інтерсів).
Програмне забезпечення для управління проєктами
- Spider Project — програмний пакет з управління проєктами.
- ERPNext — корпоративна система планування ресурсів підприємства, що включає багато модулів.
Див. також
Примітки
- Chatfield, Carl. A short course in project management. Microsoft.
- * The Definitive Guide to Project Management. Nokes, Sebastian. 2nd Ed.n. London (Financial Times / Prentice Hall): 2007.
- Paul C. Dinsmore et al (2005) The right projects done right! John Wiley and Sons, 2005. . p.35 and further.
- Lewis R. Ireland (2006) Project Management. McGraw-Hill Professional, 2006. . p.110.
- Joseph Phillips (2003). PMP Project Management Professional Study Guide. McGraw-Hill Professional, 2003. p.354.
- Dennis Lock (2007) Project management (9e ed.) Gower Publishing, Ltd., 2007.
- 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.
- David I. Cleland, Roland Gareis (2006). Global project management handbook. "Chapter 1: «The evolution of project management». McGraw-Hill Professional, 2006.
- Martin Stevens (2002). Project Management Pathways. Association for Project Management. APM Publishing Limited, 2002 p.xxii
- Morgen Witzel (2003). Fifty key figures in management. Routledge, 2003. . p. 96-101.
- David I. Cleland, Roland Gareis (2006). Global project management handbook. McGraw-Hill Professional, 2006. . p.1-4 states: «It was in the 1950s when project management was formally recognized as a distinct contribution arising from the management discipline.»
- . Архів оригіналу за 7 червня 2007. Процитовано 8 березня 2010.
- Bjarne Kousholt (2007). Project Management -. Theory and practice.. Nyt Teknisk Forlag. . p.59.
- . Архів оригіналу за 6 грудня 2009. Процитовано 8 березня 2010.
{{}}
: Обслуговування CS1: Сторінки з текстом «archived copy» як значення параметру title () - F. L. Harrison, Dennis Lock (2004). Advanced project management: a structured approach. Gower Publishing, Ltd., 2004. . p.34.
- Royce, Winston W. (1970). (PDF). Technical Papers of Western Electronic Show and Convention (WesCon) August 25-28, 1970, Los Angeles, USA (англ.). Архів оригіналу (PDF) за 15 березня 2016.
- Stellman, Andrew; Greene, Jennifer (2005). . O'Reilly Media. ISBN . Архів оригіналу за 9 лютого 2015. Процитовано 8 березня 2010.
- OGC — PRINCE2 — Background. Архів оригіналу за 22 серпня 2011. Процитовано 8 березня 2010.
- VA Office of Information and Technology (2003) Project Management Guide [ 14 січня 2009 у Wayback Machine.] US DEPARTMENT OF VETERANS AFFAIRS. March 3, 2005.
- NASA (2001). NASA NPR 9501.2D [ 2010-06-10 у Wayback Machine.]. May 23, 2001.
- Albert Hamilton (2004). Handbook of Project Management Procedures. TTL Publishing, Ltd.
Література
- В. Бакуменко. Управління проєктами // Політична енциклопедія. Редкол.: Ю. Левенець (голова), Ю. Шаповал (заст. голови) та ін. — К.:Парламентське видавництво, 2011. — с.738
Посилання
- Max Wideman's «Open Source» Comparative Glossary of Project Management Terms
- Open Source Project Management manual
- Guidelines for Managing Projects from the UK Department for Business, Enterprise and Regulatory Reform (BERR)
- Бурков В.Н., Коргин Н.А., Новиков Д.А. Введение в теорию управления организационными системами. Учебник / Под ред. Д. А. Новикова. - М.: Книжный дом "ЛИБРОКОМ", 2009. – 264 с.
Вікіпедія, Українська, Україна, книга, книги, бібліотека, стаття, читати, завантажити, безкоштовно, безкоштовно завантажити, mp3, відео, mp4, 3gp, jpg, jpeg, gif, png, малюнок, музика, пісня, фільм, книга, гра, ігри, мобільний, телефон, android, ios, apple, мобільний телефон, samsung, iphone, xiomi, xiaomi, redmi, honor, oppo, nokia, sonya, mi, ПК, web, Інтернет
Upravlinnya proyektami angl project management oblast znan z planuvannya organizaciyi ta upravlinnya resursami z metoyu uspishnogo dosyagnennya cilej ta zavershennya zavdan proyektu Inodi ototozhnyuyetsya z upravlinnyam programami ale programa ce faktichno vishij riven grupa pov yazanih ta vzayemozalezhnih proyektiv Proyekt ce obmezhenij chasovimi ramkami proces sho maye viznachenij pochatok ta kinec zazvichaj obmezhenij datoyu ale takozh mozhe obmezhuvatisya finansuvannyam abo dosyagnennyam rezultativ yakij zdijsnyuyetsya dlya realizaciyi unikalnih cilej ta zavdan zazvichaj shob prizvesti do vigidnih zmin abo stvorennya dodanoyi vartosti Timchasova priroda proyektiv kontrastuye z biznesom procesami yaki ye povtoryuvanoyu postijnoyu abo chastkovo postijnoyu diyalnistyu z virobnictva produktiv abo poslug Na praktici upravlinnya vishezaznachenimi dvoma sistemami chasto riznitsya i takim chinom vimagaye rozvitku okremih tehnichnih navichok ta vikoristannya rozpodilenogo upravlinnya nimi Golovnim zavdannyam proyektnogo upravlinnya ye dosyagnennya vsih cilej ta vikonannya zavdan proyektu odnochasno vikonuyuchi zobov yazannya shodo napered viznachenih obmezhen proyektu Tipovimi obmezhennyami ye mezhi ta zmist proyektu chas byudzhet Drugoryadnim zavdannyam ale bilsh ambitnim ye optimizaciya rozpodilennya ta integraciya zavdan neobhidnih dlya dosyagnennya napered viznachenih cilej Istoriya upravlinnya proyektamiRimski soldati buduyut fortecyu Kolona Trayana 113 r n e Upravlinnya proyektami praktikuvalosya z pochatku viniknennya civilizaciyi Do 1900 roku tvorchi arhitektori ta inzheneri upravlyali inzhenernimi proyektami samotuzhki Napriklad Vitruvij 1 stolittya do n e Kristofer Ren 1632 1723 Tomas Telford 1757 1834 ta Isambard Kingdom Bryunel 1806 1859 Z 1950 roku organizaciyi pochali sistematichno vikoristovuvati instrumenti ta tehniki proyektnogo upravlinnya dlya keruvannya skladnimi proyektami Genri Gant 1861 1919 batko tehnik planuvannya ta kontrolyu Yak nauka upravlinnya proyektami viniklo z dekilkoh prikladnih nauk takih yak budivnictvo inzheneriya ta oboronna diyalnist Zasnovnikom proyektnogo upravlinnya vvazhayut Genri Ganta yakogo nazivayut batkom tehnik planuvannya ta kontrolyu Vin vidomij zavdyaki vikoristannyu diagrami Ganta yak instrumentu upravlinnya proyektami Takozh zasnovnikom proyektnogo upravlinnya vvazhayut Anri Fajol zavdyaki stvorennyu nim 5 funkcij upravlinnya sho formuyut zasadi znan upravlinnya proyektami ta programami Gant ta Fajol buli prihilnikami teorij z naukovogo upravlinnya Frederika Vinslov Tejlora Jogo robota ce poperednik suchasnih instrumentiv upravlinnya proyektami vklyuchayuchi dekompoziciyu robit ta rozpodilennya resursiv 1950 ti rozpochali epohu suchasnogo proyektnogo upravlinnya Upravlinnya proyektami pochali viznavati yak okremij napryam sho vinik z nauki pro upravlinnya V Spoluchenih Shtatah do 1950 ih proyektami upravlyali ad hoc vikoristovuyuchi diagrami Ganta neformalni tehniki ta instrumenti V toj chas bulo rozrobleno dvi matematichni modeli proyektnogo upravlinnya Metod kritichnogo shlyahu angl Critical Path Method CPM buv rozroblenij yak spilnij proyekt mizh korporaciyami DyuPon angl DuPont Corporation ta Remington Rend angl Remington Rand Corporation dlya upravlinnya ta pidtrimki proyektiv Programa ocinki ta kontrolyu angl Program Evaluation and Review Technique PERT bula rozroblena Buz Alenom ta Gamiltonom angl Booz Allen amp Hamilton razom z Korporaciyeyu Lokgid angl Lockheed Corporation yak chastina programi vijskovo morskogo flotu Spoluchenih Shtativ dlya pidvodnih chovniv Raketi Polyaris Ci matematichni tehniki shvidko poshirilisya mizh bagatma privatnimi pidpriyemstvami Merezheva diagrama PERT dlya semimisyachnogo proyektu z p yatma klyuchovimi podiyami V toj chas koli rozroblyalisya modeli planuvannya tehniki dlya ocinki vartosti proyektiv zavdyaki prorivnim robotam Gansa Lange ta inshih viniklo Upravlinnya vartistyu ta Inzhenerna ekonomika V 1956 r pershimi praktikami proyektnogo upravlinnya ta sumizhnimi specialistami z kalendarnogo planuvannya proyektnogo kontrolyu ocinki vartosti ta yiyi kontrolyu bula stvorena Amerikanska asociaciya inzheneriv z upravlinnya vartistyu angl American Association of Cost Engineers zaraz doslivno Mizhnarodna asociaciya z prosuvannya upravlinnyam vartistyu angl Association for the Advancement of Cost Engineering AACE International AACE prodovzhuvala doslidnicki roboti i v 2006 r vipustila pershij integrovanij proces dlya portfelnogo programnogo ta proyektnogo upravlinnya Sistema povnogo upravlinnya vartistyu angl Total Cost Management Framework Mizhnarodna asociaciya proyektnogo upravlinnya angl International Project Management Association IPMA bula zasnovana v Yevropi v 1967 r yak ob yednannya dekilkoh nacionalnih asociacij proyektnogo upravlinnya IPMA j sogodni zberigaye federalnu strukturu i zaraz skladayetsya z chleniv asociacij na kozhnomu kontinenti za viklyuchennyam Antarktidi IPMA proponuye programu sertifikaciyi sho skladayetsya z chotiroh rivniv yaka bazuyetsya na osnovnih kompetenciyah IPMA angl IPMA Competence Baseline ICB Kompetenciyi ICB vklyuchayut tehnichni kompetenciyi kontekstualni kompetenciyi ta povedinkovi kompetenciyi V 1969 r v Spoluchenih Shtatah buv stvorenij Institut proyektnogo upravlinnya angl Project management institute PMI PMI opublikuvav Dovidnik z upravlinnya proyektami angl A Guide to the Project Management Body of Knowledge PMBOK Guide yakij opisuye praktiki upravlinnya proyektami sho ye odnakovimi dlya bilshosti proyektiv u bilshosti vipadkiv PMI takozh proponuye riznomanitnu sertifikaciyu Metodi upravlinnya proyektamiIsnuye pevna kilkist metodiv upravlinnya proyektnimi aktivnostyami vklyuchayuchi Edzhajl angl Agile interaktivni poslidovni ta metodi rozpodilu na etapi Popri metod sho vikoristovuyetsya neobhidno duzhe uvazhno rozglyadati zagalni cili proyektu kalendarnij plan vartist vitrati odnochasno z rolyami ta vidpovidalnistyu usih vikonavciv ta zacikavlenih storin Tradicijnij metod Tradicijnij metod podilu na etapi peredbachaye viznachennya poslidovnosti dij sho mayut buti zaversheni V tradicijnomu metodi mozhlivo viznachiti 5 skladovih proyektu 4 etapi ta kontrol rozvitku proyektu Tipovi etapi vikonannya proyektu Iniciyuvannya Monitoring ta kontrol Ne vsi proyekti prohodyat kozhen z etapiv proyekt mozhe buti pripinenij do jogo zavershennya Deyaki proyekti ne mayut etapiv strukturovanogo planuvannya ta abo monitoringu Deyaki proyekti prohodyat stadiyi 2 3 4 abo dekilka raziv Bagato galuzej vikoristovuyut variaciyi zaznachenih etapiv Napriklad budivelni proyekti zazvichaj prohodyat cherez priblizno taki etapi abo ta V rozrobci programnogo zabezpechennya cej pidhid vidomij pid nazvoyu doslivno model vodospadu angl waterfall model napriklad druga grupa zavdan vikonuyetsya pislya pershoyi v linijnij poslidovnosti Dlya modeli vodospadu vikoristovuvatimemo nazvu poslidovna model Z metoyu adaptaciyi poslidovnoyi modeli pri rozrobci programnogo zabezpechennya bagato organizacij vikoristovuyut metodologiyu Racionalnih unifikovanih procesiv angl Rational Unified Process RUP RUP ne vimagaye ta odnoznachno ne vkazuye na neobhidnist vikoristannya poslidovnoyi modeli Vikoristannya poslidovnoyi modeli upravlinnya proyektami efektivne dlya nevelikih viznachenih proyektiv ale dlya bilsh velikih neviznachenih ta novih proyektiv zaznachena model chasto prizvodit do negativnih rezultativ Konus neviznachenosti angl Cone of Uncertainty poyasnyuye take yavishe tim sho planuvannya yake vikonuyetsya na pochatkovih etapah proyektu ye ne efektivnim cherez znachnij stupin neviznachenosti Ce osoblivo aktualno dlya rozrobki programnogo zabezpechennya oskilki taka rozrobka chasto ye novim produktom V proyektah de vimogi ne buli zaversheni i mozhut zminyuvatisya vikoristovuyetsya upravlinnya vimogami z metoyu rozrobki tochnogo i povnogo viznachennya povedinki programnogo zabezpechennya sho mozhe buti bazisom dlya jogo rozrobki Todi yak viznachennya mozhut zminyuvatisya v zalezhnosti vid galuzi faktichni etapi zazvichaj vidpovidayut zagalnim krokam virishennya problem angl problem solving identifikaciya problemi ocinyuvannya variantiv virishennya vibir shlyahu virishennya vprovadzhennya ta ocinyuvannya Kritichnij shlyah upravlinnya proyektom Kritichnij shlyah upravlinnya proyektom angl Critical Chain Project Management CCPM ce metod planuvannya ta upravlinnya proyektami yakij na pershe misce stavit upravlinnya resursami fizichnimi ta lyudskimi neobhidnimi dlya vikonannya zavdan proyektu Faktichno ce dopovnennya Teoriyi obmezhen angl Theory of Constraints TOC dlya proyektiv Golovnim zavdannyam ye pidvishennya produktivnosti abo zbilshennya vidsotku zavershenih zavdan proyektiv v organizaciyi Zastosovuyuchi pershi tri z p yati osnovnih krokiv TOC sistemni obmezhennya dlya vsih proyektiv viznachayutsya yak resursi Shob vikoristovuvati obmezhennya zavdannya na kritichnomu shlyahu otrimuyut prioritet vishij nizh inshi aktivnosti Zagalom proyekti planuyutsya ta upravlyayutsya takim chinom shob resursi buli dostupni koli zavdannya kritichnogo shlyahu mayut rozpochatisya pidporyadkovuyuchi usi inshi resursi zavdannyam kritichnogo shlyahu Popri tip proyektu plan proyektu maye viznachati rozpodilennya resursiv na rivni angl Resource Leveling Najdovsha poslidovnist resursno obmezhenih zavdan maye buti viznachena yak kritichnij shlyah V seredovishah sho mayut dekilka proyektiv rozpodilennya resursiv na rivni vikoristovuyetsya v usih proyektah Chasto dosit viznachiti chi prosto obrati odin naskriznij resurs resurs sho vistupaye yak obmezhennya v usih proyektah ta poslidovno roztashuvati proyekti vidpovidno do dostupnosti cogo resursu Cikli planuvannya ta zvorotnogo zv yazku v Ekstremalnomu programuvanni ang Extreme Programming XP z chasovimi mezhami povtoryuvanih cikliv Ekstremalne upravlinnya proyektami V kritichnih oglyadah Upravlinnya proyektami zaznachalosya sho dekilka metodiv upravlinnya proyektami yaki bazuyutsya na metodici Programi ocinki ta kontrolyu angl Program Evaluation and Review Technique PERT ne povnoyu miroyu vidpovidayut multiproyektnomu seredovishu suchasnih kompanij Bilshist z takih kompanij oriyentovani na masshtabni yedinorazovi ne povtoryuvani proyekti v yakih usi vidi upravlinnya vikoristovuyut instrumenti proyektnogo upravlinnya Vikoristannya proyektnoyi modeli dlya proyektiv chi skorishe zavdan sho trivayut dekilka tizhniv na praktici prizvodit do nepotribnih vitrat ta slabkoyi gnuchkosti Zamist vikoristannya klasichnogo upravlinnya proyektami fahivci z upravlinnya proyektami namagayutsya znajti rizni polegsheni metodi modeli taki yak metodologiya upravlinnya proyektami Edzhajl angl Agile Project Management doslivno shvidke ruhlive upravlinnya proyektami vklyuchayuchi Ekstremalne programuvannya angl Extreme programming dlya rozrobki programnogo zabezpechennya a takozh tehniki Skram angl Scrum doslivno natovp skupchennya Uzagalnennya Ekstremalnogo programuvannya dlya zastosuvannya v inshih vidah proyektiv otrimalo nazvu Ekstremalne proyektne upravlinnya sho mozhe buti vikoristane razom z Pobudovoyu procesiv angl Process modeling ta principami upravlinnya vzayemodiyeyu lyudmi angl Human interaction management Upravlinnya poslidovnistyu podij Upravlinnya poslidovnistyu podij angl Event chain methodology ce she odin metod yakij dopovnyuye metodi kritichnogo shlyahu angl Critical Path Method CPM ta metod upravlinnya kritichnim shlyahom angl Critical Chain Project Management CCPM Metod upravlinnya poslidovnistyu podij ce tehnika upravlinnya neviznachenistyu ta analizu strukturi i planu vikonannya robit zavdan sho sfokusovana na viznachenni ta upravlinni podiyami ta poslidovnostyami podij yaki vplivayut na plan realizaciyi proyektu Upravlinnya poslidovnistyu podij dopomagaye zmenshuvati negativnij vpliv dosvidu vzayemodiyi ta osobistih yakostej odnochasno dopomagayuchi modelyuvati neviznachenosti v planah vikonannya proyektiv Upravlinnya poslidovnistyu podij bazuyetsya na nastupnih principah Jmovirnij moment riziku Aktivnist zavdannya v bilshosti realnih procesiv ne ye trivalim bezperervnim procesom Na zavdannya vplivayut zovnishni podiyi yaki mozhut viniknuti na odnomu z etapiv poseredini vikonannya zavdannya Poslidovnist podij Podiyi mozhut viklikati inshi podiyi sho budut stvoryuvati poslidovnosti podij Taki poslidovnosti podij mozhut suttyevo vplivati na shlyah proyektu Kilkisnij analiz vikoristovuyetsya dlya viznachennya kumulyativnogo efektu takih poslidovnostej podij na plan vikonannya proyektu Kritichni podiyi abo poslidovnosti podij Odinochni podiyi abo poslidovnosti podij sho najbilsh jmovirno zmozhut vplinuti na proyekt vvazhayutsya kritichnimi podiyami abo kritichnimi poslidovnostyami podij Voni mozhut buti viznacheni shlyahom analizu Pismove vidobrazhennya proyektu razom z podiyami Navit yaksho proyekt chastkovo zavershenij i trivalist proyektu vartist a takozh informaciya pro podiyi sho stalisya vzhe vidomi isnuye mozhlivist utochnennya informaciyi pro majbutni mozhlivi podiyi sho dozvolyaye sprognozuvati efektivnist majbutnogo vikonannya proyektu Vidobrazhennya poslidovnosti podij Podiyi ta poslidovnosti podij mozhut buti vidobrazheni vikoristovuyuchi diagrami poslidovnosti podij na diagrami Ganta Proyekti v kontrolovanomu seredovishi Model procesiv PRINCE2 Proyekti v kontrolovanomu seredovishi angl Projects in controlled environments PRINCE ce strukturovanij pidhid do upravlinnya proyektami yakij buv stvorenij v 1996 roci yak tipovij metod upravlinnya proyektami Faktichno ce kombinaciya metodologiyi PROMPT sho evolyucionuvala v metodologiyu PRINCE z metodologiyu IBM MITP angl Managing the implementation of the total project MITP Upravlinnya vprovadzhennyam usogo proyektu PRINCE2 proponuye metod upravlinnya proyektami v ramkah chitko viznachenoyi strukturi organizaciyi PRINCE2 opisuye proceduri koordinaciyi lyudej ta aktivnostej v proyekti yak rozroblyati ta kontrolyuvati proyekt ta sho robiti yaksho neobhidno vnesti zmini do proyektu u zv yazku z vidhilennyam vid planu vprovadzhennya Kozhen proces viznacheno z klyuchovimi vhidnimi ta vihidnimi danimi a takozh cilyami ta aktivnostyami yaki neobhidno vikonati dlya dosyagnennya takih cilej Ce dozvolyaye avtomatichno kontrolyuvati bud yake vidhilennya vid planu Rozpodilennya na etapi yakimi mozhlivo upravlyati zabezpechuye efektivnij kontrol resursiv Vprovadzhennya proyektu vidbuvayetsya strukturovano ta kontrolovano zavdyaki integrovanomu kontrolyu za vikonannyam PRINCE2 nadaye yedinu terminologiyu usim uchasnikam proyektu Riznomanitni roli upravlinnya ta sferi vidpovidalnosti sho zadiyani v proyekti povnistyu opisani ta mozhut buti adaptovani shob vidpovidati skladnosti proyektu ta mozhlivostyam organizaciyi Procesne upravlinnya Model mozhlivostej zrilosti poperednik modeli CMMI Podalshij rozvitok koncepciyi kontrolyu v proyektnomu upravlinni prizvodit do ob yednannya metodik procesnogo upravlinnya angl Proces based management Cya sfera rozvivayetsya zavdyaki vikoristannyu Modelej zrilosti angl Maturity models takih yak CMMI angl Capability Maturity Model Integration doslivno Integraciya modeli mozhlivostej zrilosti ta ISO IEC15504 angl Software Process Improvement and Capability Estimation SPICE doslivno Pokrashennya procesu rozrobki programnogo zabezpechennya ta ocinki mozhlivostej Pidhodi do upravlinnya proyektami Edzhajl angl Agile project management bazuyutsya na principah upravlinnya vzayemodiyeyu lyudej angl Human interaction management sho zasnovani na procesnomu pidhodi do spivpraci lyudej Cej pidhid duzhe silno vidriznyayetsya vid tradicijnogo Rozrobka programnogo zabezpechennya Edzhajl chi Gnuchka rozrobka produktu angl Flexible product development rozglyadayut proyekt yak poslidovnist nevelikih zavdan yaki vinikayut ta vikonuyutsya situativno vidpovidno do vimog obstavin Iniciaciya ta vikonannya ye skorishe adaptivnimi do zovnishnih obstavin nizh zavchasno povnistyu splanovanim procesom Grupi procesiv upravlinnya proyektamiTradicijno upravlinnya proyektami vklyuchaye nastupnij perelik elementiv chotiri grupi procesiv ta sistemu kontrolyu Nezalezhno vid metodologiyi chi terminologiyi sho zastosovuyetsya vikoristovuyutsya odni j ti sami bazovi procesi upravlinnya proyektami Etapi vikonannya proyektiv Grupi procesiv zazvichaj vklyuchayut Iniciyuvannya Planuvannya chi rozrobka Ekspluataciya chi vikonannya Zavershennya U proyektnomu seredovishi z doslidnickim nahilom napriklad Doslidzhennya ta proyektuvannya angl Researsh and Development zaznacheni etapi mozhut dopovnyuvatisya tochkami prijnyattya rishen de virishuyetsya chi potribno prodovzhuvati chi pripiniti vprovadzhennya proyektu Iniciyuvannya Grupa procesiv iniciyuvannya Proces iniciyuvannya viznachaye zmist ta mezhi proyektu Yaksho zaznachenij etap vikonuyetsya ne povnoyu miroyu to zdebilshogo proyekt ne bude vidpovidati vimogam biznesu Klyuchovimi kontrolnimi indikatorami dlya zaznachenogo etapu ye rozuminnya biznes seredovisha ta vklyuchennya usih neobhidnih kontrolnih indikatoriv v proyekt Usi nevidpovidnosti problemni pitannya mayut buti rozglyanuti ta rishennya shodo takih pitan mayut buti prijnyati z metoyu yih usunennya Etap iniciyuvannya maye mistiti plan sho visvitlyuye taki pitannya analiz biznes potreb vimog v vimiryuvanih pokaznikah oglyad isnuyuchih procesiv Finansovij analiz vitrat i dohodiv vklyuchayuchi byudzhet analiz zacikavlenimi storonami vklyuchayuchi koristuvachiv pracivnikiv pidtrimki proyektu statut proyektu project charter pidsumkovij dokument iniciaciyi yakij vklyuchaye vitrati zavdannya rezultati ta kalendarnij plan vprovadzhennya Planuvannya ta rozrobka Grupa procesiv planuvannya Pislya etapu iniciyuvannya proyekt zaplanovano z neobhidnim rivnem detalizaciyi Golovne zavdannya splanuvati chas vitrati ta resursi z metoyu adekvatnoyi ocinki roboti yaku neobhidno vikonati ta efektivnogo upravlinnya rizikami protyagom vprovadzhennya proyektu Analogichno grupi procesiv iniciyuvannya nedostatno rozroblenij plan znachno znizhuye shansi proyektu uspishno zavershiti postavleni pered nim zavdannya Planuvannya proyektu zagalom skladayetsya z viznachennya yak planuvati napriklad za rivnem detalizaciyi chi etapami vprovadzhennya rozrobki dokumentu sho viznachaye zmist ta mezhi proyektu viznachennya grupi vidpovidalnih sho planuvatimut proyekt viznachennya rezultativ proyektu ta stvorennya strukturi dekompoziciyi robit viznachennya zavdan yaki neobhidno vikonati dlya dosyagnennya cilej proyektu ta logichne poslidovne ob yednannya takih zavdan ocinki vimog do resursiv dlya zabezpechennya vikonannya zavdan ocinki chasu ta vitrat na vikonannya zavdan rozrobki kalendarnogo planu grafiku rozrobka byudzhetu planuvannya rizikiv otrimannya formalnogo pogodzhennya pochatku roboti Dodatkovi procesi taki yak planuvannya komunikacij viznachennya rolej ta rivnya vidpovidalnosti zakupivel v ramkah proyektu a takozh provedennya poperednoyi zustrichi uchasnikiv proyektu angl Kick off meeting zagalom ye rekomendovanimi Dlya proyektiv z rozrobki novih produktiv konceptualna rozrobka produktu mozhe provoditisya odnochasno z aktivnostyami z planuvannya yaki mozhut dopomogti grupi z planuvannya shlyahom informuvannya pro viznacheni rezultati proyektu ta zaplanovani zavdannya Vikonannya Grupa procesiv vikonannya Vikonannya skladayetsya z procesiv neobhidnih dlya zavershennya robit viznachenih v plani proyektu z metoyu vikonannya vimog proyektu Proces vikonannya vklyuchaye koordinuvannya lyudej ta resursiv odnochasno z integraciyeyu ta vikonannyam zavdan proyektu vidpovidno do planu upravlinnya proyektom Rezultati proyektu ye rezultatami vikonannya zavdan proyektu vidpovidno do planu proyektu Monitoring ta kontrol Monitoring ta Kontrol skladayetsya z procesiv sho vikonuyutsya z metoyu oglyadu stanu vikonannya proyektu shob potencijni problemi buli viznacheni vchasno i koriguyuchi diyi mozhlivo bulo vikonati z metoyu kontrolyu vikonannya proyektu Golovnim zdobutkom ye regulyarnij oglyad ta ocinyuvannya procesu vikonannya proyektu z metoyu viznachennya vidhilen vid planu upravlinnya proyektom Grupa procesiv monitoringu ta kontrolyu Monitoring ta kontrol vklyuchaye vimiryuvannya potochnogo vikonannya zavdan proyektu de mi ye zaraz monitoring zminnih skladovih proyektu zmist ta mezhi proyektu vitrati tosho v porivnyanni do planu upravlinnya proyektu ta bazovogo planu vikonannya proyektu de mi mayemo buti viznachennya koriguyuchih dij z metoyu pravilnogo virishennya vidkritih pitan ta rizikiv Yak mi mozhemo privesti faktichnij stan vikonannya do planovogo vikonannya vpliv na faktori sho mozhut prizvesti do porushennya integrovanogo kontrolyu zmin dlya togo shob lishe pogodzheni zmini vprovadzhuvalisya V bagatoetapnih proyektah procesi monitoringu ta kontrolyu zabezpechuyut zvorotnij zv yazok mizh etapami proyektu zadlya zabezpechennya koriguyuchih chi preventivnih dij z metoyu privedennya proyektu u vidpovidnist z planom upravlinnya proyektom Pidtrimka proyektu ce postijnij proces sho vklyuchaye postijnu pidtrimku kincevih koristuvachiv vipravlennya pomilok onovlennya programnogo zabezpechennya Cikl monitoringu ta kontrolyu Na comu etapi auditori mayut zvertati uvagu na efektivnist ta shvidkist virishennya problem koristuvachiv Napriklad protyagom vprovadzhennya bud yakogo budivelnogo proyektu zmist ta mezhi proyektu mozhut zminyuvatisya Zmini ce normalna ta ochikuvana chastina procesu budivnictva Zmini mozhut buti rezultatom neobhidnih modifikacij konstrukciyi vidminnostyah budivelnogo majdanchika dostupnosti materialiv zmin na vimogu pidryadnoyi organizaciyi vplivom tretih storin i t d Okrim vprovadzhennya zmin voni mayut buti zakripleni v dokumentah shob vidobraziti kincevij rezultat Opisanij proces otrimav nazvu Upravlinnya zminami angl Change management Zazvichaj vlasnik vimagaye ostatochne dokumentuvannya zmin shob zafiksuvati usi zmini a inodi bud yaku zminu sho zminyuye materialni paketi zavershenoyi roboti Dokumentuvannya zdijsnyuyetsya za dopomogoyu dogovirnih dokumentiv zazvichaj ale ne obov yazkovo obmezhuyuchis kreslennyami Kincevij produkt takogo procesu otrimav nazvu doslivno kreslennya yak pobudovano angl As built drawing chi bilsh sprosheno Yak pobudovano angl As built Vimoga shodo nadannya takih kreslen ye normoyu budivelnih dogovoriv Koli zmini vneseni do proyektu zhittyezdatnist proyektu maye buti ocinena she raz Vazhlivo ne vtratiti pochatkovih cilej ta zavdan proyektu Koli usi zmini zibrani prognozovanij rezultat mozhe ne vipravdati investiciyi u proyekt Zavershennya Grupa procesiv zavershennya proyektu Zavershennya vklyuchaye formalne prijnyattya proyektu ta vidpovidno jogo zakrittya Provodyatsya administrativni aktivnosti vklyuchayuchi peredachu do arhivu robochoyi dokumentaciyi ta dokumentuvannya zdobutogo dosvidu Cej etap skladayetsya z zakrittya proyektu Zavershennya usih aktivnostej u vsih grupah procesiv z metoyu formalnogo zakrittya proyektu abo etapu proyektu zakrittya dogovoru kontraktu Zavershennya ta oplata kozhnogo dogovoru vklyuchayuchi virishennya bud yakih vidkritih pitan ta zakrittya kozhnogo dogovoru sho stosuyetsya proyektu v cilomu abo pevnogo etapu proyektu Sistemi kontrolyu proyektiv Kontrol proyektu ce element yakij zabezpechuye vidpovidnist proyektu grafiku vikonannya ta byudzhetu Kontrol proyektu pochinayetsya z planuvannya ta zakinchuyetsya zvitom z vikonannya proyektu pronizuyuchi kozhen element procesu upravlinnya proyektom Kozhen proyekt maye buti ocinenij shodo rivnya neobhidnogo kontrolyu zabagato kontrolyu oznachaye vtratu chasu zamalo kontrolyu oznachaye zbilshennya rizikiv Yaksho kontrol proyektu vprovadzhenij ne virno vartist dlya biznesu poyasnyuyetsya u terminah pomilok vipravlen ta dodatkovih vitrat na audit Sistemi kontrolyu neobhidni dlya vitrat rizikiv yakosti komunikacij chasu zmin zakupivel ta lyudskih resursiv Do togo zh auditori mayut viznachiti naskilki proyekti vplivayut na finansovu zvitnist naskilki dostovirnu informaciyu otrimuyut zamovniki i skilki tochok kontrolyu isnuye Auditori mayut rozglyanuti proces rozrobki ta proceduri na predmet sposobu vprovadzhennya Proces virobnictva ta yakist kincevogo produktu takozh mozhe buti ocinenij yaksho taka potreba vinikaye Biznes mozhe zabazhati vid auditorskoyi firmi fiksuvannya problem na rannih etapah z metoyu zmenshennya zusil neobhidnih na vipravlennya Auditor mozhe vistupati yak konsultant z kontrolyu chastina proyektnoyi komandi abo yak okremij auditor chastina avditu Biznes inodi vikoristovuye formalizovani procesi rozrobki sistem Ce dopomagaye pidtverditi uspishnist rozrobki Formalnij proces efektivnishij u stvorenni silnih tochok kontrolyu Avditori mayut pereviriti takij proces ta pidtverditi jogo yakisnu organizaciyu ta vidpovidnist praktici Garnij formalnij plan vprovadzhennya sistemi harakterizuye Strategiya zadlya privedennya rozrobki do zagalnishih cilej organizaciyi dlya novih sistem Politiki upravlinnya proyektom shodo chasu ta byudzhetu Proceduri sho opisuyut proces Ocinka yakosti zmin Temi z upravlinnya proyektamiMenedzher proyektu Menedzher proyektu ce fahivec u sferi upravlinnya proyektami Menedzher proyektu mozhe buti vidpovidalnim za planuvannya vikonannya ta zavershennya bud yakogo proyektu zazvichaj v budivelnij galuzi prokladanni kabelnih merezh telekomunikaciyah abo rozrobci programnogo zabezpechennya U galuzyah virobnictva ta nadannya poslug takozh isnuyut menedzheri proyektiv Menedzher proyektu ce osoba vidpovidalna za vikonannya viznachenih zavdan proyektu Golovnimi zavdannyami menedzhera proyektiv ye viznachennya chitkih ta realizovnih zavdan proyektu viznachennya vimog do proyektu ta upravlinnya troma obmezhennyami proyektu vartistyu chasom mezhami ta obsyagom zavdan Menedzher proyektu dosit chasto ye predstavnikom zamovnika i maye viznachiti ta sformulyuvati chitki potrebi vimogi zamovnika bazuyuchis na znannyah pro organizaciyu yaku vin predstavlyaye Vminnya vikoristovuvati vnutrishni proceduri pidryadnika ta stvoryuvati tisni zv yazki z priznachenimi predstavnikami zamovnika ye zhittyevo neobhidnim dlya zabezpechennya vikonannya klyuchovih zavdan shodo cini chasu realizaciyi yakosti ta zadovolennya vimog zamovnika Trikutnik upravlinnya proyektami Trikutnik upravlinnya proyektom Yak bud yake pochinannya proyekt vikonuyetsya ta zavershuyetsya vidpovidno do pevnih obmezhen Tradicijno takimi obmezhennyami vvazhayutsya zmist ta mezhi angl Scope chas angl Time ta vartist angl Cost Taki obmezhennya otrimali nazvu Trikutnik upravlinnya proyektami de kozhna storona ye pevnim obmezhennyam Odna storona trikutnika ne mozhe buti zminena shob ne vplinuti na inshi storoni Podalshe utochnennya obmezhen viddilyaye yakist angl Quality chi produktivnist vprovadzhennya proyektu vid zmistu ta mezh i peretvoryuye yakist v chetverte obmezhennya Obmezhennya za chasom ce chas za yakij neobhidno zavershiti proyekt Vartist ce rozmir byudzhetu yakij vidilenij na realizaciyu proyektu Obmezhennya za zmistom ta mezhami ce zavdannya yaki mayut buti zaversheni dlya dosyagnennya kincevogo rezultatu proyektu Zaznacheni tri obmezhennya dosit chasto vzayemopov yazani zbilshennya mezh ta obsyagiv zavdan zazvichaj prizvodit do zbilshennya chasu ta vartosti obmezhenij chas mozhe oznachati zbilshennya vartosti chi zmenshennya zmistu ta mezh proyektu Nauka pro upravlinnya proyektami zabezpechuye instrumenti ta metodi sho nadayut zmogu komandi proyektu ne lishe menedzheru proyektu organizuvati svoyu robotu takim chinom shob vikonati vimogi shodo obmezhen Struktura dekompoziciyi robit Priklad Strukturi dekompoziciyi robit sho vikoristovuyetsya v strukturi zvitnosti NASA Struktura dekompoziciyi robit angl Work breakdown Structure WBS ce derevopodibna struktura sho pokazuye rozpodil zavdan neobhidnih dlya dosyagnennya cili vikonannya zavdannya napriklad programa proyekt ta kontrakt WBS mozhe buti oriyentovana na aparatnu chastinu produkt servis chi proces WBS mozhe buti rozroblena shlyahom poslidovnogo podilu kincevoyi cili zavdannya na komponenti sho pidlyagayut upravlinnyu z oglyadu na rozmir trivalist ta vidpovidalnist napriklad sistemi pidsistemi komponenti zavdannya pid zavdannya paketi robit ta mistyat usi kroki neobhidni dlya vikonannya zavdannya Struktura dekompoziciyi robit zabezpechuye osnovu dlya prirodnogo vprovadzhennya zagalnogo planuvannya ta kontrolyu kontraktu ta ye bazisom dlya podilu roboti na etapi z yakih mozhut buti vidileni zavdannya i mozhe buti vprovadzhena tehnichna kalendarna vitratna zvitnist ta zvitnist na pidstavi lyudino godin Struktura upravlinnya proyektami Priklad strukturi upravlinnya IT proyektami Zhittyevij cikl Programi Investiciyi vklyuchaye upravlinnya proyektom ta zhittyevi cikli vprovadzhennya sistemi razom z aktivnostyami pov yazanimi z rozgortannyam sistemi ta ekspluataciyeyu Vidpovidno do koncepciyi upravlinnya ekspluataciyeyu sistemi ta pov yazani aktivnosti sho vinikayut pislya zavershennya proyektu ne viznacheni v comu posibniku Napriklad div diagramu u Departamenti upravlinnya spravami veteraniv Spoluchenih Shtativ angl US United States Department of Veterans Affairs VA zhittyevij cikl upravlinnya programoyu viznachenij ta opisanij v Strukturi upravlinnya IT proyektami VA shob integruvati proyektni investicijni aktivnosti ta proyekt v cilomu v proces byudzhetuvannya Diagrama Struktura upravlinnya proyektami ilyustruye Etap 4 yakij vinikaye pislya rozgortannya sistemi ta zakrittya proyektu Aktivnosti etapu zakrittya proyektu v VA prodovzhuyutsya protyagom rozgortannya sistemi ta perehodyat v etap ekspluataciyi sistemi z metoyu vidobrazhennya aktivnostej yaki vvazhayutsya chastinoyu proyektu Diagrama pokazuye diyi ta pov yazani artefakti procesu Upravlinnya IT proyektami ta programami v VA Mizhnarodni standarti Bulo dekilka sprob rozvitku standartiv Upravlinnya proyektami taki yak ISO 21500 seriya standartiv Mizhnarodnoyi organizaciyi zi standartizaciyi ISO yaki zastosovuyutsya pri upravlinni proyektami programami ta portfelyami organizacij Model Mozhlivostej Zrilosti angl Capability Maturity Model Institut inzheneriv programnogo zabezpechennya angl Software Engineering Institute Svitova spilnota z Standartiv Efektivnosti proyektiv angl Global Alliance for Project Performance Standards GAPPS vidkritij standart sho opisuye kompetenciyi dlya menedzheriv proyektiv ta program Posibnik z Upravlinnya proyektami angl A Guide to the Project Management Body of Knowledge Metod Germes angl HERMES method zagalnij metod upravlinnya proyektami u Shvejcariyi obranij dlya vikoristannya v Lyuksemburzi ta mizhnarodnih organizaciyah Standarti ISO ISO 9000 sim ya standartiv shodo sistem upravlinnya yakistyu ISO 10006 2003 Sistemi upravlinnya yakistyu ta posibnik z upravlinnya yakistyu v proyektah Prince2 angl Project in controlled Environments doslivno proyekti v kontrolovanih seredovishah Proces rozrobki programnogo zabezpechennya komandoyu angl Team Software Process TSP Institut inzheneriv programnogo zabezpechennya angl Software Engineering Institute Struktura upravlinnya zagalnimi vitratami angl Total cost management framework mizhnarodna metodologiya AACE dlya Integrovanogo portfelyu Program ta Upravlinnya proyektami V model metod rozrobki sistem Metod logichnoyi strukturi angl Logical framework approach metod populyarnij v mizhnarodnih developerskih organizaciyah P2M angl A Guidebook of Project and Program Management for Enterprise Innovation standart po upravlinnyu proyektami sho bazuyetsya na innovacijnih programah Upravlinnya portfelem proyektiv Zrostayucha kilkist organizacij vikoristovuye tak zvane upravlinnya portfelem proyektiv angl Project portfolio management PPM yak instrument viboru prioritetnih proyektiv pislya chogo vikoristovuyutsya metodi upravlinnya proyektami yak zasib uzgodzhennya resursnih konfliktiv u vipadkah koli kilka proyektiv konkuruyut za dostup do spilnih resursiv i yak zasib dosyagnennya rezultativ u formi najkrashoyi vigodi dlya organizacij v cilomu proyektami vikoristovuyutsya dlya togo shob pravilno vprovadzhuvati proyekti a PPM vikoristovuyetsya dlya togo shob vprovadzhuvati pravilni proyekti V bagatoh galuzyah PPM staye metodom viboru ta prioritezaciyi sered proyektiv sho vikoristovuyut odnij j ti zh resursi konflikt intersiv Programne zabezpechennya dlya upravlinnya proyektami Dokladnishe Sistema upravlinnya proyektami Spider Project programnij paket z upravlinnya proyektami ERPNext korporativna sistema planuvannya resursiv pidpriyemstva sho vklyuchaye bagato moduliv Div takozhISO 21500 proyekt PRINCE2 P2M Glosarij terminiv z upravlinnya proyektami Ekstremalne upravlinnya proyektami Statut proyektu Tehnika ocinyuvannya ta analizu program Upravlinnya chasomPrimitkiChatfield Carl A short course in project management Microsoft The Definitive Guide to Project Management Nokes Sebastian 2nd Ed n London Financial Times Prentice Hall 2007 ISBN 978 0 273 71097 4 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 Lewis R Ireland 2006 Project Management McGraw Hill Professional 2006 ISBN 0 07 147160 X p 110 Joseph Phillips 2003 PMP Project Management Professional Study Guide McGraw Hill Professional 2003 ISBN 0 07 223062 2 p 354 Dennis Lock 2007 Project management 9e ed Gower Publishing Ltd 2007 ISBN 0 566 08772 3 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 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 Martin Stevens 2002 Project Management Pathways Association for Project Management APM Publishing Limited 2002 ISBN 1 903494 01 X p xxii Morgen Witzel 2003 Fifty key figures in management Routledge 2003 ISBN 0 415 36977 0 p 96 101 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 Arhiv originalu za 7 chervnya 2007 Procitovano 8 bereznya 2010 Bjarne Kousholt 2007 Project Management Theory and practice Nyt Teknisk Forlag ISBN 87 571 2603 8 p 59 Arhiv originalu za 6 grudnya 2009 Procitovano 8 bereznya 2010 a href wiki D0 A8 D0 B0 D0 B1 D0 BB D0 BE D0 BD Cite web title Shablon Cite web cite web a Obslugovuvannya CS1 Storinki z tekstom archived copy yak znachennya parametru title posilannya F L Harrison Dennis Lock 2004 Advanced project management a structured approach Gower Publishing Ltd 2004 ISBN 0 566 07822 8 p 34 Royce Winston W 1970 PDF Technical Papers of Western Electronic Show and Convention WesCon August 25 28 1970 Los Angeles USA angl Arhiv originalu PDF za 15 bereznya 2016 Stellman Andrew Greene Jennifer 2005 O Reilly Media ISBN 978 0 596 00948 9 Arhiv originalu za 9 lyutogo 2015 Procitovano 8 bereznya 2010 OGC PRINCE2 Background Arhiv originalu za 22 serpnya 2011 Procitovano 8 bereznya 2010 VA Office of Information and Technology 2003 Project Management Guide 14 sichnya 2009 u Wayback Machine US DEPARTMENT OF VETERANS AFFAIRS March 3 2005 NASA 2001 NASA NPR 9501 2D 2010 06 10 u Wayback Machine May 23 2001 Albert Hamilton 2004 Handbook of Project Management Procedures TTL Publishing Ltd ISBN 0 7277 3258 7LiteraturaV Bakumenko Upravlinnya proyektami Politichna enciklopediya Redkol Yu Levenec golova Yu Shapoval zast golovi ta in K Parlamentske vidavnictvo 2011 s 738 ISBN 978 966 611 818 2PosilannyaMax Wideman s Open Source Comparative Glossary of Project Management Terms Open Source Project Management manual Guidelines for Managing Projects from the UK Department for Business Enterprise and Regulatory Reform BERR Burkov V N Korgin N A Novikov D A Vvedenie v teoriyu upravleniya organizacionnymi sistemami Uchebnik Pod red D A Novikova M Knizhnyj dom LIBROKOM 2009 264 s