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

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

Сьюзен Хіґні, моїй дружині та подрузі вже сорок років

Передмова
до п’ятого видання

Минуло вже чотири роки з моменту публікації четвертого видання цієї книжки, деякі важливі показники у світі управління проєктами змінилися, а інші залишилися незмінними. Відповідно до нещодавнього звіту Інституту управління проєктами (Project Management Institute, PMI®) під назвою «Динаміка професії», відсоток успішних проєктів (таких, що досягають своїх цілей) у період між 2012 та 2015 роками залишився на рівні 64 %. Однак сьогодні високоефективні організації зосереджують свою увагу на основних аспектах культури, талантів та процесів, які підтримують успішні проєкти. Такі організації послуговуються управлінням проєктів та досягають поставлених цілей і ділових намірів у два з половиною рази частіше, ніж менш ефективні виконавці. Головний висновок із цього звіту зрозумілий: зверніться до основ та закладіть фундамент для успішних проєктів у майбутньому. П’яте видання «Основ управління проєктами» — це чудовий інструмент для того, щоб закласти власне підґрунтя для управління проєктами та, у разі необхідності, продовжити свій шлях до досягнення статусу досвідченого професіонала з управління проєктами.

До цього видання було додано два нові розділи. Управління зацікавленими сторонами було додано до п’ятого видання «Довідника з управління проєктами» (Project Management Body of Knowledge, PMBOK® Guide) 2013 року як нова сфера знань, тож ми додали Розділ 4 «Упровадження управління зацікавленими сторонами в процес планування проєкту». Лишень замислитися, скільки людей та груп допомагають вам у просуванні вашого проєкту його життєвим циклом. А тепер подумайте, скільки з них впливають на результати вашого проєкту. Ці люди та групи називають зацікавленими сторонами. Чи визначили ви свої зацікавлені сторони? Чи управляєте ви ними від ініціювання проєкту до його завершення? Багато менеджерів проєктів такого не роблять, і це відбивається на їхніх результатах. Цей розділ пропонує кращі практики, інструменти та методи, які допоможуть вам у взаємодії із зацікавленими сторонами та управлінні ними.

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

Також до цього видання було внесено чимало змін. Передусім це видання «Основ управління проєктами» було оновлено й переглянуто для досягнення відповідності з п’ятим виданням «Довідника з управління проєктами».

Серед оновлень видання — розширений Розділ 6, який раніше називався «Створення плану управління ризиками проєкту». Нині він зосереджується на створенні власного плану комунікацій та пропонує чудовий шаблон, який за потреби можна адаптувати до власних особливостей. Цей етап має бути обов’язковим для будь-якого проєктного менеджера, який працює із середніми та великими проєктами.

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

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

Джозеф Дж. Хіґні

Листопад 2015 року

Розділ 1.
Загальне уявлення про управління проєктами

У чому ж полягає суть управління проєктами? Коли 1997 року вийшло перше видання цієї книжки, Інститут управління проєктами (ІУП) мав лише кілька тисяч членів, а станом на 2015 рік їх налічувалося майже 462000 осіб. Для тих із вас, хто не знає, ІУП — це професійна організація для людей, які досліджують та вдосконалюють управління проєктами. Ви можете отримати більше інформації на вебсайті інституту — www.pmi.org. Окрім надання різноманітних послуг для членів, головною метою ІУП є сприяння управлінню проєктами як професії. Для цього інститут створив процес сертифікації, згідно з яким кваліфіковані особи можуть отримати звання «спеціаліст з управління проєктами» (Project Management Professional, PMP®). Для цього необхідно мати певний досвід роботи (приблизно 5000 годин) та скласти онлайн-іспит, який базується на «Довіднику з управління проєктами» («Довідник PMBOK®»).

Професійна асоціація? Лише для управління проєктами? Хіба управління проєктами це не просто різновид загального менеджменту?

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

Отже, що таке управління проєктами та, зрештою, що таке проєкт? ІУП визначає проєкт як «тимчасові заходи, спрямовані на створення унікального продукту, послуги чи досягнення результату» (PMBOK® Guide, PMI, 2013, с. 5). Це означає, що проєкт — одноразова діяльність. Якщо вона повторюється, це вже не проєкт. Проєкт повинен мати певні точки початку та кінця (термін), бюджет (вартість), чітко визначений зміст (або масштаби) роботи, яку необхідно виконати, та конкретні вимоги до результатів, яких потрібно досягти. Я кажу «повинен мати», тому що не завжди проєкт відповідає бажаному визначенню. До речі, у даній книжці ці характеристики проєкту називаються цілями PCTS (англ. performance, cost, time, scope, відповідно РВТЗ — результати, вартість, тривалість, зміст).

ІУП визначає проєкт як «тимчасові заходи, спрямовані на створення унікального продукту, послуги чи досягнення результату».

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

«Проєкт — це проблема, запланована до розв’язання».

Дж. М. Джуран

Невдачі проєкту

Сучасні дослідження демонструють неоднозначні результати щодо показників успішності управління проєктами. Нещодавній звіт Standish Group під назвою «CHAOS»{1} із акцентом на проєкти розробки програмного забезпечення вказує: 29 % проєктів — успішні, 52 % — мають труднощі, а 19 % — зазнають невдачі. Слід зазначити, що фактори успіху було «осучаснено», аби вони відповідали термінам, бюджету та задовільним результатам. Рівень успішності практично не змінився порівняно зі звітом за 2011 рік. У компанії Standish усе ж підкреслюють, що менші проєкти мають значно вищий рівень успішності, ніж більші.

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

Найбільш яскраво описують ситуацію дані, які нещодавно опублікував Інститут управління проєктами. ІУП постійно відстежує стан управління проєктами, їхніми програмами та портфелем. Його дослідження 2015 року «Динаміка професії» виявляє деякі позитивні тенденції, але також зазначає, що відсоток проєктів, які досягають своїх цілей, із 2012 року стабільно залишається на рівні 64 %. Для досягнення покращення ІУП пропонує організаціям звернутися до основ й особливо до трьох наведених нижче сфер.

1. Культура. Робота над створенням відповідного бачення управління проєктами.

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

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

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

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

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

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

PMBOK® Guide, PMI дає таке визначення: управління проєктами — це «застосування знань, умінь, інструментів та технік проєктної діяльності для задоволення проєктних вимог. Управління проєктами здійснюється за допомогою застосування та інтеграції 47 логічно згрупованих процесів управління проєктами, які формують п’ять груп процесів: ініціація, планування, виконання, моніторинг і контроль, завершення» (PMBOK® Guide, PMI, 2013, с. 6).

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

PMBOK® Guide, PMI

В останньому «Довіднику PMBOK®» додано п’ять нових процесів управління проєктами, що наведено нижче.

1. Планування управління змістом.

2. Планування управління графіком.

3. Планування управління витратами.

4. Планування управління зацікавленими сторонами.

5. Контроль залучення зацікавлених сторін.

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

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

Було б краще, якби «Довідник PMBOK®» чітко вказував, що менеджер проєктів повинен сприяти плануванню. Одна з помилок, яких припускаються недосвідчені проєктні менеджери,— це планувати проєкт за всю свою команду. У такому разі учасники команди не лише не сприймають цей план як належний — він ще зазвичай містить багато невирішених питань. Менеджери не можуть усе обдумати, їхні оцінки тривалості завдань можуть бути помилковими — і вся ця діяльність розпадається одразу ж після запуску проєкту. Перше правило управління проєктами полягає в тому, що люди, які мають виконувати цю роботу, повинні допомагати її планувати.

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

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

Найкращим визначенням лідерства я вважаю наведене Венсом Пакардом у його книжці «Підкорювачі піраміди» (The Pyramid Climbers, Crest Books, 1962). Він каже: «Лідерство — це мистецтво діяти так, щоб інші хотіли робити те, що, на вашу думку, потрібно зробити». Ключове слово тут — «хотіли». Диктатори змушують інших робити те, чого хочуть вони. Так само поводяться охоронці, які наглядають за групами ув’язнених. Але лідер діє так, що інші хочуть виконувати певну роботу — у цьому й полягає суттєва різниця.

«Лідерство — це мистецтво діяти так, щоб інші хотіли робити те, що, на вашу думку, потрібно зробити».

Венс Паккард

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

Це не просто планування!

Одна з поширених помилок щодо управління проєктами — твердження, що це просто планування. Згідно зі своїм останнім звітом, компанія Microsoft продала величезну кількість копій програми Microsoft Project®, однак рівень краху проєктів усе одно залишається високим. Безумовно, планування є головним інструментом, що використовують для управління проєктами, але воно не настільки важливе, як створення спільного бачення, чого має досягти проєкт, або розбудова гарної ієрархічної структури робіт (ICP) для визначення всієї роботи, яку потрібно виконати (про ієрархічну структуру робіт я детальніше розкажу в Розділі 7). Проте, якщо не забезпечити хороше управління проєктами, розроблений детальний графік лишень допоможе з великою точністю задокументувати власні невдачі!

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

Випадковий менеджер проєктів

Чи бувало таке, що вам раптово доручали управління проєктом без надання титулу «менеджер проєкту» чи належної підтримки? Чи вважали ви себе менеджером проєкту та проєктною командою? Що ж, ви такі не одні. Усе частіше люди виконують роботу, яка, згідно з «Довідником PMBOK®» (PMI 3, 2013) відповідає поняттю «проєкт»: «тимчасові заходи, спрямовані на створення унікального продукту, послуги чи досягнення результату». Наявні визначені термін та зміст роботи, обмежені ресурси та часто фіксований бюджет. Хоча вони менш формальні та не потребують проєктної команди, ці проєкти повинні бути сплановані, мати графік виконання та контролюватися. Потрібно доставити винятковий/прийнятний проєктний продукт та повністю або частково задовольнити замовника.

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

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

Пастка «2 в 1»: працівник та менеджер проєкту

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

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

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

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

У цій книжці не висвітлюється тема вибору менеджерів проєктів, але зацікавлені читачі можуть знайти необхідну інформацію в роботі Роберта К. Висоцьки та Джеймса П. Льюїса під назвою «Менеджери проєктів світового рівня» (The World-Class Project Manager, Perseus, 2001).

Неможливо мати все й одразу!

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

Зв’язок між параметрами — результатами (P), вартістю (B), терміном (T) та змістом (З) — можна записати так:

В = f(x)(Р, Т, З).

Тобто вартість проєкту — це функція результатів (Р), терміну (Т) та змісту (З). Графічно мені подобається зображувати це як трикутник, у якому P, В і T — сторони, а З — площа. Це показано на рис. 1.1.

Рис. 1.1. Зв’язок між Р, Т, З та В

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

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

Спонсор незмінно вигукує: «Як цей проєкт може коштувати так багато?» Він має в голові певну вартість, а ваші цифри завжди її перевищуватимуть. Тож спонсор може сказати: «Якщо проєкт стільки коштує, ми не можемо виправдати виконання цієї роботи». Саме так! І таке рішення він має ухвалити. Але він, безумовно, намагатиметься змусити менеджера проєкту погодитися на меншу вартість, і якщо ви так зробите, то спричините повний крах — не тільки свій, а й спонсора.

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

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

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

Існує більша ймовірність, що в проєкті щось випадково піде не так, ніж що він буде несподівано ідеальним.

Фази проєкту

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

Рис. 1.2. Життєвий цикл проблемного проєкту

Я демонстрував цей рисунок людям у багатьох країнах — і вони незмінно сміялися та казали: «Саме так усе й відбувається». У цій ситуації мене заспокоює те, що ми, американці, не єдині, хто стикається з подібною проблемою, однак є й погана новина — якщо всі визнають цю модель, то існує багато неадекватних проєктів.

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

Рис. 1.3. Правильний життєвий цикл проєкту

Визначення

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

Я запевнив його, що це доволі поширене явище.

«Що мені робити?» — запитав він.

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

На зустрічі я підійшов до дошки й сказав: «Напишімо, яка проблема стоїть перед нами». Хтось негайно запротестував: «Нам не потрібно цього робити. Ми всі знаємо, у чому проблема».

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

А далі було весело. Хтось сказав: «Ну...», і я записав на дошці його твердження, а інший промовив: «Я із цим не згодний!»

І за три години ми нарешті сформулювали проблему.

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

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

Після того як проєкт буде визначено, ви можете братися до планування роботи. Такий план містить три компоненти: стратегію, тактику та логістику. Стратегія — це загальний підхід або «план гри», якого ви дотримуватиметеся для виконання роботи. Наступним прикладом стратегії поділився мій друг, який знається на військовій історії.

Стратегія

Кінець безкоштовного уривку. Щоби читати далі, придбайте, будь ласка, повну версію книги.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Про авторів

З 2001 року Джозеф Хіґні є президентом компанії QMA International, що надає широкий спектр консультацій із менеджменту у всьому світі. Він проводить семінари для компаній зі списку Fortune-500 та виступає на окремих конференціях та конвенціях. Серед його клієнтів — компанії PepsiCo, Federal Express, Verizon, Merck, SAP Americas, а також Гарвардська школа бізнесу та Збройні сили США.

Містер Хіґні приєднався до Американської асоціації менеджменту (AMA) 1996 року як керівник програми, здійснюючи управління виробництвом, якістю та закупівлею лінійки семінарів. Згодом він розробляв лінійки продуктів з управління проєктами й був призначений менеджером групової програми в Центрі розвитку менеджменту в Нью-Йорку, де управляв менеджерами програм із різних сфер — управління проєктами, навчання та розвитку, комунікацій, закупівлі та загального управління. Невдовзі він став керівником глобальних програм з поширення найкращих практик управління проєктами та очолив міжнародну команду, відповідальну за пошук та включення найкращих практик у вміст навчальних програм AMA у всьому світі.

Містер Хіґні також є викладачем у Міському університеті Нью-Йорка та Інституті й Коледжі імені Роберта В. Даулінга (Нью-Йорк), де викладає як для студентів, так і для аспірантів. Зараз він викладає кілька курсів місцевої MBA-програми для керівників при коледжі ім. Даулінга. Програма містить навчання у сферах управління проєктами, управління виробництвом та операціями, дослідження операцій, лідерства, загального управління, системи управління людськими ресурсами, управління якістю, контролю якості статистичної роботи та процесів, розвитку керівного персоналу.

Містер Хіґні розпочав свою кар’єру в компанії Grumman Aerospace (Northrop Grumman), де працював у відділах управління матеріалами та корпоративних закупівель. На час завершення своєї кар’єри в Northrop Grumman він очолював проєктну команду зі створення та впровадження корпоративної системи оцінювання ефективності постачальників.

Містер Хіґні здобув ступінь бакалавра з педагогіки в Коледжі імені Чарлза Вільяма Поста та ступінь магістра з промислового менеджменту в Державному університеті Нью-Йорка в Стоні-Брук. Його професійна діяльність пов’язана з Інститутом управління проєктами, Міжнародною асоціацією управління проєктами та Американським товариством якості.

Книжка «Основи управління проєктами» не стала б бестселером, якби не Джеймс П. Льюїс, доктор наук, автор її перших трьох видань. Доктор Льюїс — президент заснованої 1981 року навчально-консалтингової компанії Lewis Institute, яка спеціалізується на управлінні проєктами. Досвідчений менеджер проєктів, він з 1981 року почав проводити навчальні семінари у всьому світі й навчив тонкощів управління проєктами понад 40000 осіб.

Джеймс Льюїс є автором десяти книжок, зокрема «Планування проєктів, створення графіків та управління проєктами», «Освоєння управління проєктами», «Настільний довідник менеджера проєктів», «Спільна робота: 12 принципів Boeing Commercial Aircraft для управління проєктами, командами та організацією» (McGraw-Hill) та «Як створити та управляти успішною проєктною командою. Командний проєктний менеджмент» (AMACOM Books). Він також написав книжку «Управління проєктами світового класу» (Perseus) у співавторстві з Робертом Висоцьки.

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