Сфера виконання "Підхід до розробки та життєвий цикл" (Development Approach and Life Cycle Performance Domaine)

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

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

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

Сфера виконання "Підхід до розробки та життєвий цикл" це одна зі сфер виконання в PMBOK 7

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

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

• Результат (Deliverable). Будь-який унікальний продукт, результат або здатність надати послугу, які необхідно створити для завершення процесу, фази або проекту, що піддається перевірці.
• Підхід до розробки (Development Approach). Метод, який використовується для створення та розвитку продукту, послуги або результату протягом життєвого циклу проекту, наприклад, прогностичний, ітеративний, інкрементний, адаптивний або гібридний метод.
• Каденція (Cadence). Ритм діяльності, що здійснюється впродовж проєкту.
• Фаза проекту (Project Phase). Сукупність логічно пов'язаних між собою проектних заходів, що завершуються досягненням одного або декількох результатів.
• Життєвий цикл проекту (Project Life Cycle). Послідовність фаз, через які проходить проект від його початку до завершення.

2.3.1 Взаємозв'язок між розробкою, каденцією та життєвим циклом (2.3.1 Development, Cadence, and Life Cycle Relationship)

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

2.3.2 Каденція постачання (2.3.2 Delivery Cadence)

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

• Єдина поставка (Single delivery). Проєкти, які мають єдину поставку, виконують її наприкінці проєкту. Наприклад, проект реінжинірингу процесів може не мати жодного результату до кінця проекту, коли новий процес буде впроваджено.
• Кілька здач (Multiple deliveries). Деякі проекти мають кілька девелоперських етапів. Проект може мати кілька компонентів, які виконуються в різний час протягом усього проекту. Проект з розробки нового лікарського засобу може мати кілька етапів, наприклад, доклінічні дослідження, результати фази 1, результати фази 2, результати фази 3, реєстрація, а потім запуск. У цьому прикладі етапи є послідовними. У деяких проектах є етапи, які розробляються окремо, а не послідовно, як, наприклад, у проекті з оновлення системи безпеки будівлі. Ресурси можуть включати фізичні бар'єри для входу, нові бейджі, нові кодові накладки для ключів тощо. Кожна з них є окремою поставкою, але вони не обов'язково повинні надходити в певному порядку. Всі поставки завершуються до того, як проект вважається завершеним.
• Періодичні поставки (Periodic deliveries). Періодичні поставки схожі на багаторазові поставки, але вони здійснюються за фіксованим графіком, наприклад, щомісяця або раз на два місяці. Новий програмний додаток може мати внутрішні поставки кожні два тижні, а потім періодично випускатися на ринок.

Інший варіант доставки називається безперервною доставкою. Безперервна доставка - це практика негайного надання клієнтам нових функцій, часто за допомогою невеликих партій робіт і технологій автоматизації. Безперервну доставку можна використовувати для цифрових продуктів. З точки зору управління продуктом, акцент робиться на наданні переваг і цінності протягом усього життєвого циклу продукту. Як і в проєкті, є аспекти, орієнтовані на розвиток. Однак, як і у випадку з програмою, може бути багато циклів розробки, а також заходів з підтримки. Цей тип діяльності краще працює з проектними командами, які є стабільними і залишаються недоторканими. Оскільки проектні команди зосереджені на одному продукті, вони можуть застосовувати знання про продукт, зацікавлені сторони та ринок. Це дозволяє команді реагувати на ринкові тенденції і залишатися зосередженою на створенні цінності. Ця практика включена в такі підходи, як DevOps, #noprojects і Continuous Digital, наприклад.

Безперервна доставка бере свої витоки з філософії Тойота (пізніше додам посилання)

Підходи до розробки (2.3.3 Development Approaches)

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

Три найпоширеніші підходи - це предиктивний, гібридний та адаптивний. Як показано на Рисунку 2-7, ці підходи часто розглядаються як спектр, від прогностичного підходу на одному кінці спектру до адаптивного на іншому.

Прогностичний підхід (Predictive approach).

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

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

Гібридний підхід (Hybrid approach).

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

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

Відмінності та взаємодія між ітеративним та інкрементальним розвитком показані на Рисунку 2-8.

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

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

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

Адаптивний підхід (Adaptive approach).

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

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

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

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

Міркування щодо вибору підходу до розвитку (2.3.4 Considerations For Selecting A Development Approach)

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

Продукт, послуга або результат (2.3.4.1 Product, Service, or Result)

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

• Ступінь інноваційності (Degree of innovation). Результати, обсяг і вимоги яких добре зрозумілі, з якими команда проекту працювала раніше і які дозволяють планувати заздалегідь, добре підходять для прогностичного підходу. Результати, які мають високий ступінь інноваційності або в яких проектна команда не має досвіду, краще підходять для більш адаптивного підходу.
• Визначеність вимог (Requirements certainty). Коли вимоги добре відомі і їх легко визначити, добре підходить предиктивний підхід. Якщо вимоги є невизначеними, мінливими або складними, і очікується, що вони будуть змінюватися протягом проекту, краще використовувати більш адаптивний підхід.
• Стабільність обсягу робіт (Scope stability). Якщо обсяг результату є стабільним і навряд чи зміниться, корисним є прогностичний підхід. Якщо очікується, що обсяг буде змінюватися часто, може бути корисним підхід, який ближчий до адаптивного.
• Легкість внесення змін (Ease of change). Пов'язано з визначеністю вимог та стабільністю обсягу робіт, якщо природа результату ускладнює управління та внесення змін, то найкращим є прогностичний підхід. Для результатів, які можуть легко адаптуватися до змін, можна використовувати підхід, який є більш адаптивним.
• Варіанти постачання (Delivery options). Як описано в Розділі 2.3.2 про каденцію надання послуг, на підхід до розробки впливає характер результату і те, чи може він бути наданий у вигляді компонентів. Продукти, послуги або результати, які можуть бути розроблені та/або надані частинами, відповідають інкрементальному, ітеративному або адаптивному підходам. Деякі великі проекти можуть бути сплановані з використанням прогностичного підходу, але можуть бути й такі, що можуть розроблятися та реалізовуватися поетапно.
• Ризик (Risk). Продукти, які за своєю природою мають високий ризик, потребують аналізу перед вибором підходу до розробки. Деякі продукти з високим рівнем ризику можуть вимагати значного попереднього планування та суворих процесів для зменшення загроз. Інші продукти можуть зменшити ризик, якщо будувати їх за модульним принципом та адаптувати дизайн і розробку на основі навчання, щоб скористатися новими можливостями або зменшити вразливість до загроз.
• Вимоги безпеки (Safety requirements). Продукти, які мають суворі вимоги до безпеки, часто використовують прогностичний підхід, оскільки існує потреба у значному попередньому плануванні, щоб забезпечити визначення, планування, створення, інтеграцію та тестування всіх вимог безпеки.
• Нормативно-правові акти (Regulations). У середовищах зі значним регуляторним наглядом може знадобитися використання предиктивного підходу через необхідні процеси, документацію та демонстраційні потреби.

Проект (2.3.4.2 Project)

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

• Зацікавлені сторони (Stakeholders). Проекти, які використовують адаптивні методи, вимагають значного залучення зацікавлених сторін протягом усього процесу. Певні зацікавлені сторони, такі як власник продукту, відіграють важливу роль у встановленні та визначенні пріоритетів роботи.
• Обмеження розкладу (Schedule constraints). Якщо є потреба доставити щось раніше, навіть якщо це не готовий продукт, корисним є ітеративний або адаптивний підхід.
• Доступність фінансування (Funding availability). Проекти, які працюють в умовах невизначеності з фінансуванням, можуть отримати вигоду від адаптивного або ітеративного підходу. Мінімально життєздатний продукт може бути випущений з меншими інвестиціями, ніж складний продукт. Це дозволяє провести ринкове тестування або захоплення ринку з мінімальними інвестиціями. Подальші інвестиції можуть бути зроблені на основі реакції ринку на продукт або послугу.

Організація (2.3.4.3 Organization)

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

• Організаційна структура (Organizational structure). Організаційна структура, яка має багато рівнів, жорстку структуру звітності та значну бюрократію, часто використовує прогностичний підхід. Проекти, які використовують адаптивні методи, як правило, мають пласку структуру і можуть працювати з проектними командами, що самоорганізуються.
• Культура (Culture). Прогностичний підхід краще вписується в організацію з культурою управління та керівництва, де робота планується, а прогрес вимірюється порівняно з базовими показниками. Адаптивні підходи краще вписуються в організацію, яка робить акцент на самоуправлінні проектною командою.
• Організаційна спроможність (Organizational capability). Перехід від прогнозних підходів до адаптивних, а потім до використання гнучких методів - це більше, ніж просто заява про те, що організація відтепер буде гнучкою. Це передбачає зміну мислення, починаючи з виконавчого рівня і закінчуючи всією організацією. Організаційна політика, способи роботи, структура звітності та ставлення - все це повинно бути узгоджено для успішного застосування адаптивних методів.
• Розмір і місцезнаходження проектної команди (Project team size and location). Адаптивні підходи, особливо гнучкі методи, часто краще працюють з проектними командами розміром 7 ± 2. Адаптивні підходи також надають перевагу проектним командам, які розташовані в одному фізичному просторі. Великі проектні команди і проектні команди, які є майже віртуальними, можуть працювати краще, використовуючи підхід, який ближчий до прогностичної частини спектру. Однак існують підходи, які прагнуть розширити масштаби адаптивних підходів для роботи з великими та розподіленими проектними командами.

Визначення життєвого циклу та фаз (2.3.5 Life Cycle And Phase Definitions)

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

• Здійсненність (Feasibility). На цьому етапі визначається, чи є бізнес-кейс обґрунтованим і чи здатна організація досягти запланованого результату.
• Дизайн (Design). Планування та аналіз призводять до розробки проекту, який буде реалізовано в подальшому.
• Побудова (Build). Здійснюється створення результату з комплексними заходами із забезпечення якості.
• Тестування (Test). Остаточна перевірка якості та інспекція результатів здійснюється перед переходом, запуском в експлуатацію або прийняттям замовником.
• Розгортання (Deploy). Результати проекту вводяться в експлуатацію і завершуються перехідні заходи, необхідні для підтримки, реалізації переваг і управління організаційними змінами.
• Закриття (Close). Проект закривається, знання та артефакти проекту архівуються, члени проектної команди звільняються, а контракти закриваються.

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

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

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

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

Цей підхід може бути модифікований для використання в ситуаціях безперервного постачання, як описано в Розділі 2.3.2 "Каденція постачання".

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

Узгодження періодичності надання послуг, підходу до розвитку та життєвого циклу (2.3.6 Aligning Of Delivery Cadence, Development Approach, And Life Cycle)

Приклади громадських центрів, описані в розділі 2.3.3, будуть розглянуті ще раз, щоб продемонструвати, як узгоджуються між собою періодичність надання послуг, підхід до розвитку та життєвий цикл. У цьому прикладі є чотири продукти та послуги: будівля, навчання для громадських патрулів (the community action patrol - CAP), послуги для людей похилого віку та веб-сайт. У Таблиці 2-4 описано періодичність надання послуг та підхід до розробки.

На основі цієї інформації можна визначити потенційний життєвий цикл:

• Запуск (Start Up). Критеріями входу на цю фазу є схвалення бізнес-плану та затвердження статуту проекту. На цій фазі розробляється дорожня карта високого рівня, визначаються початкові потреби у фінансуванні, команда проекту та потреби у ресурсах, створюється графік виконання етапів та планується стратегія закупівель. Ці результати повинні бути завершені до виходу з початкової фази. Критерії виходу будуть переглянуті під час контрольного огляду початкової фази.
• План (Plan). На цьому етапі інформація високого рівня щодо будівлі розкладається на детальні плани. Завершується розробка детального проектного документу для тренінгу CAP. Завершується аналіз пропозиції послуг вищого рівня, а також аналіз прогалин. Створено початковий фреймворк для веб-сайту. Ці результати мають бути завершені до виходу з фази планування. Критерії завершення будуть переглянуті під час підсумкового огляду фази планування.
• Розробка (Development). Цей етап перетинається з етапами тестування та розгортання, оскільки результати мають різні терміни реалізації та різні підходи. Веб-сайт буде розміщено на початку етапу, щоб інформувати громадськість про прогрес у створенні громадського центру. Надання деяких послуг та тренінги для учасників CAP можуть розпочатися ще до відкриття громадського центру. Кожен результат може мати окремий огляд перед тим, як перейти до фази тестування.
• Тестування (Test). Ця фаза накладається на фази розробки та розгортання. Тип тесту буде залежати від кінцевого результату. Цей етап включає перевірку будівлі, бета-версію курсів ВПД, невеликі випробування для старших служб та роботу в тестовому середовищі для кожної версії веб-сайту. Перед тим, як перейти до фази розгортання, кожен результат пройде відповідне тестування.
• Розгортання (Deploy). Ця фаза накладається на фази розробки і тестування. Перше розгортання веб-сайту може бути дещо раннім у проекті. Діяльність на цій фазі буде повторюватися в міру того, як ставатимуть доступними нові результати. Остаточним розгортанням проекту стане відкриття громадського центру. Після відкриття громадського центру постійне оновлення веб-сайту та послуг для людей похилого віку стане частиною роботи.
• Закриття (Close). Цей етап відбувається періодично по мірі виконання поставлених завдань. Після розгортання початкового веб-сайту персонал проекту (включно з підрядниками) буде звільнений, а ретроспектива або уроки, отримані за кожним результатом, будуть завершені. Після завершення всього проекту буде проведено аналіз інформації, отриманої на різних етапах, та загальну оцінку ефективності проекту порівняно з базовими показниками. Перед остаточним закриттям буде переглянуто статут проекту та бізнес-план, щоб визначити, чи досягнуто запланованих вигод і цінності від отриманих результатів.

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

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

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

Взаємодія з іншими сферами діяльності (2.3.7 Interactions With Other Performance Domain)

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

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

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

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

Вимірювання результатів (2.3.8 Measuring Outcom)

У таблиці 2-5 зліва наведено результати, а праворуч - способи їх перевірки.