В шапке
Ключевые проблемы при реализации внутренних проектов компании

Ключевые проблемы при реализации внутренних проектов компании

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

Перечислю топ-7 ключевых, с моей точки зрения, проблем внутренних проектов из своей более чем 10-летней практики управления внутренними проектами:

  • Отсутствие штатного сотрудника, компетентного в управлении проектами;
  • Совмещение роли заказчика и руководителя проекта в одном лице;
  • Непонимание заказчиком проекта своей роли в проекте или неадекватное выполнение этой роли;
  • Отсутствие у сотрудников компании мотивации на участие во внутренних проектах;
  • Выделение запланированного времени на внутренний проект не по плану;
  • Отсутствие у сотрудников практики отчетности за выполнение задач по проекту;
  • Отсутствие правил приемо-сдаточных испытаний при сдаче результатов проекта.

Рассмотрим проблемы на примерах, после чего разберем способы их решения.

Допустим, компания решилась на проект внедрения CRM-системы. При этом принято решение о том, что доработку программного продукта, в случае необходимости, будет делать сторонняя ИТ-компания.

Возникает вопрос: нужен ли стороны компании руководитель проекта, ведь он будет в ИТ-компании? Давайте разберемся с тем, что нужно сделать, чтобы проекта внедрения CRM был признан успешным. Это произойдет в случае достижения целей проекта в срок и в бюджет. Кто будет отвечать за это? Можно ли передать проект «под ключ» ИТ-компании и быть уверенным в том, что она сделает успешный проект? Глядя на статистику успешности ИТ-проектов (см. тут:  http://project-management.zis.by/statistika/vestibulum_iaculis.html), я бы не строил иллюзий относительно того, что передача проекта «под ключ» повышает вероятность его успеха. Как мы можем повлиять на сотрудника другой компании? В случае невыполнения проекта в срок разорвать договор и остаться с незаконченным программным продуктом при полном непонимании, что с этим продуктом делать дальше? Итак, мой ответ на вопрос «нужно ли иметь руководителя проекта со стороны заказчика» очевиден. Именно он, а не руководитель со стороны ИТ-компании, будет отвечать за успех проекта. Руководитель проекта со стороны компании-заказчика будет участвовать в планировании и контроле проекта, отслеживать отставания от расписания и принимать решения, как можно изменить план проекта так, чтобы успеть реализовать его в срок.

Чем же будет заниматься заказчик проекта CRM? Ответственность заказчика проекта в том, чтобы четко сформулировать цели и результаты проекта, организовать сбор требований к результатам проекта и утвердить их. По мере получения промежуточных результатов заказчику нужно знакомиться с ними, давать обратную связь относительно правильности реализации требований к результатам проекта и по завершении организовать приемо-сдаточные испытания результатов проекта и принять их. Заказчиком проекта лучше выбрать того сотрудника компании, который будет пользоваться результатами проекта (или чьи сотрудники будут пользоваться ими).

В отличие от руководителя проекта, заказчик не должен разбираться в тонкостях того, как спланировать и проконтролировать проект, как вносить изменения в ход проекта и т.д. Подробнее о ролях в проекте я писал здесь: http://project-management.zis.by/komanda-proekta/roli-v-proekte.html

Теперь представьте, что руководителем проекта внедрения CRM назначили начальника отдела продаж и его же определили как заказчика проекта. В силу отсутствия опыта в управлении проектами начальник отдела продаж явно допустит ошибки при планировании проекта, чем заложит «бомбу» под проект. А совмещение двух ролей приведет к тому, что он начнет исправлять допущенные при планировании проекта ошибки через компромисс с самим собой относительно требований к CRM-системе. ИТ-компания не успевает дописать функциональность продукта, связанную с получением отчета по состоянию сделок? Откажемся от нее… А потом на этапе запуска системы, в случае неудачи, все свалим на ИТ-компанию или нерадивых сотрудников, которые не умеют пользоваться программой. Мое убеждение заключается в том, что между руководителем проекта и заказчиком должен быть здоровый конфликт интересов, который заключается в том, что руководителю проекта нужно сдать проект в срок и в бюджет, а заказчику проекта – получить ожидаемый результат и начать его использовать для решения его проблем. Поэтому я выступаю за то, чтобы во внутренних проектах не совмещать роль руководитель проекта и заказчика в одном человеке.

К чему приводит непонимание роли заказчика проекта сотрудником, назначенным на нее? Обратимся к примеру с проектом CRM. Во-первых, начальник отдела продаж должен понимать, что, будучи заказчиком проекта, он должен принимать все решения, касающиеся требований к результатам проекта. Он должен брать на себя ответственность по принятию таких решений, а не пытаться переложить ее на руководителя проекта или спонсора проекта, иначе это приведет к срыву сроков всего проекта. Во-вторых, начальник отдела продаж должен отвечать за согласование всех требований к результату проекта, а не только тех, что нужны для улучшения показателей работы его отдела. А с этим может быть сложность, т.к. требования других подразделений, скорее всего, будут казаться не столь важными, и заказчик проекта может ими пренебречь.

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

Проблема с выделением запланированного времени на проект заключается в том, что в случае совмещения работы сотрудников в проекте и одновременной их занятости в регулярной деятельности приоритет, скорее всего, будет отдаваться регулярной работе, а это поставит под угрозу своевременное выделение ресурсов на проект и развалит даже хорошо спланированный проект. Подробнее об этом я написал здесь: http://project-management.zis.by/planirovanie-proekta/kak-zagubit-horoshij-plan-proekta.html

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

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

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

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

Итак, проблемы внутренних проектов разобрали, перейдем к рекомендациям:

В заключение хочу заметить, что мой опыт не покрывает всех возможных проблем внутренних проектов и, возможно, я упустил что-то важное. Если у вас есть другие описания и решения проблем внутренних проектов, жду ваших предложений в комментариях к статье. Подумайте об этом!

 

Комментарии (0)
Войти как