ISO 21502 “Управління проєктами” – це неофіційний переклад міжнародного стандарту ISO 21502:2020 “Project, programme and portfolio management — Guidance on project management”. Користуйтесь, та надсилайте свої зауваження та пропозиції.

Підтримати розробку стандартів українською
Тренінг з управління проєктами згідно ДСТУ ISO 21502:2022

Передмова

ISO (the International Organization for Standardization – Міжнародна організація зі стандартизації) – це всесвітня федерація національних органів зі стандартизації (установи-учасниці ISO). Робота з підготовки міжнародних стандартів зазвичай здійснюється в технічних комітетах ISO. Кожна установа-учасниця, що зацікавлена у предметі, для якого створено технічний комітет, має право бути представленою у цьому комітеті. В роботі також беруть участь урядові та неурядові міжнародні організації, що підтримують зв’язок з ISO. ISO тісно співпрацює з Міжнародною електротехнічною комісією (МЕК) з усіх питань електротехнічної стандартизації.

Процедури, що використовуються для розробки цього документа, та процедури, призначені для його подальшого впровадження, описані в Частині 1 Директив ISO/IEC. Зокрема, слід зазначити, що для різних типів документів ISO необхідні різні критерії затвердження. Цей документ розроблено відповідно до редакційних правил Частини 2 Директив ISO/IEC (див. www.iso.org/directives).

Варто зазначити, що деякі елементи цього документа можуть бути предметом патентних прав. ISO не несе відповідальності за виявлення будь-яких або всіх таких патентних прав. Детальна інформація про будь-які патентні права, виявлені під час розробки документа, міститиметься у Вступі та/або в списку ISO отриманих патентних заявок (див. www.iso.org/patents).

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

Для пояснення добровільного характеру стандартів, значення конкретних термінів і висловів ISO, пов’язаних з оцінкою відповідності, а також інформацію про дотримання ISO принципів Світової організації торгівлі (СОТ) у Технічні бар’єри в торгівлі (TBT), див. www.iso.org/iso/foreword.html.

Цей документ підготував Технічний Комітет ISO/TC 258, Управління проєктами, програмами та портфелями.

Це перше видання ISO 21502 “Управління проєктами”, разом з ISO 21500, відміняє та заміняє ISO 21500:2012, який було переглянуто технічно. Головні зміни, порівняно з ISO 21500:2012, є такими:
a) концепцію управління проєктами було розширено для включення діяльності щодо нагляду за перебігом проєкту і вказівок організації-спонсора;
b) було додано інформацію про те, як проєкти постачають кінцеві результати та запускають реалізацію вигод;
c) було додано розгляд організаційного контексту проєктів;
d) було додано опис додаткових проєктних ролей та зобов’язань;
e) було додано нові теми, такі як створення проєктного середовища, яке забезпечує успіх; життєві цикли проєкту, точки та ворота прийняття рішень; додаткові проєктні практики, такі як управління вигодами та контроль за змінами, для відображення поточних практик управління проєктами;
f) було додано до- та після-проєктні активності;
g) було змінено формат з процесно-орієнтованого на практично-орієнтований та заснований на історії (див. Додаток А).

Будь-який зворотній зв’язок стосовно цього документа має бути направлений до національного підрозділу зі стандартів користувача. Повний перелік таких підрозділів знаходиться за посиланням www.iso.org/members.html.

Вступ

Цей документ (ISO 21502 “Управління проєктами”) надає настанови щодо концепцій та практик для управління проєктами, які важливі для поставки проєкту та впливають на її успіх.

Цільова аудиторія цього документу включає, але не обмежується:
a) виконавче та старше керівництво для кращого розуміння процесу управління проєктами та допомогу їм у здійсненні необхідної підтримки та управління керівниками проєктів та іншими особами, задіяними у проєктах;
b) осіб, залучених до врядування, вказівок, засвідчення, аудиту та управління проєктами, таких як спонсори проєкту, проєктні ради, аудитори та керівники проєктів;
c) керівників проєктів та членів проєктних команд, з метою створення спільної бази для розуміння, виконання, порівняння, оцінки та комунікації щодо практик, які використовуються в їх проєкта;
d) розробників національних чи організаційних стандартів, процесів та методів управління проєктами.

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

1 Сфера застосування

Цей документ (ISO 21502 “Управління проєктами”) надає поради щодо управління проєктами. Вони можуть бути застосовані для будь-якої організації, включно з публічними, приватними та благодійними, а також для будь-якого типу проєкту, незалежно від цілі, підходів до поставки, моделі життєвого циклу, що застосовується, складності, розміру, вартості чи тривалості.

ПРИМІТКА: Підхід до поставки може бути будь-яким методом чи процесом, який підходить до типу набутків, наприклад предиктивним, інкрементальним, ітеративним, адаптивним чи гібридним, включаючи аджайл-підходи.

Цей документ надає високорівневі описи практик, що розглядаються як вдалі та такі, що створюють гарні результати в контексті управління проєктами. Цей документ не надає порад щодо управління програмами чи портфелями. Теми, пов’язані з загальним управлінням, розтлумачено в контексті управління проєктами.

2 Нормативні посилання

Цей документ (ISO 21502 “Управління проєктами”) не містить нормативних посилань.

3 Терміни та визначення понять

У цьому документі (ISO 21502 “Управління проєктами”) використано такі терміни та визначення понять.

Логотип ДСТУ ISO 21502:2022 Управління проєктами, програмами та портфелями — Настанови щодо управління проєктамиISO та IEC підтримують термінологічну базу даних для використання у стандартизації, і вона доступна за посиланням:
– ISO Онлайн пошукова платформа, доступна тут https://www.iso.org/obp
– IEC Electropedia: доступна тут http://www.electropedia.org/

3.1
базовий план (baseline)
еталонний зразок для порівняння, який використовують для моніторингу та контролю за виконанням

[ДЖЕРЕЛО: ДСТУ ISO/TR 21506:2022, 3.1]

3.2
вигода (benefit)
створена перевага, цінність чи інший позитивний ефект

[ДЖЕРЕЛО: ДСТУ ISO/TR 21506:2022, 3.7]

3.3
бізнес-кейс (business case)
задокументоване обґрунтування на підтримку прийняття рішення про зобов’язання щодо початку проєкту (3.20), програми (3.18) або портфеля (3.15)

[ДЖЕРЕЛО: ДСТУ ISO/TR 21506:2022, 3.4]

3.4
запит на зміну (change request)
документація, що визначає запропоновані зміни до проєкту (3.20)

[ДЖЕРЕЛО: ДСТУ ISO/TR 21506:2022, 3.25]

3.5
управління конфігурацією (configuration management)
застосування процедур з метою контролю (3.6), співвідношення та підтримки документації, специфікацій та фізичних атрибутів

[ДЖЕРЕЛО: ДСТУ ISO/TR 21506:2022, 3.91]

3.6
контроль (control)
порівняння фактичного виконання робіт із запланованим, аналіз відхилень та виконання необхідних коригувальних дій (3.7) або запобіжних дій (3.17)

[ДЖЕРЕЛО: ДСТУ ISO/TR 21506:2022, 3.46]

3.7
коригувальна дія (corrective action)
напрям та операція для модифікації виконання робіт задля приведення результатів у відповідність із планом

[ДЖЕРЕЛО: ДСТУ ISO/TR 21506:2022, 3.49]

3.8
критичний шлях (critical path)
послідовність операцій, які визначають найранішу можливу дату завершення проєкту (3.20) або фази

[ДЖЕРЕЛО: ДСТУ ISO/TR 21506:2022, 3.50]

3.9
доробок (deliverable)
унікальний та такий, що може бути перевірений, елемент, що має бути створений під час проєкту (3.20)

[ДЖЕРЕЛО: ДСТУ ISO/TR 21506:2022, 3.18]

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

[ДЖЕРЕЛО: ДСТУ ISO/TR 21506:2022, 3.14]

3.11
обставина (issue)
подія, що виникає під час проєкту (3.20), і потребує вирішення задля продовження проєкту

3.12
нагода (opportunity)
виникнення ризику, який може мати сприятливий вплив

[ДЖЕРЕЛО: ДСТУ ISO/TR 21506:2022, 3.54]

3.13
кінцевий результат (outcome)
зміна в результаті використання набутку (3.14) проєкту (3.20)

3.14
набуток (output)
сукупні матеріальні чи нематеріальні доробки (3.9), які утворюють результат проєкту (3.20)

3.15
портфель (portfolio)
набір компонентів портфеля (3.16), згрупованих разом для полегшення управління ними задля досягнення стратегічних цілей
[ДЖЕРЕЛО: ДСТУ ISO/TR 21506:2022, 3.73]

3.16
компонент портфеля (portfolio component)
проєкт (3.20), програма (3.18), портфель (3.15) або інша супутня робота

[ДЖЕРЕЛО: ДСТУ ISO/TR 21506:2022, 3.44]

3.17
запобіжна дія (preventive action)
дія, яку виконують, щоб усунути причину потенційної невідповідності чи іншої потенційно небажаної ситуації

Примітка: Запобіжну дію виконують, щоб запобігти виникненню події, тоді як коригувальну дію (3.7) – щоб запобігти повторному виникненню події.

[ДЖЕРЕЛО: ДСТУ ISO 9000:2015, 3.12.1, модифіковано — Оригінальну примітку 1 до визначення було видалено.]

3.18
програма (programme)
група компонентів програми (3.19), якими скоординовано керують задля реалізації вигід (3.2)

[ДЖЕРЕЛО: ДСТУ ISO/TR 21506:2022, 3.75]

3.19
компонент програми (programme component)
проєкт (3.20), програма (3.18) або інша супутня робота

[ДЖЕРЕЛО: ДСТУ ISO/TR 21506:2022, 3.45]

3.20
проєкт (project)
тимчасове зусилля для досягнення однієї чи кількох визначених цілей

[ДЖЕРЕЛО: ДСТУ ISO/TR 21506:2022, 3.77]

3.21
засвідчення проєкту (project assurance)
заплановані та систематичні дії, важливі для впровадження впевненості організації-спонсора та проєктного спонсора (3.26) в тому, що проєкт (3.20), скоріше за все, досягне своїх цілей.

3.22
врядування проєктом (project governance)
принципи, політики та процедури, за допомогою яких затверджують проєкт (3.20) та спрямовують його на досягнення узгоджених цілей

[ДЖЕРЕЛО: ДСТУ ISO/TR 21506:2022, 3.17]

3.23
життєвий цикл проєкту (project life cycle)
визначений набір фаз від початку до кінця проєкту (3.20)

3.24
управління проєктами (project management)
скоординовані операції для спрямування та контролю (3.6) за досягненням узгоджених цілей

[ДЖЕРЕЛО: ДСТУ ISO/TR 21506:2022, 3.94]

3.25
обсяг проєкту (project scope)
це затверджені роботи для досягнення узгоджених цілей

[ДЖЕРЕЛО: ДСТУ ISO/TR 21506:2022, 3.57]

3.26
спонсор (sponsor)
особа, яка несе відповідальність за отримання ресурсів та прийняття управлінських рішень з метою досягнення успіху

[ДЖЕРЕЛО: ДСТУ ISO/TR 21506:2022, 3.83]

3.27
стейкхолдер (stakeholder)
особа, група або організація, які мають інтерес до, можуть впливати на, можуть перебувати під впливом або вважати себе під впливом будь-якого аспекту проєкту (3.20), програми (3.18) або портфеля (3.15)

[ДЖЕРЕЛО: ДСТУ ISO/TR 21506:2022, 3.85]

3.28
загроза (threat)
ризик, виникнення якого матиме негативний вплив

[ДЖЕРЕЛО: ДСТУ ISO/TR 21506:2022, 3.24]

3.29
ієрархічна структура робіт (work breakdown structure)
декомпозиція визначеного обсягу проєкту (3.20) або програми (3.18) на щораз нижчі рівні, що складаються з елементів робіт

[ДЖЕРЕЛО: ДСТУ ISO/TR 21506:2022, 3.38]

3.30
пакет робіт (work package)
група операцій, що мають визначений обсяг, доробок (3.9), час виконання та вартість

Якщо треба швидко вивчити цю тему, зверніть увагу на тренінг з управління проєктами згідно ДСТУ ISO 21502

4 Концепції управління проєктами

4.1 Огляд

4.1.1 Загальні положення

Розділ 4 описує концепції, що стосуються управління проєктами, які використовують при застосуванні практик, описаних в Розділах 6 та 7. Рисунок 1 ілюструє контекст та середовище, в межах якого проєкт може існувати. Проєкт може бути автономним або частиною програми чи портфелю (див. 4.2.5), і може перетинати ці межі всередині організації та між організаціями. Слід використовувати стратегію організації для визначення, документування та оцінки нагод, загроз, слабких та сильних сторін, які можуть допомогти попередити про подію в майбутньому. Відібрані нагоди та загрози можуть бути додатково досліджені та обґрунтовані у бізнес-кейсі. Внаслідок бізнес-кейсу можуть бути ініційовані один чи кілька проєктів. Очікується, що набутки проєктів принесуть кінцеві результати, які повинні реалізувати вигоди для організацій-спонсорів, а також для внутрішніх чи зовнішніх стейкхолдерів.

ПРИМІТКА: Пунктирні лінії операційного боксу вказують, що операції можуть розтягнутися в проєкті, програмі та портфелі (пунктирні лінії можуть бути посиланням як “інші супутні роботи”).

Рисунок 1. Приклад управління проєктами в контексті врядування та управління програмами і портфелями

4.1.2 Проєкти

Організації беруть на себе роботу для досягнення конкретних цілей. Загалом, ця робота може бути класифікована як операція або проєкт. Операції та проєкти відрізняються тим, що:
a) проєкти є тимчасовими та сфокусовані на збереженні чи створенні нової цінності або здатності для організації-спонсорів, стейкхолдерів чи клієнтів;
b) операції виконуються як безперервна діяльність і можуть бути сфокусовані на підтримці організації, наприклад, через постачання повторюваних товарів та послуг.

Ціль проєкту може бути досягнута комбінацією доробків, набутків, кінцевих результатів і вигод, що залежать від контексту проєкту (див. 4.2) та вказівок, наданих врядуванням (див. 4.3). Ціль проєкту повинна сприяти кінцевим результатам та реалізації вигод для стейкхолдерів, включаючи організацію-спонсора, інших внутрішніх та зовнішніх організаційних стейкхолдерів, клієнтів та їх стейкхолдерів. Незважаючи на те, що багато проєктів мають схожі особливості, кожен з них є унікальним. Відмінність між проєктами може полягати у таких факторах (включаючи, але не обмежуючись наведеним):
– цілі;
– контекст;
– бажані кінцеві результати;
– надані набутки;
– стейкхолдери, шо зазнають впливу;
– використані ресурси;
– складність;
– обмеження (див. 4.2.4);
– використані процеси і методи.

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

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

4.2 Контекст

4.2.1 Вплив контексту проєкту

4.2.1.1 Загальні положення

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

4.2.1.2 Фактори в межах організації

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

4.2.1.3 Фактори поза межами організації

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

4.2.2 Стратегія та проєкти організації

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

Рисунок 2. Приклад створення цінності в результаті виконання проєктів або програм

4.2.3 Перспектива клієнта та виконавця

Проєкти можна розглядати з двох точок зору:
a) замовника або організації-спонсора: організація володіє вимогами і може або виконати роботу, або замовити частину чи всю роботу організації-виконавцю;
b) організації-виконавця або підрядника: організація надає, як ключову основу або частину свого бізнесу, послугу чи товар іншим організаціям.

ПРИКЛАД 1 Приклади послуги або товару, що постачаються виконавцем або підрядником як проєкт для отримання доходу, можуть включати будівництво доріг, аеропортів, залізниць та систем інформаційних технологій.

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

ПРИКЛАД 2 Відділ інформаційних технологій організації може здійснити оновлення програмного забезпечення для виробничого відділу, використовуючи законтрактовані ресурси або партнерів. У таких ситуаціях ролі виконавця і замовника можуть бути багатовимірними.

Сторони договору повинні визначити:
– як врядування проєктами (див. 4.3) повинне функціонувати як на боці кожної окремої сторони, так і між сторонами, зв’язаними контрактними відносинами;
– структуру команди управління проєктами організації (див. 4.5.1);
– відповідних людей, які будуть залучені до проєкту;
– робочі практики, які мають бути застосовані впродовж життєвого циклу проєкту, якщо це необхідно для його виконання.

4.2.4 Обмеження проєкту

Досягати набутків та кінцевих результатів проєкту слід в межах визначеного набору обмежень, включаючи, але не обмежуючись наведеним:
a) тривалість або цільова дата завершення проєкту;
b) наявність фінансування з боку організації;
c) затверджений та розподілений бюджет;
d) наявність ресурсів проєкту, таких як люди з відповідними навичками, матеріальна база, обладнання, матеріали, інфраструктура, засоби та інші ресурси, необхідні для здійснення операцій, пов’язаних з вимогами до проєкту;
e) фактори, які стосуються здоров’я та захисту персоналу;
f) безпека;
g) прийнятний рівень ризику;
h) потенційний вплив проєкту та його набутків на соціальне, навколишнє та екологічне середовище;
i) закони, правила та інші державні вимоги;
j) мінімальні стандарти якості.

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

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

4.2.5 Проєкти як самостійна частина програми або портфеля

Проєкти можуть бути організовані як компоненти програм або портфелів або можуть бути самостійними одиницями (див. ДСТУ ISO 21503 та ДСТУ ISO 21504). Дивись Рисунок 3 як приклад того, як проєкти пов’язані з іншими компонентами.

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

Рисунок 3. Приклад взаємозв’язку між портфелями, програмами та проєктами

4.3 Врядування проєктами

4.3.1 Фреймворк врядування

Врядування проєкту повинне включати принципи, політики та фреймворки, за допомогою яких організація спрямовує, авторизує та контролює проєкт згідно зі схваленим бізнес-кейсом. Врядування повинне встановлювати нагляд за такими суб’єктами, як:
a) політики, процеси та методи, які використовують для виконання операцій та застосування практик, визначених цим документом;
b) фреймворки управління, включно з життєвим циклом проєкту (див. 4.4);
c) ролі та обов’язки, включно з межами відповідальності для прийняття рішень (див. 4.5).

Відповідальність за врядування проєктом зазвичай покладається на спонсора проєкту органом врядування організації-спонсора (див. 4.5.4) чи проєктною радою (див. 4.5.3).

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

4.3.2 Бізнес-кейс

Бізнес-кейс є основою для врядування проєкту. Для обґрунтування початку та продовження проєкту слід використовувати бізнес-кейс, який, як мінімум, повинен включати або посилатися на:
a) цілі, що мають бути досягнуті;
b) стратегічне узгодження та потенційні вигоди, що мають бути реалізовані;
c) визначені метрики для оцінки здобутої цінності;
d) прийнятний рівень ризику для організації;
e) бюджет, розклад та вимоги щодо якості;
f) потенційна діяльність та перепони щодо інших операцій організації;
g) залучення стейкхолдерів та управління взаєминами або стосунками;
h) використання людських та матеріальних ресурсів;
i) необхідні навички, знання та компетенції;
j) цільовий обсяг;
k) презентація сценаріїв;
l) запропонований управлінський підхід;
m) можливість підтримувати бізнес та організаційні активності під час змін.

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

Під час визначення життєвого циклу проєкту слід врахувати таке:
a) врядування організації та проєкту;
b) ризики;
c) фактори контролю;
d) природа чи характеристики проєкту;
e) інші фактори середовища чи організації.

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

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

Точки прийняття рішень та фази, як показано на Рисунку 4, повинні бути визначені, але можуть відрізнятися залежно від організаційного або зовнішнього середовища, фінансування, вигод, які вимагаються, ризиків та обмежень. Рисунок 4 далі ілюструє зв’язки між життєвим циклом проєкту, практиками інтегрованого управління проєктами (див. Розділ 6) та практиками управління для проєкту (див. Розділ 7).

ПРИМІТКА 1: В деяких випадках, фази можуть накладатися одна на іншу.
ПРИМІТКА 2: Фази іноді називають “етапами”.

Рисунок 4. Взаємозв’язок між життєвим циклом проєкту, практиками інтегрованого управління проєктами та практиками управління для проєкту

4.5 Проєктна організація та ролі

4.5.1 Проєктна організація

Проєктна організація – це тимчасова структура, яка визначає ролі, зони відповідальності та повноваження у проєкті. Учасникам поіменно присвоюють певні ролі в проєктній організації. Проєктна організація повинна:
a) визначити чіткий порядок звітності;
b) бути схвалена спонсором проєкту або радою проєкту;
c) бути відома всім, хто залучений в проєкт.

Структура проєктної організації може залежати від контексту проєкту (див. 4.2), середовища організації (див. 4.4), та стейкхолдерів (див. 4.5.10).

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

Приклад структури проєктної організації подано на Рисунку 5. Взаємозв’язки між ролями в межах проєктної організації слід визначити і керувати ними як описано в 7.5.

ПРИМІТКА 1: Якщо існує рада проєкту, порядок звітності може змінюватись відповідно до домовленостей врядування.
ПРИМІТКА 2: Офіс управління проєктами не обов’язково існує в усіх організаціях.

Рисунок 5. Приклад структури проєктної організації

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

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

Ролі та зони відповідальності в проєктній організації деталізовані в 4.5.24.5.11.

4.5.2 Організація-спонсор

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

ПРИМІТКА: Щодо практик інтегрованого управління проєктами, пов’язаних з організацією-спонсором, дивись 6.2, 6.3 і 6.9.

4.5.3 Рада проєкту

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

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

Якщо проєкт є спільним для двох чи більше організацій, до ради проєкту можуть входити представники кожної з організацій (див. ДСТУ ISO 21505).

ПРИМІТКА: Загальновживаними назвами для ради проєкту є, окрім іншого, “керівна група проєкту”, “керівна рада проєкту”, “керівний комітет проєкту” чи “комітет врядування”.

4.5.4 Спонсор проєкту

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

Спонсор проєкту повинен відстоювати бізнес-кейс та відповідати за врядування проєктом, включно з аудитами, розглядами та засвідченнями (див. ДСТУ ISO 21505). Окрім цього, спонсор проєкту відповідає, окрім іншого, за:
a) підтвердження того, що проєкт є виправданим впродовж усього життєвого циклу;
b) підтвердження того, що керівник проєкту та команда достатньо кваліфіковані та компетентні, щоб виконувати доручену їм роботу;
c) надання керівнику проєкту рішень, вказівок, порад та контексту, щоб забезпечити можливість адресувати бізнес-потребу, описану в бізнес-кейсі, в межах прийнятного рівня ризику проєкту чи організації;
d) підтвердження того, що організація готова до змін всередині організації чи в суспільстві та того, що такі зміни стаються (див. 7.14);
e) опрацювання ескальованих обставин та ризиків;
f) залучення ключових стейкхолдерів;
g) прийняття рішень у межах делегованих повноважень;
h) передання ризиків та обставин, що є за межами його повноважень, вищому уповноваженому органу;
i) задання культурного та етичного тону проєкту.

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

ПРИМІТКА 1: Загальновживаними назвами для спонсора проєкту є також “виконавець проєкту”, “власник проєкту”, “представник власника продукту” і “старший відповідальний власник” (див. Рисунок 5).

ПРИМІТКА 2: Щодо практик інтегрованого управління проєктами, пов’язаних зі спонсором проєкту, див. 6.4.

4.5.5 Засвідчення проєкту

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

4.5.6 Керівник проєкту

Керівник проєкту відповідає перед спонсором проєкту та радою проєкту за виконання визначеного обсягу проєкту, і також за лідерство та управління командою проєкту. Інша діяльність керівника проєкту може включати, окрім іншого:
a) визначення підходу управління згідно з ухваленим підходом врядування;
b) мотивацію команди проєкту;
c) щоденне кураторство та лідерство;
d) визначення підходу, відповідальностей, обсягу роботи та цілей команди;
e) спостереження, передбачення та звітування загального прогресу відносно плану проєкту (див. 7.2 і 7.15);
f) управління ризиками (див. 7.8) та обставинами (див. 7.9);
g) контроль та управління змінами проєкту (див. 7.10);
h) управління діяльністю постачальників згідно з відповідними договорами (див. 7.17);
i) залучення стейкхолдерів (див. 7.12) та комунікації (див. 7.13) з ними згідно з планом;
j) затвердження доробків та кінцевих результатів проєкту.

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

ПРИМІТКА: Щодо практик інтегрованого управління проєктами, пов’язаних з керівником проєкту, дивись 6.5, 6.6 і 6.8.

4.5.7 Проєктний офіс

Проєктний офіс, за потреби, повинен мати власну визначену роль, нести відповідальність та надавати звітність. Проєктні офіси можуть здійснювати різноманітну діяльність для підтримки керівника проєкту та команди, таку як, окрім іншого:
a) аналіз;
b) визначення та здійснення врядування;
c) стандартизація проєктних методів та процесів;
d) навчання з управління проєктами;
e) планування і моніторинг;
f) управління інформацією;
g) надання адміністративної підтримки.

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

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

ПРИМІТКА: Проєктний офіс також може називатись “офіс управління проєктами”, “офіс підтримки проєктів”, або іншим погодженим в компанії терміном.

4.5.8 Відповідальний за пакет робіт

Відповідальний за пакет робіт відповідає перед керівником проєкту за управління та поставку закріплених за ним набутків та кінцевих результатів, визначених у пакеті робіт. Відповідальний за пакет робіт чи лідер команди може бути представником організації-спонсора або зовнішньої організації, наприклад, підрядника. Відповідальний за пакет відповідає, окрім іншого, за:
a) підтвердження того, що пакети робіт виконані вчасно, з відповідною якістю та в межах бюджету;
b) написання та перевірку основної управлінської документації;
c) планування, моніторинг, прогнозування та звітування загального прогресу відносно плану для пакету робіт.
d) управління врегулюванням ризиків та обставин та ескалацію тих ризиків і обставин, що потребують вирішення на вищому рівні врядування.
e) контроль за змінами в обсязі робіт та за те, щоб отримувати дозвіл на ті зміни, які перебувають за межами їх відповідальності.
f) управління та оптимізацію використання ресурсів;
g) передачу набутків команді проєкту або керівнику проєкту.

ПРИМІТКА 1: Керівник проєкту може також виконувати роль відповідального за пакет робіт.
ПРИМІТКА 2: Щодо практик інтегрованого управління проєктами, пов’язаних з відповідальним за пакет робіт, дивись 6.7.

4.5.9 Члени команди проєкту

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

4.5.10 Стейкхолдери проєкту

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

Рисунок 6. Приклад потенційних стейкхолдерів проєкту

4.5.11 Інші ролі

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

4.6 Компетенції персоналу проєкту

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

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

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

5 Передумови для формалізації управління проєктами

5.1 Огляд

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

Перш ніж починати формалізувати процес управління проєктами в організації, слід оцінити наступне:
a) типи, розмір, частоту та складність поточних та майбутніх проєктів;
b) позитивний та негативний вплив на організацію, включно з впливом на стратегічні цілі, баченням, місією та іншими організаційними міркуваннями;
c) підготовка організації до впровадження управління проєктами, включно з вимогами до людських ресурсів та необхідної організаційної структури, системами та змінами процесів;
d) вплив на клієнтів та інших стейкхолдерів.

5.2 Ідеї щодо впровадження управління проєктами

Впровадження формалізованого процесу управління проєктами в організації необхідно реалізовувати як проєкт, програму чи частину портфеля проєктів залежно від масштабу та складності організаційних або суспільних змін, які відбулись. Розглядаючи можливість застосування формалізованого підходу до управління проєктами, організація повинна враховувати, такі фактори, але не обмежуватись ними:
a) визначені потреби та вигоди від формалізованого процесу управління проєктами;
b) можливість інтегрувати та узгоджувати інші супутні роботи зі стратегічними та бізнес-цілями;
c) спроможність сприймати необхідні зміни в межах організаційного врядування, структури та культури;
d) ресурсна спроможність організації поєднувати зміни, враховуючи, але не обмежуючись, людські ресурси та бюджет;
e) потенційний вплив як на внутрішніх, так і на зовнішніх стейкхолдерів;
f) здатність працювати з організаційними обмеженнями;
g) наявність необхідних компетенцій для реалізації підходу для майбутніх проєктів;
h) вплив на бюджети, виявлені ризики, графіки та вимоги поточної та запланованої діяльності організації.

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

5.3 Постійне вдосконалення середовища управління проєктами

Виконавче та вище керівництво повинні сприяти постійному вдосконаленню середовища та культури, яке має на меті перевіряти та підтримувати поточну придатність, адекватність, результативність та ефективність управління проєктами в організації. За необхідності слід проводити заходи, що сприяють безперервному вдосконаленню, включаючи, але не обмежуючись:
a) встановлення процесу оцінки для фреймворку управління проєктами організації з наголосом на перевірці відповідності стратегії організації, бізнес- та операційним цілям організації, а також ступеня, в якому уроки були засвоєні та впроваджені;
b) оцінка ефективності фреймворку управління та врядування проєктами ;
c) впровадження визначених та узгоджених удосконалень;
d) визначення та встановлення пріоритетів удосконалень та коригувань, що мають бути впроваджені;
e) збір та впровадження засвоєних уроків задля вигод поточних та майбутніх проєктів;
f) розвиток навичок управління проєктами у персоналу шляхом навчання, тренування та наставництва.

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

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

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

5.4 Узгодження з організаційними процесами та системами

Фреймворк врядування проєктами повинен узгоджуватися з іншими організаційними процесами та системами, включаючи, але не обмежуючись:
a) організаційне врядування;
b) звітність про результати діяльності;
c) процедури та відповідні підходи до поставки, що можуть бути застосовані;
d) управління ризиками;
e) управління портфелями та програмами;
f) управління інвестиціями та фінансами;
g) бізнес-аналіз, стратегічне та оперативне планування;
h) управління інформацією та документацією;
i) управління якістю.

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

6 Практики інтегрованого управління проєктами

6.1 Огляд

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

Інтеграція та адаптація вибраних практик управління для проєктами, визначених у Розділі 7, у цілісний підхід до управління проєктною роботою може бути ключем до успіху проєкту. Метою цих практик інтегрованого управління проєктами є надання можливості проєктній організації:
a) досягнути цілей проєкту;
b) визначити і керувати обсягом проєкту в рамках обмежень, враховуючи ризики та потреби в ресурсах;
c) отримати підтримку від кожної організації, яка бере участь та виконує свої обов’язки в проєкті, включаючи зобов’язання власників ресурсів, спонсорів, постачальників, клієнтів, користувачів та інших стейкхолдерів.

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

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

Практики інтегрованого управління проєктами, показані на Рисунку 7 і включають до- та після-проєктні заходи. Взаємозв’язки між заходами та пов’язаними з ними ролями наведено у 4.5. Підрозділи 6.26.9 детально описують кожну практику.

Рисунок 7. Погляд на практики інтегрованого управління проєктами, взаємозв’язки та пов’язані ролі

6.2 До-проєктні заходи

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

Для уможливлення прийняття рішення щодо початку проєкту слід достатньо детально вмотивувати та задокументувати цілі та вигоди проєкту, його обґрунтування та інвестиції. Таку документацію можна використати для того, аби забезпечити визначення пріоритетів потреб та нагод. Визначення пріоритетів може стосуватися:
a) деякого аспекту організаційної стратегії чи плану основної діяльності;
b) потреб вищих за рівнем програми чи портфеля;
c) потреб клієнтів.

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

ПРИМІТКА: Обґрунтування необхідності розпочинати проєкт можна визначити у таких документах, як технічне завдання, короткий опис проєкту, пропозиція чи попередній бізнес-кейс (див. 4.3.2).

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

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

6.3 Нагляд за проєктом

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

Цей нагляд можна здійснити за допомогою:
a) участі у прийнятті ключових рішень;
b) періодичної звітності;
c) перевірок та аудитів, щодо засвідчення;
d) ситуативних ескалацій та втручань.

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

ПРИМІТКА: Дивись 4.5.2 про роль організації-спонсора у нагляді за проєктом.

6.4 Спрямування проєкту

Метою спрямування проєкту є надання можливості проєкту продовжувати бути актуальним та виправданим в контексті організації.
Спонсор проєкту, якого підтримує чи контролює рада проєкту, повинен підтвердити, що:
a) вирішується потреба організації, бачення та цілі зіставляються зі стратегічними припущеннями та встановлюються критерії для оцінки успіху проєкту;
b) проєкт постійно обґрунтовується, а бізнес-кейс оновлюється, якщо цього вимагає врядування організації;
c) рішення, ймовірно, відповідає потребам організації з точки зору набутків, кінцевих результатів та очікуваних вигод;
d) використовуються відповідні та компетентні ресурси;
e) роботи припиняють, коли обґрунтування організації більше не виправдане.

ПРИМІТКА: Дивись 4.5.4 та 4.5.3 по ролі спонсора проєкту та ради проєкту щодо керівництва проєктом.

6.5 Ініціація проєкту

6.5.1 Огляд

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

ПРИМІТКА 1: “Ініціація проєкту” може також називатися “початок проєкту” або “проєктна ініціація”.
ПРИМІТКА 2: Дивися 4.5.6 щодо ролі керівника проєкту в ініціації проєкту.

6.5.2 Мобілізація команди проєкту

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

6.5.3 Підхід до врядування та управління проєктом

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

Керівник проєкту, за погодженням із спонсором проєкту, повинен визначити спосіб ініціації, спрямування, моніторингу, контролю та закриття проєкту, відповідно до вимог врядування (див. 4.3). Типово, це має включати:
a) життєвий цикл проєкту (див. 4.4);
b) організацію проєкту, ролі та відповідальність (див. 4.5);
c) процеси та методи для здійснення управлінської діяльності описані в Розділі 6 та 7;
d) процеси та методи для постачання набутків та кінцевих результатів проєкту (див. 6.7).

Підхід до управління проєктами може бути описаний в єдиному документі, одному загальному документі з набором допоміжних документів або набором допоміжних документів, що охоплюють конкретні практики, такі як План управління ризиками або План управління якістю (див. ДСТУ ISO 21505)

ПРИМІТКА: Назви документів, що описують підхід до управління, можуть відрізнятися. Приклади назв включають “План управління проєктом”, “Документація про ініціювання проєкту”, “Документ про визначення проєкту”, “План реалізації проєкту”, “Статут проєкту” та “Сфера дії проєкту”. Допоміжні документи для конкретних практик управління проєктами іноді називають “планами управління”, наприклад, “План управління ризиками або стратегією”, “План управління якістю”, “План управління обсягом або стратегією”.

6.5.4 Початкове обґрунтування проєкту

Початкове обґрунтування проєкту має базуватися на обґрунтуванні до-проєктних заходів (див. 6.2). Це обґрунтування повинне бути задокументоване в бізнес-кейсі (див. 4.3.2). Бізнес-кейс може бути розроблено впродовж кількох етапів проєкту в міру прогресу роботи і його слід оновлювати, щоб відображати суттєві зміни в контексті та обсязі проєкту.

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

ПРИМІТКА: Хоча документ, що обґрунтовує здійснення проєкту, часто називають “бізнес-кейсом”, фактична назва, що використовується, може відрізнятись залежно від сектору або використовуваного методу.

6.5.5 Початкове планування проєкту

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

6.6 Контроль за проєктом

6.6.1 Огляд

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

ПРИМІТКА: Див. 4.5.6 щодо ролі керівника проєкту в контексті контролю за проєктом.

6.6.2 Прогресивне обґрунтування

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

6.6.3 Управління ефективністю проєкту

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

Керівник проєкту повинен збирати та аналізувати дані про хід та результати діяльності для оцінки прогресу відносно узгодженого плану проєкту, включаючи:
— виконану роботу, виконані віхи та здійснені витрати (див. 7.2);
— заплановані або реалізовані вигоди (див. 7.3);
— управління обсягом (див. 7.4);
— отримання достатніх ресурсів для завершення робіт (див. 7.5);
— управління графіком та витратами (див. 7.6 та 7.7);
— ідентифікацію та управління ризиками та обставинами (див. 7.8 та 7.9);
— управління контролем за змінами (див. 7.10);
— якість робіт (див. 7.11);
— статус запланованого та прогнозованого залучення стейкхолдерів та комунікації (див. 7.12 та 7.13);
— управління переходом набутків до організації-спонсора чи замовника, а також підготовка та управління організаційними або суспільними змінами (див. 7.14);
— звітування про прогрес (див. 7.15);
— підтримку цілісності та доступності інформації та документації (див. 7.16);
— управління статусом закупівельної діяльності (див. 7.17);
— нові засвоєні уроки (див. 7.18).

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

Керівник проєкту повинен керувати різними технічними, адміністративними та організаційними заходами та інтерфейсами в межах проєкту.

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

6.6.4 Управління початком та завершенням кожної фази проєкту

За сприяння відповідальних за пакети робіт чи інших експертів керівник проєкту повинен підготуватися до початку кожної фази проєкту шляхом:
a) підготовки або перегляду детального плану фази;
b) перегляду вимог врядування та управління;
c) підтвердження, разом із спонсором проєкту, що проєкт все ще виправданий;
d) перегляду підходу управління відносно роботи, необхідної в цій фазі;
e) отримання дозволу на початок наступної фази.

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

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

6.6.5 Управління початком, прогресом та закриттям кожного пакету робіт

Керівник проєкту повинен контролювати пакети робіт на кожному етапі шляхом:
a) перевірки та затвердження плану для кожного пакету робіт, після того, як переконається, що він узгоджується та інтегрується із загальним планом проєкту та відповідної фази;
b) забезпечення того, що роботи з інтеграції та доробки між пакетами робіт та в їх межах є запланованими, здійсненими і відповідають вимогам;
c) покладання відповідальності за кожен пакет робіт на відповідального за пакет робіт;
d) ініціювання пакетів робіт відповідно до плану проєкту або у відповідь на ризик або обставину;
e) перевірки прогресу роботи, включаючи вирішення будь-яких ризиків, обставин або запитів на зміни;
f) перевірки якості доробків;
g) підтвердження завершення, передачі доробків та закриття пакету робіт.

6.7 Управління поставкою

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

Робота проєкту може бути організована у пакети робіт для розподілу та контролю роботи, що проводяться різними командами. Пакети робіт повинні бути призначені відповідальному за пакет робіт (див. 4.5.8). Робота повинна бути належним чином визначена, спланована, відстежена і контрольована, а якістю слід активно керувати. Методи та процеси роботи повинні бути пристосовані для використання, щоб максимізувати ймовірність успіху в проєктному середовищі. Відповідальний за пакет робіт повинен моніторити, вимірювати та контролювати доручену роботу відповідно до затвердженого плану проєкту, використовуючи практики, визначені у Розділі 7. Слід вживати запобіжних та коригувальних дії та, за потреби, вносити запити на зміну для досягнення поставлених цілей роботи.

Відповідальний за пакет робіт повинен керувати постачанням своїх пакетів робіт, включаючи але, не обмежуючись:
a) планування призначених пакетів робіт (див. 7.2 до 7.7);
b) мобілізація команди;
c) вирішення ризиків, обставин, запитів на зміну та поглядів стейкхолдерів (див. 7.8, 7.9, 7.10 та 7.12);
d) управління постачальниками, якщо такі є (див. 7.17);
e) розробку необхідних набутків із використанням відповідних та пропорційних методів та технік (див. 7.11);
f) перевірку та підтвердження доробків;
g) інформування керівника проєкту про прогрес, ескалацію ризиків, обставин та запитів на прийняття рішень та вказівки (див. 7.15);
h) збір та застосування засвоєних уроків (див. 7.18);
i) закриття пакету робіт, як тільки керівник проєкту підтвердить його виконання (див. 6.6.5);
j) ведення записів про виконану роботу (див. 7.16).

ПРИМІТКА 1: Набутки іноді називають “активами” (див. ДСТУ ISO 55000).
ПРИМІТКА 2: Дивись 4.5.8 щодо ролі менеджера пакету робіт в контексті управління постачанням.

6.8 Закриття чи припинення проєкту

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

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

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

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

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

До завершення проєкт може бути припинений спонсором проєкту або організацією-спонсором з наступних причин, включаючи, але не обмежуючись:
a) проєкт більше не потрібний і не життєздатний;
b) пов’язані з проєктом ризики стали неприпустимо високими;
c) зовнішній споживач більше не бажає отримання набутків проєкту.

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

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

ПРИМІТКА: Дивись 4.5.6 щодо ролі керівника проєкту в контексті закриття або припинення проєкту.

6.9 Після-проєктні заходи

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

Спонсор проєкту повинен забезпечити проведення перевірки для визначення ступеня успішності проєктів в програмах або портфелях, або тих проєктів, що потребують заходів після закриття, включаючи:
a) досягнення визначених цілей;
b) реалізацію вигід;
c) забезпечення організаційних чи соціальних змін або кінцевих результатів, таких як операційна ефективність;
d) досягнення стійких змін, включаючи безперервне задоволення очікувань, встановлених у бізнес-кейсі.

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

ПРИМІТКА: Дивись 4.5.2 щодо ролі організації-спонсора в контексті після-проєктних заходів.

7 Практики управління для проєкту

7.1 Огляд

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

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

Рисунок 8. Практики управління для проєкту відносно практик інтегрованого управління проєктами

7.2 Планування

7.2.1 Огляд

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

7.2.2 Розробка плану

Планування повинне бути спільною операцією, з можливим залученням членів команди до планування їх роботи. Оцінки повинні бути виправданими. План може включати:
a) вигоди, які слід реалізувати (див. 7.3);
b) обсяг: бажані набутки та кінцеві результати (див. 7.4) з урахуванням якості (див. 7.11);
c) необхідні ресурси, такі як люди, матеріали, інструменти та обладнання, та інші організації (див. 7.5);
d) розклад: коли потрібно виконати операції (див. 7.6);
e) вартість (див. 7.7);
f) ризики, властиві плану (див. 7.8);
g) припущення та обмеження.

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

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

7.2.3 Моніторинг плану

План повинен буди послідовним та інтегрованим. План повинен бути достатньо деталізованим, щоб встановити базові плани. Такі базові плани можуть відображати будь-які аспекти плану, такі як вимоги, обсяг, якість, розклад, вартість, ресурси та ризики. Зміни до базових планів слід проводити контрольовано (див. 7.10).

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

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

7.3.1 Огляд

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

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

7.3.2 Ідентифікація та аналіз вигід

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

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

Ідентифікація та аналіз вигід повинні включати, але не обмежуватися:
a) ідентифікацію та пріоритезацію очікуваних вигід;
b) ідентифікацію можливих негативних наслідків від очікуваних вигід;
c) ідентифікацію додаткових вигід протягом життєвого циклу проєкту;
d) ідентифікацію масштабів будь-яких необхідних організаційних та суспільних змін;
e) ідентифікацію стейкхолдерів для кожної вигоди, яка має бути реалізована;
f) узгодження вигід зі стратегічними та іншими цілями;
g) визначення показників продуктивності та звітування для кожної вигоди;
h) визначення періоду часу для реалізації вигід;
i) перевірка того, що заплановані набутки та кінцеві результати ймовірно нададуть необхідні вигоди.

ПРИМІТКА: Потенційні проєкти розглядаються у межах до-проєктного періоду (див. 6.2 та Рисунок 7).

7.3.3 Моніторинг вигід

Моніторинг вигід включає, але не обмежується:
a) моніторинг прогресу протягом життєвого циклу проєкту у напрямку досягнення кінцевих результатів та їх впливу на реалізацію запланованих вигід;
b) збір показників вимірювання виконання для кожної вигоди;
c) надання звітності та інформування про стан очікуваних вигід.

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

7.3.4 Підтримка вигід

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

7.4 Управління обсягом

7.4.1 Огляд

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

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

7.4.2 Визначення обсягу

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

Авторизована робота, що формує обсяг проєкту, може бути визначена з точки зору цілей проєкту, планування або ієрархічної структури робіт. За необхідності обсяг повинен бути додатково розроблений і розділений на частини в ієрархічній структурі робіт, або в іншому типі структури. Структура робіт ідентифікує, визначає та документує необхідну роботу, щоб створити основу для планування (див. ДСТУ ISO 21511). Слід узгодити відповідні критерії прийняття.

7.4.3 Контроль обсягу

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

7.4.4 Підтвердження постачання обсягу

Постачання набутків та кінцевих результатів, які формують обсяг проєкту, має бути підтверджене відповідно до визначених критеріїв прийняття, включаючи:
a) перевірку та підтвердження, що вимоги якості та стандарти якості проєкту були дотримані (див. 7.11);
b) підтвердження того, що організація-спонсор, замовники та інші стейкхолдери готові отримати, та де це доречно, використати доробки проєкту;
c) управління передачею доробків та, де це доречно, відповідальності, від команди проєкту до організації-спонсору або замовнику;
d) отримання підтвердження, що передача була завершена.

ПРИМІТКА: Дивись 7.14 щодо управління організаційними та соціальними змінами, які є результатом проєкту.

7.5 Управління ресурсами

7.5.1 Огляд

Метою управління ресурсами є визначення ресурсів, необхідних для постачання обсягу проєкту з точки зору якості, кількості та оптимального використання. Ресурси повинні бути невід’ємною частиною плану проєкту (див. 7.2).

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

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

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

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

7.5.2 Планування проєктної організації

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

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

7.5.3 Створення команди

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

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

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

7.5.4. Розвиток команди

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

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

7.5.5 Управління командою

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

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

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

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

7.5.6 Планування, управління та контроль фізичних та матеріальних ресурсів

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

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

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

7.6 Управління розкладом

7.6.1 Огляд

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

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

Керівник проєкту повинен порівнювати прогрес зі схваленим базовим розкладом, щоб забезпечити своєчасне виконання обсягу в межах встановлених обмежень розкладу та цілей проєкту. Контроль розкладу повинен включати моніторинг стану фаз, пакетів робіт та операцій, пов’язаних з проєктом. Контроль також має включати в себе управління змінами в розкладі, моніторинг віх та введення інших елементів контролю, які є доцільними. Такі техніки, як управління здобутою цінністю, можуть бути використані для відстеження фактичних результатів та прогнозування майбутньої продуктивності (див. ДСТУ ISO 21508).

7.6.2 Оцінка тривалості операцій

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

7.6.3 Розробка розкладу

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

Розклад слід розробляти, щоб визначити:
a) чи можна досягти цілей проєкту вчасно;
b) критичний шлях та пов’язані з ним ризики;
c) фактичний прогрес, досягнутий за розкладом, порівняно зі схваленим базовим розкладом.

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

7.6.4 Контроль розкладу

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

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

При контролі розкладу фокус має бути на:
a) визначенні досягнутого на сьогодні прогресу;
b) порівнянні фактичного виконання робіт із затвердженим базовим розкладом для визначення будь-яких відхилень;
c) прогнозуванні дати закінчення;
d) здійсненні відповідних запобіжних або коригувальних дій для уникнення несприятливих затримок у розкладі.

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

7.7 Управління вартістю

7.7.1 Огляд

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

В межах управління вартістю слід оцінити вартість кожного елемента робіт, розробити бюджет, отримати кошти та контролювати вартість проєкту. Для моніторингу витрат та передбачення майбутнього виконання проєкту можна використовувати такі техніки як управління здобутою цінністю (див. ДСТУ ISO 21508).

7.7.2 Оцінка вартості

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

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

7.7.3 Розробка бюджету

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

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

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

7.7.4 Контроль вартості

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

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

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

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

7.8 Управління ризиками

7.8.1 Огляд

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

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

7.8.2 Ідентифікація ризиків

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

ПРИМІТКА: запис ризиків може мати назву “реєстр ризиків”, “перелік ризиків” або будь-який інший термін, що використовують в організації.

7.8.3 Оцінювання ризиків

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

ПРИМІТКА 1: Наслідки також можуть називати “впливом”.

ПРИМІТКА 2: Ймовірність також можуть називати “можливість”.

7.8.4 Реагування на ризики

Реагування на ризики передбачає підготовку варіантів дій для посилення нагод та зменшення загроз проєкту. Заходи з реагування на ризики можуть включати, окрім іншого:
a) прийняття;
b) уникнення;
c) пом’якшення;
d) передачу;
e) використання резервів;
f) використання;
g) посилення.

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

Залишкові ризики можуть виникати як наслідок заходів реагування на кожен ризик. Реагування на ризик може передбачати відхилення від плану або зміну до базового плану (див. 7.10).

7.8.5 Контроль ризиків

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

7.9 Управління обставинами

7.9.1 Огляд

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

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

7.9.2 Ідентифікація обставин

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

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

ПРИМІТКА: Запис обставин може мати назву “реєстр обставин”, “журнал обставин” або будь-який інший термін, що використовують в організації.

7.9.3 Вирішення обставин

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

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

7.10 Контроль змін

7.10.1 Огляд

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

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

ПРИМІТКА: Оцінка включає визначення впливу змін на обмеження проєкту (див. 4.2.4).

7.10.2 Визначення фреймворку контролю змін

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

7.10.3 Ідентифікація та оцінка запитів на зміну

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

ПРИМІТКА: Запис запитів на зміну може мати назву “реєстр змін”, “журнал змін” або будь-який інший термін, що використовують в організації.

7.10.4 Планування впровадження запитів на зміну

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

7.10.5 Впровадження та закриття запитів на зміну

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

7.11 Управління якістю

7.11.1 Огляд

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

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

Стейкхолдери проєкту повинні бути проінформовані про ймовірність того, що:
a) проєкт досягне цілей;
b) доробки будуть відповідати вимогам якості та стандартам;
c) набутки та кінцеві результати проєкту дозволять реалізувати очікувані вигоди для організації чи суспільства.

7.11.2 Планування якості

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

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

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

Планування якості повинне включати:
a) визначення та погодження зі спонсором проєкту та іншими стейкхолдерами цілей та відповідних стандартів якості, яких слід досягти;
b) документування метрик якості та критеріїв прийняття доробків проєкту;
c) встановлення інструментів, процедур, методів та ресурсів, необхідних для досягнення узгоджених стандартів;
d) визначення методів, технік та ресурсів для здійснення запланованих систематичних заходів з якості;
e) розробку визначеного підходу до управління якістю, включаючи тип оглядів, відповідальності та учасників, запланованих відповідно до плану проєкту;
f) консолідацію інформації щодо якості в плані управління якістю.

7.11.3 Забезпечення якості

Забезпечення якості повинне сприяти та забезпечувати відповідність з прийнятними вимогами до продуктивності, процесів та стандартів якості, та включає:
a) інформування про цілі та відповідні стандарти, які слід використовувати, та перевірку їх використання;
b) перевірку відповідності з визначеним підходом управління щодо якості;
c) підтвердження, що впроваджені інструменти, процедури, техніки та ресурси застосовуються;
d) відповідність з запланованим підходом для перевірки набутку відповідно до затверджених вимог та специфікацій, де це доречно;
e) проведення аудиту людьми, які не залежать від керівника проєкту та команди; вони можуть представляти іншу частину спонсорської або виконавчої організації, або організацію замовника.

Запити на зміну (див. 7.10) можуть бути спричинені операціями з забезпечення якості.

7.11.4 Контроль якості

Контроль якості повинен використовуватися для:
a) визначення того, чи досягаються цілі проєкту, вимоги до якості, показники та стандарти якості;
b) виявлення причин та шляхів усунення незадовільної роботи.

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

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

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

7.12 Залучення стейкхолдерів

7.12.1 Огляд

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

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

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

7.12.2 Ідентифікація стейкхолдерів

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

До стейкхолдерів належать, включаючи, але не обмежуючись:
a) організації-спонсори та проєктні команди (див. 4.5);
b) замовники;
c) партнери та постачальники;
d) групи з особливими інтересами чи впливом;
e) контролюючі органи;
f) постачальники фінансів;
g) акціонери;
h) відповідні зовнішні треті сторони.

7.12.3 Залучення стейкхолдерів

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

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

7.13 Управління комунікаціями

7.13.1 Огляд

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

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

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

7.13.2 Планування комунікацій

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

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

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

7.13.3 Розповсюдження інформації

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

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

7.13.4 Відстеження впливу комунікацій

Вплив комунікацій слід відстежувати, оцінювати і, коли доречно, реагувати на нього. План комунікацій за необхідності слід корегувати для успішного досягнення кінцевого результату проєкту. Відстеження впливу комунікації слід фокусувати на:
a) посиленні розуміння та співпраці між різними стейкхолдерами;
b) наданні своєчасної, точної та неупередженої інформації;
c) вирішенні обставин комунікацій для зниження ризику.

7.14 Управління організаційними та суспільними змінами

7.14.1 Огляд

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

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

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

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

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

ПРИМІТКА 1: Організаційні зміни включають структуру, управління або діяльність організації, наприклад, запровадження нових способів роботи.
ПРИМІТКА 2: Соціальні зміни включають ті зміни, які впливають на суспільство, такі як інфраструктура (наприклад, дороги, залізниця, аеропорти та водопостачання), нові податкові режими, державні пенсії та пільги, житло, навколишнє середовище, охорона здоров’я та безпека.

7.14.2 Ідентифікація необхідності змін

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

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

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

ПРИМІТКА: Цей план може називатися “цільовою операційною моделлю”, “майбутнім станом” або будь-яким іншим терміном, що використовують в організації.

7.14.3 Впровадження організаційних та соціальних змін

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

7.15 Звітність

7.15.1 Огляд

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

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

ПРИМІТКА: Звітність не є тотожною до комунікації. Звітність фокусується на наданні статусу, аналізу відхилень, та прогнозуванні майбутньої продуктивності проєкту, тоді як комунікація має на меті задоволення інформаційних потреб, щоб забезпечити ефективну взаємодію зі стейкхолдерами, та сприяє успішному досягненню кінцевих результатів проєкту.

7.15.2 Планування звітування

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

7.15.3 Управління звітуванням

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

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

7.15.4 Надання звітів

Звіти повинні надаватися своєчасно, відповідно до визначеного у проєкті управлінського підходу до звітності (див. 6.5.3). Коли це доречно, звіти повинні відповідати будь-яким вимогам конфіденційності або безпеки.

7.16 Управління інформацією та документацією

7.16.1 Огляд

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

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

7.16.2 Визначення, якою інформацією слід керувати

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

7.16.3 Зберігання та отримання інформації та документації

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

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

7.17 Закупівлі

7.17.1 Огляд

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

Закупівлі слід планувати з використанням процесів закупівель в організації , якщо такі є, відповідно до стратегії закупівель проєкту. Управління закупівлями має бути інтегроване з плануванням (див. 7.2).

ПРИМІТКА: Закупівлі вимагають знання відповідних законів та практики, і їх часто проводять спеціалісти, що не входять до проєктної організації, наприклад, спеціаліст із пошуку ресурсів у організації-спонсорі.

7.17.2 Планування закупівель

Слід визначити стратегію закупівель з урахуванням:
a) рішень у проєкті “робити або купувати”;
b) практик постачання;
c) типу юридично обов’язкових договорів;
d) процесу закупівель, який буде використовуватися.

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

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

7.17.3 Оцінка та вибір постачальників

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

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

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

7.17.4 Адміністрування контрактів

Адміністрування контрактів повинне:
a) включати управління зв’язками з постачальниками, моніторинг виконання контрактів, управління змінами та виправленнями контрактів, розгляд претензій та розірвання договорів;
b) забезпечити виконання сторонами договору вимог проєкту відповідно до умов юридичної угоди;
c) включати збір даних про ефективність роботи постачальника та ведення детальних записів (див. 7.15);
d) за потреби виконуватись упродовж усього життєвого циклу проєкту.

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

7.17.5 Закриття контрактів

Договори можуть бути закриті за двох обставин, коли:
a) зобов’язання сторін по контракту були виконані; або
b) договір закривається достроково, відповідно до положень про розірвання договору.

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

При закритті договору пов’язана з ним документація повинна бути заархівована відповідно до фреймворку управління інформацією проєкту (див. 7.16).

7.18 Засвоєні уроки

7.18.1 Огляд

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

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

7.18.2 Ідентифікація уроків

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

7.18.3 Розповсюдження уроків

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

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

ПРИМІТКА: Проєктний офіс часто є власником процесів та методів управління проєктами (див. 4.5.7).

Додаток A до ISO 21502 “Управління проєктами”

(інформаційний)

Процеси управління проєктами, засновані на практиках

Цей додаток містить інформацію про те:
a) як цей документ еволюціонував із ISO 21500:2012, забезпечивши зв’язок між фреймворком, базованим на процесах ISO 21500:2012, та фреймворком, базованим на практиці в цьому документі (див. таблицю A.1);
b) як цей документ може бути використаний як підґрунтя для розробки фреймворку управління проєктами, базованої на процесах, припускаючи індивідуальну відповідність між процесами у ISO 21500:2012 та практиками цього документа (див. таблицю A.2).

У таблиці A.1 наведено процеси та поняття у ISO 21500:2012 та еквівалентні посилання в цьому документі.

Таблиця A.1 – Порівняння між ISO 21500:2012 та цим документом

Процеси та поняття у ISO 21500:2012 Посилання в цьому документі (ISO 21502 "Управління проєктами")
Інтеграція Практики інтегрованого управління проєктами (Розділ 6)
3.5.3.1 Загальні положення 6.2 До-проєктні заходи
6.9 Після-проєктні заходи
3.8 Стейкхолдери та проєктна організація 6.3 Нагляд за проєктом
6.4 Спрямування проєкту
4.3.2 Розробити статут проєкту 6.5.3 Підхід до врядування та управління проєктом
6.5.4 Початкове обґрунтування проєкту
6.5.5 Початкове планування проєкту
4.3.4 Безпосередня проєктна робота
4.3.5 Контроль проєктної роботи
6.7 Управління виконанням робіт
6.6.2 Прогресивне обґрунтування
6.6.3 Управління ефективністю проєкту
6.6.4 Управління початком та завершенням кожної фази проєкту
6.6.5 Управління початком, прогресом та закриттям кожного пакету робіт
4.3.3 Розробити плани проєктів
4.3.5 Контроль проєктної роботи
7.2 Планування
7.2.2 Розробка плану
7.2.3 Моніторинг плану
4.3.6 Контроль змін 7.10 Контроль змін
7.10.2 Визначення фреймворку контролю змін
7.10.3 Ідентифікація та оцінка запитів на зміну
7.10.4 Планування впровадження запитів на зміни
7.10.5 Впровадження та закриття запитів на зміни
4.3.7 Закриття проєкту чи фази проєкту 6.8 Закриття чи припинення проєкту
4.3.8 Збір засвоєних уроків 7.18 Засвоєні уроки
7.18.2 Ідентифікація уроків
7.18.3 Розповсюдження уроків
3.4.3 Реалізація вигод 7.3 Управління вигодами
7.3.2 Ідентифікація та аналіз вигод
7.3.3 Моніторинг вигод
7.3.4 Підтримка вигод
Стейкхолдери 7.12 Залучення стейкхолдерів
4.3.9 Визначити стейкхолдерів 7.12.2 Ідентифікація стейкхолдерів
4.3.10 Управляти стейкхолдерами 7.12.3 Залучати стейкхолдерів
Обсяг 7.4 Управління обсягом
4.3.11 Визначити обсяг 7.4.2 Визначення обсягу
4.3.13 Визначити операції
4.3.12 Створити ієрархічну структуру робіт
4.3.14 Контроль обсягу 7.4.3 Контроль обсягу
7.4.4 Підтвердження постачання обсягу
Ресурси 7.5 Управління ресурсами
4.3.17 Визначити проєктну організацію 7.5.2 Планування проєктної організації
6.5.2 Мобілізація команди проєкту
4.3.15 Створити команду проєкту 7.5.3 Створення команди
4.3.18 Розвивати команду проєкту 7.5.4 Розвиток команди
4.3.20 Управляти проєктною командою 7.5.5 Управління командою
4.3.16 Оцінювати ресурси
4.3.19 Контролювати ресурси
7.5.6 Планування, управління та контроль фізичних та матеріальних ресурсів
Час 7.6 Управління розкладом
4.3.21 Послідовність операцій
4.3.22 Оцінити тривалість операції 7.6.2 Оцінка тривалості операції
4.3.23 Розробити графік 7.6.3 Розробка розкладу
4.3.24 Контролювати графік 7.6.4 Контроль розкладу
Вартість 7.7 Управління вартістю
4.3.25 Оцінити вартість 7.7.2 Оцінка вартості
4.3.26 Розробити бюджет 7.7.3 Розробка бюджету
4.3.27 Контролювати витрати 7.7.4 Контроль вартості
Ризик 7.8 Управління ризиками
4.3.28 Ідентифікувати ризик 7.8.2 Ідентифікація ризику
4.3.29 Оцінити ризики 7.8.3 Оцінювання ризиків
4.3.30 Усунути ризик 7.8.4 Реагування на ризики
4.3.31 Контролювати ризик 7.8.5 Контроль ризиків
7.9 Управління обставинами
7.9.2 Ідентифікація обставин
7.9.3 Вирішення обставин
Якість 7.11 Управління якістю
4.3.32 План по якості 7.11.2 Планування якості
4.3.33 Виконувати забезпечення якості 7.11.3 Забезпечення якості
4.3.34 Виконання контролю якості 7.11.4 Контроль якості
Закупівлі 7.17 Закупівлі
4.3.35 Планувати закупівлі 7.17.2 Планування закупівель
4.3.36 Обирати постачальників 7.17.3 Оцінка та вибір постачальників
4.3.37 Адмініструвати закупівлі 7.17.4 Адміністрування контрактів
7.17.5 Закриття контрактів
Комунікації 7.13 Управління комунікаціями
7.15 Звітність
4.3.38 Планувати комунікації 7.13.2 Планування комунікацій
7.15.2 Планування звітування
4.3.39 Поширювати інформацію 7.13.3 Розповсюдження інформації
7.15.4 Надання звітів
4.3.40 Керувати комунікаціями 7.13.4 Відстеження впливу комунікацій
7.15.3 Управління звітуванням
7.16 Управління інформацією та документацією
7.16.2 Визначення, якою інформацією слід керувати
7.16.3 Зберігання та отримання інформації та документації
7.14 Управління організаційними та суспільними змінами
7.14.2 Ідентифікація необхідності змін
7.14.3 Впровадження організаційних та соціальних змін

У таблиці A.2 показано, як практики цього документа можна співвіднести з інформацією, що міститься у ISO 21500:2012.

Практики в Розділі 6 та Розділі 7 цього документа можуть бути зіставлені з парадигмою групи процесів (ініціювання, планування, впровадження, контроль та закриття) ISO 21500:2012, як показано в таблиці A.2. Заголовки стовпців посилаються на групи процесів ISO 21500:2012, усі інші є посиланнями на цей документ.

Таблиця A.2 – Порівняння практик у пунктах 6 і 7 цього документа з групами процесів ISO 21500:2012

Статті цього документу (ISO 21502 "Управління проєктами") Групи процесів ISO 21500:2012
Ініціація Планування Виконання Контролювання Закриття
6 Практики інтегрованого управління проєктами 6.3 Нагляд за проєктом
6.4 Спрямування проєкту
6.5.2 Мобілізація команди проєкту
6.5.3 Підхід до врядування та управління проєктом
6.5.4 Початкове обґрунтування проєкту
6.5.5 Початкове планування проєкту
6.6.4 Управління початком та завершенням кожної фази проєкту(див. також 6.6.5)
6.6.5 Управління початком, прогресом та закриттям кожного пакету робіт 6.6.2 Прогресивне обґрунтування
6.6.3 Управління ефективністю проєкту
6.7 Управління поставкою
6.8 Закриття чи припинення проєкту
7.2 Планування 7.2.2 Розробка плану 7.2.3 Моніторинг плану
7.3 Управління вигодами 7.3.2 Ідентифікація та аналіз вигод 7.3.3 Моніторинг вигод
7.3.4 Підтримка вигод
7.4 Управління обсягом 7.4.2 Визначення обсягу 7.4.3 Контроль обсягу
7.4.4 Підтвердження постачання обсягу
7.5 Управління ресурсами 7.5.2 Планування проєктної організації 7.5.3 Створення команди
7.5.4 Розвиток команди
7.5.5 Управління командою
7.5.6 Планування, управління та контроль фізичних та матеріальних ресурсів
7.6 Управління розкладом 7.6.2 Оцінка тривалості операції
7.6.3 Розробка розкладу
7.6.4 Контроль розкладу
7.7 Управління вартістю 7.7.2 Оцінка вартості
7.7.3 Розробка бюджету
7.7.4 Контроль вартості
7.8 Управління ризиками 7.8.2 Ідентифікація ризиків
7.8.3 Оцінювання ризиків
7.8.4 Реагування на ризики 7.8.5 Контроль ризиків
7.9 Управління обставинами 7.9.2 Ідентифікація обставин 7.9.3 Вирішення обставин
7.10 Контроль змін 7.10.2 Встановлення фреймворку контролю змін
7.10.4 Планування виконання запитів на зміну
7.10.3 Ідентифікація та оцінка запитів на зміну 7.10.5 Впровадження та закриття запитів на зміну
7.11 Управління якістю 7.11.2 Планування якості 7.11.3 Забезпечення якості 7.11.4 Контролювання якості
7.12 Управління стейкхолдерами 7.12.2 Ідентифікація стейкхолдерів 7.12.3 Залучення стейкхолдерів
7.13 Управління комунікаціями 7.13.2 Планування комунікацій 7.13.3 Розповсюдження інформації 7.13.4 Відстеження впливу комунікацій
7.14 Управління організаційними та соціальними змінами 7.14.2 Ідентифікація необхідності змін 7.14.3 Виконання організаційних та соціальних змін
7.15 Звітування 7.15.2 Планування звітування 7.15.4 Надання звітів 7.15.3 Управління звітуванням
7.16 Управління інформацією та документацією 7.16.2 Визначення, якою інформацією слід керувати 7.16.3 Зберігання та отримання інформації та документації
7.17 Закупівлі 7.17.2 Планування закупівель 7.17.3 Оцінка та вибір постачальників 7.17.4 Адміністрування контрактів 7.17.5 Закриття контрактів
7.18 Засвоєні уроки 7.18.2 Ідентифікація уроків 7.18.3 Розповсюдження уроків

Таблиця A.3 – Таблиця взаємозв’язку практик ДСТУ ISO 21502:2022 (ISO 21502:2020, IDT)

7. Практики управління

6. Практики інтегрованого управління проєктами

6.2. До-проєктні заходи

6.3. Нагляд за проєктом

6.4. Спрямування проєкту

6.5. Ініціація проєкту

6.6. Контроль за проєктом

6.7. Управління поставкою

6.8. Закриття чи припинення проєкту

6.9. Після-проєктні заходи

7.2. Планування

6.5.3. Підхід до врядування та управління проєктом 7.2.3. Моніторинг плану
7.2.2/6.5.5. Розробка плану

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

7.3.2. Ідентифікація та аналіз вигід 7.3.4. Підтримка вигід 7.3.3. Моніторинг вигід 6.5.4. Початкове обґрунтування проєкту 6.6.2. Прогресивне обґрунтування

7.4. Управління обсягом

7.4.4. Підтвердження постачання обсягу 7.4.2. Визначення обсягу 7.4.3. Контроль обсягу

7.5. Управління ресурсами

7.5.2. Планування проєктної організації 7.5.5. Управління командою 7.5.4. Розвиток команди
7.5.3/6.5.2. Створення команди 7.5.6. Планування, управління та контроль фізичних та матеріальних ресурсів

7.6. Управління розкладом

7.6.2. Оцінка тривалості виконання робіт 7.6.4. Контроль розкладу
7.6.3. Розробка розкладу

7.7. Управління вартістю

7.7.2. Оцінка вартості 7.7.4. Контроль вартості
7.7.3. Розробка бюджету

7.8. Управління ризиками

7.8.2. Ідентифікація ризиків 7.8.3. Оцінювання ризиків 7.8.5. Контроль ризиків 7.8.4. Реагування на ризик

7.9. Управління обставинами

7.9.2. Ідентифікація обставин
7.9.3. Вирішення обставин

7.10. Контроль змін

7.10.2. Визначення фреймворку контролю змін 7.10.3. Ідентифікація та оцінка запитів на зміну 7.10.5. Впровадження та закриття запитів на зміну
7.10.4. Планування впровадження запитів на зміну

7.11. Управління якістю

7.11.4. Контроль якості 7.11.2. Планування якості 7.11.3. Забезпечення якості

7.12. Залучення стейкхолдерів

7.12.2. Ідентифікація стейкхолдерів 7.12.3. Залучення стейкхолдерів

7.13. Управління комунікаціями

7.13.2. Планування комунікацій 7.13.4. Відстеження впливу комунікацій 7.13.3. Розповсюдження інформації

7.14. Управління організаційними та суспільними змінами

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

7.15. Звітність

7.15.2. Планування звітування 6.6.3. Управління ефективністю проєкту 7.15.4. Надання звітів
7.15.3. Управління звітуванням

7.16. Управління інформацією та документацією

7.16.2. Визначення, якою інформацією слід керувати 7.16.3. Зберігання та отримання інформації та документації

7.17. Закупівлі

7.17.2. Планування закупівель 7.17.3. Оцінка та вибір постачальників 7.17.5. Закриття контрактів
7.17.4. Адміністрування контрактів

7.18. Засвоєні уроки

7.18.2. Ідентифікація уроків 7.18.3. Розповсюдження уроків

Бібліографія ISO 21502 “Управління проєктами”

[1] ДСТУ ISO 9000:2015 (ISO 9000:2015, IDT), Системи управління якістю. Основні положення та словник.
[2] ДСТУ ISO 21500:2022 (ISO 21500:2021, IDT), Управління проєктами, програмами та портфелями. Контекст та концепції.
[3] ДСТУ ISO 21503:2022 (ISO 21503:2022, IDT), Управління проєктами, програмами та портфелями. Настанови щодо управління програмами.
[4] ДСТУ ISO 21504:2022 (ISO 21504:2022, IDT), Управління проєктами, програмами та портфелями. Настанови щодо управління портфелями.
[5] ДСТУ ISO 21505:2022 (ISO 21505:2017, IDT), Управління проєктами, програмами та портфелями. Настанови щодо врядування.
[6] ДСТУ ISO/TR 21506:2022 (ISO 21505:2017, MOD), Управління проєктами, програмами та портфелями. Словник.
[7] ДСТУ ISO 21508:2022 (ISO 21508:2018, IDT), Управління здобутою цінністю в управлінні проєктами та програмами.
[8] ДСТУ ISO 21511:2022 (ISO 21511:2018, IDT), Ієрархічна структура робіт для управління проєктами та програмами.
[9] ДСТУ ISO 55000:2019 (ISO 55000:2014, IDT), Управління активами. Загальний огляд, принципи та термінологія.