Нужно ли обосновывать ценность от проектного управления руководству организации? (еще один ответ на риторический вопрос)

Для меня этот вопрос звучит почти так же, как «Нужно ли объяснять разницу покупателю между Ладой и BMW?». Если такой вопрос возник, то может быть и не стоит пытаться ничего доказывать.

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

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

Для других же руководителей бизнесов, зачастую до поры до времени крайне успешных, все это «проектное управление» приравнивается к «методологии, которая никому не интересна».

Когда в организации появляются инициативные сотрудники и руководители, которые понимают, что результаты проектов не устраивают как руководство, так и заказчиков, а также выжигают руководителей и команду проектов, и при этом видят в инструментах проектного управления возможность исправить ситуацию, возникает вопрос: «как продать проектное управление / проектный офис руководству?».

Но, нужно ли продавать проектное управление, обосновывать его, доказывать на цифрах его эффективность, прежде чем начать применять?

На мой взгляд, дело это не слишком перспективное. Ключевым фактором успеха является осознанность руководства, а не точный расчет эффекта. Хотя я не исключаю то, что отдельные инструменты и практики могут при этом применяться на уровне команды или подразделения, но не организации в целом.

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

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

Доступные открытые исследования и бенчмарки настолько обобщенные и субъективные, то ими можно пользоваться разве что для первичного разговора о пользе проектного управления.

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

Что же делать?

1) Искать острые и распознаваемые руководством проблемы (достаточно начать с типичных кейсов)

2) Подтверждать их частоту, значимость или стоимость

3) Прояснять причины данных проблем

4) Если предпринимались усилия, чтобы устранить причины – выяснить, почему они не сработали, кому это выгодно

5) Показывать, как проектное управление может помочь их устранить

Например:

1) Выделенные на проект сотрудники подразделения A фактически не участвуют в проекте с нужным % загрузки, что привело к сдвигу формирования ТЗ на X месяцев

2) Для того, чтобы нагнать срок проекта, пришлось закупать оборудование у поставщика со склада по цене на Y% выше, чем в случае, если можно было бы сделать предзаказ. В 50% проектах требуется срочная закупка оборудования из-за несвоевременной подготовки ТЗ.

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

4) Не было возможности отказаться от выполнения проекта при этом заменить назначенного сотрудника в отведенный срок невозможно.

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

Что на этом пути можно сделать не так?

1) Взять проблему, которая не интересует руководство, и волнует, например, только исполнителей или руководителей проектов

2) Взять проблему, частоту, значимость или стоимость которой невозможно объективно посчитать или получить подтверждение от признанных для руководства организации экспертов

3) Подменить поиск причин отсутствием какого-либо инструмента «проблема в том, что у нас нет методологии проектного управления, информационной системы управления проектами»

4) Считать, что данную проблему никто и никогда не пытался решить, т.е. все дураки или не заинтересованы

5) Ну и наконец, показать инструменты проектного управления в отрыве от проблем конкретных проектов и программ, их последствий, причин возникновения и механизма устранения

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

Есть другой вариант, «продавать» инструменты, например, внедрение «информационной системы управления проектами», это опасный, хотя зачастую один из немногих работающих путей. Основная трудность — восприятие внедрения ИСУП, как отдельно стоящей от организационных изменений задачи.

В итоге «продажа» внедрение инструментов проектного управления на уровне организации в отсутствии внятного заказа от топ-руководства, наличия внутренних успешных кейсов и применения или необходимых полномочий у инициатора даже, если окажется успешно, может привести к печальным последствиям в будущем (об этом отдельный пост).