Оценка реализуемости проекта
Переход к стадии оценки
Как известно, стоимость исправления ошибок из-за неточностей, в том числе в планировании проекта, в десятки раз превышает затраты на подготовку детальных, согласованных и выверенных проектных планов. Завершение этапа планирования стадии рекомендуется производить только после того, как будет произведена проверка проекта в соответствии с приведенными в табл. 8.1 пунктами [8].
На этапе "Оценка" стадии "Планирование проекта" ЖЦ ИС необходимо произвести оценку реализуемости проекта с тем, чтобы принять решение о дальнейшем развитии проекта с учетом имеющихся ограничений, выделенных и подтвержденных ресурсов. При этом оценку реализуемости не стоит путать с ТЭО проекта, или бизнес-кейсом. В отличие от бизнес-кейса, оценка реализуемости направлена на идентификацию факторов, которые определяют, будет ли ИТ-проект успешным или он обречен на неудачу; таким образом, оценка реализуемости является основанием для дальнейшего развития проекта. Работы по оценке реализуемости, часто называемой в англоязычной литературе feasibility study, имеют определенную стоимость и требуют дополнительных ресурсов, но инвестирование этих ресурсов может обезопасить компании от траты времени и ресурсов на заведомо невыполнимые проекты.
Оценка реализуемости направлена на анализ всех аспектов ИТ-проекта, которые могут значительно повлиять на его успех или неудачу, по итогам проведенного анализа дается оценка перспективы реализации этого проекта. Ниже мы перейдем к рассмотрению аспектов оценки реализуемости проекта.
Анализ достижимости запланированных бизнес-выгод
Данный анализ призван ответить на вопрос, будут ли и каким образом будут реализованы предполагаемые выгоды, указанные в ТЭО проекта. При этом для их реализации всегда необходимо привлекать высшее и среднее руководство компании в число сторонников проекта, т.к. практика показывает (см. критические факторы успеха), что без участия руководства среднего и высшего звена проект внедрения ИС, как правило, оказывается неуспешным. Для структурирования результатов произведенных изысканий по итогам анализа выгод рекомендуется использовать следующий шаблон (см. табл. 8.2), позволяющий комплексно документировать информацию о каждой из выгод.
Gap-анализ
Функциональные и технические требования должны быть соотнесены с функциональными и техническими характеристиками внедряемой системы. С его помощью может быть продемонстрирована возможность использования конкретного продукта, обеспечивающего требуемую функциональность. В качестве инструмента для реализации обозначенной цели можно также использовать "домик качества", описанный в разделе формирования требований проекта.
Оценка реализуемости проектного расписания
Данная оценка призвана ответить на вопрос, являются ли предложенные временные рамки проекта реальными и достижимыми.
Для оценки реализуемости проектного расписания рекомендуется использовать метод анализа возможных сценариев и выравнивания ресурсов.
увеличить изображение
Рис. 8.1. Пример использования выравнивания ресурсов (превышение доступности ресурсов)
Анализ возможных сценариев - это метод оценки, в основе которого лежит рассмотрение вопросов типа "Что произойдет, если ситуация будет развиваться по сценарию Х?". В этом случае выполняется анализ сети расписания, при котором с помощью модели расписания просчитываются различные сценарии (например, задержка поставки или увеличение длительности отдельных операций) или моделируется воздействие непредвиденных внешних факторов. Таким образом, результаты анализа возможных сценариев могут использоваться для оценки выполнимости расписания при неблагоприятных условиях и для составления резервных планов.
Выравнивание ресурсов - это метод анализа сети расписания, который применяется к модели расписания, проанализированной методом критического пути [20]. Выравнивание ресурсов используется для выявления плановых операций, которые необходимо выполнить, чтобы уложиться в указанные сроки. Выравнивание ресурсов удобно проводить с помощью компьютерных программ составления расписаний, используя гистограммы ресурсов (см. рис. 8.1, 8.2). Гистограмма ресурсов создается на разделенном экране - в верхней части отображается диаграмма Гантта, где изображены операции, использующие ресурсы, представленные в нижней части экрана в виде столбиковой диаграммы. Диаграммы используют одинаковую шкалу времени.
Оценка доступности и загрузки человеческих ресурсов
Необходимо произвести точную оценку ресурсов, а также составить график потребности в них. Результаты анализа должны давать представление о том, способна ли компания обеспечить все необходимые ресурсы, обладающие необходимым уровнем компетенции.
Команда | Работы | Недели | 1 | 2 | 3 | 4 |
---|---|---|---|---|---|---|
Фазы | Фаза1 | Фаза 2 | ||||
Руководитель проекта | Задача 1 | 6 | 5 | 1.0 | ||
Итого дней по РМ | б | |||||
Архитектор решения/консультант-эксперт (К5) | Задача 1 | 5 | 5 | |||
Задача2 | 10 | 5 | 5 | |||
Итого дней по эксперту | 15 | 5 | 5 | 5 | ||
Старший консультант РА, ОМ, РТ, PY(K3) | Задача 1 | 3 | 4 | 5 | 5 | |
Итого дней. | 3 | 4 | 5 | 5 |
Для указания доступности ресурсов документально фиксируется период времени, в течение которого каждый член команды проекта может принимать участие в выполнении проекта. Информация о доступности ресурсов необходима для корректировки расписания проекта с учетом отпусков и обязательств по другим проектам.
На основании четко определенных требований и идентификации каждого члена команды разрабатывается типовой ресурсный план.
Типовой ресурсный план включает в себя перечень работ - задачи, которые должны быть выполнены в ходе проекта, количество и уровни членов команды, распределенные по срокам и датам, а также типовые фазы проекта (см. табл. 8.3). В плане указывается также занятость каждого ресурса в проекте.
В представленном примере календарно-ресурсного плана занятость может быть рассчитана с учетом того, что один и тот же менеджер может участвовать одновременно в нескольких проектах. Процент занятости в типовом проектном плане указывается как фактическое количество дней в неделю, выделенных на данный проект.
Календарно-ресурсный план также отражает информацию о высвобождении сотрудников, что позволяет своевременно исключать выплаты сотрудникам, уже завершившим работу над проектом, и тем самым снизить затраты на проект и обеспечить информацию о наличии свободного ресурса. Пример заполненного календарно-ресурсного плана для проекта внедрения ИС приведен в табл. 8.4.
Команда | Работы | Фазы | Подготовка | Обследование | Проектирование | Реализация | Тестирование | Подготовка к эксплуатации | |||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
недели | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | ||
Руководител ь проекта | Управление проектом | 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 |