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

  • автор:

Стадии УП: инициация – планирование – исполнение – контроль – завершение

Процессы

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

процессов управления проектами (или группы процессов):

  • Группа процессов инициации. Процессы, которые выполняются для определения нового проекта или новой фазы существующего проекта путем получения разрешения для начала проекта или фазы.

  • Группа процессов планирования. Процессы, требуемые для определения

общего содержания проекта, уточнения целей и определения

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

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

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

  1. Сбор требований

  2. Определение целей и содержания

  3. Создание ИСР (иерархической структуры работ)

  4. Определение операций

  5. Определение последовательности операций

  6. Оценка ресурсов операции

  7. Оценка длительности операций

  8. Разработка расписания

  9. Оценка затрат

  10. Определение бюджета

  11. Планирование качества

  12. Разработка плана трудовых ресурсов

  13. Планирование коммуникаций

  14. Планирование управления рисками

  15. Идентификация рисков

  16. Выполнение качественного анализа рисков

  17. Выполнение количественного анализа рисков

  18. Планирование реагирования на риски

  19. Планирование закупок

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

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

Включает:

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

2 Подтверждение качества

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

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

5 Управление командой проекта

6 Распределение информации

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

8 Осуществление закупок

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

Включает:

1 Мониторинг и управление работами проекта

2 Осуществление общего управления изменениями

3 Подтверждение содержания

4 Управление содержанием

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

6 Управление стоимостью

7 Осуществление контроля качества

8 Подготовка отчетов об исполнении

9 Мониторинг и управление рисками

10 Управление закупочной деятельностью

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

1 Завершение проекта или фазы

2 Закрытие закупок

Закрытие закупок – процесс завершения всех закупок по каждому проекту

▲ Функции управления проектом

  • Планирование (Planning)

  • Контроль (Control)

  • Анализ (Analysis)

  • Принятие решений (Decision making)

  • Составление и сопровождение бюджета проекта (Budgeting)

  • Организация осуществления (Organisation)

  • Мониторинг (Monitoring)

  • Оценка (Evaluation)

  • Отчетность (Reporting)

  • Экспертиза (Appraisal)

  • Проверка и приемка (Validation)

  • Администрирование (Administration)

Подсистемы управления проектом (PM Subsystems)

  • Управление содержанием и объемами работ (Score Management)

  • Управление продолжительностью (Time Management)

  • Управление стоимостью (Cost Management)

  • Управление качеством (Quality Management)

  • Управление закупками и поставками (Procurement & Logistics Management)

  • Управление ресурсами (Resource Management)

  • Управление человеческими ресурсами (Human Resource Management)

  • Управление изменениями (Change Management)

  • Управление рисками (Risk Management)

  • Управление запасами (Inventory Management)

  • Интеграционное управление (Integration Management)

  • Управление информацией и коммуникациями (Information & Communication Management)

Управление стоимостью проекта

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

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

Виды бюджетов

Стадия проекта

Вид бюджета

Назначение бюджета

Погрешность, %

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

Бюджетные ожидания

Предварительное планирование платежей и потребности в финансах

Обоснование инвестиций

Предварительный бюджет

Обоснование статей затрат, обоснование и планирование привлечения и использования финансовых средств

Технико-экономическое обоснование

Тендеры, переговоры и контракты

Уточненный бюджет

Планирование расчетов с подрядчиками и поставщиками

Разработка рабочей документации

Окончательный бюджет

Директивное ограничение использования ресурсов

Реализация проекта

Фактический бюджет

Управление стоимостью (учет и контроль)

Сдача в эксплуатацию

Эксплуатация

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

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

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

Плановые (бюджетные) затраты — (BCWS) Это бюджетная стоимость работ, запланированных в соответствии с расписанием, или количество ресурса, предполагаемые для использования к текущей дате. BCWS = ВС (общий бюджет) х % по плану.

Фактические затраты — ACWP. Это стоимость фактически выполненных работ на текущую дату или количество ресурса, фактически потраченное на выполнение работ до текущей даты. Фактические затраты не зависят от плановых показателей по затратам или потреблению ресурсов.

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

плановые (бюджетные) затраты — BCWS;

фактические затраты — ACWP;

освоенный объем — BCWP (Budgeted Cost of Work Performed). Это плановая стоимость фактически выполненных работ или количество ресурса, запланированное на фактически выполненный объем работ к текущей дате. Освоенный объем не зависит от фактически произведенных затрат по работе:

BCWP = Плановая стоимость х % использования ресурса.

Смета – список затрат проекта по стадиям

Смета проекта — список затрат проекта, разбитых по статьям.

Смета – плановая стоимость запланированных работ.

Методы разработки:

-Метод оценки по прошлым результатам;

-Метод «сверху-вниз»;

-Метод «снизу-вверх»;

-Специализированные информационные программы

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

Григорий Львович Ципес, ведущий системный аналитик компании IBS, GTsipes@ibs.ru Александр Самуилович Товб, руководитель проектов компании IBS, A_Tovb@ibs.ru

Начнем эту заметку с рассказа об одном забавном эпизоде. Однажды в нашей компании проходили практику студенты-дипломники, специализирующиеся на управлении проектами. Выдавая им задание, руководитель практики (один из авторов этой заметки) попросил описать scope проекта (он так и сказал — скоуп). «А что такое scope?» — осторожно поинтересовалась одна девушка. «О, scope — это…» — ответил руководитель и нарисовал руками в воздухе нечто, напоминающее средних размеров глобус. «Понятно, — грустно сказала девушка. — Нам в институте так же объясняли».

Ситуация очень характерная и довольно опасная. Есть некий термин, употребляемый в англоязычных источниках и не имеющий очевидного и однозначного перевода на русский язык в контексте управления проектами. На профессиональном жаргоне мы привыкли пользоваться этим термином на языке оригинала. Действительно, гораздо удобнее сказать scope, чем какое-нибудь достаточно громоздкое «содержание и границы». Если кому-то непонятно, то всегда можно объяснить, хотя бы с помощью жестов. А приводит все это к тому, что некоторое время спустя точного значения термина никто уже не помнит, каждый трактует его по-своему, и при этом все думают, что понимают друг друга!

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

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

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

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

КРАТКИЙ СРАВНИТЕЛЬНЫЙ ГЛОССАРИЙ

Проект (project) — уникальный комплекс взаимосвязанных мероприятий для достижения заранее поставленных целей при определенных требованиях к срокам, бюджету и характеристикам ожидаемых результатов. Проект — уникальный процесс, состоящий из набора взаимоувязанных и контролируемых работ с датами начала и окончания и предпринятый, чтобы достичь цели соответствия конкретным требованиям, включая ограничения по времени, затратам и ресурсам . Проект — целенаправленная деятельность временного характера, предназначенная для создания уникального продукта или услуги . Управление проектами (Project Management) — профессиональная творческая деятельность по руководству людскими и материальными ресурсами путем применения современных методов, средств и искусства управления для успешного достижения заранее поставленных целей при определенных требованиях к срокам, бюджету и характеристикам ожидаемых результатов проектов, осуществляемых в рыночных условиях в социальных системах. Управление проектом включает планирование, организацию, мониторинг и контроль всех аспектов проекта в ходе непрерывного процесса достижения его целей . Управление проектом — процесс применения знаний, навыков, методов, средств и технологий к проектной деятельности с целью достижения или превышения ожиданий участников проекта . План управления проектом (Project Management Plan) — основополагающий документ (baseline document), с которого должен начинаться любой проект. Содержит согласованное всеми участниками документально зафиксированное представление о проекте. В инвестиционных проектах — мастер-план проекта (Project Master Plan) (УП). Устав проекта (Project Charter) — документ, разработанный вышестоящей администрацией, который предоставляет менеджеру проекта право использовать ресурсы организации для выполнения работ проекта . Определение проекта (Project Definition Report) — документ, определяющий проект, в том числе: каковы цели и результаты проекта; в чем его необходимость; что должно быть сделано; как, когда и где это должно быть сделано; что для этого нужно; сколько это будет стоить; какие необходимо привлечь внешние ресурсы и организации; какие стандарты и процедуры подлежат соблюдению при осуществлении проекта . Базис (Project Baseline) — основополагающие параметры и, фиксирующие их согласованное понимание всеми участниками, документы проекта — «точка опоры» для всего последующего развития проекта. Базовый план (Baseline) — первоначальный план проекта с утвержденными изменениями. Базовый план бывает также и по составляющим проекта — стоимости, расписанию и т. д. Содержание и границы проекта (Project Scope) — цели и задачи проекта, основные результаты, критерии оценки того, что работа или ее часть выполнена. Содержание проекта, объем работ (Scope) — (букв. пределы, рамки, сфера). Содержание работ и результаты проекта (или его части). Проект описывается путем перечисления всех выполняемых работ, необходимых ресурсов и конечных результатов, включая требования к качеству . Предметная область (Scope) — совокупность продуктов и услуг, производство которых должно быть обеспечено в рамках осуществляемого проекта . Цели (Scope) — совокупность продуктов и услуг, намеченных к производству в проекте . Ключевые вехи проекта (Project Milestones) — ключевые события проекта, свершение которых является необходимым и достаточным условием, определяющим достижение результатов проекта. Обычно представляются в виде схемы или таблицы с взаимосвязями и сроками свершения, образуя План по Вехам (Milestone Plan, Milestone Schedule, Master Schedule). Контрольное событие — важное событие проекта, обычно связанное с достижением важнейших результатов . Другие варианты — ключевое событие , контрольная точка . Структура декомпозиции работ (Work Breakdown Structure), СДР (WBS) — представление проекта в виде иерархической структуры работ, полученной путем последовательной декомпозиции. СДР предназначена для детального планирования, оценки стоимости и обеспечения персональной ответственности исполнителей. Структурная декомпозиция работ — иерархическая структуризация работ проекта, ориентированная на основные результаты проекта, определяющие его предметную область. Каждый нижестоящий уровень структуры представляет собой детализацию элемента высшего уровня проекта. Элементом проекта может быть как продукт, услуга, так и пакет работ или работа . Иерархическая структура работ — структуризация работ проекта, отражающая его основные результаты. Каждый следующий уровень иерархии отражает более детальное определение компонентов проекта . Структура разбиения работ — иерархическая структура последовательной декомпозиции проекта на подпроекты, пакеты работ различного уровня, пакеты детальных работ . Проектные отклонения (Project Exceptions) — несовпадения фактических и плановых результатов проекта, причины таких несовпадений, методы и технологии, позволяющие справляться с такими ситуациями в проекте. Включают в себя риски, проблемы и изменения. Отклонение (Deviation) — выход за пределы установленных требований. К отклонениям относятся случаи, когда результат работы не удовлетворяет требованиям или необоснованно их превышает. Проектные риски (Project Risks) — возможность возникновения непредвиденных ситуаций или рисковых событий в проекте, которые могут негативно или позитивно воздействовать на достижение целей проекта. Риск проекта характеризуется следующими факторами: источниками и характеристиками событий, которые могут оказать влияние на его выполнение; вероятностями появления таких событий; возможным ущербом проекту и оценкой его влияния на проект. Риск — потенциальная, численно измеримая возможность неблагоприятных ситуаций и связанных с ними последствий в виде потерь, ущерба, убытков . Проектный риск в самом общем понимании — это опасность нежелательных отклонений от ожидаемых состояний в будущем, из расчета которых принимаются решения в настоящем . Проблемы проекта (Project Problems) — любой функциональный, технический или связанный с бизнесом вопрос, который возник в процессе осуществления проекта и требует изучения и решения для того, чтобы проект мог идти так, как запланировано. Проблемные ситуации (Problem situations) — возникающие при осуществлении проекта ситуации, для выхода из которых необходимо находить оптимальные решения . Решение проблем (Problem Solving) — определение последовательных систематических процедур, с помощью которых анализируются и решаются проблемные ситуации . Изменения проекта (Project Changes) — модификация ранее согласованных продуктов и услуг, сроков исполнения и стоимости работ, используемых ресурсов, управленческих и технологических процессов и т. п. Изменения — увеличение или уменьшение характеристик элементов проекта. Пересмотр базового плана проекта. Подразумевает документально оформленные и утвержденные изменения . Календарный план проекта (Project Schedule) — перечень планируемых работ проекта со сроками исполнения и ответственными лицами, подготовленный в соответствующей форме, определенной планом управления проектом. Расписание проекта — плановые даты для выполнения работ и плановые даты для наступления контрольных (ключевых) событий («вех») проекта . Куратор проекта (Sponsor) — лицо, отвечающее перед руководством предприятия за успех проекта в целом и имеющее полномочия для решения ресурсных и других проблем, эскалированных руководителем проекта. Спонсор проекта — лицо или организация, для которых проект предпринят и которые в наибольшей степени принимают на себя проектный риск . Руководитель проекта (Project manager) — менеджер, отвечающий за успешную реализацию проекта, взаимодействие с заказчиком, субподрядчиками и подразделениями компании, а также за организацию подготовки и предоставление отчетности по проекту. Менеджер проекта — лицо, ответственное за управление проектом . Бюджет проекта (Project budget) — утвержденное запланированное распределение финансовых средств проекта по различным основаниям: по статьям затрат, по временным периодам, по участникам проекта, по решаемым задачам, по компонентам ожидаемых результатов, по элементам организационной структуры проекта и т. п. Бюджет проекта — сметная стоимость, распределенная по периодам выполнения проекта . Заинтересованные лица (Stakeholders) — физические и юридические лица, как непосредственно участвующие в проекте, так и те, чьи интересы могут быть затронуты процессами осуществления проекта и его результатами. Участники проекта — физические лица и организации, которые непосредственно вовлечены в проект или чьи интересы могут быть затронуты при осуществлении проекта .

Источники, по которым цитируются определения:

Наверно каждый, кто внедрял проектное управление, сталкивался с ситуацией, когда собственники бизнеса задавали себе и вам вопрос типа «Вот жили мы жили без этого вашего проектного управления, нахрена оно нам нужно и что оно нам даст для бизнеса?!»
Ситуации, конечно же, бывают очень разные, но в основе лежит одинаковый базис. С проектными компаниями все намного проще, сделал проект, получил бабки, сделал плохо или не вовремя — не получил или получил, но не все. Или еще множество вариаций на тему, смысл един, реализация проектов напрямую влияет на финансовые показатели бизнеса.
Сегодня же речь пойдет о не проектных компаниях, т.е. тех, для которых проекты не приносят прямой прибыли, а скорее являются инвестициями в будущее.
В первую очередь, нужно четко понимать что есть проект, а что есть отдельная задача (поручение). И категорически не нужно смешивать эти два разных типа активностей. Есть множество определений и того и другого понятия, НО важно на берегу договориться о базовых понятиях.
Итак, в своей практике я использую следующую классификацию активностей:

Как правило, собственник начинает задумываться о внедрении системы управления проектами тогда, когда сам теряет контроль в своем ручном управлении псевдо проектами.
Тогда, когда в этих псевдо активностях участвует множество подразделений компании и начинается «игра в пинг-понг». И как следствие, просрачиваются сроки, увеличиваются бюджеты и наступает «стабильный хаус».
НО при этом собственник бизнеса считает, что проектное управление — это волшебная кнопка, нажав на которую, все немедленно взлетит и будет работать как швейцарские часы.
ВАЖНО понимать самим и доносить это до собственников бизнеса и иных ЛПР (лиц принимающих решения), что грамотно построенное управление позволит:

      ГЛОБАЛЬНО — реализовать стратегию развития бизнеса Компании в запланированные сроки и деньги с соответствующим качеством

ЛОКАЛЬНО:

  • классифицировать активности
  • приоритезировать проекты и задачи
  • провести полноценное планирование проектов (сроки, бюджеты, содержание, качество, риски и т.д.)
  • осуществлять системный мониторинг, анализ и контроль реализации проектов
  • своевременно эскалировать потенциальные угрозы
  • выстраивать эффективные коммуникации в проектах
  • наполнять базу знаний лучшими практиками и нарабатывать статистику
  • Объяснять нужно не зачем «проектное управление». Для здравомыслящего человека должно быть понятно, что для успешного достижения поставленной цели нужен четкий план, учитывающий имеющиеся ограничения и риски, нужна команда, которая будет его реализовывать, с четким распределением полномочий и ответственности и планом взаимодействия, нужен контроль и анализ исполнения и окружающей среды, чтобы своевременно производить корректирующие воздействия, нужна координация с командами других проектов. Чтобы это успешно реализовать нужно опираться на накопленный опыт и инструменты управления проектами и портфелями проектов, хотя в каждой отрасли и каждой организации свои требования и особенности. А чтобы говорить с другими на одном языке нужно пользоваться терминологией, используемой в стандартах по управлению проектами. Управление проектами как дисциплина базируется на здравом смысле и накопленном опыте. Это не квантовая механика.

    Т е все вышеперечисленное образует некоторую технологию, которую обычно и называют «проектное управление» — из обсуждения на FB (автор Владимир Либерзон) Если коротко, то для меня, как для топ-менеджера проектное управление это способ быстрее прийти к заданным целям, получить ожидаемые от проектов бизнес-результаты, быстрее и эффективнее развивать компанию. Как для собственника, вкладывающего в проекты развития фактически свои деньги (которые в теории могли бы пойти на выплату дивидендов), проектное управление — это способ защитить свои инвестиции, гарантировать себе как планируемые продукты проектов так и заложенную в проект экономическую отдачу (заработать больше денег).
    Кейсы у наших клиентов показывают, что ТОП/собственник тогда начинают задумываться о проектном управлении, когда в компании достаточно серьезные средства вкладываются в развитие, а результаты компания получает с большими задержками по срокам, с перерасходом бюджета, а иногда полученные результаты просто оказываются уже не нужны. Т.е. основная боль — это потеря денег или не выполнение своего (родного для топа) амбициозного плана по развитию. Когда такие боли есть их нужно суммировать(посчитать), подойти к нему и объяснить на данном примере как можно было снизить/не допустить потери или на кейсах других компаний (лучше конкурентов) показать как другие компании таких потерь не допускают — из обсуждения на FB (автор Дмитрий Мазеин)
    Андрей Береговенко

    Добавить комментарий

    Ваш адрес email не будет опубликован. Обязательные поля помечены *