Методологія впровадження – навіщо це потрібно?
Напевно, кожен, хто стикався з більш-менш відповідальними фахівцями з впровадження, стикався з поняттям «методологія впровадження». Про це говорять всі — й хороші продавці (саме хороші), й консультанти, й експерти/аудитори. У даній статті я б хотів зупинитися, скоріше, не на описі конкретної методології (концептуально всі методології, що успішно себе зарекомендували, за великим рахунком, однакові), а на тому — навіщо методологія потрібна і як вона може допомогти замовнику.
Мені досить часто доводилося стикатися з позицією, що проект залежить від людей. Буде кваліфікована команда — буде й проект успішним. Позиція має право на існування, якщо не брати до уваги те, що успіх проекту — це ще й виконання термінів.
Наприклад, стоїть завдання з побудови процесу управління маркетинговими кампаніями, який повинен бути «прив’язаний» до певного терміну виведення продукту на ринок. Процес створений. Він відповідає всім вимогам, але запущений в роботу з відставанням на 1-2 місяці. Чи можна такий проект назвати успішним?
Чим же може допомогти методологія для «успіху» проекту?
Спочатку визначимося з поняттями… Якщо відкинути все зайве й сказати коротко, то «методологія впровадження» – це рекомендації про те, в якій послідовності та як виконувати завдання. Іноді методологія включає шаблон план-графіка проекту, який також містить терміни виконання цих завдань. Зазвичай методології створюються як результат аналізу безлічі успішних (і не дуже) проектів.
Перед тим, як відповісти на питання «навіщо нам методологія?», Подивимося на основні проблеми, які виникають на проекті:
- «Якість» рішення – зробили не те, що потрібно (частину просто забули або зробили не так)
- Тривалість проекту:
- недоступність «необхідних» людей (як не дивно – питання до замовника);
- обсяг і характеристики вимог змінювалися в ході проекту;
- не виконувалися процедури запобігання появи проблем (управління ризиками).
- Недостатньо кваліфікована команда впровадження
Як правило, ці проблеми «перегукуються» на проектах. Поява однієї проблеми призводить до решти. Наприклад, недоступність персоналу замовника частіше проявляється на проектах у некваліфікованої команди тощо.
Методологія, серед іншого, надає такі інструменти, що дозволяють виключити вплив перерахованих вище проблем (інструменти розташовані по пріоритетності):
- Контрольні точки
Є такий «професійний» жарт: «Колеги, як же ми на півроку затягнули проект? Потроху, колеги, потроху». Контрольні точки дають нам можливість протягом усього проекту контролювати стан робіт. Дуже поширена ситуація, коли результат робіт аналізують при настанні години «Х» (наприклад, часу прийому-здачі робіт), коли щось виправляти вже пізно. Загалом, контрольні точки – це обов’язковий елемент будь-якого проекту. При цьому методологія «говорить» нам про те, які точки специфічні при впровадженні саме даного продукту (у багатьох продуктів може бути своя специфіка). Достатня деталізація і контроль дозволять на ранніх стадіях, як мінімум, виявити проблеми кваліфікації команди та термінів проекту й внести корективи в хід проекту
- Обґрунтування для залучення ресурсів замовника
Як правило, замовник зацікавлений в успіху проекту не менше виконавця. Проблема нестачі ресурсів виникає на тих проектах, де компанія або в принципі не готова до впровадження, або керівництву компанії не «донесли» розуміння основних питань (навіщо потрібно виділити людей на проект, чим вони будуть займатися, що буде, якщо цього не зробити тощо). Методологія дає докладний опис всіх необхідних робіт, що є гарною підмогою для обґрунтування керівництву замовника рекомендацій по залученню ресурсів.
- Шаблони документів і опис послідовності робіт
Часто спостерігав, коли люди на проектах (іноді одні й ті ж люди на наступних проектах) витрачали час на «фантазії»: «як би нам описати ось ці роботи». Ці «фантазії» породжують кілька проблем:
- команда втрачає час на обговорення шаблонів документів, порядку контролю робіт і т.д.;
- придумуючи «велосипед», команда може пропустити важливі блоки інформації в структурі документів, що призводить до недостатньої обробки даних і збоїв в подальшій роботі.
Хороша методологія визначає структуру документів, призначення та способи їх застосування. Перевірка наповнення документів дозволяє замовнику контролювати якість і повноту вирішення його завдань.
Крім описаних вище, методологія дає відповіді на безліч інших питань, які допомагають керівникам проекту якісно управляти процесом впровадження. Безумовно, досвідчений керівник проекту, який успішно завершив 2-3 проекти, буде використовувати методологію тільки як «шпаргалку». Більш того, іноді методології є надлишковими, та деякі їх положення потребують спрощення. Однак коригувати рекомендації методології, на мою думку, можуть тільки ті фахівці, які розуміють всю «таємницю» процесів і ризиків впровадження специфічного рішення.
Співробітник, що керує проектом з боку замовника, як правило, не є професійним керівником проекту. Для нього методологія – це інструмент контролю знань і навичок команди виконавця.
Ну і наостанок...
Наведу кілька порад замовнику для виявлення – чи дійсно фахівці виконавця використовують методологію впровадження.
Попросіть на «передпродажному» етапі надати вам таку інформацію:
- ресурси (Інтернет, електронні носії тощо), де можна ознайомитися зі стандартною методологією, яку команда використовує для впровадження;
- опис фаз, на які буде розбитий проект впровадження, а також чіткий і детальний перелік (по кожній фазі):
- завдань, що вирішуються в рамках фази (що робиться, ким і з якою метою);
- проміжних контрольних точок;
- отриманих результатів.
- організаційна структура проекту – опис ролей (завдання, відповідальність) за проект;
- вимоги до співробітників замовника (в тому числі вимоги кваліфікації та досвід роботи), які повинні бути залучені на проекті;
- шаблони найбільш важливих документів проекту (по можливості, заповнені приклади цих документів за іншими проектами без конфіденційної інформації);
- опис процедур управління проектом (як будуються плани, як ведеться контроль робіт, як виконується контроль якості, процедури управління ризиками тощо);
- які зміни є в роботі команди виконавця в порівнянні зі стандартною методологією впровадження (як правило, такі зміни є в більшості випадків).