Андрей Малахов | от проектов к изменениям

Недавно спорил с заказчиком о том, как описывать проектную деятельность – через процесс или результат. Он настаивал на том, чтобы разрабатываемая нами методология была представлена в виде описанных процессов, а я объяснял, почему это делать бесполезно👇

Обычно деятельность компаний описывается в виде бизнес-процессов – логически связанных последовательных шагов. Типовой пример: размещение заказа на закупку, планирование производства, согласование договора… Понятные, последовательные шаги – основа в большинстве корпоративных информационных систем (ERP, CRM и т.д.)

❗️ Однако в проектной деятельности пошаговое описание процессов не работает. Да, верхнеуровнево проект представляет собой последовательность укрупненных шагов – фаз, этапов. Но ежедневная деятельность руководителя проекта, регулярный менеджмент – это цикличные, повторяющиеся действия, которые бессмысленно описывать в виде процессов (процесс – это всегда цепочка шагов, которая идет линейно).

Единственная ситуация в проектном управлении, где описание процесса в виде шагов оправданно, это локальные процедуры – подготовка отчетности, запуск проекта, согласование запроса на изменение и т.д.

В жизни последовательность шагов в проектном управлении может постоянно меняться, что делает почти любой описанный процесс формальным и оторванным от реальности. 

Поэтому описывать методологию проектного управления в виде процессов – очень плохая идея. Все, что нужно, чтобы методология работала – фокусироваться на результате (артефакте). И если этот результат качественный, с нужным содержанием и согласован с нужными людьми, то этого более, чем достаточно, чтобы все участники проекта понимали, за что они отвечают и что от них требуется.

Как этот результат сделан – вторично. Для новичков, чтобы сделать результат быстрее, можно подготовить инструкцию с описанием шагов. Однако это про оптимизацию процесса, а управление проектами это всегда фиксация договоренностей и взаимных ожиданий в виде результатов, ролей, событий (совещаний, встреч).

❓ Ок, но ведь нашему заказчику работать со схемами процессов более привычно – так более понятно, что и после чего нужно выполнять. 

Поэтому, чтобы внести ясность в последовательность его действий и при этом не скатиться в описание процессов, у нас родилась идея👇

💡Для каждого артефакта указать предшествующий артефакт. Например, предшественник календарного плана это дорожная карта, а предшественник дорожной карты это договор. Такое решение позволяет видеть, на что опирается каждый артефакт, помогая заказчику выстраивать логику действий.

Мы предложили заказчику взять тайм-аут и подумать, подходит ли ему такое решение. Клиент в итоге согласился.

Коллеги, на следующей неделе планирую поделиться с вами итогами года в PMLogix🚀 Киньте реакций, если интересно🔥

#кейсы #управление_проектами

Please open Telegram to view this post

VIEW IN TELEGRAM

www.tgoop.com/UzhiEzh/704

857 viewsedited  Dec 19 at 08:59

Недавно спорил с заказчиком о том, как описывать проектную деятельность – через процесс или результат. Он настаивал на том, чтобы разрабатываемая нами методология была представлена в виде описанных процессов, а я объяснял, почему это делать бесполезно👇

Обычно деятельность компаний описывается в виде бизнес-процессов – логически связанных последовательных шагов. Типовой пример: размещение заказа на закупку, планирование производства, согласование договора… Понятные, последовательные шаги – основа в большинстве корпоративных информационных систем (ERP, CRM и т.д.)

❗️ Однако в проектной деятельности пошаговое описание процессов не работает. Да, верхнеуровнево проект представляет собой последовательность укрупненных шагов – фаз, этапов. Но ежедневная деятельность руководителя проекта, регулярный менеджмент – это цикличные, повторяющиеся действия, которые бессмысленно описывать в виде процессов (процесс – это всегда цепочка шагов, которая идет линейно).

Единственная ситуация в проектном управлении, где описание процесса в виде шагов оправданно, это локальные процедуры – подготовка отчетности, запуск проекта, согласование запроса на изменение и т.д.

В жизни последовательность шагов в проектном управлении может постоянно меняться, что делает почти любой описанный процесс формальным и оторванным от реальности. 

Поэтому описывать методологию проектного управления в виде процессов – очень плохая идея. Все, что нужно, чтобы методология работала – фокусироваться на результате (артефакте). И если этот результат качественный, с нужным содержанием и согласован с нужными людьми, то этого более, чем достаточно, чтобы все участники проекта понимали, за что они отвечают и что от них требуется.

Как этот результат сделан – вторично. Для новичков, чтобы сделать результат быстрее, можно подготовить инструкцию с описанием шагов. Однако это про оптимизацию процесса, а управление проектами это всегда фиксация договоренностей и взаимных ожиданий в виде результатов, ролей, событий (совещаний, встреч).

❓ Ок, но ведь нашему заказчику работать со схемами процессов более привычно – так более понятно, что и после чего нужно выполнять. 

Поэтому, чтобы внести ясность в последовательность его действий и при этом не скатиться в описание процессов, у нас родилась идея👇

💡Для каждого артефакта указать предшествующий артефакт. Например, предшественник календарного плана это дорожная карта, а предшественник дорожной карты это договор. Такое решение позволяет видеть, на что опирается каждый артефакт, помогая заказчику выстраивать логику действий.

Мы предложили заказчику взять тайм-аут и подумать, подходит ли ему такое решение. Клиент в итоге согласился.

Коллеги, на следующей неделе планирую поделиться с вами итогами года в PMLogix🚀 Киньте реакций, если интересно🔥

#кейсы #управление_проектами