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

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

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

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

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

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

Возникает вопрос, а нужен ли со стороны компании-заказчика руководитель проекта, ведь он будет со стороны ИТ-разработчика?

Давайте разберемся с тем, что нужно сделать для успешного внедрения CRM.

Успешным проект будет признан в случае достижения целей в срок и в рамках бюджета. Кто будет отвечать за это? Можно ли передать проект «под ключ» ИТ-компании и быть уверенным, что она успешно его реализует? Глядя на статистику успешности ИТ-проектов, я бы не строил иллюзий, что передача проекта «под ключ» повышает вероятность успеха. Как мы можем повлиять на сотрудника другой компании в случае форс-мажора? Если срок будет провален, то можно, конечно, разорвать договор и остаться с незаконченным продуктом и полным непониманием того, что с ним делать дальше.

Итак, мой ответ на вопрос о руководителе со стороны заказчика однозначен: он нужен. Именно этот специалист будет отвечать за успех проекта. Руководитель со стороны компании-заказчика будет участвовать в:

• планировании и контроле
• отслеживании графика работ
• принятии решений об изменениях в плане так, чтобы уложиться в срок

Чем же будет заниматься заказчик? Его ответственность в том, чтобы:

• четко сформулировать цели и необходимые результаты
• организовать сбор требований к результатам и утвердить их

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

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

2. Совмещение ролей. Теперь представьте, что руководителем внедрения CRM назначили начальника отдела продаж и его же определили заказчиком. Из-за отсутствия опыта в управлении проектами он явно допустит ошибки при планировании, чем заложит «бомбу» под всю работу. А совмещение двух ролей приведет к тому, что он начнет исправлять допущенные при планировании ошибки через компромисс с самим собой (в вопросах требований к CRM-системе). Например, ИТ-компания не успевает реализовать функционал, связанный с получением отчетов по сделкам. Специалист может отказаться от этой опции. А на этапе запуска системы, в случае неудачи, все свалить на ИТ-компанию или сотрудников, которые не умеют пользоваться программой.

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

3. К чему приводит непонимание роли заказчика проекта - со стороны сотрудника, который на эту роль назначен?

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

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

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

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

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

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

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

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

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

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