
- •Оглавление
- •Лекция 1. Инициация проекта
- •Адаптация модели жизненного цикла проекта
- •Цели этапов жизненного цикла информационной системы
- •Области знаний проектного управления
- •Шаблон адаптации модели жизненного цикла информационной системы
- •Разработка технико-экономического обоснования
- •Матрица структурирования выгод ит-проекта
- •Формирование бизнес-цели проекта
- •Разработка устава проекта
- •Требования к уставу проекта
- •Шаблон листа управления документом
- •Идентификация и анализ участников проекта
- •Анализ воздействия участников проекта (адаптировано из [5])
- •Формирование требований проекта
- •Большой толковый словарь
- •Шаблон протокола интервью
- •Лекция 2. Планирование проекта
- •План управления проектом
- •Формирование иерархической структуры проекта
- •Определение содержания проекта
- •Требования к описанию содержания проекта
- •Формирование списка работ (операций) проекта
- •Пример списка работ
- •Определение логической последовательности выполнения работ
- •Оценка трудоемкости и потребности в ресурсах
- •Нормативы трудоемкости разработки документов на ас
- •Определение длительности операций.
- •Исходная информация процесса определения длительности операций
- •Концептуальная оценка стоимости проекта
- •Формирование сметы
- •Пример сметы проекта
- •Разработка базового плана по стоимости проекта
- •Лекция 3. Разработка расписания проекта
- •Исходные данные для разработки расписания
- •Результаты разработки расписания
- •Технология разработки расписания
- •Шаблон последовательного формирования расписания проекта
- •Пример использования шаблона последовательного формирования расписания
- •Разработка расписания проекта методом критического пути
- •Расчет раннего финиша
- •Операции проекта
- •Расчет позднего финиша
- •Расчет временного резерва
- •Организация управления расписанием проекта
- •Шаблон формы отчета о прогрессе проекта
- •Лекция 4. Планирование обеспечения качества в проекте
- •Анализ процессов управления качеством
- •Разработка плана обеспечения качества
- •Пример плана обеспечения качества проекта
- •Регламент по управлению качеством в проекте
- •Определение списка процедур для управления качеством
- •Организация управления качеством
- •Пример контрольных списков проверки качества
- •Форма представления результатов контроля качества
- •Шаблон регистрации отклонений
- •Лекция 5. Планирование рисков проекта Основные понятия управления рисками
- •Примеры управления рисками
- •Семиуровневая оценка вероятности возникновения риска
- •Шкала для оценки последствий риска, измеряемых в деньгах
- •Шкала для оценки последствий риска, измеряемых отклонениями в стоимости, сроках и технических условиях проекта
- •Определение шкалы оценки воздействия для четырех целей проекта
- •Организация управления рисками
- •Пример шаблона плана реагирования на риски
- •Пример формы регистрации риска
- •Лекция 6. Планирование человеческих ресурсов проекта
- •Определение ролей проекта
- •Матрица ответственности проекта
- •Условные обозначения матрицы ответственности (raci)
- •Распределение функциональных обязанностей команды управления проектом
- •Закрепление функций и полномочий в проекте
- •Влияние факторов внешней среды на планирование команды проекта
- •Реестр навыков для команды исполнителей проекта
- •Шкала рейтингов критичности и способностей (адаптировано из __?___ )
- •Реестры навыков
- •Реестр навыков для членов команды исполнителей
- •Реестр навыков члены команды управления проекта
- •Реестр технических компетенций
- •Пример оценки технических навыков членов команды исполнителей проекта
- •Описание грейдов консультантов
- •Лекция 7 . Планирование коммуникаций и управления конфигурацией в проекте
- •Формирование стратегии коммуникаций
- •Шаблон плана коммуникаций проекта
- •Пример матрицы коммуникаций
- •Идентификация объектов управления конфигурацией проекта
- •Формирование базовой линии конфигурации проекта
- •Организация управления конфигурацией проекта
- •Структура плана управления конфигурацией (адаптировано из [18])
- •Лекция 8. Оценка реализуемости проекта
- •Переход к стадии оценки
- •Проверочный список для этапа планирования
- •Анализ достижимости запланированных бизнес-выгод
- •Форма анализа тэо
- •Оценка реализуемости проектного расписания
- •Оценка доступности и загрузки человеческих ресурсов
- •Пример календарно-ресурсного плана
- •Пример заполнения календарно-ресурсного плана
- •Оценка организационной готовности
- •Шаблон оценки организационной готовности проекта
- •Лекция 9. Идентификация рисков проекта
- •Методики идентификации рисков
- •Сравнение методов идентификации рисков
- •Шаблон реестра рисков
- •Пример заполнения реестра рисков (упрощенный)
- •Пример заполнения расширенного журнала рисков
- •Качественный анализ рисков
- •Количественный анализ рисков
- •Сравнение стратегий реагирования на риски
- •Подтверждение содержания проекта
- •Лекция 10. Управление проектом на фазе проектирования
- •Формирование детальных планов стадии проектирования
- •Уточнение плана управления проектом
- •Руководство и управление исполнением проекта
- •На рисунке есть опечатки: слова «заказчика», «групп» должны быть со строчной буквы Обеспечение качества проекта
- •Осуществление интегрированного управления изменениями
- •Шаблон запроса на внесение изменений (pcr)
- •Шаблон журнала изменений проекта (pcl)
- •Обеспечение качества проекта на этапе проектирования
- •Обеспечение целостности элементов конфигурации
- •Обновление реестра рисков на фазе проектирования
- •Набор команды проекта
- •Оценка и управление персоналом проекта
- •Определение уточненных требований проекта
- •Мониторинг содержания и объема проекта
- •Шаблон отчета по статусу проекта (адаптировано из [8])
- •Управление требованиями проекта
- •Оценка потребности в обучении пользователей
- •Факторы выбора содержания и методологии обучения
- •Формы обучения (адаптировано из [5])
- •Лекция 11. Реализация плана коммуникаций и обучение пользователей. Подготовка перехода к следующей фазе
- •Информирование участников проекта
- •Контрольный список по реализации коммуникаций
- •Планирование обучения пользователей
- •Управление расписанием проекта
- •Расчет крутизны стоимость/время
- •Последовательность и продолжительность проектных работ
- •Результаты расчета критического пути
- •Значение крутизны, новой стоимости и критического пути проекта
- •Управление стоимостью проекта
- •Формула 5. Расчет ключевых показателей метода eva
- •Контроль качества проекта
- •Пример формы сводной таблицы сценариев тестирования
- •Пример формы журнала ошибок
- •Функции участников команды проекта, обеспечивающих выполнение процесса контроля
- •Контроль рисков проекта
- •Пример формы (интенсивного) мониторинга сотрудника
- •Лекция 12. Управление проектом на фазе разработки и внедрения
- •Детальное планирование стадии разработки и внедрения
- •Подготовка инфраструктуры для фазы эксплуатации
- •Осуществление итогов контроля качества проекта
- •Управление рисками настройки и внедрения
- •Подготовка персонала к завершению проекта
- •Организация тестирования
- •Шаблон документирования результатов процессного тестирования
- •Переход к продуктивной эксплуатации
- •Завершение проекта (фазы)
- •Учебный кейс
- •График управления стоимостью
- •Устав проекта Внедрение Microsoft Dynamics ax в компании «Client Company»
- •Бизнес-причины возникновения проекта
- •Цели проекта
- •Требования к проекту
- •Расписание контрольных событий
- •Участники проекта
- •Окружение проекта
- •Допущения и ограничения
- •Стоимость проекта
- •Руководитель проекта
- •Полномочия команды управления проектом
- •Приложение. Принятые термины и сокращения
- •Содержание проекта
- •Цели и задачи проекта
- •Требования к проектному решению
- •Границы проекта
- •Способ реализации проекта
- •Crm (управление взаимоотношениями с клиентами)
- •Первоначальная иерархическая структура работ (иср) до пакетов работ
- •1. Диагностика
- •2. Анализ
- •Потребность в ресурсах, штатное расписание и организационная структура проекта
- •Матрица ответственности
- •Укрупненный календарный план
- •Ключевые факторы успеха
- •Первоначально сформулированные риски
- •Смета расходов с указанием порядка величин
- •Ограничения проекта (со стороны исполнителя)
- •Требования к управлению конфигурацией проекта
- •План управления проектом Внедрение Microsoft Dynamics ax в компании «Client Company»
- •Цели и задачи проекта
- •Требования к проектному решению
- •Границы проекта
- •Способ реализации проекта
- •Ключевые факторы успеха
- •Ограничения проекта (со стороны Исполнителя)
- •Допущения проекта (со стороны исполнителя)
- •Процедуры управления содержанием Процедура верификации и приемки завершенных результатов поставки проекта
- •План управления расписанием Базовое расписание проекта
- •Процедуры управления сроками Процедура разработки расписания
- •Процедура контроля хода выполнения проекта
- •Процедура определения потребности во внесении изменений
- •Процедура внесения изменений
- •Процедуры управления стоимостью Процедура оценки стоимости выполненных работ
- •Процедура контроля (мониторинг)
- •Процедура анализа показателей
- •Процедура прогнозирования
- •Процедура внесения корректирующих мер
- •План управления качеством
- •Процедуры управления качеством проекта Процедура разработки плана тестирования
- •№ Сценария – уникальный идентификатор сценария тестирования;
- •Процедура проведения тестирования
- •Процедура проведения аудита качества
- •Процедура анализа процесса управления качеством
- •Процедура контроля качества документов проекта
- •Процедура разработки и согласования глоссария проекта
- •План управления обеспечением проекта персоналом Потребность в ресурсах, штатное расписание и организационная структура проекта
- •Процедуры обеспечения проекта персоналом Процедура набора персонала
- •Процедура премирования
- •Процедура обеспечения безопасности
- •План управления коммуникациями
- •Процедуры управления коммуникациями
- •Процедура предоставления отчетов по исполнению
- •Процедура распространения информации
- •Процедура анализа накопленных знаний
- •План управления рисками
- •Процедуры управления рисками Процедура планирования управления рисками
- •Процедура идентификации рисков
- •Процедура качественного анализа рисков
- •Процедура количественного анализа рисков
- •Процедура планирования реагирования на риски
- •Процедура мониторинга и управление рисками
- •План управления изменениями
- •Процедуры управления изменениями Процедура управления изменениями
- •Процедуры управления конфигурацией проекта
Шаблон запроса на внесение изменений (pcr)
Название проекта |
|
Запрос № |
|
||
Описание предлагаемого к внесению изменения и его влияние на содержание и качество проекта |
|||||
|
|||||
Автор запроса |
|
Дата подачи |
|
||
Причина подачи запроса |
|
||||
Экстренные меры (если таковые имеются) |
|
Стоимость обнаружения изменения |
|
||
Тип изменения |
|||||
Значительное (требуется перепланирование) |
|
Незначительное |
|
||
Стоимость обнаружения изменения |
|
||||
Описание влияния на расписание проекта |
|||||
|
|||||
Оценка сроков произведена согласно документу |
|
||||
Описание влияния на стоимость проекта |
|||||
|
|||||
Оценка стоимости произведена согласно документу |
|
||||
Финансируется ли изменение заказчиком? |
|
Если да, то укажите документ-основание |
|
||
Резолюция управляющего комитета |
|||||
|
|||||
Дата принятия решения |
|
На шаблоне видно, что запрос представляет собой форму с рекомендуемым объемом не больше 1 страницы, подготовка его может занять некоторое время и потребовать участия различных специалистов.
По возможности рекомендуется реализовать изменения на ранних стадиях проекта, в то время, когда стоимость их реализации традиционно гораздо ниже. Со временем продвижения вперед по расписанию проекта стоимость внесения изменений возрастает [11]. Вообще говоря, на стадии планирования обычно не имеет смысла использовать PCR: при наличии лишь грубо очерченного содержания нет никакой практической надобности пытаться контролировать изменения при помощи формализованной процедуры. Однако на более поздней стадии проектирования PCR приобретает практический смысл и его применение становится финансово оправданным. Например, на проекте разработки нового продукта имеет смысл использовать PCR для изменений, которые составляют отход от согласованных технических спецификаций и влияют на спецификации, выпущенные инженерным отделом для планирования закупок или производства. Тем не менее, в какой-то момент времени внесение изменений в проект может замедлить ход продвижения проекта, потенциально ведя к дорогостоящим переделкам. В подобной ситуации эффективным шагом является замораживание проекта по предметной части, после которого ни одно изменение не будет рассматриваться, если только не находятся критические причины в пользу такого рассмотрения. В качестве примера можно привести финансируемое заказчиком требование добавить в продукт новый показатель безопасности.
Рекомендации к заполнению содержательных разделов PCR (см. Таблица 53)
Описание предлагаемых к внесению изменений и их воздействий на содержание / качество
Описание запрашиваемого изменения должно быть достаточно точным, чтобы дать надлежащее понимание того, какая часть, предмет поставки или пакет работ должна быть изменена и каким образом. Необходимость длинных описаний исключена; язык, используемый для этой цели, должен быть как можно более лаконичным.
Объяснение причин изменения
Мотивация может быть различной. Для того чтобы иметь уверенность в правильном понимании мотивации и не допустить мотивации, идущей во вред, рекомендуется применять подход «необходимое/желаемое изменение», описанный выше. Данная методика может казаться излишне простой, однако она позволяет руководителю проекта обезопасить себя и убедиться, что каждое предлагаемое изменение имеет свое разумное обоснование.
Идентификация необходимости экстренных мер изменений
Типичная проблема, сопутствующая иногда излишне формализованному процессу интегрированного управления изменениями, состоит в том, что такое рассмотрение чрезмерно медлительно. Для преодоления этой проблемы вводится графа «экстренные меры», задача такого PCR – проинформировать орган по изменениям о том, что запрашиваемое изменение нуждается в срочном рассмотрении и утверждении. Это может означать, что органу по изменениям придется действовать быстро. Исключительно важно, чтобы чрезвычайные изменения не являлись оправданием дезинформирующих оценок в части качества, исполнения, надежности, безопасности или любых других аспектов.
Оценка влияния на расписание проекта
Сетевой график, на котором показаны логические зависимости операций, помогает анализировать, каким образом изменения в одном предмете поставки и соответствующих ему операциях повлияют на зависимые операции, расположенные дальше во времени. Часто оценивание влияния на расписание выполняется интуитивно, что в среднем на 40% менее эффективно аналитического подхода (McAfee, 2009), в то время как неформальный, но качественно выполненный анализ сетевого графика пойдет на пользу любому проекту.
Оценка влияния на стоимость проекта
Требование выполнения оценивания стоимости или ресурсов, необходимых для предлагаемого изменения, представляет собой эффективную стратегию предотвращения финансовых сюрпризов. Требование выполнения основанной на базе данных восходящей оценки при подаче запроса на внесение изменения – это имеющая твердое обоснование мера предосторожности, направленная на противодействие свойственной людям склонности снижать оценки затрат. Если изменение является значительным, вполне можно пойти дальше и запросить оценку из независимого источника, чтобы сравнить ее с оценкой автора изменения.
Идентификация типа изменения
Для избегания риска «расползания» расписания, объема и бюджета проекта необходимо просеивать все предлагаемые изменения путем определения, как они повлияют на содержание и качество проекта. Если изменение оказывает незначительное влияние, то оно может рассматриваться как незначительное корректирующее воздействие, не затрагивающее базовые планы содержания, качества, стоимости и расписания. И наоборот, изменение может быть определено как значительная перемена в содержании работ, финансировании и сроках. Это может служить обоснованием необходимости перепланирования (или переопределения базового плана), включая изменения расписаний, бюджета и распределения ресурсов. Для того чтобы сделать всех вовлеченных в полном объеме осведомленными о таких последствиях, необходимо определиться с тем, является ли данное изменение значительным или незначительным. А это, в свою очередь, становится возможным лишь после оценивания влияния изменения на содержание, качество, стоимость и расписание.
Принятие решения/ резолюция по PCR
Утверждение запроса на изменение – инициация действий по реализации изменения. Как любая проектная работа, это действие требует планирования, в высшей степени скрупулезного для больших проектов и менее скрупулезного – для малых. Планирование действия по изменению и тщательный мониторинг его выполнения являются необходимыми предварительными условиями для его успешного завершения.
Журнал изменений проекта
Запрос на внесение изменений позволяет собирать детальную информацию о конкретном единичном изменении, для целей же координации потока изменений, сопровождающих любой проект, принято использовать журнал изменений (см. Таблица 54). Администрируемый координатором изменений, PLC фиксирует каждый запрос на внесение изменения в проект и присваивает ему номер, обеспечивая, чтобы решение, принятое по данному запросу, был ли он утвержден или отклонен управляющим комитетом проекта, также было зафиксировано.
Роль PCL как репозитория изменений обеспечивает хороший контроль за всеми запрошенными, отклоненными, одобренными, выполняемыми и завершенными изменениями. Ценность этой информации заключается в ее потенциальной способности предотвратить потери средств и задержки в проекте путем информирования лиц, принимающих решения, о влиянии основных изменений на бюджет и расписание проекта. Такая ясность неизбежно уменьшает путаницу, часто встречающуюся в ситуациях, когда PCL отсутствует.
Таблица 54