Ієрархічна структура обмежень

Обмеження (Constraint) – обмежувальний фактор, що впливає на перебіг виконання проєкту, програми, портфеля або процесу.
©2013 Інститут управління проектами
Посібник до Зводу знань з управління проектами PMBOK® – 5 видання

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

1. 

   Рис. 2-9. Вплив змінної залежно від терміну проєкту.
   ©2013 Project Management Institute. Посібник до Зводу знань з управління проектами (Посібник PMBOK®) – П’яте видання

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

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

Ну, а далі по пунктах, як розбрати завдання на складові:

Як виявити обмеження?

Беремо 6 класичних типів обмежень, серед яких: зміст, якість, розклад, бюджет, ресурси та ризики, і будуємо на основі них Ієрархічну структуру обмежень. Цією структурою мають користуватися керівники проєктів під час розроблення документа “Опис змісту проєкту”, а точніше розділу “Обмеження проєкту”. Це, звісно, не гарантує 100% виявлення всіх-всіх-всіх обмежень, але різко знижує ймовірність щось забути. Ба більше, з’являється однотипний підхід до виявлення, класифікації та управління обмеженнями. Отримуємо таку структуру:

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

Як зафіксувати обмеження?

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

Де:

• Тип – тип обмеження проєкту з нашої Ієрархічної структури ресурсів.
• Обмеження – власне короткий опис самого обмеження, тобто. стану, якості або розуміння стримувальних чинників, що впливають на певний образ дії або бездіяльності, застосовних умов (внутрішніх або зовнішніх), що впливають на перебіг виконання проєкту або процесу.
• Елемент ІСР – елемент ієрархічної структури робіт (WBS), до якого належить це обмеження. Якщо воно відноситься до кількох елементів, то ставиться елемент більш верхнього рівня аж до самого проєкту.
• Джерело – П.І.Б. та контактні дані зацікавленої сторони проєкту, що визначає конкретне обмеження. Зацікавлені сторони проєкту – це особи або організації (наприклад, замовники, спонсори, організація-виконавець або громадськість), які беруть активну участь у проєкті або інтереси яких можуть бути зачеплені як позитивно, так і негативно під час виконання або в результаті завершення проєкту.
• Відповідальний – П.І.Б. та контактні дані особи, яка несе відповідальність за управління обмеженням, у процесі врівноваження конкуруючих обмежень проєкту.
• Стан – обмеження зміняться по суті, щойно стане доступною нова інформація.

Чи можуть змінюватися обмеження під час проєкту?

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

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

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

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

Чим допомагають і чим заважають обмеження в проєктах?

Можемо умовно розбити обмеження на “погані” і “хороші”. Погані – це ті, що заважають команді проєкту “розмазатися думкою по древу”, а хороші – це ті, що захищають команду від надмірного тиску з боку замовника. Але і ті, і інші “погані” і “хороші” лише умовно.

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

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

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

Як узгоджувати обмеження із замовником та іншими зацікавленими сторонами?

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

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

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

Можете взяти на озброєння цю демонстрацію. Адже “перекачаний” за обмеженнями проєкт довго не протягне…

Як правильно відобразити обмеження в документах проєкту?

Усе залежить від масштабу проєкту. Якщо проєкт невеликий – достатньо відобразити пару-трійку обмежень у Статуті проєкту. Якщо проєкт більший – використовується розділ “Обмеження проєкту” в документі “Опис змісту проєкту”. Якщо проєкт складний і комплексний – використовують окремий документ “Журнал обмежень” і бажано не у вигляді файлу MS Excel, а у вигляді електронного лога або реєстру в інформаційній системі управління проєктами. Ну, і сама УП дає змогу ввозити обмеження безпосередньо в розкладі проєкту. Наприклад, той самий MS Project дає змогу вводити візуальні та фізичні обмеження на терміни, ресурси та бюджети.

Шаблони зазначених документів можна отримати тут:

• Статут проекту
• Опис змісту проєкту

Автор: Анатолій Савін, PMP