NUPPNUP1NUP2NUP3NUP4NUP5NUP6

Не робіть нічого без чіткої мети

Нічого не слід робити, якщо це не має чіткої мети. Уявіть два паралельні світи, де все те саме, за винятком того, що ви думаєте робити: Наскільки би різними були ці світи? Чи варта різниця зусиль, щоб зробити це?

Якщо ви немаєте на увазі чіткої мети і ви робите лише щось, тому що всі інші це роблять, або всі кажуть, що це важливо робити, то

Приклад: Портфелі та програми

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

Пам’ятайте, що управління проектами полягає в тому, щоб робити все правильно, тоді як управління портфелем - це робити правильні речі. Не важливо, наскільки добре ви керуєте своїми проектами; це не буде добре, якщо ви робите неправильні проекти. Вся справа в тому, щоб мати мету.

Приклад: Проект в цілому

Гнучкість продукту залежить від проектів. У деяких проектах розвитку ІТ продукт є абсолютно гнучким, і його остаточна форма залежить від зворотного зв’язку, який буде формуватися інкрементами продукту під час проекту, що вимагає адаптивного (Agile) підходу. Це практично з точки зору поєднання портфеля, програми та шарів проекту, і йому потрібно максимально приділяти увагу кінцевій меті. Добре задокументувати мету та мати її досяжною; це одна з цілей “продуктового бачення”, яка використовується в деяких Scrum проектах. Увага до ділових цінностей у проектах Agile - це спосіб їх узгодження з метою.

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

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

Приклад: Моніторинг проекту

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

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

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

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

Приклад: Документи

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

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

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

Шукати «шаблон» - це протилежне тому, щоб робити щось на основі мети.

Приклад: Звітність про хід віконання (статус)

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

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

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

Приклад: Бізнес-обґрунтування та статут проекту

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

Хоча ви думаєте про те, як можна підготувати документи для задоволення їхніх цілей, ви можете не думати про кожен сценарій і може щось пропустити. Щоб уникнути цього, ви можете перевірити, що пропонують такі джерела, як PRINCE2®, PMBOK® Guide, P3.express і DSDM®, а потім оцінити ці пропозиції, виходячи з цілей.

Приклад: Постпроект

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

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

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

Моніторинг після проекту - це необхідний крок у орієнтації на ціль. В основному це відповідальність систем управління програмами та портфелями, і оскільки більшість компаній не мають таких рівнів управління, цим кроком зазвичай нехтують. Ось чому такі методи, як P3.express та DSDM®, додають цей крок до своїх методологій управління проектами.

Приклад: Простота

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

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

Приклад: Адаптація

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


▼ PDF