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