Помилки проджект менеджера у реалізації проєкту

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

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

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

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

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

1.Прийом проекту на етапі його заведення без достатньої кількості інформації

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

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

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

Як уникнути? Приймати проект в присутності всіх учасників, які вже познайомилися з наданими матеріалами, які, можливо, вже дали оцінку проекту, з якими можна одночасно обговорити і синхронізувати наявну на вході інформацію, з якої проджект менеджеру згодом доведеться працювати більш детально. Просіть передачу знань оформляти у вигляді документа. Це може бути google-doc або сторінка в Confluence - не має значення. Аби ви завжди змогли повернутися до оформленого документу і орієнтуватися на нього в процесі подальшої роботи з клієнтом і з командою, а не шукати відповіді на питання у sales-менеджера.

2. Розрахунок термінів в залежності від кількості вільних виконавців

Уявімо ідеальний світ, в якому, коли заходить новий проект, необхідні виконавці в повному складі, абсолютно не задіяні ніде більше, сидять дружно і чекають повного завантаження і занурення в проект з головою без будь-яких на те обмежень. Уявили? А тепер забудьте. Тому що насправді такого не буває. Вічний біль багатьох компаній - це "Є проекти - немає ресурсів, є ресурси - немає гідних проектів". І так завжди. І цим потрібно вміти жонглювати. З цим потрібно вміти працювати. Це потрібно враховувати при плануванні термінів проекту, а також при плануванні навантаження того чи іншого виконавця. Досвідчений проджект менеджер ніколи не візьме рівно 3 бізнес дня на завдання, яке команда оцінила в 24 години. Так як до моменту здачі цього завдання клієнту напевно пройде більше часу, враховуючи чималу кількість факторів, що впливають на потрапляння в термін. Це і зайнятість даного виконавця на паралельному проекті, і наявність у команди мітингів, які не входили в оцінку завдання, і ризики, пов'язані з можливістю допуску помилки при виконанні і необхідності виправити зроблене. І тут найскладніше - це пояснити потім клієнту, що завдання, оцінене в 24 години, не буде готова завтра в цей же час доби (рівно через 24 години).

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

3.Команді не донесена кінцева мета проекту

Ось вас вже інтегрували в проект, ви познайомилися з клієнтом, поспілкувалися з ним, з'ясували те, що вам було потрібно / важливо / цікаво, і відразу ж підготували команді розробників умовно-зрозумілі завдання (припустимо, юзер-сторі) з виставленою в тікети оцінкою (припустимо, вам оцінку підготував тім-лід підрозділу). Як ви думаєте, що ви отримаєте? Групу людей, яка виконує окремі один від одного завдання, не розуміючи, що повинно бути у результаті з точки зору бізнес-продукту. Як наслідок - продукт може технічно працювати коректно, але не відображати мету, яку передбачав замовник.

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

4.Відсутність проміжних контрольних точок на тривалому проекті

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

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

5.Відсутність контролю

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

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

6.Надмірний контроль і спроби все робити самому

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

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

7.Нечіткий розподіл обов'язків

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

Що робити? На старті проекту заведіть зручний, доступний всім учасникам команди документ, де зафіксуйте, хто за що відповідає, хто що виконує. Рекомендовано використання матриці RACI, про яку можна почитати додатково. Пам'ятайте - за все-все в проекті не відповідає проджект-менеджер! Якщо ви так вважаєте, будь ласка, зупиніться. У кожного члена команди є своя зона відповідальності, за яку він і буде відповідати на кожній контрольній точці.

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

8.Відсутність ведення проектної документації або несвоєчасна її актуалізація

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

Одними з найважливіших документів проджект менеджера є: технічне завдання (специфікація, SOW), реєстр зацікавлених сторін (Stakeholder Map), розклад проекту (Project Schedule), Meeting Notes (Kick off Meeting, planning Meeting, Stand-up Meeting, Retrospective), матриця відповідальності по проекту, реєстр ризиків (Risk RegisterForm), журнал змін (іноді називають Change Requests), weekly Project Status Report, документація від тестувальників (Test Plan і т.п.) і інші.

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

9.Замовчування проблем, що виникають в процесі ведення проекту

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

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

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