Что такое этапы проекта
Изучаем этапы управления проектами
Это не только списки «сделать» и «сделано»
Просмотр тем
В жизненном цикле проекта выделяют пять этапов управления проектом: инициация, планирование, выполнение, мониторинг и завершение. При работе над сложными проектами команда может ориентироваться на эти этапы как на дорожную карту.
Познакомьтесь с Софией. Она возглавляет команду HR-специалистов в своей компании. Вместе им предстоит работа над очень крупным проектом по пересмотру всего процесса адаптации новых сотрудников.
Большинство из нас (как и София) представляют два этапа, когда думают о работе над проектом: начать проект и закончить его.
На самом деле речь идет о гораздо большем. Представьте, что вы печете торт. Нельзя наугад взять ингредиенты, свалить их в кучу и сразу получить отменный и вкусный глазированный десерт. Нужно потрудиться, чтобы закупить продукты, подготовить их и смешать. Кроме того, в процессе придется то и дело пробовать результат на вкус.
От начала и до конца вы делаете множество шагов. Это и есть этапы управления проектом. Изучив их, вы сможете точнее планировать задачи, реалистичнее оценивать сроки и подходить к работе над проектом более стратегически и организованно.
Продолжим рассказ о Софии и ее команде и на их примере посмотрим, что такое типичный жизненный цикл проекта и каковы его этапы.
Что такое жизненный цикл проекта?
Термин «жизненный цикл» напоминает об уроках биологии в старших классах. Однако у него очень простое значение. Жизненный цикл проекта — это этапы, которые проходит проект с момента создания до завершения. Вы будете выполнять поэтапные действия, превращая идею проекта в готовый к сдаче результат.
Понимание жизненного цикла управления проектами позволяет команде действовать не наугад, хватаясь за первые попавшиеся задачи, а следующим образом.
Сложите эти преимущества, и вы получите главное из них: команды смогут быстрее выполнять успешные проекты.
Если использовать концепцию жизненного цикла проекта и ее преимущества, не придется впустую тратить деньги на проекты, которые не соответствуют изначальным целям.
Кажется, все ясно. У подхода на основе жизненного цикла много достоинств. Какие же этапы необходимо пройти проекту?
Согласно своду знаний по управлению проектами (PMBOK) выделяют пять четких этапов жизненного цикла управления проектом:
Итак, вы получили общее представление о теме. Давайте углубимся в детали.
Пять этапов жизненного цикла управления проектом
Может быть непросто представить целых пять этапов, особенно если вы привыкли думать всего о двух — «начало» и «конец». Каждый этап служит определенной цели и позволяет улучшить итоговый результат.
Этапы следуют друг за другом, как буквы алфавита. Чтобы воспользоваться преимуществами подхода к управлению проектом на основе жизненного цикла, нужно действовать последовательно.
Этап 1. Инициация проекта
Процесс адаптации новых сотрудников давно необходимо было преобразовать. София и команда хотят поскорее взяться за дело. Думаете, на первом этапе нужно составить план и обозначить сроки? Не спешите.
Первый этап жизненного цикла проекта — не планирование, а инициация.
На этом этапе проект пока не подтвержден. София и ее команда должны рассмотреть его в общих чертах и оценить перспективу. Прежде всего нужно понять, стоит ли за него браться. Для этого необходимо определить следующее.
София и команда определили эти пункты следующим образом.
Все эти аспекты можно отразить на карте проекта. Команда Софии может периодически смотреть на нее, чтобы помнить о месте проекта в общей картине.
Когда команда проанализировала указанные факторы, пришло время спросить себя, осуществим ли проект и стоит ли за него браться.
Если да, команда должна получить подтверждение проекта (если необходимо) и перейти к следующему этапу. Если нет? Не стоит беспокоиться. Команде просто следует начать сначала и подумать над другими способами решения проблемы. В этом случае полезно использовать шаблон карты проекта.
Этап 2. Планирование проекта
София обдумала проект в общих чертах, и пришло время подробностей. На этом этапе ей нужно вместе с командой обсудить конкретный план действий по реализации проекта.
Даже если вам не терпится приступить к работе, не экономьте время в ущерб качеству на этапе планирования. Эффективное планирование позволяет предотвратить многие основные причины провала проекта. В их числе неадекватное видение перспективы и цель, плохо налаженная коммуникация и неточность оценок.
Ради хорошего плана придется потрудиться и потратить время, поэтому заложите достаточно времени на старте проекта.
На этом этапе София и команда ответят для себя на следующие вопросы.
Цель проекта лучше всего определять, используя систему постановки целей SMART. Система основана на принципах конкретности, измеримости, достижимости, уместности и временных рамок.
С помощью этой системы София и команда определили следующую цель своего проекта по адаптации сотрудников.
Создать новый процесс адаптации, позволяющий обучать новичков и повысить коэффициент сохранения кадров на 15 %. Новую программу нужно запустить к 25 января 2021 г.
Теперь София и команда знают, к чему стремиться. Но одних только желания и надежды мало для достижения цели. Команде нужно понять, какая именно работа их ждет.
В этом им поможет структура распределения работ (WBS). Проект разбивается на задания и отображается в графическом виде. Каждое задание является действием, которое видят все участники проекта. В нашем примере София и команда выделили следующие задания.
Когда участники команды увидят, что требуется для проекта, им будет проще понять, сколько времени и ресурсов понадобится и с чего начать.
Кроме того, они определят основных действующих лиц (в нашем случае это команда HR, веб-разработчиков, графический дизайнер и команда по контенту), а также зависимости в заданиях и ресурсах. Зависимостью является любой аспект проекта, обусловленный другим аспектом.
Вот пример зависимости заданий: нельзя опубликовать материалы на дашбоарде сотрудников, пока нет дашбоарда. Для выполнения одного задания необходимо завершить другое. Или команда веб-разработчиков не может подключиться к проекту, пока не обновит дизайн сайта компании. Необходимый ресурс недоступен по первому требованию, поскольку зависит от других задач.
Теперь команда Софии учитывает зависимости и определяет разумный порядок выполнения заданий проекта, а также сроки выполнения каждого действия в индивидуальных списках задач.
Результат их работы и есть готовый план проекта. Задокументируйте план и опубликуйте там, куда есть доступ у всей команды (отлично подойдет Confluence).
Этап 3. Выполнение проекта
На этот этап приходится основной объем работы.
Команда Софии выполнит все назначенные задания проекта. Участники будут составлять процедуры, записывать видеоролики, разговаривать с сотрудниками и т. д.
В ходе планомерного продвижения по списку задач проекта команда одновременно столкнется со следующим этапом.
Этап 4. Мониторинг проекта
Вернемся к примеру с тортом. Можно ли испечь великолепный торт, всего один раз взглянув на рецепт? Пожалуй, нет.
Скорее всего, вы сверяетесь с рецептом, когда разбиваете яйца и замешиваете масло, чтобы сделать все правильно. Каждые пять минут вы заглядываете в духовку и следите, чтобы не подгорела верхушка коржа. Вы очень внимательны во время готовки.
Работа над проектом идет примерно так же. Это и есть этап мониторинга, параллельный этапу выполнения. София будет регулярно оценивать проект, чтобы убедиться в следующем.
Если использовать ПО для управления проектами, мониторинг станет проще. Процессы будут нагляднее, а вся информация и обсуждения, связанные с проектом, будут храниться централизованно.
Кроме того, стоит регулярно проводить планерки, чтобы держать в курсе всех участников команды. Шаблон протокола еженедельного собрания упростит фиксацию обсуждаемых тем, принятых решений и действий, определенных по итогу собрания.
Если София заметит отклонение от плана, она сможет скорректировать направление по ходу работы или изменить изначальный план проекта согласно новым обстоятельствам.
Этап 5. Завершение проекта
Команда справилась! Внедрен новый улучшенный процесс адаптации новых сотрудников. Команда готова отпраздновать победу совместным чаепитием и навсегда попрощаться с проектом.
Но прежде чем сделать новую отметку в списке побед, необходимо пройти этап завершения, чтобы доработать любые шероховатости. Нужно сделать следующее.
Усердная работа над проектом заслуживает хорошего завершения. Все задания выполнены и остались позади, однако важно подвести итог, чтобы закончить этот проект и настроиться на успех следующих.
Польза ПО для управления проектами
Возможно, вы думаете, что такое ПО — неплохое, но необязательное приобретение. Подумайте хорошенько. ПО для управления проектами повышает шансы на успех и снижает уровень напряжения. 77 % самых эффективных проектов управляются с помощью такого ПО.
В чем плюсы ПО для управления жизненным циклом проекта? ПО дает следующие преимущества.
Не пытайтесь управлять жизненным циклом проекта с помощью бесконечных электронных переписок, бессистемной документации и запутанных таблиц. Используйте ПО для управления проектами, например Jira, чтобы действовать стратегически и организованно на всем пути — от озарившей вас идеи до запуска продукта.
Больше успешных проектов
Только начав проект, невозможно во мгновение ока выйти на финишную прямую. Управление проектами позволяет действовать стратегически и пройти различные этапы выполнения проекта.
Действуйте поэтапно, как София и ее команда, и вы скоро сможете поздравить друг друга с очередной победой. Пригласите коллег на чай, чтобы отпраздновать новый успех (непременно с тортом).
На этапе планирования при работе над проектом приходится много рассуждать и трудиться. Упростите этот этап с помощью шаблонов плана проекта.
Процессы PMBoK 5 за 10 минут
Oct 5, 2017 · 10 min read
Подробнее об управлении проектами в моем блоге: https://salakhmir.ru/
В начале сентября 2017 года вышла шестая редакция PMBoK (Project Management Body of Knowledge). PMBoK — свод знаний по проектному менеджменту, выпускающийся организацией PMI (Project Management Institute).
Это офигенно здоровый талмуд справок по ведению проектов, регуляр н о при том обновляющийся. Первая публикация свода вышла в 1996 году, за 20 лет — шесть редакций. В довесок к выпуску свода знаний, организация проводит сертификации проектных менеджеров. Увы, по некоторым причинам, я её пройти пока не могу. Ещё одна фентифлюшка PMI — участие в “клубе”, нафиг в жизни не нужна. Кроме легального доступа к PMBoK 6, она ничего не даст. Потому я и не могу рассказать, что там, в шестой редакции. Только что читать краткие ревью, чего там появилось нового.
Сегодня пробежимся по процессам ведения проектов пятой редакции свода и поговорим о том, что такое управление проектами в целом. Статья подготовлена под влиянием соответствующего курса на курсере.
Что такое проект
Проект — набор действий, направленных на создание уникального продукта. Последним проект отличается от “процесса” — где конечный продукт не будет уникальным. Пример: рисование картины — проект, печать тысячи копий — процесс. Сдача экзамена TOEFL — проект, но изучение английского языка — процесс. Проект также имеет стадии и ограничения. Процесс может длится бесконечно. Ограничения проекта — срок, стоимость и качество. PMBoK расширяет количество ограничений до шести: добавляются содержание, риски и удовлетворённость клиента. Как правило, ограничения взаимосвязаны: например, если сокращаются время и стоимость, высокого качества можно не ожидать (и удовлетворённости клиента тоже).
Этапы выполнения проекта
Любой проект имеет начало, выполнение и завершение. PMBoK пятой редакции выносит управление этими этапами в пять процессов: инициация, планирование, выполнение, контроль выполнения и завершение проекта.
1. Инициация
Инициация проекта, человеческим языком, это когда понятно, что есть задача и понятно, что нужно стартовать. Основных процессов внутри этого этапа два: вычисление заинтересованных лиц и составление устава проекта.
Работа с заинтересованными лицами. В крупных, сложных проектах первый этап — целая система. Заинтересованными лицами могут быть как непосредственно заказчик, так и люди, на которых “последствия” выполнения проекта повлияют напрямую. Представьте проект, в рамках которого потребуется построить детский сад внутри двора жилого дома. Вопросы, которые возникают уже при инициации проекта, решаются менеджером. Думаю, основным вопросом, который возникнет, и который будет исходить не от заказчика — нежелание местных жителей видеть у себя во дворе новую постройку.
В проектах типа разработки сайтов вести беседы с конечными пользователями, конечно, не придётся. Однако, если сайт разрабатывается для большой компании с кучей департаментов, эта таблица пригодится, для того чтобы устанавливать решающих лиц и тех, кто получить непосредственное влияние от работы по итогам сдачи проекта. Случай, когда никому ничего не нужно, и никто никакого влияния не получит — самый печальный, как бы эти вводные радужно не звучали.
Составление устава проекта. Здесь решаются вопросы с документами: руководство по ведению проекта, примерный тайм-план и техническое задание. Основной вопрос устава проекта — что решает продукт, создаваемый в процессе проекта, что должны получить на выходе (например, “на выходе нужен дом на 250 квартир”).
2. Планирование
PMI отводит большой пласт именно планированию. Большинство проблем проекта возникает из-за ошибок при планировании проекта. Посудите сами: если в начале проект спланирован так, что прописано и предусмотрено абсолютно всё — какие могут быть проблемы в будущем? Планирование проекта содержит процессы: риск-менеджмент, определение проектных задач (и их декомпиляция), расписание проекта (тайм-план), формирование команды проекта.
Управление рисками
Риск — одно из неопределённых событий, которое может произойти. Риски бывают негативными, создающими проблемы (например, в проекте по строительству автобана, разорился подрядчик), так и позитивными, которые помогают проекту. Управление рисками происходит в 4 шага.
В рамках шага “ определение” происходит анализ похожих проектов — своих и чужих, на предмет того, с какими проблемами столкнулись там. Например, конкурент делал электромобили, но разорился, потому что поставщик н-ных деталей не смог предоставить требующийся объём детали, а других поставщиков нет.
Разработка плана работы с рисками — что ты будешь делать в случае, если риск наступит?
Предупреждение рисков — что можно сделать, чтобы риск не наступил? Здесь же нам нужно оценить триггеры, по которым мы сможем оценить, что риск наступил и с ним нужно что-то делать. Это как когда у вас дома выбивает пробки, вы ищете потребитель, “кладущий” электросеть.
Характеристиками рисков являются “последствия” и “вероятность наступления”, где 1 — минимальное значение, 5 — максимальное.
Оценка рисков на старте IT-проекта. Вписав риски в таблицу и посчитав “тоталы” последствия/вероятности, мы видим, что нам стоит заняться поиском выхода на лицо, принимающее решение и поиском заменяющего программиста (если уж зачем-то подключаем программиста, который вот-вот уходит в отпуск). “Метеорит” вставил для утрированного примера, когда последствия риска максимальны, но вероятность нулевая.
Проектные задачи
Здесь берутся задачи, ставящиеся перед проектом в целом и декомпилируются на этапы, подзадачи и зависимости. Техническое задание превращается в задачи, которые требуют прямого решения. Для этого составляется ИСР — Иерархическая структура работ (WBS в оригинале).
В качестве примера иерархической структуры — проект разработки веб-сайта. Проект состоит из трёх этапов, каждый из этапов (фаз выполнения проектов) содержит или не содержит свои подэтапы, а те, в свою очередь, содержат конечные задачи. Проект декомпилируется до уровня задач, где каждая задача занимает от 4 до 40 часов работы конкретного исполнителя (рекомендуется PMBoK). В проектах наподобие разработки сайтов, задача может занимать от получаса до 16 часов — я так считаю.
Определение задач происходит так:
Детализированная иерархическая структура работ позволяет оценить реальные трудозатраты проекта. Бюджет выполнения задач рассчитывается менеджером, тогда как время выполнения задачи лучше узнать у исполнителя, либо взять из предыдущего опыта решения подобной задачи, если таковой был.
Планирование и расписание
Помимо иерархической структуры есть ещё одна, интереснее: структура взаимосвязей и зависимостей задач проекта. Такая структура позволяет понять, что за чем следует, моделировать ход проекта.
Структура взаимосвязей может составляться на основе верхних уровней иерархической структуры. На примере разработки сайта, взаимосвязи линейны и выглядят так: дизайн => вёрстка => программирование. В случае проекта той же постройки детского сада, количество взаимосвязей стремится к бесконечности, их следует учитывать.
По поводу маршрута хода проекта (ака сетевой трафик) в PMBoK есть несколько инструментов — Float Time и Critical Time. Я их [пока] не использую, а желающие могут почитать об этом в интернете. Пример структуры — диаграмма PERT.
Тайм-план проекта
Тайм-план, это план того, когда и что должно быть сделано. Наибольшую популярность в этом плане обрела диаграмма Гантта. По сути, это универсальный инструмент: помимо таймингов, на диаграмме можно показать этапы проекта и критические подзадачи вместе с их взаимосвязями.
Для того, чтобы составить тайм-план в виде диаграммы Гантта, нужно:
На тайм-плане отмечаются майлстоуны — этапы с нулевой продолжительностью, вехи проекта. Например, “сдача дизайна” или “запуск сайта”. Это задачи, которые требуют выполнения, но сам момент выполнения может быть отмечен в качестве значимой точки проекта.
Диаграмма Гантта ещё тем хороша, что легко составляется — её можно хоть от руки рисовать. На компьютере её можно создать в Ms Project или Ms Excel. Я воспользовался сервисом draw.io — рекомендую.
Если базовая линия проекта изменилась и планирование посыпалось, PMBoK предлагает нам два инструмента в помощь в борьбе с проблемой: “Crashing the Project” и “Fast Tracking”. Альтернативные пути, подходящие нам и помогающие оставаться в рамках изначального тайм-плана — это уменьшение содержания проекта и уменьшение качества — время здесь равняется бюджету.
Управление командой проекта (Project Leadership)
Конечные исполнители проекта — самое важное звено при создании конечного продукта. Команда проекта — люди, которые занимаются непосредственно работой над созданием продукта. Члены команды должны иметь опыт и квалификацию в требующемся направлении.
Формирование команды проекта может происходить двумя путями:
Например, в диджитал-разработке это может выглядеть так: в компании есть дизайнеры, есть веб-программисты. У каждой из групп специалистов есть свой тим-лид — арт-директор у дизайнеров и тех.директор у программистов. Приходит заявка на разработку мобильного приложения. В таком случае, мы “нанимаем” дизайнера и веб-программиста у тим-лидов, а мобильного разработчика нанимаем из вне на время создания проекта — например, фрилансера.
После набора в команду проекта требующихся специалистов, требуется провести знакомство членов команды проекта (особенно, если часть их привлечена к проекту из вне). Знакомство команды с проектом состоит из четырёх фаз:
В случае крупных проектов может потребоваться процесс “распределение задач”. Например, если наш проект — это веб-разработка, и у нас 10 программистов и 5 верстальщиков. Распределение происходит путём поиска ответов на вопросы:
Под “может” подразумевается квалификация и навыки исполнителя. Под “выполнит” — будет ли он её делать. “Будет ли доступен” — в том случае, если команда собирается сразу, а этап работы этого специалиста произойдёт через месяц. Подразумевается, что члены рабочей группы проекта не сидят на одном месте вокруг одного проекта, что до старта проекта у него были другие задачи (проектные или нет), также могут быть задачи во время хода проекта (во время, когда он не вовлёчен в работу).
По PMBoK применяется таблица RAM — в ней обозначаются номинальные роли участников проекта. Эта тема больше про отчётность и понимание того, к кому когда обращаться. Не думаю, что есть смысл её вести, если участников проекта меньше 20 человек и каждый выполняет одну-две функции.
Менеджеру не стоит забывать, что он тоже член рабочей команды, к менеджеру проекта применимы те же вопросы и процессы. На этом этапе менеджер планирует себя, как ресурс, предполагает изменения ролей и личный тайм-менеджмент.
А вот ещё чуток про human resources и выбор исполнителя под проект, чек-лист вопросов по оценке возможностей.
Каждый участник рабочей команды — личность с собственными потребностями, желаниями и слабостями.
3. Выполнение проекта
Основной этап проекта, когда работа работается, результаты согласовываются и передаются от специалиста специалисту дорабатываясь. Задачи менеджера проектов на этом этапе — ведение коммуникации и слежение за треугольником время-бюджет-качество. Контроль и наблюдение за проектом выносится в отдельный процесс.
Причины быть “быстрее и дешевле”
Основной инструмент менеджера — коммуникация. На этом этапе составляется коммуникационный план. Опять же, вижу смысл его составлять и вести в том случае, если много исполнителей и стейкхолдеров.
4. Наблюдение и контроль выполнения проекта
В группе процессов контроля выполнения проекта происходит, соответственно, контроль выполнения проекта. Менеджер мониторит, что происходит с проектом, следит за соблюдением технического задания и сроков. Идентифицирует зоны, где требуются изменения. Инициирует соответствующие изменения.
Наблюдение за проектом
Главные инструменты тут — расписание проекта (тайм-план с майлстоунами и дедлайнами) и коммуникационный план. И сама коммуникация. Хорошая коммуникация — основа успеха проекта.
В чек-листе менеджера на этапе контроля выполнения проекта стоит три вопроса:
Участники проекта — и рабочая команда проекта и заказчики.
Помимо диаграммы Гантта для контроля сроков используется раздельный треккинг задач — это уровень повыше, в тех же сложных проектах.
Трекинг проекта происходит путём сравнения точки, в которой мы находимся на данном этапе с той, в которой должны были быть по плану. Так мы оценим, насколько мы сейчас в плюсе/в минусе по бюджету/времени, сможем провести управление стоимостью проекта:
Обычно проблемы на этом этапе выявляют ошибки, допущенные при планировании. Однако, перепланировать весь проект уже вряд ли получится — это в любом случае превратится в катастрофу с позиции бюджета, потому ищем в чём именно у нас проблема в частностях. Вот чек-лист:
Как я писал ранее, 80–90% проблем возникают по причине ошибок планирования. Только 10–20% проблем по причине ошибок команды проекта.
В случае проблем обращаемся к процессам Crashing the Project и Fast Tracking. А вот “лайтовый” список, подходящий для небольших проектов:
Если изменились ожидания клиента (при плохом обсуждении планирования с клиентом):
5. Завершение проекта
Закрытие проекта — этап, когда разрабатываемый продукт готов и его нужно сдать в эксплуатацию. К закрытию проекта есть чек-лист, касающийся самого проекта, документации и команды проекта.
Составы ключевых этапов проекта
Проникая в тонкости сокровенного знания о проектной практике, начинающий профессионал-PM или человек, готовящий себя стать проект-менеджером, должен свободно ориентироваться в основном терминологическом аппарате этого рода деятельности. Часто приходится слышать вопрос о том, как грамотно сформулировать этапы выполнения проекта. Действительно, это задача сложная. Но давайте сначала задумаемся, а принято ли в профессиональной среде оперировать понятием этапов? И в каких случаях это не только возможно, но и необходимо делать?
Определение понятий
Те из нас, кто имеет определенный опыт управления проектами или хотя-бы небольшой теоретический задел, знакомы с рядом явлений, которые менеджер использует, чтобы представить жизненный цикл инвестиционной задачи и спланировать ее решение. Список этих категорий на первый взгляд прост, в его составе:
Предложенные понятия в практике часто используют как синонимы. И если поискать в источниках, то есть вероятность обнаружить, что и словари «грешат» круговыми определениями данных философско-прикладных категорий. Можно заметить и в научной литературе, что «фаза – это стадия», «стадия – это этап» и даже веха определяется как некий этап пути. Как же быть, ведь нам нужно оперировать точным восприятием явлений?
Я предлагаю выполнить процедуру, которую мы уже однажды делали с категориями проектных задач, целей и проблем. Усилим здравое разумение и посмотрим на представленные выше понятия с позиции обычного эмпирического опыта. Ниже показана таблица, в столбиках которой проставлены исследуемые категории, а в табличной части мы будем помещать определения, образы, примеры, которые соответствуют им. Начнем с понятия «фаза». В чем состоит суть данного понятия? Чем его можно охарактеризовать, какими отличительными качествами?
Фазам проектной реализации посвящена статья на тему жизненного цикла проектной задачи. Эмпирически больше всего я воспринимаю фазу как длящееся и выраженное состояние выполнения проекта, например, фаза разработки или фаза завершения. Этих положений у проектной задачи несколько, и они всегда повторяются, хотим мы этого или нет. Принципов разбиения проекта на фазы может быть несколько, но подход к их формулированию един – с позиции длящегося состояния.
Выше в качестве иллюстрации приведен пример двух схем фазовой разбивки проекта. С точки зрения ЖЦ фазы проекта венчают вехи – важные, значимые события его реализации. По временной шкале они представляют собой событийные точки. Фазы проекта делятся на стадии – восходящие периоды развития, отделяющие собой качественные состояния фазы. Например, стадия принятия решения о старте проекта или стадия формирования проектной команды. Более динамической категорией, чем фазы и стадии, являются процессы управления, имеющие следующие черты:
Этапы же являются частями процессов управления, включающих в себя однородные по сути составы работ. Таким образом, этап – это динамическая категория, которая может повторяться на каждой фазе проекта. Например, этап анализа. В небольших проектах этапы, фазы и стадии действительно сливаются в синонимы. В крупных мероприятиях этапы наиболее выражены в процессах инициации, завершения, планирования и организации исполнения.
Этапы процессов инициации и завершения
Мы с вами исследуем процедуры регулярного управления проектами, принимая за основу достаточно высокую планку их развития в компании. Это вполне оправдано. Какой смысл детально описывать этапы каждого из процессов для небольшого по масштабам проекта? Как говорится, «бери и делай!». Другой вопрос, когда проекты включают сложные по реализации элементы, а масштаб решаемых задач значительный. Любой проект начинается с процедур инициации, этапы данной группы процессов следующие.
В настоящем разделе мы исследуем процессы инициации и завершения, которые имеют несколько схожих черт. Основными задачами инициации являются однозначное определение проекта и формулирование его целей, результатов, установление заинтересованных сторон и их ожиданий. Инициация выполняется на старте проекта и в начале каждой из его фаз.
Проект рано или поздно завершается, и очень важно грамотно его «припарковать». Помимо закрытия проекта по факту его успешной реализации данные процедуры могут быть выполнены на каждой фазе мероприятия, когда принимается решение о досрочном прекращении работ. Помимо процесса закрытия проекта или его фазы к данной группе относится также и процесс, связанный с процедурой извлечения уроков и приращения опыта. Процедуры закрытия включают следующие основные этапы.
Работа по извлечению уроков – весьма интересный и полезный процесс. Сюда включаются: презентации для проектного комитета и для других менеджеров компании, анализ и документирование выводов по успехам, проблемам и ошибкам проекта. На итоговом совещании выводы озвучиваются и принимаются рекомендации, подлежащие последующему исполнению.
Этапы процессов планирования
Процессы планирования проекта начинаются от момента запуска проекта и реализуются вплоть до завершающих стадий. Это многократные процедуры, реализуемые на каждой фазе решения проектной задачи. Целями этих процессов являются: детальная разработка содержания, выработка плана действий по управлению проектом и составление календарного расписания работ. Визуальная поэтапная модель процессов планирования предлагается вашему вниманию далее.
Рассмотрим основные этапы создания планов проекта.
Этапы процессов организации исполнения
Процессы организации исполнения проекта находятся исключительно в зоне управленческих компетенций PM. Постановка задач, координация и оперативное реагирование, проявление качеств лидера и командного вдохновителя – все это должно выполняться на этапах данной группы процессов. Представим себе пример инвестиционного проекта по разработке и выводу на рынок новой услуги в компании, действующей на рынке B2С. Типовой состав этапов процессов организации будет включать следующее.
В настоящей статье мы разобрали понятие и содержание ключевых этапов основных процессов управления проектом. Сама природа и сущность этапа как объекта управления входит в противоречие с проектной действительностью. На мой взгляд, более верно говорить не об этапах, а о подпроцессах процессов управления. Причина этого состоит том, что процедуры управления носят растянутый, порой не диагностируемый по последовательности характер. В этих условиях выделить этап как отдельную часть проектного пути сложно. Во всяком случае, логика института PMI при разработке стандарта, сделавшего ставку на процессы, стала более очевидна.