На каком этапе проекта выполняются анализ бизнес процессов

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

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

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

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

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

Фреймворк проекта оптимизации сквозного бизнес-процесса

Следует отметить, что в нашей стране термин «процесс» не принят в том контексте, в каком мы будем использовать его далее. Прежде всего необходимо дать определение термину «процесс» – это действия и процедуры, которые связаны с реализацией управленческих функций. Именно так трактуется данное понятие во всем мире.

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

• Основные процессы управления проектами — сюда относится организация и описание работ проекта. Далее в статье мы их детально опишем и разберем.
• Процессы, которые ориентированы на товар, они касаются его особенностей и технологии изготовления. Зависят такие процессы от жизненного цикла проекта, а также от области приложения.

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

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

Процессы управления задачами проекта подразделяются на несколько групп в зависимости от функций управления:

1. Процессы инициации — принимается решение о том, что проект начнет выполняться командой.
2. Процессы планирования — на данном этапе необходимо определить цели работы, а также решить, как оценивать результат, разработать эффективный план достижения целей.
3. Процессы исполнения — руководитель координирует подчиненных, чтобы добиться поставленной цели.
4. Процессы анализа — здесь необходимо определить, соответствует ли реальное положение дел плану, происходит ли достижение поставленных целей, получен ли необходимый результат, следует ли скорректировать работу команды и перераспределить ресурсы.
5. Процессы управления командой проекта – следует решить, нужно ли корректировать работу команды, при необходимости согласовать, утвердить и применить внесенные изменения.
6. Процессы завершения — формализация выполнения проекта, финальные действия, завершающие работу.

Вебинар 27.04: Автоматизация KPI-управления в туроператоре FUNSUN (бывш. TUI)

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

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

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

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

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

Результат каждого этапа управления проектами

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

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

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

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

Контроль, так же как и организация и планирование, является цикличным процессом.

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

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

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

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

Далее приведены методы, использующиеся чаще всего.

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

Такая система процессов управления проектами будет состоять из следующих этапов, которые подходят для любой области деятельности:

• обсуждаем идею;
• анализируем требования к проекту, формируем ТЗ для исполнителей, оговариваем сроки и сумму, которая выделена для реализации проекта;
• проектируем;
• исполняем;
• тестируем, вносим корректировки, устраняем допущенные ошибки;
• внедряем продукт, осуществляем техподдержку.

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

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

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

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

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

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

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

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

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

Скорость разработки составляет 4-6 историй в неделю. Причем непрерывно тестируется код в автоматическом режиме.

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

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

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

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

Scrum — это еще один метод, который был создан на основе agile. Его отличие заключается в том, что процесс разработки разделен на спринты (итерации длительностью 2-4 недели). При этом срок не меняется на протяжении всего проекта. Когда один принт завершается, клиент получает часть продукта, которую можно использовать.

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

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

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

Scrum является наиболее структурированным методом, который основывается на agile. У данного метода есть множество преимуществ гибкой модели, к примеру способность быстро адаптироваться и клиентоориентированность.

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

Если проект инновационный, а уровень непредсказуемости высокий и составлять план заблаговременно нецелесообразно, подойдут гибкие методы agile либо scrum. Так вы сможете сразу же внести необходимые поправки.

Источник: reklamaplanet.ru

Процессы PMBoK 5 за 10 минут

В начале сентября 2017 года вышла шестая редакция PMBoK (Project Management Body of Knowledge). PMBoK — свод знаний по проектному менеджменту, выпускающийся организацией PMI (Project Management Institute).

Это офигенно здоровый талмуд справок по ведению проектов, регулярно при том обновляющийся. Первая публикация свода вышла в 1996 году, за 20 лет — шесть редакций. В довесок к выпуску свода знаний, организация проводит сертификации проектных менеджеров. Увы, по некоторым причинам, я её пройти пока не могу. Ещё одна фентифлюшка PMI — участие в “клубе”, нафиг в жизни не нужна.

Кроме легального доступа к PMBoK 6, она ничего не даст. Потому я и не могу рассказать, что там, в шестой редакции. Только что читать краткие ревью, чего там появилось нового.

Сегодня пробежимся по процессам ведения проектов пятой редакции свода и поговорим о том, что такое управление проектами в целом. Статья подготовлена под влиянием соответствующего курса на курсере.

Что такое проект

Этапы выполнения проекта

Любой проект имеет начало, выполнение и завершение. PMBoK пятой редакции выносит управление этими этапами в пять процессов: инициация, планирование, выполнение, контроль выполнения и завершение проекта.

1. Инициация

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

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

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

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

Составление устава проекта. Здесь решаются вопросы с документами: руководство по ведению проекта, примерный тайм-план и техническое задание. Основной вопрос устава проекта — что решает продукт, создаваемый в процессе проекта, что должны получить на выходе (например, “на выходе нужен дом на 250 квартир”).

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

PMI отводит большой пласт именно планированию. Большинство проблем проекта возникает из-за ошибок при планировании проекта. Посудите сами: если в начале проект спланирован так, что прописано и предусмотрено абсолютно всё — какие могут быть проблемы в будущем? Планирование проекта содержит процессы: риск-менеджмент, определение проектных задач (и их декомпиляция), расписание проекта (тайм-план), формирование команды проекта.

Управление рисками

Риск — одно из неопределённых событий, которое может произойти. Риски бывают негативными, создающими проблемы (например, в проекте по строительству автобана, разорился подрядчик), так и позитивными, которые помогают проекту. Управление рисками происходит в 4 шага.

1. Определение рисков.
2. Анализ найденных рисков.
3. Разработка плана работы с рисками.
4. Предупреждение рисков.

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

Разработка плана работы с рисками — что ты будешь делать в случае, если риск наступит?

Предупреждение рисков — что можно сделать, чтобы риск не наступил? Здесь же нам нужно оценить триггеры, по которым мы сможем оценить, что риск наступил и с ним нужно что-то делать. Это как когда у вас дома выбивает пробки, вы ищете потребитель, “кладущий” электросеть.

Характеристиками рисков являются “последствия” и “вероятность наступления”, где 1 — минимальное значение, 5 — максимальное.

Оценка рисков на старте IT-проекта. Вписав риски в таблицу и посчитав “тоталы” последствия/вероятности, мы видим, что нам стоит заняться поиском выхода на лицо, принимающее решение и поиском заменяющего программиста (если уж зачем-то подключаем программиста, который вот-вот уходит в отпуск). “Метеорит” вставил для утрированного примера, когда последствия риска максимальны, но вероятность нулевая.

Проектные задачи

Здесь берутся задачи, ставящиеся перед проектом в целом и декомпилируются на этапы, подзадачи и зависимости. Техническое задание превращается в задачи, которые требуют прямого решения. Для этого составляется ИСР — Иерархическая структура работ (WBS в оригинале).

В качестве примера иерархической структуры — проект разработки веб-сайта. Проект состоит из трёх этапов, каждый из этапов (фаз выполнения проектов) содержит или не содержит свои подэтапы, а те, в свою очередь, содержат конечные задачи. Проект декомпилируется до уровня задач, где каждая задача занимает от 4 до 40 часов работы конкретного исполнителя (рекомендуется PMBoK). В проектах наподобие разработки сайтов, задача может занимать от получаса до 16 часов — я так считаю.

Определение задач происходит так:

1. Определить желаемые результаты.
2. Определить, что нужно сделать для достижения этого результата.

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

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

Помимо иерархической структуры есть ещё одна, интереснее: структура взаимосвязей и зависимостей задач проекта. Такая структура позволяет понять, что за чем следует, моделировать ход проекта.

Структура взаимосвязей может составляться на основе верхних уровней иерархической структуры. На примере разработки сайта, взаимосвязи линейны и выглядят так: дизайн => вёрстка => программирование. В случае проекта той же постройки детского сада, количество взаимосвязей стремится к бесконечности, их следует учитывать.

По поводу маршрута хода проекта (ака сетевой трафик) в PMBoK есть несколько инструментов — Float Time и Critical Time. Я их [пока] не использую, а желающие могут почитать об этом в интернете. Пример структуры — диаграмма PERT.

Тайм-план проекта

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

Для того, чтобы составить тайм-план в виде диаграммы Гантта, нужно:

1. Перенести задачи в расписание — основные этапы + их детализацию
2. Добавить длительность задач
3. Расставить зависимости и отношение

1. Добавить поздний и ранний сроки старта и финиша
2. Добавить добавочную информацию — например, имена исполнителей

На тайм-плане отмечаются майлстоуны — этапы с нулевой продолжительностью, вехи проекта. Например, “сдача дизайна” или “запуск сайта”. Это задачи, которые требуют выполнения, но сам момент выполнения может быть отмечен в качестве значимой точки проекта.

Диаграмма Гантта ещё тем хороша, что легко составляется — её можно хоть от руки рисовать. На компьютере её можно создать в Ms Project или Ms Excel. Я воспользовался сервисом draw.io — рекомендую.

Если базовая линия проекта изменилась и планирование посыпалось, PMBoK предлагает нам два инструмента в помощь в борьбе с проблемой: “Crashing the Project” и “Fast Tracking”. Альтернативные пути, подходящие нам и помогающие оставаться в рамках изначального тайм-плана — это уменьшение содержания проекта и уменьшение качества — время здесь равняется бюджету.

Управление командой проекта (Project Leadership)

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

Формирование команды проекта может происходить двумя путями:

1. Рекрутинг
2. Наём исполнителей через функциональных менеджеров (тим-лидов)

Например, в диджитал-разработке это может выглядеть так: в компании есть дизайнеры, есть веб-программисты. У каждой из групп специалистов есть свой тим-лид — арт-директор у дизайнеров и тех.директор у программистов. Приходит заявка на разработку мобильного приложения. В таком случае, мы “нанимаем” дизайнера и веб-программиста у тим-лидов, а мобильного разработчика нанимаем из вне на время создания проекта — например, фрилансера.

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

1. Знакомство между собой
2. Прояснение целей проекта.
3. Прояснение плана проекта.
4. Ответы на вопросы.

В случае крупных проектов может потребоваться процесс “распределение задач”. Например, если наш проект — это веб-разработка, и у нас 10 программистов и 5 верстальщиков. Распределение происходит путём поиска ответов на вопросы:

1. Может ли он выполнить эту задачу?
2. Выполнит ли он эту задачу?
3. Будет ли он доступен в то время, когда потребуется выполнение задачи?

Под “может” подразумевается квалификация и навыки исполнителя. Под “выполнит” — будет ли он её делать. “Будет ли доступен” — в том случае, если команда собирается сразу, а этап работы этого специалиста произойдёт через месяц. Подразумевается, что члены рабочей группы проекта не сидят на одном месте вокруг одного проекта, что до старта проекта у него были другие задачи (проектные или нет), также могут быть задачи во время хода проекта (во время, когда он не вовлёчен в работу).

По PMBoK применяется таблица RAM — в ней обозначаются номинальные роли участников проекта. Эта тема больше про отчётность и понимание того, к кому когда обращаться. Не думаю, что есть смысл её вести, если участников проекта меньше 20 человек и каждый выполняет одну-две функции.

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

А вот ещё чуток про human resources и выбор исполнителя под проект, чек-лист вопросов по оценке возможностей.

1. Насколько ежедневные обязанности исполнителя пересекаются с задачами проекта.
2. Обладает ли человек специальными навыками, требующимися в проекте.
3. Какой у человека бэкграунд и образование.
4. Каково с этим человеком работалось ранее.
5. Готовность принять назначенные задачи.
6. Общий уровень доверия.
7. Личные амбиции и желания исполнителя.

Каждый участник рабочей команды — личность с собственными потребностями, желаниями и слабостями.

3. Выполнение проекта

Основной этап проекта, когда работа работается, результаты согласовываются и передаются от специалиста специалисту дорабатываясь. Задачи менеджера проектов на этом этапе — ведение коммуникации и слежение за треугольником время-бюджет-качество. Контроль и наблюдение за проектом выносится в отдельный процесс.

Причины быть “быстрее и дешевле”

1. Приближающийся дедлайн.
2. Желание увеличить прибыль.
3. Желание опередить конкурентов.
4. Увеличение жизненного цикла продукта.

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

4. Наблюдение и контроль выполнения проекта

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

Наблюдение за проектом

1. Мониторинг
2. Оценка ситуации
3. Установка контролирующих действий (если требуется)
4. Доставка результатов работы заказчику

Главные инструменты тут — расписание проекта (тайм-план с майлстоунами и дедлайнами) и коммуникационный план. И сама коммуникация. Хорошая коммуникация — основа успеха проекта.

В чек-листе менеджера на этапе контроля выполнения проекта стоит три вопроса:

1. С кем нужно держать коммуникацию?
2. Почему и зачем нужно с ним коммуницировать?
3. Как можно держать участников проекта информированными?

Участники проекта — и рабочая команда проекта и заказчики.

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

Трекинг проекта происходит путём сравнения точки, в которой мы находимся на данном этапе с той, в которой должны были быть по плану. Так мы оценим, насколько мы сейчас в плюсе/в минусе по бюджету/времени, сможем провести управление стоимостью проекта:

1. Насколько запланированный объём отличается от действительно завершенного?
2. Насколько “расхождение” отличается от реального объёма?

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

• Цели проекта
• Стратегия
• Оценки
• Планируемое расписание
• Человеческие ресурсы (команда, организация, клиент)

Как я писал ранее, 80–90% проблем возникают по причине ошибок планирования. Только 10–20% проблем по причине ошибок команды проекта.

В случае проблем обращаемся к процессам Crashing the Project и Fast Tracking. А вот “лайтовый” список, подходящий для небольших проектов:

1. Уменьшаем качество продукта, чтобы успеть в срок
2. Уменьшение объёма продукта с той же целью
3. Повышение бюджета (!)
4. Разработка новой стратегии
5. Замена участников команды проекта

Если изменились ожидания клиента (при плохом обсуждении планирования с клиентом):

• Переговоры. Естественно — многое можно решить, всего лишь обсудив
• Обсудить регулировку содержания проекта
• Переопределить цели и отношения проекта

5. Завершение проекта

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

Закрытие проекта

• Проверить критерии достижения целей проекта
• Убедиться, что продукт доставлен потребителю
• Убедиться в удовлетворении заказчика

Закрытие документов

• Закрытие финансовых документов
• Закрытие договоров

Завершение работы проектной группы

• Закрывающая встреча с командой проекта
• Уведомление тим-лидов о завершении проекта
• Ревью документации проекта
• Отчёт о проекте с указанием того, что сделано хорошо/плохо и того, что можно было сделать лучше

Источник: salakhmir.medium.com

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

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

В этой статье рассматриваем процессы управления проектами, их взаимосвязь и решение от «КСК ТЕХНОЛОГИИ» для автоматизации процессов.

Основные процессы проекта

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

Разделить процессы проекта можно на две основных группы:

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

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

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

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

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

Инициация проекта

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

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

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

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

Основные процессы планирования:

• Планирование основных целей для управления проектами — разработка и постановка задач, проектное обоснование.
• Процесс разделения целей на небольшие управляемые компоненты для более точного контроля.
• Определение состава работ — составления списка действий, которые необходимо выполнить.
• Определение основных взаимосвязей — документирование технологических взаимосвязей между отдельными операциями.
• Оценка объема работ и продолжительности выполнения задач для успешного управления проектами.
• Определение ресурсов (материальных, финансовых, человеческих), которые могут быть задействованы в работе.
• Процесс назначения ресурсов — определение, какие ресурсы использовать для выполнения определенных операцией.
• Процесс оценки стоимостей — определение всех составляющих стоимостей операций.
• Процесс оценки бюджета — приложение оценок стоимости к разным срокам, фазам и этапам.
• Составление расписания — определение последовательности выполнения действий, распределение времени и других ресурсов с учетом наложенных взаимосвязей и ограничений.
• Подготовка плана исполнения в форме документа.
• Определение критериев успеха для оценки исполнения.

Кроме основных процессов планирования есть и вспомогательные. Необходимость в их использовании зависит от специфики конкретного проекта.

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

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

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

Исполнение — это процессы реализации ранее подготовленного плана. Контроль исполнения следует проводить по всем параметрам, которые заранее определены на этапе планирования.

Процессы исполнения и контроля также делят на основные и вспомогательные. К основным процессам относят непосредственно сам процесс исполнения плана, к вспомогательным:

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

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

Анализа

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

К основным процессам причисляют те, что непосредственно связаны с целями и показателями, влияющими на успешность:

• анализ стоимости — определение прогнозируемой и фактической стоимости операций;
• анализ рисков — оценка соответствия прогнозируемых и фактических сроков исполнения действий;
• анализ качества — отслеживание результатов и их проверка на соответствие стандартам качества;
• подтверждение целей — формальная приемка результатов участниками.

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

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

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

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

Управления

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

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

К вспомогательным процессам управления можно отнести:

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

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

Завершение проекта

Завершение работ сопровождают следующие процессы:

• закрытие контрактов, включая возникшие в ходе реализации споры;
• административное завершение — подготовка, сбор, распределение информации для формального закрытия проектных работ.

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

Попробуйте КСК.Проекты прямо сейчас!

Бесплатный доступ ко всем возможностям сервиса на 14 дней

• Управление жизненным циклом продукта
• Управление проектами и задачами
• Портал системы – единое дисковое хранилище, чат, календарь событий
• Аналитика и контроль
• Доступ с любых устройств 24/7

Взаимодействие групп процессов в проекте

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

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

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

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

Процессы управления проектами от «КСК ТЕХНОЛОГИИ»

Готовое решение от компании «КСК ТЕХНОЛОГИИ» — продукт КСК.ServiceTeamwork:

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

КСК.Servicehttps://www.kck.ru/solutions/processy-upravleniya-proektami» target=»_blank»]www.kck.ru[/mask_link]