Организация управления конфигурацией проекта 2 страница

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

Как известно, стоимость исправления ошибок из-за неточностей, в том числе в планировании проекта, в десятки раз превышает затраты на подготовку детальных, согласованных и выверенных проектных планов. Завершение этапа планирования стадии рекомендуется производить только после того, как будет произведена проверка проекта в соответствии с приведенными в табл. 8.1 пунктами [8].

Таблица 8.1. Проверочный список для этапа планирования
Аспект	Показатели
Участники проекта	· Цель проекта четко сформулирована [спонсором] перед командой проекта и отражена в ключевых документах проекта: устав, описание содержания. · Проектная команда поняла и приняла цель проекта. · Члены проектной команды понимают, каким образом реализуемый проект связан с основной деятельностью и стратегией компании заказчика. · Каждый член проектной команды имеет ясное представление о своей роли и месте в проекте. · Субподрядчики и сотрудники, работающие менее 100% их рабочего времени, понимают свой вклад в проект и дали согласие работать в соответствие разработанными правилами. · Руководители функциональных подразделений, выделяющие сотрудников для участия в проекте, имеют представление о проектных задачах, стоящих перед их подчиненными, и готовы оказывать содействие своим сотрудникам на протяжении всего проекта. · Представители клиента учтены в коммуникационном плане проекта и приняли условие проведения регулярных информационных встреч по статусу и другим вопросам проекта
Процессы и процедуры проекта	· В плане управления проектом присутствуют базовое расписание и базовый план по стоимости проекта. · План управления проектом содержит информацию о всех проектных работах, об ответственных за эту работу и доступен всем членам проектной группы. · Предусмотрена процедура отслеживания исполнения расписания проекта для каждого члена проектной команды. · Внедрен процесс интегрированного управления изменениями. · Внедрена процедура ведения журнала рисков. Сам журнал рисков доступен для заполнения всем членам проектной команды. · План управления конфигурацией проектом точно определяет размещение всей проектной документации, используемые сокращения и принятые наименования, а также предусматривает процедуру управления версионностью документов. · Руководство компании удовлетворено предложенным форматом проектных отчетов и установленной периодичностью их предоставления. · Установлено и согласовано расписание проведения отчетных встреч по проекту с участием всех членов проектной команды
Команда проекта	· В командах установлены базовые правила поведения в проекте: внутренняя этика, обращение к коллегам, дресс-код. · Каждый член команды четко знает свои обязанности и полномочия, а также обязанности и полномочия своих ближайших коллег по проекту. · Каждый член проектной команды имеет представление о профессиональном и проектном опыте своих коллег по проекту. · В базовом расписании и базовом плане по стоимости проекта выделены ресурсы на проведение командообразующих мероприятий и налаживание внутренних коммуникаций проекта

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

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

9.2. Анализ достижимости запланированных бизнес-выгод

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

Таблица 8.2. Форма анализа ТЭО
Функциональная область / Процесс / Подпроцесс	Драйвер для ROI-модели	Фактор воздействия в результате реализации проектаи реорганизации бизнес-процессов	Оценка степени воздействия	Срок реализации

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

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

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

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

Рис. 8.1. Пример использования выравнивания ресурсов (превышение доступности ресурсов)

Рис. 8.2. Пример использования выравнивания ресурсов (ресурсы оптимизированы)

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

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

9.4. Оценка доступности и загрузки человеческих ресурсов

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

Таблица 8.3. Пример календарно-ресурсного плана
Команда	Работы	Недели
Фазы	Фаза1	Фаза 2
Руководитель проекта	Задача 1		1.0
Итого дней по РМ	б
Архитектор решения / консультант-эксперт (К5)	Задача 1
Задача2
Итого дней по эксперту
Старший консультант РА, ОМ, РТ, PY(K3)	Задача 1
Итого дней.

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

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

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

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

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

Таблица 8.4. Пример заполнения календарно-ресурсного плана
Команда	Работы	Фазы	Подготовка	Обследование	Проектирование	Реализация	Тестирование	Подготовка к эксплуатации
недели
Руководител ь проекта	Управление проектом	11,0	1,0	1,0	1,0			1,0			1,0			1,0			1,0			1,0	1,0	1,0	1,0
Итого дней по РМ	11,0
Архитектор решения/ консультант-эксперт (К5)	Планирование работ	5,0			5,0
Проведение обследования	30,0				5,0	5,0	5,0	5,0	5,0	5,0
Итого дней по эксперту	35,0
Старший консультант РД ОМ,РТ, PY(K3)	Написание концептуального проекта	35,0			5,0	5,0	5,0	5,0	5,0	5,0	5,0
Согласование концептуального проекта	0,0
Настройка системы	25,0										5,0	5,0	5,0	5,0	5,0
Подготовка тестовых сценариев	5,0															5,0
Подготовка системы для тестирования	5,0																5,0
Тестирование с пользователями	5,0																	5,0
Устранение замечаний по итогам тестирования	0,0
Подготовка материалов обучения	0,0
Обучение пользователей	0,0
	Загрузка исторических данных	5,0																		5,0
Консультирование	6,0																			2,0	2,0	2,0
Итого дней по старшему консультанту	86,0
Консультант PY, РТ (К2)	Написание концептуального проекта	25,0					5,0	5,0	5,0	5,0	5,0
Настройка системы	25,0										5,0	5,0	5,0	5,0	5,0
Подготовка механизмов загрузки исторических данных	5,0															5,0
Подготовка системы для тестирования	5,0																5,0
Тестирование с пользователями	5,0																	5,0
Устранение замечаний по итогам тестирования	0,0
Подготовка материалов обучения	0,0
Обучение пользователей	0,0
Загрузка исторических данных	5,0																		5,0
Консультирование	6,0																			2,0	2,0	2,0
Итого дней по консультанту	76,0
Разработчик (К4)	Реализация отчетности	45,0									5,0	5,0	5,0	5,0	5,0	5,0	5,0	5,0	5,0
Итого дней по разработчику	45,0
ИТОГО	Дней	253,0

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

Таблица 8.5. Шаблон оценки организационной готовности проекта
№	Перспектива	Компоненты	Степень соответствия (%)
1.	Четкое сформулирован ное видение проекта	Наличие четкого и непротиворечивого представления у всех участников проекта о:
бизнес-причинах проекта целях и задачах проекта
получаемых преимуществах и выгодах для всей компании и для каждого участника в отдельности
воздействии на каждодневные рабочие практики
2.	Готовность идти до конца	Отношение руководства компании и проекта, а также его участников к проекту, с точки зрения их готовности:
довести проект до конца
участвовать в проектных работах
в необходимом объеме
непрерывно поддерживать достигнутые
результаты проекта
ориентироваться на запланированный
бизнес-результат
3.	Руководство и управление	Эффективное руководство, направленное на достижение целей проекта, с следующими характеристиками:
заинтересованность в проекте руководства высшего звена компании
заинтересованность в проекте руководства среднего звена компании
четкое разграничение полномочий и обязанностей
наличие действенных процедур разрешения конфликтных ситуаций
4.	Навыки и компетенции	Осознание всеми участниками проекта необходимости приобретения новых навыков для работы с внедряемыми технологиями и бизнес-процессами:
информированность о предстоящих интенсивных тренингах и обучении
информированность и готовность к предстоящим изменениям в процессах и должностных обязанностях
готовность участников проекта к расширению набора технических навыков
готовность участников проекта к расширению набора коммуникационных и презентационных навыков
5.	Коммуникации	Организация эффективной проектной коммуникации для передачи полной информации по корректным каналам, отвечающей следующим требованиям:
обеспечение необходимого уровня качества предоставляемой информации
корректное функционирование каналов и способов коммуникации
наличие механизмов сбора обратной связи
поддержка возможности точно оценить качество реализуемого процесса коммуникаций

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

Качественный анализ рисков. Количественный анализ рисков. Подтверждение содержания проекта.

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