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

На цьому етапі Квонг радить, як:

• підтримувати комунікаційні лінії чіткими та відкритими, розуміти, коли треба проявити гнучкість і відхилитися від плану, а коли залишатися твердим і дотримуватися термінів;
• не забувати про загальну картину (та дивитися на неї з різних боків основної ідеї) й бачити на кілька кроків вперед;
• зберігати динаміку роботи команди.

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

Вибрані поради із другого розділу читайте в тексті «Команда, дедлайни та показники успіху: докладні інструкції для медіаменеджерів про старт проєкту»

Стартова зустріч

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

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

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

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

Ще один виклик у створенні максимально інклюзивної стартової зустрічі — призначити її на час, коли всі зможуть прийти. Пріоритетно вам треба орієнтуватися на розклад тих, хто є «відповідальними» та «підзвітними» на матриці RACI. 

Вступ до зустрічі

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

Роз’яснюйте та визначайте терміни

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

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

«Парковка»

Аби не затримуватися через запитання щоп’ять хвилин, можна використати техніку «парковки». Для цього створіть пустий слайд із написом «парковка» десь у видимому для групи місці на екрані, який транслюєте, у Miro чи Jamboard, у спільному документі або на фліпчарті для офлайн-зустрічей. 

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

Який результат зустрічі?

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

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

Обговорення часових рамок

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

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

Заповнення решти графіка

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

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

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

Канали комунікації

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

• Робочий канал. Це місце для щоденної комунікації. Його учасниками мають бути лише ті, хто безпосередньо працює над проєктом. Це місце, де будь-який член команди точно може зв’язатися з іншим колегою для розв’язання робочих питань. Для цього призначені платформи обміну повідомленнями, такі як Slack або Microsoft Teams.
• Регулярні зустрічі проєктної команди. Це зустрічі активних учасників проєкту для синхронізації та обговорення питань у групі, а також для підтримання динаміки роботи. Керівник проєкту може на них повідомляти, чи все рухається за планом (аби всі спільно з’ясували, чи є прогрес). Зазвичай це щотижнева зустріч для довготривалих проєктів або щоденна для короткотривалих.
• «Джерело правди» про проєкт та його статус. Це документ для всіх, хто хоче знати фундамент проєкту (основну ідею, цілі, RACI тощо) та його поточний статус. Він має бути чітким, стислим і постійно оновлюватися. 
• Оновлення на ключових етапах для тих, хто безпосередньо не залучений у проєкт. Така комунікація в більшій групі може відбуватися як у формі зустрічі, так і через електронний лист. Такі апдейти корисні для тих, хто є в колонці «підзвітні» на матриці RACI, а також для менш залучених членів команди. За них відповідає менеджер проєкту. Активним членам команди, ймовірно, взагалі не потрібно бути в цьому каналі, адже там дублюватиметься інформація, яку вони вже знають.
• Поточна документація та довідкова інформація. На відміну від документа «джерело правди», який дає лише актуальний зріз проєкту, цей документ містить його повну історію (наприклад, протоколи зустрічей), а також покликання на будь-які довідкові матеріали (наприклад, технічні документи, конкурентний аналіз, попередні дослідження). Це має бути окремий від проєктного брифу документ. Поміж іншого, цей канал допоможе підготувати післяпроєктні презентації та зустрічі-рефлексії. На додаток до ведення журналу того, що відбулося, можна коментувати його своїми думками про те, що пройшло добре, а що ні. Робити такі нотатки в процесі важливо для довготривалих проєктів, де можна забути початкові зустрічі та обговорення до кінця роботи.

Підбиття підсумків

Стартова зустріч має завершитися зобов’язанням дотримуватися плану й домовленістю про наступні кроки, які виникли під час обговорення графіку. Треба чітко переконатися, що активні учасники проєкту знають, що їм робити далі, або коли вони почнуть свою частину роботи.

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

Поки робота виконується

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

Обізнаність

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

Моніторинг робочого каналу та встановлення регулярних нарад для синхронізації допоможуть досягти цього балансу. Утім, немає готового рішення — доведеться покладатися на свій досвід. Є безліч інструментів для управління завданнями, які допоможуть залежно від складності проєкту: Kanban, Jira, діаграми Ганта, Airtable тощо.

Комунікація

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

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

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

Ухвалення рішень

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

Аби проєкт не збивався з курсу через нові події, медіаменеджер FT Strategies радить запровадити базові процеси контролю за змінами. Наприклад, можна вести журнал запропонованих змін (і позначати, як кожна з них пов’язана з основною ідеєю чи як допоможе проєкту досягти цілі та показників успіху). Потім їх можна обговорювати всією командою під час регулярних зустрічей. Матриця RACI також допомагає визначити, кого треба залучити до ухвалення рішень.

Регулярні зустрічі проєктної команди

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

Тримати стейкхолдерів у курсі 

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

• Як вони можуть копнути глибше?

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

• На що розраховувати далі?

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

• Коли й на що потрібно звертати увагу?

Основна інформація, яку стейкхолдер має отримати зі звіту, — той факт, що проєкт просувається гладко, без подробиць. Однак іноді вам потрібно, щоб вони звернули увагу та долучилися до процесу (особливо якщо вони в діаграмі «підзвітні» або «консультовані»). Проєктному менеджеру треба переконатися, що увагу зацікавленої сторони привернули (наприклад, буквально позначити конкретний пункт «***ВАЖЛИВО***»).

Коротко про впровадження аналітичного відстеження

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

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

«Я виокремлюю це завдання для згадки, тому що його легко не помітити перед запуском і опинитися без потрібних даних потім», — зауважує Робін Квонг.

Ще кілька важливих нюансів

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

• Щоразу порівнюйте новий обсяг проєкту після раунду змін з основною ідеєю. Ви можете виявити, що фактично відмовилися від початкового задуму й тепер займаєтесь інакшим проєктом. Це нормально, але це означає, що треба написати нову версію основної ідеї й переглянути свої цілі. Не обов’язково проходити весь процес планування проєкту заново. Про «швидкі та брудні» кроки Квонг розповідав у другій частині посібника — їх буде цілком достатньо.

• Після того, як команда визнає та погодиться з тим, що варто відмовитися від початкового проєкту, треба повністю відмовитися й від його початкової ідеї. Можна просто сказати команді: «Почнімо з чистого аркуша. У нас є лише два тижні, тому головне, що ми маємо спробувати зробити, — це зробити ось що. Забудьмо про початкову ідею, наприклад, курсу в розсилці, й поміркуймо, як встигнути все за два тижні».