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