Управление проектами: различия между версиями

Материал из Википедии — свободной энциклопедии
Перейти к навигации Перейти к поиску
[отпатрулированная версия][непроверенная версия]
Содержимое удалено Содержимое добавлено
м подстановка даты в шаблон:Нет источника
 
(не показано 5 промежуточных версий 5 участников)
Строка 2: Строка 2:
'''Управление проектами''' — деятельность по решению задач и достижению поставленных целей [[Проект (в управленческой деятельности)|проекта]]. Управление проектами является частью системы [[менеджмент]]а предприятия.{{Нет АИ|19|7|2023}}
'''Управление проектами''' — деятельность по решению задач и достижению поставленных целей [[Проект (в управленческой деятельности)|проекта]]. Управление проектами является частью системы [[менеджмент]]а предприятия.{{Нет АИ|19|7|2023}}


Согласно [[PMBOK]], управление проектами есть применение знаний, навыков, инструментов и техник при выполнении проектной деятельности для достижения требований проекта и запланированных результатов. Проектные команды могут достигать результатов, используя широкий перечень подходов (предиктивный, гибридный, адаптивный)<ref>{{Книга|ссылка=https://www.pmi.org/pmbok-guide-standards/foundational/pmbok|автор=Project Management Institute|заглавие=A Guide to the Project Management Body of Knowledge (PMBOK® Guide) Seventh Edition and The Standard for Project Management|ответственный=Project Management Institute|год=2021|издательство=Project Management Institut|страницы=4|страниц=250|isbn=978-1628256642}} {{Wayback|url=https://www.pmi.org/pmbok-guide-standards/foundational/pmbok |date=20210414125903 }}</ref>.
Согласно [[PMBOK]], управление проектами есть применение знаний, навыков, инструментов и техник при выполнении проектной деятельности для достижения требований проекта и запланированных результатов. Проектные команды могут достигать результатов, используя широкий перечень подходов (предиктивный, гибридный, адаптивный)<ref>{{Книга|ссылка=https://www.pmi.org/pmbok-guide-standards/foundational/pmbok|автор=Project Management Institute|заглавие=A Guide to the Project Management Body of Knowledge (PMBOK Guide) — Seventh Edition and The Standard for Project Management|ответственный=Project Management Institute|год=2021|издательство=Project Management Institut|страницы=4|страниц=250|isbn=978-1628256642|archive-date=2021-04-14|archive-url=https://web.archive.org/web/20210414125903/https://www.pmi.org/pmbok-guide-standards/foundational/pmbok}}</ref>.


В основе современных методов управления проектами лежат методики структуризации работ и сетевого планирования, разработанные в конце 1950-х годов в США.{{Нет АИ|19|7|2023}}
В основе современных методов управления проектами лежат методики структуризации работ и сетевого планирования, разработанные в конце 1950-х годов в США.{{Нет АИ|19|7|2023}}
Строка 19: Строка 19:
Существует множество подходов к управлению жизненным циклом проекта/продукта в зависимости от типа проекта:
Существует множество подходов к управлению жизненным циклом проекта/продукта в зависимости от типа проекта:
* Предположение о неизменности требований, низких рисках, критичности сроков завершения. В этом случае применяется [[модель водопада|водопадный жизненный цикл]]. Для планирования и контроля хорошо применимы методы [[PERT]], [[метод критического пути]], [[метод освоенного объема]], [[диаграмма Ганта]]. Основная слабая сторона классического проектного менеджмента — нетолерантность к изменениям. Подход применим к строительным и инженерным проектам, в которых содержание проекта остаётся практически неизменным в течение всего проекта<ref name=autogenerated1>{{Cite web |url=http://www.pmservices.ru/project-management-news/top-7-metodov-upravleniya-proektami-agile-scrum-kanban-prince2-i-drugie/ |title=Топ-7 методов управления проектами: Scrum, Kanban, PRINCE2 и другие<!-- Заголовок добавлен ботом --> |access-date=2016-11-10 |archive-date=2016-11-10 |archive-url=https://web.archive.org/web/20161110035044/http://www.pmservices.ru/project-management-news/top-7-metodov-upravleniya-proektami-agile-scrum-kanban-prince2-i-drugie/ |deadlink=no }}</ref>.
* Предположение о неизменности требований, низких рисках, критичности сроков завершения. В этом случае применяется [[модель водопада|водопадный жизненный цикл]]. Для планирования и контроля хорошо применимы методы [[PERT]], [[метод критического пути]], [[метод освоенного объема]], [[диаграмма Ганта]]. Основная слабая сторона классического проектного менеджмента — нетолерантность к изменениям. Подход применим к строительным и инженерным проектам, в которых содержание проекта остаётся практически неизменным в течение всего проекта<ref name=autogenerated1>{{Cite web |url=http://www.pmservices.ru/project-management-news/top-7-metodov-upravleniya-proektami-agile-scrum-kanban-prince2-i-drugie/ |title=Топ-7 методов управления проектами: Scrum, Kanban, PRINCE2 и другие<!-- Заголовок добавлен ботом --> |access-date=2016-11-10 |archive-date=2016-11-10 |archive-url=https://web.archive.org/web/20161110035044/http://www.pmservices.ru/project-management-news/top-7-metodov-upravleniya-proektami-agile-scrum-kanban-prince2-i-drugie/ |deadlink=no }}</ref>.
* Предположение о критичности качества, при этом требования к сроку и ресурсам достаточно гибки (под качеством здесь понимается полнота удовлетворения потребностей, как известных, так и неизвестных заранее, часто создаваемых выходом нового продукта). В этом случае применяются спиральный жизненный цикл, [[гибкая методология разработки]] продукта, минимизация администрирования и неформальный подход к управлению проектом. К преимуществам относят гибкость и адаптивность под изменения требований. В качестве недостатков отмечают что гибкость может приводить к потере фокуса, усложнению внесения непредвиденных изменений<ref name=autogenerated1 />.
* Предположение о критичности качества, при этом требования к сроку и [[Управление ресурсами|ресурсам]] достаточно гибки (под качеством здесь понимается полнота удовлетворения потребностей, как известных, так и неизвестных заранее, часто создаваемых выходом нового продукта). В этом случае применяются спиральный жизненный цикл, [[гибкая методология разработки]] продукта, минимизация администрирования и неформальный подход к управлению проектом. К преимуществам относят гибкость и адаптивность под изменения требований. В качестве недостатков отмечают что гибкость может приводить к потере фокуса, усложнению внесения непредвиденных изменений<ref name=autogenerated1 />.
* Предположение о высоких неопределенностях и рисках проекта (для инновационных проектов и [[стартап]]ов). В этом случае применяются подходы управления [[бережливый стартап]], {{iw|Phase–gate model||en|Phase–gate model}}, {{iw|Управление реализацией преимуществ||en|Benefits realisation management}}<ref>{{Cite web |url=https://gantbpm.ru/metody-upravleniya-proektami/ |title=Методы управления проектами. 16 методологий управления проектами<!-- Заголовок добавлен ботом --> |access-date=2016-11-10 |archive-date=2016-11-11 |archive-url=https://web.archive.org/web/20161111061041/https://gantbpm.ru/metody-upravleniya-proektami/ |deadlink=no }}</ref>.
* Предположение о высоких неопределенностях и рисках проекта (для инновационных проектов и [[стартап]]ов). В этом случае применяются подходы управления [[бережливый стартап]], {{iw|Phase–gate model||en|Phase–gate model}}, {{iw|Управление реализацией преимуществ||en|Benefits realisation management}}<ref>{{Cite web |url=https://gantbpm.ru/metody-upravleniya-proektami/ |title=Методы управления проектами. 16 методологий управления проектами<!-- Заголовок добавлен ботом --> |access-date=2016-11-10 |archive-date=2016-11-11 |archive-url=https://web.archive.org/web/20161111061041/https://gantbpm.ru/metody-upravleniya-proektami/ |deadlink=no }}</ref>.


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


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

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


Даже при достижении поставленных целей и целесообразности изменений, проект может не соответствовать ожиданиям заинтересованных сторон. В проектах с высоким уровнем изменений требуется управление ожиданиями.
Даже при достижении поставленных целей и целесообразности изменений, проект может не соответствовать ожиданиям заинтересованных сторон. В проектах с высоким уровнем изменений требуется управление ожиданиями.
Строка 85: Строка 83:
* Управление производством продукта (MP).
* Управление производством продукта (MP).
* Завершение проекта (CP).
* Завершение проекта (CP).

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


Строка 95: Строка 94:
;Международные стандарты управления проектами
;Международные стандарты управления проектами
* [[ISO 10006]]:2003, Quality management systems — Guidelines for quality management in projects (в России принят как [[s:ru:ГОСТ Р ИСО 10006—2005|ГОСТ Р ИСО 10006—2005]] «Системы менеджмента качества. Руководство по менеджменту качества при проектировании»)
* [[ISO 10006]]:2003, Quality management systems — Guidelines for quality management in projects (в России принят как [[s:ru:ГОСТ Р ИСО 10006—2005|ГОСТ Р ИСО 10006—2005]] «Системы менеджмента качества. Руководство по менеджменту качества при проектировании»)
* [[ISO 21500]]:2012 Guidance on project management (в России принят как ГОСТ Р ИСО 21500-2014 Руководство по проектному менеджменту)<ref>{{Cite web |url=http://docs.cntd.ru/document/1200118020 |title=ГОСТ Р ИСО 21500-2014 «Руководство по проектному менеджменту» |access-date=2019-01-25 |archive-date=2019-01-25 |archive-url=https://web.archive.org/web/20190125131021/http://docs.cntd.ru/document/1200118020 |deadlink=no }}</ref>
* [[ISO 21500]]:2012 Guidance on project management (в России принят как ГОСТ Р ИСО 21500-2014 Руководство по проектному менеджменту)
* ISO 21504:2015 Project, programme and portfolio management — Guidance on portfolio management (в России принят как ГОСТ Р ИСО 21504-2016 «Управление проектами, программами и портфелем проектов. Руководство по управлению портфелем проектов»)
* ISO 21504:2015 Project, programme and portfolio management — Guidance on portfolio management (в России принят как ГОСТ Р ИСО 21504-2016 «Управление проектами, программами и портфелем проектов. Руководство по управлению портфелем проектов»)
* IEC 61160:2005 Design review (в России принят как ГОСТ Р МЭК 61160-2015 «Проектный менеджмент. Документальный анализ проекта»)
* IEC 61160:2005 Design review (в России принят как ГОСТ Р МЭК 61160-2015 «Проектный менеджмент. Документальный анализ проекта»)
Строка 105: Строка 104:
* [[ISEB Project Management Syllabus]]
* [[ISEB Project Management Syllabus]]
* [[Oracle Application Implementation Method]] (AIM)
* [[Oracle Application Implementation Method]] (AIM)
* [[DIN 69901|DIN 69900]] ([[Германия]]) — аналогичен российскому ГОСТ Р 56716-2015 «Проектный менеджмент. Техника сетевого планирования. Общие положения и терминология»<ref>{{Cite web|url=https://docs.cntd.ru/document/1200127270|title=ГОСТ Р 56716-2015|access-date=2021-05-20|archive-date=2021-05-20|archive-url=https://web.archive.org/web/20210520001702/https://docs.cntd.ru/document/1200127270|deadlink=no}}</ref>
* [[DIN 69901|DIN 69900]] ([[Германия]]) — аналогичен российскому ГОСТ Р 56716-2015 «Проектный менеджмент. Техника сетевого планирования. Общие положения и терминология»
* [[DIN 69901]] ([[Германия]]) — аналогичен российской серии ГОСТ Р 56715.xx-2015 «Проектный менеджмент. Системы проектного менеджмента»: «Часть 1. Основные положения»<ref>{{Cite web|url=https://docs.cntd.ru/document/1200127265|title=ГОСТ Р 56715.1-2015|access-date=2021-05-20|archive-date=2021-05-20|archive-url=https://web.archive.org/web/20210520001148/https://docs.cntd.ru/document/1200127265|deadlink=no}}</ref>; «Часть 2. Процессы и процессная модель»<ref>{{Cite web|url=https://docs.cntd.ru/document/1200127266|title=ГОСТ Р 56715.2-2015|access-date=2021-05-20|archive-date=2021-05-20|archive-url=https://web.archive.org/web/20210520001145/https://docs.cntd.ru/document/1200127266|deadlink=no}}</ref>; «Часть 3. Методы»<ref>{{Cite web|url=https://docs.cntd.ru/document/1200127267|title=ГОСТ Р 56715.3-2015|access-date=2021-05-20|archive-date=2021-05-20|archive-url=https://web.archive.org/web/20210520001142/https://docs.cntd.ru/document/1200127267|deadlink=no}}</ref>; «Часть 4. Данные и модель данных»<ref>{{Cite web|url=https://docs.cntd.ru/document/1200127268|title=ГОСТ Р 56715.4-2015|access-date=2021-05-20|archive-date=2021-05-20|archive-url=https://web.archive.org/web/20210520001145/https://docs.cntd.ru/document/1200127268|deadlink=no}}</ref>; «Часть 5. Термины и определения»<ref>{{Cite web|url=https://docs.cntd.ru/document/1200127269|title=ГОСТ Р 56715.5-2015}}</ref>
* [[DIN 69901]] ([[Германия]]) — аналогичен российской серии ГОСТ Р 56715<ref>ГОСТ Р 56715.1-2015 «Проектный менеджмент. Системы проектного менеджмента. Часть 1. Основные положения»</ref><ref>ГОСТ Р 56715.2-2015 «Проектный менеджмент. Системы проектного менеджмента. Часть 2. Процессы и процессная модель»</ref><ref>ГОСТ Р 56715.3-2015 «Проектный менеджмент. Системы проектного менеджмента. Часть 3. Методы»</ref><ref>ГОСТ Р 56715.4-2015 «Проектный менеджмент. Системы проектного менеджмента. Часть 4. Данные и модель данных»</ref><ref>ГОСТ Р 56715.5-2015 «Проектный менеджмент. Системы проектного менеджмента. Часть 5. Термины и определения»</ref>
* [[DIN 69901|DIN 699019]] ([[Германия]]) — аналогичен российской серии ГОСТ Р 56714.xx-2015 «Мультипроектный менеджмент. Управление проектом, портфелем проектов, программой»: «Часть 1. Основные положения»<ref>{{Cite web|url=https://docs.cntd.ru/document/1200127263|title=ГОСТ Р 56714.1-2015|access-date=2021-05-20|archive-date=2021-05-20|archive-url=https://web.archive.org/web/20210520002024/https://docs.cntd.ru/document/1200127263|deadlink=no}}</ref>; «Часть 2. Процессы и процессная модель»<ref>{{Cite web|url=https://docs.cntd.ru/document/1200127264|title=ГОСТ Р 56714.2-2015|access-date=2021-05-20|archive-date=2021-05-20|archive-url=https://web.archive.org/web/20210520002026/https://docs.cntd.ru/document/1200127264|deadlink=no}}</ref>
* [[DIN 69901|DIN 699019]] ([[Германия]]) — аналогичен российской серии ГОСТ Р 56714<ref>ГОСТ Р 56714.1-2015 «Мультипроектный менеджмент. Управление проектом, портфелем проектов, программой. Часть 1. Основные положения»</ref><ref>ГОСТ Р 56714.2-2015 «Мультипроектный менеджмент. Управление проектом, портфелем проектов, программой. Часть 2. Процессы и процессная модель»</ref>


;Российские стандарты управления проектами
;Российские стандарты управления проектами
* ГОСТ Р 54869-2011 «Проектный менеджмент. Требования к управлению проектом»<ref>{{Cite web |url=http://docs.cntd.ru/document/gost-r-54869-2011 |title=ГОСТ Р 54869-2011 Проектный менеджмент. Требования к управлению проектом |access-date=2015-12-09 |archive-date=2015-09-19 |archive-url=https://web.archive.org/web/20150919004614/http://docs.cntd.ru/document/gost-r-54869-2011 |deadlink=no }}</ref> (Россия)
* ГОСТ Р 54869-2011 «Проектный менеджмент. Требования к управлению проектом»
* ГОСТ Р 54870-2011 «Проектный менеджмент. Требования к управлению портфелем проектов»<ref>{{Cite web |url=http://docs.cntd.ru/document/gost-r-54870-2011 |title=ГОСТ Р 54870-2011 Проектный менеджмент. Требования к управлению портфелем проектов |access-date=2015-12-09 |archive-date=2015-09-19 |archive-url=https://web.archive.org/web/20150919005626/http://docs.cntd.ru/document/gost-r-54870-2011 |deadlink=no }}</ref> (Россия)
* ГОСТ Р 54870-2011 «Проектный менеджмент. Требования к управлению портфелем проектов»
* ГОСТ Р 54871-2011 «Проектный менеджмент. Требования к управлению программой»<ref>{{Cite web |url=http://docs.cntd.ru/document/gost-r-54871-2011 |title=ГОСТ Р 54871-2011 Проектный менеджмент. Требования к управлению программой |access-date=2015-12-09 |archive-date=2015-09-19 |archive-url=https://web.archive.org/web/20150919003331/http://docs.cntd.ru/document/gost-r-54871-2011 |deadlink=no }}</ref> (Россия)
* ГОСТ Р 54871-2011 «Проектный менеджмент. Требования к управлению программой»


;Национальные стандарты управления проектами
;Национальные стандарты управления проектами
* [[NASA Project Management]] ([[США]])
* [[NASA Project Management]] ([[США]])
* [[BSI BS 6079]], [[BS 1192]], [[APM Body of Knowledge]], [[OSCEng]] ([[Великобритания]])
* [[BSI BS 6079]], [[BS 1192]], [[APM Body of Knowledge]], [[OSCEng]] ([[Великобритания]])
* [[V-Modell]] ([[Германия]])
* [[V-Model]] ([[Германия]])
* [[VZPM]], [[Hermes method]] ([[Швейцария]])
* [[VZPM]], [[Hermes method]] ([[Швейцария]])
* [[AFITEP]] ([[Франция]])
* [[AFITEP]] ([[Франция]])
Строка 131: Строка 130:
* [[IPMA Individual Competence Baseline (IPMA ICB)]] ([[IPMA]])
* [[IPMA Individual Competence Baseline (IPMA ICB)]] ([[IPMA]])
* [[НТК (Национальные требования к компетентности специалистов)]] (Россия)
* [[НТК (Национальные требования к компетентности специалистов)]] (Россия)
* ГОСТ Р 52807-2007 «Руководство по оценке компетентности менеджеров проектов»<ref>{{Cite web|url=https://docs.cntd.ru/document/1200073588|title=ГОСТ Р 52807-2007|access-date=2021-05-20|archive-date=2021-05-20|archive-url=https://web.archive.org/web/20210520002310/https://docs.cntd.ru/document/1200073588|deadlink=no}}</ref> (Россия)
* ГОСТ Р 52807-2007 «Руководство по оценке компетентности менеджеров проектов»
* ГОСТ Р 53892-2010 «Руководство по оценке компетентности менеджеров проектов. Области компетентности и критерии профессионального соответствия»<ref>{{Cite web|url=https://docs.cntd.ru/document/1200081846|title=ГОСТ Р 53892-2010|access-date=2021-05-20|archive-date=2021-05-20|archive-url=https://web.archive.org/web/20210520002309/https://docs.cntd.ru/document/1200081846|deadlink=no}}</ref> (Россия)
* ГОСТ Р 53892-2010 «Руководство по оценке компетентности менеджеров проектов. Области компетентности и критерии профессионального соответствия»
* [[PMCDF]] ([[США]])
* [[PMCDF]] ([[США]])
* [[NCB UA]] (National Competence Baseline, Version 3.0) ([[Украина]])
* [[NCB UA]] (National Competence Baseline, Version 3.0) ([[Украина]])
Строка 144: Строка 143:


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


== См. также ==
== См. также ==
Строка 150: Строка 149:
* [[Проектирование]]
* [[Проектирование]]
* [[Портфель проектов]]
* [[Портфель проектов]]
* [[P3M3|Модель зрелости управления портфелями, программами и проектами]]
* [[Управление изменениями|Управление изменениями проекта]]
* [[Управление изменениями|Управление изменениями проекта]]
* [[Управление программами]]
* [[Управление программами]]
Строка 170: Строка 168:
* [http://www.pmi.org/ Официальный сайт Института управления проектами (PMI)]
* [http://www.pmi.org/ Официальный сайт Института управления проектами (PMI)]
* [https://www.ipma.world/ Официальный сайт Международной ассоциации управления проектами (IPMA)]
* [https://www.ipma.world/ Официальный сайт Международной ассоциации управления проектами (IPMA)]

{{ВС}}
{{ВС}}
{{Проектный менеджмент}}
{{Проектный менеджмент}}

Текущая версия от 16:23, 9 июня 2024

Управление проектами
Изображение
Соответствующая квалификация Project Management Professional[вд]
Логотип Викисклада Медиафайлы на Викискладе

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

Согласно PMBOK, управление проектами есть применение знаний, навыков, инструментов и техник при выполнении проектной деятельности для достижения требований проекта и запланированных результатов. Проектные команды могут достигать результатов, используя широкий перечень подходов (предиктивный, гибридный, адаптивный)[1].

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

Классическая форма тройственной ограниченности

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

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

The Project Management Triangle

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Определение требований к проекту
  • Постановка чётких и достижимых целей
  • Балансирование конкурирующих требований по качеству, возможностям, времени и стоимости
  • Адаптация спецификаций, планов и подходов для нужд и проблем различных заинтересованных лиц (стейкхолдеров)
Процедуры управления проектом по методологии 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 Руководство по проектному менеджменту)
  • ISO 21504:2015 Project, programme and portfolio management — Guidance on portfolio management (в России принят как ГОСТ Р ИСО 21504-2016 «Управление проектами, программами и портфелем проектов. Руководство по управлению портфелем проектов»)
  • IEC 61160:2005 Design review (в России принят как ГОСТ Р МЭК 61160-2015 «Проектный менеджмент. Документальный анализ проекта»)
  • IEC 62198:2013 Managing risk in projects — Application guidelines (в России принят как ГОСТ Р МЭК 62198-2015 «Проектный менеджмент. Руководство по применению менеджмента риска при проектировании»)
Национальные стандарты управления проектами с расширенной географией применения
Российские стандарты управления проектами
  • ГОСТ Р 54869-2011 «Проектный менеджмент. Требования к управлению проектом»
  • ГОСТ Р 54870-2011 «Проектный менеджмент. Требования к управлению портфелем проектов»
  • ГОСТ Р 54871-2011 «Проектный менеджмент. Требования к управлению программой»
Национальные стандарты управления проектами

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

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

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

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

Программное обеспечение

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

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

Примечания

[править | править код]
  1. Project Management Institute. A Guide to the Project Management Body of Knowledge (PMBOK Guide) — Seventh Edition and The Standard for Project Management / Project Management Institute. — Project Management Institut, 2021. — С. 4. — 250 с. — ISBN 978-1628256642. Архивировано 14 апреля 2021 года.
  2. 1 2 Топ-7 методов управления проектами: Scrum, Kanban, PRINCE2 и другие. Дата обращения: 10 ноября 2016. Архивировано 10 ноября 2016 года.
  3. Методы управления проектами. 16 методологий управления проектами. Дата обращения: 10 ноября 2016. Архивировано 11 ноября 2016 года.
  4. ГОСТ Р 56715.1-2015 «Проектный менеджмент. Системы проектного менеджмента. Часть 1. Основные положения»
  5. ГОСТ Р 56715.2-2015 «Проектный менеджмент. Системы проектного менеджмента. Часть 2. Процессы и процессная модель»
  6. ГОСТ Р 56715.3-2015 «Проектный менеджмент. Системы проектного менеджмента. Часть 3. Методы»
  7. ГОСТ Р 56715.4-2015 «Проектный менеджмент. Системы проектного менеджмента. Часть 4. Данные и модель данных»
  8. ГОСТ Р 56715.5-2015 «Проектный менеджмент. Системы проектного менеджмента. Часть 5. Термины и определения»
  9. ГОСТ Р 56714.1-2015 «Мультипроектный менеджмент. Управление проектом, портфелем проектов, программой. Часть 1. Основные положения»
  10. ГОСТ Р 56714.2-2015 «Мультипроектный менеджмент. Управление проектом, портфелем проектов, программой. Часть 2. Процессы и процессная модель»

Литература

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