
ALL(PDF)
.pdfконтракту, а також контексту й середовища, у яких здійснюється проект.
Система управління конфігурацією розом із загальним управлінням змінами створює стандартизований, ефективний і діючий спосіб централізованого управління схваленими змінами й базовими планами в рамках проекту.
Управління конфігурацією сконцентровано на деталізації результатів і процесів, тоді як управління змінами зосереджено на виявленні, документуванні й контролюванні змін проекту й базових планів продукту.
Застосування системи управління конфігурацією, що включає процеси управління змінами, у рамках усього проекту розв'язує три основні задачі:
•установлює метод, що розвивається, який дозволяє послідовно виявляти й запитувати зміни для створених базових планів, а також оцінювати цінність і ефективність даних змін;
•надає можливості для постійного підтвердження й поліпшення проекту шляхом розгляду впливів кожної зміни;
•забезпечує механізм, що дозволяє команді управління проектом узгоджено повідомляти зацікавлені сторони проекту про всі схвалені й відхилені зміни.
Деякі дії по управлінню конфігурацією, що входять у процес здійснення загального управління змінами:
•Визначення конфігурації. Вибір і визначення елементів конфігурації створює базис, виходячи з якого визначається й підтверджується конфігурація продукту, маркіруються продукти й документи, здійснюється управління змінами, і підтримується підзвітність.
•Звітність по статусу конфігурації. При необхідності надання відповідних даних про елемент конфігурації інформація документується, і по ній складається звіт. Така інформація включає список схвалених ідентифікацій конфігурації, статус запропонованих змін конфігурації й статус реалізації схвалених змін.
•Підтвердження й перевірка конфігурації. Підтвердження й перевірки конфігурації дозволяють переконатися, що структура елементів конфігурації проекту є вірною, а відповідні зміни зареєстровані, оцінені, схвалені, відслідковані й належним чином реалізовані. Це гарантує дотримання функціональних вимог, визначених у документації по конфігурації.
Входи, інструменти, методи й виходи Загальне управління змінами: Блок-схема даних у процесі здійснення загального управління змінами Входи
Загальне управління змінами: 1 План управління проектом (Розглянуто раніше)
2. Інформація про виконані роботи (Розглянуто раніше)
3. Запити на зміни Усі процеси моніторингу й управління, а також багато процесів виконання мають як вихід процесу запити на зміни, які можуть включати коригувальний вплив, попереджальну дію або виправлення дефектів. Однак, як правило, коригувальні та попереджувальні дії, впливають не на базові плани проекту, а лише на їхнє виконання.
Входи Загальне управління змінами (продовження):
4. Фактори середовища підприємства На здійснення загального управління змінами можуть впливати такі фактори середовища підприємства: інформаційні системи управління проектами (наприклад, автоматизовані засоби, такі як програмне забезпечення для управління розкладом, система управління конфігурацією, система збору й розподілу інформації або веб-інтерфейси до інших автоматизованих систем, що працюють у режимі онлайн). Це неповний список, але саме він повинен розглядатися в більшості проектів.
Входи Загальне управління змінами (закінчення):
5. Активи процесів організації, які можуть впливати на процес здійснення загального управління змінами, містять у собі:
• процедури управління змінами, що включають дії, згідно з якими будуть модифікуватися офіційні
стандарти компанії, політики, плани й інші документи проекту, а також порядок схвалення, підтвердження й реалізації будь-яких змін;
•процедури схвалення й видачі дозволів на внесення змін;
•базу даних вимірювань процесів, використовувану для збору й забезпечення доступу до даних вимірювань по процесах і продуктах;
•архіви проекту (наприклад, базові плани по змісту, вартості, розкладу й вимірюванню виконання, календарі проекту, сітьові діаграми проекту, реєстри ризиків, заплановані відповідні дії й визначені наслідки ризиків);
•базу знань по управлінню конфігурацією, що містить версії й базові плани по всіх офіційних стандартах компанії, політиках, процедурах і будь-яких документах проекту.
Інструменти й методи Здійснення загального управління змінами:
1. Експертні оцінки На додаток до експертних оцінок команди управління проектом, можуть попросити зацікавлених сторін проекту провести їхні власні експертизи й взяти участь у роботі ради по управлінню змінами. Подібні оцінки й експертизи застосовуються до будь-яких технічних і управлінських деталей протягом цього процесу й можуть надаватися з різноманітних джерел, таких як:
•консультанти;
•зацікавлені сторони проекту, у тому числі замовники або спонсори;
•професійні й технічні асоціації;
•галузеві об'єднання;
•експерти по окремих питаннях;
•офіс управління проектами (Project management office, PMO).
Інструменти й методи Здійснення загального управління змінами:
2. Збори по управлінню змінами Рада по управлінню змінами відповідає за організацію зборів і розгляд запитів на зміну, а також за схвалення або відхилення даних запитів.
Ролі й обов'язки таких рад чітко визначаються й узгоджуються з відповідними зацікавленими сторонами проекту. Всі рішення ради по управлінню змінами документуються й повідомляються зацікавленим сторонам проекту для інформації й наступних дій.
Виходи:
Здійснення загального управління змінами:
Якщо запит на зміну виявляється здійсненним, але тільки за межами змісту проекту, то його схвалення
потребуватиме зміни базового плану.
Якщо запит на зміну виявляється нездійсненним, то він відхиляється й може бути відправлений назад запитуючій стороні для одержання додаткової інформації.
Виходи:
Здійснення загального управління змінами (продовження):
1. Оновлення статусів запитів на зміну
Запити на зміну обробляються менеджером проекту або призначеним членом команди відповідно до системи управління змінами. Схвалені запити на зміну реалізуються процесом Керівництва й управління виконанням проекту. Статус всіх змін, як схвалених, так і не схвалених, оновлюється в журналі запитів на зміну як частина оновлень документів проекту.
.
Виходи:
Здійснення загального управління змінами (продовження):
2. Оновлення плану управління проектом
Елементи плану управління проектом, які можуть бути оновлені, містять у собі, серед іншого:
•будь-які допоміжні плани управління;
•базові плани, піддані процесу формального управління змінами.
Зміни базових планів повинні відображати тільки зміни починаючи із теперішнього моменту. Виконання в минулому не може бути змінено. Це захищає цілісність базових планів і історичні відомості про
виконання в минулому.
.
Виходи:
Здійснення загального управління змінами (закінчення):
3. Оновлення документів проекту
Документи проекту, які можуть бути оновлені в результаті процесу загального управління змінами, містять у собі журнал запитів на зміну й будь-які документи, піддані процесу формального управління змінами.
6. Завершення проекту або фази
Завершення проекту або фази - це процес завершення всіх операцій всіх груп процесів управління проектом з метою формального завершення проекту або фази.
При закритті проекту менеджер проекту розглядає всю попередню інформацію, отриману під час закриття попередніх фаз, що дозволяє впевнитися в тому, що всі роботи із проекту завершені, і проект досяг своїх цілей.
Тому що зміст проекту визначається планом управління проектом, менеджер проекту провадить аналіз даного документа, щоб упевнитися, що проект фактично завершений, перед тим, як формально констатувати це.
Процес завершення проекту або фази також установлює процедури, що досліджують і документують причини, якщо проект припинений до завершення.
Це містить у собі всі дії, необхідні для адміністративного завершення проекту або фази, включаючи покрокові методики, спрямовані на:
•дії й операції, необхідні для задоволення критеріїв завершення або виходу для фази або проекту;
•дії й операції, необхідні для передачі продуктів, послуг або результатів проекту в наступну фазу
або у виробництво й/або операційну діяльність;
•операції, необхідні для збору документів проекту або фази, перевірки успішності або невдачі проекту, акумулювання отриманих знань і архівування інформації із проекту для майбутнього використання організацією.
Завершення проекту або фази: входи, інструменти, методи й виходи
Блок-схема даних при завершенні проекту або фази Входи
Завершення проекту або фази:
1.План управління проектом Розглянуто раніше
2.Прийняті результати Результати, які були прийняті в рамках процесу підтвердження змісту
3.Активи процесів організації, які можуть впливати на процес завершення проекту або фази, містять у собі серед іншого:
•провідні вказівки або вимоги до закриття проекту або фази (наприклад, перевірки проекту, оцінки проекту й критерії передачі);
•історичну інформацію й базу засвоєних уроків (наприклад, записи й документи проекту, всю інформацію й документацію по закриттю проекту, інформацію про результати рішень по відбору попередніх проектів поряд з інформацією про виконання попередніх проектів, а також інформацію про трудомісткість при управлінні ризиками).
Інструменти й методи Завершення проекту або фази:
1. Експертні оцінки
Експертні оцінки застосовуються при проведенні дій по адміністративному закриттю. Експерти підтверджують, що закриття проекту або фази проводиться відповідно до необхідних
стандартів.
Виходи
Завершення проекту або фази: 1.Передача кінцевого продукту, послуги або результату
Вихід відноситься до передачі кінцевого продукту, послуги або результату, для виробництва якого був санкціонований проект (або у випадку закриття фази це відноситься до проміжного продукту, послуги або результату даної фази).
Виходи Завершення проекту або фази (продовження):
2.Оновлення активів процесів організації в результаті процесу завершення проекту або фази, містять
усобі серед іншого:
•Архіви проекту. Документи, отримані в результаті операцій проекту, наприклад план управління проектом, календарі змісту, вартості, розкладу й проекту, реєстри ризиків, документація по управлінню змінами, дії по реагуванню на заплановані ризики й вплив ризиків.
•Документи завершення проекту або фази. Документи завершення проекту або фази, що складаються з формальної документації, що вказує на завершення проекту або фази, а також передача результатів завершеного проекту або фази, наприклад у групу операційної діяльності або в наступну фазу. Під час завершення проекту менеджер проекту оглядає документи попередньої фази, документацію по прийманню замовником із процесу підтвердження змісту і контракту (якщо застосовно), щоб переконатися, що всі вимоги проекту виконані до остаточного завершення проекту. Якщо проект був припинений до завершення, формальна документація пояснює, чому проект був припинений, і встановлює процедури передачі завершених і незавершених результатів скасованого проекту іншим особам.
•Історична інформація. Історична інформація й інформація про засвоєні уроки передається в базу засвоєних уроків для використання в майбутніх проектах або фазах. Сюди може входити інформація із проблем і ризиків, а також по успішно застосованих методах, які можуть бути використані в майбутніх проектах.
Дякую за увагу!

УПРАВЛІННЯ РИЗИКАМИ В ПРОЕКТАХ ІНФОРМАТИЗАЦІЇ
1.Загальні поняття управління ризиками
2.Планування управління ризиками
3.Ідентифікація ризиків
4.Якісний аналіз ризиків
5.Кількісний аналіз ризиків
6.Планування реагування на ризики
7.Моніторинг і контроль ризиків
1. Загальні поняття управління ризиками
Основні поняття в галузі управління ризиками
•
•
•
•
•
Ризик
Невизначеність
Імовірність ризиків
Вимірювання ризиків
Ризик — це небезпека небажаних відхилень від очікуваних станів проекту в майбутньому, із урахуванням яких і приймаються рішення в даний момент.
Ризик - це невизначена подія або умова, яка, у випадку настання, впливає хоча б на одну ціль проекту. Під цілями в цьому випадку розуміються зміст, строки, вартість і якість.
Ризик є об’єктивним явищем, природа якого викликана неоднозначністю, невизначеністю подій. Ризики можуть бути "відомі"- ті, які визначені, оцінені, для яких можливе планування.
Ризики "невідомі" - ті, які не ідентифіковані й не можуть бути прогнозовані. У таких випадках розумним рішенням для команди проекту є виділення загального резерву на можливі втрати.
Хоча специфічні ризики й умови їхнього виникнення не визначені, менеджери проекту знають, виходячи з минулого досвіду, що більшу частину ризиків можна передбачати.
Ризик проекту, що настав, також можна розглядати як проблему.
Причинами виникнення ризиків є невизначеності, що існують у кожному проекті.
Невизначеність — це множина станів внутрішнього та зовнішнього середовища проекту.
Причиною може бути вимога, допущення, обмеження або умова, що створює ймовірність негативних або позитивних результатів.
Фактори невизначеності
•неповне знання всіх параметрів, обставин, ситуацій;
•неможливість адекватного й точного урахування всієї навіть доступної інформації
•наявність імовірнісних характеристик поведінки середовища;
•
•
наявність фактору випадковості
наявність суб'єктивних факторів протидії
Невизначеність в проекті може бути спричинена неспроможністю:
–визначити цілі проекту;
–зрозуміти, хто є зацікавленими особами цього проекту;
–призначення кваліфікованих фахівців, які підтримуються керівником, в команду проекту;
–точно оцінити витрати;
–визначити точно кінцевих користувачів результатів проекту;
–забезпечити хороші умови роботи команді проекту;
–зв'язати всіх людей, залучених в проект, контрактами або документами про взаєморозуміння. Організації сприймають ризик як вплив невизначеності на цілі їхнього проекту або на корпоративні цілі. Для організацій і зацікавлених сторін проекту прийнятними є різні ступені ризику. Це називається
«готовністю приймати ризики».
Для кожного проекту має бути розроблений послідовний підхід до ризиків, а інформація про ризики й управління ними повинна бути відкритою й достовірною. Реагування на ризики відображає те, як організація розуміє баланс між прийняттям ризиків і відхиленням від них.
Взаємозв'язок основних характеристик ризиків Основні фактори ризику в проектах інформатизації:
•зміна вимог;
•помилки при розробці технічного завдання/проектуванні, недогляди й непорозуміння;
•невдалий розподіл обов'язків і розміщення кадрів;
•неправильні оцінки (тривалість, вартість);
•фінансова нестабільність Замовника.
Ризик — це не обов’язково погано. Це загальна властивість всіх проектів. Будь-який проект має деяку міру невизначеності через початкові обмеження і мінливе оточення, в якому вони виконуються.
Ризик має три основні атрибути:
•
•
•
випадок, що містить ризик;
ймовірність;
наслідок (дія ризику).
Характеристики дій по визначенню атрибутів ризиків проекту
Види втрат і ризики
•
•
Фінансові втрати
Трудові втрати
•
•
•
•
•
•
•
•
•
Особливі види втрат
Втрати часу
Соціальні втрати
Нежиттєздатність проекту
Податковий ризик
Ризик недоплати заборгованостей
Ризик незавершеного будівництва
Інші втрати й ризики
Випадкові й систематичні види втрат
Ймовірність ризику (risk probability) — це міра можливості того, що наслідок (дія) ризику дійсно буде мати місце
Важливість ризику (risk exposure) — показник, який може використовуватися в процесі ухвалення рішення і як механізм контролю за ризиками в проекті:
VR = A * q,
де: VR — важливість ризику;
A — загроза (наслідок, дія) ризику (небажаної події); q — ймовірність її настання.
Загроза ризику (risk impact) — міра серйозності негативних наслідків, рівень збитків або оцінка потенційних можливостей, пов’язаних з ризиком.
Є кілька видів випадків, які містять ризик для проекту:
1.Випадки, які можуть статися.
2.Випадки, які матимуть великі наслідки, якщо вони відбудуться.
3.Випадки поза вашим контролем.
4.Випадки, про які вам відомо дуже мало.
Класифікація основних видів ризиків в проекті У залежності від джерела виникнення
Узалежності від місця виникнення
Узалежності від тяжкості проявів За ступенем передбачуваності За можливістю страхування
Існує також класифікація, яка поєднує критерії ймовірності (Р) та наслідків (І) ризику
Класифікація основних видів ризиків в проекті У залежності від джерела виникнення:
–природно-кліматичні;
–технічні;
–виробничі;
–економічні;
–ринкові;
–фінансові;
–соціальні;
–політичні;
–інноваційні;
–регіональні;
–галузеві;
–ризики навмисних дій (вандалізм, нечесність).
Класифікація основних видів ризиків в проекті
Узалежності від місця виникнення:
– зовнішні;
– внутрішні.
Узалежності від тяжкості проявів:
– втрачена вигода;
– збитки;
– втрата;
– банкрутство.
Класифікація основних видів ризиків в проекті За ступенем передбачуваності:
–передбачувані з малою ймовірністю;
–непередбачувані.
За можливістю страхування:
–ризики, що страхуються;
–ризики, що не страхуються.
Класифікація основних видів ризиків в проекті
Існує також класифікація, яка поєднує критерії ймовірності (Р) та наслідків (І) ризику. За цією класифікацією ризики аналогічно до тварин поділяються на такі категорії:
«Тигри». Висока ймовірність, вагомі наслідки. Ці ризики є небезпечними і повинні бути негайно нейтралізовані, тобто ризики мають бути зменшені ще на ранньому етапі ЖЦ проекту.
«Алігатори». Низька ймовірність, вагомі наслідки. Це небезпечні ризики, яких можна уникнути, якщо їх ретельно відслідковувати. За «алігаторами» слід спостерігати і розробити план дій, щоб зупинити їхнє втручання в проект.
«Цуценята». Висока ймовірність, незначні наслідки. За «Цуценятами» також спостерігають, але не так пильно і з менш терміновими планами локалізації.
«Кошенята». Низька ймовірність, незначні наслідки. «Кошенята» керівником проекту можуть бути проігноровані.
Американський Інститут управління проектами (PMI), значно переробив розділи PMBOK , що регламентують процедури управління ризиками.
Управління ризиками - це процеси, пов'язані з ідентифікацією, аналізом ризиків і прийняттям
рішень, які включають максимізацію позитивних і мінімізацію негативних наслідків настання ризикових подій.
Управління проектними ризиками — це, перш за усе, здатність вирішувати:
-що робити з їх проявами;
-коли робити це;
-чи достатньо було зроблено для їх подолання.
Управління ризиками є неперервним процесом, який відбувається на всіх фазах ЖЦ проекту.
Ціль управління проектними ризиками підвищення ймовірності позитивних для цілей проекту подій і зниження ймовірності несприятливих подій.
Управління ризиками на протязі ЖЦ проекту

Слід зазначити, що управління ризиками нині — недостатньо популярна практика в управлінні проектами. А дарма!
У ситуації, коли бюджет строго встановлений, ресурси лімітовані, найгостріше відчувається необхідність у формалізованому управлінні ризиками.
Тому в останній версії PMBOK, розділи що регламентують процедури управління ризиками розширені і містять більш детальний опис процесів, пов'язаних з управлінням ризиками у проектах.
Процес управління ризиками проекту за РМВОК4 включає:
•Планування управління ризиками - вибір підходів і планування діяльності по управлінню ризиками проекту.
•Ідентифікація ризиків - визначення ризиків, здатних вплинути на проект, і документування їхніх характеристик.
•Якісне оцінювання ризиків - якісний аналіз ризиків і умов їхнього виникнення з метою визначення їхнього впливу на успіх проекту.
•Кількісне оцінкювання - кількісний аналіз імовірності виникнення й впливи наслідків ризиків на проект.
•Планування реагування на ризики - визначення процедур і методів по ослабленню негативних наслідків ризикових подій і використанню можливих переваг.
•Моніторинг і контроль ризиків - моніторинг ризиків, визначення ризиків, що залишаються, виконання плану управління ризиками проекту й оцінка ефективності дій по мінімізації ризиків.
2. Планування управління ризиками Планування управління ризиками - процес прийняття рішень по застосуванню й плануванню управління ризиками для конкретного проекту.
Цей процес може містити в собі рішення по організації, кадровому забезпеченню процедур управління ризиками проекту, вибір кращої методології, джерел даних для ідентифікації ризику, часовий інтервал для аналізу ситуації.
Важливо спланувати управління ризиками, адекватне як рівню й типу ризику, так і важливості проекту для організації.
1. Планування управління ризиками: входи, інструменти, методи і виходи
Деякі пояснення - Результати 1 план управління ризиками описує структуру й порядок здійснення управління ризиками в рамках
проекту. Цей план включається до складу плану управління проектом і містить такі елементи:
-Методологія. Визначення підходів, інструментів і джерел даних, які можуть використовуватися для управління ризиками в даному проекті.
-Ролі й відповідальності. Визначення керівних і допоміжних членів команди, а також членів команди, відповідальних за управління ризиками, для кожного виду операцій, включених у план управління ризиками, і роз'яснення їхньої відповідальності.
-Розробка бюджету. Призначення ресурсів і оцінка коштів, необхідних для управління ризиками (ці
дані включаються в базовий план виконання вартості), а також розробка процедур по використанню резерву на можливі втрати.
Деякі пояснення - Результати - Визначення строків. Визначення строків і частоти виконання процесів управління ризиками протягом
усього життєвого циклу проекту, розробка процедур по використанню резервів розкладу на
можливі втрати, а також визначення дій по управлінню ризиками, які будуть включені в розклад проекту.
-Категорії ризиків. Визначення структури, на підставі якої провадиться систематична й всебічна ідентифікація ризиків з потрібним ступенем деталізації; така структура сприяє підвищенню ефективності і якості ідентифікації ризиків.
Вуправлінні ризиками проекту прийняті такі категорії ризиків:
1)стратегічні/комерційні (ST/COM);
2)економічні/фінансові (EC/FIN);
3)організаційні (організація, менеджмент, людський фактор) (ORG);
4)політичні (POL);
5)навколишнього середовища (ENV);
6)технічні (TECH).
Цей перелік, звичайно, може бути доповнений з огляду на специфіку проекту. Деякі пояснення - Результати
- Визначення ймовірності виникнення ризиків і їхніх впливів. Сумлінний і достовірний якісний аналіз ризиків припускає визначення різних рівнів імовірності виникнення ризиків і їхніх впливів. Загальні визначення рівнів імовірності й впливи адаптуються до конкретного проекту в ході процесу планування управління ризиками й використовуються потім у ході процесу якісного аналізу ризиків На наступному слайді наведений приклад визначень негативного впливу, які можуть бути використані при оцінці впливу ризиків, пов'язаних із чотирма цілями проекту. (Подібні таблиці можуть бути створені й відносно позитивних впливів).
Визначення шкал впливу для чотирьох цілей проекту
Деякі пояснення - Результати - Матриця ймовірності й впливу. Пріоритети між ризиками розставляються відповідно до їхніх
імовірних наслідків, які можуть впливати на цілі проекту. Типовим способом розташування ризиків по пріоритету є використання таблиці відповідності або матриці ймовірності й впливу Звичайно організація сама встановлює сполучення ймовірності й впливу, на підставі яких ступінь ризику визначається як «висока», «середня» або «низька», що у свою чергу визначає значимість ризику для планування реагування на даний ризик.
-
Для оцінювання ризиків прийнята шкала вимірювання ризиків Для цього слід обрати інтервал ймовірності і присвоїти йому числове значення. Існують трирівневі та
семирівневі (більш деталізовані) розподіли ймовірності проектного ризику.
Окрім цього ймовірність ризику в проекті може оцінюватися в грошових одиницях чи за певною суб’єктивною шкалою
Трирівневий розподіл ймовірності ризику П’ятирівневий розподіл ймовірності ризику в грошовому вимірі
Відносна шкала наслідків містить лише описові позначення, наприклад «дуже низький», «низький», «середній», «високий» і «дуже високий», які розташовані в порядку зростання максимальної сили впливу ризику згідно з визначенням організації
Деякі пояснення - Результати
-Уточнена готовність зацікавлених сторін проекту приймати ризики. У ході процесу планування управління ризиками готовність зацікавлених сторін проекту приймати ризики може коректуватися стосовно до конкретного проекту.
-Формат звітності. Містить визначення, у який спосіб провадиться документування, аналіз і обмін інформацією про результати процесів управління ризиками. Дає опис змісту й формату реєстру ризиків, а також інших необхідних звітів по ризиках.
-Відстеження. Документує порядок реєстрації всіх операцій по ризиках для цілей даного проекту, а також для майбутніх проектів і включення в документи по накопичених знаннях. Документує, у