31 авг 2020

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

Для кого:
  • Руководители проектного офиса
  • Руководители проектов
Знания и навыки:
  • Внедрение изменений
  • Коммуникации
Время на чтение:
  • 4 минуты

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Например:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Авторы статьи:
Андрей Малахов
Прокомментировать статью
Подписаться
Уведомить о
0 комментариев
Межтекстовые Отзывы
Посмотреть все комментарии
Смотрите также:
31 Мая 2024
Что такое PMBok и как его применять
В этой статье подробнее расскажем о международном стандарте по управлению проектами PMBoK: что это такое, для каких проектов лучше всего подходит, из чего состоит, преимущества и недостатки стандарта.
13 Мая 2024
Что такое уровни управления
Уровни управления в организации — это ступени иерархической структуры, которая обеспечивает порядок, а также распределение ответственности и полномочий между сотрудниками. Во главе структуры стоит тот, кто управляет компанией: генеральный или исполнительный директор, которому подчиняются управленцы нижестоящего уровня. Менеджеры, стоящие “под” главой предприятия, контролируют следующий, также нижестоящий, уровень руководителей.
26 Апр 2024
Что такое проектный треугольник и зачем он нужен проджекту
Что из себя представляет проектный треугольник и как его применяют в  управлении проектами? Как использование этого инструмента позволяет объяснить заказчику, что качественный продукт, сделанный в короткие сроки, стоить дешево не может?  В чем отличия треугольника при использовании в гибких методологиях от применения в классическом подходе Waterfall?
Подписаться на рассылку
Высылаем анонсы статей и полезные материалы
Прокомментировать статью
Текст сообщения
Имя, Отчество, Фамилия
Email

Комментарий успешно отправлен

Произошла ошибка при отправке. Попробуйте еще раз

Наверх
Здравствуйте! Если возникли вопросы, мы на связи.
Скопировано в буфер обмена