Что такое бюджет на момент завершения budget at completion

Управляем стоимостью проекта с Earned Value Management

Как измерять и контролировать эффективность исполнения планов проектов — такие вопросы являются постоянной головной болью их руководителей. Подходов к решению этих задач много. В данной статье мы рассмотрим основные элементы техники по управлению освоенным объемом (Earned Value Management, EVM), которая применяется повсеместно в проектах США, а у нас только набирает популярность в проектном управлении с учетом обновления Practice Standard for Earned Value Management, PMI. (В 2012 году я уже писал в одном известном в узких кругах журнале о ней.) Вы сможете узнать, как использовать EVM, а в комментариях давайте обсудим, у кого и как на опыте это получалось.

Ключевые точки проекта

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

Техника управления освоенным объемом Earned Value Management помогает справиться с этими задачами. Она интегрирует в себе анализ всего объема работ по проекту с планом выполнения работ и стоимостью его выполнения. Благодаря ей, можно наблюдать за основными метриками состояния проекта и оценивать реальное положение дел, внося необходимые управленческие коррективы.

Выстраиваем работу по EVM

Вы — руководитель и решили, что вы будете использовать Earned Value Management. Поговорим о практических шагах, которые вам необходимо предпринять. Сначала планирование проекта, затем измерение и анализ сроков выполнения работ и их стоимости по мере реализации проектных задач.

Планируем

Определяем полный объем работ: что должно быть разработано и поставлено заказчику. Объем указывается в содержании работ (Statement of work, SOW), у нас этот термин имеет привычные названия — тех.задание, технические/функциональные требования. На его основе составляется план выполнения проекта и рассчитывается стоимость. Начало простое, все как в классике.

Каждая работа разбивается на составляющие задачи, что позволяет лучше контролировать исполнение плана — производится декомпозиция работ. Ведь не даром «слона едят по частям».

Иерархическая структура работ (ИСР, Work breakdown structure, WBS) позволяет уточнить проект до управляемых частей — элементов, которые охватывают весь объем работ. К листьям дерева WBS работы все более детализируются.

Иерархическая структура работ создания программного продукта

Теперь определяем исполнителей работ и их зоны ответственности — готовим организационную структуру проектной команды (ОС, Organizational breakdown structure, OBS).

Организационная структура проектной команды

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

Ответственность по этим точкам, роли участников указываем в матрице разграничения ответственности (Responsibility assignment matrix, RAM) — проводим пересечение WBS (скоупа работ, отвечая на вопрос «Что должно быть сделано?») и OBS (участников проекта, отвечая на вопрос «Кто ответственен за выполнение задачи?»), тем самым определяем ответственных по контрольным точкам. Один ответственный может отвечать за несколько контрольных точек, но контрольная точка не может быть контролируемой нескольким ответственными.

На этом рисунке контрольные точки выделены желтым цветом.

Определение контрольных точек

Делаем основной план выполнения проекта (integrated master schedule, IMS). В плане все задачи разбиваем на этапы исполнения задач (до самого нижнего уровня WBS) с указанием их длительности и логических связей. Затем отмечаем бюджет для каждой задачи.

Главный план выполнения проекта

Составляем бюджет

Для применения Earned Value Management план выполнения работ должен быть интегрирован с плановыми затратами по проекту. В самом конце планирования IMS (очень рекомендую именно тогда) необходимо разработать бюджет. Бюджет должен быть четко привязан к временным интервалам выполнения задач, чтобы понимать, когда и сколько бюджетных средств будет израсходовано.

Бюджет проекта — один из основных элементов Earned Value Management. Он учитывается:

Вариант развития проекта. Пример отображения EV, PV и АС

Из примера приведенного мной выше видна ситуация на проекте — аналитический блок работ выполнялся раньше времени, но с момента согласования требований началось отклонение от плана, в том числе и в разработке…

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

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

Рассмотрим основные постулаты техники EVM:

Измеряем прогресс

Существует несколько основных подходов определения прогресса выполнения задачи.

Фиксированная формула
Удобен для небольших задач. Пример такого подхода – метод 50/50, когда 50% завершения задач указываются при старте их выполнения, а остальные 50% — после завершения. Могут быть использованы альтернативные формулы 25/75 и 0/100. Моё же любимое соотношение – 10/70/20 (старт работ, значительное исполнение задачи, и завершение её выполнения) – позволяет пройти по трёхступенчатому процессу оценки 0% → 10% → 80% →100%.

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

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

Если есть какие-то количественные показатели, то процент можно рассчитать на их основе. Например, мигрированно 65 356 элементов из 110 320, т.е. 59%.

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

Уровень загрузки (level of effort, LOE)
Если результат задачи нематериален и другие перечисленные подходы не могут быть применены, то используем этот подход. Например, для таких задач, как управление проектом или техническое сопровождение пользователей – ответственные за задачи заняты на фиксированный % времени. Таким образом, достаточно просто вычислить, какой будет прогресс, если ответственные занимались этими задачами.

Анализируем отклонения

Earned Value Management позволяет выявлять возможные отклонения от планов с помощью анализа своих основных элементов — освоенного объема, плана выполнения работ и фактических расходов. На их основе можно определить:

; ; ;

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

В случае, если два последних индекса больше или равны 1, проект находится в отличной форме. И наоборот, если меньше 1, это означает, что существует проблема в сроках или стоимости проекта.

Состояние проекта в зависимости от показателей

Прогнозируем

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

Прогноз по завершению проекта (Estimate at completion, EAC)
Позволяет определить, когда закончится проект и сколько в итоге средств уйдет на него с учетом текущего тренда.

Отклонения по завершению (Variance at completion, VAC)
Информирует об экономии или перерасходе средств в конце проекта в абсолютных или относительных величинах за период.

Индекс производительности до завершения (To complete performance index, TCPI)
Показывает необходимую эффективность использования командой оставшихся ресурсов, чтобы в конце стоимость соответствовала значениям BAC (или EAC, в случае если он был рассчитан экспертным методом). После определения индекса нужно определить, какие действия предпринять для изменения CPI в сторону нового значения, равного TCPI.

Прогноз до завершения (Estimate to complete, ETC)
Показывает ожидаемые затраты на выполнение оставшихся работ по проекту. Его можно рассчитать и экспертным путем, и с помощью математических расчетов на основе эффективности выполнения работ, определяемой CPI.

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

Для понимания, как элементы EVM связаны друг с другом, ниже нарисую график зависимости элементов.

Расчет всех элементов EVM привожу в интеллект-карте ниже в удобном для печати формате (считайте – шпаргалка).

Элементы EVM и их расчетные формулы

SV и SPI считаются на основе трудозатрат выполненных и запланированных работ. Поэтому возможна ситуация, когда работы будут завершены позже планового срока, но при этом показатели будут показывать идеальное состояние проекта — SV=0 и SPI=1. В этом случае применяется метод измерения производительности задач, когда используется время как основной показатель – вместо PV и EV необходимо использовать плановое время (PT) и фактически затраченное время (AT). Так, при выполнении всего объема работ и наличии задержки выполнения можно будет рассчитать альтернативные значения SV и SPI, акцентировав внимание на ней. Расчет для этих величин есть на схеме выше.

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

Качественный отчет по анализу отклонений содержит:

Используем на практике

Earned Value Management во всем мире зарекомендовала себя как полезный инструмент для контроля производительности и получения обратной связи о состоянии проекта в ходе управления им. За рубежом EVM активно используется такими компаниями, как IBM, Jacobs, Toshiba, SAP, Boeing. В России же её официально признают не так много компаний, например, «Лукойл» и «Ренессанс Капитал».

Вы сталкивались в своей работе с EVM? Были ли вам полезны ее подходы? Предлагаю высказаться в комментариях.

Послесловие

PMI развивает идеи ESM (earned schedule management) — управление освоенным графиком, применяя подходы EVM. Уже сейчас есть драфты используемых механик для целей ESM, позволяющие таргетированно контролировать критический путь и критическую цепь. Но это уже совсем другая история, которую могу рассказать, или о которой можете прочитать в стандарте Practice Standard for Earned Value Management, 2nd edition (2011), бесплатном приложении к PMBOK для членов PMI.

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

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

А ситуация у него на проекте непростая.

На проекте трудятся 3 программиста – Вячеслав, Роман и Егор (с заработной платой в 100 золотых в день) и 1 аналитик Петр (с заработной платой в 120 золотых в день), ну и конечно же он сам (с заработной платой в 143 золотых в день). На проектном комитете план проекта был принят с базовой длительностью 4 месяца.

В начале выполнения проекта аналитик Петр с точностью до секунды уложился в сроки подготовки материалов для своих коллег программистов, постановки были выверены и согласованы с клиентом, спецификации для разработки были отточены до «11 знаков после запятой». И со спокойной совестью, уходя с работы, он написал письмо разработчикам о готовности материалов для них спустя две недели (как и было запланировано ранее) после старта своих работ. Но забыл приложить номер из Jira с материалами задач, сервер почты как раз был недоступен, и письмо повисло в исходящих.

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

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

Впереди было чуть больше трех месяцев работы, спецификации и постановки не вызвали дополнительных вопросов, и команда работала стабильно, не перерабатывая (по 8 часов в день), все было на их стороне, чтобы сдать свою часть проекта в срок. Такая ситуация была до очередного дня рождения Ивана, который наступил спустя 2 месяца после начала проекта. После торжества Роман «сломался», и ушел на больничный на целых 2 недели. Понимая всю ответственность, Роман после выхода с больничного отрабатывал по 11 часов в день.

И вот спустя неделю после выхода Романа из отпуска, наш Иван задался таким вопросом «Может ли он себе позволить отпуск в конце своего проекта?»

Задание
Помогите Ивану 🙂 Может ли он идти в отпуск, согласно здравой логике после анализа CPI, SPI, SV, CV, TCPI. Приложите расчеты данных показателей и индикаторов, график EV/AC/PV.

Источник

Финансы как универсальное мерило для управления проектом.

Абсолютные и индексные показатели

Финансы как универсальное мерило для управления проектом.

Абсолютные и индексные показатели

Заместитель руководителя филиальной сети «1С-Рарус». MBA, PMP, «1С:РКП». Более 10 лет практики проектного управления. Управлял проектами в таких компаниях, как «ЭКСМО», «Астерос», Gulliver, курировал ряд зарубежных проектов. Преподаёт проектное управление в учебном центре IBM EE/A и в Бизнес-школе директоров фирм-франчайзи «1С».

Из сквозного примера мы видим, что с течением времени соотношение планового и освоенного объёма, а также фактических затрат может меняться. В начале проекта фактические затраты, которые мы несли, были меньше плановых, но к 10-й неделе фактические затраты превысили плановые, а освоенный объём стал отставать от планового (рис. 2).

Рис. 2. Сравнение кумулятивных данных по трём показателям проекта.

Как исправить эту ситуацию? Если мы хотим выдержать сроки выполнения проекта, то для компенсации отставания фактически выполненных работ от плановых значений, а также превышений затрат нам придётся работать эффективнее и больше. А на сколько больше, нам подскажут производные от описанных в предыдущей части статьи показателей (см. подробнее про проектный менеджмент в компании).

Абсолютные показатели отклонений от плана

Это показатели, которые демонстрируют нам отклонения по срокам и стоимости проекта на текущий момент.

Отклонение по стоимости (Cost Variance, CV) рассчитывается как разница между освоенным объёмом (EV) и фактической стоимостью (AC):

В нашем сквозном примере на 10-й неделе проекта EV равно 6 750 000 руб., а AC — 7 100 000 руб. Значит:

CV = 6 750 000 – 7 100 000 = –350 000 руб.

Дельта между фактически выполненными работами из расчёта плановой стоимости и фактическими затратами составляет 350 000 руб.

Отклонение по срокам (Schedule Variance, SV) рассчитывается как разница между освоенным объёмом (EV) и плановым объёмом (PV):

Из примера, PV равен 7 000 000 руб. Значит:

SV = 6 750 000 – 7 000 000 = –250 000 руб.

За 10 недель проекта мы недовыполнили работ на 250 000 руб. относительно запланированных.

Индексные фактические показатели

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

Индекс выполнения стоимости (Cost Performance Index, CPI) даёт понимание, насколько эффективно мы используем ресурсы на проекте относительно плановой эффективности. Рассчитывается как отношение освоенного объёма к фактической стоимости:

CPI = 6 750 000 / 7 100 000 = 0,951.

То есть мы работаем на 95,1% относительно плановой эффективности. Или на один потраченный рубль мы получаем 95,1% от запланированного результата.

Индекс выполнения сроков (Schedule Performance Index, SPI) позволяет понять, насколько мы укладываемся в календарный план и эффективно ли используем время. Он рассчитывается как отношение освоенного объёма к плановому объёму:

SPI = 6 750 000 / 7 000 000 = 0,964.

Эффективность использования времени чуть меньше 96,5%. Судя по нашему сквозному примеру, использовать время мы умеем лучше, чем контролировать затраты на проекте.

Абсолютные прогнозные показатели

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

Прогноз по завершении (Estimate at Completion, EAC) — это расчётная стоимость проекта по факту его завершения и исходя из предположения, что в дальнейшем мы будем управлять финансами проекта с текущей эффективностью. Чаще всего определяется как отношение бюджета по завершению проекта (BAC) к индексу выполнения стоимости (CPI):

В нашем примере BAC равен 50 млн руб., а CPI равен 95,1%. Тогда:

EAC = 50 000 000 / 0,951 = 52 576 235,54 руб.

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

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

Прогноз до завершения (Estimate to Complete, ETC) показывает, какое количество средств нам необходимо ещё вложить в проект до его завершения на основании текущей эффективности использования ресурсов. Показатель рассчитывается как разница между прогнозом по завершении и фактическими затратами на текущий момент:

Для нашего примера:

ETC = 52 576 235,54 – 7 100 000 = 45 476 235,54 руб.

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

Либо другой сценарий: мы собираем всех заинтересованных лиц и подсчитываем, сколько нам ещё потребуется денег и ресурсов, чтобы завершить проект. В подобной ситуации, когда мы знаем показатель прогноза до завершения (ETC), прогноз по завершении (EAC) может быть рассчитан по формуле:

Отклонение по завершении (Variance at Competition, VАC) — это показатель, наглядно демонстрирующий в деньгах, на какую сумму будет отличаться прогнозный в текущих реалиях бюджет от планируемого. Его считают как разницу между бюджетом по завершению (BAC) и прогнозом по завершению (EAC):

Для нашего примера:

VAC = 50 000 000 – 52 576 235,54 = –2 576 235,54 руб.

Обратите внимание: за 10 недель мы отстали всего на 350 000 руб. (CV), выглядящие по сравнению с общей суммой контракта в 50 миллионов незначительной суммой. Но если мы ничего не изменим, то к концу проекта это незначительное отклонение может превратиться в более чем 2,5 миллиона руб. дополнительных расходов для клиента.

Индексные прогнозные показатели

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

Нам необходимо скорректировать план проекта и выполнить свои обязательства перед «ТехноЗаказ». Для этого существует индекс производительности до завершения проекта.

Индекс производительности до завершения (To Complete Performance Index, TCPI) — это показатель, который демонстрирует, с какой финансовой эффективностью необходимо работать с текущего момента до конца проекта, чтобы на момент его окончания остаться в рамках согласованного бюджета проекта по завершению (BAC). Этот показатель измеряется в процентах или долях единицы и рассчитывается как отношение остатка работ — разницы бюджета по завершению (BAC) и освоенного объёма (EV) — к остатку денег — разнице бюджета по завершению (BAC) и фактической стоимости (AC):

TCPI = (BAC – EV)/(BAC – AC).

TCPI = (50 000 000 – 6 750 000) / (50 000 000 – 7 100 000) = 1,0081, или 100,8%.

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

1% эффективнее, либо начать приобретать ресурсы для выполнения работ всего на

1% дешевле — и проект будет выполнен в срок и за ранее оговорённый бюджет.

Однако будьте осторожны — в начале проекта этот показатель может ложно ввести руководителя проекта в заблуждение, что „всё хорошо”. Перенесёмся в будущее и окажемся на 49-й из 54 недель длительности проекта. Представим, что мы не сумели работать на 1% эффективнее и не стали искать ресурсы дешевле, понадеявшись, что за время до окончания проекта отставание ликвидируется само по себе за счёт удачного стечения обстоятельств. На 49-й неделе проекта освоен объём равный 45 650 000 руб., а наши фактические затраты составили 46 000 000 руб.

Пересчитаем индекс производительности до завершения:

TCPI = (50 000 000 – 45 650 000) / (50 000 000 – 46 000 000) = 1,0875, или 108,75%

Значит, оставшийся месяц проекта нам нужно работать на

9% эффективнее, либо сократить стоимость покупаемых ресурсов на

9%. Согласятся ли ваши программисты, системные администраторы, да и вы сами потерять

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

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

Отмечу, что в конце проекта показатель индекс производительности до завершения может стать и ненужной причиной для паники. Его имеет смысл рассматривать только вместе с абсолютными показателями — отклонение по стоимости (CV) и отклонение по завершении (VAC), чтобы понимать „цену” дополнительных усилий по удержанию проекта в 100% рамках бюджета.

Все формулы расчёта показателей в одной таблице

Для удобства перечислим все формулы расчёта показателей.

Вместо заключения

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

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

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

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

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

Источник