Группа процессов планирования на ранней стадии проекта предоставляет план какой группе процессов

Обновлено: 17.05.2024

Группа процессов инициации состоит из процессов, которые выполняются для определения нового проекта или новой фазы существующего проекта путем получения разрешения для начала проекта или фазы. В рамках процессов инициации определяются изначальные цели и содержание и фиксируются изначальные финансовые ресурсы. Определяются внутренние и внешние заинтересованные стороны проекта, которые будут взаимодействовать и влиять на общий результат проекта. Выбирается менеджер проекта, если он еще не назначен. Данная информация закрепляется в Уставе проекта и в Реестре заинтересованных сторон проекта. После утверждения Устава проекта считается, что проект официально авторизован. Хотя команда управления проектом может оказывать помощь в написании Устава проекта, утверждение и финансирование происходит за рамками проекта .

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

Вовлечение заказчиков и прочих заинтересованных сторон проекта в процессы инициации повышает вероятность разделяемой ответственности, приемки результатов, а также удовлетворения заказчиков и других заинтересованных сторон проекта.

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

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

Разработка устава проекта

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

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

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

Группа процессов планирования

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

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

Команда проекта должна способствовать вовлечению всех необходимых заинтересованных сторон в планирование проекта и разработку плана управления проектом и документов проекта. Так как процесс получения обратной связи и уточнения не может длиться неопределенно долго, установленные организацией процедуры диктуют, когда должны закончиться первоначальные работы по планированию. На данные процедуры влияет характер проекта, установленные границы проекта, соответствующие действия по мониторингу и управлению, а также внешняя среда, в которой реализуется проект.

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

План управления проектом и документы проекта, разрабатываемые как выходы группы процессов планирования, описывают все аспекты:

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

Определение бюджета – процесс консолидации оценок стоимости отдельных операций или пакетов работ для создания утвержденного базового плана по стоимости.

Планирование качества – процесс определения требований и/или стандартов качества для проекта и продукта, а также документирования того, каким образом проект будет демонстрировать соответствие требованиям и/или стандартам качества.

Разработка плана управления человеческими ресурсами – процесс определения и документирования проектных ролей, ответственностей, требуемых навыков и отношений отчетности, а также создания плана управления обеспечением персоналом.

Планирование коммуникаций – процесс выявления потребностей заинтересованных сторон проекта в информации и определения подхода к коммуникациям.

Планирование управления рисками – процесс определения того, каким образом будет осуществляться управление рисками проекта.

Идентификация рисков – процесс определения того, какие риски могут повлиять на проект, и документирования их характеристик.

Качественный анализ рисков – процесс расстановки приоритетов рисков для их дальнейшего анализа или действий, путем оценки и сопоставления их последствий и вероятностей возникновения.

Количественный анализ рисков – процесс проведения численного анализа влияния выявленных рисков на цели проекта в целом.

Планирование реагирования на риски – процесс разработки вариантов и действий для расширения возможностей и снижения угроз для целей проекта.

Планирование закупок – процесс документирования решений в отношении закупок для проекта, определения подхода и идентификации потенциальных продавцов.

Группа процессов исполнения

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

Во время исполнения проекта может потребоваться внесение изменений в план и принятие нового базового плана. Это могут быть изменения в длительности операции, изменения в производительности и доступности ресурсов и непредвиденные риски. Такие изменения могут повлиять на план управления проектом или проектные документы, а также могут потребовать детального анализа и разработки соответствующего управленческого реагирования. Результаты анализа могут привести к запросам на изменения, которые, в случае их утверждения, могут вызвать изменение плана управления проектом или прочих документов проекта и, возможно, потребуют создания новых базовых планов. На осуществление процессов группы процессов исполнения затрачивается большая часть бюджета проекта. Группа процессов исполнения включает в себя следующие процессы:

· Руководство и управление исполнением проекта

· набор команды проекта

· Развитие команды проекта

· управление командой проекта

· управление ожиданиями заинтересованных сторон

Руководство и управление исполнением проекта – процесс исполнения работ, определенных в плане управления проектом, для достижения целей проекта.

Подтверждение качества – процесс проверки требований качества и результатов измерений в процессе контроля качества для подтверждения использования соответствующих стандартов качества и рабочих инструкций.

Набор команды проекта – процесс подтверждения наличия человеческих ресурсов и набора команды, необходимой для выполнения заданий проекта.

Развитие команды проекта – процесс совершенствования компетенций, взаимодействия членов команды и общих условий работы команды для улучшения исполнения проекта.

Управление командой проекта – процесс отслеживания деятельности членов команды, обеспечения обратной связи, решения проблем и управления изменениями с целью оптимизации исполнения проекта.

Распространение информации – процесс предоставления необходимой информации заинтересованным сторонам проекта в соответствии с планом.

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

Проектный менеджмент осуществляется посредством реализации процессов с использованием понятий (концептов) и компетенций, описанных в 3.1-3.11. Каждый процесс представляет собой совокупность взаимосвязанных действий и задач. Процессы проектного менеджмента делятся на три основных типа:

- процессы проектного менеджмента, присущие только проектному менеджменту и определяющие, как должны управляться работы проекта;

- процессы создания продукта, которые не являются уникальными для проектного менеджмента и направлены на определение требований и создание конкретного продукта, услуги или результата. Состав таких процессов зависит от того, каковы конкретные желаемые результаты;

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

Настоящий стандарт описывает только процессы проектного менеджмента. При этом следует отметить, что на протяжении жизненного цикла проекта процессы, ориентированные на продукт, и поддерживающие процессы зачастую перекрываются и взаимодействуют с процессами проектного менеджмента.

4 Процессы проектного менеджмента

4.1 Применение процессов проектного менеджмента

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

Руководителям проектов и другим заинтересованным лицам рекомендуется внимательно изучить процессы, описанные в подразделе 4.3 настоящего стандарта, и применять их должным образом для реализации потребностей проектов и организаций.

Описанные в подразделе 4.3 процессы не должны применяться без изменений ко всем проектам или фазам жизненного цикла проекта. Руководитель должен корректировать состав процессов управления конкретным проектом или фазой, отбирая подходящие процессы и условия их реализации. Такая адаптация должна выполняться в соответствии с существующими политиками организации.

- выбрать из перечня, представленного в подразделе 4.3, те процессы, которые необходимы для достижения целей проекта;

- использовать определенный подход к формированию и изменению требований к продукту проекта и планов для достижения целей проекта и удовлетворения предъявляемых к проекту требований;

- определить границы содержания проекта и управлять им в пределах, определяемых ограничениями, для получения результатов проекта, учитывая риски проекта и потребности в ресурсах;

- обеспечивать исполнение обязательств всеми участниками проекта, включая заказчика и куратора проекта.

Настоящий стандарт описывает суть процессов проектного менеджмента в контексте целей, которым они служат, интеграции процессов, взаимодействия в рамках процессов, основных входов и выходов. Ради краткости в данном стандарте не приведены источники всех основных исходных данных и назначение основных выходных данных.

4.2 Управленческие и предметные группы процессов

Процессы проектного менеджмента можно классифицировать двумя способами, как принадлежащие к определенным группам процессов с точки зрения проектного менеджмента (см. 4.2.2) или к группам, построенным на принадлежности к определенному предмету управления (см. 4.2.3). Оба подхода отражены в таблице 1. Описание отдельных процессов приведено в подразделе 4.3. Процесс отображается в составе той управленческой и предметной группы, к которой относится основная часть связанной с процессом деятельности.

Процессы управления проектами

Проект — это совместные действия людей и организаций с целью реализации определенной идеи. На момент старта проекта сложно очертить границы этих действий, в процессе реализации могут произойти изменения.

Проект в целом предполагает, что есть что-то неоднозначное, что должно быть по ходу проекта выяснено и реализовано.

Яркий пример такой неоднозначности — строительство домов по типовому проекту. То, как предположительно будут выглядеть здания — это идея, и на ее основании можно сформировать образ результата: к примеру, наша цель — построить три одинаковых дома в разных районах города. Но на деле они одинаковыми будут разве что визуально — и то, могут и не быть. Потому что в процессе стройки первого возникли юридические нюансы, которые изменили ход строительства, а второй вообще пришлось сделать не шестнадцатиэтажным, а девятиэтажным по причинам, которые заранее не получилось учесть.

Также признаком проекта является ограничение по срокам и по бюджету.

Снова на примере строительства: неважно, десять домов или два нужно построить в рамках проекта — когда-то он закончится. А вот если строительная корпорация постоянно что-то строит, то ее работа — не проект, а операционная деятельность: по поиску клиентов, запуску проектирования, строительству, сдаче объектов. Одно здание или жилой комплекс будут проектами, а общая деятельность организации — нет.

Если рассуждать глубже, то проект — это еще и про выстраивание отношений между заказчиком и исполнителем.

Отношения могут быть юридические, бухгалтерские, просто человеческие и любые другие, которые могут быть в обществе.

Что такое управление проектом

Например, вы за рулем автомобиля едете из точки А, чтобы достичь результата — доехать в точку Б: это деятельность. Увидели яму на дороге — повернули руль и объехали её — это управление: вы активно повлияли на процесс. Едете дальше — видите, что мост через реку разрушен или закрыт для проезда. В зависимости от ситуации вы будете принимать решение: либо искать объезд, либо переезжать реку вброд, что тоже будет активным влиянием на процесс.

Если руководитель проекта не оказывает активного влияния на процессы, значит, он не не управляет.

Роли в проекте

Следует различать три основные группы ролей:

Участники проекта

Заказчик — тот, кому принадлежит идея
Исполнитель — тот, кому предстоит реализовать эту идею

В микробизнесе одна из сложностей — постоянный недостаток ресурсов: людей, компетенций, денег, которая мешает мыслить большими масштабами. Руководителю в этих условиях приходится исполнять множество ролей: одновременно быть и заказчиком, и исполнителем, и консультантом, и экспертом. Чтобы не впадать в крайности и не выгорать, нужно уметь разделять эти роли и в голове, и на бумаге: на сегодня моя цель переговорить с клиентом — я исполнитель, завтра я буду ставить цели команде — я руководитель проекта, послезавтра мне нужно подготовить коммерческие предложения и презентации — я сейл-менеджер. Иначе есть опасность свалиться в какую-то из крайностей и на выходе стать либо отвратительным заказчиком с отрицательной славой, либо исполнителем, с которым никто не хочет работать.

Группа управления проектом

Руководитель проекта
Администратор проекта

Что делает руководитель, мы выяснили. А администратор проекта координирует взаимоотношения внутри команды и с клиентом: фиксирует и оформляет договоренности, уведомляет о совещаниях, рассылает протоколы встреч, ведет энциклопедию информационных материалов. Этим также может заниматься руководитель, но как правило эти обязанности делегируют отдельному человеку. В микробизнесе и стартапах часто эти функции берут на себя друзья, родственники, знакомые владельца, либо он сам.

Группа реализации проекта

Если у вас небольшая команда и планируется, что каждый будет закрывать собой несколько ролей — составляйте ролевую матрицу. Сформулируйте детальный план работ, понимание задач и укажите, кто какую роль, в какой области и в какой период проекта исполняет.

Необходимые компетенции для управления проектами

Организационно-управленческие навыки

Организационные навыки — это администрирование, о котором говорили выше.

Управленческие навыки — это умение анализировать данные, события и ситуации, предвидеть развитие ситуаций и возможное их влияние на смежные процессы. Исходя из этой информации принимать решение о дальнейших своих действиях.

Юридические знания

Без знаний о договорной работе руководителю будет сложно управлять проектом. Надо понимать, как оформлять результаты, как их передавать и фиксировать передачу, как подтвердить, что клиент принял результаты. Также эти аспекты перекликаются с финансовой и бухгалтерской частью, налоговой отчетностью. Если в этом не разбираться, есть риск попасть на штрафы от налоговой или от клиента.

Задачи и цели проектного менеджмента

Зачем управлять проектами

Проведем аналогию: а что будет, если сидеть за рулем автомобиля и не управлять им? Рано или поздно произойдет ДТП. Однозначно, как говорили в начале — нужно ваше активное воздействие.

Разница между стандартами и методологиями

Проектный менеджмент строится на комбинации стандартов и методологий.

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

Например, некоторые нормативы поведения в обществе четко сформулированы в Административном кодексе: не оскорбляй других, не садись за руль без прав, выключай громкую музыку после 11 вечера. Будешь так делать — молодец. Не будешь — скорее всего, понесешь ответственность. А еще есть внутренние общечеловеческие нормы, которые ничем не регламентированы, но при этом мы ведем себя именно так, а не иначе: здороваемся при встрече, потому что это элементарная вежливость, аплодируем актерам в театре с целью выразить свою симпатию к происходящему и сделать людям приятно.

Методология — это набор правил и подходов к организации деятельности. То есть, это то, что мы должны делать, чтобы исполнить требования, описанные в стандарте.

На примере того же Административного кодекса: норма — не садиться за руль, не имея при себе водительское удостоверение. Чтобы это сделать, нужно не забыть взять его с собой. А если такого документа нет — поступить в автошколу, получить необходимые знания, сдать теоретический экзамен и вождение, и стать счастливым обладателем прав управления автомобилем.

Группы процессов

Выделяют следующие группы процессов управления проектами:

Инициация

На этом этапе происходит первая встреча, цель которой — договориться об основных правилах сотрудничества на проекте, кто за что отвечает, как взаимодействуют между собой, как согласовывают изменения. Важно составлять протокол этой встречи, чтобы синхронизировать свое видение и видение клиента на будущие процессы.

Планирование

Проектный менеджмент невозможен без планирования.

Процесс планирования делится на три этапа:

Этап базового планирования — определение состава работ и фаз проекта.

Этап детального планирования — формирование конкретных требований к тому, какие действия должны быть выполнены в рамках каждой фазы проекта.

Итог планирования — детализированный план-график выполнения работ с привязанными к ним исполнителями и датами завершения. На его основании формируются ресурсный план и бюджетный план исполнения проекта.

В микробизнесе есть скрытый подводный камень. Так как владелец — и заказчик, и исполнитель одновременно, его мозг начинает смешивать разные моменты, особенно те, которые связаны с планированием. Человек считает, что помнит и знает о договоренностях. Но в условиях быстрого переключения с одной задачи на другую границы между ними стираются. Чтобы такого не происходило, организовывайте свои задачи по категориям в рамках рабочего дня. Например, если сели за ноутбук с целью сделать презентацию — не переключайтесь на разработку технической документации, дойдите хотя бы до промежуточного результата, дайте себе отдохнуть минут 15, и только потом беритесь за новое. Так вы повысите личную эффективность и не будете выгорать.

Исполнение и контроль

Исполнение — это запланированные работы, которые выполняются в настоящий момент.

Контроль — это процесс проверки с целью соответствия планируемого и фактического. Но важно понимать, что можно проверить только результат, а не процесс.

Например, я вижу, что рабочий копает яму и знаю, что перед ним стоит цель копать. Это хорошо, но что это мне дает? Сколько он должен был выкопать? Он вчера должен был закончить или позавчера? Это результат, который реально проверить. Он копает яму такого-то глубины, длины, ширины и должен выкопать её за три дня.

Анализ

Анализ — это исследовательский процесс, результатом которого становится ваше видение, как будут развиваться те или иные события на проекте. Для формирования такого видения нужен какой-то пул данных и понимание зависимостей — как одни данные связаны с другими.

Например, за данные берем поведенческие мотивы членов команды: взаимоотношения, ответственность, пунктуальность. Проанализировав эти данные и взаимосвязи, можно предположить их влияние на процессы и результаты.

Управление

Самые важные стадии процесса управления проектами:

Завершение

В процессе завершения проекта ваша главная цель — подтвердить, что вы его завершили. Но если на этапе инициации и планирования вы не обозначили, что будет окончанием проекта, будь то реализация технической составляющей системы, демонстрация результата клиенту, подписанные акты — завершения не произойдет. Выполнили сформулированные на старте требования → отчитались с предоставлением необходимой документации → клиент согласен и подписал документы → больше ничего делать не нужно, проект завершен.

Все процессы управления на разных этапах жизненного цикла проекта пересекаются друг с другом с большей или меньшей интенсивностью:

Стадии планирования управления проектами

Независимо от того, сколько у вас людей в команде, управление подразумевает, что вы знаете, что и к какому сроку вы хотите получить в виде результата. Потому что в противном случае вы не можете влиять на процессы, управлять. А понимание, что и к какому сроку надо сделать, формируется от плана действий.

Управление начинается в момент формирования понимания результата проекта, его границ, состава работ, которые надо сделать — сначала мысленно, затем на бумаге. Исходя из этого понимания нужно определить роли, участие которых потребуется на проекте.

Соответственно, действия по управлению должны строиться так:

Взаимосвязи процессов

Цель любого процесса — прийти к результату. Договоритесь с заказчиком об общих принципах измерения результатов и зафиксируйте эти принципы документально — в виде приложений к договору, дополнительных соглашений. Тогда вы сможете отслеживать взаимосвязи и возможность перехода к следующей группе процессов, а также понимать заранее, на каком из этапов назревает кризис.

Какие проблемы могут возникнуть в процессе исполнения проекта

Есть две основные причины проблем в проектах:

Для профилактики второй ситуации определяйте взаимосвязи в проекте: какая цель перед нами стоит, кто за что отвечает, кто с кем договаривается, когда должен быть результат действий, и на основании этого анализируйте, вписываетесь вы в свои ожидания или нет. Когда оцениваете бюджет, объем работ и сроки — перестраховывайтесь и закладывайте 10-15% ресурсов на переработки.

Чем отличаются цель проекта и цель конечного продукта проекта

Проект — это комплексный результат. В случае разработки программного обеспечения — это готовый софт, законченная информационная система. Законченная — означает, что ей пользуются. Если ей не пользуются — значит, цель проекта не достигнута. Продукты — это отдельные функциональные блоки, которые могут функционировать самостоятельно. За счет совместного функционирования нескольких продуктов реализуется конечная цель проекта. При планировании проекта продукты включают в документацию как отдельные блоки, которые можно проверить, принять работу и выплатить за неё деньги.

На примере строительства: весь дом и прилегающая к нему территория — это проект. А детская площадка возле него — продукт, так как она может функционировать вне зависимости от того, готова основная постройка к сдаче в эксплуатацию или нет.

Инструменты проектного менеджмента

Используйте любые инструменты и ресурсы, которые вам нравятся по функционалу и позволяют сделать единое информационное поле для взаимодействия с клиентом.

Онлайн-сервисы максимально к этому приближены, поэтому используйте Google Диск или Яндекс.Диск для обмена документами и другой информацией.

Если планируете расширяться, то рекомендую Confluence — это отличная система для выстраивания командной работы.

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

Сущность проектного планирования

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

содержания;
сроков;
стоимости;
персонала;
поставок;
коммуникаций;
рисков и т.п.

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

Уточнить, детализировать цели и результаты мероприятия.
Определить состав и объем работ.
Оценить сроки и бюджетную стоимость.
Составить календарный план и бюджет основных фаз или всего проекта.
Произвести уточненную оценку потребностей в ресурсах на каждой фазе или для всей задачи.
Составить план ресурсного обеспечения.
Выполнить оценку рисков и создать план реагирования на них.
Разъяснить детали мероприятия заказчику.
Согласовать план с основными участниками.
Распределить ответственность за работы и задачи между участниками.
Утвердить сводный план.
Уточнить планы взаимодействия, процедуры управления планированием.

Место процессов планирования среди других процессов проектной реализации. Источник: Руководство PMBOK 5

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

Укрупненный состав процессов планирования

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

Планирование мероприятия включает в себя две группы процессов: процессы непосредственной разработки планов и вспомогательные процедуры. Результатом блока разработки является документ, именуемый сводным планом проекта. В его состав входят календарный план, бюджет мероприятия и ряд других документов. Состав и содержание работ, потребные ресурсы для их выполнения определяют последовательность, продолжительность и размер затрат на их производство.

Планирование возможных рисков (выявление, идентификация и оценка) и управление ими влияют не только на разработку календарного плана, но и на бюджетные потребности. Уточнение целей, определение границ уникальной задачи и структурирование команды и ответственности закладывают основы для полноценной работы по планированию проекта. Далее вашему вниманию предлагается модель связей основных процедур рассматриваемых процессов.

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

планы управления параметрами проекта;
базовые планы по содержанию, по стоимости, а также расписание;
обновления плана.

Этапы разработки календарного плана

Этап определения и написания состава работ списком. Достаточно часто допускаются ошибки из-за того, что все работы сразу представить не получается. Для качественного определения состава операций полезно использовать основы метода последовательной декомпозиции работ.
Этап определения исполнения проекта с точки зрения последовательности и длительности работ, которые зависят от технологии их выполнения. Для создания качественного результата данного этапа хорошо подходит уже названный метод последовательной декомпозиции задач и экспертная оценка продолжительности работ с использованием таких методов, как, например, метод мозгового штурма.
Определение доступности ресурсов. В мероприятии используются разнообразные ресурсы: финансовые, материальные, трудовые, информационные и т.п. С позиции денежных ресурсов требуется увязать график работ с графиком финансирования. Вводится понятие дефицитных ресурсов: уникальных специалистов и мощностей. Это накладывает отпечаток на последовательность и продолжительность работ.
Определение внешних ограничений. К этим ограничениям относятся сезонность, технологические процессы поставок оборудования, различные внешние события. Если взять во внимание пример особых пожеланий заказчика (по конкретным партнерам) или внешних событий (например, приуроченность завершения этапа к моменту национального праздника), то подобные события включают в мероприятие в виде вех.
Этап создания плана реагирования на риски. Мы анализируем риски проекта и для основных угроз разрабатываем план реагирования. С учетом этого плана мы затем дорабатываем календарный план.

Третий и четвертый этапы относятся к позициям ограничений, пятый этап – к рискам. Две основы реагирования (активная и пассивная) определяют момент решения и включения его в проектный план. Активное реагирование подразумевает, что мы в календарный план включаем дополнительные работы, направленные на минимизацию рисков. Это может повлиять на сроки выполнения других работ.

Как пример мы можем рассмотреть проект вывода на рынок новой услуги. Допустим, выявлен риск ее невостребованности на рынке. Тогда для минимизации данного риска необходимо провести дополнительное исследование, и эту работу приходится включать в календарный план. Пассивное реагирование подразумевает формирование дополнительных финансовых резервов под выявленные риски. Этапы разработки календарного плана могут быть представлены также и в логической последовательности, представленной далее.

Основные действия по планированию проекта

Для создания сводного плана менеджер проекта реализует серию планировочных итераций. В ходе выполнения процессов планирования формируются важные инструментальные и итоговые документы, которые в совокупности и составляют сводный план. Среди них:

иерархическая структура работ (ИСР);
сетевая диаграмма;
план управления качеством;
расписание проекта;
бюджет;
организационная диаграмма;
реестр рисков;
коммуникационный план;
сводный план проекта.

Читайте также: