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