Забагато проектів на дорозі Відставання від проекту неминуче!
Хто не знає начальника, який хоче все негайно: "Це потрібно зробити якомога швидше". ASAP, природно, означає "якомога швидше", і це прохання негайно кинути ручку і подбати про тему бос щойно перемістився до верхньої частини групи завдань.
Зустріч проекту з керівництвом середнього постачальника автомобілів: Ви орієнтуєтесь на клієнта і не змушуєте клієнтів чекати. Тож почнімо негайно! Не гарантуємо, що ви закінчите вчасно, але принаймні ми не втратили час, починаючи пізніше. На жаль, над проектом може працювати лише одна команда, яка все ще перебуває у процесі виконання п'яти-семи інших проектів. Час інтелектуального налаштування для кожного: Принаймні одна додаткова година на день, координація проектів відбувається одночасно, і всі хочуть, щоб їх обслуговували. Обслуговувати п’ять-сім керівників проектів - це буде важко і більше не можна контролювати. Повсякденне життя? Так, на жаль!
Як це поєднується з гнучким та ощадливим управлінням проектами?
Після цього досвіду ми запитали себе, який вплив має ментальність ASAP на безперешкодне управління проектами? Що трапляється, якщо компанія запускає всі проекти одночасно, без встановлення пріоритетів та без урахування термінів? Як менеджери проектів та члени команди справляються з одночасною роботою над п’ятьма або більше проектами?
Головне питання: Як мені управляти портфелем проектів таким чином, щоб проекти завершувались якомога ефективніше та цілеспрямованіше і мінімум часу? Чи може ALAP бути альтернативою?
Цікава відповідь: експеримент капітана гавані
У порту є 3 причали, 3 доківникам потрібно 3 дні, щоб розвантажити судновий вантаж. 3 судна перебувають на рейдовій дорозі в очікуванні вивантаження їх вантажу. Старий капітан гавані вважався дуже орієнтованим на споживача і мав усі 3 кораблі одночасно пристикованими. Вивантаження всіх кораблів одночасно зайняло 3 дні, так що кожен з кораблів міг знову відплисти лише через 3 дні.
Коли старий капітан гавані пішов на заслужену пенсію, молодий капітан гавані зайняв його роботу. На кордоні знову було 3 кораблі, але молодий капітан гавані подумав про те, як він може скоротити час причалу принаймні для деяких кораблів і як він може обробляти більше кораблів у своєму порту, не будуючи нових причалів.
Вихід очевидний: молодий капітан гавані завів лише один корабель у гавань і вивантажив судно зі своїми 3 доками за один день, а не всі кораблі одночасно за 3 дні, як раніше. В результаті перший корабель зміг знову відплисти через одну добу, другий - через два дні, і лише третій корабель перебував у порту протягом трьох днів. Загалом час причалу всіх кораблів становив 6, а не 9 днів, а це означає, що він збільшив місткість своїх причалів на 30%. Крім того, у нього менше стресу, оскільки він тепер може зосередитися на управлінні одним судном, яке знаходиться в порту.
Уникайте заторів у проекті!
Головний експеримент гавані це чітко демонструє: розпочинання всіх проектів якомога раніше не призводить до найкоротшого часу виконання. “Час очікування” перешкоджає якнайшвидшому завершенню проекту. Керівники проектів та члени команд працюють над багатьма проектами одночасно. Час інтелектуального налаштування знижує ефективність, і фокус втрачається.
У багатьох компаніях автомобільної галузі ми бачимо, що проекти починаються негайно, як тільки замовлення здійснюється самостійно. Необхідні потужності часто вилучаються з тих місць, де компанія вважає, що вона не контролюється іншими: наприклад, в інноваційних проектах. Компанія послаблює свою майбутню життєздатність.
Занадто багато проектів на дорозі одночасно призводить до заторів на першому будівельному майданчику. Трубопровід пересихає, і його можна продовжувати лише при масовому використанні ресурсів. Це майже завжди пояснюється ментальністю ASAP.
Шість чітких думок про те, як ефективніше керувати портфелями проектів:
1. "Як можна пізніше" - це пісне
Як можна менше проектів одночасно, портфоліо залишається чітким. Зберігаючи зусилля з управління портфелем якнайменше, уникаючи інтелектуального часу налаштування та одночасно спрямовуючи фокус команд на поточні проекти - все це реалізація бережливих принципів в управлінні проектами. Таким чином, принцип "цілісного потоку" від ощадливого виробництва також може бути перенесений на управління проектами.
2. Огляд проекту на перший погляд
Звичайно, останній можливий старт проекту може бути забезпечений лише керівництвом та замовниками, якщо є впевненість, що проект буде успішно завершений у решту часу. Зосередження уваги на прозорості ризиків, уникненні ризиків та відкритому поводженні з проектними ризиками допомагає створити цю довіру. Досвідчені менеджери проектів контролюють проектний ризик, створюючи резерв витрат і часу та готуючи резервні рішення, готові до технічних ризиків.
3. Таймбоксинг підвищує безпеку планування
Таймбоксинг - це принцип швидкого розвитку. Там сказано, що змінною в процесі проекту є не час, а надання послуг. Це як на іспиті: якщо час закінчився, він відмовляється. Деякі люди важко уявити, що таймбоксинг буде працювати в проекті, адже напівфабрикат не має сенсу.
Таймбоксинг все ще може бути використаний дуже добре, оскільки він дозволяє відслідковувати проекти. Після кожного таймбоксу команда повинна показати, чого вона досягла. Затримки з наданням послуг негайно прозорі, і контрзаходи можуть бути вжиті на ранній стадії.
4. Час - дефіцитний ресурс
Сіріл Н. Паркінсон сказав це в двох словах: "Робота розширюється настільки, наскільки є час для її виконання". План проекту повинен це враховувати, якщо час виконання проекту повинен бути мінімальним. Принцип планування, який випливає з цього, передбачає вузькі часові проміжки для заповнення робочих пакетів, тобто дефіцит ресурсу "часу". Для того, щоб мати можливість реагувати на непередбачені події, передбачений часовий буфер, який лише менеджер проекту може звільняти потроху.
5. Виправлені команди встановлюють власні пріоритети
Самоорганізовані та самокеровані команди найкраще можуть самі вирішити, якого результату вони можуть досягти за який час. Настільки ідеальний для підходу ALAP, коли встановлення пріоритетів є вирішальним. Спробуйте ринок, де команди беруть проекти, які відповідають їхнім компетенціям і яким вони можуть керувати з точки зору часу. Занадто революційний? Є компанії, які вже успішно працюють таким чином.
6. Менеджери: Відпустіть!
Я бачив це багато разів: ментальність ASAP створює більше плутанини в робочому процесі, ніж допомагає сортувати пріоритети в управлінні багатьма проектами. То чому б нам не довірити нашим командам проектів самостійно визначати пріоритети та послідовність завдань у проекті. Швидше, робота менеджера полягає у визначенні цілей, а потім уникненні. Але не залишайте сумнівів, що цілі можна досягти послідовно.
Звернення надходить до керівників:
Майте довіру до своїх команд. Вирішальним є не тип реалізації, а досягнення результату. Наберіться мужності відпустити. Залиште "як" вашим командам. Як менеджер подбайте про те, "чому" і "що"
Не давайте ASAP менталітету жодної кімнати!
Якщо ви чесно відповісте на наступні запитання, ви потрапите на шлях менталітету ASAP у своїй компанії:
- Чи належним чином забезпечені нові технології продуктів та процесів до початку серійної розробки?
- Чи існує оцінка ризику та, за необхідності, резервний план перевірених та перевірених технологій?
- Чи систематично визначаються вимоги до товару?
- Чи систематично оцінюються технічні зміни протягом періоду проекту або в наступних серіях?
- Чи завжди статус проекту актуальний та відомий керівництву?
- Процес етапу дозволяє ефективно та пильно контролювати проект?
- Віхи публікуються послідовно та своєчасно?
- Чи визнаються проектні ризики на ранній стадії, заходи щодо мінімізації ризиків або відхилення в проекті приймаються та негайно та систематично переходять до управління?
- Чи доступність ресурсів та навантаження команд є критерієм додавання чи відхилення проектів у портфоліо?
Все більше компаній намагаються уникнути спіралі ментальності ASAP. Вони усвідомлюють, що чим складнішими стають проекти, їх неможливо освоїти звичайними методами.
Початок проектів якомога пізніше має багато переваг. Однак для цього потрібне надійне планування, статус проекту, який завжди прозорий, відкритий підхід до проектних ризиків та послідовні дії всіх, хто бере участь у проекті.