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