Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
План управления проектом
Процесс разработки плана управления проектом представляет собой процесс документации действий, необходимых для определения, подготовки, интеграции и координации всех вспомогательных планов. Корректно составленный план управления проектом является основным источником информации о том, как проект будет планироваться, оцениваться, контролироваться и закрываться. План управления проектом обновляется и редактируется в рамках процесса осуществления управления изменениями.
План управления проектом может быть либо резюмирующим, либо детализированным и состоять из одного или нескольких вспомогательных планов и прочих элементов. Его рекомендуется разделять на 3 блока по характеру содержащейся в них информации.
Формирование иерархической структуры проекта
Иерархическая структура работ (ИСР) - это ориентированный на результаты способ группировки элементов проекта, который упорядочивает и определяет общее содержание проекта. Работы, не включенные в ИСР, находятся за пределами содержания проекта [18].
Модель может быть выполнена графически, в виде древовидной структуры или в виде словесного описания. С ее помощью структурируется и определяется все содержание проекта.
Построение ИСР (иерархической структуры работ).
Существуют два основных способа разработки ИСР: "сверху вниз" и "снизу вверх".
Подход "сверху вниз".
Разработка ИСР станет более легким и осмысленным делом, если будет доступна следующая информация:
После получения необходимой информации необходимо определиться с типом построения ИСР:
Что касается следующих уровней ИСР, то практикуются гибридные ИСР, сочетающие два или три метода. При выборе способа структурирования ИСР рекомендуется следовать принятому на предприятии или в отрасли стандарту.
Принимая во внимание тот факт, что число пакетов влияет на время и стоимость управления проектом( время и бюджет). Пакетом работ мы будем называть основной элемент управления ИСР, дискретную задачу, имеющую определимые конечные результаты. Очевидно, пакеты работ должны представлять небольшие результаты и быть управляемыми.
Для определения степени детализации ИСР нужна следующая информация:
Возможна ИСР со следующей детализацией:
Несмотря на уникальность каждого проекта, ИСР предыдущего проекта часто может служить шаблоном для нового. Так как большая часть проектов внедрения ИС в конкретной организации будет иметь одинаковые жизненные циклы, следовательно одинаковые или схожие результаты каждой фазы. Шаблон ИСР представляет собой древовидную структуру работ, детализированную до уровня пакетов работ, которую можно адаптировать под конкретные проекты в конкретной области приложения.
Определение содержания проекта
Содержания проекта представляет собой формулировку проекта - что необходимо сделать. Процесс разработки предварительного содержания проекта описывает и документирует характеристики и границы проекта и связанные с ним продукты и услуги, а также методы приемки и управление содержанием.
Описание содержания позволят оценить желаемый результат и выступает в качестве основы для составления базового плана содержания, которому необходимо следовать при выполнении всех работ проекта. В известном смысле описание содержания проекта можно сравнить с границами проекта - он говорит о том, что выход за границы не допускается без санкции руководителя и что все находящееся в этих границах представляет собой пространство решений, в котором разрешается действовать команде проекта.
Ключевое значение для составления описания содержания проекта имеет:
В табл. 2.1 приведены требования к описанию содержания проекта
|
Таблица 2.1. Требования к описанию содержания проекта |
||
|
№ |
Раздел |
Пояснения |
|
1. |
Название проекта |
проект должен иметь название, отражающее его суть и яркое для привлечения внимания, утвержденное имя не меняется на протяжении жизненного цикла всего проекта |
|
2. |
Цели и задачи проекта |
Цель проекта формулируется, исходя из требований заказчика и указанной в уставе проекта, она не повторяет формулировки бизнес-цели, а отвечает на вопрос, КАК эта бизнес-цель будет достигнута. |
|
3. |
Требования к проектному решению и результаты проекта |
Является элементом базового содержания проекта, входящего в план управления проектом. Описание характеристик реализуемого решения проекта и основных результатов проекта. Выполнение работ, изложенных в описании содержания, должно привести к получению основных результатов(Результаты могут включать в себя как промежуточные, так и конечные). В качестве результатов проекта могут выступать как продукты, так и услуги. Информация о количестве и качестве тоже должна быть представлена в описании проекта |
|
4. |
Границы проекта |
Является элементом базового содержания проекта, входящего в план управления проектом. Границы проекта определяют то, что включается в проект. Комплексное рассмотрение проекта подразумевает отражение функциональных, организационных, технологически и географических границ проекта. |
|
5. |
Способ реализации проекта |
подразумевает перечисление инструментов, технологий и подходов, которые будут использованы для управления проектом и достижения поставленной цели. К ним относятся:
|
|
6. |
Первоначальная ИСР до пакетов работ |
Является элементом базового содержания проекта, входящего в план управления проектом. Иерархическая структура работ проекта - модель, раскрывающая проект поуровнево до такой степени детализации, которая необходима для эффективного планирования и контроля проекта. Модель может быть выполнена графически, в виде древовидной структуры или в виде словесного описания. С ее помощью структурируется и определяется все содержание проекта. |
|
7. |
Потребность в ресурсах, штатное расписание и организационная структура проекта * |
Потребность ресурсов определяется трудоемкостью работ, отраженных в разработанной ИСР. При определении трудоемкости работ важно использовать методологию проектного управления (внедрения ИС). Организационная структура проекта определяется методологией, культурой и внутренней политикой компании-заказчика. На данном этапе рекомендуется разработать матрицу ответственности (RACI-матрицу), позволяющую распределить комплексную ответственность за задачи проекта. *(трудоемкость, роли проекта, без указания конкретных сотрудников, структура подотчетности и управления проектом) |
|
8. |
Укрупненный календарный план |
разрабатывается на основе контрольных событий, информации из устава проекта и ИСР (работы уровня 1) |
|
9. |
Критические факторы успеха |
Условия, обеспечение которых на проекте может быть залогом успеха:
|
|
10. |
Допущения проекта |
Набор условий, которые должны быть выполнены наряду с созданием продукта проекта для достижения результата проекта. Допущения обуславливают риски проекта; во время проекта происходит их мониторинг. Пример допущений:
При формировании описания содержания проекта допущения формулируются со стороны организации-исполнителя об организации-заказчике |
|
11. |
Ограничения проекта |
Ограничение указывает на условие, которое нельзя нарушать в процессе создания продукта проекта, или условие, которому ни при каких обстоятельствах не должен удовлетворять продукт проекта. Ограничения указывают на возможности команды проекта по выбору вариантов для выполнения любых проектных работ. При составлении описания содержания проекта ограничения формулируются со стороны организации-исполнителя об организации-заказчике |
|
12. |
Связь с прочими текущими программами и проектами |
возможное взаимодействие с другими проектами должно быть отражено в описании содержания проекта. Необходимо указать, где и как проекты взаимодействуют друг с другом, детально описать, какие ресурсы подпадают под совместное использование и в каких функциональных областях организации |
|
13. |
Первоначально сформулированные риски |
указываются уже известные риски и основные категории потенциальных рисков (внешние, организационные, процедурные, технические, юридические, репутационные и т.д. ) |
|
14. |
Смета расходов с указанием порядка величин |
это представление проектных затрат на проект по категориям. |
|
15. |
Требования к управлению конфигурацией проекта |
Указываются объекты управления конфигурацией проекта, в том числе проектная документация, внутренние политики и производимый продукт. |
|
16. |
Критерии приемки результатов проекта |
Являются элементом базового содержания проекта, входящего в план управления проектом. Представляют собой набор стандартов или правил, определяющих выполнение задачи с приемлемым уровнем качества |
Критические факторы успеха
Проект всегда направлен на оптимальное их использование ограниченными ресурсами. Поэтому в реализации следует уделять внимание обеспечению того или иного фактора успеха только в тот момент времени, когда это действительно важно для проекта, и снижать интенсивность привлечения ресурсов в прочие моменты времени, когда эти ресурсы могут быть задействованы на обеспечении решения прочих задач.
На рис. 2.1 отражена модель, описывающая значимость каждого из критических факторов успеха на различных этапах ЖЦ ИС. Указанные баллы отражают нормированные по десятибалльной шкале оценки значимости критических факторов на соответствующих стадиях.
Рис. 2.1. Модель критических факторов успеха в динамике этапов жизненного цикла информационной системы
Наличие спонсора из числа высшего руководства компании
Наличие спонсора у проекта зачастую предопределяет результат проекта [3]. Данный фактор имеет особенно большое значение в начале проекта, когда необходимо обеспечить политическую поддержку проекта и необходимые ресурсы; не меньшее значение он имеет в конце проекта, когда необходимо обеспечить принятие и переход к продуктивной эксплуатации системы в полном объеме в запланированный срок.
Компетентный состав команды
В составе команды проекта должны быть специалисты, обладающие необходимым опытом внедрения ERP-систем, Типична ситуация, когда данная группа представлена консультантами системного интегратора и техническими специалистами вендора. В то же время в проекте необходимо наличие сотрудников самой фирмы, с одной стороны - как основных носителей знаний о бизнес-процессах компании, с другой - для получения знаний о системе и формирования и развития соответствующих компетенций внутри компании
Межфункциональная координация
Интеграционный, т.е. комплексный, характер решения накладывает серьезные требование на межфункциональную координацию, как среди членов проектной команды, так и владельцев бизнес-процессов. Данный фактор имеет высокое значение в начале проекта, когда все участники из различных подразделений формируют общие цели проекта, и в конце, когда необходимо проанализировать достижения соответствующих целей и, убедившись, что не возникло межфункциональных противоречий, завершить проект [4].
Обеспечение "умного" реинжиниринга бизнес-процессов
Построение системы вокруг неоптимизированных процессов не имеет смысла, это чревато "автоматизацией бардака". Владельцы бизнес-процессов должны иметь представление о том, как и какие процессы будут автоматизированы. Во многих методологиях внедрения, включая aSAP, предполагается, что процессы в компании будут по большей части перестроены в соответствии с логикой, реализованной в системе, в связи с чем данный фактор приобретает еще большую значимость. Данный фактор имеет большое значение на фазе концептуального проектирования, когда производится анализ существующих бизнес-процессов и проектирование новых бизнес-процессов в системе.
Привлечение конечных пользователей
С самого начала проекта конечные пользователи должны быть активно вовлечены в проект. Они должны осознавать важность внедрения системы, а их разумные требования не должны быть проигнорированы. Очевидно, что их участие особенно важно на стадии формирования требований к системе, а также при миграции данных и интеграционном тестировании.
Принятие системы сотрудниками
Принятие системы пользователями позволяет в короткие сроки получить запланированный эффект от её внедрения и, следовательно, сократить время окупаемости проекта. Принятие во многом основано на том, понимают ли сотрудники концепцию, реализованную в системе; таким образом, аналогично реинжинирингу бизнес-процессов, данный фактор имеет наибольшую значимость на этапе концептуального проектирования
Мотивация сотрудников и членов проектной команды
Сотрудники должны быть заинтересованы в достижении целей проекта, это снизит возможное сопротивление и повысит лояльность к системе. Также надо иметь в виду, что конфликтующие цели должны быть устранены из системы мотивации сотрудников. Наибольшую значимость данный фактор приобретает на последнем этапе проекта, когда от членов проектной команды требуется наибольшее усилие для обеспечения работоспособности системы и устранения выявленных недостатков.
Продуманная стратегия коммуникаций
Коммуникации как внутри проектной группы, так и за её пределами (с будущими пользователями) являются важным аспектом, обеспечивающим успех проекта внедрения. О целях, задачах и объеме проекта должно быть известно всем участникам проекта; кроме того, участники должны быть в кратчайшие сроки информированы обо всех происходящих изменениях, как внутри проекта, так и в деятельности организации. Для решения задачи регулярной информированности должен быть выстроен план и стратегия коммуникации. Особую важность данный параметр имеет на первых двух стадиях проекта, когда в тесном сотрудничестве с менеджментом компании определяются цели и план проекта; также его значимость повторно возрастает на финальной стадии, ибо на этом этапе проектная команда должна провести большое количество информационных семинаров перед выводом системы в продуктив.
Обеспечение обучения и тренингов
Стратегия и план обучения должны быть сформированы на начальных этапах проекта, а не после его завершения, причем в них должна учитываться необходимость развития компетенции как технических специалистов, администраторов системы, так и конечных пользователей. Кроме того, надо иметь в виду, что при обучении сотрудники должны не только приобретать технические навыки (тренинги) работы в системе, но и получать понимание концепций, реализованных в ERP-системе. Обучение работе в системе должно быть включено отделом управления человеческим капиталом в план развития релевантных сотрудников, а также должна быть предусмотрена возможность обучения новых сотрудников и тех, кому требуется повторное обучение .
Формирование списка работ (операций) проекта
Инструментальным средством для определения списка работ, а также для оценки их взаимосвязи и длительности служит иерархическая структура работ ( ИСР ). результатом процесса декомпозиции ИСР является нижний уровень работ, необходимых для завершения проекта, с которым работает руководитель проекта - уровень пакетов работ. Пакеты работ разбивают на операции. Операция - это единица работ, в результате которой создается конкретный результат по внедрению информационной системы.
Перед началом определения списка работ необходимо проанализировать описание содержания проекта, ограничения и допущения с точки зрения полноты списка операций - этот список будет основой для составления смет, планирования сроков выполнения и контроля проектных работ.
Процесс определения состава операций начинается с определения степени детализации операций. Количество операций должно быть достаточным, чтобы ответственный за пакет работ мог отслеживать ход исполнения и осуществлять координацию работ. ( Например, команда решила ограничить количество операций проекта - не более 30, при этом любая операция должна иметь продолжительность не более 20 дней и не менее 10 дней.)
Далее выполняется разбиение пакетов работ на операции таким образом, чтобы были определены все операции, необходимые для реализации проекта; при этом длительность (степень детализации) не рассматривается.
На следующем этапе выполняется учет степени детализации. Если количество выделенных операций мало, их разбивают на более мелкие, если велико - родственные операции группируют. Степень детализации зависит от цели детализации, от количества контрольных событий, которые планируется отразить в расписании проекта.
Состав операций может определяться последовательно, методом набегающей волны. При использовании метода набегающей волны пакеты работ, расположенные в отдаленном будущем, планируются только на высоком уровне, в то время как пакеты работ, расположенные ближе по времени, планируются детально
Исходной информацией для процесса определения списка работ являются:
Для определения списка работ используют следующие инструменты и методы:
Процесс определения списка работ завершается формированием списка операций и уточненным списком контрольных событий.
Список операций - перечень работ, запланированных для выполнения. В список операций входят идентификатор операции и описание содержания работ по каждой операции, подробное настолько, чтобы члены команды проекта понимали, какие работы необходимо провести.
Список контрольных событий - перечень основных событий, которые должны быть включены в расписание для мониторинга хода выполнения и управления проектом, с указанием, является ли контрольное событие обязательным (например, необходимым согласно контракту) или необязательным (например, основывающимся на исторической информации).
Параметры операций расширяют описание операции путем определения ряда элементов, связанных с каждой операцией. Элементы каждой операции формируются с течением времени. На первоначальных стадиях проекта они могут включать в себя: идентификатор операции, идентификатор ИСР и название операции, а в конце формирования - коды и описание операции, перечни предшествующих и последующих операций, логические взаимосвязи, опережения и задержки, требования к ресурсам, директивные даты, ограничения и допущения. Параметры операции могут быть использованы для определения лица, ответственного за выполнение работы, географического местоположения выполнения работ и типа операции, например, уровня загрузки, дискретной или распределенной загрузки. Параметры операции нужны для разработки расписания, а также для выбора, систематизации и разнообразных сортировок запланированных операций в отчетах. Количество параметров различается в зависимости от прикладной области.
Запрошенные изменения - изменения в составе работ, которые могут появиться в ходе выполнения работ по реализации ИТ и повлиять на описание содержания проекта.
|
Таблица 2.2. Пример списка работ |
|
|
Наименование пакета работ |
Наименование операций |
|
Обследование |
|
|
Описание бизнес-процессов |
|
|
Разработка системы |
|
|
Тестирование системы |
|
Определение логической последовательности выполнения работ
Определение взаимосвязей операций включает в себя идентификацию и документирование логических взаимосвязей между плановыми операциями.
Взаимосвязи операций могут быть последовательными (с собственными отношениями предшествования), а также с опережениями и задержками. В этом случае каждый выходной элемент операции используется как входной элемент другой операции или является частью поставки. Взаимосвязи операций могут быть с перекрытиями, когда еще незавершенная операция имеет достаточно выходных элементов для начала зависящей от нее операции, или с параллельным выполнением операций [1].
Исходной информацией для процесса определения взаимосвязи операций могут быть :
При определении взаимосвязи используются нижеследующие инструменты и методы:
Определение зависимостей. Для определения последовательности операций используется три типа зависимостей: жесткая (или обязательная), нежесткая (или произвольная) и внешняя.
Применение опережений и задержек. Опережения и задержки представляют собой интервалы времени, которые совершенствуют взаимосвязи между предшествующими и последующими операциями.
Процесс определения взаимосвязи операций завершается формированием следующих документов:
Рис. 2.2. Фрагмент расписания проекта в виде диаграммы Гантта MS Project
Оценка трудоемкости и потребности в ресурсах
Оценка ресурсов каждой плановой операции определяет, какие ресурсы (человеческие ресурсы, оборудование) будут использоваться и в каком количестве и когда каждый из ресурсов будет доступен для выполнения проектных операций. Процесс оценки ресурсов операций тесно связан с процессом оценки стоимости.
В качестве примера рассмотрим оценку потребности в человеческих ресурсах. Для выделения ресурсов необходимо выяснить, какие необходимы ресурсы, их наличие, доступность и необходимое количество. Для ответа на эти вопросы требуется вести учет ресурсов и их параметров. Приведем ориентировочный состав параметров для оценки человеческих ресурсов:
В некоторых компаниях для определения доступности ресурса в пункте "Доступность" отражается период регулярного фактического отсутствия сотрудника на работе, связанного с отпуском, участием в ежегодных выставках, командировках и т.д. Это позволяет прогнозировать возможное отсутствие сотрудника при его участии в проекте. Другой, не менее важной составляющей параметра "доступность" является коэффициент доступности. Под ним подразумевается часть рабочего времени, в течение которой данный сотрудник может работать над проектами, из расчета 8-часового рабочего дня.
Исходной информацией для определения трудоемкости являются:
Для оценки ресурсов операций применяют следующие инструменты и методы:
Результатом процесса оценки ресурсов операций является следующая информация:
На рис. 2.3 представлен фрагмент диаграммы Гантта с привязкой к ресурсам
Рис. 2.3. Фрагмент диаграммы Гантта с привязкой к ресурсам
При определении трудозатрат на выполнение операций проекта используют нормативные акты и ГОСТы. В табл. 2.3 представлены нормативы времени на составление основных видов документов на различных стадиях разработки документов на автоматизированные системы (АС), а также требуемая квалификация разработчиков документов.
|
Таблица 2.3. Нормативы трудоемкости разработки документов на АС |
|||
|
Наименование документа |
Единица объема работы |
Норматив времени, ч |
Квалификация исполнителя |
|
Перечень заданий на разработку специализированных (новых) технических средств |
Позиция |
0,14 |
Инженер |
|
Перечень входных сигналов и данных |
То же |
То же |
То же |
|
Перечень выходных сигналов (документов) |
То же |
То же |
То же |
|
Спецификация оборудования |
То же |
То же |
То же |
|
Перечень заданий на разработку строительных, электротехнических, санитарно-технических и других разделов проекта, связанных с созданием системы |
То же |
То же |
То же |
|
Описание автоматизируемых функций |
Лист ф. А4 |
4,30 |
Ведущий инженер |
|
Описание постановки задач (комплекса задач) |
То же |
То же |
То же |
|
Описание информационного обеспечения системы |
То же |
То же |
То же |
|
Описание организации информационной базы |
То же |
То же |
То же |
|
Описание систем классификации и кодирования |
То же |
То же |
То же |
|
Описание массива информации |
То же |
То же |
То же |
|
Описание комплекса технических средств |
То же |
То же |
То же |
|
Описание программного обеспечения |
То же |
То же |
То же |
|
Описание алгоритма (проектной процедуры) |
То же |
То же |
То же |
|
Описание организационной структуры |
То же |
То же |
То же |
|
Описание технологического процесса обработки данных (включая телеобработку) |
То же |
То же |
То же |
|
Общее описание системы |
То же |
То же |
То же |
|
Ведомость потребности в материалах |
Позиция |
0,27 |
Инженер |
|
Ведомость машинных носителей информации |
То же |
То же |
То же |
|
Массив входных данных |
Лист ф. А4 |
0,90 |
Техник |
|
Каталог базы данных |
То же |
То же |
То же |
|
Состав выходных данных (сообщений) |
То же |
То же |
То же |
|
Технологическая инструкция |
То же |
3,00 |
Старший инженер |
|
Инструкция по формированию и ведению базы данных (набора данных) |
То же |
То же |
То же |
|
Руководство пользователя |
То же |
3,15 |
Инженер |
|
Инструкция по эксплуатации КТС |
То же |
То же |
То же |
Длительность операции - это продолжительность времени, необходимого для выполнения операции. Длительность может измеряться количеством дней, в течение которых человек (или несколько человек) трудился над данной операцией. Процесс оценки длительности плановых операций использует информацию о содержании операции, требуемых ресурсов, календарях ресурсов с указанием их доступности и трудозатратах на выполнение операции. Оценка длительности может уточняться в ходе выполнения проекта.
Рис. 2.4. Диаграмма Гантта с привязкой к ресурсам
Процесс оценки длительности операций требует, чтобы были оценены объем работы, расчетное количество ресурсов и определено количество рабочих. Оценка длительности операции выполняется помощью ИСР.
Общая длительность проекта рассчитывается как выход процесса разработки расписания.
Исходная информация процесса определения длительности операций
План управления проектом включает в себя реестр идентифицированных рисков, рассматриваемых командой при подготовке оценки длительности операций и ее корректировке с учетом рисков.
Для определения длительности операций можно использовать следующие инструменты и методы.
Оценка по аналогам подразумевает оценку фактической длительности аналогичной предыдущей плановой операции в качестве основы для оценки длительности будущей плановой операции и использует историческую информацию и экспертную оценку.
Параметрическая оценка. Оценочную величину длительности операций можно вычислить путем умножения количества работы на производительность труда. Для определения длительности операций по рабочим периодам общее количество ресурсов умножается на количество рабочего времени или производительность за рабочий период и делится на количество привлеченных ресурсов.
Оценка по трем точкам. Точность оценки длительности операций можно увеличить, если в исходной оценке учитывать размер рисков. Оценка по трем точкам основана на определении трех типов оценок:
Длительность операции = (оптимистичная + [4*наиболее вероятная оценка] + пессимистичная)/6
Результаты процесса оценки длительности операций
Оценка длительности операций. Количественные оценки вероятного числа рабочих периодов, которые потребуются для выполнения операции, всегда включает оценки диапазонов возможных значений. Например, оценка "2 недели 2 дня" означает, что плановая операция будет выполняться не менее 8 дней и не более 12 (при 5-дневной рабочей неделе).
Параметры операции (обновления). Параметры операции обновляются каждый раз, когда изменяются длительность плановых операций, допущения, сделанные при оценке длительности операций, и различные резервы, предусмотренные на случай непредвиденных обстоятельств.
Стоимостная оценка - это процесс установления стоимости ресурсов проекта, основанный на определенных фактах и допущениях. Для определения стоимостной оценки прежде всего необходимо определить операции (пакет операций), длительность операций и требуемые ресурсы. Процесс оценки и его результат в значительной степени зависят от точности описания содержания, качества доступной информации, от стадии проекта. На процесс стоимостной оценки оказывают влияние время, отведенное для проведения оцениваемой операции, опыт менеджера, инструменты оценивания, заданная точность. Оценка стоимости проекта начинается на пред-проектной стадии (до заключения контракта) и выполняется в течение всего времени выполнения проекта.
Выделяют следующие оценки стоимости:
На предпроектной стадии первоначально может определяться только порядок величины стоимости. Точность оценки порядка величины стоимости проекта может колебаться от -50% до +100%. Точность концептуальной оценки находится в интервале -30% - +50%. Точность предварительной оценки проекта колеблется от -20% до +30%. На этапе окончательной оценки точностьколеблется от -15% до +20%. Контрольная оценка имеет точность от -10% до +15%. Таким образом, каждая последующая стадия жизненного цикла проекта имеет более точную стоимостную оценку (см. рис. 2.5).
Рис. 2.5. Классификация типов оценок стоимости
Стоимостная оценка обычно выражается в единицах валюты (доллары, рубли и т. д.) для облегчения сравнения проектов и операций внутри проекта.
Стоимость плановых операций оценивается для всех ресурсов, задействованных в проекте. К ресурсам относятся, в частности, специалисты, оборудование, телефонная связь, Интернет, арендованные помещения, а также особые статьи расходов, например, учет уровня инфляции или расходы на непредвиденные обстоятельства.
На фазе планирования проекта имеет смысл использовать менее точные и менее затратные способы оценки стоимости.
К сведениям, имеющим большую важность для успешной реализации оценки стоимости, относятся:
Первые определяют структуру основных элементов оценки, вторые необходимо принимать по части обеспечения персоналом и аутсорсинга, что является ключевым элементом калькуляции себестоимости проекта.
Оценка "сверху вниз" применяется на ранних стадиях в условиях недостаточной информации о проекте. Производится только одна оценка стоимости всего проекта на самом верхнем уровне. Такая оценка не требует больших усилий, но имеет низкуюточность.
Оценка по аналогам представляет вид оценки "сверху вниз". Она подразумевает оценку текущего проекта, называемого целевым, на основе фактической стоимости одного или нескольких предыдущих проектов (аналогичных или исходных) близкого размера, сложности и содержания. Менеджеры, выполняющие оценку, могут опираться на инстинктивное чутье, исторические данные или приблизительные расчеты, модифицированные так, чтобы учесть любые различия между целевым и аналогичным проектами. При наличии очень похожего проекта оценка может быть довольно точной. Такой тип оценки применяется на любом этапе жизненного цикла проекта. Оценка по аналогам не требует больших усилий при гарантированной точности, однако не всегда удается найти и определить схожие проекты. Точность оценки по аналогии колеблется от -30% до +50%. Стоимостьподготовки такой оценки составляет 0,04%-0,15% от общей стоимости проекта.
Процесс выработки оценки по аналогии включает в себя определение специфики предварительного планирования: конечныепользователи, цель и формат оценивания, список участников процесса и их роли, доступные ресурсы. Затем следует изучение целевого проекта: его содержания, размера и показателей сложности. Далее происходит обращение к базе данных предыдущих проектов с целью их оценки. Наиболее подходящий проект (или проекты) отбирается в качестве аналогов. Соотнесение проекта-аналога и проекта-цели сложностей не вызывает, поскольку они наделены сходным набором характеристик. Затем следует перенести решение, которое позволило достичь цели при выполнении аналога, на целевой проект, корректируя элементы, не имеющие полного соответствия.
Чтобы получить денежный эквивалент затраченного времени, нужно умножить количество часов на расценки. Сумма всех оцененных элементов равна общей оценке проекта. Для менеджеров крайне важно умение выявлять скрытые различия между элементами исходного и целевого проектов и оценивать стоимость элемента целевого проекта на основе исходного, в действительности являющегося подобным или аналогичным. Проверка, пересмотр и улучшение, как было сказано в предыдущем разделе, представляют собой финальный шаг в разработке оценки по аналогии.
Оценка по аналогии предпочтительна в том случае, когда детальная информация о проекте отсутствует.
Параметрическая оценка применяется на ранних этапах проекта. Процесс параметрической оценки состоит в определении параметров оцениваемого проекта, которые изменяются пропорционально стоимости проекта. На основании одного или нескольких параметров создается математическая модель. Например, в качестве параметра разработки программного обеспечения может быть выбрана стоимость разработки строки кода. Для оценки стоимости обследования может быть выбрано количество автоматизируемых бизнес-процессов. Наиболее распространенным параметром оценки стоимости IT-проектов является количество требуемого рабочего времени на выполнение операций (пакета операций). При тесной связи между стоимостью и параметрами проекта и при возможности точного измерения параметров можно увеличить точность расчетов. Преимущество данного метода - для оценки стоимости проекта достаточно знать "ставки" привлекаемых ресурсов; недостатком является низкая точность (-30%-+50%). Стоимость подготовки параметрической оценки составляет 0,04%-0,45% от общей стоимости проекта.
Для того чтобы разработать параметрическую оценку надлежащего качества, необходимо собрать качественную исходную информацию, в которую должны входить [18]:
Параметрические оценки наиболее часто применяются на стадии определения проекта и на начальных стадиях проектирования, когда еще нет достаточного количества информации для разработки восходящей оценки.
Стоимостная оценка должна производиться компетентными сотрудниками, определение которых можно произвести в соответствии со следующими критериями [8].
Один из способов зафиксировать результаты оценки стоимости проекта - формирование сметы проекта, документа, отражающего разбивку стоимости проекта по основным категориям затрат проекта. Приведенный ниже подход к формированию сметы в большей степени соответствует параметрическому методу оценки стоимости проекта: нами выделены различные параметры, характеризующие стоимость проекта, предложена их цена за единицу и установлен коэффициент для расчета итоговых затрат по категории.
Шаблон сметы проекта
Проверка качества составления сметы проекта
Приведенный ниже контрольный список содержит пункты, рекомендованные применительно к сметам проектов.
Разработка базового плана по стоимости проекта
Базовый план по стоимости - это распределенный во времени суммарный исходящий денежный поток проекта, используемый для измерения и мониторинга исполнения стоимости проекта. Его разработка производится суммированием оценочных расходов в течение определенного временного периода; такой план отражает значение оценочных расходов и срок, когда предполагается их возникновение, при условии следования определенному порядку выполнения проектных задач и работ. Часто изображается в виде S-кривой (см. рис. 2.6).
|
Таблица 2.4. Пример сметы проекта |
|||
|
Оценка совокупной стоимости проекта для базового плана по стоимости |
0 |
||
|
Оценка совокупной стоимости проекта |
0 |
||
|
Итоговая сумма |
0 |
||
|
Прямые расходы |
0 |
||
|
Стоимость работ (консалтинг) |
0 |
||
|
Категория специалиста |
Трудозатраты (дни) |
Ставка (ден. единиц / день) |
Итого |
|
Специалист 1 |
0 |
||
|
Специалист 2 |
0 |
||
|
Специалист 3 |
0 |
||
|
Специалист 4 |
0 |
||
|
Специалист 5 |
0 |
||
|
Специалист 6 |
0 |
||
|
Специалист 7 |
0 |
||
|
Специалист 8 |
0 |
||
|
Специалист 9 |
0 |
||
|
Командировочные расходы |
0 |
||
|
Категория |
Количество / параметр |
Стоимость на единицу |
Итого |
|
Проезд |
0 |
||
|
Вид1 |
0 |
||
|
Вид 2 |
0 |
||
|
ВидЗ |
0 |
||
|
Командировочные |
0 |
||
|
Специалист 1 |
0 |
||
|
Специалист 2 |
0 |
||
|
Специалист 3 |
0 |
||
|
Специалист 4 |
0 |
||
|
Специалист 5 |
0 |
||
|
Специалист 6 |
0 |
||
|
Специалист 7 |
0 |
||
|
Специалист 8 |
0 |
||
|
Специалист 9 |
0 |
||
|
Представительские расходы |
0 |
||
|
Руководитель проекта |
0 |
||
|
Спонсор |
0 |
||
|
Сумма резервов на непредвиденные обстоятельства |
0 |
||
|
Категория |
Вероятность |
Стоимостная оценка |
Итого |
|
Вид 1 |
0 |
||
|
Вид 2 |
0 |
||
|
ВидЗ |
0 |
||
|
Накладные расходы |
0 |
||
|
Стоимость оборудования (ПО, лицензий) |
0 |
||
|
Категория |
Количество / параметр |
Стоимость на единицу |
Итого |
|
стоимость оборудования (hardware) |
0 |
||
|
логистика (доставка, страховка, охрана, таможня) |
0 |
||
|
гарантийное обслуживание (техподдержка ПО) |
0 |
||
|
стоимость лицензий с НДС |
0 |
||
|
стоимость поддержки программного продукта (до окончания проекта) |
0 |
||
|
Стоимость обучения |
0 |
||
|
Тип тренинга |
Количество обучаемых |
Стоимость курса |
Итого |
|
Тренинг 1 |
б |
||
|
Тренинг 2 |
0 |
||
|
Тренинг 3 |
0 |
||
|
Тренинг 4 |
0 |
||
|
Тренинг 5 |
0 |
||
|
Затраты на инфраструктуру проекта |
0 |
||
|
Категория |
К оличество / параметр |
Стоимость на единицу |
Итого |
|
аренда помещения |
0 |
||
|
оборудование рабочих мест |
0 |
||
|
коммунальные платежи |
0 |
||
|
оплата телекоммуникационных услуг |
0 |
||
|
телефонная связь |
0 |
||
|
Интернет |
0 |
||
|
Сумма управленческого резерва |
0 |
Построение базового плана по стоимости [18]
Построение базового плана по стоимости начинается со сбора исходной информации, к которой относятся:
Подготовка базового плана по стоимости представляет собой установление отношения между оценкой стоимости и временными параметрами проекта. Для выстраивания этого соответствия требуются четкие критерии, которые определяют как события проекта, инициирующие выплаты по включенным в элементам (статьям) расходов, так и время, проходящее между инициирующими событиями и соответствующими им выплатами. Например, при выплате зарплат членам команд управления проектами такую роль играет рабочий график этих сотрудников, который и инициирует расчет в конце каждого месяца. Интервалы - для оплат внутри и вне организации - определяются временем, необходимым для внутренней и внешней коммуникации, утверждения и выполнения административных процедур, а также политиками компаний, которые склонны удерживать у себя деньги столь долго, сколь это представляется возможным, поскольку это сокращает дебиторский цикл, а следовательно, снижает оборотный капитал компании. Далее следует анализ критериев и их письменное определение, которые позволяют распределить расходы по временным периодам в процессе формирования базового плана.
Рис. 2.6. S-кривая базового плана по стоимости
Как только тип базового плана стоимости выбран, статьи расходов, подлежащие включению в него, идентифицированы и критерии формирования определены, можно считать, что основы для распределения расходов по временным периодам заложены. После чего следует процесс обозначения и структурирования статей расходов.
Желательно, чтобы проект имел собственную систему обозначения расходов, согласованную с системой обозначения расходов компании или с принятыми в данной отрасли стандартами. Если стоимость разрабатывается на основе восходящей ("снизу вверх") оценки, его элементы можно структурировать в соответствии с ИСР, при помощи пакетов работ из ИСР проекта. Если же для его построения используется оценка по аналогии или параметрическая оценка, лучше задействовать другие методы структурирования.
Суммирование оценочных значений расходов по временным периодам. Когда все оценки статей расходов распределены по конкретным временным периодам, необходимо просуммировать расходы по этим периодам. Таким образом, получаетсяинформация об инкрементных расходах этих периодов (расходах, имеющих место в течение каждого месяца), которые потребуются на следующем шаге для графического отображения базового плана стоимости.
Графическое отображение базового плана стоимости.S-кривая является широко распространенным способом показа базового плана стоимости, выражаемого в виде накопительных расходов (см. рис. 2.6.). Для вычисления кумулятивных расходов первых двух периодов необходимо прибавить расходы первого периода к расходам второго. Добавив это значение к инкрементным расходам третьего периода, можно получить кумулятивное значение расходов первых трех периодов. Данную процедуру можно продолжать, находя последовательно кумулятивные расходы для первых четырех, пяти и т. д. периодов, а затем построить кривую кумулятивных расходов по оси ординат относительно времени по оси абсцисс .Результатом станет в видеS -кривой. Далее, как и при разработке других типов оценки стоимости, базовый план нужно проверять и пересматривать.
Выгоды построения базового плана по стоимости
Отсутствие эффективного базового плана стоимости, даже при наличии оценки стоимости и требований к трудовым ресурсам, представляет собой значительную угрозу для проекта: измерение хода исполнения проекта и потока денежной наличности становится затруднительным, если не невозможным. Имеющийся базовый план по стоимости допустимо использовать в качестве базового плана для оценки хода исполнения проекта по методу освоенного объема (см. соответствующий раздел).
Прогнозирование потока денежной наличности - еще одно достоинство, обеспечиваемое эффективным базовым планом: он заблаговременно информирует руководство или заказчика о том, что в некоторый момент должны быть доступны определенные фонды, которые потребуются для поставки ресурсов и продолжения реализации проекта. Чтобы надлежащим образом выполнял эту роль, он должен быть организован так, чтобы отражать продвижение и ход исполнения на текущую дату [18].
Действия по формированию базового плана стоимости относительно просты, независимо от того, выполняются они вручную или с помощью компьютера. Следует также сказать, что визуальное представление плана в виде S-кривой облегчает его восприятие.