Комментарии 12
Слегка верхнеуровневая статья, хотелось больше реальных практических примеров. Но принцип "не делаем то, чего не понимаем" прекрасный, всем бы так
Здорово, что вы разделяете наши принципы:) какую часть статьи вам было бы интересно раскрыть через практический пример?
Интересно посмотреть на путь какого-то конкретного проекта по этим этапам, со всеми сложностями
Потому что в теории все выглядит красиво, а на практике наверняка какая-то дичь вылазит
Я боюсь, что конкретный проект не смогу вам показать (NDA история), но если чуть конкретнее, я могу очертить с какими проблемами мы уже столкнулись:
1) качество планирования проектов - мне кажется, что это сложная история всегда, поэтому мы не одиноки. Как ни странно, чаще всего сталкиваемся с неоправданно амбициозными сроками (чаще всего по причине потерянного куска объема). Работаем над этим путем личного вовлечения или включения в работу над проектом тех, кто уже умеет в планирование.
2) Своевременное согласование изменений к проекту - тут тоже вопрос. В первую очередь мы стремимся закрывать его постоянной коммуникацией с РП, могу сказать, что уже появляются примеры, в которых РП приходят не когда срок сдачи подошел, а когда изменение действительно требуется утвердить, для меня это хороший сигнал. При этом сказать, что это на сегодня повсеместно внедренная практика у нас, я не могу.
3) Достаточно сложно дается история с написанием конкретных критериев успешности проекта - измеримые метрики вроде как понятны, но вот декомпозировать их на те, которые действительно будут достигнуты благодаря проекту, а какие случились за счет других факторов - сложно. Ну и вторая часть: отделить бизнес-цель проекта от критериев успешности не всегда бывает просто. Работаем, тренируемся, другого тут быть не может, со временем все придет, я уверен.
В целом, если говорить о нашей системе, мы живем с новой логикой примерно 4 месяца, сказать, что все раз и получилось, ну нет. Так не бывает :) Так что с дичью тоже приходится работать, разбираться в причинах, которые ее вызвали, систему калибровать... нудно, монотонно и неромантично :)
Данил, прекрасная статья! После прочтения было желание отправить своему руководству, но увы, это было бы очередным бисером, т.к. такие изменения возможны только по инициативе и при поддержке с самого верха.
У меня, как у ПМ, возникло несколько практических вопросов:
Какой уровень проработки стадий "Инициатива" и "Запуск"? Насколько детально определены scope и бюджет?
Из статьи следует, что после одобрения Инициативы, до Запуска инициатор лично прорабатывает проект, это так? На этом этапе команда еще не формируется и ПМ не назначен?
Закладываете ли резервы по расписанию и бюджету? Как их определяете?
Как решается вопрос нехватки/конфликта ресурсов в проектах?
Спасибо:) уверен, что у вас тоже все удастся. Отвечая на ваши вопросы:
Инициатива - это когда я что-то хочу поменять и понимаю выгоду/ценность этого, смог в этом убедить заказчика, но пока нет конкретики, как именно идти (не сформирован скоуп, требования, ограничения и т.д.). Собственно на этом этапе мы просим очертить выгоды, актуализировать проблематику (почему нельзя оставлять как есть) и показать, что нужно, чтобы проработать инициативу. На стадии Запуска мы уже говорим о вполне конкретных требованиях, объеме, ресурсах, команде и т.д., который как раз между Инициативой и Запуском прорабатывается. То есть здесь уже все максимально детально должно быть (не всегда получается, но замысел в том, чтобы снизить уровень неопределенности до предела и сформировать конкретные коммитменты от команды к Компании)
В нашей методике доведение проекта до запуска это роль Инициатора, все верно. Так как чаще всего это человек из бизнеса, то в усиление ему могут выделять на период проработки проф. ПМ, например, для ИТ части. Решение о выделении или невыделении ПМ на этом этапе принимается в зависимости от ожидаемой сложности и масштабности проекта. При этом, ведущая роль в любом случае остается за Инициатором.
Резервы по бюджету мы закладываем, наша методика предполагает стандартный резерв в объеме 20% от бюджета проекта, это средство демфирования неопределенности, потерянных требований и способ сократить объем процедур согласования. При этом есть определенный регламент авторизации и использования резерва, эта часть бюджет не является по умолчанию бюджетом проекта. В отношении сроков - единой методики нет, но есть ряд рекомендаций, я сторонник использования буфера времени, степень точности его оценки и объем, который закладывается - определяется на запуске. Здесь мы совместно с инициатором и будущим РП выравниваемся и принимаем решение, как будет формироваться запас по времени. Резерв по времени мы просим в явном виде показывать на запуске, чтобы у всех была полная картина.
Дефицит в ресурсах - самый острый вопрос для всех, мне кажется. Решаем путем коммуникаций в первую очередь. Плюс к этому, как я написал, у нас единый корпоративный коллегиальный орган по управлению проектами, поэтому синхронизация проводится в том числе и там.
Надеюсь, что удалось ответить на ваши вопросы :)
У нас магазин настольных игр, плюс клуб настольных игр, и еще разные проекты.
Попробовали Conflurence. он оказался слишком огромным и объемным, там еще специалист нужен отдельный)))
Всякие инструкции и документацию мы ведем на https://logycore.net/ Он очень простой и удобный. Возможностей меньше чем в Conflurence, но для маленьких проектов подходит. главное сотрудников не пугает)
Еще пробовали notion тоже очень сложно оказалось)))
Отличная статья!
Что царапнуло: "Quality Gate – эксперты по проектной деятельности, которые помогают руководителям"
Гейт - эксперт? Могли развернуть идею?
Спасибо, рад, что откликается. Под этим неочевидным термином кроется понятный процесс контроля. Контролируем два аспекта: суть и форму. Смотрим на то, что качество проработки соответствует требуемому уровню, условно "все понятно", деталей достаточно, все существенные атрибуты проекта есть. Форма - тут все совсем просто. Есть ряд шаблонов (по разным поводам), надо, чтобы эти шаблоны были корректно заполнены, потому что документация это важно. В чем, наверное, ключевое отличие нашей контрольной функции от привычной, мы скорее партнер, чем контролер, не ставим штамп "переделать" без объяснений. Живем в диалоге с бизнесом, РП, заказчиком, стараемся раскрыть назначение и смысл каждого пункта, фразы, показателя, слайда. Иногда и в обратную сторону работает, когда это обосновано, корректируем наш шаблон под конкретный проект. Стало чуть понятнее? Возможно в самой статье не очень аккуратная формулировка получилась :)
Данил, приветствую! Отличная, практичная статья! Скажите, OKR применили только для проекта преобразования проектной деятельности? Применимо ли, на Ваш взгляд, OKR внутри каждого проекта? Модель портфельного управления не рассматривали?
Добрый вечер :) целеполагание - самая тонкая материя. Очень хочется измеримые и достижимые цели, потому что от их достижения очень много чего зависит (мотивация и мотивированность в основном). Конечно, можно использовать целеполагание по OKR в проектах. Самое важное, чтобы команда понимала что с такими целями делать, а менеджмент понимал, что цель, поставленная по OKR это что-то большое и светлое и относился к фактически достигаемым результатам соответственно. Это все же определенная мировоззренческая трансформация, поэтому мы не используем такой подход для каждого проекта (по крайней мере не возводим его во главу угла), наше целеполагание ближе к классике KPI и SMART.
К портфельному управлению мы постепенно подходим, я думаю, что добежим в следующем году, делать его без сквозной автоматизации уже трудновато, поэтому сначала базовые вещи решим, а потом будем подниматься на уровень программ и портфелей.
Реформа проектного управления: как устроена целевая модель для наведения порядка в процессах