Нісенітниця Проєктного Менеджменту

Статтю "Нісенітниця Проєктного Менеджменту" опубліковано 20 вересня 2005 року на сайті
Співтовариства менеджерів "E-xecutive" у розділі "Творчість без купюр".
Була визнана "Найкращою статтею тижня" за результатами голосування спільноти.

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

Нісенітниця перша (поширена)

Платформою УП є програмний продукт

Давайте звернемося до Настанова до зводу Знань з УП (PMBOK, 3-е видання, стор. 371). Там чорним по білому написано “Програмне забезпечення для управління проєктами (Project Management Software) [Інструмент] …”. І це правильно – Програмне Забезпечення(далі за текстом – ПЗ) було і завжди буде лише інструментом для будь-якої діяльності, а будувати діяльність навколо інструменту вкрай недоцільно. Фраза “побудова системи УП на основі ПЗ” звучить так само безглуздо, як і “побудова процесу копання на основі лопати”. Якщо у Вас є потреба копати, Ви спершу визначаєтесь, що Ви копатимете (траншею, котлован, колодязь чи щось іще) і які там ґрунти, а вже потім вирішуєте, чим Ви копатимете – лопатою, екскаватором, буром чи взагалі будете викликати бригаду підривників. Чому ж з ІТ-інструментами має бути навпаки, типу “впровадимо лопату, а вже потім подивимося, що ми зможемо викопати”. Або того гірше – “впровадили екскаватор, а потрібно копати лунки для гольфу”.

Якщо консультанти пропонують Вам впровадження методології УП і створення Офісу УП на основі будь-якого ПЗ, найімовірніше, вони самі виробляють це ПЗ, пов’язані зобов’язаннями з виробником цього ПЗ або мають пряму вигоду від його продажу. Насправді їх легко зрозуміти – продати ефемерне “управління проєктами” набагато складніше, ніж конкретний широко розрекламований програмний продукт. А хто ж із нас шукає важкі шляхи, тим паче під час добування грошей?

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

Нісенітниця друга (біблійна)

Про абсолютну правильність процесів, описаних у PMBOK

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

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

Нісенітниця Проєктного Менеджменту третя (проєктно-орієнтована)

Про високу ефективність впровадження УП у проєктно-орієнтованих галузях

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

Насправді, найбільший ефект впровадження системи УП приносить у початково непроектних галузях: фінанси, виробництво, дистрибуція, транспорт тощо. У цих галузях запускається зараз величезна кількість проєктів і через брак власних накатаних технік і засобів УП вони наступають на всі граблі, на які тільки можна було наступити. Накладення ж методології УП на них як на чистий аркуш дає змогу досягати найбільшу перевагу й ефект. Як сказав Дмитро Літвак в одному зі своїх інтерв’ю[1] – “операційною діяльністю ми рубаємо капусту, а проєктною – створюємо ніж для рубання, покращуємо його капусто-рубаючі властивості. І чим швидше ми отримуємо цей ніж, чим кращі його властивості, тим вищий показник капусто-віддачі”.

Нісенітниця Проєктного Менеджменту четверта (езотерична)

УП – це дорога секретна зброя для досягнення небувалих результатів

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

Насправді тут не може бути жодної секретності, оскільки одноосібне володіння цією методологією, схоже на володіння єдиним мобільним телефоном або e-mail у світі. Яка користь від них у такому разі? Уявіть, якщо замовник володіє методологією УП, а виконавець і слухом про неї нічого не чув (або навпаки). Що відбувається в цьому випадку? Правильно! Усі розмовляють різними мовами. Виходить свого роду Вавилонська вежа і різні мови. Тому в багатьох країнах створюють системи професійної освіти в галузі управління проєктами на державному рівні для створення критичної маси проєктних менеджерів у країні. Практичними прикладами створення таких систем державного навчання можуть послужити Україна і Китай.

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

Нісенітниця Проєктного Менеджменту п’ята (богатирська)

Методологію УП можуть впровадити тільки зовнішні консультанти

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

Нісенітниця Проєктного Менеджменту шоста (документальна)

Корпоративний стандарт УП – це набір шаблонів і документів

Хоч ми і називаємо це нісенітницею, треба віддати належне, що вона найближча до реальності, але все ж таки і вона вимагає невеликого “розхитування своїх основ”. Давайте звернемося до того ж РМВОК і подивимося визначення слова “документ”. Це “носій та інформація на ньому, які зазвичай мають певну стійкість до впливів…”. Так, при створенні УП без хоч трохи формалізованих процесів УП і формування набору шаблонів не обійтися. Але якщо ми формалізуємо процеси, впишемо їх у папір і покладемо припадати пилом на полицю, тим самим забезпечивши зазначену “стійкість до впливів”, то отримаємо мертвонароджене дитя. Стандарт же має жити і постійно розвиватися, а разом із ним мають розвиватися документи, що входять до нього. Навіть до Конституції вносять поправки!

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

Погляньте на технологію Microsoft Solutions Framework[2]. Білл Г. відкрив комерційну таємницю і випустив для загального огляду одну технологію зі своєї багатої методології УП. Якщо подивитися на історію розвитку цієї технології, то видно, який довгий шлях вона пройшла. А тепер давайте проведемо невеличкий експеримент: візьмемо цю документацію, змінимо логотипи і назви Microsoft на свої і опублікуємо її у себе у вигляді УП. Що в підсумку отримаємо? Не більше ніж абсолютно нічого. Просто наша технічна бібліотека поповнитися ще кількома документами.

Якщо ж поміркувати над цим експериментом, то отримуємо, що УП – це насамперед компетенція. Компетенція персоналу, який створює, використовує, змінює і впливає на УП. Компетенція, вилита на папір. Можна навіть сказати, компетенція у твердому стані.

Нісенітниця Проєктного Менеджменту сьома (паперова)

Дуже важливо бути сертифікованим фахівцем у галузі УП

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

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

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

Чути шелест нісенітниці…

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

Експерт з нісенітниць управління проєктами
Анатолій Савін
savin@pmdoc.ua

[1] CNews.ru: Аналітика (04.07.2005). Управління проєктами: філософія КІС/KISS(http://www.cnews.ru/reviews/articles/index.shtml?2005/07/04/181683)

[2] Управління проєктами: технологія MSF (Microsoft Solutions Framework). Технологія створення програмних рішень. http://www.microsoft.com/rus/msdn/msf/default.mspx