Подходы к управлению ИТ-проектами

Современные подходы к управлению ИТ-проектами

Евгений Пикулев, PMP

директор ЗАО «Инверсия-Урал».

eugenpik@rambler.ru

Содержание

1. Введение

2. PMBOK

3. Microsoft Solution Framework

4. Экстремальное управление проектами

5. Выводы

Успешные проекты нечасты в ИТ

Статистика по 30,000 проектам по разработке ПО в американских компаниях.

Источник: The Standish Group International, Extreme Chaos, The Standish Group International, Inc., 2000

Успешные проекты – вовремя и в рамках бюджета был выполнен весь намеченный фронт работ.

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

Проваленные – не были доведены до конца.

2005

2000

1995

1990

28%23% 49%

26%28% 46%

27%40% 33%

16%31% 53%

УспешныеПроблемныеПроваленные

Как управлять ИТ-проектом?

Какие подходыприменять?

Как получитьрезультат?

Подход PMI (PMBoK, Third Edition)

Управление проектом Время

Интеграция

Содержание

Стоимость

Риски

Персонал

Коммуникации

Качество

Поставки

Области знаний PMBoK

Управление содержанием (Scope) 5 Управление сроками (Time) 6 Управление стоимостью (Cost) 3 Управление коммуникациями 4

(Communication) Управление персоналом (Human Resources) 4

Управление качеством (Quality) 3 Управление рисками (Risk) 6 Управление поставками (Procurement) 6 Управление интеграцией (Integration) 7 (!) ----- 44

Кол-во процессов

Процессы по областям знаний

5.2ScopePlanning

5.3ScopeDefinition

6.1ActivityDefinition

7.1ResourcesPlanning

6.2 ActivitySequencing

6.3ActivityDurationEstimating

7.2Cost Estimating

6.4ScheduleDevelopment

7.3CostBudgeting

4.1Project PlanDevelopment

From the Initiating Processes

From the Controlling Processes

Core Processes

Planning Processes

To theExecutingProcesses

8.1QualityPlanning

9.1OrganisationalPlanning

11.2RiskIdentification

11.3 Qualitative RiskAnalysis

11.5Risk ResponsePlanning

9.2StaffAcquisition

10.1Communications Planning

Facilitating Processes

12.1ProcurementPlanning

12.2SolicitationPlanning

11.3 Quantitative RiskAnalysis

11.1 Risk Management Planning

Много процессов, которыми надо управлять

Source: PMI’s Project Management Body of Knowledge (PMBOK®), 2004

קוד

1

2

3

4

5

6

Software Project

Analysis

Design

Build

Test

Implementation

11 12 01 02 03 04 05 06 07 08 09 10 11 12 01 02 03 04 05 06 07 08 09 10 11 12 01 02 03 04 05 06 07 08 09 10 11 12 01 022001 2002 2003 2004 2005

Расписание

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

קוד שם פעילות

1 Software Project

2 Analysis

3 Design

4 Build

5 Test

6 Implementation

Software Project

JohnAnalysis

DavidDesign

LisaBuild

JohnTest

SuzanImplementation

10 11 12 01 02 03 04 05 06 07 08 09 10 11 12 01 02 03 04 05 06 07 08 09 10 11 12 01 02 03 04 05 06 07 08 09 10 11 12 012001 2002 2003 2004 2005

Ресурсы

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

קוד שם פעילות

1 Software Project

2 Analysis

3 Design

4 Build

5 Test

6 Implementation

$ 100,000Software Project

$ 15,000 John

Analysis

$ 10,000 David

Design

$ 40,000 Lisa

Build

$ 20,000 John

Test

$ 15,000 Suzan

Implementation

10 11 12 01 02 03 04 05 06 07 08 09 10 11 12 01 02 03 04 05 06 07 08 09 10 11 12 01 02 03 04 05 06 07 08 09 10 11 12 012001 2002 2003 2004 2005

Стоимость

Risk planningCommunications planningQuality planningProcurement planningProject plan document

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

Плюсы и минусы

Best practise Проработанная

методика Институт по

сертификации. Хорошая

проработанность ряда разделов (риски, earned value)

Большое количество процессов.

«Водопадная» модель.

Нет специфических подходов к процессам ИТ (ITIL-ITSM)

Не подходит к плохо структурированным проектам

Подход Microsoft (Microsoft Solution Framework)

MSF и MOF

MSF = Microsoft Solutions Framework Подход Microsoft к управлению

ИТ-проектами: Проекты разработки ПО Проекты развертывания инфраструктуры

MOF = Microsoft Operations Framework Подход Microsoft к управлению

ИТ-процессами (операциями) на предприятии

MSF и MOF

Microsoft Operations Framework

Microsoft Solutions Framework

ЭксплуатируемВ

нед

ряе

м

СоздаемП

лан

ир

уем

Модель процессов

Планы проекта утверждены

Разработка завершена

Готовность решения утверждена

Внедрение завершено

Концепция проекта утверждена

Выработка

концепцииВнедр

ение

Разработка

Пл

анир

ован

иеС

табилизация

Промежуточные вехи

Планы проекта утверждены

Разработка завершена

Готовность решения утверждена

Внедрение завершено

Концепция проекта утверждена

Пилотное внедрение завершено

Контрольное тестирование завершено

Версии-кандидаты

Тестирование приемлемости для потребителей завершено

Точка достижения нуля

Точка конвергенции

Верификация технологий осуществлена

Базовая версия функциональной спецификации создана

Базовая версия сводного плана проекта создана

Базовая версия сводного календарного графика проекта создана

Среды разработки и тестирования развернуты

Внедренное решение стабилизировано

Внедрение на местах завершено

Ключевые компоненты развернуты

Ядро проектной группы сформировано

Черновой вариант концепции проекта составлен

Концепция подтвержденаПромежуточная версия 1 завершена

Промежуточная версия 2 завершенаПромежуточная версия N завершена

Плюсы и минусы

Гибкая методология Апробирована

Microsoft Модель команды Больше

соответствует циклу разработки ПО

Концентрация на экономической отдаче

В России практически не развита.

Нет руководителя проекта.

Многовато специфики (ежедневные сборки)

Потребуется внедрить модель MOF

Подход Дуга де Карло (Экстремальное управление

проектами)

Определение экстремального проекта

«Экстремальный проект – это комплексное, высокоскоростное, самокорректирующееся предприятие, во время работы над которым люди взаимодействуют в поисках желаемого результата в условиях крайней неопределенности, постоянных изменений и сильного стресса.»

Дуг де Карло

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

спонсоров и заказчиков, которые имеют различные и порой противоречивые интересы в результатах проекта

Недостаток полномочий членов команды для принятия решений.

Стрессовое состояние команды в связи с ненормированным рабочим днем и непредсказуемостью ситуации.

Ментальная модель проекта

Рис.1 Ментальная модель традиционного проекта

Рис.2 Ментальная модель экстремального проекта

Роль руководителя ЭП

Плюсы и минусы

Антикризисный подход

Сильная роль PM. Эффективна в

«созревших» компаниях.

Экстремальное программирование.

Не является методологией.

Большое количество рисков и стрессов.

90% успеха проекта зависит от PM.

Нет акцента на качестве.

Статистика Standish Group

0

5

10

15

20

25

30

35

40

Ove

rall

Rel

ativ

e Im

po

rtan

ce

HR ScopeIntegration Time Cost Comm. Quality RiskProcurement

Knowledge Area

Относительная важность областей знаний Software & Communications

Source: Standish Group

0

5

10

15

20

25

30

35

40

Ove

rall

Rel

ativ

e Im

po

rtan

ce

Time Cost Quality Comm.IntegrationProcu. HR Risk Scope

Knowledge Area

Относительная важность областей знаний Construction & Engineering

Source: Standish Group

В качестве вывода

Хорошие КОМАНДЫ являются НЕОБХОДИМЫМ, но не достаточным условием успешной реализации ИТ-проекта.

Спасибо за внимание !