Лекция
Привет, сегодня поговорим про оценка реализуемости it- проекта, обещаю рассказать все что знаю. Для того чтобы лучше понимать что такое оценка реализуемости it- проекта , настоятельно рекомендую прочитать все из категории Управление разработкой программных IT проектов.
Как известно, стоимость исправления ошибок из-за неточностей, в том числе в планировании проекта, в десятки раз превышает затраты на подготовку детальных, согласованных и выверенных проектных планов. Завершение этапа планирования стадии рекомендуется производить только после того, как будет произведена проверка проекта в соответствии с приведенными в табл. 10.1 пунктами [8].
Таблица 10.1. Проверочный список для этапа планирования
Аспект |
Показатели |
Участники проекта |
|
Процессы и процедуры проекта |
|
Команда проекта |
|
На этапе "Оценка" стадии "Планирование проекта" ЖЦ ИС необходимо произвести оценку реализуемости проекта с тем, чтобы принять решение о дальнейшем развитии проекта с учетом имеющихся ограничений, выделенных и подтвержденных ресурсов. При этом оценку реализуемости не стоит путать с ТЭО проекта, или бизнес-кейсом. В отличие от бизнес-кейса, оценка реализуемости направлена на идентификацию факторов, которые определяют, будет ли ИТ-проект успешным или он обречен на неудачу; таким образом, оценка реализуемости является основанием для дальнейшего развития проекта. Работы по оценке реализуемости, часто называемой в англоязычной литературе feasibility study, имеют определенную стоимость и требуют дополнительных ресурсов, но инвестирование этих ресурсов может обезопасить компании от траты времени и ресурсов на заведомо невыполнимые проекты.
Оценка реализуемости направлена на анализ всех аспектов ИТ-проекта, которые могут значительно повлиять на его успех или неудачу, по итогам проведенного анализа дается оценка перспективы реализации этого проекта. Ниже мы перейдем к рассмотрению аспектов оценки реализуемости проекта.
Данный анализ призван ответить на вопрос, будут ли и каким образом будут реализованы предполагаемые выгоды, указанные в ТЭО проекта. При этом для их реализации всегда необходимо привлекать высшее и среднее руководство компании в число сторонников проекта, т.к. практика показывает (см. критические факторы успеха), что без участия руководства среднего и высшего звена проект внедрения ИС, как правило, оказывается неуспешным. Для структурирования результатов произведенных изысканий по итогам анализа выгод рекомендуется использовать следующий шаблон (см. табл. 10.2), позволяющий комплексно документировать информацию о каждой из выгод.
Таблица 10.2. Форма анализа ТЭО
Функциональная область/Процесс/ Подпроцесс |
Драйвер для ROI-модели |
Фактор воздействия в результате реализации проектаи реорганизации бизнес-процессов |
Оценка степени воздействия |
Срок реализации |
Gap-анализ
Функциональные и технические требования должны быть соотнесены с функциональными и техническими характеристиками внедряемой системы. С его помощью может быть продемонстрирована возможность использования конкретного продукта, обеспечивающего требуемую функциональность. В качестве инструмента для реализации обозначенной цели можно также использовать "домик качества", описанный в разделе формирования требований проекта.
Данная оценка призвана ответить на вопрос, являются ли предложенные временные рамки проекта реальными и достижимыми.
Для оценки реализуемости проектного расписания рекомендуется использовать метод анализа возможных сценариев и выравнивания ресурсов.
Рис. 10.1. Пример использования выравнивания ресурсов (превышение доступности ресурсов)
Рис. 10.2. Пример использования выравнивания ресурсов (ресурсы оптимизированы)
Анализ возможных сценариев - это метод оценки, в основе которого лежит рассмотрение вопросов типа "Что произойдет, если ситуация будет развиваться по сценарию Х?". В этом случае выполняется анализ сети расписания, при котором с помощью модели расписания просчитываются различные сценарии (например, задержка поставки или увеличение длительности отдельных операций) или моделируется воздействие непредвиденных внешних факторов. Таким образом, результаты анализа возможных сценариев могут использоваться для оценки выполнимости расписания при неблагоприятных условиях и для составления резервных планов.
Выравнивание ресурсов - это метод анализа сети расписания, который применяется к модели расписания, проанализированной методом критического пути [20]. Выравнивание ресурсов используется для выявления плановых операций, которые необходимо выполнить, чтобы уложиться в указанные сроки. Выравнивание ресурсов удобно проводить с помощью компьютерных программ составления расписаний, используя гистограммы ресурсов (см. рис. 10.1,10.2). Гистограмма ресурсов создается на разделенном экране - в верхней части отображаетсядиаграмма Гантта, где изображены операции, использующие ресурсы, представленные в нижней части экрана в виде столбиковой диаграммы. Диаграммы используют одинаковую шкалу времени.
Необходимо произвести точную оценку ресурсов, а также составить график потребности в них. Результаты анализа должны даватьпредставление о том, способна ли компания обеспечить все необходимые ресурсы, обладающие необходимым уровнем компетенции.
Таблица 10.3. Пример календарно-ресурсного плана
Команда |
Работы |
Недели |
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 |
Для указания доступности ресурсов документально фиксируется период времени, в течение которого каждый член команды проекта может принимать участие в выполнении проекта. Информация о доступности ресурсов необходима для корректировки расписания проекта с учетом отпусков и обязательств по другим проектам.
На основании четко определенных требований и идентификации каждого члена команды разрабатывается типовой ресурсный план.
Типовой ресурсный план включает в себя перечень работ - задачи, которые должны быть выполнены в ходе проекта, количество и уровни членов команды, распределенные по срокам и датам, а также типовые фазы проекта (см. табл. 10.3). В плане указывается также занятость каждого ресурса в проекте.
В представленном примере календарно-ресурсного плана занятость может быть рассчитана с учетом того, что один и тот же менеджер может участвовать одновременно в нескольких проектах. Процент занятости в типовом проектном плане указывается как фактическое количество дней в неделю, выделенных на данный проект.
Календарно-ресурсный план также отражает информацию о высвобождении сотрудников, что позволяет своевременно исключать выплаты сотрудникам, уже завершившим работу над проектом, и тем самым снизить затраты на проект и обеспечить информацию о наличии свободного ресурса. Об этом говорит сайт https://intellect.icu . Пример заполненного календарно-ресурсного плана для проекта внедрения ИС приведен в табл. 10.4.
Таблица 10.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 |
Данный тип оценки должен учитывать финансовую историю компании и опыт реализации аналогичных проектов. Кроме того, крайне важными факторами являются культура организации и уровень ее зрелости. В качестве инструмента оценки организационной зрелости возможно использовать следующий диагностический подход [5], рассматривающий организационную готовность в разрезе 5 перспектив (см. табл. 10.5).
Таблица 10.5. Шаблон оценки организационной готовности проекта
№ |
Перспектива |
Компоненты |
Степень соответствия (%) |
1. |
Четкое сформулирован ное видение проекта |
Наличие четкого и непротиворечивого представления у всех участников проекта о: |
|
бизнес-причинах проекта целях и задачах проекта |
|||
получаемых преимуществах и выгодах для всей компании и для каждого участника в отдельности |
|||
воздействии на каждодневные рабочие практики |
|||
2. |
Готовность идти до конца |
Отношение руководства компании и проекта, а также его участников к проекту, с точки зрения их готовности: |
|
довести проект до конца |
|||
участвовать в проектных работах |
|||
в необходимом объеме |
|||
непрерывно поддерживать достигнутые |
|||
результаты проекта |
|||
ориентироваться на запланированный |
|||
бизнес-результат |
|||
3. |
Руководство и управление |
Эффективное руководство, направленное на достижение целей проекта, с следующими характеристиками: |
|
заинтересованность в проекте руководства высшего звена компании |
|||
заинтересованность в проекте руководства среднего звена компании |
|||
четкое разграничение полномочий и обязанностей |
|||
наличие действенных процедур разрешения конфликтных ситуаций |
|||
4. |
Навыки и компетенции |
Осознание всеми участниками проекта необходимости приобретения новых навыков для работы с внедряемыми технологиями и бизнес-процессами: |
|
информированность о предстоящих интенсивных тренингах и обучении |
|||
информированность и готовность к предстоящим изменениям в процессах и должностных обязанностях |
|||
готовность участников проекта к расширению набора технических навыков |
|||
готовность участников проекта к расширению набора коммуникационных и презентационных навыков |
|||
5. |
Коммуникации |
Организация эффективной проектной коммуникации для передачи полной информации по корректным каналам, отвечающей следующим требованиям: |
|
обеспечение необходимого уровня качества предоставляемой информации |
|||
корректное функционирование каналов и способов коммуникации |
|||
наличие механизмов сбора обратной связи |
|||
поддержка возможности точно оценить качество реализуемого процесса коммуникаций |
В заключение рассмотрения данного раздела необходимо обратить внимание, что результатом процесса оценки реализуемости редко становится однозначное утверждение или однозначный отказ от реализации проекта. Руководство компании должно комплексно рассмотреть полученные результаты и только на этом основании принимать окончательное решение [8].
В общем, мой друг ты одолел чтение этой статьи об оценка реализуемости it- проекта. Работы впереди у тебя будет много. Смело пиши комментарии, развивайся и счастье окажется в твоих руках. Надеюсь, что теперь ты понял что такое оценка реализуемости it- проекта и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Управление разработкой программных IT проектов
Комментарии
Оставить комментарий
Управление разработкой программных IT проектов
Термины: Управление разработкой программных IT проектов