10 типичных ошибок при внедрении проектного управления. Часть 2
Илья Едигарьев, руководитель департамента внедрения компании «Адванта Консалтинг
Мы продолжаем разговор о промахах и ошибках на старте внедрения системного управления проектами, начатый в первой части публикации.
6. Проектными офисами и проектами внедрения КСУП часто руководят непрофессионалы. Чаще всего, мы сталкиваемся с этим в компаниях, которые находятся в начале пути внедрения принципов управления проектами. Формирование проектных офисов в последнее время необычайно распространено, а как организовать этот процесс, понятно лишь немногим. Во главе проектных офисов становятся зачастую случайные люди. «Витя, ты же работал до нас в проектном институте?» или «Марина Сергеевна, когда вы в прошлом году проводили аудит на складе, вы же называли это проектом?» Положительные ответы на эти вопросы, чаще всего, НЕ означают, что найден подходящий кандидат.
Почему не стоит недооценивать сложность управления проектами?
- Руководитель проекта – самостоятельная специальность. Чтобы управлять проектом разработки, недостаточно быть отличным программистом. Чтобы управлять проектом строительства – мало быть даже архитектором. Об этом написано много книг, и руководителю, затеявшему создание проектного офиса, важно знать хотя бы основные тезисы.
- Подумайте над тем, чтобы привлечь ключевых специалистов со стороны. В специальности РП очень важная составляющая – это опыт, то есть «курс молодого бойца» и пара прочитанных книжек помогут далеко не всегда. Если говорить о роли руководителя проектного офиса (РПО), нужна и вовсе максимальная экспертиза. Конечно, знания о вашей компании, специфике ее процессов и ее бизнеса тоже важны. Конечно, никто не утверждает, что программист не может стать РП. Важно взвесить все «за» и «против» и принять такое решение, которое позволит добиться от внедрения лучших результатов.
- Не назначайте на роли РП/РПО топ-менеджеров. Даже если проект является ключевым для вашей компании. Никто не помешает директору давать ценные указания и участвовать в переговорах, однако работа по управлению проектами гораздо шире, и вечно занятый руководитель не сможет ее обеспечить.
7. Стремление сделать из системы управления проектами единую систему для управления всеми процессами компании. Тема учета трудовых ресурсов связана с вопросами кадрового учета. Отслеживать исполнение финансовых планов невозможно без первичной информации от бухгалтерии. План проекта будет неполным без учета поставок, а для планирования поставок нужны данные складского учета. Разрывать эти связи, казалось бы, нельзя – иначе мы не увидим цельной картины деятельности компании, зато получим проблемы дублированного ввода, расхождения данных и слабую управляемость всей компанией.
Что здесь не так?
- Система управления проектами – только часть информационного ландшафта вашей компании. Кадровый и бухгалтерский учет придется вести в другой системе. Если у вас есть склад, то вам понадобится система управления складом. Если есть собственное производство – вероятно, потребуется система класса MRP. Не нужно бояться этого разнообразия, не стоит стараться автоматизировать всю жизнь компании с помощью одного инструмента, особенно если инструмент не предназначен для этого.
- Информационная система предприятия должна быть единой – это верно. Однако не стоит отождествлять понятие информационной системы и программного продукта. Практически любое современное бизнес-приложение имеет средства интеграции. Выберите оптимальные продукты для реализации своих процессов, наладьте между ними информационный обмен – их совокупность и будет вашей Единой Системой управления бизнесом.
8. Заказчик требует немедленных результатов. Проекты внедрения системы Advanta тем и замечательны, что делаются быстро и эффективно – за 2-4 месяца. Приближается дата завершения совместной работы, и заказчик спрашивает: ну что, насколько удалось сократить отставания в проектах? Какие проекты завершилось в срок? Затраты снизились? В бюджет теперь укладываемся всегда? Ресурсных конфликтов больше нет?
Что ответить заказчику?
- Не путайте результаты проекта и результаты, которые принесет в дальнейшем продукт проекта – внедренная и постоянно используемая система. Постпроектный мониторинг – крайне полезный процесс. Кстати, мы тоже можем его автоматизировать и внедрить.
- Планируйте достижимые и простые результаты, которые непременно должны быть получены на короткой дистанции активного внедрения: например, все проекты зарегистрированы в системе; проведено две-три цикла обновления планов проектов; все пользователи обучены и аттестованы.
- Обычно до внедрения КСУП у заказчика нет ретроспективных данных. Какими были средние отставания по задачам и проектам, и как часто возникал дефицит ресурсов – никто просто не знает. Итак, отдельно планируйте отложенные эффекты – результаты, которые требуют длительных измерений: полгода, год. Редко статистика по проектам будет показательной в более коротком периоде.
- Когда будете закреплять договоренности с заказчиком (см. п. 5), не забудьте поговорить о разных типах результатов.
9. Неправильно организованы проектные комитеты. Отклонения по этой части могут быть самыми разными, вот два полярных варианта: а) проектные комитеты не проводятся вообще, и б) для принятия любого худо-бедно значимого решения по проекту требуется собрание всей управляющей верхушки компании, не меньше 10 человек. Такие практики существуют у заказчика годами, изменить ситуацию при внедрении бывает непросто.
А как правильно?
- Выделите проектный комитет в отдельное периодическое событие. Иногда он называется иначе: инновационный комитет, совещание по проектам и т.д. Главное, чтобы он проводился с одинаковой периодичностью и составом участников.
- Постарайтесь привлекать для решений не больше 5 человек, строго необходимый минимум. Возможно, вам понадобится несколько таких коллегиальных органов: например, на одном – ежемесячном – будут приниматься решения о старте и остановке проектов, а на другом – еженедельном – разбираться текущие статусы и проблемы.
- Разработайте повестку: какие вопросы обсуждаются и в каком порядке, никогда от нее не отклоняйтесь.
10. Сложившаяся практика управления мотивирует замалчивать свои прогнозы о будущих отклонениях в проектах. Принципы и методы управления изменениями, казалось бы, широко известны, однако достаточно часто мы наблюдаем такой подход. Исполнитель задачи или руководитель проекта убеждены в том, что они не вправе даже разговаривать о любых отклонениях в рамках своей задачи. Особенно – в части сроков завершения. Ведь план утвержден, даты спущены сверху и подписаны условным директором.
Однако практика такова, что отклонения случаются, и в результате все узнают о них только тогда, когда они произошли, когда зачастую уже слишком поздно решать проблему.
А как иначе?
- Мало спланировать проект, его план нужно регулярно актуализировать. Повод для актуализации – не только факт просрочки или выполнения задачи, но также любой прогноз по будущим отклонениям.
- Да, невыполненная в срок задача – это зло. Но гораздо большее зло – не актуализированный план; замалчивание проблем; неучтенные изменения.
- При внедрении системы обеспечьте мониторинг не только данных по просроченным задачам, но и показателей своевременной актуализации планов.
Удачи! Надеюсь, этот текст поможет вам обойти хотя бы несколько острых углов. Если что – обращайтесь, будем обходить их вместе.
