Міжнародні стандарти управління проектами Національні стандарти з управління проектом

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

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

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

1. Project Management Body of Knowledge (PMВОК)Американський інститут управління проектами.

Цей стандарт підлягає оновленню приблизно один раз на чотири роки. Однією з найпоширеніших редакцій є редакція 2000 р., а найактуальнішою четверта версія стандарту вийшла наприкінці 2008 р. – The Guide to the PMBOK, 4th Edition. Стандарт був прийнятий спочатку Американським національним інститутом стандартів (ANSI) як національний стандарт у США, а на сьогоднішній день має світове визнання.

Основою стандарту є процесний підхід до управління проектами. Відібрані елементарні процеси формують процедури управління проектами, які можна побудувати за "осьовим" принципом (тут маються на увазі аплікату, ординату та абсцису, представлені на рис. 1).

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

управління контрактами проекту (Project Procurement Management);
управління ризиками проекту (Project Risk Management);
управління взаємодією у проекті (Project Communications Management);
управління людськими ресурсами проекту (Project Human Resource Management);
управління якістю проекту (Project Quality Management);
управління вартістю проекту (Project Cost Management);
керування термінами проекту (Project time Management);
управління змістом проекту (Project Scope Management);
керування інтеграцією проекту (Project Integration Management).

Мал. 1. Простір процесів управління

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

2. IPMA Competence Baseline (ICB)є міжнародним нормативним документом, який визначає систему міжнародних вимог до рівня компетентності менеджерів проектів. Цей стандарт було складено міжнародною асоціацією IРМА (International Project Managers Association). На його базисі здійснюється розробка вимог щодо рівня компетентності співробітників у країнах, що є членами IPMA. Національним системам вимог необхідно відповідати ICB IPMA та офіційно ратифікуватися (затверджуватись) відповідними органами IPMA. Для 32 країн-учасниць IPMA є базисом для створення національних склепінь знань. 16 країн наразі мають затверджені національні склепіння знань, які відповідають ICB.

ICB, на відміну від РМВОК, дотримується діяльнісного, компетентного підходу, тобто визначає сфери кваліфікації та компетентності в управлінні проектами, а також принципи з оцінки кандидата на отримання сертифікату. ICB включає 42 елементи (28 основних та 14 додаткових), які визначають галузі вимог до професійного досвіду, майстерності та знань у менеджменті проектів.

ICB видано англійською, французькою та німецькою мовами. Базисом йому стали кілька національних розробок: Body of Knowledge of АРМ (Великобританія); PM-ZERT/GPM (Німеччина); Beurteilungsstruktur, AFITEP (Франція); VZPM (Швейцарія); PM-Kanon Criteres d'analyse.

Кожна національна асоціація, що входить до складу IPMA, є відповідальною за формування та затвердження власних Національних вимог з компетентності (National Competence Baseline – NCB) відповідно до ICB, а також враховуючи національні особливості та культури. Національні вимоги на відповідність ICB та основним критеріям сертифікації відповідно до стандарту EN 45013 оцінюються спеціальним Комітетом IPMA.

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

Стандарт ISO 10006- основний документ із серії стандартів профілю, що розглядається, підготовленим технічним комітетом ISO/TC 176 "Управління якістю та забезпечення якості" Всесвітньої федерації національних органів стандартизації (члени ISO).

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

У цій серії стандартів процеси групують на дві категорії. До першої категорії відносять процеси, пов'язані із забезпеченням продукту проекту (проектування – виробництво – перевірка). Опис даних процесів міститься у стандарті ISO 9004-1. До другої категорії належать безпосередньо процеси управління проектом та містяться вони у стандарті ISO 10006.

Цей стандарт охоплює 10 груп процесів управління проектом.

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

Другою групоюохоплено керування взаємозв'язками процесів.

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

Міжнародний стандарт ISO 10006 складений для проектів широкого спектру – малих та великих, короткострокових та довгострокових, для різних навколишніх умов. Стандарт не враховує тип продукту, що проектується (включаючи послуги, напівфабрикати, технічні засоби, програмне забезпечення або їх поєднання). Це означає, що покладені в основу рамкові вимоги необхідно в подальшому адаптувати даним посібником до конкретних умов створення та виконання окремого проекту.

Стандартом запозичені ключові визначення стандарту ISO 8402, у тому числі такі терміни, як проект, план проекту, продукт проекту, процес, оцінка ходу робіт, учасник проекту. Для всіх етапів управління проектом (планування, організація, контроль та моніторинг) застосовуються завдання та процеси менеджменту якості.

З міжнародних стандартів формуються і національні стандарти управління проектами. Наголосимо на той момент, що в Росії національних стандартів немає. Однак Асоціація з управління проектами Росії (SOVNET) на основі стандарту IPMA створила в 2001 р. "Основи професійних знань. Національні вимоги до компетентності фахівців". Переклад стандарту ISO 10006:2003 зареєстровано, стандарт PMI поширюється в Росії приватним порядком і використовується часто як основа для корпоративних стандартів.

Необхідно також позначити стандарти зрілості управління проектами, також мають функції міжнародних. У 2004 р. PMI розроблено стандарт оцінки рівня зрілості компанії з управління проектами ОРМЗ (Organization Project Management Maturity Model), який містить методологію виявлення стану управління проектами в компанії.

Організаційна зрілість з управління проектами

p align="justify"> Категорія "організаційна зрілість з управління проектами" описує здатність компанії відбирати проекти і керувати ними так, щоб це найбільш ефективним чином підтримувало досягнення стратегічних цілей організації.
Загальна характеристика рівнів зрілості стосовно управління проектами представлена таблиці 1.

Таблиця 1 – Загальна характеристика рівнів зрілості організації

Рівень зрілості	Характеристика рівня
Рівень 1	Початковий, нульовий рівень. Співробітники діють, ґрунтуючись на своїх особистих уявленнях про цілі роботи. Нема внутрішніх регулюючих документів. Дії не документуються, бізнес-знання не відокремлені від працівників (при звільненні працівників знання пропадають). Бізнес-процеси у компанії не описуються і, відповідно, не класифікуються. Діяльність організації є непрозорою і для основного персоналу.
Рівень 2	Рівень усвідомлення. Керівництво організації вирішує перевершити початковий рівень. Виникають внутрішні стандарти, що описують основні бізнес-процеси організації. З'являється повторюваність – виконання нових проектів виходить з досвіді здійснення попередніх проектів.
Рівень 3	Рівень керованості. У компанії стандартизовано та задокументовано всі бізнес-процеси. Система управління відокремлена від усіх співробітників підприємства, тобто. з'являється внутрішній "звід законів". Цими законами дотримуються всі співробітники організації, зокрема й топ-менеджмент.
Рівень 4	Рівень вимірюваності. В організації вводиться кількісна система оцінки ефективності бізнес-процесів (застосовуються як натуральні, і фінансові показники). Одночасно застосовується та чи інша система оцінки роботи співробітників, наприклад, система ключових показників. Обидві системи та опис бізнес-процесів та оцінки персоналу синхронізовані один з одним – ефективна діяльність організації тягне за собою і стимулювання персоналу.
Рівень 5	Рівень удосконалення. На основі аналізу кількісних показників у компанії проводиться коригування (реінжиніринг) бізнес-процесів. Корекції відбиваються у внутрішніх документах. Важливо те, що процес корекції має постійний, системний характер.

ОРМЗ – це стандарт, який є комплексним підходом, що допомагає компаніям проводити оцінку та розвиток своїх можливостей щодо ефективної реалізації проектів. Цей стандарт є ключем до організаційної зрілості управління проектами та включає три взаємозалежні елементи:

елемент "знання" (knowledge)- є комплексом, що містить сотню найкращих практик з управління проектами, які характеризують ті чи інші рівні організаційної зрілості управління проектами;

елемент "оцінка" (assessment)- Інструмент, що допомагає компаніям оцінити рівень поточної зрілості управління проектами та встановити галузі поліпшення;

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

Основне призначення ОРМЗ полягає в тому, щоб бути стандартом для організаційної зрілості з управління проектами та корпоративного управління проектами.

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

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

Якщо ви помітили помилку в тексті, будь ласка, виділіть її та натисніть Ctrl+Enter

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

У 1986 році інститутом Software Engineering Institute (SEI) починається розробка системи оцінки можливостей компаній з розробки програмного забезпечення Capability Maturity Model (CMM) на основі технік описаних Філіпом Б. Гросбі, фахівцем і відомим лектором в галузі управління якістю, в його книзі « Quality is Free». Розробка була ініційована запитом від ВПС США, зумовленим гострою необхідністю мати можливість оцінювати професійність підрядних організацій.

CMM визначає п'ять рівнів професійності:

1. Початковий – процес розробки перебуває під статистичним контролем, прогрес у вдосконаленні процесів відсутня.
2. Повторюваний – стійкий процес із відновлюваним рівнем статистичного контролю досягається шляхом застосування скрупульозного управління проектами у сфері трудовитрат, витрат, термінів і змін.
3. Встановлений – спостерігається налагоджений процес розробки, внутрішні стандарти якості, менеджмент розуміє недоліки практик. Можливе успішне впровадження передових технологій.
4. Керований – після певного етапу можна ініціювати процес аналізу. Менеджмент може управляти якістю за допомогою вироблених технік.
5. Оптимізований – організація перебуває у постійному процесі вдосконалення.

Як система оцінки CMM була опитувальником з 85 процесних і 16 технологічних питань, сам стандарт став доступний громадськості в 1988 році, повний опис CMM як сукупності процесів і практик, відповідних кожному рівню було випущено в 1991 році, в 1995 він був випущений у книжковому варіанті . Пізніше CMM було доопрацьовано до набору методологій удосконалення процесів в організаціях: Capability Maturity Model Integration (CMMI), остання (станом на кінець 2014 року) версія CMMI-DEV, V1.3. вийшла в 2010 році, далі перераховані процесні області яким приділяється увага в даному стандарті:

Аналіз причин та вирішення (CAR)
Конфігураційний менеджмент (CM)
Аналіз рішень та дозвіл (DAR)
Менеджмент інтеграції проектів (IPM)
Вимірювання та аналіз (MA)
Опис процесів організації (OPD)
Фокусування на процесах організації (OPF)
Управління ефективністю діяльності (OPM)
Продуктивний організаційний процес (OPP)
Організаційний тренінг (OT)
Інтеграція продукту (PI)
Моніторинг та контроль проекту (PMC)
Планування проекту (ПП)
Забезпечення якості продуктів та процесів (PPQA)
Кількісний менеджмент проекту (QPM)
Розробка вимог (RD)
Менеджмент вимог (REQM)
Менеджмент ризиків (RSKM)
Менеджмент договорів із постачальниками (SAM)
Розробка технічного рішення (TS)
Валідація (VAL)
Верифікація (VER)

У 1989 році "Центральне комп'ютерне та комунікаційне агентство" Великобританії (CCTA), пізніше перейменоване в "Управління державної торгівлі" (OGC), створює структуровану систему управління проектами PRINCE (PRojects IN Controlled Environments) на основі методу управління проектами PROMPT розробленого "Simpact Systems » у 1975 році і схваленим CCTA, як стандарт для всіх державних проектів інформаційних систем у Великій Британії. Після появи PRINCE ефективно замінив PROMPT. Пізніше, в 1996 році, було опубліковано оновлену версію методології PRINCE2, чому сприяв консорціум, що складається в цілому з близько 150 Європейських організацій.

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

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

Тривале бізнес-обґрунтування
Вчитися на досвіді
Розподіл ролей та обов'язків
Поетапне керування
Управління з відхилень
Фокусування на продукті
Адаптація до особливостей проекту

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

Економічне обгрунтування
Організація
Якість
Плани
Ризики
Зміни
Прогрес

Модель процесів складається з комплексу заходів, яких варто дотримуватись для спрямування, управління та завершення проекту:

Запуск проекту
Управління проектом
Ініціація проекту
Управління межами стадій
Контроль стадій
Управління постачанням продукту
Закриття проекту

У лютому 1999 року, міжнародна асоціація управління проектами «International Project Management Association» (IPMA), заснована 1965 року, як некомерційна професійна асоціація, покликана об'єднати фахівців у сфері управління проектами, публікує стандарт управління проектами «IPMA Competence Baseline» (ICB) . У цьому стандарті містяться вимоги до компетенцій, які пред'являються менеджерам проектів та членам команд з управління проектами, програмами та портфелями.

У Росії IPMA з'явилася в 1990 році як СОВНЕТ. На даний момент асоціація займається навчанням професійного управління проектами, акредитацією навчальних програм з управління проектами та міжнародною сертифікацією фахівців на основі власної чотириступеневої системи:

А – сертифікований директор проектів;
B – сертифікований старший менеджер проектів;
C – сертифікований менеджер проектів;
D – сертифікований спеціаліст з управління проектами.

Національні представництва асоціації, на основі ICB, розробляють власні вимоги до компетентності, в яких мають знайти відображення національні та культурні відмінності, дотримуючись цієї логіки, СУВНЕТ опублікував стандарт: «Основи професійних знань та Національні вимоги до компетентності фахівців з управління проектами» (НТК), остання редакція від 2010 року.

НТК розглядає системну модель управління проектами, що складається з трьох основних компонентів:

1. Об'єкти управління – проекти, програми та портфелі;
2. Суб'єкти управління – інвестор, замовник, команда, керівник та інші зацікавлені особи.
3. Процеси управління – розглядаються як сукупність завдань та процедур управління та представлені у розрізах: стадій процесу управління, функціональної області управління, тимчасовому інтервалу, об'єкту та суб'єкту управління. У НТК розрізняються такі стадії процесу управління:

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

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

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

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

У 1996 році інститутом управління проектами США (Project Management Institute, Inc., скорочено PMI), публікується керівництво A Guide to the Project Management Body of Knowledge (PMBOK Guide), в якій описується стандарт управління проектами PMBOK. Даний стандарт сумісний з міжнародним стандартом управління проектами ISO 9000. PMBOK поєднує в собі великий набір знань та практик у галузі управління проектами, а також цілими програмами та портфелями проектів. У ньому приділяється увага життєвому циклу проекту, впливу організації, зокрема її внутрішньої культури, управління проектом.

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

Група процесів управління проектами
Група процесів ініціації (2 процеси)
Група процесів планування (20 процесів)
Група процесів виконання (8 процесів)
Група процесів моніторингу та управління (10 процесів)
Група процесів завершення (2 процеси)

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

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

Взаємодія процесів управління показана в додатку А, слід зазначити, що згідно з дослідженням, проведеним доктором філософії С. Гашиком, процеси PMBOK на 95 відсотків аналогічні описаним у міжнародному стандарті з управління проектами ISO 21500.
У листопаді 2001 року Центр сертифікації фахівців з управління проектами (Project Management Professionals Certification Center, скорочено PMCC) Японії, пізніше перейменований на Асоціацію управління проектами Японії (Project Management Association of Japan, скорочено PMAJ) публікує стандарт управління проектами P2M. У контексті методології розглядаються управлінці, покликані для досягнення місії проекту, які повинні мати знання з суміжних областей і діляться на три рівні професіоналізму:

менеджер-спеціаліст (PMS),
менеджер-зареєстрований (PMR) та
менеджер-архітектор (PMA).

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

Стратегічне управління проектом
Управління фінансами проекту
Управління системами проектами
Організаційний менеджмент проекту
Управління цілями проекту
Управління ресурсами проекту
Управління ризиками
Інформаційний менеджмент
Управління взаємозв'язками проекту
Управління вартістю проекту
Управління комунікаціями у проекті

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

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

CMMI – Software Engineering Institute (США)
PRINCE – Central Computer and Telecommunications Agency (Велика Британія)
ICB – International Project Management Association (Швейцарія)
НТК - СУВНЕТ (національне представництво IPMA в Росії)
PMBOK – Project Management Institute (США)
ISO 21500 – International Organization for Standardization
P2M – Project Management Association of Japan (Японія)

Список літератури

1. Crosby P.B., Quality is Free. New York: New American Library, 1979 - ISBN 0-451-62247-2
2. Humphrey W.S., Characterizing the Software Process. A maturity Framework [Електронний ресурс] / Software Engineering Institute, 1987 – Режим доступу: www.sei.cmu.edu/reports/87tr011.pdf
3. Paulk M.C., Capability Maturity Model: Guidelines для Improving the Software Process. Mass.: Addison-Wesley Pub. Co., 1995 - ISBN 0-201-54664-7
4. CMMI® for Development, Version 1.3 [Електронний ресурс] / Software Engineering Institute, 2010 – Режим доступу: www.sei.cmu.edu/reports/10tr033.pdf (дата звернення: 03.11.2014).
5. What is PRINCE2? [Електронний ресурс] / Office of Government Commerce, UK – Режим доступу: www.prince2.com/what-is-prince2 (дата звернення: 03.11.2014).
6. Міждержавний стандарт ДСТУ ISO 21500. Посібник з управління проектами, 2012
7. PRINCE2® в одному слові [Електронний ресурс] / Andy Murray and Director of Outperform UK Ltd, 2009 – Режим доступу: www.best-management-practice.com/gempdf/PRINCE2_in_One_Thousand_Words.pdf (дата звернено1.1) .
8. ICB – IPMA Competence Baseline, Version 3.0 [Електронний ресурс] / International Project Management Association, 2006 – Режим доступу: (дата звернення: 03.11.2014).
9. Сооляте А.Ю., Управління проектами в компанії: методологія, технології, практика. М: МФПУ «Синергія», 2012
10. Certify Individuals [Електронний ресурс] / International Project Management Association – Режим доступу: ipma.ch/certification/certify-individuals (дата звернення: 03.11.2014).
11. Управління проектами. Основи професійних знань, Національні вимоги до компетентності спеціалістів / за науковою ред. д.т.н. Воропаєва В.І., М: ЗАТ «Проектна ПРАКТИКА», 2010
12. A Guide до проекту управління body of knowledge / PMI Standards Committee. USA: Project Management Institute, 1996
13. Посібник зі зведення знань з управління проектами (Керівництво PMBOK®) - четверте видання / PMI Standards Committee. USA: Project Management Institute, 2008 - ISBN: 978-1-933890-51-7
14. Gasik S., PhD, Comparison of ISO 21500 та PMBOK®. Guide Version затримано після коментарів Jesus Guardiola і Francesca Montanari [Інтернет джерело] – Режим доступу: www.sybena.pl/dokumenty/ISO-21500-and-PMBoK-Guide.pdf (дата звернення: 03.11.2014).
15. Guidebook of Project & Program Management for Enterprise Innovation [Інтернет джерело] / Project Management Association of Japan, Revision 3, 2005 – Режим доступу: Додати теги

В армії існує приказка: «хоч і потворно, зате одноманітно».

Навіщо потрібна одноманітність чи стандартність?

Спрощення розуміння у взаємодії.

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

Так само стандарти в управлінні проектами, допомагають керівникам проектів з усього світу розуміти один одного

Кращі практики.

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

За допомогою стандартів ми можемо передавати найкращі практики управління проектами між людьми. Наприклад, компанія Дюпон створила метод критичного шляху. Цей метод став стандартами в управлінні проектами і ним почали користуватися все навколо.

Систематизація знань.

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

Зараз ми познайомимося з основними стандартами, що існують на сьогоднішній день, в управлінні проектами.

ISO 21500 – розроблене міжнародним проектним співтовариством у 2012 році керівництво з управління проектами.

ГОСТ Р 54869-2011 - російський стандарт з управління проектами. Було введено в експлуатацію 1 вересня 2012 року. У стандарті відображені основні етапи роботи з проектами.

PMBOK – розроблений PMI (найбільша у світі некомерційна асоціація професійних керівників проектів) зведення правил та законів з управління проектами. Застосовується у більшості країн світу.

C-PMBOK - Китайська версія PMBOK.

P2M – японський стандарт, який в першу чергу фокусується на управлінні програмами (про те, що таке програма, ви можете прочитати у статті «Терміни управління проектами. Проект, програма, портфель…».) Мета цього стандарту – це реалізація складних інноваційних ідей та інтеграція цих ідей із підприємством.

М-Modell – розроблений Німеччина та США у 1979 році стандарт, який насамперед використовується для створення програмного забезпечення.

ICB (International Competence Baseline) IPMA – стандарт, що поєднує кілька європейських стандартів. Цей стандарт включає 28 основних областей знань в управлінні проектами і 14 додаткових. Добре визначає компетенції менеджерів проектів. Використовується у Євросоюзі, Індії, Україні, Казахстані, Азербайджані.

Hermes – швейцарський стандарт управління проектами, що в основному застосовується в ІТ.

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

APMBOK – національний стандарт Великобританії, що охоплює 52 необхідні ведення проекту.

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

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

Найбільшого поширення набула процесна модель, яка використовується в таких найбільш відомих документах, що викладають методологічні основи управління проектами, як Project Management Body of Knowledge (PMBOK) Американського інституту управління проектами (PMI), багатьма визнаний міжнародним стандартом де-факто, та стандарт ISO 10006 :1997, що надав ряду найважливіших положень РМВОК статусу стандарту де-юре. Замінив перший РМВОК редакції 1987 A Guide to the Project Management Body of Knowledge (PMBOK Guide) редакції 1996 визнаний національним стандартом США ANSI/PMI 99-001-2000.

В даний час швидко зростає інтерес до використання інших підходів, зокрема, «діяльнісного» або «менеджерського», який прийнятий як офіційний базовий більш ніж у 30 країнах світу. Цей підхід виражений у міжнародних кваліфікаційних стандартах ICB IPMA-International Competence Baseline IPMA, а професійні національні асоціації майже 20 країн вже мають свої РМ Body of Knowledge (РМ ГК), основою для яких є саме цей міжнародний стандарт.

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

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

Незважаючи на те, що більш ніж у 20 країнах існують свої національні системи сертифікації, найбільшого поширення в міжнародній практиці набули 4-рівнева система міжнародної сертифікації, що підтримується IPMA (РМР IPMA), і однорівнева національна система США, що підтримується PMI (РМР PMI). Відмінності в них пов'язані як з умовами розвитку «європейського» і «американського» підходів, що історично склалися, в управлінні проектами, так і з відмінностями в базових моделях проектної діяльності. Нині одним із базових напрямів у міжнародній кооперації є формування одноманітних підходів до уніфікації знань та стандартизації проектної діяльності, робляться спроби щодо формування єдиних глосаріїв та систем вимог та ін.

РМ-Project Management;

IPMA – International Project Management Association;

PMI-Project Management Institute (США);

AIPM- Australian Institute for Project Management (Австралія);

АРМ-Association for Project Managers (Великобританія);

COBHET – Асоціація управління проектами (Росія);

ENAA- Engineering Advancement Association of Japan (Японія);

GPM-Deutsche Gesellschaft f?r Projektmanagement;

ICB IPMA – International Competence Baseline IPMA;

NCB-National Competence Baseline;

РМ В К - Project Management Body of Knowledge,

PMBOK - Project Management Body of Knowledge PMI (США).

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

що можна і потрібно стандартизувати у РМ, що недоцільно чи неможливо стандартизувати і чому;

різні підходи до стандартизації змісту, процесів та методів РМ, що використовуються у міжнародних та національних стандартах;

уніфікація управлінської діяльності менеджерів проектів за допомогою використання професійних кваліфікаційних стандартів (вимог) та сертифікації;

міжнародні та національні стандарти з РМ;

корпоративні стандарти;

області застосування стандартів.

Базові поняття

«Project Management» - різні трактування

У світовій практиці поняття Project Management трактується неоднозначно в залежності від обраної моделі, підходу до структури знань (Body of Knowledge), типу та виду проектів та інших факторів. Переклади самого терміну Project Management на російську мову також дуже різноманітні: управління проектом (проектами), проектний менеджмент (проект-менеджмент), менеджмент проекту (проектів), проект (проект) менеджмент. Часто неоднозначний також і зміст, що вкладається в поняття «менеджмент проектів» та «управління проектами».

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

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

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

Про різні трактування поняття «проект»

Поняття «проект» у різних моделях та стандартах трактується з різних позицій. Наприклад, у процесній моделі (ШО 9000, 10006) проект сприймається як процес. А в рамках «менеджерської» (організаційно-діяльнісної) моделі (ІСВ ІРМА) «проект» як поняття визначається через «підприємство», «зусилля» та «діяльність».

Таблиця 1.1. Деякі визначення терміна «проект»

Проект - це:

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

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

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

ICB-IPMA Competence Baseline. Version 2.0.

IPMA Editorial Committee. - Bremen: Eigenverlag, 1999 - p.23.

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

ISO/TR 10006: 1997 (Е). Quality Management- Guidelines to quality in project management-p. 1.

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

Guide to the Project Management Body of Knowledge. PMI Standards Committee. 2000 Edition., 2000 - p.4.

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

AIPM - Australian Institute for Project Management, National Competence Standard for Project Management - Guidelines 1996 - p. 18.

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

British Standard BS 6079-1:2000. Project management- Part 1: Guide to Project management - p.2.

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

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

Предмети стандартизації в РМ

Відмінності у визначеннях і трактування таких ключових понять, як «проект», Project Management, «контекст проекту» тощо, відіграють істотну роль і при стандартизації в галузі РМ. У зв'язку з цим доцільно поділити елементи РМ на:

а) ті, які можна описати як процесів, об'єктів, методів;

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

Таблиця 1.2. Деякі визначення стандартизації

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

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

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

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

для міжнародних та національних стандартів за РМ як об'єкти вибираються, як правило, глосарії, процеси та методи;

для тих областей РМ, опис яких як об'єктів для стандартизації недоцільно чи неможливо, використовуються професійні кваліфікаційні стандарти (вимоги) до діяльності фахівців з РМ (Project Management Professional) і менеджерів проектів (Project Manager).

Міжнародні та національні стандарти в галузі РМ

Міжнародні стандарти

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

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

Окремі питання регулюються міжнародними стандартами. Наприклад, основними міжнародними стандартами з менеджменту якості та конфігурацією в проектах є ISO 9000:2000, 10005, 10006, 10007 та інші (див. табл. 1.3), які прийняті у низці країн та у вигляді національних стандартів.

У сфері управління системами використовується низка міжнародних стандартів, підтримуваних відповідними міжнародними організаціями. Ці стандарти визначають норми та правила щодо управління процесами в проектах технічних систем, процесами життєвого циклу системи, процесами проектування тощо, наприклад ISO/IEC 12207, Information Technology - Software life cycle processes (1995); ISO/IEC TR 15271, Інформаційна технологія - Guide for ISO/IEC 12207(1998); ISO/IEC 15288 CD2, Life Cycle Management - System Life Cycle Processes (2000) та ін.

Національні стандарти

Крім міжнародних нормативних документів та стандартів у ряді країн розроблено та використовуються національні системи стандартів та вимог. Вони мають приватний характері і регламентують окремі аспекти РМ. Таблиця 1.3. Міжнародні стандарти в галузі РМ ISO 10006:1997 Quality management - Guidelines to quality in project management ISO 10007:1995 Quality Management - Guidelines for configuration management ISO 9000:2000 Quality Management Systems - Fundamentals and Vocabulary ISO 900 performance improvements ISO 15188:2001 Project management guidelines for terminology standardization ISO 15288:2000 Life Cycle Management - System Life Cycle Processes ISO/AWI 22799 Building construction - Process management - Guidelines for project management systems IS О/I EC TR 16326:1999 Software engineering - Однією з найбільш представницьких, історично сформованих і комплексних національних систем стандартів є британські національні стандарти з РМ. Їхня ретроспектива дає гарний приклад для розуміння підходів до побудови та розвитку національної системи стандартів за РМ (див. рис. 1.4).

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

У 1984 році до складу комплексу стандартів вводиться Посібник із використання процедур управління, планування, контролю та звітності. Перші три стандарти, введені у 1981 році, є частинами 2,

3 і 4, а останній - частиною 1, тобто стандарти, що визначають застосування СПУ в управлінні проектів, з'явилися істотно раніше, ніж спочатку передбачений як основний стандарт, що визначає процедури РМ.

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

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

«Друга черга» британських стандартів за РМ було запроваджено 1992 року і було оновленням перших трьох стандартів 1981 року.

У 2000 році було введено перші три стандарти принципово нового комплексу стандартів з РМ. На малюнку 1.4 стрілками показані зв'язки, що визначають взаємовідносини спадкоємності історичних та чинних стандартів. Суцільними лініями зі стрілками позначені відносини безумовного безпосереднього попередження (наведені у тексті стандартів), а пунктирними лініями зі стрілками –? відносини умовного попередження, що відбивають відповідність предметних аспектів РМ, визначених історичними та актуальними стандартами.

Професійні міжнародні та національні кваліфікаційні стандарти для менеджерів проектів та/або фахівців з РМ

Професійна компетентність

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

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

На малюнку 1.5 представлені компоненти професійної спроможності фахівців з PM (Project Management Professional) та менеджерів проектів (Project Manager), які нормуються через стандарти та/або через кваліфікаційні вимоги.

Професійна компетентність визначається за допомогою сертифікаційних випробувань (сертифікації) та у різних країнах проводиться по-різному. Наприклад, міжнародна сертифікація IPMA передбачає чотири рівні компетентності та проводиться уповноваженими IPMA асесорами. Сама процедура триває від 1 до 3 днів залежно від рівня домагань кандидата та передбачає обов'язкову особисту участь кандидата. Так само вибудовуються системи сертифікації у країнах, які прийняли як базовий стандарт IPMA. Австралійський AIPM передбачає 7 рівнів компетентності.

Ності та оцінка проводиться в кілька етапів. Американський PMI передбачає один рівень компетентності, а іспит проводиться протягом кількох годин одного дня. З 2000 року сертифікаційні випробування проводяться без особистої присутності кандидата через «дистанційну» складання іспитів через Інтернет в уповноваженій організації. Для допуску до іспиту треба пройти відбір на основі відправлених раніше документів, головний критерій відбору - наявність достатнього досвіду професійної діяльності з РМ.

Слід зазначити, що жодна із систем сертифікаційних випробувань не вільна від недоліків. Однак головна відмінність все-таки в концептуальних підходах до проекту: при переважанні процесного підходу найбільш адекватна модель PMI, при верхівці системного підходу найбільш адекватна модель AIPM, а якщо в основу покладено «менеджерський» підхід, то доцільно використання моделей IPMA, АРМ UK, GPM та ін.

Щорічно IPMA видає збірку «Сертифікація IPMA», в якій інформує про стан сертифікації, останні зміни, наводить списки всіх сертифікованих менеджерів проектів з міжнародних та національних стандартів, офіційних міжнародних та національних асесорів тощо.

Склепіння (бази, «тіла») знань (Body of Knowledge)

Вимоги до знань визначаються Зводами (базами, системами, «тілами») знань – Body of Knowledge. Вони визначають систему вимог до знань, досвіду, майстерності менеджерів проектів та/або фахівців з РМ.

Зведення знань підтримуються та розвиваються міжнародними та/або національними професійними асоціаціями. В даний час професійні асоціації більш ніж 20 країн мають офіційні національні Body of Knowledge on Project Management (PM BoK) та національні системи сертифікації. Ці Зводи знань представлені у вигляді Національних систем вимог до професійної компетентності та/або національних стандартів з питань РМ.

У РМ міжнародним нормативним документом, визначальним систему міжнародних вимог до компетентності менеджерів проектів, є ICB ТРМА (див. табл. 1.4).

На його основі проводиться розробка національних систем вимог до компетентності спеціалістів у країнах, які! ic є членами IPMA. Національні системи вимог повинні відповідати ICB-IPMA та бути офіційно затверджені (ратифіковані) відповідними уповноваженими органами IPMA.

Ряд країн, що не входять до IP MA, мають свої Зводи знань та системи сертифікації. Наприклад, північноамериканський PMI, австралійський AIPM, японська ENAA та ін.

Таблиця 1.4. Кваліфікаційні стандарти з управління проектами

Професійні міжнародні кваліфікаційні стандарти Базовий стандарт IPMA

ICB-IPMA Competence Baseline, Version 2.0, IPMA Editorial Committee: Cajupin G>, Knopfel H., MOOTS P., Motzel E., Pannenbacker O. - Bremen: Eigenverlag, 1999. - p,112.

Системи національної сертифікації менеджерів проектів та/або спеціалістів з управління проектами та професійні національні кваліфікаційні стандарти

Великобританія – АРМ

Body of Knowledge. Fourth Edition - UK: АРМ - Association for Project Managers. - Edited by Miles Dixon - Cambridge Publishing Management, England, 2000. - p.64,

Guide to the Project Management Body of Knowledge (PMBOK Guide), 2000 Ed, Network Square, PA: Project Management Institute.

Австралія - AIPM

Competence Standart, Level 4/5/6, AIPM Australian Institute for Project Management, 1996.

Німеччина - GPM

ZERT, Zertifizierungsstelle der GPM Deutsche Gesellschaft fur Projektmanagement e.V.: Projekt- management-Kanon - Der deutsche Zugang zum Project Management Body of Knowledge, Koln, FRG, 1998).

Росія - ЗОВНІШЕ

Управління проектами. Основи професійних знань. Національні вимоги до компетентності (НТК) спеціалістів// Сертифікаційна комісія СОВНЕТ. М.: КУБС, 2001. 265 с.

У таблиці 1.4 наведено РМ Body of Knowledge деяких національних асоціацій та інститутів, які використовуються при сертифікації менеджерів проектів у різних країнах.

Міжнародне Звід знань - ICB IPMA

International Competence Baseline (ICB) є офіційним міжнародним Зведенням знань у галузі РМ, яке підтримується та розвивається IPMA. Для 32 країн світу - членів IPMA основою для розробки національних Зведень знань у галузі РМ є 1C В. В даний час 16 країн світу мають затверджені національні Зводи знань відповідно до ICB.

ICB визначає галузі кваліфікації та компетентності в РМ, а також принципи таксономії для оцінки кандидата на отримання сертифікату.

1C містить 42 елементи, що визначають області вимог до знань, професіоналізму (майстерності) і професійного досвіду в менеджменті проектів (28 основних і 14 додаткових).

ICB видано англійською, німецькою та французькою мовами. Як основу розробки ICB були використані такі національні розробки:

Body of Knowledge of АРМ (Велика Британія);

Beurteilungsstruktur, VZPM (Швейцарія);

PM-Kanon, РМ-ZERT/GPM (Німеччина);

Criteres d'analyse, AFITEP (Франція).

Кожна національна Асоціація, яка є членом IPMA, відповідальна за розробку та затвердження її власних Національних вимог щодо компетентності (National Competence Baseline, NCB) з посиланням на ICB та відповідно до них, а також з урахуванням національних особливостей та культури. Національні вимоги оцінюються на відповідність ICB та основним критеріям сертифікації відповідно до стандарту EN 45013. Далі вони затверджуються валідаційним комітетом ІР МЛ.

Національні Зводи знань - NCB

ICB є основою для розробки та використання як національних систем вимог та стандартів національних Зводів знань (National Competence Baseline, NCB) у країнах, що є членами IPMA. Однак у ряді країн, що не є членами IP MA, є свої національні Зведення знань та процедури сертифікації, зокрема, у США, Австралії, Південній Кореї та деяких інших країнах.

З національних стандартів найпоширенішим документом у галузі РМ, що використовується фахівцями багатьох країн, є РМВОК PMI Guide. З 1999 року РМВОК PMI є національним стандартом США, як «глосарій термінів та скорочень» у галузі РМ. Третя редакція "РМВОК" Guide 2000 Ed. (попередні видання - 1987 та 1996 роки) підтверджена як стандарт ANSI у березні 2001 року.

Популярність РМВОК PMI пояснюється простотою представлення частини знань РМ у процесному вигляді та активною політикою PMI щодо поширення цього підходу за межами США. Багато фахівців використовують цей стандарт як основу своєї діяльності і тому щиро вважають його де-факто міжнародним.

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

Корпоративні стандарти та норми

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

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

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

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

Застосовність стандартів практично

В рамках моделі сучасного РМ досить точно можна визначити області застосування різного виду стандартів. Зокрема, для різних компонентів сучасного РМ можна використовувати стандарти, наведені в табл. 1.5.

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

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

Таблиця 1.5. Області застосування стандартів управління проектами Компоненти змісту РМ Стандарти, що їх визначають Стратегічний РМ Основні: ISO 10006, ICB IPMA, РМ ВОК UK Ed.4 Додаткові: ISO 10007 Інструментальний РМ Основні: ISO 10006, ICB IPMA, РМ Вок UK Ed.4 Додаткові BS ххх, DIN ххх Операційний РМ Основні: ISO 10006, ICB IPMA, PMBOK PMI,

РМ ВОК UK Ed.4, НТК COBHET, BS ххх, DIN ххх

Додаткові: ISO 9004:2000, ISO 15288:2000, ISO/IEC TR 15504 SPICE, ISO 12207 Технічний РМ ISO 15188:2001, ISO 15288:2000, ISO/AWI 22796, ISO/9 15504 SPICE, ISO 12207 та ін. нованих рішень та некваліфікованої роботи. Зрештою додаткові витрати на розробку, впровадження та використання корпоративних стандартів з РМ компенсуються економією часу, зниженням ризиків, кращою координацією діяльності учасників тощо.

В даний час глобалізація стандартизації в галузі РМ розвивається у напрямку:

уніфікації вимог до РМ компетентності менеджерів та спеціалістів;

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

Висновки у розділі 1.

У РМ слід розрізняти те, що можна стандартизувати і що недоцільно або неможливо стандартизувати. 2.

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

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

Стандарти управління проектами компаній у частині методології зазвичай мають основу, яка визначається документами загального характеру, які називають рамковими. До таких документів відноситься Project Management Body of Knowledge Американського інституту управління проектами, що визнаний багатьма міжнародним стандартом де-факто, і стандарт 1БО 10006:1997, зміст і зміст яких полягає в їх спеціалізаціїі деталізації.

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

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

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

Класифікація проектів як перший етап створення стандарту

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

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

Стадії життєвого циклу проекту

Час, Вартість Кдяєство | Ризики ферсонал Комунікації Контракти Зміни

Ж Функції керування

I сі іа їх

Ініціалізації) Планування Виконання Контроль Закриття

Фази керування

Мал. 4.23.Простір процесів управління

Джерело: Товб О.С. Ципес Г.Л. Стандарт управління проектами рівня підприємства // Директор інформаційної служби. 2002. № 1-6.

У плані управління проектом відображено:

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

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

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

Класифікація за формою оплати та обліку робітдозволяє спеціалізувати: «Контроль та звітність», «Управління проектною документацією» на підставі таких форм контрактів як «Час та матеріали» та «Фіксована ціна». Таким чином, можна вести мову, наприклад, про шаблон «План управління проектом створення концепції (продукт) інформаційної системи (предметна область) вартістю понад 100 тис. дол, (масштабність) з контрактом у формі “час та матеріали” (форма оплати та обліку робіт)», як про макрошаблону, одержуваного простим складанням з кількох дрібніших (мікро) шаблонів окремих розділів плану.

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

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

Таблиця 4.18

Спеціалізований мікрошаблон «Зміст та межі проекту створення ІТ-інфраструктури філії банку»

Пункт мікро	філії банку
Обґрунтування проекту (Project justification)	Описуються основні характеристики продукту та їх взаємозв'язок з діловою необхідністю чи іншими стимулами	У всіх філіях повинна бути встановлена уніфікована, надійна, гнучка і легко нарощувана ІТ-інфраструктура на основі платформи, що дозволяє використовувати як основний засіб обробки бізнес-транзакцій прикладне програмне забезпечення
Продукт проекту (Project product)	Основні характеристики продукту та їх взаємозв'язок із діловою необхідністю	Доставити, встановити та налаштувати обладнання та системне програмне забезпечення до новоствореної філії банку, що формує основу для подальшого впровадження банківської інформаційної системи
Результати проекту (Project deliverables)	Наводиться перелік результатів (підпродуктів), досягнення (повне та успішне створення) яких означає завершення проекту	Специфікації системного програмного забезпечення та його конфігурація. Вимоги до приміщення для встановлення обладнання. Перелік обладнання та програмного забезпечення. План технічного розв'язання. Еталонні копії встановлення та конфігурації системного програмного забезпечення. Обладнання та системне програмне забезпечення, доставлене до філії банку, встановлене та підготовлене для встановлення банківської інформаційної системи
Критерії оцінки результатів (Project objectives) 1	Опис кількісних критеріїв, які мають бути задоволені, щоб проект вважався успішним	Термін доставки обладнання та програмного забезпечення до Москви не повинен перевищувати XX днів. Термін налагодження обладнання та програмного забезпечення в Москві не повинен перевищувати УУ днів. Термін транспортування обладнання та програмного забезпечення до філії банку не повинен перевищувати ЪЪднів. Термін встановлення та налагодження обладнання та програмного забезпечення у філії не повинен перевищувати УУ днів

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

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

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

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

Функціональний

замовник

	Проект П1	Проект П2	Проект ПЗ

Інвестор

Договір Д1

Виконавці

----Декомпозиція за змістовною ознакою
-Декомпозиція за формальною ознакою (фінансові потоки)

Мал. 4.24.Декомпозиція робіт з різних підстав Джерело:

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

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

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

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

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

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

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

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

1) управління ризиками.Неприємності ще не настали, але існує можливість виникнення небажаних та незапланованих подій, які можуть призвести до того, що мети проекту не буде досягнуто. Мета цієї стадії- запобігти неприємностям до їх виникнення;
2) керування проблемами.Неприємності настали і необхідно з'ясувати їхнє походження, ступінь впливу на проект, способи подолання. Мета цієї стадії -забезпечити проекту можливість йти так, як заплановано;
3) управління змінами.Неприємності виявилися серйозними і впоратися з ними без шкоди для проекту не вдалося. Мета цього етапу(те, що з фінансистів називається «зафіксувати збитки») - модифікація раніше узгоджених товарів та послуг, термінів виконання та вартості робіт, управлінських і технологічних процесів.

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

Мал. 4.25.

Джерело: Товб О.С. Ципес Г.Л. Указ. тв.

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

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

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

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

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

Таблиця 4.19

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

^"""-"----^Ймовірність події Вплив на проект	Низька (менше 20%)	Середня (від 20 до 60%)	Висока (понад 60%)
Слабке.Можлива поява питань чи проблем у проекті, але це навряд чи призведе до порушення календарного графіка, бюджету чи погіршення якості продукту.
Середнє.Можливе порушення графіка, збільшення вартості або погіршення якості продукту
Сильне.Можливе значне порушення графіка, збільшення вартості чи погіршення якості продукту

Джерело".Товб О.С. Ципес Г.Л. Указ. тв.

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

Управління проблемами.Під проблемою в проекті розуміється будь-яке функціональне, технічне або пов'язане з бізнесом питання, яке виникло в процесі здійснення проекту і вимагає реакції - вивчення та рішення для того, щоб проект міг йти так, як заплановано. Іншими словами, проблема – це виняткові обставини, які мають бути під контролем з моменту їх виникнення. Зазвичай проблеми ділять на дві категорії: 1) проблеми, які можна вирішити у місці виникнення, тобто. на рівні управління проектом (problems); 2) ескалируемые проблеми (issues), які їх вирішення потрібно підняти на верхні рівні управління, зокрема зовнішні стосовно проекту.

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

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

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

Матриця пріоритетів вирішення проблем

Таблиця 4.20

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

Джерело

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

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

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

Область неприпустимих втрат

А Ресурси

Продукти

Мал. 4.26. Області втрат Джерело:Товб А., Ципес Р. Указ. тв.

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

Мал. 4.27.

Джерело: Товб А., Ципес Г. Указ. тв.

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

Організаційні структури у проектах

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

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

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

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

Команда проекту.При формуванні організаційних структур проектів повинні дотримуватися двох основних принципів: 1) поділ рівнів відповідальності; 2) поділ областей ответственности. У цьому сенсі рішення безпосередньо пов'язані з комплексністю та складністю проектів. Для простих проектів зазвичай досить двох рівнів управління. Керівник проекту здійснює оперативне управління ходом проекту, забезпечує виконання запланованих робіт, готує пропозиції щодо змін у планах, координує технічні та людські ресурси. Повноваження щодо зміни термінів, бюджету, змісту та меж проекту належать до верхнього рівня управління та належать вищому керівнику. Взята за основу, ця схема може розвиватися як вниз (керівники підпроектів), так і вгору (керівні комітети мультипроектів або програм).

Таблиця 4.21

Поділ відповідальності при адміністративному управлінні

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

Сфера відповіді-відповідності Область управління	Відповідальність начальника підрозділу (адміністративне управління)	Відповідальність керівника проекту (управління проектами)
Планування та контроль	Формування бізнес-плану. Планування бюджету відділу. Контроль «за віхами». Звітність перед керівництвом підприємства	Детальний календарний план проекту. Планування бюджету проекту. Оперативний контроль перебігу проекту. Звітність перед керівництвом
Людські	Прийом на роботу та звільнення. Централізоване виділення ресурсів. Контроль дисципліни. Організація навчання	Формування команди проекту. Аналіз та оцінка роботи співробітників. Застосування санкцій та заохочень. Регулювання конфліктів
Реалізовані продукти (на прикладі інформаційних систем ІВ)	Методологія створення ІВ.	Проектування ІВ. Розробка ІС. Використання ІС

Джерело: Товб А., Ципес Г. Указ. тв.

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

Включення фахівців до команди проекту Про Взаємодія команди проекту із суміжними службами

Мал. 4.28.Схема формування команди проекту Джерело: Товб А., Ципес Г. Указ. тв.

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

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

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

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

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

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

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

Управління комунікаціями Управління ризиками Управління змістом та межами Проектне планування Управління якістю Фінансове та контрактне управління Управління ресурсами Управління змінами ІНТЕГРАЛЬНА ОЦІНКА ЗА ПРОЕКТОМ 7

Мал. 4.29.Діаграма поточного статусу управління проектом Джерело: Товб А., Ципес Г. Указ. тв.

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

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

Місце служби управління якістю та служби управління проектами в організаційній структурі та їх функції показані на рис. 4.30.

Служба управління якістюу частині управління проектами забезпечує:

інтеграцію стандарту управління проектами у загальну систему стандартів компанії;
контроль якості управління проектами у вигляді проведення аудиторських перевірок для перевірки дотримання корпоративних стандартів управління проектами.

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

Мал. 4.30.

виконання проектів