Основи проектного менеджменту 1 страница

Вступ

■

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

(РМВОК), є унікальним документом, в якому описані сукупні знання з

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

право, медицина та облік, ця база знань призначена для практиків і

наукових працівників, які застосовують і розвивають проектний

менеджмент. Повний РМВОК включає опис знань, що грунтуються на

перевірених традиційних широко застосовуваних практичних

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

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

використання.

У цьому розділі вміщено визначення та пояснення деяких ключових

термінів і загальний огляд решти термінології. Розділ має такі
підрозділи:

1.1 Мета даного документа

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

1.3 Що таке проектний менеджмент?

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

1.5 Комплексні заходи

Мета даного документа

Основна мета даного документа - дати визначення і описати

загальноприйняту підмножину РМВОК. Термін «загальноприйнята»

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

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

Пропонована книга містить основні відомості з проектного менеджменту і розрахована на широке коло читачів:

• менеджерів проектів та інших членів команд проектів;

• керівників менеджерів проектів;

• споживачів результатів проекту та інших зацікавлених осіб
проекту;

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

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

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

■

• ведучих навчальних програм з проектного менеджменту;

• а також усіх, хто цікавиться цією професією.

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

Даний документ використовується Інститутом проектного менеджменту (РМІ) як основа таких професійних програм розвитку:

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

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

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

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

• вони виконуються людьми;

• виконуються з обмеженими ресурсами;

• плануються, виконуються і контролюються.

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

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

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

• зміна структури, кадрів або стилю роботи організації;

• проектування нового транспортного засобу;

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

• зведення будівлі чи споруди;

• запуск політичної кампанії;

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

1.2.1 Поняття «тимчасовий»

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

Крім того, поняття «тимчасовий» не обов'язково застосовано до продукту чи послуги, що створюється в проекті. Більшість проектів виконуються до отримання певного довгочасного результату. Наприклад, проект по зведенню пам'ятника національному герою

матиме результат на кілька віків.

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

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

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

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

1.2.2 Унікальність продукту чи послуги

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

• Проект з розробки нового комерційного авіалайнера може
вимагати використання різних прототипів.

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

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

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

Поетапно означає «виконувати покроково, впевнено просуваючись на деякий крок», а розроблятися означає «ретельну і детальну роботу, глибоко продуману» [1]. Ці унікальні властивості мають бути детально визначені в проекті раніше, і вони будуть задані більш явно і детально чим краще й адекватніше розуміння продукту проекту буде у команди виконавців проекту.

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

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

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

так і механічні властивості елементів процесу і допоміжні характеристики. Усе це сприятиме створенню проектних креслень, що розробляються з метою створення виробничих креслень (будівельні креслення з ізомерій). У процесі будівництва будуть внесені необхідні уточнення і все необхідне для затвердження. Ця пізніша розробка властивостей зберігається в заключних будівельних кресленнях. При тестуванні й закритті часто продовжують подальшу розробку властивостей, і тоді її виконують у формі заключних оперативних змін. Приклад 2.Продукт проекту біофармацевтичного дослідження спочатку був визначений як «випробування ліків XYZ», оскільки кількість випробувань і розмір партії були ще невідомі. По мірі здійснення проекту продукт може бути описаний чіткіше, як, наприклад, «три випробування на фазі І, чотири випробування на фазі П і два випробування на фазі III». Наступний етап розробки може бути сконцентрований виключно на протоколі випробувань на фазі І -скільки пацієнтів отримували дози ліків, в яких кількостях і як часто. На заключних етапах проекту мають бути чітко визначені випробування на фазі III, і базуватися вони повинні на інформації, зібраній і проаналізованій під час випробувань на фазах І і II.

1.3 Що таке проектний менеджмент?

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

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

• різних потреб і бажань зацікавлених осіб;

• ідентифікованих і не ідентифікованих вимог (потреб).

Термін «проектний менеджмент» іноді означає те, що використовується для описання організаційного підходу до управління поточними діями. Цей підхід, або точніше проектне управління, розглядає багато аспектів поточних дій для застосування процедур проектного менеджменту. Хоч розуміння проектного менеджменту безумовно важливе для організації, що розробляє проект, детальне обговорення цього підходу виходить за рамки даного документа. Теоретичні відомості з проектного менеджменту можуть бути упорядковані багатьма способами. Даний посібник складається з 12 розділів, об'єднаних у дві частини.

Основи проектного менеджменту

Частина І- Предметна галузь проектного менеджменту-

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

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

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

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

Розуміння цих взаємодій є необхідною умовою для осягнення матеріалу розділів 4-12.

1.3.2 Галузі застосування знань з проектного менеджменту

Частина II - Галузі застосування знань з проектного менеджменту -поданий теоретичний і практичний матеріал в термінах складових його процесів. Ці процеси були впорядковані по дев'яти галузях застосування знань, як це показано на малюнку1—1.

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

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

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

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

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

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

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

Розділ 11 - Управління ризиком у проекті- описуються процеси, зв'язані з ідентифікацією, аналізом і розвиненням реакції на ризик у проекті. Це ідентифікація ризику, кількісна його оцінка, розвинення реакції на ризик і контроль її.

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

Малюнок 1—1.Огляд галузей застосування знань і процесів управління проектами

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

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

Загальне управління включає планування, організацію, роботу з персоналом, виконання і поточний контроль за виробничими діями, а також допоміжні дисципліни: комп'ютерне програмування, право, статистику і теорію ймовірностей, логістику і роботу з персоналом. РМВОК пересікається зі знаннями із загального управління в багатьох галузях - організаційна поведінка, фінансове прогнозування, і методи планування становлять лише невелику частину суміжних питань. Розділ 2.4 містить детальніший опис загального управління.

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

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

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

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

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

1.5 Комплексні заходи

Певні типи заходів тісно зв'язані з проектами. Такі комплексні заходи описані далі.

Програми.Програма - це група проектів, управління якими для отримання прибутків здійснюється в комплексі, оскільки за індивідуального управління ці прибутки будуть недоступні [2]. Багато які програми також включають елементи поточних дій. Наприклад:

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

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

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

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

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

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

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

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

• одна фаза проекту (фази проекту описані в розділі 2.1);

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

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

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

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

Середовище проектного

Менеджменту

Життєдіяльність проектів і управління ними відбуваються у

ширшому середовищі, ніж те, що має сам проект. Команда

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

звичайно, щоденне управління роботами проекту необхідне для

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

аспекти середовища проектного менеджменту, що на попередніх

сторінках не розглядалися. Тут розкрито такі теми:

2.1 Фази проекту та його життєвий цикл

2.2 Зацікавлені сторони проекту

2.3 Вплив виконавчої організації

2.4 Загальні управлінські навички

2.5 Соціоекономічний вплив

2.1 Фази проекту та його життєвий цикл

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

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

поділяють його на кілька фаз для забезпечення кращого контролю за

управлінням і відповідних зв'язків з поточними роботами організації. У

сукупності фази проекту мають назву «життєвий цикл проекту».

2.1.1 Властивості фаз проекту

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

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

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

2.1.2 Властивості життєвого циклу проекту

Життєвий цикл проекту слугує для визначення початку і закінчення

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

Життєвий цикл проекту визначатиме, які перехідні дії наприкінці

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

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

Життєві цикли проекту звичайно визначають:

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

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

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

Більшість описів життєвих циклів проекту використовують безліч загальних властивостей:

• матеріальні витрати та кількість залученого до проекту
персоналу спочатку низькі, згодом зростають і швидко йдуть
угору, коли проект наближається до завершення. Ця ситуація
зображена на малюнку 2—1;

• імовірність успішного завершення проекту є найменшою, а
ризик і невизначеність відповідно найвищими на початку
проекту. Імовірність успішного завершення проекту
поступово зростає по мірі виконання проекту;

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

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

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

Малюнок 2-2.Приклад життєвого циклу закупівель Міністерства оборони стосовно DOD

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

2.1.3 Приклади життєвих циклів проектів

Описані далі життєві цикли проектів були вибрані для ілюстрації

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

Проекти закупівель у Міністерстві оборони.Директива 5000.2 Міністерства оборони США від 26 лютого 1993 р. описує серію віх і фаз із закупівель, як це показано на малюнку 2—2:

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

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

• Демонстрація і перевірка - закінчується затвердженням
розробки.

• Розробка інженерних і виробничих рішень - закінчується
затвердженням виробничих рішень.

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

Малюнок 2—3.Приклад життєвого циклу будівельного проекту (за Моррисом)

Будівництво.Моррис [1] описує життєвий цикл будівельного проекту, як це ілюструє малюнок 2—3:

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

• Планування та проектування - базовий проект, вартість і

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

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

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

Фармацевтична галузь.Мерфі [2] описує життєвий цикл проекту з розробки нового фармацевтичного продукту в США, як це показано на малюнку 2—4:

• Відкриття і початкові дослідження - включає початкові та
прикладні дослідження з визначення кандидатів на доклінічне
тестування.

• Доклінічна розробка - включає лабораторне тестування та
випробування на тваринах для визначення безпеки й .
ефективності, а також підготовку і початок програми
Дослідження Нових Ліків (IND).

• Реєстрація розробок - включає тести по клінічних фазах І, II і
III, а також підготовку і запуск програми Застосування Нових
Ліків (NDA).

Роботи з просування - включає додаткові роботи з підтримки перевірки NDA з боку Департаменту харчових і лікарських виробів.

Малюнок 2—4.Характерний приклад життєвого циклу для фармацевтичного проекту (за Мерфі)

Розробка програмного забезпечення.Мюнк в [3] описує спіральну модель з розробки програмного забезпечення з чотирма циклами і чотирма квадратами, як це показано на малюнку 2—5: