Впровадити CRM.
Автоматизувати процес.
Описати бізнес-процеси.
Такі формулювання регулярно використовуються як цілі проектів.
Ми розуміємо, що проекти завжди мають на меті впровадження змін. Наприклад:
Впровадити CRM.
Чи описує це зміну?
Так.
CRM не було - CRM з'явилася.
Тобто відбулася цілком реальна зміна:
CRM відсутня → CRM впроваджена.
Тому проблема формулювання «впровадити CRM» не в тому, що воно взагалі не описує зміни.
Питання в іншому:
Чи є зміна стану CRM саме тією зміною системи, заради якої існує проект?
І ось тут починається більш цікава розмова про пошук цілі проекту.
Ціль починається з правильного об'єкта зміни
У межах методу Kushko System я використовую таке визначення цілі:
Ціль проекту - цільовий стан релевантного об'єкта змін, необхідний і достатній для задоволення потреби, що стала підставою для проекту, досягнення якого знаходиться в межах суттєвого керованого впливу проекту.
Де:
Потреба - необхідність досягнення, зміни або збереження певного стану системи, що стала підставою для ініціювання проекту.
Логіка визначення цілі у спрощеному вигляді:
Потреба → Релевантний об'єкт зміни → Необхідний і достатній цільовий стан → Перевірка можливості забезпечити цей стан засобами проекту
Ключове слово тут - релевантний.
Тому що в проекті можуть одночасно існувати кілька різних об'єктів.
Наприклад, у CRM-проекті є:
- сама CRM-система
- дані
- робота менеджерів із лідами
- управлінська звітність
- система оперативного управління продажами.
CRM при цьому може бути не кінцевим об'єктом зміни, а лише засобом зміни іншої системи.
Але тут з'являється ще один принципово важливий момент.
Релевантний об'єкт зміни не можна визначати виходячи з того, чим проекту зручно або легко управляти.
Послідовність має бути іншою:
Спочатку визначаємо, що насправді потрібно змінити. Лише після цього перевіряємо, чи здатний проект це забезпечити. Не навпаки.
Інакше замість задоволення потреби можна дуже швидко отримати зручну для управління, але нерелевантну ціль.
Продукт проекту ≠ об'єкт зміни
Розглянемо типовий кейс.
У компанії:
- дані про клієнтів і угоди знаходяться в Excel, пошті та особистих записах
- частина лідів втрачається
- немає інформації про стан активних угод за етапами
- управлінська звітність формується вручну з різних джерел.
Після цього компанія запускає проект:
Впровадити CRM.
CRM дійсно з'явиться.
Але яка потреба спричинила появу проекту?
Просто мати CRM, тому що так прийнято?
Не зовсім.
Потреба полягає в тому, щоб змінити спосіб організації роботи з лідами, угодами та інформацією про продажі.
Тобто для задоволення потреби має змінитися стан іншого об'єкта:
системи роботи з лідами, угодами та інформацією про продажі.
CRM - рішення, яке ми обрали для забезпечення цієї зміни.
Тому маємо дві різні зміни.
Перша:
CRM відсутня → CRM впроваджена.
Друга:
Фрагментована робота з лідами та угодами → Робота в єдиному актуальному інформаційному контурі.
Обидві описують реальні зміни.
Але вони описують різні об'єкти.
І тільки одна з них безпосередньо відповідає потребі, що стала підставою для проекту.
А CRM у цьому випадку - не релевантний об'єкт цільової зміни, а засіб зміни стану іншої системи.
Простий тест
Звідси виникає дуже практичне питання:
Якщо проектний продукт буде повністю створений, але стан системи, для зміни якого виникла потреба, не зміниться - чи можемо ми вважати ціль досягнутою?
У нашому прикладі:
CRM налаштована.
Дані перенесені.
Інтеграції працюють.
Користувачі навчені.
Система введена в промислову експлуатацію.
Але при цьому:
- менеджери продовжують вести частину угод у Excel
- дані в CRM неактуальні
- керівники не використовують CRM для оперативного управління
- інформація про активні угоди, як і раніше, збирається вручну.
Чи досягнуто ціль?
Якщо ціль:
Впровадити CRM
— формально так.
Якщо проект існував для зміни способу управління продажами - ні.
Тобто у формулюванні цілі ми успішно підмінили релевантний об'єкт зміни вторинним - проектним продуктом.
Саме тут проектний продукт підміняє ціль проекту.
І саме так виникає імітація результативності:
діяльність є, продукт створено, а потрібна зміна системи не відбулася.
Але існує й менш очевидний варіант тієї самої помилки.
Можна не зупинятися на «впровадити CRM», а сформулювати ціль, наприклад, так:
Забезпечити ведення всіх активних угод у CRM.
Це вже зміна способу роботи.
Вона знаходиться в бізнес-системі, а не тільки в самому продукті.
І проект, ймовірно, здатний її забезпечити.
Але якщо вихідна потреба передбачала також актуальність даних, єдиний інформаційний контур та можливість використовувати ці дані для оперативного управління, такої зміни недостатньо.
Ми просто звузили ціль до тієї частини системи, якою зручно управляти.
Тому питання не тільки в тому, чи знаходиться ціль у межах керованого впливу проекту.
Потрібно перевірити ще одне:
Чи є визначений цільовий стан необхідним і достатнім для задоволення потреби, що стала підставою для проекту?
Саме тому об'єкт зміни та необхідний цільовий стан повинні визначатися до перевірки доступних проекту важелів управління.
Якщо після цього виявляється, що проект не здатний забезпечити потрібну зміну, це не означає, що потрібно звузити ціль до зручного рівня.
Це означає, що потрібно переглянути контекст проекту або визнати розрив між поставленою ціллю та можливістю проекту її забезпечити.
А як бути з лопатою?
Тут виникає важливе уточнення.
Для зовнішнього підрядника результатом проекту наче може бути сам продукт.
Наприклад:
CRM-система, готова до промислової експлуатації.
І якщо саме це визначено в межах його відповідальності, проект підрядника може вважатися успішним після створення, перевірки та передачі такого продукту.
Але тут важливо зрозуміти, що саме продає підрядник.
Умовно кажучи, він може продавати:
лопату
або:
траншею.
Якщо підрядник продає лопату, він обмежує свою відповідальність продуктом.
У такому випадку він не бере на себе відповідальність за те, що система роботи замовника реально зміниться.
Але чи повинно це влаштовувати замовника продукту?
CRM може бути чудово реалізована, але спроектована під інший бізнес, інші процеси або інший спосіб роботи.
Тобто ключова потреба замовника залишиться незадоволеною.
Тому одночасно можуть бути правдивими два твердження:
проект підрядника успішно завершений
і
потреба замовника не задоволена.
У цьому немає суперечності.
Просто підрядник відповідав за продукт, який не гарантує задоволення потреби замовника.
Тобто задоволення цієї потреби не входило до наміру підрядника.
Але навіть у такому випадку творець продукту не може проектувати його у відриві від цільового стану системи, для зміни якої цей продукт створюється.
Будь-який творець проектного продукту повинен чітко розуміти цільовий стан релевантного об'єкта змін, для досягнення якого створюється цей продукт.
І цього недостатньо.
Він повинен бути здатний вивести з цього розуміння конкретні та перевірювані вимоги до продукту.
Логіка тут виглядає так:
цільовий стан об'єкта → вимоги до продукту → перевірювані параметри продукту
Тобто навіть якщо підрядник продає «лопату», він повинен розуміти, яку саме траншею нею мають викопати.
Інакше виникає фундаментальний розрив:
продукт може повністю відповідати формальним характеристикам, але бути недостатнім для досягнення цільового стану системи замовника.
Інша ситуація - коли підрядник продає траншею.
Тобто бере на себе відповідальність не тільки за створення CRM, а й за досягнення визначеного стану системи замовника.
Наприклад:
Робота з лідами та активними угодами переведена в єдиний актуальний інформаційний контур, а дані CRM використовуються для оперативного управління продажами.
У цьому випадку релевантний об'єкт зміни, цільовий стан і критерії його підтвердження повинні входити в контекст проекту підрядника.
Тоді наша логіка не потребує жодної модифікації.
Підрядник відповідає не тільки за Вихід, а й за Результат.
Проблема виникає в іншому місці:
коли замовнику продають «лопату», а очікування формуються так, ніби йому продали «траншею».
Саме тут виникає розрив між виконаним контрактом і незадоволеною потребою.
Тому для замовника важливо ще до вибору рішення визначити:
яку зміну системи потрібно отримати і за яку частину цієї зміни реально бере відповідальність постачальник.
А для постачальника - зрозуміти:
який цільовий стан системи повинен забезпечити його продукт і які вимоги до продукту з цього випливають.
Інакше можна придбати якісний інструмент, який повністю відповідає технічному завданню, але так і не отримати результат, заради якого цей інструмент купувався.
Саме це ми дуже часто і спостерігаємо на практиці.
Вихід, результат і ефект
Щоб не змішувати різні рівні - розділимо три сутності:
Вихід → Результат → Ефект
Вихід
Вихід - матеріальний чи інформаційний продукт, створений або змінений у результаті проектної діяльності.
Наприклад:
CRM-система, готова до промислової експлуатації.
Це продукт проекту.
Він може включати:
- налаштовану систему
- перенесені дані
- необхідну управлінську звітність
- інструкції та навчальні матеріали.
Це продукт проекту, створений для забезпечення цільової зміни системи.
Але ще не обов'язково цільова зміна системи.
Результат
Результат - це фактично досягнутий змінений стан релевантного об'єкта.
Наприклад:
Робота з лідами та активними угодами здійснюється в CRM як у єдиному актуальному інформаційному контурі, а актуальні дані використовуються для оперативного управління продажами.
Тепер ми говоримо вже не про CRM.
Ми описуємо, як після проекту працює система продажів.
Ефект
Далі виникають наслідки отриманого результату:
- менше втрачених лідів
- зростання конверсії
- збільшення продажів.
Це вже бізнес-ефекти.
І тут виникає друга принципова межа.
Коли ціль знаходиться занадто високо
Інша крайність - покласти на проект відповідальність за бізнес-ефект:
Збільшити продажі на 15%.
Формулювання виглядає переконливо.
Є конкретний результат.
Є цифра.
Його легко виміряти.
Але виникає інше питання:
Чи має саме цей проект достатній керований вплив, щоб відповідати за +15% продажів?
Припустимо, CRM-проект реалізований ідеально.
Активні угоди ведуться в системі.
Дані актуальні.
Керівники використовують інформацію CRM.
Новий спосіб роботи стабільно функціонує.
Але одночасно:
- ринок скоротився
- компанія підвищила ціни
- маркетинг зменшив кількість лідів
- сильні менеджери звільнилися
- конкурент випустив кращий продукт.
Продажі впали на 5%.
Якщо ціллю проекту було:
Збільшити продажі на 15%
доведеться визнати, що проект свою ціль не досяг.
Але чи справді це означає, що проект провалився? Ні.
Можливо, помилка виникла ще до його запуску:
проекту делегували відповідальність за зміну, критичні фактори досягнення якої знаходяться поза межами його суттєвого керованого впливу.
І це вже не просто проблема формулювання цілі.
Це дефект архітектури відповідальності.
Проект може створювати передумови для отримання ефектів.
Але:
впливати на результат і мати можливість його забезпечити - не одне й те саме.
Де насправді знаходиться ціль проекту
Тепер можна скласти повний ланцюжок:
Проектна діяльність → Вихід → Результат → Ефект
Для CRM це може виглядати так:
налаштувати CRM, перенести дані, інтегрувати системи, навчити користувачів → CRM готова до промислової експлуатації → робота з лідами та угодами здійснюється в єдиному актуальному інформаційному контурі → зростають продажі
При русі вправо, як правило, збільшується кількість факторів, які знаходяться поза безпосереднім управлінням проекту.
Але це не означає, що ціль потрібно просто рухати вліво до першої точки, яка повністю підконтрольна проекту.
Спочатку потрібно визначити релевантний об'єкт зміни та необхідний і достатній цільовий стан.
І лише після цього перевіряти, чи має проект достатній керований вплив для його забезпечення.
Тому ціль конкретного проекту повинна одночасно відповідати трьом умовам:
- Описується саме та зміна релевантного об'єкта, заради якої проект існує
- Цільовий стан цього об'єкта є необхідним і достатнім для задоволення потреби
- Проект має контур управління, достатній для забезпечення цієї зміни.
Таким чином, помилитися можна в трьох напрямках.
З одного боку:
підмінили ціль проектним продуктом і не визначили зміну системи, заради якої його створювали.
Другий варіант:
звузили об'єкт або цільовий стан до зручної керованої частини, недостатньої для задоволення потреби, що стала підставою для проекту.
З іншого:
взяли на себе відповідальність за бізнес-ефект, який знаходиться за межами достатнього керованого впливу проекту.
Ціль знаходиться не просто «десь посередині» між продуктом і бізнес-ефектом.
Вона визначається від потреби і релевантного об'єкта зміни, а межі керованості проекту виступають перевіркою того, чи може проект нести за неї відповідальність.
А як щодо Project Management?
У підходах PMI використовується конструкція:
Output → Outcome → Benefit
За змістом вона досить близька до:
Вихід → Результат → Ефект
Output - те, що створено.
Outcome - що реально змінилося внаслідок використання створеного продукту.
Benefit - яку корисність організація очікує отримати внаслідок цієї зміни.
Але для проектування проекту як керованої системи цього розподілу недостатньо.
Потрібно поставити ще одне питання:
Де в цьому ланцюжку закінчується достатній керований вплив проекту?
Benefit може чудово пояснювати, навіщо організація взагалі інвестує в проект.
Саме заради benefit проект може бути започаткований.
Але це ще не означає, що конкретний проект здатний цей benefit гарантовано забезпечити.
Тому:
Проект може існувати заради ефекту, за який він сам не може нести повну відповідальність.
У цьому немає суперечності.
Проблема виникає тоді, коли очікуваний ефект автоматично стає ціллю проекту, хоча проект не має достатнього контуру управління для його забезпечення.
Чому SMART недостатньо
Розглянемо формулювання:
Збільшити продажі на 15% до 31 грудня.
Ціль може прекрасно пройти перевірку SMART.
Вона конкретна.
Вимірювана.
Має строк.
Але SMART не відповідає на два принципові питання.
Критерій Achievable частково перевіряє досяжність цілі, але досяжність і наявність у конкретного проекту достатнього контуру управління для її забезпечення - не одне й те саме.
Перше:
Чи є це саме тією зміною релевантного об'єкта, яка необхідна і достатня для задоволення потреби?
Друге:
Чи має суб'єкт, якому делегована ця ціль, достатній вплив на критичні фактори її досягнення?
Тому перевірку цілі варто починати не зі SMART.
Спочатку потрібно відповісти на фундаментальні питання:
Яка потреба стала причиною проекту?
Стан якого об'єкта насправді потрібно змінити?
Який його стан буде необхідним і достатнім для задоволення потреби?
І тільки після цього:
Чи здатний проект забезпечити цю зміну?
І вже потім уточнювати показники, строки, допустимі відхилення, спосіб підтвердження результату.
Добре сформульована некерована ціль від цього не стає хорошою ціллю.
Так само як керована ціль не стає хорошою лише тому, що її зручно досягати, якщо вона недостатня для задоволення потреби, що стала підставою для проекту.
Як визначити ціль проекту
Практично я використовую п'ять послідовних кроків.
1. Визначити потребу:
Що саме стало підставою для виникнення проекту?
Не:
Нам потрібна CRM.
А:
- якого стану системи необхідно досягти
- чого бракує в поточному стані
- яку проблему необхідно вирішити.
Наприклад:
Компанії необхідно забезпечити керовану роботу з клієнтами та активними угодами на основі актуальної інформації.
На цьому етапі ще не потрібно виходити з того, чим майбутньому проекту буде зручно управляти.
Ми спочатку визначаємо потребу, що стала підставою для проекту.
2. Визначити релевантний об'єкт зміни:
Стан якого об'єкта повинен змінитися, щоб потреба була задоволена?
Це може бути:
- бізнес-процес
- інформаційний контур
- організаційна модель
- система управління
- виробнича система
- інфраструктура.
У нашому прикладі це:
система роботи з лідами та активними угодами.
Важливо: об'єкт зміни визначається з потреби, а не з доступних проекту інструментів і повноважень.
3. Визначити необхідний і достатній цільовий стан:
Що конкретно повинно стати інакше, щоб потреба була задоволена?
Наприклад:
Робота з лідами та активними угодами здійснюється в єдиному актуальному інформаційному контурі, дані якого використовуються для оперативного управління продажами.
Тепер ми маємо не просто рішення, а цільовий стан.
На цьому етапі важливо не звужувати його тільки тому, що окрему частину зміни простіше забезпечити.
4. Відокремити проектний продукт від цільової зміни:
Потрібно поставити питання:
Чи є зміна стану створюваного проектом продукту тією зміною, заради якої існує проект, чи сам продукт є лише засобом зміни іншої системи?
CRM, ERP, регламент, нова оргструктура, PMO, система мотивації, автоматизована система - усе це може бути проектним продуктом.
Але факт створення продукту ще не доводить, що отримано потрібну зміну системи.
Саме тому потрібно перевірити:
Що станеться, якщо продукт буде створений, а система продовжить працювати так само, як до проекту?
Якщо в такому випадку ми не можемо визнати проект успішним - ціль знаходиться не на рівні продукту.
5. Перевірити керованість і можливість підтвердження:
Тільки тепер переходимо до питання можливостей самого проекту.
Перше:
Чи має проект контур управління, достатній для забезпечення необхідного цільового стану?
Якщо ні, проблема знаходиться не в цілі.
Потрібно перевірити, чи може бути змінений контур самого проекту так, щоб він отримав достатні можливості для забезпечення результату.
І лише якщо це неможливо, виникає питання про коректність контексту проекту.
Звужувати ціль лише для того, щоб вона стала зручно керованою, не можна - у такому випадку ми просто перестанемо задовольняти вихідну потребу.
Друге питання:
Чи можемо ми до завершення проекту підтвердити, що цей стан фактично отримано?
Наприклад, для CRM можна перевірити:
- чи ведуться визначені активні угоди в CRM
- чи актуальні критичні дані
- чи відсутній паралельний обов'язковий контур ведення угод
- чи формується необхідна управлінська інформація на основі CRM
- чи використовують її керівники
- чи підтримується новий стан протягом визначеного контрольного періоду.
Тільки після цього ціль стає повноцінним об'єктом управління.
Цю логіку можна пройти на практиці в інструменті Kushko System - Контекст проекту.
Він допомагає послідовно зафіксувати ціль, виходи, результат, показники, ресурсне забезпечення та контур управління проектом.
Ціль і результат - у чому різниця?
Якщо і ціль, і результат описують стан системи, виникає логічне питання:
Чим вони тоді відрізняються?
Відповідь проста.
Ціль - необхідний і достатній цільовий стан релевантного об'єкта змін, який повинен бути досягнутий.
Результат - фактично отриманий і підтверджений стан цього об'єкта після реалізації проекту.
Тобто:
Ціль - куди повинні прийти.
Результат - куди фактично прийшли.
Саме тому між ними повинна існувати пряма логічна відповідність.
Якщо результат не дозволяє підтвердити досягнення цілі - десь у конструкції проекту є розрив.
А навіщо тоді потрібен ефект?
Без нього проект теж не має сенсу.
Наприклад:
Результат: робота з активними угодами здійснюється в єдиному актуальному інформаційному контурі.
Навіщо бізнесу це потрібно?
Щоб:
- зменшити втрати лідів
- прискорити управлінську реакцію
- підвищити конверсію
- зрештою - збільшити продажі.
Це формує бізнес-сенс проекту.
Але бізнес-сенс і відповідальність проекту - не одне й те саме.
Проект може створюватися заради ефекту, не маючи можливості самостійно його гарантувати.
І це нормально.
Ненормально - не розрізняти ці два рівні.
П'ять питань для перевірки цілі проекту
У підсумку достатньо послідовно поставити п'ять питань:
1. Яка потреба стала причиною виникнення проекту?
2. Стан якого об'єкта повинен змінитися, щоб потребу було задоволено?
3. Яким має бути необхідний і достатній цільовий стан цього об'єкта?
4. Чи не підмінили ми цільову зміну створенням проектного продукту або зручною для управління, але недостатньою частиною необхідної зміни?
5. Чи має проект контур управління, достатній для забезпечення цієї зміни, та чи може її досягнення бути підтверджене в межах проекту?
І тут принципова послідовність:
Спочатку визначаємо, що насправді потрібно змінити. Лише після цього перевіряємо, чи здатний проект це забезпечити. Не навпаки.
Якщо на всі п'ять питань є чіткі відповіді, ціль проекту, швидше за все, знаходиться на правильному рівні.
Проблема визначення цілі проекту значно глибша, ніж вибір правильного дієслова або використання SMART.
Помилитися можна щонайменше тричі.
Перший раз - вибрати не той об'єкт зміни і підмінити необхідну зміну системи створенням засобу її реалізації.
Другий - звузити об'єкт або цільовий стан під зручну керованість і в результаті отримати зміну, недостатню для задоволення вихідної потреби.
Третій - вийти за межі керованості проекту і покласти на нього відповідальність за бізнес-ефект, на який він лише впливає.
Тому хороша ціль проекту для мене - це:
цільовий стан релевантного об'єкта змін, необхідний і достатній для задоволення потреби, що стала підставою для проекту, досягнення якого знаходиться в межах суттєвого керованого впливу проекту.
Тоді стає зрозуміло:
- що саме ми змінюємо
- навіщо нам потрібні проектні продукти
- за який результат відповідає проект
- де закінчується його відповідальність
- який бізнес-ефект обґрунтовує саму необхідність проекту.
І тільки після цього має сенс детально проектувати роботи, виходи, ресурси, строки, бюджет та повноваження.
Інакше можна дуже професійно реалізувати проект - і лише наприкінці виявити, що ми успішно змінили не той об'єкт або змінили його недостатньо.
Перевірте ціль свого проекту
Якщо хочете перевірити цю логіку на власному проекті - скористайтеся інструментом аналізу контексту проекту Kushko System.
Він дозволяє не тільки сформулювати ціль, а й перевірити її зв'язок із результатом, виходами, показниками, ресурсами та контуром управління проектом.