Коли проект короткий - все в ньому зібрані і йдуть до спільної мети, і управляти таким проектом щодо просто. А ось при тривалості в рік і більше утримати фокус команди і стейкхолдерів і зберегти керованість набагато складніше. Цифри наведені для ІТ і, ясна річ, умовні, для різних областей вони будуть різними. Як же зробити так, щоб і через рік і через два проект як і раніше був цікавий команді і стейкхолдерам, ніс розумне, добре і світле, і не вимагав божевільних зусиль для управління ним?
Відразу обмовлюся, що по можливості такі проекти все-таки потрібно розбивати на кілька. Це простіше як з точки зору управління, так і з точки зору мотивації. Коли в проекті, нехай і боргом, встигає змінитися майже вся команда, нехай навіть в силу природної плинності кадрів, це нікого не радує і породжує негативне ставлення до нього і підозри про недостатню кваліфікацію РМА (несправедливо, але факт).
До речі, вміння зробити проект коротким - це окремий навик, який варто розвивати, тому що керованість таких проектів в рази вище. Але про це якось іншим разом.
Отже, що потрібно для того, щоб зробити довгостроковий проект керованим?
1. Чіткі процеси і непримиренність до їх недотримання
На етапі планування грамотний керівник проекту повинен продумати не тільки процеси роботи зараз, але і те, як вони будуть змінюватися в ході життєвого циклу проекту. Наприклад, якщо на активній фазі (наприклад, збір і погодження розбіжностей між вимогами) ви проводите збори робочої групи один раз в тиждень, то краще відразу домовитися про те, що на етапі розробки вони будуть один раз в три тижні або один раз на місяць.
Найгірше, що можна зробити - це пустити питання на самоплив, мовляв, в той час, коли постійне залучення групи не вимагається, буду збирати зустрічі при необхідності. Як тільки з календаря пропаде регулярна зустріч - про проект забудуть, фокус буде втрачено. Однак який сенс збирати людей, якщо для них немає конкретних завдань, запитаєте ви?
Саме тому важливо продумати цей момент ще при плануванні робіт і зробити так, щоб потік завдань для всіх учасників був відносно постійним протягом всього ходу проекту або хоча б не висихав зовсім. Вимоги зібрані, розробка запущена? Саме час разом з робочою групою спланувати, як ви будете вчити людей, і що для цього потрібно зробити.
Те ж саме і з плануванням відпусток - як тільки ви пропустите 1-2 зустрічі - народ почне ходити як зручно йому, а ви потім в найкритичніший момент виявите, що ключові співробітники у відпустці саме в той час, на яке ви запланували на них важливі активності.
2. Розбиття проекту на стадії і відзначення завершення цих стадій
Якщо довгостроковий проект з якихось причин (часто фінансовим або політичним, до речі) неможливо розбити на кілька, потрібно, принаймні, чітко позначити його стадії і критерії їх завершення. Після того, як стадія завершена, необхідно її офіційно закрити - провести презентацію для керуючого комітету, нагородити, влаштувати якесь тімбілдингові захід і відзначити цю справу. Це дасть людям розуміння того, що проект рухається, а не стоїть на місці, дозволить поставити ментальну "галочку" "я зробив" і продовжувати бігти.
Відмінний приклад - "Барвистий забіг" у Москві, на якому кожен кілометр траси був відзначений новим кольором, щоб люди розуміли, що вони пробігли ще один шматок і могли отримати "підзарядку".
3. Витягнуті уроки по кожному етапу
Після завершення стадії добре б проводити сесії по тому, які уроки (позитивні і негативні) команди витягла за час цієї стадії, і як вони допоможуть нам далі.
Знову ж таки, дає відчуття завершення попередньої стадії і дозволяє відокремити її від подальших плюс поповнити скарбничку тими знаннями, які в кінці проекту (через рік!) Будуть вже давно і благополучно забуті.
4. Поетапне введення результатів в роботу
Швидше за все, це не ваш випадок (тоді ви з самого початку робили б проект по гнучкій методології), але іноді можна якось це виправити вже в ході самого проекту. Якщо non-Agile - це політичне рішення, то проміжну версію завжди можна назвати тестової або "для отримання зворотного зв'язку" і робити собі спокійно проект так, як зручно і ефективно.
Ну і якісь окремі речі можна вводити теж раніше повного запуску - наприклад, якщо в проекті передбачені дашборда на великих екранах, можна повісити їх за рік до старту і транслювати на них новини проекту та щось ще. По-перше, заздалегідь зробите цей шматок, по-друге - вогні будуть ненав'язливо нагадувати про проект, по-третє - у людей буде розуміння, що ця частина проекту завершена.
5. Регулярна переоцінка необхідності проекту, вимог, стейкхолдерів, ризиків
Це сумний факт, але більшість результатів довгострокових проектів застарівають ще до того, як потрапити до кінцевих користувачів. А іноді і взагалі з'ясовується, що вони більше не потрібні, стратегія компанії змінилася, ключові зацікавлені особи поїхали працювати в Лондон і ще сотні причин, чому ваша робота виявилася нікому не потрібною. Якщо з якихось причин Agile не для вас і здавати проект по шматках ніяк не можна - то потрібно з певною регулярністю повертатися до цілей проектів, переконуватися, що вони для компанії ще актуальні і затверджувати їх у нових посадових осіб. Те ж саме актуально для вимог.
І, звичайно, якщо в компанії змінюється топ-менеджер, який має безпосереднє відношення до вашого проекту - необхідно переконатися, що він про проект знає і що з тим, що він принесе зазначені вигоди і на нього буде витрачено зазначені гроші і ресурси, згоден (як максимум - заручитися підтримкою, як мінімум - підстрахуватися, щоб потім не виявилося, що він ні до чого, гроші витрачені, а ви крайній).
6. Бриф проекту
Бриф - хороша штука, що дозволяє в розтягнутому за часом проект не забути, а навіщо, власне, це все, і особливо про те, що розумне, добре і світле несе проект і для кого він робиться. Детально я писала про брифі тут.
Ось і все, правила прості, але їх дотримання допоможе утримати проект на короткому повідку і не дати людям втратити фокус на ньому. Іноді, виконуючи якісь з вказаних вище пунктів (особливо п.5), можна зрозуміти, що проект вже нерелевантен і компанії не потрібен. Цей той самий випадок, коли не дивлячись на вже витрачені гроші, краще підняти питання про його закриття. Завзято догризть кактус і зробити те, що не потрібно нікому - це не той досвід, який вам потрібен як керівнику проекту. А вміння вчасно зрозуміти і визнати правду і особливо сказати менеджменту "все, гроші викинуті на вітер, пропоную далі їх не викидати і проект закрити і почати новий" - безцінне, і є одним із доказів вашого професіоналізму.
Всім коротких проектів і швидких перемог!
Давайте не губитися - підпишіться прямо зараз!
Чому не варто питати "чому"