Руководство по управлению стоимостью проекта

Научитесь: Профессия Менеджер проектов
Узнать больше

Проект считается успешным, если он завершен в установленные сроки, выполнен в рамках бюджета и в соответствии с ожиданиями заказчика. Управление стоимостью заключается в обеспечении выполнения тройного ограничения на управление проектами — по стоимости, срокам и содержанию
[
10
]
. Управление стоимостью проекта объединяет процессы, выполняемые в ходе планирования, разработки бюджета и контролирования затрат и обеспечивающие завершение проекта в рамках утвержденного бюджета. К процессам управления стоимостью относятся:

стоимостная оценка — определение примерной стоимости ресурсов, необходимых для выполнения операций проекта;

разработка бюджета расходов — суммирование оценок стоимости отдельных операций или пакетов работ с целью формирования базового плана по стоимости ;

управление стоимостью — воздействие на факторы, вызывающие отклонения по стоимости, и управление изменениями бюджета проекта.

Взаимодействие процессов представлено на
рис.
6.1.

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

Стоимостная оценка

Стоимостная оценка — это процесс установления стоимости ресурсов проекта, основанный на определенных фактах и допущениях. Для определения стоимостной оценки прежде всего необходимо определить операции (пакет операций), длительность операций и требуемые ресурсы. Процесс оценки и его результат в значительной степени зависят от точности описания содержания, качества доступной информации, от стадии проекта. На процесс стоимостной оценки оказывают влияние: время, отведенное для проведения оцениваемой операции, опыт менеджера, инструменты оценивания, заданная точность. Оценка стоимости проекта начинается на предпроектной стадии (до заключения контракта) и выполняется в течение всего времени выполнения проекта. Выделяют следующие оценки стоимости
[
12
]
:

• оценка порядка величины;
• концептуальная оценка;
• предварительная оценка;
• окончательная оценка;
• контрольная оценка.

На предпроектной стадии первоначально может определяться только порядок величины стоимости. Точность оценки порядка величины стоимости проекта может колебаться от (-50%) до (+100%). Точность концептуальной оценки находится в интервале (-30%) — (+50%). Точность предварительной оценки проекта колеблется от (-20%) до (+30%). На этапе окончательной оценки точность колеблется от (-15%) до (+20%). Контрольная оценка имеет точность от -10% до +15%. Таким образом, каждая последующая стадия жизненного цикла проекта имеет более точную стоимостную оценку (
рис.
6.2).

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

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

Входная информация для процесса оценки стоимости [9]

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

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

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

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

Словарь ИСР содержит подробное описание работы для каждого элемента ИСР.

План управления проектом — общий план мероприятий по исполнению, мониторингу и контролю над проектом, содержащий указания и руководства по составлению плана управления стоимостью и контролю за его исполнением, а также дополнительные планы:

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

Инструменты и методы, используемые для оценки стоимости

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

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

Оценка по аналогам представляет вид оценки сверху-вниз. При этом используется фактическая стоимость ранее выполненных проектов для оценки текущего проекта. При наличии очень похожего проекта оценка может быть довольно точной. Такой тип оценки применяется на любом этапе жизненного цикла проекта. Оценка по аналогам не требует много усилий при гарантированной точности, однако не всегда удается найти и определить схожие проекты. Точность оценки по аналогии колеблется от -30% до +50%. Стоимость подготовки такой оценки составляет 0,04%-0,15% от общей стоимости проекта.

Оценка снизу-вверх применяется на этапе подготовки базового плана проекта и формировании контрольной оценки. Процесс начинается с оценки деталей проекта с последующим суммированием деталей на итоговых уровнях. Степень точности оценки зависит от уровня детализации ИСР. Оценка снизу-вверх обеспечивает точность от +0,15/-10% до +5%/-5%, но имеет высокую стоимость (от 0,45% до 2% от общей стоимости проекта) и продолжительность.

Параметрическая оценка применяется на ранних этапах проекта. Процесс параметрической оценки состоит в определении параметров оцениваемого проекта, которые изменяются пропорционально стоимости проекта. На основании одного или нескольких параметров создается математическая модель. Например, в качестве параметра разработки программного обеспечения может быть выбрана стоимость разработки строки кода. Для оценки стоимости обследования может быть выбрано количество автоматизируемых бизнес-процессов. Наиболее распространенным параметром оценки стоимости IT-проектов является количество требуемого рабочего времени на выполнение операций (пакета операций). При тесной связи между стоимостью и параметрами проекта и при возможности точного измерения параметров можно увеличить точность расчетов. Преимущество данного метода: для оценки стоимости проекта достаточно знать «ставки» привлекаемых ресурсов: недостатком является низкая точность (-30%-+50%). Стоимость подготовки
параметрической оценки составляет 0,04%-0,45% от общей стоимости проекта.

Контрольные оценки представляют собой разновидность оценок снизу-вверх
[
10
]
. В качестве уровня детализации для выполнения оценки стоимости используется ИСР. Контрольная оценка основана на принципе более детальной оценки снизу-вверх. При оценке затрат на работы проекта, как правило, определяют наиболее вероятное значение затрат, затраты при благоприятных и неблагоприятных обстоятельствах, то есть оптимистическую, пессимистическую и наиболее вероятную оценку. Для расчета математического ожидания и среднеквадратичного отклонения применяют формулы, которые используются в методике PERT:

Математическое ожидание = [оптимистическое + пессимистическое + (4x наиболее вероятное)]/6

Среднеквадратичное отклонение = (пессимистическое — оптимистическое)/ 6^{1Предполагается, что читатель знаком с основами статистики.}

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

Выходы процесса стоимостной оценки

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

Вспомогательные данные, на основании которых была произведена стоимостная оценка, должны содержать описание содержания работ проекта для плановой операции:

• документацию того, как оценка получена;
• документацию обо всех допущениях, сделанных для оценки;
• документацию обо всех ограничениях.

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

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

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

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

Для чего нужно управлять стоимостью проекта

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

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

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

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

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

Рассмотрим один из методов управления стоимостью проекта.

Отчет по освоенному объему

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

Есть несколько показателей, смысл которых необходимо понимать для того, чтобы эффективно использовать в своей практике отчет по освоенному объему. Рассмотрим три основных показателя – BCWS, BCWP и ACWP.

Первый показатель – BCWS (Budgeted Cost of Work Scheduled) – плановая (сметная) стоимость запланированных (к выполнению за рассматриваемый период времени) работ (ПСЗР). Project Management Institute (PMI) переименовал показатель BCWS, и сейчас он называется Planned Value, или PV (что на русский может быть переведено как ?планируемый объем?. – Прим. ред.). Посмотрим, будет ли принята в профессиональной среде эта новая терминология, или люди продолжат пользоваться старой аббревиатурой. Достаточно разобраться в способе расчета этого показателя, чтобы понять, что его название точно передает смысл: он является суммой плановых бюджетных стоимостей работ проекта, которые должны быть выполнены в рассматриваемый период времени. Все элементарные работы проекта имеют планируемую бюджетную стоимость, которая определяется на основе сметы затрат и календарного плана проекта (календарный план содержит сроки начала и продолжительность каждой работы). Таким образом, BCWS – просто сумма этих величин, объединенных по планируемому времени предстоящего осуществления затрат, то есть план проекта, представленный в виде сумм бюджета, привязанных к моментам времени, когда было запланировано эти суммы потратить.

Следующий показатель – ACWP (Actual Cost of Work Performed) – фактическая стоимость выполненных работ. Как и в случае с BCWS, PMI также дал этому показателю новое имя – Actual Cost, или сокращенно AC (что на русский может быть переведено как ?фактические затраты?. – Прим. ред.). При расчете этого показателя объединяются не планируемые, а реальные затраты проекта, произведенные за рассматриваемый период времени. По окончании каждого отчетного периода общий объем затрат проекта за этот период добавляется к общему объему затрат за предыдущие отчетные периоды.

И наконец, третий показатель, который чуть сложнее предыдущих, – BCWP (Budgeted Cost of Work Performed) – планируемая (сметная) стоимость выполненных работ (ПСВР). Его еще иногда называют Earned Value, или сокращенно EV (что на русский может быть переведено как ?освоенный объем?. – Прим. ред.). Этот показатель дал название и методу освоенного объема, и отчету по освоенному объему. Планируемая стоимость выполненных работ BCWP (EV), как и два предыдущих показателя, – это объединение денежных средств по рассматриваемому периоду времени. Выше мы указали, что каждая из элементарных работ проекта имеет планируемую бюджетную стоимость и сроки выполнения. BCWP – это объединение плановых стоимостей фактически выполненных за отчетный период работ. Например, если выполнена работа с плановой (сметной) стоимостью 1000 долл., то BCWP для этой работы по ее окончанию будет равен 1000 долл. Так же, как и для других показателей, чтобы получить BCWP проекта, суммируются BCWP всех работ, выполненных к окончанию отчетного периода.

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

Автор: Майк Ньюэлл
Источник: Опубликовано в журнале”Директор ИС”, – 4, 2002 год

Елена Филипова, сертифицированный специалист Project Management Institute, квалификация Project Management Professional (PMP), автор книги «С чего начать внедрение проектного управления? Готовая методология контроля проектов организации»

Не так давно я рассказывала о том, что внедрение информационной системы проектного управления и программного продукта для управления проектами должно происходить последовательно. Действительно, сначала нужно определиться с контролем сроков и только после этого приступать к управлению бюджетом проекта. Но в жизни заказчику все всегда нужно СРАЗУ, и мой заказчик – не исключение. Не успела я определить ключевые контрольные точки и запустить первую отчетность в системе ADVANTA, от руководства прилетела задача о внедрении контроля бюджета. Мне нужно было сделать все быстро, просто и так, чтобы заказчику понравилось. По-моему, у меня получилось.

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

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

Представьте себе, как же сложно финансовому блоку с проектами, ведь погрешность оценки бюджета даже при кропотливом и точном расчете достигает 5-10%, а при грубом часто приближена к 50-100%! На практике это выливается в то, что бюджета почти всегда не хватает, а требуемые закупки постоянно приходится пересматривать. Кроме того, сама разработка проекта приносит вынужденные изменения – замена элементов, обходные решения, новые компоненты и прочее – все это молниеносно отражается на бюджете.

Без должного внимания к управлению стоимостью проектов никто в компании точно не сможет сказать, сколько бюджета уже потрачено и сколько денег осталось, какие закупки находятся в работе и что понадобится уже завтра, какая есть экономия и где появился перерасход. В такой ситуации на плечи финансистов ложится невыполнимая задача поиска необходимых средств и организация закупок «ВЧЕРА» или «УЖЕ ЗАВТРА». Приходится выкручиваться, рисковать и идти на нарушение некоторых инструкций, закупать частями или переплачивать за аренду требуемого оборудования, и никакие регламенты тут не помогают.

Управление закупками как первый шаг к порядку в бюджете 

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

Классический подход к построению системы управления проектами требует продолжительного времени. Типовые шаги для построения процессов требуют не менее 3-6 месяцев:

• провести обследование;
• определить прототипы процессов;
• провести обучение персонала;
• настроить инструменты для управления;
• выполнить пилотные проекты.

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

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

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

Простой подход к управлению закупками и наведению порядка с бюджетом

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

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

Для быстрого наведения порядка необходимо было, как минимум, внедрить процессы планирования и контроля закупок. Сказано – сделано. Организация закупок заняла всего несколько дней. Что был сделано:

1. Мы провели несколько совещаний с проектными группами, на которых зафиксировали что, по какому проекту нужно и когда это должно быть закуплено.
2. Я встретилась с отделом закупок и проинтервьюировала его сотрудников. Версии процессов у начальников и простых администраторов отличались, поэтому пришлось сделать пару очных ставок. Я, конечно, запросила регламенты, но, как и ожидалось, реальная жизнь сильно отличалась от бумажного варианта процесса. В результате выяснилось, какие закупки по каким процессам должны идти.
3. В системе управления проектами ADVANTA я настроила необходимые объекты, полученные варианты процессов, создала отчеты для мониторинга закупок и для понимания бюджета, а также формы сбора данных.

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

Отдельно расскажу про то, как работает система.

Шаг 1. Руководитель проекта (или в нашем случае, аналитик) фиксирует в плане проекта требуемые закупки. Он заполняет отдельную карточку «Закупка», в которой фиксирует необходимые для отдела закупок сведения. Ранее использовалась форма в Excel, куда все это вносили и отправляли по почте, ее я тоже настроила изADVANTA:привычные формы, которые автоматически формируются из системы, всегда нравятся пользователям.

Рис.1. Как выглядят закупки в плане проекта в системе ADVANTA

Рис 2. Внешний вид карточки закупки и отчета в ней

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

Рис 3. Пример формы для сбора статуса закупок

Шаг 3.Сотрудник проектного офиса еженедельно рассылает статус закупок всем заинтересованным сторонам. Кроме того, формирует для руководства отчеты из системы, которые говорят о том, какие закупки предстоят и на какие суммы.

Рис. 4. Реестр закупок по программе проектовв системе ADVANTA

Рис. 5. Бюджет по программе на основе статуса исполнения закупок

Рис. 6. Визуализация бюджета по программе по статьям затрат

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

Что дальше

Конечно, пока это не идеальное управление бюджетом, но это точно уже УПРАВЛЕНИЕ. Пока все только начинается, но уже сейчас, потратив неделю времени, мы получили реальный инструмент планирования и бюджетирования. Просто, реально, доступно и без лишних трудозатрат. Остается поддерживать созданное и развивать его, чтобы упростить жизнь сотрудникам и максимально снизить риски управления стоимостью.

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

Рекомендуем посетить популярные страницы сайта:

Корпоративное управление проектами

Программа для управления проектами

Управление проектами на предприятии