Управление изменениями в ИТ-проектах

Презентация «Управление изменениями в ИТ-проектах» со 2-й онлайн конференции «Проектное мышление» прошедшей 2 октября 2018 года.
Обсуждаются принципы управления изменениями в проектах, применимость agile в традиционных waterfall корпоративных проектах, проектные риски и практические кейсы!

Transcript

1. Управление изменениями в ИТ-проектах Александр Михайлов Вторая онлайн конференция «Проектное мышление» 2 октября 2018
2. 5 шагов по управлению изменениями 2 1. Идентификация 2. Обсуждение 3. Проработка 4. Согласование 5. Внедрение
3. Ключевые оценки изменений 3 • Соответствие целям проекта • Стоимость изменений • Сроки реализации изменений • Риски отказа от изменений • Риски принятия изменений • Отделимость от текущего функционала
4. Ключевые влияния изменений 4 • Цели проекта • Бюджет проекта • График освоения • Дата начала использования продукта (опытно- промышленной эксплуатации) • Срок завершения проекта • Договорные обязательства • Взаимосвязанные проекты
5. Управление изменениями зависит от среды 5 Традиционный водопадный (waterfall) подход хорошо зарекомендовал себя в сложных средах, например при реализации проектов в крупных организациях. Гибкий (agile) подход может быть успешно использован там, где имеется высокая неопределенность целей, требований или процессов. Например, если Заказчик не может четко сформулировать требования к системе или не готов решить, как должен выглядеть бизнес-процесс с использованием новой информационной системы.
6. Ценность гибких методологий 6 Гибкие (agile) методологии управления проектами позволяют: • успешно, шаг за шагом двигаться к достижению целей проекта в условиях высокой неопределенности требований (среды) и/или • обеспечивать частую доставку новых небольших результатов и улучшений (инкрементальные релизы) Гибкие методологии по определению подразумевают возможность оперативных изменений – строятся на последовательности коротких этапов работ (спринтов), после которых осуществляется уточнение или пересмотр требований и приоритетов.
7. Agile & Waterfall *Михайлов А.С. Корпоративное управление проектами / Управление проектами, №1(44), 2018 https://pmmagazine.ru/articles/korporativnoe-upravlenie-proektami Применимость Agile в традиционных корпоративных Waterfall проектах, с привлечением внешних подрядчиков, в значительной степени зависит от схемы договорных отношений* Успешная работа по Agile возможна, если Исполнитель находится в относительно равноправных отношениях с Заказчиком, например, оплачиваться по T&M
8. Agile & Waterfall • Рассмотрим пример жизненного цикла традиционного (waterfall) корпоративного проекта (синя линия), этап планирования которого завершается за пять месяцев, еще через два месяца, после заключения договора, на проект выходит подрядчик (оранжевая линия) и начинается этап реализации; завершение проекта – это снова только внутрикорпоративный этап. • Успешное применение гибких (agile) методов вполне возможно на этапе реализации. Например, подрядчик может выполнять работу небольшими спринтами, с демонстрацией промежуточных результатов и уточнением требований (зеленые блоки). • Одной из главных особенностей такого смешанного использования подходов будет необходимость митигировать риски неисполнения подрядчиком условий договора, особенно в случае fix price договора, в котором фиксируются срок, стоимость и объем работ. Вариантом может быть определение в договоре небольших этапов, по длине спринтов, или использование рамочного договора, с подписанием дополнительных соглашений под конкретные спринты.
9. Проблемы, связанные c изменением объема Неполнота объема (Scope Gap) – необходимость уточнения требований по ходу реализации проекта Расползание объема (Scope Creep) – добавление новых требований по ходу реализации проекта Нереализуемость объема (Scope Non Deliverability) – техническая сложность или фактическая дороговизна реализации требований 9
10. PERIL Database The Project Experience Risk Information Library (PERIL) and www.failureproofprojects.com by Tom Kendrick Identifying and Managing Project Risk
11. КЕЙС #1: директивные сроки 11 По проекту были установлены директивные сроки, не связанные с объективными внешними ограничениями. На момент утверждения проекта отсутствовал детальный календарный план-графика проекта. Руководитель проекта не сумел аргументировать сроки реализации проекта. Директивные сроки оказались не адекватными, в проект пришлось вносить изменения.
12. КЕЙС #2: задержка поставки 12 В проекте предусматривалась поставка и монтаж оборудования. Практически единственным доступным каналом поставки оборудования являлся водный речной путь. В связи с сезонными ограничениями работы речных портов сроки проекта увеличились на пол года.
13. КЕЙС #3: изменение среды 13 Приостановка проекта по причине задержек взаимосвязанного бизнес-проекта.
14. 10 золотых правил разработки требований* 1. Начинайте с самого непонятного 2. Поймите бизнес-цели, определите задачи проекта 3. Погрузитесь в бизнес-процессы, поймите, как все устроено 4. Прорабатывайте требования, чтобы они были реализуемы 5. Как можно раньше привлекайте техническую экспертизу 6. Разделяйте сложное на части 7. Держите строй – не увлекайтесь одним в ущерб остальному 8. Осторожно – перфекционизм! Умейте вовремя остановиться 9. Продумайте содержание документа требований 10. Пишите понятно, по существу, не гонитесь за объемом *Михайлов А.С. Десять золотых правил разработки требований / Бизнес & Информационные технологии, №8 (61), 2016 http://bit.samag.ru/archive/article/1747
15. Лучшие мировые практики 15 PMI Professional in Business Analysis Handbook PMI Business Analysis for Practitioners Business Analysis Body of Knowledge (BABoK) Systems Engineering Handbook
16. Декомпозиция Декомпозиция (“есть слона по частям”) является одним из основных методов борьбы со сложностью В случае изменений проекты можно разделять по функциональности, организационному или географическому объему, бизнес-процессам, этапам реализации и тп. 16 проект не резиновый – не все изменения правильно реализовывать в рамках существующего проекта
17. КЕЙС #4 Трансформация проекта в программу 17 В объем проекта был включен ряд взаимосвязанных, но фактически разноплановых задач. В связи со сложностью управления было принято решение о трансформации проекта в программу взаимосвязанных проектов.
18. Варианты критериев нового проекта: • изменения отделимы от основного функционала • увеличение стоимости проекта > 25% • увеличение срока > 50% В случае, если хотя бы один из критериев выполняется, то с высокой вероятностью целесообразно трансформировать изменения в отдельный проект ВАЖНО: расчет отклонений стоимости и срока правильно осуществлять относительно самых первоначальных параметров проекта 18
19. Заменить нельзя оставить
20. Риски замены руководителя проекта Смена руководителя проекта в ходе реализации проекта несет большие риски для успешного завершения проекта – реализовывать проект должен тот, кто его планировал! 20
21. Весьма своеобразен термин project … 21 “Весьма своеобразен термин project, обозначающий и тему разработки и саму разработку; мы переводим его как «проект», расширяя обычное русское значение этого слова …” Г.Н. Поваров в Кн.: Холл А.Д. Опыт методологии для системотехники (1975) В 2018 году исполняется 90 лет со дня рождения философа и кибернетика Геллия Николаевича Поваров (1928 – 2004), которому мы обязаны современным пониманием термина «проект».
22. Спасибо! 22 Александр Михайлов Менеджер портфеля ИТ-проектов, «Норникель» PhD, ПМ СТАНДАРТ (СРП-2), PRIME almikh@mail.ru facebook: amikhayloff Вопросы?