Як правильно керувати проектом, ТЕХНОЛОГІЇ, ІНЖИНІРИНГ, ІННОВАЦІЇ

Вимірник діаметра, вимірник ексцентриситету, автоматизація, ГІС, моделювання, розробка програмного забезпечення та електроніки, БІМ

Як правильно керувати проектом

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

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

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

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

1. За який проект (проекти) ми маємо взятися?

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

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

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

Давайте використати розробку продукту як приклад для вивчення нашої проблеми.

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

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

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

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

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

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

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

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

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

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

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

Елі назвав це Деревом контенту на відміну від загального Дерева стратегії та тактики, інструменту, який використовується у проектах щодо впровадження змін. Він стверджував, що такий підхід дозволить скоротити кількість змін на цілих 50%.

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

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

Усунено розростання обсягів: а) на етапі планування визначено, де немає потреби у змінах у специфікаціях, вимогах та дизайні; б) на етапі виконання покращено синхронізацію змісту проектних завдань.
Скорочено загальну увагу керівництва: а) увага сфокусована на майбутнє, а не на процесівиконання.
Збільшилася швидкість виконання проектів: а) зменшилася кількість прийняття та погодження необхідних рішень і, отже, затримки.
Збільшилася швидкість у спільних областях: а) покращено синхронізацію та взаємодію між командами розробників, зменшено кількість переробок.
Поліпшено розміщення пріоритетів релізів за допомогою підвищення прозорості ROI.
За 45 хвилин новий член проектної команди чітко зрозумів складний довгостроковий проект [Керівник проекту].
Інженери стали набагато краще розуміти деталі, які вимагаються від продукту, що розробляється, і потреби, що лежать в основі цих рішень [Технічний керівник].
Документи – не лише специфікації того, що потрібно, але ще важливіше, причини, чому проект необхідний, що саме буде зроблено і що не буде, все це ясно викладається всім зацікавленим сторонам. Вони чітко пояснюють усім зацікавленим сторонам обсяг проекту, і, що ще важливіше, усувають будь-яке неправильне тлумачення, нерозуміння та непорозуміння, які зазвичай викликають тривалі переробки протягом усього проекту [Технічний директор].

3. Як ми повинні планувати та керувати виконанням проекту?

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

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

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

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

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

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

Рішення повністю документоване у підході Критичного ланцюга для управління проектами.

Ось три керівні принципи та правила для їх прийняття:

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

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

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