Планирование проекта

Критические факторы успеха

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

Наличие спонсора из числа высшего руководства компании

Наличие спонсора у проекта зачастую предопределяет результат проекта [3]. Данный фактор имеет особенно большое значение в начале проекта, когда необходимо обеспечить политическую поддержку проекта и необходимые ресурсы; не меньшее значение он имеет в конце проекта, когда необходимо обеспечить принятие и переход к продуктивной эксплуатации системы в полном объеме в запланированный срок.

Компетентный состав команды

В составе команды проекта должны быть специалисты, обладающие необходимым опытом внедрения ERP-систем, Типична ситуация, когда данная группа представлена консультантами системного интегратора и техническими специалистами вендора. В то же время в проекте необходимо наличие сотрудников самой фирмы, с одной стороны - как основных носителей знаний о бизнес-процессах компании, с другой - для получения знаний о системе и формирования и развития соответствующих компетенций внутри компании [4, 6].

Межфункциональная координация

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

Обеспечение "умного" реинжиниринга бизнес-процессов

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

Привлечение конечных пользователей

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

Принятие системы сотрудниками

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

Мотивация сотрудников и членов проектной команды

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

Продуманная стратегия коммуникаций

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

Обеспечение обучения и тренингов

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

Формирование списка работ (операций) проекта

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

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

Процесс определения состава операций начинается с определения степени детализации операций. Количество операций должно быть достаточным для того, чтобы ответственный за пакет работ мог отслеживать ход исполнения и осуществлять координацию работ. Число операций не должно быть слишком большим, затрудняющим оценку общего состояния проекта с помощью системы отчетности о ходе выполнения проекта [20]. Например, команда решила ограничить количество операций проекта - не более 30, при этом любая операция должна иметь продолжительность не более 20 дней и не менее 10 дней.

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

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

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

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

Исходной информацией для процесса определения списка работ являются [23]:

Для определения списка работ используют следующие инструменты и методы:

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

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

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

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

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

Определение логической последовательности выполнения работ

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

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

Исходной информацией для процесса определения взаимосвязи операций могут быть [11]:

При определении взаимосвязи используются нижеследующие инструменты и методы.

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

Метод стрелочных диаграмм: метод построения сетевых диаграмм расписания проекта, где операции представляются в виде дуг, которые соединяются в узлах, показывающих их зависимости. Этот метод еще называется " операции на дугах".

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

Определение зависимостей. Для определения последовательности операций используется три типа зависимостей: жесткая (или обязательная), нежесткая (или произвольная) и внешняя.

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

Процесс определения взаимосвязи операций завершается формированием следующих документов.

Сетевые диаграммы расписания проекта - схематическое отображение плановых операций проекта и логических взаимосвязей (зависимостей) между ними. Сетевая диаграмма расписания проекта может быть построена вручную или при помощи программного обеспечения для управления проектом, например, Spider или MS Project. Она может включать в себя полную детализацию проекта или одну или несколько суммарных операций (пакет операций). На рис. 2.2 приведен пример представления расписания проекта в виде диаграммы Гантта MS Project.

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

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

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

Оценка трудоемкости и потребности в ресурсах

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

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

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

Исходной информацией для определения трудоемкости являются:

Для оценки ресурсов операций применяют следующие инструменты и методы.

На рис. 2.3 представлен фрагмент диаграммы Гантта с привязкой к ресурсам

При определении трудозатрат на выполнение операций проекта используют нормативные акты и ГОСТы. В табл. 2.3 представлены нормативы времени на составление основных видов документов на различных стадиях разработки документов на автоматизированные системы (АС), а также требуемая квалификация разработчиков документов.

Определение длительности операций.

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

Процесс оценки длительности операций требует, чтобы были оценены объем работы, расчетное количество ресурсов и определено количество рабочих. Оценка длительности операции выполняется помощью ИСР.

Общая длительность проекта рассчитывается как выход процесса разработки расписания.

Исходная информация процесса определения длительности операций

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

Для определения длительности операций можно использовать следующие инструменты и методы.

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

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

Оценка по трем точкам. Точность оценки длительности операций можно увеличить, если в исходной оценке учитывать размер рисков. Оценка по трем точкам основана на определении трех типов оценок:

Длительность операции = (оптимистичная + [4*наиболее вероятная оценка] + пессимистичная)/6

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

Оценка длительности операций. Количественные оценки вероятного числа рабочих периодов, которые потребуются для выполнения операции, всегда включает оценки диапазонов возможных значений. Например, оценка "2 недели $$\pm$$ 2 дня" означает, что плановая операция будет выполняться не менее 8 дней и не более 12 (при 5-дневной рабочей неделе).

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

Концептуальная оценка стоимости проекта

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

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

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

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

На фазе планирования проекта имеет смысл использовать менее точные и менее затратные способы оценки стоимости.

К сведениям, имеющим большую важность для успешной реализации оценки стоимости, относятся:

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

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

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

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

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

Оценка по аналогии предпочтительна в том случае, когда детальная информация о проекте отсутствует.

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

Для того чтобы разработать параметрическую оценку надлежащего качества, необходимо собрать качественную исходную информацию, в которую должны входить [18]:

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

Стоимостная оценка должна производиться компетентными сотрудниками, определение которых можно произвести в соответствии со следующими критериями [8].

Формирование сметы

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

Шаблон сметы проекта

Проверка качества составления сметы проекта

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

Разработка базового плана по стоимости проекта

Базовый план по стоимости - это распределенный во времени суммарный исходящий денежный поток проекта, используемый для измерения и мониторинга исполнения стоимости проекта. Его разработка производится суммированием оценочных расходов в течение определенного временного периода; такой план отражает значение оценочных расходов и срок, когда предполагается их возникновение, при условии следования определенному порядку выполнения проектных задач и работ. Часто изображается в виде S-кривой (см. рис. 2.6).

Построение базового плана по стоимости [18]

Построение базового плана по стоимости начинается со сбора исходной информации, к которой относятся:

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

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

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

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

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

Выгоды построения базового плана по стоимости

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

Прогнозирование потока денежной наличности - еще одно достоинство, обеспечиваемое эффективным базовым планом: он заблаговременно информирует руководство или заказчика о том, что в некоторый момент должны быть доступны определенные фонды, которые потребуются для поставки ресурсов и продолжения реализации проекта. Чтобы надлежащим образом выполнял эту роль, он должен быть организован так, чтобы отражать продвижение и ход исполнения на текущую дату [18].

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