Умови, чинники і критерії успішної реалізації проекту. Критерії успішності проекту Критерії успіхів і невдач в управлінні проектами

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

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

Однак в більшості компаній проекти реалізуються не завжди «гладко». Вони не вписуються в рутинну щоденну роботу. «Гартнер» - всесвітньо відома аналітична компанія - вважає, що 66% великомасштабних проектів не можуть виконати заявлені комерційні цілі, Завершуються з запізненням, або значно перевитрачають бюджет. Група Стендіш, що відслідковує виключно успіхи і невдачі ІТ-проектів, визначає невдалі проекти як проекти, кинуті посередині, і оцінює кількість невдач в 15%. При цьому «ущербні» проекти (визначені як проекти з перевитратою коштів, зривом термінів, і проекти з незадовільними результатами) складають 51% від всіх ІТ-проектів.

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

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

На думку А. Головіна, проект зазнає невдачі в трьох випадках :

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

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

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

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

В цілому слід зазначити, що головними причинами невдач проектівє:

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

Група Стендіш впевнена, що з амие важливі факториуспіху або невдачі проектутакі, в порядку важливості:

Рівень залучення замовника.
Підтримка вищого керівництва.
Досвідчений керівник проекту.

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

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

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

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

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

Рішення про порятунок проекту беруть: вище керівництво (в 50% компаній), спонсор (16%), керівник відділу (16%) або менеджер проекту (13%). У невеликих фірмах спонсор (24%) або менеджер проекту (24%) мають набагато більше влади в плані голоси за порятунок проекту. Рідше це рішення приймає глава відділу (5%).

Узагальнення практичного досвіду управління проектами показує, що найчастіше кроки, спрямовані на порятунок проекту , Це:

модернізація комунікації та управління (62%);
перегляд завдань проекту - скорочення його масштабів, перегляд фінансування (60%);
додавання або видалення ресурсів (58%);
вирішення технічних проблем (49%);
заміна менеджера проекту або залучення консультанта (36%).

Фірми, у яких немає методології, частіше вважають за краще замінювати менеджера проекту, ніж ті, у яких методологія освоєна (22% і 9% відповідно). Вони також частіше залучають сторонніх консультантів для порятунку проекту (26% проти 11%).

Зазвичай операції з порятунку проблемного проекту досить успішні. Майже три чверті проблемних проектів (74%) в результаті успішно завершені, 18% ще в процесі, тому остаточні результати не відомі. Тільки 4% дійсно провалені, і 3% закриті з бізнес-міркувань.

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

Компанії, у яких не прийнята стандартна методологія ведення проекту, не завжди цінують ці вміння і навички, ніж ті, у яких така методологія присутній (78% перших висловилися про важливість кваліфікації менеджера проекту і 96% - друге).

Майже всі організації-респонденти (92%) відзначили, що вміння і навички менеджера проекту дуже важливі(64%) або просто важливі (28%) для успіху операції з порятунку проблемного проекту.

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

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

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

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

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

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

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

Серед інших факторів успіху проектного управлінняслід назвати:

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

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

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

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

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

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

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

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

Хоча в управлінні проектами використовуються такі терміни як «початок-закінчення», термінологія далеко не так важлива, як зміст: те, яким чином роботи пов'язані один з одним (яка технологія).

Очевидно, що дослідження кривої «час / вартість» до початку проекту дозволяє компанії прийняти правильне рішення при затвердженні розкладу проекту.

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

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

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

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

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

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

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

Загальна готовність до змін. В успішних організаціях панує філософія, заснована на наступних положеннях: «вік живи - вік учись», «не помиляється той, хто нічого не робить», «немає такої проблеми, з якою ми не змогли б упоратися».
Культура конфліктів. При успішних проектах з конфліктами обходяться конструктивно і відкрито. Панує вільний обмін інформацією та думками, а також відкритість для критики.
Особиста відповідальність співробітників проекту. Успіх проектів безпосередньо пов'язаний зі ступенем особистої відповідальності співробітників проекту і можливості самоорганізації. Чим більшими повноваженнями володіє кожен окремо, тим швидше він готовий взяти на себе відповідальність, і тим більше його особиста ініціатива і мотивація. Малі повноваження, навпаки, сприяють пасивності і навіть протидії.
Культура довіри. По-людськи приємний клімат відкритості, щирості і чесності в спілкуванні один з одним підвищує ймовірність успіху проектів. При культурі довіри існує менший ступінь прийняття помилок і рішення приймаються всіма, а після рішення втілюються в життя.
відсутність ієрархії. Проекти тоді були особливо успішними, коли робота над проектом відбувалася в команді, де ієрархія не грає ролі в організації проекту або, щонайменше, зведена до мінімуму. Жорстка ієрархія блокувала в невдалих проектах творчість і мотивацію співробітників проекту.
Комунікаційна та інформаційна культура. Проекти були особливо успішними, коли в команді панувала атмосфера інтенсивного обміну інформацією і відкритої комунікації, тобто висока ступінь гласності. Гарна комунікація в цьому відношенні означає добру співпрацю, і навпаки. Інтенсивна комунікація між різними функціональними сферами призводить до того, що зростає взаєморозуміння, і співробітники можуть поглянути за «край тарілки» своєї власної сфери, що призводить до прийняття більш зважених рішень.

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

Що таке успішний проект?

8 червня в рамках 3-й міжнародній Тижня проектного менеджменту, організованої компанією "Технології управління Спайдер Україна", відбувся семінар "Успіх проекту - критерії, управління, корпоративна культура".

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

типи проектів

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

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

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

Удача проекту лежить за його межами

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

Успіх оцінить NPV і IRR

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

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

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

Керувати проектом як бізнесом?

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

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

небізнесовій оцінки

Втім, фактично відповіддю на поставлені вище питання був запропонований інший підхід, більш універсальний, не обов'язково прив'язувати до вище зазначених бізнес-показниками ефективності. Складається перелік показників, які компанія вважає для себе придатними для оцінки ефективності. Кожен проект з цього переліку оцінюється (наприклад, по 10-бальній системі), при цьому кожен показник множиться на оцінку важливості проекту, а отримані бали в переліку сумуються. Таким чином, проекти будуть проранжовано по ефективності відповідно до прийнятого переліком показників. Якщо немає необхідності використовувати NPV і IRR, то значить, не обов'язковий і бізнесмен-проджект-менеджер, а значить, звичайний проджект-менеджер не "зазіхає" на життєвий цикл продукту, а "вариться" в контексті життєвого циклу проекту.

Як зв'язати успіх команди і успіх проекту

Поряд з питанням про успішність проекту стоїть і питання про успішність команди проекту. Цілком очевидно, що команда в проекті може бути успішною, а сам проект - немає; можливо і зворотне. Справді, команда вклалася в обмеження проекту, але виявилося, що проект збитковий - його цілі були поставлені перед командою неправильно. Або навпаки, команда досягла результату із запізненням і перевитратою бюджету, але при цьому з точки зору прибутку проект виявився успішним. Щоб проект був успішним, необхідно поєднати інтереси команди проекту і організації, яка виконує проект. Це визначається прийнятими критеріями і системою мотивації. Критерії повинні бути такими, щоб в точках прийняття рішення про продовження робіт (kill points) можна було оцінити доцільність управлінських рішень. Наприклад, чи варто витрачати гроші, щоб прискорити реалізацію, або заощадити, але спізнитися - як це "відгукнеться" в майбутньому.

Критерії успіху і невдачі

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

"Три сценарії" проти ризиків проекту

Спочатку будь-які оцінки, що використовуються при плануванні проекту, повинні містити діапазони можливих значень. Але як би не були хороші критерії оцінки, необхідно мати на увазі, що в них завжди присутній елемент невизначеності. Невизначеність подій і умов призводить до ризику проекту. Тому управління проектами вимагає управління ризиками, і в PMBoK Guide (звід знань управління проектами від PMI) введений спеціальний розділ про процеси управління ризиками. В. Ліберзон виклав свою версію інтерпретації цього розділу. В цілому вона збігається з тим, що викладається в класичних курсах з управління ризиками підприємства в цілому. Адже природа багатьох з них однакова при управлінні і проектами, і фінансами, і ІТ, і виробництвом. Що стосується способу моделювання ризиків, то гарний в теорії і погано реалізований на практиці метод Монте-Карло доповідач пропонує замінити підходом "трьох сценаріїв" (оптимістичний, найбільш імовірний, песимістичний), при цьому оцінку ризиків вести не по самим можливостям успіху, а по їх трендам. "Три сценарії" застосовується для оцінки ресурсів і критичних шляхів. При цьому критичне розклад складається з урахуванням страхових резервів (буферів). Під час бесіди з автором цих рядків В. Ліберзон висловив думку про те, що все управління проектами в кінцевому рахунку зводиться до управління цими резервами. Тому "по-доброму" за рахунок резервів різного рівня "відповідальності" необхідно передбачити п'ять (!) Бюджетів - виконавця, команди, керівництва, контракту і точки відмови від контракту.Комп'ютерне моделювання - запорука успіху

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

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

- Борис Жданов, головний редактор журналу "Корпоративні системи"

Критерії успішності проекту- сукупність показників, які дають можливість судити про ступінь успішності виконання проекту.

Критерії успішності управління проектом- показники ефективності управління проектом.

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

Чітке і однозначне визначення цих критеріїв є обов'язковим завданням на початковому етапі запуску проекту. Керівник проекту повинен визначити і погодити показники успішності і способи їх оцінки з усіма зацікавленими сторонами проекту.

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

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

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

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

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

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

На самому початку проекту вельми доцільно проаналізувати причини можливих невдач проекту (потенційні зони ризиків).

Основними причинами невдач проекту можуть бути:

Неясні цілі;

Недостатнє фінансування;

Зміна пріоритетів бізнесу;

Недостатня підтримка з боку вищого керівництва;

Неефективна команда (кваліфікація персоналу проекту);

Недостатньо ефективна взаємодія в проекті;

Недолік самоврядування;

Недостатньо ефективні комунікації;

Відсутність мотивації (відноситься до внутрішніх ризиків);

Необхідно протестувати проект на «причини можливих невдач»: чи достатньо зрозумілі цілі проекту? Ступінь надійності інвесторів? Чи достатня кваліфікація команди проекту? Чи достатня її мотивація?

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

Далі буде...

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

Але спершу доведеться відповісти на питання "що таке проект" :)

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

Це перше питання, на яке необхідно відповісти будь-якому менеджеру.

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

Більшість методологій проектного управління об'ємні. Наприклад, остання редакція "біблії менеджерів" PMBoK становить майже 1000 сторінок, керівництва Prince2, IPMA та інші (про них - як-небудь іншим разом) - теж не маленькі.

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

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

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

визначення терміна

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

Подібні формулювання зустрічаються часто. В тому числі, в самому PMBoK. Проблема: вони невдалі. З них незрозуміло головне - чим проект відрізняється від «не проекту".

Не вірите? Спробуйте підібрати хоча б один приклад будь-якої діяльності, який не підпадає під це визначення?

Пояснюємо на прикладі

Ви вирушаєте на роботу або готуєте собі вранці яєчню на сніданок.

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

Обмежені у часі? Безумовно! Не можна снідати пів дня або витратити добу на дорогу.

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

Чи потрібно називати таку роботу проектом? Звичайно, ні! Які там 1000 сторінок методологій, щоб посмажити яєчню. Можна впоратися однією інтуїцією і здоровим глуздом.

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

Про пафосі тренерів

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

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

Однак, повернемося до яєчні.

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

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

І ось в такій ситуації, ваша діяльність починає все більше нагадувати проект. Ви починаєте ретельніше (у порівнянні зі звичним сніданком) планувати - лізете в інтернет, з'ясовуєте "як смажити", "як розбивати", підбираєте спеціальну сковорідку (або навіть купуєте в магазині підходящу, розраховуєте час. Не обов'язково вся 1000 сторінок PMBoK знайде застосування в такому підході. Але дуже багато елементів, які вам не спало б і в голову використовувати для звичайного сніданку або подорожі до офісу ви застосуєте тут.

Що змінилося

Дозвольте запропонувати своє визначення.

Проектом ми назвемо роботу над завданням, якій властиві одночасно:

кінцівку,
висока невизначеність.

Кінцівка - це "рамки", обмеженість в термінах і ресурсах.

Висока невизначеність - говорить про те, що поставлене завдання до кінця незрозуміло, як вирішити. Тільки коли ОБИДВА умови дотримуються - застосовуйте проектне управлінні.

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

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

Ось чому (на мій погляд) будівництво єгипетських пірамідстародавніми єгиптянами - не проект. Як мінімум один з параметрів відсутня. І це - кінцівку.

Будівництво єгипетських пірамід - не проект

Будівництво піраміди починали, коли народжувався фараон. Закінчити потрібно було до моменту його смерті. Якщо не траплялося загибелі в дитинстві, то, швидше за все, на будівництво відводилося років 20-30 як мінімум. Ресурси (люди, матеріали) також не були дефіцитними. Думки розходяться - будували чи піраміду раби або вільні найманці, але, в будь-якому випадку, працював принцип - "щось пішло не так? Давайте приженемо ще людей ". Якщо у вас не обмежені терміни і / або бюджети, то рано чи пізно ви впораєтеся з будь-яким завданням. Навіть з дуже складною. І дуже незрозумілою вам. З п'ятого-десятого-двадцятого рази, після величезних витрат - все у вас вийде.

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

Операційна діяльність - це що

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

Для операційної діяльності характерно порушення обох принципів: (без-) кінцівку і (відсутність) невизначеності.

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

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

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

Критерії успіху проекту

Говорячи про визначення проекту важливо згадати і критерії успіху. Хто такий "успішний менеджер"? Що таке "успішний проект"? І що вважати провалом?

Відповідь давно вироблений методологами.

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

Звучить громіздко, але легко передається однією картинкою. Уявіть собі трикутник (його з деяких пір перестали малювати в PMBoK, але суть нікуди не поділася). У трикутника три грані = терміни, гроші, зміст. У центрі - усміхнений смайлик. Всі.

Це критерії вашого успішного проекту.

Грані - то що погоджено з замовником до старту проекту. Зазвичай - такі домовленості високорівневі, в загальних рисах, але вони ж - непорушні. Пообіцяли зробити будинок з цегли, 9-и поверховий, в термін 12 місяців і з бюджетом в 1 млн. Доларів? Робіть!

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

Отже, три грані проекту ви повинні визначити ДО того, як почнете працювати. Терміни ( "закінчимо не пізніше, ніж"), гроші ( "бюджет проекту не більше, ніж ...") і зміст в 2-3 пропозиції ( "що робимо і чого не робимо"). Ці межі символізує трикутник на зображенні.

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

Як стати хорошим менеджером

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

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

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

Проектне управління - це балансування: як визначити і не провалити рамки трикутника (терміни-гроші-вміст) і домогтися задоволеності ключових зацікавлених сторін проекту. Це ключове, що потрібно пам'ятати про критерії успіху проекту.

Стаття написана на підставі навчального курсу з управління проектами.

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

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

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

· Підвищити ефективність взаємодії з контрагентами;

· Збільшити клієнтську базу компанії;

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

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

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

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

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

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

Цілі проекту повинні відповідати вимогам SMART (Specific - Спеціалізовані, Mesurable - Вимірні, Actively Influencible - Актуальні, Realistic - Реалістичні, Time Limited - Обмежені за часом).

Для наведеного прикладу необхідно було визначити цілі:

· Після завершення проекту 90% співробітників використовують інформаційну систему;

· Система містить актуальні дані;

· Збільшити клієнтську базу компанії на 20% за півроку використання системи;

· Збільшити кількість позитивних відгуків споживачів на 10% і зменшити кількість скарг на 10% за півроку використання системи.

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

Для оцінки виконання цілей проекту вводять критерії успішності проекту. Проект успішний, якщо він:

· Завершено у встановлені терміни;

· В рамках виділеного бюджету;

· При задоволенні замовника.

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

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

Початок проекту пов'язано з початком його реалізації і початком вкладення грошових коштівв його виконання.

Закінченням існування проекту може бути:

· Введення в дію об'єктів, результатів проекту, початок їх експлуатації та використання результатів виконання проекту;

· Переклад персоналу, що виконував проект, на іншу роботу;

· Досягнення проектом заданих результатів;

· Припинення фінансування проекту;

· Початок робіт по внесенню в проект серйозних змін, не передбачених початковим задумом (модернізація);

· Висновок об'єктів, результатів проекту з експлуатації.

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

Стану, через які проходить проект, називають фазами (етапами, стадіями).

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

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

У свою чергу, кожна виділена фаза (етап) може ділитися на фази (етапи) наступного рівня (підфази, підетапи) і т.д.

Приклад життєвого циклу проекту наведено на рис. 1.3.

відображено:

· Фази проекту;

· Віхи по початку і закінчення кожної фази;

· Результати кожної фази.

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

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

Що наростає в ході проекту і різко знижується до завершення рис. 1.4
):

· Рівень витрат;

· Рівень завантаження персоналу.

Що збільшується в ході проекту (рис. 1.5
):

· Ймовірність успішного завершення проекту;

· Вартість змін;

· Вартість виправлення помилок.

Що зменшується в ході проекту (рис. 1.6
):

· Невизначеність / ризики проекту;

· Можливість учасників вплинути на кінцеві характеристики продукту проекту;

· Можливість учасників вплинути на вартість продукту проекту.

Існує взаємозв'язок життєвого циклу проекту і життєвого циклу продукту.

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

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