Professional Documents
Culture Documents
All PDF
All PDF
Лекції:
Лазарєва Світлана Федорівна
професор кафедри інформаційного менеджменту
413 кімн.
Тел. 537-07-43
Практичні, семінарські та лабораторні:
РЕКОМЕНДОВАНА ЛІТЕРАТУРА
Основна:
• Батенко Л.П., Загородніх О.А., Ліщинська В.В. Управління проектами: Навч. посібник. – К.:
КНЕУ, 2003. – 231 с.
• Фергус О’Коннел. Как успешно руководить проектами. Серебряная пуля: Пер. с англ. – М.:
КУДИЦ-ОБРАЗ, 2003. – 288 с.
• Джозеф Филлипс. Менеджмент ІТ-проектов.На пути от старта до финиша: Пер. с англ. – М.:
“ЛОРИ”, 2005. – 376 с.
• Куперштейн В.И. Microsoft Project 2010 в управлении проектами/Под общей ред. А.В.Цветкова.-
Спб.: БХВ- Петербург,2012.- 416 с.
• Кочетков А.Г. и др. Управление проектами (зарубежный опыт). – СПб.: "ДваТри", 1992. – 515 с.
Завдання дисципліни:
Поточний контроль
а) виконання завдань та відповіді на семінарських (практичних,лабораторних) заняттях - 30 балів:
–Результати експрес-контролю (тестування) – 14 балів;
–Лабораторна робота №1 + статут 4+2=6 балів;
–Лабораторні роботи № 2-5 – 8 балів;
–Задача аналіз проектних ризиків – 2 бали.
б) виконання завдань для самостійного опрацювання (2x5=10 балів) (Підготовка реферату (есе) та
його презентація або переклад іншомовних текстів; підготовка реферативних матеріалів з
публікацій, участь у науковій конференції тощо).
в) виконання модульних (контрольних) завдань (два модуля) – 2x5=10 балів.
г) заохочувальний бал (бонус) – 5 балів.
Усього – 50 + 5 балів
За вибором студента
Курсова робота
100 балів.
• Класифікація проектів.
Визначення проекту:
Що таке проект?
Що таке управління проектом?
Управління проектами
(Project Management)
Управління проектами
- це застосування знань, навичок, інструментів і методів до робіт проекту для задоволення вимог, що
висуваються до проекту.
Зв'язок методології управління проектами
з іншими управлінськими дисциплінами
Піраміда “арсеналу” управління проектом
Етапи розвитку методів управління проектами
Етапи розвитку методів управління проектами
• магію віри,
• магію влади,
• магію лідерства,
• магію компетенції,
• магію цілепокладання,
• магію ціледосягнення,
• магію системи,
• магію процесу,
• магію очікувань,
• магію результату,
• Ризик (конфлікти).
Взаємозалежність основних ознак проекту
Тріада проектного менеджменту
Проекти розрізняються за обсягом, змістом і формою
Над проектом можуть працювати багато виконавців або одна особа (наприклад, переатестація всіх
співробітників – це проект, умеблювання й обладнання кафедри - також).
Керівництво проектом може бути формальним (з включенням в річний план організації, офіційним
затвердженням плану робіт, кошторису і виконавців) або неформальним (виконуваним за
дорученням, без встановлення витрат і кількості учасників).
Проекти можуть контролюватися формально (витрачені кошти і час строго обліковуються
відповідними службами) і неформально (облік не ведеться, а витрати відносять на виробничі
витрати).
Проекти розрізняються за обсягом, змістом і формою
Проекти можуть виконуватись як зовнішніх, так і внутрішніх клієнтів і замовників (розробка або
впровадження готової ІС у клієнта – це проект, підготовка пропозицій щодо удосконалення
системи мотивації персоналу – також проект)
Проект може виконуватися на основі офіційного договору (підписаного обома сторонами, наприклад,
договір на розробку ПЗ) або за неформальною домовленістю (встановлення нової програми на
комп’ютер колеги)
Проекти можуть бути як ділового (щорічне складання плану робіт на наступний рік), так і
приватного призначення (організація святкування свого ювілею).
Основні принципи управління проектом інформатизації
• Принцип успіху
• Принцип зобов'язань
• Принцип альтернатив
• Принцип єдиноначальності
• Процесний принцип
– якість,
– вартість.
4.Принцип єдиноначальності
Цей принцип необхідний для ефективного розподілу зобов'язань щодо проекту.
Між спонсором і керівником проекту повинен існувати єдиний канал комунікації для передачі всіх
рішень, що впливають на продукт проекту.
Власник кінцевого продукту проекту, навіть якщо він представлений більше, ніж однією особою, не
зважаючи ні на що, має право одного голосу.
Також команда проекту повинна мати одну відповідальну особу, керівника проекту, для роботи над
проектом. Він повинен бути відданим справі, мати навички, досвід, повноваження і завзятість,
необхідні для успішного здійснення проекту.
5. Принцип культурного середовища
Керівництво проекту повинне створювати сприятливе культурне середовище, щоб команда проекту
працювала на повну силу.
Сприятливе культурне середовище - це середовище, у якому проект повністю підтримується
керівництвом, а членам команди проекту надана можливість працювати на повну силу без зайвих
бюрократичних перешкод.
Цей принцип містить у собі потребу в керівництві за якого спрямованість і стиль керівництва
відповідають як типу, так і фазі життєвого циклу проекту.
6. Процесний принцип
Для виконання задач проекту повинні існувати ефективні політики й процедури, які, як мінімум, повинні
охоплювати:
– планування,
– виконання.
Ці дві послідовні фази складають основу життєвого циклу кожного проекту і можуть бути розширені,
щоб відповідати контрольним вимогам кожного проекту в будь-якій сфері.
Життєвий цикл проекту характеризується "віхами", що позначають початок проекту, "контрольні точки",
які він повинен перетнути, і кінець проекту.
Портфель проектів
- це набір проектів або програм і інших робіт, об'єднаних разом з метою ефективного управління
даними роботами для досягнення стратегічних цілей.
Проекти й програми портфеля не обов'язково є взаємозалежними або прямо пов'язаними.
Управління портфелями
• Менеджер проекту має справу з задачами, націленими на створення чогось нового або на
зміни існуючого.
• Цілі проекту повинні бути чіткими, зрозумілими і прийнятими усіма, хто відповідає або
впливає на виконання проекту.
• час
• ресурси
• гроші
• якість
Основні параметри управління проектом:
• Визначення задач (робіт). Задача (робота) - це будь-які дії або події, які необхідні для
виконання проекту
• Оцінка бюджету
• Встановлення пріоритетів
• за предметом стандартизації
• за методичним джерелом
1. За предметом стандартизації розрізняють:
• Інститут управління проектами США (Project Management Institute – PMI). Членами PMI є
фахівці в галузі управління проектами з усього світу, в різних країнах функціонують відділення
інституту. PMI веде активне розроблення стандартів у сфері управління проектами.
Міжнародні стандарти, що визначають норми й правила по управлінню процесами в проектах
технічних систем, процесами життєвого циклу системи, процесами проектування тощо
• 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 -
Побудова конструкцій. Процесний менеджмент. Провідні вказівки щодо систем проектного
менеджменту.
Професійні міжнародні й національні кваліфікаційні стандарти для менеджерів проектів й/або фахівців з
управління проектами
• економічні,
• організаційні,
• технічні,
• змішані.
Соціальні проекти
- цілі тільки намічаються і далі коригуються по мірі досягнення проміжних результатів; кількісна. і
якісна їх оцінка суттєво утруднена;
- терміни і тривалість проекту залежать від ймовірнісних чинників або тільки намічаються і
надалі підлягають уточненню;
- витрати залежать від бюджетних асигнувань;
- ресурси виділяються по мірі потреби;
- мають велику невизначеність.
Економічні проекти:
- цілі - поліпшення економічних показників функціонування системи; головні цілі проекту є
попередніми. Вони намічаються, але потребують коригування по мірі реалізації проекту . Це
стосується тривалості і термінів виконання проекту також
- ресурси надаються по мірі необхідності і в межах можливого;
- витрати встановлюються заздалегідь, контролюються на економічність і контролюються по мірі
реалізації проекту.
Організаційні проекти
• проекти заздалегідь визначені, але результати проекту кількісно і якісно важко визначити,
оскільки вони пов'язані з організаційним поліпшенням системи;
• інвестиційні,
• інноваційні,
• дослідження і розвитку,
• навчально-освітні,
• ІТ-проекти (інформатизації),
• комбіновані.
Інвестиційний проект - головною метою є створення або реновація основних фондів, що вимагає
вкладення інвестицій
- мета, термін завершення і тривалість, витрати на проект чітко визначені і фіксовані.
- необхідні ресурси і фактична вартість залежать від ходу виконання робіт по проекту і необхідні
потужності повинні надаватись відповідно до графіка і терміну готовності етапів і завершення
проекту.
Інноваційний
• головна мета проекту чітко визначена, але окремі цілі (підцілі) можуть уточнюватися по мірі
досягнення проміжних результатів,
• планування витрат на проект часто залежить від виділених асигнувань і як правило менше від
бюджету, що виділяється для проекту
Проект інформатизації:
комплекс взаємопов’язаних заходів, зазвичай інвестиційного характеру, що узгоджені за часом,
використанням певних матеріально-технічних, інформаційних, людських, фінансових та інших
ресурсів і мають на меті створення заздалегідь визначених інформаційних і
телекомунікаційних систем, засобів інформатизації та інформаційних ресурсів, які
відповідають певним технічним умовам і показникам якості.
• дрібні,
• середні,
• великі,
• дуже великі.
Такий поділ проектів дуже умовний.
Масштаби проектів можна розглядати й у більш конкретній формі:
• міждержавні,
• міжнародні,
• національні,
• міжрегіональні та регіональні,
• міжгалузеві та галузеві,
• корпоративні,
• відомчі,
• прості,
• складні та
• дуже складні.
Ступінь складності залежить від характеру і новизни завдань, які необхідно виконати, ступеня
ретельності підготовки і розробки всіх аспектів аналізу проектів, вимог до рівня професійності й
досвіду управлінської команди.
Зазвичай мега- та мультипроекти належать до складних чи дуже складних проектів.
На практиці часто виникає необхідність одночасного виконання різних проектів, результати яких тією чи
іншою мірою впливають один на одного.
Залежно від взаємовпливу розрізняють такі види проектів:
• незалежні,
• взаємовиключаючі,
• умовні,
• заміщуючі,
• синергічні.
Відповідно до класифікації й розподілу проектів на види можна виділити деякі особливості та типові
умови, які дозволяють відрізняти їх один від одного.
Поняття “нормального проекту"
Нормальним вважається той проект в якому більш-менш збалансований вплив таких чинників:
• якість;
• обмеженість ресурсів.
Особливості управління малими проектами
• дуже важливою є оцінка якості робіт, оскільки часу на виправлення помилок немає. Тому перед
початком роботи необхідно розглянути питання про:
- ділянки роботи;
- методи роботи;
- графіки основних операцій;
- форми звітів;
- умови контракту.
Особливості управління малими проектами
Для малих проектів рекомендується:
- призначити одного адміністратора;
- організація команди проекту повинна бути гнучкою, забезпечувати взаємозамінність членів;
- кожний член команди повинен чітко знати задачі і обсяги робіт;
- при плануванні і складанні графіка робіт застосовувати прості методи;
- пуск або введення в експлуатацію повинні здійснювати ті ж фахівці, що починали проект.
Особливості управління мегапроектами
Мегапроекти:
- висока вартість;
- потреба в фінансових коштах вимагає нетрадиційної форми фінансування;
- великий обсяг робіт;
- необхідність участі інших країн;
- віддаленість районів, де реалізуюся мегапроекти, додаткові витрати на інфраструктуру;
- вплив на навколишнє середовище регіону.
Особливості управління мегапроектами
При організації управління необхідно враховувати чинники:
- розподіл елементів проекту по різних виконавцях і необхідність координації їх діяльності;
- необхідність аналізу соціального середовища регіону, країни загалом, ряду країн - учасниць
проекту;
- необхідність виділення в якості самостійної фази розробку концепції проекту;
- розробка і постійне оновлення планів проекту;
- необхідність моніторингу проекту з постійним оновленням всіх його елементів;
- урахування унікальності мегапроекту.
Особливості управління короткостроковими проектами
Короткострокові проекти:
- стислі терміни реалізації;
- вартість може складати до кількох десятків тисяч доларів і може зростати в процесі реалізації.
Особливості управління короткостроковими проектами
Рекомендації:
• попередні дослідження;
• визначення проекту, яке включає: Цілі, Задачі, Результати, Основні вимоги, Обмежувальні
умови, Критерії, Рівень ризику, Оточення проекту, Потенційні учасники, Необхідний час,
Ресурси, Кошти та ін.;
• введення в експлуатацію;
Незалежно від кількості фаз, що складають проект, всі фази мають схожі характеристики:
• При послідовному виконанні фаз завершення фази супроводжується певного роду передачею
отриманого продукту як результат фази.
• Як правило, роботи фази мають властивості, які відрізняють її від інших фаз. При цьому можуть
залучатися різні організації й використовуватися різні набори компеденцій.
• Для успішного досягнення головного результату або мети фази потрібен додатковий ступінь контролю.
• Передінвестиційна фаза
• Інвестиційна фаза
• Експлуатаційна фаза
Передінвестиційна фаза
• Будівництво (Construction)
• Навчання (Training)
Експлуатаційна фаза
• Прийом і запуск (Commissioning & Start)
• Класифікація проектів.
Питання 6.
Учасники й оточення проекту.
Склад учасників проекту, їх роль, розподіл їх функцій і відповідальності залежать від типу, виду,
масштабу і складності проекту, а також від фаз ЖЦ проекту.
Жорстких регламентів по складу учасників проекту не існує.
Незмінними можна вважати наступні функції по здійсненню проекту, а отже і такий склад основних
учасників:
- проект повинен бути осмислений, “придуманий" і ініційований, значить у нього повинен бути
ініціатор;
- проект повинен мати головну зацікавлену особу (організацію), тобто сторону, яка є майбутнім
власником і користувачем результатами проекту і несе за нього відповідальність. У нашій
термінології замовник = власник + користувач;
- здійснення проекту вимагає залучення інвестицій, отже, у нього повинні бути інвестори;
- проект треба готувати і здійснювати, значить у нього повинні бути виконавці;
- внаслідок реалізації більшості проектів щось має вироблятися або надаватися послуги, отже проект
повинен мати своїх продавців, виробників і споживачів;
- проектом треба управляти, отже у проект повинен мати менеджерів.
Принципова схема учасників проекту
Функції основних учасників проекту
Ініціатор: сторона, що є автором головної ідеї проекту, його попереднього обґрунтування і пропозицій
по здійсненню проекту.
Ініціатором може бути практично будь-хто з майбутніх учасників проекту, але зрештою ділова ініціатива
по здійсненню проекту повинна виходити від замовника.
Функції основних учасників проекту
Замовник: головна сторона, зацікавлена у здійсненні проекту і досягненні його результату.
Як правило, це майбутній власник і користувач результатів проекту. Він визначає основні вимоги і
масштаби проекту, забезпечує фінансування проекту за рахунок своїх коштів або коштів інвесторів,
що залучаються до проекту. Він укладає контракти з основними виконавцями проекту, несе
відповідальність за цими контрактами, управляє персоналом взаємодії між учасниками проекту,
несе відповідальність за проект перед суспільством і законом.
Функції основних учасників проекту
Інвестор: сторона, що вкладає інвестиції в проект.
Мета інвестора - максимізація прибутку на свої інвестиції.
Якщо інвестор і замовник не одна особа, то звичайно як інвестори виступають банки, інвестиційні
фонди.
Інвестори вступають у контрактні відносини із замовником, здійснюють розрахунки з іншими сторонами
по мірі виконання проекту. Інвестори є повноправними партнерами проекту і власниками проекту,
поки їм не будуть виплачені всі кошти за контрактом із замовником або кредитною угодою.
Функції основних учасників проекту
Керівник проекту (менеджер): юридична особа, якій замовник і інвестор делегує повноваження з
керівництва роботами по здійсненню проекту, а саме: плануванню, контролю і координації робіт
всіх учасників проекту. Склад функцій і повноважень керівника проекту визначається контрактом із
замовником. Однак, перед керівником проекту і його командою звичайно ставиться задача
всеосяжного керівництва і координації робіт протягом ЖЦ проекту до досягнення певної мети
проекту і результатів при дотриманні встановлених термінів, бюджету і якості.
Функції основних учасників проекту
Команда проекту: специфічна організаційна структура очолювана керівником проекту і яка створюється
на період здійснення проекту.
Задача команди проекту: здійснення функцій управління проектом до ефективного досягнення цілей
проекту.
Склад і функції команди проекту залежать від масштабів, складності і інших характеристик проекту.
Як правило, основними учасниками команди проекту є: менеджер проекту, інженер, адміністративний
керівник контракту, контролер, бухгалтер, керівник служби матеріально-технічного забезпечення,
керівник робіт з проектування, керівник будівництва, координатор робіт з експлуатації,
адміністративний помічник, керівник інформаційної служби.
Функції основних учасників проекту
Контрактор (генеральний контрактор): сторона або учасник проекту, що вступає у відносини з
замовником і який бере на себе відповідальність за виконання робіт за контрактом. Це може бути
весь проект або його частина.
Мета контрактора - отримання максимально можливого прибутку. Функції контрактора: укладання
контракту із замовником (інвестором), відбір і укладання договорів з субконтракторами,
забезпечення координації їх робіт, прийняття і оплата робіт співвиконавців. Контрактором може
бути керівник проекту або інші активні учасники проекту.
Субконтрактор: вступає у договірні відносини з контрактором або субконтрактором більш високого
рівня, несе відповідальність за виконання робіт і послуг відповідно до контракту.
Функції основних учасників проекту
Проектувальник: юридична особа, що виконує за контрактом проектно-дослідницькі роботи в рамках
проекту. Вступає у договірні відносини з генеральним контрактором або безпосередньо із
замовником.
Генеральний підрядник: юридична особа, чия пропозиція прийнята замовником (як правило, для
будівельних проектів). Тому звичайно генеральним підрядником є будівельна і проектно-будівельна
організації. Генеральний підрядник несе відповідальність за виконання робіт відповідно до
контракту, підбирає і укладає договори з субпідрядниками на виконання окремих робіт і послуг.
Постачальники: субконтрактори, що здійснюють різні види постачання на контрактній основі.
Функції основних учасників проекту
Ліцензори: організації, що видають ліцензії на право володіння земельними ділянками, ведення торгів,
виконання певних робіт і послуг, використання “ноу-хау".
Органи влади: сторона, що висуває і підтримує екологічні, соціальні і інші висуваються суспільством і
державою сторони проекту і що задовольняє свої інтереси шляхом отримання податку від
учасників проекту.
Власник земельної ділянки: юридична або фізична особа, що є власником землі, що бере участь у проекті.
Виробник кінцевої продукції: здійснює експлуатацію створених основних фондів і виробляє кінцеву
продукцію. Бере участь у всіх фазах проекту. У багатьох випадках є замовником і інвестором.
Головна мета – прибуток.
Функції основних учасників проекту
Споживачі кінцевої продукції: юридичні і фізичні особи, що є покупцями і користувачами кінцевої
продукції, що визначають вимоги до кінцевої продукції і послуг, що формують попит на них. За
рахунок коштів споживачів відшкодовуються витрати на проект і формується прибуток всіх
учасників проекту.
Інші учасники проекту: конкуренти основних учасників проекту; суспільні групи і населення, чиї
економічні і неекономічні інтереси зачіпає здійснення проекту; спонсори проекту; різні
консалтингові, інжинірингові організації, залучені до здійснення проекту і інші.
Функції основних учасників проекту
Для визначення повного складу учасників проекту, побудови його функціональної і організаційної
структур на стадії розробки концепції проекту необхідно визначити:
- предметну область: цілі, задачі, роботи і основні результати, масштаби, терміни, складність;
- відносини власності, залученої до здійснення проекту (що скільки коштує і кому належить);
- основні ідеї реалізації проекту (як зробити);
- основні активні учасники проекту;
- основні пасивні учасники проекту (кого торкається проект);
- які мотивації учасників проекту (можливий прибуток, збитки, ризик і т.д.)
Оточення проекту
Щоб методично правильно організувати роботу з реалізації проекту необхідно враховувати таке:
1. - Проект виникає, існує та розвивається у певному оточенні, яке називається зовнішнім середовищем
2. - Ряд елементів проекту можуть бути використані як в його складі, так і поза ним (наприклад –
спеціалісти працюють над кількома проектами).
3. - Проект не є жорстким утворенням. Його елементи можуть перейти із зовнішнього середовища до
складу проекту і навпаки.
Проект та його оточення
Схема оточення проекту
Оточення проекту у складі підприємства
Експертна оцінка ступеню впливу факторів оточення на різні типи проектів
Основи управління проектами
• Проект і сутність проектної діяльності.
• Міжнародні та національні стандарти з управління проектами.
• Класифікація проектів.
• Життєвий цикл і фази проекту.
• Моделювання і стандарти життєвого циклу проектів інформатизації.
• Учасники й оточення проекту.
• дерево цілей
• дерево рішень
• дерево робіт
• матриця відповідальності
• сіткова модель
• структура витрат
Дерево цілей - схема цілей, підцілей по рівнях
Основне правило розбиття – повнота.
Кожна ціль верхнього рівня повинна бути представлена повним набором підцілей.
Ціль (мета) проекту - доказовий результат і задані умови реалізації загальної задачі проекту
Розрізняють:
цілі -"результати" (доказовий результат) і
цілі - "спосіб дій" (умови реалізації).
Разом ці компоненти складають цілі проекту, які виникають на основі потреб, необхідності, бажання,
ідей тощо.
Знаходження цілі проекту рівнозначно його визначенню і складає важливий етап в його розробці
При знаходженні цілі не можна обмежуватися формулюванням тільки абстрактно, а треба знайти точні
цільові характеристики/результати проекту і умови, що враховуються при реалізації проекту
(вимоги і обмежень).
Після знаходження цілі приступають до пошуку й оцінки альтернативних способів її досягнення.
Для кожного проекту може бути велика кількість взаємопов'язаних цілей, що відображають його
структуру і учасників.
Цілі проекту повинні мати чітке значення; результати, що отримуються при досягненні цілей, повинні
бути вимірними; задані обмеження і вимоги - здійсненними, тобто цілі повинні знаходитися в
області допустимих рішень проекту.
Звичайно вони обмежуються термінами, бюджетом, ресурсами, що виділяються і необхідною якістю
результатів.
Визначення цілей проекту - творчий процес, який включає:
1) ВИЗНАЧЕННЯ ПОКАЖЧИКІВ ЦІЛЕЙ
2) ВИЗНАЧЕННЯ МОЖЛИВИХ ЦІЛЕЙ ПРОЕКТУ
3) ОПИС ЦІЛЕЙ ПРОЕКТУ
Визначення цілей проекту - творчий процес:
1) ВИЗНАЧЕННЯ ПОКАЖЧИКІВ ЦІЛЕЙ можна розглядати як попереднє дослідження, після якого по
знайдених покажчиках може бути розпочатий активний пошук цілі та її формулювання.
Цей етап вимагає вивчення різних джерел, які можуть містити необхідну інформацію (вимоги до
проекту, замовлення на проект, оточення підприємства etc)
Визначення цілей проекту - творчий процес:
2) ВИЗНАЧЕННЯ МОЖЛИВИХ ЦІЛЕЙ ПРОЕКТУ - використовуються індивідуальні/групові методи.
Строгих підходів до цього немає.
При індивідуальній роботі використовуються логічні методи (односторонній розгляд проекту), при
груповій роботі - інтуїтивні (мозкового штурму, запису ідей etc)
Визначення цілей проекту - творчий процес:
3) ОПИС ЦІЛЕЙ ПРОЕКТУ - задокументована угода про цілі проекту.
Опис цілей визначає суть проекту і є основою для подальшої роботи над проектом
Якщо були ризикові міркування, то в опис проекту входить угода про результати, заява про наміри,
терміни і бюджет, угода про розв'язання можливого конфлікту між результатами, термінами і
витратами.
• визначення ступеня деталізації проектних робіт (так, щоб вони піддавались оцінці);
• визначення кількості рівнів (як правило три — чотири, для сучасних компаній — чотири
оптимально);
Структура робіт проекту (WBS) повинна бути інтегрована з організаційною структурою проекту
(OBS- Organization Breakdown Structure)
WBS розбиває загальний обсяг робіт по проекту на незалежні блоки, що піддаються управлінню - пакети
робіт, які будуть передані під управління так званих цільових менеджерів команди проекту, що
несуть відповідальність за їхнє здійснення й завершення, установлюючи, таким чином, логічний
зв'язок між ресурсами проекту й обсягами робіт, які треба буде здійснити.
Організаційна структура виконавців (OBS – Organization Breakdown Structure)
У цій схемі керівник - нульовий рівень. На більш низьких рівнях - відділи, необхідні для
функціонального управління роботами.
Ці рівні іноді відповідають рівням WBS. Мета OBS - визначити виконавців, відповідальних за виконання
робіт.
матриця відповідальності - зв'язує пакети робіт з організаціями-виконавцями.
Складається на основі WBS і OBS
Сітьова модель - на основі WBS і OBS, дерева цілей і робіт складають сітковий графік вузлових подій
Інші моделі
• структура витрат - ієрархічний граф, який фіксує вартість елементів проекту на кожному
рівні.
Схема взаємодії структурних моделей проекту
• висока ймовірність появи нових, раніше не виконуваних робіт, для яких технологія й
система управління створюються "на ходу";
• захист авторського права на бази даних і програми, створені для потреб інформатизації та
особистої інформації;
• законодавством України та
• не мати у своєму статутному фонді іноземних інвестицій та іноземних громадян серед своїх
засновників;
• Бізнес-проекти. До них відносять проекти метою яких є створення нових ІТ-сервісів для
бізнес-підрозділів.
• комп’ютерної графіки;
• найпоширеніший,
• найчисельніший,
• найскладніший
вид проектів інформатизації підприємства.
Проекти розвитку фінансово-економічних систем автоматизують, як правило, забезпечуючі
(допоміжні) бізнес-процеси.
Виключенням є системи MRP II / ERP, які автоматизують крім того і планування операцій основних
бізнес-процесів.
Прикладом фінансово-економічних систем є:
• зміна ліцензійної політики виробників ПЗ, наприклад введення фірмою Microsoft практики
обмеженого терміну дії ліцензії на операційну систему Windows XP, а також інші можливі
проблеми.
Ці зовнішні ризики перебувають поза контролем підприємства і його ІТ-служби, внаслідок чого
вдосконалювання управління ІТ-службою не дозволяє їх усунути.
Всі перераховані ситуації несуть у собі ризики відмови сервісу або зниження його якості.
• Технічні проблеми, такі як некоректна обробка дати, можуть привести до відмови сервісу в
ситуації, не передбаченої розробником апаратних або програмних засобів.
• Зміна технічної політики виробників устаткування й ПЗ означає звичайно часткове або повне
припинення підтримки певних ІТ-Рішень із боку їхніх виробників.
• Нарешті, зміна ліцензійної політики (точніше, ті зміни, які представляють проблему для
кінцевих користувачів) веде до подорожчання програмного забезпечення, а значить і
відповідних сервісів.
Проекти розв’язання проблем
Подібний проект передбачає термінову зміну інфраструктури ІТ підприємства, пов'язану з обставинами,
не врахованими в плануванні.
Йдеться про таку ситуацію в розв'язанні проблеми, коли необхідні зміни вимагають окремого проекту.
Сам проект полягає в модернізації або заміні ресурсів ІТ, які послужили причиною проблеми.
Терміновість зміни має на увазі усунення проблеми на певний термін (дату).
Загальні принципи таких “надзвичайних” проектів:
• необхідно оцінити повні витрати по моделі ФВА для основного й запасного варіантів
розв'язання;
Розробка схеми проекту розв'язання проблеми має на увазі кілька обов'язкових етапів:
Слід зазначити, що в рамках однієї проблеми не обов'язково присутні всі складові втрат. Проблеми,
пов'язані з політикою виробників, як правило, не створюють ризиків відмови сервісу.
Аналогічно непередбачені технічні проблеми створюють ризики відмови сервісу, але не ведуть до
подорожчання існуючих ІТ-Рішень.
Статут проекту - це документ, який після затвердження формально санкціонує (ініціює) проект або фазу,
і документує початкові вимоги, що задовольняють потребам і очікуванням зацікавлених сторін
проекту.
Він установлює партнерство між виконуючою організацією й організацією, що подала заявку (або
замовником, у випадку зовнішніх проектів).
Менеджер проекту визначається або призначається відразу, як тільки це стає можливим, переважно під
час розробки Статуту проекту й обов'язково до початку планування.
Рекомендується, щоб менеджер проекту брав участь у розробці Статуту проекту, тому що даний
документ наділяє менеджера проекту повноваженнями використовувати ресурси для виконання
проекту.
Розробка Статуту проекту:
входи, інструменти, методи й виходи
Вхідні дані: Розробка Статуту проекту
1. Опис робіт (Statement of work, SOW) - це словесний опис продуктів або послуг, які повинен зробити
проект.
Для внутрішніх проектів ініціатор або спонсор проекту надає опис робіт на підставі бізнес-потреб,
вимог до продукту або послуги.
Для зовнішніх проектів опис робіт може бути отриманий від замовника як частина документації по
пропозиціях, наприклад запиту пропозиції, запиту інформації, запиту заявок, або як частина
контракту.
Вхідні дані
Розробка Статуту проекту: (продовження)
Перелік робіт відображає:
• консультанти;
• галузеві об'єднання;
• Мета проекту
• Орієнтовний бюджет
Зі Статуту виключена вимога до опису повернення інвестицій (ROI), тому що все що відбувається до
Статуту в тому числі ROI-Аналіз - це справа портфельного менеджера.
Шаблон статуту проекту:
Елементи статуту проекту:
• Бізнес-умови проекту (причини для початку роботи над проектом) (Обмеження проекту)
• Базовий граничний строк завершення робіт (більш точна дата наводиться в плані проекту)
• Виконавчий комітет
• Лідер проекту
• Лідери проекту в IT-Галузі (Лідери команд розробки або лідери проектних команд в IT-
Галузі, які допомагають менеджерові проекту в адмініструванні й/або управлінні
специфічними аспектами проекту)
• Координатор випробувань
• Контролер якості
• Контролер конфігурації
• Контролер змін
• Методами, які повинні бути використані, щоб одержати допуск і контролювати проектні
операції
• Метриками, які повинні бути зібрані при реалізації проекту, і аналізом, що повинен бути
виконаний з ними
Шаблон статуту проекту:
Управління проектом (закінчення)
Цей розділ також визначає методи й політики, використовувані для контролю границь проекту,
управління емісіями й управління змінами й конфігуруванням.
Також у рамках розділу повинен бути представлений план проектних комунікацій - методи,
синхронізація, спостерігачі й т.д. у проектних комунікаціях (інструменти які повинні
використовуватися, методи одержання результату, адресати, колекція проектної інформації й
реакцій на неї й архівація робочих паперів проекту).
Шаблон статуту проекту:
Дії по управлінню якістю
Дії по управлінню якістю пов'язані як із процесами управління проектом, так і з результатами
проекту.
Потрібен список усіх оглядів по якості й тестах якості, використовуваним у проекті, включаючи права
власності, наближені план-графіки й зусилля.
Наприклад, має бути присутнім огляд проектного плану, конструкційні огляди, випробування пристроїв,
випробування систем, прийомні випробування. Для цього повинен бути складений і спланований
список всіх об'єднаних споживчо-клієнтських оглядів.
Шаблон статуту проекту:
Дії по управлінню якістю
Включіть наради для підготовки оглядів по результатах тестів приймання й перевірку відповідності
вимогам.
На цьому етапі проекту специфічні огляди, пов'язані із продуктами, і процеси (конструкційні огляди,
системні тести й т.п.) можуть бути ще не відомі. Проте, опис очікуваних типів оглядів і рівнів
залучення різних зацікавлених сторін і членів команди повинен бути тут представлений.
Шаблон статуту проекту:
Графік проекту
Діаграма Гантта для робіт, ресурсів і пов'язаних з ними відповідальних виконавців.
Методологія управління проектами, прийнята в компанії, й/або Методологія управління життєвим
циклом систем може вплинути на побудову діаграми Гантта (включаючи відповідну декомпозицію
робіт).
Графік проекту повинен враховувати критичні залежності між проектними групами.
Рекомендується використовувати спеціальні програмні інструменти проектного менеджменту для
розробки графіка проекту й моніторингу його реалізації відповідно до графіка.
Шаблон статуту проекту:
Оцінка трудомісткості проекту
Цей розділ описує проектні зусилля в людино-днях або людино-місяцях, оцінювані відповідно до
процедури оцінки, прийнятої в компанії. Зусилля повинні бути декомпоновані на етапи й фази
проекту.
Включається інформація, використовувана для оцінювання зусиль (припущення, історичні дані,
використовувані для одержання оцінок і т.п.).
Шаблон статуту проекту:
Оцінка вартості проекту
Цей розділ визначає вартість проекту, оцінювану відповідно до процедури, прийнятої в компанії.
Вартість повинна бути класифікована (праця, обладнання, офісний простір тощо) і декомпонована
на етапи й фази проекту.
Додатково, політика й методи постачання/поставок, використовувані в проекті, повинні бути
деталізовані (хто відповідає за рішення про закупівлі й розробку й управління рахунками
замовлень, платіжними дорученнями й т.п. і як все це управляється).
Включається інформація, використовувана для одержання оцінок вартості (допущення, джерела
вартісної інформації, історія вартостей, використовувані для оцінки).
Статут необхідний будь-якому проекту
Він формує зміст зобов'язань менеджера проекту, зміст володіння проектом його спонсором, зміст
колективної роботи команди проекту.
Статут проекту охоронить від конфліктів у майбутньому із приводу того, хто бере участь у проекті й, чи
повинен залучатися певний співробітник у команду розробки проекту.
У цілому статут дозволить швидше досягти мети проекту.
Приклад статуту проекту
Проект: Відновлення операційних систем до ХР і до серверів 2000
Спонсор проекту: Піскун Максим, провідний інженер з ІТ (к. 233)
Менеджер проекту: Михайло Шварговський, мережний адміністратор (к. 234)
Команда проекту: Едуард Басов, Анна Берінгер, Марина Бабич, Ксенія Фролова, Шарлота Харченко,
Дмитро Батіг, Катерина Манько, Михайло Сивкович, Марко Терновий, Степан Удовенко
Приклад статуту проекту (продовження)
Мета проекту: Всі настільні системи оновлюються до Windows XP до 3 грудня 2010 р.
Всі сервери обновляються й переносяться на п'ять серверів Windows 2000 Servers до 20 грудня
наступного року.
Приклад статуту проекту (продовження)
Бізнес-Умови: Windows 95 використовувалася компанією п'ять останніх років. Персонал полюбив і
вивчив цю систему, але настав час іти далі. Ми збираємося впровадити нові технології Microsoft,
подібні Windows 95, але переважаючі по своїх можливостях - тобто системи Windows XP. Ця
операційна система дозволить підвищити продуктивність праці, забезпечить більшу мобільність,
підсилить захист і спростить обслуговування. Крім того, у ХР реалізовані нові технології, такі як
інфрачервоний мережний доступ, які допоможуть впровадити складську систему для готової
продукції й нове фінансове ПЗ, розгортання його намічене на кінець року. Зрозуміло, компанія
продовжить присутність в Інтернеті й проведення інтерактивної торгівлі. У цій області системи ХР
мають прекрасні можливості для всіх нас.
Приклад статуту проекту (продовження)
Як відзначалося в останній рік, сервери компанії застаріли, стали повільними за сучасними мірками. Ми
замінимо сервери шістьома новими багатопроцесорними серверами з достатньою кількістю
пам'яті, дисків RAID, а також швидкими й надійними стрічковими масивами, що означає швидку,
безперебійну й продуктивну роботу всіх співробітників компанії.
Для розгортання на всіх наших серверах обрана операційна система Windows 2000 Advanced Server, що
надасть користувачам швидкий пошук ресурсів, підвищить час безперебійної роботи мережі та її
безпеку.
Приклад статуту проекту (продовження)
Результати проекту:
• Грудень Завершення розгортання систем ХР. Установка нових серверів 2000 і створення
інфраструктури. Перетворення існуючих серверів в Windows 2000. Проект
завершується 20 грудня наступного року.
Дякую за увагу!
Тема: Управління процесом виконання проекту
• функціональний;
• динамічний;
• предметний;
• процесний.
Функціональний підхід
Досягнення цілей проекту здійснюється через функції управління.
Функція управління у застосуванні до управління проектом означає діяльність команди проекту по
управлінню проектом.
Реалізація кожної функції забезпечується відповідним управлінським підрозділом, який є структурним
елементом системи управління проектом.
Цей підхід найбільш універсальний, передбачає розгляд таких основних функцій управлінської
діяльності:
• планування,
• організація,
• координація,
• активізація,
• контроль.
Динамічний підхід
передбачає розгляд у часі всіх процесів, пов'язаних з основною діяльністю по виконанню проекту;
дозволяє визначити конкретний зміст функцій на кожному етапі здійснення проекту.
Цей підхід пов'язаний з логікою розвитку робіт і визначає так зване спеціальне управління реалізації
проекту, яке включає
• аналіз проблеми,
• експлуатацію і демонтаж.
Предметний підхід
визначає об'єкти проекту, на які направлене управління.
Наприклад, підготовка приміщення для розміщення ІТ-служби, серверної, розробка ПЗ, впровадження
системи тощо.
1. Декомпозиція функцій в управлінні проектами
З метою декомпозиції функцій використовується і такий аспект, як рівень діяльності.
Виділяються два види такого розділення: організаційний рівень і масштаби діяльності по управлінню.
• Ітеративність фаз
Змінено (основне)
• Планування змісту
•
• PMBOK4 запропонував ітеративне ведення проектів
Порівняння PMBOK й ітеративної методики Agile
• Інтерв'ю
• Фокус-групи по компетенції
• Опитувальники
• Прототипи
• вимоги до якості;
• Замовник (споживач) проекту (Project Customer) – особа усередині або поза організацією,
що буде використовувати результати проекту
Діючі особи проекту
(виконавці)
• Функціональний лідер проекту об'єднує зусилля учасників проекту в рамках функції або
підрозділу. Саме з ним взаємодіє менеджер проекту.
• Лідер пакета робіт об'єднує зусилля окремих осіб у рамках пакета робіт.
Трикутник компромісів
• гнучкість і пристосовність;
• організованість і дисципліна;
•
Галузі знань PMBOK
Управління проектами виконується за допомогою застосування й інтеграції логічно згрупованих 42
процесів управління проектами, об'єднаних в 5 груп процесів:
• ініціація;
• планування;
• виконання;
• моніторинг і управління;
• завершення.
До управління проектами, як правило, входить:
• визначення вимог;
– зміст;
– якість;
– розклад;
– бюджет;
– ресурси; і
– ризики.
Групи процесів управління проектами
Визначає й уточнює цілі й планує дії, необхідні для досягнення цілей і змісту, заради яких був початий
проект.
У групу процесів планування входять такі процеси:
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. Планування закупівель
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-маніфест розробки ПЗ
Ми постійно відкриваємо для себе досконаліші методи розробки програмного забезпечення, займаючись
розробкою безпосередньо та допомагаючи у цьому іншим.
Завдяки цій роботі ми змогли зрозуміти, що:
• Працюючий продукт слід випускати якомога частіше, з періодичністю від пари тижнів до
пари місяців.
• Щоб робота була виконана, створіть їм умови, надайте підтримку і повністю на них
покладіться.
• об’єднання людей, що спільно реалізують програму або ціль і діють на основі певних правил та
процедур.
Поняття організації зазвичай співставляється з поняттями структури, системи та управління.
Організація системи управління проектом це сукупність дій, які дозволяють об’єднати в одне ціле
всі складові частини проекту, включно з усіма зацікавленими сторонами, для успішної взаємодії
по досягненню цілей проекту.
• а також згідно з розподілом функцій, етапів і конкретних робочих процедур між учасниками
проекту (будівництво, фінансування, ліцензійні заходи, монтаж, налагодження, запуск та
експлуатація устаткування тощо).
Класифікація організаційних форм УП
• Основна система,
• Менеджером проекту (агентом замовника) може бути співробітник практично будь-якої фірми -
учасниці проекту (замовника, включно) або консультативної фірми.
Обов’язки між учасниками проекту за “основної системи” розподіляються так:
Замовник: визначає масштаби проекту, укладає контракти з менеджером проекту та іншими учасниками
і несе відповідальність по цих контрактах, керує процесом взаємодії між усіма учасниками.
Менеджер проекту:
• Недоліки: ризик за долю проекту повністю лягає на замовника. Крім того немає впевненості в
стабільності “граничних” витрат по проекту, тому він вимушений повністю покладатись на
компетентність менеджера проекту.
“системи розширеного управління” передбачають встановлення фіксованої ціни
Загальна схема розподілу відповідальності:
Замовник - відповідає за визначення масштабів та параметрів проекту, укладає контракт з
менеджером проекту, який повинен забезпечити спорудження об’єкта, у більшості випадків, “під
ключ”.
Фахівці розглядають такі організаційні форми як своєрідні “спільні підприємства” до складу яких
входять всі учасники проекту за виключенням замовника.
Менеджер проекту забезпечує управління та координацію процесів проектування та будівництва у
відповідності з угодою між учасниками проекту у межах фіксованої (кошторисної) ціни.
Менеджером може бути представник підрядної організації або консалтингової фірми (іноді
інжинірингові), який управляє проектом, координує поставки та роботи з інжинірингу. Ризик
покладається на підрядчика.
Система прискореного будівництва
• Провідні учасники проекту - замовник і підрядчик (крім них можуть бути й інші учасники),
створюють свої власні групи, які очолюють менеджери проекту, власне від замовника та
підрядчика. Ці менеджери підпорядковуються єдиному менеджеру проекту, яким може бути один
з них, в залежності від організаційної форми реалізації проекту.
• Для управління проектом створюється єдина група на чолі з менеджером проекту. В групу
входять повноважні представники всіх учасників проекту. Всередині кожної фірми-учасниці може
створюватись своя група контролю за ходом проекту.
Логіку взаємодії учасників проекту всередині такої групи відображає її організаційна структура.
Існує кілька типів організаційних структур, які широко застосовують в управлінні проектами:
• проектна,
• матрична,
• персонал робочої групи виділяється для участі в проекті на повний робочий день.
Принцип робочої групи найприйнятніший тоді, коли масштаби проекту і тривалість його
виконання такі, що персонал може бути зайнятим у проекті протягом усього робочого дня і
коли, в ідеальному варіанті він може розташовуватись в одному місці.
У випадку проектної структури
У цілому робоча група проекту - це підрозділ, створений для того, щоб розподіляти робочі завдання
у відповідності з вказівками менеджера проекту, а також технічними умовами та процедурами
проекту.
Принцип робочої групи не обов’язково гарантує найбільш ефективну діяльність по УП. Однак, зазвичай,
він робить проект більш економічним, оскільки забезпечується найкраще співвідношення між
строками, витратами та обсягами робіт, а також якість їх виконання.
Проектні структури
• Якщо для будь-якого виду діяльності необхідно більше семи виконавців, то слід розподілити її на
роботу, пов’язану з керівництвом і на кілька підпорядкованих робіт.
• Коло обов’язків будь-якого керівника слід обмежувати керівництвом не більше ніж сімома
роботами.
При побудові оргструктури
слід керуватись логікою “здорового глузду”, якщо будь-яка з рекомендацій не відповідає конкретним
умовам.
Управління й організація відносяться до сфери практичної діяльності людей, а не до вправ з
абстрактної логіки. Тому слід враховувати причини суто суб’єктивні. Наприклад, те, чому віддає
перевагу замовник або виконавець, недоліки розробників, конфліктні ситуації та інше, що
може спричинити відхилення від рекомендацій.
5. Функції провідних фахівців робочої групи УП
У процесі вибору та призначення персоналу проекту необхідно враховувати такі чинники як наявність
необхідних фахівців, їх кваліфікацію, досвід та особисті якості, здатність працювати у складі групи
і забезпечувати досягнення поставленої мети.
Якщо організації-учасники проекту створюють свої групи по УП, всі вони, зазвичай мають подібну
оргструктуру. Кожна робоча група формується у відповідності з потребами проекту, з урахуванням
кваліфікації та досвіду персоналу, що працює над проектом.
Величина робочої групи залежить від масштабів і типу проекту
• використовує персонал контролю проекту для планування обсягів і термінів робіт, отримання
оцінок і контролю затрат,
•У випадку
відповідає за всю роботу над проектом.
малих проектів він є також координатором проекту або керує кількома проектами одночасно.
У випадку великих проектів йому допомагає координатор робіт по проекту.
Інженер-координатор проекту -
відповідає за координацію робіт по проекту на усіх його стадіях, включаючи проектування, закупівлю
обладнання та матеріалів, будівництво та введення об’єктів в експлуатацію.
Його основні обов’язки:
• визначає обсяги робіт і терміни їх виконання, встановлює взаємозв’язки між елементами проекту,
забезпечує планування,
• забезпечує необхідну якість робіт, у тому числі слідкує за тим, щоб різні напрямки проектування та
інженерного забезпечення відповідали б нормативам та обмеженням проекту, контролює виконання
робіт у відповідності з вимогами самого проекту та замовника щодо економічних показників, ТУ та
державних стандартів,
Менеджер служби МТЗ проекту відповідає за своєчасну доставку обладнання і матеріалів тощо.
Менеджер будівництва (іноді його називають менеджером на місці ведення будівельно-монтажних
робіт) відповідає за всі види робіт, які виконуються на будівельному майданчику. Іноді
вважається, що це основна управлінська посада при роботі над проектом.
Менеджер будівництва має власний персонал, який вирішує питання трудових відносин між
адміністрацією та профспілками, техніки безпеки, встановлення зв’язків з організаціями та
окремими особами, а також свою власну виробничу підгрупу, яка займається інженерним
забезпеченням робіт, веденням господарських справ та ін.
Управління командою
передбачає лідерство в її створенні, налагодження її роботи, дослідження групової динаміки.
Лідерство — це здатність мобілізувати потенційні психологічні потреби послідовників (підлеглих) і
спиратися на них в момент гострого суперництва чи конфлікту.
Лідерство — це стосунки, які виникають в ході взаємного стимулювання і підтримки, завдяки чому
стимули людей перетворюються в їх участь, що дає конкретні результати.
Процес лідерства оснований на взаємозалежності: лідери відкривають потенційні можливості тих, кого
ведуть за собою.
Команда проекту
За формою команда проекту відображає існуючу організаційну структуру управління проектом,
розділення функцій, обов'язків і відповідальності за рішення, що приймаються в процесі його
реалізації.
На верхньому рівні структури знаходиться менеджер проекту, а на нижніх виконавці, відділи і
фахівці, що відповідають за окремі функціональні сфери.
Команда проекту
За змістом команда проекту являє собою групу фахівців високої кваліфікації, що володіють
знаннями і навичками, необхідними для ефективного досягнення цілей проекту.
Команда проекту
Основним інтегруючим чинником створення і діяльності команди виступає стратегічна мета реалізація
проекту.
У процесі досягнення цілей проекту команда набуває своїх меж, використовує організаційні можливості
учасників і ресурси проекту.
Команда проекту виступає як соціальний організм, що має свій початок, здійснює процес
життєдіяльності (управління проектом) і завершує своє існування розформуванням або
трансформацією в іншу управлінську команду.
Команда проекту
З одного боку, команда проекту впливає на створення певного організаційного середовища проекту,
формуючи цінності, принципи і норми поведінки персоналу.
З іншого боку, діє в ній, підкоряючись єдиній меті та філософії управління проектом.
Команда проекту
Якщо команда починається з лідера, то управління командою — з його знань і навичок організовувати
роботу команди. За результатами опитування 20 тисяч вищих і середніх менеджерів США, до числа
топ-десятки якостей лідера були віднесені:
- етичність;
- вміння працювати в команді;
- чесність;
- цікавість до всього;
- працелюбність;
- розум;
- цілеспрямованість.
Команда проекту
Реалізація проекту тривале підприємство, що має підвищену частку ризику і схильне до постійних змін.
Тому особливою характеристикою команди проекту є підприємницький характер її діяльності,
направлений на розв’язання слабоструктурованих задач і швидке реагування на вимоги
зовнішнього середовища і умови реалізації проекту, що змінюються.
Команда проекту
Командна кооперація персоналу дозволяє збільшити продуктивність управлінської праці на 70-80%
Командоутворення
Процес формування команди проекту (командоутворення) звичайно розглядають як утворення єдиного,
цілісного колективу управлінців, здатного ефективно досягати мети проекту.
Значення командної роботи по реалізації проекту укладається в можливості синергічного ефекту від
об'єднання групових зусиль, знань і вироблення групових управлінських рішень, тобто в
досягненні «стану, при якому ціле більше, ніж сума його складових частин». Така кооперація в
роботі персоналу значно ефективніша, ніж конкуренція.
Основні етапи командоутворення
• формування,
• спрацьовуванння,
• функціонування,
• реорганізація,
• розформування.
Особливості управління командою на стадії Формування
Особливості роботи в проекті полягають в тому, що фахівці команди не знають один одного, ніколи не
працювали разом, не є єдиним колективом з встановленими механізмами взаємодії, груповими
установками.
Для їх ефективної спільної діяльності необхідний певний період, коли вони визначають відносини,
пристосовуються до умов роботи в команді, усвідомлюють себе єдиним цілим.
На цій стадії відбувається знайомство членів команди один з одним і з проектом загалом, формуються
загальні цілі і цінності, визначаються норми і правила взаємодії, ставляться задачі команди і
визначаються шляхи і принципи їх досягнення.
Особливості управління командою на стадії Спрацьовування (психологічної напруженості)
Це період початку спільної роботи, розвитку згуртованості групи, що вирішує колективну задачу.
Він характеризується підвищеним рівнем конфліктності, викликаним відмінністю в характерах
фахівців, підходах, стилях і методах розв'язання проблем.
Всередині команди йде процес виявлення лідерів, формування неформальних груп, визначаються
ролі окремих працівників і їх місце в команді, встановлюється психологічний клімат в колективі,
його внутрішня культура, що визначає стиль роботи і управління, спосіб взаємодії членів
команди.
Особливості управління командою на стадії Робоча (нормального функціонування)
Найбільш тривала стадія. На основі сформованого командного почуття йде нормальний
продуктивний процес роботи.
Деталі взаємодії уточнюються по ходу виконання задач, спілкування в різних ділових ситуаціях.
Стадія характеризується максимальним розкриттям індивідуальних творчих здібностей, члени
команди вчаться розуміти і враховувати потреби і інтереси один одного.
Конфлікти і суперечки в основному виникають з причин, пов'язаних з проектною діяльністю, і
мають конструктивний характер.
Особливості управління командою на стадії Робоча (нормального функціонування) (закінчення)
Задачею менеджера проекту на цій стадії є:
• підтримка в команді атмосфери довіри і взаємовиручки, єдності в розумінні цілей і задач проекту і
способів їх досягнення;
• Це знижує контроль.
Переваги делегування повноважень:
• делегування дозволить вам зосередитися на тих аспектах роботи, які вимагають вашого особистого
досвіду, знань і кваліфікації;
• Процеси планування
• Календарне планування
• Ресурсне планування
1. Необхідність і особливості планування в управлінні проектами
Сутність планування
Планування є найважливішим процесом управління проектом, що визначає у часі всю діяльність по
його здійсненню.
Планування - це безперервний процес визначення найкращого способу дій для досягнення
поставлених цілей з урахуванням обстановки, що склалася.
В управлінні проектами планування займає основне місце, втілюючи в собі організаційні засади
всього процесу реалізації проекту.
• управління вартістю;
• управління часом;
• управління якістю;
• управління комунікаціями;
• управління ризиками;
• управління інтеграцією.
2. Принципи планування в проекті
При всьому різноманітті проектів існують загальні підходи і принципи планування в проектах, що
зумовлені типовою діяльністю по управлінню проектами, яка направлена на безперервне
вирішення таких загальних питань:
• Що необхідно робити?
• Що і скільки коштує?
• Що і коли повинно бути сплачено? Які це кошти і звідки вони надходять?
• концептуальний;
• стратегічний;
• поточний;
• оперативний.
• План управління змістом проекту (Scope Management Plan) - документ, що описує, як буде
визначатися, розроблятися й перевірятися зміст проекту та ієрархічна структура робіт, а
також як здійснювати управління змістом проекту.
• План управління вартістю (Cost Management Plan) — документ, що задає формат і визначає
операції й критерії для планування, структурування й управління вартістю проекту.
- процес визначення й документування потреб зацікавлених сторін проекту для досягнення цілей
проекту.
Приклад №1
Типова структура плану проекту по створенню виробничого об’єкта включає:
• Функціональний план.
• Аналіз чинників виконання проекту.
• матеріали обстеження;
• Шифр проекту
• Назва проекту
• Автор документу
• Дата створення
• № версії
Приклад № 3
Шаблон плану управління проектом (продовження)
Ієрархічна структура робіт проекту
<Подайте в графічному чи табличному вигляді ієрархічну структуру робіт проекту з потрібним
ступенем деталізації>
Віхи проекту
<Складіть список контрольних точок проекту. Список контрольних точок визначає ключові події
проекту, їхні дати й результати, які повинні бути отримані за станом на ці дати >
Календарний план проекту
<Складіть план-графік робіт проекту, що описує всі контрольні точки й роботи із призначеними
датами початку й закінчення, а так само взаємозв’язку завдань>
Приклад № 3
Шаблон плану управління проектом (продовження)
Вартісний план проекту
<Вартісний план являє собою розподілений за часом бюджет, по якому провадиться контроль
використання коштів проекту>
План якості проекту
<План якості проекту визначає параметри й критерії досягнення якості проекту, щодо яких буде
проводитися контроль якості отриманих результатів>
Приклад № 3
Шаблон плану управління проектом (продовження)
Ресурсний план проекту
<Перелічіть всіх співробітників (як внутрішніх, так і зовнішніх), які будуть задіяні в проекті, із
вказівкою строків їхньої зайнятості й відсотка завантаження>
План управління командою проекту Організаційна структура проекту
<Подайте організаційну структуру проекту в графічному вигляді>
Приклад № 3
Шаблон плану управління проектом (продовження)
Матриця відповідальності
<Матриця відповідальності встановлює відповідальність ролей проекту відносно виконання основних
або типових робіт>
План управління комунікаціями проекту
<План управління комунікаціями відображає вимоги до комунікацій з боку учасників проекту>
Реєстр ризиків проекту
<Ідентифіковані ризики проекту містять у собі можливі невизначені події, які можуть виникнути в
проекті й викликати наслідки, які спричинять небажані ефекти>
Приклад № 3
Шаблон плану управління проектом (продовження)
План управління ризиками проекту
<Опишіть правила й періодичність перегляду реєстру ризиків проекту>
План управління контрактами й постачаннями
<Перелічіть всі контракти, які повинні бути укладені для здійснення поставок або робіт із проекту,
указавши строки, у які ці поставки або роботи повинні бути виконані>
План комунікацій проекту
Приклад № 3
Шаблон плану управління проектом (закінчення)
План управління змінами
<План управління змінами містить у собі порядок управління змінами в проекті й розробляється на
підставі процедури внесення змін
ЗАТВЕРДЖЕНО:
Посада Дата Підпис
ПОГОДЖЕНО:
Посада Дата Підпис
Календарне і ресурсне планування
• Календарне планування
• Ресурсне планування
•
1. Календарне планування
Центральне місце у плануванні проекту займають задачі календарного планування - складання і
коригування розкладу, в якому роботи, виконані різними організаціями, ув'язуються в часі між
собою і з можливостями їх забезпечення різними видами матеріально-технічних ресурсів.
При ув'язці повинно бути забезпечено дотримання заданих обмежень (строки пакетів робіт, обсяги
ресурсів, фінансування та ін.), оптимальне (за прийнятим критерієм) розподілення ресурсів.
• перспективні графіки;
• логічні сіті;
• графіки;
•У ходідіаграми і т.д.
реалізації проекту застосовуються різні
типи календарних планів:
У свою чергу, функціональні календарні плани робіт поділяються (ФКПР):
За типами робіт:
• ФКПР проектування;
• ФКПР МТС;
• ФКПР будівництво;
• ФКПР також можуть бути складені: на окремі черги, підсистеми, комплекси великого проекту, які
в цьому випадку розглядаються як мініпроекти.
Призначення календарного плану варіюється в залежності від рівня управління, на якому він
використовується:
керівник вищої ланки - для контролю термінів досягнення основних корпоративних цілей;
функціональні керівники - для контролю виконання функціональних календарних планів робіт;
менеджер проекту - для контролю виконання основних етапів календарних планів і рівня готовності
проектних вузлів.
Кожна робота в календарному плані характеризується:
• відповідальним виконавцем.
Кожна робота в календарному плані характеризується:
При аналізі календарних планів визначають також резерв часу (величина можливого відхилення
тривалості для кожної роботи, яка не вплине на завершення проекту вчасно).
У більшості складних календарних планів існує до 6 варіантів моментів початку, закінчення, тривалості
робіт і резерву часу.
Це - ранні, пізні, базові, планові і фактичні дати, резерв часу.
У повній системі календарного планування використовують до 15 дат і моментів часу, що визначають
роботу:
Процес складання календарного плану полягає у визначенні значень зазначених на попередньому слайді
дат і моментів часу.
Планові дати вибираються між ранніми і пізніми датами виконання робіт.
Однак, дата, яка планується для роботи перед початком виконання проекту, може відрізнятися від дати
поточного плану.
Дуже важливо зареєструвати первинний план, тому що він є базою, відносно якої надалі здійснюється
контроль за часом.
Ця дата називається базовою датою, а дата поточного плану - поточною плановою датою.
При призначенні базових або поточних планових дат необхідно також враховувати ресурсні
обмеження.
Методи розрахунку сітьових моделей дозволяють обчислювати тільки ранні та пізні дати.
Базові і поточні планові дати необхідно вибирати з урахуванням інших факторів.
Існують три варіанти вибору:
• календарний план по пізніх закінченнях (жорстко справа): використовується для подання ходу
виконання проекту у кращому вигляді для споживача;
• календарний план між ними: робиться або для згладжування використовуваних ресурсів або для
показу замовнику найбільш вірогідного закінчення.
Визначення тривалості роботи
Тривалість роботи - це головний параметр планування на основі якого розраховуються початок і
закінчення роботи.
У загальному вигляді тривалість роботи залежить від сумарної трудомісткості кожного елементу
роботи, і числа працюючих, які можуть її виконати
• Як правило, втрати часу (свята, хвороби, навчання і т.п. складають до 30% від загального робочого
часу.
Слід враховувати також, що деякі співробітники можуть працювати над проектом неповний день.
Тому загальна їх кількість повинна розраховуватися виходячи з числа працюючих повний день. (При
коригуванні тривалості необхідно точно знати, враховані вони чи ні при обліку втраченого часу,
тобто до того, як збільшити тривалість на 40%).
Тривалість деяких робіт залежить від часу очікування пакету робіт або постачання матеріалів, яке не
залежить від числа працівників, що виконують роботу, від додаткової інформації або від очікування
здійснення якихось змін.
У цих випадках вірогідна тривалість роботи може бути отримана на основі попереднього досвіду або на
базі оперативних і статистичних даних реалізації аналогічних проектів.
При оцінці тривалості необхідно враховувати також логічний взаємозв'язок робіт.
• За обмеження у часі
• За обмежених ресурсів
1. Ресурсне планування за обмеження у часі
передбачає жорсткі обмеження на терміни завершення робіт і призначення на проект додаткових
ресурсів на періоди перевантаження.
Такий підхід ще називають методом “Згладжування”, за якого потрібно оптимізувати деякий показник
якості використання ресурсів, наприклад, мінімум перевищення необхідних ресурсів над заданим
рівнем їхньої наявності.
2. Планування за обмежених ресурсів
передбачає, що початково задана кількість доступних ресурсів не може бути змінена і є основним
обмеженням проекту.
За даного підходу наявна кількість ресурсу є незмінною, а розв’язання конфліктних ситуацій
здійснюється за рахунок зміни дати закінчення робіт.
Такий підхід ще називають методом “Калібрування”. Цей алгоритм мінімізує терміни виконання
комплексу робіт при заданих обмеженнях на ресурси.
Ідея цього методу: на черговий відрізок часу (зміна, тиждень) ставляться на обслуговування і
забезпечуються необхідними ресурсами роботи відповідно до прийнятого пріоритету, якщо
виявляється, що в даному періоді ресурсів для виконання деяких робіт не вистачає, то початок
виконання цих робіт відтерміновується.
Сучасним методом, який при розробці календарного плану враховує не лише часові, а й ресурсні
обмеження проекту, є метод критичних ланцюжків (ССРМ - Critical Chain Project
Management).
Метод критичних ланцюжків — це підхід до вирішення невизначеностей у будь-якому проекті і є
поширенням теорії обмежень (TOC - Theory of Constraints) на сферу управління проектами.
Розроблений ізраїльським вченим Еліяху Голдраттом, метод критичних ланцюжків передбачає ескалацію
управління ризиками з рівня операції (роботи) до рівня всього проекту, тобто від виконавців до
менеджера проекту.
Теорія обмежень містить два основні положення:
1. У будь-якій системі, в будь-якій організації поліпшення роботи кожної окремо узятої підсистеми не
забезпечить хорошої роботи всієї системи в цілому.
2. Для того, щоб поліпшити роботу всієї системи, необхідно поліпшити роботу найслабкішої ланки,
те, що ми називаємо «обмеженням» системи, яким би незначним воно не здавалося.
Стосовно управління проектами теорія обмежень була адаптована в середині 90-х рр., коли з’явилося
поняття «критичного ланцюжка».
Отже, в основі теорії обмежень лежить розуміння того, що оптимальний стан системи не завжди
визначається оптимальним станом всіх її підсистем.
Тому перед початком роботи з великими системами в різних організаціях, зокрема з системою
управління проектами, перш за все слід визначити головне обмеження системи.
Потрібний дуже ретельний аналіз, щоб знайти найслабкішу ланку з урахуванням специфіки роботи
організації, після чого з’являється шанс удосконалити всю систему.
Проект також є єдиною системою і страждає через те, що оптимальність досягається не в цілому, а лише
для окремих складових.
Наприклад, виконавці проекту часто завищують час, необхідний для виконання завдань, що їм доручено,
щоб гарантовано вкластися в строк.
Проте це істотно знижує вірогідність завершити вчасно проект в цілому.
В управлінні проектами існує три групи проблем:
1) статистичні;
2) поведінкові;
3) управлінські.
• коректний розподіл часу цього ресурсу і планування всіх проектів, виходячи з його
доступності.
Алгоритм методу критичних ланцюжків (ССРМ) містить певну послідовність кроків:
1. У розробленому розкладі проекту виділяється критичний ланцюжок робіт по методу критичного
шляху.
2. Знайдений критичний ланцюжок робіт модифікується з урахуванням доступності і наявності
ресурсів.
3. Зменшення тривалості робіт, представлених менеджерові проекту виконавцями, на одну третину.
Величина, на яку зменшується тривалість робіт, науково не обґрунтована і має емпіричний
характер.
4. Створення розкладу з урахуванням «вирізаної» тривалості робіт і формування нового
критичного шляху критичного ланцюжка (рис. наступний слайд).
Алгоритм методу критичних ланцюжків (ССРМ) містить певну послідовність кроків: (закінчення)
5. Формування буфера проекту з буферів робіт критичного ланцюжка і окремих часткових буферів
— буферів некритичних робіт. Принцип формування буферів передбачає наявність у проекті
кількох ланцюжків робіт, які можуть виконуватися паралельно, а також об’єднуватися разом.
Визначення розміру буфера базується виключно на припущеннях і особистому досвіді менеджера
проекту.
6. Управління буферами. При подальшому контролі проекту менеджер здійснює моніторинг
витрачання буфера. Залежно від ступеня витрачання буфера менеджер ухвалює різні управлінські
рішення, приділяючи максимум уваги роботам, що належать ланцюжку з найвищою швидкістю
витрачання буфера.
Створення критичного ланцюжка робіт
• часову,
• ресурсну,
• економіко-фінансову.
Сутність кожної оцінки реалізованості проекту така:
• логічна — це урахування логічних обмежень на можливий порядок виконання робіт у часі згідно з
особливостями проекту та його предметної області;
Дякую за увагу!
Тема: Методи планування проекту
• Сітьові моделі
1. Розвиток методів планування
Спочатку використовувалися досить прості засоби і методи:
лінійні діаграми;
таблиці трудових витрат,
таблиці витрат ресурсів, у яких зазначені терміни підготовки робочої документації, початок
експлуатації, терміни по інших етапах і ресурси, необхідні для їх здійснення;
таблиці обладнання, що містять дані про типи обладнання, терміни постачання;
фінансові таблиці, що відображають витрати і прибутки.
Потім почали використовувати методи дослідження операцій, сітьові методи, наприклад метод
критичного шляху.
Методи сітьового планування
Основна мета - скорочення до мінімуму тривалості проекту.
Базуються на методах, розроблених практично одночасно й незалежно:
метод критичного шляху (МКШ) (англ. – Critical Path Method - CPM) і
метод оцінки та перегляду планів (ПЕРТ) (англ. – Program Evaluation and Review Technique - PERT).
Метод критичного шляху (МКШ) краще використовувати тоді, коли операції проекту мають визначену
тривалість,
Метод ПЕРТ більш ефективний
якщо оцінки тривалості мають ймовірнісний характер.
Загальна умова - для реалізації події повинні бути завершені усі попередні операції.
Сітьова діаграма (сіть, граф сіті, PERT-діаграма)
– графічне відображення робіт проекту і залежностей між ними.
2. Сітьові моделі
Сітьове планування - це побудова сітьового графіка та обчислення його параметрів
Для побудови сітьового графіка потрібно мати:
• список робіт
• сіті "вершини-події";
• Прийняття рішень
1. Сутність та види контролю в управлінні проектами
Контроль -
це процес у якому керівник проекту встановлює чи досягаються поставлені цілі, виявляє причини,
які дестабілізують хід роботи і обґрунтовує прийняття управлінських рішень, що коригують
виконання робіт по проекту, перш ніж будуть завдані збитки проекту.
Мета контролю -
забезпечення виконання планових показників і підвищення загальної ефективності функцій
планування та контролю проекту.
Основні задачі контролю:
• їх зіставлення з плановими;
• виявлення відхилень.
Для розв’язання цих задач контроль повинен забезпечити:
• Виявлення відхилень від цілей реалізації проекту за допомогою ряду критеріїв і обмежень,
які фіксуються в календарних планах, бюджетах і ін. документації.
- факти і події,
- прогнозування наслідків.
За часовою ознакою та метою проведення розрізняють три види контролю:
1 - попередній,
2 - поточний,
3 – заключний.
Попередній контроль
здійснюється до фактичного початку виконання робіт і направлений на дотримання певних правил і
процедур, здебільшого він стосується ресурсного забезпечення робіт.
Поточний контроль
здійснюється при реалізації проекту, він включає контроль часових характеристик, контроль
досягнення проміжних цілей проекту, контроль виконання заданих обсягів робіт, контроль
бюджету, контроль ресурсів, контроль якості.
Основна мета - оперативне регулювання ходу реалізації проекту.
Такий підхід базується на порівнянні досягнутих результатів з встановленими в плані проекту
вартісними, часовими, ресурсними характеристиками.
Заключний контроль
проводиться на стадії завершення проекту з метою інтегральної оцінки реалізації проекту.
Основне призначення - узагальнення отриманого досвіду для подальшої розробки й реалізації
проектів-аналогів і з метою вдосконалення процедур управління.
Іноді контроль ототожнюють з оцінкою.
Між контролем і оцінкою існує тісний зв’язок.
Оцінка так само, як і контроль, є важливою функцією зворотного зв'язку однак вона базується на
попередньому підведенні проміжних підсумків і оцінюванні загальної картини і зазвичай
проводиться особою або групою осіб, які не працюють безпосередньо над проектом.
Контроль передбачає постійне стеження за просуванням проекту, він сфокусований на деталях
проекту.
За контрольні дії несе відповідальність керівник проекту.
Процеси контролю проекту поділяються на основні і допоміжні
Основні:
• ведення звітності по проекту - збір і передача звітної інформації про хід реалізації проекту,
включаючи звіти про виконані роботи, про виконання планових показників, прогноз з
урахуванням результатів.
Допоміжні:
• час,
• обсяг робіт,
• вартість.
Крім того, керівництво відповідає за управління змістом робіт (змінами), якістю й організаційною
структурою.
Отже, для створення ефективної системи контролю необхідно:
• ретельно спланувати всі роботи, виконання яких необхідне для завершення проекту;
• організацій-виконавців,
• кошторисну вартість
• фактичні результати
• результати, що прогнозуються
• відхилення та
• точність
• своєчасність
• повнота інформації
• метод простого контролю (контроль в момент закінчення робіт), який також називають
методом "0 - 100", оскільки він відстежує тільки моменти завершення детальних робіт.
Вважається, що робота виконана тільки тоді, коли досягнуто її кінцевого результату;
• метод 50/50, в якому є можливість обліку деякого проміжного результату для незавершених
робіт. Міра завершеності роботи визначається в момент, коли на роботу витрачено 50%
бюджету;
• експертна оцінка ступеню виконання робіт і готовності проекту - виконується зазвичай для
надання інформації на вимогу когось з учасників проекту, наприклад, інвестора.
• вимірні роботи, для яких можуть визначатися дискретні прирости відповідно до графіка
виконання, завершення таких робіт має конкретні матеріальні результати. Тобто це роботи
для яких можна визначати кількісний прогрес.
• роботи впливу, які не можна розбити на дискретні заплановані прирости, роботи типу
підтримки і керівництва проектом, лобіювання у владних структурах тощо. Для таких робіт
визначають якісний прогрес.
Один із варіантів оцінки прогресу - реєстрація його по таких критеріях:
• зміст робіт.
Найголовніший показник для контролю і аналізу
терміни закінчення робіт.
Якщо були виявлені затримки в роботах критичного шляху або в досягненні ключових віх проекту, то
найімовірніше весь проект буде також затриманий на відповідний термін.
Фактична інформація використовується для складання нових графіків.
Для кожної роботи оцінюється її стан (початок, закінчення, час, що вже витрачено і час (тривалість), що
залишився), обчислюються нові тривалості для робіт, що виконуються.
Цей процес звичайно веде до необхідності коригування дати завершення проекту в цілому.
Після отримання звіту з фактичними даними отримуємо два графіки робіт: базовий графік і поточний
графік, який відображає вплив останніх фактичних даних.
Визначення стану проекту означає порівняння цих двох планів.
Виконання і витрачений час є досить інформативними показниками, оскільки часто існує суттєва
невідповідність між кількістю часу, яку проект або робота використали до поточної дати, і дійсними
результатами, ступенем завершеності роботи.
У процесі виконання проекту проводиться аналіз фактичного стану проекту, враховуючи повністю
закінчені роботи, досягнуті проміжні результати, а також такі, що піддаються вимірюванню й
оцінці ступеня завершеності роботи.
Оцінки виконаних і майбутніх обсягів робіт також можуть бути корисні для:
• Перегляд термінів.
• Припинення проекту.
1. Знайти альтернативне рішення.
Насамперед необхідно розглянути можливості, пов'язані з підвищенням ефективності робіт за рахунок
нових технологічних або організаційних рішень. Нове рішення, наприклад, може полягати в
зміні послідовності виконання ряду робіт.
2. Перегляд вартості.
Даний підхід означає збільшення обсягів робіт і призначення додаткових ресурсів.
Рішення може полягати у збільшенні навантаження на існуючі ресурси або залученні додаткових людей,
обладнання, матеріалів.
Цей підхід звичайно застосовується у разі необхідності усунення часових затримок проекту.
3. Перегляд термінів.
Даний підхід означає, що терміни виконання робіт будуть перенесені.
Керівництво проекту може піти на таке рішення у разі жорстких обмежень по вартості.
4. Перегляд змісту робіт.
Даний підхід передбачає, що обсяг робіт по проекту може бути зменшений і відповідно лише частина
запланованих результатів проекту буде досягнута, за умови, що перегляд якісних характеристик
результатів проекту не передбачається.
5. Припинення проекту.
Таке рішення приймається тоді, коли прогнозовані витрати по проекту перевищують очікувані
вигоди.
Рішення, пов'язане з припиненням проекту, крім суто економічних аспектів, пов'язане з подоланням
проблем психологічного характеру, пов'язаних з інтересами різних учасників проекту.
Дякую за увагу!
Тема: Управління змістом проекту (предметною областю
• Створення ієрархічної структури робіт (ІСР) – процес поділу результатів проекту й робіт
проекту на більш дрібні елементи, якими легше керувати.
Процеси, використовувані для управління змістом проекту, а також допоміжні інструменти й методи
розрізняються залежно від прикладної області й звичайно визначаються як частина життєвого
циклу проекту.
Схвалений докладний опис змісту проекту разом з ІСР і словником ІСР являють собою базовий план
проекту по змісту.
Далі зміст, оформлений в базовому плані, відслідковується, підтверджується й контролюється протягом
усього життєвого циклу проекту.
Здійсненню зазначених п'яти процесів управління змістом проекту, передують дії команди управління
проектом по плануванню.
Роботи із планування є частиною процесу розробки плану управління проектом (див. тему
Управління інтеграцією), у результаті якого створюється план управління змістом, що дає вказівки
щодо того, як зміст проекту буде визначатися, документуватися, підтверджуватися, управлятися й
контролюватися.
План управління змістом може бути формальним і неформальним, деталізованим, або задавати
лише загальні рамки залежно від потреб проекту.
Виконання змісту проекту порівнюється з планом управління проектом (див. тему Управління
інтеграцією).
Виконання змісту продукту порівнюється з вимогами до продукту.
Процеси управління змістом проекту повинні бути добре інтегровані із процесами інших галузей знань,
щоб роботи проекту привели до створення заданого змісту проекту.
2. Процеси, пов'язані зі змістом проекту
1.Збір вимог – процес визначення й документування потреб зацікавлених сторін проекту для досягнення
цілей проекту.
На успіх проекту прямо впливає старанність збору й управління вимогами до проекту й продукту.
• структуру відстеження, тобто які параметри вимог будуть відбиті в матриці відстеження, і
вимоги до яких інших документів проекту будуть відслідковуватися.
Збір вимог: виходи
3. Матриця відстеження вимог являє собою таблицю, що зв'язує вимоги з їхнім походженням і
відслідковує їх протягом життєвого циклу проекту.
Застосування матриці відстеження вимог допомагає впевнитися, що кожна вимога збільшує цінність
бізнесу, зв'язуючи його із цілями бізнесу й проекту. Це дозволяє відслідковувати вимоги протягом
життєвого циклу проекту, що допомагає впевнитися в тому, що вимоги, схвалені в документах по
вимогах, виконані наприкінці проекту.
Нарешті, матриця відстеження вимог забезпечує структуру для управління змінами змісту продукту.
Збір вимог: виходи
Цей процес містить у собі, не обмежуючись тільки відстеженням, такі елементи:
Визначення змісту - процес розробки докладного опису проекту й продукту. Підготовка докладного
опису змісту проекту надзвичайно важлива для успіху проекту й ґрунтується на основних
результатах, допущеннях і обмеженнях, задокументованих під час ініціації проекту.
Зміст проекту визначається під час планування й описується більш докладно в міру надходження
інформації про проект.
Існуючі ризики, допущення й обмеження аналізуються на предмет повноти; додаткові ризики,
допущення й обмеження додаються в міру необхідності.
Визначення змісту: входи, інструменти й методи, виходи
Блок-схема даних при визначенні змісту
Визначення змісту: входи
1. Статут проекту надає опис проекту високого рівня й характеристики продукту. Крім того, він містить
вимоги до схвалення проекту. Якщо виконуюча організація не використовує Статут проекту,
необхідно одержати або підготувати аналогічну інформацію, яку варто використовувати як основу
для детального опису змісту проекту.
2. Документи по вимогах Описані вище
3. Активи процесів організації Приклади активів процесів організації, які можуть впливати на процес
визначення змісту, містять у собі, серед іншого:
- правила, процедури й шаблони опису змісту проекту;
- проектні архіви з попередніх проектів;
- знання, накопичені в попередніх фазах або проектах.
Визначення змісту: інструменти й методи
1. Експертна оцінка часто використовується для аналізу інформації, необхідної для розробки опису
змісту проекту. Подібні оцінки й експертизи застосовуються у відношенні будь-яких технічних
деталей. Подібні експертизи проводяться будь-якою особою або групою осіб, що мають спеціальні
знання або підготовку, і доступні з безлічі джерел, включаючи :
- інші підрозділи в рамках організації;
- консультантів;
- зацікавлені сторони проекту, у тому числі замовники або спонсори;
- професійні й технічні асоціації;
- промислові групи;
- експерти з окремих питань.
Визначення змісту: інструменти й методи
2. Аналіз продукту може стати ефективним інструментом для проектів, результатом яких є продукт, а не
послуга або результат. У кожній прикладній області існує один або кілька загальноприйнятих
методів перекладу описів продукту високого рівня в матеріальні результати. Аналіз продукту
містить у собі методи, такі як ієрархічна розбивка продукту, системний аналіз, аналіз вимог,
системний інжиніринг, оптимізація вигоди й функціонально-вартісної аналіз.
3. Пошук альтернатив являє собою метод, використовуваний для генерації різних підходів до
здійснення й виконання робіт проекту. Може застосовуватися безліч загальних методів управління,
таких як мозковий штурм, всебічний розгляд питання, парні порівняння й т.д.
4. Семінари за участю модератора Описані раніше.
Визначення змісту: виходи
1.Опис змісту проекту містить детально розписані результати проекту й роботи, які необхідно виконати
для одержання цих результатів.
Опис змісту проекту також формулює загальне розуміння змісту проекту зацікавленими сторонами
проекту і може містити очевидні виключення проекту, що може допомогти в управлінні
очікуваннями зацікавлених сторін проекту. Це дозволяє команді проекту здійснювати більш
детальне планування, направляє роботу команди проекту під час виконання й створює базовий
план для оцінки того, чи входять запити на зміни або додаткову роботу в рамки проекту.
Ступінь і рівень деталізації, з якою опис змісту проекту визначає роботу, яку необхідно виконати, і
роботу, яку необхідно виключити, можуть визначити, наскільки добре команда управління
проектом може контролювати зміст всього проекту.
Визначення змісту: виходи
Детальний опис змісту проекту або безпосередньо, або за допомогою посилань на інші документи
містить у собі:
- Опис змісту продукту. Послідовно уточнює характеристики продукту, послуги або результату,
описаного в Статуті проекту або в документах по вимогах.
- Критерії приймання продукту. Визначає процес і критерії приймання завершених продуктів, послуг
або результатів.
- Результати проекту. Результати проекту включають як виходи, що містять продукт або послугу
проекту, так і допоміжні результати, такі як звіти й документи по управлінню проектом. Результати
можуть бути описані узагальнено або з високим ступенем деталізації.
- Виключення проекту. Як правило, визначають, що виключено із проекту. Докладний опис того, що не
входить до змісту проекту, допомагає управляти очікуваннями зацікавлених сторін проекту.
Визначення змісту: виходи
(продовження)
- Обмеження проекту. Перераховуються й описуються конкретні обмеження проекту, пов'язані з його
змістом, що обмежують можливості команди, наприклад визначений бюджет, будь-які встановлені
дати або контрольні події розкладу, які визначені замовником або виконуючою організацією. Якщо
проект виконується за контрактом, положення контракту, як правило, є обмеженнями. Інформація
про обмеження може бути зазначена в описі змісту проекту або в окремому журналі.
Створення ієрархічної структури робіт (ІСР) - це процес поділу результатів проекту й робіт із проекту
на більш дрібні елементи, якими легше управляти.
Ієрархічна структура робіт - це орієнтована на результати ієрархічна декомпозиція робіт, які повинна
виконати команда проекту для досягнення цілей проекту й створення необхідних результатів; на
кожному більш низькому рівні ІСР представляє усе більше детальний опис робіт із проекту.
ІСР організує й визначає загальний зміст проекту й представляє роботи, зазначені в поточному
схваленому описі змісту проекту.
Заплановані роботи містяться в елементах ІСР самого нижнього рівня, які називаються «пакетами
робіт».
Для пакетів робіт можуть складатися розклади, оцінюватися вартість, може проводитися їхній
моніторинг і управління.
У контексті ІСР «робота» означає продукти або результати робіт, що є результатами дій, але не самі дії.
Створення ІСР: входи, інструменти й методи, виходи
Блок-схема даних при створенні ІСР
Створення ІСР: входи
1. Опис змісту проекту Описано раніше.
2. Документи по вимогах Описані раніше.
3. Активи процесів організації, що можуть впливати на процес створення ІСР, містять у собі, серед
іншого:
- правила, процедури й шаблони для ІСР;
- проектні архіви з попередніх проектів;
- знання, накопичені в попередніх проектах.
Створення ІСР: інструменти й методи
1. Декомпозиція - це поділ результатів проекту на більш дрібні й легко керовані елементи; декомпозиція
виконується доти, поки роботи й результати не будуть визначені на рівні пакетів робіт. Рівень
пакетів робіт є нижчим і являє собою точку, у якій вартість і тривалості операцій робіт піддаються
достовірній оцінці й управлінню. Рівень деталізації пакетів робіт розрізняється залежно від розміру
й складності проекту.
Створення ІСР: інструменти й методи
Декомпозиція всієї сукупності робіт із проекту до пакетів робіт звичайно містить у собі такі дії:
- визначення й аналіз результатів і відповідних робіт;
- структурування й організація ІСР;
- розбивка верхніх рівнів ІСР на деталізовані елементи більш низьких рівнів;
- розробку й присвоєння ідентифікаційних кодів елементам ІСР;
- перевірку необхідності й достатності ступеня декомпозиції.
Структура ІСР може бути створена в різних формах, наприклад:
- як перший рівень декомпозиції використовуються фази життєвого циклу проекту, на другому рівні
розташовані результати, що належать до проекту й продукту;
- як перший рівень декомпозиції використовуються основні результати;
- використовуються підпроекти, які можуть розроблятися організаціями, що не входять у команду
проекту, наприклад за контрактом. У таких випадках продавець розробляє допоміжну ієрархічну
структуру робіт з контракту в рамках робіт, включених в умови контракту.
Зразок ієрархічної структури робіт
Зразок ієрархічної структури робіт, організованої по фазах
Для декомпозиції елементів ІСР верхнього рівня потрібний поділ робіт кожного результату або
підпроекту на основні елементи, де елементи ІСР являють собою продукти, що піддаються
перевірці, послуги або результати.
ІСР може бути структурована у вигляді схеми, організаційної діаграми, причинно-наслідкової діаграми
або іншим методом.
Перевірка правильності декомпозиції вимагає посвідчення в тому, що низькорівневі елементи ІСР - саме
ті елементи, які необхідні й достатні для створення відповідних результатів більш високого рівня.
Різні результати можуть мати різні рівні декомпозиції. Роботу з деяких результатів досить декомпозувати
усього лише до наступного рівня, щоб досягти рівня пакетів робіт, однак для інших можуть
знадобитися додаткові рівні декомпозиції.
У міру декомпозиції робіт до більш глибоких рівнів деталізації можливість планування, управління й
контролю робіт розширюється.
Однак надмірна декомпозиція може призвести до непродуктивної управлінської трудомісткості,
неефективного використання ресурсів і зниження ефективності виконання робіт.
Декомпозиція може виявитися неможливою для результатів або підпроектів, які будуть виконуватися у
віддаленому періоді часу.
Команда управління проектом звичайно очікує точного визначення результату або підпроекту, щоб мати
можливість розробити докладну ІСР.
Цей метод іноді називають «плануванням методом хвилі, що набігає».
ІСР представляє всі роботи продукту й проекту, включаючи роботи з управління проектом. Загальний
зміст робіт на самих нижніх рівнях повинен скручуватися в більш високі рівні, щоб нічого не було
пропущено, і не виконувалася зайва робота. Іноді це називають «правилом 100 %».
Практичний стандарт PMI по ієрархічних структурах робіт (the Practice Standard for Work Breakdown
Structures - Second Edition) містить рекомендації зі створення, розробки й застосування ієрархічних
структур робіт. Цей стандарт містить конкретні галузеві приклади шаблонів ІСР, які можуть бути
адаптовані до конкретних проектів у певних прикладних областях.
Створення ІСР: виходи
• ІСР - це орієнтований на результати ієрархічний поділ робіт, які повинна виконати команда
проекту для досягнення цілей проекту й створення необхідних результатів; на кожному більш
низькому рівні ІСР являє собою усе більш детальне визначення робіт із проекту.
Створення ІСР: виходи
ІСР остаточно оформляється за допомогою створення контрольних рахунків для пакетів робіт і
унікального ідентифікатора із плану рахунків. Дані ідентифікатори створюють структуру для
ієрархічного підсумовування інформації про витрати, розклад і ресурси.
Контрольний рахунок - елемент управління, за допомогою якого зміст, вартість і розклад інтегруються й
порівнюються з освоєним обсягом для вимірювання виконання.
Контрольні рахунки поміщаються на обраних рівнях управління в ІСР. Кожний контрольний рахунок
може включати один або кілька пакетів робіт, але кожний пакет робіт повинен бути прив'язаний
тільки до одного контрольного рахунку.
Створення ІСР: виходи
2. Словник ІСР – це документ, генерований процесом створення ієрархічної структури робіт (ІСР) і
який її доповнює.
Словник ІСР надає більш детальні описи елементів ІСР, включаючи пакети робіт і контрольні рахунки.
Створення ІСР: виходи
Інформація в словнику ІСР містить у собі, серед іншого:
- ідентифікатор плану рахунків;
- опис робіт;
- відповідальну організацію;
- список контрольних подій розкладу;
- пов'язані заплановані операції;
- необхідні ресурси;
- оцінки вартості;
- вимоги до якості;
- критерії приймання;
- технічні посилання;
- контрактну інформацію.
Створення ІСР: виходи
3. Базовий план по змісту є елементом плану управління проектом.
Елементи базового плану по змісту містять у собі:
- Опис змісту проекту - містить у собі опис змісту продукту, результати проекту й визначає критерії
приймання продукту користувачем.
- ІСР - визначає кожний результат і декомпозицію результатів на пакети робіт.
- Словник ІСР - містить докладний опис робіт і технічну документацію по кожному елементу ІСР.
Створення ІСР: виходи
4. Оновлення документів проекту
Документи проекту, які можуть бути оновлені, містять у собі документи по вимогах, але не обмежуються
тільки ними. Якщо в результаті процесу створення ІСР з'являються схвалені запити на зміни, може
знадобитися коректування документів по вимогах, щоб включити в них схвалені зміни.
2.4. Підтвердження змісту
Управління змістом – процес моніторингу статусу проекту й змісту продукту, а також управління
змінами базового плану по змісту.
Управління змістом проекту забезпечує обробку всіх запитаних змін і рекомендованих коригувальних і
попереджуючих дій у рамках процесу здійснення загального управління змінами (див. тему
управління інтеграцією проекту).
Управління змістом проекту використовується також для управління фактичними змінами в міру їхньої
появи; воно інтегровано в інші процеси управління.
Некеровані зміни часто називають «зрушенням змісту проекту».
Зміни в кожному проекті неминучі, і тому необхідно процес управління змінами.
Управління змістом: входи, інструменти й методи, виходи
Блок-схема даних при управлінні змістом
Управління змістом: входи
1. План управління проектом, розглянутий в темі Управління інтеграцією проекту, містить таку
інформацію, використовувану для управління змістом:
- Базовий план по змісту. Базовий план по змісту порівнюється з фактичними результатами, для того
щоб визначити, чи потрібні коригувальні зміни або попереджальні дії.
- План управління змістом. План управління змістом описує, як буде здійснюватися управління
змістом проекту і його контроль.
- План управління змінами. План управління змінами визначає процес управління змінами проекту.
- План управління конфігурацією. План управління конфігурацією визначає ті елементи, які є
конфігураційними, елементи, які вимагають формалізованого управління змінами, а також процес
управління змінами таких елементів.
- План управління вимогами. План управління вимогами може містити в собі порядок планування,
відстеження й складання звітів по вимогах, а також порядок ініціювання змін вимог до продукту,
послузі або результату. Також він описує порядок проведення аналізу впливів і рівні повноважень,
необхідні для схвалення даних змін.
Управління змістом: входи
2. Інформація про виконання робіт інформація про виконання проекту, наприклад дані про те, робота
над якими результатами почалася, про її хід і про те, по яких результатах робота вже закінчена.
3. Документи по вимогах (Розглянуто раніше)
4. Матриця відстеження вимог (Розглянуто раніше).
5. Активи процесів організації, які можуть впливати на процес управління змістом, містять у собі,
серед іншого:
- існуючі формальні й неформальні правила, процедури й провідні вказівки, пов'язані зі змістом;
- використовувані методи моніторингу й звітності.
Управління змістом: інструменти й методи
1. Аналіз відхилень. Вимірювання виконання проекту використовуються для оцінки величини
відхилення від початкового базового плану по змісту. Важливі аспекти управління змістом проекту
містять у собі визначення причини й ступеня відхилення щодо базового плану по змісту (див. цю
тему, п.2.4) і прийняття рішень про необхідність коригувальних або попереджуючих дій.
Управління змістом: виходи
1. Результати вимірювання виконання робіт можуть містити в собі порівняння запланованого й
фактичного технічного виконання або інші вимірювання виконання змісту. Ця інформація
документується й передається зацікавленим сторонам проекту.
2. Оновлення активів процесів організації. Активи процесів організації, які можуть бути оновлені,
містять у собі, серед іншого:
- причини відхилень;
- обрані коригувальні впливи й причини;
- інші види знань, накопичених у ході управління змістом проекту.
Управління змістом: виходи
3. Запити на зміни Аналіз виконання змісту може призвести до появи запиту на зміну базового плану по
змісту або інших елементах плану управління проектом. Запити на зміни можуть містити в собі
попереджуючі, коригувальні впливи або виправлення дефектів.
Запити на зміни обробляються з метою проведення перевірки й представлення відповідно до процесу
здійснення загального управління змінами (див. тему Управління інтеграцією проекту).
Управління змістом: виходи
4. Оновлення плану управління проектом включає:
- Оновлення базового плану по змісту. Якщо схвалені запити на зміни впливають на зміст проекту, то
опис змісту, ІСР і словник ІСР переглядаються й випускаються заново, щоб відбити схвалені зміни.
- Оновлення інших базових планів. Якщо схвалені запити на зміни впливають на зміст проекту, то
відповідний базовий план за вартістю й базовими розкладами переглядаються й випускаються
заново, щоб відбити схвалені зміни.
Управління змістом: виходи
5. Оновлення документів проекту
Документи проекту, які можуть бути оновлені, містять у собі, серед іншого:
- документи по вимогах;
- матрицю відстеження вимог.
Дякую за увагу!
Тема: Розробка системи управління і забезпечення якості програмних продуктів у відповідності з
ISO-9000
• Цей стандарт специфікує модель забезпечення якості на всіх етапах життєвого циклу
товару/послуги.
ISO-9002 та ISO-9003
• ISO-9003 - системи якості - модель забезпечення якості в процесі контролю готової продукції
та її випробування.
ISO-9004 має чотири частини:
• Відповідальність керівництва;
• Система якості;
• Аналіз контракту;
• Управління проектуванням;
• Закупки;
• Управління процесами;
• Контроль і випробування;
• Підготовка кадрів;
• Обслуговування.
1. Відповідальність керівництва
На керівництво компанії–постачальника покладається задача визначення політики та зобов’язань з
якості.
Політика повинна бути узгодженою як з цілями самої компанії, так і з очікуваннями і запитами
самого користувача.
Постачальник повинен забезпечити розуміння цієї політики службовцями компанії, її проведення та
підтримку на усіх рівнях.
Керівництво визначає і документально оформляє відповідальність, повноваження та механізми взаємодії
персоналу, який виконує та перевіряє роботу, що впливає на якість.
Керівництво призначає менеджера з якості з відповідними повноваженнями для забезпечення розробки,
впровадження та підтримки в робочому стані системи якості та надання звітів про її
функціонування , які дозволяють проаналізувати та удосконалити систему якості.
2. Система якості
Компанія-постачальник повинна розробити, документально оформити та підтримати в робочому стані
систему якості як засіб, що забезпечує відповідність продукції вимогам стандарту ISO-9001.
Система якості передбачає наявність:
• За контрактом із замовником;
• Як комерційний продукт для певного сектора ринку;
• Як система, вмонтована в апаратне забезпечення;
• Як система підтримки бізнес-процесів постачальника.
Загальні положення аналізу контрактів, визначені в ISO 9000-3, прийнятні для будь-якої з цих ситуацій.
3. Аналіз контракту (продовження)
Постачальник повинен попередньо проаналізувати заявку на тендер, контракт чи замовлення (до
надання заявки або укладання контракту).
Це дозволить гарантувати адекватне визначення вимог до проекту і можливість виконати контракт.
У процесі аналізу контрактів на ПЗ можуть враховуватись різноманітні аспекти взаємодії з замовником,
технічні міркування, аспекти управління та фактори забезпечення захисту і конфіденційності.
3. Аналіз контракту (закінчення)
Наприклад, можуть аналізуватися:
• термінологія;
• ступінь участі замовника у спільній роботі;
• планування розробки.
4. Управління проектуванням (продовження)
Проект розробки ПП організується за певною моделлю ЖЦ.
ISO 9000-3 не визначає, якою повинна бути модель ЖЦ, це залежить від специфіки задачі.
Стандарт наводить лише визначення моделі ЖЦ як сукупності процесів.
Модель показує, коли ці процеси і як підключаються до реалізації проекту.
4. Управління проектуванням (продовження)
Відомо, що розробка системи – це процес встановлення початкових вимог до кінцевого продукту.
Стандарт оговорює, що цей процес повинен проводитись у чітко визначеному порядку, що дозволить
попередити появу помилок та усуне залежність від процесів перевірки та затвердження як єдиних
методів по виявленню проблемних ситуацій.
Вимога строго дотримуватись дисципліни процесу розробки означає наявність та підтримку в робочому
стані документованих процедур, які і стануть гарантією того, що ПП створюється у відповідності
з заданими вимогами та планами розробки і забезпечення якості.
4. Управління проектуванням (продовження)
Управління проектом повинне враховувати такі аспекти як:
• спеціальні вимоги до стійкості систем або до її зворотних дій на потенційні аварійні ситуації.
4. Управління проектуванням (продовження)
Для процесів кодування необхідно задавати правила використання мов програмування, принципи
кодування та правила розробки відповідних коментарів.
Інструментальні засоби і методи, що використовуються при розробці ПП (системи аналізу та
проектування, компілятори) повинні попередньо затверджуватись і контролюватися системою
конфігураційного управління.
Область застосування інструментарію повинна бути задокументована, а його використання періодично
аналізуватися, з метою встановлення необхідності удосконалення інструментальних систем або
заміни на нові продукти.
4. Управління проектуванням (продовження)
Проектування та розробка повинні ретельно плануватись.
План розробки ПП повинен формулювати задокументовані дії з:
• проектування;
• кодування;
• інтеграції;
• тестування;
• встановлення;
• підтримки.
4. Управління проектуванням (продовження)
План повинен включати також такі пов’язані з основним процесом плани :
• забезпечення якості;
• управління ризиками;
• управління конфігурацією;
• плани інтеграції;
• плани установки;
• можливість тестування.
4. Управління проектуванням (продовження)
На певних стадіях проектування проводиться перевірка відповідності вихідних даних вхідним вимогам.
Така верифікація проекту може включати аналіз вихідних даних, демонстрації, в тому числі за
допомогою прототипів і моделювання, або тестування.
Тільки перевірені вихідні проектні дані затверджуються для остаточного прийому і подальшого
використання.
Усі виявлені в процесі перевірки проблемні ситуації повинні адекватно розв'язуватися.
4. Управління проектуванням (закінчення)
Перш ніж система буде передана замовнику, постачальник повинен затвердити систему на відповідність
заданому призначенню.
Замовнику може бути переданий тільки затверджений програмний продукт.
Всі зміни і модифікації проекту повинні бути ідентифіковані, документально оформлені, проаналізовані
і затверджені до їх реалізації.
Постачальник встановлює і підтримує в робочому стані процедури управління змінами в проекті, які
можуть виникнути на будь-якій стадії життєвого циклу системи.
5. Управління документацією і даними
Постачальник повинен розробити і підтримувати в робочому стані документовані процедури управління
всіма специфікаціями і даними, що відносяться до вимог стандарту ISO 9001, включаючи і
документи зовнішнього походження (стандарти і креслення споживача).
Документи і дані можуть розміщуватися на будь-якому паперовому або електронному носієві.
5. Управління документацією і даними (закінчення)
Для реалізації контролю за документами і даними можуть використовуватися процедури управління
конфігурацією.
У сферу дії цього розділу стандарту попадають:
• комерційне ПЗ;
• розробка за субконтрактом;
• комп'ютерне і комунікаційне апаратне забезпечення;
• засоби розробки;
• персонал, що наймається за контрактом;
• сервіс підтримки і супроводу;
• навчальні курси і матеріали.
7. Ідентифікація і відслідковування продукції
Постачальник повинен встановити і підтримувати в робочому стані процедури ідентифікація елементів
програмного забезпечення на всіх етапах, від специфікації вимог до розробки, реплікації і
доставки.
Протягом життєвого циклу системи повинні працювати процедури відстеження компонентів складових
частин програмного забезпечення.
7. Ідентифікація і відслідковування продукції (продовження)
Процедури ідентифікації і відстеження реалізовуються в системі конфігураційного управління, яка
визначається як дисципліна управління, відповідно до якої здійснюється технічне й
адміністративне керівництво розробкою і підтримкою життєвого циклу елементів конфігурації,
включаючи елементи програмного забезпечення.
Ця дисципліна застосовна також до документації і апаратного забезпечення, що стосується
програмного продукту, який розробляється.
Міра використання конфігураційного управління залежить від розміру і складності проекту, а також від
рівня пов'язаного з ним ризику.
7. Ідентифікація і відслідковування продукції (продовження)
Одна з цілей конфігураційного управління задокументувати і забезпечити повну видимість поточної
конфігурації продукту і ступеня відповідності початковим вимогам. Інша мета надати кожному, хто
працює над проектом, точну інформацію на будь-якому етапі життєвого циклу.
Система конфігураційного управління надає, зокрема, можливість ідентифікувати версію кожного
елемента програмного забезпечення, управляти одночасно модифікацією даного елемента двом або
більше незалежним розробникам, координувати модифікацію безлічі продуктів і т.д.
7. Ідентифікація і відслідковування продукції (закінчення)
У визначенні конфігурації беруть участь:
• тестування модулів,
• системи загалом і
• анотовані документи,
• результати аналізу,
• аудиторські повідомлення.
13. Управління реєстрацією даних про якість (закінчення)
У тому випадку, якщо дані про якість зберігаються в електронному вигляді, при визначенні часу
збереження і доступу до даних необхідно враховувати ступінь можливої деградації електронних
копій і доступність пристроїв і програмних компонентів для доступу до даних.
14. Внутрішній аудит якості
Постачальник розробляє і підтримує в робочому стані документовані процедури планування і
проведення внутрішніх перевірок якості, які дозволять пересвідчитися, що діяльність в галузі
якості та її результати відповідають запланованим заходам, а також підтвердити ефективність
системи якості.
14. Внутрішній аудит якості (закінчення)
Внутрішні перевірки якості плануються на основі статусу і важливості діяльності, що перевіряється.
Внутрішній аудит повинен проводитися персоналом, не залежним від осіб, які несуть відповідальність
за діяльність, що перевіряється.
Внутрішній аудитор аналізує узгодженість програми якості для конкретного проекту із загальною
системою якості, прийнятою в організації.
15. Підготовка кадрів
Постачальник повинен розробити і підтримувати в робочому стані документовані процедури визначення
потреб у підготовці кадрів, а також забезпечувати підготовку всього персоналу, що виконує роботи,
які впливають на якість.
Персонал повинен бути кваліфікований на основі відповідної освіти, підготовки і досвіду.
15. Підготовка кадрів (закінчення)
Визначення задач навчання повинно ув'язуватися з тими інструментальними засобами, методами і
комп'ютерними ресурсами, які будуть використовуватися в розробці програмного продукту і
управлінні ним.
Можливо, буде також потрібне спеціальне навчання в тій галузі, з якою пов'язаний програмний продукт,
що розробляється.
16.Обслуговування
Що стосується програмного забезпечення, то під обслуговуванням тут розуміють супровід системи
(maintenance) і підтримку замовників (customer support).
Підтримка замовників обговорюється в стандарті ISO 9000-2.
16.Обслуговування (продовження)
Супровід системи, як правило, включає в себе:
Дякую за увагу!
Управління вартістю проектів
1. Місце функції управління вартістю в методології проектного менеджменту
2. Сутність управління вартістю
3. Оцінювання вартості
4. Визначення бюджету
5. Управління вартістю
1.Місце функції управління вартістю в методології проектного менеджменту
Управління вартістю проекту поєднує процеси, виконувані в ході планування, розробки бюджету й
управління витратами і які забезпечують завершення проекту в рамках затвердженого бюджету.
Процеси управління вартістю проекту:
1. Оцінювання вартості – процес визначення зразкової вартості ресурсів, необхідних для виконання
операцій проекту.
2. Визначення бюджету – процес підсумовування оцінок вартості окремих операцій або пакетів робіт
для формування санкціонованого базового плану за вартістю.
3. Управління вартістю – процес моніторингу статусу проекту для коректування бюджету проекту й
внесення змін у базовий план за вартістю.
У РМВОК ці процеси розглядаються як окремі, тому що інструменти й методи кожного з них різні.
Можливості впливу на вартість максимальні на ранніх стадіях проекту, тому дуже важливо якомога
раніше визначити зміст проекту.
Роботам, що складають три процеси управління вартістю проекту, передує деяка дія по плануванню,
виконувана командою управління проектом. Це планування є частиною процесу розробки плану
управління проектом, у результаті якого виходить план управління вартістю, що встановлює
формат і критерії планування, структурування, оцінювання, розробки бюджету й управління
вартістю проекту. Процеси управління вартістю й пов'язані з ними інструменти й методи звичайно
вибираються на стадії визначення життєвого циклу проекту і документально фіксуються в плані
управління вартістю.
- Ступінь точності. При оцінці вартості операцій дані округляються з певною точністю (наприклад, до
100, 1000 дол. США) залежно від змісту операцій і масштабу проекту; у цьому округленні можуть
ураховуватися резерви на можливі втрати.
- Одиниці вимірювання. Для кожного типу ресурсів оговорюються одиниці вимірювання (наприклад,
людино-години, людино-дні, тижні або фіксована вартість).
- Зв'язки між процедурами організації. Ієрархічна структура робіт (ІСР) надає структуру для плану
управління вартістю, що дозволяє забезпечити несуперечність оцінок, бюджету й управління
вартістю. Елемент ІСР, використовуваний для обліку вартості проекту, називається контрольним
рахунком. Кожному контрольному рахунку присвоюється унікальний код або номер, що
безпосередньо пов'язаний із системою бухгалтерського обліку виконуючої організації.
- Контрольні пороги. Для моніторингу виконання вартості можуть визначатися пороги відхилень, що
дозволяє встановити заздалегідь узгоджену величину допустимого відхилення, перш ніж будуть
розпочаті деякі дії. Пороги звичайно показуються у відхиленні від базового плану, вираженому у
відсотках.
– визначати формули розрахунку для управління освоєним обсягом, необхідні для визначення
прогнозу по завершенні та інших методів відстеження.
- Формати звітності. Визначаються формати й регулярність складання різноманітних звітів про
вартість.
- Описи процесів. Документально фіксуються описи кожного із трьох процесів управління вартістю.
Вся ця інформація включається в план управління вартістю (елемент плану управління проектом), або в
текст його основної частини, або у вигляді додатків. План управління вартістю може бути
формальні і неформальним і мати більший або менший ступінь деталізації залежно від потреб
проекту.
Управління вартістю проекту має враховувати вимоги до інформації про витрати, пропоновані
зацікавленими сторонами проекту.
Різні зацікавлені сторони проекту можуть розраховувати вартість проекту різними способами й у різні
моменти часу.
Наприклад, ціна предмета, що купується, може оцінюватися на момент ухвалення рішення або
підтвердження покупки, на момент оформлення замовлення, на момент поставки, або його
фактична вартість зараховується й фіксується при веденні видатків проекту.
Управління вартістю проекту стосується, насамперед, вартості ресурсів, необхідних для виконання
операцій проекту. Крім того, при управлінні вартістю проекту варто враховувати, як прийняті
рішення позначаться на наступних періодичних витратах на експлуатацію, обслуговування й
технічну підтримку продукту, послуги або результату проекту.
Наприклад, обмеження числа перевірок конструкторських креслень може знизити вартість проекту, але
це може призвести до підвищення експлуатаційних витрат замовника.
Джерелами інформації на вході є виходи процесів проекту з інших галузей знань. Після одержання вся
ця інформація стає доступною як входи для всіх трьох процесів управління вартістю.
Вартість оцінюється для всіх ресурсів, які будуть задіяні в проекті. До ресурсів належать, зокрема,
робоча сила, матеріали, обладнання, послуги й споруди, а також особливі статті витрат, такі як
урахування рівня інфляції або видатки на можливі втрати. Оцінювання вартості – це кількісне
оцінювання можливої вартості ресурсів, необхідних для виконання операції.
Оцінювання вартості являє собою процес приблизного оцінювання вартості ресурсів, необхідних для
виконання операцій проекту.
Оцінювання вартості є прогнозами, заснованими на інформації, відомої в конкретний момент часу. Вони
містять у собі виявлення й розгляд альтернатив розрахунку вартості для ініціації й виконання
проекту. Для досягнення оптимальних витрат проекту повинні бути розглянуті співвідношення й
ризики вартості, такі як рішення «виробляти або купити», «купити або орендувати», а також
розподіл ресурсів.
Оцінювання вартості, як правило, виражаються в грошових одиницях, хоча в окремих випадках
використовуються інші одиниці вимірювання, такі як людино-години або людино-дні, для
полегшення порівняння й виключення впливу коливань курсів валют.
У ході виконання проекту рекомендується проводити уточнення оцінки вартості для відбиття додаткових
деталей у міру їхнього виявлення. Точність оцінки вартості проекту підвищується в міру
просування проекту по життєвому циклі.
Отже, оцінювання вартості є ітеративним процесом, що повторюється від фази до фази.
Наприклад, у фазі ініціації проекту може бути отримана досить груба оцінка «порядку величини», у
діапазоні ±50 %.
Надалі, у міру надходження інформації, діапазон оцінки може звузитися до ±10 %.
У деяких організаціях існують особливі вказівки щодо того, коли такі уточнення варто робити, і якої
точності при цьому можна чекати.
Вартість оцінюється для всіх ресурсів, які будуть задіяні в проекті. До ресурсів належать, зокрема,
робоча сила, матеріали, обладнання, послуги й споруди, а також особливі статті витрат, такі як
урахування рівня інфляції або видатки на можливі втрати.
Оцінювання вартості – це кількісне оцінювання можливої вартості ресурсів, необхідних для виконання
операції.
Оцінювання вартості:
входи, інструменти і методи, виходи
Блок-схема даних при оцінюванні вартості
Оцінювання вартості: входи
1. Базовий план по змісту
- Опис змісту. Опис змісту (див. тему Управління змістом) містить у собі опис продукту, критерії
приймання, ключові результати, межі проекту, допущення й обмеження проекту. Одне з головних
допущень, що має бути зроблене при оцінці витрат проекту, полягає в тому, чи будуть оцінки
обмежені тільки безпосередніми витратами проекту або вони також будуть включати непрямі
витрати. Непрямі витрати - це витрати, які неможливо безпосередньо віднести до конкретного
проекту, і, отже, вони акумулюються й розподіляються рівномірно між кількома проектами за
допомогою затвердженої й документованої процедури обліку. Одним із найпоширеніших обмежень
для багатьох проектів є обмеженість бюджету проекту. Серед інших прикладів обмежень можна
навести необхідні дати поставок, наявність кваліфікованих людських ресурсів і правила організації.
- Ієрархічна структура робіт і Словник ІСР (див. тему Управління змістом).
- Додаткова інформація, яку можна знайти в базовому плані по змісту і яка містить вимоги, що
зачіпають контрактні зобов'язання і юридичну відповідальність, включає питання здоров'я,
безпеки, захищеності, продуктивності, охорони навколишнього середовища, страхування, прав
інтелектуальної власності, ліцензій і дозволів. Всі їх варто враховувати при визначенні оцінок
вартості.
Оцінювання вартості: входи
2. Розклад проекту. Головними факторами при визначенні вартості проекту є типи й кількість ресурсів,
а також кількість часу, протягом якого необхідно використовувати ці ресурси для виконання робіт із
проекту. Ресурси запланованих операцій і їхні тривалості використовуються як ключові входи
даного процесу. Оцінювання ресурсів операцій містить у собі визначення доступності й кількості
персоналу й матеріалів, необхідних для виконання запланованих операцій. Ці дані тісно пов'язані з
оцінкою вартості. Оцінювання тривалості операцій впливає на оцінку вартості в будь-якому
проекті, у бюджеті якого передбачене виправлення на вартість фінансування (включаючи відсотки
по позиках) і в якому ресурси призначаються на певний період часу, що відповідає тривалості
виконання операції. Оцінювання тривалості операцій також може впливати на оцінку вартості в тих
випадках, коли враховуються витрати, що залежать від часу (наприклад, профспілка, з якою
укладений колективний договір, що регулярно продовжується, або матеріали із сезонними
коливаннями вартості).
Оцінювання вартості: входи
3. План управління людськими ресурсами Характеристики управління людськими ресурсами,
тарифні ставки персоналу проекту й відповідні винагороди/заохочення є необхідними складовими
оцінювання вартості проекту.
4. Реєстр ризиків. Для урахування витрат на зниження ризиків необхідно переглянути реєстр ризиків.
Ризики можуть бути загрозами або сприятливими можливостями, тому вони звичайно впливають
на вартість як окремої операції, так і всього проекту. Як правило, у випадку виникнення ризику
негативного характеру, вартість проекту в поточному або найближчому періоді звичайно
збільшується, і іноді відбувається затримка робіт, передбачених розкладом проекту.
Оцінювання вартості: входи
5. Фактори середовища підприємства, які можуть впливати на процес оцінювання вартості, містять у
собі, серед іншого:
- Кон'юнктуру ринку. Кон'юнктура ринку описує, які продукти, послуги й результати доступні на
ринку, хто є їхніми постачальниками, на яких умовах і в які строки. Регіональні й/або глобальні
умови попиту та пропозиції впливають на вартість ресурсів.
- Опубліковану комерційну інформацію. Інформація про тарифи вартості ресурсів часто доступна в
комерційних базах даних, що містять відомості про кваліфікацію й вартість людських ресурсів, а
також відомості про вартість стандартних матеріалів і обладнання. Іншим джерелом інформації є
опубліковані прайс-листи організацій-продавців.
Оцінювання вартості: входи
6. Активи процесів організації, які впливають на процес оцінювання вартості, містять у собі, серед
іншого:
- правила оцінювання вартості;
- шаблони оцінювання вартості;
- історичну інформацію; і
- накопичені знання.
Оцінювання вартості: інструменти і методи
1. Експертна оцінка.На оцінку вартості впливають багато змінних, такі як ставки заробітної плати,
вартість матеріалів, інфляція, фактори ризику та ін. Експертні оцінки, засновані на історичній
інформації, дають важливе розуміння навколишнього середовища й інформації з попередніх
подібних проектів. Також експертні оцінки можуть бути використані для визначення необхідності
об'єднання методів оцінювання й способів усунення розходжень між ними.
Оцінювання вартості: інструменти і методи
2. Оцінювання за аналогами. Використовуються значення таких параметрів, як зміст, вартість, бюджет
і тривалість, або вимірювання таких величин, як розмір, вага й складність, з попередніх подібних
проектів як основи для оцінювання аналогічних параметрів або показників поточного проекту. При
оцінюванні вартості по даному методу за основу оцінювання вартості поточного проекту
приймається фактична вартість попередніх подібних проектів. Цей підхід, що дозволяє оцінювати
загальну величину, іноді адаптується залежно від відомих розходжень у складності проекту.
Найчастіше оцінювання вартості за аналогами використовується у випадку, коли обсяг детальної
інформації про проект обмежений, наприклад на його ранніх фазах. Оцінювання вартості по
аналогах виконується із застосуванням історичної інформації й експертної оцінки.
Метод оцінювання вартості за аналогами, як правило, обходиться дешевше й займає менше часу, ніж
інші методи, але при цьому він звичайно виявляється й менш точним. Оцінювання вартості за
аналогами може застосовуватися до всього проекту або до його частин разом з іншими методами
оцінювання. Оцінювання за аналогами стає найбільш достовірним у випадках, коли попередній
проект подібний поточному не тільки за зовнішніми ознаками, але й по суті, а в членів команди
проекту, зайнятих підготовкою оцінювання, є необхідні знання.
Оцінювання вартості: інструменти і методи
3. Параметричне оцінювання - це метод, за якого для обчислення оцінки параметрів операції, таких як
вартість, бюджет і тривалість, використовуються статистичні взаємозв'язки між історичними
даними й іншими змінними (наприклад, площею у квадратних метрах у будівництві). За допомогою
даного методу можна одержати більш точну оцінку вартості. Ступінь точності залежить від
складності й даних, що лежать в основі моделі. Параметричне оцінювання вартості може
застосовуватися до всього проекту або до його частин разом з іншими методами оцінювання.
4. Оцінювання «знизу нагору» - це метод оцінювання елементів робіт. Вартість окремих пакетів робіт
або операцій оцінюється з найвищим ступенем конкретизації деталей. Детальна вартість потім
підсумовується або «згортається» до більш високих рівнів з метою наступного відстеження й
складання звітів. На вартість і точність оцінювання «знизу нагору» звичайно впливають розмір і
складність кожної окремої операції або пакета робіт.
Оцінювання вартості: інструменти і методи
5. Оцінювання по трьох точках. Точність оцінок вартості операцій по одній точці може бути поліпшена
шляхом розгляду невизначеностей і ризиків оцінок. Ця концепція походить із методу оцінювання й
аналізу програм (PERT). Для визначення зразкового діапазону вартості операції PERT використовує
три оцінки:
- Найбільш імовірна (См). Вартість операції, заснована на реалістичній оцінці трудомісткості
необхідної роботи й всіх прогнозованих витрат.
- Оптимістична (Со). Вартість операції, заснована на аналізі сприятливого сценарію розвитку операції.
- Песимістична (Ср). Вартість операції, заснована на аналізі несприятливого сценарію розвитку
операції.
Оцінювання вартості: інструменти і методи
Аналіз PERT дозволяє визначити очікувану (СЕ) вартість операції шляхом обчислення
середньозваженого цих трьох оцінок:
4. Визначення. бюджету
Визначення бюджету - процес об'єднання оціночної вартості окремих операцій або пакетів робіт для
розробки санкціонованого базового плану за вартістю. Даний базовий план містить у собі всі
санкціоновані бюджети, за винятком управлінських резервів.
Бюджети проекту являють собою засоби, санкціоновані для виконання проекту.
Виконання вартості проекту порівнюється із санкціонованим бюджетом
Визначення бюджету:
входи, інструменти і методи, виходи
Блок-схема даних при визначенні бюджету
Визначення бюджету: входи
1. Оцінювання вартості операцій. Оцінювання вартості кожного пакета робіт складається із суми
оцінок вартості кожної операції,що входить у пакет робіт.
2. Основа для оцінювання. Допоміжні деталі для оцінювання вартості повинні бути визначені, як
описано раніше. Будь-які головні допущення, пов'язані із включенням або виключенням непрямих
витрат з бюджету проекту, вказуються в основі для оцінок.
3 Базовий план по змісту.
- Опис змісту. Формальні обмеження на період витрачання коштів на проект можуть бути встановлені
організацією або іншими органами, такими як урядові заклади, а також можуть бути закріплені в
контракті. Ці обмеження фінансування відображаються в описі змісту проекту.
- Ієрархічна структура робіт. Ієрархічна структура робіт проекту (ІСР) визначає взаємини між усіма
результатами проекту і їхніх різноманітних елементів.
- Словник ІСР. Словник ІСР і відповідні детальні описи робіт дають точні визначення результатів і опис
робіт для кожного елемента ІСР, необхідного для досягнення кожного результату.
Визначення бюджету: входи
4. Розклад проекту, як частина плану управління проектом, містить у собі планові дати початку й
закінчення операцій, контрольних подій, пакетів робіт, планованих пакетів робіт і контрольних
рахунків проекту. Дана інформація може бути використана для підсумовування витрат за
календарні періоди, у які заплановане виникнення витрат.
5. Ресурсні календарі містять інформацію про склад і час виділення ресурсів. Ця інформація може
використовуватися для зазначення вартості ресурсів протягом проекту.
6. Контракти. При визначенні бюджету враховується контрактна інформація й витрати, пов'язані із
придбаними продуктами, послугами або результатами.
7. Активи процесів організації, які впливають на процес визначення бюджету, містять у собі, серед
іншого:
- існуючі формальні й неформальні правила, процедури й провідні вказівки, пов'язані з розробкою
бюджету витрат;
- інструменти розробки бюджету витрат; і
- методи складання звітів.
Визначення бюджету: інструменти і методи
1. Підсумовування вартості Оцінки вартості підсумовуються по пакетах робіт відповідно до ІСР. Потім
оцінки вартості пакетів робіт поєднуються в елементи більш високих рівнів елементів ІСР (таких
як контрольні рахунки), у підсумку утвориться оцінювання вартості всього проекту.
2. Аналіз резервів бюджету може встановити як резерви на можливі втрати, так і управлінські резерви
проекту.
Резерви на можливі втрати - це кошти на випадок незапланованих, але потенційно необхідних змін, які
можуть виникнути в результаті реалізованих ризиків, зазначених у реєстрі ризиків.
Управлінські резерви - це бюджети, зарезервовані на незаплановані зміни змісту й вартості проекту.
Менеджеру проекту може знадобитися отримати схвалення на управлінські резерви до їх
одержання в розпорядження або витрат.
Резерви не є частиною базового плану проекту за вартістю, але вони можуть бути включені в загальний
бюджет проекту. Вони не враховуються при розрахунку освоєного обсягу.
Визначення бюджету: інструменти і методи
3. Експертна оцінка. При визначенні бюджету повинні використовуватися оцінки, засновані на досвіді в
прикладній області, галузі знань, сфері діяльності, галузі промисловості й т.д., відповідно до
виконуваної операції. Таку експертну оцінку можуть надати особа або група осіб, що мають фахову
освіту, знання, навички, досвід або підготовку. Експертні оцінки доступні з багатьох джерел, до
яких належать, серед іншого:
- інші підрозділи в рамках виконуючої організації;
- консультанти;
- зацікавлені сторони проекту, у тому числі замовники;
- професійні й технічні асоціації; і
- галузеві об'єднання.
Визначення бюджету: інструменти і методи
4. Історичні взаємозв'язки. Будь-які історичні взаємозв'язки, що дають у результаті параметричні
оцінки або оцінки по аналогах, передбачають використання характеристик (параметрів) проекту
для розробки математичних моделей, щоб прогнозувати загальну вартість проекту. Такі моделі
можуть бути простими (наприклад, будівництво житла засноване на певній вартості квадратного
метра житлової площі) або складними (наприклад, одна модель обрахування витрат на розробку
програмного забезпечення використовує кілька окремих поправочних коефіцієнтів, кожний з яких
включає безліч елементів).
Як вартість, так і точність параметричних моделей і моделей за аналогами може значно різнитися. Вони
найбільш достовірні, коли:
- історична інформація, використовувана для розробки моделі, точна;
- параметри, використовувані в моделі, повністю піддаються кількісному вираженню; і
- моделі масштабовані, тобто застосовні як до великого проекту, до невеликого проекту, так і до фаз
проекту.
Визначення бюджету: інструменти і методи
5. Узгодження фінансових обмежень. Використання коштів має бути узгоджене з будь-якими
фінансовими обмеженнями по виділенню коштів під проект.
Розбіжності між фінансовими обмеженнями й плановими витратами іноді приводять до необхідності
перегляду розкладу робіт для узгодження норм витрат. Це може бути реалізоване шляхом внесення
в розклад проекту обмежень по необхідних датах робіт.
Визначення бюджету: виходи
Управління вартістю являє собою процес моніторингу статусу проекту для коректування бюджету
проекту й внесення змін у базовий план за вартістю.
Коректування бюджету пов'язане з реєстрацією фактичних витрат, понесених на певну дату. Будь-яке
збільшення санкціонованого бюджету може бути затверджене тільки за допомогою процесу
загального управління змінами.
Моніторинг витрачання коштів без прийняття до уваги обсягу робіт, виконуваних у зв'язку із цими
видатками, має малу цінність для проекту, якщо тільки не дозволяє команді проекту залишатися в
рамках затвердженого бюджету.
Отже, більша частина дій по управлінню вартістю пов'язана з аналізом взаємозв'язків між витратами
коштів проекту й фізичною роботою, виконуваною у зв'язку із цими витратами.
Ключовим елементом ефективного управління вартістю є управління затвердженим базовим планом
виконання вартості й змінами даного базового плану.
Цей показник дав назву й методу освоєного обсягу, і звіту по освоєному обсягу.
Планована вартість виконаних робіт ОО, як і два інших показники, - це об'єднання коштів за
розглянутим періодом часу.
ОО - це об'єднання планової вартості фактично виконаних за звітний період робіт. Наприклад, якщо
виконано роботу із плановою (кошторисною) вартістю 10000 грн., то ОО для цієї роботи з її
закінченням буде дорівнювати 10000 грн.
Управління вартістю: інструменти і методи
Фактична вартість (ФВ) - це загальна вартість, фактично витрачена й зареєстрована під час виконання
робіт у рамках операції або елемента ієрархічної структури робіт. Це загальна вартість, витрачена
при виконанні робіт, обмірюваних освоєним обсягом. Фактична вартість по визначенню повинна
відповідати тому, що було закладено в плановий обсяг і обмірюване освоєним обсягом (наприклад,
тільки прямі витрати робочого часу, тільки прямі витрати або всі витрати, включаючи непрямі). У
фактичної вартості відсутня верхня межа; виміряється все, що витрачається для досягнення
освоєного обсягу.
Управління вартістю: інструменти і методи
Також здійснюється контроль відхилень від схваленого базового плану:
- Відхилення по строках (ВСТР) являє собою вимірювання виконання строків проекту. Значення
його дорівнює різниці між освоєним обсягом (ОО) плановим обсягом (ПО). Відхилення по строках
у методі УОО являє собою показник, корисний тим, що він демонструє, коли проект відстає по
строках від свого базового плану. Відхилення по строках в остаточному підсумку буде дорівнювати
нулю при завершенні проекту, тому що всі планові обсяги на той час повинні бути освоєні. Такі
показники відхилень найкраще використовувати разом з методом критичного шляху для складання
розкладу й управління ризиками.
Рівняння: ВСТР = ОО - ПО.
Управління вартістю: інструменти і методи
- Відхилення за вартістю (ВВРТ) являє собою вимірювання виконання вартості проекту. Воно
дорівнює різниці між освоєним обсягом (ОО) і фактичною вартістю (ФВ). Відхилення за вартістю
наприкінці проекту буде дорівнювати різниці між бюджетом по завершенні (БПЗ) і фактично
витраченою сумою. ВВРТ у методі управління освоєним обсягом (УОО) надзвичайно важливе,
тому що воно демонструє взаємозв'язок між фізичним виконанням і витраченими коштами. Будь-
яке негативне ВВРТ найчастіше є невідшкодовуваним для проекту.
Рівняння: ВВРТ = ОО - ФВ.
Управління вартістю: інструменти і методи
Значення ВСТР і ВВРТ можуть бути перетворені в індикатори виконання для відбиття виконання
вартості й строків будь-якого проекту в порівнянні з усіма іншими проектами або в рамках
портфеля проектів. Відхилення й показники корисні для визначення статусу проекту, а також
надають основу для оцінювання підсумкових строків і вартості проекту.
- Індекс виконання строків (ІВСТР) являє собою вимір досягнутих обсягів виконання проекту в
порівнянні із запланованим обсягом. Іноді він використовується разом з індексом виконання
вартості (ІВВРТ) для прогнозування остаточних оцінок завершення проекту. Значення ІВСТР
менше 1,0 указує на те, що виконано менше робіт, чим було заплановано. Значення ІВСТР більше
1,0 указує на те, що виконано більше робіт, чим було заплановано. Тому що ІВСТР вимірює всі
роботи проекту, також повинне бути проаналізоване виконання на критичному шляху, щоб
визначити, буде проект завершений до або після своєї планової дати фінішу. ІВСТР дорівнює
відношенню ОО до ПО.
Рівняння: ІВСТР = ОО/ПО.
Управління вартістю: інструменти і методи
- Індекс виконання вартості (ІВВРТ) являє собою вимір обсягу виконаних робіт з порівняння з
фактичною вартістю виконання проекту. Він уважається найбільш важливим показником УОО й
вимірює вартісну ефективність виконаної роботи. Значення ІВВРТ менше 1,0 указує на
перевитрату вартості для виконаної роботи. Значення ІВВРТ більше 1,0 указує на недоосвоєння
вартості при виконанні на конкретну дату. ІВСТР дорівнює відношенню ОО до ФВ.
Рівняння: ІВВРТ = ОО/ФВ.
Управління вартістю: інструменти і методи
Три показники планового обсягу, освоєного обсягу й фактичної вартості можуть бути об'єктами
контролю, і про них можуть складатися періодичні (звичайно щотижневі або щомісячні) або
сукупні звіти.
ЗВІТ ПО ОСВОЄНОМУ ОБСЯГУ
Звіт по освоєному обсягу є найкращим методом для відображення ходу виконання проекту.
Його перевага полягає в тому, що на одному аркуші паперу можна показати стан значимого критерію
виконання проекту.
У звіті по освоєному обсягу можна побачити, як розподіляються за часом плановані витрати проекту, а
також реальні витрати коштів і обсяги фактично виконаних робіт.
На основі даних цього звіту можуть бути підраховані величини відхилень по витратах і строках.
ЗВІТ ПО ОСВОЄНОМУ ОБСЯГУ
У звіті по освоєному обсягу наводяться всі три показники.
Якщо проект іде в строгій відповідності із запланованими строками й бюджетом, то, очевидно, що всі
три показники будуть збігатися.
Управління вартістю: інструменти і методи
На наступному слайді зображені S-подібні криві, що відображають дані ОО проекту, що перевитрачає
бюджет і відстає від плану.
Освоєний обсяг, плановий обсяг і фактична вартість
Управління вартістю: інструменти і методи
2. Прогнозування У міру виконання проекту команда проекту може розробити прогноз по завершенні
(ППЗ), що може відрізнятися від бюджету по завершенні (БПЗ), ґрунтуючись на ефективності
виконання проекту. Якщо стає очевидним, що БПЗ більше не є досяжним, менеджер проекту
повинен розробити ППЗ.
Розробка ППЗ містить у собі оцінку або передбачення умов і подій, які виникнуть у майбутньому, на
підставі інформації й знань, наявних на момент прогнозування. Прогнози формуються,
оновлюються й перевидаються заново на основі інформації про виконання робіт, що надходить.
Інформація про виконання робіт охоплює минуле виконання проекту й будь-яку інформацію, що
може вплинути на проект у майбутньому.
Управління вартістю: інструменти і методи
Прогноз по завершенні (ППЗ) звичайно заснований на фактичній вартості, витраченої при виконанні
робіт, і прогнозі до завершення (ПДЗ) робіт, що залишилися.
На команду проекту покладений обов'язок передбачати, із чим вона може зіткнутися під час виконання
ПДЗ, на підставі наявного в цей момент досвіду.
Метод УОО ефективний разом з неавтоматичними прогнозами необхідної вартості ППЗ. Найширше
використовуваним підходом прогнозування ППЗ є неавтоматичне підсумовування «знизу нагору»,
проведене менеджером і командою проекту.
Управління вартістю: інструменти і методи
Метод ППЗ «знизу нагору», використовуваний менеджером проекту, заснований на фактичній вартості
й досвіді, отриманих на виконаних роботах, і вимагає проведення нової оцінки до завершення
робіт, що залишилися, по проекту. Даний метод може викликати проблеми, тому що він втручається
в проведення робіт із проекту. Персонал, що виконує роботи із проекту, повинен призупинити свою
роботу, щоб надати детальний ПДЗ «знизу нагору» для робіт, що залишилися. Як правило, на
виконання ПДЗ не закладається окремого бюджету, так що на ці цілі в проекті витрачаються
додаткові кошти.
Рівняння: ППЗ = ФВ + ПДЗ «знизу нагору».
Управління вартістю: інструменти і методи
Неавтоматичний ППЗ менеджера проекту може бути швидко зіставлений з низкою розрахованих ППЗ,
що представляють різноманітні сценарії ризиків. Хоча дані УОО можуть швидко зробити безліч
статистичних ППЗ, нижче описані тільки три найпоширеніші методи:
Дякую за увагу!
Управління інтеграцією в проекті
1. Розробка Статуту проекту
2. Розробка плану управління проектом
3. Керівництво й управління виконанням проекту
4. Моніторинг і управління роботами проекту
5. Здійснення загального управління змінами
6. Завершення проекту або фази
Галузі застосування знань з проектного менеджменту
Статут проекту
Установлює партнерство між виконуючою організацією й організацією, що подала заявку (або
замовником, у випадку зовнішніх проектів).
Затверджений Статут проекту формально ініціює проект.
Менеджер проекту переважно призначається під час розробки Статуту проекту й обов'язково до початку
планування.
Рекомендується, щоб менеджер проекту брав участь у розробці Статуту проекту, тому що даний
документ наділяє менеджера проекту повноваженнями використовувати ресурси для виконання
проекту.
Розробка Статуту проекту:
входи, інструменти, методи й виходи
Блок-схема даних при розробці Статуту проекту
Вхідні дані: Розробка Статуту проекту
1. Опис робіт (Statement of work, SOW) - це словесний опис продуктів або послуг, які повинен зробити
проект.
Для внутрішніх проектів ініціатор або спонсор проекту надає опис робіт на підставі бізнес-потреб,
вимог до продукту або послуги.
Для зовнішніх проектів опис робіт може бути отриманий від замовника як частина документації по
пропозиціях, наприклад запиту пропозиції, запиту інформації, запиту заявок, або як частина
контракту.
Вхідні дані
Розробка Статуту проекту: (продовження)
Перелік робіт відображає:
• Стратегічний план. Усі проекти повинні підтримувати стратегічні цілі організації. Стратегічний
план виконуючої організації повинен розглядатися як один із факторів при прийнятті рішень про
вибір проекту й розстановці пріоритетів.
Вхідні дані
Розробка Статуту проекту: (продовження)
2.Економічне обґрунтування або подібний документ надає необхідну з погляду бізнесу інформацію,
що дозволяє визначити, чи вартий проект необхідних інвестицій.
Звичайно в економічному обґрунтуванні містяться бізнес-потреби й порівняльний аналіз витрат і
результатів для виправдання проекту.
Економічне обґрунтування може написати організація, що подає заявку, або замовник, у випадку
зовнішніх проектів.
Вхідні дані
Розробка Статуту проекту:(продовження)
Економічне обґрунтування створюється як результат дії одного або кількох факторів:
- вимоги ринку (наприклад, ІТ-компанія санкціонує проект з розробки нової версії програмного
продукту у відповідь на зміну законодавства з оподаткування);
- потреба організації (наприклад, тренінгова компанія санкціонує проект по створенню нового курсу
навчання з метою збільшення прибутку);
- вимоги замовника (наприклад, телекомунікаційна компанія санкціонує проект по створенню нового
контакт-центру для нового району);
- технологічний прогрес (наприклад, виробник комп'ютерної техніки санкціонує новий проект з
розробки більш швидкодіючого, економічного й компактного ноутбука з використанням останніх
досягнень у технології виготовлення комп'ютерної пам'яті й електронних компонентів);
- правові вимоги (наприклад, Національний банк санкціонує проект для розробки рекомендацій щодо
інформаційної безпеки комерційних банків);
- екологічні впливи (наприклад, компанія розпочинає проект для зменшення свого впливу на
навколишнє середовище); або
- соціальні потреби (наприклад, неурядова організація в країні, що розвивається, санкціонує проект по
створенню притулків для бездомних).
Вхідні дані
Розробка Статуту проекту:(продовження)
У випадку якщо проект складається з кількох фаз, економічне обґрунтування може періодично
переглядатися для забезпечення того, щоб проект знаходився на правильному шляху до досягнення
вигід для бізнесу.
На ранніх стадіях життєвого циклу проекту періодичний перегляд економічного обґрунтування
спонсорською організацією також допомагає впевнитися, що проект усе ще необхідний.
Вхідні дані
Розробка Статуту проекту: (закінчення)
3 Контракт є входом, якщо проект виконується для зовнішнього замовника.
4 Фактори середовища підприємства, які можуть впливати на процес розробки Статуту проекту,
містять у собі серед іншого:
• державні й промислові стандарти;
• інфраструктуру організації;
• ситуацію на ринку.
5 Активи процесів організації, які можуть впливати на процес розробки Статуту проекту, містять у
собі серед іншого:
• стандартні процеси організації, правила й описи типових процесів для використання в організації;
• шаблони (наприклад, шаблон Статуту проекту);
• історичну інформацію й базу засвоєних уроків.
Інструменти й методи
Розробка Статуту проекту:
1 Експертні оцінки - часто використовуються для оцінювання входів, застосовуваних для розробки
Статуту проекту.
Подібні оцінки й експертизи в даному процесі застосовуються у відношенні будь-яких технічних і
управлінських деталей.
Такі експертизи проводяться будь-якою особою або групою осіб, що володіють спеціальними знаннями
або підготовкою, і доступні з безлічі джерел, включаючи такі:
• консультанти;
• галузеві об'єднання;
• експерти по окремих питаннях;
• зведений бюджет;
• вимоги до схвалення проекту (що складає успіх проекту, хто вирішує, що проект виявився
успішним, і хто підписує проект);
• ім'я й повноваження спонсора або іншої особи (осіб), що затверджує Статут проекту
2. Розробка плану управління проектом
Розробка плану управління проектом – це процес документування дій, необхідних для визначення,
підготовки, інтеграції й координації всіх допоміжних планів.
План управління проектом визначає, як буде виконуватися проект, як буде проводитися його
моніторинг, контроль і закриття.
Зміст плану управління проектом різниться залежно від прикладної області й складності проекту.
План управління проектом розробляється в рамках серії інтегрованих процесів до завершення проекту.
Результатом даного процесу є план управління проектом, що поступово розробляється шляхом
внесення оновлень, контролюється й затверджується в процесі здійснення загального управління
змінами
Розробка плану управління проектом:
входи, інструменти, методи й виходи
Блок-схема даних при розробці плану управління проектом
Вхідні дані
для розробки плану управління проектом
1 Статут проекту
Див. тему “Статут проекту”
Вхідні дані
для розробки плану управління проектом (продовження)
2. Виходи процесів планування.
Будь-які базові й допоміжні плани управління, що є виходами інших процесів планування, є входами для
даного процесу. Вони включають як базові документи (наприклад, ієрархічна структура робіт),
так і допоміжні деталі.
Виходи багатьох процесів планування, що розглянуті нами у відповідній темі інтегруються для
створення плану управління проектом.
Крім того, відновлення даних документів можуть привести до коригування плану управління проектом.
Для проектів інформатизації можуть бути необхідними вхідні дані, що залежать від цієї прикладної
сфери.
Вхідні дані для розробки плану управління проектом (продовження)
3. Фактори середовища підприємства, які можуть впливати на процес розробки плану управління
проектом, містять у собі серед іншого:
• державні й промислові стандарти;
• інформаційні системи управління проектами (наприклад, автоматизовані засоби, такі як програмне
забезпечення для управління розкладом, система управління конфігурацією, система збору й
розподілу інформації або веб-інтерфейси до інших автоматизованих систем, що працюють у
режимі онлайн);
• організаційну структуру й культуру;
• інфраструктуру (наприклад, споруди, що існують й капітальне обладнання);
• управління персоналом (наприклад, директиви по найму й звільненню, оцінки ефективності роботи
співробітників і документи про навчання).
Вхідні дані для розробки плану управління проектом (продовження)
4. Активи процесів організації, які можуть впливати на процес розробки плану управління проектом,
містять у собі серед іншого:
• типові провідні вказівки, робочі інструкції, критерії оцінки пропозицій і критерії вимірювання
виконання;
• шаблон плану управління проектом - елементи плану управління проектом, які можуть бути
оновлені, зокрема:
– провідні вказівки й критерії для адаптації набору стандартних процесів організації з метою
задоволення конкретних потреб проекту;
– провідні вказівки або вимоги до закриття проекту, наприклад критерії підтвердження й
приймання продуктів;
• процедури управління змінами, що включають дії, згідно котрим будуть модифікуватися офіційні
стандарти компанії, політики, плани й процедури або будь-які документи проекту, а також порядок
схвалення й підтвердження будь-яких змін;
Вхідні дані для розробки плану управління проектом (закінчення)
4. Активи процесів організації архіви по минулих проектах (наприклад, базові плани по змісту,
вартості, розкладу й вимірюванню виконання, календарі проектів, сітьові діаграми проекту, реєстри
ризиків, заплановані відповідні дії й певні наслідки ризиків);
• визначення ресурсів і рівнів розвитку навичок, необхідних для виконання робіт із проекту;
• визначення того, які документи проекту будуть піддані процесу формального управління
змінами.
Виходи
розробки плану управління проектом
1 План управління проектом інтегрує й консолідує всі допоміжні плани управління й базові плани,
отримані в результаті процесів планування, і містить у собі:
• обраний для проекту життєвий цикл і процеси, які будуть застосовуватися в кожній фазі;
– опис інструментів і методів, які будуть використані для виконання даних процесів;
• ключові заходи щодо аналізу управління відносно змісту, границь і строків, що полегшують
розгляд проблем і рішень, що очікують прийняття.
Виходи
розробки плану управління проектом (продовження)
План управління проектом може бути складений як на рівні зведення, так і в деталях, і може складатися
з одного або кількох допоміжних планів.
Кожний з допоміжних планів деталізований до того ступеня, що потрібно для конкретного проекту.
Після затвердження плану управління проектом він може змінюватися тільки після того, як буде
створений запит на зміну й схвалений у рамках процесу здійснення загального управління змінами.
Виходи
розробки плану управління проектом (продовження)
Базові плани проекту містять у собі:
• базовий розклад;
• базовий план виконання вартості;
• базовий план по змісту.
Виходи
розробки плану управління проектом (продовження)
Допоміжні плани містять у собі:
• план управління змістом;
• план управління вимогами;
• план управління розкладом;
• план управління вартістю;
• план управління якістю;
• план удосконалення процесів;
• план управління людськими ресурсами;
• план управління комунікаціями;
• план управління ризиками;
• план управління закупівлями.
Виходи
розробки плану управління проектом (закінчення)
Часто базові плани по змісту, розкладу й вартості поєднують у базовий план виконання,
використовуваний у якості загального базового плану проекту, з яким може порівнюватися загальне
виконання.
Базовий план виконання використовується для вимірювання освоєного обсягу.
3. Керівництво й управління виконанням проекту
Загальне управління змінами – процес перевірки всіх запитів на зміну, їхні затвердження й управління
змінами результатів, активів процесів організації, документів проекту й плану управління
проектом.
Процес загального управління змінами проводиться із самого початку проекту й аж до його завершення.
План управління проектом, опис змісту проекту та інші результати підтримуються шляхом проведення
ретельного й постійного управління змінами - відхилення або схвалення змін, що дозволяє
гарантувати, що в переглянутий базовий план включаються тільки схвалені зміни.
Процес загального управління змінами містить у собі такі дії по управлінню змінами, представлені на
різних рівнях деталізації залежно від ходу виконання проекту:
• вплив на фактори, які можуть обійти загальне управління змінами, для того, щоб упроваджувалися у
виконання тільки схвалені зміни;
• своєчасний огляд, аналіз і схвалення запитів на зміну, що представляє виняткову важливість, тому
що повільні рішення можуть негативно вплинути на строки, вартість або здійсненність змін;
• управління схваленими змінами;
• підтримка цілісності базових планів шляхом включення в план управління проектом і документи
проекту тільки схвалених змін;
• аналіз, схвалення або відхилення всіх рекомендованих коригувальних і попереджуючих дій;
• координація змін усього проекту (наприклад, запропонована зміна розкладу найчастіше впливає
також і на вартість, ризики, якість і забезпечення персоналом);
• документування повного впливу запитів на зміну.
Запит на зміну може подати будь-яка зацікавлена сторона, залучена у проект. Хоча зміни можуть бути
ініційовані усно, вони обов'язково повинні бути зареєстровані в писаній формі й передані в систему
управління змінами й/або управління конфігурацією.
Запити на зміни піддаються процесам, зазначеним у системах управління змінами й управління
конфігурацією. Ці процеси, пов'язані із запитами на зміну, можуть вимагати інформацію про
очікуваний вплив на строки й на вартість.
Кожний задокументований запит на зміну або схвалюється, або відхиляється якоюсь уповноваженою
особою з команди управління проектом або сторонньої організації. У багатьох проектах менеджер
проекту наділений повноваженнями схвалювати певні види запитів на зміну, що зазначено в
документах про ролі й обов'язки в рамках проекту.
За необхідності процес здійснення загального управління змінами містить у собі раду по управлінню
змінами (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. Моніторинг і контроль ризиків
• Ризик
• Невизначеність
• Імовірність ризиків
• Вимірювання ризиків
•
Ризик — це небезпека небажаних відхилень від очікуваних станів проекту в майбутньому, із
урахуванням яких і приймаються рішення в даний момент.
Ризик - це невизначена подія або умова, яка, у випадку настання, впливає хоча б на одну ціль проекту.
Під цілями в цьому випадку розуміються зміст, строки, вартість і якість.
• зміна вимог;
Ризик — це не обов’язково погано. Це загальна властивість всіх проектів. Будь-який проект має деяку
міру невизначеності через початкові обмеження і мінливе оточення, в якому вони виконуються.
Ризик має три основні атрибути:
• ймовірність;
• Фінансові втрати
• Трудові втрати
• Особливі види втрат
• Втрати часу
• Соціальні втрати
• Нежиттєздатність проекту
• Податковий ризик
Ймовірність ризику (risk probability) — це міра можливості того, що наслідок (дія) ризику дійсно буде
мати місце
Важливість ризику (risk exposure) — показник, який може використовуватися в процесі ухвалення
рішення і як механізм контролю за ризиками в проекті:
VR = A * q,
де: VR — важливість ризику;
A — загроза (наслідок, дія) ризику (небажаної події);
q — ймовірність її настання.
Загроза ризику (risk impact) — міра серйозності негативних наслідків, рівень збитків або оцінка
потенційних можливостей, пов’язаних з ризиком.
Є кілька видів випадків, які містять ризик для проекту:
1. Випадки, які можуть статися.
2. Випадки, які матимуть великі наслідки, якщо вони відбудуться.
3. Випадки поза вашим контролем.
4. Випадки, про які вам відомо дуже мало.
Класифікація основних видів ризиків в проекті
У залежності від джерела виникнення
У залежності від місця виникнення
У залежності від тяжкості проявів
За ступенем передбачуваності
За можливістю страхування
Існує також класифікація, яка поєднує критерії ймовірності (Р) та наслідків (І) ризику
Класифікація основних видів ризиків в проекті
У залежності від джерела виникнення:
– природно-кліматичні;
– технічні;
– виробничі;
– економічні;
– ринкові;
– фінансові;
– соціальні;
– політичні;
– інноваційні;
– регіональні;
– галузеві;
– ризики навмисних дій (вандалізм, нечесність).
Класифікація основних видів ризиків в проекті
У залежності від місця виникнення:
– зовнішні;
– внутрішні.
У залежності від тяжкості проявів:
– втрачена вигода;
– збитки;
– втрата;
– банкрутство.
Класифікація основних видів ризиків в проекті
За ступенем передбачуваності:
– передбачувані з малою ймовірністю;
– непередбачувані.
За можливістю страхування:
– ризики, що страхуються;
– ризики, що не страхуються.
Класифікація основних видів ризиків в проекті
Існує також класифікація, яка поєднує критерії ймовірності (Р) та наслідків (І) ризику.
За цією класифікацією ризики аналогічно до тварин поділяються на такі категорії:
«Тигри». Висока ймовірність, вагомі наслідки. Ці ризики є небезпечними і повинні бути негайно
нейтралізовані, тобто ризики мають бути зменшені ще на ранньому етапі ЖЦ проекту.
«Алігатори». Низька ймовірність, вагомі наслідки. Це небезпечні ризики, яких можна уникнути, якщо їх
ретельно відслідковувати. За «алігаторами» слід спостерігати і розробити план дій, щоб зупинити
їхнє втручання в проект.
«Цуценята». Висока ймовірність, незначні наслідки. За «Цуценятами» також спостерігають, але не так
пильно і з менш терміновими планами локалізації.
«Кошенята». Низька ймовірність, незначні наслідки. «Кошенята» керівником проекту можуть бути
проігноровані.
• Якісне оцінювання ризиків - якісний аналіз ризиків і умов їхнього виникнення з метою
визначення їхнього впливу на успіх проекту.
Відносна шкала наслідків містить лише описові позначення, наприклад «дуже низький», «низький»,
«середній», «високий» і «дуже високий», які розташовані в порядку зростання максимальної сили
впливу ризику згідно з визначенням організації
Деякі пояснення - Результати
- Уточнена готовність зацікавлених сторін проекту приймати ризики. У ході процесу планування
управління ризиками готовність зацікавлених сторін проекту приймати ризики може коректуватися
стосовно до конкретного проекту.
- Формат звітності. Містить визначення, у який спосіб провадиться документування, аналіз і обмін
інформацією про результати процесів управління ризиками. Дає опис змісту й формату реєстру
ризиків, а також інших необхідних звітів по ризиках.
- Відстеження. Документує порядок реєстрації всіх операцій по ризиках для цілей даного проекту, а
також для майбутніх проектів і включення в документи по накопичених знаннях. Документує, у
яких випадках і у який спосіб буде проводитися аудит процесів управління ризиками.
Організація може використовувати розроблену заздалегідь схему категоризації типових ризиків, що
може приймати форму простого списку категорій або оформлятися у вигляді ієрархічної структури
ризиків.
Ієрархічна структура ризиків - це ієрархічно організоване зображення певних ризиків проекту,
згрупованих по категоріях і підкатегоріях, що визначає різні області й причини потенційних ризиків.
• Ризик
• Невизначеність
• Імовірність ризиків
• Вимірювання ризиків
•
Ризик — це небезпека небажаних відхилень від очікуваних станів проекту в майбутньому, із
урахуванням яких і приймаються рішення в даний момент.
Ризик - це невизначена подія або умова, яка, у випадку настання, впливає хоча б на одну ціль проекту.
Під цілями в цьому випадку розуміються зміст, строки, вартість і якість.
Ризик може бути викликаний однією або кількома причинами й у випадку виникнення може вплинути на
один або кілька аспектів.
Можна звести до мінімуму ризик у проекті шляхом або усунення обмежень (що є достатньо
проблематичним), або пошуку і зниження невизначеності.
До умов виникнення ризиків можуть також належати аспекти середовища організації або проекту, що
сприяють збільшенню ризику (наприклад, невдалий вибір методів при управлінні проектом,
відсутність загальних систем управління, одночасне виконання кількох проектів або залежність від
зовнішніх зацікавлених сторін проекту, яких неможливо контролювати).
Фактори невизначеності
Ставлення до ризику з боку окремих осіб і груп осіб обумовлено їхнім розумінням ризику й
відповідною реакцією на його виникнення.
В основі даних відносин лежать сприйняття, готовність приймати ризики й інші види
необ'єктивності, які необхідно старанно виявляти.
Для кожного проекту повинен бути розроблений послідовний підхід до ризиків, а інформація про ризики
й управління ними повинна бути відкритою й достовірною. Реагування на ризики відображає те, як
організація розуміє баланс між прийняттям ризиків і відхиленням від них.
Для досягнення успіху організація повинна вживати заздалегідь і послідовно попереджуючі дії по
управлінню ризиками протягом усього проекту.
На всіх рівнях організації повинен бути зроблений усвідомлений вибір для активної ідентифікації й
здійснення ефективного управління ризиками протягом усього життєвого циклу проекту.
Ризик існує з моменту зародження задуму проекту. Просування проекту вперед без виконання
попереджуючих дій по управлінню ризиками збільшує вплив, який певні ризики можуть чинити на
проект, що може призвести до невдачі.
Взаємозв'язок основних характеристик ризиків
Основні фактори ризику в проектах інформатизації
• зміна вимог;
Ризик — це не обов’язково погано. Це загальна властивість всіх проектів. Будь-який проект має деяку
міру невизначеності через початкові обмеження і мінливе оточення, в якому вони виконуються.
Ризик має три основні атрибути:
• ймовірність;
• Фінансові втрати
• Трудові втрати
• Втрати часу
• Соціальні втрати
• Нежиттєздатність проекту
• Податковий ризик
Ймовірність ризику (risk probability) — це міра можливості того, що наслідок (дія) ризику дійсно буде
мати місце
Важливість ризику (risk exposure) — показник, який може використовуватися в процесі ухвалення
рішення і як механізм контролю за ризиками в проекті:
VR = A * q,
де: VR — важливість ризику;
A — загроза (наслідок, дія) ризику (небажаної події);
q — ймовірність її настання.
Загроза ризику (risk impact) — міра серйозності негативних наслідків, рівень збитків або оцінка
потенційних можливостей, пов’язаних з ризиком.
Є кілька видів випадків, які містять ризик для проекту:
1. Випадки, які можуть статися.
2. Випадки, які матимуть великі наслідки, якщо вони відбудуться.
3. Випадки поза вашим контролем.
4. Випадки, про які вам відомо дуже мало.
Класифікація основних видів ризиків в проекті
У залежності від джерела виникнення
У залежності від місця виникнення
У залежності від тяжкості проявів
За ступенем передбачуваності
За можливістю страхування
Існує також класифікація, яка поєднує критерії ймовірності (Р) та наслідків (І) ризику
Класифікація основних видів ризиків в проекті
У залежності від джерела виникнення:
– природно-кліматичні;
– технічні;
– виробничі;
– економічні;
– ринкові;
– фінансові;
– соціальні;
– політичні;
– інноваційні;
– регіональні;
– галузеві;
– ризики навмисних дій (вандалізм, нечесність).
Класифікація основних видів ризиків в проекті
У залежності від місця виникнення:
– зовнішні;
– внутрішні.
У залежності від тяжкості проявів:
– втрачена вигода;
– збитки;
– втрата;
– банкрутство.
Класифікація основних видів ризиків в проекті
За ступенем передбачуваності:
– передбачувані з малою ймовірністю;
– непередбачувані.
За можливістю страхування:
– ризики, що страхуються;
– ризики, що не страхуються.
Класифікація основних видів ризиків в проекті
Існує також класифікація, яка поєднує критерії ймовірності (Р) та наслідків (І) ризику.
За цією класифікацією ризики аналогічно до тварин поділяються на такі категорії:
«Тигри». Висока ймовірність, вагомі наслідки. Ці ризики є небезпечними і повинні бути негайно
нейтралізовані, тобто ризики мають бути зменшені ще на ранньому етапі ЖЦ проекту.
«Алігатори». Низька ймовірність, вагомі наслідки. Це небезпечні ризики, яких можна уникнути, якщо їх
ретельно відслідковувати. За «алігаторами» слід спостерігати і розробити план дій, щоб зупинити
їхнє втручання в проект.
«Цуценята». Висока ймовірність, незначні наслідки. За «Цуценятами» також спостерігають, але не так
пильно і з менш терміновими планами локалізації.
«Кошенята». Низька ймовірність, незначні наслідки. «Кошенята» керівником проекту можуть бути
проігноровані.
• Якісна оцінка ризиків - якісний аналіз ризиків і умов їхнього виникнення з метою визначення
їхнього впливу на успіх проекту.
Ці процеси взаємозалежні один з одним, а також із процесами з інших галузей знань. Залежно від потреб
проекту в кожному процесі можуть брати участь одна або кілька осіб. Кожний процес відбувається
в кожному проекті не менш одного разу й виконується в одній або кількох фазах проекту, якщо
проект розбитий на фази. Хоча процеси представлені тут у вигляді дискретних елементів із чітко
означеними границями, на практиці вони накладаються один на одного й впливають; такі
накладення й взаємозв'язки тут не описані
• категорії ризиків;
• стандартні шаблони;
• ролі та відповідальності;
• накопичені знання; і
• реєстри зацікавлених сторін проекту, які теж є важливими ресурсами і які слід розглядати як
елементи процесу створення ефективних планів управління ризиками.
Деякі пояснення - Інструменти і методи
1 Наради по плануванню й аналіз. У нарадах можуть брати участь менеджер проекту, окремі члени
команди проекту й зацікавлені сторони проекту, представники організації, відповідальні за дії по
плануванню ризиків і реагуванню на них, і, при необхідності, інші особи.
На таких нарадах складаються високорівневі плани дій по управлінню ризиками. Також розробляються
елементи вартості й заплановані дії по управлінню ризиками, які включаються відповідно в бюджет
і розклад проекту.
Можуть визначатися або переглядатися підходи до використання резервів на можливі втрати й ризиків.
Розподіляється відповідальність по управлінню ризиками. Наявні в організації загальні шаблони,
що стосуються категорій ризиків і визначення термінів (наприклад, рівні ризику, імовірність
виникнення ризиків по типах, вплив ризиків по типах цілей, а також матриця ймовірності й
впливи), адаптуються до конкретного проекту з урахуванням його специфіки. Якщо шаблонів для
інших кроків процесу не існує, вони можуть бути створені в ході даних нарад. Виходи цих операцій
поєднуються в плані управління ризиками.
Деякі пояснення - Результати
1 план управління ризиками описує структуру й порядок здійснення управління ризиками в рамках
проекту. Цей план включається до складу плану управління проектом і містить такі елементи:
- Методологія. Визначення підходів, інструментів і джерел даних, які можуть використовуватися для
управління ризиками в даному проекті.
- Ролі й відповідальності. Визначення керівних і допоміжних членів команди, а також членів команди,
відповідальних за управління ризиками, для кожного виду операцій, включених у план управління
ризиками, і роз'яснення їхньої відповідальності.
- Розробка бюджету. Призначення ресурсів і оцінка коштів, необхідних для управління ризиками (ці
дані включаються в базовий план виконання вартості), а також розробка процедур по використанню
резерву на можливі втрати.
Деякі пояснення - Результати
- Визначення строків. Визначення строків і частоти виконання процесів управління ризиками протягом
усього життєвого циклу проекту, розробка процедур по використанню резервів розкладу на
можливі втрати, а також визначення дій по управлінню ризиками, які будуть включені в розклад
проекту.
• журнал допущень;
• сітьові діаграми;
• базові плани; і
• академічні дослідження;
• бенчмаркинг;
• промислові дослідження; і
• ставлення до ризиків.
Деякі пояснення: Ідентифікація ризиків: входи
11 Активи процесів організації, які можуть впливати на процес ідентифікації ризиків, містять у собі,
серед іншого:
• накопичені знання.
Деякі пояснення:
Ідентифікація ризиків: інструменти й методи
1 Аналіз документації
Можна здійснювати структурований аналіз документації по проекту, включаючи плани, допущення,
архіви попередніх проектів, контракти й інші джерела. Якість планів, а також погодженість планів і
їхня відповідність вимогам і допущенням проекту можуть служити показниками можливості
ризиків у проекті.
Деякі пояснення:
Ідентифікація ризиків: інструменти й методи
2 Методи збору інформації:
Мозковий штурм. Метою мозкового штурму є створення всеосяжного списку ризиків проекту. Як
правило, мозковий штурм проводить команда проекту, часто за участю ряду експертів з різних
областей, що не є членами команди. За основу може прийматися система категорій ризиків,
наприклад ієрархічна структура ризиків. Далі ризики підлягають ідентифікації й категоризації по
типах, а їхнє визначення - уточненню.
Метод Дельфи - це спосіб досягнення консенсусу між експертами з питань ризиків проекту, що беруть
участь анонімно. За допомогою опитувального аркуша ведучий збирає ідеї про важливі ризики
проекту. Складаються резюме відповідей, які потім повертаються експертам для подальших
коментарів. Консенсус може бути досягнуто за кілька циклів даного процесу. Метод Дельфи
допомагає перебороти необ'єктивність і усуває надлишковий вплив окремих осіб на результат
роботи.
Опитування серед досвідчених учасників проекту, зацікавлених сторін проекту або експертів у цій
галузі може сприяти ідентифікації ризиків.
Аналіз першопричин являє собою особливий метод визначення проблеми, виявлення основних причин,
що призвели до неї, і розробки попереджувальних дій.
Деякі пояснення:
Ідентифікація ризиків: інструменти й методи
3 Аналіз контрольних списків, які можуть розроблятися на основі історичної інформації й знань,
отриманих у ході виконання попередніх аналогічних проектів або з інших джерел інформації. Хоча
контрольний список може бути коротким і простим, неможливо створити вичерпний список.
Команда повинна приділяти особливу увагу питанням, які не знайшли свого відбиття в
контрольному списку. При завершенні проекту контрольний список варто переглядати з метою
внесення в нього нових накопичених знань і поліпшення для використання в майбутніх проектах.
Деякі пояснення:
Ідентифікація ризиків: інструменти й методи
4 Аналіз допущень
Кожний проект і кожний визначений ризик проекту задумується й розробляється на підставі ряду
гіпотез, сценаріїв і допущень.
Аналіз допущень досліджує обґрунтованість допущень стосовно до проекту. Даний аналіз дозволяє
ідентифікувати ризики проекту, що виникають внаслідок неточності, нестабільності,
суперечливості або неповноти допущень.
Деякі пояснення:
Ідентифікація ризиків: інструменти й методи
5 Методи складання діаграм
До методів відображення ризиків у вигляді діаграм належать:
• Блок-схеми процесу або системні діаграми. Цей вид графічного відображення демонструє
порядок взаємодії різних елементів системи між собою і їхні причинно-наслідкові зв'язки.
Можна істотно поліпшити виконання проекту, зосередивши зусилля на ризиках, що мають найвищий
пріоритет.
При якісному аналізі ризиків визначають пріоритети ідентифікованих ризиків на підставі ймовірності
або можливості їхнього настання, їхній вплив на досягнення цілей проекту у випадку настання, а
також з урахуванням ряду інших факторів (наприклад, часових рамок реагування й готовності
організації приймати ризики, закладені в обмеженнях проекту за вартістю, термінами, змістом і
якістю).
Якісний аналіз ризиків звичайно є швидким і ефективним за вартістю способом розстановки пріоритетів
для планування реагування на ризики й, при необхідності, закладає основу для кількісного аналізу
ризиків. Процес якісного аналізу ризиків повинен періодично повторюватися протягом життєвого
циклу проекту, щоб він постійно відповідав змінам ризиків проекту. Даний процес може привести
до виконання кількісного аналізу ризиків або прямо до планування реагування на ризики.
Якісний аналіз ризиків: входи, інструменти, методи і виходи
Деякі пояснення:
Якісний аналіз ризиків: входи
1 Реєстр ризиків Розглянуто раніше
2 План управління ризиками
Для виконання якісного аналізу ризиків істотними є такі елементи плану управління ризиками:
• категорії ризиків,
• бази даних по ризиках, які можуть бути отримані із промислових або приватних джерел.
Деякі пояснення:
Якісний аналіз ризиків: інструменти і методи
1 оцінювання ймовірності виникнення й впливу ризиків
Оцінювання ймовірності виникнення ризиків передбачає проведення дослідження можливості настання
того або іншого ризику. При оцінці впливу ризику визначається потенційний ефект, який він може
зробити на цілі проекту (наприклад, строки, вартість, якість або виконання), включаючи
негативний вплив для загроз і позитивний вплив для сприятливих можливостей.
Імовірність і вплив оцінюються для кожного визначеного ризику. Ризики можуть бути оцінені в ході
опитувань або нарад з учасниками, яких вибирають залежно від їхньої поінформованості про
обговорювані категорії ризиків. У число опитуваних можуть входити члени команди проекту й, у
ряді випадків, особи, що не беруть участі в проекті, але широко обізнані з цією галуззю.
Деякі пояснення:
Якісний аналіз ризиків: інструменти і методи
Під час опитування або наради оцінюється ступінь імовірності виникнення кожного ризику і його
впливу на кожну із цілей проекту.
Також фіксується пояснювальна інформація, у тому числі допущення, що пояснюють установлені рівні
ризиків.
Імовірність виникнення й впливу ризиків ранжируються відповідно до визначень, представлених у плані
управління ризиками.
Ризики з низьким ступенем імовірності й впливи включаються в список ризиків, за якими надалі
ведеться спостереження.
Деякі пояснення:
Якісний аналіз ризиків: інструменти і методи
2 Матриця ймовірності й впливу
Розміщення пріоритетів між ризиками для наступного кількісного аналізу й реагування здійснюється на
підставі рейтингу ризиків. Звичайно правила рейтингової системи ризиків визначаються
організацією заздалегідь перед початком проекту й включаються в активи процесів організації.
Правила рейтингової системи ризиків можуть бути адаптовані до конкретного проекту в ході
процесу планування управління ризиками.
Деякі пояснення:
Якісний аналіз ризиків: інструменти і методи
Оцінювання важливості кожного ризику й, отже, його пріоритету, як правило, здійснюється за
допомогою таблиці відповідності або матриці ймовірності й впливу (наступний слайд).
Така матриця визначає комбінації ймовірності й впливу, які дозволяють присвоювати ризикам рейтинги
низького, середнього або високого пріоритету.
Область темно-сірого кольору (найвищі чисельні значення) позначає високий рівень ризику, світліша
область (найменші числові значення) позначає низький рівень ризику, а найясніша (середнього
числового значення) позначає середній рівень ризику.
Деякі пояснення:
Якісний аналіз ризиків: інструменти і методи
3 Оцінка якості даних про ризики
Для того щоб результати якісного аналізу ризиків були надійними, необхідні точні й об'єктивні дані.
Аналіз якості даних про ризики є методом оцінки корисності даних про ризики для управління
ризиками. Аналіз містить у собі вивчення глибини розуміння ризику, а також точності, якості,
надійності й повноти даних про ризик. Якщо якість даних неприйнятна, можливо, буде потрібно
зібрати більш якісні дані.
Деякі пояснення:
Якісний аналіз ризиків: інструменти і методи
4 Категоризація ризиків
Для визначення областей проекту, що мають найбільшу невизначеність, ризики проекту можна
категоризувати за джерелом ризику (наприклад, за допомогою ієрархічної структури ризиків), по
області проекту, що торкає ризик (наприклад, за допомогою ІСР) або по якомусь іншому критерію
(наприклад, по фазі проекту). Ефективну систему реагування на ризики можна розробити на основі
угруповання ризиків по їхніх головних причинах.
Деякі пояснення:
Якісний аналіз ризиків: інструменти і методи
5 Оцінка терміновості ризиків
Ризики, що вимагають негайного реагування, можуть розглядатися як найбільш термінові для вживання
відповідних заходів. Показниками пріоритетності можуть слугувати час реагування на ризик,
симптоми й ознаки ризику, а також рейтинг ризику. У деяких якісних аналізах оцінка терміновості
ризику може бути об'єднана з ранжируванням ризиків на основі матриці ймовірності й впливу для
визначення кінцевого рейтингу серйозності ризику.
Деякі пояснення:
Якісний аналіз ризиків: інструменти і методи
6 Експертна оцінка
Для оцінки ймовірності виникнення й впливу кожного ризику з метою визначення його розташування в
матриці, показаної на слайді 61, потрібна експертна оцінка.
Експертами, як правило, є особи, що мають досвід участі в подібних проектах, що мали місце в не
занадто віддаленому минулому. Крім того, експертами є особи, що займаються плануванням і
управлінням конкретного проекту, зокрема відносно специфіки даного проекту. Надійність
експертних оцінок часто одержують у ході семінарів або опитувань по зниженню ризиків. Під час
даного процесу необхідно враховувати необ'єктивність експертів.
Деякі пояснення:
Якісний аналіз ризиків: виходи
Ведення реєстру ризиків починається в процесі ідентифікації ризиків. Відновлення реєстру ризиків на
основі інформації, одержуваної в результаті якісного аналізу ризиків, містять у собі:
Кількісний аналіз ризиків - це процес чисельного аналізу впливу виявлених ризиків на загальні цілі
проекту
Кількісна оцінка ризиків
визначає ймовірність виникнення ризиків і вплив наслідків ризиків на проект, що допомагає групі
управління проектами вірно приймати рішення й уникати невизначеностей.
Кількісний аналіз ризиків проводиться відносно тих ризиків, які в результаті процесу якісного аналізу
були класифіковані як такі, що потенційно й істотно впливають на конфронтуючі вимоги проекту.
У процесі кількісного аналізу ризиків оцінюється вплив цих ризиків у випадку їхнього настання. Він
може використовуватися для присвоєння числового рейтингу окремо для кожного із цих ризиків
або для оцінювання спільного впливу всіх ризиків на проект.
Даний аналіз також надає кількісний підхід до прийняття рішень в умовах невизначеності.
Деякі пояснення:
Кількісний аналіз ризиків: входи
1 Реєстр ризиків. Розглянуто раніше
2 План управління ризиками. Розглянуто раніше
3 План управління вартістю
План управління вартістю проекту встановлює формат і критерії планування, структурування, оцінки,
розробки бюджету й управління вартістю проекту.
Ці контрольні елементи дозволяють визначити структуру й/або підхід до виконання кількісного аналізу
плану по бюджету або за вартістю.
Деякі пояснення:
Кількісний аналіз ризиків: входи
4 План управління розкладом проекту встановлює формат і критерії розробки й контролю розкладу
проекту.
Ці контрольні елементи й характер самого розкладу дозволяють визначити структуру й/або підхід до
виконання кількісного аналізу розкладу.
5 Активи процесів організації, які можуть впливати на процес кількісного аналізу ризиків, містять у
собі, серед іншого:
• Аналіз чутливості.
• Аналіз очікуваного грошового значення.
• Моделювання й імітація.
Деякі пояснення:
Кількісний аналіз ризиків: інструменти й методи
Аналіз чутливості. Аналіз чутливості допомагає визначити, які ризики мають найбільший потенційний
вплив на проект. У процесі аналізу встановлюється, у якому ступені невизначеність кожного
елемента проекту відображається на розглянутій цілі проекту, за умови, що всі інші невизначені
елементи приймають базові значення. Одним з типових способів відображення результатів аналізу
чутливості є діаграма «торнадо», що корисна при порівнянні відносної важливості й впливу
змінних, що мають високий ступінь невизначеності, з іншими, більш стабільними змінними.
Деякі пояснення:
Кількісний аналіз ризиків: інструменти й методи
Аналіз очікуваного грошового значення - це статистична концепція, що дозволяє розрахувати
середній результат, коли в майбутньому можуть відбутися або не відбутися ті або інші сценарії
(тобто аналіз в умовах невизначеності).
Аналіз очікуваного грошового значення сприятливих можливостей, як правило, виражається в
позитивних величинах, а ризики - у негативних.
Для даного аналізу потрібно нейтральне стосовно ризиків допущення, яке не схильне до надмірного
ризику, і навпаки, яке, повністю його не відкидає.
Щоб розрахувати очікуване грошове значення для проекту, необхідно помножити значення кожного
можливого результату на ймовірність його настання, а потім скласти разом отримані значення.
Найчастіше даний тип аналізу використовується при аналізі дерева рішень.
Деякі пояснення:
Кількісний аналіз ризиків: інструменти й методи
Моделювання й імітація. При імітації проекту використовується модель для визначення можливих
впливів докладно описаних невизначеностей на результати проекту в цілому. Ітеративна імітація,
як правило, проводиться за допомогою методу Монте-Карло. При імітації модель проекту
розраховується безліч разів (ітеративно), при цьому для кожної ітерації вхідні значення (наприклад,
оцінки вартості й тривалості операцій) вибираються довільно з розподілів ймовірностей цих
змінних. У ході ітерацій розраховується розподіл ймовірностей (наприклад, загальна вартість або
дата завершення). При аналізі ризиків вартості методом імітування використовується оцінка
вартості. При аналізі ризиків розкладу використовується сітьова діаграма розкладу й оцінка
тривалості.
Деякі пояснення:
Кількісний аналіз ризиків: інструменти й методи
3 Експертна оцінка (в ідеалі залучення експертів, що мають значимий недавній досвід) потрібна для
визначення потенційного впливу на вартість і строки для оцінювання ймовірності й визначення
входів (наприклад, розподілів ймовірностей) для інструментів.
Експертна оцінка також відіграє певну роль при інтерпретації даних. Експерти повинні бути здатні
визначати недоліки інструментів, а також їхні відносні переваги. Експерти можуть визначити
придатність певного інструмента з урахуванням можливостей і культури організації.
Деякі пояснення:
Кількісний аналіз ризиків: виходи
1 оновлення реєстру ризиків
Провадиться подальше оновлення реєстру ризиків для включення в нього кількісного звіту по
ризиках, у якому деталізуються кількісні підходи, виходи й рекомендації. Оновленню
підлягають такі основні елементи:
Заплановані дії по реагуванню на ризики повинні відповідати серйозності ризиків, бути економічно
ефективними в розв'язанні проблеми, реалістичними в контексті проекту й погодженими з усіма
залученими сторонами.
Крім того, необхідно, щоб за їхнє виконання відповідало конкретна особа.
Дії по реагуванню на ризики також повинні бути своєчасними.
Часто потрібен вибір найкращого способу реагування на ризики з кількох можливих варіантів.
Планування реагування на ризики: входи, інструменти, методи і виходи
Деякі пояснення:
Планування реагування на ризики: входи
1 Реєстр ризиків. У реєстрі ризиків вказуються:
• ідентифіковані ризики;
• першопричини ризиків;
• симптоми й ознаки;
– Відхилення.
– Передача.
– Зниження.
Ці три типові стратегії реагування на появу негативних загроз, або ризиків для досягнення цілей
проекту.
– Прийняття.
Ця стратегія, може використовуватися як для негативних ризиків (загроз), так і для позитивних ризиків
(сприятливих можливостей).
Деякі пояснення:
Планування реагування на ризики: інструменти й методи
Відхилення. Відхилення від ризиків має на увазі зміну плану управління проектом таким чином, щоб
повністю виключити загрозу. Менеджер проекту також може захистити цілі проекту від впливу
ризиків або змінити ціль, що піддається небезпеці (наприклад, розширити рамки розкладу, змінити
стратегію або скоротити зміст). Найбільш радикальною стратегією відхилення є повне закриття
проекту. Від деяких ризиків, що виникають на ранній стадії проекту, можна ухилитися шляхом
уточнення вимог, одержання інформації, поліпшення комунікацій або проведення експертизи.
Деякі пояснення:
Планування реагування на ризики: інструменти й методи
Передача. Для передачі ризику потрібно перекласти весь негативний вплив загрози або його частину, а
також відповідальність за реагування на третю сторону.
При передачі ризику відповідальність за управління ним перекладається на іншу сторону; ризик при
цьому не усувається.
Передача відповідальності за ризик найбільш ефективна відносно фінансових ризиків.
Передача ризику практично завжди має на увазі виплату премії за ризик стороні, що бере на себе ризик.
Інструменти передачі можуть бути досить різноманітними й містять у собі, серед іншого:
• використання страховки,
– Використання.
– Розподіл.
– Збільшення.
– Прийняття.
Четверта стратегія, «прийняття», може використовуватися як для негативних ризиків (загроз), так і для
позитивних ризиків (сприятливих можливостей).
Деякі пояснення:
Планування реагування на ризики: інструменти й методи
Використання. Ця стратегія може бути обрана для реагування на ризики з позитивним впливом, якщо з
погляду організації необхідно, щоб дана сприятлива можливість гарантовано була реалізована.
Ця стратегія призначена для усунення невизначеності, пов'язаної з певним позитивним ризиком, за
допомогою заходів, що забезпечують появу можливості.
До числа заходів прямого реагування на дану можливість належать: залучення до участі в проекті
найбільш талановитого персоналу організації з метою скоротити час, необхідний для його
завершення, або забезпечити меншу вартість, ніж планувалося спочатку.
Деякі пояснення:
Планування реагування на ризики: інструменти й методи
Розподіл позитивного ризику означає передачу частини або всієї відповідальності за можливість третій
стороні, здатній краще інших скористатися в інтересах проекту сприятливою можливістю, що
з’явилася.
До числа заходів щодо розподілу належать: утворення партнерств зі спільною відповідальністю за
ризики, команд, спеціалізованих компаній або спільних підприємств, які можуть засновуватися з
конкретною метою одержання всіма сторонами переваг тієї або іншої можливості .
Деякі пояснення:
Планування реагування на ризики: інструменти й методи
Збільшення. Ця стратегія використовується для підвищення ймовірності виникнення й/або позитивного
впливу можливості.
Визначення й максимізація ключових факторів, що обумовлюють появу цих позитивних впливів, можуть
підвищити ймовірність їхнього настання. Приклади збільшення можливостей містять у собі
виділення додаткових ресурсів для операції з метою її раннього завершення.
Прийняття можливості - це бажання скористатися перевагою можливості у випадку її настання без
активного переслідування можливості.
Деякі пояснення:
Планування реагування на ризики: інструменти й методи
3 Стратегії реагування на можливі втрати
Деякі способи реагування призначені для використання тільки у випадку настання певних подій.
Стосовно деяких ризиків команда проекту може задіяти план реагування на ризики, що може бути
уведений у дію тільки при заздалегідь визначених умовах, якщо є впевненість у достатній кількості
ознак для виконання плану.
Необхідно визначити й відслідковувати події, які запускають механізм реагування на можливі втрати,
наприклад пропуск проміжних контрольних подій або одержання більш високого рівня
пріоритетності в постачальника.
Деякі пояснення:
Планування реагування на ризики: інструменти й методи
4 Експертна оцінка є входом, одержуваним від добре обізнаних сторін, щодо дій, що вживаються у
відношенні конкретних і визначених ризиків.
Експертну оцінку може надати особа або група осіб, що мають фахову освіту, знання, навички, досвід
або підготовку в галузі розробки заходів реагування на ризики.
Деякі пояснення:
Планування реагування на ризики: виходи
1 Оновлення реєстру ризиків. У процесі планування реагування на ризики вибираються,
затверджуються й включаються до реєстру відповідні способи реагування на ризики.
Реєстр ризиків повинен бути складений таким чином, щоб ступінь його деталізації відповідав
ранжируванню по пріоритетах і запланованих діях по реагуванню на ризики. Часто ризики
високого й середнього рівня пріоритетності описуються більш докладно.
Ризики, яким був присвоєний низький рівень пріоритетності, включаються в список для періодичного
контролю.
Деякі пояснення:
Планування реагування на ризики: виходи
Елементи реєстру ризиків можуть містити в собі:
-виявлені ризики; їхні описи; область (і) проекту (наприклад, елемент ІСР), піддана (ий) їхньому впливу;
їх причини (наприклад, елемент ієрархічної структури ризиків); а також характер і ступінь їхнього
впливу на цілі проекту;
-осіб, відповідальних за ризики, і покладену на них відповідальність;
-виходи процесу якісного аналізу, включаючи список ризиків проекту, упорядкованих по пріоритетності;
-заздалегідь погоджені стратегії реагування на ризики; конкретні дії по реалізації обраної стратегії
реагування;
-умови, симптоми й ознаки настання ризиків;
-операції, внесені в бюджет і розклад, необхідні для реалізації обраних способів реагування на ризики;
-плани на випадок можливих втрат і умови, при яких вони приводяться у виконання;
-резервні плани, використовувані як відповідна реакція на виникнення ризику, якщо первісне реагування
на ризик виявилося неадекватним;
-залишкові ризики, що збереглися після запланованого реагування, а також ризики, які були прийняті
свідомо;
-вторинні ризики, що виникають як прямий наслідок застосування реагування на ризики;
-резерви на можливі втрати, розраховані на основі даних кількісного аналізу ризиків проекту й порогів
ризиків організації.
Деякі пояснення:
Планування реагування на ризики: виходи
2 Контрактні угоди, пов'язані з ризиками
Щоб чітко визначити відповідальність кожної зі сторін на випадок виникнення кожного окремого ризику,
складаються контрактні угоди (наприклад, договори страхування, надання послуг і ін.).
Це може відбуватися за допомогою зниження або передачі всієї загрози чи її частини, або збільшення
або розподілу всієї можливості чи її частини.
Обраний тип контракту також представляє механізм розподілу ризиків.
Дані рішення є входами процесу планування закупівель.
Деякі пояснення:
Планування реагування на ризики: виходи
3 Оновлення плану управління проектом. Елементи плану управління проектом, що можуть бути
оновлені, містять у собі, серед іншого:
• Базовий розклад.
• Базовий розклад.
Моніторинг і контроль
У процесі контролю й управління ризиками застосовуються такі методи, як аналіз відхилень і тенденцій,
для виконання яких необхідні дані про виконання, зібрані в процесі виконання проекту. Інші цілі
процесу контролю й управління ризиками покликані визначити:
• статус результатів;
• хід виконання розкладу; і
•4 Звітипонесені витрати.
про виконання
У звітах про виконання наводиться інформація, отримана в результаті вимірювань виконання, що
піддається аналізу для надання відомостей про виконання робіт із проекту, включаючи аналіз
відхилень, дані про освоєний обсяг і прогнозовані дані.
Деякі пояснення:
Моніторинг і управління ризиками: інструменти й методи
1 Переоцінка ризиків
Моніторинг і управління ризиками часто приводить до ідентифікації нових ризиків, переоцінці поточних
ризиків або закриттю ризиків, які втратили свою актуальність. Переоцінка ризиків проекту повинна
проводитися регулярно, відповідно до розкладу. Обсяг і ступінь деталізації повторень залежать від
ходу виконання проекту стосовно поставлених цілей.
Деякі пояснення:
Моніторинг і управління ризиками: інструменти й методи
2 Аудити ризиків
Аудит ризиків припускає вивчення й надання в документальному виді результатів оцінки ефективності
дій по реагуванню на ризики, що ставляться до ідентифікованих ризиків, вивчення основних
причин їхнього виникнення, а також оцінку ефективності процесу управління ризиками.
Менеджер проекту відповідає за забезпечення регулярного проведення аудитів ризиків відповідно до
плану управління ризиками проекту.
Аудити ризиків можуть проводитися в ході регулярних нарад по оцінці поточного стану проекту, або
можуть проводитися окремі наради із приводу їх.
Формат і цілі аудита повинні бути чітко визначені до початку його проведення.
Деякі пояснення:
Моніторинг і управління ризиками: інструменти й методи
3 Аналіз відхилень і тенденцій
У багатьох процесах управління використовується аналіз відхилень для порівняння запланованих
результатів з фактичними. З метою контролю й управління настаннями ризиків варто переглядати
тенденції виконання проекту, використовуючи інформацію про виконання. Для контролю
загального виконання проекту можуть використовуватися аналіз освоєного обсягу й інші методи
аналізу відхилень і тенденцій проекту. Результати даних аналізів дозволяють прогнозувати
потенційні відхилення проекту на момент його завершення по показниках вартості й строкам. Такі
відхилення від базового плану можуть указувати на можливі впливи, викликані загрозами або
сприятливими можливостями.
Деякі пояснення:
Моніторинг і управління ризиками: інструменти й методи
4 Вимірювання технічного виконання
При вимірюванні технічного виконання порівнюються одержувані в процесі реалізації проекту технічні
результати із запланованими.
Для цього потрібне визначення кількісних показників технічного виконання, які можуть бути
використані для порівняння фактичних результатів із заданими показниками.
До таких показників технічного виконання можуть належати вага, строки транзакцій, число допущених
дефектів, місткість складу й ін.
Відхилення, наприклад, фактично більша або менша функціональність, ніж було заплановано в
контрольній точці, можуть допомогти спрогнозувати ступінь успіху в досягненні змісту проекту,
також вони дозволяють розкрити ступінь технічного ризику, з яким стикається проект.
Деякі пояснення:
Моніторинг і управління ризиками: інструменти й методи
5 Аналіз резервів
У ході виконання проекту можуть наставати різні ризики, що роблять як позитивний, так і негативний
вплив на резерви на можливі втрати по бюджету або розкладу. При аналізі резервів для визначення
адекватності залишку резерву проводиться порівняння обсягу резервів, що залишилися, на можливі
втрати з кількістю ризиків, що залишилися, за станом на будь-який момент часу процесу виконання
проекту.
Деякі пояснення:
Моніторинг і управління ризиками: інструменти й методи
6 Наради по поточному стану
Управління ризиками проекту повинне включатися до порядку денного періодичних нарад із приводу
поточного стану.
Залежно від ідентифікованих ризиків, їхньої пріоритетності й труднощів реагування цей пункт порядку
денного може вимагати різної кількості часу. Чим частіше проводяться подібні наради, тим легше
стає управляти ризиками. Часті обговорення ризиків підвищують імовірність того, що персонал
почне самостійно визначати ризики й можливості.
Деякі пояснення:
Моніторинг і управління ризиками: виходи
1 Оновлення реєстру ризиків містить у собі, серед іншого:
• шаблони для плану управління ризиками, включаючи матрицю ймовірності й впливу і реєстр
ризиків;
• приймається рішення про здійснення або про відмову від запобіжних заходів,
•
Дякую за увагу!
Управління людськими ресурсами проекту
1. Сутність управління людськими ресурсами проекту
2. Розробка плану управління людськими ресурсами
3. Набір команди проекту
4. Розвиток команди проекту
5. Управління командою проекту
1. Сутність управління людськими ресурсами проекту
Розподіл ролей і відповідальності між членами команди проекту дозволяє всім членам команди брати
участь у плануванні проекту й прийнятті рішень, що є цінним для проекту.
Залучення членів команди до участі на ранніх стадіях проекту дозволяє використовувати наявний у них
досвід при плануванні проекту й зміцнює націленість команди на досягнення результатів проекту.
У невеликих проектах обов'язки по управлінню проектом можуть бути розподілені між всіма членами
команди або доручені безпосередньо менеджерові проекту.
Спонсор проекту працює в контакті з командою управління проектом і звичайно бере участь у вирішенні
таких питань, як фінансування проекту, уточнення змісту проекту, моніторинг поточного стану й
надання впливу на інших осіб в інтересах проекту.
Велика увага повинна приділятися розгляду доступності людських ресурсів або конкуренції за них,
їхньому дефіциту або обмеженості.
Ролі в проекті можуть бути призначені окремим особам або групам осіб. Ці особи або групи можуть
бути залучені як зі штату самої організації, що виконує проект, так і зі сторонніх організацій.
На ресурси з тим самим рівнем кваліфікації або тим самим набором навичок можуть претендувати інші
проекти.
Зазначені фактори можуть значно вплинути на вартість, строки, ризики, якість і інші аспекти проекту.
При ефективному плануванні людських ресурсів варто враховувати й планувати ці фактори й
розробляти альтернативні плани управління людськими ресурсами.
Розробка плану управління людськими ресурсами:
входи, інструменти і методи, виходи
Блок-схема даних при розробці плану управління людськими ресурсами
Розробка плану управління людськими ресурсами:
входи
1. Вимоги до ресурсів операцій. Для визначення потреб проекту в персоналі при плануванні людських
ресурсів використовуються вимоги до ресурсів операцій (Див. тему Управління строками проекту).
Попередні вимоги до необхідного для команди проекту персоналу й рівня його кваліфікації послідовно
проробляються в рамках процесу розробки плану управління людськими ресурсами.
.
Розробка плану управління людськими ресурсами:
входи
2. Фактори середовища підприємства, які можуть впливати на процес розробки плану управління
людськими ресурсами, містять у собі, серед іншого:
- організаційну культуру й структуру;
- існуючі людські ресурси;
- правила управління персоналом; і
- ситуацію на ринку.
3. Активи процесів організації, які можуть впливати на процес розробки плану управління людськими
ресурсами, містять у собі, серед іншого:
- стандартні процеси й норми організації, а також описи типових ролей;
- шаблони організаційних діаграм і посадових інструкцій; і
- історичну інформацію з організаційних структур, які виявилися ефективними в попередніх проектах.
Розробка плану управління людськими ресурсами:
інструменти і методи
1. Організаційні діаграми і посадові інструкції
Існують різні формати документування розподілу ролей і відповідальності членів команди. Більшість
форматів належать до одного із трьох типів: ієрархічний, матричний і текстовий формати.
Крім того, деякі призначення по проекту вказуються в допоміжних планах управління проектом
(наприклад, у планах управління ризиками, якістю або комунікаціями).
Незалежно від того, який метод використовується, ціль завжди одна - домогтися того, щоб для кожного
пакета робіт був призначений один відповідальний за його виконання й щоб кожний член команди
чітко розумів свою роль і сферу відповідальності.
Формати визначення ролей і відповідальності:
(1) Ієрархічні діаграми.
(2) Матричні діаграми.
(3) Текстові формати.
(4) Інші розділи плану управління проектом.
Розробка плану управління людськими ресурсами:
інструменти і методи
(1) Ієрархічні діаграми. Для відображення посад і взаємин зверху донизу у графічному форматі можна
використовувати структуру звичайної організаційної діаграми.
Організаційна структура (ОС) схожа на ієрархічну структуру робіт (ІСР), але організована не за
результатами проекту, а відповідно до наявної структури підрозділів організації (відділів, груп або
команд). Під кожним відділом зазначений список операцій проекту або пакета робіт.
Таким чином, конкретний функціональний відділ може довідатися про всі свої обов'язки по проекту
(наприклад, відділ інформаційних технологій або відділ закупівель), вивчивши свою частину
організаційної структури.
Ієрархічна структура ресурсів - це інший різновид ієрархічної діаграми. Вона використовується для
поділу проекту по типах ресурсів. Наприклад, ієрархічна структура ресурсів може відобразити всіх
зварювальників і зварювальне обладнання, використовуване при будівництві судна, незважаючи на
те, що вони розкидані по різних відгалуженнях ОС і ІСР. Ієрархічна структура ресурсів може бути
корисна при контролі вартості проекту й може використовуватися відповідно до системи
бухгалтерського обліку, що діє в організації. Вона також може містити інші категорії ресурсів, крім
людських.
Розробка плану управління людськими ресурсами:
інструменти і методи
(2) Матричні діаграми. Матриця відповідальності (МВ) використовується для відображення зв'язків
між пакетами робіт або операціями й членами команди проекту. У великих проектах МВ можуть
використовуватися на різних рівнях. Наприклад, МВ високого рівня може визначати, яка група або
підрозділ команди відповідає за який елемент в ІСР, у той час як МВ більш низького рівня
використовуються в групі для розподілу ролей, відповідальності й рівнів повноважень відносно
конкретних операцій. Матричний формат показує всі операції, які виконуються однією людиною, і
всіх людей, що беруть участь у виконанні однієї операції. Матричний формат також забезпечує
наділення відповідальністю за виконання одного завдання тільки однієї людини щоб уникнути
різних невідповідностей.
Розробка плану управління людськими ресурсами:
інструменти і методи
На наступному слайді зображена матриця відповідальності, яку ще називають матрицею RACI
(Відповідає - Затверджує - Консультує - Поінформовується). У лівому стовпчику у вигляді операцій
зразок діаграми показує роботу, яку необхідно виконати. Призначені ресурси можуть бути показані
як окремі виконавці або групи осіб. Матриця RACI є лише одним з типів МВ; менеджер проекту
може вибрати інші варіанти позначення, такі як «керівник» або «ресурс» та ін., залежно від
особливостей проекту. Матриця RACI особливо важлива, коли команда складається із внутрішніх і
зовнішніх ресурсів, тому що дозволяє чітко розділяти ролі й очікування.
Матриця відповідальності (МВ ) з використанням формату RACI
Розробка плану управління людськими ресурсами:
інструменти і методи
(3) Текстові формати. Для опису розподілу відповідальності, при якому потрібні докладні описи,
використовуються текстові формати.
Звичайно в таких документах у короткій формі міститься така інформація: обов'язки, повноваження,
компетенція й кваліфікація.
Такі документи називають по-різному, наприклад «посадові інструкції» або «форма ролі-обов'язки-
повноваження». Вони можуть використовуватися як шаблони для майбутніх проектів, особливо
якщо в процесі виконання проекту відновлення інформації відбувається з використанням
накопичених у ході проекту знань.
Розробка плану управління людськими ресурсами:
інструменти і методи
(4) Інші розділи плану управління проектом. Перелік і опис деяких обов'язків, що належать до
управління проектом, наводяться в інших розділах плану управління проектом.
Наприклад, у реєстрі ризиків перераховані особи, відповідальні за ризики, у плані управління
комунікаціями міститься список членів команди, відповідальних за дії по комунікаціях, а в плані
управління якістю перераховані особи, відповідальні за виконання дій по забезпеченню й контролю
якості.
Розробка плану управління людськими ресурсами:
інструменти і методи
2. Налагодження зв'язків - це формальна й неформальна взаємодія з іншими особами в організації,
галузі або в професійному середовищі.
Це конструктивний спосіб зрозуміти політичні й міжособистісні фактори, здатні вплинути на
ефективність різних варіантів управління забезпеченням проекту персоналом.
Дії по налагодженню зв'язків в галузі людських ресурсів можуть містити в собі активну переписку,
зустрічі за обідом, неформальні бесіди, включаючи зустрічі й різні заходи, торговельні конференції
й симпозіуми.
Налагодження зв'язків може бути корисним методом на початку проекту.
Також налагодження зв'язків може бути ефективним способом розширити професійні навички
управління проектом у ході реалізації проекту й після його закінчення.
Розробка плану управління людськими ресурсами:
інструменти і методи
3. Теорія організації розкриває поведінку людей, команди й підрозділів організації. Ефективне
використання даної інформації дозволяє скоротити час, вартість або трудомісткість, необхідні для
створення виходів планування людських ресурсів, і підвищити ймовірність того, що таке
планування буде ефективним.
Важливо розуміти, що в різних організаційних структурах індивідуальні реакції й продуктивність, а
також характеристики міжособистісних відносин будуть відрізнятися.
Розробка плану управління людськими ресурсами:
виходи
1. План управління людськими ресурсами, який є частиною плану управління проектом, надає
рекомендації про порядок визначення, набору, управління, контролю й вивільнення людських
ресурсів проекту. План управління людськими ресурсами повинен містити в собі, серед іншого:
- Ролі й сфери відповідальності.
– Набір персоналу.
– Ресурсні календарі.
– План вивільнення персоналу.
– Потреби в навчанні.
– Визнання заслуг і винагорода.
– Відповідність нормам.
– Безпека.Розробка плану управління людськими ресурсами:
виходи
Набір персоналу. При плануванні набору членів команди проекту виникає ряд питань. Наприклад, чи
будуть задіяні наявні людські ресурси організації, або вони будуть набиратися ззовні на
контрактній основі? Чи будуть члени команди працювати в одному місці, або вони можуть
працювати віддалено? Яка вартість, що відповідає кожному рівню знань (кваліфікації), необхідних
для проекту? Наскільки відділ по роботі з персоналом і функціональними менеджерами зможуть
допомогти команді управління проектом?
Розробка плану управління людськими ресурсами:
виходи
Ресурсні календарі. У плані управління забезпеченням проекту персоналом вказуються строки
залучення членів команди проекту, як індивідуально, так і колективно, а також вказується час
початку заходів щодо набору (наприклад, наймання персоналу). Одним із інструментів для
графічного відображення людських ресурсів є гістограма ресурсу. На цій стовпчастій діаграмі
відображається кількість годин, яку особі, відділу або всій команді проекту доведеться працювати
щотижня або місяць протягом усього проекту. Діаграма може містити горизонтальну лінію, що
відображає максимальну кількість годин, розрахованих для певного ресурсу. Якщо стовпчики
діаграми виходять за межі максимальної кількості годин, то в цьому випадку необхідно застосувати
стратегію вирівнювання ресурсів (наприклад, виділити додаткові ресурси або розширити часові
рамки розкладу).
Розробка плану управління людськими ресурсами:
виходи
План вивільнення персоналу. Визначення методу й часу звільнення членів команди від обов'язків у
проекті представляє користь як для проекту, так і для членів команди. Коли члени команди
звільняються від участі в проекті, то при цьому виключаються виплати співробітникам, що вже
виконали свою частку роботи в проекті, і в такий спосіб знижуються витрати на проект. Загальний
клімат поліпшується, якщо плавний перехід до нових проектів уже спланований заздалегідь. План
вивільнення персоналу також може скоротити ризики у сфері людських ресурсів, які можуть
виникнути в ході реалізації або по закінченні проекту.
Розробка плану управління людськими ресурсами:
виходи
Потреби в навчанні. Якщо існують побоювання, що кваліфікація членів команди, призначуваних для
участі в проекті, може виявитися недостатньою, то в рамках проекту варто розробити план
навчання персоналу. У цьому плані можуть бути також передбачені програми навчання членів
команди, які приведуть до одержання ними сертифікацій, які сприяють успішному виконанню
проекту.
Розробка плану управління людськими ресурсами:
виходи
Визнання заслуг і винагорода. Чіткі критерії й спланована система винагороди допомагають
стимулювати й підтримувати бажану поведінку людей, зайнятих у проекті. Щоб визнання заслуг і
винагорода були ефективними, вони повинні ґрунтуватися на діях і показниках продуктивності,
підконтрольних даній особі. Створення плану із зазначенням часу винагороди гарантує, що про
заохочення не забудуть. Розподіл заохочень і винагород є частиною процесу розвитку команди
проекту.
Розробка плану управління людськими ресурсами:
виходи
Відповідність нормам. План управління забезпеченням проекту персоналом може передбачати
стратегії, що забезпечують відповідність проекту існуючим державним нормативним актам, умовам
договорів із профспілками й іншим установленим нормам відносно людських ресурсів.
Безпека. У план управління забезпеченням проекту персоналом, а також до реєстру ризиків можуть
включатися норми й правила по захисту членів команди від нещасних випадків.
3. Набір команди проекту
Набір команди проекту - це процес підтвердження доступності людських ресурсів і набору команди,
необхідної для виконання завдань по проекту. Команда управління проектом може мати або не мати
прямого контролю при підборі членів команди, тому що на це впливають колективні трудові
договори, використання персоналу субпідрядників, матричне середовище проекту, внутрішні або
зовнішні відносини підзвітності або різні інші причини.
Розвиток команди проекту - це процес підвищення кваліфікації членів команди проекту, поліпшення
взаємодії між ними й поліпшення загальних умов роботи команди для підвищення ефективності
проекту.
Менеджери проектів повинні вміти визначати, формувати, підтримувати, мотивувати, керувати й
надихати команди проектів для підвищення ефективності їхньої роботи й досягнення цілей
проекту.
Командна робота є критично важливим фактором успіху проекту, а розвиток ефективних команд
проектів є одним із найважливіших обов'язків менеджера проекту. Менеджери проектів повинні
створювати умови, що сприяють командній роботі.
Менеджери проектів повинні постійно мотивувати свою команду, ставлячи перед нею задачі й надаючи
можливості, забезпечуючи при необхідності їх своєчасним зворотним зв'язком і підтримкою, а
також заохочуючи й винагороджуючи за гарне виконання робіт.
Висока ефективність роботи команди може бути досягнута за допомогою відкритої й ефективної
комунікації, підвищення довіри між членами команди, конструктивного управління конфліктами, а
також за рахунок сприяння вирішенню проблем і прийняттю рішень на основі співробітництва.
Для одержання ресурсів, необхідних для розвитку ефективних команд проектів, менеджер проекту
повинен залучати підтримку керівництва й/або впливати на зацікавлені сторони проекту.
Команда управління проектом повинна використовувати культурні розбіжності для одержання вигоди,
орієнтуватися на розвиток і підтримку команди проекту протягом усього життєвого циклу проекту,
а також дотримуватися моделі взаємозалежної спільної роботи в обстановці взаємної довіри.
Розвиток команди проекту спрямовано на розвиток навичок співробітників, їхньої технічної
кваліфікації, а також поліпшення загального клімату в команді й підвищення ефективності
виконання проекту. Для цього потрібні чіткі, ефективні й діючі способи комунікації між членами
команди протягом усього життєвого циклу проекту.
Цілі розвитку команди проекту містять у собі, серед іншого:
- підвищення рівня знань і навичок членів команди для підвищення їхньої здатності досягати
результатів проекту при зниженні вартості, скороченні строків і поліпшенні якості;
- зміцнення почуття довіри й згуртованості серед членів команди для підвищення морального духу,
зменшення конфліктів і поліпшення командної роботи; і
- створення динамічної й згуртованої командної культури для підвищення як індивідуальної, так і
командної продуктивності, стимулювання командного духу й співробітництва, а також створення
можливостей для взаємного навчання й наставництва, спрямованих на обмін знаннями й досвідом
між членами команди.
Розвиток команди проекту:
входи, інструменти і методи, виходи
Блок-схема даних при розвитку команди проекту
Розвиток команди проекту: входи
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. Оцінювання тривалості операцій
5. Розробка розкладу
6. Управління розкладом
7. Методичні засади визначення трудомісткості проекту інформатизації
7.1. Модель СОСОМО (Constructive Cost Model)
7.2. Метод функціональних балів (FPA)
Управління строками в проекті включає процеси, необхідні для забезпечення того, щоб проект
завершився вчасно:
• Визначення операцій.
• Розробка розкладу.
• Управління розкладом.
•
Визначення операцій – процес визначення конкретних операцій, які необхідно виконати для одержання
результатів проекту.
Визначення послідовності операцій – процес виявлення й документування залежностей між
операціями проекту.
Оцінювання ресурсів операцій – процес оцінювання типів і кількості матеріалів, людських ресурсів,
обладнання або поставок, необхідних для виконання кожної операції.
Оцінювання тривалості операцій – процес приблизного визначення кількості робочих періодів,
необхідних для завершення окремих операцій при передбачуваних ресурсах.
Розробка розкладу – процес аналізу послідовностей операцій, їхньої тривалості, потреби в ресурсах і
часових обмеженнях для створення розкладу проекту.
Управління розкладом – процес моніторингу статусу проекту для коректування його виконання й
внесення змін у базовий розклад.
РЯД ПРИПУЩЕНЬ ПРИ ВИКЛАДІ МАТЕРІАЛУ
• Усі процеси взаємодіють як між собою, так і з процесами інших галузей застосування знань з
проектного менеджменту.
• Кожний процес виконується, як правило, по одному разу на кожній фазі проекту.
Визначення операцій – процес визначення конкретних операцій, які необхідно виконати для одержання
результатів проекту.
У процесі розробки Ієрархічної Структури Робіт (ІСР) визначаються результати самого нижнього рівня -
пакети робіт.
Пакети робіт проекту звичайно розкладаються на більш дрібні елементи за назвою "операції", які
описують роботу, необхідну для виконання пакета робіт.
Операції надають основу для оцінювання, планування, виконання, моніторингу й контролю робіт із
проекту. Мається на увазі, що визначення й планування операцій розкладу в даному процесі
проводяться у такий спосіб, який забезпечує досягнення цілей проекту.
Визначення операцій:
входи, інструменти й методи, виходи
Блок-схема даних при визначенні операцій
Визначення операцій:
входи
1. Базовий план по змісту Результати, обмеження й допущення проекту документуються в базовому
плані по змісту (див тему Управління змістом) і детально розглядаються при визначенні операцій.
2. Фактори середовища підприємства, які можуть впливати на процес визначення операцій, містять у
собі інформаційну систему управління проектами, не обмежуючись тільки нею.
3. Активи процесів організації, які можуть впливати на процес визначення операцій, містять у собі,
серед іншого:
• існуючі формальні й неформальні, пов'язані із плануванням, правила, процедури й провідні вказівки,
такі як методологія складання розкладу, які враховуються при визначенні операцій;
• базу накопичених знань, що містить історичну інформацію щодо списків операцій, використаних у
попередніх подібних проектах.
Визначення операцій:
інструменти і методи
1. Декомпозиція У застосуванні до визначення операцій метод декомпозиції має на увазі поділ пакетів
робіт проекту на більш дрібні й більш керовані елементи, називані «операціями». Операції являють
собою дії, необхідні для виконання пакета робіт. У процесі визначення операцій кінцеві виходи
визначаються як дії, а не як результати, як це відбувається в процесі створення ІСР (див тему
Управління змістом).
Список операцій, ІСР і словник ІСР можуть розроблятися послідовно або паралельно, при цьому
основою розробки остаточного списку операцій служать ІСР і словник ІСР. Кожний пакет робіт в
ІСР розділяється на операції, необхідні для одержання результатів цього пакета робіт. Участь
членів команди в процесі декомпозиції може привести до одержання кращих і більш точних
результатів.
Визначення операцій:
інструменти і методи
2. Планування методом хвилі, що набігає, являє собою вид планування способом послідовної
розробки, при якому робота, що повинна бути виконана в найближчій перспективі, планується в
деталях на нижчому рівні ІСР, а робота у віддаленому майбутньому планується на більш високому
рівні ІСР.
Отже, робота може існувати на різних рівнях деталізації залежно від того, на якій стадії життєвого циклу
проекту вона перебуває. Наприклад, під час раннього стратегічного планування, коли інформація
ще недостатньо визначена, пакети робіт можуть бути декомпозовані до рівня контрольних подій.
По мірі надходження інформації про майбутні у найближчій перспективі події може бути проведена їхня
декомпозиція до операцій.
Визначення операцій:
інструменти і методи
3. Шаблони Як шаблон для нового проекту найчастіше можна використовувати стандартний перелік
операцій з попереднього проекту або його частину. Інформація про відповідні параметри операцій
у шаблонах також може містити іншу описову інформацію, корисну при визначенні операцій.
Шаблони можуть також застосовуватися для ідентифікації типових контрольних подій розкладу.
4. Експертна оцінка Експертиза при визначенні операцій може проводитися членами команди проекту
або інших експертів, що мають досвід і навички розробки детальних описів змісту проектів, ІСР і
розкладів проектів.
Визначення операцій:
виходи
1. Список операцій - це вичерпний перелік, який включає всі операції розкладу, передбачені для даного
проекту.
У список операцій входять ідентифікатор операції й опис змісту робіт з кожної операції, деталізований
настільки, щоб члени команди проекту розуміли, які роботи необхідно провести.
Визначення операцій:
виходи
2. Параметри операції розширюють її опис шляхом визначення ряду елементів, пов'язаних з кожною
операцією. Елементи кожної операції формуються із часом. На початкових стадіях проекту вони
можуть містити в собі ідентифікатор операції, ідентифікатор ІСР і назву операції, а наприкінці
формування – коди й опис операції, переліки попередніх і наступних операцій, логічні
взаємозв'язки, випередження й затримки, вимоги до ресурсів, статусні дати, обмеження й
допущення.
Параметри операції можуть бути використані для визначення особи, відповідального за виконання
роботи, географічного місця розташування виконання робіт і типу операції, наприклад рівень
завантаження, дискретне або розподілене завантаження. Параметри операції використовуються для
розробки розкладу, а також для вибору, систематизації й різноманітних сортувань запланованих
операцій у звітах. Кількість параметрів розрізняється залежно від прикладної області.
Визначення операцій:
виходи
3. Список контрольних подій
Контрольна подія (віха) - це важливий момент або подія проекту.
Список контрольних подій визначає всі контрольні події, указуючи при цьому, чи є контрольна подія
обов'язковою (наприклад, необхідною відповідно до контракту) або необов'язковою (наприклад, що
ґрунтується на історичній інформації).
2. Визначення послідовності операцій
Визначення послідовності може бути виконане за допомогою програм управління проектами або за
допомогою автоматичних або ручних методів. Останній варіант є більш ефективним у невеликих
проектах і на ранніх фазах великих проектів, коли деталізація ще не така значна.
Ручну і комп'ютерну технології можна використовувати в поєднанні.
Визначення операцій:
входи, інструменти й методи, виходи
Блок-схема даних при визначенні послідовності операцій
Визначення операцій: входи
1. Список операцій Описано раніше
2. Параметри операції Описано раніше. Параметри операції можуть описувати необхідну послідовність
подій або визначені зв'язки з попередніми й наступними операціями.
3 Список контрольних подій Описано раніше. Список контрольних подій може містити розрахункові
дати конкретних контрольних подій.
4 Опис змісту проекту (Див. тему Управління замістом) містить опис змісту продукту, що включає
характеристики продукту, здатні вплинути на визначення послідовності операцій, такі як фізичний
план заводу, що повинен бути споруджений, або інтерфейси підсистем у проекті, пов'язаному із
програмним забезпеченням. Хоча дані впливи часто очевидні в списку операцій, як правило, для
забезпечення точності проводиться перевірка опису змісту продукту.
5. Активи процесів організації, які можуть впливати на процес визначення послідовності операцій,
містять у собі, серед іншого, проектні архіви з корпоративної бази знань, використовувані в
методології складання розклади.
Визначення операцій:
інструменти й методи
1. Метод діаграм передування в методології критичного шляху для побудови сітьової діаграми проекту,
у якій операції зображуються у вигляді квадратів або прямокутників (називаних «вузлами»), а
логічні взаємозв'язки, що існують між ними, - стрілками. Цей метод також називається “операціями
у вузлах” або “вершини-роботи”; він використовується в більшості пакетів програм управління
проектами. Метод діаграм передування включає чотири типи залежностей, або логічних
взаємозв'язків:
Фініш-•Старт.
Фініш-•Фініш.
Старт-•Старт.
Старт-•Фініш.
Визначення операцій:
інструменти й методи
2. Визначення залежностей
Для визначення послідовності операцій використовуються три типи залежностей:
• Обов'язкові залежності.
• Дискреційні залежності.
• Зовнішні залежності.
Визначення операцій:
інструменти й методи
Обов'язкові залежності – це такі залежності, які потрібні за контрактом або є невід'ємною властивістю
виконуваної роботи. Команда проекту визначає, які залежності є обов'язковими, під час процесу
визначення послідовності операцій.
Обов'язкові залежності часто мають на увазі фізичні обмеження, наприклад у будівельному проекті, де
неможливо звести наземну конструкцію до спорудження фундаменту, або в проекті, пов'язаному з
електронікою, де прототип повинен бути створений до того, як він буде протестований. Обов'язкові
залежності також іноді називають «жорсткою логікою».
Визначення операцій:
інструменти й методи
Дискреційні залежності. У ході процесу визначення послідовності операцій команда проекту визначає,
які залежності є дискреційними. Дискреційні залежності іноді також називають "кращою логікою",
"переважною логікою" або "м'якою логікою". Дискреційні залежності встановлюються на основі
передових методів організації робіт у певній прикладній області або в рамках незвичайного аспекту
проекту, де краща особлива послідовність, хоча можуть існувати й інші прийнятні послідовності.
Дискреційні залежності повинні бути повністю задокументовані, тому що вони можуть створювати
необґрунтовані повні часові резерви й можуть обмежити наступні варіанти складання розкладу.
При застосуванні методів швидкого проходу повинен проводитися аналіз цих дискреційних
залежностей і розглядатися необхідність їхньої модифікації або видалення.
Визначення операцій:
інструменти й методи
Зовнішні залежності. У ході процесу визначення послідовності операцій команда управління проектом
виявляє зовнішні залежності.
Зовнішні залежності - це такі залежності, які включають взаємозв'язки між операціями проекту й
операціями поза проектом. Ці залежності звичайно не піддаються контролю з боку команди
проекту. Наприклад, у проекті по розробці програмного забезпечення операція тестування може
залежати від поставки апаратного забезпечення сторонньою організацією, а в деяких будівельних
проектах підготовчі роботи на ділянці можна починати тільки після видачі офіційного
підтвердження, що будівництво не нанесе збитку навколишньому середовищу.
Визначення операцій:
інструменти й методи
3. Застосування випереджень і затримок
Команда управління проектом визначає залежності, які можуть зажадати випередження або затримки
для точного визначення логічного взаємозв'язку. Використання затримок і випереджень не повинне
заміняти логіки розкладу. Операції й пов'язані з ними допущення повинні документуватися.
Випередження допускає прискорення строків виконання наступної операції. Наприклад, у проекті по
будівництву нового офісного будинку озеленення може бути заплановане на 2 тижні раніше
запланованого завершення дефектної відомості. Це може бути представлене у вигляді відносини
«фініш-старт» з 2-тижневим випередженням.
Затримка встановлює відстрочку виконання наступної операції. Наприклад, команда технічних фахівців
може приступитися до редагування проекту великого документа через п'ятнадцять днів після
початку його написання. Це може бути представлене у вигляді відносини « старт-старт» з 15-
денною затримкою.
Визначення операцій:
інструменти й методи
.4 Шаблони сіток. Стандартизовані шаблони сітьових діаграм можуть полегшити підготовку сіток
операцій проекту. Вони можуть містити в собі як проект у цілому, так і його частину. Частини
сітьової діаграми проекту часто називають «підсітями» або «фрагментами». Шаблони підсітей
особливо корисні в тих випадках, коли проект включає кілька ідентичних або майже ідентичних
результатів, таких як , наприклад, модулі програм, які кодують, у проекті з розробки програмного
забезпечення або фазу запуску дослідницького проекту.
• списки операцій;
• параметри операцій;
• реєстр ризиків.
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) тривалість операції за допомогою обчислення середнього
зваженого цих трьох оцінок:
Розробка розкладу - процес аналізу послідовностей операцій, їхньої тривалості, вимог до ресурсів і
часових обмежень для створення розкладу проекту.
Уведення операцій, тривалості й ресурсів в інструмент складання розкладу, наприклад 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. Методичні засади визначення трудомісткості проекту інформатизації
Методичні засади визначення трудомісткості проекту
Створення норм і нормативів витрат праці при програмуванні дуже складний процес, насамперед
через те, що програмування - творча праця, а також тому, що в програмуванні однієї задачі
можуть брати участь фахівці різних професій і категорій: наукові працівники; математики;
інженери - технологи; економісти; техніки; оператори.
Методичні засади визначення трудомісткості проекту
Крім того продуктивність праці при програмуванні залежить від багатьох чинників, врахувати які
важко:
• кваліфікація програміста;
• мова програмування;
Дякую за увагу!
Управління якістю проекту
1. Сутність управління якістю
2. Планування якості
3. Забезпечення якості
4. Контроль якості
1. Сутність управління якістю
Управління якістю проекту передбачає процеси, необхідні для забезпечення того, щоб проект
задовольняв ті потреби, задля яких він і розроблений.
Управління якістю проекту містить у собі процеси й дії виконуючої організації, політику в галузі якості,
цілі й сфери відповідальності в галузі якості таким чином, щоб проект задовольняв тим потребам,
заради яких він був розпочатий.
Управління якістю здійснюється за допомогою системи управління якістю, яка передбачає певні правила
й процедури, а також дії по постійному вдосконалюванню процесів, що проводяться, за
необхідності, протягом усього проекту.
Основні процеси управління якістю
• Планування якості - процес визначення вимог і/або стандартів якості для проекту й продукту,
а також документування того, у який спосіб проект буде демонструвати відповідність
установленим вимогам і стандартам.
• задоволення споживача - розуміння потреб, управління ними і вплив на них у такий спосіб, щоб
очікування споживача були повністю задоволені або навіть перевершені. Це вимагає поєднання
відповідності специфікаціям (у проект необхідно ввести те, що інформуватиме про майбутні
створення) і зручності використання продукту (продукт або послуга має задовольняти реальні
потреби);
• запобігання зайвій інспекції - витрати на запобігання похибкам завжди менші, ніж витрати на їх
виправлення;
• відповідальності служб менеджменту - успішне виконання проекту вимагає участі всіх членів
команди, але відповідальність за виконання несе служба менеджменту, яка надає для успіху
необхідні ресурси;
Модель управління якістю, описана в РМВОК4, в основі своїй відповідає вимогам Міжнародної
організації по стандартизації (International Organization for Standardization, ISO).
Ця модель ураховує також авторські моделі управління якістю, розроблені Демингом (Deming), Юраном
(Juran), Кросби (Crosby) і ін., і загальні моделі, такі як тотальне управління якістю (TQM), Шість
сигм (Six Sigma), аналіз характеру й наслідків відмов, контрольні оцінки на етапі проектування,
думку замовника, вартість якості (COQ) і постійне вдосконалювання.
- Відповідальність керівництва. Для досягнення успіху потрібна участь всіх членів команди проекту,
але за забезпечення проекту ресурсами, необхідними для його успішного завершення,
відповідальність несе керівництво. Вартість якості позначає загальну вартість всіх заходів,
спрямованих на забезпечення якості, протягом життєвого циклу продукту. Рішення, прийняті по
проекту, можуть впливати на вартість якості в процесі експлуатації в результаті повернень
продуктів, претензій по гарантії й кампаній по відкликанню продукції. Таким чином, внаслідок
тимчасового характеру проекту, організація-спонсор може ухвалити рішення щодо вкладанні
коштів у підвищення якості продукту, особливо у визначення вартості й запобігання дефектів, з
метою зниження зовнішньої вартості якості.
2. Планування якості
Планування якості -
процес визначення вимог і/або стандартів якості для проекту й продукту, а також документування того, у
який спосіб проект буде демонструвати відповідність установленим вимогам і стандартам
Планування якості
Це один із ключових процесів поліпшення в плануванні проекту і здійснювати його необхідно
регулярно, паралельно з іншими процесами планування проекту.
Наприклад, бажане управління якістю може вимагати коригування календарного плану чи вартості або
бажаний продукт якості може вимагати детального аналізу ризику з певної проблеми
Один із фундаментальних принципів сучасного управління якістю -
якість планується, а не перевіряється.
Планування якості:
входи, інструменти й методи, виходи
Блок-схема даних при плануванні якості
Входи планування якості
1.Базовий план по змісту є основним параметром при плануванні якості (див. тему “Управління
змістом”), оскільки в ньому задокументовані головні результати проекту та цілі - необхідна
інформація для визначення основних вимог зацікавленої особи.
Входи планування якості
1 План по змісту включає:
- Опис змісту. Опис змісту містить опис проекту, його основних результатів і критеріїв приймання. Опис
змісту продукту часто містить подробиці щодо технічних і інших важливих питань, які можуть
вплинути на планування якості. Визначення критеріїв приймання може значно збільшити або
зменшити вартість якості проекту. Відповідність всім критеріям приймання має на увазі
задоволення всіх вимог замовника.
- ІСР. ІСР визначає результати, пакети робіт і контрольні рахунки, використовувані для вимірювання
виконання проекту.
- Словник ІСР. Словник ІСР визначає технічну інформацію для елементів ІСР.
Входи планування якості
2. Реєстр зацікавлених сторін проекту визначає зацікавлених сторін проекту, що мають певні інтереси
відносно якості або впливають на нього.
3. Базовий план виконання вартості документує прийняті часові фази, використовувані для
вимірювання виконання вартості (див. тему Управління вартістю проекту).
4. Базовий розклад документує прийняті метрики виконання строків, включаючи дати старту й фінішу
(див. тему Управління строками проекту).
5. Реєстр ризиків містить інформацію про погрози й можливості, які можуть впливати на вимоги до
якості (див. тему Управління ризиками проекту).
Входи планування якості
6. Фактори середовища підприємства, які впливають на процес планування якості, містять у собі,
серед іншого:
- нормативні акти урядових органів;
- правила, стандарти й провідні вказівки, специфічні для прикладної області; і
- умови роботи/експлуатації проекту/продукту, які можуть вплинути на якість проекту.
Входи планування якості
7. Активи процесів організації, які впливають на процес планування якості, містять у собі, серед
іншого:
- правила, процедури й провідні вказівки організації в галузі якості;
- бази історичних даних;
- знання, накопичені в попередніх проектах; і
• 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 кожна група процесів
має тільки одну загальну мету.
• Підпрактика (subpractice) (або інакше, підлеглі базові практики) — детальний опис дій, які
можуть стати керівництвом для інтерпретації спеціальних і загальних практик.
Підпрактики наводяться під текстом базових практик і описують, що очікується від організації по
виконанню даної базової практики.
Підпрактики можуть використовуватися як допомога при визначенні, чи задовільно впроваджені базові
практики.
Основні компоненти CMMI
• Типовий робочий продукт (typical work product) — приклад того, що повинно бути
отримане в результаті виконання спеціальної або загальної практики. Ці приклади названі
типовими робочими продуктами, тому що можуть існувати й інші, не менш ефективні, робочі
продукти.
Модель CMMI випущена у двох варіантах - безперервне подання й стадійне подання
В основі безперервного подання лежить концепція можливостей процесів у певній сфері (6 рівнів).
В основі стадійного подання лежить концепція зрілості процесів організації в цілому (5 рівнів).
Модель CMMI випущена у двох варіантах - безперервне подання й стадійне подання
Різниця між двома поданнями полягає в тому, що концепція можливостей процесів розглядає
комплекс дій («практик»), пов'язаних з однією групою процесів,
у той час як концепція зрілості процесів розглядає комплекс процесів у масштабах всієї організації.
Безперервне подання CMMI
розглядає чотири категорії (групи) процесів:
• управління проектами,
• підтримка,
• інженерія,
• управління процесами.
Групи процесів по категоріях процесів безперервного подання CMMI
Групи процесів по категоріях процесів безперервного подання CMMI (продовження)
Групи процесів по категоріях процесів безперервного подання CMMI (продовження)
Групи процесів по категоріях процесів безперервного подання CMMI (закінчення)
В основі безперервного подання лежить концепція можливостей процесів у певній групі.
Організація може зосередитися на тій групі процесів, що для неї є найбільш критичною.
У цьому випадку можна говорити про рівень потенційних можливостей для обраної групи процесів.
Це означає, наприклад, що організація може досягти 5-го рівня потенційної можливості по управлінню
проектами й залишатися нижче 2-го рівня потенційної можливості по управлінню процесами.
Різниця між двома поданнями полягає в тому, що концепція можливостей процесів (безперервне
подання) розглядає комплекс дій («практик»), пов'язаних з однією групою процесів, у той час як
концепція зрілості процесів (стадійне подання) розглядає комплекс процесів у масштабах всієї
організації.
Приклад
Модель зрілості керівника проекту
Зрілість керівника. Рівень 1.
Зрілість керівника. Рівень 2.
Зрілість керівника. Рівень 2. (закінчення)
Зрілість керівника. Рівень 3.
Зрілість керівника. Рівень 3. (закінчення)
Зрілість керівника. Рівень 4.
Зрілість керівника. Рівень 4. (закінчення)
Зрілість керівника. Рівень 5.
Зрілість керівника. Рівень 5. (закінчення)
Успіх проекту багато в чому визначається тим, як організоване його управління
CMMI включає в УП такі групи процесів:
• планування проекту;
• управління ризиками;
Дякую за увагу!
Тема:
СММІ: Планування проекту
Успіх проекту багато в чому визначається тим, як організоване його управління
CMMI включає в УП такі групи процесів:
• планування проекту;
• управління ризиками;
• проаналізувати плани;
• обсяг проекту;
• технічний підхід;
• графік;
• опис задач;
• структура робіт.
2. Оцінювання робочих продуктів і характеристик виконуваних задач
Більшість моделей по оцінці трудовитрат, вартості й графіка засновані на визначенні розміру, складності
й структури продукту.
Як правило, розміри визначаються для робочих продуктів (що поставляються й не поставляються
клієнтові), документів і операційного й підтримуючого програмного забезпечення.
Розмір може вимірятися кількістю функцій, функціональних точок, рядків програмного коду, класів і
об'єктів, вимог, інтерфейсів, сторінок, входів і виходів, обсягом даних. Кожному із цих атрибутів
рекомендується присвоїти рівень труднощів або складності.
Оцінювання робочих продуктів і завдань стає більш об'єктивним, якщо базується на визначенні
технічного підходу до виконання проекту
Під технічним підходом розуміється формування високорівневої стратегії розробки, яка включає
рішення по таких питаннях:
• безпека й надійність,
• ергономіка.
Велике значення мають методи визначення атрибутів робочих продуктів і задач, оскільки від цього буде
залежати надійність оцінок.
Приклади таких методів:
• технічний підхід;
• розмір і складність виконуваних задач і робочих продуктів;
• оцінні моделі;
• оцінки атрибутів.
3. Визначення життєвого циклу проекту
Фази життєвого циклу визначають логічні точки для прийняття важливих рішень по ресурсах і
технічному підходу.
Саме в таких точках може коригуватися хід проекту, а також його обсяг і вартість.
Розуміння життєвого циклу проекту критично важливо для визначення обсягу зусиль по плануванню,
часу початкового планування, а також часу й умов для перепланування
Для програмної інженерії визначення фаз проекту звичайно включає вибір і уточнення моделі розробки,
що дозволяє описати взаємозалежності й послідовність дій.
Для системної інженерії визначаються основні фази продукту (тобто концепція, розробка й т.д.).
У великих проектах фази можуть містити етапи. Так, фаза розробки може містити етапи аналізу вимог,
проектування, програмування, інтеграції, тестування.
Рекомендовані робочі продукти - результати етапу “Визначення життєвого циклу проекту”:
• обґрунтування оцінок,
• графік проекту;
• критичний шлях;
• бюджет проекту.
6. Визначення проектних ризиків
У групі процесів «Планування проекту» виконуються ідентифікація ризикових подій, їхній аналіз і
визначення пріоритетів,
У групі «Моніторинг і контроль проекту» проводиться моніторинг ризиків,
У групі «Управління ризиками» здійснюються відстеження й пом'якшення впливу ризиків.
Визначення й аналіз ризиків на етапі планування проектів включає
• ідентифікацію ризиків,
• їхнє документування,
• пріоритезацію ризиків,
• пріоритети ризиків.
7. Планування управління проектними даними
Під проектними даними розуміють різні форми документації.
Документуються всі аспекти проектної діяльності.
Дані можуть мати різноманітну форму (звіти, керівництва, записи, графіки, креслення, специфікації,
файли, кореспонденція) і можуть існувати в будь-якому середовищі (друковані й електронні
матеріали, фотографії, мультимедіа й т.д.).
Проектні плани повинні передбачати ідентифікацію даних, методи їхнього збору й поширення.
При плануванні проекту варто визначити вимоги як до номенклатури створюваних у проекті даних, так і
до їхнього змісту й форми.
Стандартні вимоги до змісту й формату даних сприяють їхньому кращому розумінню й полегшують
управління джерелами даних.
Варто звернути особливу увагу на планування заходів по забезпеченню конфіденційності й безпеки
даних, а також на встановлення механізму архівування й забезпечення доступу до архівованих
даних.
Рекомендовані робочі продукти - результати етапу “Спланувати управління проектними даними”:
• внутрішнє навчання,
• зовнішнє навчання,
• наймання нового персоналу.
Рекомендовані робочі продукти - результати етапу “Планування необхідних знань і навичок”:
• матриця залучення;
• ролі й відповідальності в проекті.
11. Установлення плану проекту
Результатом робіт із планування проекту є документований план, що визначає всі аспекти проекту:
• життєвий цикл,
• етапи,
• управління даними,
• ідентифікацію ризиків,
• задачі,
• ролі й відповідальності,
• навички й знання,
• описи процесів.
Рекомендовані робочі продукти - результати етапу “Установлення плану проекту”
• плани по якості,
• плани вимірювань,
• плани навчання.
Додаткові плани, розроблювані по різних групах процесів, можуть містити інформацію, що буде
затребувана планом проекту.
Такі плани можуть служити більш детальним керівництвом, повинні бути сумісні один з одним і
підтримувати загальний план проекту в частині визначення повноважень, обов'язків,
відповідальності, звітності й контролю.
Може складатися загальний план проекту, так званий майстер-план.
Необхідно визначити й узгодити для різних проектних робіт:
• права,
• обов'язки,
• підзвітність,
• порядок контролю,
• переконатися в загальному розумінні цілей, завдань, ролей і взаємин, які будуть потрібні для
успішного виконання проекту.
Рекомендовані робочі продукти - результати етапу “Аналіз планів”:
• переглянуті бюджети;
• уточнені графіки;
• документовані зобов'язання.
Дякую за увагу!
Тема:
СММІ: Моніторинг і контроль проекту
Контроль і моніторинг необхідні для:
розуміння того, у якому стані перебуває проект, і які коригувальні дії можуть бути розпочаті, якщо
хід виконання проекту істотно відхиляється від плану.
• аналіз проблем;
• визначення значних відхилень (відхилення від планових значень уважається значним, якщо
без прийняття відповідних коригувальних заходів воно може призвести до недосягнення
цілей проекту).
Всі значні відхилення від параметрів планування повинні документуватися.
2. Моніторинг зобов'язань учасників і інших зацікавлених сторін включає:
• виявлення зобов'язань, які не були виконані або котрі перебувають під загрозою
невиконання;
• інформування про поточний статус ризиків (зміни в імовірності прояву ризику, поява нових
ризиків, зміна пріоритетів ризиків) всіх зацікавлених сторін.
4. Моніторинг управління даними включає:
• регулярне інформування зацікавлених сторін про статус доручених робіт і робочих продуктів
(у число зацікавлених сторін входять керівництво, члени проектної команди, клієнти, кінцеві
користувачі, постачальники);
• зміна процесів;
Управління постачальниками
До постачальників можуть відноситися структури, що входять до складу організації, але зовнішні
стосовно даного проекту, виробничі підрозділи й лабораторії, комерційні структури.
Якщо проект використовує зовнішні продукти, повинна бути укладена угода й виділені ресурси для
управління й виконання цієї угоди.
Управління постачальниками
Продукт – це як власне продукти, так і послуги.
Формальна угода - будь-яка юридична угода між організацією, що представляє проект, і
постачальником.
Ця угода може мати форму контракту, ліцензії або меморандуму.
Продукт, що отримується – продукт, що поставляється в проект і стає частиною продукту, що
поставляється клієнтові.
Група процесів «Управління постачальниками» містить у собі:
• вибір постачальників;
• виконання угоди;
• вибір постачальника.
2. Вибір постачальників (продовження)
Критерії оцінки постачальника мають першорядне значення й повинні враховувати важливі для даного
проекту фактори.
Серед них географічне розташування постачальника, відгуки про роботу постачальника, технічні
характеристики продукції.
2. Вибір постачальників (закінчення)
Рекомендовані робочі продукти:
• критерії оцінки,
• запити постачальникам і
• вимоги.
3. Укладання угод з постачальниками
Як правило, організація має встановлену процедуру укладання угод з постачальниками.
Ціль цих угод - інформувати постачальника про потреби проекту, очікування від постачальника й
кількісні міри оцінки ефективності роботи постачальника.
Оскільки кожна угода є результатом переговорів з постачальником, початково висунуті вимоги можуть
уточнюватися.
В угоді з постачальником документується також і те, що повинен забезпечити проект для успішної
поставки (наприклад, обладнані приміщення, документація, послуги).
При укладанні формальної угоди з постачальником документуються:
• критерії приймання.
Важливо гарантувати, що всі учасники досягли однакового розуміння угоди й вимог ще до того, як ця
угода почне виконуватися.
При необхідності перегляду угоди з постачальником варто переглянути плани проекту й зобов'язання
учасників.
3. Укладання угод з постачальниками (закінчення)
Рекомендовані робочі продукти:
• завдання на роботу,
• контракти,
• ліцензійні угоди.
4. Аналіз комерційно доступних продуктів
Фактори, що враховуються при оцінці продуктів, які передбачається придбати:
• вартість продуктів,
• прейскуранти,
• критерії оцінки,
• технічних нарад,
• управлінського аналізу.
5. Виконання угоди (продовження)
а) Аналізи ходу виконання робіт можуть мати формальний і неформальний характер і звичайно містять у
собі:
• підготовку аналізу,
• засідання,
Залежно від ходу виконання робіт угоди з постачальником, плани й графіки проекту можуть
переглядатися.
5. Виконання угоди (закінчення)
Рекомендовані робочі продукти - результати даного етапу:
• установлення угоди з постачальником про план дій по продуктам, які не пройшли приймальні
випробування;
• процедури приймання,
Дякую за увагу!
Тема. СММІ: Моніторинг і контроль проекту
Контроль і моніторинг необхідні для розуміння того, у якому
стані перебуває проект, і які коригувальні дії можуть бути початі,
якщо хід виконання проекту істотно відхиляється від плану.
Основою всіх дій по моніторингу є документований план проекту. Прогрес у ході проекту звичайно
визначається порівнянням реально отриманих результатів (робочі продукти, завдання, трудовитрати,
вартість) із планованими величинами на заздалегідь установлених етапах або рівнях контролю відповідно
до графіка проекту або структури робіт.
Ця група процесів містить у собі:
1. моніторинг параметрів планування;
2. моніторинг зобов'язань учасників;
3. моніторинг проектних ризиків;
4. моніторинг управління даними;
5. моніторинг залучення зацікавлених сторін;
6. проведення аналізу ходу виконання проекту;
7. проведення аналізу виконання етапів проекту;
8. аналіз проблем;
9. прийняття коригувальних дій;
10. виконання коригувальних дій.
Загальна схема моніторингу й контролю проекту показана на рис. 1.
Непередбачуваний Початковий
1
процес
Спеціальні практики
Рівні Загальні
Типові робочі продукти можливостей практики
Деталі (subpractices)
Коментарі (notes)
Рисунок 2. Основні компоненти безперервного подання CMMI
В основі стадійного подання лежить концепція зрілості процесів організації в цілому. Передбачено
5 рівнів зрілості організації: початковий, керований, визначений, кількісно керований, оптимізований
(рис.1).
Стадійне подання CMMI засноване на тому, що для досягнення певного рівня зрілості організація
повинна впровадити всі без винятку процеси, що належать до даного й усіх попередніх рівнів зрілості.
Так, організація, що ставить за мету досягти 4-го рівня зрілості повинна освоїти всі процеси 2-го, 3-го й
4-го рівнів. Якщо виявиться, що дана організація освоїла всі процеси 3-го й 4-го рівнів, але не освоїла
хоча б одного процесу 2-го рівня зрілості, вона не буде визнана відповідною навіть 2-му рівню зрілості.
Рівні зрілості
Деталі (subpractices)
Коментарі (notes)
Проектні
Отримати плани
згоду
виконавців
Моніторинг і
контроль
Встановити оцінки
Встановити
оцінки
Оцінити обсяг
робочих
проекту
продуктів і
Дані по
задач
плануванню
Оцінити
зусилля і
вартість
Визначити
життєвий цикл
проекту
Проектні плани
Рисунок 6. Схема розробки плану проекту
Розробка й підтримка бюджету й графіка проекту звичайно передбачають: визначення доступних
або необхідних ресурсів, розподіл робіт у часі й по етапах; установлення взаємозалежностей для різних
робіт; визначення тривалості кожної роботи; визначення ключових дат поставки продуктів клієнтові;
установлення етапів для визначення досягнутих результатів і проведення необхідних вимірів; визначення
необхідних резервів за часом і ресурсами; документування припущень і їхніх обґрунтувань.
Бюджет і графік проекту повинні базуватися на проведених оцінках. Насамперед, визначаються
основні етапи проекту, вибір яких заснований на календарних датах або на завершенні певних робочих
продуктів.
Графік проекту «прив'язує» точки прийняття ключових рішень до календарних дат, при цьому
враховуються такі фактори, як доступність ресурсів і залежність від зусиль інших груп. На цьому ж етапі,
залежно від обмежень у часі, наявних історичних даних і допущень, розробляються критерії визначення
«небезпечних» станів.
Графік проекту завжди заснований на деяких припущеннях. Найпоширенішими є припущення про
тривалість визначених проектних робіт. Часто припущення поширюються на ті події й робочі продукти,
для яких важко або неможливо провести оцінки. Якомога раніше варто визначити обмеження, що
впливають на гнучкість у виборі методів управління. До обмежень, у першу чергу, належать тривалість
виконання завдань, доступні вхідні дані, наявність необхідних ресурсів.
Одним із ключових факторів успіху є визначення взаємозалежності задач. Звичайно задачі
плануються в деякій послідовності, що дозволяє мінімізувати тривалість проекту. Найпоширеніший
метод розподілу зусиль по різних задачах - метод критичного шляху.
При розробці графіка доцільно встановити «пороги» (критерії істотного відхилення від плану
проекту), при досягненні яких необхідно почати коригувальні дії. Коригувальні дії можуть полягати в
переплануванні, зміні досягнутих угод (у тому числі із замовником) або залученню додаткових ресурсів
у рамках діючого плану.
Рекомендовані робочі продукти - результати даного етапу: графік проекту; критичний шлях;
бюджет проекту.
6. Визначення проектних ризиків
У групі процесів «Планування проекту» виконуються ідентифікація ризикових подій, їхній аналіз
і визначення пріоритетів, у групі «Моніторинг і контроль проекту» проводиться моніторинг ризиків, в
групі «Управління ризиками» здійснюються відстеження й пом'якшення впливу ризиків.
Визначення й аналіз ризиків на етапі планування проектів включає ідентифікацію ризиків, їхнє
документування, досягнення згоди зацікавлених сторін щодо повноти й коректності документованих
ризиків, пріоритезацію ризиків, а також їхню ревізію в міру необхідності.
Під ідентифікацією ризиків розуміється визначення потенційних проблем, небезпек, загроз і інших
подій, які можуть негативно вплинути на досягнення цілей проекту. При ідентифікації ризиків
рекомендується використовувати такі методи, як оцінка ризиків, контрольні списки, структуровані
інтерв'ю, мозкові штурми, моделі процесів, вартісні моделі, системний аналіз.
Ревізія ризиків проводиться, коли з'являється новий ризик, потенційні ризики стають проблемою,
ризик перестає бути загрозою або істотно змінюється ситуація із проектом.
Рекомендовані робочі продукти - результати даного етапу: список ідентифікованих ризиків;
вплив ризиків і ймовірність їхнього прояву; пріоритети ризиків.
7. Планування управління проектними даними
Під проектними даними розуміють різні форми документації. Документуються всі аспекти
проектної діяльності. Дані можуть мати різноманітну форму (звіти, керівництва, записи, графіки,
креслення, специфікації, файли, кореспонденція) і можуть існувати в будь-якому середовищі (друковані
й електронні матеріали, фотографії, мультимедіа й т.д.).
Проектні плани повинні передбачати ідентифікацію даних, методи їхнього збору й поширення.
При плануванні проекту варто визначити вимоги як до номенклатури створюваних у проекті даних, так і
до їхнього змісту й форми. Стандартні вимоги до змісту й формату даних сприяють їхньому кращому
розумінню й полегшують управління джерелами даних.
Збір документів необхідний, для того щоб проаналізувати й підтвердити виконання вимог до
документів, що поставляються й не поставляються клієнтові, до даних, включених і не включених у
контракт, і даних, наданих клієнтом. Досить часто дані збираються без чіткого уявлення про те, як вони
будуть використовуватися. Оскільки дані досить дорого коштують, вони повинні створюватися й
збиратися тільки в тих випадках, коли це дійсно необхідно.
Варто звернути особливу увагу на планування заходів по забезпеченню конфіденційності й
безпеки даних, а також на встановлення механізму архівування й забезпечення доступу до архівованих
даних.
Рекомендовані робочі продукти - результати даного етапу: план управління даними; перелік
керованих даних; опис змісту й формату даних; вимоги до конфіденційності й безпеки даних; механізм
повернення, відтворення й розподілу даних; графік збору даних; перелік даних, які повинні збиратися в
проекті.
8. Планування ресурсів
Проектні ресурси включають персонал, обладнання, матеріали, технології й методики. Визначення
проектних ресурсів засновано на початкових оцінках і, у свою чергу, може використовуватися для
уточнення структури робіт по проекту. На цій стадії структура робіт верхнього рівня, створена раніше як
основа для оцінок, звичайно декомпозуєтся на робочі пакети, що описують задачі, які можуть
виконуватися й контролюватися окремо. Така декомпозиція допомагає розподілити обов'язки по
керівництву проектом і контролю ходу виконання проекту. Кожному робочому пакету або робочому
продукту повинен бути присвоєний унікальний ідентифікатор.
Комплектування проектної команди залежить від декомпозиції вимог до проекту на задачі,
проектні ролі й відповідальності, як це описано робочими пакетами WBS.
Здебільшого проекти в певному значенні унікальні й вимагають унікальних засобів для успішного
виконання. Своєчасне визначення й придбання цих засобів може виявитися критичним фактором успіху
проекту. Але й у тому випадку, коли необхідні засоби не є унікальними, складання переліку обладнання
й пристроїв сприяє кращому розумінню всіх аспектів проекту.
Рекомендовані робочі продукти - результати даного етапу: робочі пакети структури робіт;
словник задач WBS; вимоги до людських ресурсів; перелік критично важливого обладнання й виробничих
площ; описи й діаграми процесів; перелік вимог до адміністрування проекту.
9. Планування необхідних знань і навичок
Під необхідними знаннями й навичками мається на увазі знання предметної області й технічні
знання. Передача знань, необхідних для виконання проекту, включає як навчання проектної команди, так
і придбання знань із зовнішніх джерел. Саме доступні в організації знання й навички визначають вимоги
до комплектування проектної команди.
На етапі планування необхідно встановити необхідні для даного проекту знання й навички, оцінити
знання й навички наявного персоналу, вибрати механізми забезпечення необхідних знань і навичок і
описати ці механізми в проектному плані. Як правило, механізми забезпечення знань включають
внутрішнє навчання, зовнішнє навчання, наймання нового персоналу.
Рекомендовані робочі продукти - результати даного етапу: перелік необхідних знань; плани
укомплектування проектної команди; плани наймання нового персоналу; бази даних (наприклад, навички
й навчання).
10. Планування залучення зацікавлених осіб
Концепція зацікавлених осіб є присутньою практично в усіх групах процесів CMMI. Під
зацікавленою особою (stakeholder) розуміється група або індивідуум, що беруть особисту участь у роботах
із проекту, що представляють проект на різних рівнях і зацікавлені в успіху проекту.
Зацікавлені особи встановлюються для всіх фаз життєвого циклу проекту. Це звичайно робиться
шляхом ідентифікації ролей і функцій, а також ступеня залучення в конкретні проектні роботи. Варто
звернути особливу увагу на тих, хто залучений до даної проектної роботи, і на тих, хто має необхідні
знання й експертизу для її виконання. Одним із найбільш зручних форматів для такої ідентифікації є
двовимірна матриця з переліком зацікавлених осіб по одній осі й проектними роботами з іншої.
Список зацікавлених осіб може змінюватися в міру того, як проект переходить від однієї фази до
іншої. Тому важливо, щоб особи, зацікавлені в більш пізніх фазах проекту, одержували завчасний доступ
до вимог і проектних рішень, які можуть вплинути на їхню роботу.
У загальному випадку план залучення зацікавлених осіб повинен включати перелік зацікавлених
осіб, обґрунтування їхнього залучення в проект, їхні ролі й відповідальності для кожної фази життєвого
циклу проекту, взаємозв'язки між ними, відносне значення кожного зацікавленої особи для успіху
проекту, необхідні ресурси для взаємодії зацікавлених осіб, графік їхньої участі в проекті.
Рекомендовані робочі продукти - результати даного етапу: список зацікавлених осіб; матриця
залучення; ролі й відповідальності в проекті.
11. Установлення плану проекту
Результатом робіт із планування проекту є документований план, що визначає всі аспекти проекту:
графік, що відображає технічні роботи і їхню взаємозалежність, життєвий цикл, вимоги й стандарти якості
для продуктів, що поставляються, етапи, технічні й управлінські задачі, залучення й взаємодія
зацікавлених осіб, управління даними, ідентифікацію ризиків, задачі, ролі й відповідальності, необхідні
ресурси, включаючи обладнання, виробничі приміщення, персонал, навички й знання, метрики, які
передбачається використовувати при моніторингу проекту, описи процесів.
12. Аналіз планів
У загальному випадку на цьому етапі розробляється ряд додаткових планів по спеціальних
дисциплінах, у тому числі плани по якості, плани управління конфігурацією, плани вимірювань, плани
навчання. Багато із цих планів описані загальними практиками в кожній групі процесів, але описані в
CMMI практики не є єдиним шляхом досягнення поставлених цілей. Організації або проекти можуть
використовувати альтернативні дії, які будуть більш ефективними в даному проекті. Наприклад, у
невеликих проектах можуть не знадобитися додаткові плани.
Додаткові плани, розроблювані по різних групах процесів, можуть містити інформацію, що буде
затребувана планом проекту. Такі плани можуть служити більш детальним керівництвом, повинні бути
сумісні один з одним і підтримувати загальний план проекту в частині визначення повноважень,
обов'язків, відповідальностей, звітності й контролю.
Може складатися загальний план проекту, так званий майстер-план. У кожному разі необхідно
визначити й узгодити для різних проектних робіт права, обов'язки, підзвітність, порядок контролю,
проаналізувати всі плани, які можуть вплинути на проект, і переконатися в загальному розумінні цілей,
завдань, ролей і взаємин, які будуть потрібні для успішного виконання проекту.
Рекомендовані робочі продукти - результати даного етапу: записи про аналіз планів.
13. Узгодження рівнів робіт і ресурсів
Звичайно оцінка необхідних ресурсів проводиться на різних рівнях. Важливо порівняти отримані
оцінки з реально наявними ресурсами й узгодити розбіжності. Для такого узгодження використовуються:
зниження рівня або відстрочка ряду вимог до технічних характеристик, запит додаткових ресурсів,
знаходження шляхів збільшення продуктивності, залучення зовнішніх ресурсів, знаходження
оптимального сполучення знань і навичок персоналу, перегляд або ревізія планів, що впливають на хід
виконання й успіх проекту.
Рекомендовані робочі продукти - результати даного етапу: ревізовані методи й параметри
оцінки (наприклад, краще обладнання, використання покупних компонентів); переглянуті бюджети;
уточнені графіки; список ревізованих вимог; переглянуті угоди між зацікавленими особами.
14. Одержання зобов'язань учасників по виконанню плану
Плани ефективні тоді й тільки тоді, коли учасники роботи згодні із цими планами, вважають їх
здійсненними й беруть на себе зобов'язання виконати доручені їм задачі. У моделі CMMI всі ці аспекти
включені в термін commitment, що будемо перекладати як «зобов'язання».
Дуже часто «зобов'язання» інтерпретують як обов'язок і ототожнюють із покладанням обов'язків
по виконанню роботи. Модель CMMI вкладає інший зміст у цей термін. Поняття «зобов'язання» означає,
що робота зрозуміла виконавцеві, що він уважає цю роботу необхідною й здійсненною, що він приймає
на себе зобов'язання виконати цю роботу в строк і якнайкраще. Можна зобов'язати співробітника
виконати те або інше завдання, але важко очікувати, що він докладе всіх зусіль і вміння для його
виконання. Скоріше треба приготуватися до пояснень із приводу того, чому дана робота не могла бути
виконана.
Для того щоб забезпечити зобов'язання й довести, що зобов'язання дійсно взяте, можна
порекомендувати наступні дії: обговорити зі співробітником завдання, переконатися в розумінні цього
завдання, попросити його висловити свій коментар щодо правильності й чіткості формулювання, оцінити
необхідні час і трудовитрати й, нарешті, спланувати виконання цієї роботи. Для перевірки, що відповідні
зобов'язання отримані по всіх задачах, рекомендується використовувати у якості контрольного списку
структуру робіт.
Одержання зобов'язань - це «квиток у два боки»: виконавці, що беруть на себе зобов'язання,
повинні бути впевнені в тому, що робота може бути виконана в межах установленої вартості, графіка й
накладених обмежень. Досить часто на першому етапі варто задовольнитися попередніми зобов'язаннями
для того, щоб почати роботу й у ході її виконання домогтися необхідних гарантій для прийняття
формальних зобов'язань.
Зобов'язання повинні бути отримані як з боку виконавців, так і з боку організації. Зобов'язання
організації - як тимчасові, так і постійні - необхідно викласти в письмовому вигляді й підписати на
відповідному рівні. Таке документування сприяє взаєморозумінню сторін, а також дає можливість
відслідковувати й підтримувати зобов'язання.
Зобов'язання учасників проекту також повинні бути документовані шляхом візування планів,
письмовим підтвердженням прийняття й розуміння поставленого завдання, участю в розробці й аналізі
планів.
Рекомендовані робочі продукти - результати даного етапу: документовані запити на прийняття
зобов'язань; документовані зобов'язання.
Глосарій
Група процесів (process area) — група взаємозалежних практик, виконання яких дозволяє досягти
мети даної групи процесів.
Ціль (goal) - заява на вищому рівні про те, що повинно бути досягнуто при ефективному
застосуванні практик. Спеціальні цілі застосовні до кожної групи процесів.
Практика (practice) — опис дій, які варто почати, щоб «пустити в хід» ключові елементи даної
групи процесів. Спеціальна практика - це дії, що необхідні для досягнення спеціальної мети.
Типовий робочий продукт (typical work product) — приклад того, що повинно бути отримане в
результаті виконання спеціальної або загальної практики. Ці приклади названі типовими робочими
продуктами, тому що можуть існувати й інші, не менш ефективні, робочі продукти.
Субпрактика (subpractice) — детальний опис дій, які можуть стати керівництвом для інтерпретації
спеціальних і загальних практик. Субпрактики можуть сприйматися як такі, що пропонують елементи,
але в дійсності вони мають інформативний характер і дають корисні ідеї про те, що реально може
принести користь для поліпшення процесів.
Уточнення (discipline amplification) містять інформацію про конкретну інженерну дисципліну
(наприклад, програмування, системний інжиніринг) і пов'язані зі спеціальними практиками.
Загальна ціль (generic goal) називається загальною тому, що одне й та саме формулювання цілі
з'являється в різних групах процесів. У стадійному поданні CMMI кожна група процесів має тільки одну
загальну ціль.
Загальна практика (generic practice) — елемент інституалізації процесів, певним чином гарантія
того, що процеси даної групи будуть ефективними, повторюваними й стабільними.
Уточнення загальних практик (Generic practice elaborations) є
посібником із застосування загальних практик до конкретної групи
процесів.
Тема. ОРГАНІЗАЦІЯ ОФІСУ ПРОЕКТУ
1. Поняття офісу проекту
2. Основні принципи проектування й склад офісу проекту
3. Основні принципи організації віртуального офісу проекту
1. Поняття офісу проекту
Управління великим проектом, як правило, вимагає досить представницької команди, до якої
входять керівник (менеджер) проекту, менеджери та фахівці з напрямків діяльності, ряд функціональних
працівників. Ефективність їх взаємодії значною мірою впливає на ефективність проекту загалом. Разом з
тим, команда проекту - це тимчасове організаційне утворення з не стабільною структурою, яка змінюється
в міру виконання етапів проекту, тобто частина персоналу залучається на певні періоди. Наприклад, деякі
члени команди можуть залучатися до роботи над проектом на неповний робочий день, поряд з основною
діяльністю; хтось із команди може здійснювати функції по реалізації проекту паралельно основній роботі,
працюючи одночасно в іншій організації; члени команди проекту можуть знаходитися не тільки у різних
районах в межах одного міста, але й у різних, часто досить віддалених одне від одного містах, а також
у різних країнах.
Це висуває особливі вимоги до організації роботи команди, забезпечення конфіденційності та
захисту комерційної таємниці проекту. Розв’язання цих проблем забезпечує офіс команди проекту.
Ідеологія офісу, прийнята в розвинених країнах, трактує офіс не тільки й не стільки як окреме
приміщення, обладнане комп'ютерною й оргтехнікою, у якому (яких) здійснюється управління проектом,
але й як інфраструктуру, яка забезпечує всі процеси управління проектом.
Офіс проекту — специфічна інфраструктура, що забезпечує ефективну реалізацію проекту (або
портфеля проектів) у рамках системи комп'ютерних, комунікаційних і інформаційних технологій і
узгоджених стандартів здійснення діяльності й комунікацій.
Основне призначення офісу проекту в даному трактуванні - забезпечення ефективної комунікації
членів команди проекту за спільного виконання робіт, що можливо тільки при наявності розвинених
засобів зв'язку, комп'ютерів і спеціального програмного забезпечення, засобів телекомунікації,
різноманітної оргтехніки, сучасних інформаційних технологій тощо.
Офіс проекту - це оптимально організоване середовище (у традиційному розумінні місце), де члени
команди проекту можуть здійснювати процеси управління проектом, проводити наради, вести переговори
з партнерами, зберігати проектну документацію.
У вітчизняній практиці управління проектами ідеологія офісу проекту практично не
використовується. У західній системі управління проектами офіс проекту в самому узагальненому вигляді
розуміється як:
певний набір робочих місць, прив'язаних до конкретних географічних координат, у тому числі:
головний офіс, де розміщається менеджер проекту, проводяться важливі наради, зберігається
основна документація, встановлені засоби зв'язку, комп'ютерне обладнання й оргтехніка тощо;
набір територіально розподілених офісів (обладнаних робочих місць, у тому числі домашніх,
мобільних) окремих груп або членів команди проекту, де встановлені засоби комунікацій, комп'ютери,
оргтехніка;
віртуальний офіс, не прив'язаний до певного місця, а представляє собою програмно-
телекомунікаційне середовище, яке забезпечує можливість роботи й комунікацій за єдиними
стандартами.
У багатопроектній системі офіс проекту, як правило, являє собою багаторівневу систему:
на першому рівні цієї системи розглядаються конкретні проекти й принципи їх моніторингу. На
цьому рівні працює одна або кілька команд менеджерів, що забезпечують планування проектів з
урахуванням обмежених ресурсів, оцінки витрат і майбутньої вартості проекту, а також контроль
поточного стану проекту й підготовку звітів. Тут використовуються традиційні інструменти й
інформаційні технології моніторингу проектів;
на другому рівні розглядаються питання формування портфеля проектів організації, їх взаємозв'язки
й раціональне наповнення. На цьому рівні базовими є інструменти тендерів (для поповнення портфеля
замовлень), стратегічного менеджменту, управління загальними ресурсами й управління якістю в
проектах;
на третьому рівні розв’язується задача корпоративної політики розвитку проектної організації.
В однопроектній системі офіс орієнтований на управління конкретним проектом.
Експертна оцінка показує, що такий підхід економить 30-40% витрат на проекти й часу на їх
реалізацію.
Основними вимогами до організації офісу проекту є:
наявність реального управлінського офісу - приміщення;
єдині внутрішньофірмові стандарти підготовки й супроводу проектів (проекту);
інформаційна технологія управління проектами;
база даних і шаблонів типових рішень по проектах;
комп'ютерна мережа, сполучена з Internet;
віртуальний офіс на базі комп'ютерних мереж, який забезпечує функціонування команди
проекту в режимі реального часу, незважаючи на територіальну розподіленість членів команди.
Основою віртуального офісу є розподілена комп'ютерна система на базі телекомунікаційних мереж,
що дозволяє користуватися єдиними програмними засобами, єдиними базами даних і знань, вести єдиний
облік, контроль, моніторинг робіт по проекту, проводити відеоконференції, телекомунікаційні наради в
реальному режимі часу.
Переваги віртуального офісу пов'язані з можливістю організації ефективної розподіленої системи
управління проектами (з підключенням домашніх і мобільних офісів). Такий проектний офіс містить дві
групи програмних засобів у рамках технології "клієнт - сервер" або іншої мережевої технології. Перша
група програмних засобів розміщається на сервері й включає засоби ведення баз даних, наприклад Oracle,
Informix, для взаємодії проекту з менеджерами. Друга група розміщається на робочому місці клієнта й на
основі Internet (або іншої системи обміну інформацією) підтримує функції віртуального офісу. Ці
віртуальні функції першого рівня дозволяють менеджерові проекту фіксувати поточний стан проекту по
ресурсах, виконанню робіт і витрат незалежно від реального знаходження членів команди проекту. При
цьому використання мобільної техніки "Notebook + модем + мобільний телефон" робить віртуальну
частину офісу мобільною.
2. Основні принципи проектування й склад офісу проекту
Сучасне поняття офісу містить у собі велику кількість технічних й організаційних рішень, таких, як:
1. Приміщення:
проектування основних приміщень головного офісу проекту (прийняття просторово-
планувальних рішень);
опрацювання питань інтер'єру й внутрішньої обробки приміщень, облаштованості меблями.
2. Оргтехніка й допоміжне обладнання:
пристрої для організації документообігу;
організаційні засоби - дошки для малювання, планшети для календарних графіків, обладнання
для проведення нарад тощо;
організаційна техніка - копіри, проектори, знищувачі паперу;
засоби безпеки - сигналізація, регламентація доступу до приміщень;
господарський інвентар й обладнання.
3. Програмно-комп'ютерні комплекси й засоби зв'язку й телекомунікацій:
комп'ютерна техніка - мережеве обладнання, комп'ютери, сервери, принтери;
програмне забезпечення;
засоби зв'язку - телефонні станції, телефонні апарати, канали зв'язку, пейджери, мобільні
телефони.
Усі ці складові взаємозалежні, тому, говорячи про офіс, слід мати на увазі, що мова йде про єдину
організаційно-технічну систему.
Інформаційні технології, програмно-комп'ютерні засоби та засоби комунікацій в управлінні
проектами докладно розглянуто далі (див. розділ 22). У цьому розділі торкнемося цих питань з точки зору
їх участі в організації офісу проекту.
Конкретний проект характеризується специфікою бізнес-процесів його реалізації. Під бізнес-
процесами розуміється сукупність дій, процедур, що становлять зміст одного завершеного циклу, акту
бізнес-діяльності. Наприклад, бізнес-процес збуту починається із заповнення форми замовлення
менеджером відділу збуту, продовжується плануванням виробництва, підтвердженням доставки від
дистриб'юторів, формуванням рахунку-фактури у фінансовій бухгалтерії, контролем за наданим
товарним кредитом і зарахуванням грошей на рахунок постачальника.
Бізнес-процес розбивається на окремі бізнес-операції (наприклад, оформлення рахунку або доставка
продукції). Елементи бізнес-процесу: генерація ідеї, що визначає загальний напрямок процесу,
формування задуму, формулювання цілей, установлення змісту процесу, планування операції -
зіставлення поставлених завдань і розташовуваних ресурсів з метою мінімізації витрат, складання бізнес-
плану, висновок контракту, пророблення ресурсного забезпечення, реалізація процесу і його завершення.
По суті кожен бізнес-процес у своєму роді представляє якийсь проект, його реалізація здійснюється
в рамках методології управління проектами. Для конкретного проекту виробляється розбивка на окремі
види бізнес-процесів.
Реалізація бізнес-процесів у рамках управління проектом повинна бути організована оптимальним
чином і це обумовлює вимоги до організації офісу:
інформаційний супровід бізнес-процесу повинен бути орієнтований на оптимальне за часом і
витратами його виконання;
повинне бути виключене дублювання бізнес-операцій;
менеджери, що діють у рамках одного бізнес-процесу, повинні бути зв'язані засобами
комунікацій й у випадку розташування в одній географічній крапці локалізовані від менеджерів, що
виконують інші функції.
Це самі загальні вимоги. У даному розділі ми не розглядаємо питання оптимізації бізнес-процесів,
але слід зазначити, що їхня структура визначає локалізацію і структуру офісу. Тому питанням
проектування бізнес-процесів команди проекту має бути приділена першорядна увага при проектуванні
офісу проекту.
Проектування приміщень і площ звичайно здійснюється в спеціалізованому програмному продукті,
наприклад в AutoCAD. Для сполученого проектування архітектури, інтер'єру, організаційної структури й
бізнес-процесів можна експортувати креслення з AutoCAD в Visio2000. Приклад єдиного підходу до
формування просторового, організаційного середовища й оптимізації бізнес-процесів наведений на мал.
6.2.2. На ньому представлена схема планування офісу, розміщень-комп'ютерів і засобів зв'язку,
розміщення персоналу відповідно до бізнес-процесів, реалізованими їм.
Доцільно розглядати організаційну структуру команди проекту й реалізовані бізнес-процеси в
рамках управління проектом у комплексі для оптимізації офісу й системного аналізу технічних,
організаційних й економічних рішень. Даний підхід корисний через те, що сучасні рішення по
проектуванню й організації роботи офісу проекту є комплексними.
Система безпеки не тільки запобігає несанкціонований доступ у приміщення, але за допомогою
магнітних ключів регламентує користування оргтехнікою, комп'ютерами (для використання техніки
необхідно прикласти свій ключ), контролює використання організаційної техніки, дозволяє визначати
місцезнаходження співробітників усередині офісу, регламентує доступ до інформації (як паперової, так й
електронної), контролює місцезнаходження меблів, устаткування й інших матеріальних цінностей.
Сучасні комп'ютери, засоби зв'язку й інформаційні технології настільки зрослись, що варто
розглядати їх як єдину інформаційно-телекомунікаційну систему. По тим самим каналах зв'язку
передаються телефонні повідомлення й дані, при цьому можна звертатися з комп'ютера до телефонних
станціями й апаратам (програмувати автоматичний дозвон, розсилання факсів, організацію й проведення
нарад). Існуючі телефонні станції можуть бути настроєні так, що співробітники мають можливість
дзвонити й передавати дані тільки тим працівникам, які з ними безпосередньо зв'язані в ході виконання
бізнес-процесів.
Природно, одним з важливих рішень із погляду організації роботи офісу є програмне забезпечення,
вибір і впровадження яких повинні реалізувати роботу повноцінного електронного офісу як єдиного
інтегрального Intranet-середовища, що регламентує всі взаємозв'язки співробітників, що організує роботу
з документами, їхнє зберігання, архівування, знищення. При цьому можливо реалізовувати програмно-
апаратні комплекси, що організують і систематизують як електронний, так і паперовий документообіг.
Електронний офіс проекту проектується як система, орієнтована в першу чергу на роботу з
інформацією у вигляді документів, що припускає заміну ручних методів обробки документів
автоматизованими процедурами.
Програмно-телекомунікаційне середовище офісу опирається на розвинене інформаційне
забезпечення проекту, що повинне надавати можливість інтегрованої обробки всіх видів інформації, що
циркулює в системі, у тому числі документів, породжених електронним і паперовим документообігом:
зовнішньої й внутрішньої переписки, здійснюваної як в електронної, так й у паперовій формі.
База даних документів повинна бути елементом єдиної бази даних, інформації й знань команди
проекту; вона формується як централізований електронний архів документів ( що включає в тому числі й
паперові оригінали, і електронні копії оригіналів паперових документів). Система управління базою
даних документів повинна забезпечувати:
централізовану реєстрацію всіх документів, які циркулюють у системі;
зберігання документів в електронному виді в різних форматах;
ведення централізованого каталогу документів проекту, що забезпечує можливість їхнього
пошуку (по ключових атрибутах, з використанням повнотекстового пошуку й т.д.);
зберігання повної історії роботи з документами (хто, коли і як працював з документом), а також
різних версій документів;
надійну систему захисту документів, регламентацію доступу персоналу до документів різного
призначення;
можливість підтримки архівів документів на всіх видах зовнішніх пристроїв, включаючи
магнітооптичні й бібліотеки лазерних компакт-дисків.
Прикладне програмне забезпечення документообігу офісу проекту повинне включати наступні
ключові компоненти:
систему управління зберіганням документів - програмне забезпечення, що реалізує функції
управління єдиним документарним фондом проекту (централізованим архівом);
систему управління документообігом - програмне забезпечення, що реалізує адміністрування
документообігу, управління маршрутизацією й рухом документів, координацією документопотоків,
контролем за пересуванням документів, за своєчасною їхньою обробкою й т.д.;
набір стандартних бізнес-додатків, що використаються командою проекту для підготовки
документів - текстових процесорів, електронних таблиць і т.п., набір спеціалізованих функціональних
додатків, призначених для підготовки документів (на відміну від стандартних бізнес-додатків вони
взаємодіють із базою даних, що підтримує структуровану інформацію);
систему експорту/імпорту документів.
У якості центрального керуючого блоку програмного забезпечення електронного офісу виступає
система управління повноваженнями користувачів, що:
здійснює розмежування доступу користувачів до інформації (у тому числі до документів
різного ступеня таємності);
здійснює регламентацію доступу користувачів до функцій, надаваним системою.
3. Основні принципи організації віртуального офісу проекту
Нині поняття й ідеологія віртуального офісу проекту набувають усе більшого значення у зв'язку з
розвитком мережі Інтернет і зростанням значення програмно-інформаційного й комунікаційного аспекту
управління проектами.
Принципи віртуальних інфраструктур розробляються й практично реалізуються в розвинених
країнах Заходу із середини 90-х років.
У світовій теорії й практиці управління визначення "віртуальний" стало ключовим. Усе частіше
говорять про віртуальні продажі, банківські операції, фонди, фабрики й організації. У принципі
віртуальна інфраструктура має ті самі можливості й потенціал, що й традиційна організація. Але в той же
час віртуальна інфраструктура є принципово новою концепцією організаційної структури для інтеграції
діяльності початку XXI ст. Поняття віртуального підприємства є природним розвитком поняття
комп’ютерно-інтегрованого виробництва, а в більш загальному контексті - характерним прикладом
побудови комп’ютерно-інтегрованої організації на основі нових інформаційних і комунікаційних
технологій.
Перший стиль
(Детальне знання проекту та високий рівень контролю)
• вимагає, щоб план проекту був розроблений дуже детально, щоб всі ці деталі вводились в базу
даних системи та були доступні у будь-який час.
Вимогою є, щоб робоча група проекту здійснювала поточний контроль за роботою через короткі
проміжки часу. Ступінь деталізації залежить від масштабів та складності проекту.
Другий стиль
(Детальне знання проекту та невисокий рівень контролю)
• вимагає, щоб план проекту був розроблений досить детально, і щоб всі ці деталі були введені в базу
даних, але не передбачає, щоб подробиці плану були легко доступними.
Менеджер проекту може не аналізувати всю цю інформацію, а вивчає її тільки вибірково. При
необхідності він повинен отримати детальну інформацію. Такий стиль надає більше свободи
робочій групі при розробці своїх планів.
АІСУП не повинна бути надто чутливою.
Третій стиль
(Невисокі знання деталей проекту та невисокий рівень контролю)
• не потребує розробки дуже деталізованого плану проекту для введення в БД або забезпечення
доступності інформації.
Цей стиль також надає робочій групі більше свободи у розробці власних планів.
Такий підхід називається управління «по відхиленнях».
АІСУП також не повинна бути надто чутливою.
Четвертий стиль
(Невисоке знання деталей проекту та значний рівень контролю)
•Менеджеру
є не зовсім звичайним. Він навпаки вимагає, щоб план проекту не розроблявся дуже детально.
проекту необхідно забезпечити рівень контролю за БД та легку доступність інформації.
Така система буде зручною для менеджера проекту, якому необхідно керувати деталями і якому необхідно
надавати багато звітів про стан справ вищим керівникам різного рівня. Ці звіти повинні бути
довільними за своїм характером.
У цьому випадку АІСУП повинна бути виключно чутливою.
При визначенні вимог до конкретної ІС УП необхідно чітко визначитись на який стиль слід
орієнтуватись і для розв'язання яких задач буде потрібна АІСУП
Для цього керівникові необхідно проаналізувати характер діяльності власної організації з точки зору
можливості і доцільності застосування проектної форми планування і управління.
Яка діяльність може плануватися у вигляді проектів?
Наскільки детально необхідно планувати і контролювати проекти?
Тільки після цього можна з упевненістю сказати наскільки прийняте рішення про використання системи
для управління проектами є обґрунтованим.
Потім необхідно визначитися з класами функцій планування і управління, які повинна реалізувати
ІСУП:
• тільки планування або планування і контроль ходу проекту;
• планування і контроль лише термінів виконання робіт;
• планування і контроль фінансових вкладень без детального планування використання ресурсів;
• детальне планування використання ресурсів;
• багатопроектне управління.
Корисно заздалегідь визначити:
• Приблизні вимоги до розмірності проектів і детальності планування, організаційної структури
управління і звітності.
• Скільки проектів буде вестися одночасно і чи будуть вони взаємозалежними?
• Яка приблизна кількість задач в одному проекті?
• Скільки видів ресурсів буде задіяно в одному проекті і як будуть розділятися ресурси між
проектами?
Корисно заздалегідь визначити:
• Після аналізу всіх вимог необхідно прийняти рішення про вибір ІСУП з тих, що пропонує
ринок, або при відсутності на ринку системи, яка відповідає вимогам– про розробку власної:
Кілька зауважень
Розробка власної ІС обійдеться значно дорожче
Сам процес розробки досить тривалий і відповідно результат від використання такої системи відстає у
часі від моменту вкладення коштів, оскільки, будь-який проект обмежений у часі, це є суттєвим.
Процес розробки досить складний і трудомісткий процес. Він вимагає залучення різноманітних
фахівців.
Розробка нової ІС сама по собі є проектом і відповідно вимагає управління.
Тому, розробка ІС із застосуванням готових ПЗ (як власними силами, так із залученням сторонньої
фірми) є більш доцільним, крім випадків, коли фірма сама є розробником ПЗ.
Дякую за увагу!
Управління закупівлями проекту
• Планування закупівель
• Здійснення закупівель
• Закриття закупівель
1. Сутність управління закупівлями проекту
Управління закупівлями проекту містить у собі процеси покупки або придбання тих необхідних
продуктів, послуг або результатів, які виробляються поза виконуючою організацією. Організація
може виступати в ролі як покупця, так і продавця продуктів, послуг або результатів проекту.
Управління закупівлями проекту містить у собі процеси управління контрактами й змінами,
необхідні для складання й адміністрування контрактів або замовлень на покупку, підготовлених
уповноваженими членами команди проекту.
Управління закупівлями проекту також передбачає адміністрування всіх контрактів на придбання
проекту, укладених сторонньою організацією (покупцем) з виконуючою організацією (продавцем),
а також адміністрування контрактних зобов'язань, покладених на команду проекту за контрактом.
Основні процеси управління закупівлями проекту
• Планування закупівель
• Здійснення закупівель
• Закриття закупівель
Процеси управління закупівлями проекту містять у собі роботу з контрактами, які є юридичними
документами, що регулюють правові відносини між покупцем і продавцем.
Контракт - це взаємна угода, що зобов'язує продавця надати покупцеві певні продукти, послуги або
результати, а покупця - надати продавцеві грошове або інше належне зустрічне задоволення.
Угода може бути простою або складною; у ній може бути відбита простота або складність результатів і
необхідних дій.
Закупівельний контракт містить основні положення й умови та може містити в собі інші пункти, які
визначає покупець для зазначення того, що саме продавець повинен зробити або надати.
Хоча всі документи проекту в тій або іншій формі аналізуються й проходять процедуру узгодження,
процес затвердження контракту звичайно буває більш тривалим у силу юридичної
відповідальності, що він накладає.
У процесі обговорення й затвердження основна увага приділяється точному опису в юридичних
термінах продуктів, послуг і результатів відповідно до вимог проекту.
На ранній стадії команда управління проектом може скористатися підтримкою фахівців у сфері
укладання договорів, закупівельної діяльності, правовій сфері й технічних галузях знань.
Звертання до фахівців за допомогою може бути обов'язковою відповідно до правил організації.
Різні дії, здійснювані в ході процесів управління закупівлями проекту, утворять життєвий цикл
контракту.
Активне управління життєвим циклом контракту й ретельно вивірені формулювання положень і умов
контрактів на закупівлю дозволяють уникнути, знизити або передати продавцеві деякі ризики
проекту, що піддаються визначенню.
Укладання контракту на поставку продукту або надання послуг є одним зі способів розподілу
відповідальності за управління або розподіл потенційних ризиків.
Складний проект може передбачати одночасне або послідовне управління кількома контрактами або
субпідрядами. У таких випадках життєвий цикл кожного контракту може закінчитися під час
кожної з фаз життєвого циклу проекту.
Управління закупівлями проекту розглядається з погляду відносин між продавцем і покупцем.
Відносини покупець-продавець можуть існувати на різних рівнях у рамках будь-якого проекту, а
також між організаціями, що є внутрішніми або зовнішніми стосовно організації-замовника.
Якщо предметом придбання не є матеріали, вироби або звичайні продукти, продавець здійснює
управління роботою як проектом.
У таких випадках покупець стає замовником і, у силу цього, ключовою зацікавленою стороною проекту
для продавця.
Команда управління проектом з боку продавця зацікавлена брати участь у всіх процесах управління
проектом, а не тільки в процесах з даної галузі знань.
Положення й умови контракту стають ключовими входами багатьох процесів управління з боку
продавця. Контракт може безпосередньо містити входи (наприклад, основні результати, ключові
контрольні події, показники вартості) або може обмежувати варіанти вибору команди проекту
(наприклад, схвалення покупцем рішень по забезпеченню проекту персоналом).
При розгляді цієї теми передбачається, що покупець входить у команду проекту, а продавці не є
частиною організації, до якої належить команда проекту.
А також передбачається, що між покупцем і продавцем оформлені й існують формальні договірні
відносини.
Однак більша частина описаного матеріалу рівною мірою застосовна й до недоговірних відносин,
укладених з іншими підрозділами організації команди проекту.
2. Планування закупівель
– купувати чи ні?
Вимоги розкладу проекту можуть впливати на стратегію планування закупівель. На розклад проекту
можуть вплинути рішення, прийняті при розробці плану управління закупівлями. Ці рішення тісно
пов'язані з розробкою розкладу, оцінкою ресурсів операцій (див. тему “Управління строками
проекту”) і рішеннями «виробляти або купувати».
Процес планування закупівель містить у собі аналіз ризиків, пов'язаних з кожним рішенням «виробляти
або купувати», а також аналіз типу контракту, що планується укласти з метою зниження ризиків
або, у деяких випадках, їхньої передачі продавцеві.
Планування закупівель проекту:
входи, інструменти й методи, виходи
Блок-схема даних при плануванні закупівель
Планування закупівель: входи
1. Базовий план по змісту описує потребу в проекті, обґрунтування, вимоги й поточні межі проекту
(Див. тему “Управління змістом”). Він складається з таких елементів:
Опис змісту (опис змісту продукту, опис послуги й опис результату, список результатів і критерії
приймання, а також важлива інформація відносно технічних проблем або питань, які можуть
впливати на оцінку вартості). Серед прикладів обмежень можна навести необхідні дати поставки,
доступність кваліфікованих людських ресурсів і правила організації.
ІСР.
Словник ІСР (наводяться відповідні детальні описи робіт, необхідних для досягнення кожного
результату).
Планування закупівель: входи
2. Документація по вимогах може містити:
• важливу інформацію про вимоги проекту, що враховується під час планування закупівель;
• вимоги, що мають договірні й правові аспекти, які можуть стосуватися здоров'я, безпеки,
надійності, продуктивності, охорони навколишнього середовища, страхування, права на
інтелектуальну власність, рівня можливості працевлаштування, ліцензій й дозволів, - всі ці
аспекти повинні враховуватися при плануванні закупівель.
Планування закупівель: входи
3. Партнерські угоди - це правові договірні угоди між двома або більше господарюючими суб'єктами
про формування партнерств або спільних підприємств або інші домовленості, визначені сторонами.
Ці угоди визначають ролі продавця й покупця для кожної сторони. У момент припинення існування
виниклої комерційної можливості дія партнерської угоди також закінчується. Під час дії
партнерської угоди вона в значній мірі впливає на процес планування проекту. Таким чином, якщо
в рамках проекту діє партнерська угода, ролі продавця й покупця, як правило, визначені, так само
як визначені й такі аспекти, як зміст робіт, конкурентні вимоги й інші важливі питання.
Планування закупівель: входи
4. Реєстр ризиків містить інформацію, що належить до ризиків, наприклад ідентифіковані ризики,
особи, відповідальні за ризики, і реагування на ризики (Див. тему “ Управління ризиками ” ).
5. Контрактні угоди, що стосуються ризиків, включають угоди, у тому числі договори про
страхування, прийняття зобов'язань, надання послуг і інші угоди, що передбачають конкретну
відповідальність кожної зі сторін за визначені ризики (Див. тему “ Управління ризиками ”).
Планування закупівель: входи
6. Вимоги до ресурсів операцій містять інформацію про конкретні потреби, такі як людські ресурси,
обладнання або місце розташування (Див. тему “ Управління строками проекту ”).
7. Розклад проекту містить інформацію про необхідні строки або обов'язкові дати одержання
результатів (Див. тему “ Управління строками проекту ”).
8. Оцінки вартості операцій, розроблені в рамках дій по закупівлях, використовуються для оцінювання
обґрунтованості заявок або пропозицій, отриманих від потенційних продавців (Див. тему “
Управління вартістю проекту ”).
Планування закупівель: входи
9. Базовий план виконання вартості надає докладну інформацію про розподіл запланованого бюджету
в часі (Див. тему “ Управління вартістю проекту ”).
10. Фактори середовища підприємства, які можуть впливати на процес планування закупівель, містять
у собі, серед іншого:
• ситуацію на ринку;
• типові положення й умови поставки продуктів, пропозиції послуг і результатів або галузеві
умови; і
• системи управління, які враховуються при розробці плану управління закупівлями й при
виборі типів контрактів, які будуть використовуватися;
Здійснення закупівель - це процес одержання відповідей від продавців, вибору підходящого продавця й
укладання контракту.
У ході даного процесу команда одержує заявки або пропозиції й застосовує заздалегідь визначені
критерії для вибору одного або кількох продавців, досить кваліфікованих для виконання роботи й
прийнятних як продавців.
Відносно більшості закуповуваних товарів весь процес запиту пропозицій від продавців і оцінювання
цих пропозицій може повторюватися. На основі попередньої пропозиції може бути складений
короткий список підходящих продавців. Потім може бути проведене більш детальне оцінювання на
основі документа, запитаного в продавців зі скороченого списку, з більш конкретними й повними
вимогами.
Здійснення закупівель:
входи, інструменти й методи, виходи
Блок-схема даних при здійсненні закупівель
Здійснення закупівель: входи
1. План управління проектом
План управління закупівлями, частина плану управління проектом (див. тему Управляння інтеграцією) є
входом для здійснення закупівель і описує порядок управління процесами закупівлі, починаючи з
розробки закупівельної документації й закінчуючи закриттям контракту.
2. Закупівельна документація. Описана раніше у цій темі.
3. Критерії вибору постачальника можуть містити в собі інформацію про необхідні здатності,
можливості й технічний досвід постачальника, про дати поставок, вартість продукту, вартість
життєвого циклу й підхід до контракту, як описано раніше у цій темі.
Здійснення закупівель: входи
4. Список кваліфікованих продавців. Список продавців, кваліфікація й минулий досвід яких були
заздалегідь перевірені з метою забезпечення того, щоб закупівлі здійснювалися тільки в тих
продавців, які здатні виконати відповідні контракти.
5. Пропозиції продавців, підготовлені у відповідь на пакет закупівельної документації, складають
основу інформації, що використовується оцінюючим органом, для вибору одного або кількох
найбільш успішних потенційних продавців.
6. Документи проекту, які часто підлягають розгляду, містять у собі:
– інформацію про значимий минулий досвід роботи із продавцями, як гарний, так і поганий.
Здійснення закупівель: інструменти й методи
1. Конференції потенційних продавців (іноді називані «конференціями підрядників», «конференціями
вендорів» або «передтендерними конференціями») - це зустрічі з усіма потенційними продавцями,
що передують підготовці й наданню заявок або пропозицій з їх боку.
Метою таких конференцій є забезпечення ясного однакового розуміння пропонованих вимог до
майбутніх закупівель (наприклад, технічні вимоги й умови контрактів) і недопущення
привілейованого становища кого-небудь із постачальників. Відповіді на питання можуть бути
внесені в закупівельну документацію як поправки. Для дотримання принципу чесності покупець
повинен обов'язково забезпечити умови, за яких всі потенційні продавці можуть вислухати всі
питання кожного окремого потенційного продавця й всі відповіді покупців.
Здійснення закупівель: інструменти й методи
2. Методи оцінювання пропозицій. При здійсненні складних закупівель, у яких вибір постачальника
ґрунтується на відповідях продавців на попередньо визначені зважені критерії, формальний процес
проведення оцінок визначається правилами проведення закупівель, прийнятими покупцем.
Оцінний комітет робить свій вибір, який потім повинне схвалити керівництво до укладання
контракту.
Здійснення закупівель: інструменти й методи
3. Незалежні оцінки. У відношенні багатьох товарів, які придбаває організація-закупник, остання
може на вибір або підготувати свою власну оцінку, що буде служити як еталон для оцінювання, або
звернутися за оцінкою вартості до стороннього професійного оцінювача. Значні розходження в
оцінках вартості можуть указувати на те, що описи робіт із закупівлі є неповними, неоднозначними,
а також/або, що передбачувані продавці або не розуміють, або не змогли повною мірою відповісти
на опис робіт із закупівлі.
4. Експертна оцінка. При оцінюванні пропозицій продавців може використовуватися експертна оцінка.
Пропозиції можуть оцінюватися міждисциплінарною командою експертів, що мають досвід у
кожній зі сфер, що зазначені в закупівельній документації й у пропонованому контракті. У цьому
випадку може придатися досвід у функціональних дисциплінах, таких як укладання контрактів,
юриспруденція, фінанси, бухгалтерський облік, інжиніринг, конструювання, проведення
досліджень, розробка, продажі й виробництво.
Здійснення закупівель: інструменти й методи
5. Оголошення. Перелік потенційних продавців може бути значно розширений шляхом розміщення
оголошень у засобах масової інформації, наприклад газетах або спеціалізованих галузевих
виданнях. На деякі предмети закупівлі поширюються спеціальні вимоги чинного законодавства, що
передбачають розміщення оголошень у засобах масової інформації як обов'язковий захід.
Публікації оголошень у загальнодоступних засобах масової інформації є обов'язковою умовою для
майбутніх контрактів, що укладаються державними організаціями.
6. Пошук в Інтернеті. Інтернет значно впливає на більшість закупівель проекту й на покупки в рамках
ланцюжка поставок в організаціях. Хоча багато сировинних продуктів, деталі або стандартні товари
можна швидко знайти й одержати за фіксованою ціною через Інтернет, заходи щодо закупівлі, що
характеризуються високими ризиками й складністю й потребують ретельного моніторингу, не слід
проводити подібним чином.
Здійснення закупівель: інструменти й методи
7. Переговори по закупівлях. У ході переговорів уточнюється структура, вимоги й інші умови покупок
з метою досягнення узгодженості, яка влаштовує обидві сторони до підписання контракту.
Остаточний текст контракту відображає всі досягнуті узгодженості. У тексті контракту
оговорюються відповідальність, повноваження на внесення змін, юридичні аспекти й регулюючі
закони, технічні й управлінські підходи, права власності, фінансування контакту, технічні рішення,
загальний розклад, платежі й ціна. У результаті переговорів розробляється договірний документ,
який може виконуватися і покупцем, і продавцем.
Переговори по контрактах у відношенні складних закуповуваних товарів можуть бути самостійним
процесом із власними входами (наприклад, проблеми або відкритий список товарів) і виходами
(наприклад, документ про ухвалені рішення). При поставці простих товарів умови поставки в
контракті можуть бути фіксованими й не підлягають подальшому обговоренню. Такі умови можуть
прийматися тільки продавцем.
Не обов'язково, щоб переговори за контрактом очолював менеджер проекту. Менеджер проекту й інші
члени команди управління проектом можуть бути присутніми під час переговорів для надання
допомоги, а також, при необхідності, для уточнення вимог проекту до технічних, управлінських
аспектів і питань якості.
Здійснення закупівель: виходи
1. Обрані продавці - це ті продавці, які були визнані конкурентоспроможними за результатами
оцінювання пропозиції або заявки й з якими були проведені переговори із приводу проекту
контракту, що стане фактичним контрактом після його укладання.
Остаточне схвалення всіх складних закупівель, пов'язаних з високими ризиками й вартістю, як правило,
вимагає їхнього попереднього схвалення вищим керівництвом організації.
Здійснення закупівель: виходи
2. Укладені закупівельні контракти. Закупівельний контракт укладається з кожним обраним
продавцем. Контракт може мати форму простого замовлення на покупку або бути складним
документом. Незалежно від складності документа, контракт є взаємною згодою, що зобов'язує
продавця надати покупцеві зазначені продукти, послуги або результати, а покупця - надати
продавцеві певне грошове або інше зустрічне задоволення. Контракт фіксує юридичні відносини,
усі суперечки по яких можуть бути врегульовані в судовому порядку.
Здійснення закупівель: виходи
Основні елементи договірного документа можуть різнитися, але зокрема можуть містити в собі таке:
– завдання (опис робіт) або очікувані результати;
– базовий розклад;
– звіти про виконання;
– період виконання;
– ролі й відповідальності;
– місце виконання контракту продавцем;
– ціни;
– порядок оплати;
– місце поставки;
– критерії перевірки й приймання;
– гарантійні зобов'язання;
– підтримку продукту;
– обмеження відповідальності;
– винагороди й утримання;
– штрафні санкції;
– способи заохочення;
– страхові гарантії й гарантії виконання контракту;
– схвалення вибору субпідрядників;
– управління запитами на зміну; і
– механізми припинення дії контракту й альтернативного вирішення суперечок (АРКС, ADR).
Метод АРКС може бути визначений заздалегідь у рамках оформлення закупівлі.
Здійснення закупівель: виходи
3. Ресурсні календарі. Документується кількість і доступність договірних ресурсів, а також дати, коли
кожний окремий ресурс може використовуватися, а коли ні.
4. Запити на зміну плану управління проектом, його допоміжних планів і інших елементів
обробляються для розгляду й подання в рамках процесу здійснення загального управління змінами
(див. тему “Управління інтеграцією”.
5. Оновлення плану управління проектом. Елементи плану управління проектом, які можуть бути
оновлені, містять у собі, серед іншого:
– базовий план за вартістю;
– базовий план по змісту;
– базовий розклад; і
– план управління закупівлями.
6. Оновлення документів проекту. Документи проекту, які можуть бути оновлені, містять у собі, серед
іншого:
– документацію по вимогах;
– документацію по відстеженню вимог; і реєстр ризиків.
4. Управління закупівельною діяльністю
Управління закупівельною діяльністю також містить елемент фінансового управління, що містить у собі
моніторинг платежів продавцю.
Це дозволяє гарантувати, що умови платежів, визначені положеннями контракту, виконуються належним
чином, а виплати продавцеві безпосередньо пов'язані з виконанням останнім своїх зобов'язань за
контрактом.
Одним із принципових питань при здійсненні платежів постачальникам є створення тісного зв'язку між
зробленими платежами й виконаною роботою.
• Базовий план розкладу. Якщо є відставання, які впливають на загальне виконання проекту,
можливо, буде потрібно оновлення базового плану розкладу для відбиття поточних
очікувань.
5. Закриття закупівель
Закриття закупівель являє собою процес завершення всіх закупівель проекту. Даний процес є
допоміжним для процесу завершення проекту або фази, оскільки містить у собі підтвердження
того, що всі роботи й результати виявилися прийнятними.
Процес закриття закупівель також містить у собі такі адміністративні дії як повне врегулювання
відкритих претензій, оновлення документів для відбиття остаточних результатів і архівування такої
інформації для майбутнього використання. При закритті закупівель розглядається кожний контракт,
що має відношення до проекту або фази проекту. У проектах, що складаються з кількох фаз, умови
контракту можуть застосовуватися тільки до певної фази проекту. У таких випадках процес
закриття закупівель закриває тільки ті закупівлі, які застосовні до цієї фази проекту. Нерозв'язані
претензії можуть передаватися для судового розгляду після закриття. Умови й положення контракту
можуть пропонувати певні процедури закриття контракту.
Передчасне припинення дії контракту є особливим випадком закриття закупівлі, що може бути
викликаний взаємною згодою обох сторін, невиконанням зобов'язань однієї зі сторін або в
інтересах покупця, якщо таке передбачено в контракті. Права й відповідальності сторін у випадку
передчасного припинення дії контракту містяться в умовах припинення дії контракту. На підставі
даних умов і положень контракту покупець може мати право розірвати весь контракт або його
частину з певної причини або з міркувань своєї зручності в будь-який час. Однак у силу тих самих
умов і положень контракту покупцеві, можливо, доведеться компенсувати продавцеві витрати,
понесені у фазі підготовки, а також вартість всіх завершених і прийнятих робіт, пов'язаних з
перерваною частиною контракту.
Закриття закупівель:
входи, інструменти й методи, виходи
Блок-схема даних при закритті закупівель
Закриття закупівель: входи
1. План управління проектом (див. “Управління інтеграцією”)
2. Закупівельна документація. З метою закриття контракту здійснюється збір, нумерація й архівування
всієї закупівельної документації. Інформація про виконання строків, змісту, якості й вартості
контракту, а також вся документація по змінах контракту, записи про проведені платежі й
результати перевірок заносяться в каталог. Ця інформація може використовуватися як інформація
про накопичені знання й основа для оцінювання підрядників для майбутніх контрактів.
Закриття закупівель: інструменти й методи
1. Аудит закупівель є структурованою перевіркою процесу закупівель, починаючи із процесу
планування закупівель і закінчуючи управлінням закупівельною діяльністю. Метою аудиту
закупівель є визначення успіхів і невдач, що дозволяє виконуючій організації використовувати
позитивний досвід і уникнути помилок при підготовці або адмініструванні інших закупівельних
контрактів проекту або інших проектів.
2. Урегулювання шляхом переговорів. У всіх закупівельних взаєминах остаточне справедливе
врегулювання всіх нерозв'язаних проблем, претензій і розбіжностей за допомогою переговорів є
основною метою. У тих випадках, коли врегулювання не може бути досягнуте шляхом прямих
переговорів, можуть використовуватися деякі способи й механізми альтернативного розв'язання
конфліктних ситуацій (АРКС), у тому числі посередництво або арбітражний суд. Варіантом з
найменшою перевагою, застосовуваним тільки в тому випадку, якщо всі інші закінчилися
невдачею, є розгляд у суді.
3 Система управління документами. Описана раніше у цій темі.
Закриття закупівель: виходи
• .1 Закриті закупівлі
• Покупець, звичайно через свого вповноваженого адміністратора закупівель, направляє продавцеві
формальне письмове повідомлення про завершення контракту. Вимоги до формального закриття
закупівель звичайно визначаються в умовах і положеннях контракту й включаються в план
управління закупівлями.
• .2 Оновлення активів процесів організації
• Елементи активів процесів організації, які можуть бути оновлені, містять у собі, серед іншого:
• Архів закупівель. Повний пакет пронумерованих контрактних документів, у тому числі закритий
контракт, підготовляється й включається в остаточний архів проекту.
• Приймання результатів. Звичайно покупець зобов'язує призначеного їм адміністратора контракту
сповістити продавця в офіційному письмовому повідомленні про те, що результати прийняті або не
прийняті. Вимоги до офіційного приймання результатів і порядок вирішення суперечок за
результатами, не відповідним вимогам контракту, звичайно вказуються в тексті контракту.
• Документацію по накопичених знаннях. Накопичені знання й рекомендації з удосконалення
процесів повинні бути розроблені для архіву проекту з метою підвищення ефективності управління
закупівлями в майбутньому.
Управління комунікаціями проекту
• Планування комунікацій
• Поширення інформації
Управління комунікаціями проекту містить у собі процеси, необхідні для своєчасного створення,
збору, поширення, зберігання, одержання й використання інформації проекту.
Менеджери проектів витрачають велику частину свого часу на здійснення комунікацій із членами
команди й з іншими зацікавленими сторонами проекту, незалежно від того, чи вони є внутрішніми
(на всіх рівнях організації) або зовнішніми стосовно організації.
Ефективні комунікації є мостом, що пов'язує різні зацікавлені сторони, що залучені в проект, поєднуючи
різноманітні культурні й організаційні особливості, різні рівні досвіду, а також різні погляди й
інтереси відносно виконання або результату проекту.
Основні процеси управління комунікаціями проекту
• Планування комунікацій
• Поширення інформації
• внутрішні (у рамках проекту) і зовнішні (із замовником, іншими проектами, ЗМІ, громадськістю);
• усні й письмові; і
• постановку питань, пропозицію ідей і ситуацій для розгляду з метою поліпшення розуміння;
• навчання з метою підвищення знань членів команди, що, у свою чергу, підвищує продуктивність
їхньої праці;
Для успіху проекту критично важливо визначити зацікавлені сторони проекту на його ранній стадії, а
також проаналізувати сфери їхніх інтересів, очікувань і рівні важливості й впливу.
Потім для максимізації позитивного впливу й зниження потенційних негативних наслідків можна
розробити стратегію індивідуального підходу до кожної зацікавленої сторони проекту й визначення
рівня й строків її залучення в проект.
Оцінка й відповідна стратегія повинні періодично переглядатися в ході виконання проекту з метою
їхньої адаптації до потенційних змін.
• матрицю впливу/впливу, що групує зацікавлені сторони проекту на основі їхньої активної участі
(«впливу») у проекті і їхньої здатності вносити зміни в планування або виконання проекту
(«впливу»); і
• модель особливостей, що описує класи зацікавлених сторін проекту залежно від їхнього рівня
влади (здатності нав'язувати свою волю), наполегливості (необхідності в негайних діях) і
законності (їхня участь є невід'ємним).
Приклад матриці влади/інтересів з нанесеними зацікавленими сторонами проекту
Визначення зацікавлених сторін проекту: інструменти й методи
Крок 3: Оцінити, у який спосіб ключові зацікавлені сторони проекту швидше за все будуть реагувати
або діяти в різноманітних ситуаціях, для того щоб спланувати, як вплинути на них з метою
посилення їхньої підтримки й скорочення потенційних негативних впливів.
Визначення зацікавлених сторін проекту: інструменти й методи
2. Експертна оцінка. Для забезпечення всебічного визначення й внесення в список зацікавлених сторін
проекту необхідно одержати оцінку або експертну думку від таких осіб або груп осіб, що пройшли
спеціальну підготовку або мають знання в даній предметній області, наприклад:
• вищого керівництва;
• менеджерів проектів, що працювали над проектами з тієї ж галузі (прямо або за допомогою
накопичених знань);
• Оцінну інформацію: основні вимоги й очікування, потенційний вплив у проекті, фаза в життєвому
циклі проекту, що найбільше цікавить; і
• організаційні діаграми;
• інформація про зацікавлені сторони проекту з Реєстру зацікавлених сторін проекту й стратегії
управління зацікавленими сторонами проекту.
Планування комунікацій: інструменти і методи
2.Технології комунікацій. Методи передачі інформації серед зацікавлених сторін проекту можуть
значно різнитися. Наприклад, команда проекту може використовувати різноманітні методи
комунікацій, від коротких обговорень до повноцінних нарад, від простих письмових документів до
матеріалів (наприклад, розкладів і баз даних), доступних через Інтернет.
Фактори, які можуть впливати на проект, містять у собі:
• Доступність технології.
• Тривалість проекту.
• Доступність технології. Чи дійсно необхідні системи, що вже встановлені й діють, або потрібно
включити їх у список потреб проекту? Наприклад, чи є в передбачуваної (их) зацікавленої сторони
(зацікавлених сторін) проекту доступ до обраної технології комунікацій?
• Інтерактивні комунікації.
• Комунікації методом інформування без запиту.
•Як, коли
Комунікації методом інформування за запитом.
і які методи комунікацій будуть використовуватися - вирішує менеджер проекту залежно від
вимог до комунікацій.
Планування комунікацій: інструменти і методи
Інтерактивні комунікації. Між двома або більше сторонами, що здійснюють багатобічний обмін
інформацією. Цей метод є найефективнішим для забезпечення загального розуміння вмзначених
питань всіма зацікавленими сторонами; він містить у собі зустрічі, телефонні переговори,
відеоконференції й т.д.
Планування комунікацій: інструменти і методи
Комунікації методом інформування без запиту. Інформація відсилається певним одержувачам, які
повинні про неї довідатися.
Цей метод забезпечує поширення інформації, але не гарантує того, що вона буде фактично отримана або
зрозуміла передбачуваною аудиторією. До комунікацій методом інформування без запиту належать
листи, записки, звіти, повідомлення електронною поштою, факси, голосові послання, прес-релізи й
т.д.
Планування комунікацій: інструменти і методи
Комунікації методом інформування за запитом. Використовуються для дуже великих обсягів
інформації або для дуже великих аудиторій, коли потрібно, щоб одержувачі зверталися до
переданого змісту за своїм власним бажанням. До таких методів належать сайти інтрамереж,
навчання з використанням електронних технологій, банки даних і т.д.
Планування комунікацій: виходи
• відомості про передану інформацію, включаючи мову, формат, зміст й ступінь деталізації;
• методи або технології, використовувані для передачі інформації (наприклад, службові записки,
повідомлення електронною поштою й/або прес-релізи);
• схема передачі по інстанціях, що визначає строки й порядок передачі на вищі рівні (ланцюжок
імен) проблем, які не можуть бути розв’язані персоналом на більш низькому рівні;
• розклад проекту;
• Вибір засобів зв'язку. Прийняті рішення про те, коли краще спілкуватися усно, а коли письмово,
коли краще написати неформальну записку, а коли формальний звіт, а також коли краще поговорити
особисто, а коли написати електронний лист.
• шаблони; і
Управління очікуваннями зацікавлених сторін проекту містить у собі такі комунікаційні дії, спрямовані
на надання впливу на очікування зацікавлених сторін проекту й розв'язання проблем і вирішення
питань, що їх турбують:
• прояснення й розв'язання виявлених проблем. Їхнє розв'язання може призвести до запиту на зміну,
або воно може бути здійснене за межами проекту, наприклад, відкладене до наступного проекту або
фази або передано іншому підрозділу організації.
• урегулювання конфліктів;
• активне слухання; і
• навички письма; і
• Реєстр зацікавлених сторін проекту. Оновлюється в міру зміни інформації про зацікавлені
сторони проекту, коли виявляються нові зацікавлені сторони, коли зареєстровані сторони більше не
беруть участі у проекті або більше не піддані його впливу, або в тих випадках, коли потрібні інші
оновлення, пов'язані з певними зацікавленими сторонами проекту.
Підготовка звітів про виконання являє собою процес збору й поширення інформації про виконання,
включаючи звіти про стан, результати виміру виконання й прогнози.
Процес підготовки звітів про виконання включає періодичний збір фактичних даних і їхнє зіставлення з
базовим планом для оцінки просування проекту і його виконання, передачі даної інформації, а
також прогнозування результатів проекту.
Звіти про виконання повинні надавати інформацію на відповідному для кожної аудиторії рівні. Їхній
формат може варіюватися від простого звіту про поточний стан до більш деталізованих звітів.
Підготовка звітів про виконання: входи, інструменти, методи й виходи
Блок-схема даних у процесі підготовки звітів про виконання
Підготовка звітів про виконання: входи
1. План управління проектом надає інформацію з базових планів проекту.
Базовий план виконання є затвердженим планом робіт із проекту, з яким порівнюється виконання
проекту, а також виміряються відхилення для контролю управління. Базовий план виконання, як
правило, поєднує параметри змісту, строків і вартості проекту, але також може включати
технічні показники й параметри якості.
2. Інформація про виконання робіт. Здійснюється збір такої інформації про результати виконання
операцій проекту:
– статус результатів;
– хід виконання розкладу; і
–Підготовка
понесені витрати.
звітів про виконання: входи (продовження)
3. Результати вимірювання виконання робіт. Інформація про виконання робіт використовується для
створення метрик операцій проекту, що дозволяє оцінити фактичне виконання в порівнянні із
плановим. Ці метрики містять у собі, серед іншого:
– шаблони звітів;
• Визначити вплив відхилень по вартості й строках проекту, а також в інших його областях (тобто
коректування виконання якості й зміна змісту й т.д.)
– Методи часових рядів. Використовують історичні дані як основу для оцінювання майбутніх
результатів. Наприклад, метод освоєного обсягу, екстраполяція, оцінка тренду й крива росту.
– Суб'єктивні методи. Містять у собі інтуїтивні судження, думки й імовірнісні оцінки. Наприклад,
опитування, метод Дельфі, розробка сценаріїв, прогнозування технологій і прогнозування по
аналогіях.
– Інші методи. Інші методи можуть містити в собі моделювання, імовірнісне прогнозування й
прогнозування по множині.
Підготовка звітів про виконання:
інструменти й методи
3. Методи комунікацій
Для обміну й аналізу інформації про хід виконання проекту можуть проводитися наради по оцінці
поточного стану. Менеджер проекту, як правило, використовує метод інформування без запиту,
описаний у разделе 10.2.2.4, для поширення звітів про виконання.
Підготовка звітів про виконання:
інструменти й методи (закінчення)
4. Системи звітності надає менеджерові проекту стандартний інструмент для збору, зберігання й
поширення серед зацікавлених сторін проекту інформації про вартість, просування й виконання
проекту.
Пакети програмного забезпечення дозволяють менеджерові проекту поєднувати звіти з кількох систем і
полегшують поширення звітів серед зацікавлених сторін проекту. Прикладами форматів
поширення можуть бути: звіти у формі таблиць, аналіз за допомогою електронних таблиць і
презентації. Для візуального подання інформації про виконання проекту можуть
використовуватися графічні пакети.
Підготовка звітів про виконання: виходи
1. Звіти про виконання організують і поєднують зібрану інформацію, а також представляють
результати будь-якого аналізу в порівнянні з базовим планом виконання.
Звіти повинні надавати інформацію про поточний стан і прогрес виконання проекту, на тім рівні
деталізації, що потрібно різним зацікавленим сторонам проекту, що зафіксовано в плані
управління комунікаціями. Найпоширенішими форматами звітів про виконання є стрічкові
діаграми, S-побідні криві, гістограми й таблиці.
Часто у звітність про виконання включають аналіз відхилень, аналіз освоєного обсягу й прогнозовані
дані. На наступному слайді у табличному виді представлені дані освоєного обсягу (див. тему
“Управління вартістю”).
Приклад звіту про виконання в табличному форматі
Підготовка звітів про виконання: виходи
Звіти про виконання складаються періодично, і їхній формат може варіюватися від простого звіту про
поточний стан до більш деталізованих звітів.
У простому звіті про поточний стан може міститися тільки така інформація про виконання, як відсоток
виконання або дані про поточний стан по кожній галузі знань з УП (наприклад, по змісту, строках,
вартості й якості).
Деталізовані звіти можуть містити в собі:
• рекомендовані коригувальні впливи містять у собі зміни, які повинні привести очікуване майбутнє
виконання проекту у відповідність із планом управління проектом; і