Проектная деятельность
план-конспект занятия (10 класс)

1.1. Роль проектной деятельности в современном мире

«Из всех трудностей, с которыми столкнулись НАСА, отправляя человека на Луну, управление было, наверное, самой сложной задачей».
Роджер Лаунис, историк НАСА

Люди реализовывали проекты с древних времен. Строительство Египетских пирамид, Великой Китайской стены, аэрокосмические программы и проекты (запуск первого искусственного спутника Земли, легендарный первый в мировой истории полет человека в космос, осуществленный 12 апреля 1961 года, высадка человека на Луну) являются яркими примерами проектов прошлого, результаты которых сыграли важную роль в истории человечества.

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

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

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

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

В 1999 году начата практика фиксирования накопленного опыта управления проектами. В результате реализации NASA космической программы «Аполлон» накоплен значительный опыт, т.к. требовалось организовать беспрецедентные ресурсы и в кратчайшие сроки добиться требуемого результата. И историческое бюро NASA приняло решение опубликовать монографию «Managing the Moon Program», содержащую воспоминания ключевых участников процесса управления «Аполлоном». Книга содержит описание основных подходов к управлению «Аполлоном». В книге отмечаются наиболее удачные практики, направленные на налаживание коммуникаций между всеми участниками и организацию эффективного выполнения программы. Одна из практик – это идея организовать взаимодействие за счет создания структуры управления программой параллельно с функциональной структурой Центра пилотируемых космических кораблей с распределением и фиксированием ответственности. Еще одной удачной практикой является разбивка программы на несколько фаз. Использование различных инструментов управления программой привело к успеху, и 16–24 июля 1969 года жители Земли впервые в истории совершили посадку на поверхность Луны.

Далее практика фиксирования опыта управления проектами продолжила свое развитие в создании таких документов как своды знаний и стандарты по управлению проектами.

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

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

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

В докладах представителей российской ассоциации управления проектами «СОВНЕТ» приводятся следующие основные причины роста интереса к управлению проектами (по данным Volkswagen Coaching GmbH ProjektManagement и др.):

• возрастание сложности проектов – 27 %;
• увеличение числа проектов – 25 %;
• ужесточение требований к срокам – 23 %;
• конкуренция и требования рынка – 11 %;
• требования к качеству продукта – 9 %;
• мотивация персонала – 4 %;
• новое руководство – 1 %.

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

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

Рекомендуемая литература

Арчибальд Р. А88 Управление высокотехнологичными программами и проектами / Рассел Д. Арчибальд; Пер. с англ. Мамонтова Е. В.; Под ред. А. Д. Баженова, А. О. Арефьева. – 3-е изд., перераб. и доп. – М. : Компания АйТи ; ДМК Пресс, 2010. – 464 с.

Управление проектами: учеб. пособие для студентов, обучающихся по специальности «Менеджмент организации» / И. И. Мазур [и др.]; под общ. ред. И. И. Мазура и В. Д. Шапиро. – 6-е изд., стер. – М.т: Издательство «ОмегаЛ», 2010. – 960 с.: ил., табл. – (Современное бизнесобразование).

Управление проектом. Основы проектного управления : учебник / коллектив авторов; под ред. проф. М.Л. Разу. – 3те изд., перераб. и доп. – М. : КНОРУС, 2010. – 760 c.

Разу М.Л., Воропаев В.И., Якутии Ю.В. и др. Управление программами и проектами: 17-модульная программа для менеджеров «Управление развитием организации». Модуль 8. – М: ИНФРА-М, 2000. – 320 с.

Полковников А. В. Управление проектами. Полный курс МВА/ А. В. Полковников, М. Ф. Дубовик. – М.: ЗАО «Олимп-Бизнес», 2015. – 552 с.

1.3. Причины неудач и критерии успешности проектов. Что определяет, является проект «хорошим» или «плохим»?

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

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

Зададимся вопросом: все ли проекты успешно завершаются? Очевидно, что нет.

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

По данным статистического портала ожидалось, что по итогам 2019 г. расходы на программное обеспечение для предприятий достигнет 457 миллиардов долларов США. В том же году расходы на мировом рынке информационных технологий прогнозировались на уровне 3740 млрд долларов США, в то время как на ИТ-услуги, второй по величине сегмент после услуг связи, должны были составить 1 016 млрд долларов США.

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

Исследование (Standish Group), основанное на анализе 50 000 программных проектов показало, что менее 40 % проектов были выполнены с требуемым качеством (см. рисунок).

Статистика исследований Standish Group по успешным, проблемным и провальным проектам

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

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

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

Успех проекта, успешность проекта

Согласно «Национальным требованиям к компетентности специалистов» успех проекта, как правило, означает получение всеми заинтересованными сторонами результатов, оправдывающих их ожидания, достижение целей и выполнение требований. Если такие цели и требования сформулированы, критериями успешности проекта могут выступать количественные показатели, отражающие степень достижения целей проекта или выполнения определенных требований [10].

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

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

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

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

Критерии успешности проекта

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

Критерии успешности проекта – это совокупность показателей, которые дают возможность судить о степени успешности выполнения проекта [12].

Общий критерий успешности проекта – это достижение целей проекта в запланированное время и в рамках запланированных ресурсов [12].

В качестве критериев успешности проекта можно выделить следующие:

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

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

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

И еще раз подчеркнем, что использование подходов проектного управления помогает привести проект к заявленной цели. и позволит достичь экономии времени выполнения проекта в среднем на 20–30 % и экономии расходов проекта в среднем на 10–15 %.

Факторы успеха проекта

Факторы успеха проекта – внешние и внутренние условия, которые способствуют обеспечению успешности проекта, от них напрямую зависит успешная реализация проекта [12].

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

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

Факторы, связанные с командой проекта:

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

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

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

Факторы, связанные с обстоятельствами

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

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

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

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

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

Модель ус, IPMA

Для того чтобы определить, является ли проект или программа «хорошим» или «плохим» и что имеется в виду при стремлении к совершенству в реализации проектов и программ, IPMA определен стандарт для успешных проектов, Project Excellence Baseline® или PEB.

Модель PEB основана на модели EFQM (the European Foundation for Quality Management, Европейского фонда управления качеством), но адаптирована к области управления проектами и программами.

При оценке и обеспечении качества проектов и программ в модели PEB рассматриваются три области:

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

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

[10] Управление проектами: Основы профессиональных знаний, Национальные требования к компетентности специалистов (NCB – SOVNET National Competence Baseline Version 3.1), 2014, стр. 77.

[11] Разу М.Л., Воропаев В.И., Якутии Ю.В. и др. Управление программами и проектами: 17-модульная программа для менеджеров «Управление развитием организации»

[12] Полковников А. В. Управление проектами. Полный курс МВА/ А. В. Полковников, М. Ф. Дубовик. – М. : ЗАО «Олимп-Бизнес». 2015. – стр. 62– 66.

1.4. Виды и классификация проектов

Давайте прежде всего ответим на вопрос: для чего проекты разделять по видам и зачем их классифицировать?

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

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

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

В Национальных требованиях к компетентности специалистов [13] приведены варианты классификации (см. таблицу)

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

Рекомендованные Рассел Д. Арчибальдом категории проектов (см. таблицу)

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

Рассел Д. Арчибальд предлагает следующую классификацию для проектов каждой категории:

1. Объем проекта по количеству денег и других ограниченных ресурсов (людей, специалистов узкого профиля, производственных мощностей).
2. Сложность проекта – многообразие его целей и содержания, а также количество участвующих в нем внутренних подразделений и внешних организаций (последнее часто определяет количество требуемых специалистов узкого профиля, источников технологии или финансирования).
3. Внешний или внутренний заказчик. Если проект должен быть выполнен по формальному контракту с внешним заказчиком, это приводит к возникновению ряда управленческих проблем, нехарактерных для проекта, выполняемого для внутреннего заказчика и для внутренних нужд.
4. Степень участия заказчика в проекте. Во многих проектах заказчик должен выполнять значительный объем работ, принимать важные решения и своевременно предоставлять ключевые результаты, если он хочет, чтобы проект выполнялся в соответствии с расписанием. Задержки со стороны заказчика – частая причина отставания проектов от графика и увеличения их стоимости. Крайне важно, чтобы та часть проекта, исполнение которой входит в обязанности заказчика, была тщательно распланирована и согласована с остальными частями.
5. Уровни риска в проекте. Основные факторы, влияющие на степень риска:

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

Рассел Д. Арчибальд говорит, что целесообразно выделять по крайней мере два класса проектов в категории, например, большие и малые.

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

• крупные проекты – те, которые в силу большого объема, высокой сложности и/или высокого риска требуют:

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

• малые проекты – те, которые в силу малого объема, невысокой сложности и/ или низкого риска допускают:

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

Некоторые организации, кроме этих больших и малых проектов, несут ответственность за работы, получившие название мегапроектов. Это особенно крупные проекты, в которых обычно задействовано множество компаний и/ или учреждений. Международные предприятия по освоению космического пространства, транспортные и энергетические корпорации – вот лишь немногие примеры таких мегапроектов. Они могут финансироваться из различных источников: правительственных, частных, банков международного развития; часто являются интернациональными и выходят за рамки государственных границ. Мегапроекты лежат за пределами вышеприведенной классификации проектов (больших и малых) и чрезвычайно редки случаи, когда одна организация одновременно принимается за два или более таких проектов [14].

[13] Управление проектами: Основы профессиональных знаний, Национальные требования к компетентности специалистов (NCB –SOVNET National Competence Baseline Version 3.1). 2014, стр. 62–63.

[14] Арчибальд Р. А88 Управление высокотехнологичными программами и проектами / Рассел Д. Арчибальд ; Пер. с англ. Е. В. Мамонтова; под ред. А. Д. Баженова, А. О. Арефьева. – 3-е изд., перераб. и доп. – М. : Компания АйТи ; ДМК Пресс, 2010, стр. 464.

2.1. Международные и национальные стандарты по управлению проектами

Ответить на вопрос «что необходимо делать, чтобы эффективно управлять проектами?» невозможно без знания стандартов в области управления проектами.

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

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

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

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

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

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

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

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

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

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

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

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

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

Отдельные вопросы в сфере проектного управления регулируются международными стандартами серии ISO, такие как ISO 21500:2012 Guidance on project management (руководство по управлению проектами) и другие [1].

Международная Ассоциация управления проектами, IPMA (International Project Management Association), ICB

IPMA – первая международная ассоциация по управлению проектами, основанная в 1965 году. В 1996 году организация была переименована в IPMA (ранее задуманная в 1964 году как INTERnational NETwork (the INTERNET) и основанная в 1965 как IMSA (International Management Systems Association) и начала свою деятельность по сертификации. IPMA распространилась из Европы в Азию, Африку, на Ближний Восток, Австралию и Америку. Сегодня IPMA объединяет 70 национальных ассоциаций-членов. Национальные ассоциации развивают управление проектами на своих территориях, взаимодействуя с заинтересованными сторонами и расширяя отношения с государственными органами, корпорациями, университетами и колледжами, а также учебными организациями и консалтинговыми компаниями. Некоторые национальные ассоциации также называются IPMA, некоторые имеют собственное название.

IPMA разработаны международные стандарты в области управления проектами, программами и портфелями:

• IPMA Individual Competence Baseline®, ICB version 4 для менеджеров проектов, программ и портфелей;
• IPMA Project Excellence Baseline® (PEB) – модель, определяющая качество проектов или программ;
• IPMA Organisational Competence Baseline® (OCB) для организаций.

На основе ICB4 IPMA также определены квалификационные стандарты для тренеров, инструкторов и консультантов в области проектов, программ и портфелей, ICB4CCT.

IPMA ICB4 определяет элементы компетентности, которыми должны обладать профессионалы в области управления проектами, программами и портфелями проектов.

В IPMA ICB4 представлены три области – управление проектами, управление программами и управление портфелями проектов.

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

• люди (people). Элементы компетентности «люди» определяют личные качества, знания, умения и навыки межличностного взаимодействия, необходимые для успешной работы в управлении проектом/программой/портфелем проектов;
• практика (practice). Элементы компетентности «практика» определяют общие методы и средства, знание которых необходимы для управления проектами/программами/портфелями проектов;
• контекст (context). Элементы компетентности «контекст» служат навигаторами для профессионалов в работе с окружением, в котором реализуется проект/программа/портфель проектов [2].

Для того чтобы показать, как различные элементы компетентности могут быть применены в Agile среде IPMA был разработан IPMA reference Guide ICB4 in an Agile World.

Ассоциация управления проектами «СОВНЕТ», НТК

Единственный в России национальный представитель Международной ассоциации управления проектами (IPMA) с 1991 года – Ассоциация управления проектами «СОВНЕТ». Ассоциация управления проектами «СОВНЕТ» – это добровольный союз профессионалов, осуществляющих научные исследования и разработки, обучение и сертификацию специалистов в области управления проектами, подготовку, выполнение и управление проектами в различных сферах деятельности.

«СОВНЕТ» основана 25 октября 1990. С февраля 1991 года «СОВНЕТ» является национальным российским членом Международной ассоциации управления проектами – IPMA.

Группой сертифицированных специалистов СОВНЕТ на основе и в соответствии с Международными Требованиями к Компетенции специалистов по управлению проектами (ICB, IPMA) разработаны Национальные требования к компетентности специалистов по Управлению проектами (НТК). НТК является основополагающим документом национальной сертификационной программы специалистов по управлению проектами.

В НТК изложены основы сертификационной программы Международной Ассоциации Управления Проектами – IPMA и методологические принципы формирования на ее основе Национальной Программы сертификации специалистов по управлению проектами. Представлены основы профессиональных знаний по управлению проектами, профессиональные требования, предъявляемые к знаниям, опыту, навыкам, мастерству, а также личным качествам специалистов [2].

Институт управления проектами PMI (Project Management Institute), PMBOK® Guide  

PMI основан в 1969 году. PMI разработан Guide to the Project Management Body of Knowledge (PMBOK® Guide). В шестую версию, вышедшую в 2017 году, наряду с традиционными подходами включена информация о гибких технологиях управления проектами и в партнерстве с Agile Alliance создан Agile Practice Guide. Шестое издание PMBOK® Guide и Agile Practice Guide разработаны, чтобы дополнять друг друга.

Основополагающим стандартами, выпущенными PMI, также являются:

• The Standard for Risk Management in Portfolios, Programs, and Projects; 
• The Standard for Organizational Project Management;
• The PMI Guide to Business Analysis;
• The Standard for Program Management;
• The Standard for Portfolio Management;
• Organizational Project Management Maturity Model (OPM3®).

Помимо основополагающих стандартов PMI разработаны также:

• Practice Standards & Frameworks. Описывают использование инструментов, техник или процесса, указанных в основополагающих стандартах;
• Practice Guides. Предоставляют вспомогательную информацию и инструкции, которые помогают применять стандарты PMI.

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

PRINCE2

PRINCE2 (аббревиатура для PRojects IN Controlled Environments (проекты в контролируемых средах) – это де-факто метод, основанный на процессах, для эффективного управления проектами. PRINCE2 широко используется правительством Великобритании и широко используется в частном секторе, как в Великобритании, так и за рубежом.

Ключевые особенности PRINCE2:

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

Автономная некоммерческая организация «Центр оценки и развития проектного управления» (АНО «ЦОРПУ»), ПМ СТАНДАРТ

АНО «ЦОРПУ» – независимая площадка для работы экспертов, развивающих проектное управление в России. Создана в 2014 году.

АНО «ЦОРПУ» активно содействует развитию проектного управления в Российской Федерации и СНГ, повышению эффективности применения принципов, методов и инструментов проектного управления в коммерческих и государственных организациях.

Основные направления работы АНО «ЦОРПУ»:

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

По инициативе и при участии экспертов АНО «ЦОРПУ» разработан проект российского ГОСТ «Система менеджмента проектной деятельности», эксперты Центра задействованы в разработке ГОСТ «Проектный офис». Эксперты ЦОРПУ включены в международные группы по разработке стандартов ISO.

На площадке АНО «ЦОРПУ» развивается система развития, оценки и применения проектного управления ПМ СТАНДАРТ и, в частности, сертификация ПМ СТАНДАРТ.

P2M

P2M – это японский стандарт «Руководство по управлению инновационными проектами и программами предприятий», который поддерживается Ассоциацией проектных менеджеров Японии (PMAJ), стандарт действует с 2001 года.

PMAJ (Project Management Association of Japan) основана 5 октября 2005 года объединением Project Management Professionals Certification Center (PMCC) и Japan Project Management Forum (JPMF) [3].

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

Целью проекта, согласно стандарту P2M, является не создание продукта/услуги, а создание ценности, инновации, достижение миссии организации. Для этого в процессе выполнения проекта проводится анализ соответствия результатов проекта заявленным на фазе планирования ценностям и миссии проекта.

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

Agile Alliance

В феврале 2001 года на горнолыжном курорте Snowbird в горах Уосатч, штат Юта, семнадцать человек встретились, чтобы покататься на лыжах. Появился «Манифест гибкой разработки программного обеспечения» (Agile Manifesto), подписанный всеми участниками. Эта группа единомышленников назвала себя «Agile Alliance».

Авторы Agile Manifesto выбрали «Agile», потому что это слово представляло адаптивность и реакцию на изменения, которые были так важны для их подхода.

Сегодня Agile Alliance – некоммерческая организация с более чем 60 000 членов и подписчиков по всему миру, занимающаяся продвижением и поддерживающая концепцию Agile Software Development.

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

[1] Управление проектами: Основы профессиональных знаний, Национальные требования к компетентности специалистов (NCB – SOVNET National Competence Baseline Version 3.1). 2014, стр. 143.

[2] Ассоциация управления проектами «СОВНЕТ». http://sovnet.ru

[3] Project Management Association of Japan (PMAJ). https://www.pmaj.or.jp

3.1. Цели и содержание проекта

Для определения содержания проекта прежде всего необходимо определить цель проекта.

После того, как сформулирована цель, можно определить

• Продукт проекта (или результат).
• Стратегию проекта.
• Границы проекта.
• Задачи и работы проекта, которые должны быть выполнены для создания продукта.

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

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

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

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

У проекта может быть несколько целей.

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

Достигнутые договоренности должны быть задокументированы, согласованы и быть включены в документ «Устав проекта».

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

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

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

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

• Specific (Конкретная). Нацелена на конкретную область для улучшения.
• Measurable (Измерима). Количественно определена или, по крайней мере, предлагать индикаторы прогресса.
• Аssignable (Назначаема). Определено, кто будет выполнять.
• Realistic (Реалистична). Определяет, какие результаты могут быть реально достигнуты при наличии доступных ресурсов.
• Time-bound (Ограничена во времени). Определяет, когда могут быть достигнуты результаты.

Можно отметить, что существуют и другие расшифровки аббревиатуры SMART. Так, например, часто используются критерии Attainable (Достижима) вместо Аssignable и Relevant (Актуальна) вместо Realistic.

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

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

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

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

2. Мозговой штурм (мозговая атака, brainstorming) – метод командного обсуждения, при котором участникам обсуждения предлагают максимально большее количество идей. Затем идеи оцениваются и отбираются наиболее удачные. При проведении мозгового штурма крайне важен полный запрет на критику и оценку высказываемых идей.
3. Метод «635» - модификация мозгового штурма. Метод был разработан Берндом Рорбахом Цифры «635» означают: 6 человек, которые выражают 3 идеи в течение 5 минут. Участников знакомят с проблемой за 2-3 дня. Метод проводится в письменной форме без взаимодействия участников. Каждому участнику выдается бланк с описание проблемы, в который необходимо занести 3 идеи в течение 5 минут. После бланки передаются по кругу, и каждый участник также в течение 5 минут делает 3 замечания к предложенным другими идеям (изменяет/ дополняет/ опровергает). После собранная информация анализируется и проводится отбор идей.
4. «Метод Уолта Диснея». Метод, при котором проблема рассматривается последовательно с трёх точек зрения: творческой («мечтатель»), реалистичной («реалист») и критической («критик»). Автор методики – Роберт Б. Дилтс.  Метод может быть применен как индивидуально, так и для организации групповой работы.
5. Другие.

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

После того, как определена цель проекта, можно определить продукт (результат) проекта.

Продукт проекта (либо результат) - основной конечный результат (актив), который предоставляется заказчику.

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

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

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

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

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

В зависимости от выбранной стратегии определяются задачи и работы проекта («какие действия?» необходимо выполнить).

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

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

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

Рисунок 1. Взаимосвязь элементов содержания проекта между собой и с целями компании

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

Рекомендуемая литература

• Полковников А. В. Управление проектами. Полный курс МВА/ А. В. Полковников, М. Ф. Дубовик. – М.: ЗАО «Олимп-Бизнес», 2015. – 552 с.
• Управление проектами: Основы профессиональных знаний, Национальные требования к компетентности специалистов (NCB – SOVNET National Competence Baseline Version 3.1). – М.: ЗАО «Проектная ПРАКТИКА», 2014. - 259 с.
• Doran, G. T. (1981). There's a S.M.A.R.T. way to write management's goals and objectives. Management Review, Volume 70, Issue 11(AMA FORUM). – P. 35-36.

[1] Doran, G. T. (1981). There's a S.M.A.R.T. way to write management's goals and objectives. Management Review, Volume 70, Issue 11(AMA FORUM), Pages 35-36.

[2] Полковников А. В. Управление проектами. Полный курс МВА/ А. В. Полковников, М. Ф. Дубовик - М.: ЗАО «Олимп-Бизнес», 2015, стр. 73.

[3] Управление проектами: Основы профессиональных знаний, Национальные требования к компетентности специалистов (NCB – SOVNET National Competence Baseline Version 3.1), 2014, стр. 74.