Файл: Методические рекомендации по организации и проведению практических работ по учебной дисциплине мдк. 02. 02 Управление проектами.pdf

19
Планирование
Разработка и периодическая актуализация плана
Утверждение плана
Управление командой проекта
Назначение сотрудника на роль
Руководителя проекта
Формирование команды проекта
Определение квалификационных требований и состава рабочих групп специалистов по разработке и реализации проекта
Обеспечение выделения необходимых ресурсов для выполнения проекта
Непосредственное руководство
Командой проекта
Формирование предложений по стимулированию Команды проекта
Обеспечение стимулирования Команды проекта
Организация выполнения работ
Организация взаимодействия с
Заказчиком и обеспечение всех необходимых коммуникационных связей с другими участниками проекта
Организация подготовки, согласования и утверждения всей документации, необходимой для создания продукта
(услуги) в рамках проекта
Организация, проведение и документирование процедур передачи
Заказчику разработанного продукта
(услуги)
Рассмотрение и утверждение

20 регламентирующих документов, необходимых для организации и выполнения проекта
Ведение организационно- распорядительной и отчетной документации.
Поддержание в актуальном состоянии списка команды проекта
Обеспечение команды проекта необходимыми информационными материалами
Материально-техническое и хозяйственное обеспечение команды проекта
Контроль хода выполнения проекта
Организация и проведение совещаний по обсуждению хода работ проекта
Подготовка и предоставление Куратору отчетов о ходе работ проекта
Получение и анализ сводной отчетности о ходе реализации проекта
Согласование фактических трудозатрат специалистов при исполнении проекта
2)
Сформировать матрицу отчетности
Таблица 2 Матрица отчетности.
Должностное лицо
Подготовка отчета
Рассмотрение
отчета
Архивация отчета
Обозначение: П- подготовка отчета, Р -рассмотрение отчета, А - архивация отчета.
3)
Сформировать план по вехам
Таблица 3 План по вехам.
Наименование вехи проекта
Ключевые даты
Содержание отчёта:

21 1)
Матрица ответственности.
2)
Матрица отчетности.
3)
План по вехам.
4)
Ответы на контрольные вопросы
Контрольные вопросы:
1)
Для чего необходимо использовать матрицу ответственности, матрицу отчетности?
2)
Что такое веха проекта?
3)
Что такое план по вехам, его значение для реализации проекта?
Раздел 1. Управление проектами в сфере информационных технологий
Тема 1.4. Планирование и структуризация проекта (12 часов)
Практическая работа №9
«Построение иерархической структуры проекта (этапы проекта,
декомпозиция, кодификация работ, расстановка взаимосвязей)».
Задачи обучающегося:
1. Изучить методы построения иерархической структуры проекта
Опорные понятия: ‘структура проекта
Планируемый результат:
Студент должен
Уметь осуществлять построение иерархической структуры проекта
Необходимое оборудование: ПК, MS Office
Порядок выполнения работы:
Изучите теоретический материал:
Для целей определения состава операций хорошо подходит методология последовательной иерархической структуры работ проекта, она также называется часто структурной декомпозицией работ (СДР), в англоязычной интерпретации – WBS (Work
Breakdown Structure), или структурой разбиения работ (СРР). Мы будем пользоваться аббревиатурой ИСР. Этот документ – плод творческой командной деятельности, в результате которой уточняется содержание проекта в части состава работ.
«Работа» – самое точное определение осуществляемых в ходе достижения проектных целей процедур в силу максимальной близости к задачному контексту проектной деятельности. Работу и задачу легче всего грамотно декомпозировать (разбить) на составляющие операции и подзадачи. Я лишь напомню, что работа – это элемент процессуального действия, имеющего входы, выходы, длительность, ресурсное наполнение, управляющее воздействие, а задача тяготеет к результату. Работа – категория динамическая, а задача – это точка в будущем, адекватная в понимании «достигнуто – не достигнуто» в заданный момент времени.
Хотя задача и работа не одно и то же, в проекте их объединяет результат, который и является предметом декомпозиции при разработке ИСР. Таким образом, разбивая общий результат проектной задачи на более мелкие элементы, которые мы также можем разбить, в итоге получаем структурную иерархию. Для такой иерархии обязательны правила как собственно разбиения, так и контроля правильности выполненной декомпозиции.

22
Визуальная форма иерархической структуры работ проекта
ИСР формируется на основе ряда правил, два из которых являются ключевыми.
1. Правило 100%. Специальное правило самопроверки обязывает собирать в структуру все создаваемые продукты, результаты работ, операций вне зависимости от источника их производства: внутреннего или внешнего. Это правило применяется ко всем элементам создаваемой иерархии. Ответственное за создание структуры проекта лицо обязано каждый раз после завершения списка раздела задавать вопрос: «Все ли мы учли, что могли забыть?».
На практике это представляет собой весьма дискомфортную процедуру. Поэтому практически сразу с момента начала работы над структурой PM следует привлекать экспертов. Именно здесь начинается детальное планирование и нужны те, кто досконально разбирается в отдельных процессах.
2. Правило взаимоисключения элементов. Каждый раз разбивая результат на детализированные элементы, нужно применять ясный критерий, при этом отслеживать, чтобы полученные объекты не смешивались на одном уровне и не дублировались на разных «веточках» иерархии. Под «веточками» далее будем понимать выделенные иерархические разделы, имеющие дальнейшее разбиение вниз. В иерархии не допустимы два или более элемента с идентичным содержанием. Эта ошибка может привести к дублированию операций и конфликтам.
Иерархическая структура работ представляет собой совокупность элементов, выполненных в удобной графической форме. Графическое представление имеет ряд преимуществ перед списочным составом задач или работ. За счет наглядности ИСР и коллегиального труда над ее созданием достигается большая вовлеченность и мотивация команды, уровень коммуникаций повышается, улучшается мониторинг операций и их контроль. Кроме того, визуальная форма позволяет охватить всю архитектуру проекта одним взглядом.
Важным элементом структуры выступают пакеты работ, представляющие собой как раз списки операций, в процессе выполнения которых достигается результат вышестоящей задачи. Пакет работ выполняется без потребности в дополнительной информации, выдает измеримый результат, подлежит реалистичной оценке и может быть передан для исполнения стороннему подрядчику. Важным подспорьем для иерархической структуры является специальный словарь. Он позволяет всем участникам однозначно толковать термины и элементы структуры, а менеджеру проекта словарь помогает определить границы ответственности членов команды и не допустить дублирования операций под разными названиями. В словаре ИСР указываются: номер элемента в структуре; название элемента; продолжительность операции; предшественник и последователь элемента;

23 результаты; ответственный за операцию участник.
Структура разрабатывается групповым методом в несколько итераций. При этом последовательно разбираются цели и результаты проекта, критерии их достижения, продукты, функциональные зоны, критерии разбиения результатов, объемы операций, технические требования. Схема этапов создания ИСР представлена в конце раздела.
Основные ориентиры (условия) при создании структуры работ следующие.
Для каждого элемента структуры формулируется измеримый результат.
Каждый результат вышестоящего элемента носит агрегированный характер, т.е. является итогом результатов «дочерних» элементов декомпозиции.
Пакеты и отдельные операции должны быть уникальными.
Структура должна быть полной, но не избыточной.
Элементы структуры верхних уровней должны быть совместимы с организационной структурой проекта.
Размер элементов нижнего уровня должен быть достаточным для эффективного управления, но не избыточным для их контроля.
Этапы разработки иерархической структуры работ
Выбор критериев для разбиения на элементы
Существует несколько подходов к разбиению результатов проекта на элементы.
Основными являются два из них: продуктовый и функциональный. Данные критерии совмещать на одном уровне нельзя, а на разных уровнях иерархии допустимо и даже целесообразно. Продуктовый подход необходим PM для общения с заказчиком. Заказчику важно видеть, что и когда менеджер будет ему сдавать, все ли продукты проекта будут ему представлены и т.п. Функциональный подход удобен менеджеру для взаимодействия с исполнителями. По нему проще назначить ответственных за отдельные блоки операций.

24
Кубическая модель структур проекта, преобразуемая в структуру работ
Иерархическая структура работ, формируемая под руководством PM, на верхних уровнях иерархии может использовать любой критерий, исходя из логики декомпозиции.
Часто, если проект выполняется в несколько этапов, может использоваться подход, исходя из кубической модели структур проекта (смотреть схему, размещенную выше). На верхнем уровне мы разбиваем результаты по этапам жизненного цикла проекта, затем структурируем по производимым проектным продуктам, и, наконец, пакеты работ комплектуем по функциональному критерию или по видам деятельности. Ниже вашему вниманию представлен пример продуктовой ИСР.
Пример продуктовой иерархической структуры
Мы находимся в позиции менеджера проекта. Для РМ ключевая информация для создания иерархической структурой кроется в уставе. В нем нам важен раздел «Структура продукта». Допустим, на первом уровне ИСР мы сразу используем продуктовый подход, игнорируя этапы жизненного цикла. Важно не допускать смешивания разных по значимости операций на одном уровне. Кроме того, нельзя смешивать содержательные и управленческие работы.
Описание содержательных действий следует выполнить в первую очередь. Только когда данное описание выполнено полностью, можно формировать управленческий блок работ, выделив его в условный продукт, например, в «Систему управления проектом».
Помимо содержательного комплекта продуктов и СУП на первом уровне иерархии также размещаются такие «продукты», как «Проектная документация» и «Объект, сданный в эксплуатацию». Далее приведен пример иерархической структуры, сформированной по функциональному критерию.

25
Пример функциональной иерархической структуры
Задание:
1.Исходя из предметной области составить функциональную структуру проекта
2.Оформить отчет о проделанной работе
Раздел 1. Управление проектами в сфере информационных технологий

26
Со стороны заказчика ключевые роли играют спонсор проекта и менеджер
проекта. Спонсор проекта обеспечивает организационную сторону проекта и подтверждает правильность целей проекта. В его ведении находится бюджет проекта. Спонсором проекта может быть отдельный человек или целый комитет, в зависимости от масштабов и сложности проекта. Менеджер проекта со стороны заказчика назначается в том случае, если осуществление проекта организацией заказчика требует ежедневного управления. В его обязанности входит предоставление ресурсов заказчиков, разрешение проблем и отслеживание состояния проекта.
Ключевые роли со стороны исполнителя - руководитель проекта (менеджер
проекта) со стороны исполнителя и бизнес-менеджер.
Бизнес-менеджер отвечает за успешное выполнение проекта и представляет исполнителя в его договорных отношениях с заказчиком. Менеджер проекта
(руководитель проекта) отвечает как за успехи, так и за неудачи проекта. В его задачи входит управление сроками, стоимостью, качеством работ с целью удовлетворения ожиданий заказчика и достижения бизнес-целей исполнителя.
Команда управления проектом включает координатора проекта, администратора
проекта, менеджера по конфигурации, комитет по управлению, комитет по контролю за
изменениями, комитет по анализу спорных вопросов.
В состав команды проекта входят не только команда управления проектом, но и исполнители проекта. Примеры проектных ролей исполнителей, характерных для IT- проектов: функциональный архитектор, функциональный консультант, разработчик,
администратор ИС, тестировщик, менеджер по качеству, системный аналитик.
ЗАДАНИЕ:
1. Рассмотрите пример матрицы ответственности. Аналогично, согласно своей предметной области и организационной структуры постройте матрицу ответственности.
2. Составьте реестр навыков члены команды управления монопроекта (см. табл.4)
3. Заполните Реестр навыков согласно своей предметной области (см. табл. 2,3)
ПРИМЕР:
Категории и компонеты навыков
Критичность
Способности
Технические навыки (категория I)
Оказание помощи в разрешении проблем
Взаимодействие с техническим персоналом
Понимание технологий и трендов (тенденций)
Понимание прикладных задач маркетинга и применение продукта
Очень важно
Административные навыки Привлечение и удержание работников высокого класса
Способность к эффективному общению (устному и письменному)
Оценивание ресурсов и ведение переговоров с целью их получения
Работа (сотрудничество) с другими организациями
Важно
Навыки межличностного общения и лидерства
Способность инициировать преобразования, совершенствовать методы управления
Урегулирование конфликтов
Оказание помощи при принятии групповых решений
Оказание помощи в решении проблем
Формирование перспективной точки зрения
Определение четких и ясных целей
Управление конфликтами
Мотивация людей
Очень важно
Стратегические навыки
Способность работать в условиях рисков и неопределенностей
Стратегическое мышление, планирование и применение
Важно