Как сделать оценку проекта

Олег Пашинин

Одна из серьезных проблем в проектах – превышение сроков и бюджета. Можно даже сказать, что провальных проектов как бы и нет вовсе, а есть такие, срок которых увеличен до бесконечности, а бюджет пока закончился. Примечательно, что от превышения сроков страдают и исполнитель и заказчик. Заказчик не получает ожидаемого результата, а исполнитель – ожидаемых денег. Казалось бы, общая проблема должна объединять, но она зачастую только создает дополнительные проблемы между сторонами. Как сделать так, чтобы сроки и бюджет всегда выдерживались? Кое-чего в этом направлении нам удалось достичь.

бюджет

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

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

Каждая из сторон, по-своему, права. С этим приходится мириться и в таких условиях, не договорившись окончательно, начинать проекты. Но изначальное недопонимание, как правило, в ходе проекта только увеличивается и приводит… не будем о грустном. Расскажу о принципах и методах ведения проекта, используемых нами, которые, так или иначе, имеют отношение к соблюдению сроков и бюджета. Возможно, кому-то это поможет улучшить качество собственных проектов.

Рамки проекта

Первый ключевой момент – проработка рамок. Рамки проекта – это документ, в котором написаны требования заказчика к системе, но не настолько фундаментальный как ТЗ. Функциональные рамки проекта составляет консультант/аналитик – сотрудник проектной команды исполнителя – на основе интервью с ключевыми специалистами заказчика. Рамки проекта – это полное понимание всех задач, которые нужно решить в ходе проекта, но без детализации. Это также перечень задач, которые не будут решены в ходе проекта. Этот вопрос занимает одну-две недели. Столько же может занять согласование и уточнение.

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

Проработка архитектуры

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

Иногда мы делаем отдельный документ «Оценка», в котором фиксируем оценку и предполагаемую реализацию. Иногда это делается в виде комментариев к каждому требованию в документе «Рамки проекта». Оценка архитектора занимает, как правило, два-пять дней. Возникающие у архитектора вопросы могут вскрыть непроработанные консультантом аспекты и потребовать дополнительной проработки. Это отлично, ведь уменьшаются риски возникновения данных проблем в ходе проекта. Проработку архитектуры и формирование вопросов архитектор может сделать самостоятельно. Но финальное совещание по обсуждению и оценке требований проектная команда проводит вместе, как минимум в составе: консультант, архитектор, руководитель проекта.

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

Планирование работ

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

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

Планирование работ мы делаем в MS Project. В плане работ мы проставляем трудоемкость выполнения той или иной задачи. Оценки, выданные архитектором, можно использовать только в сочетании с пониманием того, кто будет реализовывать эти требования. У нас должны появиться конкретные фамилии людей. И от того, кого конкретно мы привлекаем на данную задачу, будет зависеть корректировка оценки данной задачи.

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

Оценка бюджета

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

Дальнейшие расчеты я, как руководитель проекта, делаю в таблице Excel. Примерно так:

Ресурс

Длительность (мес.)

Загрузка

Единиц

Трудо-

затрат, (час)

Ставка в час

Стоимость (месяц)

Стоимость (без НДС)

РП (Пашинин)

5

0,5

2,5

420

2000 р.

336 000 р.

840 000 р.

Ведущий консультант (Плешкова)

4

1

4

672

1400 р.

235 200 р.

940 800 р.

Архитектор (Шаповалов)

5

1

5

840

1400 р.

235 200 р.

1 176 000 р.

Консультант (Корх)

4

1

4

672

1100 р.

184 800 р.

739 200 р.

Ведущий разработчик (Харитонов)

3

1

3

504

1400 р.

235 200 р.

705 600 р.

Разработчик (Колесников)

3

1

3

504

1100 р.

184 800 р.

554 400 р.








4 956 000 р.

В результате появляется бюджет проекта. На планирование и составление бюджета уходит еще примерно два-три дня.

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

Уточнение рамок, срока, бюджета

В результате проделанной работы мы получили документы:

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

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

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

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

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

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

Управление сроком и бюджетом

Мы выполнили оценку, согласовали бюджет и сроки. Готовы к заключению контракта и выполнению работ. Но необходимо ответить еще на один вопрос – что исполнитель продает заказчику? С одной стороны он продает результат – в контракте содержатся рамки работ, которые обязуется выполнить исполнитель. Это договор типа «fix price». С другой стороны он продает ресурсы – бюджет составляется на основании длительности привлечения ресурсов, то есть «time & materials». Это разные типы взаимоотношений.

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

Суть их заключается в следующем:

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

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

3) Если в ходе проекта происходит изменение или несоблюдение рамок проекта, но они не влекут изменения сроков и бюджета, то обязательства сторон остаются в рамках контракта.

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

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

Подведем итоги. Ключевые моменты соблюдения бюджета и сроков закладываются в самом начале проекта при проведении оценки и закрепляются в контракте:

  • Для оценки сроков и бюджета необходимо сделать тщательную проработку рамок проекта. На это требуется время.
  • Во время оценки трудоемкости выполнения задач выполняется проработка архитектуры предполагаемого решения, которая фиксируется письменно.
  • Планирование трудоемкости задач производится на основе продуктивности тех специалистов, которые будут эти задачи выполнять. Продуктивность – это параметр, вычисленный по предыдущим проектам для каждого специалиста.
  • Расчет бюджета выполняется на основе длительности пребывания ресурсов на проекте.
  • В рамки проекта вносятся функциональные требования, архитектурные ограничения, а также обязательства заказчика, критичные для выполнения проекта исполнителем в срок.
  • Исполнитель берет на себя обязательства по своевременному выделению качественных ресурсов в полном объеме на сроки, оговоренные в контракте для выполнения рамок проекта. Заказчик берет на себя обязательства по выделению дополнительного бюджета, в случае, если изменения в ходе проекта приводят к увеличению сроков и бюджета.

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

Впервые статья была опубликована на Executive.ru 10 сентября 2010 года в рубрике «Творчество без купюр». Реанонсирована в контентном блоке в рамках специального проекта редакции

Источник изображений: Фотобанк stockphotos

Расскажите коллегам:
Комментарии
Researcher, Москва

К сожалению или к счастью IT-проекты в общем обладают неким удивительным свойством.

Это свойство заключается в том, что выполнить проект и получить деньги может ЛЮБАЯ команда.
ЛЮБАЯ – не обладающая системными знаниями, не теоретическими, и прочими НЕ…
Важно другое. Для команды ВАЖНА вероятность достижения ГЛАВНОЙ ЦЕЛИ таких проектов – УДОВЛЕТВОРЁННОСТЬ заказчика. И тут нужны методы ГАРАНТИРУЮЩИЕ такой результат. Автор наверное на такое откровение и претендует.
Заканчивая преамбулу, хочу сказать, что если есть желание делиться опытом по организации исполнения IT-проектов нужно доказывать положительный эффект и ограниченность зону их применения. Потому как, примеряя предложенный автором подход к нам и нашей деятельности ПРОВАЛ был бы гарантирован.
Мы так
не делали,
не делаем
и не будем делать никогда.
А за плечами у нас более 1000 (тысячи) IT-проектов ценой от 10 000$ до 2 000 000$ и длительностью от 1 месяца до 2 лет. Ни одного провального!!

Перейду к статье.

Очень странно, что автор не оперирует таким общеизвестным параметром – ЦЕЛЬ проекта или ЦЕЛИ заказчика!
При этом вводит довольно странный термин «Рамки проекта». Хотя по описанию содержания это близко к «требованиям». Но как без «Цели» можно писать требования? И еще хуже, как без «цели» писать требования на основе ОПРОСА? Нет критериев оценки требования.
Но при наличии «ЦЕЛИ» требования фактически представляют собой «дерево подцелей» проекта.

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

Дальнейший анализ мне не интересен!

Пишу только для того, что бы случайный читатель не вздумал делать что либо подобное!!

Автору цитата из миниатюрки Семена Альтова:
«…Постовой: И я про вас никому. Езжайте! Да, когда свернете налево, ну вы-то направо, там проезд запрещен, обрыв. Но вам туда можно.»

Председатель совета директоров, Москва
Овсий Валерий пишет: Очень странно, что автор не оперирует...
оперирует, но только не в статье http://www.sinera.ru/methods но еще и придумывает новые :o
Researcher, Москва
Евгений Корнев, Да! Действительно! На сайте не так уж все и плохо. Но я то на статью реагировал. Странно, почему статья и сайт так расходятся? Может авторы разные?
Директор по развитию, Беларусь
Овсий Валерий пишет: При этом вводит довольно странный термин «Рамки проекта».
Это как раз понять не сложно, в PMbook это называется этап определения проекта когда и происходит снижение неопределенности и выход на проект ТЗ. Вообще, если бы изложение шло в соответствии с PMbook, то все было понятней. Зачем автор пошел на подмену принятых определений? Ему виднее. Но вот контрактные положения просто изумляют, покольку не гарантируют сторонам вобще ничего. Просто тем кто не имеет возможности управлять проектом, но очень хочет поработать, предлагается отбросить поднадоевший ''золотой треугольник''. В результате получается договор типа: мы гарантируем, что в течение года будем возиться с Вашим проектом в оговоренных рамках за энную сумму денег (точка). К управлению проектами это отношения не имеет по определению. Отсюда и тонко замеченная господином Овсием точка 672 часа. Почему 672? - а Проджект так нарисовал в пределах рамки, нет треугольника - нет критического пути. Может я чего не понял, тогда цитата из статьи: [COLOR=green=green]Исполнитель гарантирует выполнение проекта в оговоренные сроки и бюджета, в случае, если рамки проекта не будут изменены. Исполнитель гарантирует, что в случае выполнения работ раньше срока, сотрудники Исполнителя, при необходимости, продолжат работу на проекте в рамках оплаченного бюджета над дополнительными задачами. Если в ходе проекта происходит изменение или несоблюдение рамок проекта, но они не влекут изменения сроков и бюджета, то обязательства Заказчика и Исполнителя остаются в рамках контракта. [/COLOR][COLOR=green=green]Если изменения, вносимые в рамки проекта, влекут дополнительное привлечение ресурсов, то составляется дополнительное соглашение и Заказчик оплачивает работы, превышающие первоначальный бюджет. [/COLOR]
Директор по развитию, Беларусь

А теперь повторю часть этой цитаты:
''Если в ходе проекта происходит изменение или несоблюдение рамок проекта, но они не влекут изменения сроков и бюджета, то обязательства Заказчика и Исполнителя остаются в рамках контракта.
Если изменения, вносимые в рамки проекта, влекут дополнительное привлечение ресурсов, то составляется дополнительное соглашение и Заказчик оплачивает работы, превышающие первоначальный бюджет.''
И тоже использую ''Если'': А Если это договор по выигранному тендеру? Наверное дальше рассуждения излишни.

Генеральный директор, Москва

Валерий,
1000 успешных проектов без срыва срока и бюджета, которые у вас выполнили ''любые'' люди?
У вашей компании 40 клиентов. Т.е. у каждого клиента вы выполнили в среднем по 25 проектов. Если допустить неравномерное распределение проектов по клиентам, то есть клиенты, у которых вы выполнили, возможно, 100 проектов?
1000 проектов за 12лет работы вашей компании дают около 80 проектов в год (считая с самого первого года работы компании). Но за 2010 год у вас только 2 крупных проекта. Остальные 78 проектов настолько небольшие, что вы о них ничего не хотите сказать? Или если система развертывается в филиальной сети, то количество проектов вы считаете по числу филиалов банка?
У меня нет оснований вам недоверять. Очевидно, что у вас за плечами невероятно большой опыт. Я за 7 лет работы в ИТ консалтинге, к сожалению, видел не менее половины неудачных проектов. В которых встречалось и MBA, и PMI, и ктн, и т.д и т.п., не говоря уже о ''любых'' специалистах. Конечно вслух эти проекты никто неудачными не назвал. Если у вас 1000 проектов выполнили ''любые'' люди, все проекты были успешными, и это не были типовые проекты, то у вас есть чему поучиться. Вы, действительно, нашли гарантирующий метод. Буду признателен, если вы дадите ссылки на ваши работы, где он изложен. Мне анализ интересен.
p.s. Авторы одинаковые.

Генеральный директор, Москва
Виталий Амбалов пишет: Это как раз понять не сложно, в PMbook это называется этап определения проекта когда и происходит снижение неопределенности и выход на проект ТЗ. Вообще, если бы изложение шло в соответствии с PMbook, то все было понятней. Зачем автор пошел на подмену принятых определений?
Виталий, что такое PMbook? Вы имеете в виду PMBOK ?
Директор по развитию, Беларусь
Олег Пашинин пишет: Вы имеете в виду PMBOK ?
Что-то вроде того - PMI 99-001-2004 P.S. Project Management Pmbook Features The Project Management Pmbook product provides a comprehensive set of features. Easily customize the product to meet your requirements and streamline your Project Management Pmbook processes. Так что Вы хотели Олег?
Генеральный директор, Москва
Виталий Амбалов пишет: Что-то вроде того - PMI 99-001-2004 P.S. Project Management Pmbook Features The Project Management Pmbook product provides a comprehensive set of features. Easily customize the product to meet your requirements and streamline your Project Management Pmbook processes. Так что Вы хотели Олег?
Виталий, пытаюсь разобраться, куда вы меня послали. То, что вы процитировали: Project Management Pmbook Features The Project Management Pmbook product provides a comprehensive set of features. Easily customize the product to meet your requirements and streamline your Project Management Pmbook processes. лежит здесь: http://www.thinmind.com/Sales/Project/Search/project-management-pmbook.htm Очень похоже на то, что это старая страница описания конкретного продукта (сервиса) под названием ''Project Management''. Видимо, поставщиков что-то смутило, потому что сейчас эта страница выглядит так: http://www.thinmind.com/Sales/Project/ProjectFeature.htm (Project Management Features The Project Management product provides a comprehensive set of features. Easily customize the product to meet your requirements and streamline your project management processes.) Никакого PMbook ''что-то вроде'' PMBOK сходства. Стандарт, к которому вы меня отослали, я так полагаю: http://webstore.ansi.org/RecordDetail.aspx?sku=ANSI/PMI+99/001/2004 Это все-таки ''A Guide to the Project Management Body of Knowledge (PMBOK Guide)'' Я не сдавал на PMP и с деятельностью PMI знаком только в общих чертах, поэтому умничать не буду. PMBOK - это всего лишь один из стандартов. В своей практике я больше сталкивался с AIM. Но кроме них полно других, включая ГОСТ. И этапы у всех называются по-разному, и состав/структура выходных документов разная, хотя все об одном и том же. Если вам нравится демонстрировать глубину знаний, рекомендую почитать ''Лекции по управлению программными проектами'' господина С.Архипенкова http://www.arkhipenkov.ru/index.files/publications.htm. Обратите внимание на лекцию по оценке трудоемкости. Там, я думаю, вас все удовлетворит.
Директор по развитию, Беларусь
Олег Пашинин пишет: Я не сдавал на PMP и с деятельностью PMI знаком только в общих чертах, поэтому умничать не буду. PMBOK - это всего лишь один из стандартов. В своей практике я больше сталкивался с AIM. Но кроме них полно других, включая ГОСТ.
Слава Богу, что вспомнили про ГОСТЫ. Вот в них то и есть требования к ТЗ но нет рамок проекта. А нет ТЗ нет и контракта, о чем я и написал. При проверке с пристрастием контрактов основанных на ''рамках'' могут возникнуть большие проблемы. Т.к. нет четкого предмета контракта, но есть конкретные деньги. А что касается отказа от общепринятых понятий, то для этого нужны веские основания, вот коллеги этих оснований и не увидели. Так что извините, ничего личного.
Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
Все дискуссии
HR-новости
Треть профессионалов не доверяют своему руководству

Специалисты меньше, чем руководители и директора, склонны к доверию.

Зарплатные ожидания IT-специалистов превышают возможности работодателей в 1,5-2 раза

Общий рост зарплат в IT-сфере за первые 9 месяцев 2023 года составил 15-20%.

Россияне стали меньше тревожиться из-за работы

Год назад уровень тревожности россиян по поводу различных возможных проблем на работе был выше.

Уровень счастья напрямую влияет на продуктивность большинства россиян

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