✨ Интересный опыт прохожу прямо сейчас с одним из своих любимых заказчиков - пытаемся определить несколько бизнес-инициатив как проект(-ы).
То, что заказчик понимает, что сложными задачами с участием многих команд разных иерархий надежнее управлять по проектной методологии - это уже круто!
Нюанс в том, что за годы жизни в Agile многие забыли с чего проект начинается и чем определяется, а кроме того появилось поколение менеджеров, которые эти времена даже не застали.
✍️В до Agile-времена была обязательная фаза инициации проекта, итогом которой был документ Устав (Паспорт) проекта.
По сути это был стартовый контракт между вовлеченными сторонами.
В уставе фиксировались: цели, границы, ключевые участники, критерии успеха, ограничения и допущения проекта.
Корпоративные проектные офисы адаптировали соответствующие шаблоны из проектных методологий PMBOK или IPMA к специфике каждой компании.
Более того,
на базе содержимого этого документа и принималось решение go/don't go - т.е. идти дальше с этим проектом или нет (или доработать и выступить еще раз).
🏃♀️Что сейчас?
⭕️Agile приучил многих к мысли: «Главное — начать, детали уточним в процессе».
⭕️Исчезли шаблоны документа "Устав проекта" и исчез повод подумать о важных для проекта вещах
- теперь о них часто на старте и не думают вовсе.
⭕️Распространенный подход менеджера в Agile: «Зачем неделю писать документ, если можно за два дня сделать прототип?».
👉Следствие: даже при выборе проектного подхода возникает желание пропустить этап инициации, быстро согласовать план и побежать.
🐈Граблей у такого подхода предостаточно:
от того, что команды понимают цели проекта по-разному или не понимают вовсе,
до того, что в проекте "внезапно появляется" новый заказчик или заинтересованное лицо, которого забыли спросить, но без которого внедрить проект или продукт нельзя.
🧐Поэтому мы решили уделить время фазе инициации проекта, но не формально - а по сути.
Коллеги подготовили описание своего проекта, как они его видят.
Я заглянул в найденный на просторах интернета фрагмент PMBOK 8 про этап инициации, использовал как стартовую шпаргалку и добавил важное исходя из своего опыта, чего мне в описании не хватило.
Обсуждаем, как договоримся - зафиксируем.
📝Получился вот такой список вопросов с минимальным пояснением, которым делюсь -
берите, используйте кому подойдет:
👨⚖️Кто ответственный менеджер от Заказчика за задачу под ключ?
Важно, что это - не стейкхолдер (не Project Sponsor), это - именно его представитель, готовый выделять ресурс на оперативное управление и глубокое участие в проекте на уровне менеджера.
🤔 Зачем мы эту задачу реализовываем?
Ради роста дохода, сокращения расходов, повышения лояльности клиентов, иное?
Можно кратко описать "что" хотим делать, но точно не нужно описывать "как" мы это хотим делать.
📈 Какие бизнес-метрики успеха проекта и КПЭ?
С детализацией, достаточной для признания результата проекта успешным/не успешным и для контроля изменений скоупа в ходе реализации.
👤👥 Какие стороны участвуют в проекте и в какой роли?
Кто главный интересант, кто Заказчик(-и), кто со-Заказчик(-и), кто - смежник, кто - просто предоставляет сервис и в проекте не участвует, без кого успех невозможен?
✍️ Есть ли входящие договоренности и заданные условия?
То, что проект принимает как данность на момент старта. Например, две стороны уже заключили договор, в рамках которого планируют реализовывать проект.
✋Какие границы у проекта?
Фиксируется общее понимание в деталях, за что отвечает и, главное, за что не отвечает проект - иначе есть риск взять под крыло необъятное.
🪫 Какие у проекта ограничения?
Заранее заданные на вход ограничения, например по бюджету, ресурсам или по скоупу проекта, которые влияют на результат и которые важно зафиксировать "на берегу".
❓ У кого-нибудь есть что добавить или с чем поспорить?
==
Важно помнить, что проектное управление не является волшебной таблеткой и некоторые задачи действительно проще и быстрее реализовать в Agile, но это уже совсем другая история ©️