Презентация на тему: Управление IT проектом

Управление IT проектом
Литература
П олезные ссылки
Термины и определения
Управление IT проектом
Понятие «Проект» и «Управление проектами»
Группы процессов УП
Группа процессов инициирования
Группа процессов планирования
Группа процессов исполнения
Группа процессов мониторинга и управления
Группа завершающих процессов
Инициация Initiation
Инициаторы проектов:
Инициация Схема процесса
Инициация Описание продукта
Инициация Методы выбора проекта
Инициация Устав и менеджер проекта
Инициация Ограничения проекта
Инициация Допущения проекта
Процессы планирования Зачем планировать?
Процессы планирования План проекта
Процессы планирования Последовательность планирования проекта
Планирование содержания Scope Planning
Планирование содержания Схема процесса
Планирование содержания Основные элементы процесса
Планирование содержания «Содержание проекта»
Определение содержания Scope Definition
Определение содержания Схема процесса
Определение содержания Основные элементы процесса
Определение содержания Декомпозиция - метод
Определение содержания Иерархическая структура работ ( WBS)
Определение операций Activity Definition
Определение операций Схема процесса
Определение операций Основные элементы процесса
Последовательность операций Activity Sequencing
Последовательность операций Схема процесса
Последовательность операций Основные элементы процесса
Последовательность операций Жесткие зависимости
Последовательность операций Мягкие зависимости
Последовательность операций Внешние зависимости
Последовательность операций Определения зависимости
Последовательность операций Используемые связи операций
Последовательность операций Диаграммы предшествования
Последовательность операций Диаграммы предшествования
Последовательность операций Стрелочные диаграммы
Последовательность операций Стрелочные диаграммы
Последовательность операций Условные диаграммы
Последовательность операций Сетевая диаграмма проекта
Планирование ресурсов Resource Planning
Планирование ресурсов Схема процесса
Планирование ресурсов Потребность в ресурсах
Оценка длительности операции Activity Duration Estimation
Оценка длительности операции Схема процесса
Разработка расписания Schedule Development
Разработка расписания проекта Схема процесса
Разработка расписания Математические методы
Разработка расписания Метод критического пути
Разработка расписания Метод критического пути
Разработка расписания Методы сжатия длительности проекта
Оценка стоимости Cost Estimation
Оценка стоимости Схема процесса
Оценка стоимости Стоимость ресурсов
Оценка стоимости Аналоговая оценка
Оценка стоимости Оценка снизу-вверх
Оценка стоимости Компьютерные методы
Разработка бюджета Cost Budgeting
Разработка бюджета Схема процесса
Организационное планирование Organizational Planning
Организационное планирование Схема процесса
Организационное планирование Взаимосвязи проекта
Организационное планирование Роли и ответственности
Организационное планирование План управления персоналом
Организационное планирование Организационная диаграмма
Подбор персонала Staff Acquisition
Подбор персонала Схема процесса
Планирование взаимодействия Communications Planning
Планирование взаимодействия Схема процесса
Планирование взаимодействия Коммуникационные требования и технологии
Разработка плана проекта Project Plan Development
Исполнение
Контроль
Процессы исполнения и контроля Блок-схема процессов
Завершение
IT -проекты
Примеры ролей в IT-проекте
Фазы проектов разработки и развития программного обеспечения
Отличительные особенности IT- проектов :
Управление IT проектом
Управление IT проектом
Управление IT проектом
Управление IT проектом
1/92
Средняя оценка: 4.8/5 (всего оценок: 41)
Код скопирован в буфер обмена
Скачать (690 Кб)
1

Первый слайд презентации: Управление IT проектом

Салмин Павел Сергеевич salmin@bk.ru 1

Изображение слайда
2

Слайд 2: Литература

Соммервилл, Иан. Инженерия программного обеспечения, 6-е издание.: Пер. с англ. – М.: Издательский дом "Вильямс", 2002. – 624 с. Балашов, А. И. Управление проектами: учебник для бакалавров / А. И. Балашов, Е.М. Рогова, М. В. Тихонова, Е. А. Ткаченко; под ред. Е. М. Роговой. – М. : Издательство Юрайт, 2013. – 383 с. 2

Изображение слайда
3

Слайд 3: П олезные ссылки

http://microsoftproject.ru/ ( все об MS Project) https://www.expert-systems.com/ ( разработчик ПО « Project Expert ») http://www.symphonyteleca.com/ (разработчик ПО) http://www.pmi.org / / ( управление проектами по стандарту PMB o K® (PMI). подготовка к сертификации ) 3

Изображение слайда
4

Слайд 4: Термины и определения

Свод знаний по  управлению проектами  ( англ.   Project Management Body of Knowledge, PMBoK ) представляет собой сумму профессиональных знаний по управлению проектами.  PMI  использует этот документ в качестве основного справочного материала для своих программ по профессиональному развитию. Является Американским национальным стандартом. В стандарте PMBoK описываются суть процессов управления проектами в терминах интеграции между процессами и взаимодействий между ними, а также цели, которым они служат. Эти процессы разделены на пять групп, называемых «группы процессов управления проектом ». 4

Изображение слайда
5

Слайд 5

Институт управления проектами  ( Project Management Institute, PMI) — всемирная некоммерческая профессиональная организация по управлению проектами. PMI осуществляет разработку стандартов, проведение исследований, образовательную деятельность, публикацию статей, журналов и книг, расширение возможностей сотрудничества в региональных отделениях, проведение конференций и обучающих семинаров, а также аккредитацию в области управления проектами. PMI привлекает волонтеров для создания отраслевых стандартов, таких как  Руководство к Своду знаний по управлению проектами (Руководство PMBOK®). Руководство PMBOK® было признано Американским Национальным Институтом Стандартов (ANSI). В 2012 году процессы управления проектами, описанные в Руководстве PMBOK® 4-го издания, были адаптированы  Международной организацией по стандартизации (ISO ). 5

Изображение слайда
6

Слайд 6: Понятие «Проект» и «Управление проектами»

Наиболее популярное определение, данное американским Институтом проектного управления и содержащееся в руководстве по основам проектного управления ( PMBOK Guide ), трактует проект следующим образом: Проект — это временное предприятие, предназначенное для создания уникальных продуктов, услуг или результатов. 6

Изображение слайда
7

Слайд 7: Группы процессов УП

Инициация – принятие решения о старте проекта или фазы; Планирование – определение или переопределение целей и путей их достижения; Исполнение – координация исполнителей и ресурсов для выполнения плана; Контроль – обеспечение достижения целей проекта путем регулярного мониторинга состояния исполнения и определения необходимых корректирующих действий; Завершение – формализация и корректное завершение исполнения проекта или фазы. 7

Изображение слайда
8

Слайд 8: Группа процессов инициирования

Разработка устава проекта Определение заинтересованных сторон проекта 8

Изображение слайда
9

Слайд 9: Группа процессов планирования

Разработка плана управления проектом Планирование содержания Определение содержания Создание иерархической структуры работ (ИСР) Определение состава операций Определение взаимосвязей операций Оценка ресурсов Оценка длительности операций Разработка расписания Стоимостная оценка Разработка бюджета расходов Планирование качества Планирование человеческих ресурсов Планирование коммуникаций Планирование управления рисками Идентификация рисков Качественный анализ рисков Количественный анализ рисков Планирование реагирования на риски Планирование покупок Планирование контрактов 9

Изображение слайда
10

Слайд 10: Группа процессов исполнения

Руководство и управление исполнением проекта Процесс обеспечения качества Набор команды проекта Развитие команды проекта Распространение информации Запрос информации у продавцов Выбор продавцов 10

Изображение слайда
11

Слайд 11: Группа процессов мониторинга и управления

Мониторинг и управление работами проекта Общее управление изменениями Подтверждение содержания Управление содержанием Управление расписанием Управление стоимостью Процесс контроля качества Управление командой проекта Отчетность по исполнению Управление участниками проекта Наблюдение и управление рисками Администрирование контрактов 11

Изображение слайда
12

Слайд 12: Группа завершающих процессов

Закрытие проекта Закрытие контрактов 12

Изображение слайда
13

Слайд 13: Инициация Initiation

Инициация - это процесс формального признания необходимости выполнения проекта, для исполняющегося проекта - необходимости перехода к следующей фазе проекта Часто при инициации необходим предварительный анализ в форме анализа осуществимости, ТЭО, бизнес- плана,... 13

Изображение слайда
14

Слайд 14: Инициаторы проектов:

• Требования рынка • Деловая необходимость • Потребности заказчика • Технологический прорыв • Законодательные требования • Социальная необходимость 14

Изображение слайда
15

Слайд 15: Инициация Схема процесса

15

Изображение слайда
16

Слайд 16: Инициация Описание продукта

Описание продукта – внешний документ, автор - заказчик Состав документа: характеристики продукта или услуги Связь продукта с бизнес-потребностью Описание продукта должно быть достаточным для планирования Описание продукта детализируется в процессе последовательного уточнения 16

Изображение слайда
17

Слайд 17: Инициация Методы выбора проекта

Выбор проекта производится из портфеля проектов ( project portfolio ), т.е. набора проектов, потенциально интересных для исполняющей организации Для эффективности выбора проекты портфеля должны быть оценены и проранжированы Для выбора используются разнообразные методы и критерии выбора, зависящие от предметной области Часто используются методы взвешивания 17

Изображение слайда
18

Слайд 18: Инициация Устав и менеджер проекта

Устав проекта ( Project Charter ) – формально авторизует проект среди участников Внешний к проекту документ, авторы – участники, часто - исполняющая организация и заказчик Состав документа: • Бизнес-потребность проекта и продукта • Описание продукта Для внешних проектов уставом часто является контракт Назначение менеджера проекта ( Project Manager ) – лица, полностью и единолично ответственного за все в проекте 18

Изображение слайда
19

Слайд 19: Инициация Ограничения проекта

Ограничения ( Constraints) – факторы, которые будут лимитировать возможности команды проекта, например: • По срокам, стоимостям, ресурсам • По характеристикам продукта • По процедурам управления проектом • По особенностям участников и внешнего окружения 19

Изображение слайда
20

Слайд 20: Инициация Допущения проекта

Допущения ( Assumptions ) – факторы, о которых при планировании предполагаются, что они будут достоверными, например : • О наличии или отсутствии неспецифицированных ограничений по срокам, стоимостям и ресурсам • О характеристиках продукта • О системе управления проектом • О взаимодействии проекта с участниками • О внешнем окружении (законы, экономика, природа) Допущения – один из основных источников рисков 20

Изображение слайда
21

Слайд 21: Процессы планирования Зачем планировать?

Проект без плана или с нереалистичным планом – это либо мечта, либо авантюра; Плохо спланированный проект скорее всего не будет исполнен в срок и бюджет; Реалистичное определение работ, сроков, бюджетов и исполнителей приводит инновацию к обычной деятельности; Чем более инновационен проект, тем больше необходимость планирования. 21

Изображение слайда
22

Слайд 22: Процессы планирования План проекта

План проекта – это свод законов, определяющие исполнение всего проекта Основа Плана проекта – календарный план работ Вторая составляющая Плана проекта – правила игры (процедуры) Согласованный и утвержденный План проекта создает базис взаимодействия всех участников проекта 22

Изображение слайда
23

Слайд 23: Процессы планирования Последовательность планирования проекта

Описание продукта Устав проекта Создание WBS Содержание проекта Иерархическая структура работ ( WBS) Создание расписания Сетевая диаграмма Пул ресурсов Расписание проекта Создание Плана проекта Бюджет проекта Планы управления сроками, стоимостью... WBS ( Work Breakdown Structure) - Иерархическая структура работ 23

Изображение слайда
24

Слайд 24: Планирование содержания Scope Planning

Планирование содержания проекта – процесс последовательного уточнения и документирования работ проекта (содержания проекта), которые приведут к созданию продукта проекта Scope – предметная область, цели и способы их достижения, объем работ, структура работ Для сложных проектов процесс может повторяться на более низких уровнях иерархии 24

Изображение слайда
25

Слайд 25: Планирование содержания Схема процесса

25

Изображение слайда
26

Слайд 26: Планирование содержания Основные элементы процесса

Вход • Описание продукта ( Product Description) • Устав проекта ( Project Charter) Методы • Анализ технический, финансовый,... Результаты • Содержание проекта ( Scope Statement) • План управления содержанием ( Scope Management Plan) 26

Изображение слайда
27

Слайд 27: Планирование содержания «Содержание проекта»

Назначение • Основа всех дальнейших решений • Единое понимание целей проекта Состав документа • Бизнес-обоснование проекта • Продукт проекта (из «Описания продукта») • Основные результаты проекта • Измеримые критерии достижения результатов (минимум: стоимость, сроки, качество) 27

Изображение слайда
28

Слайд 28: Определение содержания Scope Definition

Дальнейшее деление основных результатов проекта на меньшие, более управляемые компоненты с целью: • Повысить точность стоимостных, временных и ресурсных оценок • Определить основу для измерения и управления исполнением • Обеспечить четкое распределение ответственности 28

Изображение слайда
29

Слайд 29: Определение содержания Схема процесса

29

Изображение слайда
30

Слайд 30: Определение содержания Основные элементы процесса

Входы • Содержание проекта Методы • Шаблоны Иерархических Структур Работ (WBS) • Декомпозиция Результаты • Иерархическая Структура Работ ( WBS) 30

Изображение слайда
31

Слайд 31: Определение содержания Декомпозиция - метод

Декомпозиция – последовательное деление основных результатов проекта на меньшие компоненты до уровня детализации, достаточного для обеспечения управления проектом (планирования, исполнения, контроля и завершения) Корректность декомпозиции • Каждый элемент полностью определен • Нижнеуровневые операции и необходимы, и достаточны для соответствующего элемента • Каждый элемент нижнего уровня может быть оценен по стоимости, срокам и приписан к организационной единице (подразделение, исполнитель), которая способна его исполнить 31

Изображение слайда
32

Слайд 32: Определение содержания Иерархическая структура работ ( WBS)

Иерархическая структура работ (WBS – Work Breakdown Structure) – ориентированная на результаты структура проектных компонентов, которая организует и определяет все содержание проекта Пакеты работ - элементы нижнего уровня WBS, длительность пакета работ – до 40-80 час Работы, не включенные в WBS, не являются работами проекта WBS используется для формирования единого понимания целей проекта Каждый элемент WBS описывается в WBS Dictionary 32

Изображение слайда
33

Слайд 33: Определение операций Activity Definition

Определение операций - идентификация и документирование операций, которые необходимо исполнить для получения результатов, определенных в Иерархической Структуре Работ ( WBS) Операции – работы проекта максимального уровня детализации Операции часто называются работами, задачами, заданиями, … 33

Изображение слайда
34

Слайд 34: Определение операций Схема процесса

34

Изображение слайда
35

Слайд 35: Определение операций Основные элементы процесса

Вход • Иерархическая Структура Работ ( WBS) Методы • Декомпозиция (здесь - операции, в WBS – работы или результаты) • Шаблоны перечней операций и пакетов работ Результаты • Перечень операций с описанием 35

Изображение слайда
36

Слайд 36: Последовательность операций Activity Sequencing

Последовательность операций - идентификация и документирование логических взаимосвязей между операциями Необходима аккуратность для получения реалистичного расписания Часто используется компьютерные программы составления расписания Для небольших или начальной фазы больших проектов полезно провести процесс вручную – для лучшего понимания логики проекта 36

Изображение слайда
37

Слайд 37: Последовательность операций Схема процесса

37

Изображение слайда
38

Слайд 38: Последовательность операций Основные элементы процесса

Входы • Перечень операций • Зависимости • Контрольные события ( milestones) – операции с нулевым объемом работ Методы • Диаграммные методы Результаты • Сетевая диаграмма проекта 38

Изображение слайда
39

Слайд 39: Последовательность операций Жесткие зависимости

Жесткие зависимости ( mandatory dependences, hard logic) – зависимости, которые внутренне (физически) присущи выполняемым работам: • Стены после фундамента в строительстве • Тестирование после прототипа в электронике 39

Изображение слайда
40

Слайд 40: Последовательность операций Мягкие зависимости

Мягкие зависимости ( discretionary dependencies, preferred preferential, soft logic ) – те, которые определяются командой проекта: • Общепринятая практика в данной области • Предпочтения команды проекта, хотя могут быть другие варианты действий Использовать осторожно и максимально документировать, так как это ограничивает возможные расписания 40

Изображение слайда
41

Слайд 41: Последовательность операций Внешние зависимости

Внешние зависимости ( external dependencies) включают взаимосвязи проектных и непроектных работ ( исполняемых лицами, не входящих в команду проекта): • Тестирование ПО возможно только после поставки извне • Получение лицензии перед началом некоторой деятельности 41

Изображение слайда
42

Слайд 42: Последовательность операций Определения зависимости

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

Изображение слайда
43

Слайд 43: Последовательность операций Используемые связи операций

43

Изображение слайда
44

Слайд 44: Последовательность операций Диаграммы предшествования

Метод диаграмм предшествования (PDM - Precedence Diagramming Method, AON – activity-on-node) Сетевая диаграмма проекта представляется в виде прямоугольников для операций, соединяемых стрелками, которые отображают зависимости Наиболее часто используемый способ представления сетевых диаграмм в программном обеспечении Может быть построена вручную 44

Изображение слайда
45

Слайд 45: Последовательность операций Диаграммы предшествования

Работы в узлах, связи - стрелки 45

Изображение слайда
46

Слайд 46: Последовательность операций Стрелочные диаграммы

Метод стрелочных диаграмм (ADM - Arrow Diagramming Method, AOA – activity- onarrow ) Сетевая диаграмма проекта представляется в виде стрелок для операций, соединяемых узлами для отображения зависимостей Зависимости только финиш-старт Необходимы пустые ( dummy ) операции 46

Изображение слайда
47

Слайд 47: Последовательность операций Стрелочные диаграммы

Работы - на стрелках, в узлах - связи или события 47

Изображение слайда
48

Слайд 48: Последовательность операций Условные диаграммы

Метод условных диаграмм (Conditional Diagramming Method Допускают циклы и условные переходы Техника графической оценки и обзора Graphical Evaluation and Review Technique (GERT ) 48

Изображение слайда
49

Слайд 49: Последовательность операций Сетевая диаграмма проекта

Сетевая диаграмма проекта – схематическое представление работ проекта и их взаимосвязей в любом из описанных выше видов Исторически называются диаграммами PERT (Program Evaluation and Review Technique ) Программа оценки и метод анализа 49

Изображение слайда
50

Слайд 50: Планирование ресурсов Resource Planning

Планирование ресурсов – определение того, какие ресурсы (люди, оборудование, материалы) и в каком количестве будут использованы на работах проекта Ресурсы делятся на возобновляемые (люди, оборудование) и невозобновляемые (материалы) Ресурсы расходуются и производятся на работах проекта 50

Изображение слайда
51

Слайд 51: Планирование ресурсов Схема процесса

51

Изображение слайда
52

Слайд 52: Планирование ресурсов Потребность в ресурсах

Выход процесса – типы и количество ресурсов, необходимых для выполнения всех операций проекта Для вышестоящих элементов WBS необходимые ресурсы могут определяются суммированием Ресурсы приобретаются либо путем подбора персонала, либо контрактом 52

Изображение слайда
53

Слайд 53: Оценка длительности операции Activity Duration Estimation

Определение длительности операции исходя из информации о работе и назначенных на нее ресурсах Разные типы операций ( D = W / U): • Фиксированная длительность ( fixed Duration) • Фиксированные ресурсы ( fixed Units) • Фиксированный объем работ ( fixed Work ) Календарная длительность операции может зависеть от выходных дней (календарь операции) 53

Изображение слайда
54

Слайд 54: Оценка длительности операции Схема процесса

54

Изображение слайда
55

Слайд 55: Разработка расписания Schedule Development

Разработка расписания проекта означает определение дат начала и завершения всех работ проекта Утвержденное расписание служит базовым планом по расписанию Разработка расписания – существенно итеративный процесс и производится на протяжении всего жизненного цикла проекта 55

Изображение слайда
56

Слайд 56: Разработка расписания проекта Схема процесса

56

Изображение слайда
57

Слайд 57: Разработка расписания Математические методы

Метод критического пути (CPM – Critical Path Method) – использует наиболее вероятную оценку длительности работ PERT – Program Evaluation and Review Technique – использует ожидаемую оценку длительности работ Графические методы (GERT – Graphic Evaluation and Review Technique) – допускает вероятностную трактовку как сетевой логики проекта, так и длительностей работ 57

Изображение слайда
58

Слайд 58: Разработка расписания Метод критического пути

Критический путь – серии операций, которые определяют длительность проекта Критический путь определяется вычислением для каждой из операций ранних дат ( Early Start, Finish ) в прямом проходе и поздних дат ( Late Start, Finish ) в обратном Учитываются опережения и задержки Резерв ( Float, Total Float, Slack) – время, на которое операция может быть задержана, без увеличения длительности проекта: Резерв = Поздний старт - Ранний старт 58

Изображение слайда
59

Слайд 59: Разработка расписания Метод критического пути

Свободный резерв ( Free Float ) – время, на которое операция может быть задержана от раннего начала, не влияя на раннее начало любой последующей работы Те работы, у которых нет резервов, находятся на критическом пути Критический путь может изменяться, их может быть несколько Команда проекта должна обращать особое внимание на работы критического пути 59

Изображение слайда
60

Слайд 60: Разработка расписания Методы сжатия длительности проекта

Сжатие ( Crashing) – назначение дополнительных ресурсов на операцию, обычно приводит к увеличению стоимости Быстрый проход ( Fast tracking ) – исполнение последовательных работ параллельно, обычно приводит к возрастанию рисков Сжатие длительности следует применять сначала к работам критического пути Необходимо выявлять изменения критического пути, вызванные сжатием 60

Изображение слайда
61

Слайд 61: Оценка стоимости Cost Estimation

Разработка аппроксимации (оценки) стоимости ресурсов, необходимых для завершения операций проекта Если проект исполняется по контракту, следует различать оценку стоимости и определение контрактной цены. Цена является бизнес-решением, а оценка стоимости является одним из факторов при определении цены контракта 61

Изображение слайда
62

Слайд 62: Оценка стоимости Схема процесса

62

Изображение слайда
63

Слайд 63: Оценка стоимости Стоимость ресурсов

Для возобновляемых ресурсов задается стоимость единицы времени их работы Для материалов задается стоимость единицы Ресурс может иметь разную стоимость на разных операциях Возобновляемые ресурсы в процессе своей работы могут расходовать материалы 63

Изображение слайда
64

Слайд 64: Оценка стоимости Аналоговая оценка

Аналоговая оценка (сверху – вниз) – использование фактической стоимости ресурсов в предыдущем аналогичном проекте Часто используется на ранних стадиях исполнения проекта Обычно дешевле других методов, однако менее точна 64

Изображение слайда
65

Слайд 65: Оценка стоимости Оценка снизу-вверх

Оцениваются стоимости отдельных операций или пакетов работ, которые суммируются вверх по WBS проекта до получения оценки стоимости всего проекта Уменьшение размеров операций приводит к возрастанию точности оценки, однако при этом возрастает ее трудоемкость. Команда проекта должна находить компромисс 65

Изображение слайда
66

Слайд 66: Оценка стоимости Компьютерные методы

Использование программ управления проектами существенно облегчает оценку стоимости и позволяет легко рассчитывать альтернативные варианты Обычно в программах реализован уже рассмотренный метод «снизу-вверх» 66

Изображение слайда
67

Слайд 67: Разработка бюджета Cost Budgeting

Аллокация всех оценок стоимости на операции или пакеты работ с тем, чтобы установить основу для измерения состояния исполнения проекта Часто разработка бюджета производится после его утверждения, тем не менее рекомендуется, по возможности, разрабатывать бюджет как можно раньше 67

Изображение слайда
68

Слайд 68: Разработка бюджета Схема процесса

68

Изображение слайда
69

Слайд 69: Организационное планирование Organizational Planning

Организационное планирование включает идентификацию, документирование и назначение проектных ролей, ответственностей и отношений отчетности Назначения производятся индивидуумам или группам (подрядчики, подразделения) Производится на ранних стадиях планирования, но должно пересматриваться на регулярной основе Тесно связано с планированием взаимодействия, так как организационная структура проекта – основной фактор, определяющий взаимодействия 69

Изображение слайда
70

Слайд 70: Организационное планирование Схема процесса

70

Изображение слайда
71

Слайд 71: Организационное планирование Взаимосвязи проекта

Взаимосвязи проекта – формальные и неформальные отношения отчетности следующих видов: • Организационные • Технические • Межличностные Часто эти разновидности взаимосвязей проявляются совместно 71

Изображение слайда
72

Слайд 72: Организационное планирование Роли и ответственности

Назначение ролей (что делает?) и ответственностей (что решает?) должно быть увязано с работами и результатами проекта ( WBS) Увязка может производится для разных уровней иерархии путем декомпозиции Основные виды ответственностей: • Первичная ( primary) – ответственность исполнителя за результаты порученного задания • Окончательная ( ultimate) – ответственность руководителя за управляемую систему (включая все процессы и результаты) 72

Изображение слайда
73

Слайд 73: Организационное планирование План управления персоналом

План управления персоналом ( Staffing Management Plan ) определяет, когда и как (процедуры) персонал включается в и исключается из команды проекта Часто включает гистограммы занятости (resource histograms) Особое внимание надо уделять влиянию временности назначений на мотивацию и стоимость (эффект «придумать себе работу») Существенный элемент Плана проекта 73

Изображение слайда
74

Слайд 74: Организационное планирование Организационная диаграмма

Организационная диаграмма проекта (organizational chart) – любое графическое представление отношений отчетности в проекте Организационная иерархическая структура ( Organizational Breakdown Structure, OBS) – особый вид диаграмм, показывает, какая организационная единица отвечает за какой пакет работ 74

Изображение слайда
75

Слайд 75: Подбор персонала Staff Acquisition

Подбор персонала – получение необходимых людских ресурсов (индивидуумы или группы) для работы в Проекте Ресурсы могут быть доступны внутри организации ( переговоры), либо извне ( контракты) Критический фактор – качество ресурсов 75

Изображение слайда
76

Слайд 76: Подбор персонала Схема процесса

76

Изображение слайда
77

Слайд 77: Планирование взаимодействия Communications Planning

Планирование взаимодействия - определение информационных и коммуникационных потребностей участников проекта: • Кому, Когда и Какая информация нужна • Как и Кем эта информация будет предоставляться Организационная структура проекта – главная определяющая взаимодействия Производится на ранних стадиях планирования, но должно пересматриваться на регулярной основе 77

Изображение слайда
78

Слайд 78: Планирование взаимодействия Схема процесса

78

Изображение слайда
79

Слайд 79: Планирование взаимодействия Коммуникационные требования и технологии

Коммуникационные требования – сумма информационных потребностей участников Учитываются не любые потребности, а только «необходимые и достаточные» для успеха проекта Коммуникационные технологии также выбираются из рациональных соображений (частота и срочность, наличие оборудования, квалификация пользователей, …), а не из желания обеспечить участников самыми передовыми средствами взаимодействия 79

Изображение слайда
80

Слайд 80: Разработка плана проекта Project Plan Development

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

Изображение слайда
81

Слайд 81: Исполнение

– координация исполнителей и ресурсов для выполнения плана; 81

Изображение слайда
82

Слайд 82: Контроль

– обеспечение достижения целей проекта путем регулярного мониторинга состояния исполнения и определения необходимых корректирующих действий; 82

Изображение слайда
83

Слайд 83: Процессы исполнения и контроля Блок-схема процессов

83

Изображение слайда
84

Слайд 84: Завершение

– формализация и корректное завершение исполнения проекта или фазы. 84

Изображение слайда
85

Слайд 85: IT -проекты

К IT-проектам относятся - проекты разработки и развития программного обеспечения; - проекты внедрения информационных (автоматизированных) систем, - инфраструктурные и организационные проекты. 85

Изображение слайда
86

Слайд 86: Примеры ролей в IT-проекте

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

Изображение слайда
87

Слайд 87: Фазы проектов разработки и развития программного обеспечения

Создание спецификации ПО – что система должна делать и ограничения на разработку Разработка ПО – производство программной системы Тестирование ПО (включает в себя validation и verification ) – проверка того, что клиент хочет именно того, что прописано в спецификации, и что система соответствует спецификации Развитие или эволюция ПО – изменение ПО в ответ на изменение внешних требований. Подготовка к эксплуатации. Поддержка эксплуатации 87

Изображение слайда
88

Слайд 88: Отличительные особенности IT- проектов :

1. Их эффективность не всегда возможно выразить в деньгах. Информационная система сама по себе не повышает прибыльности предприятия, она может лишь повысить эффективность и ускорить процесс обработки данных. Увеличивает же прибыльность способность менеджмента принимать эффективные решения на основе этой информации. Если же не удается выделить параметры, по которым можно оценить эффективность IТ-проекта, то такой проект является организационным, так как и его идея, и реализация предусматривают изменение бизнес–процессов и системы управления предприятием. Связано это с тем, что некоторые проблемы, которые пытаются решить с помощью автоматизации, связаны с организацией работы на предприятии, и решить их можно только путем организационных и административных мероприятий. 88

Изображение слайда
89

Слайд 89

2. IТ–проекты являются высокорисковыми. Риски срыва сроков, превышения плановой трудоемкости и не достижения запланированных результатов по этим проектам особенно высоки. Для IT-проектов характерна высокая интенсивность в сочетании с глубокой детализацией календарно-сетевых графиков и итерационностью выполнения работ. Обычно требуется детализация трудовых ресурсов до конкретного исполнителя. Нетрудовые ресурсы и материалы отслеживаются значительно реже. 89

Изображение слайда
90

Слайд 90

3. Любой просчет или ошибка, как правило, очень быстро становятся известны широкому кругу людей. Если, например, осуществляется замена сервера или настройка какой-либо информационной системы и происходит сбой, то все пользователи тут же узнают об этом. Для сравнения в маркетинговом проекте просчеты далеко не так очевидны. Можно в его рамках сделать все правильно, но, допустим, не в полном объеме учесть интересы целевой аудитории. Напрямую обвинить в этом упущении руководителя проекта довольно сложно, т.к. существует большое количество внешних факторов. В IT-проекте кроме многочисленных внешних факторов более очевидна ответственность за результат. 90

Изображение слайда
91

Слайд 91

4. Многие IT-проекты имеют колоссальные бюджеты. В крупных компаниях масштабы проектной деятельности в области IT измеряются миллионами долларов, и, причем реализация новых проектов происходит постоянно. Развитие IT-инфраструктуры в растущих компаниях требует больших и регулярных вложений. Большие бюджеты, в свою очередь, подразумевают больший уровень ответственности и, соответственно, больший уровень компетенции тех людей, которые этими проектами управляют. 91

Изображение слайда
92

Последний слайд презентации: Управление IT проектом

5. Специфичное разделение на уровне идеологии заказчика и исполнителя: заказчиком, как правило, является бизнес, а исполнителем IT-специалисты. Данный аспект предопределяет наличие определенных трудностей в выявлении требований, ожиданий от проекта, в формировании технического задания. В IT-проектах чаще всего курирование процессами разработки и реализации осуществляется не бизнес-руководителем, а передается руководству IT, как следствие между ними возможны коммуникационные конфликты, несовпадение ожиданий, требований и результатов. Избежать подобного «недопонимания» между бизнесом и IT можно с помощью методик по выявлению и корректному фиксированию ожиданий от проекта, а также за счет четкого сбора требований к проекту на всех уровнях пользователей. 92

Изображение слайда