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

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

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

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

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

В Плані керування проектом має бути відбито

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

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

Плановий бюджет проекту

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Розглянуті вище приклади класифікацій проектів спеціально підібрані нами для ілюстрації можливості складання шаблона з відносно незалежних стандартних фрагментів. Однак у реальному житті зустрічаються й інші ситуації. Наприклад, в IBM прийнята класифікація проектів по складності (комплексності). Відповідно до цієї класифікації проекти діляться на звичайний бізнес (Business as Usual - Ba), стандартні проекти системної інтеграції й складні проекти системної інтеграції. Причому саме ця класифікація є визначальною для структури й утримування Плану керування проектом. При цьому інші класифікації зберігають своє значення для формування окремих розділів Плану.

План керування проектом

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

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

Утримування й границі проекту

При побудові спеціалізованого мікрошаблона "Утримування й границі проекту" ми використовували рекомендації PMBo PMI (Табл. 1).

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

Табл. 2.

Спеціалізований мікрошаблон:"Утримування й границі проекту створення Ит-Інфраструктури філії банку"

Зіставивши наведене в прикладі втримування розділів Продукт проекту й Результати проекту , можна помітити, що результатами проекту є елементи декомпозиції продукту проекту. Саме тому при формуванні Плану (а, отже, і при формуванні шаблона Плану) часто використовують структуру декомпозиції робіт (WBS - Work Breakdown Structure), а багато провідних компаній включають у свої методології й стандарти типові WBS як у явному виді (Andersen Consulting), так і неявно (IBM).

Структура декомпозиції робіт

Провести декомпозицію й скласти структуру декомпозиції робіт (WBS - Work Breakdown Structure) за твердженням деяких авторів дуже легко: "Насамперед, варто розбити проект на трохи подпроектов. Кожний з подпроектов, у свою чергу, може бути розбитий на деяке число подподпроектов. Так варто послідовно ділити проект на складові частини доти, поки не буде досягнутий потрібний рівень деталізації" (Цитуємо по статті М. Ньюэлла "Структура декомпозиції робіт" у березневому номері журналу "Директор інформаційної служби" за 2001 р.).

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

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

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

На які ж подпроекты варто розбити вихідний проект? Що буде зручніше бачити на першому рівні декомпозиції - компонента ИС (програмні, технічні, інформаційні) або технологічні етапи (концепція, технічне завдання, проектування й т.д.)? А може бути зручніше згрупувати роботи з виконавців або по замовниках?

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

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

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

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

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

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

Проілюструємо це на прикладі не самого складного розділу плану "Організаційна структура проекту". В PMBo необхідна інформація розкидана по декількох розділах (2.2.; 2.3.; 2;4.; 4.1.3.; 9), а в ISO 10006:1997(Е) - розділі 5.8. Але й у тім і в іншому випадку для створення спеціалізованого шаблона цієї інформації не досить!

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

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

Проектні відхилення. Ризики, проблеми, зміни

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

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

Однак, уже плануючи проект, ми припускаємо, що не все вийде саме так, як заплановано. І реальне виконання проекту, як правило, підтверджує ці побоювання. Виникаючі розбіжності первісного погодженого й зафіксованого подання про проект (project baseline) і того, що виходить у дійсності, і називаються звичайно відхиленнями. Термін, що розуміється в цьому змісті, "відхилення" еквівалентний терміну "deviations", використовуваному в англомовній літературі.

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

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

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

Сценарії керування відхиленнями

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

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

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

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

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

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

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

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

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

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

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

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

Керування ризиками

Найпростішому, і разом з тим необхідне, що повинне бути відбите в стандарті - формальна сторона керування ризиками, а саме:

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

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

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

Табл. 3.

Матриця ступеня погрози ризику

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

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

Керування проблемами

Насамперед, пояснимо, що ми називаємо проблемами й чому проблемами можна (і потрібно) управляти.

У ході реальної роботи зі створення й впровадження стандарту керування проектами на підприємстві авторам довелося зштовхнутися з тим, що словосполучення "керування проблемами" викликає здивування в колег, що не мали досвіду знайомства з англомовними стандартами керування проектами. Многим здаються більше звичними вкорінені в російськомовній літературі терміни «рішення» або «дозвіл проблем», які відповідають визначенням «problem solving» або «problem resolution», прийнятим у згадуваним вище так званих "рамкових" стандартах.

Автори в цьому питанні воліють випливати духу й букві таких стандартів керування проектами як MITP/PMM/WISDDM корпорації IBM, у яких цей процес називається "problems/issues management", що в російському перекладі найкраще, на наш погляд, виглядає саме як "керування проблемами".

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

Звичайно проблеми ділять на дві категорії - на проблеми, які можуть бути вирішені в місці виникнення, тобто на рівні керування проектом - problems, і эскалируемые проблеми - issues, які для їхнього дозволу потрібно підняти на верхні рівні керування, у тому числі, зовнішні стосовно проекту.

У стандарті повинна бути відбита формальна сторона керування проблемами:

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

Література: сновна [1, 4], додаткова [1, 2].

Дата добавления: 2015-07-26; просмотров: 150; Нарушение авторских прав

Мы поможем в написании ваших работ!