Выбор типа ИСР

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

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

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

3. Определение степени детализации ИСР

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

Для определения степени детализации ИСР нужна следующая информация:

• количество уровней в ИСР ;

• количество и средний размер пакета работ, принятые в отрасли. Так, для большинства средних и малых ИТ-проектов характерны

ИСР со следующей детализацией:

• от трех до четырех уровней;

• от 15 до 40 пакетов работ;

• от 40 до 80 часов на средний пакет работ;

• от 3% до 7% общего бюджета рабочих часов на средний пакет работ [18].

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

3. Определение содержания проекта

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

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

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

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

• устав проекта;

• формулировка требований организации-заказчика;

• ТЭО;

• внутрикорпоративная методология управления проектами и соответствующие политики.

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

Таблица 2.1. Требования к описанию содержания проекта

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

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

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

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

Рис. 2.1. Модель критических факторов успеха в динамике этапов жизненного цикла информационной системы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• методология внедрения ИС;

• контракт;

• описание содержания проекта;

• иерархическая структура работ ( ИСР );

• словарь ИСР.

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

• декомпозиция;

• шаблоны;

• планирование методом набегающей волны;

• экспертная оценка.

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

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

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

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

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

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

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

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

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

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

2. методология внедрения ИС;

3. результаты процесса определения состава операций;

4. список операций;

5. параметры операций;

6. список контрольных событий;

7. одобренные запросы на изменение.

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

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

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

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

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

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

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

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

Рис. 2.2. Фрагмент расписания проекта в виде диаграммы Гантта MS Project

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

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

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

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

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

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

• ФИО;

• возраст;

• образование;

• курсы повышения квалификации;

• должность в компании;

• краткая характеристика;

• перечень проектов, в которых принимал участие, роль и объем работ, качество проделанной работы;

• график работы (является основой для календаря ресурса);

• доступность (коэффициент доступности, отпуска, больничные, выставки и т.д.).

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

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

• список операций. Список операций определяет плановые операции для оцениваемых ресурсов;

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

• наличие ресурсов. Для оценки типов ресурсов используется информация о том, какие ресурсы (функциональные консультанты, бизнес-аналитики, серверы и т. п.) потенциально доступны;

• план управления проектом. План управления расписанием является составляющей частью плана управления проектом и используется в оценке ресурсов операций;

• ресурсные календари устанавливают, когда и насколько определенные ресурсы проекта будут доступны на протяжении проекта.

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

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

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

• Экспертная оценка. Такую оценку может дать экспертная группа, имеющая специальную подготовку в области планирования и оценки ресурсов.

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

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

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

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

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

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

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

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

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

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

Таблица 2.3. Нормативы трудоемкости разработки документов на АС

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

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

Рис. 2.4. Диаграмма Гантта с привязкой к ресурсам

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

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

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

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

• Список операций - результат процесса определения взаимосвязи операций.

• Параметры операций - результат процесса определения взаимосвязи операций.

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

• Календарь ресурсов - результат процесса оценки ресурсов операций.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• концептуальная оценка;

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

• окончательная оценка;

• контрольная оценка.

На предпроектной стадии первоначально может определяться только порядок величины стоимости. Точность оценки порядка величины стоимости проекта может колебаться от -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].

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

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

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

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

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

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

• Система обозначений расходных категорий проекта.

• Ясно и четко сформулированное описание элементов.

• Явное указание количества элементов по категориям затрат.

• Явное указание стоимости единицы для каждого элемента категории затрат.

• Явное отражение управленческого и резерва на непредвиденные обстоятельства.

• Отдельное отражение стоимости материалов и элементов и стоимости работ.

• Отражение совокупной стоимости проекта (с учетом и без учета резервов).

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

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

Таблица 2.4. Пример сметы проекта

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

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

• результаты оценки стоимости проекта;

• ИСР ;

• расписание проекта.

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

Рис. 2.6. S-кривая базового плана по стоимости

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

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

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

Графическое отображение базового плана стоимости

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

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

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

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

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

4. Разработка расписания проекта

Исходные данные для разработки расписания. Результаты разработки расписания. Технология разработки расписания. Разработка расписания проекта методом критического пути. Организация управления расписанием проекта. Исходная информация для процесса управления расписанием. Линия исполнения. Построение линии исполнения проекта. Диаграмма контрольных событий. Построение диаграммы контрольных событий.

1. Исходные данные для разработки расписания

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

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

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

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

Диаграмма Гантта - диаграмма, которая использует горизонтальные полосы для представления операций проекта, показывает даты начала и завершения каждой операции и проекта относительно горизонтальной шкалы времени [18].

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

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

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

• сбор исходной информации для построения диаграммы;

• построение сетевой диаграммы, отражающей взаимосвязь операций;

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

• выбор контрольных событий - событий, которые являются главными для продвижения проекта;

• упорядочивание контрольных событий - изучение взаимосвязей и определение последовательности их выполнения;

• нанесение контрольных событий на детальное расписание проекта ;

• проверка равномерности распределения контрольных событий по расписанию проекта.

2. Результаты разработки расписания

Результатами процесса разработки расписания являются:

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

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

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

• требования к ресурсам (обновления);

• параметры операции (обновления);

• календарь проекта (обновления);

• запрошенные изменения. В процессе разработки расписания могут появиться запрошенные изменения, которые обрабатываются в процессе общего управления изменениями;

• план управления проектом (обновления). План управления проектом обновляется с отражением всех одобренных изменений в способах управления расписанием проекта.

3. Технология разработки расписания

При разработке расписания рекомендуется соблюдать следующую последовательность работ [23]:

• определить перечень операций, которые должны быть включены в расписание;

• определить взаимосвязь операций;

• определить длительность каждой операции;

• рассчитать с помощью прямого прохода раннее расписание для каждой операции;

• рассчитать с помощью обратного прохода позднее расписание для каждой операции;

• вычислить временной резерв для каждой операции;

• определить критический путь ;

• сравнить дату предполагаемого завершения проекта с датой завершения проекта по обязательству;

• подкорректировать расписание или дату завершения проекта по обязательству, если завершение проекта по расписанию предполагается раньше этой даты;

• определить ограничения на ресурсы;

• откорректировать расписание в соответствии с ограничениями на ресурсы;

• проверить, не планируется ли завершение проекта по откорректированному расписанию раньше даты обязательства;

• согласовать расписание.

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

Таблица 3.1. Шаблон последовательного формирования расписания проекта

Далее следует пример его использования для фазы подготовки проекта (см. табл. 3.2).

Таблица 3.2. Пример использования шаблона последовательного формирования расписания

Логическая последовательность и трудоемкость работ

Закрепление ролей исполнителей за проектными работами

Закрепление ролей исполнителей за проектными работами

4. Разработка расписания проекта методом критического пути

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

• Создать перечень операций, которые должны быть включены в расписание.

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

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

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

• Определить предшествующую операцию для каждой операции.

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

• Рассчитать с помощью прямого прохода (forward pass) раннее расписание (early schedule): ранний старт (ES) и ранний финиш (EF) для каждой операции.

При расчете раннего расписания для операций требуется придерживаться нескольких правил составления расписаний (scheduling conventions). Данные правила приняты сообществом по составлению расписаний (scheduling community). В расписании старт первой операции всегда назначается на дату старта проекта. Эта дата является входом плана проекта. Первая дата старта является стартом проекта. Дата раннего финиша - это дата раннего старта плюс длительность операции. При этом применяется следующее правило. Считается, что каждая операция начинается в момент начала того периода, в который она стартует, и оканчивается в момент завершения периода, в который она завершается. Это означает, что если длительность операции составляет один день и если она начинается первого января, то заканчивается данная операция также первого января. В соответствии с данным правилом ранний финиш любой операции равен раннему старту плюс длительность минус один. Таким образом, операция 1 начинается в день 1 и заканчивается в день 15 (см. табл. 3.3). Следующая операция должна начаться в следующий доступный временной период: поскольку операция 1 заканчивается в день 15, операция 2 должна начаться в день 16, а закончиться в день 20. Операции 3 и 4 представляют следующую проблему. Эти операции зависят от операции 2, т. е. операция 2 должна окончиться перед их стартом. Очевидно, что датой раннего старта обеих операций будет день 21.

Формула 1. Расчет раннего финиша

EF=ES + Длительность - 1

• Рассчитать с помощью обратного прохода (backward pass) позднее расписание (late schedule) для каждой операции.

Для выполнения обратного прохода необходимо начинать с последней операции, которая была выполнена в раннем расписании. Логическим обоснованием этого является следующее: если раннее расписание определяет самую раннюю дату завершения проекта, то в обратном проходе мы ищем для всех операций самые поздние даты их выполнения, при которых проект мог бы быть полностью выполнен. Мы начинаем с наиболее поздней из дат раннего финиша, соответствующей завершению последней операции. Это время позднего финиша (LF). Для получения времени позднего старта (LS) из времени позднего финиша вычитается длительность. Даты позднего расписания (поздний старт и поздний финиш) для операции 11 будут соответственно днями 90 и 94. Поскольку дата позднего старта операции 11 - день 90, операции 10 и 3 должны быть окончены не позднее дня 89. Это будет датой позднего финиша для обеих операций. Таков самый поздний срок завершения данных операций для того, чтобы обеспечить завершение проекта в день 94 и дату позднего старта операции 11. Для получения дат позднего старта для каждой операции вычитаются их длительность. При рассмотрении операции 2 надо быть очень внимательными в выборе даты позднего финиша, которая также согласуется с датами позднего старта операций 3, 4 и 6. Поскольку датами позднего старта операций 3, 4 и 6 являются дни 86, 53 и 21, соответственно, датой позднего финиша операции 2 является день 20.

Таблица 3.3. Операции проекта

Формула 2. Расчет позднего финиша

LS=LF - Длительность + 1

• Вычислить временной резерв ( float ) для каждой операции.

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

Формула 3. Расчет временного резерва

float = LS - ES = LF - ES

• Определить критический путь (critical path).

Критический путь (critical path) - это последовательность операций, имеющих нулевой временной резерв (zero float). Операции с нулевым временным резервом - это операции, задержка которых обязательно влечет за собой задержку окончания всего проекта. Операции такого типа необходимо жестко контролировать, чтобы обеспечить завершение работы над проектом в установленное время. И наоборот, операции, которые не лежат на критическом пути и имеют ненулевой временной резерв, необязательно контролировать так жестко. К тому же, важно знать, выполнение каких операций проекта может быть задержано без изменения даты завершения проекта. Ресурсы операций, имеющих резерв времени, при необходимости могут быть использованы для выполнения обхода (workaround).

• Определить, не состоится ли предполагаемое завершение проекта раньше даты обязательства (promise date).

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

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

• Подкорректировать расписание или дату обязательства.

Затем надо отрегулировать расписание или дату обязательства. Возможны две ситуации: расписание с датой обязательства более ранней, чем предварительно определенная дата, и расписание с датой обязательства более поздней, чем предварительно определенная дата. Если предварительная дата расписания является более поздней, чем обязательства, то необходимо применять сжатие (crashing) или быстрый проход (tracking).

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

• Запросить ресурсы и определить ограничения на ресурсы.

• Отрегулировать расписание в соответствии с ограничениями на ресурсы.

• Определить, не состоится ли предполагаемое завершение проекта раньше даты обязательства.

• Подкорректировать расписание или дату обязательства.

• Получить одобрение расписания (согласовать расписание).

5. Организация управления расписанием проекта

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

Исходная информация для процесса управления расписанием

План управления расписанием определяет, как будут осуществляться контроль и управление расписанием проекта.

Базовый план расписания является составляющей плана управления проектом и основой для измерения исполнения расписания и отчетности по ней в рамках базового плана исполнения.

Отчеты об исполнении задач дают информацию об исполнении расписания.

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

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

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

Таблица 3.4. Шаблон формы отчета о прогрессе проекта

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

Измерение эффективности

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

Анализ отклонений

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

Сравнительные диаграммы расписания

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

6. Линия исполнения

Линия исполнения показывает, на какое количество времени каждая операция проекта опережает базовое расписание или отстает от него [18].

Слева от линии исполнения показана выполненная доля каждой операции, справа - оставшаяся доля. По мнению Драгана З. Милошевича [18], в передовых приложениях последнего времени линия баланса исполнения рассматривается как один из шагов проактивного управления расписанием. Количество времени, на которое операция отстает от базового расписания, используется для корректировки воздействий для устранения возможной задержки.

Построение линии исполнения проекта

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

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

   • Каково отклонение фактического расписания от базового?

   • Какие проблемы вызывают отклонения?

   • Какие новые риски могут возникнуть и как они могут повлиять на дату завершения операции?

   • Каков текущий тренд выполнения проекта?

   • Какие действия наметил владелец операции для предотвращения срыва сроков выполнения операции?

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

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

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

Рис. 3.1. Пример линии исполнения проекта (адаптировано из [18])

5. Рисование линии исполнения.

   • Взять базовое расписание проекта и отметить на календаре (в шапке базового расписания) дату проведения совещания - статусную или отчетную.

   • От этой даты рисовать вниз вертикальную линию до пересечения со строкой первой операции

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

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

7. Диаграмма контрольных событий

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

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

Рис. 3.2. Пример диаграммы прогнозирования контрольных событий

Построение диаграммы контрольных событий

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

На горизонтальной оси отмечают те же даты наступления контрольных событий.

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

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

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

5. Планирование обеспечения качества проекта

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

1. Разработка плана обеспечения качества

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

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

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

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

Таблица 4.2. План обеспечения качества проекта

2. Регламент по управлению качеством в проекте

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

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

Таблица 4.1. Анализ процессов управления качеством

3. Примеры процедур планирования качества Процедура документирования

Настоящая процедура предназначена для управления документированием в проекте.

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

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

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

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

Для проведения процедуры согласования выделяются сотрудники, ответственные за согласование.

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

Согласующее должностное лицо проводит анализ документа и в течение 3-х дней направляет свои замечания ответственному за согласование.

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

Процедура утверждения документов

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

Формируется пакет документов, состоящий из двух электронных копий документов на CD и листов, на которые ставятся подписи (обложка и лист согласования на каждый утверждаемый документ). Два идентичных пакета документов предназначены для заказчика и исполнителя.

На следующий день, в оговоренное время, пакет документов доставляется в кабинет утверждающего лица. Документы, утверждаемые на УК, печатаются в полном объеме (не только подписные листы).

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

После этого документ считается утвержденным. Подписанные листы и соответствующие электронные версии документов являются утвержденными версиями проекта.

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

Таблица 4.3. Определение списка процедур для управления качеством

4. Организация управления качеством

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

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

Для обеспечения процесса оценки качества проекта на стадии планирования разрабатываются контрольные списки качества - таблицы с инструкциями для проверяющего лица. Пункты контрольного списка должны быть достаточно значимыми, поскольку, если контрольный список будет перегружен, его не будут использовать (см. табл. 4.4). Контрольные списки качества - это метрики качества, которые определены для каждого этапа проекта на основании ожиданий заказчика, этим метрикам присвоен свой статус: критический, серьезный, важный. Включение в контрольные списки качества неважных метрик нежелателен, так как иначе данныйсписок не будет использоваться. Преимуществом его применения является простота, даже на малых проектах для данного инструмента не требуется больших затрат ресурсов и времени, при этом с помощью контрольного списка качества можно на этапе выполнения работ отследить, что не было выполнено из требований заказчика [11].

Таблица 4.4. Пример контрольных списков проверки качества

Пояснения к заполнению формы контрольных списков

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

• Ожидаемый результат - метрика качества, которую необходимо достичь.

• Тип - присвоенный тип данной метрики, может быть критический, серьезный, желательный.

• Да/Нет - достигнут ли ожидаемый результат. Заполняется на этапе контроля и обеспечения качества проекта.

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

Таблица 4.5. Форма представления результатов контроля качества

На рис. 4.1 приведено графическое изображение процедуры разработки контрольных списков качества.

Рис. 4.1. Процедура разработки контрольных списков (графическое изображение)

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

• анализ исправления замечаний предыдущей проверки;

• проведение проверки проекта в соответствии с контрольными списками ;

• оформление отчета о контроле качества;

• информирование команды проекта о появлении новых отчетных документов.

Ниже приведен шаблон для регистрации списка отклонений и описание процедуры обеспечения качества (табл. 4.6).

Таблица 4.6. Шаблон регистрации отклонений

Рис. 4.2. Графическое описание процедуры управления качеством

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

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

1. Основные понятия управления рисками

Риск проекта - это кумулятивный эффект  вероятностей наступления неопределенных событий, способных оказать отрицательное или положительное влияние на цели проекта [23]. Риски подразделяются на известные и неизвестные. Известные рискиидентифицируются и подлежат управлению - создаются планы реагирования на риски и резервы на возможные потери. Неизвестныериски нельзя определить, и следовательно, невозможно спланировать действия по реагированию на такой риск.

Событие риска - потенциально возможное событие, которое может нанести ущерб или принести выгоды проекту [23].

Вероятность возникновения риска - вероятность того, что событие риска наступит [23]. Все риски имеют вероятность больше нуля и меньше 100%. Риск с вероятностью 0 не может произойти и не считается риском. Риск с вероятностью 100% также не являетсяриском, поскольку это достоверное событие, которое должно быть предусмотрено планом проекта.

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

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

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

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

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

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

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

Бюджетирование - определяет бюджет для управления рисками проекта.

Временные рамки - устанавливают частоту процессов управления рисками.

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

Контроль - раздел, определяющий формат плана реагирования на риски.

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

Примером методологии является дисциплина управления рисками MSF (Microsoft Solutions Framework) [11]. MSF описывает процесс непрерывного выявления и оценки рисков, их приоритизации и реализации стратегий по превентивному управлению рисками на протяжении всех фаз жизненного цикла проекта.

Методы управления проектными рисками для малых и средних проектов достаточно проработаны и позволяют эффективно снижать уровень рисков и трудозатраты по проекту (см. табл. 5.1) Для ведения крупных проектов "стандартного" набора методов оказывается недостаточно [15].

Таблица 5.1. Примеры управления рисками

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

На этапе планирования в соответствии с принятой политикой и процедурами в процессе управления рисками организация должна осуществлять следующие действия:

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

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

• идентифицировать риски.

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

2. Определение уровней вероятности возникновения рисков и их последствий

Общие определения уровней вероятности и уровней воздействия адаптируются отдельно для каждого проекта в ходе процесса планирования управления рисками и используются в процессе качественного анализа рисков. Можно применить относительную шкалу, на которой вероятность обозначена описательно, со значениями от "крайне маловероятно" до "почти наверное", или шкалу, на которой вероятности соответствует цифровое значение, например: 0,1 - 0,3 - 0,5 - 0,7 - 0,9. В табл. 5.2 представлено семиуровневое разделение вероятности [11]. Для каждого интервала вероятностей выполнена относительная и числовая оценка.

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

Таблица 5.2. Семиуровневая оценка вероятности возникновения риска

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

Когда денежные единицы не могут быть применены, проектная группа может использовать другие шкалы оценки последствий риска (см. табл. 5.4). Система оценки воздействий должна отражать политику и ценности организации и проектной группы.

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

Таблица 5.5. Определение шкалы оценки воздействия для четырех целей проекта

Рис. 5.1. Матрица воздействия (вероятностей и последствий) рисков

Относительная шкала последствий разрабатывается каждой организацией самостоятельно. Шкала содержит только описательные обозначения, например, "очень низкий", "низкий", "средний", "высокий" и "очень высокий", расположенные в порядке возрастания максимальной силы воздействия риска согласно определению данной организации. То же самое можно сделать иначе, путем присвоения данным последствиям цифровых значений, которые могут быть линейными и нелинейными, например, 0,1 - 0,3 -0,5 - 0,7 - 0,9 или 0,05 - 0,1- 0,2 - 0,4 - 0,8. В табл. 5.5 представлены как относительный, так и цифровой (в данном случае нелинейный) способы обозначения последствий риска для четырех целей проекта [23].

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

Матрица вероятности и последствий содержит комбинации вероятности и воздействия, при помощи которых рискамприсваивается определенный ранг: низкий, средний или высший [23]. Матрица может содержать описательные термины или цифровые обозначения (см. рис. 5.1) и строится на основании шкал оценки вероятности и оценки степени влияния возможногориска. Левый столбец матрицы содержит значения вероятности возникновения риска, в первой строке расположена шкала со значениями возможных последствий. Ячейки заполняются результатами перемножения значений этих шкал. Сопоставляя значениеячейки матрицы со шкалой оценки воздействия, риски можно разделить по категориям: малые, средние и большие. Рассмотрим матрицу вероятности и последствий, представленную на рис. 5.1. Риски, имеющие очень высокую вероятность, но незначительные последствия, а также риски, имеющие низкую вероятность и незначительные последствия, считаются рисками, не оказывающими воздействия (клетки таблицы серого цвета). Риски с очень большими последствиями, но малой вероятностью, как и риски с незначительными последствиями и высокой вероятностью (клетки светло-серого цвета), имеют среднее воздействие на проект.Риски, которым необходимо уделять особое внимание, имеют достаточно высокую вероятность и существенные последствия (клетки таблицы, окрашенные темно-серым цветом).

3. Методики идентификации рисков

Для идентификации рисков используют следующие методы [11,23].

Мозговой штурм.Целью мозгового штурма является создание подробного списка рисков проекта. Список рисков разрабатывается на собрании, в котором принимает участие 10-15 человек - члены команды проекта, часто совместно с участием экспертов из разных областей, не являющихся членами команды. Участники собрания называют риски, которые считают важными для проекта, при этом не допускается обсуждение выдвинутых рисков. Далее риски сортируют по категориям и уточняют.

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

Метод номинальных групп позволяет идентифицировать и расположить риски в порядке их важности. Данный метод предполагает формирование группы из 7-10 экспертов. Каждый участник индивидуально и без обсуждений перечисляет видимые им рискипроекта. Далее происходит совместное обсуждение всех выделенных рисков и повторное индивидуальное составление спискарисков в порядке их важности.

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

Опросы экспертов с большим опытом работы над проектами.

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

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

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

Метод аналогии.Для идентификации рисков этот метод использует накопленные знания и планы по управлению рисками других аналогичных проектов.

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

Таблица 5.6. Сравнение методов идентификации рисков

Сравнение методов идентификации рисков проекта [11] представлено в табл. 5.6.

Идентифицированные риски документируются в так называемых реестрах рисков.

Примеры шаблонов реестра рисков [11] приведены в таблицах 5.7и 5.8.

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

Таблица 5.7. Шаблон реестра рисков

Таблица 5.8. Пример заполнения реестра рисков (упрощенный)

Таблица 5.9. Пример заполнения расширенного журнала рисков

4. Организация управления рисками

Согласно стандарту ISO 15288, процесс контроля включает следующие действия:

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

• ведение учета рисков в течение всего жизненного цикла.

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

Для обеспечения контроля и управления рисками на этапе планирования разрабатывают план реагирования на риски, шаблонкоторого представлен в табл. 5.10.

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

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

На рассматриваемой стадии ЖЦ ИТ наиболее вероятно возникновение рисков, вызванных следующими обстоятельствами [22]:

1. неправильно определена область применения проекта;

2. не определен спонсор проекта;

3. не разработана стратегия реагирования на риски ;

4. не определены ожидания участников проекта;

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

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

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

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

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

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

5. Пример процедуры управления рисками

Настоящая процедура применятся для управления рисками на проекте внедрения ИС. По согласованию сторон процедура может изменяться. Управление рисками выполняется на протяжении всего проекта с использованием журнала регистрации (реестра)рисков.

Запись риска

• Любой член функциональной группы от исполнителя или заказчика может сформулировать риск и инициировать его решение согласно процедуре. Риск фиксируется руководителями функциональных групп "Финансы", "Персонал" или лицами, назначенными ими; в журнале рисков необходимо дать ссылку на файл журнала рисков в проектной библиотеке.

• Одновременно оформляется форма регистрации риска ; необходимо дать ссылку на файл формы регистрации рисков в проектной библиотеке.

• Журнал рисков размещается в проектной библиотеке секретарем проекта и обновляется/дополняется ежедневно в конце дня.

• Формы регистрации рисков размещаются в проектной библиотеке и обновляются/дополняются ежедневно в конце дня.

• Управление/минимизация рисков

• Возможные варианты управления/минимизации риска обсуждаются на ежедневных оперативных совещаниях и на еженедельных совещаниях группы управления проектом и документируются в форме регистрации рисков

• Принятое решение документируется в форме регистрации рисков.

• Влияние на график работ оценивается для каждого решения.

• Если необходимо, заполняются формы - запросы на изменение.

Информация фиксируется в форме регистрации риска (см. табл. 5.11), состоящей из:

1. верхнего колонтитула с указанием:

   • имени автора, объявившего риск ;

   • функциональной области и этапа проекта, к которому относится риск ;

   • даты записи;

   • порядкового номера записи;

   • полного описание риска ;

2. формулировки текущего состояния (изменяется по мере необходимости):

   • назначенный ответственный за разрешение риска ;

   • приоритет: "критично", "высокий", "средний", "низкий";

3. изучения/минимизации риска:

   • возможные пути решения: возможные пути минимизации риска, включая влияние на проект в терминах нарушения хода проекта, времени, качества;

   • оценка влияния: оценка влияния на бизнес/технические аспекты проекта;

4. решения:

   • рекомендация: окончательное решение для утверждения;

5. утверждения:

   • утверждено исполнителем, дата;

   • утверждено заказчиком, дата;

   • соответствующий номер запроса на изменение (если присутствует запрос на изменение);

   • запрос на изменение утвержден, дата.

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

7. Планирование человеческих ресурсов проекта

Определение ролей проекта. Матрица ответственности проекта. Построение матрицы ответственности. Закрепление функций и полномочий в проекте. Реестры навыков.

1. Определение ролей проекта

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

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

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

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

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

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

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

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

Ключевые роли со стороны исполнителя - руководитель проекта (менеджер проекта) со стороны исполнителя и бизнес-менеджер.

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

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

В крупных проектах могут быть организованы комитет по управлению, комитет по контролю за изменениями, комитет по анализу спорных вопросов [8].

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

Состав команды управления должен быть достаточным, чтобы осуществлять [11]:

• управление ресурсами проекта, в том числе:

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

  • подготовка предложений по изменению состава группы управления проектом;

  • утверждение персональных изменений в составе рабочих групп проекта;

  • оценка стоимости проекта, подготовка бюджетов проекта и отчетов об исполнении бюджетов;

• управление сроками выполнения проекта, в том числе:

  • подготовка плана работ проекта;

  • контроль над выполнением проекта;

  • подготовка отчетов о ходе работ проекта;

• управление качеством проекта, в том числе:

  • контроль соответствия разрабатываемых проектных решений техническому заданию;

  • организация экспертизы проектных решений;

• управление рисками проекта, в том числе:

  • анализ рисков проекта;

  • разработка планов мероприятий по снижению рисков;

  • реализация мероприятий по снижению рисков;

• управление проблемами проекта, в том числе:

  • анализ проблем проекта;

  • разработка мероприятий по разрешению проблем проекта;

  • реализация мероприятий по разрешению проблем проекта;

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

  • согласование отчетов о ходе работ;

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

  • контроль документирования проектных результатов.

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

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

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

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

увеличить изображение Рис. 6.1. Пример организационной структуры проекта

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

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

2. Матрица ответственности проекта

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

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

Построение матрицы ответственности

1. Перечислить основные работы проекта.

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

2. Перечислить группы/роли внутри проектной команды.

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

3. Закодировать матрицу ответственности.

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

На коды, используемые в матрице ответственности, каких-либо ограничений не существует, но наибольшее распространение получил метод RACI (Responsible (R), Accountable (A), Consulted (C), Informed(I)), в котором приведено описание соответствующих кодов.

4. Инициировать использование матрицы и включить процедуру использования матрицы ответственности в документ "План управления проектом".

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

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

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

3. Закрепление функций и полномочий в проекте

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

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

Основные функции:

• общее руководство ходом реализации проекта;

• обеспечение выделения необходимых ресурсов для выполнения проекта, обеспечение финансирования работ;

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

• получение и анализ сводной отчетности о ходе реализации проекта;

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

Основные полномочия:

• утверждение целей проекта;

• согласование назначения руководителя проекта;

• утверждение общего плана и бюджета проекта;

• получение от руководителя проекта сводной отчетности о ходе его выполнения;

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

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

Основные функции:

• формирование команды проекта и команды управления проектом;

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

• распределение ресурсов проекта и организация взаимодействия команды проекта в процессе его выполнения;

• организация взаимодействия с заказчиком и обеспечение всех необходимых коммуникационных связей с другими участниками проекта;

• учет фактических затрат ресурсов по исполнению проекта;

• формирование и предоставление куратору отчетности по проекту.

Основные полномочия:

• назначение задач команде проекта (отдельным ее членам) и контроль их выполнения;

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

• подтверждение или отклонение отчетов о фактических затратах исполнителей проекта;

• обоснование необходимости и запрос куратору проекта на выделение дополнительных ресурсов на проект;

• обращение к куратору за поддержкой в случае необходимости.

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

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

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

Основные функции:

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

• определение ресурсов, которые необходимы для разработки и внедрения ИС в рамках, заданных условиями проекта;

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

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

• организация подготовки, согласования и утверждения всей технической документации, необходимой для создания ИС в рамках проекта;

• планирование и согласование фактических трудозатрат специалистов при исполнении проекта;

• формирование и предоставление руководителю проекта необходимой отчетности;

• анализ хода выполнения и промежуточных результатов создания ИС;

• организация, проведение и документирование процедур передачи заказчику разработанной ИС.

Основные полномочия: