В каком процессе управления создается продукт проекта

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

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

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

Процессы проекта

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

  • Процессы Управления Проектами – касающиеся организации и описания работ проекта (которые будут подробно описаны далее);
  • Процессы, ориентированные на продукт – касающиеся спецификации и производства продукта. Эти процессы определяются жизненным циклом проекта и зависят от области приложения.

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

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

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

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

Наложение групп процессов в фазе.

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

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

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

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

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

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

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

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

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

Процессы инициации

Инициация включает единственный подпроцесс – Авторизацию, т.е. решение начать следующую фазу проекта.

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

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

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

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

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

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

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

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

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

Вспомогательные процессы планирования

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

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

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

Процессы исполнения и контроля

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

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

К основным можно отнести сам процесс исполнения плана проекта.

Среди вспомогательных процессов отметим:

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

Процессы анализа

Процессы анализа включают как анализ плана, так и анализ исполнения проекта.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Процессы завершения

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

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

Источник

Текущая версия страницы пока не проверялась опытными участниками и может значительно отличаться от версии, проверенной 30 августа 2020;
проверки требуют 5 правок.

Управление проектами — деятельность по достижению поставленных целей и задач проекта.

Ключевым фактором успеха проектного управления является наличие чёткого заранее определённого плана, минимизации рисков и отклонений от плана, эффективного управления изменениями (в отличие от процессного, функционального управления, управления уровнем услуг) [источник не указан 815 дней]. Продуктами проекта могут быть продукция предприятия или организации (результаты научных и маркетинговых исследований, проектно-конструкторская и технологическая документация на новое изделие, разработанные для заказчика) и решение разных внутренних производственных задач (например, повышение качества продукции и эффективности организации труда, оптимизация финансовых потоков).

Управление проектами является частью системы менеджмента предприятия.

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

История[править | править код]

В основе современных методов управления проектами лежат методики структуризации работ и сетевого планирования, разработанные в конце 50-х годов XX века в США.

Классическая форма тройственной ограниченности[править | править код]

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

The Project Management Triangle

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

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

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

Подходы к управлению жизненным циклом продукта[править | править код]

Существует множество подходов к управлению жизненным циклом проекта/продукта в зависимости от типа проекта:

  • Предположение о неизменности требований, низких рисках, критичности сроков завершения. В этом случае применяется водопадный жизненный цикл. Для планирования и контроля хорошо применимы методы PERT, метод критического пути, метод освоенного объема, диаграмма Ганта. Основная слабая сторона классического проектного менеджмента – нетолерантность к изменениям. Подход применим к строительным и инженерным проектам, в которых содержание проекта остаётся практически неизменным в течение всего проекта [1].
  • Предположение о критичности качества, при этом требования к сроку и ресурсам достаточно гибки (под качеством здесь понимается полнота удовлетворения потребностей, как известных, так и неизвестных заранее, часто создаваемых выходом нового продукта). В этом случае применяются спиральный жизненный цикл, гибкая методология разработки продукта, минимизация администрирования и неформальный подход к управлению проектом. К преимуществам относят гибкость и адаптивность под изменения требований. В качестве недостатков отмечают что гибкость может приводить к потере фокуса, усложнению внесения непредвиденных изменений [1].
  • Предположение о высоких неопределенностях и рисках проекта (для инновационных проектов и стартапов). В этом случае применяются подходы управления бережливый стартап, Phase–gate model[en], Управление реализацией преимуществ[en][2].

Роли в проекте[править | править код]

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

Заказчик определяет цель и ограничения проекта и его финансирование.
Исполнитель выполняет проект согласно утвержденному плану.

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

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

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

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

Цель управления проектом и успешность проекта[править | править код]

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

Группы оценок успешности:

  • Ориентированные на контракт с жесткой фиксацией требований и минимизацией изменений в ходе проекта, например традиционные методологии, в том числе PMBOK: «проект успешен, если выполнен согласно утвержденным критериям: объёму, сроку, качеству». То есть проект успешен, если исполнен и закрыт договор между Заказчиком и Исполнителем (вне зависимости от того, являлся ли он юридическим документом в случае внешних проектов или определялся как-то иначе в случае внутренних проектов). При этом оценка успешности единая как для заказчика так и для исполнителя.
  • Ориентированные на удовлетворенность заказчика с гибким управлением требованиями, например гибкие методологии SCRUM: «проект успешен, если заказчик удовлетворен»
  • Ориентированные на длительное взаимодействие с Заказчиком: управление программами, направленное на длительное взаимодействие, а не на один проект/контракт. Здесь делается акцент на продолжение сотрудничества Исполнителя с Заказчиком в рамках последующих проектов и иного взаимодействия.
  • Сбалансированные, например PRINCE2: «проект успешен при сбалансированности по крайней мере по трем категориям — бизнеса, ориентации на пользователя и технологической зрелости». Здесь делается акцент на финансовой успешности проекта, удовлетворенности пользователей и развитии технологий. Оценка успешности может различаться с точки зрения бизнеса, пользователя и исполнителя. Такие методики оценки чаще используются для внутренних проектов, когда заказчик и исполнитель находятся в одной организации.

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

В целом можно определить цель управления проектами следующим образом:

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

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

Корпоративная система управления проектами[править | править код]

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

Процедуры управления проектом[править | править код]

Процедуры управления проектом по традиционной методологии[править | править код]

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

  • Определение среды проекта.
  • Формулирование проекта.
  • Планирование проекта.
  • Техническое выполнение проекта (за исключением планирования и контроля).
  • Контроль над выполнением проекта.

Процедуры управления проектом по методологии PMI[править | править код]

Основные процедуры и процессы PMI описаны в стандарте PMBOK:

  • Определение требований к проекту
  • Постановка чётких и достижимых целей
  • Балансирование конкурирующих требований по качеству, возможностям, времени и стоимости
  • Адаптация спецификаций, планов и подходов для нужд и проблем различных заинтересованных лиц (стейкхолдеров)

Процедуры управления проектом по методологии IPMA[править | править код]

  • Системное представление Управления проектами IPMA
  • Национальные требования к компетенции специалистов по управлению проектами (НТК)

Процедуры управления проектом по методологии PRINCE2[править | править код]

  • Начало проекта (SU).
  • Запуск проекта (IP).
  • Планирование проекта (PL).
  • Управление проектом (DP).
  • Контроль стадий (CS).
  • Контроль границ стадий (SB).
  • Управление производством продукта (MP).
  • Завершение проекта (CP).

Прочие процедуры (управление командой, контрактами) вынесены «за рамки» методологии и называются инструментарием менеджера проекта. Кроме того, методология рассматривает «компоненты», которые состоят из Бизнес плана (Business Case), организации, планирования, управления рисками, управления качеством, управление конфигурацией, контроля и управления изменениями.

План управления проектом[править | править код]

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

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

Стандарты управления проектами[править | править код]

Международные стандарты управления (менеджмента) проектами:

  • ISO 10006:2003, Quality management systems — Guidelines for quality management in projects (в России принят как ГОСТ Р ИСО 10006—2005 «Системы менеджмента качества. Руководство по менеджменту качества при проектировании»)
  • ISO 21500:2012 Guidance on project management (в России принят как ГОСТ Р ИСО 21500-2014 Руководство по проектному менеджменту)[3]

Национальные стандарты с расширенной географией применения:

  • ANSI PMI PMBOK 6th Edition – A Guide to the Project Management Body of Knowledge (PMBOK Guide)
  • PRINCE2 (PRojects IN a Controlled Environment)
  • ISEB Project Management Syllabus
  • Oracle Application Implementation Method (AIM)

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

  • ГОСТ Р 54869—2011 «Проектный менеджмент. Требования к управлению проектом» [4] (Россия)
  • ГОСТ Р 54870—2011 «Проектный менеджмент. Требования к управлению портфелем проектов» [5] (Россия)
  • ГОСТ Р 54871—2011 «Проектный менеджмент. Требования к управлению программой» [6] (Россия)
  • NASA Project Management (США)
  • BSI BS 6079 (Великобритания)
  • APM Body of Knowledge (Великобритания)
  • OSCEng (Великобритания)
  • DIN 69901 (Германия)
  • V-Modell (Германия)
  • VZPM (Швейцария)
  • AFITEP (Франция)
  • Hermes method (Швейцария)
  • ANCSPM (Австралия)
  • CAN/CSA-ISO 10006-98 (Канада)
  • P2M (Япония)
  • C-PMBOK (Китай)
  • South African NQF4 (ЮАР)
  • CEPM (Индия)
  • PROMAT (Южная Корея)

Стандарты оценки компетенции менеджера проекта:

  • IPMA Individual Competence Baseline (IPMA ICB) (IPMA)
  • НТК (Национальные требования к компетентности специалистов) (Россия)
  • PMCDF (США)
  • NCB UA (National Competence Baseline, Version 3.0) (Украина)

Методологии управления проектами[править | править код]

  1. Методология PMI, сформулированная в виде стандарта PMBOK, базируется на концепции управления проектами через группу стандартных процессов. Однако последняя версия стандарта PMBOK отражает существенную коррекцию методологии в сторону итеративных методик.
  2. Методология IW URM (Unique Reliable Method), разрабатывалась и оттачивалась с тем, чтобы в любом проекте был гарантирован успех — цели клиента достигнуты в оговоренный срок, в рамках определенного бюджета и с необходимым качеством. Для реализации разных типов проектов используется набор различных процедур, документов и технологий, наиболее подходящих для конкретного типа проекта.
  3. Процесс управления проектами TenStep помогает менеджерам проектов успешно руководить проектами всех видов. TenStep предлагает пошаговый подход, начинающийся с простейших вещей и заканчивающийся настолько изощренными приемами, насколько это может потребоваться для конкретного проекта, включая шаблоны документов.
  4. Методология P2M базируется в ориентированности не на продукт или процессы, а на улучшение организации в результате выполнения проектов. Иными словами, методология описывает, как использовать полученный в результате выполнения проектов опыт для развития компании.

Программное обеспечение[править | править код]

Существует программное обеспечение как для управления проектами, так и управления портфелем проектов.

См. также[править | править код]

  • Управление программами
  • Портфель проектов
  • Офис управления проектами
  • Проектирование
  • Модель зрелости управления портфелями, программами и проектами

Примечания[править | править код]

Литература[править | править код]

  • Стэнли Э. Портни. Управление проектами для “чайников” = Project Management For Dummies. — М.: «Диалектика», 2006. — С. 368. — ISBN 0-7645-5283-X.
  • Рассел Д. Арчибальд. Управление высокотехнологичными программами и проектами = Managing High Technology Programs and Projects. — М.: Академия Ай-ти, 2004. — С. 472. — ISBN 5-98463-002-3.
  • Ньюэлл Майкл В. Управление проектами для профессионалов. Руководство по подготовке к сдаче сертификационного экзамена. — Кудиц-пресс, 2008. — С. 416. — ISBN 978-5-91136-009-2.
  • Том ДеМарко. Deadline. Роман об управлении проектами. — М: Вершина, 2006. — С. 143. — ISBN 5-9626-0132-7.
  • Ашманов Игорь Станиславович. Жизнь внутри пузыря. — М.: Манн, Иванов и Фербер, 2008. — С. 208. — ISBN 978-5-902862-79-6. Архивная копия от 3 июня 2009 на Wayback Machine
  • Ким Хелдман. Профессиональное управление проектами. — М.: Бином, 2005. — С. 517. — ISBN 5-94774-234-9.
  • Лапыгин Ю. Н. Управление проектами: от планирования до оценки эффективности. — М.: Омега-Л, 2008. — С. 252. — ISBN 978-5-370-00985-3.
  •  Богданов. В. В. Управление проектами. Корпоративная система — шаг за шагом. – М: : Манн, Иванов и Фербер, 2012. — 248 c. – ISBN 978-5-91657-232-2

Ссылки[править | править код]

  • Официальный сайт Института управления проектами (PMI)
  • Официальный сайт Международной ассоциации управления проектами (IPMA)

Источник