| № п/п | Наименование показателя | Характеристика показателя |
| 1. | BCWS (Budgeted Cost of Work Scheduled) — плановая (сметная) стоимость запланированных работ (к выполнению за рассматриваемый период времени) (ПСЗР). | Project Management Institute (PMI) переименовал показатель BCWS, и сейчас он называется Planned Value, или PV («планируемый объем»). Первоначальное название этого показателя приведено потому, что оно очень четко отражает его суть — это сумма плановых бюджетных стоимостей работ по проекту, которые должны быть выполнены в определенный период времени. Каждая элементарная работа проекта имеет планируемую бюджетную стоимость. Последняя на основе сметы затрат и календарного плана проекта (который включает время начала и длительность каждой из работ). Значит, BCWS — сумма стоимостей работ, которые объединены по планируемому времени предстоящих затрат. Таким образом, это план проекта в виде сумм затрат с привязкой к моменту времени, когда планируется эти деньги потратить |
Окончание табл. 3.5
| № п/п | Наименование показателя | Характеристика показателя |
| 2. | ACWP (Actual Cost of Work Performed) — фактическая стоимость выполненных работ | Этот показатель PMI также переименовал — Actual Cost — AC («фактические затраты»). Когда рассчитывается этот показатель, то объединяем не планируемые, а фактические затраты проекта, которые произведены за анализируемый период времени. Когда отчетный период оканчивается, то общий объем затрат в рамках этого периода прибавляется к общему объему затрат по проекту за предыдущие отчетные периоды нарастающим итогом |
| 3. | BCWP (Budgeted Cost of Work Performed) — планируемая (сметная) стоимость выполненных работ (ПСВР) | Новое название — Earned Value — EV («освоенный объем»). Как раз этот третий показатель дает название отчету по освоенному объему и методу освоенного объема. Планируемая стоимость выполненных работ BCWP (EV) (также как и два предыдущих показателя), — это объединение финансов по рассматриваемому периоду времени. Ранее было сказано, что каждая элементарная работа проекта имеет запланированную бюджетную стоимость и срок выполнения. BCWP — это объединение плановых стоимостей фактически выполненных за отчетный период работ. То есть, суммируются плановые стоимости только тех элементарных работ, которые в рассматриваемом периоде были фактически выполнены. Чтобы найти BCWP проекта, суммируются BCWP всех работ, выполненных к окончанию отчетного периода |
В отчете по освоенному объему находятся все три показателя. Причем, что является очевидным — если проект идет в строгом соответствии с запланированными бюджетом и сроками, то, очевидно, все три показателя будут совпадать.
ФАЗЫПРОЕКТА
Фаза проекта (или стадия) включает одну или несколько задач. В результате выполнения этой задачи (задач) достигаем одного или нескольких результатов проекта.
Задачей называется работа, реализуемая в рамках проекта для получения запланированного результата. Так как проект обычно включает много задач, то для того чтобы было удобнее отслеживать план, они объединяются в некоторые совокупности (фазы). Совокупность фаз (или стадий) проекта — это его жизненный цикл.
Если для достижения результатов задачи достаточно выполнить только эту самую задачу, то для того, чтобы достичь результата фазы проекта, следует выполнить совокупность задач. Различие между фазой и задачей состоит в том, что результат фазы — сумма результатов совокупности задач. Например, в MS Project фазы называют суммарными задачами (summary task), что наглядно демонстрирует смысл понятия фаза проекта.
Вообще, при планировании всегда следует понимать, что чем детальнее план проекта, тем он точнее (а значит, лучше). Поэтому в тех случаях, когда это возможно, следует детализировать большие задачи на подзадачи (таким образом, задачи превращаются в фазы). Это позволяет разбить большую неопределенность на более мелкие, лучше поддающиеся исследованию. Существуют общепризнанные формальные критерии, показывающие, что задачу можно разбить на подзадачи. Это — длительность (задачи 2-3 дня или меньше) и большое число задействованных исполнителей (как правило, если решением задачи занимаются больше 2-3 человек, то каждый решает свою отдельную задачу, которую необходимо отдельно учесть в плане проекта). Фазы могут состоять и из задач, и из других более мелких фаз.
Проект разбивается на фазы (стадии) также, чтобы было удобнее отслеживать ход работ. По окончании отдельной фазы (стадии) проекта необходимо проанализировать полученные результаты и общий ход выполнения проекта. Это делается для того, чтобы при минимуме затрат выявить и исправить ошибки. Здесь следует определить, возможен ли переход к следующей фазе проекта.
В большинстве жизненных циклов получаем последовательное выполнение фаз. Следующая фаза практически всегда должна начинаться только тогда, когда результаты предыдущей будут одобрены и утверждены. Но в некоторых жизненных циклах следующая фаза начинается до одобрения результатов предыдущей, если такой риск считается возможным и приемлемым. «Пересечение» фаз при планировании носит название быстрого пути (fast tracking).
Разбиение проекта на фазы дает возможность представить его в виде списка основных результатов и сроков (дат), к которым эти результаты должны быть реализованы. Менеджер проекта выполняет непосредственный контроль исполнения каждой задачи внутри проекта, сообщая вышестоящему руководству только о достижении фазовых результатов по фазам или стадиям проекта.
ВЕХИ ПРОЕКТА
Каждый проект ориентирован на достижение определенной цели, и обычно достичь ее нельзя, не достигнув нескольких промежуточных целей (реперных точек проекта). Например, нельзя выстроить здание, не заложив фундамент. Значит, закладка фундамента — промежуточная цель при постройке здания. При планировании по стадиям проекта, по окончании и каждой их стадий появляется промежуточный результата, а значит, это веха проекта.
Задачи, в результате выполнения которых реализуются промежуточные цели, называют завершающими задачами, или, в терминах MS Project, вехами (milestones). Обычно итогом фазы (стадии) является достижение промежуточной цели, а поэтому вехой в плане проекта обозначают последнюю задачу фазы. Ведь в результате выполнения этой последней задачи достигается результат вех фазы.
Но, порой бывают ситуации, когда такая задача отсутствует, а результат фазы достигается, к примеру, одновременным выполнением нескольких задач. В этом случае создается фиктивная завершающая задача. Эта задача присутствует в плане только для обозначения момента завершения фазы. Длительность такой задачи устанавливается равной нулю, на нее не выделяются исполнители. Но такое решение облегчает мониторинг плана проекта.
ЗАВЕРШЕНИЕ ПРОЕКТА
Закрытие проекта — важный и очень трудный этап его жизненного цикла. Если проект вовремя не закрыть, то он будет потреблять ресурсы. Например, вовремя не принято решение о роспуске команды. Мотивация персонала уже низкая, участники команды стремятся перейти к новым проектам — в этом проекте они свои задачи выполнили. Но при завершении проекта необходимо выполнить определенные действия, сформировать необходимые документы и уведомления, прежде чем говорить о полном окончании проекта.
Во-первых, необходимо выполнить все формальные процедуры. Иными словами, если проект выполнялся в согласовании с пунктами контракта, необходимо, передатьзаказчику результаты выполненных заданий. Проект не будет считаться закрытым без формального принятия клиентом конечного результата проекта. Причем, чтобы возникло как можно меньше проблем при подписании финального соглашения с заказчиками, менеджеру проекта необходимо последовательно согласовывать с заказчиками результаты промежуточных отчетов или этапов и добиваться их одобрения. В этом случае, утверждение клиентом результата проекта практически означает его согласие с результатами последнего этапа, а не всего проекта в целом.
На этапе закрытия проекта необходимо убедиться, что требования заинтересованных сторон выполнены, ожидания оправданы. Это возможно осуществить через подписание акта сдачи-приемки между исполнителем и заказчиком. В качестве дополнительных способов оценки можно опросить клиентов с целью выяснения факта удовлетворения или неудовлетворения их требований.
Во-вторых, необходимо решить все административные вопросы. Иногда эти вопросы могут оказаться важнее, чем формальные пункты проекта (например, тогда, если проект был реализован без заключения контракта). В административные задачи менеджера на этапе закрытия проекта включается:
· утверждение, что все задания выполнены;
· уверенность в применимости и высоком качестве результатов проекта (через письменное подтверждение от заинтересованных сторон проекта);
· закрытие всех кредитов после того, как погашены все платежи;
· осуществление всех оставшихся по проекту выплат поставщикам, контрагентам и другим заинтересованным сторонам;
· пересмотр и обновление всей документации;
· составление полной документации данных по проекту;
· получение платежей по проекту, если он выполняется для клиента, финансирующего выполнение работ;
· обновление картотеки данных по персоналу или предоставление функциональным менеджерам команды информации для того, чтобы они могли составить отчет по проделанной работе участников проекта;
· составление списка использованных активов баланса проекта, которые можно применить в других сферах организации;
· подтверждение выхода из проекта определенных заинтересованных сторон с тем, чтобы завершить проект.
· роспуск команды проекта, (возможность приступить к работе над другими задачами);
· оценка степени удовлетворенности заинтересованных сторон проекта его результатами;
· сбор всех полученных знаний и опыта для их дальнейшего использования (в качестве уроков проекта);
· освобождение рабочего пространства (например, офиса) проекта;
· уведомление всех заинтересованных сторон об окончании проекта и доступности ресурсов для выполнения других видов проектов и работ;
· отметка о достижениях команды проекта (например, выражение признания отдельным лицам за их вклад в развитие проекта или задачи).
Иногда в проектах существует возможность перераспределения внеоборотных активов, а далее их повторное использование в качестве компонента фазы закрытия проекта. Здесь можно говорить о программном обеспечении, комплектующих, капитальном оборудовании, площадках для осуществления испытаний и пр. В этом случае менеджер проекта несет ответственность за обеспечение этого перераспределения основных средств, а также за обновление их статуса в базе данных и возможность, и необходимость дальнейшего их использования в производственном процессе.
Иногда в процессе закрытия проекта встает необходимость решения дополнительных задач, которые не были включены в план (например, из-за форс-мажорных обстоятельств). Результатом этого может явиться превышение бюджета и графика проекта. Чтобы предотвратить подобные ситуации, следует изначально предусмотреть перечень документов, уведомлений и действий, необходимых на этапе закрытия проекта, а также проанализировать все риски, возможные для этого этапа.
Передача накопленных знаний. Этап завершения проекта предусматривает создание архива проекта. Архив проекта должен содержать все документы, всю информацию по проекту, причем, доступную для участников проекта (каждой группе, персоне — своя необходимая и достаточная доля информации). Это особенно важно для финансовой документации проекта. В ней должны быть учтены все требования законодательства по бухгалтерскому, налоговому учету и т. д.
При формировании архива необходимо удалить их него избыточную, дублирующую, ненужную информацию. Это является важным при дальнейшем анализе и использовании этих данных.
Вообще, создание архива является необходимым для:
· Соблюдения требований законодательства;
· Получения информации в случае проведения аудиторской проверки и необходимости повторного рассмотрения данных по проекту;
· Реализации аналогичных проектов;
· Извлечения уроков для будущих проектов, программ и др.
То есть всегда необходимо при реализации текущего проекта использовать достижения ранее выполнявшихся работ.
Безусловно, самым важным активом для многих компаний является персонал. Люди обладают знаниями, навыками, опытом, необходимым для успешной реализации деятельности и решения задач проекта и компании в целом. Поэтому руководство компаний должно заботиться об обогащении совокупности знаний. В этом случае (даже если происходит смена сотрудников) компания успешно аккумулирует накопленный опыт. Это может реализоваться через хорошо задокументированные завершенные проекты. Формирование базы данных или знаний по выполненным проектам дает возможность последующим менеджерам использовать накопленную информацию для развития своей деятельности, для выполнения текущих проектов с большей эффективностью и наименьшим риском, а также с лучшим результатом.
Участникам проекта при его завершении следует организовать архив проекта таким образом, чтобы сделать его максимально полезным для будущих проектов. Огромную роль в этом играет хороший менеджер проекта, который будет активно вносить вклад в совокупность знаний компании, передавая знания и опыт. Возможно проведение «круглых столов», встреч с менеджерами других проектов, общих информационных собраний способствует быстрому распространению приобретенных знаний. Полезным является проведение встреч, где все заинтересованные стороны проекта обсуждают успехи, ошибки проекта, полезный опыт. Такая информация должны быть задокументирована.
Роспуск команды включает следующие шаги:
· благодарность участникам проекта за вклад, внесенный в достижение результатов;
· содействие участникам в дальнейшем трудоустройстве.
Выразить благодарность следует таким образом, чтобы при необходимости члены команды продолжили работу именно с вами, если будет открыт следующий проект. Для этого менеджер проекта должен не только проинформировать людей об имеющихся вакансиях и возможностях, а приложить более существенные усилия.
Итоговый анализ этапа закрытия проекта. В целом, при завершении необходимо:
· сформировать перечень завершающих мероприятий (документов, уведомлений, действий), не упустив ничего, что может помешать успешному окончанию проекта;
· оценить и задокументировать вклад каждого участника команды, вынести благодарность;
· обновить документацию (отражать заключительный статус проекта в целом и результата);
· создать архив проекта;
· сформировать документальное подтверждение достижения целей проекта (в том числе и со стороны пользователей);
· извлечь уроки из текущего проекта и аккумулировать необходимый опыт для других проектов и работ;
· провести оценку удовлетворенности всех заинтересованных сторон проекта, в особенности клиента. Эта оценка должна быть объективной и независимой, проводиться третьей стороной.
ДОКУМЕНТЫРМ
В зависимости от используемых в компании при управлении проектов различных стандартов и методов, пакет документов проекта может различаться. Рассмотрим в общем виде важнейшие документы проекта.
Необходимым документом является Устав проекта. Если обобщить точки зрения, имеющиеся в проектной практике, то получится, что под Уставом проекта разные специалисты, в т. ч. ориентирующиеся на PMBOK, понимают:
· заявку на инициацию проекта;
· приказ на инициацию проекта;
· краткое положение о проектном подразделении (цели, организационная структура управления проектом, распределение ролей и ответственности внутри проектной команды);
· техническое задание менеджеру проекта от руководства или заказчика;
· обоснование проекта;
· аналог плана управления проектом.
Причем, если по проекту заключается контракт с внешним клиентом, то он может полностью заменить Устав. По сути, предназначение Устава в том, что он служит обеспечению интеграции проекта, то есть согласованности действий всех участников проекта на всех этапах его реализации.
На фазе инициализации Устав включает в себя документирование бизнес-потребностей (проблем, возможностей) и общее описание продуктов проекта, а также связи целей проекта и проекта в целом с текущей деятельностью компании. Документ создается после заключения контракта менеджером, инициатором, спонсором или представителем внешней стороны, связанной с проектом. При утверждении Устава важно, что персона, утверждающая Устав имеет полномочия по принятию основных решений по проекту, включая его финансирование.
Содержание Устава проекта включает следующую информацию или содержит ссылки на другие документы:
· требования к продукту проекта;
· цель проекта, justification — краткое основание;
· ожидания заинтересованных сторон в проекте и анализ их влияния;
· план контрольных точек в проекте;
· распределение ролей и обязанностей в проекте;
· анализ внешнего окружения и внутренней организационной среды (ограничения, связанные с ними);
· экономическое обоснование проекта, которое должно быть действительно на всем протяжении выполнения проекта;
· обобщенный бюджет проекта.
Проектная команда должна поддерживать Устав проекта в актуальном состоянии, получать обратную связь от участников проекта о необходимых улучшениях документа, контролировать изменения.
Документ, определяющий содержание проекта. Этот документ предназначен высокоуровневого определения проекта. Он включает в себя требования к продуктам в проекте и характеристики и рамки проекта. Он разрабатывается после утверждения Устава проекта. Его могут создавать менеджер проекта или представители внешней стороны, связанной с проектом, на основе информации, предоставленной инициатором или спонсором проекта. Право утверждать документ, определяющий содержание проекта имеет спонсор проекта или представитель внешней стороны, связанной с проектом.
Документ включает в себя:
‑ Цели проекта;
‑ требования и характеристики продукта проекта;
‑ критерии приемки продукта;
‑ рамки проекта и проектные решения;
‑ проектные предположения и ограничения;
‑ идентификацию рисков на начальной стадии;
‑ организацию проекта на стадии инициации;
‑ перечень и расписание контрольных точек;
‑ предварительный расчет стоимости;
‑ требования по управлению конфигурацией проекта и согласованные требования.
Так как в процессе работы над проектом необходимо вносить изменения и осуществлять их контроль, данный документ анализируется и обновляется.
План управления проектом. На основе Плана управления проектом обеспечивается определение, интеграция и координация всех составных планов проекта. План управления проектом показывает, как должен реализовываться, контролироваться и отслеживаться проект. План разрабатывается вслед за Уставом и Документом, определяющим содержание проекта менеджером проекта или командой проекта с участием других заинтересованных лиц. Утверждать План управления проектом имеет право спонсор проекта, совет проекта согласно различным методологиям.
План управления проектом отражает:
‑ процессы, отобранные проектной командой;
‑ уровень внедрения каждого отобранного процесса, определенный проектной командой;
‑ описание методов и средств, используемых для реализации этих процессов;
‑ жизненный цикл и фазы проекта, связанные с ним;
‑ зависимости и взаимодействия между процессами при управлении конкретным проектом;
‑ организация выполнения работы для достижения цели проекта;
‑ как будут выполняться контроль изменений и мониторинг;
‑ как будет выполняться управление конфигурацией продукта;
‑ как будет достигаться интеграция исходных планов (baselines) проекта;
‑ требования к информации и коммуникации между заинтересованными сторонами.
План управления проектом может объединять все отдельные планы проекта, например:
‑ План управления содержанием;
‑ план улучшений;
‑ план управления качеством;
‑ план управления рисками;
‑ план управления поставками;
‑ план управления расписанием;
‑ план управления стоимостью;
‑ план управления коммуникациями;
‑ план управления персоналом.