CC BY
64
Посилання на статтю_
Войтенко О.С. Оцшка та BM6ip ефективних методологш управлiння проектами органiзацiйного розвитку/О.С. Войтенко // Управлшня проектами та розвиток виробництва: Зб.наук.пр. - Луганськ: вид-во СНУ ím. В.Даля, 2006 - №4(20).- С. 2835.
УДК 65.012
О.С. Войтенко
ОЦ1НКА ТА ВИБ1Р ЕФЕКТИВНИХ МЕТОДОЛОГ1Й УПРАВЛ1ННЯ ПРОЕКТАМИ ОРГАН1ЗАЦ1ЙНОГО РОЗВИТКУ
Досл1джено основн1 методологи управлшня проектами, що використовуються орган1зац1ями в процес1 свое!' д1яльност1 на сучасному етапк Запропоновано методику вибору методологш управл1ння проектами орган1зац1ями на основ! експертних оц1нок щодо вид1лених базових характеристик. Табл. 2, дж. 19.
Ключов1 слова: методолог1я управл1ння проектами, проект, накопичення кращого досвщу.
О.С. Войтенко
ОЦЕНКА И ВЫБОР ЭФФЕКТИВНЫХ МЕТОДОЛОГИЙ УПРАВЛЕНИЯ ПРОЕКТАМИ ОРГАНИЗАЦИОННОГО РАЗВИТИЯ
Исследованы основные методологии управления проектами, которые используются организациями в процессе своей деятельности на сегодняшний день. Предложена методика выбора методологий управления проектами на основе экспертных оценок по выделенным базовым характеристикам. Табл. 2, ист. 19.
O.S. Voytenko
EVALUATION AND SELECTION OF EFFECTIVE PROJECT MANAGEMENT METHODOLOGIES OF ORGANIZATIONAL GROWTH
Main project management methodologies which used by organization in process of their functioning on modern stage was scrutinized. The method for selection of project management methodologies by organizations on the basis of expert evaluations concerning determined basic characteristics was proposed.
Вступ. В наш час, проекти вимагають набагато бтьше штеграци й застосування шновацшних технологш, це неодмЫно тягне за собою використання бтьш креативних шляхiв проектування, розробки, тестування, i розгортання виробiв i послуг. Менеджер бтьше не може створити графк виконання проекту на основi одного або двох шаблошв. Один iз способiв досягти бтьш ефективного результату полягае у використанш методологш. Вже пройшли т часи, коли для планування проекту можна застосувати ттьки пщхщ на основi життевих ци^в проек^в, тепер проекти вимагають серйозноТ координаци й контролю.
"Управлшня проектами та розвиток виробництва", 2006, № 4(20)
1
Постановка проблеми. На сьогодшшнш день недостатньо розглянуто питання щодо аналiзу юнуючих методологiй управлiння проектами для вибору та використання Тх органiзацiями в процесi своеТ дiяльностi. Наприклад, в теори управлiння проектами щодо впровадження та розробки шформацшних технологiй i програмного забезпечення вiдомо приблизно 15 методологiй та стандартiв. Саме тому що ця дисциплша управлiння проектами е одшею з найскладнiших в управлшш оргашзаци тому проектнi менеджери шукають або намагаються розробити власш, гнучкi, швидкi, легкi в управлшш та дешевi методологи. При виборi методологiТ важливо знати, в якш галузi застосовуеться дана методологiя, описуе вона концептуальний пщхщ або е прикладною, тобто докладно описаш не ттьки процеси управлiння, але й передбачеш шаблони документiв, сценари щодо визначених ситуацш, використання iнструментальних засобiв, управлiння ризиками, документообiгом, якiстю тощо.
Анал'з останнiх досл'джень та публ'шацш. Проаналiзувавши лггературу та науковi публкаци з управлiння проектами на сучасному етат, можна сказати, що докладно описаш бази знань з управлшня проектами (PMBoK, P2M, APMBoK i т.д.), стандарти з формування технолопчноТ зрiлостi компанiй (OPM3, PMMM, CMM i т.д.), методологiТ створення шформацшних систем (ISO12207, PJM, MSF, RUP, XP i т.д.). Але потрiбно вiдзначити, що методика вибору методологш управлiння проектами не розроблена, базовi характеристики даних методологiй в лiтературi зустрiчаються рiдко. Наприклад, в [2] розглядаеться невеликий набiр методологiй з точки зору впровадження в дiяльнiсть оргашзаци та не визначаються основш показники цих методологiй. В шших джерелах [3-5] аналiзуються методи взаемоди проектiв та Тх зовнiшнього та внутршнього середовища: зацiкавлених сторiн, визначення усшху тощо.
Цллю дано)' статт'1 е узагальнення останшх дослiджень та створення методiв оцiнки та вибору ефективних методологш управлшня проектами оргашзацшного розвитку на основi системного аналiзу базових характеристик методологiй. Важливим е не ттьки формулювання конкретних базових характеристик методологш, але й визначення термшу "методолопя", тобто що вона повинна описувати, як елементи повинна вмщувати, яку роль вона повинна в^гравати в стратеги дiяльностi оргашзаци. В цш статтi дiстали подальший розвиток дослiдження щодо ролi використання методологш в управлшш проектами.
Основш результати досл'дження. Методологю можна визначити як систему моделей, методiв, керiвних принцишв або принцитв, якi можуть бути застосованi до певноТ ситуаци (проекту). У проектному середовищi ц керiвнi принципи можуть бути перелком дiй, який повинен бути виконаний. Методолопя може бути певним пщходом, шаблонами, формами, i навiть контрольними списками щодо виконання, ям використовуються на протязi всього життевого шляху проекту.
Отже методологiя це:
- процес, що документуе ряд кромв i процедур, щодо успiшного завершення проекту;
- певний процес, щоб досягти завершення;
- ряд кромв, за допомогою яких проект просуваеться дал^
- набiр методiв, процедур i стандартiв, якi визначають розробку i принципи управлiння щодо виконання поставок, послуг або ршень;
- штегрований набiр завдань, методiв, шструменлв, ролей, обов'язкiв i вiх, що використовуються в проектк
Формально методолопя управлшня проектами повинна описувати роботу вах члешв команди протягом всього життевого шляху проекту. Вс члени
2
"Управлшня проектами та розвиток виробництва", 2006, № 4(20)
шманди пoвиннi знати i викopиcтoвyвати oбpанy мeтoдoлoгiю. Багатo пpoeктниx мeтoдoлoгiй oпиcyють yпpавлiння oдним пpoeктoм, не oцiнюючи, щo багатo iншиx пpoeктiв y кoмпанiï викopиcтoвyють тi ж cамi pecypcи. Meтoдoлoгiя yпpавлiння пpoeктoм пoвинна забeзпeчyвати кoмплeкcнe бачення мeнeджepiв пpoeктiв пpo cтpyктypy yпpавлiння пpoeктами в opганiзацiï.
Треба poзyмiти, щo багато мeтoдoлoгiй yпpавлiння пpoeктами:
- мають ви^кий piвeнь абcтpакцiï;
- мютять нeдocтатню iнфopмацiю щoдo пiдтpимки циx мeтoдoлoгiй;
- не фyнкцioнальнi абo не звepтаютьcя дo кpитичниx пpoцeciв yпpавлiння;
- iгнopyють cтандаpти пpoмиcлoвocтi й кращий дocвiд;
- мають „привабливий вигляд" але не мають peальнoгo впpoваджeння, iнтeгpацiï в бiзнec;
- викopиcтoвyють нecтандаpтнi пpoeктнi пiдxoди й тepмiнoлoгiю;
- передбачають занадто вeликy тpивалicть пpoeктiв через ви^ку бюpoкpатiю та адмiнicтpyвання.
Жoдна мeтoдoлoгiя yпpавлiння пpoeктами не мoжe забезпечити у^шне викoнання пpoeктy в будь-якш галyзi заcтocyвання. Багатo мeтoдoлoгiй дoпoмагають запoбiгти пpoблeмам, багатo адаптoванi дo cпeцифiчниx пpoeктiв, але вce звoдитьcя дo заcтocyвання пeвниx пpинципiв управлшня пpoeктами. Кoжна мeтoдoлoгiя yпpавлiння пpoeктами мае наcтyпнi елементи:
- мютить фази життeвoгo шляxy;
- вимipюe викoнання пpoeктy (oпиcye мoнiтopинг вишнання);
- oпиcye пpoтиpизикoвi poбoти та управлшня змшами;
- oпиcye призначення pecypciв на piзнi фази життeвoгo шляxy пpoeктy.
Meтoдoлoгiï yпpавлiння пpoeктами викopиcтoвyютьcя кoмпанiями тiльки тoдi,
шли задачi впpoваджeння е вiдпoвiдними й легш заcтocoвними. Пpoeктнi плани pí^o oнoвлюютьcя. Багатo пpoeктiв зocepeджyють увагу тiльки на задoвoлeннi зацiкавлeниx crop^ пpoтягoм пoчаткoвиx фаз пpoeктy замють тoгo, щoб вiдпoвiдати фактичнoмy плану на вcьoмy життeвoмy шляxy пpoeктy.
Якщo poзглядати дiяльнicть бyдь-якoï opганiзацiï, тo мoжна пoбачити, щo мeтoдoлoгiя yпpавлiння пpoeктами не е вiдoкpeмлeнoю cиcтeмoю. Пpикладoм взаeмoзв'язкy дeякиx мeтoдoлoгiй мoжyть cлyжити:
- мeтoдoлoгiя пpoдаж й маркетингу;
- мeтoдoлoгiя набopy пepcoналy;
- мeтoдoлoгiя yпpавлiння пpoeктами;
- мeтoдoлoгiя poзpoбки (маeтьcя на уваз^ щo пpoгpамнe забезпечення абo виpiб cтвopeнi на ocнoвi пeвниx cтандаpтiв, якi вимагають пeвниx тexнiчниx кpoкiв щoдo викoнання, якi мeтoдoлoгiя yпpавлiння пpoeктами не включае);
- мeтoдoлoгiя пiдтpимки прийняття yпpавлiнcькиx ршень.
В бyдь-якoмy пpoeктi менеджери пpoeктiв вiдпoвiдальнi за ключoвi oблаcтi. Деяк iз циx oбoв'язкiв, бeзпocepeдньo пoв'язанi з мeтoдoлoгiями yпpавлiння пpoeктами, а ^ме:
- oдepжання cxвалeння для пpoдoвжeння пpoeктy;
- визначення мoжливocтi пpoeктy та завершення для вcьoгo бiзнecy;
- визначення, щo нeoбxiднi пpoeктнi pecypcи iдeнтифiкoванi й poзпoдiлeнi;
- планування пpoeктy дo нeoбxiднoгo piвня дeталiзацiï;
- iдeнтифiкацiя, щo пpoeктна мeтoдoлoгiя й пpoцecи е вiдпoвiдними;
- здiйcнeння мoнiтopингy пpoeктy пo тepмiнам, ваpтocтi, якocтi тoщo;
- iдeнтифiкацiя i кoнтpoль ризиш пpoeктy;
- забезпечення звiтами ва зацiкавлeнi cтopoни пpoeктy;
- забезпечення л^деро^ в пpoeктнiй кoмандi.
"Управлшня пpoeктами та poзвитoк виpoбництва", 2006, № 4(20)
3
Проекти бувають pi3Hi в залежностi вщ po3Mipy компани', po3Mipy рiшення, po3Mipy проектного штату, призначеного на проект тощо. 1дентифкаци' i вiдбiр правильно!' методологи дозволяе:
- уникнути помилок;
- зменшити вартiсть проекту;
- зменшити проекты ризики;
- забезпечити виконання графшв проекту;
- щентифкувати i виправляти помилки завчасно;
- уникнути зайво' документации
Стратегiя завжди йде поперед будь-яко' тактики. Стратепя повинна бути сформульована перш, шж ми вибираемо методологiю розвитку або проектну методологш. Стратепя як це завжди було й буде завжди залишатися, е несмнченною боротьбою за перевагу. Цть стратеги' полягае в тому, щоб виконувати таю роботи, ям створюють, пiдтримують та складають переваги.
lсторiя доводить, що краща стратепя й тактика досягнул в областях, фундаментальних для основних сил компани (наприклад, мати дисциплшу управлшня проектами). Багато проблем виникають, коли планування вщдтене вщ виконання. Витрачати на планування занадто багато часу е типовою помилкою управлiнцiв. Можна сттьки часу витратити на розробку стратеги' та тактики, що в мнц кш^в це призведе до нершучосл i помилок.
Мета розробки стратеги полягае в тому, щоб забезпечити швидке керiвництво й концентрацш зусиль, оскiльки оргашзаци' безупинно прагнуть полiпшувати ïx положення або одержувати перевагу на ринку.
В системному аспект методологiя управлiння проектами може розглядатися ттьки як пщсистема деяко' метасистеми. В табл. 1 наведет деям елементи методологи' управлiння проектами як системи.
Бтьшють проектiв беруть за основу загальноприйнятий життевий шлях. Не можна сказати, що ц проекти вс розробленi й виконують той самий шлях, але вони залишаються унiверсальними, оскiльки вони проходять подiбнi фази протягом життевого шляху проекту.
Таблиця 1
Елементи методологи управлшня як системи
Елемент системи Приклад
Проекты стандарти й кращi методи PMBOK, ICB, RUP, Java
Пщтримук^ процеси Контроль 3MÍH
lнфрастрyктyра yправлiння проектом Project management office
Шаблони Резюме проекту
Показники виконання ROI, Benefit Cost Analysis
Проекты роботи Тестування
Проекты техшки WBS
Проектнi iнстрyменти MS Project, Primavera
Проектнi ролi й обов'язки Команда проекту
Стрyктyра методологiï Процеси життевого шляху проекту
lнстрyментальнi моделi методологiï Prince2, eXtreme Programming
Методологи' управлшня проектами можна роздтити на проекты методологи (Project management frameworks) та методологи розробки проеклв (Project development methodologies).
При розглядi проектних методологш, ям юнують сьогодш, можна сказати, що працюють вони по^зному. Деям мають превентивний характер, деякi -реактивний, тобто не попереджують змши, а лише реагують на них. Ti методологiï, якi не мають достатнього рiвня планування, не будуть приносити
4
"Управлшня проектами та розвиток виробництва", 2006, № 4(20)
ycnix оргашзаци'. Деякi з наступних елеменпв необхiднi перед проектуванням, покупкою, або дослщним тестуванням передбачуваного рiшення:
- забезпечення стандартних доведених процеав i методiв;
- порiвняння за методом аналопв, експертних оцiнок тощо;
- визначення процеав, необхщних для виконання проекту;
- визначення графшв по вартост i часу згiдно з вибраною методологieю;
- визначення, як елементи компетентностi е важливими;
- формування та конф^урування ресурсiв;
- взаемодiя з постачальниками i зацкавленими сторонами проекту.
Розробка проектноТ методологи й пристосування ïï до ситуаци' часто
стикаеться зi змiнами на багатьох рiвнях у культурi, процесах i шформацшних системах. Культура може забезпечити команди проек^в розподiленою шформа^ею й полегшити зв'язок. Процесний пщхщ може забезпечити структуру дiй у проектах, що допомагае новим членам команд i може забезпечити загальну мову. 1нформацшш системи можуть бути пов'язаш iз певним процесом i забезпечити шструменти, якi впливають на щоденну роботу. Дослщження процесiв базуеться на активнш участi протягом розробки методологи для розробки продукту проекту. Результати аналiзуються, щоб забезпечити бтьш глибоке розумшня факторiв успiху, коли нова проектна методолопя повинна бути розвинена. Цть полягае в тому, щоб створити структуру, яка може бути використана компашями, як хочуть розвити або полiпшити |'х юнуючу проектну методологiю.
Впроваджуючи будь який новий процес, оргашза^я змiнюе свою культуру. Отже, менеджер проек^в не ттьки розробляе процеси управлiння проектом але також i створюе:
- плани пщтримки;
- плани комушкацш;
- плани впровадження.
Цi елементи полегшують змiну культури в оргашзаци i е фундаментальними для усшшного впровадження управлшня проектами. Менеджер проек^в повинен розумiти бiзнес процеси оргашзаци i бути здатним поеднати |'х з процесами управлшня проектами швидко та ефективно.
На сьогодшшнш день в лiтературi описано великий набiр методологiй управлiння проектами. Основнi або найбтьш вживанi методологи' управлiння проектами представлен в таблицi 2. Даш методологи' проаналiзованi за визначеними базовими характеристиками. Перелк даних характеристик, |'х опис та можливi значення в таблиц 2 наведенi нижче:
- галузь використання. Дана характеристика вказуе, в якш галузi господарювання найбтьш застосована дана методологiя. Як правило проектш методологiï можуть застосовуватися в рiзних галузях, оскiльки надаеться перелк основних процесiв управлiння; методологiï розробки проек^в навпаки, передбачають детальний перелк як управлiнських, так i технолопчних процесiв та використовують кращий досвщ у визначенiй галузi. Показник в таблиц може приймати значення: назва галузi або рiзнi галузi;
- po3Mip проекту. Вказуе, до якого розмiру проек^в застосування е ефективним. Деяк методологiï, наприклад ХР або Offshore, орiентованi пiд маленькi проекти з невеликою командою щодо розробки програмного забезпечення в сти^ строки. Таю методологи iнодi називають "легкими". Показник в таблиц може приймати значення: велим, середш, малi або рiзнi (-);
- ризики виникнення проблем. Вказуе на рiвень виникнення проблем в ходi реалiзацiï проекту. Чим детальшше визначенi ризики в методологи, тим менший
"Управлшня проектами та розвиток виробництва", 2006, № 4(20)
5
рiвень виникнення проблем. Показник в таблиц може приймати значення: велим, середш, мал^
- складн'ють впровадження. Вказуе, як описанi стратегiя i процеси впровадження даноТ методологи у дiяльнiсть оргашзаци. Дана характеристика е суперечливою, оскiльки велика ступiнь деталiзацп впровадження (процеси, документи, звггнють тощо) може негативно впливати на строки виконання проеклв. Показник в таблиц може приймати значення: велика, середня, мала;
- '¡нтенсивн'ють використання ресурав. Описуе, насмльки штенсивно передбачене використання ресурав по ходу виконання проеклв. Показник в таблиц може приймати значення: велика, середня, мала;
- част! змни в проектах. Вказуе, чи пщтримуе (передбачеш) методолопя змши в процесi виконання проектiв. Показник в таблиц може приймати значення: так (+), ш (-);
- пiдтримка зм/'н у зм'ют'! проекту. Вказуе, чи передбачена в методологи змша змюту проекту з урахуванням зовшшнього середовища проекту, наприклад, змши очкувань зацкавлених сторiн або вимог користувачiв продукту. Показник в таблиц може приймати значення: так (+), ш (-);
- пiдтримка звiтностi по проекту. Чи передбачена система звпносп по проекту, тобто зворотнш зв'язок з зацкавленими сторонами проекту. Показник в таблиц може приймати значення: так (+), ш (-);
- системи ведення документообгу. Вказуе, чи передбачеш в методологи документи, шаблони докуменлв щодо управлшня змшами та комунiкацiями по проекту. Може приймати значення: так (+), ш (-);
- використання нформа^йних технологй. Чи передбачено використання шформацшних технологш управлшня проектами в процес виконання. Може приймати значення: так (+), ш (-);
- накопичення досв/'ду та формування технолог'нно)' зр'тост'!. Чи описан процеси накопичення досвщу, використання кращого досвщу в майбутшх проектах та формування технолопчноТ зрiлостi. Може приймати значення: так (+),
н (-);
Таблиця 2
Основнi характеристики методологш ynравлiння проектами
Галузь використання Масштаб проекту Ризики виникнення проблем Складнють впровадження 1нтенсивнють використання ресурав Част змiни в проектах Пщтримка змiн у змiстi проекту Пщтримка звгтност по проекту Системи ведення документооб^ Використання шформ. технологiй к н н а в у и m о. т з ■ Р ю 3- Я M i S нх ее 3- ь и п о к а X Проектний шдхщ Процесний niдхiд Сценарний шдхщ
Project Management Frameworks (п poen™ мeтoдoлoгiï)
Waterfall Рiзнi - низ мал сер - + + - - - фаз + -
Incremental Рiзнi - сер сер сер - - + - - - фаз + -
Spiral Рiзиi - вис вел вис - + + - - - фаз + -
6 "Упpавлiння пpoeктами та poзвитoк виpoбництва", 2006, № 4(20)
System Development Life Cycle Рiзнi - сер сер сер + + + - - - фаз + -
PMBoK Рiзнi - сер сер сер + + + - - + фаз + -
OPM3 Рiзнi - сер сер сер + + + - - + фаз + +
Object oriented Рiзнi - вис вел вис + + - - + - тер + -
Unicycle Рiзнi - низ мал низ - + - - - - фаз + -
V-methodology Рiзнi - сер мал низ + + - - - - фаз + -
Project Development Methodologies (методологи' створення проекпв)
Rapid Applications Development !Т сер низ мал низ + - - - + - фаз + +
Crystal !Т сер сер мал сер + + - - - - тер + -
Prototyping Рiзнi - низ мал низ + + + - - - фаз + -
General publication Видавництво сер низ мал сер + + + + + - фаз + -
Pharma Фармакологiя вел сер сер сер + + - - - - фаз + -
Drug Development Фармакологiя сер сер сер вис - + + + - - фаз + +
Open source IТ сер низ мал сер + + - + + - тер + -
SSADM !Т - вис сер вис + + + - - - фаз + -
Pramis IТ мал низ мал низ + + + - - - фаз + -
Offshore IТ мал сер мал низ + + + - + - фаз + -
Reverse engineering IТ мал сер сер сер + + + - - + фаз + -
CMMI IТ - сер вис вис + + + - + + фаз + +
RUP !Т вел сер вис низ + + + + + - фаз + +
Prince 2 IТ вел сер мал сер - + + - + - фаз + -
eXtreme Programming IТ мал сер вис низ + + - + + - тер + -
ISO 12207 IТ - низ сер сер + + + + + - фаз + +
MIL-STD 498 IТ сер сер мал низ + + + + + + фаз + +
DOD 5000 !Т сер сер мал низ + + + + + + фаз + +
ГОСТ 34 IТ вел вис сер вис - - + + - - фаз - -
Microsoft Solutions Framework IТ вел сер сер сер + + + + + - тер + +
Project Management Method (ORACLE) IТ вел сер сер вис + + + + + - фаз + +
- проектний пдх'д. Характеризуемся ч^кою орieнтацieю на досягнення цiлi - створення продукту проекту. 1нструменти управлiння проектами побудован з урахуванням унiкальностi проекту та покликан забезпечити досягнення ц^ за заданими критерiями. Може приймати значення: Фазний, 1терацшний;
- процесний пдх'д. Це регламента^я та ушфка^я дiй проектних менеджерiв щодо приведення 'х до процесiв, що повторюються, з описом вхiдних та вихщних параметрiв, а також набору дш, що перетворюють вхiд у вихщ. Може приймати значення: так (+), н (-);
- сценарний пдхд. Пов'язаний з процесами подготовки та прийняття ршень в управлiннi проектами. Сценари забезпечують швидкий перенос кращо'Г практики в рiзнi процеси управлшня проектами. Може приймати значення: так (+),
н (-).
Також слiд зазначити, що в таблицi вказан середнi значення визначених характеристик експертних знань щодо вказаних методологш управлшня.
Даний перелк базових характеристик методологш управлшня проектами може слугувати проектному менеджеру шструментом попереднього визначення перелку методологш щодо впровадження в дiяльнiсть оргашзаци. При чому порядок характеристик та ваговi коефiцiенти щодо визначення кращо' методологи повиннi визначатися в кожному випадку окремо, в залежност вщ навколишнього середовища та зацкавлених сторiн проекту. У випадку, коли одна з зацкавлених сторiн проекту вже використовуе у сво'й дiяльностi визначену методологiю, перехiд на шшу методологiю може бути недоцiльним.
Висновки та використання результат'в роботи. В данш робот представлено визначення методологи управлшня проектами, и основнi
"Управлшня проектами та розвиток виробництва", 2006, № 4(20)
7
властивосл, а також розглянут та проаналiзованi найбiльш розповсюдженi на сучасному етап методологи управлiння проектами за визначеними базовими характеристиками. Наведена в робот таблиця аналiзу методологш та базових характеристик може слугувати шструментом пщтримки прийняття управлiнських рiшень проектним менеджером або керiвництвом оргашзаци для впровадження вщповщноТ' методологи управлiння проектами.
Л1ТЕРАТУРА
1. Бушуев С.Д. Развитие систем знаний и технологий управления проектами. Управление проектами. М.: Издательский дом Гребенникова. 2(2) 2005.
2. Charvat J. Project Management Methodologies—Selecting, Implementing, and Supporting Methodologies and Processes for Projects, John Wiley & Sons © 2003 (264 pages).
3. Dragan Milosevic, Peerasit Patanakul Standardized project management may increase development project success.//International journal of project management №3 (2005), 181192.
4. Lynn Crawford, Julien Pollack Hard and soft projects: a framework for analysis.//International journal of project management №8 (2004), 645-655.
5. Schindler M., & Eppler M.J., Harvesting project knowledge: A review of project learning methods and success factors. International Journal of Project management 21, 219-228, 2003.
6. ISO/IEC 12207:1995(E), Information Technology - Software Life Cycle Processes, ISO/IEC, Geneve, Switzerland, 1995.
7. DoD Instruction 5000.2, "Operation of the Defense Acquisition System," April 5, 2002.
8. MIL-STD-498. military standard software development and documentation. 5 December 1994. AMSC NO. N7069. 76 pages.
9. Microsoft Solutions Framework. Модель процеав MSF вер. 3.1. Техычний опис. 2002 Microsoft Corporation.
10. Jennifer Stapleton, DSDM Dynamic Systems Development Method: The Method in Practice, Addison-Wesley, 1997.
11. Malik, Palencia. Synchronize and Stabilize versus Open Source, Computer Science report 95.314A. Ottawa, Ontario, Canada: Carleton University (December 6, 1999).
12. Royce, W. The Rational Edge—CMM versus CMMI, From Conventional to Modern Software Management, February 2000.
13. Using the Rational Unified Process for Small Projects; Expanding upon extreme Programming. Gary, Indiana: Gary Police, Rational Software.
14. Weaver P., N. Lambrou, and M. Walkey. Practical SSADM, Ver. 4, 2nd ed. Pitman Publishing, 1993.
15. Chapman, J. R. "Project Management Scalability Methodology Guide."—New Drug Development Process. 1997.
16. Кент Бек, Экстремальное программирование, Питер, 2005, 216 стр.
17. Managing Successful Projects with PRINCE2. Reference Manual. 2002, Nantwich, Cheshire CW5 6GD.
18. Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание 2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA.
19. CMMISM-SE/SW/IPPD, V1.02, CMMI for Systems Engineering/Software Engineering/Integrated Product and Process Development, Version 1.02, CMMISM-SE/SW/IPPD, V1.02, Continuous Representation. CMU/SEI-2000-TR-031, ESC-TR-2000-096, Carnegie Mellon University, Software Engineering Institute, Pittsburgh, PA, November 2000.
Стаття надмшла до редакцп 10.10.2006 р.
8
"Управлшня проектами та розвиток виробництва", 2006, № 4(20)
