лекция. Основные понятия управления проектами
 Скачать 1.91 Mb.
|
|
ГЛАВА 4. УПРАВЛЕНИЕ ИНТЕГРАЦИЕЙ ПРОЕКТА Управление интеграцией проекта включает в себя процессы и работы по идентификации, определению, объединению, унификации и координации различных процессов и работ по управлению проектом различных групп управления проектом. Цель интеграции состоит в достижении эффективного взаимодействия процессов управления проектами, обеспечивающих достижение целей проекта. Интеграция управления проектом требует, чтобы все процессы управления проектами были выстроены и связаны с другими процессами для облегчения их координации. В контексте управления проектом интеграция — это принятие решений о том, где концентрировать ресурсы на каждую конкретную дату, предугадывание потенциальных проблем, и их решение до того, как эти проблемы станут критическими, и хорошая координация работы проекта в целом. Интеграция также подразумевает нахождение компромиссов между пересекающимися целями и альтернативами. Управление интеграцией подразумевает интеграцию всех остальных процессов управления. Часто связи между процессами в группах процессов управления проектами неоднократно повторяются. Например, группа процессов планирования на ранней стадии проекта предоставляет группе процессов исполнения подготовленный план управления проектом; впоследствии она участвует в его обновлении по мере появления изменений по ходу выполнения проекта. Управление интеграцией проекта включает в себя процессы: разработку устава проекта, разработку плана управления проектом, управление исполнением проекта, мониторинг хода выполнения, общее управление изменениями, закрытие проекта или фаз. 4.1. Разработка устава проекта Устав — это первый официальный документ проекта. Устав проекта является документом, формально авторизующим проект. Устав проекта наделяет менеджера проекта полномочиями задействовать ресурсы организации на операциях проекта. Менеджер проекта определяется и назначается как можно раньше. Менеджера проекта необходимо всегда назначать до начала планирования и желательно на этапе разработки Устава проекта (табл. 4.1). Таблица 4.1.Разработка устава проекта
Устав проекта включает в себя:
Пример формы устава проекта приведен в Приложении 1. Метод экспертной оценки часто применяется для оценки входов, необходимых для разработки Устава проекта. Такая оценка и экспертиза применяются ко всем техническим и организационным деталям в ходе этого процесса. Экспертиза осуществляется любым лицом или группой лиц, имеющими специальные знания или подготовку; источники в таких случаях могут быть разными:
4.2. Разработка плана управления проектом План управления проектом может быть либо резюмирующим, либо детализированным и состоять из одного или нескольких вспомогательных планов и приложений. Каждый из вспомогательных планов описывается настолько подробно, насколько того требует конкретный проект (табл. 4.2). Таблица 4.2.Разработка плана управления проектом
Пример Плана проекта приведен в Приложении 2. Вспомогательные планы включают в себя (список не исчерпывающий):
Приложения включают в себя (перечень не исчерпывающий):
Различают базовый и текущий план проекта. Базовый план проекта — это официально утвержденный документ, относительно которого измеряется выполнение проекта и который будет использоваться для управления и контроля за исполнением проекта. Базовый план изменяется только в крайних случаях, обычно по согласованию со спонсором проекта, заказчиком, управляющим комитетом проекта. Текущий план проекта — это документ или набор документов, который изменяется по мере выполнения проекта и поступления информации о фактическом выполнении работ. Как правило, такой план всегда отличается от базового, так как ни один проект не может идти в точности согласно первоначальному плану. Текущий план изменяет руководитель проекта. Очень часто в больших проектах невозможно сразу сформировать детальный план проекта. В действительности, если проект рассчитан на годы (например, строительство здания), то определить в точности до одного дня сроки всех детальных работ невозможно. В этом случае используется планирование методом набегающей волны. Метод набегающей волны — вид планирования последовательной разработки, при котором работа, которую надо будет выполнить в ближайшей перспективе, подробно планируется с глубоким раскрытием иерархической структуры работ, в то время как далеко отстоящая работа планируется с относительно неглубоким раскрытием иерархической структуры работ, но по мере выполнения работ производится подробное планирование работ, которые надо будет выполнить в ближайшие временные периоды. Таким образом, на первом этапе планируются укрупненные этапы работ, ресурсы и суммы бюджета по этапам, а в дальнейшем перед приближением каждого следующего этапа план уточняется до деталей. Такой метод часто применяется в авиастроении, например, при разработке новой модели самолета, когда неизвестно в точности, какие технологические решения будут применяться. 4.3. Управление исполнением проекта Процесс управления исполнением фактически подразумевает выполнение работ проекта для создания результата проекта (табл. 4.3). Таблица 4.3.Управление исполнением проекта
Одобренные запросы на изменение — это документированные, согласованные изменения, изменяющие содержание проекта. Согласованные запросы на изменение могут также изменять внутренние правила, планы управления проектом, процедуры, затраты или бюджет, а также графики работ. Процесс руководства и управления исполнением проекта требует от менеджера и команды проекта выполнения ряда действий по выполнению плана управления проектом. Вот некоторые из этих действий:
Менеджер проекта вместе с командой управления проектом управляет ходом запланированных операций проекта и различными техническими и организационными взаимосвязями, существующими в рамках проекта. 4.4. Мониторинг и контроль над работами проекта Мониторинг и контроль над работами проекта — это процесс непрерывного наблюдения, анализа и регулирования прогресса проекта для достижения целевых показателей эффективности, определенных в плане управления проектом (табл. 4.4). Таблица 4.4.Мониторинг и контроль над работами проекта
Процесс мониторинга и управления работами проекта затрагивает следующие моменты:
Основным результатом мониторинга (наблюдения) и контроля (сравнение плана и факта) является выявления отклонений от плана проекта. Такие отклонения обычно регистрируются в Запросе на изменение. Запрос на изменение может инициировать любой участник проекта, однако в формальной форме запрос обычно регистрируется руководителем проекта. 4.5. Общее управление изменениями Внесение изменений — это цикличный процесс, который повторяется в течение всего исполнения проекта. Внесение изменений включает процесс контроля выполнения плана проекта, анализ полученных данных и отчетности, принятие решений по результатам анализа и внесение изменений в план при необходимости (табл. 4.5). Таблица 4.5.Общее управление изменениями
Менеджер проекта несет ответственность за полное и своевременное обновление плана проекта в соответствии с возникшими изменениями. Менеджер проекта должен обновлять план проекта ежедневно. Источниками отклонений могут служить как внутренние факторы проекта (срыв сроков, болезнь исполнителей и т.п.), так и внешние (новые запросы заказчика с дополнительными требованиями). Анализ внесения изменений проводится с целью учета последствий изменений плана проекта. Анализ может производиться менеджером проекта по показателям:
Если показатели выходят за допустимые ограничения, Менеджер проекта должен инициировать процедуру согласования изменений с руководителем программы проектов, портфеля проектов, заказчиком, спонсором и так далее. Если изменение не выходит за рамки ограниченных параметров, менеджер проекта сам принимает решение по изменению. Менеджер проекта отслеживает статус Запроса на изменение (инициирован, на анализе, отклонен, принят, закрыт). Запросы на изменение обычно регистрируются в Регистрационном журнале изменений . Регистрационный журнал изменений содержит перечень всех Запросов на изменения по проекту, дату их поступления, статус, сроки выполнения, инициатора изменения и другую справочную информацию. Пример Запроса на изменение приведен в Приложении 3. Пример Регистрационного журнала изменений приведен в Приложении 4. Если изменение согласовано руководством (например, по запросу заказчика добавляется новый блок работ в проект), руководитель проекта меняет базовый план проекта (увеличивает сроки, планирует новые работы и бюджет). В проектах для внешнего заказчика главной целью команды проекта при управлении изменениями является ограничение разрастания рамок работ по проекту. Если же изменение действительно необходимо, желательно, чтобы спонсор (заказчик) проекта финансировал дополнительные работы и заключил дополнительное соглашение к контракту на данные работы. 4.6. Закрытие проекта (или фазы) Закрытие проекта или фазы — это процесс завершения всех выполненных операций во всех группах процессов управления проектом для формального закрытия проекта или проектной фазы. Процесс закрытия проекта также определяет процедуры исследования и документирования причин отклонений (табл. 4.6). Таблица 4.6.Закрытие проекта или фазы
Необходимо отметить, что процессу формального завершения проекта очень часто не уделяется достаточно внимания, что ведет к серьезным проблемам в работе с заказчиками. Самая распространенная ситуация, когда результат проекта передается заказчику в недоработанном виде или с заказчиком остаются невыполненные договоренности о доделках каких-либо работ. Например, команда проекта реализует проект открытия нового торгового центра. Торговый центр должен открыться к определенной заранее дате, так как именно к этой дате приурочена рекламная компания и церемония открытия, перенести сроки которых очень сложно. Сроки выполнения работ по проекту задерживаются, и команда проекта к открытию доделать все работы не успевает. Торговый центр открывается с небольшими недоделками — не работает лифт, не установлена система кондиционирования в рабочих помещениях и т.д. Все недостатки собственными силами доделывает служба эксплуатации здания, что приводит к дополнительным затратам времени и средств. Команда проекта не несет ответственности за свои недоработки, но получает положенную премию и считает проект завершенным. Таким образом, на этапе завершения проекта должны быть проанализированы критерии закрытия проекта:
Только после выполнения всех требований к завершению проект может быть закрыт. ГЛАВА 5. УПРАВЛЕНИЕ СОДЕРЖАНИЕМ ПРОЕКТА Управление содержанием проекта включает процессы, необходимые для того, чтобы удостовериться в том, что проект включает все необходимые работы (и только их) для достижения успеха проекта. Процессы этой области знаний:
Управление содержанием осуществляется на протяжении всего жизненного цикла проекта. Содержание проекта — работы, которые необходимо выполнить, чтобы получить продукт, услугу или результат с указанными свойствами и функциями. Содержание продукта — свойства и функции, которые характеризуют продукт, услугу или результат. Определение содержания и управление им определяет общий успех проекта. При работе над каждым проектом важно соблюдать баланс средств, источников данных и методологий, процедур и других факторов для того, чтоб усилия, потраченные на работу с содержанием, соответствовали размеру, сложности и важности проекта. Многие проекты терпят неудачи чаще всего из-за того, что их содержание и границы плохо определены. Ожидания стороны, заинтересованной в реализации проекта (в частности, заказчика или спонсора), часто не совпадают с ожиданиями команды, занятой в проекте. Сделать так, чтобы ожидания совпадали, — задача трудная, однако крайне важно решить ее для успеха проекта в целом. Когда речь заходит об определении содержания проекта, команда проекта и клиент как бы меняются ролями. До этого момента с заказчиком в основном контактируют люди, в задачи которых входит «продать» проект. «Продавец» пытался убедить заказчика, что проект — дело стоящее, на него стоит потратиться. Иногда «продавец» описывает проект в столь ярких красках, что намеренно или непроизвольно заставляет клиента поверить: все, что мог себе представить последний в самых невероятных мечтах, благодаря проекту превратится в реальность. На деле такое происходит весьма редко. У заказчика формируются завышенные ожидания, что очень опасно для проекта. Когда команда проекта сформирована и определение содержания проекта происходит в процессе переговоров, заказчик считает, что проект уже согласован. В итоге весь процесс определения содержания и границ проекта заказчик считает пустой тратой времени. Клиент может даже воспротивиться определению содержания проекта. Это происходит в том случае, если заказчик не знает в точности, что ему необходимо. Одно из наиболее сложных испытаний для команды проекта — убедить представителей заказчика, что их цели в проекте во многом схожи. Другими словами, главная цель проекта — дать заказчику то, что ему действительно нужно и очень важно, и описать содержание проекта. Команда проекта должна войти в положение заказчика. То, что заказчик знает о проекте немного, не помешает его успешно реализовать. В конечном счете, причина, по которой на проекте работают определенные люди, как раз в том и состоит, что это специалисты именно в данной области. Что бы представители заказчика ни думали, они специалистами не являются, иначе не обратились бы к подрядчику. Иногда для определения границ проекта должны быть использованы неординарные средства. Возможно, одному или нескольким сотрудникам проекта придется поработать какое-то время у заказчика, чтобы войти в курс дела и осознать, каких усовершенствований он ждет от проекта. Это хороший прием, если клиент не желает или не способен выделить необходимые временные и кадровые ресурсы для работы с командой проекта. Представитель проекта как бы перевоплощается в заказчика и, узнав о нем достаточно много, начинает выступать от его имени. 5.1. Сбор требований Сбор требований — это процесс определения и документирования требований участников проекта относительно результатов проекта (табл. 5.1). Таблица 5.1.Сбор требований
Реестр участников проекта должен включать:
Документированные требования участников проекта должны содержать:
План управления требованиями (рис. 5.1 ) определяет порядок анализа, документирования и управления требованиями в течение жизненного цикла проекта.  Матрица отслеживания требований — это таблица, в которой показана корреляция между требованиями к проекту и его элементами, как то:
Пример матрицы отслеживания требований показан в табл. 5.2. Таблица 5.2.Пример матрицы отслеживания требований
В российской практике требования к проекту оформляются в Техническом задании на проект. Часто техническое задание является приложением к договору. Необходимо отметить, что в российской специфике бизнеса только договор с подписями и печатями сторон является несокрушимым аргументом в споре с заказчиком при разрастании требований к проекту. Поэтому команда проекта должна всеми силами стараться включить максимально подробные требования к проекту со всеми ограничениями и допущениями в контракт. Ограничения по проекту — это все, что ограничивает рамки проекта. Например, ограничением содержания проекта по проведению учебного курса будет являться программа курса. При желании заказчика программа курса может быть расширена, то есть количество работы увеличивается, но расширение программы будет сделано за дополнительную плату. Допущения проекта — это все предположения, которые делает команда при планировании работ. Например, при проведении курса мы делаем допущение, что заказчик самостоятельно подготовит учебный класс и предоставит компьютеры слушателям. 5.2. Определение содержания Определение содержания — это создание детального документа, отражающего цели и задачи проектных работ («Описание содержания проекта», согласно PMI). Необходимо отметить, что из-за плохого перевода термина в России никто не использует подобное название документа. Процесс определения содержания показан в табл. 5.3. Таблица 5.3.Определение содержания
Обычно, подобный документ называется Техническим проектом, Концепцией или просто Проектом, содержащим проектную документацию (например, чертежи здания). Основой для разработки Описания содержания проекта (Технического проекта) служит Устав проекта, который детализируется в Требованиях к проекту (Техническом задании). Включает следующие разделы:
В крупных технологически сложных проектах, к которым предъявляются серьезные требования к безопасности и технологии проведения работ, российские предприятия применяют требования ГОСТ для создания проектной документации. Примерами таких сложных проектов могут служить бурение нефтяных скважин, строительство дорог, зданий и т.д. Однако даже в небольших проектах нужно очень подробно описывать все характеристики будущих результатов проекта, для того, чтобы избежать потом разногласий с заказчиком по приемке работ. Даже если заказчик считает подобный документ ненужным, команда проекта должна убедить его подписать документ. Всегда есть риск, что руководитель проекта не сможет доказать, что проект завершен из-за появления новых требований заказчика. Чаще всего невозможно описать все содержание проекта подробно. Поэтому Описание содержания может детализироваться и уточняться в ходе проекта. 5.3. Создание иерархической структуры работ Создание иерархической структуры работ — это декомпозиция целей проекта на более мелкие и более управляемые компоненты (табл. 5.4). Таблица 5.4.Создание ИСР
ИСР — согласованная с результатами проекта иерархическая декомпозиция работ, которые команда проекта должна выполнить для достижения целей и создания результатов проекта. Декомпозиция — это разбиение основных целей и результатов на более мелкие и управляемые с целью:
Этапы декомпозиции: 1) определение основных целей проекта; 2) декомпозиция основных целей; 3) разбиение каждой цели на фундаментальные компоненты. Обычно применяют следующие виды ИСР:
 Могут быть и другие, в том числе смешанные типы. Основное требование при декомпозиции — на одном уровне иерархии не должно быть смешения принципов декомпозиции (то есть, нельзя смешивать классификацию яблок по принципам цвета, сорта и размера на одном уровне). На каждый блок ИСР должен быть назначен ответственный сотрудник, что позволит закрепить ответственность за конкретными членами команды. На практике ИСР формируется обычно в информационной системе управления проектами. Словарь ИСР — документ, появляющийся при создании ИСР и обеспечивающий работу с ней. Словарь ИСР используется для расширения информации о каждом элементе ИСР. Каждый элемент словаря должен содержать описание элементарной работы, связанные с ней операции, ее стоимость и длительность, ответственного за эту работу и риски, связанные с этой работой. Словарь ИСР представляет собой реестр всех элементов ИСР и их характеристики (табл. 5.5). Таблица 5.5.Пример словаря ИСР
ГЛАВА 6. УПРАВЛЕНИЕ СРОКАМИ ПРОЕКТА Управление сроками проекта включает в себя процессы, обеспечивающие своевременное завершением проекта. Управление сроками по PMI включает в себя шесть процессов, пять из которых касаются планирования сроков. Однако в большинстве случаев результатом планирования сроков является расписание, то есть календарно-сетевой график проекта. Поэтому многие компании рассматривают процесс планирования сроков проекта как единый процесс, не разбивая его на подпроцессы. В нашем курсе мы будем рассматривать процесс планирования сроков как единый процесс с учетом входов, выходов и инструментов по всем пяти процессам PMI. 6.1. Планирование сроков Планирование сроков (табл. 6.1) включает в себя следующие процессы:
Так как в реальности все эти процессы происходят одновременно, причем для их выполнения чаще всего используется информационная система, мы будем рассматривать процессы как единое целое и в одном разделе. Таблица 6.1.Планирование сроков
Итогом выполнения всех процессов является Расписание проекта (которое в России из-за неудачного перевода PMI чаще всего называют Графиком работ проекта ). Пример графика проекта (рис. 6.1 ). Пример сетевой диаграммы (рис. 6.2 ). Пример диаграммы контрольных точек (отображены только вехи проекта) (рис. 6.3 ). | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||