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

Цю статтю було опубліковано 26 березня 2009 року на сайті Спільноти менеджерів “E-xecutive” у рубриці “П’ятничний менеджер”.

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

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

Але весь цей час автор без діла не сидів. Навіть зробив щиру спробу написати кандидатську дисертацію з управління проєктами, але штабна робота була якоюсь мало захопливою, тому він узяв шинель і пішов на фронт. А в польових умовах управління проєктами “чомусь” має зовсім не такий вигляд, як у книжках. Тому стали виявлятися нові нісенітниці. І хоча їх було досить багато, ми зупинимося на цифрі 13, яка дуже пасує до нашого кризового часу (з 1-ї до 7-ї читайте у статті “Нісенітниця проєктного менеджменту”, що розміщена за адресою pmdoc.ua/pm-nonsense), а 14-ту і наступні залишимо для наступної статті, яка називатиметься, приміром, “Нові пригоди нісенітниць ПМ” або щось на кшталт того, і вийде вона, напевно, так само, як і ця, років за три.

Отже, продовжимо…

Нісенітниця восьма (компетентська)

Керівнику проєкту не обов’язково розбиратися у сфері застосування* проєкту, достатньо бути досвідченим і грамотним проєктним менеджером.

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

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

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

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

Нісенітниця дев’ята (часово-грошова)

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

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

Давайте знову звернемося до “біблії” проєктного менеджменту (PMBOK, 4-е видання, стор. 17) і прочитаємо там таку фразу: “Вплив стейкхолдерів проєкту, ризик і невизначеність мають найбільше значення на початку проєкту. Ці фактори зменшуються по ходу проєкту.“. І що ж виходить? Коли ми плануємо проєкт (тобто перебуваємо на початку проєкту і в повній невизначеності в досягненні його цілей) ми оцифровуємо критерії успішності проєкту (тобто заявляємо всім тривалість і вартість проєкту). А коли ми завершуємо проєкт і знаємо про нього все, ми чомусь маємо оцінювати його успішність за цифрами, отриманими в стані невизначеності?…

Отже, давайте розставляти крапки над “ї”. Дійсно, грамотний і досвідчений керівник проєкту для проєктів, що повторюються, може з точністю до 5-10% спланувати графік і бюджет проєкту і вкластися в ці терміни, гроші і похибку, реалізуючи проєкт. Але якщо результат, подібний до запланованого в новому проєкті, ніхто з учасників проєкту раніше не досягав, критерії його успішності явно лежать не в мінімальному відхиленні від запланованих терміну і бюджету. А як же тоді визначити успішний проєкт чи ні? Давайте розглянемо два приклади:

1. Команда проєкту на чолі з керівником проєкту вдвічі перевищила строки і вчетверо бюджет, і зробила трохи не те, що планували спочатку. Ба більше, постійно відстежуючи потреби ринку і спілкуючись з усіма стейкхолдерами проєкту, вони внесли в проєкт стільки змін, що розуму не осягнути! Але чомусь усі задоволені результатом – у всіх учасників від ейфорії паморочиться в голові, Замовник тисне всім руки, висловлює окрему подяку керівнику проєкту за хорошу роботу…
2. Плануючи проєкт, усі стейкхолдери домовляються, що необхідно зробити саме ЦЕ, у ТАКІ терміни, за СТІЛЬКИ грошей. Усі розуміють, що тільки в такому разі результат проєкту “принесе всім щастя”, тому вписують ЦЕ, ТАКІ та СТІЛЬКИ в папір, ламінують і радіючи вивішують у кожного в кабінеті. Керівник проєкту “жене коней”, відкидає будь-які зміни в проєкті, оскільки вони спричиняють зміну бюджету і термінів (водночас усі учасники з ним погоджуються), і вкладається в заламіновані ТАКІ терміни і СТІЛЬКИ грошей із мінімальним відхиленням: -1% за термінами і +1% за грошима. Але під кінець Замовник не знає кому і як впарити ЦЕ, оскільки самому вже ЦЕ давно не потрібно. Керівник проєкту, який уже встиг вписати в резюме завідомо успішний проєкт, скромно стирає його кнопочкою Backspace. Команда на преміальні вже давно не розраховує…

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

Нісенітниця десята (замовникова)

Роль Замовника в проєкті виняткова і непохитна.

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

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

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

1. Замовник абсолютно точно розумів поточний стан проєкту (тобто забезпечити прозорість проєкту);
2. при бажанні або потребі Замовника вносити якісь зміни в перебіг проєкту, він абсолютно точно бачив, як це вплине на терміни, бюджет і результати проєкту;
3. рішення за проєктом надходили Замовнику в готовому вигляді зі зрозумілим обґрунтуванням, і йому залишалося тільки вибрати (якщо мається на увазі вибір із кількох варіантів) або просто підписати;
4. Замовник був глибоко залучений у процес реалізації проєкту в ролі консультанта, і керівник проєкту отримував від нього найцінніші відомості з перших рук.

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

Нісенітниця одинадцята (хеадхантерська)

Керівників проєктів не вистачає на всі проєкти.

Це найпоширеніша нісенітниця 2007-2008 років. Сьогодні її продовжують поширювати, але з прикметником, мовляв “досвідчених”, “грамотних”, “професійних” тощо керівників проєктів не вистачає…

Міф про брак проєктних менеджерів вигадали і поширюють HeadHunter-и та HR-и. Хоча вони це зробили не зі зла, і навіть не з користі – їм допомогли ті, хто раптом зрозумів, що їм терміново потрібні керівники проєктів, до того ж одразу навчені досвідом, сертифіковані та за невеликі гроші. А оскільки така потреба виникла якось одразу, а ще й по всьому світу – ось на світ і з’явилася чергова нісенітниця. Але все таки гарний час – “криза”. Вона майже вбила цю нісенітницю, а ми доб’ємо! Ви справді хочете собі в проєкт одразу гуру затягнути? Тоді розраховуйте щомісячну винагороду цієї людини – як 0,1-0,5% від повного бюджету проєкту. Ба більше, не розраховуйте на цю людину більш ніж на один-два проєкти. Навіть якщо Ви готові будете оплачувати її постійно зростаючу вартість, їй уже буде не цікаво у Ваших проєктах і її ККД різко впаде.

Викриття цієї нісенітниці лежить у розумінні, що проєктними менеджерами не стають – ними народжуються. Якщо порівняти людей із кульками, а їхню трудову діяльність – із величезною півсферою (див. рисунок), то сили, що діють на основну масу людей (назвемо їх F_G – “бажання стабільності”), змушують їх скотитися по цій півсфері в рівноважне положення, і там уже в цій купі кульок, під дією іншої сили (назвемо її F_A – “амбіції”), намагаються піднятися вище. Якщо ж трапляються якісь катаклізми і ця півсфера перевертається, або пропадає, або щось іще, то ці кульки страждають, депресують, катаються в пошуках рівноважного стану, частенько закочуючись не туди, куди слід. Але є “кульки”, які “катаються” постійно! На них діють зовсім інші сили або діють по-іншому, і вони примудряються закотитися на вершину перевернутої півсфери і там балансувати; покататися тоненьким, натягнутим високо під стелею, дротом; з усією швидкістю підкотитися до краю урвища і навіть злетіти над ним… Вивченню цих сил автор коли-небудь присвятить окрему статтю.

Це такий особливий склад характеру людей, які бояться рівноважного стану. Коли все спокійно – їм погано, коли все рухається – їм добре. Ось із них і виходять чудові проєктні менеджери, а ще підприємці та дослідники. Так! Часто ці люди нічого не знають про існування PMBOK і жодного разу не бачили Microsoft Project. Ба більше, вони навряд чи розглядали свої реалізовані проєкти з погляду термінів і бюджетів, і ніколи не заганяли їх у рамку “ініціалізація – планування – виконання – контроль – завершення”. Але на якомусь підсвідомому рівні вони примудрялися доводити справу до переможного кінця. Коли ж їм на озброєння потрапляє методологія УП, їх одразу починають називати успішними керівниками проєктів. Шукайте саме таких людей! Від інших їх відрізняє не освіта і досвід роботи (критерії, за якими їх шукають HeadHunter-и і HR-и), а наявність усіх таких якостей:

1. Націленість на результат і задоволення від процесу;
2. Здатність вирішувати проблеми, а не бажання констатувати факт їх наявності;
3. Азарт від подолання перешкод;
4. Уміння домовлятися з людьми.

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

Нісенітниця дванадцята (ломова)

Керівник проєкту може поєднувати обов’язки проєктного менеджера і посадові обов’язки співробітника фірми.

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

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

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

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

Що ж виходить у підсумку? Керівник проєкту, перебуваючи в штаті та виконуючи роботи за проєктом, поступово перетворюється на “ломового коня”, повільно, як днище корабля мушлями, обростаючи функціональними обов’язками, які абсолютно не стосуються проєкту. Йому кажуть “ти це вже робив”, “у тебе це виходить краще за всіх”, “нам потрібен твій досвід у цьому питанні”, “ти минулого разу чудово домовився з цими людьми” тощо. Тому компанія користується ним ще раз, і ще раз, і ще…

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

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

Тому намагайтеся не змішувати функції керівника проєкту і функції співробітника, особливо якщо проєкт разовий і не є основним бізнесом компанії.

Нісенітниця тринадцята (антикризова)

Криза – це погано.

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

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

Уся творчість людства зосередилася на зароблянні грошей. Причому більшості було абсолютно байдуже, яким саме чином заробляти гроші. Чим простіше – тим краще. Гроші виходило робити безпосередньо з грошей. Усі стали забувати класичну формулу кругообігу грошового капіталу Г-Т-Г’**. Здавалося, що в новій економіці вона не працює, а світові фінансові центри підживлювали цю ілюзію фінансовими вливаннями з неіснуючих фондів, точніше з фондів майбутнього. І раптом… це майбутнє настало! Грошей не стало і все встало…

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

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

Тож можете назвати кризу як завгодно – “це цікаво”, “це важко”, “це невизначеність”, “це нові можливості” тощо, але і вже точно не “це погано”.

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

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

Уже традиційно закінчуємо статтю цим розділом.

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

* Сфера застосування (Application Area) – Категорія проєктів, що володіють загальними елементами, значущими для таких проєктів, але такими, що не є необхідними або притаманними всім проєктам. Сфери застосування зазвичай визначають у термінах продукту (тобто за схожими технологіями або методами виробництва), типу замовника (тобто внутрішні або зовнішні, державні або комерційні) або галузі (тобто комунальні послуги, автомобілебудування, космонавтика, інформаційні технології тощо). Сфери застосування можуть перекриватися.
A Guide to the Project Management Body of Knowledge (PMBOK® Guide) -Fourth Edition
© 2008 Project Management Institute, 14 Campus Blvd., Newtown Square, PA 19073-3299 USA.

** Г-Т-Г’ (Гроші-Товар-Гроші’) – проста формула кругообігу грошового капіталу процесу виробництва капіталу.
Карл Маркс. Капітал. Критика політичної економії. Том II. Книга 2.
Процес обігу капіталу / Видано за ред. Ф. Енгельса. – М.: Політиздат, 1984.