corada.ru
Как сделать, чтобы проект взлетел?
21.09.2017
155

Как сделать, чтобы проект взлетел?

В прошлый раз мы говорили о причинах того, почему проекты не взлетают (то есть, не достигают ожидаемого результата вообще, или достигают его не так как хотелось бы – с превышением сроков, бюджетов, или запаса нервных клеток). Достаточно подробно я проанализировал разные причины, которые приводят к неудовлетворительным результатам. 

Время прочтения: ~ 8 минут 46 секунд Нет времени читать?

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

Почему же не получилось?

Когда проект не удался

1. Требования к проекту

  • Не описаны должны образом, не извлечены из заказчика, или поменялись в ходе проекта.
  • Всплыли принципиально нерешаемые проблемы.
  • В том числе, отдельно важно, не зафиксированы требования к системе отчетности.

2. Работа с системой

  • Люди не умеют работать в системе, и не могут/не хотят научиться.
  • В системе нет данных в нужном виде (истории, необходимых разрезов аналитики, или текущие данные некорректно заносятся).

3. Бюджет

  • Изменения бюджета из-за расширения требований. 
  • Изменение отношения заказчика к проекту (и его бюджету – то есть, сам бюджет не поменялся, но по субъективным ощущением, стало «что-то многовато»).

4. Срыв сроков

  • Недооценка объема и сложности работы.
  • Сопротивление сотрудников и руководства заказчика. 
  • Смена команды в ходе проекта (с любой стороны).
  • Недооценка степени участия заказчиком в проекте.

5. Ожидания заказчика не совпали с результатом
(в худшую сторону)

И что с этим делать?
Попробуем попунктно пройти по всему списку.

Проблемы с зафиксированными (или нет) требованиями 

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

Люди не умеют работать в системе, и не могут/не хотят научиться

Люди не умеют работать в системе

Что тут скажешь – обучение, это отдельная наука. И заниматься ей должны люди, которые умеют это делать. Как минимум, они должны быть стрессоустойчивыми, разговаривающими на языке пользователя, идеально знать типовые конфигурации (продукты, которым будут обучать).

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

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

Проблемы с бюджетом
 А где бюджет?

Для начала возвращаемся к самому началу – максимально подробно фиксируем требования. Эти подробные требования должны быть оценены и рассчитаны так же подробно :)

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

Обе стороны в самом начале должны четко договориться:

  • Что входит в периметр проекта, и бюджет, а что нет.
  • Как будет согласоваться запрос на изменение бюджета.
  • Как осуществляется оплата (какими частями и в какие сроки).

Кажется, все очевидно. Но нет! Если бы было очевидно, клиенты не жаловались бы на «неожиданно нам в конце месяца выставили счет».

Сопротивление сотрудников и руководства заказчика.
Смена команды в ходе проекта (с любой стороны).
Недооценка степени участия заказчиком в проекте

Сопротивление команды и руководства заказчика

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

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

Работать с ним много, плотно, разъяснять, показывать. Общаться с разными контактными лицами и лицами, принимающими решения. Искать заинтересованные в проекте стороны (не только тогда, когда идет пресейл, и надо понять перед кем КП защищать, но и дальше, в ходе проекта). 

Клиенту же необходимо с самого начала уделять внимание ходу проекта. К сожалению, «заплатить, уйти, и вернуться за результатом», это не работает. Без вашего, дорогой наш заказчик, участия – проект не полетит. Как ни старайся, не полетит. Заказчик – важный игрок в своем проекте.

Ожидания заказчика не совпали с результатом (в худшую сторону)

Заказчик недоволен

Управление ожиданиями – самая больная, как мне кажется, тема в проекте. И самая мало описанная. Все книги про управление проектами содержат разделы про управление рисками, бюджетом, ресурсами… но не про ожидания. Ожидания заказчика от проекта – вещь сугубо субъективная.

Вот проект сделан хорошо: вовремя, в бюджете, тестовые испытания прошел, люди работают, критерии приемки выполнены. А заказчик не доволен, и все тут. Потому что в ожидания не попали.

А вот проект – вроде так себе. Со сроками промахнулись. Функционал не весь реализовали. А заказчик – доволен, и даже другим рекомендует. Можно бы и порадоваться, но вопрос «да почему же» не дает спать спокойно.

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

Что мы делаем?

Работа с заказчиком требует детального подхода
  • Выявляем и используем удобные заказчику каналы коммуникации (кому-то удобнее поговорить по телефону, кто-то исключительно на очных встречах воспринимает информацию, другие любят е-мейл, а кому – и вотсап или вайбер лучший друг). 
  • Привыкаем к удобному заказчику графику коммуникаций. В понедельник планерки, в пятницу командировки, а по нечетным средам – обучение? ОК, скажите только когда вам удобно воспринимать информацию от нас, и мы подстроимся.
  • Добиваемся внимания всеми правдами и неправдами :) Это так. Просто по другому не получится. 

Конечно я разбирал причины проблем, и пути их системного устранения – с точки зрения исполнителя. И выводы эти будут полезны в большей степени таким же проектным организациям, как наша. Но со стороны клиента – знать потенциальные подводные камни тоже полезно, это помогает правильно править своим кораблём, ну или правильно выбрать команду.

Для того, чтобы делать проекты и не умирать на них, проектной организации необходимо: 

  • Система ведения проекта с постоянными улучшениями.
  • Система управления рисками.
  • Подход к управлению ожиданиями клиента.

Ну а вам, если вы выступаете в качестве заказчика, можно проверить наличие у вашего потенциального подрядчика данных «фич». Или хотя бы спросить его об этом, и послушать, что он отвечает. Успешных нам всем проектов, коллеги! :)

Удачных всем нам проектов!

Вам будет интересно прочитать

Если проект не взлетелЯ продолжу тему «взлетающих» и не совсем, проектов. Структурировать и понять – почему не все проекты получаются хорошо, даже если обе стороны (кажется) были готовы к проекту и хотели его. Что мешает успеху проекта, и как избежать этих проблем...>>>

Loading
Москва
123022, Россия, Москва, Метро «Улица 1905 года» ул. Б. Декабрьская, Дом 1 (вход со стороны двора)

+7 (499) 753-77-19

с 9:00 до 19:00

E-mail: info@corada.ru
Обратная связь
×
Оставьте Ваше сообщение и мы свяжемся с Вами в удобное для Вас время
Нажимая на кнопку «Отправить», я даю согласие на обработку персональных данных
×
Подпишитесь на рассылку
чтобы не пропустить что-то важное!
О чём наша рассылка?
Нажимая на кнопку «Отправить», я даю согласие на обработку персональных данных
Корада
123022, Россия, Москва, Метро «Улица 1905 года» ул. Б. Декабрьская, Дом 1 (вход со стороны двора) Москва Московская область
55.764649244784 37.559671178647
+7 (499) 753-77-19 info@corada.ru с 9:00 до 19:00 от 2200 рублей/час Корада Консалтинг
Корада.Севастополь
г. Севастополь, ул. Воронина 10, оф. 502 Севастополь Крым
44.61214837259 33.521790694524
+7 (8692) 77-79-78 info@corada.ru с 9:00 до 19:00 от 2200 рублей/час Корада Консалтинг
Корада.Санкт-Петербург
ул. Новорощинская, д. 4, офис 631-1. (Бизнес-центр "Собрание") Санкт-Петербург Ленинградская область
59.884476857031 30.326848246033
+7 (812) 5000-9-12 spb@corada.ru с 9:00 до 19:00 от 2200 рублей/час Корада Консалтинг
Корада.Новосибирск
Бориса Богаткова, 210/1, офис 706 Новосибирск Новосибирская область
55.03621503618 82.977122617721
+7 (383) 312-02-50 novosib@corada.ru с 9:00 до 19:00 от 2200 рублей/час Корада Консалтинг
Корада
ул. Бэнулеску Бодони 59, оф. 817
47.030333687145 28.836092990738
+373 (67) 730731 md@corada.ru 10:00 - 19:00 от 2200 рублей/час Корада Консалтинг