Оценка проекта: угадываем будущее

Многим кажется, что оценка проекта – это просто: составил план в MS Project и готово. Но, глядя на историю изменений регламента по оценке проекта в нашем Confluence, я убеждаюсь, что ни в один другой регламент я не вносил столько правок – этот документ постоянно обновляется и дополняется.

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

 

 

Итак, обо мне: я достаточно давно занимаюсь проектным управлением, сертифицирован по разным технологиям управления проектами.

В проектном отделе, которым я руковожу, почти 50 человек, 6 руководителей проектов, в портфеле отдела более 16 проектов. Объект исследования достойный, опыт можно тиражировать.

Когда я говорю про оценку проекта, я имею в виду процесс оценки проекта – его количественные показатели приведены на слайде:

• Процесс оценки проекта мы развиваем полтора года.

• Проведено более 150 оценок.

• Среднее время, которое тратит руководитель проекта на оценку входящего лида – 25 часов.

• Так как небольших проектов больше, для сравнения я еще привел максимальное время оценки – у нас есть один клиент, на оценку проекта которого было потрачено 475 часов. Вдумайтесь: три человека потратили целый месяц, чтобы оценить проект.

• Иногда заказчики сообщают нам оценки, сделанные другими компаниями, и наши расчёты, как правило, оказываются близкими. А если и есть расхождения, они вполне объяснимы. Ситуации, когда мы вообще не понимаем, как выполнить работу за сумму, оцененную другими компаниями, встречаются в одном случае из десяти – это скорее погрешность.

 

Схема оценки проекта

 

Вот так выглядит сам процесс оценки проекта.

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

• На первом этапе мы проводим предварительную оценку. Вы же знаете эти веселые запросы, которые прилетают 15 декабря: «Запустите мне с Нового года ERP за 300 тысяч рублей». В последнее время таких запросов стало меньше, но они до сих пор встречаются. Чтобы понять корректность ожиданий заказчика и выполнимость его запроса, мы проводим предварительную оценку. Причем здесь у нас получился достаточно интересный механизм, я чуть позже о нем расскажу.

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

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

• И последняя оценка – самая точная. Когда у нас уже есть 300 ЧТЗ, и мы уже точно знаем, что будет сделано.

Давайте разберем каждый из этих этапов.

 

Этап №1: Предварительная оценка

 

На этапе предварительной оценки мы:

• Классифицируем проект – пытаемся понять, что вообще за задача перед нами стоит.

• Проводим предварительную оценку по методу аналогий – мы знаем, сколько в среднем времени уходит на автоматизацию одного рабочего места, и это достаточно хорошая статистика для запуска ERP. Посчитав затраты по рабочим местам, по интеграциям и так далее, мы можем оценить проект с точностью плюс-минус 30-40 процентов.

• Также на этапе предварительной оценки мы формализуем все параметры расчета, которые уже пойдут на следующий этап детальной оценки.

 

 

Для предварительной оценки проекта мы сделали калькулятор – он используется еще до передачи клиентского запроса проектному отделу.

В этом калькуляторе менеджер отдела продаж:

• Вводит конфигурации – обычно клиент уже знает, какая конфигурация ему нужна, или менеджер отдела продаж сам это предполагает.

• Заполняет параметры для расчета – количество рабочих мест, количество подсистем, которые будут запускаться и т.д.

Получается ориентировочный бюджет проекта.

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

 

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

 

 

А для оценки необходимых проекту усилий я применил регрессионную модель.

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

Для расчета усилий по проекту у нас есть определенные критерии:

• С кем мы общаемся: с владельцем или генеральным директором, или к нам пришел какой-то руководитель.

• Оцениваем, насколько у нас хватает текущих ресурсов.

• Насколько это профильная конфигурация.

На основании этих параметров мы рассчитываем ресурсы, которые потребуется инвестировать в этот проект.

Понятно, что если пришло два лида с одинаковым бюджетом, но в одном – профильная ERP-система, а в другом – какая-то отраслевая нишевая система, очевидно, что нам лучше заняться профильным для нас проектом. Регрессионная модель именно это и показывает.

 

Задачи этапа предварительной оценки:

• Быстро понять, будем мы этим заниматься или не будем – лучше сразу честно сказать клиенту: «Это не наш профиль, извините»;

• Даже если вы работаете «инхауз», вы тоже можете делать такую же предварительную оценку, чтобы быстро оценить профит – что даст бизнесу решение этой задачи. А то часто бывает, что срочно нужен отчет, но никакой ценности от него нет – просто интересно посмотреть. А еще, работая «инхауз», вы можете с помощью предварительной оценки понять приоритеты и риски по задаче – что будет, если ее не делать.

• Формальные методики, применяемые на этапе предварительной оценки: MoSCow, WSJF и другие. Я применяю регрессионную модель, она мне нравится больше. Различных методик оценки много – кому интересно, можете потом поизучать.

•  

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

 

Этап №2: Предварительная оценка по видам работ

 

Мы не делаем на каждый проект новый MS Project – у нас есть шаблоны планов со стандартными этапами для трех видов проекта:

• базовый;

• стандартный;

• и корпоративный.

Сергей Лебедев на конференции рассказывал про типизацию проектов. У нас тоже есть типы проектов со своими шаблонами, которые мы применяем при планировании будущей ресурсной загрузки. А объем работ при расчете плана уже подбирается, исходя из запроса.

 

Для всех видов работ в плане я провел нормирование. Теперь, когда руководитель проекта считает план, он, по сути, указывает количество результатов: сколько нужно провести интервью, сколько систем исследовать и т.д.

На каждый вид работ есть нормы – так существенно снижается вероятность того, что мы что-то забудем или что-то недооценим.

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

 

 

Чтобы договориться с заказчиком, мы используем документ «Допущения и ограничения».

В этом документе перечислены общие допущения и ограничения: работаем удаленно, общаемся на русском языке и так далее.

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

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

 

Документ «Допущения и ограничения» – это живой документ.

Например, мы на старте проекта предполагали, что нужно автоматизировать 10 процессов – мы по этим 10 процессам провели интервью, согласовали протоколы, сделали концепцию.

А когда сделали проектные решения и описали бизнес-процессы to be, стало понятно, что какой-то процесс забыли – у нас появился разрыв.

Тогда мы говорим: «Дорогой заказчик, мы можем остаться в том же бюджете при сохранении этих 10 процессов, но у тебя здесь будет какая-то Excel, которая вылетает из одного процесса и залетает в другой. Или можем автоматизировать этот процесс, но тогда надо будет пересчитать бюджет, потому что мы не укладываемся».

 

Важно, чтобы параметры, которые вы выявляете для проекта, были для заказчика простыми и понятными:

• Количество процессов – всем понятно, что это количество модельных примеров, которые мы сделаем.

• Количество встреч – тоже всем понятно, что это количество встреч, которые мы проведем.

И исходя из этих параметров мы считаем план.

 

 

Например, в документе «Допущения и ограничения» мы договариваемся, что на этапе «Моделирование» будем моделировать до 10 процессов.

Но когда после этапа предпроектного обследования в проекте появляется реестр бизнес-процессов, там, как правило, для каждого в колонке «Требуется моделирование» указано «Да».

Тут мы вспоминаем про наши ограничения и начинаем приоритизировать – оставляем «Да» только для тех процессов, которые входят в установленный нами лимит.

 

Вот так у нас в документе «Допущения и ограничения» выглядят параметры для этапов «Техническое задание», «Проектирование» и «Разработка».

Обратите внимание, здесь на этапе «Разработка» есть важное ограничение по количеству отчетных и печатных форм. Как правило, эту работу можно разделить с заказчиком – самому заказчику будет удобнее, если у него сотрудники погрузятся в контекст проекта. Поэтому здесь можно договориться, что исполнитель будет делать отчетные и печатные формы в таком-то объеме, а все, что свыше, уходит на сторону заказчика.

 

 

После составления план нужно верифицировать – проверить его реализуемость. У меня есть отдельный большой документ, который называется «Критерии успешности плана». На слайде – некоторые выдержки из этого документа. Например:

• «Ведущих аналитиков в плане должно быть не менее 50% от общего числа аналитиков».

• «Оформлены ограничения и допущения».

• «По этапам бюджет проекта распределен следующим образом…»

Это критерии успешности, по которым РП может себя проверить.

Конечно, от этих критериев могут быть отклонения. Например, бывают проекты, где разработка занимает больше 50% – главное, чтобы РП это понимал и мог обосновать, почему возникло то или иное отклонение.

 

Приемы и методы кросс-проверки оценок

 

 

Следующий прием, который мы используем при оценке – это перепроверка. После того как у нас готов календарно-сетевой график в MS Project, мы, чтобы его перепроверить, составляем ресурсный план в Excel.

• Мы делим процессы по группам.

• Для каждой группы планируем примерное время запуска. Например, мы знаем, что на запуск бюджетирования или казначейства на производственном предприятии нужно столько-то времени – мы это делали много раз, и примерно знаем, сколько это занимает.

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

Получается ресурсный план.

 

Как правило, оценка по ресурсному плану обычно получается выше, чем по MS Project, и дальше начинаются циклические итерации выверки, чтобы разобраться, в чем заключаются эти отклонения, и почему они возникли.

 

Следующий момент, который я хотел бы подчеркнуть – это нормирование. Казалось бы, что сложного определить, сколько в среднем длилась встреча на предыдущих проектах? Но мы эти корректировки считать замучились.

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

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

 

Про точность оценки. На слайде рекомендации по первичной оценки проекта из PMBoK 6 – там допускается, что оценка будет с точностью от минус 25% до плюс 75%.

В наших проектах такая точность, к сожалению, не прокатывает. Даже если точность оценки плюс-минус 30%, по нашему опыту, клиенты будут недовольны. Поэтому далее мы переходим к оценке проекта по требованиям.

 

Этап №3: Оценка требований

 

Расскажу, какие есть приемы для оценки требований.

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

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

 

 

Рассмотрим пример оценки требований. На слайде – распределение требований по функциональным областям на одном из текущих проектов.

Всего требований – 229. Это много: вдумчиво пройти, оценить с разработчиком каждое требование занимает много времени. Но 80% этих требований – шаблонные: “сделать такой отчет, такую печатную форму, такое рабочее место”. Мы же знаем, сколько времени занимает разработка отчета в среднем. Даже если на один отчет уйдет на два часа больше, а на второй – на два часа меньше, в среднем все равно попадете, отклонение на больших объемах будет незаметным.

• 80% требований оценить просто – достаточно ввести стандартные градации объема работ по этим требованиям и оценить каждую из этих стандартных градаций.

• А оставшиеся 20% требований будут уникальны – нужно брать двух архитекторов и вместе с ними сидеть, креативить, может даже метаданные где-то расписывать.

Для оценки большинства требований мы используем стандартные градации объемов работ, установленные для значений полей «Уровень сложности» и «Сложность доработки».

 

 

Например, так выглядит градация оценок для «Сложности доработки». Это шкала от 0 до 9, каждый уровень которой имеет диапазон «Трудоемкость от» и «Трудоемкость до» Чтобы уложить в план, берем среднюю.

 

Что делать если… Приемы оценки проекта при недостаточной входящей информации

 

Немного про особые случаи, которые возникают в оценке:

• Первый случай – из недавнего примера. Прислали кучу верхнеуровневых требований, по которым просто непонятно, что нужно делать. Говорят: «Давайте оценку». Мы говорим: «Давайте пообщаемся». Нам говорят: «Нет, давайте оценку». Что с этим делать – сейчас расскажу. Мы придумали инструмент, который позволяет в таких случаях достаточно точно оценить проект.

• Второй кейс. Прибегает закупщик, говорит: «Дайте скорее оценку, нам нужно срочно подаваться в тендер!» – «А оценку чего?» – «Вот вам бумажка А4». Мы понимаем, что там завод, 500 пользователей, а на А4 написано 5 предложений. Как оценивать? Достаточно сложно дать какую-то вдумчивую оценку.

• И третий, уже конструктивный пример. Посчитали план, заказчик говорит: «Бюджета на этот год не хватает, что можно убрать?» И нужно обоснованно показать, какие блоки или процессы заказчик можно убрать из плана, чтобы уложить его в бюджет Заказчика.

 

 

Для первых двух случаев – когда нужно оценить проект в условиях высокой неопределенности – мы придумали отдельный инструмент.

Поскольку у нас есть требования, но они какие-то мутные, мы делаем оценку, опираясь на процессы – они у нас сгруппированы по функциональным областям (уровень L1 описания бизнес-процессов).

• По каждому требованию мы понимаем, к какому процессу оно относится.

• Для каждого процесса назначаем сложность его внедрения.

• И оцениваем объем доработок.

По сочетанию этих двух параметров – «Сложность» и «Доработки» – мы для каждого процесса подбираем проектную команду:

• Если доработок много, для процесса нужен разработчик 1 или 0,5.

• Если доработок мало, разработчик не нужен.

Назначаем проектную команду каждому процессу, считаем трудозатраты и получаем общую оценку проекта.

Интересный прием, несколько раз попробовали, нам понравился.

 

 

И третий кейс, это когда нужно понять, сколько денег можно сэкономить, если убрать из проекта какую-то функциональную область.

Я вам уже показывал табличку из 229 требований. Мы оценили трудоемкость каждого требования, но над каждым требованием работает разработчик, аналитик, РП, функциональный и технический архитекторы. Как вы думаете, можно ли спрогнозировать, сколько на конкретное требование потребуется работы РП? Нет, конечно. Но в зависимости от уровня сложности можно предугадать процентное распределение работ между членами команды.

Мы составили таблицу с загрузкой проектных ролей в зависимости от сложности задачи – на слайде процентные соотношения для РП, ТА, ФА, плюс там есть еще аналитики и разработчики.

А потом по всем требованиям просто протянули формулу. Получилось достаточно показательно – хороший прием, нам и Заказчику понравился.

 

Расчет резерва под риски

 

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

 

PMBoK 6 рекомендует три уровня таких резервов:

• управленческий резерв;

• резерв на возможные потери;

• резерв на возможные потери операции.

Но мы на практике применяем только три резерва: резерв РП; резерв куратора и резерв под ситуацию.

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

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

На что нужно закладывать резерв:

• У меня на каждом проекте как минимум одна замена специалиста. Например, в компании есть специалист, который работает в компании уже свыше 10 лет. Его все клиенты любят, он всем нравится. Но в прошлом году его попросили снять с проекта. Удивлены были все – отдел продаж, все производственные отделы, даже маркетинг ко мне подходил, спрашивал, что случилось. Бывает, не сработались. Личное несовпадение. Поэтому под одну-две замены нужно иметь резерв.

• Резерв РП тратится на то, что в процессе доработки всегда будут какие-то мелочи, из-за которых заниматься пересогласованием и подписанием допсоглашений – просто лень. А таких мелочей, как правило, много – чтобы покрыть эти расходы, нужно иметь небольшой резерв.

• Ну и резерв под ситуацию. Ситуации бывают разные.

 

 

Резерв под ситуацию зависит от многих факторов. На слайде – производственная программа моего отдела.

• Бывает такое, что РП сейчас простаивает, у него нет загрузки – он только пришел в компанию, и мне нужен для него проект. Тогда, чтобы быстрее продать проект, мы никаких резервов под ситуацию закладывать не будем.

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

Резерв под ситуацию – это плавающий резерв, который зависит от внешней ситуации.

 

Собираем все в кучу. У нас есть:

• Рассчитанный бюджет по параметрам проекта, имеющий количественные характеристики: сколько мы будем делать работы; по каким процессам; сколько там будет ЧТЗ; сколько будет проектных решений; и так далее.

• Добавляем резервы на небольшие доработки, изменения, отклонения.

• Резерв под замену специалистов.

• И, если у нас есть какая-то сложная ситуация, когда проект нужно стартовать прямо сейчас или никогда – тогда еще небольшой резерв под риски.

 

Заключение

В целом у меня все. Давайте еще раз зафиксируем этапы оценки проекта:

• Определяем параметры проекта.

• Выполняем расчет на основе параметров – такой расчет всегда обоснован.

• В ходе проекта управляем бюджетом – мониторим эти параметры, отслеживаем, сколько работы мы сделали.

 

Вопросы и ответы

 

Вы рассказывали о ситуации высокого уровня неопределенности, когда клиент просит сделать оценку требований, даже не соглашаясь на первоначальную встречу. В качестве решения предлагали расписать эти требования по бизнес-процессам. А откуда вы знаете, какие у этого клиента бизнес-процессы – как можно быть уверенным, сбудется ваша оценка или нет?

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

Продажник все-таки выясняет?

Это совместная работа производственного отдела и отдела продаж.

Вы можете оценивать проекты только для своих команд? Или это услуга отчуждаема и может продаваться?

Я об этом не думал. Теоретически можно.

Вы говорили, что оцениваете по методу аналогий. Но для этого же нужна какая-то статистика. А как оценивать, если такой статистики нет?

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

Получается, что это экспертная оценка?

А как без статистики иначе?

Насколько нужно привлекать разработчика к оценке? Привлекаете ли вы?

Я не могу дать какой-то универсальный совет – привлекать или не привлекать разработчика. Это зависит от команды. Даже скорее, это решение на откуп руководителя проектов.

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

Вы говорили про резервы разного рода. Вы как-то отдельно заказчику показываете, что есть базовая часть, и есть резерв? Либо это идет как-то более размыто? Клиенты нормально реагируют на слово «резерв»?

По моему опыту, скорее негативно реагируют, поэтому отдельно не показываем.

Но это зависит от клиента. Есть так называемые профессиональные клиенты, и у меня был случай, где мне прямым текстом сказали: «Если ты до 20% заложил, я тебя пойму».

Если профессиональные клиенты начинают детально рассматривать оценку под микроскопом – окей, мы отдельно показываем. Если не просят – ну и ладно.

Эти резервы заложены в определенных статьях?

Они распределяются по этапам.

Расскажите о вашем самом провальном проекте. На каком этапе вы ошиблись в вашем проектировании, и кто понес затраты?

Все ошибки на проектах совершаются при его планировании. Всегда и никак иначе.

У меня был проект, который пришел ко мне уже в состоянии полного завала. Там попытались одновременно запустить Розницу и ERP. Так делать нельзя – это должны были быть отдельные проекты, которые, желательно, идут друг за другом, а не одновременно. Это был косяк планирования роудмапа проекта.

А затраты понес подрядчик, конечно.

А когда у вас начинаются финансовые отношения с клиентом? Это же тоже работа: посчитать все, провести какое-то первоначальное обследования, опросы задать. На момент, когда вы начинаете считать проект, у вас уже какие-то финансовые отношения с клиентом есть?

Нет, расчет стоимости проекта мы выполняем бесплатно.

А сколько времени уходит на то, чтобы оценить проект?

От 25 до 475 часов, я об этом уже говорил в начале. Но для клиента эта услуга бесплатная.

А вы говорите, что не можете заставить кого-то работать бесплатно. Как тогда это оплачивается? Позже?

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

Планируете ли вы выход из проекта, если что-то пойдет не так? Если да – то на каком этапе? И говорите ли вы об этом с клиентом?

Конкретно в WiseAdvice только одна такая история была, но там все было полюбовно: сели, поговорили и расстались.

Я понимаю, к чему вы вопрос задаете. Условно мы понимаем, что проект уже точно финансово неуспешный, мы хотим из него выйти и как-то планируем вывод. Но пока не было таких кейсов. Будут – расскажу.

 

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event 2022 Saint Petersburg.