ГЛАВА 1. ПРОЦЕССЫ УПРАВЛЕНИЯ СОДЕРЖАНИЕМ ПРОЕКТА
1.1 Управление содержанием проекта
Управление содержанием проекта – область знаний управления проектом, что включает процессы определения необходимых объемов работ проекта, планирование их выполнения, управление изменениями в объемах и работах.
Процессы, что используются при управлении содержанием проекта и вспомогательные инструменты могут различаться в зависимости от сферы реализации проекта. Утвержденное содержание проекта и иерархическая структура работ являются базовым планом проекта, куда могут вноситься изменения, проводится отслеживание выполнения работ.
Управление содержанием проекта включает в себя процессы, необходимые для подтверждения того, что проект включает все виды деятельности и только те из них, которые необходимы для успешного завершения проекта. Основная задача – определение и проверка того, что включено или не включено в проект.
Управление содержанием проекта описывает действия, необходимые для четкого определения, что именно должно быть сделано в ходе выполнения проекта, что выходит за рамки проекта.
В самом общем виде методология проектного менеджмента определяет и формализует процедуры, методы и инструменты реализации пяти групп управленческих процессов (согласно стандарту PMBOK Guide):
• Инициации проекта
• Планирования
• Организации исполнения;
• Контроля исполнения;
• Завершения проекта.
Группы процессов управления проектами
(согласно стандарту PMBOK Guide 3-d Edition)
Инициация проекта – процесс управления проектом, результатом которого является авторизация и санкционирование начала проекта или очередной фазы его жизненного цикла.
Инициация проекта может включать следующие процедуры:
• Разработка концепции проекта:
o Анализ проблемы и потребности в проекте;
o Сбор исходных данных;
o Определение целей и задач проекта;
o Рассмотрение альтернативных вариантов проекта.
• Рассмотрение и утверждение концепции.
• Принятие решения о начале проекта:
o Определение и назначение менеджера проекта;
o Принятие решения об обеспечении ресурсами выполнения первой фазы проекта.
Планирование проекта – непрерывный процесс, направленный на определение и согласование наилучшего способа действий для достижения поставленных целей проекта с учетом всех факторов его реализации.
Основным результатом этого этапа является План проекта. Однако, процесс планирования не завершается разработкой и утверждением первоначального плана проекта. В ходе осуществления проекта могут происходить изменения как внутри проекта, так и во внешнем окружении, которые требуют уточнения планов, а часто значительного перепланирования. Поэтому процессы планирования могут осуществляться на протяжении всего жизненного цикла проекта, начиная с предварительного укрупненного плана в составе концепции проекта, и заканчивая детальным планом работ завершающей фазы проекта.
Планирование – комплексная, многокритериальная функция, предполагающая рассмотрение, анализ и прогнозирование нескольких функциональных областей проекта. Планирование проекта может включать следующие процедуры:
• Планирование целей и содержания проекта
• Календарное планирование работ проекта
• Планирование затрат и финансирования проекта
• Планирование качества
• Организационное планирование
• Планирование коммуникаций
• Планирование управления рисками
• Планирование контрактов
• Разработку сводного плана проекта.
При этом очень важно не забывать, что по ходу реализации проекта, происходит уточнение и более четкая детализация планов, а также возможно перепланирование проекта.
Организация исполнения проекта – процесс обеспечения реализации плана проекта путем организации выполнения включенных в него работ и координации исполнителей.
Организация исполнения проекта может включать следующие процедуры:
• Распределение функциональных обязанностей и ответственности
• Постановку системы отчетности
• Организацию контроля выполнения расписания проекта
• Организацию контроля затрат по проекту
• Организацию контроля качества
• Оперативное управление мерами по снижению и предотвращению рисков
• Управление командой проекта
• Распределение информации в проекте
• Подготовку и заключение контрактов
• Управление изменениями в проекте
В ходе процессов организации исполнения менеджеру проекта сильно потребуются лидерские навыки, умение решать проблемы и разрешать конфликты.
Контроль исполнения проекта - процесс сравнения показателей плановых и фактических показателей выполнения проекта, анализ отклонений и их причин, оценка возможных альтернатив и принятие, в случае необходимости, решений о корректирующих действиях для ликвидации нежелательных отклонений.
Контроль проекта может включать следующие процедуры:
• Сбор отчетности о ходе работ по проекту
• Анализ текущего состояния проекта относительно основных базовых показателей (результаты, стоимость, время)
• Прогнозирование достижения целей проекта
• Подготовку и анализ последствий корректирующих воздействий
• Принятие решений о воздействиях и изменениях
Завершение проекта – процесс формального окончания работ и закрытия всего проекта.
Завершение проекта может включать следующие процедуры:
• Сдача результатов проекта Заказчику;
• Заключительная оценка финансовой ситуации (постпроектный отчет);
• Заключительный отчет по проекту и проектная документация;
• Список открытых вопросов и заключительных работ;
• Разрешение всех спорных вопросов
• Роспуск команды проекта
• Документирование и анализ опыта выполнения данного проекта.
В рамках данных процессов производится архивация основных управленческих и содержательных проектных документов для последующего использования при реализации других проектов.
1.2 Иерархические структуры работ проекта
Структуры работ проекта — иерархические декомпозиции проекта на составные части (элементы, модули), необходимые и достаточные для эффективного осуществления процесса управления проектом в интересах различных его участников.
Понимание проекта как структурированного (информационного) объекта, подчиняющегося логическим суждениям и формальным правилам, является основой профессиональных методов управления проектом. Для выявления и осознания целей, состава и содержания проекта, организации планирования и контроля процессов осуществления проектов необходимо определить и построить структуру работ проекта, используя методы декомпозиции.
Рисунок 1.1 Пример ИСР по проекту
Для этого весь проект делится на компоненты или хозяйственные программы, определяющие подразделы и отдельные группы работ. Эта процедура известна как составление дерева работ проекта (WBS – Work Breakdown Structure) [5].
Иерархическая структура работ (далее ИСР) — это разбиение вашего проекта на более мелкие и измеримые части. ИСР описывает все результаты/работы, которые должны быть получены/выполнены для завершения проекта. Все, что не вошло в ИСР в рамки проекта не входит [6].
Структурная декомпозиция работ проекта (СДР) является графическим воплощением проекта и представляет собой совокупность взаимосвязанных элементов проекта различной степени детализации.
Структурная декомпозиция работ проекта является центральным инструментом определения работ, которые должны выполняться в рамках проекта. Описание работ (пакетов работ) должно включать: содержание работ, предполагаемые результаты, возможность измерения и оценки степени их выполнения. Чаще всего используется два вида СДР:
Декомпозиция по функциональному принципу (продукту проекта и его составляющим). Ниже в качестве примера приведена декомпозиция проекта по системной интеграции. Основным продуктом проекта является информационная система, включающая в себя промежуточные продукты: локальную сеть, рабочие станции и сервера, СУБД, системное и прикладное программное обеспечение.
Декомпозиция по хронологическому принципу (жизненному циклу проекта).
При управлении проектом на протяжении его жизненного цикла используются и другие структурные модели проекта, основой большинства которых является СДР. Наиболее существенными из них являются:
Дерево целей и результатов — первая по времени разработки структурная модель декомпозиции цели проекта на составные части. Дерево целей можно построить в соответствии со структурой проекта. В вершине дерева ставится общая (генеральная) цель, на последующих ярусах ветвей располагаются в иерархической соподчиненности декомпозированные цели соответствующего уровня, вплоть до целей самого нижнего уровня, соответствующих элементарным мероприятиям и действиям в проекте.
Дерево задач — разработка структурной модели проекта по декомпозиции задач проекта на составные части. Состав задач проекта определяется из целей проекта, конечного результата и предпроектного состояния предметной составляющей проекта — продукта, бизнес-функции или услуги. Системный подход в определении задач проекта аналогичен подходу в определении целей, используя технологии иерархических декомпозиций в виде дерева. В вершине «дерева» располагается сверхзадача проекта, в основании — элементарные задачи (работы, мероприятия) нижнего уровня. Такие методики — разбиение проекта на более мелкие задачи — позволяют представить его в виде вполне управляемых компонентов.
Одна из главных задач СДР — определение и проверка того, что включено или не включено в предметную составляющую проекта, т.е. фиксация границ проекта.
Чем детальнее в СДР отражены задачи нижнего уровня, тем выше может обеспечиваться прозрачность проекта. Проработанная в деталях и передаваемая в реальное исполнение СДР является эффективным инструментом по управлению проектом. При этом опытные менеджеры особое внимание уделяют фиксации мероприятий, передающих результаты предшествующей задачи (задач) на вход последующей (последующим), что осуществляется посредством вех, фиксирующих условия передачи результатов, достижения текущих целей и необходимые в данном случае документы. Четкое и системное определение вех в СДР обеспечивает высокое качество обратной связи в управлении проектом и контроля его исполнения, так как основная часть вех содержит требования по предоставлению отчетности по состоянию задач. Такая методика позволяет эффективно учитывать отклонения от плановых параметров задач и управлять изменениями проекта.
Основные подходы к построению структурной модели проекта:
• Структурная модель организации проекта (или проектный офис), представляющая иерархическую декомпозицию организационной и производственной структуры проекта.
• Матрица ответственности и распределения работ по исполнителям, которая строится на основе структурных моделей работ проекта и организации проекта.
• Сетевая модель проекта, или иерархическая система сетевых моделей проекта, с заданной степенью детализации работ, отвечающей требованиям различных уровней управления и участников проекта, которая строится на основе СДР, дерева целей, структуры организации проекта и матрицы ответственности.
• Дерево ресурсов — структурная декомпозиция требуемых ресурсов для выполнения проекта.
• Дерево стоимости — структурная декомпозиция стоимостных показателей проекта, которая строится на основе СДР, дерева ресурсов и данных о стоимости элементов проекта.
• Структурная декомпозиция контрактов по работам проекта.
• Дерево распределения рисков проектов.
На основе композиции различных структурных и информационных моделей можно построить и другие дополнительные композиционные структурные модели, необходимые для решения задач управления проектом различными его участниками.
Принятая структура проекта с выделенной в ней иерархией устойчивых элементов и образует основу информационного языка проекта, на котором общаются все участники проекта и ведется документирование. Поэтому принятая структура, и только она, должна использоваться на протяжении всего жизненного цикла проекта, хотя сама структура и может претерпеть изменения в ходе выполнения проекта. В этом случае должны быть внесены связанные с этим изменения во всей документации проекта.
WBS – крайне полезная вещь в планировании проекта и вот почему:
1. WBS – если не единственный, но точно самый эффективный способ наглядно отразить весь объем проекта.
2. WBS фокусирует внимание не на процессе, а на ожидаемом результате, и создает нужный «посыл».
3. В идеале в разработке WBS участвует заказчик или его представитель и вся команда, что позволяет, а) обеспечить единое понимание результатов проекта и его объема б) увидеть важность и вклад отдельных элементов в общий результат
4. С помощью WBS можно наглядно обосновать необходимости в финансах или человеческих ресурсах.
5. WBS помогает предотвратить риски и изменения или по крайней мере значительно (очень значительно!) снизить их вероятность и влияние, так как именно здесь всплывут многие неочевидные ранее вещи и «а мы хотели совсем другое» (и, так и должно быть, для этого инструмент и предназначен).
6. На уровне WBS уже можно определить и согласовать контрольные точки проекта (как для решений о продолжении проекта после очередного этапа, так и для контроля затрат человеческих и финансовых ресурсов).
Уже на этом этапе хорошо бы донести до заказчика вашу позицию «Если задач нет в WBS – их нет и в проекте». Во-первых, все постараются при разработке или при согласовании немного больше, а во-вторых – у вас появится хороший рычаг влияния на будущее.
1.3 Глоссарий проекта как важный аспект определения
содержания проекта
Очень часто, когда, вы приходите в проектную команду, которая довольно давно работает над проектом, то первое время вы чувствуете себя несколько неуютно из-за того, что люди вокруг вас говорят на каком-то особенном, языке. Они используют названия модулей, аббревиатуры каких-то определений, состояний, ситуаций, форм, ролей, документов и много еще чего, что человек несведущий сразу не поймет. Это все - глоссарий проекта. Он существует независимо от того, фиксируете вы его в документе или нет. Он появляется в первые дни работы над проектом, когда появляется первое рабочее название будущей системы, и очень активно формируется в последующие дни, во время бесед с заказчиками и обсуждений внутри команды. Фиксировать его на бумаге или нет - ваше дело. Но принято считать, что глоссарий проекта это документ , который больше нужен вам (проектной команде), чем заказчику, а потому сформировать его и поддерживать в рабочем состоянии весьма полезно.
Глоссарий входит в число необходимых документов во всех «тяжелых» методиках разработки (RUP, MSF). Но и для гибких (agile) методик, глоссарий, относится к вещам, которые лучше иметь, чем не иметь. Основополагающим принципом всех agile методик является поддержка внутри - командных коммуникаций на самом высоком уровне. Согласитесь, сложно общаться, не зная языка, а глоссарий – это и есть язык, на котором говорит команда. Для ведения глоссария вполне подходят wiki системы.
Важная функция, которую должен выполнять глоссарий, это установление соответствия между терминами заказчика (предметной области) и терминами архитектуры системы. Это особенно важно для тяжелых методик, в которых проектные роли аналитика, архитектора, разработчика и тестировщика выполняют разные люди. Типичный пример – наименования состояний объектов. На уровне требований и пользовательского интерфейса они имеют свои имена. Когда мы спускаемся на уровень дизайна и реализации - те же вещи называются по-другому. Учитывая, что требования (use cases) и дизайн (design models) описаны в разных документах возникает путаница и всякие нелепые ошибки.
Что стоит включать в глоссарий? Реально глоссарий содержит всю специфическую для проекта терминологию, используемую в своей работе проектной командой. Вероятно, не стоит фиксировать на бумаге жаргонизмы, наподобие «финики» (роль пользователя системы - финансисты), и «юрики» (то же – юристы). Не место в глоссарии названиям проектных серверов, репозиториев и прочей технической информации.
В глоссарии желательно зафиксировать:
• названия основных прецедентов использования, в форме понятной пользователю и заказчику системы, сопроводив их небольшим (не больше одного предложения) описанием. Это нужно, в первую очередь разработчикам (как ни странно)
• названия всех понятий (сущностей) предметной области (домена приложения) в форме понятной пользователям и названия соответствующих им классов (объектов, модулей), если такое соответствие существует.
• названия и значения ключевых свойств сущностей предметной области. Например, для системы обработки заказов, таким ключевым свойством может быть «стоимость заказа», с описанием из чего она состоит и как формируется.
• термины предметной области, которым не соответствуют какие либо сущности в системе, но которые важны для понимания предметной области. Например, названия бизнес операций или бизнес процессов.
• названия основных модулей и блоков системы, названия подсистем и их назначение
• названия состояний сущностей системы и соответствующие им системные названия.
• синонимы. Важно отразить, что для обозначения одного и того же понятия могут использоваться разные названия.
• роли пользователей [7].
Например, глоссарий сантехнических терминов:
Американка - Разборное соединение, используемое для соединения труб с помощью накидной гайки.
Бай-пас - Перемычка, соединяющая подающую и обратную трубы радиатора, которая позволяет пустить теплоноситель в обход отопительного прибора, перекрыв соответствующие краны.
Бочонок - Отрезок трубы с двумя короткими наружными резьбами.
Гидроаккумулятор - Сосуд, работающий под давлением, который позволяет накапливать гидравлическую энергию и возвращать её в систему в нужный момент.
Елочка - Смеситель раковинный старого образца.
Картридж - Запорно-смесительный элемент смесителя, выполненный в виде шара с отверстиями
Коллектор - Сантехнический элемент в системах отопления и водоснабжения для удобного распределения воды к конечным точкам потребления.
Лён - Используется для герметизации резьбовых соединений. Наматывается на резьбу по ходу движения, на лен наносится унипак.
Стояк - Вертикальный трубопровод водоснабжения, водяного отопления или канализации.
Утка - Два отвода, соединенные так, что оси труб смещаются друг относительно друга.
Футорка - Соединитель с переходом с внутренней резьбы на наружную большего диаметра.
ГЛАВА 2. СОДЕРЖАНИЕ ПРОЕКТА «СТРОИТЕЛЬСТВО КОТТЕДЖА»
2.1. Описание проекта «Строительства коттеджа»
В данной курсовой работе будет рассматриваться проект строительства коттеджа, стоимость и сроки, которого рассчитывали при помощи программы Microsoft Project Document.
Дата начала проекта 4 Апреля 2020 года, а завершение проекта запланировано на 26 Октября 2020 года. Длительность всего проекта составляет 147 дней, стоимость проекта 10 317 623,00 рубля. Основные этапы проекта:
1. Инициация проекта;
2. Планирование;
3. Строительство:
a) Подготовка территории, земляные работы, фундамент;
b) Стены, окна лестницы, двери;
c) Перекрытие, кровля;
d) Мансарда, отделочные работы;
e) Устройство крыльца, разные работы;
f) Электротехнические работы, отопление;
g) Сантехнические работы.
4. Завершение.
Связь между каждыми работами представлена в сетевом графике, в приложении 1.
2.2. Структура декомпозиции работ проекта (WBS)
Создание иерархической структуры работ (ИСР) – это деление крупных работ на меньшие компоненты, с целью упростить их управление. Основная выгода состоит в том, что визуально можно показать всю структуру работ и грамотно спланировать управления ими.
На рисунке 2.1 представлена схема создания иерархической структуры работ.
Рисунок 2.1. Создание ИСР
На рисунке 2.2 представлены все работы проекта: «Строительство коттеджа».
Рисунок 2.2. Все работы проекта: «Строительство коттеджа»
В соответствии со своей локальной сметой 8.7, которая представлена в приложении 2, будет рассматриваться пакет работ: Электротехнические работы, отопление.
На рисунке 2.3 представлен пакет работ: Электротехнические работы, отопление.
Рисунок 2.3. Пакет работ: Электротехнические работы, отопление.
На данном рисунке видно, что под этапом: электротехнические работы, отопление задействованы 3 работы: Канализация, Водопровод, Отопление, а также отражены дополнительные затраты.
2.3. Календарный план выполнения работ проекта (диаграмма Ганта)
Для того, чтобы отслеживать выполнения задач точно в срок используют диаграмму Ганта. Диаграмма Ганта — это способ визуально показать запланированные задачи и эффективно управлять ими. Диаграмму Ганта впервые придумал инженер из Америки Генри Гант. Основная функция диаграммы — упорядочить задачи в соответствии с их датами и приоритетами, показать какая существует между ними связь.
Разработка расписания – это процесс, при котором происходит анализ операций, длительностей, потребностей в ресурсах, ограничений. Основная выгода состоит в том, что при вводе операций, длительностей, логических связей, а также ресурсов и их доступности в инструмент, который составляет расписание создается схема расписания с запланированными датами выполнения всех операцией. На рисунке 2.4 представлена схема разработки расписания.
Рисунок 2.4. Схема разработки расписания
Календарный план выполнения работ проекта: «Строительство коттеджа» представлен на рисунке 2.5.
Рисунок 2.5. Календарный план выполнения работ проекта
На рисунке 2.5. видно, что проект на начинается 4 Апреля 2020 года, а также обозначены все работы, которые выполняются в ходе этого проекта.
2.4. Ресурсы проекта
Ресурсы проекта могут быть материальными и трудовыми, они на назнчаются на задачи и обеспечивают их выполенеие. Расчеты ресурсов проводились по смете.
Оценка ресурсов операцией – это процесс при котором оценивают ресурсы, котрые требуются для выполнения каждой операции, например: количество и тип материалов, оборудование, расходные материалы, человеческие ресурсы и т. д. Основная выгода в том, что данный процесс позволяет определить точное количество и тип требуемых ресурсов, тем самым позволяет более точно оценить их стоимость и длительность. На рисунке 16 представлена схема оценки ресурсов.
Рисунок 16. Схема оценки ресурсов
На рисунке 2.7. представлены ресурсы пакета работ: «Электротехнические работы, отопление»
Рисунок 2.7. Ресурсы пакета работ:«Электротехнические работы, отопление»
На рисунке 2.7. видно, что используются 3 трудовых ресурса и 3 материальных.
2.5. Бюджет проекта
Планирование управления стоимостью – это процесс, который устанавливает политику, процедуру, документацию для планирования, управления и контроля расходов проекта. Основная выгода в том, что процесс дает руководство и указания относительно управления стоимости проекта на протяжении всего ЖЦ проекта. На рисунке 2.8 представлена схема планирования управления стоимостью.
