Управління проектами інформатизації

Лекції:

Лазарєва Світлана Федорівна

професор кафедри інформаційного менеджменту

413 кімн.

Тел. 537-07-43

Практичні, семінарські та лабораторні:

1 гр. - Лазарєва Світлана Федорівна

2,3 гр. - Самченко Наталія Костянтинівна – ст. викладач кафедри інформаційного менеджменту

РЕКОМЕНДОВАНА ЛІТЕРАТУРА

Основна:

• Арчибальд Р. Управление высокотехнологическими программами и проектами. - М.: ДМК Пресс, 2002.- 464 с.

• Батенко Л.П., Загородніх О.А., Ліщинська В.В. Управління проектами: Навч. посібник. – К.: КНЕУ, 2003. – 231 с.

• Кантор М. Управление программными проектами. Практическое руководство по разработке успешного программного обеспечения.: Пер. с. англ. – М.: Издательский дом "Вильямс", 2002. – 176 с.

• Ройс У. Управление проектами по созданию программного обеспечения. Унифицированный подход. - М. : "ЛОРИ", 2002. – 424 с.

РЕКОМЕНДОВАНА ЛІТЕРАТУРА

Основна:

• Управление программами и проектами: (Модульная программа для менеджеров) / М.Л. Разу и др. – М.: ИНФРА – М., 2000. – 392 с.

• Фергус О’Коннел. Как успешно руководить проектами. Серебряная пуля: Пер. с англ. – М.: КУДИЦ-ОБРАЗ, 2003. – 288 с.

• Джозеф Филлипс. Менеджмент ІТ-проектов.На пути от старта до финиша: Пер. с англ. – М.: “ЛОРИ”, 2005. – 376 с.

• Куперштейн В.И. Microsoft Project 2010 в управлении проектами/Под общей ред. А.В.Цветкова.- Спб.: БХВ- Петербург,2012.- 416 с.

• Лазарєва С.Ф. Електронний навчальний комплекс з дисципліни “ Управління проектами інформатизації ”

РЕКОМЕНДОВАНА ЛІТЕРАТУРА

Додаткова:

• Кочетков А.Г. и др. Управление проектами (зарубежный опыт). – СПб.: "ДваТри", 1992. – 515 с.

• Шапиро В.Д. и др. Управление проектами. – СПб.: "ДваТри", 1993. – 443 с.

• Богданов В. "Управление проектами в Microsoft Project 2003". Учебный курс. – СПб.: Издательский дом "Питер", 2004. – 608 с.

• Управление инвестиционными проектами: Опыт IBM /Р.Браузр, З. Коллар, В.Тан и др. Пер. с англ. С.В. Лонов. — М.: "Инфра -М".-1995.

Мета дисципліни “Управління проектами інформатизації”

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

Завдання дисципліни:

• засвоїти основні теоретичні, методичні та організаційні основи проектного менеджменту;

• оволодіти методами управління проектами на всіх фазах життєвого циклу проекту;

• ознайомитися з особливостями, принципами та задачами проектного менеджменту у сфері інформатизації;

• навчитися застосовувати методи та інструменти управління проектами в діяльності, пов‘язаній з інформатизацією;

• ознайомитися з можливостями найбільш поширених в Україні програмних засобів управління проектами;

Завдання дисципліни (закінчення):

• набути практичних навичок створення інформаційної системи управління проектами у середовищі MS Project;

• отримати практичні навички організації, планування, контролю та регулювання процесів управління ІТ-проектами;

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

Поточний контроль

а) виконання завдань та відповіді на семінарських (практичних,лабораторних) заняттях - 30 балів:

• Результати експрес-контролю (тестування) – 14 балів;

• Лабораторна робота №1 + статут 4+2=6 балів;

• Лабораторні роботи № 2-5 – 8 балів;

• Задача аналіз проектних ризиків – 2 бали.

б) виконання завдань для самостійного опрацювання (2x5=10 балів) (Підготовка реферату (есе) та його презентація або переклад іншомовних текстів; підготовка реферативних матеріалів з публікацій, участь у науковій конференції тощо).

в) виконання модульних (контрольних) завдань (два модуля) – 2x5=10 балів.

г) заохочувальний бал (бонус) – 5 балів.

Усього – 50 + 5 балів

За вибором студента

Курсова робота

100 балів.

Підсумковий контроль: державний іспит

Оцінка на іспиті - 50 балів

Максимальна оцінка на державному іспиті

100 балів (50+50)

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

• Проект і сутність проектної діяльності.

• Міжнародні та національні стандарти з управління проектами.

• Класифікація проектів.

• Життєвий цикл і фази проекту.

• Моделювання і стандарти життєвого циклу проектів інформатизації.

• Учасники й оточення проекту.

• Методичні засади структуризації проекту.

1. Проект і сутність проектної діяльності

Визначення проекту:

Що таке проект?

Що таке управління проектом?

Управління проектами (Project Management)

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

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

Зв'язок методології управління проектами з іншими управлінськими дисциплінами

Піраміда “арсеналу” управління проектом

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

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

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

Розвиток управління проектами як науки та галузі практичної діяльності бере свій початок з середини 50-х років минулого століття

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

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

У 60–70-х рр. XX ст. в управлінні проектами панувала «технічна» професійна парадигма.

На початку 80-х рр. на зміну попередній прийшла «Менеджерська» професійна парадигма, яка ще продовжує і нині впливати на діяльність з управління проектами.

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

Відбувається переорієнтація акцентів у напрямку м’яких компонентів: команди, учасників проекту, зацікавлених сторін, тобто на особистості, від яких і залежить майбутнє управління проектами. Розвиваються гнучкі методології УП - Agile Project Management

Ефективно будувати світ проектів можуть тільки фахові, духовні і креативні проектні менеджери.

Духовна складова включає такі магії проектного управління:

• магію віри,

• магію влади,

• магію лідерства,

• магію компетенції,

• магію цілепокладання,

• магію ціледосягнення,

• магію системи,

• магію процесу,

• магію очікувань,

• магію результату,

• магію розвитку тощо.

C. Д. Бушуєв, Н. С. Бушуєва

(Українська асоціація УП)

Основні характеристики будь-якого проекту:

• Спрямованість на досягнення конкретної цілі/цілей;

• Координоване виконання взаємопов’язаних дій;

• Встановлена протяжність у часі (з певним початком і закінченням);

• Визначені ресурси - трудові, фінансові, обладнання та інформація;

• Певний ступінь неповторності та унікальності;

• Ризик (конфлікти).

Взаємозалежність основних ознак проекту

Тріада проектного менеджменту

Проекти розрізняються за обсягом, змістом і формою

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

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

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

Проекти розрізняються за обсягом, змістом і формою

Проекти можуть виконуватись як зовнішніх, так і внутрішніх клієнтів і замовників (розробка або впровадження готової ІС у клієнта – це проект, підготовка пропозицій щодо удосконалення системи мотивації персоналу – також проект)

Проект може виконуватися на основі офіційного договору (підписаного обома сторонами, наприклад, договір на розробку ПЗ) або за неформальною домовленістю (встановлення нової програми на комп’ютер колеги)

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

Основні принципи управління проектом інформатизації

• Принцип успіху

• Принцип зобов'язань

• Принцип альтернатив

• Принцип єдиноначальності

• Принцип культурного середовища (придатності)

• Процесний принцип

• Принцип життєвого циклу

1. Принцип успіху

Ціль управління проектом - робити успішний продукт.

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

Багато проектів виконуються "вчасно й у межах бюджету", але продукт не є успішним, і навпаки багато проектів не є "вчасними й у межах бюджету", але продукт є успішним.

2. Принцип зобов'язань

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

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

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

3.Принцип альтернатив

Основні змінні процесу управління проектом інформатизації повинні бути взаємно погодженими:

• можливості (масштаб) продукту,

• якість,

• термін (час) виробництва продукту,

• вартість.

4.Принцип єдиноначальності

Цей принцип необхідний для ефективного розподілу зобов'язань щодо проекту.

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

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

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

5. Принцип культурного середовища

Керівництво проекту повинне створювати сприятливе культурне середовище, щоб команда проекту працювала на повну силу.

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

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

6. Процесний принцип

Для виконання задач проекту повинні існувати ефективні політики й процедури, які, як мінімум, повинні охоплювати:

• чіткі ролі й обов'язки,

• передачу прав і відповідальності,

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

7.Принцип життєвого циклу

Спочатку плануйте, потім робіть.

Процес успішного управління проектом складається з двох великих фаз:

• планування,

• виконання.

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

Життєвий цикл проекту характеризується "віхами", що позначають початок проекту, "контрольні точки", які він повинен перетнути, і кінець проекту.

Портфель проектів

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

Проекти й програми портфеля не обов'язково є взаємозалежними або прямо пов'язаними.

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

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

Управління портфелями передбачає забезпечення перегляду проектів і програм з метою встановлення пріоритетів при розподілі ресурсів і відповідності портфеля стратегіям організації.

Програма

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

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

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

Управління програмою

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

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

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

Управління програмами

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

Дії, пов'язані із цими взаємозалежностями, можуть включати:

• зняття обмежень по ресурсах і/або вирішення конфліктів, що зачіпають кілька проектів у рамках системи;

• узгодження організаційного/стратегічного напрямку, що зачіпає цілі й задачі проекту й програми; і

• вирішення питань і управління змінами в рамках загальної структури управління.

Як приклад програми можна навести Національну Програму інформатизації України

Проекти й стратегічне планування

Проекти найчастіше використовуються як засоби виконання стратегічного плану організації.

Проекти, як правило, авторизуються в результаті одного або кількох стратегічних міркувань:

• вимоги ринку;

• стратегічні можливості/потреби підприємства;

• вимоги замовника;

• технологічний прогрес; і

• законодавчі вимоги.

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

Порівняння проектів, програм і портфелів

Порівняння проектів, програм і портфелів

Порівняння проектів, програм і портфелів

Порівняння проектів, програм і портфелів

Порівняння проектів, програм і портфелів

Порівняння проектів, програм і портфелів (закінчення)

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

Перше: Управління проектами орієнтоване на новацію або зміни.

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

Управління проектами, навпаки, шукає змін, тоді як операційне управління шукає однаковості.

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

Менеджеру проекту доводиться стикатися з не завжди передбачуваними і не завжди виправданими витратами.

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

Друге: на відміну від виробничої системи проект є одноразовою, а не циклічною діяльністю. Виробнича діяльність навпаки, пов'язана з циклами, які періодично повторюються (щогодини, щодня, кожного тижня і т.д.).

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

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

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

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

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

Четверте: існують відмінності в шляхах прискорення робіт у разі проекту й у виробництві.

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

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

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

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

Різниця у функціонуванні підприємства і проекту

Наслідки зазначених відмінностей

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

• Ресурси, необхідні для виконання проекту, і кінцеві результати невизначені й складно передбачувані.

• Цілі проекту повинні бути чіткими, зрозумілими і прийнятими усіма, хто відповідає або впливає на виконання проекту.

• Рішення в управлінні проектами повинні бути спрямовані на роботу, що залишилась.

Закони управління проектами:

Перший закон. Усі рішення необхідно спрямовувати на досягнення цілей проекту.

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

В УП принципову роль відіграють чотири чинники:

• час

• ресурси

• гроші

• якість

Основні параметри управління проектом:

• Кількість рівнів управління проектом

• Критерії оцінювання завершення проекту та його окремих етапів

• Методи звітності, що будуть використовуватись

• Система та засоби обміном інформацією

• Регулярність проведення нарад

Планування - основа успішного завершення проекту:

• Встановлення кінцевої цілі

• Визначення задач (робіт). Задача (робота) - це будь-які дії або події, які необхідні для виконання проекту

• Встановлення обсягів робіт по проекту

• Встановлення термінів виконання робіт і проекту в цілому

• Оцінка бюджету

• Встановлення вимог до якості

• Встановлення пріоритетів

• Розробка стратегії управління проектом (один чи кілька менеджерів буде управляти проектом)

Методи складання розкладу проекту:

“зверху-вниз” - для великих проектів;

“знизу-вверх” - для невеликих, типових проектів.

Призначення ресурсів

Ресурси - люди, обладнання, матеріали та ін., необхідні для виконання робіт по проекту

2. Міжнародні та національні стандарти з управління проектами

1. Види стандартів та їх класифікація

стандарт (від англ. норма, зразок) - це зразок, еталон, модель, прийняті за вихідні для зіставлення з ними інших подібних об'єктів.

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

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

Законодавство

В Україні діяльність, пов’язана зі стандартизацією здійснюється відповідно до закону України "Про стандартизацію"

Основні терміни, використовувані у законі “Про стандартизацію”

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

Основні терміни

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

Основні терміни

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

Цей термін охоплює такі поняття як "стандарт", "кодекс усталеної практики" і "технічні умови"

Основні терміни

Міжнародний і регіональний стандарти - стандарти, прийняті, відповідно, міжнародним або регіональним органом стандартизації

Основні терміни

Національні стандарти - державні стандарти України, прийняті центральним органом виконавчої влади у сфері стандартизації та доступні для широкого кола користувачів

Основні терміни

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

Стандарти можна класифікувати за різними ознаками

• за предметом стандартизації

• залежно від рівня суб'єкта стандартизації, який приймає чи схвалює стандарти

• за методичним джерелом

1. За предметом стандартизації розрізняють:

• стандарти з управління проектами (ISO 10006 );

• стандарти на організацію життєвого циклу (ЖЦ) продукції та послуг, створення та використання автоматизованих систем (АС), інформаційних систем та програмного забезпечення (ПЗ) (ISO/IEC 12207, Information Technology — Software life cycle processes (1995); ISO/IEC 15288 CD2, Life Cycle Management — System Life Cycle Processes (2000));

• професійні кваліфікаційні стандарти з управління проектами;

• функціональні стандарти (стандарти на мови програмування, інтерфейси, протоколи);

• стандарти сертифікації та ін.

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

• офіційні міжнародні стандарти, кодекси усталеної практики та класифікатори, прийняті чи схвалені міжнародними консорціумами та комітетами зі стандартизації (ISO, OSF, OMG (раніше CODASYL);

• офіційні національні або національні відомчі стандарти, кодекси усталеної практики та класифікатори, прийняті чи схвалені центральним органом виконавчої влади у сфері стандартизації, видані ним каталоги та реєстри загальнодержавного застосування (наприклад, національний стандарт США ANSI/PMI 99-001-2000);

• корпоративні (фірмові) стандарти, кодекси усталеної практики та класифікатори, прийняті чи схвалені провідними компаніями галузі, наприклад, Oracle CDM (Custom Development Method), Oracle PJM (Project Development Method), Microsoft Solutions Framework (MSF) або Rational Unified Process (RUP) тощо;

• стандарти, кодекси усталеної практики та технічні умови, прийняті чи схвалені іншими суб'єктами, що займаються стандартизацією;

• стандарти "де-факто" (PMBoK, мова діаграм SADT Д. Росса).

3. За методичним джерелом:

• методичні матеріали фірм-розробників ПЗ;

• методичні матеріали фірм-консультантів;

• методичні матеріали наукових центрів;

• методичні матеріали консорціумів зі стандартизації (наприклад, UNIDO, Price Waterhouse SMM, SEI CMM).

Вони можуть мати різну назву: метод, методологія, підхід, модель.

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

• ступенем обов'язковості для організацій різних типів;

• конкретністю та деталізацією вимог, які вони містять;

• відкритістю та гнучкістю, можливістю адаптування до конкретних умов.

Глобалізація стандартизації в галузі РМ розвивається в двох напрямках:

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

• уніфікація вимог до компетентності менеджерів і фахівців з РМ.

Сучасні підходи до стандартизації в галузі РМ засновані на:

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

для тих галузей РМ, описати які у вигляді об'єктів стандартизації недоцільно або неможливо, використовуються професійні кваліфікаційні стандарти (вимоги) до діяльності фахівців із РМ (Project Management Professional) і менеджерів проектів (Project Manager).

Базові напрямки у міжнародній кооперації з розвитку ПМ:

• формування однакових підходів до уніфікації знань і стандартизації проектної діяльності,

• формування єдиних глосаріїв і системи вимог і т. ін.

Всеохоплюючих систем міжнародних стандартів з РМ немає й, очевидно, бути не може

Це пов'язано як із принциповою неможливістю комплексної стандартизації діяльності в соціальних системах (специфіка сучасних проектів як системи), так і з недоцільністю розробки стандартів з великого кола питань сучасного РМ

Стандарти завжди мають зворотний бік.

З одного боку, вони нормують проектну діяльність, тобто відповідають на запитання "як правильно робити?"

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

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

• Міжнародна організація зі стандартизації ISO (The International Organization for Standardization — ISO) є всесвітньою федерацією національних організацій по стандартизації (комітетів-членів ISO) до складу якої входять 120 країн. Україна є повноправним членом ISO з 1993 р. Як національний комітет-член входить до складу комітетів: CASCO (Комітет з оцінювання відповідності), STACO (Комітет з наукових принципів стандартизації), DEVCO (Комітет з надання допомоги країнам, що розвиваються), REMCO (Комітет зі стандартних зразків), CAPOLCO (Комітет із захисту інтересів споживачів). Україна бере активну участь у роботі спільного ТК ISO/IEC СТК1 "Інформаційні технології", який створений у 1987 р;

• Міжнародна асоціація проектного менеджменту (International Project Management Association – IPMA) об'єднує 45 національних асоціацій і є авторитетною професійною організацією в галузі управління проектами. Україна в IPMA представлена Національною асоціацією управління проектами УКРНЕТ (UPMA);

• Інститут управління проектами США (Project Management Institute – PMI). Членами PMI є фахівці в галузі управління проектами з усього світу, в різних країнах функціонують відділення інституту. PMI веде активне розроблення стандартів у сфері управління проектами.

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

• ISO/IEC 12207, Information Technology — Software life cycle processes;

• ISO/IEC TR 16326:1999 Software engineering — Guide for the application of ISO/IEC 12207 to project management - Програмна інженерія. Посібник для впровадження ISO/IEC 12207 у проектний менеджмент.

Міжнародні стандарти в галузі РМ

• ISO 15288:2000, Life Cycle Management — System Life Cycle Processes (2000) - Управління життєвим циклом. Процеси системи життєвого циклу

• ISO 15188:2001 Project management guidelines for terminology standardization - Провідні вказівки проектного менеджменту щодо стандартизації термінології.

Міжнародні стандарти в галузі РМ (продовження)

ISO 10005:1995 Administrative Quality Management. Guidelines for Quality Programs - Адміністративне управління якістю. Провідні вказівки щодо програм якості

ISO 10006:1997 Quality management — Guidelines to quality in project management - Менеджмент якості. Провідні вказівки щодо якості при управлінні проектами

ISO 10007:1995 Quality Management— Guidelines for configuration management - Менеджмент якості. Провідні вказівки щодо конфігураційного менеджменту

Міжнародні стандарти в галузі РМ (продовження)

ISO 9000:2000 Quality Management Systems — Fundamentals and Vocabulary Системи менеджменту якості. Основи та словник.

ISO 9000-3 - настанови щодо застосування ISO - 9001 до розроблення, поставляння та супроводження ПЗ.

ISO 9004:2000 Quality Management Systems — Guidelines for performance improvements - Системи менеджменту якості. Провідні вказівки щодо впровадження удосконалень.

Міжнародні стандарти в галузі РМ (продовження)

ISO 21500:2012. Guidance on project management «Керівництво з управління проектами».

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

Міжнародні стандарти в галузі РМ (закінчення)

ISO/AWI 22799 Building construction — Process management— Guidelines for project management systems - Побудова конструкцій. Процесний менеджмент. Провідні вказівки щодо систем проектного менеджменту.

Професійні міжнародні й національні кваліфікаційні стандарти для менеджерів проектів й/або фахівців з управління проектами

• ICB (International Competence Baseline) є офіційним міжнародним Зводом знань у галузі проектного менеджменту, що підтримується й розвивається IPMA. (в Україні він представлений NCB UA (National Competence Baseline, Version 3.1), що сертифікується UPMA);

• PMCDF– Project Management Competence Development Framework – PMI PMBoK Guide

• P2M PMAJ (Японія)

• GAPPS (Global Alliance for Project Performance Standards

Стандарт OPM3

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

Для того, щоб допомогти їм оцінювати і розвивати свої можливості з ефективної реалізації проектів, Американським Інститутом Управління проектами (PMI) був запропонований стандарт OPM3 (Organization Project Management Maturity Mode) — Модель Організаційної Зрілості Управління Проектами.

Модель Організаційної Зрілості Управління Проектами

Виділяють три рівні зрілості суб’єктів господарювання, які запровадили управління проектами (стандарт OPM3):

1)         управління проектами (PM3 = Project Management Maturity Model);

2)         управління програмами й проектами (P2M3 = Programme and Project Management Maturity Model);

3)         управління портфелями, програмами й проектами (P3M3 = = Portfolio, Programme and Project Management Maturity Model).

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

Ретроспектива розвитку британських національних стандартів з управління проектами

Багато інших країн світу також мають, або розробляють свої національні стандарти.

Зокрема, Росія в 2011 році прийняла такі стандарти з УП:

• ГОСТ Р 54869 – 2011 «Проектний менеджмент. Вимоги до управління проектом»;

• ГОСТ Р 54870 – 2011 «Проектний менеджмент. Вимоги до управління портфелем проектів»;

• ГОСТ Р 54871 – 2011 «Проектний менеджмент. Вимоги до управління програмою».

Національні стандарти деяких країн світу

Національні стандарти деяких країн світу

Національні стандарти деяких країн світу

Національні стандарти деяких країн світу

В Україні національних стандартів з управління проектами не існує, але широко використовуються стандарти IPMA, PMI, які активно пропагує Українська асоціація управління проектами, і частково японський стандарт P2M, що використовується для управління інноваційними проектами.

3. Класифікація проектів

Різноманітність проектів, які зустрічаються, можна класифікувати за різними критеріями

за класом проекту (складом і структурою самого проекту та його предметної галузі)

монопроект — окремий проект різних типів, видів та масштабів;

мультипроект — комплексний проект, який складається з ряду монопроектів і потребує застосування багатопроектного управління;

мегапроект — цільові програми розвитку регіонів, галузей, держави, які включають до свого складу ряд моно- і мультипроектів;

за типом проекту (основними сферами діяльності, в яких здійснюється проект)

• соціальні,

• економічні,

• організаційні,

• технічні,

• змішані.

Соціальні проекти

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

- терміни і тривалість проекту залежать від ймовірнісних чинників або тільки намічаються і надалі підлягають уточненню;

- витрати залежать від бюджетних асигнувань;

- ресурси виділяються по мірі потреби;

- мають велику невизначеність.

Економічні проекти:

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

- ресурси надаються по мірі необхідності і в межах можливого;

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

Організаційні проекти

• проекти заздалегідь визначені, але результати проекту кількісно і якісно важко визначити, оскільки вони пов'язані з організаційним поліпшенням системи;

• строки і тривалість задаються заздалегідь, ресурси надаються по можливості;

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

за видом проекту (характером предметної галузі проекту)

• інвестиційні,

• інноваційні,

• дослідження і розвитку,

• навчально-освітні,

• ІТ-проекти (інформатизації),

• комбіновані.

Інвестиційний проект - головною метою є створення або реновація основних фондів, що вимагає вкладення інвестицій

- мета, термін завершення і тривалість, витрати на проект чітко визначені і фіксовані.

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

Інноваційний

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

Проекти дослідження і розвитку

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

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

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

Проект інформатизації:

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

Закон України «Про Концепцію Національної програми інформатизації»

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

• короткострокові (до 3 років),

• середньострокові (від 3 до 5 років),

• довгострокові (понад 5 років).

Проекти можна також класифікувати:

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

• дрібні,

• середні,

• великі,

• дуже великі.

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

Масштаби проектів можна розглядати й у більш конкретній формі:

• міждержавні,

• міжнародні,

• національні,

• міжрегіональні та регіональні,

• міжгалузеві та галузеві,

• корпоративні,

• відомчі,

• проекти одного підприємства;

за складністю (ступенем складності) розрізняють:

• прості,

• складні та

• дуже складні.

Ступінь складності залежить від характеру і новизни завдань, які необхідно виконати, ступеня ретельності підготовки і розробки всіх аспектів аналізу проектів, вимог до рівня професійності й досвіду управлінської команди.

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

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

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

• незалежні,

• взаємовиключаючі,

• умовні,

• заміщуючі,

• синергічні.

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

Поняття “нормального проекту"

Нормальним вважається той проект в якому більш-менш збалансований вплив таких чинників:

• масштаб або розмір проекту;

• терміни реалізації (тривалість);

• якість;

• обмеженість ресурсів.

Особливості управління малими проектами

• застосування спрощених методів управління, розподілу матеріально-технічних і трудових ресурсів, проектні скорочення не на шкоду якості.

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

- ділянки роботи;

- методи роботи;

- графіки основних операцій;

- форми звітів;

- умови контракту.

Особливості управління малими проектами

Для малих проектів рекомендується:

- призначити одного адміністратора;

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

- кожний член команди повинен чітко знати задачі і обсяги робіт;

- при плануванні і складанні графіка робіт застосовувати прості методи;

- пуск або введення в експлуатацію повинні здійснювати ті ж фахівці, що починали проект.

Особливості управління мегапроектами

Мегапроекти:

- висока вартість;

- потреба в фінансових коштах вимагає нетрадиційної форми фінансування;

- великий обсяг робіт;

- необхідність участі інших країн;

- віддаленість районів, де реалізуюся мегапроекти, додаткові витрати на інфраструктуру;

- вплив на навколишнє середовище регіону.

Особливості управління мегапроектами

При організації управління необхідно враховувати чинники:

- розподіл елементів проекту по різних виконавцях і необхідність координації їх діяльності;

- необхідність аналізу соціального середовища регіону, країни загалом, ряду країн - учасниць проекту;

- необхідність виділення в якості самостійної фази розробку концепції проекту;

- розробка і постійне оновлення планів проекту;

- необхідність моніторингу проекту з постійним оновленням всіх його елементів;

- урахування унікальності мегапроекту.

Особливості управління короткостроковими проектами

Короткострокові проекти:

- стислі терміни реалізації;

- вартість може складати до кількох десятків тисяч доларів і може зростати в процесі реалізації.

Особливості управління короткостроковими проектами

Рекомендації:

• введення матричної організаційної структури;

• покладання відповідальності за всю діяльність по реалізації проекту на один підрозділ;

• забезпечення завершення проекту силами тих самих фахівців, що його починали;

• передати частину повноважень від керівника з правом прийняття рішень (делегувати повноваження);

• максимально скасувати і скоротити звітність, великі наради. Оперативно вирішувати усі питання;

• звести до min зміни в ході робіт;

• використовувати графіки робіт тільки з метою контролю;

• створити і використовувати систему стимулювання для виконавців;

• співробітництво з мінімальним числом підрядчиків.

Особливості управління бездефектними проектами

Бездефектні проекти - домінує підвищена якість.

Для них характерна висока вартість.

Вимоги:

• об'єднаний план проектних і будівельних робіт

• поєднання графіка будівництва з графіком пускових робіт;

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

• аналіз проблем, пов'язаних з проектом, що дозволяє їх виявити і усунути;

• застосування max гнучкої системи УП.

Особливості управління мультипроектами

1) Один підрядчик виконує комплекс схожих робіт для різних замовників

2) кілька підрядчиків виконують роботи для одного об'єкта й одного замовника

3) кілька підрядчиків виконують роботи за окремими контрактами для різних замовників у загальному географічному просторі.

У названих варіантах мова йде про змагання в умовах обмежених ресурсів.

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

Особливості управління проектами модульного будівництва

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

Особливості, які необхідно враховувати:

- треба створити спеціальну комплексну робочу групу фахівців по модулях;

- кожна група повинна працювати як складова однієї команди,

- план проекту повинен враховувати вимоги до своєчасності виконання робіт і повинен бути пов'язаний з іншими роботами;

- одне з самих складних – комплексування модулів (наприклад, доставка модулів до будівельного майданчика, об'єднання модулів ПЗ в систему тощо).

Особливості управління міжнародними проектами

Міжнародні проекти - характерно:

- складність і висока вартість;

- важлива роль в економіці і політиці;

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

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

- тривалість підготовчого періоду звичайно є більшою у зв'язку з необхідністю організації і управління

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

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

4. Життєвий цикл і фази проекту

Життєвий цикл проекту (ЖЦП)

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

Життєвий цикл проекту

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

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

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

1 - Початкова фаза або концепція Головний зміст робіт:

• збір початкових даних і аналіз існуючого стану;

• попередні дослідження;

• виявлення потреб у змінах;

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

• визначення і порівняльна характеристика альтернатив;

• представлення пропозицій, їх випробування і експертиза;

• затвердження концепції й отримання схвалення для наступної фази розробки.

2 - Фаза організації й підготовки - розробка основних компонентів проекту і підготовка до його реалізації. Загальний зміст робіт:

• призначення керівника і формування команди проекту;

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

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

• організація проведення торгів, укладання субконтрактів;

• організація виконання базових проектів і дослідно-конструкторських робіт по проекту;

• презентація проекту, отримання ухвали на продовження робіт.

3 - Фаза реалізації (виконання робіт) проекту - виконання основних робіт по досягненню основних цілей проекту. Основні роботи:

• організація проведення торгів і укладання контрактів;

• введення в дію системи управління проектом;

• організація виконання робіт;

• введення в дію засобів і способів комунікації учасників проекту;

• введення в дію системи мотивації і стимулювання команди проекту;

• детальне проектування і технічна специфікація;

• оперативне планування робіт;

• встановлення системи інформаційного контролю за ходом робіт;

• організація і управління матеріально-технічним забезпеченням робіт;

• виконання робіт, передбачених проектом;

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

• розв'язання задач і проблем, що виникли.

4 - Фаза завершення проекту - досягаються кінцеві цілі проекту, підведення підсумків вирішення конфліктів і закриття проекту. Основний зміст робіт:

• планування процесу завершення;

• експлуатаційне випробування продукту;

• підготовка кадрів для експлуатації відповідного об'єкта;

• підготовка документації;

• здавання об'єкта замовнику;

• введення в експлуатацію;

• оцінка результатів проекту і підведення підсумків;

• підготовка підсумкових документів;

• закриття робіт і проектів;

• вирішення конфліктних ситуацій;

• реалізація ресурсів, що залишилися;

• накопичення фактичних і дослідних даних для подальших проектів;

• розформування команди проекту.

Узагальнена структура життєвого циклу, як правило, відображає такі характеристики:

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

• Вплив зацікавлених сторін проекту, ризик і невизначеність (як показано на слайді 132) мають найбільші значення на початку проекту. Ці фактори зменшуються по ходу проекту.

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

Типові рівні вартості й забезпечення проекту персоналом протягом життєвого циклу проекту

Вплив змінної, заснованої на строках проекту

Слід відрізняти життєвий цикл проекту від життєвого циклу продукту

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

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

Взаємозв'язки життєвого циклу проекту й продукту

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

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

Існує безліч можливих взаємозв'язків

Наприклад, розробка нового продукту сама по собі може бути проектом.

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

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

У кожному з цих прикладів життєвий цикл проекту відрізняється від життєвого циклу продукту.

З одним продуктом може бути пов'язано безліч проектів

Додаткової ефективності можна досягти, управляючи всіма супутніми проектами в сукупності.

Наприклад, з розробкою нової ІС може бути пов'язана низка окремих проектів.

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

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

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

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

Фази проекту - це елемент життєвого циклу проекту. Фаза проекту не є групою процесів управління проектом.

Структура фаз дозволяє розділити проект на логічні підгрупи для більш легкого управління, планування й контролю.

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

Незалежно від кількості фаз, що складають проект, всі фази мають схожі характеристики:

• При послідовному виконанні фаз завершення фази супроводжується певного роду передачею отриманого продукту як результат фази.

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

• Для успішного досягнення головного результату або мети фази потрібен додатковий ступінь контролю.

Структура фаз забезпечує формальну основу для контролю.

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

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

Зв'язки між фазами

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

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

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

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

Приклад трифазного проекту

Приклад проекту з фазами, що перекриваються

Розподіл ЖЦ інвестиційного проекту на фази може бути різноманітним, наприклад, за пропозицією ЮНІДО виділяються:

• Передінвестиційна фаза

• Інвестиційна фаза

• Експлуатаційна фаза

Передінвестиційна фаза

• Аналіз інвестиційних можливостей (Identification)

• Попереднє ТЕО (Pre-Feasibility Study)

• ТЕО (Feasibility Study) Feasibility Study)

• Доповідь про інвестиційні можливості (Appraisal Report)

Інвестиційна фаза

• Переговори й укладання контрактів (Negotiating & Contracting)

• Проектування (Engineering Design)

• Будівництво (Construction)

• Маркетинг (Pre-Production Marketing)

• Навчання (Training)

Експлуатаційна фаза

• Прийом і запуск (Commissioning & Start)

• Заміна обладнання (Replacement)

• Розширення, інновація (Expansion, Innovation)

Фазы инвестиционного проекта

Принципова схема чергування фаз реалізації проекту

Етапи створення системи

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

• Проект і сутність проектної діяльності.

• Міжнародні та національні стандарти з управління проектами.

• Класифікація проектів.

• Життєвий цикл і фази проекту.

• Моделювання і стандарти життєвого циклу проектів інформатизації.

• Учасники й оточення проекту.

• Методичні засади структуризації проекту.

Питання 5.

Моделювання і стандарти життєвого циклу проектів інформатизації

Моделі життєвого циклу ІС: що вибрати?

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

Узагальнена модель життєвого циклу

Узагальнена модель життєвого циклу: 1. Розробка стратегії

звичайно виконує замовник спільно з майбутнім її користувачем.

У залежності від кваліфікації замовника і складності системи, стратегія може бути зафіксована в документах. У вітчизняній практиці це ТЗ.

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

Всі ці відомості відображаються в документах, що ініціюють розробку ІС.

Узагальнена модель життєвого циклу: 2. Створення і впровадження системи

Вона може бути побудована в залежності від прийнятої моделі ЖЦ проекту.

Головну роль протягом цієї фази відіграє організація-розробник.

Узагальнена модель життєвого циклу: 3. Супровід

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

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

Каскадна модель ЖЦ ІС

характеризується структурою впорядкованих стадій з яких складаються стадії створення і впровадження.

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

Склад і назва технологічних стадій у різних авторів різна. Відмінності зводяться до ступеню деталізації. Американський стандарт стадій створення автоматизованої системи військового призначення DOD-STD-2167A передбачає стадії, наведені на наступному слайді.

Каскадна модель життєвого циклу ІС

Каскадна модель ЖЦ ІС

Переваги каскадної моделі:

1) Детермінованість моделі;

2) Чітка регламентованість (що спрощує управління проектом, особливо контроль за виконанням).

Недоліки каскадної моделі:

1) Від затвердження ТЗ до впровадження готового продукту минає багато часу. Існує ризик, що вимоги користувачів зміняться і не будуть задоволені.

2) Можливі випадки, коли реальні потреби залишилися незмінними, але були неправильно або недостатньо використані користувачем під час розробки ТЗ.

Спіральна модель ЖЦ

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

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

На кожній ітерації створюють діючий прототип, піддають критичній оцінці. На заключній ітерації прототип приймають за остаточний варіант системи.

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

Спіральна модель життєвого циклу

Спіральна модель ЖЦ

Переваги - відсутність недоліків каскадної моделі, оскільки можна врахувати вимоги, що змінилися.

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

Інші моделі

Проміжними між каскадною і спіральною моделями є :

1) Метод швидкого прототипу;

2) Метод послідовного нарощування функцій;

3) Еволюційна модель;

4) Модель заснована на повторному використанні компонент;

5) Модель заснована на автоматизованому синтезі програм.

1. Метод швидкого прототипу

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

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

1. Метод швидкого прототипу

Основне призначення - полегшити виявлення вимог користувача.

Прототип після розробки ТЗ не використовується, а в іншому ця модель ЖЦ співпадає з каскадною.

Приклад такого підходу - Британський стандарт SSADM. Він реалізовує модель схожу на каскадну, однак передбачає багатократне коригування документів.

2. Метод послідовного нарощування функцій

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

Ця модель дозволяє зменшити час впровадження першої черги ІС. Користувач раніше починає відчувати перевагу від автоматизації.

Перевага - скорочення термінів окупності.

Недолік - складність планування й управління в поєднанні з необхідністю дотримання відкритої архітектури.

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

3. Еволюційна модель

передбачає доробку ІС до рівня якості, який задовольнить кінцевого користувача, безпосередньо в процесі дослідної експлуатації.

Розробку ІС починають з тих функцій, про які розробники мають чітке уявлення.

Знання відносно інших функцій системи уточнюють вже після її часткового впровадження в експлуатацію.

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

3. Еволюційна модель

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

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

4. Модель заснована на повторному використанні компонентів

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

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

4. Модель заснована на повторному використанні компонентів (продовження)

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

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

4. Модель заснована на повторному використанні компонентів (закінчення)

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

Нині, у зв'язку з поширенням об'єктно-орієнтованого підходу до розробки ІС, вона набуває все зростаючого значення.

5. Модель заснована на автоматизованому синтезі програм

Ця модель заснована на трансляції спеціально розроблених програм на мові високого рівня в машинні програми.

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

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

Разом із тим автоматизований синтез програм дозволяє різко скоротити всі види витрат на кожний подальший зразок ІС і реалізувати високу якість програмного продукту.

Вибір ЖЦ ІС

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

Вибір залежить від того, хто є замовником ІС. Якщо це - ринок або замовник - недержавна організація, то вибір диктується тільки логікою здорового глузду та використовуваною методологією розробки ІС (MSF, CDM Oracle тощо).

Якщо проект розробляється за державним замовленням, то необхідно дотримуватись ДСТУ, тобто треба застосовувати каскадну модель.

Обов'язкові етапи робіт під час проектування, впровадження та експлуатації засобів інформатизації (постанова Кабінету Міністрів України від 11 листопада 2009 р. N 1191)

• Визначення потреби у засобах інформатизації та вивчення питання щодо можливості їх модернізації для забезпечення виконання необхідних функцій.

• Розроблення техніко-економічного обґрунтування створення або модернізації засобів інформатизації.

• Обґрунтування необхідності використання особистих немайнових та (або) майнових прав інтелектуальної власності на засоби інформатизації.

• Розроблення технічного завдання на створення або модернізацію засобів інформатизації.

• Розроблення технічного та робочого або техноробочого проекту створення чи модернізації засобів інформатизації.

• Проведення навчання фахівців для забезпечення функціонування засобів інформатизації.

• Виконання пусконалагоджувальних робіт.

• Проведення випробувань створених або модернізованих засобів інформатизації.

• Введення засобів інформатизації в експлуатацію.

• Виконання робіт з обслуговування засобів інформатизації відповідно до гарантійних зобов'язань.

• Післягарантійне обслуговування засобів інформатизації.

Опис основних процесів життєвого циклу програмного продукту

А1 Процес замовлення

Виконавець – Замовник

Дії:

1.1. Ініціювання;

1.2. Підготовка запиту щодо пропозицій (тендеру);

13. Підготовка та коригування контракту;

1 4. Нагляд за постачанням;

1.5. Приймання та завершення

Опис основних процесів життєвого циклу ПП: ініціювання

Опис основних процесів життєвого циклу ПП: ініціювання

Опис основних процесів життєвого циклу ПП: ініціювання

Опис основних процесів життєвого циклу ПП: підготовка запиту щодо пропозицій (тендеру)

Опис основних процесів життєвого циклу ПП: підготовка запиту щодо пропозицій (тендеру)

Замовнику і розробнику доцільно врахувати:

Розробник отримує методику і нормативну базу для повного і зрозумілого замовнику опису всіх своїх робіт з тестування ПЗ і АС, організації паралельної роботи нової і старої систем, інших робіт, пов'язаних з "впровадженням".

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

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

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

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

Питання 6.

Учасники й оточення проекту.

Склад учасників проекту, їх роль, розподіл їх функцій і відповідальності залежать від типу, виду, масштабу і складності проекту, а також від фаз ЖЦ проекту.

Жорстких регламентів по складу учасників проекту не існує.

Незмінними можна вважати наступні функції по здійсненню проекту, а отже і такий склад основних учасників:

- проект повинен бути осмислений, “придуманий" і ініційований, значить у нього повинен бути ініціатор;

- проект повинен мати головну зацікавлену особу (організацію), тобто сторону, яка є майбутнім власником і користувачем результатами проекту і несе за нього відповідальність. У нашій термінології замовник = власник + користувач;

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

- проект треба готувати і здійснювати, значить у нього повинні бути виконавці;

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

- проектом треба управляти, отже у проект повинен мати менеджерів.

Принципова схема учасників проекту

Функції основних учасників проекту

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

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

Функції основних учасників проекту

Замовник: головна сторона, зацікавлена у здійсненні проекту і досягненні його результату.

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

Функції основних учасників проекту

Інвестор: сторона, що вкладає інвестиції в проект.

Мета інвестора - максимізація прибутку на свої інвестиції.

Якщо інвестор і замовник не одна особа, то звичайно як інвестори виступають банки, інвестиційні фонди.

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

Функції основних учасників проекту

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

Функції основних учасників проекту

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

Задача команди проекту: здійснення функцій управління проектом до ефективного досягнення цілей проекту.

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

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

Функції основних учасників проекту

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

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

Субконтрактор: вступає у договірні відносини з контрактором або субконтрактором більш високого рівня, несе відповідальність за виконання робіт і послуг відповідно до контракту.

Функції основних учасників проекту

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

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

Постачальники: субконтрактори, що здійснюють різні види постачання на контрактній основі.

Функції основних учасників проекту

Ліцензори: організації, що видають ліцензії на право володіння земельними ділянками, ведення торгів, виконання певних робіт і послуг, використання “ноу-хау".

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

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

Виробник кінцевої продукції: здійснює експлуатацію створених основних фондів і виробляє кінцеву продукцію. Бере участь у всіх фазах проекту. У багатьох випадках є замовником і інвестором. Головна мета – прибуток.

Функції основних учасників проекту

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

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

Функції основних учасників проекту

Для визначення повного складу учасників проекту, побудови його функціональної і організаційної структур на стадії розробки концепції проекту необхідно визначити:

- предметну область: цілі, задачі, роботи і основні результати, масштаби, терміни, складність;

- відносини власності, залученої до здійснення проекту (що скільки коштує і кому належить);

- основні ідеї реалізації проекту (як зробити);

- основні активні учасники проекту;

- основні пасивні учасники проекту (кого торкається проект);

- які мотивації учасників проекту (можливий прибуток, збитки, ризик і т.д.)

Оточення проекту

Щоб методично правильно організувати роботу з реалізації проекту необхідно враховувати таке:

1. - Проект виникає, існує та розвивається у певному оточенні, яке називається зовнішнім середовищем

2. - Ряд елементів проекту можуть бути використані як в його складі, так і поза ним (наприклад – спеціалісти працюють над кількома проектами).

3. - Проект не є жорстким утворенням. Його елементи можуть перейти із зовнішнього середовища до складу проекту і навпаки.

Проект та його оточення

Схема оточення проекту

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

Експертна оцінка ступеню впливу факторів оточення на різні типи проектів

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

• Проект і сутність проектної діяльності.

• Міжнародні та національні стандарти з управління проектами.

• Класифікація проектів.

• Життєвий цикл і фази проекту.

• Моделювання і стандарти життєвого циклу проектів інформатизації.

• Учасники й оточення проекту.

• Методичні засади структуризації проекту.

Питання 7: Структуризація проекту

1. Поняття структури проекту

2. Структурні моделі

3. Основні етапи структуризації проекту

1. Поняття структури проекту

Структура проекту (СП) - сукупність взаємопов'язаних елементів і процесів, представлених з різною мірою деталізації.

На основі СП будуються різні структурні моделі, що використовуються в управлінні проектами

Основним призначенням структури є визначення продукції, яку необхідно розробити або виробити.

Структура пов’язує елементи робіт, які доведеться виконати – як між собою, так і з кінцевою метою проекту.

1. Поняття структури проекту

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

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

1. Поняття структури проекту

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

1. Поняття структури проекту

Структуризація передбачає розбивку проекту на фази життєвого циклу проекту, етапи, роботи, завдання, одиничні робочі процеси; розробку так званої робочої структури проекту (Work Breakdown Structure — WBS), організаційної структури проекту (Organization Breakdown Structure — OBS), структури розподілу відповідальності й обов'язків виконавців при виконанні робіт із проекту на основі WBS і OBS у вигляді матриці, структури витрат проекту (Cost Breakdown Structure — CBS) та ін.

Основні задачі структуризації:

1) розбиття проекту на блоки, що піддаються управлінню;

2) розподіл відповідальності за різні елементи проекту й ув'язка робіт зі структурою організації та ресурсами;

3) точна оцінка необхідних витрат – коштів, часу, та матеріальних ресурсів;

4) створення єдиної бази для планування, складання кошторисів і контролю за витратами;

5) ув'язка робіт по проекту з системою ведення бухгалтерських рахунків у компанії;

6) перехід від загальних, не завжди конкретно сформульованих цілей, до конкретних задач, що виконуються підрозділами компанії;

7) визначення комплексів робіт (пакетів робіт, підрядів).

Основні вимоги до структуризації проекту:

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

2) кількість характеристик елементів проекту (обсяги робіт, вартість, ресурси. кількість виконавців) на кожному рівні ієрархії повинні співпадати.

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

Існують 2 основних методи структуризації:

1) "зверху-вниз" - низхідний підхід - визначаються загальні задачі, далі вони деталізуються

2) "знизу-вгору" - висхідний - визначає окремі задачі, які потім узагальнюються по рівнях

Для структуризації проекту використовується ряд спеціальних моделей:

• дерево цілей

• дерево рішень

• дерево робіт

• організаційна структура виконавців

• матриця відповідальності

• сіткова модель

• структура споживання ресурсів

• структура витрат

Дерево цілей - схема цілей, підцілей по рівнях

Основне правило розбиття – повнота.

Кожна ціль верхнього рівня повинна бути представлена повним набором підцілей.

Ціль (мета) проекту - доказовий результат і задані умови реалізації загальної задачі проекту

Розрізняють:

цілі -"результати" (доказовий результат) і

цілі - "спосіб дій" (умови реалізації).

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

Знаходження цілі проекту рівнозначно його визначенню і складає важливий етап в його розробці

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

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

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

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

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

Визначення цілей проекту - творчий процес, який включає:

1) ВИЗНАЧЕННЯ ПОКАЖЧИКІВ ЦІЛЕЙ

2) ВИЗНАЧЕННЯ МОЖЛИВИХ ЦІЛЕЙ ПРОЕКТУ

3) ОПИС ЦІЛЕЙ ПРОЕКТУ

Визначення цілей проекту - творчий процес:

1) ВИЗНАЧЕННЯ ПОКАЖЧИКІВ ЦІЛЕЙ можна розглядати як попереднє дослідження, після якого по знайдених покажчиках може бути розпочатий активний пошук цілі та її формулювання.

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

Визначення цілей проекту - творчий процес:

2) ВИЗНАЧЕННЯ МОЖЛИВИХ ЦІЛЕЙ ПРОЕКТУ - використовуються індивідуальні/групові методи. Строгих підходів до цього немає.

При індивідуальній роботі використовуються логічні методи (односторонній розгляд проекту), при груповій роботі - інтуїтивні (мозкового штурму, запису ідей etc)

Визначення цілей проекту - творчий процес:

3) ОПИС ЦІЛЕЙ ПРОЕКТУ - задокументована угода про цілі проекту.

Опис цілей визначає суть проекту і є основою для подальшої роботи над проектом

Якщо були ризикові міркування, то в опис проекту входить угода про результати, заява про наміри, терміни і бюджет, угода про розв'язання можливого конфлікту між результатами, термінами і витратами.

Визначення цілей проекту - творчий процес:

При описі цілі проекту повинні знайти відображення в чіткій однозначній формі:

- результат проекту - описується як бажаний стан системи і залежить від типу і виду проекту; доповнюється описом ефекту;

- терміни закінчення - описуються як часовий інтервал, в якому бажане завершення проекту; звичайно це заява про намір, але може бути і що зобов'язуючий часовий інтервал;

- витрати - в описі - це бюджетні рамки, іноді - чітка верхня межа;

- порядок зміни цілей - повинен бути визначений у зв'язку з можливістю зміни цілей;

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

Цілепокладання

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

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

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

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

Дерево робіт - структура декомпозиції робіт (СДР) (англ. - WBS - Work Breakdown Structure)

- це орієнтована на результати структуризація компонентів проекту, що дозволяє впорядкувати зміст проекту.

Елементи СДР (WBS) - це об'єднані блоки робіт проекту (наприклад, «Тестування»), які включають більш детальні блоки робіт і роботи.

Для створення WBS структуризація може провадитися по таких рівнях:

рівень 1 — проект;

рівень 2 — стадії або субпроекти;

рівень 3 — системи або блоки;

рівень 4 — робочі пакети.

Основні етапи розробки WBS:

• визначення ступеня деталізації проектних робіт (так, щоб вони піддавались оцінці);

• визначення кількості рівнів (як правило три — чотири, для сучасних компаній — чотири оптимально);

• розробка структури кожного рівня (формуються горизонтальні рівні);

• підготовка опису елементів WBS (стисла назва кожної складової WBS);

• формування системи кодування (кодуються всі блоки);

• проведення зворотних обчислень (витрати знизу вгору за принципом: відділ локалізації—субпідрядник).

Принципом декомпозиції проекту на блоки робіт СДР може слугувати:

Декомпозиція за підпроектами (підпроект 1 – підпроект 2 — підпроект 3);

Декомпозиція за фазами/етапами (концептуальна - проектування — будівництво — приймання), (постановка задачі, розробка, тестування й т.п.)

Декомпозиція за продуктами (Розробка звіту, Розробка модуля програми й т.п.)

Декомпозиція за регіонами (Роботи в Києві, роботи в Донецьку й т.п.)

Декомпозиція за місцем виконання робіт (фундамент — зовнішні роботи — внутрішні роботи);

Декомпозиція за центрами витрат (компанія 1 — компанія 2 — компанія 3).

Допускається використання в одному проекті різних способів декомпозиції за умови, що на одному рівні ієрархії не буде їх змішання.

При декомпозиції проекту на блоки необхідно стежити, щоб роботи в різних блоках не дублювалися.

Доцільно створити для окремих типів проектів стандартні формати їх WBS – шаблони.

Декомпозиція по продукту передбачає розробку двох ієрархічних схем:

• ієрархію виробів (результату) та

• ієрархію робіт, які між собою пов'язані.

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

WBS - Work Breakdown Structure

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

Пакет робіт може бути самостійною фінансовою одиницею і мати окремий кошторис та звіт про витрати.

СДР (WBS ) - основа для розробки структурної схеми адміністративного управління проектом.

ОСНОВНІ ПРАВИЛА ПОБУДОВИ WBS

1. Кожний елемент WBS повинен забезпечувати досягнення відчутного результату.

2. Кожний елемент WBS одного рівня повинен бути результатом всіх підпорядкованих елементів, перерахованих безпосередньо під ним.

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

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

5. Результати пакетів робіт повинні бути унікальними й відрізнятися від результатів інших пакетів робіт того ж рівня.

ОСНОВНІ ПРАВИЛА ПОБУДОВИ WBS (закінчення)

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

7. Процес розробки WBS повинен забезпечувати коригування WBS у випадку зміни обсягу робіт по проекту.

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

9. Усі пакети робіт повинні бути сумісні з організаційною структурою й структурою витрат.

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

Дерево робіт

Структура продукції

Структура робіт

Структура робіт проекту (WBS) повинна бути інтегрована з організаційною структурою проекту (OBS- Organization Breakdown Structure)

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

Організаційна структура виконавців (OBS – Organization Breakdown Structure)

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

Ці рівні іноді відповідають рівням WBS. Мета OBS - визначити виконавців, відповідальних за виконання робіт.

матриця відповідальності - зв'язує пакети робіт з організаціями-виконавцями. Складається на основі WBS і OBS

Сітьова модель - на основі WBS і OBS, дерева цілей і робіт складають сітковий графік вузлових подій

Інші моделі

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

• структура витрат - ієрархічний граф, який фіксує вартість елементів проекту на кожному рівні.

Схема взаємодії структурних моделей проекту

Структура проекту має поєднувати розподіл проекту на

• компоненти продукції (результату) проекту;

• етапи життєвого циклу;

• елементи організаційної структури.

Отже, мистецтво розбиття проекту (структуризації) полягає в умілому поєднанні трьох різних структур:

процесу; продукту; організації

в єдину структуру проекту.

Послідовність дій по структуризації проекту

1. Визначення цілей проекту . Повністю та чітко визначити:

• характер проекту;

• цілі та зміст проекту;

• кінцеві продукти та їх характеристика.

2. Рівень деталізації. Обдумати (задати) різні рівні деталізації планів та кількість рівнів та елементів в структурі розбиття проекту.

3. Структура процесу. Підготовити схему життєвого циклу проекту.

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

5. Структура продукту. Це схема розбиття на підсистеми або ієрархія робіт.

Послідовність дій по структуризації проекту (продовження)

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

7. Структура розбиття проекту. Пункти 3-6 об’єднуються в єдину структуру проекту.

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

Послідовність дій по структуризації проекту (продовження)

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

Таким чином, матриця “призначає” кожному пакету робіт конкретних виконавців.

10. Робочий план бухгалтерських рахунків. У разі необхідності потрібно опрацювати систему субрахунків, які “стикуються” з планом рахунків. (управлінський облік).

Послідовність дій по структуризації проекту (продовження)

11. Робочий сітковий графік. Реалізація перших 10 кроків дозволяє розробити деталізований графік, який включає по кожній з робіт часові та ресурсні оцінки.

12. Система наряд-завдань.

Випливає з попередньої структури (п.7) та матриці (п.9). На цьому етапі завдання мають бути абсолютно конкретними у часі і по ресурсах.

13. Система звітності та контролю. Розроблюються форми звітів та повідомлень, продумується спосіб їх надання тощо.

Тема: Класифікація проектів інформатизації

1.Особливості та ознаки проектів інформатизації

2. Узагальнена класифікація проектів інформатизації

3. Державні (національні) проекти інформатизації

4. Проекти інформатизації рівня підприємства

Основні особливості проектів інформатизації

• інтелектуалоємкий характер предметної області більшості проектів;

• першорядна важливість проблеми людських ресурсів у всіх її аспектах;

• мала частка господарської діяльності, пов'язаної з матеріальними активами;

• високий ступінь залежності від зовнішніх умов, насамперед, поведінки замовника;

• підвищені ризики, включаючи ризики порушення термінів і бюджету, припинення або призупинення проекту, невдалого впровадження результатів;

• підвищені вимоги до якості, що мають об'єктивно-конструктивний характер, тобто такий, що можна перевірити;

Основні особливості проектів інформатизації (закінчення)

• високий ступінь індивідуалізації "під клієнта" і важливість організації "тісної" роботи з ним;

• висока ймовірність появи нових, раніше не виконуваних робіт, для яких технологія й система управління створюються "на ходу";

• критична важливість офісної системи, що підтримує комунікації й базу знань;

• наявність суттєвих особливостей планування, контролю й обліку;

• нерівномірність надходження замовлень, що утрудняє управління ресурсами;

• досить часто географічна віддаленість клієнта;

• наявність кількох виконавців та їхня географічна розподіленість.

Виділення проектів інформатизації в окремий тип відповідає сучасним тенденціям у проектному менеджменті

Українська асоціація управління проектами так класифікує проекти за типом:

інвестиційний,

дослідний,

організаційний,

інформаційних технологій

і зазначає, що проекти можуть класифікуватись і за іншими критеріями (внутрішніми й зовнішніми).

ІТ-проект (проект інформатизації ) - це сукупність процесів і комплексу дій, пов’язаних зі створенням, удосконаленням чи впровадженням інформаційної системи або її складової частини — програмного забезпечення.

В Україні визначення належності програм і проектів, виконуваних за державним замовленням, до сфери інформатизації здійснюється відповідно до нині чинної методики, затвердженої Державним комітетом зв’язку та інформатизації України Міністерства транспорту та зв'язку (Наказ Міністерства транспорту та зв'язку N 24 ( z0072-07 ) від 16.01.2007 )

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

Методика так визначає проект (роботу) з інформатизації:

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

Бюджетна програма органу державної влади належить до сфери інформатизації,

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

До проектів (робіт) з інформатизації належать:

1. Створення інформаційних, інформаційно-пошукових, інформаційно-довідкових, інформаційно-аналітичних, геоінформаційних, автоматизованих ІС;

2. Створення інформаційно-аналітичних центрів та програмно-технічних (програмно-апаратних) комплексів;

3. Створення і розвиток телекомунікаційних систем, у тому числі корпоративних і локальних обчислювальних мереж, а також засобів інформатизації, призначених для функціонування телекомунікаційних систем;

До проектів (робіт) з інформатизації належать (продовження):

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

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

6. Створення програмно-технічних засобів для забезпечення захисту інформації;

До проектів (робіт) з інформатизації належать (продовження):

7. Здійснення моніторингу, якщо в результаті формуються відповідні інформаційні ресурси;

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

9. Створення, розвиток, упровадження стандартів у сфері інформаційних технологій, у тому числі адаптація до міжнародних стандартів;

До проектів (робіт) з інформатизації належать (закінчення):

10. Здійснення сертифікації програмного та технічного забезпечення робіт з інформатизації;

11. Розробка концепцій, розробка та реалізація галузевих та регіональних програм інформатизації, програм інформатизації органів місцевого самоврядування, нормативно-правових актів, спрямованих на розвиток сфери інформатизації;

12. Упровадження операційних систем з відкритим кодом в органах державної влади.

Здійснюючи класифікацію, слід пам’ятати, що проекти інформатизації:

• можуть відноситись до різних професійних сфер діяльності (фінансова, юридична, маркетингова та ін.);

• мають різну складність задач, що розв’язуються;

• мають різний масштаб з точки зору ресурсів, що залучаються.

Класифікація проектів інформатизації

Класифікація проектів інформатизації

Класифікація проектів інформатизації

Класифікація проектів інформатизації

Класифікація проектів інформатизації

Державні проекти інформатизації фінансуються з державного бюджету і є досить витратним

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

Нормативно-правову основу розробки державних проектів інформатизації складають:

• закони України "Про Національну програму інформатизації”, "Про Концепцію Національної програми інформатизації“ та ін.,

• постанови Верховної Ради та Кабінету Мiнiстрiв України,

• укази Президента України, направлені на виконання цих законів та вирішення конкретних питань інформатизації.

Функції органів державної влади у процесі інформатизації (Закон України "Про Національну програму інформатизації”, ст. 6):

• захист авторського права на бази даних і програми, створені для потреб інформатизації та особистої інформації;

• встановлення стандартів, норм і правил використання засобів інформатизації;

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

• визначення пріоритетних напрямів інформатизації з метою подальшої підтримки її шляхом державного фінансування та пільгового оподаткування;

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

Функції органів державної влади у процесі інформатизації (закінчення):

• підтримка вітчизняного виробництва програмних і технічних засобів інформатизації;

• підтримка фундаментальних наукових досліджень для розроблення швидкісних математичних і технічних засобів обробки інформації;

• забезпечення підготовки спеціалістів з питань інформатизації та інформаційних технологій;

• організація сертифікації програмних і технічних засобів інформатизації;

• державне регулювання цін і тарифів на використання телекомунікаційних та комп'ютерних мереж для потреб інформатизації у бюджетній сфері;

• забезпечення інформаційної безпеки держави.

Національна програма інформатизації

• формується за пріоритетними напрямками, що відповідають загальній стратегії соціального і економічного розвитку України,

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

• є відкритою для періодичного коригування цілей, етапів, складу конкретних завдань і проектів на основі аналізу світових тенденцій розвитку сфери інформатизації, оцінки отриманих результатів розвитку інформаційної інфраструктури і прогнозів соціально-економічного розвитку України.

Завдання Національної програми інформатизації на наступні три роки та обсяги їх бюджетного фінансування на наступний рік щорічно затверджуються Верховною Радою України.

Замовники Національної програми інформатизації

Генеральний державний замовник - центральний орган виконавчої влади, визначений Кабінетом Міністрів України – нині ці функції виконує Державне агентство з питань науки, інновацій та інформатизації України

та державні замовники окремих завдань (проектів) інформатизації Національної програми - органи виконавчої влади та органи місцевого самоврядування, до сфери діяльності яких належать ці завдання.

Державних замовників з окремих завдань (проектів) інформатизації затверджує Кабінет Міністрів України за поданням Генерального державного замовника.

Замовники Національної програми інформатизації

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

Конкурс виконавців проводиться у відповідності з Положенням про конкурс виконавців Національної програми інформатизації

Окреме завдання:

комплекс проектів інформатизації, взаємопов'язаних і взаємопогоджених за термінами реалізації, складом виконавців та спрямованих на досягнення конкретних цілей.

Порядок формування та виконання окремих завдань і проектів Національної програми інформатизації

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

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

Фінансування проектів інформатизації органів державної влади

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

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

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

Виконавці проектів (робіт)

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

Нерезиденти - юридичні особи, суб'єкти підприємницької діяльності, що не мають статусу юридичної особи (філії, представництва тощо), з місцезнаходженням за межами України, які створені й діють відповідно до законодавства іноземної держави, у тому числі юридичні особи та інші суб'єкти підприємницької діяльності, створені за участю юридичних і фізичних осіб;

Відбір виконавців окремих завдань (проектів) Національної програми інформатизації проводиться на конкурсних засадах.

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

Порядок погодження проектів з Генеральним державним замовником Національної програми інформатизації

якщо видатки, пов'язані з виконанням проектів (робіт), що належать до сфери інформатизації, перевищують суму, еквівалентну 20 тис. євро для товарів, 40 тис. євро - для робіт і послуг, то органи державної влади погоджують зазначені проекти (роботи) з Генеральним державним замовником Національної програми інформатизації

Порядок віднесення проектів до сфери інформатизації

Органи державної влади на підставі Тематичних планів науково-дослідних та дослідно-конструкторських робіт або Планів закупівель товарів, робіт і послуг, які фінансуються з Державного бюджету України, самостійно або із залученням експертів роблять висновки щодо належності проектів (робіт) до сфери інформатизації, керуючись зазначеною раніше Методикою Державного комітету зв’язку та інформатизації України

Відбір проектів та виконавців проектів

здійснюється, як правило, на конкурсних засадах.

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

Умови конкурсу оголошуються в друкованих засобах масової інформації державним замовником.

Експертиза окремих завдань (проектів) Національної програми інформатизації

проводиться згідно із:

• законодавством України та

• Положенням про експертизу у галузі інформатизації, затвердженим наказом Національного агентства з питань інформатизації від 26 січня 1996 року N19

Основні завдання Експертно-консультаційної ради з питань інформатизації при Кабінеті Міністрів України (постійно діючого дорадчо-консультативного органу)

• забезпечення експертно-аналітичної та консультаційної підтримки процесу прийняття рішень Кабінетом Міністрів України щодо реалізації державної політики у сфері інформатизації;

• розгляд питань інформатизації, визначених Законом України "Про Національну програму інформатизації";

• розроблення пропозицій щодо визначення комплексу заходів, спрямованих на захист державних інтересів в галузі ІТ;

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

Основні завдання Експертно-консультаційної ради з питань інформатизації при Кабінеті Міністрів України (продовження)

• забезпечення ефективної взаємодії між органами виконавчої влади та суб'єктами господарювання в галузі інформаційних технологій;

• розроблення пропозицій щодо удосконалення нормативно-правової бази у галузі інформатизації та проведення експертизи проектів нормативних актів;

• інформування Кабінету Міністрів України про тенденції розвитку інформаційних технологій, результати проведення інформаційно-аналітичної роботи, спрямованої на розвиток галузі.

До складу Експертно-консультаційної ради з питань інформатизації при Кабінеті Міністрів України входять

фахівці у галузі ІТ, провідні представники органів державної влади, підприємств, установ, організацій, учені.

Персональний склад Ради затверджується Кабінетом Міністрів України.

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

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

Засідання Ради проводяться згідно з планами її діяльності або в міру необхідності за рішенням голови Ради чи його заступників.

Фінансування

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

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

Обсяги фінансування Національної програми інформатизації з Державного бюджету України

визначаються Законом України про Державний бюджет України на наступний бюджетний рік і встановлюються окремим рядком.

Галузеві та регіональні програми і проекти інформатизації фінансуються

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

Фінансування

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

Особливості виконання проектів інформатизації у сфері національної безпеки та оборони держави

Відбір виконавців окремих завдань (проектів) Національної програми інформатизації у сфері національної безпеки та оборони держави регламентується “Положенням про порядок передачі резидентам окремих завдань (проектів) Національної програми інформатизації у сфері національної безпеки та оборони держави” (затверджено постановою Кабінету Міністрів України від 26 липня 1999 р. N 1354)

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

Вживані у цьому Положенні терміни

"Генеральний державний замовник", "державний замовник", "резидент", "окреме завдання", "проект інформатизації" вживаються у значеннях, наведених у Законі України "Про Національну програму інформатизації" (74/98-ВР), розглянутих нами раніше.

Вживані у цьому Положенні терміни

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

Виконавець окремого завдання (проекту) повинен відповідати таким вимогам:

• не мати у своєму статутному фонді іноземних інвестицій та іноземних громадян серед своїх засновників;

• мати досвідчений і кваліфікований персонал для виконання завдання (проекту);

• володіти необхідними матеріально-технічними ресурсами;

• мати належну ділову репутацію

Фінансування

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

У разі недостатності фінансування у поточному році строки виконання окремих завдань (проектів) Національної програми інформатизації переглядаються у порядку, визначеному Положенням про формування та виконання Національної програми інформатизації

Контроль

Контроль за формуванням та виконанням Національної програми інформатизації здійснює Кабінет Міністрів України.

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

При Верховній Раді України з 1998 року функціонує на громадських засадах Консультативна рада з питань інформатизації яка є дорадчо-консультативним органом.

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

До складу Консультативної ради входять

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

Склад Консультативної ради включає не менше 15 осіб.

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

Комітет Верховної Ради України з питань інформатизації та інформаційних технологій був створений 25 грудня 2012 на підставі постанови Верховної Ради України № 11-VII і став першим законодавчим органом державної влади у сфері інформатизації та інформаційних технологій.

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

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

Ці проекти також не є однорідними і їх класифікація є корисною з точки зору формування ефективного механізму їх здійснення.

За ознакою впливу на сервіси (послуги) інформаційних технологій (ІТ) проекти інформатизації рівня підприємства можна розділити на дві групи

• Бізнес-проекти. До них відносять проекти метою яких є створення нових ІТ-сервісів для бізнес-підрозділів.

• Інфраструктурні проекти. Це проекти, які не впливають на склад ІТ-сервісів для бізнес-підрозділів.

Проекти кожної з цих груп також можна класифікувати за різними ознаками.

Класифікація проектів інформатизації рівня підприємства

Проекти розвитку систем АСУ ТП і контрольно-вимірювального обладнання

АСУ ТП - системи, що забезпечують збір даних з технологічних установок і управління останніми.

Вони є частиною технологічного ланцюжка основних бізнес-процесів

Проекти розвитку АСУ ТП і контрольно-вимірювального обладнання призначені:

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

Вони дуже різноманітні, що обумовлено великою кількістю різноманітних об’єктів впровадження таких систем.

Проекти розвитку АСУ ТП

Ця група проектів має високу частку зв'язаних проектів.

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

Наприклад, сучасне підприємство або цех, що вводиться в експлуатацію, неодмінно містить значні за вартістю об'єкти АСУ ТП.

Механізм прийняття рішень по проектах розвитку АСУ ТП

Проект ініціюється виробничим підрозділом, яке відповідає за експлуатацію обладнання, керованого АСУ ТП.

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

Там оцінюють достатність існуючої ІТ-інфраструктури і розглядають проект з точки зору забезпечення необхідної продуктивності й технічної надійності.

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

Механізм прийняття рішень по проектах розвитку АСУ ТП (продовження)

Запропоноване рішення розглядається з точки зору оптимізації витрат з урахуванням усього портфеля проектів і діючих ІТ-сервісів.

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

Ухвалене рішення передається на виконання виробничому підрозділу (у частині, що стосується власне АСУ ТП) й інформаційній службі (у частині ІТ-інфраструктури).

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

Схема прийняття рішення щодо проекту розвитку АСУ ТП

Проекти розвитку предметної області

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

Прикладом таких систем є системи:

• автоматизованого проектування, що базуються на моделях інженерних розрахунків;

• моделювання родовищ у добувній промисловості, що базуються на математичних моделях геології;

• технічного аналізу і прогнозування біржових котирувань цінних паперів;

• комп’ютерної графіки;

• біржової торгівлі та ін.

Проекти розвитку предметної області

дуже різноманітні та мають цілу низку властивостей, що відрізняють їх від проектів інших видів:

• жорсткі вимоги до апаратних і програмних засобів, які повинні бути виконані за принципом "усе або нічого";

• жорсткі вимоги до інфраструктури інформаційної служби - локальної мережі, засобів зв'язку, систем резервного копіювання й інших засобів підвищення надійності зберігання даних;

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

Проекти розвитку предметної області (продовження)

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

Такі системи мають жорстоко задані входи і виходи і більше, ніж АСУ ТП нагадують “чорний ящик”.

Проекти розвитку предметної області (закінчення)

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

За недостатньої пропускної спроможності або недостатньої технічної надійності існуючої ІТ-інфраструктури формується специфікація на закупівлю необхідного обладнання й ПЗ

Схема прийняття рішення щодо систем предметної області

Проекти розвитку фінансово-економічних систем

• найпоширеніший,

• найчисельніший,

• найскладніший

вид проектів інформатизації підприємства.

Проекти розвитку фінансово-економічних систем автоматизують, як правило, забезпечуючі (допоміжні) бізнес-процеси.

Виключенням є системи MRP II / ERP, які автоматизують крім того і планування операцій основних бізнес-процесів.

Прикладом фінансово-економічних систем є:

• системи MRP II / ERP;

• системи бюджетування і контролю виконання бюджету;

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

• системи розрахунків з постачальниками/покупцями і контролю заборгованості;

• сектор банківських систем, орієнтованих перш за усе на інтеграцію бухгалтерського і фінансового обліку, включаючи облік кредитних, депозитних операцій, операцій на ринку цінних паперів;

• проекти електронного бізнесу тощо.

Проекти розвитку фінансово-економічних систем

Основні риси:

По-перше, автоматизують виключно управлінську працю.

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

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

Проекти розвитку фінансово-економічних систем (продовження)

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

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

Проекти розвитку фінансово-економічних систем

Одна з основних проблем - розробка чи закупівля на стороні.

Розробка може здійснюватися як власними силами підприємства, так і стороннім виробником на замовлення.

Проекти розвитку фінансово-економічних систем

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

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

Основна умова успіху - завдання бізнесу, розв'язуване проектом, повинне знаходитися в компетенції особи, що є замовником проекту.

Прийняття рішення з розробки фінансово-економічної системи

Інформаційна служба розглядає запит бізнес-підрозділу на рівні служби планування сервісу.

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

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

Потім оцінюються вимоги сервісу до ІТ з точки зору технічної надійності.

Сформована у такий спосіб специфікація рішення надходить на розгляд Комітету з управління змінами (або іншого уповноваженого органу).

Прийняття рішення з розробки фінансово-економічної системи (продовження)

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

За відсутності на підприємстві системи функціонально-вартісного аналізу/управління (ФВА/ФВУ), метою проекту може також стати побудова моделі ФВА розглянутого бізнес-процесу (групи бізнес-процесів).

Прийняття рішення з розробки фінансово-економічної системи (продовження)

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

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

Після схвалення Комітетом починається виконання проекту розробки або впровадження.

Прийняття рішення з розробки фінансово-економічної системи

Інфраструктурні проекти

- проекти підтримки. Проекти розвитку ІТ-інфраструктури з метою підтримки кількох бізнес-проектів;

- проекти розширення. Проекти розвитку ІТ-інфраструктури з метою впровадження на нових об’єктах підприємства існуючих бізнес-сервісів (ІТ-сервісів для бізнес-підрозділів);

- проекти розв’язання проблем. Проекти, що адаптують ІТ-інфраструктуру підприємства до обставин, які не передбачені регулярним плануванням і викликані необхідністю розвитку ІТ- інфраструктури;

- проекти розвитку інформаційної служби. Проекти розвитку ІТ- інфраструктури, націлені на підвищення ефективності діяльності самої інформаційної служби з розробки сервісів, їх супроводу та управління ними.

Проекти підтримки бізнес-проектів

Проект ініціюється в блоці процесів планування й управління сервісами.

Підстава для підготовки проекту - невідповідність існуючих ресурсів ІТ-інфраструктури потребам планованих бізнес-проектів.

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

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

Схема прийняття рішення з розробки проектів підтримки

Проекти підтримки бізнес-проектів

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

Істотні зміни по ходу проекту також розглядаються по описаній вище схемі.

Єдина відмінність полягає в тому, що в останньому випадку рішення приймається не тільки із приводу власне інфраструктурного проекту, але й із приводу бізнес-проектів, які він підтримує.

Інфраструктурні проекти підтримки

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

Результат проектів даної групи - створення нових ресурсів ІТ, безпосередньо використовуваних новостворюваними бізнес-сервісами.

Проекти розширення

Проекти цієї групи націлені на поширення існуючих бізнес-сервісів на нові об'єкти.

Необхідність у подібних проектах виникає за умови придбання підприємства або створення нового.

У першому випадку проблеми інфраструктури ІТ вирішуються, як правило, окремим інфраструктурним проектом.

При створенні ж нового виробничого об'єкта або офісу проблеми інфраструктури ІТ звичайно повністю або частково розв'язуються в рамках зв'язаного проекту.

Приклади проектів розширення:

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

• проекти впровадження бізнес-додатків, наприклад електронної пошти, ERP-Систем, систем звітності.

Приклади проектів розширення (продовження)

У всіх перерахованих проектів є загальна риса: обґрунтування потреби бізнесу в сервісі ІТ не потрібне й не проводиться.

Однак забезпечення даного сервісу на придбаному підприємстві вимагає окремого проекту розвитку ІТ.

Результатом проекту є створення ресурсів ІТ, що забезпечують функціонування існуючих бізнес-сервісів на новому підприємстві.

Схема прийняття рішень по проекту розширення

Проекти розв’язання проблем

Хоча модель ITIL/ITSM дозволяє обмежити внутрішні ризики ІТ-інфраструктури підприємства, а також організувати планування й управління цими ризиками, зберігаються ризики зовнішнього середовища, які найчастіше неможливо контролювати.

Ризики зовнішнього середовища:

• технічні проблеми, не передбачені в рамках регулярних процедур планування й управління ІТ;

• зміна технічної політики виробників обладнання й ПЗ, наприклад, коливання компанії Hewlett-Packard відносно своєї лінії UNIX-Серверів;

• зміна ліцензійної політики виробників ПЗ, наприклад введення фірмою Microsoft практики обмеженого терміну дії ліцензії на операційну систему Windows XP, а також інші можливі проблеми.

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

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

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

• Зміна технічної політики виробників устаткування й ПЗ означає звичайно часткове або повне припинення підтримки певних ІТ-Рішень із боку їхніх виробників.

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

Проекти розв’язання проблем

Подібний проект передбачає термінову зміну інфраструктури ІТ підприємства, пов'язану з обставинами, не врахованими в плануванні.

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

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

Терміновість зміни має на увазі усунення проблеми на певний термін (дату).

Загальні принципи таких “надзвичайних” проектів:

• метою проекту є відновлення сервісу, а не забезпечення працездатності обладнання й ПЗ. Іншими словами, за необхідності те й інше варто замінити;

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

• необхідно оцінити повні витрати по моделі ФВА для основного й запасного варіантів розв'язання;

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

Розробка схеми проекту розв'язання проблеми має на увазі кілька обов'язкових етапів:

• Діагностика проблеми - визначення переліку обладнання й ПЗ, порушених проблемою, потім внутрішніх сервісів, заснованих на даному обладнанні й ПЗ, і, нарешті, зовнішніх сервісів.

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

Розробка схеми проекту розв'язання проблеми має на увазі кілька обов'язкових етапів (продовження):

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

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

Розробка схеми проекту розв'язання проблеми має на увазі кілька обов'язкових етапів (продовження):

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

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

Розробка схеми проекту розв'язання проблеми має на увазі кілька обов'язкових етапів:

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

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

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

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

Слід зазначити, що в рамках однієї проблеми не обов'язково присутні всі складові втрат. Проблеми, пов'язані з політикою виробників, як правило, не створюють ризиків відмови сервісу.

Аналогічно непередбачені технічні проблеми створюють ризики відмови сервісу, але не ведуть до подорожчання існуючих ІТ-Рішень.

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

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

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

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

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

Якщо проект розвитку ІТ спирається на змінювані рішення, необхідні відповідні зміни в такому проекті.

Схема прийняття рішення по проектах розв'язання проблем

Проекти підвищення ефективності діяльності інформаційної служби

• стандартизація обладнання й ПЗ, а також подальше вдосконалювання уведених стандартів;

• перехід на обладнання й ПЗ промислового рівня, укрупнення ІТ-Рішень;

• впровадження сучасних засобів управління корпоративною мережею;

• навчання персоналу ІС і кінцевих користувачів;

• впровадження сучасних моделей управління ІС у сполученні з відповідними засобами автоматизації;

• передача в аутсорсинг непрофільних видів діяльності.

Прийняття рішень по проекту розвитку ІнфСл провадиться за особливою схемою

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

Проект обґрунтовується в рамках процесу розробки стратегії ІТ (у вигляді певного набору значень показників ефективності діяльності ІнфСл).

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

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

Прийняття рішень по проектах розвитку ІнфСлужби

Статут проекту

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

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

Менеджер проекту визначається або призначається відразу, як тільки це стає можливим, переважно під час розробки Статуту проекту й обов'язково до початку планування.

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

Розробка Статуту проекту: входи, інструменти, методи й виходи

Вхідні дані: Розробка Статуту проекту

1. Опис робіт (Statement of work, SOW) - це словесний опис продуктів або послуг, які повинен зробити проект.

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

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

Вхідні дані Розробка Статуту проекту: (продовження)

Перелік робіт відображає:

• Бізнес-Потребу. Бізнес-потреба організації може бути заснована на ринковому попиті, технологічному прогресі, правових вимогах або постановах уряду.

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

• Стратегічний план. Усі проекти повинні підтримувати стратегічні цілі організації. Стратегічний план виконуючої організації повинен розглядатися як один із факторів при прийнятті рішень про вибір проекту й розстановці пріоритетів.

Вхідні дані Розробка Статуту проекту: (продовження)

2.Економічне обґрунтування або подібний документ надає необхідну з погляду бізнесу інформацію, що дозволяє визначити, чи вартий проект необхідних інвестицій.

Звичайно в економічному обґрунтуванні містяться бізнес-потреби й порівняльний аналіз витрат і результатів для виправдання проекту.

Економічне обґрунтування може написати організація, що подає заявку, або замовник, у випадку зовнішніх проектів.

Вхідні дані Розробка Статуту проекту:(продовження)

Економічне обґрунтування створюється як результат дії одного або кількох факторів:

- вимоги ринку (наприклад, ІТ-компанія санкціонує проект з розробки нової версії програмного продукту у відповідь на зміну законодавства з оподаткування);

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

- вимоги замовника (наприклад, телекомунікаційна компанія санкціонує проект по створенню нового контакт-центру для нового району);

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

- правові вимоги (наприклад, Національний банк санкціонує проект для розробки рекомендацій щодо інформаційної безпеки комерційних банків);

- екологічні впливи (наприклад, компанія розпочинає проект для зменшення свого впливу на навколишнє середовище); або

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

Вхідні дані Розробка Статуту проекту:(продовження)

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

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

Вхідні дані Розробка Статуту проекту: (закінчення)

3 Контракт є входом, якщо проект виконується для зовнішнього замовника.

4 Фактори середовища підприємства, які можуть впливати на процес розробки Статуту проекту, містять у собі серед іншого:

• державні й промислові стандарти;

• інфраструктуру організації;

• ситуацію на ринку.

5 Активи процесів організації, які можуть впливати на процес розробки Статуту проекту, містять у собі серед іншого:

• стандартні процеси організації, правила й описи типових процесів для використання в організації;

• шаблони (наприклад, шаблон Статуту проекту);

• історичну інформацію й базу засвоєних уроків.

Інструменти й методи Розробка Статуту проекту:

1 Експертні оцінки - часто використовуються для оцінювання входів, застосовуваних для розробки Статуту проекту.

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

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

• інші підрозділи в рамках організації;

• консультанти;

• зацікавлені сторони проекту, у тому числі замовники або спонсори;

• професійні й технічні асоціації;

• галузеві об'єднання;

• експерти по окремих питаннях;

• офіс управління проектами (Project management office, PMO).

Виходи Розробка Статуту проекту:

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

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

Склад Статуту за PMBOK 4:

• Мета проекту

• Вимірювані критерії успішності проекту

• Короткий виклад загальних вимог

• Короткий виклад опису суті проекту

• Короткий виклад характеристик продукту проекту

• Ключові віхи по строках проекту

• Орієнтовний бюджет

• Вимоги до системи затвердження результатів проекту й хто вирішує, що проект успішно завершений

• Менеджер проекту, його повноваження й відповідальність

• Поіменний перелік осіб із зазначенням їхньої відповідальності за проект 

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

Шаблон статуту проекту:

Елементи статуту проекту:

• Офіційна назва, призначення та сфера застосування проекту

• Контактна інформація спонсора проекту

• Контактна інформація менеджера проекту

• Цілі проекту з показниками їх досягнення

• Бізнес-умови проекту (причини для початку роботи над проектом) (Обмеження проекту)

• Оцінка ризиків проекту

• Узагальнені результати проекту й елементи, що поставляються ним

• Загальний опис методів роботи членів проекту

• Базовий граничний строк завершення робіт (більш точна дата наводиться в плані проекту)

• Ресурси проекту, його бюджет, співробітники і розробники

Шаблон статуту проекту:

<НАЗВА ПРОЕКТУ>

Версія документа #:

Дата створення документа:

Спонсор проекту:

Менеджер проекту:

Інші учасники проекту:

Шаблон статуту проекту: Призначення проекту

Короткий опис проекту.

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

Також повинна бути наведена деяка історична інформація про те, як і чому проект був ініційований.

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

Шаблон статуту проекту: Рамки проекту

У статуті визначаються рамки проекту й рамки продукту (послуги/товару).

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

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

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

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

Фокус Статуту повинен концентруватися на процесах проекту.

Шаблон статуту проекту: Цілі проекту

Визначаються загальні цілі проекту.

Тобто визначається те, чого проект повинен досягти в бізнес- і технічних термінах.

Шаблон статуту проекту: Узгодження

Цей розділ визначає імена й ролі зацікавлених сторін проекту та їхню згоду зі Статутом.

У цей розділ часто включаються підписи.

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

Шаблон статуту проекту: Посилання

Визначаються інші документи, включаючи, наприклад, "Інвестиційне рішення", " Бізнес-Кейс", і "Логічний структурний аналіз", (в електронній і паперовій формі), які пов'язані із проектом під час розробки Статуту.

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

Також повинна бути надана достатня інформація, щоб пояснити, як документ пов'язаний із проектом , який саме його фрагмент відноситься до проекту і як він може бути знайдений.

Шаблон статуту проекту: Термінологія

Визначаються всі унікальні й ключові терміни й/або акроніми, часто використовувані в проекті.

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

Шаблон статуту проекту: Виходи проекту й умови якості

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

Визначаються ключові контрольні точки.

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

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

Ступінь підтримки, що повинна бути надана продукту, повинна бути також представлена як якісна ціль.

Шаблон статуту проекту: Організація й відповідальність

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

Примітка: Із РМВОК 4 виключено всі функціональні й організаційні вимоги зі Статуту Проекту.

Шаблон статуту проекту: Організація й відповідальність (продовження)

Можлива структура організації:

• Виконавчий комітет

• Лідер проекту

• Менеджер проекту ( IT-Менеджер проекту й/або менеджер проекту в бізнес-сфері)

• Лідери проекту в IT-Галузі (Лідери команд розробки або лідери проектних команд в IT-Галузі, які допомагають менеджерові проекту в адмініструванні й/або управлінні специфічними аспектами проекту)

• Члени проектних команд (включаючи членів IT-Команд і бізнес-клієнтів)

• Координатор випробувань

• Контролер якості

• Контролер конфігурації

• Контролер змін

Організація й відповідальність (продовження)

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

У великих проектах лідери проектних IT-команд можуть призначатися помічниками менеджера проекту в діях по координації всіх операцій проекту й управлінню специфічними виходами за планом робіт.

Організація й відповідальність (закінчення)

У більшості проектів краще розділяти ролі менеджера проекту й лідера команди. Суміщення веде до відхилення від виконання основних функцій по управлінню проектом.

Ці ролі звичайно описуються в "Керівництві менеджера IT-Проекту", "Основні ролі й обов'язки".

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

Шаблон статуту проекту: Залежності

Всі залежності за межами прямого контролю керуючих проектом або зовнішні рамки проекту (які можуть вплинути на успіх проекту) повинні бути визначені.

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

Внутрішні залежності також повинні бути розглянуті.

Залежності проекту й/або виходів проекту від інших проектів/продуктів (існуючі або, що перебувають у розвитку) повинні бути зрозумілі.

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

Повинні бути також визначені необхідні зв'язки з іншими існуючими або планованими системами

Шаблон статуту проекту: Плани підтримки дій

Тут описуються плани підтримки операцій.

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

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

Шаблон статуту проекту: Забезпечення й ресурси проекту

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

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

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

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

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

Запобіжні заходи й плановані реакції також повинні бути описані.

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

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

Шаблон статуту проекту: Управління ризиком (закінчення)

У великих проектах План управління ризиками може розроблятися поза Статутом.

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

Відомий підхід, що має назву Безперервне управлінням ризиками (Continuous Risk Management - CRM). Існують відповідні Керівництва (відкриті ресурси й Інтернет), до змісту яких входять систематичний (таксономічний) опитувальник і всі алгоритми, які можуть бути використані у пов'язаних інструментах і технологіях.

Шаблон статуту проекту: Процесні умови й відхилення

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

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

Шаблон статуту проекту: Етапи

Включає опис життєвого циклу проекту і життєвого циклу поставки рішення (розробки проекту).

Повинні бути визначені етапи проекту, цілі кожного етапу й ознаки їхніх входів/виходів.

Роблять посилання на прийняті в компанії для етапу проекту підходів до визначення вхідних ресурсів/результату й ознак входу/виходу.

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

Шаблон статуту проекту: Управління проектом

У розділі пояснюються методи й процедури, які застосовуються для надання допомоги менеджеру проекту в оцінці виконання проекту й інформуванні про виконання проектної команди, спонсора проекту й зацікавлених сторін проекту.

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

Шаблон статуту проекту: Управління проектом (продовження)

Управління проектом характеризується:

• Типом і частотою розробки проектних звітів

• Частотою проведення нарад проектної команди

• Частотою обговорень контрольних точок етапів проекту (проведених, по-можливості, Виконавчим комітетом).

• Частотою зборів Виконавчого комітету

• Ім'ям і розміщенням проектного файлу

• Методами, які повинні бути використані, щоб одержати допуск і контролювати проектні операції

• Критерієм випуску змінених версій проектного плану

• Метриками, які повинні бути зібрані при реалізації проекту, і аналізом, що повинен бути виконаний з ними

Шаблон статуту проекту: Управління проектом (закінчення)

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

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

Шаблон статуту проекту: Дії по управлінню якістю

Дії по управлінню якістю пов'язані як із процесами управління проектом, так і з результатами проекту.

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

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

Шаблон статуту проекту: Дії по управлінню якістю

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

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

Шаблон статуту проекту: Графік проекту

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

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

Графік проекту повинен враховувати критичні залежності між проектними групами.

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

Шаблон статуту проекту: Оцінка трудомісткості проекту

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

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

Шаблон статуту проекту: Оцінка вартості проекту

Цей розділ визначає вартість проекту, оцінювану відповідно до процедури, прийнятої в компанії. Вартість повинна бути класифікована (праця, обладнання, офісний простір тощо) і декомпонована на етапи й фази проекту.

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

Включається інформація, використовувана для одержання оцінок вартості (допущення, джерела вартісної інформації, історія вартостей, використовувані для оцінки).

Статут необхідний будь-якому проекту

Він формує зміст зобов'язань менеджера проекту, зміст володіння проектом його спонсором, зміст колективної роботи команди проекту.

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

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

Приклад статуту проекту

Проект: Відновлення операційних систем до ХР і до серверів 2000

Спонсор проекту: Піскун Максим, провідний інженер з ІТ (к. 233)

Менеджер проекту: Михайло Шварговський, мережний адміністратор (к. 234)

Команда проекту: Едуард Басов, Анна Берінгер, Марина Бабич, Ксенія Фролова, Шарлота Харченко, Дмитро Батіг, Катерина Манько, Михайло Сивкович, Марко Терновий, Степан Удовенко

Приклад статуту проекту (продовження)

Мета проекту: Всі настільні системи оновлюються до Windows XP до 3 грудня 2010 р.

Всі сервери обновляються й переносяться на п'ять серверів Windows 2000 Servers до 20 грудня наступного року.

Приклад статуту проекту (продовження)

Бізнес-Умови: Windows 95 використовувалася компанією п'ять останніх років. Персонал полюбив і вивчив цю систему, але настав час іти далі. Ми збираємося впровадити нові технології Microsoft, подібні Windows 95, але переважаючі по своїх можливостях - тобто системи Windows XP. Ця операційна система дозволить підвищити продуктивність праці, забезпечить більшу мобільність, підсилить захист і спростить обслуговування. Крім того, у ХР реалізовані нові технології, такі як інфрачервоний мережний доступ, які допоможуть впровадити складську систему для готової продукції й нове фінансове ПЗ, розгортання його намічене на кінець року. Зрозуміло, компанія продовжить присутність в Інтернеті й проведення інтерактивної торгівлі. У цій області системи ХР мають прекрасні можливості для всіх нас.

Приклад статуту проекту (продовження)

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

Для розгортання на всіх наших серверах обрана операційна система Windows 2000 Advanced Server, що надасть користувачам швидкий пошук ресурсів, підвищить час безперебійної роботи мережі та її безпеку.

Приклад статуту проекту (продовження)

Результати проекту:

• Windows XP на кожному настільному й переносному комп'ютері

• Windows 2000 на шести нових серверах

• Усі роботи завершуються 20 грудня наступного року

Приклад статуту проекту (продовження)

Базовий графік робіт:

• Вересень Тестування методів розгортання, дослідження стану користувальницьких систем і додатків, завершення створення образа й формування сценаріїв,

• Жовтень Початкове розгортання в пілотній групі з 100 користувачів. Перевірка, документування й вирішення проблем, що виникли. Повторне розгортання в тій самій пілотній групі доробленої версії й сценаріїв. Початок тестування й настроювання Windows 2000 Server.

Приклад статуту проекту (продовження)

Базовий графік робіт:

• Листопад Початок чотиригодинних підготовчих курсів, розрахованих на один місяць. Слухачі курсів будуть учитися розгортати ХР на своїх настільних ПК- Діагностику й допомогу на місцях координує Дмитро Батіг, менеджер служби підтримки. Продовження тестування Windows 2000 Servers. Три системи Windows 2000 Servers будуть запущені до 15 листопада 2006 р.

• Грудень Завершення розгортання систем ХР. Установка нових серверів 2000 і створення інфраструктури. Перетворення існуючих серверів в Windows 2000. Проект завершується 20 грудня наступного року.

Приклад статуту проекту (продовження)

Ресурси проекту:

• Бюджет: $175 тис. (включаючи ХР, сервер 2000, ліцензії клієнтського доступу CAL, консалтинг, навчання)

• Тестова лабораторія резервується на чотири місяці

• Запрошення консультанта з Donaldson Education

Приклад статуту проекту (закінчення)

Статут проекту може містити стільки інформації, скільки необхідно.

Звичайно він доступний у всій компанії (за винятком фінансових даних), тому потрібно кілька разів перевірити його до випуску.

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

У статуті проекту чітко прописана відповідальність співробітників, що беруть участь у проекті.

Дякую за увагу!

Тема: Управління процесом виконання проекту

• Декомпозиція функцій в управлінні проектами

• Управлінська діяльність відповідно до PMBOK Guide – Project Management Body Of Knowledge

• Розширення PMBOK у застосуванні до ІТ-проектів

1. Декомпозиція функцій в управлінні проектами

1. Декомпозиція функцій в управлінні проектами

Концепція управління проектом може розглядатися в різних аспектах.

Найбільш поширеними є:

• функціональний;

• динамічний;

• предметний;

• процесний.

Функціональний підхід

Досягнення цілей проекту здійснюється через функції управління.

Функція управління у застосуванні до управління проектом означає діяльність команди проекту по управлінню проектом.

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

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

• планування,

• організація,

• координація,

• активізація,

• контроль.

Динамічний підхід

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

Цей підхід пов'язаний з логікою розвитку робіт і визначає так зване спеціальне управління реалізації проекту, яке включає

• аналіз проблеми,

• розробку концепції проекту,

• базове і детальне проектування,

• будівельно-монтажні і пусконалагоджувальні роботи,

• експлуатацію і демонтаж.

Предметний підхід

визначає об'єкти проекту, на які направлене управління.

Наприклад, підготовка приміщення для розміщення ІТ-служби, серверної, розробка ПЗ, впровадження системи тощо.

1. Декомпозиція функцій в управлінні проектами

З метою декомпозиції функцій використовується і такий аспект, як рівень діяльності.

Виділяються два види такого розділення: організаційний рівень і масштаби діяльності по управлінню.

• Організаційний рівень: проект загалом; міжфірмові утворення; організації-учасники; окремі колективи розробників.

• Масштабність діяльності: політика; стратегія; тактика; функції; процедури; операції.

Процесний підхід

Процеси – дії та процедури, пов’язані з реалізацією функцій управління.

Процесний підхід до виділення функцій в управлінні проектами наведено на наступному слайді

Процесний підхід

Зазвичай процеси управління проектами представлені як дискретні елементи із чітко визначеними взаємодіями.

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

Фахівці з управління проектами, визнають, що існує багато різних способів управління проектами.

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

Процесний підхід

Застосування процесів управління проектами є ітеративним, і багато процесів повторюються кілька разів протягом проекту.

Групи процесів управління проектами пов'язані за допомогою виходів (результатів), які вони виробляють.

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

2. Управлінська діяльність відповідно до PMBOK Guide – Project Management Body Of Knowledge

PMBOK

• концентрація кращої практики (best practice);

• основа взаємодії між командами проекту;

• база для сертифікації фахівців;

• систематизація знань у специфічній галузі - управління проектами.

Відповідає на питання «ЩО РОБИТИ?»

«ЯК РОБИТИ?» - визначається корпоративними регламентними документами

Організації

1. PMI - Project Management Institute

(Інститут управління проектами, США)

PMBOK – Project Management Body Of Knowledge – звід знань по управлінню проектами - стандарт ANCI (American Standards Institute)

2. APM - Association of Project Management

(Асоціація управління проектами, Великобританія)

APM Body Of Knowledge

Зміст стандарту PMBOK 2008

Розділ 1. “Структура управління проектами” - формує основу для розуміння суті управління проектами (Вступ, Життєвий цикл проекту і організація)

Розділ 2. “Стандарт для управління проектами” визначає процеси управління проектами для окремого проекту, а також входи і виходи для кожного процесу.

Зокрема, виділено п'ять груп процесів управління проектами: ініціація, планування, виконання, моніторинг і контроль, і завершення; співвіднесено галузі знань з управління проектами із зазначеними групами процесів.

Розділ 3. “Галузі знань управління проектами” описує галузі знань управління проектами; в ньому перераховані процеси управління проектами и визначені входи, інструменти, методи і виходи для кожної галузі.

Усього виділено:

9 галузей знань; 5 груп и 42 процеси

Основні зміни в PMBOK4

Добавлено (основне)

• Сбір вимог, аналітика и протипування

• Ідентифікація зацікавлених осіб

• Ітеративність фаз

Змінено (основне)

• Статут проекту позбавлений функцій ініціалізації

Вилучено (основне)

• Попередній зміст проекту

• Планування змісту

• Вагова модель по закупках

PMBOK 4 став ітеративним?

• PMBOK 3 передбачав тільки «Водопад» (каскадну модель)

• PMBOK4 запропонував ітеративне ведення проектів

Порівняння PMBOK й ітеративної методики Agile

• PMBOK – священна корова це сам план

• Agile – священна корова це результат (Value)

Мишель Слигер, PMP, Master of Scrum

Нове у фіксуванні сфери охоплення

• Опис вимог стейкхолдерів (Stakeholder Requirements Documentation)

• План управління вимогами (Requirements Management Plan)

• Матриця трансформації вимог (Requirements Traceability Matrix)

Методи збору вимог по PMBOK4

• Інтерв'ю

• Фокус-групи по компетенції

• Тематичні сесії (Facilitated Workshop)

• Креативні техніки прийняття рішень і вирішення конфліктів інтересів стейкхолдерів

• Опитувальники

• Спостереження за виконанням процесу в реальності, а не тільки по паперах

• Прототипи

Опис вимог за PMBOK4

• які бізнес-проблеми вдасться розв'язати продуктом проекту;

• відповідність цілей проекту і бізнесу;

• функціональні вимоги, включаючи опис бізнес-процесів и взаємодію з кінцевим продуктом проекту;

• вимоги до якості;

• опис коригувань організаційної структури;

• опис змін у поточних бізнес-процесах;

• вимоги до технічної підтримки і навчання

Ідентифікація зацікавлених осіб

Основні діючі особи (керівники)

• Менеджер (керівник) проекту (Project Manager) - особа, відповідальна за управління проектом

• Спонсор (куратор) проекту (Project Sponsor) – особа, що забезпечує ресурси проекту й будь-яку адміністративну підтримку. Визначає пріоритети, забезпечує взаємодію з функціональними підрозділами, затверджує зміни. У внутрішніх проектах звичайно відповідає за результати проекту

• Замовник (споживач) проекту (Project Customer) – особа усередині або поза організацією, що буде використовувати результати проекту

Діючі особи проекту (виконавці)

• Керівник функціонального підрозділу направляє ресурси в затверджені проекти

• Функціональний лідер проекту об'єднує зусилля учасників проекту в рамках функції або підрозділу. Саме з ним взаємодіє менеджер проекту.

• Лідер пакета робіт об'єднує зусилля окремих осіб у рамках пакета робіт.

Трикутник компромісів

Ключові особисті якості менеджера проекту:

• гнучкість і пристосовність;

• ініціативність і якості лідера;

• агресивність, упевненість у собі, уміння переконувати, чітко виражати свої думки, честолюбство, активність, енергійність;

• уміння спілкуватися, вести посередництво, об'єднувати зусилля;

• широкий кругозір, здатність до узагальнення;

• урівноваженість ентузіазм, уява, безпосередність;

• здатність дотримуватись балансу технічних, часових, вартісних і людських факторів;

• організованість і дисципліна;

• здатність і бажання присвячувати більшу частину свого часу плануванню й контролю;

• здатність виявляти проблеми й приймати рішення.

Галузі знань PMBOK

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

• ініціація;

• планування;

• виконання;

• моніторинг і управління;

• завершення.

До управління проектами, як правило, входить:

• визначення вимог;

• задоволення різних потреб, розв'язання проблем і задоволення очікувань різних зацікавлених сторін проекту в ході планування й виконання проекту;

• урівноважування конкуруючих обмежень проекту, серед яких:

• зміст;

• якість;

• розклад;

• бюджет;

• ресурси; і

• ризики.

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

Нумерація – відповідно з розділами PMBOK(3)–2004 р.

Таблиця взаємозв’язку процесів і галузей знань PMBOK 4

Таблиця взаємозв’язку процесів і галузей знань PMBOK 4

Таблиця взаємозв’язку процесів і галузей знань PMBOK 4

Таблиця взаємозв’язку процесів і галузей знань PMBOK 4

Взаємозв'язок груп процесів

Група процесів ініціації

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

У рамках процесів ініціації визначаються первісні цілі й зміст, і фіксуються початкові фінансові ресурси.

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

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

Група процесів ініціації

Ця інформація закріплюється в Статуті проекту й у Реєстрі зацікавлених сторін проекту.

Після затвердження Статуту проекту вважається, що проект офіційно авторизований.

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

Границі проекту

Група процесів ініціації

Отже, у групу процесів ініціації входять такі процеси:

• Розробка Статуту проекту

• Розробка попереднього опису змісту проекту

Група процесів планування

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

У групу процесів планування входять такі процеси:

4.2. Розроблення плану управління проектом

5.1. Збір вимог

5.2. Визначення змісту

5.3. Створення WBS

6.1. Визначення операцій

6.2. Визначення взаємозв’язків операцій

6.3.Оцінювання ресурсів операцій

6.4. Оцінювання тривалості операцій

6.5. Розробка розкладу (календарного плану)

7.1. Оцінювання витрат

7.2. Розробка бюджету витрат

8.1. Планування якості

9.1. Планування людських ресурсів

10.2. Планування комунікацій

11.1. Планування управління ризиками

11.2. Виявлення ризиків

11.3.Якісний аналіз ризиків.

11.4. Кількісний аналіз ризиків

11.5. Планування реакцій на ризики

12.1. Планування закупівель

Галузі знань MSF

Галузі знань MSF

3. Розширення PMBOK у застосуванні до ІТ-проектів

PMBOK так описує необхідність розширення сфер застосування:

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

Університетом Defense Acquisition University (DAU) при міністерстві оборони США на основі PMI PMBOK другої редакції (2000 рік) підготовлене розширення PMBOK для кількох галузей (у т.ч. для ІТ):

У контексті інформаційних технологій, найцікавіші три з п'яти галузей знань, доданих в PMBOK:

1. Project Systems Engineering Management (управління інженерною діяльністю) (13)

2. Project Software Acquisition Management (управління придбанням програмного забезпечення) (14)

3. Project Test and Evaluation (T&E) Management (управління тестуванням і оцінкою) (16)

1. Управління інженерною діяльністю в проекті (13)

Включає три процеси:

(13.1) Планування інженерної діяльності (Systems Engineering Planning)

(13.2) Інженерна діяльність (Systems Engineering Activities)

(13.3) Аналіз і контроль (Analysis and Control)

Задача процесів цієї групи

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

“По своїй природі «управління інженерною діяльністю» охоплює всі функціональні дисципліни, необхідні для проектування, розробки, тестування, виробництва й підтримки продуктів.” [PMBOK Do Ext, 2003, с.167].

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

2. Управління придбанням ПЗ описує процес “діяльність по придбанню ПЗ” - 14.1 SAM Activities, що звичайно включає (або може включати) такі функції

1. Interoperability global information grid (GIG) (14.1.1.2);

2. Capability Development Document (14.1.1.6);

3. System/Subsystem Specification (SSS) (14.1.1.7)

4. Systems Engineering Plan (14.1.1.9)

5. Test and evaluation master plan (TEMP) (14.1.1.10)

6. Software development and management plans (14.1.1.11)

7. Software requirements (14.1.1.15)

8. Developer software capability evaluation (14.1.1.18)

2. Управління придбанням ПЗ описує процес “діяльність по придбанню ПЗ” - 14.1 SAM Activities, що звичайно включає (або може включати) такі функції

1. Interoperability global information grid (GIG) (14.1.1.2) – перевірку відповідності вимогам інтероперабельності, тобто прозорості взаємодії (забезпечення такої) у контексті існуючих і планованих до використання інформаційних систем і/або заданих критеріїв інтероперабельності;

2. Capability Development Document (14.1.1.6) – документ, що готується замовником/користувачем програмної системи, який описує ключові високорівневі вимоги до системи з погляду параметрів продуктивності, готовності/здатності до інтеграції й операційного оточення, у якому дана система буде експлуатуватися;

2. Управління придбанням ПЗ описує процес “діяльність по придбанню ПЗ” - 14.1 SAM Activities, що звичайно включає (або може включати) такі функції

3. System/Subsystem Specification (SSS) (14.1.1.7) - специфікація системи і її підсистем, що включає високорівневі вимоги й методи перевірки відповідності системи цим вимогам;

4. Systems Engineering Plan (14.1.1.9) – докладно описується в групі процесів управління інженерною діяльністю (13) і являє собою загальний (високорівневий) план і графік робіт, необхідних для одержання необхідного програмного продукту;

2. Управління придбанням програмного забезпечення (продовження)

5. Test and evaluation master plan (TEMP) (14.1.1.10) – план робіт з тестування й оцінки готовності програмної системи;

6. Software development and management plans (14.1.1.11) – звичайно включає Software Development Plan (SDP) або аналогічні плани-графіки робіт, що описують життєвий цикл конкретного програмного проекту; такий план базується на нормативних актах, стандартах і/або регламентах, прийнятих у конкретній організації/підрозділі;

7. Software requirements (14.1.1.15) – докладні вимоги до системи, що деталізують

2. Управління придбанням програмного забезпечення

8. Developer software capability evaluation (14.1.1.18) - оцінка можливостей розробника програмного забезпечення; вимагає від виконавця робіт, зокрема, “повної відповідності Software Engineering Institute (SEI) Capability Maturity Model (CMM) рівню 3 або його еквіваленту”.

Така позиція вже стала де-факто стандартною вимогою до компаній, що виконують замовлену розробку програмного забезпечення для середніх і великих компаній і організацій у всьому світі. Модель SEI CMM, а точніше CMMI Capability Maturity Model Integration [CMMI 1.1, 2002].

Функції цієї групи процесів деталізують питання управління інженерною діяльністю (13) у застосуванні до програмного забезпечення.

Ряд загальних технік, не пов'язаних зі специфікою Розширень PMBOK:

1. Software development maturity assessments (14.1.2.1) – оцінка (може передбачати сертифікацію) зрілості «процесів» розробки програмного забезпечення;

2. Software acquisition maturity assessments (14.1.2.2) – оцінка зрілості «процесів» придбання ПЗ; докладно описані в Software Acqusition моделей оцінки зрілості CMM і CMMI (SA-CMM і SA-CMMI, відповідно);

3. Software measures (14.1.2.3) – метрики програмного забезпечення; включають вимірні характеристики якості (quality metrics);

4.Life-cycle standards tailoring (14.1.2.4) – адаптація стандартів і методологій в галузі управління життєвим циклом; має на увазі, наприклад, адаптацію стандарту ISO/IEC 12207;

Дві ключові групи аспектів, пов'язаних з управлінням роботами (а не, наприклад, з архітектурними й технологічними питаннями):

1. Моделі, стандарти й методології управління життєвим циклом програмного забезпечення;

2. Моделі й методи оцінки зрілості й удосконалювання процесу розробки.

Agile-маніфест розробки ПЗ

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

Завдяки цій роботі ми змогли зрозуміти, що:

• Люди та співпраця важливіші за процеси та інструменти

• Працюючий продукт важливіший за вичерпну документацію

• Співпраця із замовником важливіша за обговорення умов контракту

• Готовність до змін важливіша за дотримання плану

Тобто, хоча, цінності, що справа важливі, ми все ж цінуємо більше те, що зліва.

Основні принципи Agile-маніфесту

• Найвищим пріоритетом для нас є задоволення потреб замовника, шляхом завчасного та регулярного постачання програмного забезпечення.

• Схвальне ставлення до змін, навіть на заключних стадіях розробки.

• Agile-процеси надають можливість використовувати зміни задля забезпечення конкурентоспроможності замовника.

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

• Впродовж усього проекту розробники і представники бізнесу повинні працювати разом щодня.

Основні принципи Agile-маніфесту (продовження)

• Над проектом повинні працювати вмотивовані професіонали.

• Щоб робота була виконана, створіть їм умови, надайте підтримку і повністю на них покладіться.

• Особиста комунікація – найефективніший та найпрактичніший метод як донести інформацію до команди, так і поширити її всередині.

• Працюючий продукт – головний показник прогресу.

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

Основні принципи Agile-маніфесту (закінчення)

• Постійна увага до технічної досконалості і якості проектування підвищує гнучкість проекту.

• Простота – мистецтво мінімізації зайвої роботи – вкрай необхідна.

• Найкращі вимоги, архітектурні та технічні рішення виникають у командах, що здатні самоорганізовуватись.

• Команда регулярно намагається знайти способи підвищення ефективності та відповідно коригує свою роботу.

Тема 8. Організація робіт по проекту

1. Організаційні форми реалізації проекту

2 Поняття організаційно-динамічної структури управління проектом

3. Типи організаційних структур груп для УП

4. Вибір організаційної структури управління проектом

5.Функції провідних фахівців робочої групи УП

6. Формування і розвиток команди проекту

1. Організаційні форми реалізації проекту

Організація (від лат. organizo - надаю стрункого вигляду, улаштовую):

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

• сукупність процесів або дій, що ведуть до утворення й удосконалювання взаємозв’язків між частинами цілого;

• об’єднання людей, що спільно реалізують програму або ціль і діють на основі певних правил та процедур.

Поняття організації зазвичай співставляється з поняттями структури, системи та управління.

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

Організаційні форми реалізації проекту

Поняття організаційної структури проекту охоплює,

по-перше, організаційні форми реалізації проекту,

по-друге, - організаційні структури управління проектом.

Організаційна форма - це організація взаємодії та взаємовідносин між усіма учасниками проекту.

Організаційна структура УП - сукупність взаємопов’язаних органів управління, що знаходяться на різних ступенях (рівнях) системи управління.

Організаційна форма реалізації проекту залежить від:

• того хто є менеджером проекту;

• конкретних параметрів проекту: термінів, обсягу, цілей тощо;

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

Класифікація організаційних форм УП

• Основна система,

• Система розширеного управління,

• Система прискореного будівництва.

Організаційні форми управління проектом можна класифікувати лише умовно.

“основна система”

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

• Повноваження менеджера проекту обмежуються умовами, передбаченими контрактом із замовником.

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

Обов’язки між учасниками проекту за “основної системи” розподіляються так:

Замовник: визначає масштаби проекту, укладає контракти з менеджером проекту та іншими учасниками і несе відповідальність по цих контрактах, керує процесом взаємодії між усіма учасниками.

Менеджер проекту:

• відповідає за координацію та управління всім ходом розробки та реалізації проекту,

• працює за контрактом із замовником. З іншими учасниками відносини на умовах інших контрактів недопустимі.

Інші учасники проекту виконують традиційні для них функції.

“основна система”

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

• Недоліки: ризик за долю проекту повністю лягає на замовника. Крім того немає впевненості в стабільності “граничних” витрат по проекту, тому він вимушений повністю покладатись на компетентність менеджера проекту.

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

Загальна схема розподілу відповідальності:

Замовник - відповідає за визначення масштабів та параметрів проекту, укладає контракт з менеджером проекту, який повинен забезпечити спорудження об’єкта, у більшості випадків, “під ключ”.

Фахівці розглядають такі організаційні форми як своєрідні “спільні підприємства” до складу яких входять всі учасники проекту за виключенням замовника.

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

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

Система прискореного будівництва

• проектування та будівництво здійснюється однією проектно-будівельною фірмою, з якою замовник укладає контракт “під ключ” із заздалегідь визначеною ціною проекту.

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

2. Поняття організаційно-динамічної структури управління проектом

Динамізм - це постійні зміни.

Структури, що змінюють свою конструкцію на різних етапах здійснення проекту, називаються організаційно-динамічними.

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

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

Тому дуже важливо на початковій (концептуальній) фазі визначити динамізм організаційної структури, це дозволить своєчасно підготувати «вхід» і «вихід» необхідного персоналу проекту.

2. Поняття організаційно-динамічної структури управління проектом

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

Ця обставина забезпечує єдиний підхід до проектування організаційно-динамічної структури управління.

Проектування організаційно-динамічних структур спирається на такі принципи:

• принцип єдності адміністрування, що виключає подвійність підкорення і суперечність вказівок;

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

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

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

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

На вибір варіанта організаційної структури впливають такі чинники:

• технічні (масштаби проекту, складність технологічних процесів і обладнання, рівень механізації і автоматизації, характер інформаційних потоків);

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

• соціально-психологічні (соціальна структура і відносини в команді проекту, характеристика психологічного клімату і інш.);

• зовнішні зв'язки і умови (характеристика кооперації та конкуренції, система постачання, кліматичні та природні умови та інш.);

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

3. Типи організаційних структур груп для управління проектами

Концепція управління проектами передбачає:

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

Ця група створюється на період реалізації проекту і після його завершення розпускається.

На практиці застосовуються два основних підходи до формування груп для УП:

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

• Для управління проектом створюється єдина група на чолі з менеджером проекту. В групу входять повноважні представники всіх учасників проекту. Всередині кожної фірми-учасниці може створюватись своя група контролю за ходом проекту.

Логіку взаємодії учасників проекту всередині такої групи відображає її організаційна структура.

Існує кілька типів організаційних структур, які широко застосовують в управлінні проектами:

• проектна,

• матрична,

• комбінація цих двох типів структур,

• проект здійснюється у межах функціональної структури фірм учасниць.

Згідно з проектною структурою управління

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

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

У проектній структурі менеджер проекту має повні повноваження.

Члени команд проектів залишають свої функціональні відділи й переходять у підпорядкування до менеджерів проектів у проектно-орієнтовані підрозділи.

Тим самим досягається повна координація роботи команди проекту.

За проектної структури

• персонал робочої групи виділяється для участі в проекті на повний робочий день.

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

У випадку проектної структури

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

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

Проектні структури

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

Однак у проектної структури є й серйозні недоліки:

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

- після завершення проекту виникають проблеми із працевлаштуванням персоналу проектних підрозділів — їхні місця у функціональних підрозділах можуть бути зайняті;

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

Матрична структура управління створюється на базі функціональної

У цьому разі взаємовідносини базуються на прямих вертикальних зв’язках «керівник — підлеглий».

З метою розв’язання конкретних проблем створюються тимчасові проектні групи, які очолюють керівники проектів.

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

Керівники проектів взаємодіють з функціональними відділами по горизонталі; ці зв’язки накладаються на традиційні вертикальні зв’язки «керівник — підлеглий», утворюючи матрицю взаємодії.

Матрична структура управління

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

Для того, щоб ця структура була ефективною, необхідно мати ефективну систему контролю за виконанням робіт, пов’язаних з проектом, якістю їх виконання, витратами та термінами.

Необхідно постійно стежити за тим, щоб фактичні показники відповідали плановим.

Матрична структура управління

Матричну структуру управління доцільно застосовувати при реалізації малих і середніх проектів.

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

Матричні структури управління проектами, зазвичай, використовуються, коли проекти повторюються, є невеликими, але не рутинними.

Матрична структура управління

Залежно від повноважень менеджера матрична форма має багато модифікацій:

від так званої слабо матричної та майже функціональної до сильно матричної та майже проектної.

Матрична структура управління

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

Повноваження менеджера проекту в такій структурі обмежені.

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

Матрична структура управління

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

Менеджери проектів у такій структурі не входять у функціональні підрозділи, якщо не вважати таким Проектний офіс.

Членів команди управління проектом не виводять зі складу своїх функціональних підрозділів, але «відряджають» у команду проекту.

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

Матрична структура управління

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

Таке виділення може бути повним і частковим (коли співробітник лише частково завантажений роботами проекту).

Матрична структура управління

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

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

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

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

Матрична структура управління

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

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

На практиці протягом багатьох років матрична організація використовувалась як найкращий спосіб роботи над проектом, особливо в ІТ- фірмах.

Нині проектна структура вважається найефективнішою і тому більш популярною.

Порівняльна характеристика проектної і матричної структури

Порівняльна характеристика проектної і матричної структури

За функціональної структури

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

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

За функціональної структури

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

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

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

Недоліки функціональної структури:

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

Цей тип структури використовується, зазвичай, в тих організаціях, де:

- стабільний режим роботи,

- відносно малий вплив зовнішнього середовища,

- незмінна спеціалізація виробництва,

- рівномірний темп розвитку організації.

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

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

Характеристики типів організацій

Формування системи управління проектно-орієнтованою компанією

4. Вибір організаційної структури управління проектом

Вибір організаційної структури управління проектом

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

Можна застосовувати усі три вищезазначені структури залежно від проекту.

Разом ці структури можна застосовувати ще й у межах одного проекту на різних рівнях і фазах управління ним.

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

Вибір організаційної структури управління проектом

Більшість сучасних організацій використовують змішані структури.

Так, функціональні організації створюють спеціальні команди по управлінню важливими проектами.

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

Вибір організаційної структури управління проектом

Організаційна структура повинна бути якомога простішою і якомога краще виконувати свої функції.

Основними критеріями для вибору можуть бути:

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

– технологія проекту;

– складність проекту;

– тривалість проектного циклу;

– розмір проекту;

– важливість проекту;

– взаємозалежність окремих частин проекту;

– зобов’язання по термінах виконання робіт тощо.

Вибір організаційної структури управління проектом

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

Узагальнена (базова) оргструктура

може бути адаптована для конкретної розробки через об‘єднання суміжних робіт.

Рекомендації по адаптації оргструктури:

• Об‘єднати суміжні види діяльності в оргструктурі.

• Об‘єднати сусідні роботи з кількістю виконавців менше двох, якщо вони не пов’язані з керівництвом кількох підпорядкованих робіт, або для виконання робіт необхідно менше ніж 0,5 виконавця і є відсутньою перспектива зростання зайнятості на наступній фазі.

• Якщо для будь-якого виду діяльності необхідно більше семи виконавців, то слід розподілити її на роботу, пов’язану з керівництвом і на кілька підпорядкованих робіт.

• Коло обов’язків будь-якого керівника слід обмежувати керівництвом не більше ніж сімома роботами.

При побудові оргструктури

слід керуватись логікою “здорового глузду”, якщо будь-яка з рекомендацій не відповідає конкретним умовам.

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

5. Функції провідних фахівців робочої групи УП

Робоча група складається з таких підгруп:

• підрозділи, що створюються за відповідними напрямками основної діяльності (проектування, закупівля (постачання), будівництво, тощо) (їх називають виробничими підрозділами);

• персонал контролю та координації проекту;

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

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

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

Величина робочої групи залежить від масштабів і типу проекту

В робочу групу проекту можуть входити:

- менеджер проекту;

- інженер-координатор проекту;

- менеджер служби матеріально-технічного забезпечення проекту

- менеджер будівництва;

- менеджер служби контролю ;

- координатор робіт з проектування;

- координатор проекту з використання засобів автоматизації УП (менеджер ІС);

- адміністративний керівник контрактів;

- адміністративний менеджер.

Обов’язки провідних фахівців:

Менеджер проекту - провідний член групи, він:

• делегує повноваження членам групи,

• слідкує за виконанням плану, оцінює стан робіт, координує та коригує їх виконання,

• використовує персонал контролю проекту для планування обсягів і термінів робіт, отримання оцінок і контролю затрат,

• відповідає за всю роботу над проектом.

У випадку малих проектів він є також координатором проекту або керує кількома проектами одночасно.

У випадку великих проектів йому допомагає координатор робіт по проекту.

Інженер-координатор проекту -

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

Його основні обов’язки:

• визначає обсяги робіт і терміни їх виконання, встановлює взаємозв’язки між елементами проекту, забезпечує планування,

• контролює виконання бюджету проекту (особливо витрати на робочу силу та матеріали),

• забезпечує необхідну якість робіт, у тому числі слідкує за тим, щоб різні напрямки проектування та інженерного забезпечення відповідали б нормативам та обмеженням проекту, контролює виконання робіт у відповідності з вимогами самого проекту та замовника щодо економічних показників, ТУ та державних стандартів,

• відповідає за комунікації (зв’язок) між усіма учасниками проекту.

Інженер-координатор проекту не відповідає за технічні рішення, що закладені в проектній документації. Це є обов’язком головного і провідних інженерів за напрямками робіт, які направлені в робочу групу проекту.

Менеджер служби МТЗ проекту відповідає за своєчасну доставку обладнання і матеріалів тощо.

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

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

Менеджер служби контролю працює у тісному контакті з менеджером проекту.

Основними сферами його діяльності є:

• планування та встановлення термінів,

• оцінка витрат і планування вартості,

• контроль витрат і тенденцій їх зміни,

• інформування менеджера проекту та зацікавлені служби про хід робіт,

• управління матеріально-технічними запасами,

• контроль документації та ін.

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

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

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

Основні види діяльності, які здійснює координатор робіт з проектування:

• визначення обсягів робіт,

• встановлення зв’язків з проектування,

• календарне планування та поточний контроль за ходом проектних робіт,

• збирання даних та аналіз результатів проектування.

Координатор проекту з використання засобів автоматизації УП (менеджер ІС).

В його обов’язки входить підбір, адаптація та використання програмних засобів (спеціальних пакетів) управління проектами (Project management). Він несе відповідальність за машинну обробку інформації в процесі УП. У разі необхідності розробляє нові ПЗ.

Адміністративний керівник контрактів контролює виконання контрактів включаючи питання, пов’язані з поставками матеріалів та обладнання, наданням послуг, прийомом виконаних робіт, оплатою контрактів та їх закриттям.

Протягом усього ЖЦП він контактує з контракторами.

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

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

Складає план закриття контрактів.

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

Адміністративний менеджер (помічник менеджера проекту) координує допоміжну діяльність:

• конторські послуги (надання оргтехніки, меблів, приміщень, копіювальної техніки, надання загальних конторських послуг, бібліотечне обслуговування, тощо);

• фінансові послуги - бухгалтерський облік, укладання контрактів, страхування, внутрішні ревізії, тощо;

• забезпечення зайнятості персоналу, призначення ставок зарплати, організація виробничого навчання і т.ін.

6.Формування і розвиток команди проекту

Команда проекту

Будь-які проекти здійснюються командами людей, які створені заради досягнення цілей проекту.

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

Управління командою

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

Лідерство — це здатність мобілізувати потенційні психологічні потреби послідовників (підлеглих) і спиратися на них в момент гострого суперництва чи конфлікту.

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

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

Команда проекту

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

На верхньому рівні структури знаходиться менеджер проекту, а на нижніх виконавці, відділи і фахівці, що відповідають за окремі функціональні сфери.

Команда проекту

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

Команда проекту

Основним інтегруючим чинником створення і діяльності команди виступає стратегічна мета реалізація проекту.

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

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

Команда проекту

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

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

Команда проекту

Якщо команда починається з лідера, то управління командою — з його знань і навичок організовувати роботу команди. За результатами опитування 20 тисяч вищих і середніх менеджерів США, до числа топ-десятки якостей лідера були віднесені:

- етичність;

- вміння працювати в команді;

- чесність;

- цікавість до всього;

- працелюбність;

- розум;

- цілеспрямованість.

Команда проекту

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

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

Команда проекту

Командна кооперація персоналу дозволяє збільшити продуктивність управлінської праці на 70-80%

Командоутворення

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

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

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

• Визначення складу команди проекту.

• Визначення функціональних обов'язків учасників команди проекту.

• Управління розвитком і діяльністю команди:

• Формування команди проекту.

• Планування роботи команди.

• Організація роботи команди.

• Контроль і координація діяльності команди.

Стадії життєвого циклу команди

Аналогічно життєвому циклу проекту команда проекту має свій життєвий цикл, в якому можна виділити п'ять основних стадій:

• формування,

• спрацьовуванння,

• функціонування,

• реорганізація,

• розформування.

Особливості управління командою на стадії Формування

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

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

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

Особливості управління командою на стадії Спрацьовування (психологічної напруженості)

Це період початку спільної роботи, розвитку згуртованості групи, що вирішує колективну задачу.

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

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

Особливості управління командою на стадії Робоча (нормального функціонування)

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

Деталі взаємодії уточнюються по ходу виконання задач, спілкування в різних ділових ситуаціях.

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

Конфлікти і суперечки в основному виникають з причин, пов'язаних з проектною діяльністю, і мають конструктивний характер.

Особливості управління командою на стадії Робоча (нормального функціонування) (закінчення)

Задачею менеджера проекту на цій стадії є:

• раціональний розподіл функцій між фахівцями і відділами;

• забезпечення відповідності особистих можливостей і здібностей структурі і змісту робіт, що виконуються;

• з'єднання в робочих групах і функціональних підрозділах працівників з різними доповнюючими одна одну індивідуальними здібностями, знаннями і навичками;

• підтримка в команді атмосфери довіри і взаємовиручки, єдності в розумінні цілей і задач проекту і способів їх досягнення;

• визначення і розв’язання конфліктних ситуацій;

• створення дійової системи мотивації;

• контроль за досягненням проміжних результатів проекту і координування діяльності всіх функціональних відділів;

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

Особливості управління командою на стадії Реорганізація

Стадія реорганізації виникає при змінах в кількісному і якісному складах команди у випадках, викликаних:

• змінами в проекті (задачах, планах, результатах проекту);

• змінами структури управління проектом;

• завершенням окремих стадій проекту;

• зміною обсягів і видів робіт, учасників проекту;

• заміною працівників через професійну невідповідність;

• додатковим залученням нових фахівців;

• запрошенням тимчасових експертів.

Особливості управління командою на стадії Реорганізація (закінчення)

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

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

Особливості управління командою на стадії Розформування

При завершенні окремих стадій і всього проекту розформовуються окремі підрозділи і вся команда проекту.

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

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

У разі ефективної діяльності команди по реалізації проекту при виникненні нових проектів ці працівники складають «ядро» нової команди.

Особливості управління командою на стадії Розформування

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

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

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

Особливості управління командою на стадії Розформування

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

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

Для ефективної організації роботи команди необхідні:

• чіткий розподіл ролей і обов'язків;

• усвідомлення всіма членами команди цілей і поточних задач проекту;

• врахування і особистісних, і професійних якостей фахівців при об'єднанні їх в команду;

• увага менеджерів і до досягнення цілей проекту, і до встановлення дружньої робочої атмосфери.

Відповідальність за роботу завжди лежить на менеджерові команди проекту.

Іншу частину роботи можна і треба уміти делегувати.

Уміння делегувати повноваження, тим самим розвиваючи здібності персоналу, стає основною якістю ефективного менеджера проекту.

Поширені помилки, що перешкоджають делегуванню повноважень

• Швидше зробити самому!

• Ні в кого немає відповідних навичок і здібностей!

• Інші можуть зробити не так, як треба.

• Інші можуть зробити краще.

• Немає часу на інструктаж.

• У інших людей і так повно справ.

• Люди можуть подумати, що ви їх перевантажуєте.

• Це можна зробити самому в неробочий час.

• Це знижує контроль.

Переваги делегування повноважень:

• делегування дозволить вам зосередитися на тих аспектах роботи, які вимагають вашого особистого досвіду, знань і кваліфікації;

• основна частина роботи будь-якого менеджера повинна бути направлена на розв'язання стратегічних, а не поточних проблем;

• головною задачею менеджера проекту є керівництво персоналом;

• делегування кращий спосіб мотивації творчого персоналу;

• делегування спосіб навчання працівників;

• це перспективний шлях кар'єри персоналу проекту!

Рекомендації Т. Пітерса і Р. Уотермена, адаптовані до проекту з організації діяльності персоналу

• Орієнтація на дії. Головним принципом існування команди стає дієвість.

• Обличчям до споживачів. Команда віддана ідеї проекту, інтересам споживачів кінцевого продукту проекту.

• Стимулювання самостійності і заповзятливості. Заохочення творчого підходу і виправданого ризику в досягненні цілей проекту.

• Продуктивність від людини. Команда зрілий колектив, самостійні і відповідальні люди.

Рекомендації Т. Пітерса і Р. Уотермена (закінчення)

• Зв'язок з життям, ціннісне керівництво. У проекті створюється стимулююча культура, ціннісні установки персоналу підтримуються вищим менеджментом.

• Вірність своїй справі. Персонал високо професійний і орієнтується на кар'єру в області проекту-менеджменту.

• Простота форми, скромний штат управління. Вищий рівень управління проектом небагаточисельний, структура гнучка і адаптивна.

• Свобода і жорсткість. Принципи реалізації проекту поєднання централізації і децентралізації: делегування повноважень і відповідальності; ефективне лідерство і взаємодія.

Контроль і координація діяльності команди

Зміни, неминучі в будь-якому проекті, ведуть до зміни задач команди проекту, коригування її діяльності.

Контроль за виконанням поставлених цілей і координація діяльності окремих функціональних підрозділів є найважливішими функціями менеджера проекту.

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

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

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

• Необхідність і особливості планування в управлінні проектами

• Принципи планування в проекті

• Цілі, призначення та види планів

• Процеси планування

• Документування плану проекту

• Календарне планування

• Ресурсне планування

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

Сутність планування

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

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

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

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

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

Діяльність з розробки планів охоплює всі етапи проектного циклу.

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

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

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

План - це модель дій і прогнозу стану проекту і його оточення.

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

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

Така послідовна деталізація плану управління проектом часто називається «планування хвилею, що набігає» («rolling wave planning»), що вказує на те, що планування й документування – повторювані процеси, що постійно йдуть.

План - це модель дій і прогнозу стану проекту і його оточення.

То ж навіщо потрібне планування проекту, якщо все змінюється?

Справа в тому, що в управлінні проектом головним є не виконання плану, а ефективне досягнення мети проекту.

Тому основне призначення планування полягає в безперервній підтримці "курсу" розвитку проекту на шляху до його успішного завершення.

Що планується в проекті?

У проекті необхідно планувати все те, що підлягає обліку, контролю, аналізу і регулюванню.

Це насамперед планування у рамках таких сфер діяльності:

• управління предметною областю (змістом);

• управління вартістю;

• управління часом;

• управління якістю;

• управління людськими ресурсами;

• управління комунікаціями;

• управління ризиками;

• управління постачанням і контрактами;

• управління інтеграцією.

2. Принципи планування в проекті

При всьому різноманітті проектів існують загальні підходи і принципи планування в проектах, що зумовлені типовою діяльністю по управлінню проектами, яка направлена на безперервне вирішення таких загальних питань:

• Що необхідно робити?

• Хто і що повинен робити?

• Хто з ким взаємодіє?

• Коли і що повинне бути зроблено?

• Скільки і яких ресурсів треба і для чого?

• Коли і звідки ресурси повинні поступати?

• Що і скільки коштує?

• Що і коли повинно бути сплачено? Які це кошти і звідки вони надходять?

• Які ліміти ресурсів і бюджету?

• Яка якість потрібна?

• Які ризики проекту?

• Що виконано на момент, що розглядається, що ні?

• Ким і які терміни порушені?

• Що необхідно зробити, щоб проект був виконаний вчасно?

До загальних принципів планування можна віднести такі:

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

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

До загальних принципів планування можна віднести такі: (продовження)

• Збалансованість по ресурсах. Означає, що плани не містять задач і робіт, не забезпечених необхідними ресурсами.

• Системність. Передбачає застосування системного підходу і врахування впливу на проект чинників його оточення; розгляд проекту як цілісної системи з визначенням і врахуванням взаємозв'язків як всередині, так і поза ним.

До загальних принципів планування можна віднести такі: (продовження)

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

• Багатофункціональність. Означає обов'язкове планування всіх встановлених функцій управління проектом і сфер діяльності.

До загальних принципів планування можна віднести такі: (продовження)

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

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

До загальних принципів планування можна віднести такі: (закінчення)

• Несуперечність. Забезпечується спадкоємністю та взаємопов’язаністю всіх планових рішень.

• Безперервність. Полягає у моніторингу, контролі та, за необхідності, актуалізації планових рішень.

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

3. Цілі, призначення та види планів

Основна ціль планування - інтеграція всіх учасників проекту для виконання комплексу робіт, що забезпечують досягнення кінцевих результатів проекту.

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

Результатом процесу планування є система планів проекту.

Традиційно склалася така система планів:

• на доінвестиційній стадії у складі концепції проекту, бізнес-плану, попереднього ТЕО — може складатись попередній (укрупнений) план реалізації проекту з урахуванням потреб в основних видах ресурсів і обґрунтуванням інвестицій;

• на стадії розробки проектно-технологічної документації у складі плану управління реалізацією проекту.

У відповідності з фундаментальними рівнями управління план управління реалізацією проекту включає таку система планів:

• концептуальний;

• стратегічний;

• тактичний, який у свою чергу включає:

• поточний;

• оперативний.

Рівні плану відповідають рівням управління.

Чим вищий рівень управління, тим більш агрегована, узагальнена інформація використовується для управління

На концептуальному рівні

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

Стратегічний план визначає:

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

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

• кооперацію організацій виконавців;

• потреби у матеріальних, технічних і фінансових ресурсах з розподілом по роках, кварталах.

Стратегічний план

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

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

Стратегічний план

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

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

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

На тактичному рівні розрізняють

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

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

Результатом процесу планування є система планів проекту

План управління проектом (Project Management Plan) — основоположний документ, що містить узгоджене всіма учасниками, документально зафіксоване уявлення про проект.

План управління проектом — це затверджений формальний документ, в якому вказано, як проект буде виконуватися і як буде відбуватися моніторинг та управління проектом.

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

До плану управління проектом входять:

• План управління змістом проекту (Scope Management Plan) - документ, що описує, як буде визначатися, розроблятися й перевірятися зміст проекту та ієрархічна структура робіт, а також як здійснювати управління змістом проекту.

• Календарний план (Schedule Plan) — документ, що встановлює критерії й операції по розробці й управлінню розкладом проекту.

• План управління вартістю (Cost Management Plan) — документ, що задає формат і визначає операції й критерії для планування, структурування й управління вартістю проекту.

• План управління якістю (Quality Management Plan) — документ, що визначає стандарти якості, які відповідають проекту, і засоби досягнення цих стандартів.

До плану управління проектом входять: (продовження)

• План управління персоналом (Staffing Management Plan) — документ, що описує спосіб виконання вимог до ресурсів.

• План управління взаємодією (Communication Management Plan) — документ, який визначає потреби в інформації й комунікаціях учасників проекту: ким вони є, який ступінь їхньої зацікавленості й впливу на проект, хто яку інформацію потребує, коли вона необхідна і як вона буде надаватися.

• План управління ризиками (Risk Management Plan) — документ, що описує, як буде організоване і як буде виконуватися управління ризиками проекту.

• План управління поставками (Procurement Management Plan) — документ, що описує управління процесами постачань, починаючи від розробки документації по поставках і до закриття контракту.

До плану управління проектом входять: (закінчення)

Крім перерахованих планів до складу плану управління проектом додається:

План по віхах (Milestone Plan) та

План управління змінами (Project Change Management Plan), які розглянемо детальніше.

План по віхах (Milestone Plan)

Віха (контрольна точка) подія або дата в ході здійснення проекту.

Віха використовується для відображення стану завершення робіт у таких контрольних точках де:

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

– приймаються рішення про коригування робочих планів;

– визначається спосіб презентації — нарада, конференція, розсилання звіту.

План по віхах це послідовність віх, що визначені менеджером.

План по віхах (Milestone Plan)

На відміну від робіт віхи не мають визначеної тривалості (тривалість = 0), для їх оцінки використовуються тільки критерії «виконано» або «не виконано».

Під час складання плану по віхах слід пам’ятати, що віхи повинні:

– бути зрозумілими для всіх учасників;

– підлягати управлінню;

– знаходиться на відповідних відстанях (щотижня, щомісяця);

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

– їхня кількість не повинна бути більшою 10–15 на проект.

План по віхах (Milestone Plan)

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

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

Далі повинні бути виділені ключові події, що мають відношення безпосередньо до проекту.

Для створення плану по віхах необхідно:

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

- виділити всі події, що мають строго визначені строки, зрив яких неможливий (важливі переговори, зустрічі, виставки тощо);

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

У результаті планування :

План по віхах буде містити такі дані:

- дата початку проекту;

- важливі етапи з проміжними та основними результати проекту;

- обмеження;

- дата завершення проекту.

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

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

На етапі календарного планування необхідно заповнити проміжки між основними віхами конкретними пакетами робіт.

План управління змінами передбачено на той випадок, якщо необхідно внести зміни у план управління проектом.

Зміни можуть бути пов’язані з модифікаціями, доповненнями й ревізіями проекту. При цьому статус плану змінюється на оновлений (updated).

Зміни можуть стосуватися результатів проекту, проектних документів, які потрібно обов’язково виконати.

Найчастіше члени команди управління проектом на чолі з менеджером проекту відповідають за зміни в проектних документах.

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

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

– комплексний (зведений, головний, генеральний) календарний план;

– конкретні (детальні) календарні плани за виконавцями;

– конкретні (детальні) календарні плани за пакетами робіт;

– відомості потреб у ресурсах;

– графіки постачання технологічного устаткування та матеріалів;

– план укладання контрактів;

– перелік організаційно-технологічних заходів з реалізації проекту;

– план контролю за виконанням робіт.

Після розробки комплексного плану управління проектом його затверджують.

Затверджені план управління проектом разом з календарними графіками утворять базову версію проекту (project baseline).

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

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

4. Процеси планування

Група процесів планування

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

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

Група процесів Планування

Група процесів Планування

4.2. Розробка плану управління проектом

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

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

4.2. Розробка плану УП: входи й виходи

5.1.Збір вимог

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

Збір вимог: входи й виходи

5.2. Визначення цілей і змісту

- процес розробки детального опису проекту й продукту.

Визначення цілей і змісту: входи й виходи

5.3.Створення WBS (ІСР-ієрархічної структури робіт)

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

Створення ІСР: входи й виходи

6.1. Визначення операцій - процес визначення тих операцій, які необхідно виконати для створення результатів проекту

6.2. Визначення послідовності операцій - процес визначення й документування зв'язків між операціями проекту.

6.3. Оцінювання ресурсів операції - процес оцінки типів і кількості матеріалів, людських ресурсів, устаткування або закупівель, необхідних для виконання кожної операції.

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

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

7.1.Оцінювання витрат – процес приблизного підрахунку грошових ресурсів, необхідних для завершення операцій проекту.

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

8.1. Планування якості - процес визначення вимог і/або стандартів якості для проекту й продукту, а також документування того, у який спосіб проект буде демонструвати відповідність вимогам і/або стандартам якості.

9.1. Розробка плану трудових ресурсів - процес визначення й документування проектних ролей, відповідальності, необхідних навичок і відносин звітності, а також створення плану управління забезпеченням персоналом.

10.2. Планування комунікацій - процес виявлення потреб зацікавлених сторін проекту в інформації й визначення підходу до комунікацій

11.1. Планування управління ризиками - процес визначення того, у який спосіб буде здійснюватися управління ризиками проекту

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

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

11.4. Кількісний аналіз ризиків - процес проведення чисельного аналізу впливу виявлених ризиків на цілі проекту в цілому

11.5. Планування реагування на ризики Планування реагування на ризики - процес розробки варіантів і дій для розширення можливостей і зниження загроз для цілей проекту.

12.1. Планування закупівель - процес документування рішень відносно закупівель для проекту, визначення підходу й ідентифікації потенційних продавців

Група процесів планування

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

Оновлення, що виникають внаслідок схвалених змін під час проекту, можуть значно впливати на частини плану управління проектом і документи проекту.

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

Група процесів планування

Команда проекту повинна сприяти залученню всіх необхідних зацікавлених сторін у планування проекту й розробку плану управління проектом і документів проекту.

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

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

Група процесів планування

Інші взаємодії між процесами в рамках групи процесів планування залежать від характеру проекту.

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

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

5. Документування плану проекту

Результати планування повинні бути задокументовані й надані для затвердження.

Єдиного стандарту щодо складу документів плану не існує.

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

Кожна проектноорієнтована компанія на основі власного досвіду розробляє свої шаблони плану проекту.

Приклад №1

Типова структура плану проекту по створенню виробничого об’єкта включає:

• Основні цілі проекту.

• Фінансовий план проекту.

• План виконання субконтрактів.

• Функціональний план.

• Аналіз чинників виконання проекту.

• Додатки до плану проекту.

Така сама структура може бути прийнята і в ІТ-проекті

Приклад №1

1.Основні цілі проекту.

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

Приклад №1

2. Фінансовий план проекту.

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

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

Фінансовому плануванню передує кошторисна робота. Кошториси складаються на кожний вид, етап робіт.

Крім того фінансове планування передбачає оцінку фінансово-економічних показників проекту (дисконтований прибуток, термін окупності та ін.).

Приклад №1

3. План виконання субконтрактів.

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

При складанні цього плану:

а) оцінюються альтернативи укладання субконтрактів; критеріями такої оцінки є можливість виконання технічних завдань субпідрядниками в необхідні терміни;

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

в) розробляється концептуальний календарний план проекту як складова частина контрактної документації.

Приклад №1

4.Функціональний план.

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

Функціональний план складається з таких планових документів:

• головного календарного плану проекту;

• календарних планів робіт (короткострокових);

• функціональних планів робіт.

Приклад №1 (Функціональний план)

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

Короткострокові календарні плани формуються на основі ГКП і містять переліки робіт, терміни, прізвища осіб, відповідальних за їх здійснення.

Приклад №1 (Функціональний план)

Функціональні плани робіт (ФПР) - система планових документів, що містять заходи, а також конкретні технічні й проектні рішення з окремих особливостей виконання проекту.

За планом практичних робіт:

• початкові дані для проектування;

• пріоритети виконання робіт;

• потреба в персоналі;

• процедури затвердження проектних розробок;

За планом матеріально-технічного постачання:

• терміни постачання обладнання;

• терміни і контроль за установкою обладнання;

За планом будівництва:

• вимоги до приміщень для розміщення обладнання і персоналу;

• організація робіт з підготовки і будівництва приміщень;

За планом контролю якості:

• загальні критерії якості;

• контроль обладнання, що поставляється;

За планом введення в експлуатацію:

• підготовчі роботи;

• доексплуатаційний контроль;

• введення в експлуатацію.

Приклад №1

Аналіз чинників виконання проекту.

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

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

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

Приклад №1

Додатки до плану проекту.

Виносяться дані, що використовуються при складанні плану:

• дані з концепції проекту;

• матеріали обстеження;

• вимоги і обмеження до проекту та інше

Приклад №2

План проекту може мати такі основні розділи:

1 - короткий опис проекту;

2 - вступ (цілі і очікувані результати, стратегія, обсяг робіт, організаційні зв’язки, посилання на зовнішні документи);

3 - структура проекту (ролі та відповідальність, процес управління проектом, огляди і затвердження);

4 - комплекс робіт (роботи проекту, оцінка обсягів робіт і кваліфікації, зовнішні задачі, можливі зміни);

5 - графік робіт (по етапах і список дій);

6 - ресурсне забезпечення (персонал, обладнання, засоби, інше);

7 - фінансування (історія фінансування подібних проектів, бюджет, план витрат, фонди, пропозиції);

8 - обмеження, ризики і невизначеність (залежність від зовнішніх проектів/подій, ризики і невизначеність, процес розв’язання проблем).

Приклад № 3 Шаблон плану управління проектом (початок)

ІНФОРМАЦІЯ ПРО ДОКУМЕНТ

• Шифр проекту

• Назва проекту

• Автор документу

• Дата створення

• № версії

Приклад № 3 Шаблон плану управління проектом (продовження)

Ієрархічна структура робіт проекту

<Подайте в графічному чи табличному вигляді ієрархічну структуру робіт проекту з потрібним ступенем деталізації>

Віхи проекту

<Складіть список контрольних точок проекту. Список контрольних точок визначає ключові події проекту, їхні дати й результати, які повинні бути отримані за станом на ці дати >

Календарний план проекту

<Складіть план-графік робіт проекту, що описує всі контрольні точки й роботи із призначеними датами початку й закінчення, а так само взаємозв’язку завдань>

Приклад № 3 Шаблон плану управління проектом (продовження)

Вартісний план проекту

<Вартісний план являє собою розподілений за часом бюджет, по якому провадиться контроль використання коштів проекту>

План якості проекту

<План якості проекту визначає параметри й критерії досягнення якості проекту, щодо яких буде проводитися контроль якості отриманих результатів>

Приклад № 3 Шаблон плану управління проектом (продовження)

Ресурсний план проекту

<Перелічіть всіх співробітників (як внутрішніх, так і зовнішніх), які будуть задіяні в проекті, із вказівкою строків їхньої зайнятості й відсотка завантаження>

План управління командою проекту Організаційна структура проекту

<Подайте організаційну структуру проекту в графічному вигляді>

Приклад № 3 Шаблон плану управління проектом (продовження)

Матриця відповідальності

<Матриця відповідальності встановлює відповідальність ролей проекту відносно виконання основних або типових робіт>

План управління комунікаціями проекту

<План управління комунікаціями відображає вимоги до комунікацій з боку учасників проекту>

Реєстр ризиків проекту

<Ідентифіковані ризики проекту містять у собі можливі невизначені події, які можуть виникнути в проекті й викликати наслідки, які спричинять небажані ефекти>

Приклад № 3 Шаблон плану управління проектом (продовження)

План управління ризиками проекту

<Опишіть правила й періодичність перегляду реєстру ризиків проекту>

План управління контрактами й постачаннями

<Перелічіть всі контракти, які повинні бути укладені для здійснення поставок або робіт із проекту, указавши строки, у які ці поставки або роботи повинні бути виконані>

План комунікацій проекту

Приклад № 3 Шаблон плану управління проектом (закінчення)

План управління змінами

<План управління змінами містить у собі порядок управління змінами в проекті й розробляється на підставі процедури внесення змін

ЗАТВЕРДЖЕНО:

Посада Дата Підпис

ПОГОДЖЕНО:

Посада Дата Підпис

Календарне і ресурсне планування

• Календарне планування

• Ресурсне планування

• Використання методу критичних ланцюжків у календарному плануванні проекту

• Аналіз можливості реалізації й оптимізація плану проекту

1. Календарне планування

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

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

Цілі календарного плану (Schedule) : – забезпечити вчасне надходження фінансування; – координувати надходження ресурсів; – вчасно забезпечити потрібні ресурси; – передбачити у різні моменти рівень потрібних фінансових витрат і ресурсів та раціональний розподіл їх між проектами; – забезпечити вчасне виконання проекту

Календарний план (Schedule) лише як перелік тільки планових параметрів проектних робіт втрачає свій сенс без порівняння з фактичними термінами їх виконання, тому частіше ведуть мову про календарні графіки.

Існує дві найпоширеніші форми подання календарного графіку:

1) таблична — з переліком робіт із зазначенням тривалості їх виконання;

2) діаграмна (балочні діаграми, або діаграми Ганта).

У ході реалізації проекту застосовуються різні типи календарних планів:

За рівнем планування розрізняють:

• Календарні плани проекту (розробляються до укладання контрактів);

• Функціональні календарні плани робіт (ФКПР).

За глибиною планування:

• перспективні графіки;

• графіки початку і завершення робіт по проекту;

• щомісячні, щотижневі, щоденні.

За формою подання:

• логічні сіті;

• графіки;

• діаграми і т.д.

У ході реалізації проекту застосовуються різні типи календарних планів:

У свою чергу, функціональні календарні плани робіт поділяються (ФКПР):

За типами робіт:

• ФКПР проектування;

• ФКПР МТС;

• ФКПР будівництво;

• ФКПР введення в експлуатацію і освоєння.

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

Призначення календарного плану варіюється в залежності від рівня управління, на якому він використовується:

керівник вищої ланки - для контролю термінів досягнення основних корпоративних цілей;

функціональні керівники - для контролю виконання функціональних календарних планів робіт;

менеджер проекту - для контролю виконання основних етапів календарних планів і рівня готовності проектних вузлів.

Кожна робота в календарному плані характеризується:

• тривалістю (часом виконання);

• датами початку і закінчення;

• ресурсами, що необхідні для виконання;

• відповідальним виконавцем.

Кожна робота в календарному плані характеризується:

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

У більшості складних календарних планів існує до 6 варіантів моментів початку, закінчення, тривалості робіт і резерву часу.

Це - ранні, пізні, базові, планові і фактичні дати, резерв часу.

У повній системі календарного планування використовують до 15 дат і моментів часу, що визначають роботу:

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

Планові дати вибираються між ранніми і пізніми датами виконання робіт.

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

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

Ця дата називається базовою датою, а дата поточного плану - поточною плановою датою.

При призначенні базових або поточних планових дат необхідно також враховувати ресурсні обмеження.

Методи розрахунку сітьових моделей дозволяють обчислювати тільки ранні та пізні дати.

Базові і поточні планові дати необхідно вибирати з урахуванням інших факторів.

Існують три варіанти вибору:

• календарний план по ранніх початках (жорстко зліва): використовується для стимулювання виконавців проекту;

• календарний план по пізніх закінченнях (жорстко справа): використовується для подання ходу виконання проекту у кращому вигляді для споживача;

• календарний план між ними: робиться або для згладжування використовуваних ресурсів або для показу замовнику найбільш вірогідного закінчення.

Визначення тривалості роботи

Тривалість роботи - це головний параметр планування на основі якого розраховуються початок і закінчення роботи.

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

При оцінці реальної тривалості необхідно також враховувати й інші чинники:

• Час, втрачений на непроектні роботи.

• Робота неповний день.

• Перешкоди, що виникають між людьми, що виконують цю роботу тощо.

• Як правило, втрати часу (свята, хвороби, навчання і т.п. складають до 30% від загального робочого часу.

• Отже min тривалість роботи треба збільшити на 40 %.

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

Тому загальна їх кількість повинна розраховуватися виходячи з числа працюючих повний день. (При коригуванні тривалості необхідно точно знати, враховані вони чи ні при обліку втраченого часу, тобто до того, як збільшити тривалість на 40%).

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

У цих випадках вірогідна тривалість роботи може бути отримана на основі попереднього досвіду або на базі оперативних і статистичних даних реалізації аналогічних проектів.

При оцінці тривалості необхідно враховувати також логічний взаємозв'язок робіт.

В задачах управління проектом зазвичай розрізняють два види ресурсів:

• Непоновлювані, складовані, накопичувані

• Поновлювані, нескладовані, ненакопичувані

1. Непоновлювані, складовані, накопичувані

Ресурси, які при виконанні робіт повністю використовуються, і які повторно використати неможливо.

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

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

2. Поновлювані, нескладовані, ненакопичувані

Ресурси - зберігають свою натурально-речовинну форму і з вивільненням можуть використовуватись на інших роботах.

Якщо ці ресурси простоюють, їх не можна використати потім, вони не накопичуються.

Такі ресурси часто називають ресурсами типу "потужності".

Приклад: люди і засоби праці багаторазового використання (машини, механізми, тощо).

Перевірка ресурсного забезпечення календарного плану означає співставлення наявних і необхідних ресурсів для проекту в цілому.

У загальному вигляді алгоритм ресурсного планування включає три етапи:

1 - визначення ресурсів (опис ресурсу і визначення максимуму доступної кількості даного ресурсу);

2 - призначення ресурсів задачам (елементарним роботам);

3 - аналіз розкладу і розв’язання протиріч, що виникли між необхідною і наявною кількістю ресурсу.

Оскільки наявність необхідних ресурсів для виконання робіт часто є ключовим фактором УП, керівник може розробити реальний план тільки у тому випадку, коли описані доступні ресурси.

Процес призначення ресурсів полягає у зазначенні для кожної роботи (задачі) необхідних ресурсів і визначенні їх необхідної кількості.

Існує три основних види залежності потреби у ресурсах від ходу роботи (тривалості):

• постійний - протягом всієї роботи завантаження (фронт робіт) ресурсу не змінюється;

• східчастий - протягом роботи завантаження ресурсу змінюється стрибкоподібно (сходинками);

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

Два основні підходи до ресурсного планування:

• За обмеження у часі

• За обмежених ресурсів

1. Ресурсне планування за обмеження у часі

передбачає жорсткі обмеження на терміни завершення робіт і призначення на проект додаткових ресурсів на періоди перевантаження.

Такий підхід ще називають методом “Згладжування”, за якого потрібно оптимізувати деякий показник якості використання ресурсів, наприклад, мінімум перевищення необхідних ресурсів над заданим рівнем їхньої наявності.

2. Планування за обмежених ресурсів

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

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

Такий підхід ще називають методом “Калібрування”. Цей алгоритм мінімізує терміни виконання комплексу робіт при заданих обмеженнях на ресурси.

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

Доцільно поєднувати обидва підходи

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

Сучасним методом, який при розробці календарного плану враховує не лише часові, а й ресурсні обмеження проекту, є метод критичних ланцюжків (ССРМ - Critical Chain Project Management).

Метод критичних ланцюжків — це підхід до вирішення невизначеностей у будь-якому проекті і є поширенням теорії обмежень (TOC - Theory of Constraints) на сферу управління проектами.

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

Теорія обмежень містить два основні положення:

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

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

Стосовно управління проектами теорія обмежень була адаптована в середині 90-х рр., коли з’явилося поняття «критичного ланцюжка».

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

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

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

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

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

Проте це істотно знижує вірогідність завершити вчасно проект в цілому.

В управлінні проектами існує три групи проблем:

1) статистичні;

2) поведінкові;

3) управлінські.

Найважливішими є управлінські аспекти, оскільки вони впливають на всі інші

1) статистичні

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

За статистикою проекти завжди запізнюються.

Наприклад, якщо на задачі відведено п’ять днів, то вірогідність, що її вдасться завершити за чотири або за три дні, дуже невелика. Значно більше шансів, що вона буде виконана через тиждень.

Час реалізації проекту має тенденцію до збільшення, так само як і бюджет, і обсяг робіт за проектом.

У більшості проектів раннє виконання робіт не заохочується.

Чому?

Через те, що дати задач-послідовників уже сплановані й люди, призначені на їхнє виконання, теж мають свої плани на інші дні.

Виходить, якщо хтось закінчив задачу раніше, то він, скоріше за все, навіть не сповістить про це: навіщо підводити своїх колег?

2) поведінкові

Ця група проблем відноситься до поведінкових особливостей людей, що беруть участь в проекті.

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

Це серйозна психологічна проблема в управлінні проектами.

Наприклад.

Буфер часу в кожній операції.

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

Наприклад

Наприклад

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

Тобто набуває чинності так званий «синдром студента»: робота відкладатиметься до самого крайнього терміну.

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

“синдром студента”

Виконавець приступить до виконання завдання тільки у найкоротші, оптимістичніші строки до контрольної дати.

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

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

Третя група проблем пов’язана з тим, як керівництво організації оцінює роботу людей в проекті.

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

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

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

Наприклад.

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

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

1) робота з керівництвом організації, спроба змінити їх підходи до оцінювання діяльності співробітників. Треба добитися, щоб керівництво мало правильні критерії оцінювання керівників проекту, співробітників і в цілому результатів проекту. Така зміна системи оцінювання впливає на те, як люди поводяться в проектах;

2) працювати з членами проектної команди і переконати їх відмовитися від практики приховувати свій буферний час і віддати його на благо всього проекту.

Необхідно включити буферний час окремих учасників проекту в буферний час для проекту

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

Це так зване управління буферами.

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

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

Виникає необхідність координувати плани кількох проектів, що працюють на загальних ресурсах.

Слід ідентифікувати найбільш завантажені ресурси, які будуть обмеженням для всієї мультипроектної системи.

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

У термінології теорії обмежень це називається «барабаном», під ритм якого «танцює» вся організація.

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

• зміна системи оцінювання менеджерами організації і визначення ресурсу, який є головним обмеженням системи;

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

Алгоритм методу критичних ланцюжків (ССРМ) містить певну послідовність кроків:

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

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

3. Зменшення тривалості робіт, представлених менеджерові проекту виконавцями, на одну третину. Величина, на яку зменшується тривалість робіт, науково не обґрунтована і має емпіричний характер.

4. Створення розкладу з урахуванням «вирізаної» тривалості робіт і формування нового критичного шляху критичного ланцюжка (рис. наступний слайд).

Алгоритм методу критичних ланцюжків (ССРМ) містить певну послідовність кроків: (закінчення)

5. Формування буфера проекту з буферів робіт критичного ланцюжка і окремих часткових буферів — буферів некритичних робіт. Принцип формування буферів передбачає наявність у проекті кількох ланцюжків робіт, які можуть виконуватися паралельно, а також об’єднуватися разом. Визначення розміру буфера базується виключно на припущеннях і особистому досвіді менеджера проекту.

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

Створення критичного ланцюжка робіт

Після розробки календарний план уточнюють і, в разі потреби, деталізують.

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

Розрізняють чотири типи оцінок можливості реалізації проекту:

• логічну,

• часову,

• ресурсну,

• економіко-фінансову.

Сутність кожної оцінки реалізованості проекту така:

• логічна — це урахування логічних обмежень на можливий порядок виконання робіт у часі згідно з особливостями проекту та його предметної області;

• часова — це розрахунок і аналіз часових характеристик робіт;

Сутність кожної оцінки реалізованості проекту така: (продовження)

• ресурсна реалізованість — це урахування обмеженості наявних чи доступних ресурсів у кожен момент часу виконання проекту.

Ресурсні можливості реалізації проекту аналізують у дві стадії:

на першій - оцінюють наявність ресурсів для всіх робіт,

на другій - згладжують епюру використання ресурсів.

Сутність кожної оцінки реалізованості проекту така: (закінчення)

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

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

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

Зазвичай аналіз плану робіт проекту виконується наприкінці етапу планування задач.

Проект плану доцільно перевіряти за такими критеріями, як:

• мінімальна тривалість його виконання;

• мінімальна вартість та максимальне використання власних ресурсів;

• максимальна задоволеність замовника тощо.

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

Оптимізація проекту передбачає:

1. Оптимізацію термінів.

2. Оптимізацію розподілу ресурсів.

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

Перед оптимізацією проекту обов’язково необхідно зберегти резервну копію плану.

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

На цій стадії необхідно виконати такі дії:

– визначити ресурси і розподілити їх у часі;

– оптимізувати сумарні графіки потреби в ресурсах;

– визначити постачальників ресурсів за проектом;

– сформувати графіки постачання ресурсів.

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

Для оптимізації плану проекту необхідно використовувати різноманітні стратегії коригування проектного плану.

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

Можливі стратегії коригування плану:

1. Змінити тривалість робіт (Change a task duration).

2. Переглянути залежність робіт (Review task dependencies).

3. Встановити випередження або затримку для робіт (Set overlap or delay for tasks).

4. Переглянути і змінити обмеження на роботу (Review and change a task constraint).

5. Модифікувати проектний календар (Modify the project calendar).

6. Модифікувати ресурсний календар (Modify a resource calendar).

Можливі стратегії коригування плану(закінчення):

7. Модифікувати чи видалити робочий календар задачі (Modify or remove a task calendar)

8. Додати ресурси (Add a resource).

9. Замінити ресурси (Change a resource).

10. Змінити кількість часу, яку ресурс витрачає на задачу (Adjust the amount of time a resource spends on a task).

11. Поліпшити роботу ресурсу (Improve resource performance).

Суть стратегій коригування плану

1. Змінити тривалість роботи (Change a task duration). Якщо це можливо, найпростіший шлях — скоротити тривалість роботи, особливо для тих задач, які є на критичному шляху.

2. Переглянути залежність робіт (Review task dependencies). Необхідно переконатися, що всі роботи були логічно пов’язані.

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

Суть стратегій коригування плану

3. Встановити випередження або затримку для робіт (Set overlap or delay for tasks). Сценарій реалізується за допомогою часткового покриття робіт, які відбуваються на критичному шляху, або за допомогою затримки некритичної роботи, таким чином, що ресурс може працювати над іншою, критичнішою роботою.

4. Переглянути і змінити обмеження на роботу (Review and change a task constraint). Жорстке обмеження (inflexible constraint) для роботи, особливо, якщо вона є критичною, може обмежити здатність зміни графіку робіт проекту. Якщо робота не повинна починатися або закінчуватися на конкретній даті, щонайшвидше зніміть або змініть обмеження.

Суть стратегій коригування плану

5. Модифікувати проектний календар (Modify the project calendar). За допомогою зміни проектного календаря, де вказується як, коли і як довго ресурси працюють над роботами, можна потенційно скоротити повну тривалість проекту.

6. Модифікувати календар ресурсу (Modify a resource calendar). За допомогою зміни індивідуальних календарів ресурсу можна скоротити повну тривалість роботи, над якою працюють ресурси.

Суть стратегій коригування плану

7. Модифікувати або видалити календар задачі (Modify or remove a task calendar). Робочий календар, застосований до певної роботи, може продовжувати тривалість, якщо час, вказаний в розкладі, суперечить призначеному ресурсному календарю.

8. Додати ресурси (Add a resource). Додавання додаткових ресурсів до задач може допомогти зменшити тривалість задач і скоротити довжину проекту для задач на критичному шляху.

Суть стратегій коригування плану

9. Замінити ресурси (Change a resource). Можна безпосередньо замінити один ресурс на інший, якщо це допоможе задачі закінчитися раніше. Можна замінити ресурс для розв'язання проблеми перепрацювання (overallocations), скоротити витрати, збільшити ефективність або якість роботи.

Суть стратегій коригування плану

10. Змінити кількість часу, яку ресурс витрачає на задачу (Adjust the amount of time a resource spends on a task).

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

За замовчуванням використовується планування з фіксованим обсягом робіт (effort-driven scheduling), за допомогою якого тривалість цих задач зменшується.

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

Суть стратегій коригування плану

11. Поліпшити роботу ресурсу (Improve resource performance). Поліпшити роботу ресурсу можна навчанням ресурсу, а також, забезпечуючи ресурси кращими інструментами, застосовуючи навики управління до проблем ресурсу тощо. Це іноді єдине рішення, якщо інші людські ресурси є недоступними.

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

Дякую за увагу!

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

• Розвиток методів планування

• Сітьові моделі

1. Розвиток методів планування

Спочатку використовувалися досить прості засоби і методи:

лінійні діаграми;

таблиці трудових витрат,

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

таблиці обладнання, що містять дані про типи обладнання, терміни постачання;

фінансові таблиці, що відображають витрати і прибутки.

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

Методи сітьового планування

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

Базуються на методах, розроблених практично одночасно й незалежно:

метод критичного шляху (МКШ) (англ. – Critical Path Method - CPM) і

метод оцінки та перегляду планів (ПЕРТ) (англ. – Program Evaluation and Review Technique - PERT).

Метод критичного шляху (МКШ) краще використовувати тоді, коли операції проекту мають визначену тривалість,

Метод ПЕРТ більш ефективний

якщо оцінки тривалості мають ймовірнісний характер.

Загальна умова - для реалізації події повинні бути завершені усі попередні операції.

Сітьова діаграма (сіть, граф сіті, PERT-діаграма)

– графічне відображення робіт проекту і залежностей між ними.

2. Сітьові моделі

Сітьове планування - це побудова сітьового графіка та обчислення його параметрів

Для побудови сітьового графіка потрібно мати:

• список робіт

• логічні зв'язки між роботами

Робота (операція) - дія, необхідна для реалізації проекту

Роботи в сітьових графіках мають свій номер або код, який присвоюється їм при побудові WBS- структури

Логічні зв'язки

Послідовні, коли одна робота виконується після другої;

Паралельні, коли кілька робіт можуть виконуватися одночасно

Сітьові моделі доцільно використовувати тільки для складних проектів.

Існує три типи сіток:

• сіті "вершини-події";

• сіті типу "вершини-роботи“ (сіті передування);

• змішані сіті.

Сіті типу "вершини-події" (стрілчасті)

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

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

Стрілчастий графік

Роботи А і В паралельні

Зображення роботи в сіті IJ

Хоча стрілчасті сіті менш популярні, ніж сіті передування, їх все ще застосовують у деяких прикладних сферах.

В IJ-сітях використовують тільки залежності «фініш-старт», тому є необхідність використання фіктивних робіт для правильного визначення всіх логічних зв'язків.

Креслять діаграми IJ вручну або з допомогою комп'ютера.

Сіті типу "вершини-роботи" або сіті передування

Зображення роботи в сіті передування

Типи логічних залежностей між роботами

закінчення-початок: робота В не може початися, поки не закінчиться робота А. Це стандартна ситуація, коли наступна робота не може розпочатись, поки не закінчиться попередня;

закінчення-закінчення: робота D не може закінчитися, поки не закінчиться робота С. Використовується для моделювання паралельних робіт;

Типи логічних залежностей між роботами (закінчення)

початок-початок: робота D не може початися поки не почнеться С. Використовується для моделювання робіт, які виконуються одночасно;

початок-закінчення: робота F не може закінчитися поки не почнеться Е. Використовується для робіт, виконуваних вахтовим методом.

Затримка/випередження

наступна робота не може розпочатись раніше, ніж через два дні після завершення попередньої роботи

наступна робота розпочинається на три дні раніше, ніж завершиться попередня робота

Розрахунок сітьової моделі

• Визначення переліку й послідовності виконання робіт. Графічна побудова сітьового графіка.

• Означення тривалості роботи.

• Визначення термінів початку і завершення робіт шляхом “прямого проходження” по сіті.

• Визначення пізніх термінів початку і завершення робіт шляхом “ зворотного проходження” по сіті.

• Визначення критичного шляху і запасу часу по роботах

Послідовність побудови графіка

• Визначити перелік і послідовність виконання робіт на основі WBS- структури (визначається менеджером проекту)

• Накреслити сітьовий графік із зображенням робіт і логічних зв'язків між ними

• Позначити на графіку тривалість кожної роботи

Прядок побудови графіка (продовження)

4. Визначити ранні терміни початку і закінчення робіт (пряме проходження по сіті)

Ранні дати початку (ES – Early Start) і закінчення (EF - Early Finish) робіт

ES_i+1 = EF_i + 1;

EF_i = ES_i + t_i -1.

EF_i - ранній термін завершення і-ї роботи;

ES_i - ранній термін початку і-ї роботи;

t_i – тривалість і-ї роботи;

ES_i+1 - ранній початок роботи і+1.

Прядок побудови графіка (продовження)

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

Раннє закінчення перетворюється у наступній роботі у ранній початок відніманням випередження або додаванням запізнення, які передбачають залежність закінчення-початок

Прядок побудови графіка (продовження)

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

Прядок побудови графіка (продовження)

5. Визначити пізні терміни початку і завершення робіт шляхом “зворотнього проходження” по сіті

Пізні дати пізнього початку (LS – Late Start) і закінчення (LF - Late Finish) робіт

LS_i = LF_i -t_i +1;

LF_i+1 = LS_i -1.

LS_i - пізній термін початку і-ї роботи;

LF_i - пізній термін завершення і-ї роботи;

t_i – тривалість і-ї роботи;

LS_i+1 - пізній термін початку роботи і+1.

Прядок побудови графіка (продовження)

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

Прядок побудови графіка (продовження)

6. Визначити критичний шлях і резерв часу по роботах

Роботи, у яких ранні й пізні терміни початку й закінчення збігаються, називаються критичними.

Критичний шлях утворюється послідовністю критичних робіт.

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

Прядок побудови графіка (продовження)

Резерв часу (F - Float) – це той максимальний час, на який можна відкласти початок некритичної роботи, без зміни тривалості усього проекту.

F_i = LS_i - ES_i;

F_i = LF_i - EF_i;

Задача: Розробка ТЗ на створення інформаційної служби

Задача: Розробка ТЗ на створення інформаційної служби (закінчення)

Втрати робочого часу з різних причин (хвороби, навчання, свята тощо) - 30%.

Визначити:

• коефіцієнт втрат робочого часу,

• тривалість кожної роботи.

• скласти сітьовий графік методом критичного шляху, використовуючи сітки типу “вершини - роботи”.

Тема: Контроль в управлінні проектами

• Сутність та види контролю в управлінні проектами.

• Загальні принципи побудови системи контролю.

• Моніторинг робіт по проекту.

• Вимірювання прогресу і аналіз результатів.

• Прийняття рішень

1. Сутність та види контролю в управлінні проектами

Контроль -

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

Мета контролю -

забезпечення виконання планових показників і підвищення загальної ефективності функцій планування та контролю проекту.

Основні задачі контролю:

• отримання фактичних даних про хід виконання робіт по проекту,

• їх зіставлення з плановими;

• виявлення відхилень.

Для розв’язання цих задач контроль повинен забезпечити:

• Моніторинг - систематичне і планове спостереження за всіма операціями.

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

• Прогнозування наслідків ситуації, що склалась.

• Обґрунтування необхідності прийняття коригувальних впливів.

Предмет контролю:

• факти і події,

• перевірка виконання конкретних рішень,

• з'ясування причин відхилення,

• оцінювання ситуації,

• прогнозування наслідків.

За часовою ознакою та метою проведення розрізняють три види контролю:

1 - попередній,

2 - поточний,

3 – заключний.

Попередній контроль

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

Поточний контроль

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

Основна мета - оперативне регулювання ходу реалізації проекту.

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

Заключний контроль

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

Основне призначення - узагальнення отриманого досвіду для подальшої розробки й реалізації проектів-аналогів і з метою вдосконалення процедур управління.

Іноді контроль ототожнюють з оцінкою.

Між контролем і оцінкою існує тісний зв’язок.

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

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

За контрольні дії несе відповідальність керівник проекту.

Процеси контролю проекту поділяються на основні і допоміжні

Основні:

• загальний контроль змін - координація змін по проекту загалом;

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

Допоміжні:

• контроль змін змісту - контроль за змінами змісту проекту;

• контроль розкладу - контроль за змінами в розкладі проекту;

• контроль витрат - контроль витрат по роботах і змін бюджету проекту;

• контроль якості - відстеження конкретних результатів проекту для визначення їх відповідності встановленим стандартам і прийняття необхідних заходів по усуненню причин, що приводять до порушення якості;

• контроль ризику - реагування на зміну рівня ризику в ході реалізації проекту.

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

• відстеження: збір і документування фактичних даних; визначення в офіційних і неофіційних звітах міри відповідності фактичного виконання запланованим показникам;

• аналіз: оцінка поточного стану робіт і порівняння досягнутих результатів із запланованими; визначення причини і шляхів впливу на відхилення від виконання плану;

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

2. Загальні принципи побудови системи контролю

Вимоги до системи контролю

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

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

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

Принципи побудови ефективної системи контролю

1 - Наявність конкретних планів.

2. - Наявність інформативної системи звітності.

3. - Наявність ефективної системи аналізу фактичних показників і тенденцій.

4 - Регулярне спостереження

5 - Наявність ефективної системи реагування.

1 - Наявність конкретних планів.

Плани повинні бути змістовні, чітко структуровані і фіксовані, з тим щоб забезпечувати основу для контролю.

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

2. - Наявність інформативної системи звітності.

Звіти повинні відображати стан проекту відносно початкових планів на основі єдиних підходів і критеріїв.

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

Результати, представлені в звітах, повинні обговорюватися на нарадах.

3. - Наявність ефективної системи аналізу фактичних показників і тенденцій.

Визначення базової траєкторії, нормативів, стандартів для порівняння з ними поточних значень елементів, що контролюються.

Основними показниками для аналізу є час і вартість.

Для аналізу тенденцій у вартісних і часових оцінках робіт проекту необхідно використати спеціальні звіти.

4 - Регулярне спостереження

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

5 - Наявність ефективної системи реагування.

Завершальним кроком процесу контролю є дії керівництва і направлені на подолання відхилень у ході робіт проекту.

Ці дії можуть бути направлені на усунення виявлених недоліків і подолання негативних тенденцій в рамках проекту.

Однак у ряді випадків може бути потрібний перегляд плану.

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

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

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

Звичайно при управлінні проектом контролюються три основні кількісні характеристики:

• час,

• обсяг робіт,

• вартість.

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

Отже, для створення ефективної системи контролю необхідно:

• ретельно спланувати всі роботи, виконання яких необхідне для завершення проекту;

• точно оцінити час, ресурси і витрати;

• визначити склад і рівень деталізування робіт, що підлягають контролю.

• визначити склад показників, що контролюються.

• встановити форми надання і терміни представлення первинної інформації і аналітичних звітів.

• визначити склад, методи і технології надання аналітичних і графічних звітів.

• призначити відповідальних за повноту, достовірність і своєчасність надання фактичних даних.

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

3. Моніторинг робіт по проекту

Моніторинг -

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

Перший крок у процесі контролю - збір і обробка даних про фактичний стан робіт.

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

Інформація що відображає стан і хід робіт по проекту надходить від:

• членів проектної команди,

• організацій-виконавців,

• незалежних контролерів або

• з планових і звітних документів.

Формальні джерела інформації

• форми обліку часу експлуатації машин і обладнання,

• звіти про виконання заданих обсягів робіт,

• табелі використання робочої сили,

• наряди,

• різні види повідомлень про хід робіт і інші документи.

Можна скласти спеціальні звіти за різними формами:

а) безпосередньо при особистих контактах

б) у табличній формі

в) у графічній формі

Незалежно від форми надання, звітна інформація повинна включати 5 основних елементів:

• кошторисну вартість

• фактичні результати

• результати, що прогнозуються

• відхилення та

• причини, які пояснюють ці відхилення

Обов'язкові вимоги до системи збору інформації для системи контролю:

• точність

• своєчасність

• повнота інформації

• забезпечення єдності інформації для всіх учасників проекту

Розрізняють три ступеня деталізування інформації для досягнення мети контролю:

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

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

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

Методи контролю

• метод простого контролю (контроль в момент закінчення робіт), який також називають методом "0 - 100", оскільки він відстежує тільки моменти завершення детальних робіт. Вважається, що робота виконана тільки тоді, коли досягнуто її кінцевого результату;

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

Іноді зустрічаються дещо модифіковані варіанти методу детального контролю:

• метод 50/50, в якому є можливість обліку деякого проміжного результату для незавершених робіт. Міра завершеності роботи визначається в момент, коли на роботу витрачено 50% бюджету;

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

• регулярний оперативний контроль, який здійснюється на рівні відповідальних виконавців.

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

Критерії для контролю і необхідні дані

4. Вимірювання прогресу й аналіз робіт

Для позначення критеріїв оцінки стану проекту використовувався термін - прогрес.

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

• Якісний прогрес - виконання або невиконання яких-небудь контрольних етапів.

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

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

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

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

Один із варіантів оцінки прогресу - реєстрація його по таких критеріях:

• досягнення контрольних точок (етапів) у виконанні календарного плану проекту (контроль і аналіз термінів закінчення робіт та ін. часових характеристик);

• витрати фінансових коштів;

• витрати ресурсів і ефективність їх використання (блок показників на кожний вид ресурсів);

• величина отриманих прибутків або обсяги виконаних робіт;

• якість (блок якісних характеристик проекту);

• зміст робіт.

Найголовніший показник для контролю і аналізу

терміни закінчення робіт.

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

Фактична інформація використовується для складання нових графіків.

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

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

Після отримання звіту з фактичними даними отримуємо два графіки робіт: базовий графік і поточний графік, який відображає вплив останніх фактичних даних.

Визначення стану проекту означає порівняння цих двох планів.

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

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

Оцінки виконаних і майбутніх обсягів робіт також можуть бути корисні для:

• перегляду оцінок тривалості робіт;

(проводиться тоді, коли на стадії планування зроблені помилки, що неминуче виявиться в звітах про фактичне виконання)

• визначення причин затримок;

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

• вартісного аналізу фактичного стану.

5. Прийняття рішень

Можливі варіанти дій, що найчастіше використовуються у разі відхилення проекту від плану:

• Знайти альтернативне рішення.

• Перегляд вартості.

• Перегляд термінів.

• Перегляд змісту робіт.

• Припинення проекту.

1. Знайти альтернативне рішення.

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

2. Перегляд вартості.

Даний підхід означає збільшення обсягів робіт і призначення додаткових ресурсів.

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

Цей підхід звичайно застосовується у разі необхідності усунення часових затримок проекту.

3. Перегляд термінів.

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

Керівництво проекту може піти на таке рішення у разі жорстких обмежень по вартості.

4. Перегляд змісту робіт.

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

5. Припинення проекту.

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

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

Дякую за увагу!

Тема: Управління змістом проекту (предметною областю

• Сутність управління змістом проекту

• Процеси, пов'язані зі змістом проекту

2.1. Збір вимог

2.2. Визначення змісту

2.3. Створення ієрархічної структури робіт

2.4. Підтвердження змісту

2.5. Управління змістом змісту

Галузі застосування знань з проектного менеджменту

• Управління інтеграцією в проекті;

• Управління змістом проекту;

• Управління строками у проекті;

• Управління вартістю проекту;

• Управління якістю проекту;

• Управління людськими ресурсами проекту;

• Управління ризиками проекту ;

• Управління комунікаціями у проекті;

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

1.Сутність управління змістом проекту

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

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

У контексті проекту термін “зміст” може позначати:

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

і/або

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

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

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

• Збір вимог - процес визначення й документування потреб зацікавлених сторін проекту для досягнення цілей проекту.

• Визначення змісту – процес розробки докладного опису проекту й продукту.

• Створення ієрархічної структури робіт (ІСР) – процес поділу результатів проекту й робіт проекту на більш дрібні елементи, якими легше керувати.

• Підтвердження змісту – процес формалізованого приймання завершених результатів проекту.

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

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

Схвалений докладний опис змісту проекту разом з ІСР і словником ІСР являють собою базовий план проекту по змісту.

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

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

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

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

Виконання змісту проекту порівнюється з планом управління проектом (див. тему Управління інтеграцією).

Виконання змісту продукту порівнюється з вимогами до продукту.

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

2. Процеси, пов'язані зі змістом проекту 2.1. Збір вимог

1.Збір вимог – процес визначення й документування потреб зацікавлених сторін проекту для досягнення цілей проекту.

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

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

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

Вимоги стають базою для розробки ієрархічної структури робіт (ІСР).

Планування вартості, розклади і якості будується на основі цих вимог.

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

Багато організацій розділяють вимоги на категорії «вимоги до проекту» і «вимоги до продукту».

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

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

Збір вимог: входи, інструменти й методи, виходи

Блок-схема даних при зборі вимог

Збір вимог: входи

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

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

Збір вимог: інструменти й методи

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

Звичайно в ході інтерв'ю задають підготовлені й непідготовлені питання й записують відповіді.

Інтерв'ю часто проводяться «один на один», але іноді в них можуть брати участь кілька інтерв'юерів і/або інтерв’юрованих.

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

Збір вимог: інструменти й методи

2. Фокус-Групи

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

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

.

Збір вимог: інструменти й методи

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

Збір вимог: інструменти й методи

Наприклад, в галузі розробки програмного забезпечення використовуються семінари за участю модератора за назвою «Спільна розробка (або проектування) додатків» (Joint Application Development (or Design), JAD).

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

Збір вимог: інструменти й методи

Ще один приклад семінару за участю модератора, що допомагає визначити критично важливі характеристики для просування нового продукту - «Розгортання функції якості» (Quality Function Deployment, QFD).

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

QFD починається зі збору потреб замовника, що також називається «думкою замовника» (Voice of the Customer, VOC). Потім ці потреби об'єктивно сортуються, і між ними розставляються пріоритети, а також установлюються цілі для їхнього досягнення.

Збір вимог: інструменти й методи

4. Групові творчі методи

Для виявлення вимог до проекту й продукту можуть організовуватися різні групові заходи, наприклад:

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

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

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

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

• Діаграма подібності. Даний метод дозволяє розсортувати по групах велику кількість ідей для їхнього огляду й аналізу.

Збір вимог: інструменти й методи

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

Існує безліч методів прийняття групового рішення, наприклад:

• Одноголосність. Усі погоджуються з певним напрямком дій.

• Більшість голосів. Підтримка з боку більше 50 % членів групи.

• Відносна більшість голосів. Вибирається рішення самого численного блоку в групі, навіть якщо не набрано більшість голосів.

• Диктатура. Одна людина приймає рішення за всю групу.

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

Збір вимог: інструменти й методи

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

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

Збір вимог: інструменти й методи

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

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

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

Збір вимог: інструменти й методи

8. Прототипи

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

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

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

Збір вимог: виходи

1 Документи по вимогах описують, яким чином окремі вимоги задовольняють бізнес- потреби проекту.

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

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

Збір вимог: виходи

Елементи документів по вимогах можуть містити в собі, серед іншого:

• бізнес-потребу або можливість, яку необхідно використовувати, з описом обмежень нинішньої ситуації й того, чому необхідна реалізація проекту;

• цілі бізнесу й проекту для можливості контролю;

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

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

• вимоги до якості;

• критерії приймання;

• бізнес-правила, що описують керівні принципи організації;

• вплив на інші відділи організації, такі як центр обробки викликів, відділ продажів, технологічні групи;

• вплив на інші органи усередині й за межами виконуючої організації;

• вимоги до технічної підтримки й навчання;

• допущення й обмеження відносно вимог.

Збір вимог: виходи

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

Збір вимог: виходи

Елементи плану управління вимогами можуть містити в собі, серед іншого:

• порядок планування, відстеження й складання звітів про дії відносно вимог;

• дії по управлінню конфігурацією, такі як порядок ініціювання змін вимог до продукту, послузі або результату, порядок аналізу впливу, його виявлення, відстеження й складання звітів про нього, а також рівні повноважень, необхідні для схвалення даних змін;

• процес розміщення пріоритетів вимог;

• використовувані показники продукту й обґрунтування їхнього використання;

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

Збір вимог: виходи

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

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

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

Збір вимог: виходи

Цей процес містить у собі, не обмежуючись тільки відстеженням, такі елементи:

• вимоги до бізнес-потреб, можливостей, задач і цілей;

• вимоги до цілей проекту;

• вимоги до змісту проекту / результатів ІСР;

• вимоги до проектування продукту;

• вимоги до розробки продукту;

• вимоги до стратегії й сценаріїв перевірки;

• деталізацію вимог від високого рівня до більш детальних вимог.

Збір вимог: виходи

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

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

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

2.2. Визначення змісту

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

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

Існуючі ризики, допущення й обмеження аналізуються на предмет повноти; додаткові ризики, допущення й обмеження додаються в міру необхідності.

Визначення змісту: входи, інструменти й методи, виходи

Блок-схема даних при визначенні змісту

Визначення змісту: входи

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

2. Документи по вимогах Описані вище

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

- правила, процедури й шаблони опису змісту проекту;

- проектні архіви з попередніх проектів;

- знання, накопичені в попередніх фазах або проектах.

Визначення змісту: інструменти й методи

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

- інші підрозділи в рамках організації;

- консультантів;

- зацікавлені сторони проекту, у тому числі замовники або спонсори;

- професійні й технічні асоціації;

- промислові групи;

- експерти з окремих питань.

Визначення змісту: інструменти й методи

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

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

4. Семінари за участю модератора Описані раніше.

Визначення змісту: виходи

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

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

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

Визначення змісту: виходи

Детальний опис змісту проекту або безпосередньо, або за допомогою посилань на інші документи містить у собі:

- Опис змісту продукту. Послідовно уточнює характеристики продукту, послуги або результату, описаного в Статуті проекту або в документах по вимогах.

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

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

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

Визначення змісту: виходи

(продовження)

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

• Допущення проекту. Перераховуються й описуються конкретні допущення проекту, пов'язані зі змістом проекту, і потенційний вплив цих допущень у випадку, якщо вони виявляться помилковими. Команди проектів часто виявляють, документують і підтверджують допущення в рамках проведеного ними процесу планування. Інформація про допущення може бути зазначена в описі змісту проекту або в окремому журналі.

Визначення змісту: виходи

2. Оновлення документів проекту

Документи проекту, які можуть бути оновлені, містять у собі, серед іншого:

- Реєстр зацікавлених сторін проекту;

- документи по вимогах;

- матрицю відстеження вимог.

2.3. Створення ієрархічної структури робіт

Створення ієрархічної структури робіт (ІСР) - це процес поділу результатів проекту й робіт із проекту на більш дрібні елементи, якими легше управляти.

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

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

Заплановані роботи містяться в елементах ІСР самого нижнього рівня, які називаються «пакетами робіт».

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

У контексті ІСР «робота» означає продукти або результати робіт, що є результатами дій, але не самі дії.

Створення ІСР: входи, інструменти й методи, виходи

Блок-схема даних при створенні ІСР

Створення ІСР: входи

1. Опис змісту проекту Описано раніше.

2. Документи по вимогах Описані раніше.

3. Активи процесів організації, що можуть впливати на процес створення ІСР, містять у собі, серед іншого:

- правила, процедури й шаблони для ІСР;

- проектні архіви з попередніх проектів;

- знання, накопичені в попередніх проектах.

Створення ІСР: інструменти й методи

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

Створення ІСР: інструменти й методи

Декомпозиція всієї сукупності робіт із проекту до пакетів робіт звичайно містить у собі такі дії:

- визначення й аналіз результатів і відповідних робіт;

- структурування й організація ІСР;

- розбивка верхніх рівнів ІСР на деталізовані елементи більш низьких рівнів;

- розробку й присвоєння ідентифікаційних кодів елементам ІСР;

- перевірку необхідності й достатності ступеня декомпозиції.

Структура ІСР може бути створена в різних формах, наприклад:

- як перший рівень декомпозиції використовуються фази життєвого циклу проекту, на другому рівні розташовані результати, що належать до проекту й продукту;

- як перший рівень декомпозиції використовуються основні результати;

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

Зразок ієрархічної структури робіт

Зразок ієрархічної структури робіт, організованої по фазах

Для декомпозиції елементів ІСР верхнього рівня потрібний поділ робіт кожного результату або підпроекту на основні елементи, де елементи ІСР являють собою продукти, що піддаються перевірці, послуги або результати.

ІСР може бути структурована у вигляді схеми, організаційної діаграми, причинно-наслідкової діаграми або іншим методом.

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

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

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

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

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

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

Цей метод іноді називають «плануванням методом хвилі, що набігає».

ІСР представляє всі роботи продукту й проекту, включаючи роботи з управління проектом. Загальний зміст робіт на самих нижніх рівнях повинен скручуватися в більш високі рівні, щоб нічого не було пропущено, і не виконувалася зайва робота. Іноді це називають «правилом 100 %».

Практичний стандарт PMI по ієрархічних структурах робіт (the Practice Standard for Work Breakdown Structures - Second Edition) містить рекомендації зі створення, розробки й застосування ієрархічних структур робіт. Цей стандарт містить конкретні галузеві приклади шаблонів ІСР, які можуть бути адаптовані до конкретних проектів у певних прикладних областях.

Створення ІСР: виходи

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

Створення ІСР: виходи

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

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

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

Створення ІСР: виходи

2. Словник ІСР – це документ, генерований процесом створення ієрархічної структури робіт (ІСР) і який її доповнює.

Словник ІСР надає більш детальні описи елементів ІСР, включаючи пакети робіт і контрольні рахунки.

Створення ІСР: виходи

Інформація в словнику ІСР містить у собі, серед іншого:

- ідентифікатор плану рахунків;

- опис робіт;

- відповідальну організацію;

- список контрольних подій розкладу;

- пов'язані заплановані операції;

- необхідні ресурси;

- оцінки вартості;

- вимоги до якості;

- критерії приймання;

- технічні посилання;

- контрактну інформацію.

Створення ІСР: виходи

3. Базовий план по змісту є елементом плану управління проектом.

Елементи базового плану по змісту містять у собі:

- Опис змісту проекту - містить у собі опис змісту продукту, результати проекту й визначає критерії приймання продукту користувачем.

- ІСР - визначає кожний результат і декомпозицію результатів на пакети робіт.

- Словник ІСР - містить докладний опис робіт і технічну документацію по кожному елементу ІСР.

Створення ІСР: виходи

4. Оновлення документів проекту

Документи проекту, які можуть бути оновлені, містять у собі документи по вимогах, але не обмежуються тільки ними. Якщо в результаті процесу створення ІСР з'являються схвалені запити на зміни, може знадобитися коректування документів по вимогах, щоб включити в них схвалені зміни.

2.4. Підтвердження змісту

Підтвердження змісту - процес формалізованого приймання завершених результатів проекту.

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

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

Контроль якості, як правило, проводиться до підтвердження змісту, однак ці два процеси можуть виконуватися й паралельно.

Підтвердження змісту: входи, інструменти й методи, виходи

Блок-схема даних при підтвердженні змісту

Підтвердження змісту: входи

1. План управління проектом, описаний у темі Управління інтеграцією проекту містить базовий план по змісту.

Елементи базового плану по змісту містять у собі:

- Опис змісту проекту. Опис змісту проекту містить у собі опис змісту продукту, результати проекту й визначає критерії приймання продукту користувачем.

- ІСР. ІСР визначає кожний результат і декомпозицію результатів на пакети робіт.

- Словник ІСР. Словник ІСР містить докладний опис робіт і технічну документацію по кожному елементу ІСР.

Підтвердження змісту: входи

2. Документи по вимогах У документах по вимогах перераховані всі вимоги до проекту, продукту, технічні й інші види вимог, які повинні бути представлені для проекту й продукту, а також критерії їхнього приймання. Документи по вимогах описані раніше

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

4. Підтверджені результати, завершені й перевірені на правильність у процесі контролю якості.

Підтвердження змісту: інструменти й методи

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

Інспекції іноді називаються «перевірками», «перевірками продукту», «аудитами» або «наскрізним контролем».

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

Підтвердження змісту: виходи

1. Прийняті результати

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

Підтвердження змісту: виходи

2. Запити на зміни

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

Підтвердження змісту: виходи

3. Оновлення документів проекту

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

2.5. Управління змістом

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

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

Управління змістом проекту використовується також для управління фактичними змінами в міру їхньої появи; воно інтегровано в інші процеси управління.

Некеровані зміни часто називають «зрушенням змісту проекту».

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

Управління змістом: входи, інструменти й методи, виходи

Блок-схема даних при управлінні змістом

Управління змістом: входи

1. План управління проектом, розглянутий в темі Управління інтеграцією проекту, містить таку інформацію, використовувану для управління змістом:

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

- План управління змістом. План управління змістом описує, як буде здійснюватися управління змістом проекту і його контроль.

- План управління змінами. План управління змінами визначає процес управління змінами проекту.

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

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

Управління змістом: входи

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

3. Документи по вимогах (Розглянуто раніше)

4. Матриця відстеження вимог (Розглянуто раніше).

5. Активи процесів організації, які можуть впливати на процес управління змістом, містять у собі, серед іншого:

- існуючі формальні й неформальні правила, процедури й провідні вказівки, пов'язані зі змістом;

- використовувані методи моніторингу й звітності.

Управління змістом: інструменти й методи

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

Управління змістом: виходи

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

2. Оновлення активів процесів організації. Активи процесів організації, які можуть бути оновлені, містять у собі, серед іншого:

- причини відхилень;

- обрані коригувальні впливи й причини;

- інші види знань, накопичених у ході управління змістом проекту.

Управління змістом: виходи

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

Запити на зміни обробляються з метою проведення перевірки й представлення відповідно до процесу здійснення загального управління змінами (див. тему Управління інтеграцією проекту).

Управління змістом: виходи

4. Оновлення плану управління проектом включає:

- Оновлення базового плану по змісту. Якщо схвалені запити на зміни впливають на зміст проекту, то опис змісту, ІСР і словник ІСР переглядаються й випускаються заново, щоб відбити схвалені зміни.

- Оновлення інших базових планів. Якщо схвалені запити на зміни впливають на зміст проекту, то відповідний базовий план за вартістю й базовими розкладами переглядаються й випускаються заново, щоб відбити схвалені зміни.

Управління змістом: виходи

5. Оновлення документів проекту

Документи проекту, які можуть бути оновлені, містять у собі, серед іншого:

- документи по вимогах;

- матрицю відстеження вимог.

Дякую за увагу!

Тема: Розробка системи управління і забезпечення якості програмних продуктів у відповідності з ISO-9000

• Загальна характеристика стандартів ISO-9000 із забезпечення якості продукції та послуг.

• Необхідність розробки системи управління по забезпеченню якості ПП.

• Основні положення стандарту ISO-9000-3

1. Загальна характеристика стандартів ISO-9000 із забезпечення якості продукції та послуг

ISO-9000 - стандарт на якість проектування, розробки, виготовлення та післяпродажного обслуговування

Основна ідея ISO 9000: система якості припускає побудову такої структури управління процесом виробництва, що гарантує випуск якісного продукту в будь-який момент, поки система діє.

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

ISO -9000, не є стандартом якості власне для товарів і послуг, що виробляє підприємство.

Схема “покриває” всі етапи виробничого циклу випуску товарів/послуг:

• закупку сировини і матеріалів;

• проектування;

• створення і доставку товарів;

• обслуговування клієнтів;

• навчання персоналу.

Власне ISO-9000 регламентує два ключових моменти:

• наявність і документування відповідного бізнес-процесу;

• вимірювання його якості.

Структура ISO 9000

Це — набір з п'яти підгруп: 9000, 9001, 9002, 9003 і 9004, виданий Міжнародною організацією зі стандартизації зі штаб-квартирою в Женеві, що сама по собі є федерацією національних установ по роботі зі стандартами, — таких як Американський національний інститут стандартів.

В основному текст ISO 9000 розроблений Британським інститутом стандартів, який взяв на себе відповідальність щодо просування стандартів на бізнес-процеси в Європейському Союзі.

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

ISO -9000 це серія стандартів

В основу стандартів серії ISO 9000 лягла філософія підходів CPI (Continuous Process Improvement) і TQM (Total Quality Management).

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

Загальна структура документації на систему якості визначена стандартами серії ISO 9000 і звичайно представляється у вигляді так званої піраміди якості.

Піраміда якості

Є чотири частини ISO-9000:

• 9000-1 - настанови щодо вибору і застосування

• 9000-2 - настанови щодо застосування ISO -9001, ISO -9002 та ISO -9003

• 9000-3 - настанови щодо застосування ISO -9001 до розроблення, поставляння та супроводження ПЗ.

• 9000-4 - настанови щодо управління програмною надійністю.

ISO-9001- системи якості - є найбільш повним

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

• Цей стандарт специфікує модель забезпечення якості на всіх етапах життєвого циклу товару/послуги.

ISO-9002 та ISO-9003

• ISO-9002 - системи якості - модель забезпечення якості в процесі виробництва, монтажу та обслуговування.

• ISO-9003 - системи якості - модель забезпечення якості в процесі контролю готової продукції та її випробування.

ISO-9004 має чотири частини:

• ISO-9004-1 - управління якістю та елементи системи якості: Частина 1: настанови

• ISO-9004-2 - управління якістю та елементи системи якості: Частина 2: настанови щодо послуг.

• ISO-9004-3 - управління якістю та елементи системи якості: Частина 3: настанови щодо перероблюваних матеріалів.

• ISO-9004-4 - управління якістю та елементи системи якості: Частина 4: настанови щодо поліпшення якості.

Для процесу розробки програм використовується стандарт ISO 9001, що передбачає проектування в процесі виробництва

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

Спеціально для забезпечення процесів розробки програмних систем організацією ISO, розроблене керівництво ISO 9000-3, що формулює вимоги моделі якості ISO 9001 до організації процесу розробки програмного забезпечення.

Отже, для оцінювання якості процесу розробки у власній організації або в організації підрядників можуть використовуватися вимоги керівництва ISO 9000-3.

Нині повсюдно вводиться у використання версія стандарту 2000 року, у якому в основу ставиться управління процесом, однак у даній версії стандарту специфіка, пов'язана з розробкою ПЗ відсутня.

Хоча стандарти ISO розроблялися за урядової підтримки, сертифікація за ISO 9000 — справа цілком добровільна

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

Основною причиною сертифікації є те що закордонні компанії вимагають наявності сертифіката від своїх постачальників.

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

Сертифікація підприємства за стандартом ISO-9000 включає такі три етапи:

• застосування стандартів на підприємстві, яке полягає в розробці та введенні в дію низки заходів, пропонованих стандартами

• проведення власне сертифікації акредитованими ISO – органами (спеціальна фірма-реєстратор здійснює інспекцію компанії)

• періодичні (два рази на рік) перевірки підприємства на наслідування (відповідність) стандартів

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

В іншому випадку реєстрація може бути визнана недійсною.

2. Необхідність розробки системи управління по забезпеченню якості ПП

Програмні продукти стали визнавати як продукцію технічного призначення з середини 80-х років минулого століття

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

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

• Чітка організація спільної роботи команди розробників;

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

Система якості є організаційним стрижнем створення оптимальних умов для продуктивної праці фахівців.

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

Ці методи варіюються від компанії до компанії, але основні їх положення єдині для всіх і визначаються стандартом ISO-9001 і ISO-9000-3.

Останній включає усі положення загального стандарту ISO-9001, а також необхідні доповнення до них, що стосуються розробки, поставки й обслуговування ПЗ.

ISO-9001 встановлює вимоги до системи якості постачальника і дозволяє оцінити його можливості з проектування та постачання продукції, на відповідність цим вимогам.

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

3. Основні положення стандарту ISO-9000-3

Основні поняття, якими оперує стандарт ISO-9000-3:

Продукт – результат дії або процесів;

Програмний продукт - набір комп’ютерних програм, процедур і , можливо, пов’язаних з ними документів та даних;

Елемент програмного забезпечення - (software item) - будь-яка частина програмного продукту, що ідентифікована;

Основа (baseline) - формально узгоджена версія елемента конфігурації, зафіксована у певний момент часу на протязі життєвого циклу елемента конфігурації;

Розробка (development) - процес життєвого циклу ПП, що охоплює аналіз вимог, проектування, кодування, інтеграцію, тестування, установку та підтримку;

Модель життєвого циклу - (life cycle model) - базова модель, яка включає процеси, дії та задачі, що мають місце у розробці, функціонуванні та супроводі ПП і охоплюють увесь життєвий цикл системи від визначення вимог до завершення;

Етап - певний сегмент роботи;

Регресійне тестування - (regression testing)- тестування , що дозволяє упевнитися в тому, що зміни, внесені з метою виправлення виявлених помилок , не породили нових;

Реплікація - (replication)- копіювання програмного продукту з одного носія на інший.

Стандарт впроваджується на добровільній основі і зобов’язує підприємства строго регламентувати такі аспекти виробничої діяльності:

• Відповідальність керівництва;

• Система якості;

• Аналіз контракту;

• Управління проектуванням;

• Управління документацією і даними;

• Закупки;

• Ідентифікація та відслідковування продукції;

• Управління процесами;

• Контроль і випробування;

• Управління продукцією, що не відповідає вимогам;

• Коригувальні та запобіжні дії;

• Завантажувально-розвантажувальні роботи, зберігання, упаковка, консервація та поставка;

• Управління реєстрацією даних про якість;

• Внутрішній аудит якості;

• Підготовка кадрів;

• Обслуговування.

1. Відповідальність керівництва

На керівництво компанії–постачальника покладається задача визначення політики та зобов’язань з якості.

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

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

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

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

2. Система якості

Компанія-постачальник повинна розробити, документально оформити та підтримати в робочому стані систему якості як засіб, що забезпечує відповідність продукції вимогам стандарту ISO-9001.

Система якості передбачає наявність:

• Інструкції з якості, яка включає методики системи якості компанії;

• Опис структури документації , що використовується в системі якості.

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

2. Система якості (закінчення)

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

• формулює вимоги до якості,

• описує модель ЖЦ,

• задає критерії початку і кінця кожного етапу проекту,

• визначає типи аналізу, тестування та інших дій з перевірки та затвердження ПП,

• визначає процедури управління конфігурацією.

Планування якості “настроює” систему якості на певний проект.

3. Аналіз контракту

Система якості передбачає певні дії з аналізу контракту.

ПП може розроблятись:

• За контрактом із замовником;

• Як комерційний продукт для певного сектора ринку;

• Як система, вмонтована в апаратне забезпечення;

• Як система підтримки бізнес-процесів постачальника.

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

3. Аналіз контракту (продовження)

Постачальник повинен попередньо проаналізувати заявку на тендер, контракт чи замовлення (до надання заявки або укладання контракту).

Це дозволить гарантувати адекватне визначення вимог до проекту і можливість виконати контракт.

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

3. Аналіз контракту (закінчення)

Наприклад, можуть аналізуватися:

• узгоджені із замовником критерії прийняття або відмови від готової системи;

• термінологія;

• ступінь участі замовника у спільній роботі;

• відповідальність замовника за надання певних даних або обладнання;

• зобов'язання замовника перед постачальником із заміни на нові версії системи або зобов'язання постачальника підтримувати старі версії, тощо.

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

4. Управління проектуванням

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

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

Цей розділ стандарту IS0 9000-3 містить вказівки з таких основних дій в процесі розробки:

• аналіз вимог до проекту;

• проектування архітектури систем;

• детальне проектування та кодування;

• планування розробки.

4. Управління проектуванням (продовження)

Проект розробки ПП організується за певною моделлю ЖЦ.

ISO 9000-3 не визначає, якою повинна бути модель ЖЦ, це залежить від специфіки задачі.

Стандарт наводить лише визначення моделі ЖЦ як сукупності процесів.

Модель показує, коли ці процеси і як підключаються до реалізації проекту.

4. Управління проектуванням (продовження)

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

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

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

4. Управління проектуванням (продовження)

Управління проектом повинне враховувати такі аспекти як:

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

• досвід попередніх проектів;

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

• вимоги до захисту та безпеки;

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

4. Управління проектуванням (продовження)

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

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

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

4. Управління проектуванням (продовження)

Проектування та розробка повинні ретельно плануватись.

План розробки ПП повинен формулювати задокументовані дії з:

• аналізу вимог до систем;

• проектування;

• кодування;

• інтеграції;

• тестування;

• встановлення;

• підтримки.

4. Управління проектуванням (продовження)

План повинен включати також такі пов’язані з основним процесом плани :

• забезпечення якості;

• управління ризиками;

• управління конфігурацією;

• плани інтеграції;

• плани установки;

• плани навчання співробітників та ін.

4. Управління проектуванням (продовження)

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

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

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

• необхідність брати участь в проекті,

• зобов'язання по своєчасному наданню потрібної інформації.

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

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

4. Управління проектуванням (продовження)

Вхідні проектні вимоги до продукції.

Вимоги формулює замовник, а постачальник аналізує, наскільки вони адекватні.

Неповні, двозначні або суперечливі вимоги є предметом урегулювання з особами, відповідальними за їх висунення.

У певних ситуаціях, за обопільною згодою, специфікацію вимог може провести постачальник.

Вихідні проектні дані також оформляються документально, причому так, щоб їх можна було перевірити і підтвердити відносно вхідних проектних вимог.

Вихідні дані проекту програмної системи можуть включати:

• специфікацію архітектури проекту,

• детальну специфікацію проекту,

• початкові коди,

• керівництво користувача.

4. Управління проектуванням (продовження)

Постачальник програмного продукту повинен планувати і провести офіційний, документально оформлений аналіз результатів проектування.

Міра формальності та строгість процесів аналізу відповідають складності системи, що розробляється і ступеню ризику, пов'язаного з її використанням.

Аналіз проектування стосується таких аспектів:

• можливість виконати проект,

• задоволення вимог захисту і безпеки системи,

• виконання правил програмування і

• можливість тестування.

4. Управління проектуванням (продовження)

На певних стадіях проектування проводиться перевірка відповідності вихідних даних вхідним вимогам.

Така верифікація проекту може включати аналіз вихідних даних, демонстрації, в тому числі за допомогою прототипів і моделювання, або тестування.

Тільки перевірені вихідні проектні дані затверджуються для остаточного прийому і подальшого використання.

Усі виявлені в процесі перевірки проблемні ситуації повинні адекватно розв'язуватися.

4. Управління проектуванням (закінчення)

Перш ніж система буде передана замовнику, постачальник повинен затвердити систему на відповідність заданому призначенню.

Замовнику може бути переданий тільки затверджений програмний продукт.

Всі зміни і модифікації проекту повинні бути ідентифіковані, документально оформлені, проаналізовані і затверджені до їх реалізації.

Постачальник встановлює і підтримує в робочому стані процедури управління змінами в проекті, які можуть виникнути на будь-якій стадії життєвого циклу системи.

5. Управління документацією і даними

Постачальник повинен розробити і підтримувати в робочому стані документовані процедури управління всіма специфікаціями і даними, що відносяться до вимог стандарту ISO 9001, включаючи і документи зовнішнього походження (стандарти і креслення споживача).

Документи і дані можуть розміщуватися на будь-якому паперовому або електронному носієві.

5. Управління документацією і даними (закінчення)

Для реалізації контролю за документами і даними можуть використовуватися процедури управління конфігурацією.

У сферу дії цього розділу стандарту попадають:

• контракти, що специфікують вимоги до продукту;

• документи, що описують систему якості,

• документи що містять різні плани постачальника і взаємодію постачальника зі споживачем;

• документи і дані, що описують конкретний програмний продукт.

6. Закупівля

Постачальнику ставиться в обов'язок розробити й підтримувати в робочому стані документовані процедури, що гарантують відповідність закупленої продукції встановленим вимогам.

При розробці, постачанні, інсталяції та супроводі програмних продуктів як закупівля може фігурувати:

• комерційне ПЗ;

• розробка за субконтрактом;

• комп'ютерне і комунікаційне апаратне забезпечення;

• засоби розробки;

• персонал, що наймається за контрактом;

• сервіс підтримки і супроводу;

• навчальні курси і матеріали.

7. Ідентифікація і відслідковування продукції

Постачальник повинен встановити і підтримувати в робочому стані процедури ідентифікація елементів програмного забезпечення на всіх етапах, від специфікації вимог до розробки, реплікації і доставки.

Протягом життєвого циклу системи повинні працювати процедури відстеження компонентів складових частин програмного забезпечення.

7. Ідентифікація і відслідковування продукції (продовження)

Процедури ідентифікації і відстеження реалізовуються в системі конфігураційного управління, яка визначається як дисципліна управління, відповідно до якої здійснюється технічне й адміністративне керівництво розробкою і підтримкою життєвого циклу елементів конфігурації, включаючи елементи програмного забезпечення.

Ця дисципліна застосовна також до документації і апаратного забезпечення, що стосується програмного продукту, який розробляється.

Міра використання конфігураційного управління залежить від розміру і складності проекту, а також від рівня пов'язаного з ним ризику.

7. Ідентифікація і відслідковування продукції (продовження)

Одна з цілей конфігураційного управління задокументувати і забезпечити повну видимість поточної конфігурації продукту і ступеня відповідності початковим вимогам. Інша мета надати кожному, хто працює над проектом, точну інформацію на будь-якому етапі життєвого циклу.

Система конфігураційного управління надає, зокрема, можливість ідентифікувати версію кожного елемента програмного забезпечення, управляти одночасно модифікацією даного елемента двом або більше незалежним розробникам, координувати модифікацію безлічі продуктів і т.д.

7. Ідентифікація і відслідковування продукції (закінчення)

У визначенні конфігурації беруть участь:

• структура продукту і вибір елементів конфігурації,

• друкована документація і комп'ютерні файли,

• угоди по присвоєнню імен, встановленню конфігураційних основ.

8. Управління процесами

Постачальник повинен визначити і спланувати процеси розробки, установки й обслуговування продукту.

Процес розробки програмної системи організований як безліч процесів, що перетворюють початкові вимоги на програмний продукт (див. розділ стандарту "Управління проектуванням").

Даний розділ стандарту оговорює вимоги до реплікації, доставки й інсталяції програмних продуктів.

9. Контроль і випробування

Постачальник повинен розробити і підтримувати в робочому стані документовані процедури контролю і випробувань для перевірки виконання встановлених вимог до продукції.

Контроль і випробування, простіше кажучи, тестування програмного продукту може потребуватися на кількох рівнях, від окремих елементів ПЗ до закінченої системи.

Існує кілька підходів до тестування, які даним стандартом не оговорюються. Вибір підходу залежить від постачальника.

Обсяг тестування, міра контролю за середовищем випробувань, вхідні і вихідні дані тестів можуть варіюватися в залежності від вибраного підходу, складності системи і пов'язаних з нею ризиків.

9. Контроль і випробування (продовження)

Постачальник повинен визначити, задокументувати і періодично аналізувати план:

• тестування модулів,

• тестування інтеграційних процесів,

• системи загалом і

• тестування для остаточного приймання.

У процесі розробки постачальник повинен контролювати і випробовувати продукцію відповідно до програми якості.

9. Контроль і випробування (продовження)

Всі види остаточного контролю і тестування також потрібно провести відповідно до цієї програми, щоб пересвідчитися, що готовий продукт відповідає встановленим вимогам.

Для виробника програмних систем це означає, що перш ніж продукт буде переданий замовнику, постачальник повинен офіційно підтвердити, що продукт працює відповідно до заданого призначення, в умовах, схожих з тими, в яких буде застосовуватися система.

Будь-які відмінності між середовищем затвердження системи і фактичним середовищем її використання, а також ризик, пов'язаний з цими відмінностями, повинні бути виявлені і зареєстровані на якомога більш ранніх етапах життєвого циклу.

9. Контроль і випробування (закінчення)

Крім того для остаточного затвердження, замовник може провести тестування при прийманні вже затвердженого продукту.

При цьому він буде визначати, відповідає чи ні продукт раніше узгодженим критеріям.

Замовник може передати повноваження на проведення таких тестів постачальнику або третій особі.

Постачальник і замовник повинні узгодити між собою методи розв'язання проблем, виявлених в ході процедури приймання.

10. Управління невідповідною продукцією

Постачальник повинен розробити і підтримувати в робочому стані документовані процедури, які гарантують, що продукт, невідповідний встановленим вимогам, не буде ненавмисно використовуватися або встановлюватися.

При розробці програмного забезпечення для ізоляції його невідповідних елементів може зажадатися вивести їх з середовища розробки або тестування в окреме середовище.

У разі розробки вбудованого ПЗ можлива ізоляція апаратного компонента, що містить невідповідний прикладний елемент.

11. Коригувальні та запобіжні дії

Постачальник повинен розробити і підтримувати в робочому стані документовані процедури по виконанню коригувальних і запобіжних дій.

Будь-яка така дія по усуненню причин фактичних або потенційних невідповідностей повинна бути адекватною проблемам і враховувати ступінь ризику.

11. Коригувальні та запобіжні дії

Якщо коригувальні дії безпосередньо впливають на програмний продукт, може бути підключений процес конфігураційного управління для контролю за змінами.

Початкові дані для запобіжних дій може дати аналіз базових причин невідповідностей, що виникли.

12. Завантажувально-розвантажувальні роботи, зберігання, упаковка, консервація і постачання

Цей розділ стандарту ISO 9000-3 конкретизує специфіку можливих пошкоджень програмного продукту, засобу зберігання, методи упаковки, консервації і постачання ПЗ.

Пошкодження програмного забезпечення означає зміну його інформаційного вмісту.

Стандарт оговорює, що зараження програмного продукту комп'ютерним вірусом вважається пошкодженням ПЗ.

Заходи захисту від вірусів описуються в керівництві по реплікації.

12. Завантажувально-розвантажувальні роботи, зберігання, упаковка, консервація і постачання (продовження)

Термін "зношення" не застосується до тієї інформації, яку містить програмна система.

Однак зноситися може носій, на якому зберігається система, і постачальник повинен вжити відповідних заходів обережності.

Постачальник повинен визначити систему зберігання елементів програмного забезпечення, управління доступом до цих елементів і підтримки версій продукту.

12. Завантажувально-розвантажувальні роботи, зберігання, упаковка, консервація і постачання (закінчення)

Для того щоб підтримати цілісність системи і забезпечити базис для управління змінами, елементи програмного забезпечення потрібно зберігати в середовищі, яке здатне захистити їх від несанкціонованих змін і забезпечує контрольований доступ і вибірку основноїтаі будь-яких інших копій.

Крім того, повинні бути враховані умови зберігання носіїв, особливо можливий електромагнітний і електростатичний вплив.

13. Управління реєстрацією даних про якість

Постачальник розробляє і підтримує в робочому стані документовані процедури ідентифікації, збору, індексування, доступу, складання картотеки, зберігання, ведення і вилучення зареєстрованих даних про якість.

Приклади таких даних:

• документовані результати тестування,

• повідомлення про проблеми,

• запити про зміни,

• анотовані документи,

• результати аналізу,

• протоколи різних засідань,

• аудиторські повідомлення.

13. Управління реєстрацією даних про якість (закінчення)

У тому випадку, якщо дані про якість зберігаються в електронному вигляді, при визначенні часу збереження і доступу до даних необхідно враховувати ступінь можливої деградації електронних копій і доступність пристроїв і програмних компонентів для доступу до даних.

14. Внутрішній аудит якості

Постачальник розробляє і підтримує в робочому стані документовані процедури планування і проведення внутрішніх перевірок якості, які дозволять пересвідчитися, що діяльність в галузі якості та її результати відповідають запланованим заходам, а також підтвердити ефективність системи якості.

14. Внутрішній аудит якості (закінчення)

Внутрішні перевірки якості плануються на основі статусу і важливості діяльності, що перевіряється.

Внутрішній аудит повинен проводитися персоналом, не залежним від осіб, які несуть відповідальність за діяльність, що перевіряється.

Внутрішній аудитор аналізує узгодженість програми якості для конкретного проекту із загальною системою якості, прийнятою в організації.

15. Підготовка кадрів

Постачальник повинен розробити і підтримувати в робочому стані документовані процедури визначення потреб у підготовці кадрів, а також забезпечувати підготовку всього персоналу, що виконує роботи, які впливають на якість.

Персонал повинен бути кваліфікований на основі відповідної освіти, підготовки і досвіду.

15. Підготовка кадрів (закінчення)

Визначення задач навчання повинно ув'язуватися з тими інструментальними засобами, методами і комп'ютерними ресурсами, які будуть використовуватися в розробці програмного продукту і управлінні ним.

Можливо, буде також потрібне спеціальне навчання в тій галузі, з якою пов'язаний програмний продукт, що розробляється.

16.Обслуговування

Що стосується програмного забезпечення, то під обслуговуванням тут розуміють супровід системи (maintenance) і підтримку замовників (customer support).

Підтримка замовників обговорюється в стандарті ISO 9000-2.

16.Обслуговування (продовження)

Супровід системи, як правило, включає в себе:

• виявлення й аналіз невідповідностей в програмній системі, що викликають збої в її роботі;

• виправлення програмних помилок;

• модифікацію інтерфейсів, що необхідно у разі внесення доповнень або змін в апаратуру;

• функціональне розширення або поліпшення продуктивності

16.Обслуговування (продовження)

Усі дії по супроводу повинні проводитися і контролюватися відповідно до плану супроводу, який заздалегідь визначається й узгоджується постачальником і замовником.

На закінчення залишається лише додати.

Загальні положення стандарту по забезпеченню якості лише верхівка айсберга.

За межами залишаються деталі тих процесів, які реально забезпечують якість кінцевого продукту.

Але це, як правило, "ноу-хау" компанії.

Дякую за увагу!

Управління вартістю проектів

1. Місце функції управління вартістю в методології проектного менеджменту

2. Сутність управління вартістю

3. Оцінювання вартості

4. Визначення бюджету

5. Управління вартістю

1.Місце функції управління вартістю в методології проектного менеджменту

П”ЯТЬ ГРУП ПРОЦЕСІВ, ЩО ОПИСУЮТЬ ФУНКЦІЮ УПРАВЛІННЯ ВАРТІСТЮ В ПРОЕКТАХ:

1.процеси ініціалізації  визначення рівня витрат по проекту, складу й структури ресурсів, необхідних для початку проекту або фази проекту, а також вибір джерел надходження коштів, механізму їхнього розподілу й процедур документування (фінансової звітності) по проекту

2.процеси планування  розробка й постійна підтримка робочої схеми фінансування завдань проекту, здійснення механізму оптимального перерозподілу ресурсів по проекту затверджених початковим планом

П”ЯТЬ ГРУП ПРОЦЕСІВ, ЩО ОПИСУЮТЬ ФУНКЦІЮ УПРАВЛІННЯ ВАРТІСТЮ В ПРОЕКТАХ (закінчення):

3.процеси виконання  координація ресурсів, робіт і процедур їхнього здійснення для виконання початкового плану проекту й наступних відкоригованих планів, підтримка спадковості фінансових планів

4.процеси контролю  перевірка виконання фінансових планів по проекту, контроль витрат бюджету проекту виходячи з календарного плану-графіку й, якщо це необхідно, коригування календарних і фінансових планів

5.процеси закриття  формалізація всіх фінансових процедур проекту або фази (документування, архівація даних, звітність) і доведення його до логічного завершення

2. Сутність управління вартістю проекту

Управління вартістю проекту поєднує процеси, виконувані в ході планування, розробки бюджету й управління витратами і які забезпечують завершення проекту в рамках затвердженого бюджету.

Процеси управління вартістю проекту:

1. Оцінювання вартості – процес визначення зразкової вартості ресурсів, необхідних для виконання операцій проекту.

2. Визначення бюджету – процес підсумовування оцінок вартості окремих операцій або пакетів робіт для формування санкціонованого базового плану за вартістю.

3. Управління вартістю – процес моніторингу статусу проекту для коректування бюджету проекту й внесення змін у базовий план за вартістю.

Ці процеси взаємозалежні один з одним, а також із процесами з інших галузей знань.

Залежно від потреб проекту в кожному процесі можуть брати участь одна особа або група осіб.

Кожний процес відбувається в кожному проекті не менш одного разу й виконується в одній або декількох фазах проекту, якщо проект розбитий на фази.

Хоча процеси представлені у вигляді дискретних елементів із чітко визначеними межами, на практиці вони можуть накладатися один на одного й впливати.

У деяких проектах, особливо невеликих, оцінювання вартості й розробка бюджету витрат настільки тісно взаємозалежні, що розглядаються як єдиний процес, що може виконуватися однією людиною за відносно короткий період часу

У РМВОК ці процеси розглядаються як окремі, тому що інструменти й методи кожного з них різні. Можливості впливу на вартість максимальні на ранніх стадіях проекту, тому дуже важливо якомога раніше визначити зміст проекту.

Роботам, що складають три процеси управління вартістю проекту, передує деяка дія по плануванню, виконувана командою управління проектом. Це планування є частиною процесу розробки плану управління проектом, у результаті якого виходить план управління вартістю, що встановлює формат і критерії планування, структурування, оцінювання, розробки бюджету й управління вартістю проекту. Процеси управління вартістю й пов'язані з ними інструменти й методи звичайно вибираються на стадії визначення життєвого циклу проекту і документально фіксуються в плані управління вартістю.

Наприклад, у плані управління вартістю можуть фіксуватися:

- Ступінь точності.

- Одиниці вимірювання.

- Зв'язки між процедурами організації.

- Контрольні пороги.

- Правила вимірювання виконання.

- Формати звітності.

- Описи процесів.

Вся ця інформація включається в план управління вартістю (елемент плану управління проектом), або в текст його основної частини, або у вигляді додатків.

План управління вартістю може бути формальним і неформальним і мати більший або менший ступінь деталізації залежно від потреб проекту.

- Ступінь точності. При оцінці вартості операцій дані округляються з певною точністю (наприклад, до 100, 1000 дол. США) залежно від змісту операцій і масштабу проекту; у цьому округленні можуть ураховуватися резерви на можливі втрати.

- Одиниці вимірювання. Для кожного типу ресурсів оговорюються одиниці вимірювання (наприклад, людино-години, людино-дні, тижні або фіксована вартість).

- Зв'язки між процедурами організації. Ієрархічна структура робіт (ІСР) надає структуру для плану управління вартістю, що дозволяє забезпечити несуперечність оцінок, бюджету й управління вартістю. Елемент ІСР, використовуваний для обліку вартості проекту, називається контрольним рахунком. Кожному контрольному рахунку присвоюється унікальний код або номер, що безпосередньо пов'язаний із системою бухгалтерського обліку виконуючої організації.

- Контрольні пороги. Для моніторингу виконання вартості можуть визначатися пороги відхилень, що дозволяє встановити заздалегідь узгоджену величину допустимого відхилення, перш ніж будуть розпочаті деякі дії. Пороги звичайно показуються у відхиленні від базового плану, вираженому у відсотках.

- Правила вимірювання виконання. Установлюються правила вимірювання виконання відповідно до управління освоєним обсягом. Наприклад, план управління вартістю може:

• визначати ІСР і точки, у яких буде проводитися вимірювання контрольних рахунків;

• установлювати методи вимірювання освоєного обсягу (наприклад, зважені контрольні події, фіксовані значення, відсоток виконання й т.д.) для застосування; і

• визначати формули розрахунку для управління освоєним обсягом, необхідні для визначення прогнозу по завершенні та інших методів відстеження.

- Формати звітності. Визначаються формати й регулярність складання різноманітних звітів про вартість.

- Описи процесів. Документально фіксуються описи кожного із трьох процесів управління вартістю.

Вся ця інформація включається в план управління вартістю (елемент плану управління проектом), або в текст його основної частини, або у вигляді додатків. План управління вартістю може бути формальні і неформальним і мати більший або менший ступінь деталізації залежно від потреб проекту.

Управління вартістю проекту має враховувати вимоги до інформації про витрати, пропоновані зацікавленими сторонами проекту.

Різні зацікавлені сторони проекту можуть розраховувати вартість проекту різними способами й у різні моменти часу.

Наприклад, ціна предмета, що купується, може оцінюватися на момент ухвалення рішення або підтвердження покупки, на момент оформлення замовлення, на момент поставки, або його фактична вартість зараховується й фіксується при веденні видатків проекту.

Управління вартістю проекту стосується, насамперед, вартості ресурсів, необхідних для виконання операцій проекту. Крім того, при управлінні вартістю проекту варто враховувати, як прийняті рішення позначаться на наступних періодичних витратах на експлуатацію, обслуговування й технічну підтримку продукту, послуги або результату проекту.

Наприклад, обмеження числа перевірок конструкторських креслень може знизити вартість проекту, але це може призвести до підвищення експлуатаційних витрат замовника.

Джерелами інформації на вході є виходи процесів проекту з інших галузей знань. Після одержання вся ця інформація стає доступною як входи для всіх трьох процесів управління вартістю.

Вартість оцінюється для всіх ресурсів, які будуть задіяні в проекті. До ресурсів належать, зокрема, робоча сила, матеріали, обладнання, послуги й споруди, а також особливі статті витрат, такі як урахування рівня інфляції або видатки на можливі втрати. Оцінювання вартості – це кількісне оцінювання можливої вартості ресурсів, необхідних для виконання операції.

У багатьох організаціях прогнозування й аналіз передбачуваної фінансової ефективності продукту проекту виконується поза рамками проекту. В інших, як наприклад, у проектах капітального будівництва, управління вартістю проекту включає й таку роботу. У тому випадку, коли такі прогнозування й аналіз включені в проект, управління вартістю проекту охоплює додаткові процеси й ряд методів зі сфери загального управління, такі як аналіз рентабельності інвестицій, дисконтованого грошового потоку й окупності інвестованих коштів.

План управління вартістю розробляється на ранній стадії планування проекту й визначає структуру кожного із трьох процесів управління вартістю для забезпечення ефективності й узгодженості цих процесів.

3. Оцінювання вартості

Оцінювання вартості являє собою процес приблизного оцінювання вартості ресурсів, необхідних для виконання операцій проекту.

Оцінювання вартості є прогнозами, заснованими на інформації, відомої в конкретний момент часу. Вони містять у собі виявлення й розгляд альтернатив розрахунку вартості для ініціації й виконання проекту. Для досягнення оптимальних витрат проекту повинні бути розглянуті співвідношення й ризики вартості, такі як рішення «виробляти або купити», «купити або орендувати», а також розподіл ресурсів.

Оцінювання вартості, як правило, виражаються в грошових одиницях, хоча в окремих випадках використовуються інші одиниці вимірювання, такі як людино-години або людино-дні, для полегшення порівняння й виключення впливу коливань курсів валют.

У ході виконання проекту рекомендується проводити уточнення оцінки вартості для відбиття додаткових деталей у міру їхнього виявлення. Точність оцінки вартості проекту підвищується в міру просування проекту по життєвому циклі.

Отже, оцінювання вартості є ітеративним процесом, що повторюється від фази до фази.

Наприклад, у фазі ініціації проекту може бути отримана досить груба оцінка «порядку величини», у діапазоні ±50 %.

Надалі, у міру надходження інформації, діапазон оцінки може звузитися до ±10 %.

У деяких організаціях існують особливі вказівки щодо того, коли такі уточнення варто робити, і якої точності при цьому можна чекати.

Вартість оцінюється для всіх ресурсів, які будуть задіяні в проекті. До ресурсів належать, зокрема, робоча сила, матеріали, обладнання, послуги й споруди, а також особливі статті витрат, такі як урахування рівня інфляції або видатки на можливі втрати.

Оцінювання вартості – це кількісне оцінювання можливої вартості ресурсів, необхідних для виконання операції.

Оцінювання вартості: входи, інструменти і методи, виходи

Блок-схема даних при оцінюванні вартості

Оцінювання вартості: входи

1. Базовий план по змісту

- Опис змісту. Опис змісту (див. тему Управління змістом) містить у собі опис продукту, критерії приймання, ключові результати, межі проекту, допущення й обмеження проекту. Одне з головних допущень, що має бути зроблене при оцінці витрат проекту, полягає в тому, чи будуть оцінки обмежені тільки безпосередніми витратами проекту або вони також будуть включати непрямі витрати. Непрямі витрати - це витрати, які неможливо безпосередньо віднести до конкретного проекту, і, отже, вони акумулюються й розподіляються рівномірно між кількома проектами за допомогою затвердженої й документованої процедури обліку. Одним із найпоширеніших обмежень для багатьох проектів є обмеженість бюджету проекту. Серед інших прикладів обмежень можна навести необхідні дати поставок, наявність кваліфікованих людських ресурсів і правила організації.

- Ієрархічна структура робіт і Словник ІСР (див. тему Управління змістом).

- Додаткова інформація, яку можна знайти в базовому плані по змісту і яка містить вимоги, що зачіпають контрактні зобов'язання і юридичну відповідальність, включає питання здоров'я, безпеки, захищеності, продуктивності, охорони навколишнього середовища, страхування, прав інтелектуальної власності, ліцензій і дозволів. Всі їх варто враховувати при визначенні оцінок вартості.

Оцінювання вартості: входи

2. Розклад проекту. Головними факторами при визначенні вартості проекту є типи й кількість ресурсів, а також кількість часу, протягом якого необхідно використовувати ці ресурси для виконання робіт із проекту. Ресурси запланованих операцій і їхні тривалості використовуються як ключові входи даного процесу. Оцінювання ресурсів операцій містить у собі визначення доступності й кількості персоналу й матеріалів, необхідних для виконання запланованих операцій. Ці дані тісно пов'язані з оцінкою вартості. Оцінювання тривалості операцій впливає на оцінку вартості в будь-якому проекті, у бюджеті якого передбачене виправлення на вартість фінансування (включаючи відсотки по позиках) і в якому ресурси призначаються на певний період часу, що відповідає тривалості виконання операції. Оцінювання тривалості операцій також може впливати на оцінку вартості в тих випадках, коли враховуються витрати, що залежать від часу (наприклад, профспілка, з якою укладений колективний договір, що регулярно продовжується, або матеріали із сезонними коливаннями вартості).

Оцінювання вартості: входи

3. План управління людськими ресурсами Характеристики управління людськими ресурсами, тарифні ставки персоналу проекту й відповідні винагороди/заохочення є необхідними складовими оцінювання вартості проекту.

4. Реєстр ризиків. Для урахування витрат на зниження ризиків необхідно переглянути реєстр ризиків. Ризики можуть бути загрозами або сприятливими можливостями, тому вони звичайно впливають на вартість як окремої операції, так і всього проекту. Як правило, у випадку виникнення ризику негативного характеру, вартість проекту в поточному або найближчому періоді звичайно збільшується, і іноді відбувається затримка робіт, передбачених розкладом проекту.

Оцінювання вартості: входи

5. Фактори середовища підприємства, які можуть впливати на процес оцінювання вартості, містять у собі, серед іншого:

- Кон'юнктуру ринку. Кон'юнктура ринку описує, які продукти, послуги й результати доступні на ринку, хто є їхніми постачальниками, на яких умовах і в які строки. Регіональні й/або глобальні умови попиту та пропозиції впливають на вартість ресурсів.

- Опубліковану комерційну інформацію. Інформація про тарифи вартості ресурсів часто доступна в комерційних базах даних, що містять відомості про кваліфікацію й вартість людських ресурсів, а також відомості про вартість стандартних матеріалів і обладнання. Іншим джерелом інформації є опубліковані прайс-листи організацій-продавців.

Оцінювання вартості: входи

6. Активи процесів організації, які впливають на процес оцінювання вартості, містять у собі, серед іншого:

- правила оцінювання вартості;

- шаблони оцінювання вартості;

- історичну інформацію; і

- накопичені знання.

Оцінювання вартості: інструменти і методи

1. Експертна оцінка.На оцінку вартості впливають багато змінних, такі як ставки заробітної плати, вартість матеріалів, інфляція, фактори ризику та ін. Експертні оцінки, засновані на історичній інформації, дають важливе розуміння навколишнього середовища й інформації з попередніх подібних проектів. Також експертні оцінки можуть бути використані для визначення необхідності об'єднання методів оцінювання й способів усунення розходжень між ними.

Оцінювання вартості: інструменти і методи

2. Оцінювання за аналогами. Використовуються значення таких параметрів, як зміст, вартість, бюджет і тривалість, або вимірювання таких величин, як розмір, вага й складність, з попередніх подібних проектів як основи для оцінювання аналогічних параметрів або показників поточного проекту. При оцінюванні вартості по даному методу за основу оцінювання вартості поточного проекту приймається фактична вартість попередніх подібних проектів. Цей підхід, що дозволяє оцінювати загальну величину, іноді адаптується залежно від відомих розходжень у складності проекту.

Найчастіше оцінювання вартості за аналогами використовується у випадку, коли обсяг детальної інформації про проект обмежений, наприклад на його ранніх фазах. Оцінювання вартості по аналогах виконується із застосуванням історичної інформації й експертної оцінки.

Метод оцінювання вартості за аналогами, як правило, обходиться дешевше й займає менше часу, ніж інші методи, але при цьому він звичайно виявляється й менш точним. Оцінювання вартості за аналогами може застосовуватися до всього проекту або до його частин разом з іншими методами оцінювання. Оцінювання за аналогами стає найбільш достовірним у випадках, коли попередній проект подібний поточному не тільки за зовнішніми ознаками, але й по суті, а в членів команди проекту, зайнятих підготовкою оцінювання, є необхідні знання.

Оцінювання вартості: інструменти і методи

3. Параметричне оцінювання - це метод, за якого для обчислення оцінки параметрів операції, таких як вартість, бюджет і тривалість, використовуються статистичні взаємозв'язки між історичними даними й іншими змінними (наприклад, площею у квадратних метрах у будівництві). За допомогою даного методу можна одержати більш точну оцінку вартості. Ступінь точності залежить від складності й даних, що лежать в основі моделі. Параметричне оцінювання вартості може застосовуватися до всього проекту або до його частин разом з іншими методами оцінювання.

4. Оцінювання «знизу нагору» - це метод оцінювання елементів робіт. Вартість окремих пакетів робіт або операцій оцінюється з найвищим ступенем конкретизації деталей. Детальна вартість потім підсумовується або «згортається» до більш високих рівнів з метою наступного відстеження й складання звітів. На вартість і точність оцінювання «знизу нагору» звичайно впливають розмір і складність кожної окремої операції або пакета робіт.

Оцінювання вартості: інструменти і методи

5. Оцінювання по трьох точках. Точність оцінок вартості операцій по одній точці може бути поліпшена шляхом розгляду невизначеностей і ризиків оцінок. Ця концепція походить із методу оцінювання й аналізу програм (PERT). Для визначення зразкового діапазону вартості операції PERT використовує три оцінки:

- Найбільш імовірна (См). Вартість операції, заснована на реалістичній оцінці трудомісткості необхідної роботи й всіх прогнозованих витрат.

- Оптимістична (Со). Вартість операції, заснована на аналізі сприятливого сценарію розвитку операції.

- Песимістична (Ср). Вартість операції, заснована на аналізі несприятливого сценарію розвитку операції.

Оцінювання вартості: інструменти і методи

Аналіз PERT дозволяє визначити очікувану (С_Е) вартість операції шляхом обчислення середньозваженого цих трьох оцінок:

Оцінювання вартості, заснована на даному рівнянні (або навіть на простому середньоарифметичному цих трьох точок), може бути більш точною, а три точки дозволяють прояснити діапазон невизначеності оцінки вартості.

Оцінювання вартості: інструменти і методи

6. Аналіз резервів. Оцінювання вартості можуть містити в собі резерви на можливі втрати (іноді називані «коштами на можливі втрати») для урахування невизначеності вартості. Резерв на можливі втрати може виражатися у відсотках оцінної вартості, фіксованим числом або може бути розроблений за допомогою методів кількісного аналізу.

У міру надходження більш точної інформації про проект резерви на можливі втрати можуть бути використані, скорочені або ліквідовані. Можливі втрати повинні бути чітко визначені в документації з вартості. Резерви на можливі втрати є частиною вимог до фінансування.

Оцінювання вартості: інструменти і методи

7. Вартість якості. Для підготовки оцінки вартості операцій можуть бути використані допущення про вартість якості (Див тему Управління якістю).

8. Програмне забезпечення для управління проектами, використовуване для оцінювання Для оцінювання вартості проектів широко використовується різне ПЗ для управління проектами, наприклад окремі додатки, призначені для оцінювання вартості, електронні таблиці, а також інструментальні засоби для моделювання й обробки статистичної інформації. Такі інструменти полегшують використання деяких методів оцінювання вартості й, отже, сприяють швидкому розгляду альтернативних оцінок вартості.

Оцінювання вартості: інструменти і методи

9. Аналіз пропозицій постачальників. Методи оцінювання вартості можуть включати аналіз можливої вартості проекту залежно від відповідних пропозицій кваліфікованих постачальників. У випадках, коли постачальник дістає проект у процесі конкурсу, може знадобитися, щоб команда проекту провела додаткове оціннювання вартості й визначила вартість окремих результатів і розрахувала остаточну вартість усього проекту в цілому.

Оцінювання вартості: виходи

1. Оцінки вартості операцій - це кількісне оцінювання ймовірних витрат, необхідних для виконання робіт із проекту. Оцінювання вартості може представлятися в узагальненій формі або в деталях. Витрати оцінюються по всіх ресурсах, використаних в оцінюванні вартості операцій. До ресурсів відносяться, зокрема, прямі витрати праці, матеріали, обладнання, послуги, споруди, інформаційні технології й особливі статті витрат, такі як урахування рівня інфляції або витрати на можливі втрати. Непрямі витрати, якщо вони включені в оцінку вартості проекту, можуть ураховуватися на рівні операцій або на більш високих рівнях.

Оцінювання вартості: виходи

2. Основа для оцінювання. Кількість і тип додаткових деталей, що обґрунтовують оцінку вартості, розрізняються залежно від прикладної області. Незалежно від рівня деталізації, допоміжна документація повинна забезпечувати чітке й повне розуміння того, яким способом була розрахована вартість.

Допоміжні деталі для оцінювання вартості операцій можуть містити в собі:

- документацію з основи для оцінювання (тобто того, як оцінка отримана);

- документацію з усіх прийнятих допущень;

- документацію з усіх відомих обмежень;

- зазначення діапазону можливих оцінок (наприклад, 10 000 дол. ± 10 %), щоб показати, що очікувана вартість предмета повинна лежати в межах зазначеного діапазону значень); і

- зазначення ступеня вірогідності остаточної оцінки.

3. Оновлення документів проекту. Документи проекту, які можуть бути оновлені, містять у собі, зокрема, реєстр ризиків.

4. Визначення. бюджету

Визначення бюджету - процес об'єднання оціночної вартості окремих операцій або пакетів робіт для розробки санкціонованого базового плану за вартістю. Даний базовий план містить у собі всі санкціоновані бюджети, за винятком управлінських резервів.

Бюджети проекту являють собою засоби, санкціоновані для виконання проекту.

Виконання вартості проекту порівнюється із санкціонованим бюджетом

Визначення бюджету: входи, інструменти і методи, виходи

Блок-схема даних при визначенні бюджету

Визначення бюджету: входи

1. Оцінювання вартості операцій. Оцінювання вартості кожного пакета робіт складається із суми оцінок вартості кожної операції,що входить у пакет робіт.

2. Основа для оцінювання. Допоміжні деталі для оцінювання вартості повинні бути визначені, як описано раніше. Будь-які головні допущення, пов'язані із включенням або виключенням непрямих витрат з бюджету проекту, вказуються в основі для оцінок.

3 Базовий план по змісту.

- Опис змісту. Формальні обмеження на період витрачання коштів на проект можуть бути встановлені організацією або іншими органами, такими як урядові заклади, а також можуть бути закріплені в контракті. Ці обмеження фінансування відображаються в описі змісту проекту.

- Ієрархічна структура робіт. Ієрархічна структура робіт проекту (ІСР) визначає взаємини між усіма результатами проекту і їхніх різноманітних елементів.

- Словник ІСР. Словник ІСР і відповідні детальні описи робіт дають точні визначення результатів і опис робіт для кожного елемента ІСР, необхідного для досягнення кожного результату.

Визначення бюджету: входи

4. Розклад проекту, як частина плану управління проектом, містить у собі планові дати початку й закінчення операцій, контрольних подій, пакетів робіт, планованих пакетів робіт і контрольних рахунків проекту. Дана інформація може бути використана для підсумовування витрат за календарні періоди, у які заплановане виникнення витрат.

5. Ресурсні календарі містять інформацію про склад і час виділення ресурсів. Ця інформація може використовуватися для зазначення вартості ресурсів протягом проекту.

6. Контракти. При визначенні бюджету враховується контрактна інформація й витрати, пов'язані із придбаними продуктами, послугами або результатами.

7. Активи процесів організації, які впливають на процес визначення бюджету, містять у собі, серед іншого:

- існуючі формальні й неформальні правила, процедури й провідні вказівки, пов'язані з розробкою бюджету витрат;

- інструменти розробки бюджету витрат; і

- методи складання звітів.

Визначення бюджету: інструменти і методи

1. Підсумовування вартості Оцінки вартості підсумовуються по пакетах робіт відповідно до ІСР. Потім оцінки вартості пакетів робіт поєднуються в елементи більш високих рівнів елементів ІСР (таких як контрольні рахунки), у підсумку утвориться оцінювання вартості всього проекту.

2. Аналіз резервів бюджету може встановити як резерви на можливі втрати, так і управлінські резерви проекту.

Резерви на можливі втрати - це кошти на випадок незапланованих, але потенційно необхідних змін, які можуть виникнути в результаті реалізованих ризиків, зазначених у реєстрі ризиків.

Управлінські резерви - це бюджети, зарезервовані на незаплановані зміни змісту й вартості проекту. Менеджеру проекту може знадобитися отримати схвалення на управлінські резерви до їх одержання в розпорядження або витрат.

Резерви не є частиною базового плану проекту за вартістю, але вони можуть бути включені в загальний бюджет проекту. Вони не враховуються при розрахунку освоєного обсягу.

Визначення бюджету: інструменти і методи

3. Експертна оцінка. При визначенні бюджету повинні використовуватися оцінки, засновані на досвіді в прикладній області, галузі знань, сфері діяльності, галузі промисловості й т.д., відповідно до виконуваної операції. Таку експертну оцінку можуть надати особа або група осіб, що мають фахову освіту, знання, навички, досвід або підготовку. Експертні оцінки доступні з багатьох джерел, до яких належать, серед іншого:

- інші підрозділи в рамках виконуючої організації;

- консультанти;

- зацікавлені сторони проекту, у тому числі замовники;

- професійні й технічні асоціації; і

- галузеві об'єднання.

Визначення бюджету: інструменти і методи

4. Історичні взаємозв'язки. Будь-які історичні взаємозв'язки, що дають у результаті параметричні оцінки або оцінки по аналогах, передбачають використання характеристик (параметрів) проекту для розробки математичних моделей, щоб прогнозувати загальну вартість проекту. Такі моделі можуть бути простими (наприклад, будівництво житла засноване на певній вартості квадратного метра житлової площі) або складними (наприклад, одна модель обрахування витрат на розробку програмного забезпечення використовує кілька окремих поправочних коефіцієнтів, кожний з яких включає безліч елементів).

Як вартість, так і точність параметричних моделей і моделей за аналогами може значно різнитися. Вони найбільш достовірні, коли:

- історична інформація, використовувана для розробки моделі, точна;

- параметри, використовувані в моделі, повністю піддаються кількісному вираженню; і

- моделі масштабовані, тобто застосовні як до великого проекту, до невеликого проекту, так і до фаз проекту.

Визначення бюджету: інструменти і методи

5. Узгодження фінансових обмежень. Використання коштів має бути узгоджене з будь-якими фінансовими обмеженнями по виділенню коштів під проект.

Розбіжності між фінансовими обмеженнями й плановими витратами іноді приводять до необхідності перегляду розкладу робіт для узгодження норм витрат. Це може бути реалізоване шляхом внесення в розклад проекту обмежень по необхідних датах робіт.

Визначення бюджету: виходи

• Базовий план виконання вартості - це санкціонований розподілений у часі бюджет по завершенні, по якому провадиться звірення, моніторинг і контроль загального виконання вартості проекту.

Він розробляється шляхом підсумовування схвалених бюджетів на конкретний період часу й, як правило, зображується у вигляді S-подібної кривої, як показано на наступному. У методі управління освоєним обсягом базовий план виконання вартості називається «базовим планом виконання».

Базовий план за вартістю, витрати й вимоги до фінансування

Визначення бюджету: виходи

2. Вимоги до фінансування проекту, загальні та періодичні (наприклад, щоквартальні або щорічні), виводяться на підставі базового плану за вартістю. Базовий план за вартістю містить заплановані видатки плюс очікувані зобов'язання. Найчастіше фінансування являє собою інкрементні суми, наростання яких відбувається не постійно, тому на слайді вони представлені у вигляді східчастої функції.

Загальна кількість необхідних коштів - це сума коштів, зазначених у базовому плані за вартістю, і управлінських резервів, якщо такі є.

.

Визначення бюджету: виходи

3. Оновлення документів проекту

Документи проекту, які можуть бути оновлені, містять у собі, серед іншого:

- реєстр ризиків;

- оцінку вартості; і

- розклад проекту.

5. Управління вартістю

Управління вартістю являє собою процес моніторингу статусу проекту для коректування бюджету проекту й внесення змін у базовий план за вартістю.

Коректування бюджету пов'язане з реєстрацією фактичних витрат, понесених на певну дату. Будь-яке збільшення санкціонованого бюджету може бути затверджене тільки за допомогою процесу загального управління змінами.

Моніторинг витрачання коштів без прийняття до уваги обсягу робіт, виконуваних у зв'язку із цими видатками, має малу цінність для проекту, якщо тільки не дозволяє команді проекту залишатися в рамках затвердженого бюджету.

Отже, більша частина дій по управлінню вартістю пов'язана з аналізом взаємозв'язків між витратами коштів проекту й фізичною роботою, виконуваною у зв'язку із цими витратами.

Ключовим елементом ефективного управління вартістю є управління затвердженим базовим планом виконання вартості й змінами даного базового плану.

Управління вартістю проекту містить у собі:

- вплив на фактори, що викликають зміни санкціонованого базового плану за вартістю;

- забезпечення своєчасної обробки всіх запитів на зміну;

- управління фактичними змінами в міру їхнього виникнення;

- забезпечення витрачання коштів у рамках затвердженого бюджету протягом певного періоду або протягом усього проекту;

- моніторинг виконання вартості з метою виявлення й аналізу відхилень від схваленого базового плану за вартістю;

- моніторинг виконання робіт і їхнє зіставлення з витраченими коштами;

- запобігання включення не схвалених змін у звіти за вартістю або використаними ресурсами;

- інформування відповідних зацікавлених сторін проекту про всі схвалені зміни й пов'язану з ними вартість; і

- дії по скороченню очікуваних перевитрат коштів до прийнятного рівня.

Управління вартістю проекту містить у собі пошук причин, що викликають як позитивні, так і негативні відхилення, і є частиною процесу здійснення загального управління змінами.

Управління вартістю: входи, інструменти і методи, виходи

Блок-схема даних при управлінні вартістю

Управління вартістю: входи

1. План управління проектом, описаний у темі Управління інтеграцією, містить таку інформацію, використовувану для управління вартістю:

- Базовий план виконання вартості.

- План управління вартістю.

2. Вимоги до фінансування проекту (описані раніше).

Управління вартістю: входи

3. Інформація про виконання робіт містить відомості про хід виконання проекту, наприклад дані про те, робота над якими результатами почалася, про ступінь виконання й про те, по яких результатах робота вже закінчена. Інформація також містить у собі санкціоновані й здійснені витрати, а також оцінку виконання робіт із проекту.

4. Активи процесів організації, які можуть впливати на процес управління вартістю, містять у собі, серед іншого:

- існуючі формальні й неформальні правила, процедури й провідні вказівки, пов'язані з управлінням вартістю;

- інструменти управління вартістю; і

- використовувані методи моніторингу й складання звітності.

Управління вартістю: інструменти і методи

1. Управління освоєним обсягом

Метод управління освоєним обсягом (УОО) у різних своїх формах є широко розповсюдженим методом вимірювання виконання. Він поєднує параметри змісту, вартості й розкладу проекту, які дозволяють команді управління проектом оцінювати й вимірювати ефективність і ступінь виконання проекту. Це метод управління проектом, що вимагає формування інтегрованого базового плану, з яким буде порівнюватися виконання протягом проекту.

Управління вартістю: інструменти і методи

Принципи УОО можуть застосовуватися до всіх проектів у будь-якій галузі. За допомогою УОО розробляють і здійснюють контроль таких трьох ключових показників для кожного пакета робіт і контрольного рахунку:

• Плановий обсяг (ПО) (Planned Value, або скорочено PV).

• Освоєний обсяг (ОО) (Earned Value, або скорочено EV ).

• Фактична вартість (ФВ) (Actual Cost, або скорочено AC ).

Управління вартістю: інструменти і методи

Плановий обсяг (ПО) - це санкціонований бюджет, виділений для роботи, яку необхідно виконати в рамках операції або елемента ієрархічної структури робіт. Він містить у собі деталізовану санкціоновану роботу плюс її бюджет, розподілений по фазах у життєвому циклі проекту. Сукупний плановий обсяг іноді називається "базовим планом виконання". Загальна величина планового обсягу проекту також відомий як "бюджет по завершенні" (БПЗ).

-

Управління вартістю: інструменти і методи

Освоєний обсяг (ОО) - це обсяг виконаної роботи в показниках затвердженого бюджету, виділеного для даної роботи в рамках операції або елемента ієрархічної структури робіт. Це санкціонована робота, що була виконана, разом із санкціонованим бюджетом для цієї виконаної роботи. Вимірюваний освоєний обсяг повинен бути прив'язаний до базового планового обсягу, і обмірюваний освоєний обсяг не може перевищувати санкціонований бюджет планового обсягу для даного елемента.

Управління вартістю: інструменти і методи

Термін "освоєний обсяг" часто використовується для позначення відсотка виконання проекту. Для кожного елемента ІСР повинні бути встановлені критерії вимірювання виконання робіт, що знаходяться у процесі виконання. Менеджери проектів контролюють освоєний обсяг, як інкрементно для визначення поточного статусу, так і кумулятивно для визначення довгострокових тенденцій ефективності виконання.

Цей показник дав назву й методу освоєного обсягу, і звіту по освоєному обсягу.

Планована вартість виконаних робіт ОО, як і два інших показники, - це об'єднання коштів за розглянутим періодом часу.

ОО - це об'єднання планової вартості фактично виконаних за звітний період робіт. Наприклад, якщо виконано роботу із плановою (кошторисною) вартістю 10000 грн., то ОО для цієї роботи з її закінченням буде дорівнювати 10000 грн.

Управління вартістю: інструменти і методи

Фактична вартість (ФВ) - це загальна вартість, фактично витрачена й зареєстрована під час виконання робіт у рамках операції або елемента ієрархічної структури робіт. Це загальна вартість, витрачена при виконанні робіт, обмірюваних освоєним обсягом. Фактична вартість по визначенню повинна відповідати тому, що було закладено в плановий обсяг і обмірюване освоєним обсягом (наприклад, тільки прямі витрати робочого часу, тільки прямі витрати або всі витрати, включаючи непрямі). У фактичної вартості відсутня верхня межа; виміряється все, що витрачається для досягнення освоєного обсягу.

Управління вартістю: інструменти і методи

Також здійснюється контроль відхилень від схваленого базового плану:

• Відхилення по строках (ВСТР) являє собою вимірювання виконання строків проекту. Значення його дорівнює різниці між освоєним обсягом (ОО) плановим обсягом (ПО). Відхилення по строках у методі УОО являє собою показник, корисний тим, що він демонструє, коли проект відстає по строках від свого базового плану. Відхилення по строках в остаточному підсумку буде дорівнювати нулю при завершенні проекту, тому що всі планові обсяги на той час повинні бути освоєні. Такі показники відхилень найкраще використовувати разом з методом критичного шляху для складання розкладу й управління ризиками.

Рівняння: ВСТР = ОО - ПО.

Управління вартістю: інструменти і методи

• Відхилення за вартістю (ВВРТ) являє собою вимірювання виконання вартості проекту. Воно дорівнює різниці між освоєним обсягом (ОО) і фактичною вартістю (ФВ). Відхилення за вартістю наприкінці проекту буде дорівнювати різниці між бюджетом по завершенні (БПЗ) і фактично витраченою сумою. ВВРТ у методі управління освоєним обсягом (УОО) надзвичайно важливе, тому що воно демонструє взаємозв'язок між фізичним виконанням і витраченими коштами. Будь-яке негативне ВВРТ найчастіше є невідшкодовуваним для проекту.

Рівняння: ВВРТ = ОО - ФВ.

Управління вартістю: інструменти і методи

Значення ВСТР і ВВРТ можуть бути перетворені в індикатори виконання для відбиття виконання вартості й строків будь-якого проекту в порівнянні з усіма іншими проектами або в рамках портфеля проектів. Відхилення й показники корисні для визначення статусу проекту, а також надають основу для оцінювання підсумкових строків і вартості проекту.

• Індекс виконання строків

• Індекс виконання вартості

Управління вартістю: інструменти і методи

• Індекс виконання строків (ІВСТР) являє собою вимір досягнутих обсягів виконання проекту в порівнянні із запланованим обсягом. Іноді він використовується разом з індексом виконання вартості (ІВВРТ) для прогнозування остаточних оцінок завершення проекту. Значення ІВСТР менше 1,0 указує на те, що виконано менше робіт, чим було заплановано. Значення ІВСТР більше 1,0 указує на те, що виконано більше робіт, чим було заплановано. Тому що ІВСТР вимірює всі роботи проекту, також повинне бути проаналізоване виконання на критичному шляху, щоб визначити, буде проект завершений до або після своєї планової дати фінішу. ІВСТР дорівнює відношенню ОО до ПО.

Рівняння: ІВСТР = ОО/ПО.

Управління вартістю: інструменти і методи

• Індекс виконання вартості (ІВВРТ) являє собою вимір обсягу виконаних робіт з порівняння з фактичною вартістю виконання проекту. Він уважається найбільш важливим показником УОО й вимірює вартісну ефективність виконаної роботи. Значення ІВВРТ менше 1,0 указує на перевитрату вартості для виконаної роботи. Значення ІВВРТ більше 1,0 указує на недоосвоєння вартості при виконанні на конкретну дату. ІВСТР дорівнює відношенню ОО до ФВ.

Рівняння: ІВВРТ = ОО/ФВ.

Управління вартістю: інструменти і методи

Три показники планового обсягу, освоєного обсягу й фактичної вартості можуть бути об'єктами контролю, і про них можуть складатися періодичні (звичайно щотижневі або щомісячні) або сукупні звіти.

ЗВІТ ПО ОСВОЄНОМУ ОБСЯГУ

Звіт по освоєному обсягу є найкращим методом для відображення ходу виконання проекту.

Його перевага полягає в тому, що на одному аркуші паперу можна показати стан значимого критерію виконання проекту.

У звіті по освоєному обсягу можна побачити, як розподіляються за часом плановані витрати проекту, а також реальні витрати коштів і обсяги фактично виконаних робіт.

На основі даних цього звіту можуть бути підраховані величини відхилень по витратах і строках.

ЗВІТ ПО ОСВОЄНОМУ ОБСЯГУ

У звіті по освоєному обсягу наводяться всі три показники.

Якщо проект іде в строгій відповідності із запланованими строками й бюджетом, то, очевидно, що всі три показники будуть збігатися.

Управління вартістю: інструменти і методи

На наступному слайді зображені S-подібні криві, що відображають дані ОО проекту, що перевитрачає бюджет і відстає від плану.

Освоєний обсяг, плановий обсяг і фактична вартість

Управління вартістю: інструменти і методи

2. Прогнозування У міру виконання проекту команда проекту може розробити прогноз по завершенні (ППЗ), що може відрізнятися від бюджету по завершенні (БПЗ), ґрунтуючись на ефективності виконання проекту. Якщо стає очевидним, що БПЗ більше не є досяжним, менеджер проекту повинен розробити ППЗ.

Розробка ППЗ містить у собі оцінку або передбачення умов і подій, які виникнуть у майбутньому, на підставі інформації й знань, наявних на момент прогнозування. Прогнози формуються, оновлюються й перевидаються заново на основі інформації про виконання робіт, що надходить. Інформація про виконання робіт охоплює минуле виконання проекту й будь-яку інформацію, що може вплинути на проект у майбутньому.

Управління вартістю: інструменти і методи

Прогноз по завершенні (ППЗ) звичайно заснований на фактичній вартості, витраченої при виконанні робіт, і прогнозі до завершення (ПДЗ) робіт, що залишилися.

На команду проекту покладений обов'язок передбачати, із чим вона може зіткнутися під час виконання ПДЗ, на підставі наявного в цей момент досвіду.

Метод УОО ефективний разом з неавтоматичними прогнозами необхідної вартості ППЗ. Найширше використовуваним підходом прогнозування ППЗ є неавтоматичне підсумовування «знизу нагору», проведене менеджером і командою проекту.

Управління вартістю: інструменти і методи

Метод ППЗ «знизу нагору», використовуваний менеджером проекту, заснований на фактичній вартості й досвіді, отриманих на виконаних роботах, і вимагає проведення нової оцінки до завершення робіт, що залишилися, по проекту. Даний метод може викликати проблеми, тому що він втручається в проведення робіт із проекту. Персонал, що виконує роботи із проекту, повинен призупинити свою роботу, щоб надати детальний ПДЗ «знизу нагору» для робіт, що залишилися. Як правило, на виконання ПДЗ не закладається окремого бюджету, так що на ці цілі в проекті витрачаються додаткові кошти.

Рівняння: ППЗ = ФВ + ПДЗ «знизу нагору».

Управління вартістю: інструменти і методи

Неавтоматичний ППЗ менеджера проекту може бути швидко зіставлений з низкою розрахованих ППЗ, що представляють різноманітні сценарії ризиків. Хоча дані УОО можуть швидко зробити безліч статистичних ППЗ, нижче описані тільки три найпоширеніші методи:

• ППЗ для робіт ПДЗ , виконаних по забюджетованих ставках.

• ППЗ для робіт ПДЗ , виконаних з ефективністю поточного ІВВРТ.

• ППЗ для робіт ПДЗ із урахуванням обох факторів ІВСТР и ІВВРТ.

Кожний із цих підходів може бути правильним для будь-якого конкретного проекту й подавати команді управління проектом сигнал «раннього попередження», якщо прогнози ППЗ виходять за рамки допусків.

Управління вартістю: інструменти і методи

(1). ППЗ для робіт ПДЗ , виконаних по забюджетованих ставках. Даний метод ППЗ використовує фактичне виконання проекту на конкретну дату (сприятливе або несприятливе), представлене фактичною вартістю, і пророкує, що всі майбутні роботи ПДЗ будуть виконані по забюджетованих ставках. У тих випадках, коли фактичне виконання несприятливе, допущення, що майбутнє виконання покращиться, повинне бути прийняте тільки в тому випадку, якщо це підтверджується аналізом ризиків проекту.

Рівняння: ППЗ = ФВ + БПЗ - ОО.

Управління вартістю: інструменти і методи

(2). ППЗ для робіт ПДЗ , виконаних з ефективністю поточного ІВВРТ. Цей метод допускає, що проект продовжиться в майбутньому так само, як він протікав до цього моменту. Допускається, що роботи ПДЗ будуть виконуватися на тому ж рівні кумулятивного індексу виконання вартості (ІВВРТ), який був досягнутий до цього моменту.

Рівняння: ППЗ = БПЗ/кумулятивний ІВВРТ

Управління вартістю: інструменти і методи

(3).ППЗ для робіт ПДЗ із урахуванням обох факторів ІВСТР и ІВВРТ. У даному прогнозі роботи ПДЗ будуть виконуватися з ефективністю, що враховує індекси виконання як вартості, так і строків. Він допускає як негативне виконання вартості на конкретну дату, так і вимогу дотримання проектом жорстких зобов'язань по строках. Даний метод найбільш корисний у випадку, коли одним із факторів, що впливають на дію ПДЗ, є розклад проекту. Варіації даного методу розглядають ІВВРТ і ІВСТР у різних співвідношеннях (наприклад, 80/20, 50/50 та ін.), відповідно до думки менеджера проекту. Рівняння: ФВ + [(БПЗ - ОО)] / (кумулятивний ІВВРТ x кумулятивний ІВСТР)].

Управління вартістю: інструменти і методи

3. Індекс продуктивності до завершення (ІПДЗ) - це обчислюваний прогноз ефективності виконання вартості, що повинна бути досягнута на роботах, що залишилися, для задоволення певної управлінської мети, такий як БПЗ або ППЗ. Якщо стає очевидним, що БПЗ більше не є здійсненним, менеджер проекту розробляє прогноз по завершенні (ППЗ). Після схвалення ППЗ фактично заміняє собою БПЗ як ціль виконання вартості.

Рівняння для ІПДЗ засновано на БПЗ:

(БПЗ - ОО) / (БПЗ - ФВ).

ІПДЗ концептуально представлений на наступному слайді. Рівняння для ІПДЗ показано в лівому нижньому куті - робота, що залишилася (визначений як БПЗ мінус ОО), ділена на кошти, що залишилися (які можуть розраховуватися або як БПЗ мінус ФВ, або як ППЗ мінус ФВ).

Індекс продуктивності до завершення (ІПДЗ)

Управління вартістю: інструменти і методи

Якщо кумулятивний ІВВРТ нижче базового плану (як показано на попередньому слайді), всі майбутні роботи із проекту негайно повинні виконуватися відповідно до ІПДЗ (БПЗ) (що відбито у верхній лінії на слайді № 54), щоб залишатися в рамках санкціонованого БПЗ. Судження про те, чи є даний рівень виконання досяжним, приймається на основі ряду міркувань, включаючи ризики, розклад і технічні параметри. Якщо керівництво визнає, що БПЗ більше недосяжний, менеджер проекту підготовляє новий прогноз по завершенні (ППЗ) для робіт, і після його схвалення проект буде виконуватися з новим цільовим значенням ППЗ. Цей рівень ефективності виконання зображений у вигляді лінії ІПДЗ (ППЗ). Рівняння для ІПДЗ, заснованого на ППЗ: (БПЗ - ОО) / (ППЗ - ФВ).

Управління вартістю: інструменти і методи

4. Аналіз виконання передбачає порівняння виконання вартості, запланованих операцій або пакетів робіт із плином часу, виконання яких відрізняється від передбачених бюджетом значень, як убік збільшення, так і убік зменшення, з оцінними коштами, необхідними для завершення виконуваних робіт. Якщо використовується УОО, то визначається така інформація:

- Аналіз відхилень. Аналіз відхилень при використанні в УОО містить у собі порівняння фактичного виконання проекту із плановим або очікуваним виконанням. Найбільше часто аналізуються відхилення за вартістю й по строках.

- Аналіз тенденцій. Аналіз тенденцій припускає вивчення даних про виконання проекту із часом для визначення того, поліпшується або погіршується виконання проекту. Методи графічного аналізу цінні для розуміння ефективності й обсягів виконання на конкретну дату й для порівняння із цільовими показниками подальшого виконання у формі БПЗ у порівнянні із ППЗ і дат завершення.

- Виконання освоєного обсягу. Управління освоєним обсягом передбачає порівняння базового плану з фактичним виконанням строків і вартості.

Управління вартістю: інструменти і методи

5. Аналіз відхилень

Показники виконання вартості (ВВРТ, ІВВРТ) використовуються для оцінювання величини відхилення від початкового базового плану за вартістю. Важливі аспекти управління вартістю проекту містять у собі визначення причини й ступеня відхилення щодо базового плану виконання вартості і прийняття рішень про необхідність коригувальних або попереджуючих дій. У міру виконання все більшого обсягу робіт процентний діапазон припустимих відхилень буде мати тенденцію до зменшення. У міру наближення проекту до завершення великі процентні значення припустимих відхилень, прийняті на початку проекту, можуть зменшуватися.

Управління вартістю: інструменти і методи

6. Програмне забезпечення для управління проектами

Для здійснення моніторингу трьох показників УОО (ПО, ОО й ФВ) часто використовується програмне забезпечення для управління проектами, що графічно відображає тренди й прогнозує діапазон можливих остаточних результатів проекту.

Управління вартістю: виходи

1. Результати вимірювання виконання робіт

Розраховані значення ВВРТ, ВСТР, ІВВРТ і ІВСТР для елементів ІСР, зокрема, для пакетів робіт і контрольних рахунків, документально фіксуються й направляються зацікавленим сторонам проекту.

2. Бюджетні прогнози. Або розраховане значення ППЗ, або значення ППЗ «знизу нагору» документально фіксується й направляється зацікавленим сторонам проекту.

Управління вартістю: виходи

3. Оновлення активів процесів організації

Активи процесів організації, які можуть бути оновлені, містять у собі, серед іншого:

- причини відхилень;

- обрані коригувальні впливи й причини; і

- інші знання, накопичені в ході управління вартістю проекту.

4. Запити на зміну

Аналіз ефективності виконання проекту може спричинити підготовку запиту на зміну базового плану виконання вартості або інших елементів плану управління проектом. Запити на зміну можуть включати попереджуючі або коригувальні впливи й обробляються з метою аналізу й реалізації в процесі здійснення загального управління змінами (раздел 4.5).

Управління вартістю: виходи

5. Оновлення плану управління проектом

Елементи плану управління проектом, які можуть бути оновлені, містять у собі, серед іншого:

- Базовий план виконання вартості. У відповідь на схвалення змін змісту, ресурсів операцій або оцінок вартості в базовий план виконання вартості вносяться відповідні зміни. У деяких випадках відхилення за вартістю можуть бути настільки істотними, що для створення реалістичної основи для вимірювання виконання проекту базовий план за вартістю повинен бути переглянутий.

- План управління вартістю.

6. Оновлення документів проекту

Документи проекту, які можуть бути оновлені, містять у собі, серед іншого:

- оцінки вартості; і

- основу для оцінок.

Дякую за увагу!

Управління інтеграцією в проекті

1. Розробка Статуту проекту

2. Розробка плану управління проектом

3. Керівництво й управління виконанням проекту

4. Моніторинг і управління роботами проекту

5. Здійснення загального управління змінами

6. Завершення проекту або фази

Галузі застосування знань з проектного менеджменту

• Управління інтеграцією в проекті;

• Управління змістом проекту;

• Управління термінами у проекті;

• Управління вартістю проекту;

• Управління якістю проекту;

• Управління людськими ресурсами проекту;

• Управління комунікаціями у проекті;

• Управління ризиками проекту;

• Управління закупівлями в проекті.

Управління інтеграцією в проекті

Включає різні дії, необхідні для того, щоб основний процес був скоординований правильно.

Управління інтеграцією в проекті включає здійснення обміну між конкуруючими цілями й альтернативами для того, щоб задовольнити або навіть перевищити очікування зацікавлених осіб.

Основні процеси управління інтеграцією в проекті

1 Розробка Статуту проекту

2 Розробка плану управління проектом

3 Керівництво й управління виконанням проекту

4 Моніторинг і управління роботами проекту

5 Здійснення загального управління змінами

6 Завершення проекту або фази – процес завершення всіх операцій всіх груп процесів управління проектом з метою формального завершення проекту або фази.

Ці процеси є суто інтеграційними

Вони взаємодіють як між собою, так і з процесами інших галузей застосування знань з проектного менеджменту.

Кожний процес може включати зусилля одного чи кількох індивідуумів або груп індивідуумів, спрямовані на задоволення потреб проекту, і виконується, як правило, по одному разу на кожній фазі проекту.

1. Розробка Статуту проекту

1. Розробка Статуту проекту – процес розробки документа, що формально санкціонує проект або фазу й документує первісні вимоги, що задовольняють потреби й очікування зацікавлених сторін проекту.

Статут проекту

Установлює партнерство між виконуючою організацією й організацією, що подала заявку (або замовником, у випадку зовнішніх проектів).

Затверджений Статут проекту формально ініціює проект.

Менеджер проекту переважно призначається під час розробки Статуту проекту й обов'язково до початку планування.

Рекомендується, щоб менеджер проекту брав участь у розробці Статуту проекту, тому що даний документ наділяє менеджера проекту повноваженнями використовувати ресурси для виконання проекту.

Розробка Статуту проекту: входи, інструменти, методи й виходи

Блок-схема даних при розробці Статуту проекту

Вхідні дані: Розробка Статуту проекту

1. Опис робіт (Statement of work, SOW) - це словесний опис продуктів або послуг, які повинен зробити проект.

Для внутрішніх проектів ініціатор або спонсор проекту надає опис робіт на підставі бізнес-потреб, вимог до продукту або послуги.

Для зовнішніх проектів опис робіт може бути отриманий від замовника як частина документації по пропозиціях, наприклад запиту пропозиції, запиту інформації, запиту заявок, або як частина контракту.

Вхідні дані Розробка Статуту проекту: (продовження)

Перелік робіт відображає:

• Бізнес-Потребу. Бізнес-потреба організації може бути заснована на ринковому попиті, технологічному прогресі, правових вимогах або постановах уряду.

• Опис змісту продукту. Документує характеристики продукту, для створення якого започатковується проект. Опис повинен також відображати взаємозв'язок між створюваними продуктами або послугами й бізнес-потребою, яку повинен задовольнити проект.

• Стратегічний план. Усі проекти повинні підтримувати стратегічні цілі організації. Стратегічний план виконуючої організації повинен розглядатися як один із факторів при прийнятті рішень про вибір проекту й розстановці пріоритетів.

Вхідні дані Розробка Статуту проекту: (продовження)

2.Економічне обґрунтування або подібний документ надає необхідну з погляду бізнесу інформацію, що дозволяє визначити, чи вартий проект необхідних інвестицій.

Звичайно в економічному обґрунтуванні містяться бізнес-потреби й порівняльний аналіз витрат і результатів для виправдання проекту.

Економічне обґрунтування може написати організація, що подає заявку, або замовник, у випадку зовнішніх проектів.

Вхідні дані Розробка Статуту проекту:(продовження)

Економічне обґрунтування створюється як результат дії одного або кількох факторів:

- вимоги ринку (наприклад, ІТ-компанія санкціонує проект з розробки нової версії програмного продукту у відповідь на зміну законодавства з оподаткування);

- потреба організації (наприклад, тренінгова компанія санкціонує проект по створенню нового курсу навчання з метою збільшення прибутку);

- вимоги замовника (наприклад, телекомунікаційна компанія санкціонує проект по створенню нового контакт-центру для нового району);

- технологічний прогрес (наприклад, виробник комп'ютерної техніки санкціонує новий проект з розробки більш швидкодіючого, економічного й компактного ноутбука з використанням останніх досягнень у технології виготовлення комп'ютерної пам'яті й електронних компонентів);

- правові вимоги (наприклад, Національний банк санкціонує проект для розробки рекомендацій щодо інформаційної безпеки комерційних банків);

- екологічні впливи (наприклад, компанія розпочинає проект для зменшення свого впливу на навколишнє середовище); або

- соціальні потреби (наприклад, неурядова організація в країні, що розвивається, санкціонує проект по створенню притулків для бездомних).

Вхідні дані Розробка Статуту проекту:(продовження)

У випадку якщо проект складається з кількох фаз, економічне обґрунтування може періодично переглядатися для забезпечення того, щоб проект знаходився на правильному шляху до досягнення вигід для бізнесу.

На ранніх стадіях життєвого циклу проекту періодичний перегляд економічного обґрунтування спонсорською організацією також допомагає впевнитися, що проект усе ще необхідний.

Вхідні дані Розробка Статуту проекту: (закінчення)

3 Контракт є входом, якщо проект виконується для зовнішнього замовника.

4 Фактори середовища підприємства, які можуть впливати на процес розробки Статуту проекту, містять у собі серед іншого:

• державні й промислові стандарти;

• інфраструктуру організації;

• ситуацію на ринку.

5 Активи процесів організації, які можуть впливати на процес розробки Статуту проекту, містять у собі серед іншого:

• стандартні процеси організації, правила й описи типових процесів для використання в організації;

• шаблони (наприклад, шаблон Статуту проекту);

• історичну інформацію й базу засвоєних уроків.

Інструменти й методи Розробка Статуту проекту:

1 Експертні оцінки - часто використовуються для оцінювання входів, застосовуваних для розробки Статуту проекту.

Подібні оцінки й експертизи в даному процесі застосовуються у відношенні будь-яких технічних і управлінських деталей.

Такі експертизи проводяться будь-якою особою або групою осіб, що володіють спеціальними знаннями або підготовкою, і доступні з безлічі джерел, включаючи такі:

• інші підрозділи в рамках організації;

• консультанти;

• зацікавлені сторони проекту, у тому числі замовники або спонсори;

• професійні й технічні асоціації;

• галузеві об'єднання;

• експерти по окремих питаннях;

• офіс управління проектами (Project management office, PMO).

Виходи Розробка Статуту проекту:

1 Статут проекту документує бізнес-потреби, нинішнє розуміння потреб замовника, а також новий продукт, послугу або результат, що планується створити, наприклад:

• призначення або обґрунтування проекту;

• вимірні цілі проекту й відповідні критерії успіху;

• вимоги високого рівня;

• опис проекту високого рівня;

• ризики високого рівня;

• зведений розклад контрольних подій;

• зведений бюджет;

• вимоги до схвалення проекту (що складає успіх проекту, хто вирішує, що проект виявився успішним, і хто підписує проект);

• призначений менеджер проекту, рівень відповідальності й повноважень;

• ім'я й повноваження спонсора або іншої особи (осіб), що затверджує Статут проекту

2. Розробка плану управління проектом

Розробка плану управління проектом – це процес документування дій, необхідних для визначення, підготовки, інтеграції й координації всіх допоміжних планів.

План управління проектом визначає, як буде виконуватися проект, як буде проводитися його моніторинг, контроль і закриття.

Зміст плану управління проектом різниться залежно від прикладної області й складності проекту.

План управління проектом розробляється в рамках серії інтегрованих процесів до завершення проекту.

Результатом даного процесу є план управління проектом, що поступово розробляється шляхом внесення оновлень, контролюється й затверджується в процесі здійснення загального управління змінами

Розробка плану управління проектом: входи, інструменти, методи й виходи

Блок-схема даних при розробці плану управління проектом

Вхідні дані для розробки плану управління проектом

1 Статут проекту

Див. тему “Статут проекту”

Вхідні дані для розробки плану управління проектом (продовження)

2. Виходи процесів планування.

Будь-які базові й допоміжні плани управління, що є виходами інших процесів планування, є входами для даного процесу. Вони включають як базові документи (наприклад, ієрархічна структура робіт), так і допоміжні деталі.

Виходи багатьох процесів планування, що розглянуті нами у відповідній темі інтегруються для створення плану управління проектом.

Крім того, відновлення даних документів можуть привести до коригування плану управління проектом.

Для проектів інформатизації можуть бути необхідними вхідні дані, що залежать від цієї прикладної сфери.

Вхідні дані для розробки плану управління проектом (продовження)

3. Фактори середовища підприємства, які можуть впливати на процес розробки плану управління проектом, містять у собі серед іншого:

• державні й промислові стандарти;

• інформаційні системи управління проектами (наприклад, автоматизовані засоби, такі як програмне забезпечення для управління розкладом, система управління конфігурацією, система збору й розподілу інформації або веб-інтерфейси до інших автоматизованих систем, що працюють у режимі онлайн);

• організаційну структуру й культуру;

• інфраструктуру (наприклад, споруди, що існують й капітальне обладнання);

• управління персоналом (наприклад, директиви по найму й звільненню, оцінки ефективності роботи співробітників і документи про навчання).

Вхідні дані для розробки плану управління проектом (продовження)

4. Активи процесів організації, які можуть впливати на процес розробки плану управління проектом, містять у собі серед іншого:

• типові провідні вказівки, робочі інструкції, критерії оцінки пропозицій і критерії вимірювання виконання;

• шаблон плану управління проектом - елементи плану управління проектом, які можуть бути оновлені, зокрема:

• провідні вказівки й критерії для адаптації набору стандартних процесів організації з метою задоволення конкретних потреб проекту;

• провідні вказівки або вимоги до закриття проекту, наприклад критерії підтвердження й приймання продуктів;

• процедури управління змінами, що включають дії, згідно котрим будуть модифікуватися офіційні стандарти компанії, політики, плани й процедури або будь-які документи проекту, а також порядок схвалення й підтвердження будь-яких змін;

Вхідні дані для розробки плану управління проектом (закінчення)

4. Активи процесів організації архіви по минулих проектах (наприклад, базові плани по змісту, вартості, розкладу й вимірюванню виконання, календарі проектів, сітьові діаграми проекту, реєстри ризиків, заплановані відповідні дії й певні наслідки ризиків);

• історичну інформацію й базу засвоєних уроків;

• базу знань по управлінню конфігурацією, що містить версії й базові плани по всіх офіційних стандартах компанії, політиках, процедурах і будь-яких документах проекту.

Інструменти і методи для розробки плану управління проектом

1 Експертні оцінки

При розробці плану управління проектом експертні оцінки використовуються для:

• адаптації процесу для задоволення вимог проекту;

• розробки технічних і управлінських деталей, які будуть включені в план управління проектом;

• визначення ресурсів і рівнів розвитку навичок, необхідних для виконання робіт із проекту;

• визначення рівня управління конфігурацією, що буде застосовуватися в проекті;

• визначення того, які документи проекту будуть піддані процесу формального управління змінами.

Виходи розробки плану управління проектом

1 План управління проектом інтегрує й консолідує всі допоміжні плани управління й базові плани, отримані в результаті процесів планування, і містить у собі:

• обраний для проекту життєвий цикл і процеси, які будуть застосовуватися в кожній фазі;

• результати адаптації, отримані від команди управління проектом, а саме:

• процеси управління проектом, обрані командою управління проектом;

• рівень реалізації кожного обраного процесу;

• опис інструментів і методів, які будуть використані для виконання даних процесів;

• порядок використання обраних процесів для управління конкретним проектом, включаючи залежності й взаємодії між даними процесами, а також необхідні входи й виходи;

Виходи розробки плану управління проектом (продовження)

1 План управління проектом містить (продовження):

• порядок виконання робіт для досягнення цілей проекту;

• план управління змінами, що документує порядок моніторингу й контролю змін;

• план управління конфігурацією, що документує порядок управління конфігурацією;

• порядок підтримки цілісності базових планів виконання;

• потреби в комунікації між зацікавленими сторонами проекту й методи її реалізації;

• ключові заходи щодо аналізу управління відносно змісту, границь і строків, що полегшують розгляд проблем і рішень, що очікують прийняття.

Виходи розробки плану управління проектом (продовження)

План управління проектом може бути складений як на рівні зведення, так і в деталях, і може складатися з одного або кількох допоміжних планів.

Кожний з допоміжних планів деталізований до того ступеня, що потрібно для конкретного проекту.

Після затвердження плану управління проектом він може змінюватися тільки після того, як буде створений запит на зміну й схвалений у рамках процесу здійснення загального управління змінами.

Виходи розробки плану управління проектом (продовження)

Базові плани проекту містять у собі:

• базовий розклад;

• базовий план виконання вартості;

• базовий план по змісту.

Виходи розробки плану управління проектом (продовження)

Допоміжні плани містять у собі:

• план управління змістом;

• план управління вимогами;

• план управління розкладом;

• план управління вартістю;

• план управління якістю;

• план удосконалення процесів;

• план управління людськими ресурсами;

• план управління комунікаціями;

• план управління ризиками;

• план управління закупівлями.

Виходи розробки плану управління проектом (закінчення)

Часто базові плани по змісту, розкладу й вартості поєднують у базовий план виконання, використовуваний у якості загального базового плану проекту, з яким може порівнюватися загальне виконання.

Базовий план виконання використовується для вимірювання освоєного обсягу.

3. Керівництво й управління виконанням проекту

Керівництво й управління виконанням проекту – це процес виконання робіт, визначених у плані управління проектом, для досягнення цілей проекту.

Операції з керівництва й управління виконанням проекту містять у собі:

• здійснення дій для виконання вимог проекту;

• створення результатів проекту;

• добір, підготовка й управління членами команди, призначеними на проект;

• одержання, управління й використання ресурсів, включаючи матеріали, інструменти, обладнання й споруди;

• застосування запланованих методів і стандартів;

• налагодження й управління каналами комунікацій проекту, як зовнішніми, так і внутрішніми стосовно команди проекту;

• визначення даних проекту, таких як вартість, розклад, технічне або якісне виконання й статус, для полегшення прогнозування;

• випуск запитів на зміну й адаптація схвалених змін до змісту, планів і середовища проекту;

• управління ризиками й виконання дій по реагуванню на ризики;

• управління продавцями й постачальниками;

• збір і документування засвоєних уроків, а також виконання схвалених дій по вдосконаленню процесів.

Керівництво й управління виконанням проекту (продовження)

Менеджер проекту разом з командою управління проектом керує виконанням запланованих операцій проекту й управляє різноманітними технічними й організаційними зв'язками, що існують у рамках проекту.

Результатами є виходи процесів виконання робіт проекту (основна діяльність), запланованих і внесених у розклад плану управління проектом.

Інформація про виконання робіт, про ступінь завершеності результатів і про те, що вже зроблено, збирається як складова виконання проекту й використовується у процесі звітування про виконання.

Інформація про виконані роботи також використовується як вхід у групі процесів моніторингу й управління.

Керівництво й управління виконанням проекту (продовження)

Керівництво й управління виконанням проекту також вимагає реалізації схвалених змін, включаючи:

• Коригувальний вплив. Документована вказівка для виконання робіт із проекту з метою приведення у відповідність очікуваного майбутнього виконання робіт із проекту з планом управління проектом.

• Попереджуюча дія. Документована вказівка здійснити дію, що може знизити ймовірність негативних наслідків, пов'язаних з ризиками проекту.

• Виправлення дефекту. Формально документоване виявлення дефекту в елементі проекту, що містить рекомендації або про виправлення дефекту, або про повну заміну елемента.

2. Керівництво й управління виконанням плану проекту: входи, інструменти і методи, виходи

Блок-схема даних при керівництві й управлінні виконанням проекту

Входи Керівництво й управління виконанням проекту:

1 План управління проектом. Розглянуто раніше

2 Схвалені запити на зміну

Для схвалених запитів на зміну команда проекту складає розклад реалізації.

Схвалені запити на зміну - це документовані, санкціоновані зміни, що розширюють або скорочують зміст проекту.

Схвалені запити на зміну також можуть змінювати правила, план управління проектом, процедури, витрати або бюджети або змінювати розклади.

Схвалені запити на зміну можуть призвести до виконання попереджуючих або коригувальних дій.

Входи Керівництво й управління виконанням проекту (продовження):

3 Фактори середовища підприємства, які можуть впливати на процес керівництва й управління виконанням проекту, містять у собі:

• культуру й структуру організації, компанії або замовника;

• інфраструктуру (наприклад, споруди що існують й обладнання);

• управління персоналом (наприклад, директиви по найму й звільненню, оцінки ефективності роботи співробітників і документи про навчання);

• готовність зацікавлених сторін проекту приймати ризики;

• інформаційні системи управління проектами (наприклад, програмне забезпечення для управління розкладом, система управління конфігурацією, система збору й розподілу інформації або веб-інтерфейси до інших автоматизованих систем, що працюють у режимі онлайн).

Входи Керівництво й управління виконанням проекту (продовження):

4 Активи процесів організації, які можуть впливати на процес керівництва й управління виконанням проекту, містять у собі:

• типові провідні вказівки й робочі інструкції;

• вимоги по обміну інформацією, що визначають допустимі середовища передачі даних, вимоги по збереженню записів і безпеки;

• процедури управління проблемами й дефектами, що визначають засоби контролю проблем і дефектів, виявлення й розв’язання проблем і дефектів, а також відстеження питань, що вимагають рішення;

• базу даних вимірювань процесів, використовувану для збору й забезпечення доступу до даних вимірювань по процесах і продуктах;

• архіви по попередніх проектах (наприклад, базові плани по змісту, вартості, розкладу й вимірювання виконання, календарі проектів, сітьові діаграми проекту, реєстри ризиків, заплановані відповідні дії й певні наслідки ризиків);

• базу даних по управлінню проблемами й дефектами, що містить історичні відомості про статус проблем і дефектів, інформацію про управління, дані про розв’язання проблем і усунення дефектів, а також результати розв’язання проблем.

Інструменти й методи Керівництво й управління виконанням проекту:

1 Експертні оцінки використовуються для оцінювання входів, необхідних для керівництва й управління виконанням плану управління проектом.

Подібні оцінки й експертизи застосовуються у відношенні всіх технічних і управлінських деталей протягом даного процесу.

Така експертиза проводиться менеджером проекту й командою управління проектом з опорою на спеціальні знання або підготовку.

Додаткова експертиза може бути отримана з різних джерел, включаючи такі:

• інші підрозділи в рамках організації;

• консультанти;

• зацікавлені сторони проекту, у тому числі замовники або спонсори;

• професійні й технічні асоціації.

Інструменти й методи Керівництво й управління виконанням проекту (продовження):

2 Інформаційна система управління проектами, будучи одним із факторів середовища підприємства, надає доступ до автоматизованих засобів, таких як програмне забезпечення для управління розкладом, система управління конфігурацією, система збору й розподілу інформації або веб-інтерфейси інших автоматизованих систем, що працюють у режимі онлайн, використовуваних під час робіт з керівництва й управління виконанням проекту.

Виходи Керівництво й управління виконанням проекту:

1 Результати

Схвалений результат - це будь-якій унікальний продукт і, продукт, що піддається перевірці, результат або здатність здійснити послугу, яка (ий) повинен (на) бути зроблений (на) для завершення процесу, фази або проекту.

2 Інформація про виконані роботи

У міру просування проекту регулярно збирається інформація про його операції. Така інформація може належати до різних результатів виконання, включаючи:

• статус результату;

• хід виконання розкладу;

• понесені витрати.

Виходи Керівництво й управління виконанням проекту (продовження):

3. Запити на зміну Якщо при виконанні робіт із проекту виникають проблеми, випускаються запити на зміну, які можуть змінювати правила або процедури проекту, його зміст, вартість або бюджет, розклад проекту або його якість.

Інші запити на зміну включають попереджувальні або коригувальні дії, що дозволяють запобігти негативному впливові на проект у майбутньому.

Виходи Керівництво й управління виконанням проекту (продовження):

Запити на зміну можуть бути прямими або непрямими, ініційованими ззовні або зсередини, необов'язковими або обов'язковими за законом або контактом, а також можуть містити:

• Коригувальний вплив. Документована вказівка для виконання робіт з метою приведення у відповідність очікуваного майбутнього виконання робіт із проекту із планом управління проектом.

• Попереджувальна дія. Документована вказівка здійснити дію, що може знизити ймовірність негативних наслідків, пов'язаних з ризиками проекту.

• Виправлення дефекту. Формально документоване виявлення дефекту в елементі проекту, що містить рекомендації або про виправлення дефекту, або про повну заміну елемента.

• Відновлення. Зміни у формально контрольованій документації, планах і т.д., що відображають модифіковані або додаткові ідеї або зміст.

Виходи Керівництво й управління виконанням проекту (продовження):

4 Оновлення плану управління проектом

Елементи плану управління проектом, які можуть бути оновлені, містять у собі:

• план управління вимогами;

• план управління розкладом;

• план управління вартістю;

• план управління якістю;

• план управління людськими ресурсами;

• план управління комунікаціями;

• план управління ризиками;

• план управління закупівлями;

• базові плани проекту.

Виходи Керівництво й управління виконанням проекту (закінчення):

5 Оновлення документів проекту

Документи проекту, які можуть бути оновлені, містять у собі:

• документацію по вимогах;

• журнали проекту (проблем, припущень і т.д.);

• реєстр ризиків;

• Реєстр зацікавлених сторін проекту.

4. Моніторинг і управління роботами проекту

Моніторинг і управління роботами проекту – це процес відстеження, перевірки й регулювання виконання для досягнення цілей проекту, визначених у плані управління проектом.

Моніторинг - це аспект управління проектом, здійснюваний протягом усього проекту.

Моніторинг містить у собі збір, вимірювання і розподіл інформації про виконання, а також оцінку вимірювань і тенденцій для впливу на поліпшення процесу.

Постійний моніторинг дає команді управління проектом можливість розуміти загальний стан проекту й визначати, на які області варто звернути особливу увагу.

Управління містить у собі визначення коригувальних або попереджуючих дій, або повторне планування й відстеження планів з метою визначити, чи вдалося розв’язати проблему за допомогою початих дій.

Моніторинг і управління роботами проекту: входи, інструменти і методи, виходи

Блок-схема даних при моніторингу й управлінні роботами проекту

Входи Моніторинг і управління роботами проекту:

1. План управління проектом (розглянуто раніше)

2. Звіти про виконання, що складаються командою проекту, повинні містити детальний опис робіт, досягнень, контрольних подій, виявлених питань і проблем. Звіти про виконання можуть використовуватися для повідомлення ключової інформації, що включає:

• поточний статус;

• істотні досягнення за зазначений період часу;

• внесені в розклад операції;

• прогнози;

• проблеми.

Входи Моніторинг і управління роботами проекту:

3. Фактори середовища підприємства, які можуть впливати на процес моніторингу й управління роботами проекту, містять у собі:

• державні й промислові стандарти (наприклад, розпорядження контролюючих органів, стандарти на продукцію, стандарти якості й стандарти виготовлення);

• корпоративну систему санкціонування виконання робіт;

• готовність зацікавлених сторін проекту приймати ризики;

• інформаційні системи управління проектами (наприклад, автоматизовані системи, такі як програмне забезпечення для управління розкладом, система управління конфігурацією, система збору й розподілу інформації або веб- інтерфейси до інших автоматизованих систем, що працюють у режимі онлайн).

Входи Моніторинг і управління роботами проекту:

4 Активи процесів організації

Активи процесів організації, які можуть впливати на процес моніторингу й управління роботами проекту, містять у собі серед іншого:

• вимоги організації до обміну інформацією;

• процедури фінансового контролю (наприклад, звітність за часом, коди бухгалтерського обліку, аналіз видатків і витрат і стандартні положення контрактів);

• процедури розв’язання проблем і усунення дефектів;

• процедури управління ризиками, включаючи категорії ризиків, визначення ймовірності й наслідків, а також матрицю ймовірності й наслідків;

• базу даних вимірювань процесів, використовувану для забезпечення доступу до даних вимірів по процесах і продуктах;

• базу засвоєних уроків.

Інструменти й методи Моніторинг і управління роботами проекту:

1. Експертні оцінки

Експертні оцінки використовуються командою управління проекту для інтерпретації інформації, одержуваної в результаті процесів моніторингу й управління.

Менеджер проекту разом з командою визначає дії, необхідні для забезпечення того, щоб виконання проекту відповідало очікуванням.

Виходи Моніторинг і управління роботами проекту:

1.Запити на зміну У результаті порівняння запланованих результатів з фактичними можуть випускатися запити на зміну, які можуть розширити, скоригувати або скоротити проект або зміст продукту.

Зміни можуть впливати на план управління проектом, документи або результати проекту. Зміни можуть містити в собі серед іншого:

• Коригувальний вплив. Документована вказівка для виконання робіт із проекту для приведення очікуваного майбутнього виконання робіт із проекту у відповідність із планом управління проектом.

• Попереджуюча дія. Документована вказівка здійснити дію, що може знизити ймовірність негативних наслідків, пов'язаних з ризиками проекту.

• Виправлення дефекту. Формально документоване виявлення дефекту в елементі проекту, що містить рекомендації або про виправлення дефекту, або про повну заміну елемента.

Виходи Моніторинг і управління роботами проекту:

2. Відновлення плану управління проектом

Елементи плану управління проектом, які можуть бути оновлені, містять у собі серед іншого:

• план управління розкладом;

• план управління вартістю;

• план управління якістю;

• базовий план по змісту;

• базовий розклад;

• базовий план виконання вартості.

3. Відновлення документів проекту

Документи проекту, які можуть бути оновлені, містять у собі серед іншого:

• прогнози;

• звіти про виконання;

• журнал проблем.

5. Загальне управління змінами

Загальне управління змінами – процес перевірки всіх запитів на зміну, їхні затвердження й управління змінами результатів, активів процесів організації, документів проекту й плану управління проектом.

Процес загального управління змінами проводиться із самого початку проекту й аж до його завершення.

План управління проектом, опис змісту проекту та інші результати підтримуються шляхом проведення ретельного й постійного управління змінами - відхилення або схвалення змін, що дозволяє гарантувати, що в переглянутий базовий план включаються тільки схвалені зміни.

Процес загального управління змінами містить у собі такі дії по управлінню змінами, представлені на різних рівнях деталізації залежно від ходу виконання проекту:

• вплив на фактори, які можуть обійти загальне управління змінами, для того, щоб упроваджувалися у виконання тільки схвалені зміни;

• своєчасний огляд, аналіз і схвалення запитів на зміну, що представляє виняткову важливість, тому що повільні рішення можуть негативно вплинути на строки, вартість або здійсненність змін;

• управління схваленими змінами;

• підтримка цілісності базових планів шляхом включення в план управління проектом і документи проекту тільки схвалених змін;

• аналіз, схвалення або відхилення всіх рекомендованих коригувальних і попереджуючих дій;

• координація змін усього проекту (наприклад, запропонована зміна розкладу найчастіше впливає також і на вартість, ризики, якість і забезпечення персоналом);

• документування повного впливу запитів на зміну.

Запит на зміну може подати будь-яка зацікавлена сторона, залучена у проект. Хоча зміни можуть бути ініційовані усно, вони обов'язково повинні бути зареєстровані в писаній формі й передані в систему управління змінами й/або управління конфігурацією.

Запити на зміни піддаються процесам, зазначеним у системах управління змінами й управління конфігурацією. Ці процеси, пов'язані із запитами на зміну, можуть вимагати інформацію про очікуваний вплив на строки й на вартість.

Кожний задокументований запит на зміну або схвалюється, або відхиляється якоюсь уповноваженою особою з команди управління проектом або сторонньої організації. У багатьох проектах менеджер проекту наділений повноваженнями схвалювати певні види запитів на зміну, що зазначено в документах про ролі й обов'язки в рамках проекту.

За необхідності процес здійснення загального управління змінами містить у собі раду по управлінню змінами (change control board, CCB), відповідальну за схвалення або відхилення запитів на зміну. Ролі й обов'язки таких рад чітко визначаються в рамках процедур управління конфігурацією й управління змінами й узгоджуються з відповідними зацікавленими сторонами проекту. Багато великих організацій розробляють багаторівневі структури, що розділяють обов'язки між радами.

Якщо проект реалізується за контрактом, то деякі запропоновані зміни можуть вимагати схвалення замовником, що вказується в контракті. Схвалені запити на зміну можуть зажадати створення нових або перегляду старих оцінок вартості, послідовностей операцій, дат розкладу, потреб у ресурсах і аналізу альтернатив реагування на ризики. Ці зміни можуть зажадати внесення виправлень у план управління проектом або в інші плани/документи проекту. Застосовуваний рівень управління змінами залежить від прикладної області, складності конкретного проекту, вимог контракту, а також контексту й середовища, у яких здійснюється проект.

Система управління конфігурацією розом із загальним управлінням змінами створює стандартизований, ефективний і діючий спосіб централізованого управління схваленими змінами й базовими планами в рамках проекту.

Управління конфігурацією сконцентровано на деталізації результатів і процесів, тоді як управління змінами зосереджено на виявленні, документуванні й контролюванні змін проекту й базових планів продукту.

Застосування системи управління конфігурацією, що включає процеси управління змінами, у рамках усього проекту розв'язує три основні задачі:

• установлює метод, що розвивається, який дозволяє послідовно виявляти й запитувати зміни для створених базових планів, а також оцінювати цінність і ефективність даних змін;

• надає можливості для постійного підтвердження й поліпшення проекту шляхом розгляду впливів кожної зміни;

• забезпечує механізм, що дозволяє команді управління проектом узгоджено повідомляти зацікавлені сторони проекту про всі схвалені й відхилені зміни.

Деякі дії по управлінню конфігурацією, що входять у процес здійснення загального управління змінами:

• Визначення конфігурації. Вибір і визначення елементів конфігурації створює базис, виходячи з якого визначається й підтверджується конфігурація продукту, маркіруються продукти й документи, здійснюється управління змінами, і підтримується підзвітність.

• Звітність по статусу конфігурації. При необхідності надання відповідних даних про елемент конфігурації інформація документується, і по ній складається звіт. Така інформація включає список схвалених ідентифікацій конфігурації, статус запропонованих змін конфігурації й статус реалізації схвалених змін.

• Підтвердження й перевірка конфігурації. Підтвердження й перевірки конфігурації дозволяють переконатися, що структура елементів конфігурації проекту є вірною, а відповідні зміни зареєстровані, оцінені, схвалені, відслідковані й належним чином реалізовані. Це гарантує дотримання функціональних вимог, визначених у документації по конфігурації.

Входи, інструменти, методи й виходи Загальне управління змінами:

Блок-схема даних у процесі здійснення загального управління змінами

Входи Загальне управління змінами:

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).

Цей перелік, звичайно, може бути доповнений з огляду на специфіку проекту.

Деякі пояснення - Результати

- Визначення ймовірності виникнення ризиків і їхніх впливів. Сумлінний і достовірний якісний аналіз ризиків припускає визначення різних рівнів імовірності виникнення ризиків і їхніх впливів. Загальні визначення рівнів імовірності й впливи адаптуються до конкретного проекту в ході процесу планування управління ризиками й використовуються потім у ході процесу якісного аналізу ризиків На наступному слайді наведений приклад визначень негативного впливу, які можуть бути використані при оцінці впливу ризиків, пов'язаних із чотирма цілями проекту. (Подібні таблиці можуть бути створені й відносно позитивних впливів).

Визначення шкал впливу для чотирьох цілей проекту

Деякі пояснення - Результати

- Матриця ймовірності й впливу. Пріоритети між ризиками розставляються відповідно до їхніх імовірних наслідків, які можуть впливати на цілі проекту. Типовим способом розташування ризиків по пріоритету є використання таблиці відповідності або матриці ймовірності й впливу Звичайно організація сама встановлює сполучення ймовірності й впливу, на підставі яких ступінь ризику визначається як «висока», «середня» або «низька», що у свою чергу визначає значимість ризику для планування реагування на даний ризик.

-

Для оцінювання ризиків прийнята шкала вимірювання ризиків

Для цього слід обрати інтервал ймовірності і присвоїти йому числове значення. Існують трирівневі та семирівневі (більш деталізовані) розподіли ймовірності проектного ризику.

Окрім цього ймовірність ризику в проекті може оцінюватися в грошових одиницях чи за певною суб’єктивною шкалою

Трирівневий розподіл ймовірності ризику

П’ятирівневий розподіл ймовірності ризику в грошовому вимірі

Відносна шкала наслідків містить лише описові позначення, наприклад «дуже низький», «низький», «середній», «високий» і «дуже високий», які розташовані в порядку зростання максимальної сили впливу ризику згідно з визначенням організації

Деякі пояснення - Результати

- Уточнена готовність зацікавлених сторін проекту приймати ризики. У ході процесу планування управління ризиками готовність зацікавлених сторін проекту приймати ризики може коректуватися стосовно до конкретного проекту.

- Формат звітності. Містить визначення, у який спосіб провадиться документування, аналіз і обмін інформацією про результати процесів управління ризиками. Дає опис змісту й формату реєстру ризиків, а також інших необхідних звітів по ризиках.

- Відстеження. Документує порядок реєстрації всіх операцій по ризиках для цілей даного проекту, а також для майбутніх проектів і включення в документи по накопичених знаннях. Документує, у яких випадках і у який спосіб буде проводитися аудит процесів управління ризиками.

Організація може використовувати розроблену заздалегідь схему категоризації типових ризиків, що може приймати форму простого списку категорій або оформлятися у вигляді ієрархічної структури ризиків. Ієрархічна структура ризиків - це ієрархічно організоване зображення певних ризиків проекту, згрупованих по категоріях і підкатегоріях, що визначає різні області й причини потенційних ризиків.

В управлінні ризиками проекту прийняті такі категорії ризиків:

1) стратегічні/комерційні (ST/COM);

2) економічні/фінансові (EC/FIN);

3) організаційні (організація, менеджмент, людський фактор) (ORG);

4) політичні (POL);

5) навколишнього середовища (ENV);

6) технічні (TECH).

Цей перелік, звичайно, може бути доповнений з огляду на специфіку проекту.

Приклад Ієрархічної структури ризиків

3. Ідентифікація ризиків

Ідентифікація ризиків визначає, які ризики здатні вплинути на проект, і документує характеристики цих ризиків.

Ідентифікація ризиків не буде ефективною, якщо вона не буде проводитися регулярно у ході проекту.

Ідентифікація ризиків повинна залучати щонайбільше учасників: менеджерів проекту, замовників, користувачів, незалежних фахівців.

Ідентифікація ризиків - ітераційний процес.

Спочатку ідентифікація ризиків може бути виконана частиною менеджерів проекту або групою аналітиків ризиків. Далі ідентифікацією може займатися основна група менеджерів проекту. Для формування об'єктивної оцінки в завершальній стадії процесу можуть брати участь незалежні фахівці. Можливе реагування може бути визначене протягом процесу ідентифікації ризиків.

Анкета ідентифікації ризиків

Ідентифікація ризиків: входи, інструменти, методи і виходи

УПРАВЛІННЯ РИЗИКАМИ В ПРОЕКТАХ ІНФОРМАТИЗАЦІЇ

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) описані шість процедур управління ризиками.

Управління проектними ризиками — це, перш за усе, здатність вирішувати:

- що робити з їх проявами;

- коли робити це;

- чи достатньо було зроблено для їх подолання.

Управління ризиками є неперервним процесом, який відбувається на всіх фазах ЖЦ проекту.

Ціль управління проектними ризиками -підвищення ймовірності позитивних для цілей проекту подій і зниження ймовірності несприятливих подій.

Управління ризиками на протязі ЖЦ проекту

Слід зазначити, що управління ризиками нині — недостатньо популярна практика в управлінні проектами. А дарма!

У ситуації, коли бюджет строго встановлений, ресурси лімітовані, найгостріше відчувається необхідність у формалізованому управлінні ризиками.

Тому в останній версії PMBOK, розділи що регламентують процедури управління ризиками розширені і містять більш детальний опис процесів, пов'язаних з управлінням ризиками у проектах.

Процес управління ризиками проекту за РМВОК4 включає:

• Планування управління ризиками - вибір підходів і планування діяльності по управлінню ризиками проекту.

• Ідентифікація ризиків - визначення ризиків, здатних вплинути на проект, і документування їхніх характеристик.

• Якісна оцінка ризиків - якісний аналіз ризиків і умов їхнього виникнення з метою визначення їхнього впливу на успіх проекту.

• Кількісна оцінка - кількісний аналіз імовірності виникнення й впливи наслідків ризиків на проект.

• Планування реагування на ризики - визначення процедур і методів по ослабленню негативних наслідків ризикових подій і використанню можливих переваг.

• Моніторинг і контроль ризиків - моніторинг ризиків, визначення ризиків, що залишаються, виконання плану управління ризиками проекту й оцінка ефективності дій по мінімізації ризиків.

Ці процеси взаємозалежні один з одним, а також із процесами з інших галузей знань. Залежно від потреб проекту в кожному процесі можуть брати участь одна або кілька осіб. Кожний процес відбувається в кожному проекті не менш одного разу й виконується в одній або кількох фазах проекту, якщо проект розбитий на фази. Хоча процеси представлені тут у вигляді дискретних елементів із чітко означеними границями, на практиці вони накладаються один на одного й впливають; такі накладення й взаємозв'язки тут не описані

2. Планування управління ризиками

Планування управління ризиками - процес прийняття рішень по застосуванню й плануванню управління ризиками для конкретного проекту.

Цей процес може містити в собі рішення по організації, кадровому забезпеченню процедур управління ризиками проекту, вибір кращої методології, джерел даних для ідентифікації ризику, часовий інтервал для аналізу ситуації.

Важливо спланувати управління ризиками, адекватне як рівню й типу ризику, так і важливості проекту для організації.

1. Планування управління ризиками: входи, інструменти, методи і виходи

Деякі пояснення – Вхідні дані

1 Опис змісту проекту надає чітке розуміння діапазону можливостей, пов'язаних з проектом і його результатами ,а також встановлює рамки того, наскільки значними можуть виявитися зусилля по управлінню ризиками

2 План управління вартістю визначає порядок складання звітів з бюджетних ризиків, можливих втрат і управлінських резервів, а також порядок надання доступу до них.

3 План управління розкладом визначає порядок складання звітів з можливих відхилень від розкладу і порядок їх оцінювання

.4 План управління комунікаціями проекту визначає взаємодії, що будуть мати місце протягом виконання проекту, а також встановлює, хто буде доступний для розповсюдження інформації по різних ризиках і реагуванню на них у різний час (і в різних місцях).

Деякі пояснення – Вхідні дані (закінчення)

5 Фактори середовища підприємства, які можуть вплинути на процес планування управління ризиками, включають, серед іншого, ставлення до ризиків і готовність приймати ризики, яка описує ступінь ризику, котру може витримати організація.

6 Активи процесів організації, що можуть вплинути на процес планування управління ризиками, включають, серед іншого:

• категорії ризиків;

• загальні визначення понять і термінів;

• формати опису ризиків;

• стандартні шаблони;

• ролі та відповідальності;

• рівні повноважень для прийняття рішень;

• накопичені знання; і

• реєстри зацікавлених сторін проекту, які теж є важливими ресурсами і які слід розглядати як елементи процесу створення ефективних планів управління ризиками.

Деякі пояснення - Інструменти і методи

1 Наради по плануванню й аналіз. У нарадах можуть брати участь менеджер проекту, окремі члени команди проекту й зацікавлені сторони проекту, представники організації, відповідальні за дії по плануванню ризиків і реагуванню на них, і, при необхідності, інші особи.

На таких нарадах складаються високорівневі плани дій по управлінню ризиками. Також розробляються елементи вартості й заплановані дії по управлінню ризиками, які включаються відповідно в бюджет і розклад проекту.

Можуть визначатися або переглядатися підходи до використання резервів на можливі втрати й ризиків. Розподіляється відповідальність по управлінню ризиками. Наявні в організації загальні шаблони, що стосуються категорій ризиків і визначення термінів (наприклад, рівні ризику, імовірність виникнення ризиків по типах, вплив ризиків по типах цілей, а також матриця ймовірності й впливи), адаптуються до конкретного проекту з урахуванням його специфіки. Якщо шаблонів для інших кроків процесу не існує, вони можуть бути створені в ході даних нарад. Виходи цих операцій поєднуються в плані управління ризиками.

Деякі пояснення - Результати

1 план управління ризиками описує структуру й порядок здійснення управління ризиками в рамках проекту. Цей план включається до складу плану управління проектом і містить такі елементи:

- Методологія. Визначення підходів, інструментів і джерел даних, які можуть використовуватися для управління ризиками в даному проекті.

- Ролі й відповідальності. Визначення керівних і допоміжних членів команди, а також членів команди, відповідальних за управління ризиками, для кожного виду операцій, включених у план управління ризиками, і роз'яснення їхньої відповідальності.

- Розробка бюджету. Призначення ресурсів і оцінка коштів, необхідних для управління ризиками (ці дані включаються в базовий план виконання вартості), а також розробка процедур по використанню резерву на можливі втрати.

Деякі пояснення - Результати

- Визначення строків. Визначення строків і частоти виконання процесів управління ризиками протягом усього життєвого циклу проекту, розробка процедур по використанню резервів розкладу на можливі втрати, а також визначення дій по управлінню ризиками, які будуть включені в розклад проекту.

• Категорії ризиків. Визначення структури, на підставі якої провадиться систематична й всебічна ідентифікація ризиків з потрібним ступенем деталізації; така структура сприяє підвищенню ефективності і якості ідентифікації ризиків.

Деякі пояснення - Результати

• Визначення ймовірності виникнення ризиків і їхніх впливів. Сумлінний і достовірний якісний аналіз ризиків припускає визначення різних рівнів імовірності виникнення ризиків і їхніх впливів. Загальні визначення рівнів імовірності й впливи адаптуються до конкретного проекту в ході процесу планування управління ризиками й використовуються потім у ході процесу якісного аналізу ризиків.

Для оцінювання ризиків прийнята шкала вимірювання ризиків

Для встановлення шкали оцінювання слід обрати інтервал ймовірності і присвоїти йому числове значення. Існують трирівневі та семирівневі (більш деталізовані) розподіли ймовірності проектного ризику.

Окрім цього ймовірність ризику в проекті може оцінюватися в грошових одиницях чи за певною суб’єктивною шкалою

Трирівневий розподіл ймовірності ризику

П’ятирівневий розподіл ймовірності ризику в грошовому вимірі

Деякі пояснення - Результати

- Матриця ймовірності й впливу. Пріоритети між ризиками розставляються відповідно до їхніх імовірних наслідків, які можуть впливати на меті проекту. Типовим способом розташування ризиків по пріоритету є використання таблиці відповідності або матриці ймовірності й впливу Звичайно організація сама встановлює сполучення ймовірності й впливу, на підставі яких ступінь ризику визначається як «висока», «середня» або «низька», що у свою чергу визначає значимість ризику для планування реагування на даний ризик.

-

Визначення шкал впливу для чотирьох цілей проекту

Визначення шкал впливу для чотирьох цілей проекту

На попередньому слайді наведено приклад визначень негативного впливу, які можуть бути використані при оцінці впливу ризиків, пов'язаних із чотирма цілями проекту.

Подібні таблиці можуть бути створені й відносно позитивних впливів.

Деякі пояснення - Результати

- Уточнена готовність зацікавлених сторін проекту приймати ризики. У ході процесу планування управління ризиками готовність зацікавлених сторін проекту приймати ризики може коректуватися стосовно до конкретного проекту.

- Формат звітності. Містить визначення, у який спосіб провадиться документування, аналіз і обмін інформацією про результати процесів управління ризиками. Дає опис змісту й формату реєстру ризиків, а також інших необхідних звітів по ризиках.

- Відстеження. Документує порядок реєстрації всіх операцій по ризиках для цілей даного проекту, а також для майбутніх проектів і включення в документи по накопичених знаннях. Документує, у яких випадках і у який спосіб буде проводитися аудит процесів управління ризиками.

Організація може використовувати розроблену заздалегідь схему категоризації типових ризиків, що може приймати форму простого списку категорій або оформлятися у вигляді ієрархічної структури ризиків. Ієрархічна структура ризиків - це ієрархічно організоване зображення певних ризиків проекту, згрупованих по категоріях і підкатегоріях, що визначає різні області й причини потенційних ризиків.

Приклад Ієрархічної структури ризиків

3. Ідентифікація ризиків

Ідентифікація ризиків визначає, які ризики здатні вплинути на проект, і документує характеристики цих ризиків.

Ідентифікація ризиків не буде ефективною, якщо вона не буде проводитися регулярно у ході проекту.

Ідентифікація ризиків повинна залучати щонайбільше учасників: менеджерів проекту, замовників, користувачів, незалежних фахівців.

Ідентифікація ризиків - ітераційний процес.

Спочатку ідентифікація ризиків може бути виконана частиною менеджерів проекту або групою аналітиків ризиків. Далі ідентифікацією може займатися основна група менеджерів проекту. Для формування об'єктивної оцінки в завершальній стадії процесу можуть брати участь незалежні фахівці. Можливе реагування може бути визначене протягом процесу ідентифікації ризиків.

Анкета ідентифікації ризиків

Ідентифікація ризиків: входи, інструменти, методи і виходи

Деякі пояснення: Ідентифікація ризиків: входи

1 План управління ризиками. Ключовими входами процесу ідентифікації ризиків, одержуваними із плану управління ризиками, є схема розподілу ролей і відповідальності, резерв на дії по керуванню ризиками, передбачений у бюджеті й розкладі, а також категорії ризиків. Ці дії іноді знаходять своє відбиття в ієрархічній структурі ризиків

2 Оцінка вартості операцій. Перегляд оцінки вартості операцій корисний для ідентифікації ризиків, так вона надає кількісну оцінку найбільш імовірної вартості виконання запланованих операцій і в ідеалі виражається у вигляді діапазону, ширина якого вказує на ступінь ризику. Подібна перевірка дозволяє визначити, достатня чи ні (що створює ризик для проекту) оцінка для виконання операції.

Деякі пояснення: Ідентифікація ризиків: входи

3 Оцінка тривалості операцій. Перегляд оцінки тривалості операцій корисний при визначенні ризиків, пов'язаних з часовими обмеженнями операцій або всього проекту; ширина діапазону подібної оцінки також демонструє відносний ступінь ризику.

4 Базовий план по змісту. Допущення проекту приводяться в описі змісту проекту. Невизначеність у допущеннях проекту варто розглядати як потенційне джерело виникнення ризиків проекту.

ІСР (WBS) є найважливішим входом для ідентифікації ризиків, оскільки вона сприяє розумінню потенційних ризиків як на мікро, так і на макро рівні. Ризики можуть ідентифікуватися й згодом відслідковуватися на загальному рівні або на рівнях контрольних рахунків і/або пакетів робіт.

Деякі пояснення: Ідентифікація ризиків: входи

5 Реєстр зацікавлених сторін проекту. Інформація про зацікавлені сторони проекту корисна для одержання входів для ідентифікації ризиків, оскільки при цьому забезпечується, що серед ключових зацікавлених сторін проекту, особливо замовників, будуть проведені опитування, або вони зможуть яким-небудь іншим способом взяти участь у процесі ідентифікації ризиків.

6 План управління вартістю. Процес ідентифікації ризиків вимагає розуміння планів управління вартістю, які приводяться в плані управління проектом. Конкретний для кожного проекту підхід до управління вартістю в силу свого характеру або структури може створювати або знижувати ризики.

Деякі пояснення: Ідентифікація ризиків: входи

7 План управління розкладом. Процес ідентифікації ризиків також вимагає розуміння плану управління розкладом, що приводиться в плані управління проектом. Конкретний для кожного проекту підхід до управління розкладом у силу свого характеру або структури може створювати або знижувати ризики.

8 План управління якістю. Процес ідентифікації ризиків вимагає розуміння плану управління якістю, що приводиться в плані управління проектом. Конкретний для кожного проекту підхід до управління якістю в чинність свого характеру або структури може створювати або знижувати ризики.

Деякі пояснення: Ідентифікація ризиків: входи

9 Документи проекту містять у собі, серед іншого:

• журнал допущень;

• звіти про виконання робіт;

• звіти про освоєний обсяг;

• сітьові діаграми;

• базові плани; і

• іншу проектну інформацію, що є цінною для ідентифікації ризиків.

Деякі пояснення: Ідентифікація ризиків: входи

10 Фактори середовища підприємства, які можуть впливати на процес ідентифікації ризиків, містять у собі, серед іншого:

• опубліковану інформацію, включаючи комерційні бази даних;

• академічні дослідження;

• опубліковані контрольні списки;

• бенчмаркинг;

• промислові дослідження; і

• ставлення до ризиків.

Деякі пояснення: Ідентифікація ризиків: входи

11 Активи процесів організації, які можуть впливати на процес ідентифікації ризиків, містять у собі, серед іншого:

• проектні архіви, включаючи фактичні дані;

• елементи управління процесами проекту й організації;

• шаблони описів ризиків; і

• накопичені знання.

Деякі пояснення: Ідентифікація ризиків: інструменти й методи

1 Аналіз документації

Можна здійснювати структурований аналіз документації по проекту, включаючи плани, допущення, архіви попередніх проектів, контракти й інші джерела. Якість планів, а також погодженість планів і їхня відповідність вимогам і допущенням проекту можуть служити показниками можливості ризиків у проекті.

Деякі пояснення: Ідентифікація ризиків: інструменти й методи

2 Методи збору інформації:

Мозковий штурм. Метою мозкового штурму є створення всеосяжного списку ризиків проекту. Як правило, мозковий штурм проводить команда проекту, часто за участю ряду експертів з різних областей, що не є членами команди. За основу може прийматися система категорій ризиків, наприклад ієрархічна структура ризиків. Далі ризики підлягають ідентифікації й категоризації по типах, а їхнє визначення - уточненню.

Метод Дельфи - це спосіб досягнення консенсусу між експертами з питань ризиків проекту, що беруть участь анонімно. За допомогою опитувального аркуша ведучий збирає ідеї про важливі ризики проекту. Складаються резюме відповідей, які потім повертаються експертам для подальших коментарів. Консенсус може бути досягнуто за кілька циклів даного процесу. Метод Дельфи допомагає перебороти необ'єктивність і усуває надлишковий вплив окремих осіб на результат роботи.

Опитування серед досвідчених учасників проекту, зацікавлених сторін проекту або експертів у цій галузі може сприяти ідентифікації ризиків.

Аналіз першопричин являє собою особливий метод визначення проблеми, виявлення основних причин, що призвели до неї, і розробки попереджувальних дій.

Деякі пояснення: Ідентифікація ризиків: інструменти й методи

3 Аналіз контрольних списків, які можуть розроблятися на основі історичної інформації й знань, отриманих у ході виконання попередніх аналогічних проектів або з інших джерел інформації. Хоча контрольний список може бути коротким і простим, неможливо створити вичерпний список. Команда повинна приділяти особливу увагу питанням, які не знайшли свого відбиття в контрольному списку. При завершенні проекту контрольний список варто переглядати з метою внесення в нього нових накопичених знань і поліпшення для використання в майбутніх проектах.

Деякі пояснення: Ідентифікація ризиків: інструменти й методи

4 Аналіз допущень

Кожний проект і кожний визначений ризик проекту задумується й розробляється на підставі ряду гіпотез, сценаріїв і допущень.

Аналіз допущень досліджує обґрунтованість допущень стосовно до проекту. Даний аналіз дозволяє ідентифікувати ризики проекту, що виникають внаслідок неточності, нестабільності, суперечливості або неповноти допущень.

Деякі пояснення: Ідентифікація ризиків: інструменти й методи

5 Методи складання діаграм

До методів відображення ризиків у вигляді діаграм належать:

• Причинно-наслідкові діаграми. Ці графіки, також відомі як діаграми Ишикави або діаграми «риб'ячий кістяк», використовуються для визначення причин виникнення ризиків.

• Блок-схеми процесу або системні діаграми. Цей вид графічного відображення демонструє порядок взаємодії різних елементів системи між собою і їхні причинно-наслідкові зв'язки.

• Діаграми впливу. Графічно представляють ситуації, показуючи причинні впливи, часове впорядкування подій і інші відносини між змінними й результатами.

Деякі пояснення: Ідентифікація ризиків: інструменти й методи

6 Аналіз сильних і слабких сторін, можливостей і загроз

Цей метод дозволяє провести аналіз проекту з погляду кожного з аспектів: сильних і слабких сторін, можливостей і загроз, - що дає більш повне уявлення про ризики проекту.

При використанні цього методу починають із визначення сильних і слабких сторін організації, приділяючи особливу увагу або організації, що виконує проект, або більш широкому сегменту галузі. Дані фактори часто визначаються в ході мозкового штурму. Потім у процесі аналізу сильних і слабких сторін, можливостей і загроз визначають можливості проекту, обумовлені сильними сторонами організації, а також загрози, що з'являються внаслідок її слабких сторін.

За допомогою аналізу сильних і слабких сторін, можливостей і загроз також досліджують, наскільки сильні сторони організації компенсують загрози і які можливості можна використовувати для подолання слабких сторін.

Деякі пояснення: Ідентифікація ризиків: інструменти й методи

7 Експертна оцінка

Ризики можуть бути визначені безпосередньо експертами, що мають відповідний досвід роботи в подібних проектах або сферах бізнесу. Таких експертів повинен визначати менеджер проекту й запрошувати для розгляду всіх аспектів проекту.

Експерти можуть повідомити про можливі ризики на основі свого попереднього досвіду й областей компетенції. Під час даного процесу необхідно враховувати необ'єктивність експертів.

Деякі пояснення: Ідентифікація ризиків: виходи

Головні виходи процесу ідентифікації ризиків, як правило, містяться в реєстрі ризиків.

1 Реєстр ризиків

Основні виходи процесу ідентифікації ризиків - це початкові записи в реєстрі ризиків. В остаточному підсумку, до реєстру ризиків заносяться результати інших процесів управління ризиками в міру їхнього здійснення, що згодом приводить до підвищення рівня й розмаїтості типів інформації, що міститься в реєстрі ризиків.

Підготовка реєстру ризиків починається в процесі ідентифікації ризиків, протягом якого реєстр заповнюється зазначеною на наступному слайді інформацією. Потім ця інформація стає доступною при здійсненні інших процесів, що належать до управління проектом і управління ризиками проекту.

Деякі пояснення: Ідентифікація ризиків: виходи

Реєстр ризиків містить:

Список ідентифікованих ризиків. Ідентифіковані ризики описуються з достатнім ступенем деталізації. У даному списку може використовуватися спрощена структура ризиків, наприклад: може відбутися ПОДІЯ, що ВПЛИНЕ, або за УМОВИ відбудеться ПОДІЯ, що буде мати НАСЛІДОК.

На додаток до списку визначених ризиків для більшої наочності можуть вказуватися першопричини ризиків. Це фундаментальні умови або події, які здатні викликати настання одного або кількох визначених ризиків. Вони повинні реєструватися й використовуватися для допомоги в ідентифікації ризиків у майбутньому в рамках даного й іншого проектів.

Список можливих дій по реагуванню. Іноді в процесі ідентифікації ризиків можуть визначатися можливі дії по реагуванню на них. Такі заходи реагування, якщо вони визначені під час цього процесу, можуть послужити як входи для процесу планування реагування на ризики

Алгоритм аналізу ризиків

4. Якісний аналіз ризиків

Якісний аналіз ризиків - процес розставлення пріоритетів між ризиками для подальшого аналізу або дії за допомогою оцінювання й підсумовування ймовірності їхнього виникнення та впливу.

Можна істотно поліпшити виконання проекту, зосередивши зусилля на ризиках, що мають найвищий пріоритет.

При якісному аналізі ризиків визначають пріоритети ідентифікованих ризиків на підставі ймовірності або можливості їхнього настання, їхній вплив на досягнення цілей проекту у випадку настання, а також з урахуванням ряду інших факторів (наприклад, часових рамок реагування й готовності організації приймати ризики, закладені в обмеженнях проекту за вартістю, термінами, змістом і якістю).

Якісний аналіз ризиків звичайно є швидким і ефективним за вартістю способом розстановки пріоритетів для планування реагування на ризики й, при необхідності, закладає основу для кількісного аналізу ризиків. Процес якісного аналізу ризиків повинен періодично повторюватися протягом життєвого циклу проекту, щоб він постійно відповідав змінам ризиків проекту. Даний процес може привести до виконання кількісного аналізу ризиків або прямо до планування реагування на ризики.

Якісний аналіз ризиків: входи, інструменти, методи і виходи

Деякі пояснення: Якісний аналіз ризиків: входи

1 Реєстр ризиків Розглянуто раніше

2 План управління ризиками

Для виконання якісного аналізу ризиків істотними є такі елементи плану управління ризиками:

• розподіл ролей і відповідальності в управлінні ризиками, бюджетом і запланованими операціями по управлінню ризиками,

• категорії ризиків,

• визначення ймовірності виникнення й впливу,

• матриця ймовірності та впливу й

• уточнена готовність зацікавлених сторін проекту приймати ризики.

Зазвичай, ці входи адаптуються до конкретного проекту в ході процесу планування управління ризиками. Якщо цих входів немає, їх можна розробити в процесі якісного аналізу ризиків.

Деякі пояснення: Якісний аналіз ризиків: входи

3 Опис змісту проекту

У типових або періодично повторюваних проектах з кожним разом розуміння ризиків зростає.

Для проектів, заснованих на останніх досягненнях сучасної техніки або, які вперше використовують якусь технологію, а також для надзвичайно складних проектів характерний високий ступінь невизначеності.

Ступінь невизначеності можна оцінити при вивченні опису змісту проекту.

Деякі пояснення: Якісний аналіз ризиків: входи

4 Активи процесів організації, які можуть впливати на процес якісного аналізу ризиків, містять у собі, серед іншого:

• інформацію із завершених попередніх аналогічних проектів;

• вивчення аналогічних проектів фахівцями з ризиків; і

• бази даних по ризиках, які можуть бути отримані із промислових або приватних джерел.

Деякі пояснення: Якісний аналіз ризиків: інструменти і методи

1 оцінювання ймовірності виникнення й впливу ризиків

Оцінювання ймовірності виникнення ризиків передбачає проведення дослідження можливості настання того або іншого ризику. При оцінці впливу ризику визначається потенційний ефект, який він може зробити на цілі проекту (наприклад, строки, вартість, якість або виконання), включаючи негативний вплив для загроз і позитивний вплив для сприятливих можливостей.

Імовірність і вплив оцінюються для кожного визначеного ризику. Ризики можуть бути оцінені в ході опитувань або нарад з учасниками, яких вибирають залежно від їхньої поінформованості про обговорювані категорії ризиків. У число опитуваних можуть входити члени команди проекту й, у ряді випадків, особи, що не беруть участі в проекті, але широко обізнані з цією галуззю.

Деякі пояснення: Якісний аналіз ризиків: інструменти і методи

Під час опитування або наради оцінюється ступінь імовірності виникнення кожного ризику і його впливу на кожну із цілей проекту.

Також фіксується пояснювальна інформація, у тому числі допущення, що пояснюють установлені рівні ризиків.

Імовірність виникнення й впливу ризиків ранжируються відповідно до визначень, представлених у плані управління ризиками.

Ризики з низьким ступенем імовірності й впливи включаються в список ризиків, за якими надалі ведеться спостереження.

Деякі пояснення: Якісний аналіз ризиків: інструменти і методи

2 Матриця ймовірності й впливу

Розміщення пріоритетів між ризиками для наступного кількісного аналізу й реагування здійснюється на підставі рейтингу ризиків. Звичайно правила рейтингової системи ризиків визначаються організацією заздалегідь перед початком проекту й включаються в активи процесів організації. Правила рейтингової системи ризиків можуть бути адаптовані до конкретного проекту в ході процесу планування управління ризиками.

Деякі пояснення: Якісний аналіз ризиків: інструменти і методи

Оцінювання важливості кожного ризику й, отже, його пріоритету, як правило, здійснюється за допомогою таблиці відповідності або матриці ймовірності й впливу (наступний слайд).

Така матриця визначає комбінації ймовірності й впливу, які дозволяють присвоювати ризикам рейтинги низького, середнього або високого пріоритету.

Область темно-сірого кольору (найвищі чисельні значення) позначає високий рівень ризику, світліша область (найменші числові значення) позначає низький рівень ризику, а найясніша (середнього числового значення) позначає середній рівень ризику.

Деякі пояснення: Якісний аналіз ризиків: інструменти і методи

3 Оцінка якості даних про ризики

Для того щоб результати якісного аналізу ризиків були надійними, необхідні точні й об'єктивні дані. Аналіз якості даних про ризики є методом оцінки корисності даних про ризики для управління ризиками. Аналіз містить у собі вивчення глибини розуміння ризику, а також точності, якості, надійності й повноти даних про ризик. Якщо якість даних неприйнятна, можливо, буде потрібно зібрати більш якісні дані.

Деякі пояснення: Якісний аналіз ризиків: інструменти і методи

4 Категоризація ризиків

Для визначення областей проекту, що мають найбільшу невизначеність, ризики проекту можна категоризувати за джерелом ризику (наприклад, за допомогою ієрархічної структури ризиків), по області проекту, що торкає ризик (наприклад, за допомогою ІСР) або по якомусь іншому критерію (наприклад, по фазі проекту). Ефективну систему реагування на ризики можна розробити на основі угруповання ризиків по їхніх головних причинах.

Деякі пояснення: Якісний аналіз ризиків: інструменти і методи

5 Оцінка терміновості ризиків

Ризики, що вимагають негайного реагування, можуть розглядатися як найбільш термінові для вживання відповідних заходів. Показниками пріоритетності можуть слугувати час реагування на ризик, симптоми й ознаки ризику, а також рейтинг ризику. У деяких якісних аналізах оцінка терміновості ризику може бути об'єднана з ранжируванням ризиків на основі матриці ймовірності й впливу для визначення кінцевого рейтингу серйозності ризику.

Деякі пояснення: Якісний аналіз ризиків: інструменти і методи

6 Експертна оцінка

Для оцінки ймовірності виникнення й впливу кожного ризику з метою визначення його розташування в матриці, показаної на слайді 61, потрібна експертна оцінка.

Експертами, як правило, є особи, що мають досвід участі в подібних проектах, що мали місце в не занадто віддаленому минулому. Крім того, експертами є особи, що займаються плануванням і управлінням конкретного проекту, зокрема відносно специфіки даного проекту. Надійність експертних оцінок часто одержують у ході семінарів або опитувань по зниженню ризиків. Під час даного процесу необхідно враховувати необ'єктивність експертів.

Деякі пояснення: Якісний аналіз ризиків: виходи

Ведення реєстру ризиків починається в процесі ідентифікації ризиків. Відновлення реєстру ризиків на основі інформації, одержуваної в результаті якісного аналізу ризиків, містять у собі:

• Відносне ранжирування або список пріоритетів ризиків проекту.

• Ризики, згруповані по категоріях.

• Причини ризиків або області проекту, що вимагають особливої уваги.

• Список ризиків, що вимагають негайного реагування.

• Список ризиків, що вимагають додаткового аналізу й реагування.

• Список ризиків з низьким пріоритетом, що вимагає спостереження.

• Тенденції результатів якісного аналізу ризиків.

Деякі пояснення: Якісний аналіз ризиків: виходи

Відносне ранжирування або список пріоритетів ризиків проекту. Для класифікації ризиків у відповідності зі значимістю кожного з них може використовуватися матриця ймовірності й впливу. За допомогою комбінацій імовірності настання кожного з ризиків і їхнього впливу на цілі у випадку настання, між ризиками розставляються пріоритети шляхом поділу їх на групи «високого ризику», «середнього ризику» і «низького ризику».

Ризики можуть бути розставлені по пріоритетності окремо для строків, вартості й виконання, оскільки організації можуть по-різному оцінювати значимість цілей проекту.

Потім менеджер проекту може використовувати список ризиків, розставлених по пріоритетності, щоб зосередити особливу увагу на ті з них, які мають високу значимість для проекту, а реагування на них може дати найкращий результат. Опис основи для оцінювання ймовірності й впливу варто включати в перелік оцінених ризиків, оскільки це важливо для проекту.

Деякі пояснення: Якісний аналіз ризиків: виходи

Ризики, згруповані по категоріях. Поділ ризиків по категоріях може розкрити найпоширеніші першопричини ризиків або вказати на області проекту, що вимагають особливої уваги. Виявлення концентрацій ризику дозволяє підвищити ефективність реагування на них.

Причини ризиків або області проекту, що вимагають особливої уваги. Виявлення концентрацій ризику може підвищити ефективність реагування на них.

Список ризиків, що вимагають негайного реагування. Ризики, що вимагають негайного реагування, і ризики, які можуть бути врегульовані пізніше, можна помістити в різні групи.

Деякі пояснення: Якісний аналіз ризиків: виходи

Список ризиків, що вимагають додаткового аналізу й реагування. Деякі ризики можуть зажадати додаткового аналізу, включаючи кількісний аналіз ризиків, або додаткових відповідних дій.

Список ризиків з низьким пріоритетом, що вимагає спостереження. Ризики, які не були оцінені під час процесу якісного аналізу ризиків як важливі, можуть бути внесені в список для постійного спостереження.

Тенденції результатів якісного аналізу ризиків. У міру виконання повторних аналізів можуть виявлятися тенденції розвитку визначених ризиків, що може слугувати підставою для визначення терміновості реагування на них або необхідності їхнього подальшого аналізу.

5. Кількісний аналіз ризиків

Кількісний аналіз ризиків - це процес чисельного аналізу впливу виявлених ризиків на загальні цілі проекту

Кількісна оцінка ризиків

визначає ймовірність виникнення ризиків і вплив наслідків ризиків на проект, що допомагає групі управління проектами вірно приймати рішення й уникати невизначеностей.

Кількісний аналіз ризиків проводиться відносно тих ризиків, які в результаті процесу якісного аналізу були класифіковані як такі, що потенційно й істотно впливають на конфронтуючі вимоги проекту.

У процесі кількісного аналізу ризиків оцінюється вплив цих ризиків у випадку їхнього настання. Він може використовуватися для присвоєння числового рейтингу окремо для кожного із цих ризиків або для оцінювання спільного впливу всіх ризиків на проект.

Даний аналіз також надає кількісний підхід до прийняття рішень в умовах невизначеності.

Як правило, кількісний аналіз ризиків виконується після якісного аналізу ризиків.

У деяких випадках для розробки ефективних заходів реагування на ризики кількісний аналіз ризиків не потрібен.

Вибір методу (методів) аналізу в кожному конкретному проекті визначається наявністю часу й бюджетом, а також потребою в якісній і кількісній констатації ризиків і їхнього впливу.

Кількісний аналіз ризиків: входи, інструменти, методи і виходи

Деякі пояснення: Кількісний аналіз ризиків: входи

1 Реєстр ризиків. Розглянуто раніше

2 План управління ризиками. Розглянуто раніше

3 План управління вартістю

План управління вартістю проекту встановлює формат і критерії планування, структурування, оцінки, розробки бюджету й управління вартістю проекту.

Ці контрольні елементи дозволяють визначити структуру й/або підхід до виконання кількісного аналізу плану по бюджету або за вартістю.

Деякі пояснення: Кількісний аналіз ризиків: входи

4 План управління розкладом проекту встановлює формат і критерії розробки й контролю розкладу проекту.

Ці контрольні елементи й характер самого розкладу дозволяють визначити структуру й/або підхід до виконання кількісного аналізу розкладу.

5 Активи процесів організації, які можуть впливати на процес кількісного аналізу ризиків, містять у собі, серед іншого:

• інформацію із завершених попередніх аналогічних проектів;

• дослідження аналогічних проектів фахівцями з ризиків; і

• бази даних по ризиках, які можуть бути отримані із промислових або приватних джерел.

Деякі пояснення: Кількісний аналіз ризиків: інструменти й методи

1 Методи збору й подання інформації

Опитування. Методи проведення опитувань дозволяють одержати досвід і історичні дані для кількісної оцінки ймовірності й впливу ризиків на цілі проекту. Необхідна інформація залежить від використовуваного типу імовірнісного розподілу. Наприклад, для деяких найбільш широко використовуваних моделей розподілів необхідно зібрати інформацію про оптимістичний (низька ймовірність), песимістичний (висока ймовірність) і найбільш імовірний сценарії. Документування обґрунтувань діапазонів ризиків і допущень є важливим елементом опитувань із приводу ризиків, оскільки ці документи дозволяють зробити висновок про надійність і вірогідність аналізу.

Розподіл ймовірностей. Безперервний розподіл імовірностей, широко використовуваний в моделюванні й імітації, являє собою невизначеність значень, наприклад тривалості запланованих операцій і вартості елементів проекту. Для подання невизначених подій може використовуватися дискретний розподіл, наприклад результати випробування або можливий сценарій дерева рішень.

Деякі пояснення: Кількісний аналіз ризиків: інструменти й методи

.2 Методи кількісного аналізу ризиків і моделювання

До найбільш широко використовуваних методів належать аналітичні підходи, орієнтовані як на подію, так і на проект, у тому числі:

• Аналіз чутливості.

• Аналіз очікуваного грошового значення.

• Моделювання й імітація.

Деякі пояснення: Кількісний аналіз ризиків: інструменти й методи

Аналіз чутливості. Аналіз чутливості допомагає визначити, які ризики мають найбільший потенційний вплив на проект. У процесі аналізу встановлюється, у якому ступені невизначеність кожного елемента проекту відображається на розглянутій цілі проекту, за умови, що всі інші невизначені елементи приймають базові значення. Одним з типових способів відображення результатів аналізу чутливості є діаграма «торнадо», що корисна при порівнянні відносної важливості й впливу змінних, що мають високий ступінь невизначеності, з іншими, більш стабільними змінними.

Деякі пояснення: Кількісний аналіз ризиків: інструменти й методи

Аналіз очікуваного грошового значення - це статистична концепція, що дозволяє розрахувати середній результат, коли в майбутньому можуть відбутися або не відбутися ті або інші сценарії (тобто аналіз в умовах невизначеності).

Аналіз очікуваного грошового значення сприятливих можливостей, як правило, виражається в позитивних величинах, а ризики - у негативних.

Для даного аналізу потрібно нейтральне стосовно ризиків допущення, яке не схильне до надмірного ризику, і навпаки, яке, повністю його не відкидає.

Щоб розрахувати очікуване грошове значення для проекту, необхідно помножити значення кожного можливого результату на ймовірність його настання, а потім скласти разом отримані значення. Найчастіше даний тип аналізу використовується при аналізі дерева рішень.

Деякі пояснення: Кількісний аналіз ризиків: інструменти й методи

Моделювання й імітація. При імітації проекту використовується модель для визначення можливих впливів докладно описаних невизначеностей на результати проекту в цілому. Ітеративна імітація, як правило, проводиться за допомогою методу Монте-Карло. При імітації модель проекту розраховується безліч разів (ітеративно), при цьому для кожної ітерації вхідні значення (наприклад, оцінки вартості й тривалості операцій) вибираються довільно з розподілів ймовірностей цих змінних. У ході ітерацій розраховується розподіл ймовірностей (наприклад, загальна вартість або дата завершення). При аналізі ризиків вартості методом імітування використовується оцінка вартості. При аналізі ризиків розкладу використовується сітьова діаграма розкладу й оцінка тривалості.

Деякі пояснення: Кількісний аналіз ризиків: інструменти й методи

3 Експертна оцінка (в ідеалі залучення експертів, що мають значимий недавній досвід) потрібна для визначення потенційного впливу на вартість і строки для оцінювання ймовірності й визначення входів (наприклад, розподілів ймовірностей) для інструментів.

Експертна оцінка також відіграє певну роль при інтерпретації даних. Експерти повинні бути здатні визначати недоліки інструментів, а також їхні відносні переваги. Експерти можуть визначити придатність певного інструмента з урахуванням можливостей і культури організації.

Деякі пояснення: Кількісний аналіз ризиків: виходи

1 оновлення реєстру ризиків

Провадиться подальше оновлення реєстру ризиків для включення в нього кількісного звіту по ризиках, у якому деталізуються кількісні підходи, виходи й рекомендації. Оновленню підлягають такі основні елементи:

• Імовірнісний аналіз проекту.

• Імовірність досягнення цілей за вартістю й строками.

• Список кількісно визначених ризиків із розставленими пріоритетами.

• Тенденції результатів кількісного аналізу ризиків.

6. Планування реагування на ризики

Планування реагування на відомі ризики - це процес розробки варіантів і дій по розширенню можливостей і зниженню загроз для цілей проекту.

Даний процес йде за процесом якісного аналізу ризиків і процесом кількісного аналізу ризиків (якщо такий здійснювався).

Він містить у собі визначення й призначення особи («відповідального за реагування на ризики»), що бере відповідальність за кожну погоджену й підкріплену бюджетом реакцію на ризик.

При плануванні реагування на ризики розглядаються ризики в порядку їхньої пріоритетності; при необхідності, нові відповідні ресурси й операції додаються в бюджет, розклад і план управління проектом.

Заплановані дії по реагуванню на ризики повинні відповідати серйозності ризиків, бути економічно ефективними в розв'язанні проблеми, реалістичними в контексті проекту й погодженими з усіма залученими сторонами.

Крім того, необхідно, щоб за їхнє виконання відповідало конкретна особа.

Дії по реагуванню на ризики також повинні бути своєчасними.

Часто потрібен вибір найкращого способу реагування на ризики з кількох можливих варіантів.

Планування реагування на ризики: входи, інструменти, методи і виходи

Деякі пояснення: Планування реагування на ризики: входи

1 Реєстр ризиків. У реєстрі ризиків вказуються:

• ідентифіковані ризики;

• першопричини ризиків;

• списки можливих заходів реагування;

• особи, відповідальні за ризики;

• симптоми й ознаки;

• відносний рейтинг або список ризиків проекту, упорядкованих по пріоритетності;

• список ризиків, що вимагають негайного реагування;

• список ризиків, що вимагають додаткового аналізу й реагування;

• тенденції результатів якісного аналізу;

• а також список ризиків з низьким пріоритетом, що вимагає спостереження.

Деякі пояснення: Планування реагування на ризики: входи

2 План управління ризиками. До важливих елементів плану управління ризиками належать:

• розподіл ролей і відповідальності;

• визначення аналізів ризиків;

• строки проведення перевірок (і усунення ризиків, виявлених у ході перевірки); а також

• пороги для низьких, середніх і високих ризиків.

Пороги ризиків допомагають визначити ті ризики, у відношенні яких потрібні особливі заходи реагування.

Існує кілька стратегій реагування на ризики.

Для кожного ризику необхідно вибрати стратегію або комбінацію стратегій, що представляється найбільш ефективною.

Для вибору найбільш адекватного способу реагування на ризики можна скористатися інструментом аналізу ризиків, таким як аналіз дерева рішень. Потім необхідно розробити конкретні заходи щодо впровадження обраної стратегії. Можна визначити основну й запасну стратегії.

На випадок, якщо обрана стратегія виявиться недостатньо ефективною або наступить прийнятий ризик, можна розробити резервний план.

Також необхідно переглянути вторинні ризики (ризики, викликані стратегіями). Часто виділяється резерв на можливі втрати за часом або вартістю. Такий резерв може містити в собі визначення умов, за яких він може використовуватися.

Деякі пояснення: Планування реагування на ризики: інструменти й методи

1 Стратегії реагування на негативні ризики (загрози)

• Відхилення.

• Передача.

• Зниження.

Ці три типові стратегії реагування на появу негативних загроз, або ризиків для досягнення цілей проекту.

• Прийняття.

Ця стратегія, може використовуватися як для негативних ризиків (загроз), так і для позитивних ризиків (сприятливих можливостей).

Деякі пояснення: Планування реагування на ризики: інструменти й методи

Відхилення. Відхилення від ризиків має на увазі зміну плану управління проектом таким чином, щоб повністю виключити загрозу. Менеджер проекту також може захистити цілі проекту від впливу ризиків або змінити ціль, що піддається небезпеці (наприклад, розширити рамки розкладу, змінити стратегію або скоротити зміст). Найбільш радикальною стратегією відхилення є повне закриття проекту. Від деяких ризиків, що виникають на ранній стадії проекту, можна ухилитися шляхом уточнення вимог, одержання інформації, поліпшення комунікацій або проведення експертизи.

Деякі пояснення: Планування реагування на ризики: інструменти й методи

Передача. Для передачі ризику потрібно перекласти весь негативний вплив загрози або його частину, а також відповідальність за реагування на третю сторону.

При передачі ризику відповідальність за управління ним перекладається на іншу сторону; ризик при цьому не усувається.

Передача відповідальності за ризик найбільш ефективна відносно фінансових ризиків.

Передача ризику практично завжди має на увазі виплату премії за ризик стороні, що бере на себе ризик.

Інструменти передачі можуть бути досить різноманітними й містять у собі, серед іншого:

• використання страховки,

• гарантії виконання контракту,

• гарантійні зобов'язання й т.д.

Для передачі відповідальності за визначені ризики іншій стороні можуть використовуватися контракти.

Деякі пояснення: Планування реагування на ризики: інструменти й методи

Зниження ризиків припускає зменшення ймовірності й/або впливу негативної ризикованої події до прийнятних меж.

Розпочаті ранні дії по зменшенню ймовірності настання ризику й/або його впливу в ході проекту часто виявляються більш ефективним, ніж спроби відшкодувань збитку, що вживаються після настання ризику.

Наприклад, впровадження менш складних процесів, проведення більшого числа випробувань або вибір більш надійного постачальника. Також, для зниження може знадобитися розробка прототипу для зменшення ризику розростання масштабів процесу або продукту в порівнянні зі стендовою моделлю. Якщо неможливо зменшити ймовірність, зниження ризику має бути спрямоване на вплив ризику, а саме на ті зв'язки, які визначають серйозність впливу. Наприклад, проектування надмірності в системі може зменшити вагу наслідків відмови основного елемента.

Деякі пояснення: Планування реагування на ризики: інструменти й методи

Прийняття. Застосування даної стратегії обумовлене тим, що рідко вдається усунути всі загрози проекту. Вона вказує на те, що команда проекту вирішила не змінювати план управління проектом для боротьби з ризиком або не здатна визначити якусь іншу підходящу стратегію реагування.

Ця стратегія може бути пасивною або активною.

Пасивне прийняття не вимагає ніяких дій, крім документування стратегії, - команді проекту доведеться мати справу з ризиками в міру їхнього настання.

Найпоширенішою стратегією активного прийняття є встановлення резерву на можливі втрати, включаючи визначені обсяги часу, грошей або ресурсів, що необхідні для усунення ризиків.

Деякі пояснення: Планування реагування на ризики: інструменти й методи

.2 Стратегії реагування на позитивні ризики (сприятливі можливості)

• Використання.

• Розподіл.

• Збільшення.

• Прийняття.

Четверта стратегія, «прийняття», може використовуватися як для негативних ризиків (загроз), так і для позитивних ризиків (сприятливих можливостей).

Деякі пояснення: Планування реагування на ризики: інструменти й методи

Використання. Ця стратегія може бути обрана для реагування на ризики з позитивним впливом, якщо з погляду організації необхідно, щоб дана сприятлива можливість гарантовано була реалізована.

Ця стратегія призначена для усунення невизначеності, пов'язаної з певним позитивним ризиком, за допомогою заходів, що забезпечують появу можливості.

До числа заходів прямого реагування на дану можливість належать: залучення до участі в проекті найбільш талановитого персоналу організації з метою скоротити час, необхідний для його завершення, або забезпечити меншу вартість, ніж планувалося спочатку.

Деякі пояснення: Планування реагування на ризики: інструменти й методи

Розподіл позитивного ризику означає передачу частини або всієї відповідальності за можливість третій стороні, здатній краще інших скористатися в інтересах проекту сприятливою можливістю, що з’явилася.

До числа заходів щодо розподілу належать: утворення партнерств зі спільною відповідальністю за ризики, команд, спеціалізованих компаній або спільних підприємств, які можуть засновуватися з конкретною метою одержання всіма сторонами переваг тієї або іншої можливості .

Деякі пояснення: Планування реагування на ризики: інструменти й методи

Збільшення. Ця стратегія використовується для підвищення ймовірності виникнення й/або позитивного впливу можливості.

Визначення й максимізація ключових факторів, що обумовлюють появу цих позитивних впливів, можуть підвищити ймовірність їхнього настання. Приклади збільшення можливостей містять у собі виділення додаткових ресурсів для операції з метою її раннього завершення.

Прийняття можливості - це бажання скористатися перевагою можливості у випадку її настання без активного переслідування можливості.

Деякі пояснення: Планування реагування на ризики: інструменти й методи

3 Стратегії реагування на можливі втрати

Деякі способи реагування призначені для використання тільки у випадку настання певних подій.

Стосовно деяких ризиків команда проекту може задіяти план реагування на ризики, що може бути уведений у дію тільки при заздалегідь визначених умовах, якщо є впевненість у достатній кількості ознак для виконання плану.

Необхідно визначити й відслідковувати події, які запускають механізм реагування на можливі втрати, наприклад пропуск проміжних контрольних подій або одержання більш високого рівня пріоритетності в постачальника.

Деякі пояснення: Планування реагування на ризики: інструменти й методи

4 Експертна оцінка є входом, одержуваним від добре обізнаних сторін, щодо дій, що вживаються у відношенні конкретних і визначених ризиків.

Експертну оцінку може надати особа або група осіб, що мають фахову освіту, знання, навички, досвід або підготовку в галузі розробки заходів реагування на ризики.

Деякі пояснення: Планування реагування на ризики: виходи

1 Оновлення реєстру ризиків. У процесі планування реагування на ризики вибираються, затверджуються й включаються до реєстру відповідні способи реагування на ризики.

Реєстр ризиків повинен бути складений таким чином, щоб ступінь його деталізації відповідав ранжируванню по пріоритетах і запланованих діях по реагуванню на ризики. Часто ризики високого й середнього рівня пріоритетності описуються більш докладно.

Ризики, яким був присвоєний низький рівень пріоритетності, включаються в список для періодичного контролю.

Деякі пояснення: Планування реагування на ризики: виходи

Елементи реєстру ризиків можуть містити в собі:

-виявлені ризики; їхні описи; область (і) проекту (наприклад, елемент ІСР), піддана (ий) їхньому впливу; їх причини (наприклад, елемент ієрархічної структури ризиків); а також характер і ступінь їхнього впливу на цілі проекту;

-осіб, відповідальних за ризики, і покладену на них відповідальність;

-виходи процесу якісного аналізу, включаючи список ризиків проекту, упорядкованих по пріоритетності;

-заздалегідь погоджені стратегії реагування на ризики; конкретні дії по реалізації обраної стратегії реагування;

-умови, симптоми й ознаки настання ризиків;

-операції, внесені в бюджет і розклад, необхідні для реалізації обраних способів реагування на ризики;

-плани на випадок можливих втрат і умови, при яких вони приводяться у виконання;

-резервні плани, використовувані як відповідна реакція на виникнення ризику, якщо первісне реагування на ризик виявилося неадекватним;

-залишкові ризики, що збереглися після запланованого реагування, а також ризики, які були прийняті свідомо;

-вторинні ризики, що виникають як прямий наслідок застосування реагування на ризики;

-резерви на можливі втрати, розраховані на основі даних кількісного аналізу ризиків проекту й порогів ризиків організації.

Деякі пояснення: Планування реагування на ризики: виходи

2 Контрактні угоди, пов'язані з ризиками

Щоб чітко визначити відповідальність кожної зі сторін на випадок виникнення кожного окремого ризику, складаються контрактні угоди (наприклад, договори страхування, надання послуг і ін.).

Це може відбуватися за допомогою зниження або передачі всієї загрози чи її частини, або збільшення або розподілу всієї можливості чи її частини.

Обраний тип контракту також представляє механізм розподілу ризиків.

Дані рішення є входами процесу планування закупівель.

Деякі пояснення: Планування реагування на ризики: виходи

3 Оновлення плану управління проектом. Елементи плану управління проектом, що можуть бути оновлені, містять у собі, серед іншого:

• План управління розкладом.

• План управління вартістю.

• План управління якістю.

• План управління закупівлями.

• План управління людськими ресурсами.

• Ієрархічну структуру робіт.

• Базовий розклад.

• Базовий план виконання вартості.

Деякі пояснення: Планування реагування на ризики: виходи

План управління розкладом обновляється для відображення змін у процесі й практиці, викликаних реагуванням на ризики. До таких оновлень можуть належати зміни готовності приймати ризик або зміни поведінки, пов'язані із завантаженням і вирівнюванням ресурсів, а також із самими оновленнями розкладу.

План управління вартістю обновляється для відображення змін у процесі й практиці, викликаних реагуванням на ризики. До таких оновлень можуть належати зміни готовності приймати ризик або зміни поведінки, пов'язані з калькуляцією вартості, відстеженням вартості й звітністю по ній, а також з оновленнями бюджету й споживанням резервів на можливі втрати.

Деякі пояснення: Планування реагування на ризики: виходи

План управління якістю. План управління якістю обновляється для відображення змін у процесі й практиці, викликаних відповідями на ризики. До таких відновлень можуть належати зміни готовності приймати ризик або зміни поведінки, пов'язані з вимогами, забезпеченням або контролем якості, а також з оновленнями документації по вимогах.

План управління закупівлями. План управління закупівлями може бути оновлений для відбиття змін у стратегії, наприклад змін у рішеннях «виробляти або купити» або в типі (ах) контракту (ів), викликаних реагуванням на ризики.

Деякі пояснення: Планування реагування на ризики: виходи

План управління закупівлями може бути оновлений для відбиття змін у стратегії, наприклад змін у рішеннях «виробляти або купити» або в типі (ах) контракту (ів), викликаних реагуванням на ризики.

План управління людськими ресурсами, обновляється для відображення змін структури організації й використання ресурсів, викликаних реагуванням на ризики.

До таких оновлень можуть належати зміни готовності приймати ризик або зміни поведінки, пов'язані з розподілом персоналу, а також з оновленнями завантаження ресурсів.

Деякі пояснення: Планування реагування на ризики: виходи

Оскільки в ході реагування на ризики створюється нова робота (або пропускається робота), для відбиття цих змін можуть бути оновленими:

• Ієрархічна структура робіт (ІСР).

• Базовий розклад.

• Базовий план виконання вартості

Деякі пояснення: Планування реагування на ризики: виходи

4 Оновлення документів проекту:

Журналу допущень. У міру надходження нової інформації під час вживання заходів реагування на ризики, допущення, по суті, теж змінюються. Журнал допущень повинен бути переглянутий для включення в нього даної інформації. Допущення можуть вказуватися в описі змісту або в окремому журналі допущень.

Технічної документації. У міру надходження нової інформації під час вживання заходів реагування на ризики можуть змінюватися технічні підходи й фізичні результати. Будь-яка допоміжна документація повинна бути переглянута для включення в неї даної інформації.

6. Моніторинг і контроль ризиків

Моніторинг і управління ризиками - це процес застосування планів реагування на ризики, спостереження за виявленими ризиками, контролю залишкових ризиків, ідентифікації нових ризиків і оцінки ефективності процесу регулювання ризиків протягом проекту (див. наступний слайд).

Заплановані дії по реагуванню на ризики, включені в план управління проектом, виконуються протягом життєвого циклу проекту; також варто проводити постійний контроль робіт проекту на предмет виявлення нових ризиків, змінених ризиків і ризиків, які втратили свою актуальність.

Моніторинг і контроль

Метою моніторингу й контролю є з'ясувати, чи:

• система реагування на ризики впроваджена відповідно до плану

• було реагування досить ефективним, чи необхідні зміни

• ризики змінилися в порівнянні з попереднім значенням

• було настання впливу ризиків

• були прийняті необхідні заходи

• вплив ризиків виявився запланованим, чи став випадковим результатом.

Моніторинг і управління ризиками: входи, інструменти, методи і виходи

Моніторинг і контроль

У процесі контролю й управління ризиками застосовуються такі методи, як аналіз відхилень і тенденцій, для виконання яких необхідні дані про виконання, зібрані в процесі виконання проекту. Інші цілі процесу контролю й управління ризиками покликані визначити:

• чи дійсні ще допущення проекту;

• чи показує аналіз, що оцінений ризик змінився або втратив свою актуальність;

• чи виконуються правила й процедури по управлінню ризиками; і

• чи необхідно узгоджувати резерви на можливі втрати за вартістю або розкладом з поточними оцінками ризиків.

Моніторинг і контроль

Моніторинг і управління ризиками може містити в собі вибір альтернативних стратегій, виконання плану реагування на ризики або резервний план, виконання коригувальних впливів і зміну плану управління проектом.

Особа , відповідальна за реагування на ризики, періодично звітує перед менеджером проекту про ефективність плану, про всі непередбачені наслідки, а також про корективи, необхідні для належного управління ризиком.

Процес моніторингу й управління ризиками також містить у собі оновлення активів процесів організації, у тому числі баз накопичених знань проекту й шаблонів для управління ризиками, які знадобляться для майбутніх проектів.

Моніторинг і контроль

Контроль може викликати вибір альтернативних стратегій, прийняття коректив, перепланування проекту для досягнення базового плану.

Між менеджерами проекту й групою ризику повинна бути постійна взаємодія, повинні фіксуватися всі зміни і явища.

Звіти про виконання проекту повинні формуватися регулярно.

Деякі пояснення: Моніторинг і управління ризиками: входи

1 Реєстр ризиків

Реєстр ризиків має ключові входи, які містять у собі ідентифіковані ризики й осіб, відповідальних за них, заздалегідь погоджені дії по реагуванню на ризики, конкретні дії по їхньому застосуванню, симптоми й ознаки ризиків, залишкові й вторинні ризики, список ризиків з низьким пріоритетом, що вимагає спостереження, а також резерви на можливі втрати за часом і вартістю.

2 План управління проектом

План управління проектом містить план управління ризиками, що містить у собі рівні готовності приймати ризики, протоколи й призначення персоналу (у тому числі осіб, відповідальних за ризики), строки й інші ресурси управління ризиками проекту.

Деякі пояснення: Моніторинг і управління ризиками: входи

3 Інформація про виконання робіт, пов'язана з різними результатами виконання, містить у собі, серед іншого:

• статус результатів;

• хід виконання розкладу; і

• понесені витрати.

4 Звіти про виконання

У звітах про виконання наводиться інформація, отримана в результаті вимірювань виконання, що піддається аналізу для надання відомостей про виконання робіт із проекту, включаючи аналіз відхилень, дані про освоєний обсяг і прогнозовані дані.

Деякі пояснення: Моніторинг і управління ризиками: інструменти й методи

1 Переоцінка ризиків

Моніторинг і управління ризиками часто приводить до ідентифікації нових ризиків, переоцінці поточних ризиків або закриттю ризиків, які втратили свою актуальність. Переоцінка ризиків проекту повинна проводитися регулярно, відповідно до розкладу. Обсяг і ступінь деталізації повторень залежать від ходу виконання проекту стосовно поставлених цілей.

Деякі пояснення: Моніторинг і управління ризиками: інструменти й методи

2 Аудити ризиків

Аудит ризиків припускає вивчення й надання в документальному виді результатів оцінки ефективності дій по реагуванню на ризики, що ставляться до ідентифікованих ризиків, вивчення основних причин їхнього виникнення, а також оцінку ефективності процесу управління ризиками.

Менеджер проекту відповідає за забезпечення регулярного проведення аудитів ризиків відповідно до плану управління ризиками проекту.

Аудити ризиків можуть проводитися в ході регулярних нарад по оцінці поточного стану проекту, або можуть проводитися окремі наради із приводу їх.

Формат і цілі аудита повинні бути чітко визначені до початку його проведення.

Деякі пояснення: Моніторинг і управління ризиками: інструменти й методи

3 Аналіз відхилень і тенденцій

У багатьох процесах управління використовується аналіз відхилень для порівняння запланованих результатів з фактичними. З метою контролю й управління настаннями ризиків варто переглядати тенденції виконання проекту, використовуючи інформацію про виконання. Для контролю загального виконання проекту можуть використовуватися аналіз освоєного обсягу й інші методи аналізу відхилень і тенденцій проекту. Результати даних аналізів дозволяють прогнозувати потенційні відхилення проекту на момент його завершення по показниках вартості й строкам. Такі відхилення від базового плану можуть указувати на можливі впливи, викликані загрозами або сприятливими можливостями.

Деякі пояснення: Моніторинг і управління ризиками: інструменти й методи

4 Вимірювання технічного виконання

При вимірюванні технічного виконання порівнюються одержувані в процесі реалізації проекту технічні результати із запланованими.

Для цього потрібне визначення кількісних показників технічного виконання, які можуть бути використані для порівняння фактичних результатів із заданими показниками.

До таких показників технічного виконання можуть належати вага, строки транзакцій, число допущених дефектів, місткість складу й ін.

Відхилення, наприклад, фактично більша або менша функціональність, ніж було заплановано в контрольній точці, можуть допомогти спрогнозувати ступінь успіху в досягненні змісту проекту, також вони дозволяють розкрити ступінь технічного ризику, з яким стикається проект.

Деякі пояснення: Моніторинг і управління ризиками: інструменти й методи

5 Аналіз резервів

У ході виконання проекту можуть наставати різні ризики, що роблять як позитивний, так і негативний вплив на резерви на можливі втрати по бюджету або розкладу. При аналізі резервів для визначення адекватності залишку резерву проводиться порівняння обсягу резервів, що залишилися, на можливі втрати з кількістю ризиків, що залишилися, за станом на будь-який момент часу процесу виконання проекту.

Деякі пояснення: Моніторинг і управління ризиками: інструменти й методи

6 Наради по поточному стану

Управління ризиками проекту повинне включатися до порядку денного періодичних нарад із приводу поточного стану.

Залежно від ідентифікованих ризиків, їхньої пріоритетності й труднощів реагування цей пункт порядку денного може вимагати різної кількості часу. Чим частіше проводяться подібні наради, тим легше стає управляти ризиками. Часті обговорення ризиків підвищують імовірність того, що персонал почне самостійно визначати ризики й можливості.

Деякі пояснення: Моніторинг і управління ризиками: виходи

1 Оновлення реєстру ризиків містить у собі, серед іншого:

•    Результати переоцінки ризиків, аудитів ризиків і періодичних перевірок ризиків. Ці результати можуть містити в собі визначення настання нових ризиків, оновлення ймовірностей, впливів, пріоритетів, планів реагування, відповідальності й інших елементів реєстру ризику. Також вони можуть містити в собі закриття ризиків, які більше незастосовні, і вивільнення пов'язаних з ними резервів.

• Фактичні результати ризиків проекту й заходів реагування на них. Ця інформація може допомогти менеджерам проектів при плануванні ризиків у рамках їхніх організацій, у тому числі й для майбутніх проектів.

Деякі пояснення: Моніторинг і управління ризиками: виходи

2 Оновлення активів процесів організації

У ході виконання шести процесів управління ризиками проекту генерується інформація, що може використовуватися в майбутніх проектах і повинна бути внесена в активи процесів організації. Активи процесів організації, які можуть бути оновлені, містять у собі, серед іншого:

• шаблони для плану управління ризиками, включаючи матрицю ймовірності й впливу і реєстр ризиків;

• ієрархічну структуру ризиків; і

• знання, накопичені в ході дій по управлінню ризиками проекту.

Дані документи варто оновлювати в міру необхідності й при завершенні проекту. Також включаються фінальні версії шаблонів реєстру ризиків і плану управління ризиками, контрольних списків і ієрархічної структури ризиків.

Деякі пояснення: Моніторинг і управління ризиками: виходи

3 Запити на зміну

Використання планів реагування на ризики або обхідні варіанти дій іноді приводить до запитів на зміну. Запити на зміну підготовляються й подаються на розгляд у процесі здійснення загального управління змінами. Запити на зміну також можуть містити в собі рекомендовані коригувальні й попереджуючі дії.

Рекомендовані коригувальні впливи. Рекомендовані коригувальні впливи містять у собі плани реагування на ризики й плани обходів. Останні є заходами реагування, які не були спочатку заплановані, але потрібні для регулювання виникаючих ризиків, які не були виявлені раніше або були пасивно прийняті.

Рекомендовані попереджуючі дії. Рекомендовані попереджуючі дії використовуються для того, щоб привести проект у відповідність із планом управління проектом.

Деякі пояснення: Моніторинг і управління ризиками: виходи

4 Оновлення плану управління проектом

Якщо схвалені запити на зміну впливають на процеси управління ризиками, то відповідні документи по елементах плану управління проектом переглядаються й випускаються заново, щоб відбити схвалені зміни. Елементи плану управління проектом, які можуть бути оновлені, такі ж, як і в процесі планування реагування на ризики.

5 Оновлення документів проекту

Документи проекту, які можуть бути оновлені в результаті процесу контролю й управління ризиками, такі ж, як у процесі планування реагування на ризики.

Визначення ефективності методів зниження ризиків

• розглядається ризик, що має найбільшу важливість для проекту,

• визначаються перевитрати коштів з урахуванням імовірності настання несприятливої події,

• визначається перелік можливих заходів, спрямованих на зменшення ймовірності й небезпеки ризикової події,

• визначаються додаткові витрати на реалізацію запропонованих заходів,

Визначення ефективності методів зниження ризиків (закінчення)

• порівнюються необхідні витрати на реалізацію запропонованих заходів із можливою перевитратою коштів внаслідок настання ризикової події,

• приймається рішення про здійснення або про відмову від запобіжних заходів,

• процес зіставлення ймовірності й наслідків ризикових подій з витратами на заходи щодо їхнього зниження повторюється для наступного по важливості ризику.

Дякую за увагу!

Управління людськими ресурсами проекту

1. Сутність управління людськими ресурсами проекту

2. Розробка плану управління людськими ресурсами

3. Набір команди проекту

4. Розвиток команди проекту

5. Управління командою проекту

1. Сутність управління людськими ресурсами проекту

Управління людськими ресурсами проекту містить у собі процеси організації, управління й керівництва командою проекту.

Команда проекту складається з людей, яким визначені ролі й відповідальність за виконання проекту.

У міру виконання проекту професійний і чисельний склад команди проекту може часто змінюватися. Членів команди проекту також іноді називають «персоналом проекту».

Розподіл ролей і відповідальності між членами команди проекту дозволяє всім членам команди брати участь у плануванні проекту й прийнятті рішень, що є цінним для проекту.

Залучення членів команди до участі на ранніх стадіях проекту дозволяє використовувати наявний у них досвід при плануванні проекту й зміцнює націленість команди на досягнення результатів проекту.

Команда управління проектом - це частина команди проекту, що відповідає за виконання дій по управлінню й керівництву проектом, таких як ініціація, планування, виконання, моніторинг, контроль і завершення різних фаз проекту.

Ця група також може називатися «ядром», «адміністративною групою» або «лідерською групою».

У невеликих проектах обов'язки по управлінню проектом можуть бути розподілені між всіма членами команди або доручені безпосередньо менеджерові проекту.

Спонсор проекту працює в контакті з командою управління проектом і звичайно бере участь у вирішенні таких питань, як фінансування проекту, уточнення змісту проекту, моніторинг поточного стану й надання впливу на інших осіб в інтересах проекту.

Управління й керівництво командою проекту також містить у собі, серед іншого:

- Вплив на команду проекту. Поінформованість про ті фактори людських ресурсів, які можуть впливати на проект, і, по можливості, надання впливу на них. До факторів людських ресурсів належать: навколишнє середовище команди, географічне місце розташування членів команди, комунікації між зацікавленими сторонами проекту, внутрішні й зовнішні правила, культурні розходження, особливості організації та інші подібні людські фактори, які можуть змінити виконання проекту.

- Професійна й етична поведінка. Команда управління проектом повинна бути інформована про норми етичної поведінки, дотримуватись їх і забезпечувати дотримання цих норм всіма членами команди.

Процеси управління проектами звичайно представляються у вигляді дискретних елементів із чітко виділеними межами, хоча на практиці вони перетинаються й впливають такими способами, які не можуть бути детально описані в Керівництві PMBOK®. Як приклади взаємозв'язку, що підлягає додатковому плануванню, можна навести такі ситуації:

- Після того, як початкова команда проекту створила ієрархічну структуру робіт, може виникнути необхідність розширення команди.

- Після розширення складу команди проекту рівень підготовки членів команди може збільшити або зменшити ризики проекту, що викликає необхідність у додаткових оновленнях планів по ризиках.

- Якщо оцінка тривалості операцій була виконана до визначення остаточного складу команди проекту, то із залученням нових членів команди, з урахуванням їх кваліфікації, може виникнути необхідність у зміні тривалості операцій.

Процеси управління людськими ресурсами проекту:

1. Розробка плану управління людськими ресурсами — процес визначення й документування ролей, відповідальності, необхідних навичок і підзвітності, а також створення плану управління забезпеченням проекту персоналом.

2. Набір команди проекту — процес підтвердження доступності людських ресурсів і набору команди, необхідної для виконання задач по проекту.

3. Розвиток команди проекту — процес підвищення кваліфікації членів команди проекту, поліпшення взаємодії між ними й загальними умовами роботи команди з метою підвищення ефективності виконання проекту.

4. Управління командою проекту — процес контролю ефективності діяльності членів команди, забезпечення зворотного зв'язку, розв'язання проблем і управління змінами, спрямований на оптимізацію виконання проекту.

2. Розробка плану управління людськими ресурсами

Розробка плану управління людськими ресурсами – це процес визначення й документування ролей, відповідальності, необхідних навичок і відносин підзвітності, а також створення плану управління забезпеченням проекту персоналом.

Планування людських ресурсів використовується для визначення й ідентифікації людських ресурсів, а також навичок, необхідних для успіху проекту.

План управління людськими ресурсами документує ролі й відповідальність у проекті, організаційні діаграми проекту, а також план управління забезпеченням проекту персоналом, включаючи графік набору й вивільнення персоналу.

План управління людськими ресурсами також може містити в собі визначення потреб у навчанні, стратегії формування команди, плани визнання заслуг і винагороди, рекомендації відносно відповідності встановленим вимогам, питання безпеки, а також вплив плану управління забезпеченням проекту персоналом на діяльність організації.

Велика увага повинна приділятися розгляду доступності людських ресурсів або конкуренції за них, їхньому дефіциту або обмеженості.

Ролі в проекті можуть бути призначені окремим особам або групам осіб. Ці особи або групи можуть бути залучені як зі штату самої організації, що виконує проект, так і зі сторонніх організацій.

На ресурси з тим самим рівнем кваліфікації або тим самим набором навичок можуть претендувати інші проекти.

Зазначені фактори можуть значно вплинути на вартість, строки, ризики, якість і інші аспекти проекту. При ефективному плануванні людських ресурсів варто враховувати й планувати ці фактори й розробляти альтернативні плани управління людськими ресурсами.

Розробка плану управління людськими ресурсами: входи, інструменти і методи, виходи

Блок-схема даних при розробці плану управління людськими ресурсами

Розробка плану управління людськими ресурсами: входи

1. Вимоги до ресурсів операцій. Для визначення потреб проекту в персоналі при плануванні людських ресурсів використовуються вимоги до ресурсів операцій (Див. тему Управління строками проекту).

Попередні вимоги до необхідного для команди проекту персоналу й рівня його кваліфікації послідовно проробляються в рамках процесу розробки плану управління людськими ресурсами.

.

Розробка плану управління людськими ресурсами: входи

2. Фактори середовища підприємства, які можуть впливати на процес розробки плану управління людськими ресурсами, містять у собі, серед іншого:

- організаційну культуру й структуру;

- існуючі людські ресурси;

- правила управління персоналом; і

- ситуацію на ринку.

3. Активи процесів організації, які можуть впливати на процес розробки плану управління людськими ресурсами, містять у собі, серед іншого:

- стандартні процеси й норми організації, а також описи типових ролей;

- шаблони організаційних діаграм і посадових інструкцій; і

- історичну інформацію з організаційних структур, які виявилися ефективними в попередніх проектах.

Розробка плану управління людськими ресурсами: інструменти і методи

1. Організаційні діаграми і посадові інструкції

Існують різні формати документування розподілу ролей і відповідальності членів команди. Більшість форматів належать до одного із трьох типів: ієрархічний, матричний і текстовий формати.

Крім того, деякі призначення по проекту вказуються в допоміжних планах управління проектом (наприклад, у планах управління ризиками, якістю або комунікаціями).

Незалежно від того, який метод використовується, ціль завжди одна - домогтися того, щоб для кожного пакета робіт був призначений один відповідальний за його виконання й щоб кожний член команди чітко розумів свою роль і сферу відповідальності.

Формати визначення ролей і відповідальності:

(1) Ієрархічні діаграми.

(2) Матричні діаграми.

(3) Текстові формати.

(4) Інші розділи плану управління проектом.

Розробка плану управління людськими ресурсами: інструменти і методи

(1) Ієрархічні діаграми. Для відображення посад і взаємин зверху донизу у графічному форматі можна використовувати структуру звичайної організаційної діаграми.

Організаційна структура (ОС) схожа на ієрархічну структуру робіт (ІСР), але організована не за результатами проекту, а відповідно до наявної структури підрозділів організації (відділів, груп або команд). Під кожним відділом зазначений список операцій проекту або пакета робіт.

Таким чином, конкретний функціональний відділ може довідатися про всі свої обов'язки по проекту (наприклад, відділ інформаційних технологій або відділ закупівель), вивчивши свою частину організаційної структури.

Ієрархічна структура ресурсів - це інший різновид ієрархічної діаграми. Вона використовується для поділу проекту по типах ресурсів. Наприклад, ієрархічна структура ресурсів може відобразити всіх зварювальників і зварювальне обладнання, використовуване при будівництві судна, незважаючи на те, що вони розкидані по різних відгалуженнях ОС і ІСР. Ієрархічна структура ресурсів може бути корисна при контролі вартості проекту й може використовуватися відповідно до системи бухгалтерського обліку, що діє в організації. Вона також може містити інші категорії ресурсів, крім людських.

Розробка плану управління людськими ресурсами: інструменти і методи

(2) Матричні діаграми. Матриця відповідальності (МВ) використовується для відображення зв'язків між пакетами робіт або операціями й членами команди проекту. У великих проектах МВ можуть використовуватися на різних рівнях. Наприклад, МВ високого рівня може визначати, яка група або підрозділ команди відповідає за який елемент в ІСР, у той час як МВ більш низького рівня використовуються в групі для розподілу ролей, відповідальності й рівнів повноважень відносно конкретних операцій. Матричний формат показує всі операції, які виконуються однією людиною, і всіх людей, що беруть участь у виконанні однієї операції. Матричний формат також забезпечує наділення відповідальністю за виконання одного завдання тільки однієї людини щоб уникнути різних невідповідностей.

Розробка плану управління людськими ресурсами: інструменти і методи

На наступному слайді зображена матриця відповідальності, яку ще називають матрицею RACI (Відповідає - Затверджує - Консультує - Поінформовується). У лівому стовпчику у вигляді операцій зразок діаграми показує роботу, яку необхідно виконати. Призначені ресурси можуть бути показані як окремі виконавці або групи осіб. Матриця RACI є лише одним з типів МВ; менеджер проекту може вибрати інші варіанти позначення, такі як «керівник» або «ресурс» та ін., залежно від особливостей проекту. Матриця RACI особливо важлива, коли команда складається із внутрішніх і зовнішніх ресурсів, тому що дозволяє чітко розділяти ролі й очікування.

Матриця відповідальності (МВ ) з використанням формату RACI

Розробка плану управління людськими ресурсами: інструменти і методи

(3) Текстові формати. Для опису розподілу відповідальності, при якому потрібні докладні описи, використовуються текстові формати.

Звичайно в таких документах у короткій формі міститься така інформація: обов'язки, повноваження, компетенція й кваліфікація.

Такі документи називають по-різному, наприклад «посадові інструкції» або «форма ролі-обов'язки-повноваження». Вони можуть використовуватися як шаблони для майбутніх проектів, особливо якщо в процесі виконання проекту відновлення інформації відбувається з використанням накопичених у ході проекту знань.

Розробка плану управління людськими ресурсами: інструменти і методи

(4) Інші розділи плану управління проектом. Перелік і опис деяких обов'язків, що належать до управління проектом, наводяться в інших розділах плану управління проектом.

Наприклад, у реєстрі ризиків перераховані особи, відповідальні за ризики, у плані управління комунікаціями міститься список членів команди, відповідальних за дії по комунікаціях, а в плані управління якістю перераховані особи, відповідальні за виконання дій по забезпеченню й контролю якості.

Розробка плану управління людськими ресурсами: інструменти і методи

2. Налагодження зв'язків - це формальна й неформальна взаємодія з іншими особами в організації, галузі або в професійному середовищі.

Це конструктивний спосіб зрозуміти політичні й міжособистісні фактори, здатні вплинути на ефективність різних варіантів управління забезпеченням проекту персоналом.

Дії по налагодженню зв'язків в галузі людських ресурсів можуть містити в собі активну переписку, зустрічі за обідом, неформальні бесіди, включаючи зустрічі й різні заходи, торговельні конференції й симпозіуми.

Налагодження зв'язків може бути корисним методом на початку проекту.

Також налагодження зв'язків може бути ефективним способом розширити професійні навички управління проектом у ході реалізації проекту й після його закінчення.

Розробка плану управління людськими ресурсами: інструменти і методи

3. Теорія організації розкриває поведінку людей, команди й підрозділів організації. Ефективне використання даної інформації дозволяє скоротити час, вартість або трудомісткість, необхідні для створення виходів планування людських ресурсів, і підвищити ймовірність того, що таке планування буде ефективним.

Важливо розуміти, що в різних організаційних структурах індивідуальні реакції й продуктивність, а також характеристики міжособистісних відносин будуть відрізнятися.

Розробка плану управління людськими ресурсами: виходи

1. План управління людськими ресурсами, який є частиною плану управління проектом, надає рекомендації про порядок визначення, набору, управління, контролю й вивільнення людських ресурсів проекту. План управління людськими ресурсами повинен містити в собі, серед іншого:

• Ролі й сфери відповідальності.

• Організаційні діаграми проекту.

• План управління забезпеченням проекту персоналом.

Розробка плану управління людськими ресурсами: виходи

При перерахуванні ролей і сфер відповідальності, необхідних для виконання проекту, необхідно враховувати таке:

o    Роль. Позначення частини проекту, відповідальність за виконання якої несе певна особа. Як приклади ролей у проекті можна назвати інженера-будівельника, чиновника служби підготовки судових засідань, бізнес-аналітика й координатора проведення випробувань. Чіткий опис ролі відносно повноважень, сфер відповідальності й границь повинне документально оформлятися.

o   Повноваження. Право задіяти ресурси проекту, приймати рішення й затверджувати дії або результати. Прикладами рішень, для прийняття яких потрібні ясні й чіткі повноваження, є вибір способу виконання операції, приймання якості й порядок реагування на відхилення в проекті. Члени команди працюють найбільш ефективно, коли рівень повноважень кожного з них відповідає їхній відповідальності.

o   Відповідальність. Робота, яку член команди проекту повинен виконати для завершення операцій проекту.

o   Кваліфікація. Навички й здатності, необхідні для виконання операцій проекту. Якщо члени команди проекту не мають необхідної кваліфікації, то виконання проекту може виявитися під загрозою. При виявленні подібних невідповідностей необхідно почати попереджувальні дії, наприклад провести навчання, найняти кваліфікованих фахівців або внести в розклад або зміст проекту відповідні зміни.

Розробка плану управління людськими ресурсами: виходи

Організаційна діаграма проекту - це графічне подання складу команди проекту й відносин підзвітності між її членами. Залежно від вимог проекту вона може бути офіційною або неофіційною, докладною або узагальненою. Наприклад, організаційна діаграма проекту для команди рятувальників, що складається з 3000 чоловік, буде значно більш докладною, ніж організаційна діаграма внутрішнього проекту з командою в 20 чоловік.

Розробка плану управління людськими ресурсами: виходи

План управління забезпеченням проекту персоналом є частиною плану управління людськими ресурсами в рамках плану управління проектом і містить опис порядку й зазначення строків виконання вимог до забезпечення людськими ресурсами.

Залежно від вимог проекту план управління забезпеченням проекту персоналом може бути офіційним або неофіційним, докладним або узагальненим. Для відбиття поточних заходів щодо поповнення й розвитку команди проекту цей план у ході проекту постійно оновлюється.

Розробка плану управління людськими ресурсами: виходи

Інформація, що міститься в плані управління забезпеченням проекту персоналом, розрізняється залежно від прикладної області й масштабу проекту, але в кожному разі повинні бути відображені такі моменти:

• Набір персоналу.

• Ресурсні календарі.

• План вивільнення персоналу.

• Потреби в навчанні.

• Визнання заслуг і винагорода.

• Відповідність нормам.

• Безпека.

Розробка плану управління людськими ресурсами: виходи

Набір персоналу. При плануванні набору членів команди проекту виникає ряд питань. Наприклад, чи будуть задіяні наявні людські ресурси організації, або вони будуть набиратися ззовні на контрактній основі? Чи будуть члени команди працювати в одному місці, або вони можуть працювати віддалено? Яка вартість, що відповідає кожному рівню знань (кваліфікації), необхідних для проекту? Наскільки відділ по роботі з персоналом і функціональними менеджерами зможуть допомогти команді управління проектом?

Розробка плану управління людськими ресурсами: виходи

Ресурсні календарі. У плані управління забезпеченням проекту персоналом вказуються строки залучення членів команди проекту, як індивідуально, так і колективно, а також вказується час початку заходів щодо набору (наприклад, наймання персоналу). Одним із інструментів для графічного відображення людських ресурсів є гістограма ресурсу. На цій стовпчастій діаграмі відображається кількість годин, яку особі, відділу або всій команді проекту доведеться працювати щотижня або місяць протягом усього проекту. Діаграма може містити горизонтальну лінію, що відображає максимальну кількість годин, розрахованих для певного ресурсу. Якщо стовпчики діаграми виходять за межі максимальної кількості годин, то в цьому випадку необхідно застосувати стратегію вирівнювання ресурсів (наприклад, виділити додаткові ресурси або розширити часові рамки розкладу).

Розробка плану управління людськими ресурсами: виходи

План вивільнення персоналу. Визначення методу й часу звільнення членів команди від обов'язків у проекті представляє користь як для проекту, так і для членів команди. Коли члени команди звільняються від участі в проекті, то при цьому виключаються виплати співробітникам, що вже виконали свою частку роботи в проекті, і в такий спосіб знижуються витрати на проект. Загальний клімат поліпшується, якщо плавний перехід до нових проектів уже спланований заздалегідь. План вивільнення персоналу також може скоротити ризики у сфері людських ресурсів, які можуть виникнути в ході реалізації або по закінченні проекту.

Розробка плану управління людськими ресурсами: виходи

Потреби в навчанні. Якщо існують побоювання, що кваліфікація членів команди, призначуваних для участі в проекті, може виявитися недостатньою, то в рамках проекту варто розробити план навчання персоналу. У цьому плані можуть бути також передбачені програми навчання членів команди, які приведуть до одержання ними сертифікацій, які сприяють успішному виконанню проекту.

Розробка плану управління людськими ресурсами: виходи

Визнання заслуг і винагорода. Чіткі критерії й спланована система винагороди допомагають стимулювати й підтримувати бажану поведінку людей, зайнятих у проекті. Щоб визнання заслуг і винагорода були ефективними, вони повинні ґрунтуватися на діях і показниках продуктивності, підконтрольних даній особі. Створення плану із зазначенням часу винагороди гарантує, що про заохочення не забудуть. Розподіл заохочень і винагород є частиною процесу розвитку команди проекту.

Розробка плану управління людськими ресурсами: виходи

Відповідність нормам. План управління забезпеченням проекту персоналом може передбачати стратегії, що забезпечують відповідність проекту існуючим державним нормативним актам, умовам договорів із профспілками й іншим установленим нормам відносно людських ресурсів.

Безпека. У план управління забезпеченням проекту персоналом, а також до реєстру ризиків можуть включатися норми й правила по захисту членів команди від нещасних випадків.

3. Набір команди проекту

Набір команди проекту - це процес підтвердження доступності людських ресурсів і набору команди, необхідної для виконання завдань по проекту. Команда управління проектом може мати або не мати прямого контролю при підборі членів команди, тому що на це впливають колективні трудові договори, використання персоналу субпідрядників, матричне середовище проекту, внутрішні або зовнішні відносини підзвітності або різні інші причини.

У процесі набору команди проекту важливо розглядати такі фактори:

- Менеджер проекту або команда управління проектом повинні проводити ефективні переговори з тими особами, які займають відповідні посади для забезпечення проекту необхідними людськими ресурсами, і впливати на них.

- Нездатність набрати необхідні людські ресурси для проекту може значно вплинути на строки, бюджет, задоволеність замовника, якість і ризики проекту. Це може зменшити ймовірність успіху проекту й в остаточному підсумку призвести до його скасування.

- Якщо людські ресурси недоступні через обмеження, економічних факторів, або в силу їх більш ранніх призначень на інші проекти, від менеджера проекту або команди управління проектом може знадобитися задіяти альтернативні ресурси, які, можливо, будуть мати більш низький рівень кваліфікації, за умови, що це не порушить правові, нормативні, обов'язкові або інші особливі вимоги.

Зазначені фактори повинні розглядатися й ураховуватися на стадіях планування проекту.

Менеджер проекту або команда управління проектом повинні відображати вплив недоступності необхідних людських ресурсів у розкладі, бюджеті, планах управління ризиками і якістю проекту, планах навчання й інших планів управління проектом, при необхідності.

Набір команди проекту: входи, інструменти і методи, виходи

Блок-схема даних при наборі команди проекту

Набір команди проекту: входи

1. План управління проектом (див. тему Управління інтеграцією), містить план управління людськими ресурсами, у якому є інформація, використовувана для надання вказівок про порядок визначення, набору, управління, контролю й вивільнення людських ресурсів із проекту. Ця інформація містить у собі:

- ролі й сфери відповідальності, що визначають посади, навички й рівень кваліфікації, необхідні для проекту;

- організаційні діаграми проекту, що вказують кількість людей, необхідна для проекту; і

- план управління забезпеченням проекту персоналом, що вказує періоди часу, протягом яких необхідний кожний член команди проекту, й іншу інформацію, що є важливою при наборі команди проекту.

Набір команди проекту: входи

2. Фактори середовища підприємства, які можуть впливати на процес набору команди проекту, містять у собі, серед іншого:

- існуючу інформацію про людські ресурси, включаючи відомості про доступність, рівень кваліфікації, досвід роботи, зацікавленість в роботі над проектом і про вартість людських ресурсів;

- правила управління персоналом, наприклад ті, які впливають на залучення кадрів зі сторонніх організацій (аутсорсинг);

- організаційну структуру; і

- одне або кілька місцеположень.

3. Активи процесів організації, які можуть впливати на процес набору команди проекту, містять у собі, серед іншого, стандартні правила, процеси й процедури організації.

Набір команди проекту: інструменти і методи

1. Попереднє призначення. У деяких випадках члени команди відомі заздалегідь, тобто вони попередньо призначені на проект. Така ситуація може виникнути, якщо в результаті конкурсного відбору певним особам була обіцяна участь у проекті, якщо виконання проекту залежить від знань визначених осіб або якщо призначення певних осіб на певні посади передбачено статутом проекту.

Набір команди проекту: інструменти і методи

2. Перемовини. Призначення персоналу в багатьох проектах є предметом перемовин. Наприклад, у команди управління проектом може виникнути необхідність проведення перемовин з:

- функціональними керівниками, щоб гарантувати забезпечення проекту відповідним штатом кваліфікованих співробітників на необхідний період часу, і щоб члени команди проекту могли або мали повноваження працювати над проектом до повного виконання своїх обов'язків;

- іншими командами управління проектами усередині виконуючої організації, щоб належним чином забезпечити проект дефіцитними людськими ресурсами або вузькими фахівцями; і

- зовнішніми організаціями, виконавцями, постачальниками, підрядниками й т.д. у відношенні відповідних, дефіцитних, спеціалізованих, кваліфікованих, сертифікованих і інших людських ресурсів певного типу. Особлива увага повинна приділятися необхідності урахування правил, практик, процесів, провідних вказівок, правових і інших подібних критеріїв проведення переговорів із зовнішніми організаціями.

Набір команди проекту: інструменти і методи

3. Набір персоналу

Якщо у виконуючої організації для виконання проекту не вистачає штатних фахівців, то необхідні послуги можна одержати зі сторонніх джерел. Це може виражатися в найманні консультантів або передачі частини робіт стороннім організаціям на умовах субпідряду.

Набір команди проекту: інструменти і методи

4. Віртуальні команди

Формування віртуальних команд відкриває нові можливості по залученню членів команди проекту.

Віртуальні команди можна визначити як групи людей, об'єднаних загальною метою, де кожний член групи виконує свою роботу при мінімальному особистому контакті з іншими або при повній його відсутності.

Робота віртуальних команд стала можливою завдяки електронним засобам комунікації, наприклад електронна пошта, аудіо-, відео- й інтернет-конференції, а також наради через Інтернет.

Набір команди проекту: інструменти і методи

Формат віртуальної команди надає можливість:

- формувати команди із числа співробітників однієї компанії, що проживають у різних регіонах;

- використовувати в команді проекту спеціальні експертні знання, навіть якщо експерт перебуває в іншому географічному регіоні;

- залучати до участі в проекті співробітників, що працюють удома;

- формувати команди з виконавців, що працюють у різні зміни або години;

- включати в команду людей з обмеженою рухливістю й інвалідів; і

- братися за виконання проектів, реалізація яких в інших умовах була б неможливою через високі витрати на відрядження.

Набір команди проекту: інструменти і методи

При роботі в умовах віртуальної команди все більшого значення набуває планування комунікацій. Можливо, буде потрібно додатковий час для чіткого визначення очікувань учасників, забезпечення комунікацій, розробки правил вирішення конфліктів, залучення співробітників у процес прийняття рішень і розподілу заохочень за участь у загальному успіху проекту.

Набір команди проекту: виходи

1. Призначення персоналу проекту

Проект уважається укомплектованим персоналом, коли на роботи проекту призначені відповідні особи за допомогою розглянутих вище методів.

Документація по призначеннях може містити в собі довідник команди проекту, пам'ятки для членів команди й імена членів команди, зазначені в інших частинах плану управління проектом (наприклад, в організаційних діаграмах і розкладах проекту).

Набір команди проекту: виходи

2. Ресурсні календарі

Для зазначення доступності ресурсів у ресурсних календарях документально фіксуються періоди часу, протягом яких кожний член команди проекту може брати участь у виконанні проекту. Щоб розробити надійний розклад (див. тему Управління строками проекту), необхідно мати інформацію про всі нестиковки розкладу по кожному співробітнику, включаючи відпустки й зобов'язання по інших проектах.

Набір команди проекту: виходи

3. Оновлення плану управління проектом

Елементи плану управління проектом, які можуть бути оновлені, містять у собі, серед іншого, план управління людськими ресурсами.

Наприклад, коли певні особи призначені для виконання ролей і обов'язків по проекту, може виявитися, що між вимогами забезпечення проекту персоналом, зазначеними в плані управління людськими ресурсами, і окремими призначеними особами немає точної відповідності.

4. Розвиток команди проекту

Розвиток команди проекту - це процес підвищення кваліфікації членів команди проекту, поліпшення взаємодії між ними й поліпшення загальних умов роботи команди для підвищення ефективності проекту.

Менеджери проектів повинні вміти визначати, формувати, підтримувати, мотивувати, керувати й надихати команди проектів для підвищення ефективності їхньої роботи й досягнення цілей проекту.

Командна робота є критично важливим фактором успіху проекту, а розвиток ефективних команд проектів є одним із найважливіших обов'язків менеджера проекту. Менеджери проектів повинні створювати умови, що сприяють командній роботі.

Менеджери проектів повинні постійно мотивувати свою команду, ставлячи перед нею задачі й надаючи можливості, забезпечуючи при необхідності їх своєчасним зворотним зв'язком і підтримкою, а також заохочуючи й винагороджуючи за гарне виконання робіт.

Висока ефективність роботи команди може бути досягнута за допомогою відкритої й ефективної комунікації, підвищення довіри між членами команди, конструктивного управління конфліктами, а також за рахунок сприяння вирішенню проблем і прийняттю рішень на основі співробітництва.

Для одержання ресурсів, необхідних для розвитку ефективних команд проектів, менеджер проекту повинен залучати підтримку керівництва й/або впливати на зацікавлені сторони проекту.

Команда управління проектом повинна використовувати культурні розбіжності для одержання вигоди, орієнтуватися на розвиток і підтримку команди проекту протягом усього життєвого циклу проекту, а також дотримуватися моделі взаємозалежної спільної роботи в обстановці взаємної довіри. Розвиток команди проекту спрямовано на розвиток навичок співробітників, їхньої технічної кваліфікації, а також поліпшення загального клімату в команді й підвищення ефективності виконання проекту. Для цього потрібні чіткі, ефективні й діючі способи комунікації між членами команди протягом усього життєвого циклу проекту.

Цілі розвитку команди проекту містять у собі, серед іншого:

- підвищення рівня знань і навичок членів команди для підвищення їхньої здатності досягати результатів проекту при зниженні вартості, скороченні строків і поліпшенні якості;

- зміцнення почуття довіри й згуртованості серед членів команди для підвищення морального духу, зменшення конфліктів і поліпшення командної роботи; і

- створення динамічної й згуртованої командної культури для підвищення як індивідуальної, так і командної продуктивності, стимулювання командного духу й співробітництва, а також створення можливостей для взаємного навчання й наставництва, спрямованих на обмін знаннями й досвідом між членами команди.

Розвиток команди проекту: входи, інструменти і методи, виходи

Блок-схема даних при розвитку команди проекту

Розвиток команди проекту: входи

1. Призначення персоналу проекту

Розвиток команди починається зі складання списку членів команди проекту. Документація по призначенню персоналу проекту визначає персональний склад команди.

2. План управління проектом (див. тему Управління інтеграцією проекту) містить план управління забезпеченням проекту персоналом, у якому визначені стратегії навчання й плани розвитку команди проекту. На підставі поточної оцінки продуктивності команди проекту й інших форм управління командою проекту в план додаються такі розділи, як винагорода, зворотний зв'язок, додаткове навчання й заходи дисциплінарного впливу.

3. Ресурсні календарі визначають періоди часу, коли члени команди проекту можуть брати участь у заходах щодо розвитку команди.

Розвиток команди проекту: інструменти і методи

1. Навички міжособистісних стосунків

Для розвитку команди проекту особливо важливі навички міжособистісних стосунків, іноді називані «соціальними навичками». Команда управління проектом може значно скоротити кількість проблем і підвищити рівень взаємодії співробітників, якщо буде розуміти настрої членів команди проекту, передбачати їхні дії, уважно вислухувати й визнавати їхні думки й розв’язувати їхні проблеми. Такі навички, як уміння зрозуміти точку зору іншого, впливати, творчий підхід до роботи й здатність організовувати групову роботу набувають великого значення при управлінні командою проекту.

Розвиток команди проекту: інструменти і методи

2. Навчання містить у собі всі дії, спрямовані на підвищення кваліфікації членів команди проекту. Навчання може мати як офіційний, так і неофіційний характер. Прикладами методів навчання персоналу є навчання в класі, по Інтернету, з використанням комп'ютерних технологій або навчання на робочому місці під керівництвом іншого члена команди проекту, наставництво й інструктування. Якщо члени команди проекту не мають достатніх управлінських або технічних навичок, то розвиток таких навичок можна передбачити як частину робіт із проекту. Заплановане навчання здійснюється відповідно до плану управління забезпеченням проекту персоналом. Позапланове навчання проводиться за результатами спостереження, обговорення й оцінки ефективності виконання проекту, виконуваних під час процесів контролю управління командою проекту.

Розвиток команди проекту: інструменти і методи

3. Дії по зміцненню команди можуть варіюватися від п'ятихвилинного пункту на порядку денному наради по оцінюванню поточного стану до спеціальних тренінгів за участю професіоналів з метою поліпшення міжособистісних відносин серед членів команди. Ціль виконання дій по зміцненню команди - допомогти окремим її членам ефективно працювати один з одним. Стратегії зміцнення команди особливо цінні, коли члени команди розташовані далеко один від одного й не мають можливості особистого спілкування. Неформальне спілкування й відповідні заходи можуть допомогти зміцнити почуття довіри й установити гарні робочі взаємини.

Розвиток команди проекту: інструменти і методи

Одним з найбільш важливих навичок при розвитку середовища команди є вміння розглядати проблеми команди проекту й обговорювати їх як командні проблеми. Необхідно стимулювати всю команду для спільного вирішення даних проблем. Для формування ефективних команд проектів менеджери проектів повинні заручатися підтримкою вищого керівництва й прихильністю членів команд, призначати відповідні заохочення й винагороди, формувати своєрідність команди, ефективно влагоджувати конфлікти, зміцнювати довіру й створювати умови для відкритого спілкування між членами команди й, крім того, здійснювати адекватне управління командою.

Розвиток команди проекту: інструменти і методи

Зміцнення команди, як постійний процес, є критично важливим для успіху проекту. Хоча зміцнення команди особливо принципове на початку проекту, даний процес ніколи не закінчується. Зміни в навколишньому середовищі проекту неминучі, й для ефективного управління ними повинні додаватися постійні або періодичні зусилля по зміцненню команди.

Менеджер проекту повинен постійно контролювати дії членів команди і їхню продуктивність, щоб визначати, чи потрібні якісь дії для запобігання або усунення різних проблем команди.

Розвиток команди проекту: інструменти і методи

Одна з теорій стверджує, що існує п'ять стадій розвитку, через які можуть проходити команди. Звичайно ці стадії наступають одна по одну. Однак нерідко команда може «застрягти» на певній стадії або повернутися на більш ранню. Крім того, у проектах, члени команд яких працювали раніше разом, певні стадії можуть бути пропущені.

-Формування. На даній стадії команда збирається разом і дізнається про проект і про свої формальні ролі й відповідальність у ньому. Члени команди на даній фазі, як правило, незалежні один від одного й не дуже відкриті.

-Шторм. Протягом даної стадії команда починає вивчати роботи із проекту, технічні рішення й підхід до управління проектом. Якщо члени команди не настроєні на співробітництво й не відкриті різним ідеям і перспективам, обстановка може стати деструктивною.

-Урегулювання. На стадії врегулювання члени команди починають працювати разом і підбудовують свої робочі звички й моделі поведінки так, щоб сприяти командній роботі. Члени команди починають довіряти один одному.

-Результативність. Команди, що досягли стадії результативності, функціонують як добре організований підрозділ. Вони незалежні й спокійно й ефективно розв’язують проблеми.

-Завершення. На цій стадії команда завершує роботу й переходить до наступного проекту.

Тривалість кожної конкретної стадії залежить від динаміки, чисельного складу й керівництва команди. Менеджери проектів повинні добре уявляти собі динаміку розвитку команди, щоб сприяти ефективному проходженню членами команди всіх стадій.

Розвиток команди проекту: інструменти і методи

4. Принципи. За допомогою принципів установлюються ясні й чіткі правила поведінки, прийнятні серед членів команди. Чим раніше члени команди прийдуть до взаємної згоди про правила поведінки, тим менша ймовірність виникнення непорозумінь і тем вища продуктивність праці. Обговорення принципів дає можливість членам команди виявити важливі для них положення. Всі члени команди проекту рівною мірою відповідають за дотримання встановлених принципів.

Розвиток команди проекту: інструменти і методи

5. Спільне розташування припускає розміщення всіх або більшості найбільш активних членів команди проекту в одному місці для розширення їхніх можливостей працювати в єдиній команді. Спільне розташування може передбачатися на певний час (наприклад, на період часу, що має стратегічне значення для проекту) або на час усього проекту. Стратегія спільного розташування припускає наявність кімнати для нарад команди, місце для розміщення розкладів і інші пристосування, що сприяють взаємному спілкуванню й зміцненню почуття колективізму. Хоча спільне розташування вважається корисною стратегією, іноді віртуальних команд уникнути неможливо.

Розвиток команди проекту: інструменти і методи

6. Визнання заслуг і винагорода. Частиною процесу розвитку команди є визнання заслуг і заохочення бажаного поводження членів команди.

Початкові плани порядку заохочення розробляються в рамках процесу розробки плану управління людськими ресурсами. Важливо розуміти, що кожна конкретна винагорода, призначена будь-якій особі, буде ефективною тільки в тому випадку, якщо вона задовольняє потребу, що представляє цінність для даної особи.

Рішення про винагороду приймаються офіційно або неофіційно в процесі управління командою проекту на підставі результатів оцінки ефективності виконання проекту. При визначенні заохочень і винагород варто враховувати культурні розходження. Наприклад, у культурі, що заохочує індивідуалізм, буває складно розробити підходящі командні винагороди.

Розвиток команди проекту: інструменти і методи

Винагороджувати треба тільки бажане поводження членів команди. Наприклад, бажання працювати надурочно з метою виконання жорсткого розкладу має бути винагороджено й відзначене; а понаднормова робота внаслідок поганого планування винагороді не підлягає. Однак не варто карати членів команди за погане планування й, відповідно, нереалістичні очікування, нав'язані вищим керівництвом.

Винагорода за принципом «один виграв - всі інші програли», що призначається тільки деяким членам команди проекту (наприклад, звання «кращий працівник місяця»), може завдати шкоди згуртованості команди. Винагорода за досягнення, які під силу будь-якому члену групи (наприклад, за своєчасне здавання звітів про поточний стан), як правило, сприяють зміцненню взаємної підтримки серед членів команди.

Розвиток команди проекту: інструменти і методи

Персонал вмотивований, якщо співробітники почувають, що їх цінують в організації, а це можна продемонструвати через винагороду. Як правило, гроші розглядаються більшістю як найбільш матеріальний аспект системи заохочення, але й інші, нематеріальні нагороди також ефективні.

Більшість членів команди проекту мотивуються можливістю розвиватися, удосконалюватися й застосовувати свої професійні навички для досягнення нових кар'єрних висот. Публічне заохочення високої продуктивності праці створює позитивний підйом духу. Гарною стратегією для менеджерів проектів є визнання заслуг команди протягом усього проекту, а не тільки після його завершення.

Розвиток команди проекту: виходи

1. Оцінки ефективності роботи команди

Після того, як виконані дії по розвитку команди проекту, наприклад навчання, зміцнення команди й спільне розташування, команда управління проектом може давати офіційні й неофіційні оцінки ефективності роботи команди проекту.

Ефективні стратегії й дії по розвитку команди повинні підвищувати продуктивність праці команди, що у свою чергу сприяє досягненню цілей проекту.

Критерії оцінювання продуктивності праці команди повинні визначатися всіма відповідними сторонами й використовуватися як входи процесу розвитку команди проекту. Це особливо важливо в проектах, пов'язаних з контрактами або колективними трудовими договорами.

Розвиток команди проекту: виходи

Ефективність роботи успішної команди виміряється в одиницях сприятливого результату відповідно до погоджених цілей проекту, виконанням розкладу проекту (виконано вчасно) і виконанням бюджету (виконано в рамках фінансових обмежень).

Високоефективні команди характеризуються саме такою роботою, орієнтованою на задачі й результат. Крім того, вони демонструють особливі робочі й людські якості, які являють собою непрямі показники ефективності виконання проекту.

Розвиток команди проекту: виходи

Для оцінювання ефективності команди можуть використовуватися такі показники:

- підвищення навичок членів команди, що дозволяють їм більш ефективно виконувати доручені завдання;

- розвиток компетенцій, що допомагають групі краще працювати як єдина команда;

- скорочення плинності кадрів; і

- підвищення згуртованості команди, коли члени команди можуть відкрито ділитися інформацією й досвідом один з одним для поліпшення загальної ефективності виконання проекту.

Розвиток команди проекту: виходи

У результаті оцінювання загальної ефективності командної роботи команда управління проектом може виявити необхідність проведення спеціального навчання, інструктування, наставництва, допомоги або змін, необхідних для поліпшення ефективності її роботи. При цьому також визначаються підходящі або необхідні ресурси, необхідні для досягнення й впровадження покращень, виявлених у ході оцінки. Дані ресурси й рекомендації для поліпшення команди повинні бути відповідним чином документально оформлені й передані відповідним сторонам. Це особливо важливо, коли члени команди перебувають у профспілці, є сторонами за колективним договором, пов'язані умовами виконання контракту або перебувають в інших подібних ситуаціях.

Розвиток команди проекту: виходи

2. Оновлення факторів середовища підприємства

Фактори середовища підприємства, які можуть бути оновлені в результаті процесу розвитку команди проекту, містять у собі, серед іншого, елементи системи управління персоналом, у тому числі оновлення документів про навчання й результати оцінки навичок співробітників.

5. Управління командою проекту

Управління командою проекту містить у собі контроль діяльності членів команди, забезпечення зворотного зв'язку, розв'язання проблем і управління змінами для підвищення ефективності виконання проекту.

Команда управління проектом спостерігає за діяльністю команди, улагоджує конфлікти, вирішує проблеми й дає оцінку ефективності роботи членів команди.

Результатами управління командою проекту є запити на зміни, оновлення плану управління людськими ресурсами, розв'язання проблем, надання вхідної інформації для оцінювання ефективності роботи й додавання накопичених знань у базу даних організації.

Для управління командою проекту потрібні різні управлінські навички по організації командної роботи й інтеграції зусиль членів команди для формування високопродуктивної команди.

Управління командою припускає наявність комбінації навичок, серед яких особливого значення набувають навички спілкування, урегулювання конфліктів, навички ведення переговорів і здійснення керівництва.

Менеджери проектів повинні давати членам команди завдання, що вимагають серйозних зусиль, і забезпечувати заохочення за високу ефективність роботи.

Управління командою проекту: входи, інструменти і методи, виходи

Блок-схема даних при управлінні командою проекту

Управління командою проекту: входи

1. Призначення персоналу проекту. У результаті призначення персоналу проекту розробляється документація, що включає список членів команди проекту.

2. План управління проектом (див. тему Управління інтеграцією) містить план управління людськими ресурсами.

План управління людськими ресурсами містить у собі, серед іншого:

- ролі й сфери відповідальності;

- організацію проекту; і

- план управління забезпеченням проекту персоналом.

Управління командою проекту: входи

3. Оцінювання ефективності роботи команди

Команда управління проектом дає офіційну й неофіційну оцінку ефективності роботи команди проекту. На підставі регулярних оцінок ефективності роботи команди проекту можуть виконуватися дії з розв’язання проблем, поліпшення комунікацій між членами команди, вирішення конфліктних ситуацій і укріплення взаємодії серед членів команди.

Управління командою проекту: входи

4. Звіти про виконання

Звіти про виконання подають інформацію про відповідність поточного статусу проекту прогнозам його виконання. Управління командою проекту передбачає відстеження результатів виконання проекту в таких областях: управління розкладом, управління вартістю, контроль якості й підтвердження змісту. Інформація, що міститься у звітах про виконання разом із прогнозами, допомагає у визначенні майбутніх вимог до людських ресурсів, створенні системи визнання заслуг і заохочень і відновленні плану управління забезпеченням проекту персоналом.

Управління командою проекту: входи

5. Активи процесів організації, які можуть впливати на процес управління командою проекту, містять у собі, серед іншого:

- похвальні грамоти;

- інформаційні бюлетені;

- веб-сайти;

- систему преміювання;

- одяг з корпоративною символікою; і

- інші інструменти заохочення організації.

Управління командою проекту: інструменти і методи

1. Спостереження й обговорення використовуються для того, щоб бути в курсі процесу виконання робіт і настроїв, що панують серед членів команди проекту. Команда управління проектом стежить за такими показниками, як прогрес у створенні результатів проекту, досягнення, якими члени команди можуть пишатися, і проблеми, викликані міжособистісними протиріччями.

Управління командою проекту: інструменти і методи

2. Оцінювання ефективності виконання проекту. Цілями оцінювання ефективності виконання протягом проекту є уточнення розподілу ролей і відповідальності, забезпечення конструктивного зворотного зв'язку членам команди, виявлення невідомих або нерозв’язаних проблем, розробку індивідуальних планів навчання й постановку конкретних цілей на майбутні періоди часу.

Необхідність офіційної або неофіційної оцінки ефективності виконання проекту залежить від тривалості проекту, його складності, норм організації, положень трудових контрактів, укладених зі співробітниками, а також від кількості і якості засобів спілкування.

Управління командою проекту: інструменти і методи

3. Урегулювання конфліктів

В умовах проекту конфлікти неминучі. Джерелами конфліктів можуть стати дефіцит ресурсів, розміщення пріоритетів при складанні розкладу або особисті стилі роботи.

Наявність прийнятих у команді принципів, норм і устояної практики управління проектами, наприклад планування комунікацій і визначення ролей, сприяє зниженню кількості виникаючих конфліктів.

Управління командою проекту: інструменти і методи

Успішне врегулювання конфліктів приводить до більш високої продуктивності й позитивних робочих взаємин.

При правильному управлінні наявність різних думок з якихось питань є позитивним чинником, що сприяє творчому підходу до виконуваної роботи й прийняття правильних рішень.

Якщо наявність різних думок стає негативним фактором, то члени команди проекту повинні самі постаратися вирішити свої конфлікти.

Якщо відбувається загострення конфлікту, то менеджер проекту повинен посприяти в урегулюванні конфлікту таким чином, щоб рішення влаштовувало всі залучені в конфлікт сторони.

Конфлікт варто врегулювати на ранній стадії й, як правило, конфіденційно, прямо й при співробітництві обох сторін. Якщо конфлікт переходить у деструктивну стадію, то для його вирішення можуть бути використані формальні процедури, включаючи заходи дисциплінарного впливу.

Управління командою проекту: інструменти і методи

При врегулюванні конфлікту в умовах команди менеджери проектів повинні враховувати такі характеристики конфлікту й процесу його врегулювання:

- конфлікт природний і приводить до пошуку альтернатив;

- конфлікт є загальною проблемою;

- відкритість допомагає розв'язати конфлікт;

- при вирішенні конфлікту необхідно орієнтуватися на проблеми, а не на особистості; і

- при вирішенні конфлікту необхідно орієнтуватися на сьогодення, а не на минуле.

Управління командою проекту: інструменти і методи

Успіх менеджерів проектів у керуванні своїми командами проектів найчастіше багато в чому залежить від їхньої здатності урегульовувати конфлікти.

У різних менеджерів проектів можуть бути різні стилі вирішення конфліктів. Фактори, що впливають на методи вирішення конфліктів, містять у собі:

- порівняльну важливість і напруженість конфлікту;

- обмеженість часу, доступного для вирішення конфлікту;

- посади, займані учасниками конфлікту; і

- мотивацію до вирішення конфлікту в довгостроковій або короткостроковій перспективі.

Управління командою проекту: інструменти і методи

Існує шість основних методів, використовуваних для вирішення конфліктів. Оскільки кожний з них має своє власне призначення й застосування, методи наведені в невизначеному порядку:

- Уникнення/запобігання. Відступ від фактичної або потенційної конфліктної ситуації.

- Згладжування/примирення. Підкреслення точок дотику замість областей протиріч.

- Компроміс. Пошук рішень, які будуть деякою мірою задовільними для всіх сторін.

- Примус. Лобіювання чиєїсь точки зору за рахунок інших; можливі тільки рішення «один виграв - усі програли».

- Співробітництво. Об'єднання множини точок зору й поглядів з різних перспектив; приводить до досягнення консенсусу й підтримки рішення всіма сторонами.

- Конфронтація/розв'язання проблем. Конфлікт розцінюється як проблема, яку необхідно розв’язати шляхом дослідження альтернатив; потрібні стосунки у вигляді взаємних поступок і відкритий діалог.

Управління командою проекту: інструменти і методи

4. Журнал реєстрації проблем

При управлінні командою проекту виникають проблеми. У журналі реєстрації проблем у писемній формі вказуються конкретні особи, в обов'язки яких входить розв'язання конкретних проблем на певний термін. При розв'язанні проблем усуваються перешкоди, які можуть заважати команді в досягненні її цілей.

Управління командою проекту: інструменти і методи

5. Навички міжособистісних стосунків. Для аналізу ситуацій і відповідної взаємодії зі членами команди менеджери проектів використовують комбінацію технічних, соціальних навичок.

Використання відповідних навичок міжособистісних стосунків допомагає менеджерам проектів покористуватися із сильних сторін всіх членів команди.

Деякі з навичок міжособистісних стосунків, якими менеджери проектів користуються найчастіше:

• Лідерство.

• Вплив.

• Ефективне прийняття рішень

Управління командою проекту: інструменти і методи

Лідерство. Для успіху проекту потрібні розвинені лідерські навички. Лідерство важливо на всіх фазах життєвого циклу проекту. Особливо важливо передавати членам команди загальне бачення проекту й надихати їх на досягнення високої ефективності роботи.

Управління командою проекту: інструменти і методи

Вплив. Оскільки менеджери проектів найчастіше мають лише незначні прямі повноваження відносно членів своїх команд у матричних умовах або зовсім не мають таких, їхня здатність вчасно впливати на зацікавлені сторони проекту є критично важливою для успіху проекту. Ключові навички надання впливу містять у собі:

• здатність переконливо й чітко викладати точку зору й свою позицію з яких-небудь питань;

• високий рівень навичок активного й ефективного вислуховування;

• розгляд різних перспектив у будь-якій ситуації; і

• збір істотної й критично важливої інформації для розв'язання важливих проблем і досягнення угод при збереженні взаємної довіри.

Управління командою проекту: інструменти і методи

Ефективне прийняття рішень. Ефективне прийняття рішень має на увазі здатність проведення переговорів і надання впливу на організацію й команду управління проектом.

Деякі з рекомендацій відносно прийняття рішень:

• необхідно зосередитися на цілях, які мають бути досягнуті;

• необхідно дотримуватися процедури прийняття рішень;

• необхідно вивчати фактори середовища;

• необхідно розвивати особистісні якості членів команди;

• необхідно стимулювати творчий підхід команди до роботи; і

• необхідно управляти можливостями й ризиками.

Управління командою проекту: виходи

1. Оновлення факторів середовища підприємства

Фактори середовища підприємства, які можуть потребувати оновлень у результаті процесу управління командою проекту, містять у собі, серед іншого:

- вхід для оцінювання ефективності роботи організації; і

- оновлення інформації про навички персоналу.

Управління командою проекту: виходи

2. Оновлення активів процесів організації

Активи процесів організації, які можуть потребувати оновлень у результаті процесу управління командою проекту, містять у собі, серед іншого:

- документацію за історичною інформацією й накопиченими знаннями;

- шаблони; і

- стандартні процеси організації.

Управління командою проекту: виходи

3. Запити на зміни. Зміни в призначеннях персоналу, як внаслідок вибору, так і в силу непередбачених обставин, можуть вплинути на іншу частину плану управління проектом. Якщо проблеми, викликані призначеннями персоналу, зривають план управління проектом (наприклад, потрібне продовження строків або збільшення бюджету), то необхідно оформити запит на зміну, який буде розглянутий у рамках процесу здійснення загального управління змінами. Прикладами зміни в призначеннях персоналу можуть бути доручення співробітникам інших задач, передача частини робіт стороннім організаціям і заміна звільнених членів команди новими співробітниками.

Управління командою проекту: виходи

Попереджуючими діями є ті дії, які розробляються для зниження ймовірності й/або впливу проблем до їхнього виникнення.

До таких заходів можуть належати навчання виконанню суміжних функцій, метою яких є зниження числа проблем, що виникають у випадку відсутності деяких членів команди проекту, і додаткове роз'яснення окремих ролей для забезпечення виконання всіх необхідних обов'язків.

Управління командою проекту: виходи

4. Оновлення плану управління проектом

Елементи плану управління проектом, які можуть бути оновлені, містять у собі, серед іншого, план управління забезпеченням проекту персоналом.

Дякую за увагу!

Управління строками у проекті

1. Визначення операцій

2. Визначення послідовності операцій

3. Оцінювання ресурсів операцій

4. Оцінювання тривалості операцій

5. Розробка розкладу

6. Управління розкладом

7. Методичні засади визначення трудомісткості проекту інформатизації

7.1. Модель СОСОМО (Constructive Cost Model)

7.2. Метод функціональних балів (FPA)

Управління строками в проекті включає процеси, необхідні для забезпечення того, щоб проект завершився вчасно:

• Визначення операцій.

• Визначення послідовності операцій.

• Оцінювання ресурсів операцій.

• Оцінювання тривалості операцій.

• Розробка розкладу.

• Управління розкладом.

Визначення операцій – процес визначення конкретних операцій, які необхідно виконати для одержання результатів проекту.

Визначення послідовності операцій – процес виявлення й документування залежностей між операціями проекту.

Оцінювання ресурсів операцій – процес оцінювання типів і кількості матеріалів, людських ресурсів, обладнання або поставок, необхідних для виконання кожної операції.

Оцінювання тривалості операцій – процес приблизного визначення кількості робочих періодів, необхідних для завершення окремих операцій при передбачуваних ресурсах.

Розробка розкладу – процес аналізу послідовностей операцій, їхньої тривалості, потреби в ресурсах і часових обмеженнях для створення розкладу проекту.

Управління розкладом – процес моніторингу статусу проекту для коректування його виконання й внесення змін у базовий розклад.

РЯД ПРИПУЩЕНЬ ПРИ ВИКЛАДІ МАТЕРІАЛУ

• Усі процеси взаємодіють як між собою, так і з процесами інших галузей застосування знань з проектного менеджменту.

• Кожний процес виконується, як правило, по одному разу на кожній фазі проекту.

• Хоча процеси представлені як дискретні елементи з чітко визначеними зв'язками, на практиці вони можуть перекриватися і взаємодіяти між собою в різний спосіб.

1. Визначення операцій

Визначення операцій – процес визначення конкретних операцій, які необхідно виконати для одержання результатів проекту.

У процесі розробки Ієрархічної Структури Робіт (ІСР) визначаються результати самого нижнього рівня - пакети робіт.

Пакети робіт проекту звичайно розкладаються на більш дрібні елементи за назвою "операції", які описують роботу, необхідну для виконання пакета робіт.

Операції надають основу для оцінювання, планування, виконання, моніторингу й контролю робіт із проекту. Мається на увазі, що визначення й планування операцій розкладу в даному процесі проводяться у такий спосіб, який забезпечує досягнення цілей проекту.

Визначення операцій: входи, інструменти й методи, виходи

Блок-схема даних при визначенні операцій

Визначення операцій: входи

1. Базовий план по змісту Результати, обмеження й допущення проекту документуються в базовому плані по змісту (див тему Управління змістом) і детально розглядаються при визначенні операцій.

2. Фактори середовища підприємства, які можуть впливати на процес визначення операцій, містять у собі інформаційну систему управління проектами, не обмежуючись тільки нею.

3. Активи процесів організації, які можуть впливати на процес визначення операцій, містять у собі, серед іншого:

• існуючі формальні й неформальні, пов'язані із плануванням, правила, процедури й провідні вказівки, такі як методологія складання розкладу, які враховуються при визначенні операцій;

• базу накопичених знань, що містить історичну інформацію щодо списків операцій, використаних у попередніх подібних проектах.

Визначення операцій: інструменти і методи

1. Декомпозиція У застосуванні до визначення операцій метод декомпозиції має на увазі поділ пакетів робіт проекту на більш дрібні й більш керовані елементи, називані «операціями». Операції являють собою дії, необхідні для виконання пакета робіт. У процесі визначення операцій кінцеві виходи визначаються як дії, а не як результати, як це відбувається в процесі створення ІСР (див тему Управління змістом).

Список операцій, ІСР і словник ІСР можуть розроблятися послідовно або паралельно, при цьому основою розробки остаточного списку операцій служать ІСР і словник ІСР. Кожний пакет робіт в ІСР розділяється на операції, необхідні для одержання результатів цього пакета робіт. Участь членів команди в процесі декомпозиції може привести до одержання кращих і більш точних результатів.

Визначення операцій: інструменти і методи

2. Планування методом хвилі, що набігає, являє собою вид планування способом послідовної розробки, при якому робота, що повинна бути виконана в найближчій перспективі, планується в деталях на нижчому рівні ІСР, а робота у віддаленому майбутньому планується на більш високому рівні ІСР.

Отже, робота може існувати на різних рівнях деталізації залежно від того, на якій стадії життєвого циклу проекту вона перебуває. Наприклад, під час раннього стратегічного планування, коли інформація ще недостатньо визначена, пакети робіт можуть бути декомпозовані до рівня контрольних подій.

По мірі надходження інформації про майбутні у найближчій перспективі події може бути проведена їхня декомпозиція до операцій.

Визначення операцій: інструменти і методи

3. Шаблони Як шаблон для нового проекту найчастіше можна використовувати стандартний перелік операцій з попереднього проекту або його частину. Інформація про відповідні параметри операцій у шаблонах також може містити іншу описову інформацію, корисну при визначенні операцій. Шаблони можуть також застосовуватися для ідентифікації типових контрольних подій розкладу.

4. Експертна оцінка Експертиза при визначенні операцій може проводитися членами команди проекту або інших експертів, що мають досвід і навички розробки детальних описів змісту проектів, ІСР і розкладів проектів.

Визначення операцій: виходи

1. Список операцій - це вичерпний перелік, який включає всі операції розкладу, передбачені для даного проекту.

У список операцій входять ідентифікатор операції й опис змісту робіт з кожної операції, деталізований настільки, щоб члени команди проекту розуміли, які роботи необхідно провести.

Визначення операцій: виходи

2. Параметри операції розширюють її опис шляхом визначення ряду елементів, пов'язаних з кожною операцією. Елементи кожної операції формуються із часом. На початкових стадіях проекту вони можуть містити в собі ідентифікатор операції, ідентифікатор ІСР і назву операції, а наприкінці формування – коди й опис операції, переліки попередніх і наступних операцій, логічні взаємозв'язки, випередження й затримки, вимоги до ресурсів, статусні дати, обмеження й допущення.

Параметри операції можуть бути використані для визначення особи, відповідального за виконання роботи, географічного місця розташування виконання робіт і типу операції, наприклад рівень завантаження, дискретне або розподілене завантаження. Параметри операції використовуються для розробки розкладу, а також для вибору, систематизації й різноманітних сортувань запланованих операцій у звітах. Кількість параметрів розрізняється залежно від прикладної області.

Визначення операцій: виходи

3. Список контрольних подій

Контрольна подія (віха) - це важливий момент або подія проекту.

Список контрольних подій визначає всі контрольні події, указуючи при цьому, чи є контрольна подія обов'язковою (наприклад, необхідною відповідно до контракту) або необов'язковою (наприклад, що ґрунтується на історичній інформації).

2. Визначення послідовності операцій

Визначення послідовності операцій - процес визначення й документування взаємозв'язків між операціями проекту.

Визначення послідовності операцій здійснюється за допомогою логічних взаємозв'язків. Кожна операція й контрольна подія, крім першої й останньої, пов'язані принаймні з однією попередньою й однією наступною операцією. Іноді буває необхідно використовувати час випередження або затримки між операціями для підтримки реалістичного й досяжного розкладу проекту.

Визначення послідовності може бути виконане за допомогою програм управління проектами або за допомогою автоматичних або ручних методів. Останній варіант є більш ефективним у невеликих проектах і на ранніх фазах великих проектів, коли деталізація ще не така значна.

Ручну і комп'ютерну технології можна використовувати в поєднанні.

Визначення операцій: входи, інструменти й методи, виходи

Блок-схема даних при визначенні послідовності операцій

Визначення операцій: входи

1. Список операцій Описано раніше

2. Параметри операції Описано раніше. Параметри операції можуть описувати необхідну послідовність подій або визначені зв'язки з попередніми й наступними операціями.

3 Список контрольних подій Описано раніше. Список контрольних подій може містити розрахункові дати конкретних контрольних подій.

4 Опис змісту проекту (Див. тему Управління замістом) містить опис змісту продукту, що включає характеристики продукту, здатні вплинути на визначення послідовності операцій, такі як фізичний план заводу, що повинен бути споруджений, або інтерфейси підсистем у проекті, пов'язаному із програмним забезпеченням. Хоча дані впливи часто очевидні в списку операцій, як правило, для забезпечення точності проводиться перевірка опису змісту продукту.

5. Активи процесів організації, які можуть впливати на процес визначення послідовності операцій, містять у собі, серед іншого, проектні архіви з корпоративної бази знань, використовувані в методології складання розклади.

Визначення операцій: інструменти й методи

1. Метод діаграм передування в методології критичного шляху для побудови сітьової діаграми проекту, у якій операції зображуються у вигляді квадратів або прямокутників (називаних «вузлами»), а логічні взаємозв'язки, що існують між ними, - стрілками. Цей метод також називається “операціями у вузлах” або “вершини-роботи”; він використовується в більшості пакетів програм управління проектами. Метод діаграм передування включає чотири типи залежностей, або логічних взаємозв'язків:

Фініш-•Старт.

Фініш-•Фініш.

Старт-•Старт.

Старт-•Фініш.

Визначення операцій: інструменти й методи

2. Визначення залежностей

Для визначення послідовності операцій використовуються три типи залежностей:

•  Обов'язкові залежності.

•  Дискреційні залежності.

•  Зовнішні залежності.

Визначення операцій: інструменти й методи

Обов'язкові залежності – це такі залежності, які потрібні за контрактом або є невід'ємною властивістю виконуваної роботи. Команда проекту визначає, які залежності є обов'язковими, під час процесу визначення послідовності операцій.

Обов'язкові залежності часто мають на увазі фізичні обмеження, наприклад у будівельному проекті, де неможливо звести наземну конструкцію до спорудження фундаменту, або в проекті, пов'язаному з електронікою, де прототип повинен бути створений до того, як він буде протестований. Обов'язкові залежності також іноді називають «жорсткою логікою».

Визначення операцій: інструменти й методи

Дискреційні залежності. У ході процесу визначення послідовності операцій команда проекту визначає, які залежності є дискреційними. Дискреційні залежності іноді також називають "кращою логікою", "переважною логікою" або "м'якою логікою". Дискреційні залежності встановлюються на основі передових методів організації робіт у певній прикладній області або в рамках незвичайного аспекту проекту, де краща особлива послідовність, хоча можуть існувати й інші прийнятні послідовності. Дискреційні залежності повинні бути повністю задокументовані, тому що вони можуть створювати необґрунтовані повні часові резерви й можуть обмежити наступні варіанти складання розкладу. При застосуванні методів швидкого проходу повинен проводитися аналіз цих дискреційних залежностей і розглядатися необхідність їхньої модифікації або видалення.

Визначення операцій: інструменти й методи

Зовнішні залежності. У ході процесу визначення послідовності операцій команда управління проектом виявляє зовнішні залежності.

Зовнішні залежності - це такі залежності, які включають взаємозв'язки між операціями проекту й операціями поза проектом. Ці залежності звичайно не піддаються контролю з боку команди проекту. Наприклад, у проекті по розробці програмного забезпечення операція тестування може залежати від поставки апаратного забезпечення сторонньою організацією, а в деяких будівельних проектах підготовчі роботи на ділянці можна починати тільки після видачі офіційного підтвердження, що будівництво не нанесе збитку навколишньому середовищу.

Визначення операцій: інструменти й методи

3. Застосування випереджень і затримок

Команда управління проектом визначає залежності, які можуть зажадати випередження або затримки для точного визначення логічного взаємозв'язку. Використання затримок і випереджень не повинне заміняти логіки розкладу. Операції й пов'язані з ними допущення повинні документуватися.

Випередження допускає прискорення строків виконання наступної операції. Наприклад, у проекті по будівництву нового офісного будинку озеленення може бути заплановане на 2 тижні раніше запланованого завершення дефектної відомості. Це може бути представлене у вигляді відносини «фініш-старт» з 2-тижневим випередженням.

Затримка встановлює відстрочку виконання наступної операції. Наприклад, команда технічних фахівців може приступитися до редагування проекту великого документа через п'ятнадцять днів після початку його написання. Це може бути представлене у вигляді відносини « старт-старт» з 15-денною затримкою.

Визначення операцій: інструменти й методи

.4 Шаблони сіток. Стандартизовані шаблони сітьових діаграм можуть полегшити підготовку сіток операцій проекту. Вони можуть містити в собі як проект у цілому, так і його частину. Частини сітьової діаграми проекту часто називають «підсітями» або «фрагментами». Шаблони підсітей особливо корисні в тих випадках, коли проект включає кілька ідентичних або майже ідентичних результатів, таких як , наприклад, модулі програм, які кодують, у проекті з розробки програмного забезпечення або фазу запуску дослідницького проекту.

Визначення операцій: виходи

1. Сітьові діаграми проекту являють собою схематичне відображення запланованих операцій проекту й логічних взаємозв'язків між ними, також називаних «залежностями». Сітьова діаграма проекту може бути складена вручну або за допомогою програм управління проектами. Вона може включати всі деталі проекту або містити тільки одну або кілька загальних операцій. Діаграма може доповнюватися зведеною описовою частиною, у якій описаний основний підхід, що застосовувався для визначення послідовності операцій. Будь-які незвичайні послідовності операцій у рамках сіті повинні бути повністю описані в описовій частині.

Визначення операцій: виходи

2. Оновлені версії документів проекту

Документи проекту, які можуть бути оновлені, містять у собі, серед іншого:

• списки операцій;

• параметри операцій;

• реєстр ризиків.

3. Оцінювання ресурсів операцій

Оцінювання ресурсів операцій - це процес оцінювання типу й кількості матеріалів, людських ресурсів, обладнання або поставок, необхідних для виконання кожної операції.

Процес оцінювання ресурсів операцій тісно координується із процесом оцінювання вартості

Оцінювання ресурсів операцій: входи, інструменти, методи й виходи

Блок-схема даних при оцінюванні ресурсів операцій

Оцінювання ресурсів операцій:входи

1. Список операцій визначає операції, яким будуть потрібні ресурси.

2. Параметри операцій, розроблені в ході процесів визначення операцій і визначення послідовності операцій, надають основний інформаційний вхід, використовуваний при оцінці ресурсів, необхідних для кожної операції зі списку операцій.

Оцінювання ресурсів операцій:входи

3. Ресурсні календарі. Інформація про те, які ресурси (такі як люди, обладнання й матеріали) потенційно доступні в той час, коли заплановані операції, описана в темах Управління людськими ресурсами і Управління закупівлями, застосовується для оцінювання використання ресурсів. Ресурсні календарі встановлюють, коли й наскільки довго певні ресурси проекту будуть доступні в ході проекту. Ця інформація може перебувати на рівні операції або проекту. Дане знання містить у собі розгляд таких параметрів, як досвід і/або рівень навичок ресурсу, а також різних географічних місць знаходження ресурсів і того, коли вони можуть бути отримані.

Змішаний ресурсний календар містить у собі доступність, здатності й навички людських ресурсів (тема Управління людськими ресурсами. Наприклад, на ранніх фазах проектування пул ресурсів може містити в собі велике число молодших і старших інженерів. Проте, на більш пізніх фазах того ж проекту пул може бути скорочений до осіб, що мають достатні знання про проект завдяки досвіду роботи на його попередніх фазах.

Оцінювання ресурсів операцій:входи

4. Фактори середовища підприємства, які можуть впливати на процес оцінювання ресурсів операцій, містять у собі, серед іншого, доступність і навички ресурсів.

5. Активи процесів організації, які можуть впливати на процес оцінювання ресурсів операцій, містять у собі, серед іншого:

• правила й процедури, пов'язані з набором персоналу;

• правила й процедури, пов'язані з орендою й покупкою сировини й устаткування;

• історичну інформацію про типи ресурсів, використаних для подібних робіт у попередніх проектах.

Оцінювання ресурсів операцій: інструменти й методи

1. Експертна оцінка. Експертні оцінки часто необхідні для того, щоб оцінити пов'язані з ресурсами входи цього процесу. Таку оцінку може дати будь-яка особа або група осіб, що мають спеціальну підготовку в області планування й оцінки ресурсів.

2. Аналіз альтернатив. У багатьох запланованих операцій є альтернативні методи їхньої реалізації. До них належить використання різних рівнів спроможностей або навичок ресурсів, машин різних габаритів або типів, різних інструментів (ручних або автоматичних), а також прийняття рішень «виробляти чи купувати» відносно ресурсів.

3. Публіковані оцінні дані. Деякі компанії регулярно публікують дані про продуктивність і одиничні розцінки ресурсів по широкому спектру робочих професій, матеріальних засобів і обладнання по різних країнах і регіонам окремих країн.

Оцінювання ресурсів операцій: інструменти й методи

4. Оцінювання «знизу нагору». Коли операція не може бути оцінена з достатнім ступенем упевненості, роботи операції розділяються на більш дрібні елементи. Потреби в ресурсах кожного деталізованого елемента робіт оцінюються, і ці оцінки потім поєднуються в загальну кількість по кожному ресурсу операції.

5. Програми управління проектами здатні надати допомогу в плануванні, організації й управлінні пулами ресурсів, а також у розробці оцінок ресурсів. Залежно від можливостей програмного забезпечення можна визначати ієрархічні структури ресурсів, доступність ресурсів, вартості ресурсів і різноманітні ресурсні календарі, що сприяють оптимізації використання ресурсів.

Оцінювання ресурсів операцій: виходи

1. Вимоги до ресурсів операцій. Вихід процесу оцінювання ресурсів операцій визначає типи й кількість ресурсів, необхідних для кожної операції в пакеті робіт. Дані вимоги можуть бути об'єднані для оцінювання ресурсів для кожного пакета робіт. Ступінь деталізації й специфічності описів вимог до ресурсів може розрізнятися залежно від прикладної області. Документація по ресурсних вимогах для кожної операції може містити в собі підстава для оцінки для кожного ресурсу, а також допущення по типах ресурсів, їхньої доступності й необхідній кількості.

Оцінювання ресурсів операцій: виходи

2. Ієрархічна структура ресурсів

Ієрархічна структура ресурсів являє собою структуру ідентифікованих ресурсів по категоріях і типах ресурсів. Приклади категорій ресурсів містять у собі людські ресурси, матеріали, обладнання й сировину. Типи ресурсів можуть включати рівень навичок, рівень класу або іншу інформацію, що відповідає проекту. Ієрархічна структура ресурсів корисна для організації даних і підготовки звітності за розкладом проекту з інформацією про використання ресурсів.

Оцінювання ресурсів операцій: виходи

3. Оновлені версії документів проекту

Документи проекту, які можуть бути оновлені, містять у собі, серед іншого:

• список операцій;

• параметри операцій;

• ресурсні календарі.

4. Оцінювання тривалості операцій

Оцінювання тривалості операцій - процес приблизного визначення кількості робочих періодів, необхідних для виконання окремих операцій при передбачуваних ресурсах.

При оцінюванні тривалості операцій використовується інформація про зміст робіт операції, необхідних типах ресурсів, оцінках кількості ресурсів, а також ресурсних календарях. Входи для оцінювання тривалості операцій виходять від одного або кількох членів команди проекту, найбільшою мірою знайомих з характером робіт певної операції. Оцінювання тривалості поступово уточнюється, і процес ураховує якість і доступність даних на вході.

Процес оцінювання тривалості операцій вимагає, щоб були оцінені трудомісткість робіт і кількість ресурсів, необхідних для виконання операції; вони використовуються для зразкового оцінювання числа робочих періодів (тривалості операції), необхідних для виконання операції. Для кожної оцінки тривалості операції документуються всі дані й допущення, які використовувалися при оцінці тривалості.

Більшість програм управління проектами, що дозволяють складати розклад, розв'язують дану ситуацію за допомогою календаря проекту й альтернативних ресурсних календарів, обумовлених ресурсами, що мають специфічні робітники періоди. На додаток до логіки послідовності, операції виконуються відповідно до календаря проекту й відповідних ресурсних календарів.

Оцінювання тривалості операцій: входи, інструменти, методи й виходи

Блок-схема даних при оцінюванні тривалості операцій

Оцінювання тривалості операцій: входи

1. Список операцій. Розглянуто раніше.

2. Параметри операцій. Розглянуто раніше.

3. Вимоги до ресурсів операцій. Оцінювання вимог до ресурсів операцій впливають на тривалість операцій, тому що призначені для операції ресурси і їхня доступність впливають на тривалість більшості операцій. Наприклад, якщо для операції призначаються додаткові ресурси або ресурси з більш низькими навичками, їхня ефективність або продуктивність може бути знижена через збільшення потреби в комунікації, навчанні й координації.

Оцінювання тривалості операцій: входи

4. Ресурсні календарі. Ресурсний календар, що розробляється у рамках процесу оцінювання потреби в ресурсах операцій, може містити в собі тип, наявність і здатності людських ресурсів (тема Управління людськими ресурсами). Також ураховуються тип, кількість, доступність і спроможності як обладнання, так і матеріальних ресурсів, які можуть впливати на тривалість запланованих операцій. Наприклад, при призначенні старших і молодших штатних співробітників з повною зайнятістю, як правило, можна чекати, що старший штатний співробітник буде виконувати певну операцію за меншу кількість часу, ніж молодший.

Оцінювання тривалості операцій: входи

5. Опис змісту проекту. При оцінюванні тривалості операцій ураховуються обмеження й допущення, що містяться в описі змісту проекту. Прикладами допущень можуть слугувати, серед іншого:

• існуючі умови;

• наявність інформації;

• тривалість звітних періодів.

Прикладами обмежень можуть слугувати, серед іншого:

• наявні кваліфіковані ресурси;

• умови й вимоги контракту.

Оцінювання тривалості операцій: входи

6. Фактори середовища підприємства, які можуть впливати на процес оцінювання тривалості операцій, містять у собі, серед іншого:

• бази даних з оцінювання тривалості й інші довідкові дані;

• показники продуктивності;

• опубліковану комерційну інформацію.

7. Активи процесів організації, які можуть впливати на процес оцінювання тривалості операцій, містять у собі, серед іншого:

• історичну інформацію про тривалість;

• календарі проекту;

• методологію складання розкладу;

• накопичені знання.

Оцінювання тривалості операцій: інструменти й методи

1. Експертні оцінки, засновані на історичній інформації, можуть надати інформацію про оцінку тривалості або про рекомендовану максимальну тривалість операцій з попередніх подібних проектів.

Також експертні оцінки можуть бути використані для визначення необхідності використання різних методів оцінювання і способів вирішення розбіжностей між ними.

Оцінювання тривалості операцій: інструменти й методи

2. Оцінка за аналогами має на увазі використання таких параметрів як тривалість, бюджет, розмір, вага й складність із попередніх подібних проектів як основу для оцінювання тих же параметрів або вимірів майбутнього проекту. При оцінці тривалості даний метод опирається на фактичну тривалість попередніх подібних проектів як основу для оцінювання тривалості поточного проекту. Цей підхід, що дозволяє оцінювати загальну величину, іноді адаптується залежно від відомих розходжень у складності проекту.

Оцінювання тривалості операцій: інструменти й методи

Найчастіше оцінка тривалості за аналогами використовується для оцінювання тривалості проекту, коли обсяг детальної інформації про проект обмежений, наприклад на його ранніх фазах. При оцінюванні за аналогами застосовується історична інформація й експертна оцінка.

Як правило, оцінювання за аналогами обходиться дешевше й займає менше часу, ніж інші методи, але при цьому вона звичайно виявляється й менш точною.

Оцінювання за аналогами можуть застосовуватися до всього проекту або до його частин, а також можуть використовуватися разом з іншими методами оцінювання. Оцінка за аналогами виявляється найбільш надійною в тих випадках, коли попередні операції схожі по суті, а не тільки за формою, а члени команди проекту, що підготовляють оцінки, мають необхідний досвід.

Оцінювання тривалості операцій: інструменти й методи

3. Параметрична оцінка використовує статистичні взаємозв'язки між історичними даними й іншими змінними (наприклад, площею у квадратних метрах у будівництві) для чисельної оцінки параметрів операції, таких як вартість, бюджет і тривалість.

Тривалість операцій може бути кількісно визначена шляхом множення кількості робіт, які необхідно виконати, на кількість робочого часу, затрачувана на виробництво одиниці роботи.

Даний метод може забезпечувати більш високий ступінь точності залежно від досвіду й даних, що лежать в основі моделі. Параметричні оцінки строків можуть застосовуватися до всього проекту або до його частин разом з іншими методами оцінювання.

Оцінювання тривалості операцій: інструменти й методи

4. Оцінювання по трьох точках. Точність оцінок тривалості операцій може бути поліпшена за допомогою розгляду невизначеностей оцінок і ризиків. Дана концепція походить із Методу оцінювання й аналізу програм (PERT). Для оцінювання діапазону тривалості операції PERT використовує три оцінювання:

• Найбільш імовірна (tм). Тривалість операції визначається з урахуванням попереднього виділення ресурсів, їхньої продуктивності, реалістичної оцінки їхньої доступності для виконання даної операції, залежності від інших учасників і затримок.

• Оптимістична (tо). Тривалість операції ґрунтується на аналізі найбільш сприятливого сценарію розвитку операції.

• Песимістична (tр). Тривалість операції ґрунтується на аналізі найбільш несприятливого сценарію розвитку операції.

Оцінювання тривалості операцій: інструменти й методи

Аналіз PERT дозволяє визначити очікувану (t) тривалість операції за допомогою обчислення середнього зваженого цих трьох оцінок:

Оцінювання тривалості, засновані на даному рівнянні (або навіть на простому середньому арифметичному цих трьох точок), можуть дати більше високу точність, а три точки дозволяють прояснити діапазон невизначеності оцінок тривалості.

Оцінювання тривалості операцій: інструменти й методи

5. Аналіз резервів. Оцінювання тривалості можуть містити в собі резерви на можливі втрати (іноді називані «часовими резервами» або «буферами») у рамках загального розкладу проекту для усунення невизначеності розкладу. Резерв на можливі втрати може виражатися у відсотках від оцінної тривалості операції, у фіксованому числі робочих періодів або може бути розрахований за допомогою методів кількісного аналізу.

У міру надходження більш точної інформації про проект резерви на можливі втрати можуть бути використані, скорочені або усунуті. Можливі втрати повинні бути чітко визначені в документації з розкладу (календар. графіку).

Оцінювання тривалості операцій: виходи

• Оцінювання тривалості операцій - це кількісне оцінювання найбільш імовірного числа робочих періодів, необхідних для виконання операцій.

Оцінки тривалості не містять у собі будь-яких затримок, описаних раніше. Оцінки тривалості операцій можуть включати й діапазон можливих значень. Наприклад:

• Оцінка «2 тижні ± 2 дні» означає, що операція буде виконуватися не менш 8 і не більше 12 днів (за умови п'ятиденного робочого тижня).

• Оцінка «ймовірність того, що тривалість операції перевищить 3 тижня, становить 15 %» означає, що операція з високою ймовірністю (85 %) буде виконана за час, що не перевищує 3-х тижнів.

Оцінювання тривалості операцій: виходи

2. Оновлені версії документів проекту

Документи проекту, які можуть бути оновлені, містять у собі, серед іншого:

• параметри операцій;

• допущення, прийняті при оцінюванні тривалості операцій, такі як рівень навичок і доступність ресурсів.

5. Розробка розкладу

Розробка розкладу - процес аналізу послідовностей операцій, їхньої тривалості, вимог до ресурсів і часових обмежень для створення розкладу проекту.

Уведення операцій, тривалості й ресурсів в інструмент складання розкладу, наприклад MS Project, генерує розклад із запланованими датами завершення операцій проекту.

Розробка прийнятного розкладу проекту найчастіше є ітеративним процесом. Він визначає заплановані дати старту й фінішу операцій і контрольних подій проекту.

Розробка розкладу може зажадати проведення аналізу й перевірки оцінок тривалості й ресурсів для створення затвердженого розкладу проекту, здатного служити як базовий план, по якому буде проходити відстеження виконання. Перегляд розкладу й підтримка його реалістичності триває на всьому протязі проекту в міру виконання робіт, зміни плану управління проектом і виявлення характеру подій ризику.

Розробка розкладу: входи, інструменти, методи й виходи

Блок-схема даних при розробці розкладу

Розробка розкладу: входи

1. Список операцій. Описаний раніше.

2. Параметри операцій. Описані раніше.

3. Сітьові діаграми проекту. Описані раніше.

4. Вимоги до ресурсів операцій. Описані раніше.

5. Ресурсні календарі. Описані раніше.

6. Оцінювання тривалості операцій. Описані раніше.

7. Опис змісту проекту (див. тему Управління змістом) містить допущення й обмеження, які можуть впливати на розробку розкладу проекту.

8 Фактори середовища підприємства, які можуть впливати на процес розробки розкладу, містять у собі, серед іншого, інструмент складання розкладу, що може бути використаний при розробці розкладу.

9. Активи процесів організації, які можуть впливати на процес розробки розкладу, містять у собі, серед іншого:

• методологію складання розкладу й

• календар проекту.

Розробка розкладу: інструменти й методи

1. Аналіз сіті являє собою технологію створення розкладу проекту. У ньому застосовуються різноманітні аналітичні методи, такі як метод критичного шляху, метод критичного ланцюга, аналіз сценаріїв «що буде, якщо» і вирівнювання ресурсів, що дозволяють розрахувати дати раннього й пізнього старту й фінішу незавершених частин операцій проекту. Деякі шляхи в сіті можуть мати точки злиття або розбіжності, які можна виявити й використовувати в аналізі стиснення розкладу й інших видів аналізу.

Розробка розкладу: інструменти й методи

2. Метод критичного шляху дозволяє розрахувати теоретичні дати раннього старту й фінішу, а також дати пізнього старту й фінішу для всіх операцій без урахування ресурсних обмежень шляхом проведення аналізу проходу вперед і назад по сіті проекту. Отримані дати раннього старту й фінішу не обов'язково є розкладом проекту; вони скоріше вказують періоди часу, у рамках яких можуть бути заплановані операції з урахуванням тривалості операцій, логічних зв'язків, випереджень, затримок і інших відомих обмежень.

Розробка розкладу: інструменти й методи

На розраховані ранні й пізні дати старту й фінішу може впливати загальний часовий резерв операції, що дозволяє робити розклад гнучким і може бути позитивним, негативним або нульовим. Для будь-якого шляху в сіті гнучкість розкладу, називаний «повним часовим резервом», вимірюється позитивною різницею між ранніми й пізніми датами. У критичних шляхів повний часовий резерв або нульовий, або негативний, а заплановані операції на критичному шляху називаються «критичними операціями». Критичний шлях звичайно характеризується нульовим повним часовим резервом. У сітях може існувати кілька шляхів, близьких до критичного. Для створення шляхів у мережі з нульовим або позитивним повним часовим резервом може знадобитися адаптація тривалості операцій, логічних зв'язків, випереджень, затримок і інших часових обмежень. Після підрахунку повного часового резерву шляху в сіті також може бути визначений вільний часовий резерв - період часу, на який операція може бути відкладена, не викликаючи затримки раннього старту будь-якої безпосередньо наступної операції в даному сітьовому шляху.

Розробка розкладу: інструменти й методи

4. Вирівнювання ресурсів являє собою метод аналізу сіті, застосовуваний для розкладу, який уже було проаналізовано методом критичного шляху.

Вирівнювання ресурсів може бути використано, коли загальні або критично важливі необхідні ресурси доступні тільки в певний час або тільки в обмеженій кількості, або для підтримки використання ресурсів на постійному рівні. Вирівнювання ресурсів необхідно при перепризначенні ресурсів, наприклад коли ресурс був призначений для виконання двох або більше операцій у той самий період часу, коли спільні або критично важливі необхідні ресурси доступні тільки в певний час або тільки в обмеженій кількості. Вирівнювання ресурсів найчастіше може приводити до зміни початкового критичного шляху.

Розробка розкладу: інструменти й методи

5. Аналіз сценаріїв «що буде, якщо»

Це аналіз питання: «Що відбудеться, якщо ситуація буде розвиватися по сценарію 'Х'?» У цьому випадку виконується аналіз сіті, при якому за допомогою моделі розкладу прораховуються різні сценарії (наприклад, затримка поставки основних елементів, збільшення тривалості окремих операцій) або моделюється вплив непередбачених зовнішніх факторів (наприклад, страйк або зміна процедури ліцензування). Результати аналізу «що буде, якщо» можуть використовуватися для оцінювання можливості виконати розклад проекту при несприятливих умовах і для складання резервних планів і планів реагування для подолання або пом'якшення наслідків несподіваних ситуацій. Моделювання містить у собі розрахунок різної тривалості проекту при використанні різних допущень про тривалості операцій. Найбільш відомий метод Монте-Карло (тема Управління ризиками), у якому розподіл імовірних значень тривалості операції визначається для кожної операції й використовується для обчислення розподілу ймовірних виходів усього проекту.

Розробка розкладу: інструменти й методи

6. Застосування випереджень і затримок – це уточнення, внесені під час аналізу сіті для розробки життєздатного розкладу.

7. Стиснення розкладу скорочує тривалість проекту без зміни змісту проекту, часових обмежень, статусних дат або інших цільових параметрів розкладу. Методи стиснення розкладу містять у собі:

• Стиснення. Метод стиснення розкладу, у якому аналізуються компроміси між вартістю й розкладом, щоб визначити, яким способом можливо максимально стиснути строки при мінімальних витратах. Приклади стиснення можуть включати схвалення понаднормової роботи, використання додаткових ресурсів або плату за прискорення поставки для операцій на критичному шляху. Стиснення ефективно тільки для тих операцій, де додаткові ресурси здатні скоротити тривалість. Стиснення не завжди створює життєздатну альтернативу й може привести до збільшення ризиків і/або вартості.

• Швидкий прохід. При цьому методі стиснення розкладу фази або операції, звичайно виконувані послідовно, виконуються паралельно. Швидкий прохід може привести до доробок і збільшення ризику. Швидкий прохід застосуємо тільки в тому випадку, коли операції можуть накладатися одна на іншу для скорочення тривалості.

Розробка розкладу: інструменти й методи

8. Інструмент складання розкладу

Автоматичні інструменти складання розкладу полегшують процес складання розкладу, генеруючи дати старту й фінішу на основі інформації про операції, сітьові діаграми, ресурси і тривалості операцій. Інструмент складання розкладу може використовуватися разом з іншими програмними засобами для управління проектами або неавтоматичними методами.

Розробка розкладу: виходи

1. Розклад проекту містить, щонайменше, планову дату старту й планову дату фінішу для кожної операції.

Якщо планування ресурсів проводиться на ранній стадії, розклад проекту буде залишатися попереднім до підтвердження виділення ресурсів і затвердження розрахункових дат початку й завершення. Звичайно цей процес відбувається не пізніше, ніж буде розроблений план управління проектом. Може бути також розроблений директивний розклад проекту з певними статусними датами старту й фінішу для кожної операції. Розклад проекту може бути представлений в узагальненому вигляді, іноді називаному «укрупненим розкладом» або «розкладом контрольних подій», або ж у докладному вигляді.

Розробка розкладу: виходи

Хоча розклад проекту може бути представлений у формі таблиці, найчастіше використовується графічне подання в одному з таких форматів:

• Діаграми контрольних подій. Ці діаграми аналогічні стрічковим діаграмам, але показують тільки заплановані дати початку або завершення одержання основних результатів і ключові зовнішні події.

• Стрічкові діаграми. Ці діаграми, у яких смужки представляють операції, показують дати початку й завершення операцій і їхньої очікувані тривалості. Стрічкові діаграми порівняно легко читаються й часто використовуються для подання інформації вищому керівництву організацій. Для контролю й обміну управлінською інформацією використовуються й відображаються в стрічкових діаграмах укрупнені сумарні операції, іноді називані агрегованими операціями або гамаками, що тривають між контрольними подіями або поєднують кілька взаємозалежних пакетів.

• Сітьові діаграми проекту. ЦІ діаграми, що містять інформацію про дати операцій, звичайно показують як логіку сіті проекту, так і операції критичного шляху проекту.

Розробка розкладу: виходи

2. Базовий розклад являє собою особливу версію розкладу проекту, розроблену за допомогою аналізу сіті.

Він приймається й затверджується командою управління проектом як базовий розклад з базовими датами старту й фінішу.

Базовий розклад є елементом плану управління проектом.

Розробка розкладу: виходи

3. Дані розкладу проекту містять у собі, щонайменше, контрольні події розкладу, заплановані операції, параметри операцій і документацію по всіх виявлених допущеннях і обмеженням. Ступінь деталізації додаткової документації розрізняється залежно від прикладної області. Додаткові документи можуть, зокрема, містити в собі таку інформацію:

• потреби в ресурсах на даний період часу, часто у формі гістограм ресурсів;

• альтернативні розклади, такі як оптимістичні й песимістичні, з вирівнюванням і

• без вирівнювання ресурсів, з необхідними датами й без них;

• резерви на можливі втрати.

Дані розкладу можуть включати такі елементи, як гістограми ресурсів, проекції грошових потоків і розкладу замовлень і поставок.

Розробка розкладу: виходи

4. Оновлені версії документів проекту

Документи проекту, які можуть бути оновлені, містять у собі, серед іншого:

• Вимоги до ресурсів операцій. Вирівнювання ресурсів може вплинути на попереднє оцінювання типів і кількості необхідних ресурсів. Якщо аналіз вирівнювання ресурсів змінює вимоги до ресурсів проекту, то вимоги оновлюються.

• Параметри операцій оновлюються для включення переглянутих ресурсних вимог і будь-яких інших переглядів, викликаних процесом розробки розкладу.

• Календар кожного проекту може використовувати різні календарні одиниці як основу для складання розкладу проекту.

• Реєстр ризиків може мати потребу в оновленні для відбиття можливостей або загроз, усвідомлених у результаті допущень, прийнятих для складання розкладу.

6. Управління розкладом

Управління розкладом являє собою процес моніторингу статусу проекту для оцінювання його виконання й управління змінами базового розкладу.

Управління розкладом пов'язане з:

• визначенням поточного стану розкладу проекту;

• впливом на фактори, що викликають зміни розкладу;

• визначенням фактів зміни розкладу проекту;

• управлінням фактичними змінами в міру їхнього виникнення.

Управління розкладом є елементом процесу здійснення загального управління змінами.

Управління розкладом: входи, інструменти, методи й виходи

Управління розкладом: входи

1. План управління проектом (див. тему. Управління інтеграцією), містить план управління розкладом і базовий розклад. План управління розкладом описує порядок управління розкладом і його контролем. Базовий розклад використовується для порівняння з фактичними результатами, щоб визначити, потрібні чи зміни, що коректують або попереджають дії.

2. Розклад проекту. Найновіша версія розкладу проекту з коментарями про зміни, завершені й розпочаті операції на конкретну статусну дату.

3. Інформація про виконання робіт проекту, наприклад дані про те, які операції почалися, про їхнє виконання й про те, які операції закінчилися.

4. Активи процесів організації, які впливають на процес управління розкладом, містять у собі, серед іншого:

• існуючі формальні й неформальні правила, процедури й провідні вказівки, пов'язані з управлінням розкладом;

• інструменти управління розкладом;

• використовувані методи моніторингу й звітності.

Управління розкладом: інструменти і методи

1. Аналіз виконання При проведенні аналізу виконання вимірюється, порівнюється й аналізується виконання розкладу, наприклад фактичні дати старту й фінішу, відсоток завершення й тривалість, виконуваних робіт, що залишилася.

Якщо застосовується управління освоєним обсягом, то для оцінювання величини відхилень від розкладу використовується відхилення по строках (ВСР) (див. тему Управління вартістю) і індекс виконання строків (ІВСР).

Важливою частиною управління розкладом є ухвалення рішення про те, чи вимагають відхилення від розкладу проведення коригувальних впливів.

Якщо застосовується метод критичного ланцюга, порівняння обсягу буфера, що залишився, з обсягом буфера, необхідного для забезпечення дотримання строку завершення, може виявитися корисним при визначенні статусу розкладу. Порівнюючи необхідний і наявний буфер, можна визначити, чи доречним є коригування.

Управління розкладом: інструменти і методи

2. Аналіз відхилень. Вимірювання виконання строків (ВСР, ІВСР) використовуються для оцінювання величини відхилення від початкового базового розкладу.

Відхилення повного часового резерву також є важливим елементом планування, що дозволяє оцінити виконання строків проекту. Важливі аспекти управління розкладом проекту містять у собі визначення причини й ступеня відхилення щодо базового розкладу і прийняття рішень про необхідність коригувальних або попереджуючих дій.

Управління розкладом: інструменти і методи

3. Програми управління проектами, що дозволяють складати розклади, надають можливість порівнювати планові дати з фактичними й прогнозувати вплив змін на розклад проекту.

4. Вирівнювання ресурсів, описане раніше, використовується для оптимізації розподілу робіт серед ресурсів.

5. Аналіз сценаріїв «що буде, якщо» використовується для розгляду різноманітних сценаріїв з метою приведення розкладу у відповідність із планом.

Управління розкладом: інструменти і методи

6. Адаптація випереджень і затримок використовується для пошуку способів приведення відстаючих операцій проекту у відповідність із планом.

7. Стиснення розкладу. Методи стиснення розкладу використовуються для пошуку способів приведення відстаючих операцій проекту у відповідність із планом.

8. Інструмент складання розкладу. Дані розкладу коригуються й накопичуються в розкладі для відбиття фактичного виконання проекту й робіт, що залишилися, які необхідно виконати.

Інструмент складання розкладу й допоміжних даних розкладів використовуються разом з неавтоматичними методами або іншими програмами управління проектами для аналізу сіті й створення скоригованого розкладу проекту.

Управління розкладом: виходи

1. Результати вимірювань виконання робіт

Розраховані значення ОСР і ІВСР для елементів ІСР, зокрема для пакетів робіт і контрольних рахунків, документуються й передаються зацікавленим сторонам проекту.

2. Оновлені активи процесів організації

Активи процесів організації, які можуть бути оновлені, містять у собі, серед іншого:

• причини відхилень;

• обрані коригувальні впливи й причини, через які вони обрані;

• інші види знань, накопичених у ході управління розкладом проекту.

Управління розкладом: виходи

3. Запити на зміну. Аналіз відхилень по строках, а також аналіз звітів про виконання, результати вимірювань виконання й модифікації розкладу проекту можуть приводити до складання запитів на зміни базового розкладу й/або інших елементів плану управління проектом.

Запити на зміну обробляються для аналізу й подання в рамках процесу здійснення загального управління змінами.

Попереджувальні дії можуть містити у собі рекомендовані зміни для зменшення ймовірності негативних відхилень по строках.

Управління розкладом: виходи

4. Оновлений план управління проектом. Елементи плану управління проектом, які можуть бути оновлені, містять у собі, серед іншого:

• Базовий розклад. Зміни базового розкладу проводяться у відповідь на схвалені запити на зміну, пов'язані зі змінами змісту проекту, ресурсами операцій або оцінками тривалості операцій.

• План управління розкладом може оновлюватися для відбиття змін у способі управління розкладом.

• Базовий план за вартістю. Базовий план за вартістю може оновлюватися для відбиття змін, викликаних методами стиснення.

Управління розкладом: виходи

5. Оновлені версії документів проекту

Документи проекту, які можуть бути оновлені, містять у собі, серед іншого:

• Дані розкладу. Нові сітьові діаграми проекту можуть будуватися для відображення затвердженої тривалості, що залишилися і модифікації плану робіт. У деяких випадках затримки розкладу проекту можуть бути настільки серйозними, що може знадобитися розробка нового директивного розкладу із прогнозними датами старту й фінішу для надання реалістичних даних, використовуваних в управлінні роботами й вимірюванні виконання.

• Розклад проекту. Оновлений розклад проекту може бути створений на базі оновлених даних розкладу для відбиття змін розкладу й управління проектом.

7. Методичні засади визначення трудомісткості проекту інформатизації

Методичні засади визначення трудомісткості проекту

Створення норм і нормативів витрат праці при програмуванні дуже складний процес, насамперед через те, що програмування - творча праця, а також тому, що в програмуванні однієї задачі можуть брати участь фахівці різних професій і категорій: наукові працівники; математики; інженери - технологи; економісти; техніки; оператори.

Методичні засади визначення трудомісткості проекту

Крім того продуктивність праці при програмуванні залежить від багатьох чинників, врахувати які важко:

• логічна складність розв'язуваної задачі;

• кваліфікація програміста;

• мова програмування;

• математичне забезпечення ЕОМ;

• система команд і адресність ЕОМ та інші.

Методичні засади визначення трудомісткості проекту

У практиці організації праці при програмуванні не використовують такий показник як норма виробітку, а встановлюють тривалість на виконання певного завдання і його трудомісткість.

Методичні засади визначення трудомісткості проекту

Основним чинником, що впливає на час і трудомісткість, є складність системи, що розробляється.

У залежності від способу оцінювання впливу цього чинника в розрахункових моделях, їх умовно розділяють на дві групи:

• методи, засновані на оцінюванні загального числа операторів (рядків, команд) в початкових текстах програм, наприклад, модель СОСОМО - Constructive Cost Model;

• методи, засновані на інших характеристиках складності, наприклад, метод функціональних балів - Function Point Analysis (FPA).

7.1. Модель СОСОМО (Constructive Cost Model)

Модель СОСОМО

Метод СОСОМО – це ієрархія моделей у порядку зростання деталізації та точності

Основне розрахункове співвідношення моделі, запропонованої Боемом, для трудовитрат (в людино- місяцях):

Е=aі S^bi m(X),

де Е – трудомісткість;

а, b – константи;

S - оцінка складності розроблюваної ІС, виражена в тисячах рядків початкового програмного коду;

m(Х) - нелінійна функція вектора інших параметрів проекту X.

Модель СОСОМО

Е=aі S^bi m(X)

Значення параметрів a_і та b_i, оцінені за статистичними даними, в залежності від класу ІС:

Вектор Х містить 15 параметрів, а функція m(Х) є добутком 15 коефіцієнтів трудомісткості відповідних кожному з параметрів.

Передбачається, що в деяких усереднених умовах кожний коефіцієнт дорівнює одиниці.

Вплив відповідних факторів на трудовитрати враховують шляхом підбору значень цих коефіцієнтів.

Модель СОСОМО

Фактори вибрані таким чином, що їх взаємним впливом можна знехтувати.

Виділяють чотири групи факторів, що характеризують:

1. властивості ІС (вимоги до надійності, складність бази даних, загальна складність системи);

2. властивості обчислювальної системи (наявність обмежень на час рішення задач і на об’єм пам’яті, а також необхідність забезпечення переносу програм на різні типи ЕОМ);

3. колектив розробників (наявність кваліфікованих проектувальників, досвід роботи в заданій предметній сфері, наявність програмістів, досвід роботи з системою програмування і апаратурою);

4. технологію (використання передових методів розробки програм, застосування CASE-засобів, якість планування робіт).

На основі накопичених статистичних даних для кожної з цих груп розраховані діапазони значень відповідних коефіцієнтів і розроблена методика їх визначення в умовах конкретних проектів.

Модель СОСОМО

Крім прогнозування трудовитрат, метод СОСОМО дозволяє оцінювати тривалість розробки ІС.

Її розраховують за такою формулою:

Т=2,5E^Сi,

де Т - тривалість в місяцях.

Значення параметра С_i для проектів :

простих = 0.38,

середніх = 0.35,

складних = 0.32.

Модель СОСОМО

Основний недолік моделі СОСОМО - для оцінювання витрат і тривалості розробки необхідно мати оцінку складності ІС, виражену через число команд або операторів програми.

• точне число операторів програми стає відомим лише у кінці розробки, а розрахунки треба виконувати після складання технічного завдання;

• написання програм є лише невеликою частиною всіх трудовитрат, і тому число операторів не характеризує їх повністю;

• у разі використання кількох різних мов програмування складно підрахувати число операторів, особливо для непроцедурних мов;

• далеко не завжди зрозуміло, як здійснювати підрахунок (наприклад, чи треба враховувати коментарі і оголошення змінних тощо);

• не всі програми, що розробляються входять в комплект постачання (наприклад, програми, що забезпечують відладку і випробування).

Висновок

Обидва методи недосконалі.

Оцінка трудомісткості із застосуванням числа операторів (СОСОМО) у найгіршому випадку дала відносну помилку 800%,

а за методом FPA - " лише" 200%.

7.2. Метод функціональних балів (FPA- Function Point Analysis )

Метод функціональних балів (FPA)

Метод FPA призначений для більш вузького класу систем, ніж метод СОСОМО.

FPA орієнтований на системи, що містять у своєму складі досить складні бази даних.

До параметрів, значення яких характеризують складність системи віднесено кількість:

• класів інформаційних об'єктів,

• атрибутів інформаційних об'єктів,

• функціональних задач (інформаційних і обробки),

• вхідних і вихідних змінних кожної задачі.

Метод функціональних балів (FPA)

Параметри розроблюваної ІС, що використовують у якості вхідних даних для оцінювання її складності:

• кількість форм вхідних повідомлень - Inp,

• кількість форм вихідних повідомлень - Out,

• кількість інформаційних задач - Inq,

• кількість головних файлів - Maf,

• кількість інтерфейсів - Inf.

Метод функціональних балів (FPA)

Складність системи оцінюють у функціональних балах за такою формулою:

FP =UFP  TСF,

де UFP - логічна складність, виражена в балах,

TСF - поправочний коефіцієнт, що враховує інші фактори, від яких залежить складність системи.

Метод функціональних балів (FPA)

Логічну складність розраховують за такою формулою:

UFP = а  Inp + b  Out + с  Inq + d  Mat + е  Inf,

де Inp - кількість форм вхідних повідомлень,

Out - кількість форм вихідних повідомлень,

Inq - кількість інформаційних задач -,

Maf кількість головних файлів,

Inf - кількість інтерфейсів.

Значення кожного з коефіцієнтів, a, b, с, d, е, встановлюють у залежності від складності відповідного елемента ІС

Метод функціональних балів (FPA)

Метод функціональних балів (FPA)

Другий співмножник TСF розраховують по формулі:

TCF =0.65 +0.01 • DI,

де коефіцієнт DI (Degree of Influence) - це сума таких 14 зведених показників:

1. наявність і складність телекомунікації,

2. розподілена обробка,

3. особливі вимоги до якості,

4. ступінь використання ресурсів обладнання,

5. частота трансакції,

6. діалоговий режим введення даних,

7. особливі вимоги до ефективності роботи кінцевих користувачів,

8. діалоговий режим оновлення даних,

9. наявність складних алгоритмів обробки,

10. можливість повторного використання компонентів системи,

11. простота розгортання системи,

12. зручність експлуатації,

13. переносність на інші платформи,

14. простота супроводу.

Кожному з показників проектувальник присвоює оцінку з діапазону від 0 до 5.

Отже параметр D1 може приймати значення від 0 до 70,

а коефіцієнт TCF - відповідно від 0.65 до 1.35.

Метод функціональних балів (FPA)

Метод FPA досить широко використовується по обидві сторони Атлантики.

Існує Асоціація користувачів методу (FPA Users Group), яка регулярно проводить робочі зустрічі й конференції, які сприяють обміну інформацією між фахівцями і вдосконаленню методу.

Висновок

Отже, вже виявлено склад основних факторів, що визначають тривалість, трудомісткість і вартість розробки ІС, а також вивчено характер їх впливу.

Як правило, залежності економічних показників від цих факторів порівняно прості, і для їх повного опису досить вказати значення невеликого числа параметрів (найчастіше - одного, рідше - до трьох-чотирьох).

Головна складність полягає в тому, щоб оцінити ці параметри, тобто зробити калібрування моделі.

Висновок (закінчення)

Як показує практика останніх років, найточніші результати прогнозування дає калібрування, що виконується всередині організації-розробника з урахуванням її особливостей і, зокрема, характеру проектів ІС, на розробці яких вона спеціалізується.

Однак для проведення такого калібрування необхідно, щоб організація мала досить високу технологічну культуру і мала достатній обсяг накопичених статистичних даних. Якщо ці умови не додержані, то доводиться задовольнятися результатами калібрування моделі, виконаними для інших організацій, що може різко знизити точність прогнозування.

Дякую за увагу!

Управління якістю проекту

1. Сутність управління якістю

2. Планування якості

3. Забезпечення якості

4. Контроль якості

1. Сутність управління якістю

Управління якістю проекту передбачає процеси, необхідні для забезпечення того, щоб проект задовольняв ті потреби, задля яких він і розроблений.

Управління якістю проекту містить у собі процеси й дії виконуючої організації, політику в галузі якості, цілі й сфери відповідальності в галузі якості таким чином, щоб проект задовольняв тим потребам, заради яких він був розпочатий.

Управління якістю здійснюється за допомогою системи управління якістю, яка передбачає певні правила й процедури, а також дії по постійному вдосконалюванню процесів, що проводяться, за необхідності, протягом усього проекту.

Основні процеси управління якістю

• Планування якості - процес визначення вимог і/або стандартів якості для проекту й продукту, а також документування того, у який спосіб проект буде демонструвати відповідність установленим вимогам і стандартам.

• Забезпечення якості - процес перевірки дотримання вимог до якості й результатів вимірювань у процесі контролю якості для забезпечення застосування відповідних стандартів якості й застережених вимог.

• Контроль якості - процес контролю й запису результатів виконання дій по забезпеченню якості для оцінювання виконання й розробки рекомендацій щодо необхідних змін.

Зв'язки між процесами

Процеси взаємодіють як між собою, так і з процесами інших галузей застосування знань з проектного менеджменту.

Кожний процес може включати зусилля одного чи кількох індивідуумів або груп індивідуумів, спрямовані на задоволення потреб проекту, і виконується, як правило, по одному разу на кожній фазі проекту.

Хоча процеси представлені як дискретні елементи з чітко визначеними зв'язками, на практиці вони можуть перекриватися і взаємодіяти між собою в різний спосіб

Основний підхід до управління якістю

відповідність стандартам Міжнародної організації з питань стандартизації (ISO), що детально описані в серіях стандартів ISO 9000 та ISO 1000Х.

Цей загальний підхід також повинен поєднуватися з:

(а) відомими підходами до управління якістю, рекомендованими Демінгом, Джуреном, Кросбі та іншими,

(b) новими, такими як всеосяжне управління якістю (TQM), безперервне поліпшення і т. ін.

Управління якістю проекту має адресуватися до:

а) управління проектом,

б) управління продуктом проекту.

Недотримання вимог якості в будь-якій з цих сфер може мати серйозні негативні наслідки для зацікавлених осіб проекту.

Наприклад, задоволення вимог споживача шляхом збільшення роботи команди проекту може призвести до негативних наслідків через втому членів команди.

Задоволення цілей календарного плану проекту шляхом скорочення планових інспекцій якості може призвести до негативних наслідків через не виявлення браку.

Якість - це «сукупність властивостей об'єкта, які стосуються його здатності задовольняти проголошені та неочікувані вимоги»

Найважливішим аспектом управління якістю проекту є необхідність перетворення на стадії управління проекту неочікуваних вимог на проголошені

Слід розмежовувати поняття «якість» і «сорт»

Сорт - це «категорія, або ранг, що призначається об'єктам, які мають одне й те саме функціональне використання, але різні вимоги до якості»

Низька якість завжди є проблемою, а низький сорт може і не бути нею.

Наприклад, продукт - програмне забезпечення може бути високої якості (немає явних похибок, ретельно підготовлене керівництво для користувача) і низького сорту (обмежена кількість властивостей) або воно може бути низької якості (багато похибок, погано впорядкована призначена для користувача документація) і високого сорту (велика кількість властивостей).

Визначення і забезпечення необхідних рівнів якості та сорту є обов'язком менеджера проекту і команди управління проектом.

Команда менеджерів проекту повинна також розуміти, що сучасне управління якістю має відповідати сучасному управлінню проектом, і пам'ятати про можливість:

• задоволення споживача - розуміння потреб, управління ними і вплив на них у такий спосіб, щоб очікування споживача були повністю задоволені або навіть перевершені. Це вимагає поєднання відповідності специфікаціям (у проект необхідно ввести те, що інформуватиме про майбутні створення) і зручності використання продукту (продукт або послуга має задовольняти реальні потреби);

• запобігання зайвій інспекції - витрати на запобігання похибкам завжди менші, ніж витрати на їх виправлення;

• відповідальності служб менеджменту - успішне виконання проекту вимагає участі всіх членів команди, але відповідальність за виконання несе служба менеджменту, яка надає для успіху необхідні ресурси;

• процесів всередині фаз - цикл (що повторюється) планувати-робити-перевіряти-реалізовувати, описаний Демінгом та іншими.

Крім того, ініціативи організації, що виконує проект, з удосконалення якості (наприклад, TQM, безперервне удосконалення тощо) можуть поліпшити якість управління проектом і якість продукту проекту.

Слід пам'ятати, що прецизійність і точність - не одне й те саме.

Прецизійність - це коли значення періодично повторюваних вимірювань при порівнянні мають невеликі розбіжності.

Точність - це коли обмірюване значення найбільше близько відповідає правдивому значенню.

Прецизійні виміри зовсім не обов'язково є точними.

А дуже точний вимір може мати невисоку прецизійність.

Команда управління проектом повинна визначити відповідні рівні точності й прецизійності вимірів.

Важлива ознака, яку має чітко усвідомлювати команда менеджерів проекту

тимчасовість природи проекту, а це означає, що інвестиції на поліпшення якості продукту, особливо на запобігання дефектам і зайвій оцінці, мають бути відшкодовані виконавчою організацією, оскільки проект може не дожити до «збирання своїх плодів».

Модель управління якістю, описана в РМВОК4, в основі своїй відповідає вимогам Міжнародної організації по стандартизації (International Organization for Standardization, ISO).

Ця модель ураховує також авторські моделі управління якістю, розроблені Демингом (Deming), Юраном (Juran), Кросби (Crosby) і ін., і загальні моделі, такі як тотальне управління якістю (TQM), Шість сигм (Six Sigma), аналіз характеру й наслідків відмов, контрольні оцінки на етапі проектування, думку замовника, вартість якості (COQ) і постійне вдосконалювання.

Сучасне управління якістю є доповненням до управління проектом.

Обидві дисципліни визнають важливість таких положень:

- Задоволеність потреб замовника.

- Запобігання є важливішим за перевірки.

- Постійне вдосконалювання.

- Відповідальність керівництва.

- Задоволеність потреб замовника. Розуміння, оцінювання, визначення й управління очікуваннями замовника здійснювати таким чином, щоб його вимоги виявилися виконаними.

- Запобігання є важливішим за перевірки. Один із фундаментальних принципів сучасного управління якістю говорить, що якість повинна забезпечуватися за рахунок планування, розробки й виробництва, а не за рахунок проведення інспекцій. Витрати на попереджувальні дії по запобіганню помилок, як правило, значно нижчі, ніж вартість їхнього виправлення після виявлення в результаті перевірок.

• Постійне вдосконалювання. Цикл " виконання-перевірка-дія" (модель, описана Шухартом і вдосконалена Демингом) є основою для підвищення якості. Крім того, ініціативи по підвищенню якості, що вживаються виконуючою організацією, такі як тотальне управління якістю або Шість сигм, повинні поліпшувати якість управління проектом, а також якість продукту проекту.

Серед моделей удосконалювання процесів можна навести Організаційну модель зрілості управління проектами (Organizational Project Management Maturity Model, OPM3) і інтегровану модель зрілості та розвитку функціональних можливостей (Capability Maturity Model Integrated, CMMI).

(Див. презентації теми CMMI)

- Відповідальність керівництва. Для досягнення успіху потрібна участь всіх членів команди проекту, але за забезпечення проекту ресурсами, необхідними для його успішного завершення, відповідальність несе керівництво. Вартість якості позначає загальну вартість всіх заходів, спрямованих на забезпечення якості, протягом життєвого циклу продукту. Рішення, прийняті по проекту, можуть впливати на вартість якості в процесі експлуатації в результаті повернень продуктів, претензій по гарантії й кампаній по відкликанню продукції. Таким чином, внаслідок тимчасового характеру проекту, організація-спонсор може ухвалити рішення щодо вкладанні коштів у підвищення якості продукту, особливо у визначення вартості й запобігання дефектів, з метою зниження зовнішньої вартості якості.

2. Планування якості

Планування якості -

процес визначення вимог і/або стандартів якості для проекту й продукту, а також документування того, у який спосіб проект буде демонструвати відповідність установленим вимогам і стандартам

Планування якості

Це один із ключових процесів поліпшення в плануванні проекту і здійснювати його необхідно регулярно, паралельно з іншими процесами планування проекту.

Наприклад, бажане управління якістю може вимагати коригування календарного плану чи вартості або бажаний продукт якості може вимагати детального аналізу ризику з певної проблеми

Один із фундаментальних принципів сучасного управління якістю -

якість планується, а не перевіряється.

Планування якості: входи, інструменти й методи, виходи

Блок-схема даних при плануванні якості

Входи планування якості

1.Базовий план по змісту є основним параметром при плануванні якості (див. тему “Управління змістом”), оскільки в ньому задокументовані головні результати проекту та цілі - необхідна інформація для визначення основних вимог зацікавленої особи.

Входи планування якості

1 План по змісту включає:

- Опис змісту. Опис змісту містить опис проекту, його основних результатів і критеріїв приймання. Опис змісту продукту часто містить подробиці щодо технічних і інших важливих питань, які можуть вплинути на планування якості. Визначення критеріїв приймання може значно збільшити або зменшити вартість якості проекту. Відповідність всім критеріям приймання має на увазі задоволення всіх вимог замовника.

- ІСР. ІСР визначає результати, пакети робіт і контрольні рахунки, використовувані для вимірювання виконання проекту.

- Словник ІСР. Словник ІСР визначає технічну інформацію для елементів ІСР.

Входи планування якості

2. Реєстр зацікавлених сторін проекту визначає зацікавлених сторін проекту, що мають певні інтереси відносно якості або впливають на нього.

3. Базовий план виконання вартості документує прийняті часові фази, використовувані для вимірювання виконання вартості (див. тему Управління вартістю проекту).

4. Базовий розклад документує прийняті метрики виконання строків, включаючи дати старту й фінішу (див. тему Управління строками проекту).

5. Реєстр ризиків містить інформацію про погрози й можливості, які можуть впливати на вимоги до якості (див. тему Управління ризиками проекту).

Входи планування якості

6. Фактори середовища підприємства, які впливають на процес планування якості, містять у собі, серед іншого:

- нормативні акти урядових органів;

- правила, стандарти й провідні вказівки, специфічні для прикладної області; і

- умови роботи/експлуатації проекту/продукту, які можуть вплинути на якість проекту.

Входи планування якості

7. Активи процесів організації, які впливають на процес планування якості, містять у собі, серед іншого:

- правила, процедури й провідні вказівки організації в галузі якості;

- бази історичних даних;

- знання, накопичені в попередніх проектах; і

• політику в галузі якості, схвалену вищим керівництвом, що встановлює стратегію виконуючої організації відносно якості.

Планування якості: інструменти й методи

1. Порівняльний аналіз витрат і вигід Основна вигода від виконання вимог до якості може полягати в зменшенні числа доробок, збільшенні продуктивності, зменшенні витрат і росту задоволеності зацікавлених сторін проекту. В економічному обґрунтуванні кожної дії в галузі якості порівнюється вартість відповідного заходу відносно якості з очікуваною від нього вигодою.

Планування якості: інструменти й методи

2. Вартість якості - це сукупна вартість всіх заходів протягом життєвого циклу продукту, спрямованих на підвищення якості, забезпечення відповідності певним вимогам, а також попередження факторів, здатних викликати зниження якості і його невідповідність вимогам (доробка). Витрати внаслідок дефектів часто розділяються на внутрішні (виявлені в рамках проекту) і зовнішні (виявленим замовником). Витрати внаслідок дефектів також називаються «вартістю низької якості».

На наступному слайді представлено приклад.

Вартість якості

Планування якості: інструменти й методи

3. Контрольні карти використовуються для визначення того, чи є процес стабільним чи ні, і чи характеризується він передбачуваним виконанням.

Нижні й верхні межі, задані специфікацією, засновані на вимогах контракту. Вони відображають максимальні й мінімальні допустимі значення. Можуть накладати штрафи, пов'язані з перевищенням меж, заданих специфікацією.

Нижні й верхні контрольні межі встановлюються менеджером проекту й відповідних зацікавлених сторін проекту для відбиття точок, у яких будуть робити коригувальні впливи з метою запобігання перевищення границь, заданих специфікацією.

Процес уважається таким, що вийшов з-під контролю в тому випадку, якщо точка даних перебуває за контрольними межами або якщо сім послідовних точок знаходяться вище або нижче середньої лінії.

Зразок контрольної карти

Планування якості: інструменти й методи

Контрольні карти можуть бути використані для контролю різних типів вихідних змінних. Хоча найчастіше контрольні карти використовуються для відстеження повторюваних операцій, необхідних для виробництва промислових виробів, вони також можуть використовуватися для контролю відхилень за вартістю й розкладом, обсягу й частоти змін змісту або інших управлінських результатів, що допомагає визначити, чи перебувають процеси управління проектом під контролем.

.

Планування якості: інструменти й методи

4 Бенчмаркинг

Бенчмаркинг передбачає зіставлення поточного або планованого проекту з іншими порівнянними проектами з метою виявлення кращих практик, вироблення ідей для вдосконалювання й визначення критеріїв оцінювання виконання. Інші порівнянні проекти можуть бути як усередині виконуючої організації, так і за її межами, а також можуть належати до аналогічної прикладної області або до якоїсь іншої.

Планування якості: інструменти й методи

5. Планування експериментів (ПЕ) - це статистичний метод, що дозволяє визначити фактори, здатні впливати на конкретні параметри продукту або процесу в ході розробки або виробництва. ПЕ повинне використовуватися під час процесу планування якості для визначення кількості й типів випробувань і їхнього впливу на вартість якості.

Планування якості: інструменти й методи

ПЕ також відіграє певну роль в оптимізації продуктів або процесів. ПЕ може бути використане для зниження залежності характеристик продукту від джерел відхилень, викликаних розходженнями в навколишньому середовищі або виробництві.

Одним із важливих аспектів даного методу є статистична система, призначена для аналізу систематичних змін усіх важливих факторів, на відміну від системи, при якій відбувається зміна одного фактору в одиницю часу.

Аналіз експериментальних даних повинен сприяти розробці оптимальних умов для продукту або процесу, виявленню факторів, що впливають на результати, і виявленню взаємодій і синергії між факторами. Наприклад, конструктори автомобілів використовують даний метод для визначення того, яке сполучення підвіски й шин дасть найкращі ходові якості при розумних витратах.

Планування якості: інструменти й методи

6. Вибіркові оцінки Вибіркова оцінка передбачає вибір частини сукупності, що цікавить, для перевірки (наприклад, довільний вибір десяти інженерних креслень із сімдесяти п'яти). Частота й розміри вибірок повинні визначатися в ході процесу планування якості, щоб у вартості якості враховувалися ряд випробувань, очікувані відходи й т.д.

Існує великий звід знань за вибірковими оцінками. У деяких прикладних областях команді управління проектом буває необхідно ознайомитися з різноманітними методами вибіркових оцінок для забезпечення того, щоб вибірка дійсно представляла сукупність, що цікавить.

Планування якості: інструменти й методи

7. Розробка блок-схем

Блок-схема - це графічне подання процесу, що відображає взаємозв'язок між етапами процесу. Існує безліч стилів їхнього оформлення, але всі блок-схеми процесів відображають операції, точки прийняття рішень і порядок виконання. Під час планування якості блок-схеми можуть допомогти команді проекту передбачити проблеми в галузі якості, які можуть виникнути. Поінформованість про можливі проблеми може сприяти розробці тестових процедур або підходів до їхнього розв'язання.

Планування якості: інструменти й методи

8. Авторські методики управління якістю містять у собі такі методики:

• шість сигм (Six Sigma),

• ощадливе виробництво (Lean),

• розгортання функцій якості,

• CMMI і т.д.

Планування якості: інструменти й методи

9. Додаткові інструменти планування якості Інші інструменти планування якості часто використовуються для кращого визначення вимог до якості й планування дій по ефективному управлінню якістю. Вони містять у собі, серед іншого:

- Мозковий штурм.

- Діаграми подібності, використовувані для візуального визначення логічних угруповань, заснованих на природних взаємозв'язках.

- Аналіз силових полів, що представляє собою діаграми сил, що виступають за й проти зміни.

- Методи номінальних груп дозволяють проводити мозковий штурм ідей у невеликих групах, а потім перевіряти їх у групі більшого розміру.

- Матричні діаграми містять дві, три або чотири групи інформації й показують взаємозв'язки між факторами, причинами й цілями. Дані в матриці організовані в рядки й стовпці з пересічними осередками, які можуть бути заповнені інформацією, що описує демонстрований взаємозв'язок між елементами, розташованими в рядку й колонці.

- Матриці розміщення пріоритетів, що дозволяють ранжирувати набір різноманітних проблем і/або питань (звичайно генерованих за допомогою мозкового штурму) за рівнем їхньої важливості.

Планування якості: виходи

1. План управління якістю описує, у який спосіб команда управління проектом буде перетворювати політику виконуючої організації в галузі якості. План управління якістю є частиною або допоміжним планом у складі плану управління проектом (див. тему Управління інтеграцією проекту).

План управління якістю забезпечує вхідну інформацію для загального плану управління проектом і включає підходи до контролю якості, забезпечення якості й постійного вдосконалювання процесів проекту.

План управління якістю може бути формальним або неформальним, дуже докладним або узагальненим. Стиль і деталі визначаються вимогами проекту. Крім того, план управління якістю повинен перевірятися на ранній стадії проекту для забезпечення того, щоб прийняті рішення були засновані на точній інформації. До переваг подібної перевірки можна віднести скорочення перевищень вартості й строків, викликаних доробками.

Планування якості: виходи

2. Метрики якості описують у конкретних термінах як параметри проекту або продукту, так і способи вимірювання цих параметрів. Результат вимірювання - це фактична величина. Допуск визначає припустимі відхилення метрики. Наприклад, метрика, пов'язана з ціллю в галузі якості, - залишитися в рамках схваленого бюджету ± 10 % - може включати вимірювання вартості кожного результату й визначення відхилення цього результату у відсотках від схваленого бюджету. Метрики якості використовуються в процесах забезпечення якості й управління якістю. Деякими прикладами метрик якості є продуктивність на момент часу, показники бюджету, частота дефектів, частка відмов, доступність, надійність і регулярність проведення випробувань.

Планування якості: виходи

3. Контрольні списки якості

Контрольний список являє собою структурований документ, що звичайно ставиться до конкретного елемента, що використовується для підтвердження виконання всіх намічених дій. Контрольні списки можуть бути простими або складними залежно від вимог і порядку виконання проекту. У багатьох організаціях є стандартизовані контрольні списки, що забезпечують погодженість часто виконуваних завдань. У деяких прикладних областях контрольні списки можна також одержати від професійних асоціацій або комерційних організацій. Контрольні списки якості використовуються в процесі управління якістю.

Планування якості: виходи

4. План удосконалювання процесів являє собою допоміжний план, що входить до складу плану управління проектом (див. тему Управління інтеграцією проекту). План удосконалювання процесів описує порядок проведення аналізу процесів з метою визначення дій, що підвищують цінність цих процесів. Розглянуті галузі містять у собі:

- Межі процесів. Описують цілі процесів, їхній початок і кінець, їхні входи/виходи, необхідні дані, власника й зацікавлені сторони проекту.

- Конфігурація процесів. Графічне зображення процесів із зазначенням їхніх взаємодій, використовувана для полегшення аналізу.

- Система показників процесів. Поряд з контрольними межами дозволяє аналізувати ефективність процесів.

- Об'єкти для вдосконалювання. Указують напрямку вдосконалювання процесів.

Планування якості: виходи

5. Оновлення документів проекту

Документи проекту, які можуть бути оновлені, містять у собі, серед іншого:

- Реєстр зацікавлених сторін проекту; і

- матрицю відповідальності (див. теми: Структуризація проекту і Управління людськими ресурсами).

3. Забезпечення якості

Забезпечення якості являє собою процес перевірки дотримання вимог до якості й результатів вимірювань у процесі контролю якості для забезпечення використання відповідних стандартів якості й метрик якості.

Забезпечення якості – це один із процесів виконання, у якому використовуються дані, отримані під час контролю якості (див. наступне питання)

Спостереження за процесом забезпечення якості часто доручається відділу по забезпеченню якості або спеціальній організації.

Незалежно від того, як називається структура, що забезпечує якість, підтримку процесу забезпечення якості можуть надавати команда проекту, керівний склад виконуючої організації, замовник або спонсор, а також інші зацікавлені сторони проекту, не беручи активної участі в роботах із проекту.

Забезпечення якості також становить основу для постійного вдосконалювання процесів, а саме ітеративних заходів щодо поліпшення якості всіх процесів. Постійне вдосконалювання процесів скорочує витрати ресурсів і виключає марні операції, які не додають цінності, що підвищує рівень ефективності й результативності процесів.

Забезпечення якості: входи, інструменти, методи й виходи

Блок-схема даних при забезпеченні якості

Забезпечення якості: входи

1. План управління проектом (див. тему Планування) містить таку інформацію, використовувану для забезпечення якості:

- План управління якістю, який описує порядок забезпечення якості в рамках проекту.

- План удосконалювання процесів, який детально описує кроки проведення аналізу процесів для визначення операцій, здатних збільшити їхню цінність.

2. Система показників якості (розглянуто в другому питанні цієї теми: виходи процесу планування якості).

Забезпечення якості: входи

3. Інформація про виконання робіт У міру просування проекту регулярно збирається інформація про виконання його операцій. Результати виконання, які можуть сприяти аудитові процесу, містять у собі, серед іншого:

- результати вимірювання технічного виконання;

- статус результатів проекту;

- хід виконання розкладу; і

- понесені витрати.

4. Результати вимірювань у процесі контролю якості є результатами дій по контролю якості. Вони використовуються для аналізу й оцінювання стандартів і процесів виконуючої організації в галузі якості.

Забезпечення якості: інструменти й методи

1. Інструменти й методи планування якості й контролю якості, описані раніше також можуть бути застосований до дій по забезпеченню якості.

2. Аудит якості - це структурована, незалежна перевірка, що визначає, наскільки операції проекту відповідають, і чи відповідають, установленим у рамках проекту або організації правилам, процесам і процедурам. Цілями аудиту якості є:

- виявлення гарних/кращих застосовуваних практик;

- виявлення всіх вузьких місць/недоліків;

- поширення впроваджених або застосованих гарних практик серед подібних проектів організації й/або всієї галузі;

- активна пропозиція підтримки для поліпшення виконання процесів і надання допомоги команді в підвищенні продуктивності; і

- внесення досягнень кожного аудита в сховище накопичених знань організації.

Забезпечення якості: інструменти й методи

Аудит якості може виконуватися за розкладом або довільним способом спеціально навченими внутрішніми аудиторами, або сторонньою організацією.

Аудит якості може підтвердити реалізацію схвалених запитів на зміну, включаючи коригувальні впливи, виправлення дефектів і попереджуючі дії.

Забезпечення якості: інструменти й методи

3. Аналіз процесів передбачає виконання дій, описаних у плані вдосконалювання процесів і спрямованих на виявлення потреб у поліпшенні.

Аналіз процесів містить у собі аналіз першопричин - особливий метод аналізу проблем і виявлення глибинних причин, що призвели до їхнього виникнення, а також розробку попереджуючих дій для розв'язання таких проблем.

Забезпечення якості: виходи

1. Оновлення активів процесів організації Елементи активів процесів організації, які можуть бути оновлені, містять у собі, зокрема, стандарти якості.

2. Запити на зміну Удосконалювання якості містить у собі здійснення дій по підвищенню ефективності й/ або результативності правил, процесів і процедур виконуючої організації. Запити на зміну створюються й використовуються як вхід процесу здійснення загального управління змінами (див тему Управління інтеграцією),що дозволяє повністю розглянути рекомендовані поліпшення. Запити на зміни можуть використовуватися для здійснення коригувальних або попереджуючих дій або для виправлення дефектів.

Забезпечення якості: виходи

3. Оновлення плану управління проектом

Елементи плану управління проектом, які можуть бути оновлені, містять у собі, серед іншого:

- план управління якістю;

- план управління розкладом; і

- план управління вартістю.

4. Оновлення документів проекту

Документи проекту, які можуть бути оновлені, містять у собі, серед іншого:

- звіти по аудитах якості;

- плани навчання; і

- документацію процесу.

4. Контроль якості

Контроль якості являє собою процес контролю й запису результатів дій, спрямованих на забезпечення якості, для оцінки виконання й розробки рекомендацій щодо необхідних змін. Контроль якості здійснюється протягом усього проекту. Стандарти якості містять у собі процеси проекту й цілі по продуктах. До результатів проекту відносяться як результати робіт, так і управлінські результати, такі як показники виконання вартості й строків. Контроль якості часто проводиться відділом контролю якості або іншим підрозділом організації зі схожою назвою. Дії по контролю якості виявляють причини низької якості процесів або продуктів і дозволяють винести рекомендації й/або почати дії по їхньому усуненню.

Команда управління проектом повинна мати знання й навички статистичного аналізу якості, особливо методу вибіркових оцінок і теорії ймовірності, необхідних для того, щоб уміти оцінити результати контролю якості. Крім усього іншого, для команди проекту, можливо, виявиться корисним знати різницю між такими парами термінів:

- запобіганням (недопущення появи помилок у процесі) і перевіркою (недопущення потрапляння помилкових результатів до споживача).

- вибірковою перевіркою відповідності (результат або задовільний, або ні) і вибірковою перевіркою відхилень (результат оцінюється по числовій шкалі, що вимірює ступінь відповідності).

- допустимим відхиленням (результат прийнятний, якщо він перебуває в допустимих рамках) і контрольними межами (граничні значення, що показують, чи залишається процес керованим).

Контроль якості: входи, інструменти, методи й виходи

Блок-схема даних при контролі якості

Контроль якості: входи

1. План управління проектом, описаний у темі Управління інтеграцією, містить план управління якістю, використовуваний для контролю якості. План управління якістю описує порядок проведення контролю якості в рамках проекту.

2. Метрики якості описані в другому питанні цієї теми.

3. Контрольні списки якості описані в другому питанні цієї теми.

4. Результати вимірювання виконання робіт використовуються для створення метрик операцій проекту, що дозволяє оцінити фактичне виконання в порівнянні із плановим. Ці метрики містять у собі, серед іншого:

- планові технічні показники в порівнянні з фактичними;

- планове виконання строків у порівнянні з фактичним; і

- планове виконання вартості в порівнянні з фактичним.

Контроль якості: входи (закінчення)

5. Схвалені запити на зміну Будучи частиною процесу здійснення загального управління змінами, оновлення статусу управління змінами показують, що одні зміни схвалені, а інші ні. Схвалені запити на зміну можуть містити в собі такі модифікації, як виправлення дефектів, перегляд методів роботи й розклади. Повинні проводитися перевірки своєчасного впровадження схвалених змін.

6. Результати роботи Описані в темі Управління інтеграцією.

7. Активи процесів організації, які можуть впливати на процес контролю якості, містять у собі, серед іншого:

- стандарти й правила відносно якості;

- стандартні робочі інструкції; і

- процедури складання звітів про проблеми й дефекти, а також правила комунікацій.

Контроль якості: інструменти і методи

Перші сім з даних інструментів і методів відомі як «сім основних інструментів якості Ішикави».

1 Причинно-наслідкові діаграми

Причинно-наслідкові діаграми, також називані діаграмами Ішикави або діаграмами «риб'ячий кістяк», ілюструють зв'язок різних факторів з можливими проблемами й наслідками. (приклад причинно-наслідкової діаграми див. наступний слайд).

Можливу першопричину можна виявити, постійно задаючи питання «чому?» або «як?» рухаючись уздовж однієї з ліній. При аналізі першопричин можуть бути використані діаграми «чому-чому» і «як-як».

Причинно-наслідкові діаграми також використовуються при аналізі ризиків.

Приклад загальної причинно-наслідкової діаграми

Приклад причинно-наслідкової діаграми

Контроль якості: інструменти і методи

.2 Контрольні карти описані в раніше. Контрольні карти призначені для збору й аналізу відповідних даних з метою визначення статусу якості процесів і продуктів проекту.

Контрольні карти дають наочне подання про розвиток процесу в часі. Контрольні карти можуть використовуватися для відображення випадків, коли в процесі виникають різні зміни, викликані особливими причинами, здатними створити умови, що не піддаються контролю. Вони являють собою графічне відображення відхилення процесу й дають відповідь на питання: «чи перебуває відхилення даного процесу в рамках установлених меж?» Характер розташування точок даних на контрольній карті довільно коливних значень може говорити про несподівані перегони в процесі або тенденції до поступового збільшення відхилення. За допомогою моніторингу виходів процесу із часом контрольні карти можуть допомогти оцінити, чи привело впровадження змін процесу до бажаних поліпшень.

Якщо процес протікає в рамках установлених меж, він залишається під контролем і не має потреби в корективах. Вносити корективи в процес треба тоді, коли процес виходить за рамки встановлених меж. Сім послідовних точок за межами верхньої або нижньої контрольної границі вказують на процес, що вийшов з-під контролю. Верхня й нижня контрольна границя звичайно встановлюються в межах ± 3 сигми, де 1 сигма – одне середнє квадратичне відхилення.

.

Контроль якості: інструменти і методи

3. Розробка блок-схем

Блок-схеми, описані раніше, використовуються при контролі якості для визначення вузьких місць процесу й виявлення потенційних можливостей удосконалювання процесу. Блок-схеми також використовуються при аналізі ризиків.

4. Гістограми - це вертикальна стовпчикова діаграма, що відображає розподіл змінних. Кожний стовпчик представляє параметр або властивість проблеми/ситуації. Висота кожного стовпчика позначає відносну частоту властивості. Даний інструмент ілюструє найбільш часту причину виникнення проблем процесу по кількості й відносній висоті стовпчиків.

Контроль якості: інструменти і методи

5. Діаграма Парето є особливим типом гістограми, упорядкованої по частоті виникнення. Вона показує, яка кількість виявлених дефектів є наслідком причин, що належать до певного типу або категорії. Порядок ранжирування елементів у діаграмі Парето використовується для прийняття рішень про проведення коригувальних впливів. Команда проекту повинна в першу чергу ухвалювати рішення щодо тих проблемам, які є причиною найбільшої кількості дефектів.

Діаграма Парето концептуально пов'язана із законом Парето, що стверджує, що відносно мале число причин звичайно викликає більшість проблем або дефектів. Цей закон також відомий як принцип 80/20, відповідно до якого 80 % проблем викликано 20 % причин.

Контроль якості: інструменти і методи

6. Діаграми тренда відображає історію й характер змін. Діаграма тренда -це лінійний графік, що відображає точки даних, розташованих на графіку в порядку їхнього виникнення. Діаграма тренда дає уявлення про тенденції, коливання в часі, а також про позитивні й негативні зміни процесу в часі. Аналіз тенденцій проводиться за допомогою діаграм тренда й містить у собі використання математичних методів для прогнозування майбутніх результатів на основі даних минулих періодів. Аналіз тенденцій часто використовується для спостереження за такими показниками:

- Технічне виконання. Скільки помилок або дефектів виявлено, і скільки ще не виправлено?

- Виконання вартості й строків. Скільки операцій виконано зі значними відхиленнями в кожний період часу?

Контроль якості: інструменти і методи

7. Діаграма розкиду показує взаємозв'язок між двома змінними. Даний інструмент дозволяє команді контролю якості вивчити й визначити можливий взаємозв'язок між змінами, спостережуваними в обох змінних. На графіку проти залежних змінних зображуються незалежні змінні. Чим ближче одна до одної точки на діагональній лінії, тим тісніше вони пов'язані.

Контроль якості: інструменти і методи (виходи)

8. Вибіркове оцінювання Описано раніше. Порядок відбору й перевірки вибірок визначений у плані якості.

9. Інспекція - це перевірка продукту роботи для визначення його відповідності задокументованим стандартам. Як правило, результати інспекції містять результати вимірювань. Інспекція може проводитися на будь-якому рівні. Наприклад, інспекція результатів може проводитися по окремій операції або по кінцевому продукту проекту. Інспекція також може позначатися іншими термінами: «перевірка», «експертна оцінка», «аудит» або «наскрізний контроль». У деяких прикладних областях ці терміни мають більш вузьке й спеціальне значення. Інспекція також використовується для підтвердження усунення дефектів.

10. Перевірка схвалених запитів на зміну

Всі схвалені запити на зміну повинні бути перевірені для підтвердження того, що вони впроваджені саме так, як було схвалено.

Контроль якості: виходи

1. Результати вимірювань у процесі контролю якості є документованими результатами дій по контролю якості у форматі, визначеному під час планування якості.

2. Підтверджені зміни Будь-які змінені або виправлені елементи інспектуються, і їх або приймають, або відхиляють до надання повідомлення про рішення. Відхилені елементи можуть зажадати доробки.

3. Підтверджені результати Метою контролю якості є визначення правильності результатів. Результатами виконання процесів контролю якості є підтверджені результати. Підтверджені результати є входом підтвердження змісту (див тему Управління змістом) для формалізованого приймання.

Контроль якості: виходи

4. Оновлення активів процесів організації

Елементи активів процесів організації, які можуть бути оновлені, містять у собі, серед іншого:

- Заповнені контрольні списки. При використанні контрольних списків заповнені списки стають частиною документації по проекту (див. тему Управління інтеграцією).

- Документація по накопичених знаннях. Причини відхилень, обґрунтування на користь вибору того або іншого коригувального впливу й інші знання, накопичені в результаті процесу контролю якості, документуються, для того щоб стати частиною історичної бази даних як для даного проекту, так і для самої виконуючої організації. Накопичені знання оформляються у вигляді документів протягом усього життєвого циклу проекту, але обов'язково, як мінімум, у процесі завершення проекту.

Контроль якості: виходи

5. Запити на зміну

Якщо рекомендовані коригувальні або попереджуючі дії, або виправлення дефектів вимагають змін плану управління проектом, необхідно ініціювати запит на зміну (див тему Управління інтеграцією) відповідно до визначеного процесу здійснення загального управління змінами.

6. Оновлення плану управління проектом

Елементи плану управління проектом, які можуть бути оновлені, містять у собі, серед іншого:

- план управління якістю; і

- план удосконалювання процесів.

7. Оновлення документів проекту

Документи проекту, які можуть бути оновлені, містять у собі, зокрема, стандарти якості.

Тема: Моделі зрілості по управлінню проектами інформатизації (CMMI)

СММ (Capability Maturity Model) - це система оцінювання та перевірки можливостей компанії, зрілість якої відповідає одному з п'яти рівнів.

Модель СММ Capability Maturity Model була розроблена в 1991 році Інститутом програмної інженерії Університету Карнегі-Меллона (Software Engineering Institute, SEI) для розробки програмних продуктів. Із часом було випущено ціле сімейство моделей.

У 2002 році SEI опублікував нову модель CMMI (Capability Maturity Model Integration), що поєднує раніше випущені моделі й ураховує вимоги міжнародних стандартів.

В основі CMM/CMMI лежить поняття процесу.

Основні компоненти CMMI

• Рівень зрілості (Maturity level) - це чітко визначений щабель розвитку на шляху до зрілості процесів. П'ять рівнів зрілості являють собою високорівневу структуру СММ

Основні компоненти CMMI

Ключова група процесів (КРА - Key process area) - Кожний Рівень зрілості складається із Ключових груп процесів. Кожна Ключова група процесів визначає набір взаємопов’язаних процесів, спільне застосування яких забезпечує досягнення основних цілей, необхідне для підвищення стабільності процесу до певного Рівня зрілості. Ключові групи процесів були виділені таким чином, щоб вони характеризували конкретний Рівень. Наприклад, однією із КРА Рівня 2 є Планування проекту.

Основні компоненти CMMI

Група процесів (process area) — група взаємозалежних дій, виконання яких дозволяє досягти мети даної групи процесів.

Практика (practice) — опис дій, які варто почати, щоб «пустити в хід» ключові елементи даної групи процесів. Спеціальна практика - це дії, що необхідні для досягнення спеціальної мети.

Основні компоненти CMMI

Ціль (goal) являє собою заяву на вищому рівні про те, що повинно бути досягнуто при ефективному застосуванні практик. Спеціальні цілі застосовні до конкретної групи процесів.

Цілі резюмують основні дії ключової групи процесів (КРА) й можуть використовуватися для визначення ефективності впровадження організацією або проектом цієї КРА. Цілі визначають обсяг, границі й призначення кожної КРА.

Приклад цілі КРА "Планування проекту": "Оціночні значення документуються й використовуються при плануванні й моніторингу проекту".

Основні компоненти CMMI

• Загальна мета (generic goal) називається загальною тому, що одне й та саме формулювання мети з'являється в різних групах процесів. У стадійному поданні CMMI кожна група процесів має тільки одну загальну мету.

• Загальна практика (generic practice) — елемент інституалізації процесів, певним чином гарантія того, що процеси даної групи будуть ефективними, повторюваними й стабільними.

Основні компоненти CMMI

• Інституціоналізація (Institutionalization) - Повне впровадження процесу до його становлення частиною корпоративної культури організації.

• Уточнення загальних практик (Generic practice elaborations) є керівництвом із застосування загальних практик до конкретної групи процесів.

Основні компоненти CMMI

Загальні ознаки (Common Features) - Практичні дії розділені по п'яти секціях загальних ознак: Зобов'язання по виконанню, Здатність виконання, Виконувані дії, Вимірювання й аналіз і Перевірка впровадження.

Загальні ознаки відображають впровадження й інституціоналізацію ключової групи процесів КРА: ефективність, повторюваність, стабільність.

Загальна ознака "Виконувані дії" описує роботи із впровадження.

Чотири ознаки, що залишилися описують, наскільки процеси, що створені в організації, стали частиною корпоративної культури.

Основні компоненти CMMI

Базові практики (Key practices) - Кожна Ключова група процесів (КРА) описується за допомогою Базових практик, які, будучи виконаними, допомагають досягти цілей цієї КРА. Базові практики описують інфраструктуру й роботи, які багато в чому сприяють ефективному впровадженню й інституціоналізації КРА.

Наприклад, однією з базових практик КРА "Планування проекту" є: "План проекту з розробки ПЗ розробляється відповідно до документованої процедури".

Основні компоненти CMMI

• Підпрактика (subpractice) (або інакше, підлеглі базові практики) — детальний опис дій, які можуть стати керівництвом для інтерпретації спеціальних і загальних практик.

Підпрактики наводяться під текстом базових практик і описують, що очікується від організації по виконанню даної базової практики.

Підпрактики можуть використовуватися як допомога при визначенні, чи задовільно впроваджені базові практики.

Основні компоненти CMMI

• Уточнення (discipline amplification) містять інформацію про конкретну інженерну дисципліну (наприклад, програмування, системний інжиніринг) і пов'язані зі спеціальними практиками.

Основні компоненти CMMI

• Типовий робочий продукт (typical work product) — приклад того, що повинно бути отримане в результаті виконання спеціальної або загальної практики. Ці приклади названі типовими робочими продуктами, тому що можуть існувати й інші, не менш ефективні, робочі продукти.

Модель CMMI випущена у двох варіантах - безперервне подання й стадійне подання

В основі безперервного подання лежить концепція можливостей процесів у певній сфері (6 рівнів).

В основі стадійного подання лежить концепція зрілості процесів організації в цілому (5 рівнів).

Модель CMMI випущена у двох варіантах - безперервне подання й стадійне подання

Різниця між двома поданнями полягає в тому, що концепція можливостей процесів розглядає комплекс дій («практик»), пов'язаних з однією групою процесів,

у той час як концепція зрілості процесів розглядає комплекс процесів у масштабах всієї організації.

Безперервне подання CMMI

розглядає чотири категорії (групи) процесів:

• управління проектами,

• підтримка,

• інженерія,

• управління процесами.

Групи процесів по категоріях процесів безперервного подання CMMI

Групи процесів по категоріях процесів безперервного подання CMMI (продовження)

Групи процесів по категоріях процесів безперервного подання CMMI (продовження)

Групи процесів по категоріях процесів безперервного подання CMMI (закінчення)

В основі безперервного подання лежить концепція можливостей процесів у певній групі.

Організація може зосередитися на тій групі процесів, що для неї є найбільш критичною.

У цьому випадку можна говорити про рівень потенційних можливостей для обраної групи процесів.

Це означає, наприклад, що організація може досягти 5-го рівня потенційної можливості по управлінню проектами й залишатися нижче 2-го рівня потенційної можливості по управлінню процесами.

Рівні зрілості організації

Рівень 1: початковий (initial). Чітка організація процесів відсутня, процеси непередбачені, немає визначених правил і процедур розробки, успіх проектів звичайно є заслугою окремих осіб.

Рівень 2: керований (managed). Процеси визначаються й документуються, але вони сфокусовані на організації конкретного проекту, тобто не стандартизовані й можуть різнитися в різних проектах.

Рівень 3: визначений (defined). У всіх проектах процеси відповідають заданому корпоративному стандарту, так званому стандартному процесу організації.

Рівні зрілості організації

Рівень 4: керований на базі кількісних показників (quantitatively managed). Процеси стають передбачуваними й з'являється можливість управляти такими параметрами проекту, як кількість помилок, трудомісткість, обсяг переробок і т.д.

Рівень 5: оптимізований (optimizing). Процеси перебувають у стані постійного вдосконалювання, компанія може впроваджувати істотні інновації в процеси на основі аналізу кількісних показників, ідентифікувати кореневі причини проблем проектів і запобігати їхню появу.

Основні компоненти безперервного подання CMMI

Стадійне подання CMMI

У стадійному поданні CMMI кожний рівень зрілості характеризується сукупністю процесів, які в моделі позначаються як "Групи процесів" (Process Area).

В основі стадійного подання лежить концепція зрілості процесів організації в цілому

Стадійне подання CMMI

засноване на тому, що для досягнення певного рівня зрілості організація повинна впровадити всі без винятку процеси, що належать до даного й усіх попередніх рівнів зрілості.

Стадійне подання CMMI

Так, організація, що ставить за мету досягти 4-го рівня зрілості повинна освоїти всі процеси 2-го, 3-го й 4-го рівнів.

Якщо виявиться, що організація освоїла всі процеси 3-го й 4-го рівнів, але не освоїла хоча б одного процесу 2-го рівня зрілості, вона не буде визнана відповідною навіть 2-му рівню зрілості.

Основні компоненти стадійного подання CMMI

Взаємозв’язок груп процесів із рівнями зрілості

Взаємозв’язок груп процесів із рівнями зрілості

Взаємозв’язок груп процесів із рівнями зрілості

Як видно, переважна кількість процесів УП належать до 2-го й 3-го рівнів зрілості

Рівень 1. Початковий ("Анархія“)

Симптоми:

- співробітники самі визначають, що добре, а що погано;

- витрати і якість не прогнозуються;

- відсутні формалізовані плани;

- відсутній контроль змін;

- вище керівництво погано уявляє реальний стан справ

Рівень 2. Керований ("Фольклор“)

Симптоми:

- виявлена певна повторюваність організаційних процесів;

- досвід організації представлений у вигляді переказів корпоративної міфології;

- знання накопичуються у вигляді особистого досвіду співробітників і пропадають при їхньому звільненні.

Рівень 3.Визначений ("Стандарти“)

Симптоми:

- корпоративна міфологія записана на папері;

- процеси повторювані й не залежать від особистих якостей виконавців;

- інформація про процеси для вимірювання ефективності не збирається;

- наявність формалізованого опису процесів не означає, що вони працюють;

- організація починає адаптувати свій досвід до специфіки бізнесу;

- проводиться аналіз знань і вмінь співробітників з метою визначення необхідного рівня компетентності;

- розробляється стратегія розвитку компетентності

Рівень 4. Кількісно керований ("Вимірюваний“)

Симптоми:

- процеси вимірювані й стандартизовані

Рівень 5. Оптимізований

Симптоми:

- фокус на повторюваності й вимірності

- вся інформація про функціонування процесів фіксується

Різниця між двома поданнями полягає в тому, що концепція можливостей процесів (безперервне подання) розглядає комплекс дій («практик»), пов'язаних з однією групою процесів, у той час як концепція зрілості процесів (стадійне подання) розглядає комплекс процесів у масштабах всієї організації.

Приклад

Модель зрілості керівника проекту

Зрілість керівника. Рівень 1.

Зрілість керівника. Рівень 2.

Зрілість керівника. Рівень 2. (закінчення)

Зрілість керівника. Рівень 3.

Зрілість керівника. Рівень 3. (закінчення)

Зрілість керівника. Рівень 4.

Зрілість керівника. Рівень 4. (закінчення)

Зрілість керівника. Рівень 5.

Зрілість керівника. Рівень 5. (закінчення)

Успіх проекту багато в чому визначається тим, як організоване його управління

CMMI включає в УП такі групи процесів:

• планування проекту;

• моніторинг і контроль процесів проекту;

• управління угодами з постачальниками;

• інтегроване управління постачальниками;

• інтегроване управління процесами й продуктами проекту;

• управління ризиками;

• інтеграція команди розробників;

• кількісне управління проектом.

До другого рівня зрілості відносяться такі групи процесів: планування проекту, контроль і моніторинг та управління постачальниками.

До третього рівня зрілості відноситься управління ризиками й інтегроване управління проектом.

До четвертого рівня - кількісне управління проектом.

Дякую за увагу!

Тема: СММІ: Планування проекту

Успіх проекту багато в чому визначається тим, як організоване його управління

CMMI включає в УП такі групи процесів:

• планування проекту;

• моніторинг і контроль процесів проекту;

• управління угодами з постачальниками;

• інтегроване управління постачальниками;

• інтегроване управління процесами й продуктами проекту;

• управління ризиками;

• інтеграція команди розробників;

• кількісне управління проектом.

До другого рівня зрілості відносяться такі групи процесів: планування проекту, контроль і моніторинг та управління постачальниками.

До третього рівня зрілості відноситься управління ризиками й інтегроване управління проектом.

До четвертого рівня - кількісне управління проектом.

Завдання групи процесів «Планування проекту» -

установити й підтримувати плани, у яких визначені всі дії, необхідні для виконання проекту

Загальна схема планування проекту

В CMMI широко використовується термін план проекту

План проекту є формальним затвердженим документом, що використовується як для управління проектом, так і для контролю ходу його виконання.

Звичайно в ході проекту відбуваються різноманітні зміни у вимогах, розподілі обов'язків, оцінках трудовитрат і розмірів, процесах.

Підтримка плану полягає в повному і своєчасному відстеженні цих змін і прийнятті необхідних коригувальних заходів.

Тому в дане поняття включаються: план управління проектом, план управління ризиками, план вимірювань, план навчання й т.д.

Для встановлення ефективного процесу планування CMMI рекомендує

• оцінити обсяг проекту;

• оцінити робочі продукти і характеристики виконуваних задач;

• визначити життєвий цикл проекту;

• оцінити трудовитрати й вартість;

• установити бюджет і графік проекту;

• визначити проектні ризики;

• спланувати управління проектними даними;

• спланувати ресурси (скласти ресурсний план),

• спланувати необхідні знання й навички (скласти план навчання);

• спланувати залучення зацікавлених осіб;

• установити план проекту;

• проаналізувати плани;

• погодити рівні робіт і ресурсів;

• установити зобов'язання учасників по виконанню плану.

1.Оцінка обсягу проекту

Оцінка обсягу проекту заснована на параметрах планування.

Під параметрами планування CMMI має на увазі всю інформацію, необхідну для складання планів, організації робіт, укомплектування персоналом, керівництва й координації робіт, звітності й бюджетування

Параметри планування:

• проектні вимоги (до продукту, вимоги, що накладаються організацією, вимоги, що накладаються клієнтом тощо);

• обсяг проекту;

• встановлені завдання й робочі продукти;

• технічний підхід;

• обрана модель життєвого циклу проекту (наприклад, водоспад, ітеративна, спіральна);

• атрибути робочих продуктів і завдань (наприклад, розмір або складність);

• графік;

• методологія (моделі, дані, алгоритми) визначення необхідних матеріалів, знань, робочого часу і вартості.

Загальна схема процесу оцінювання

Рекомендують проводити оцінку обсягу проекту на основі структури робіт (work breakdown structure, WBS), оскільки весь проект декомпозується на комплекс взаємозалежних керованих компонентів.

Доцільно розробляти структуру робіт на основі архітектури продукту.

Це дозволяє виділити логічні елементи робіт, так звані «робочі пакети», кожним із яких можна керувати автономно.

Як правило, WBS розвивається, доповнюється й уточнюється в міру виконання проекту, тому при початкових оцінках доцільно використовувати структуру робіт верхнього рівня.

«Робочі пакети» варто визначати в деталях, що дозволяють провадити оцінки проектних завдань, відповідностей учасників робіт і графіка.

Правильно складена структура робіт дозволяє встановити:

ризики й завдання по їхньому ослабленню або запобіганню,

завдання по створенню робочих продуктів, що відправляються клієнтові,

завдання по придбанню необхідних знань і навичок,

завдання по розробці підтримуючих планів, таких як управління конфігурацією, забезпечення якості, плани верифікації,

завдання по інтеграції продукту й управлінню робочими продуктами, що не поставляються клієнтові

Рекомендовані робочі продукти - результати етапу “Оцінка обсягу проекту”:

• опис задач;

• опис пакетів робочих продуктів,

• структура робіт.

2. Оцінювання робочих продуктів і характеристик виконуваних задач

Більшість моделей по оцінці трудовитрат, вартості й графіка засновані на визначенні розміру, складності й структури продукту.

Як правило, розміри визначаються для робочих продуктів (що поставляються й не поставляються клієнтові), документів і операційного й підтримуючого програмного забезпечення.

Розмір може вимірятися кількістю функцій, функціональних точок, рядків програмного коду, класів і об'єктів, вимог, інтерфейсів, сторінок, входів і виходів, обсягом даних. Кожному із цих атрибутів рекомендується присвоїти рівень труднощів або складності.

Оцінювання робочих продуктів і завдань стає більш об'єктивним, якщо базується на визначенні технічного підходу до виконання проекту

Під технічним підходом розуміється формування високорівневої стратегії розробки, яка включає рішення по таких питаннях:

• особливості архітектури і технологій, що передбачаються для застосування,

• широта функціональності кінцевих продуктів,

• безпека й надійність,

• ергономіка.

Велике значення мають методи визначення атрибутів робочих продуктів і задач, оскільки від цього буде залежати надійність оцінок.

Приклади таких методів:

• кількість логічних входів/виходів для інтегральних схем,

• кількість рядків коду або функціональних точок для програмних продуктів,

• кількість і складність вимог для системної інженерії.

Рекомендується переважно використовувати для визначення розміру й складності методи, засновані на випробуваних моделях або історичних даних.

Рекомендовані робочі продукти - результати етапу “Оцінювання робочих продуктів і характеристик виконуваних задач”:

• технічний підхід;

• розмір і складність виконуваних задач і робочих продуктів;

• оцінні моделі;

• оцінки атрибутів.

3. Визначення життєвого циклу проекту

Фази життєвого циклу визначають логічні точки для прийняття важливих рішень по ресурсах і технічному підходу.

Саме в таких точках може коригуватися хід проекту, а також його обсяг і вартість.

Розуміння життєвого циклу проекту критично важливо для визначення обсягу зусиль по плануванню, часу початкового планування, а також часу й умов для перепланування

Для програмної інженерії визначення фаз проекту звичайно включає вибір і уточнення моделі розробки, що дозволяє описати взаємозалежності й послідовність дій.

Для системної інженерії визначаються основні фази продукту (тобто концепція, розробка й т.д.).

У великих проектах фази можуть містити етапи. Так, фаза розробки може містити етапи аналізу вимог, проектування, програмування, інтеграції, тестування.

Рекомендовані робочі продукти - результати етапу “Визначення життєвого циклу проекту”:

• опис фаз життєвого циклу проекту.

4.Оцінка трудовитрат і вартості

Оцінки трудовитрат і вартості звичайно ґрунтуються на результатах оцінок розмірів, робіт і інших параметрів планування.

Довіра до реалістичності цих оцінок визначається глибиною обґрунтування обраної моделі для оцінки й достовірністю історичних даних.

Нині розроблена велика кількість параметричних моделей для оцінки вартості й графіка.

Для перетворення атрибутів робочих продуктів і задач в оцінки трудовитрат і вартості рекомендується зібрати різні моделі або історичні дані.

Вхідні дані для оцінки трудовитрат і вартості:

• судження експертів,

• рівень компетентності й ролі, що вимагаються для виконання роботи,

• вимоги до продукту і його компонентів,

• новизна задач,

• технічний підхід,

• структура робіт,

• оцінки розмірів робочих продуктів і їхні очікувані зміни,

• вартість покупних виробів,

• обрана модель життєвого циклу проекту й проектні процеси,

• продуктивність обладнання,

• рівень знань персоналу,

• потреби в навчанні,

• виробничі умови (необхідні офісні площі, комп'ютери, інженерне обладнання),

• продуктивність виробничих процесів,

• відрядження,

• необхідний рівень безпеки,

• прямі й непрямі витрати.

Рекомендовані робочі продукти - результати етапу “Оцінити трудовитрати й вартість”:

• обґрунтування оцінок,

• оцінки проектних трудовитрат,

• оцінки проектної вартості.

5. Установлення бюджету й графіка - перший крок у розробці плану проекту

Розробка й підтримка бюджету й графіка проекту звичайно передбачають:

• визначення доступних або необхідних ресурсів,

• розподіл робіт у часі й по етапах;

• установлення взаємозалежностей для різних робіт;

• визначення тривалості кожної роботи;

• визначення ключових дат поставки продуктів клієнтові;

• установлення етапів для визначення досягнутих результатів і проведення необхідних вимірів;

• визначення необхідних резервів за часом і ресурсами;

• документування припущень і їхніх обґрунтувань.

Рекомендовані робочі продукти - результати етапу “Установити бюджет і графік проекту:

• графік проекту;

• критичний шлях;

• бюджет проекту.

6. Визначення проектних ризиків

У групі процесів «Планування проекту» виконуються ідентифікація ризикових подій, їхній аналіз і визначення пріоритетів,

У групі «Моніторинг і контроль проекту» проводиться моніторинг ризиків,

У групі «Управління ризиками» здійснюються відстеження й пом'якшення впливу ризиків.

Визначення й аналіз ризиків на етапі планування проектів включає

• ідентифікацію ризиків,

• їхнє документування,

• досягнення згоди зацікавлених сторін щодо повноти й коректності документованих ризиків,

• пріоритезацію ризиків,

• а також їхню ревізію в міру необхідності.

Під ідентифікацією ризиків розуміється

визначення потенційних проблем, небезпек, загроз і інших подій, які можуть негативно вплинути на досягнення цілей проекту.

При ідентифікації ризиків рекомендується використовувати такі методи, як оцінка ризиків, контрольні списки, структуровані інтерв'ю, мозкові штурми, моделі процесів, вартісні моделі, системний аналіз.

Ревізія ризиків проводиться, коли з'являється новий ризик, потенційні ризики стають проблемою, ризик перестає бути загрозою або істотно змінюється ситуація із проектом.

Рекомендовані робочі продукти - результати даного етапу “Визначення проектних ризиків”:

• список ідентифікованих ризиків;

• вплив ризиків і ймовірність їхнього прояву;

• пріоритети ризиків.

7. Планування управління проектними даними

Під проектними даними розуміють різні форми документації.

Документуються всі аспекти проектної діяльності.

Дані можуть мати різноманітну форму (звіти, керівництва, записи, графіки, креслення, специфікації, файли, кореспонденція) і можуть існувати в будь-якому середовищі (друковані й електронні матеріали, фотографії, мультимедіа й т.д.).

Проектні плани повинні передбачати ідентифікацію даних, методи їхнього збору й поширення.

При плануванні проекту варто визначити вимоги як до номенклатури створюваних у проекті даних, так і до їхнього змісту й форми.

Стандартні вимоги до змісту й формату даних сприяють їхньому кращому розумінню й полегшують управління джерелами даних.

Варто звернути особливу увагу на планування заходів по забезпеченню конфіденційності й безпеки даних, а також на встановлення механізму архівування й забезпечення доступу до архівованих даних.

Рекомендовані робочі продукти - результати етапу “Спланувати управління проектними даними”:

• план управління даними;

• перелік керованих даних;

• опис змісту й формату даних;

• вимоги до конфіденційності й безпеки даних;

• механізм повернення, відтворення й розподілу даних;

• графік збору даних;

• перелік даних, які повинні збиратися в проекті.

8. Планування ресурсів

Проектні ресурси включають персонал, обладнання, матеріали, технології й методики.

Визначення проектних ресурсів засновано на початкових оцінках і, у свою чергу, може використовуватися для уточнення структури робіт по проекту.

На цій стадії:

структура робіт верхнього рівня, створена раніше як основа для оцінок, звичайно декомпозуєтся на робочі пакети, що описують задачі, які можуть виконуватися й контролюватися окремо.

Така декомпозиція допомагає розподілити обов'язки по керівництву проектом і контролю ходу виконання проекту.

Кожному робочому пакету або робочому продукту повинен бути присвоєний унікальний ідентифікатор.

Рекомендовані робочі продукти - результати етапу “Планування ресурсів”:

• робочі пакети структури робіт;

• словник задач WBS;

• вимоги до людських ресурсів;

• перелік критично важливого обладнання й виробничих площ;

• описи й діаграми процесів;

• перелік вимог до адміністрування проекту.

9. Планування необхідних знань і навичок

Під необхідними знаннями й навичками розуміють знання предметної області й технічні знання.

Передача знань, необхідних для виконання проекту, включає як навчання проектної команди, так і придбання знань із зовнішніх джерел.

Саме доступні в організації знання й навички визначають вимоги до комплектування проектної команди.

На етапі планування необхідно:

• встановити необхідні для даного проекту знання й навички,

• оцінити знання й навички наявного персоналу,

• вибрати механізми забезпечення необхідних знань і навичок і

• описати ці механізми в проектному плані.

Як правило, механізми забезпечення знань включають:

• внутрішнє навчання,

• зовнішнє навчання,

• наймання нового персоналу.

Рекомендовані робочі продукти - результати етапу “Планування необхідних знань і навичок”:

• перелік необхідних знань;

• плани укомплектування проектної команди;

• плани наймання нового персоналу;

• бази даних (наприклад, навички й навчання).

10. Планування залучення зацікавлених осіб

Під зацікавленою особою (stakeholder) розуміється група або індивідуум, що беруть особисту участь у роботах із проекту, що представляють проект на різних рівнях і зацікавлені в успіху проекту.

Зацікавлені особи встановлюються для всіх фаз життєвого циклу проекту. Це робиться шляхом ідентифікації ролей і функцій, а також ступеня залучення в конкретні проектні роботи.

Варто звернути особливу увагу на тих, хто залучений до даної проектної роботи, і на тих, хто має необхідні знання й експертизу для її виконання.

Одним із найбільш зручних форматів для такої ідентифікації є двовимірна матриця з переліком зацікавлених осіб по одній осі й проектними роботами з іншої.

У загальному випадку план залучення зацікавлених осіб повинен включати:

• перелік зацікавлених осіб,

• обґрунтування їхнього залучення в проект,

• їхні ролі й відповідальності для кожної фази життєвого циклу проекту,

• взаємозв'язки між ними,

• відносне значення кожного зацікавленої особи для успіху проекту,

• необхідні ресурси для взаємодії зацікавлених осіб,

• графік їхньої участі в проекті.

Важливо, щоб особи, зацікавлені в більш пізніх фазах проекту, одержували завчасний доступ до вимог і проектних рішень, які можуть вплинути на їхню роботу.

Рекомендовані робочі продукти - результати етапу “Планування залучення зацікавлених осіб”:

• список зацікавлених осіб;

• матриця залучення;

• ролі й відповідальності в проекті.

11. Установлення плану проекту

Результатом робіт із планування проекту є документований план, що визначає всі аспекти проекту:

• графік, що відображає технічні роботи і їхню взаємозалежність,

• життєвий цикл,

• вимоги й стандарти якості для продуктів, що поставляються,

• етапи,

• технічні й управлінські задачі,

• залучення й взаємодію зацікавлених осіб,

• управління даними,

• ідентифікацію ризиків,

• задачі,

• ролі й відповідальності,

• необхідні ресурси, включаючи обладнання, виробничі приміщення, персонал,

• навички й знання,

• метрики, які передбачається використовувати при моніторингу проекту,

• описи процесів.

Рекомендовані робочі продукти - результати етапу “Установлення плану проекту”

• Документація плану проекту

12. Аналіз планів

На цьому етапі розробляється ряд додаткових планів по спеціальних дисциплінах, у тому числі

• плани по якості,

• плани управління конфігурацією,

• плани вимірювань,

• плани навчання.

Додаткові плани, розроблювані по різних групах процесів, можуть містити інформацію, що буде затребувана планом проекту.

Такі плани можуть служити більш детальним керівництвом, повинні бути сумісні один з одним і підтримувати загальний план проекту в частині визначення повноважень, обов'язків, відповідальності, звітності й контролю.

Може складатися загальний план проекту, так званий майстер-план.

Необхідно визначити й узгодити для різних проектних робіт:

• права,

• обов'язки,

• підзвітність,

• порядок контролю,

• проаналізувати всі плани, які можуть вплинути на проект, і

• переконатися в загальному розумінні цілей, завдань, ролей і взаємин, які будуть потрібні для успішного виконання проекту.

Рекомендовані робочі продукти - результати етапу “Аналіз планів”:

• записи про аналіз планів

13. Узгодження рівнів робіт і ресурсів

Звичайно оцінка необхідних ресурсів проводиться на різних рівнях. Важливо порівняти отримані оцінки з реально наявними ресурсами й узгодити розбіжності.

Для такого узгодження використовуються:

• зниження рівня або відстрочка ряду вимог до технічних характеристик,

• запит додаткових ресурсів,

• знаходження шляхів збільшення продуктивності,

• залучення зовнішніх ресурсів,

• знаходження оптимального сполучення знань і навичок персоналу,

• перегляд або ревізія планів, що впливають на хід виконання й успіх проекту.

Рекомендовані робочі продукти - результати етапу “Узгодження рівнів робіт і ресурсів”:

• ревізовані методи й параметри оцінки (наприклад, краще обладнання, використання покупних компонентів);

• переглянуті бюджети;

• уточнені графіки;

• список ревізованих вимог;

• переглянуті угоди між зацікавленими особами.

14. Взяття зобов'язань учасників по виконанню плану

Поняття «зобов'язання» означає, що робота зрозуміла виконавцеві, що він уважає цю роботу необхідною й здійсненною, що він приймає на себе зобов'язання виконати цю роботу в строк і якнайкраще.

Щоб забезпечити зобов'язання й довести, що зобов'язання дійсно взяте, необхідно:

• обговорити зі співробітником завдання,

• переконатися в розумінні цього завдання,

• попросити його висловити свій коментар щодо правильності й чіткості формулювання,

• оцінити необхідні час і трудовитрати й, нарешті,

• спланувати виконання цієї роботи.

Для перевірки, що відповідні зобов'язання отримані по всіх задачах, рекомендується використовувати у якості контрольного списку структуру робіт.

Зобов'язання мають бути отримані як з боку виконавців, так і з боку організації

Зобов'язання організації - як тимчасові, так і постійні - необхідно викласти в письмовому вигляді й підписати на відповідному рівні.

Таке документування сприяє взаєморозумінню сторін, а також дає можливість відслідковувати й підтримувати зобов'язання.

Зобов'язання учасників проекту також повинні бути документовані шляхом візування планів, письмовим підтвердженням прийняття й розуміння поставленого завдання, участю в розробці й аналізі планів.

Рекомендовані робочі продукти - результати етапу “Одержання зобов'язань учасників по виконанню плану”:

• документовані запити на прийняття зобов'язань;

• документовані зобов'язання.

Дякую за увагу!

Тема: СММІ: Моніторинг і контроль проекту

Контроль і моніторинг необхідні для:

розуміння того, у якому стані перебуває проект, і які коригувальні дії можуть бути розпочаті, якщо хід виконання проекту істотно відхиляється від плану.

Основою всіх дій по моніторингу є документований план проекту.

Прогрес у ході проекту звичайно визначається порівнянням реально отриманих результатів (робочі продукти, завдання, трудовитрати, вартість) із планованими величинами на заздалегідь установлених етапах або рівнях контролю відповідно до графіка проекту або структури робіт.

До групи “Моніторинг і контроль проекту” входять такі процеси:

• моніторинг параметрів планування;

• моніторинг зобов'язань учасників;

• моніторинг проектних ризиків;

• моніторинг управління даними;

• моніторинг залучення зацікавлених сторін;

• аналіз ходу виконання проекту;

• аналіз виконання етапів проекту;

• аналіз проблем;

• прийняття коригувальних дій;

• виконання коригувальних дій.

Загальна схема моніторингу й контролю проекту

1. Моніторинг параметрів планування

Найбільш типові показники прогресу у виконанні проекту: графік, вартість, трудовитрати, характеристики робочих продуктів і задач (розмір, складність, функціональність і т.д.), ресурси (виробничі приміщення, комп'ютери, периферійне обладнання, програмне забезпечення для проектування, виготовлення й тестування, мережі, засоби гарантування безпеки, персонал, процеси), знання й навички персоналу.

Рекомендується документувати не тільки фактичні значення параметрів, але й контекстну інформацію, яка їх стосується, що може полегшити розуміння отриманих даних.

1.Суть моніторингу параметрів планування

• вимірювання фактичних значень параметрів планування проекту;

• порівняння фактичних значень із плановими оцінками;

• визначення значних відхилень (відхилення від планових значень уважається значним, якщо без прийняття відповідних коригувальних заходів воно може призвести до недосягнення цілей проекту).

Всі значні відхилення від параметрів планування повинні документуватися.

2. Моніторинг зобов'язань учасників і інших зацікавлених сторін включає:

• регулярний аналіз зобов'язань учасників - як внутрішніх, так і зовнішніх;

• виявлення зобов'язань, які не були виконані або котрі перебувають під загрозою невиконання;

• документування результатів аналізу.

3. Моніторинг проектних ризиків включає:

• періодичний аналіз і документування проектних ризиків у контексті поточного статусу проекту й додаткових обставин, що виникли у ході його виконання;

• введення необхідних змін у документування ризиків при надходженні додаткової інформації;

• інформування про поточний статус ризиків (зміни в імовірності прояву ризику, поява нових ризиків, зміна пріоритетів ризиків) всіх зацікавлених сторін.

4. Моніторинг управління даними включає:

• періодичний аналіз робіт з управління даними, передбачених проектним планом;

• ідентифікацію й документування значних проблем і їхнього можливого впливу на хід виконання проекту;

• документування результатів аналізу.

5. Моніторинг залучення зацікавлених сторін включає:

• періодичний аналіз статусу реального залучення зазначених осіб;

• ідентифікацію й документування значних проблем і їхнього можливого впливу на хід виконання проекту;

• документування статусу залучення зацікавлених сторін.

Рекомендовані робочі продукти групи процесів моніторингу (1-5):

• записи про результати моніторингу.

6. Аналіз ходу виконання проекту

Ціль - надати зацікавленим сторонам інформацію.

Такий аналіз може мати неформальний характер і може бути встановлений у явному вигляді в плані проекту.

Аналіз ходу виконання проекту може здійснюватися в ході систематичних зустрічей членів проектної команди, на нарадах за участю інших інженерних і підтримуючих груп, на нарадах з керівництвом.

У проведенні такого аналізу можуть брати участь клієнти, кінцеві користувачі й постачальники.

6.Аналіз ходу виконання проекту включає:

• регулярне інформування зацікавлених сторін про статус доручених робіт і робочих продуктів (у число зацікавлених сторін входять керівництво, члени проектної команди, клієнти, кінцеві користувачі, постачальники);

• розгляд результатів збору й аналізу метрик, які використовуються для управління й контролю проекту;

• ідентифікацію й документування проблем і значних відхилень від плану;

• документування запитів на зміни й проблем, виявлених у кожному з робочих продуктів і процесів;

• документування результатів аналізу;

• простежування запитів на зміну й звітів про проблеми до їхнього закриття.

7. Аналіз виконання етапів проекту

планується заздалегідь і звичайно має формальний характер.

Такий аналіз проводиться для всіх значних подій проектного графіка, таких як завершення етапів, досягнення значних результатів.

У проведенні аналізу можуть брати участь керівництво, клієнти, кінцеві користувачі, члени проектної команди й інші зацікавлені особи усередині організації.

Аналіз виконання етапів проекту включає:

• зобов'язання учасників, актуальність плану, стан робіт, проектні ризики;

• ідентифікацію й документування проблем і їхнього можливого впливу на хід виконання проекту;

• документування результатів аналізу, запропонованих дій і ухвалених рішень;

• простежування запропонованих дій до їхнього завершення.

Рекомендовані робочі продукти - результати аналізу ходу виконання проекту й аналізу виконання етапів проекту:

• документовані результати аналізу

Аналіз проблем і коригувальні дії

Ціль етапу аналізу проблем - зібрати й проаналізувати проблеми й визначити, які коригувальні дії варто розпочати для їхнього вирішення.

Проблеми й питання, що вимагають вирішення, звичайно виявляються в ході аналізу й при виконанні процесів.

Необхідно фіксувати:

• проблеми й невідповідності, виявлені в процесі валідації й верифікації;

• значні відхилення параметрів планування проекту від їхніх оцінок;

• невиконані зобов'язання (як внутрішні, так і зовнішні);

• значні зміни в статусі ризиків;

• проблеми доступу до даних, збору даних, конфіденційності й безпеки даних;

• проблеми, пов'язані із залученням зацікавлених осіб.

Проблеми можуть мати різний характер

У тих випадках коли проблема, залишена без вирішення, може бути на перешкоді до досягнення поставлених у проекті цілей, потрібні коригувальні дії.

Тому аналіз проблем включає визначення тих питань, по яких потрібні коригувальні дії.

Рекомендовані робочі продукти - результати етапу аналізу проблем:

• перелік проблем, що вимагають прийняття коригувальних дій.

Коригувальні дії — це дії по усуненню виявленої невідповідності або дії, виконання яких сприяє вирішенню або усуненню проблеми.

Коригувальні дії, як і будь-які зміни зобов'язань, варто обговорити й погодити із зацікавленими сторонами.

До числа коригувальних дій відносяться:

• модифікація або коригування завдання на роботу;

• модифікація або коригування вимог;

• перегляд оцінок і планів;

• уточнення й нове узгодження ролей і обов'язків учасників проекту;

• введення додаткових ресурсів;

• зміна процесів;

• ревізія проектних ризиків.

Рекомендовані робочі продукти:

• план коригувальних дій.

Моніторинг коригувальних дій проводиться аж до їхнього остаточного завершення.

По завершенні коригувальної дії необхідно проаналізувати отримані результати й оцінити ефективність вжитих заходів. Якщо спостерігаються відхилення від очікуваних або планованих результатів, варто визначити й документувати дії, спрямовані на усунення цих відхилень

Рекомендовані робочі продукти:

• результати коригувальних дій.

Дякую за увагу!

Тема: Управління постачальниками

Мета групи процесів «Управління постачальниками»: управління процесом придбання продуктів і послуг від постачальників, з якими укладені формальні угоди (контракти).

Процес управління постачальниками в основному застосовний до тих продуктів і їхніх компонентів, які підлягають відправленню замовникові проекту.

Для зменшення проектних ризиків цей процес використовується також при придбанні продуктів, що не відправляються замовникові, але важливих для виконання проекту (наприклад, засобів розробки й тестового обладнання).

Управління постачальниками

До постачальників можуть відноситися структури, що входять до складу організації, але зовнішні стосовно даного проекту, виробничі підрозділи й лабораторії, комерційні структури.

Якщо проект використовує зовнішні продукти, повинна бути укладена угода й виділені ресурси для управління й виконання цієї угоди.

Управління постачальниками

Продукт – це як власне продукти, так і послуги.

Формальна угода - будь-яка юридична угода між організацією, що представляє проект, і постачальником.

Ця угода може мати форму контракту, ліцензії або меморандуму.

Продукт, що отримується – продукт, що поставляється в проект і стає частиною продукту, що поставляється клієнтові.

Група процесів «Управління постачальниками» містить у собі:

• визначення типу придбання;

• вибір постачальників;

• укладання угод з постачальниками;

• аналіз комерційно доступних продуктів (Commercial Of-The-Shelf, COTS);

• виконання угоди;

• передачу продуктів у проект.

Схема управління постачальниками

1. Визначення типу придбання

До типів придбання відносять:

• покупку комерційно доступних продуктів;

• одержання продуктів за контрактом;

• одержання продуктів від постачальника усередині організації;

• одержання продуктів від клієнта;

• будь-яку комбінацію з перерахованих типів (наприклад, укладання контракту на модифікацію комерційно доступного продукту або залучення іншого підрозділу організації до розробки продукту разом із зовнішнім постачальником).

1. Визначення типу придбання (закінчення)

Рекомендовані робочі продукти:

• перелік типів придбання всіх продуктів.

2. Вибір постачальників

Звичайно в усіх організаціях установлені процедури запитів до постачальників і вибору постачальників. Ці процедури повинні охоплювати:

• установлення й документування критеріїв оцінки потенційних постачальників;

• визначення потенційних постачальників і направлення їм запитів і вимог;

• оцінку пропозицій від потенційних постачальників відповідно до критеріїв оцінки;

• оцінку ризиків, пов'язаних з кожним постачальником;

• оцінку здатності постачальника виконати роботу;

• вибір постачальника.

2. Вибір постачальників (продовження)

Критерії оцінки постачальника мають першорядне значення й повинні враховувати важливі для даного проекту фактори.

Серед них географічне розташування постачальника, відгуки про роботу постачальника, технічні характеристики продукції.

2. Вибір постачальників (закінчення)

Рекомендовані робочі продукти:

• перелік потенційних постачальників,

• перелік кращих постачальників,

• обґрунтування вибору постачальника,

• переваги й недоліки потенційних постачальників,

• критерії оцінки,

• запити постачальникам і

• вимоги.

3. Укладання угод з постачальниками

Як правило, організація має встановлену процедуру укладання угод з постачальниками.

Ціль цих угод - інформувати постачальника про потреби проекту, очікування від постачальника й кількісні міри оцінки ефективності роботи постачальника.

Оскільки кожна угода є результатом переговорів з постачальником, початково висунуті вимоги можуть уточнюватися.

В угоді з постачальником документується також і те, що повинен забезпечити проект для успішної поставки (наприклад, обладнані приміщення, документація, послуги).

При укладанні формальної угоди з постачальником документуються:

• завдання на роботу, специфікації, умови й терміни поставки, перелік продуктів і послуг, що поставляються, графік поставки, бюджет, процес і критерії приймання;

• представники проекту й постачальника, відповідальні й уповноважені за внесення змін в угоду;

• процедура зміни вимог і зміни угоди;

• стандарти й процедури, яких необхідно дотримуватися;

• критичні залежності між проектом і постачальником;

• тип і глибина моніторингу роботи постачальника, включаючи процедури й критерії оцінки, які будуть використовуватися при цьому моніторингу;

При укладанні формальної угоди з постачальником документуються (продовження):

• типи аналізів, що будуть проводитися разом з постачальником;

• відповідальність постачальника за обслуговування й підтримку поставленого продукту;

• гарантійні зобов'язання, права власності, права користування;

• критерії приймання.

Важливо гарантувати, що всі учасники досягли однакового розуміння угоди й вимог ще до того, як ця угода почне виконуватися.

При необхідності перегляду угоди з постачальником варто переглянути плани проекту й зобов'язання учасників.

3. Укладання угод з постачальниками (закінчення)

Рекомендовані робочі продукти:

• завдання на роботу,

• контракти,

• меморандуми про наміри,

• ліцензійні угоди.

4. Аналіз комерційно доступних продуктів

Фактори, що враховуються при оцінці продуктів, які передбачається придбати:

• вартість продуктів,

• трудовитрати і вартість їхнього впровадження в проект,

• вимоги безпеки,

• переваги й можливі впливи наступних модифікацій цих продуктів.

Слід враховувати також імовірність, що постачальник перестане підтримувати ту версію продукту, що придбана проектом.

4. Аналіз комерційно доступних продуктів (продовження)

Рекомендується також оцінити якість роботи постачальника і його здатність до поставок, а також пов'язані з цим ризики.

У деяких випадках цей вибір може потребувати укладання додаткових угод, включаючи знижки на більші партії товарів, плани майбутніх удосконалень, підтримку й обслуговування на площадці покупця відповідно до запитів і звітів про проблеми, додаткові можливості, які не забезпечуються продуктом.

Якщо угода з постачальником включає підтримку придбаного продукту, така підтримка повинна плануватися.

4. Аналіз комерційно доступних продуктів (закінчення)

Рекомендовані робочі продукти - результати даного етапу:

• звіти про вивчення ринку,

• прейскуранти,

• критерії оцінки,

• звіти про роботу постачальника,

• документований аналіз комерційно доступних продуктів.

5. Виконання угоди

Виконання угоди з постачальником вимагає від замовника проведення моніторингу й аналізів.

Моніторингу піддаються не тільки графік, трудовитрати, вартість і технічні характеристики, але й використовувані постачальником процеси (наприклад, забезпечення якості, управління конфігурацією).

5. Виконання угоди (продовження)

Ефективними засобами досягнення успіху у виконанні угоди є проведення :

• спільних з постачальником аналізів ходу виконання робіт,

• технічних нарад,

• управлінського аналізу.

5. Виконання угоди (продовження)

а) Аналізи ходу виконання робіт можуть мати формальний і неформальний характер і звичайно містять у собі:

• підготовку аналізу,

• забезпечення участі всіх зацікавлених сторін,

• засідання,

• визначення, документування й простежування необхідних дій,

• підготовку й передачу учасникам звіту про результати аналізу.

5. Виконання угоди (продовження)

б) Технічні наради мають на меті вирішення таких питань:

• ознайомлення постачальника з потребами й очікуваннями клієнта;

• аналіз технічних дій постачальника й підтвердження того, що інтерпретація й реалізація вимог постачальником узгоджуються з інтерпретацією вимог проектною командою;

• підтвердження того, що технічні зобов'язання виконуються й технічні проблеми відомі й вирішуються вчасно;

• одержання технічної інформації про продукти постачальника;

• надання постачальникові необхідної технічної інформації й підтримки.

5. Виконання угоди (продовження)

в) Управлінський аналіз присвячений розгляду критичних залежностей, пов'язаних із постачальником проектних ризиків, графіка й бюджету.

Управлінський аналіз може бути сполучений із технічними нарадами.

Залежно від ходу виконання робіт угоди з постачальником, плани й графіки проекту можуть переглядатися.

5. Виконання угоди (закінчення)

Рекомендовані робочі продукти - результати даного етапу:

• звіти про хід робіт постачальника й результати вимірювань ефективності роботи постачальника,

• матеріали й звіти про спільні з постачальником аналізи,

• розпочаті коригувальні дії,

• документування результатів поставки продуктів і документації.

6. Приймання продукту й передача продуктів у проект

Перед прийманням продукту повинні бути завершені приймальні перевірки й тести.

6. Приймання придбаного продукту включає цілий ряд дій:

• розробка процедур приймання;

• аналіз і узгодження процедур приймання із зацікавленими сторонами до початку приймання;

• перевірка відповідності придбаних продуктів пропонованим вимогам;

• підтвердження виконання нетехнічних зобов'язань стосовно продукту, що отримується (наприклад, наявність відповідних ліцензій, гарантій, прав володіння, прав використання, угода про підтримку й обслуговування й т.д.);

• документування результатів приймального тестування;

• установлення угоди з постачальником про план дій по продуктам, які не пройшли приймальні випробування;

• визначення, документування й відстеження передбачених дій аж до їхнього виконання.

6. Рекомендовані робочі продукти:

• процедури приймання,

• результати приймальних випробувань,

• план усунення недоліків або план коригувальних дій.

Перед передачею придбаних продуктів у проект варто переконатися в тому, що

• підготовлено відповідні приміщення й умови для установлення, зберігання, експлуатації й супроводу,

• навчений персонал, залучений у цю роботу.

Експлуатація й зберігання придбаних продуктів повинні здійснюватися відповідно до умов, визначених контрактом на поставку.

Рекомендовані робочі продукти - результати даного етапу:

• плани передачі продуктів,

• записи про навчання,

• звіти про підтримку й супровід.

Дякую за увагу!

Тема. СММІ: Моніторинг і контроль проекту

Контроль і моніторинг необхідні для розуміння того, у якому стані перебуває проект, і які коригувальні дії можуть бути початі, якщо хід виконання проекту істотно відхиляється від плану.

Основою всіх дій по моніторингу є документований план проекту. Прогрес у ході проекту звичайно визначається порівнянням реально отриманих результатів (робочі продукти, завдання, трудовитрати, вартість) із планованими величинами на заздалегідь установлених етапах або рівнях контролю відповідно до графіка проекту або структури робіт.

Ця група процесів містить у собі:

1. моніторинг параметрів планування;

2. моніторинг зобов'язань учасників;

3. моніторинг проектних ризиків;

4. моніторинг управління даними;

5. моніторинг залучення зацікавлених сторін;

6. проведення аналізу ходу виконання проекту;

7. проведення аналізу виконання етапів проекту;

8. аналіз проблем;

9. прийняття коригувальних дій;

10. виконання коригувальних дій.

Загальна схема моніторингу й контролю проекту показана на рис. 1.

Рис. 1. Схема моніторингу й контролю проекту