Стандарты управления проектами
Рассмотрим главные стандарты, применяемые компаниями в проектном менеджменте.
PMBOK®. Project Management Body of Knowledge – свод знаний по управлению проектами, разработанный в США Институтом Управления проектами (Project Management Institute – PMI). Это универсальный стандарт, который можно использовать в любой индустрии. PMBOK основан на процессной модели – для каждого процесса указываются элементы входов (документов, решений), рекомендации инструментов и методов, которые нужно использовать в каждом процессе, результаты процессов – выходы. Стандарт носит рекомендательный характер – какие-то из рекомендаций можно не использовать.
ГОСТ Р 54869-2011. Российский стандарт по управлению проектами основан на стандарте PMBOK, но адаптирован под реалии российского бизнеса. Стандарт представлен в дополнительных материалах.
ICB IPMA. International Competence Baseline of the International Project Management Association. Европейский стандарт, разработанный международной ассоциацией управления проектами, который использует компетентностную модель. В нем предлагается развивать компетенции руководителей проектов – технические, управленческие, лидерские и т.д.
ISO 21500. Международный стандарт по управлению проектами. Его можно назвать облегченным PMBOK – он похож на американский стандарт, но значительно сжат. Процессная модель включает только входы и выходы – без описания инструментов и методов. Этот стандарт рекомендует в каждом процессе использовать собственные инструменты и методы.
PRINCE2. Стандарт, разработанный в Великобритании. Его используют прежде всего при управлении IT-проектами. Он отличается от PMBOK тем, что носит инструктивный характер. Он более жесткий. Стандарт предлагает инструкции, которым необходимо следовать. Описывает шаги – как использовать те или иные рекомендации и инструменты, в каком направлении двигаться.
P2M. Японский стандарт, который заключается в управлении тремя инновациями – управлении проектами, управлении программами проектов, управлении портфелями проектов. В отличие от других стандартов, методология этого стандарта ориентирована не на продукт, а на улучшение организации в результате выполнения проектов. Стандарт описывает, как сочетать проекты и программы с бизнес-стратегией компании и использовать полученный в результате выполнения проектов опыт для развития и продвижения к стратегическим целям.
Цель проекта – создание нового, уникального результата, продукта, услуги. Цель программы проектов – достижение выгод в бизнесе компании (например, повышение дохода, извлечение прибыли, возврат инвестиций, расширение присутствия на рынке и т.д.). Цель портфеля проектов – достижение стратегической цели компании. Внутри портфелей могут быть программы проектов, внутри программ проектов – проекты и блоки операционной деятельности. Руководитель программы управляет руководителями проектов и руководителями операционных блоков, которые входят в программу. Директор портфеля обязан консолидировать выгоды – результаты программ, вложенных в портфель.
C-PMBOK. Китайский стандарт управления проектами, в основе которого американский PMBOK. Он учитывает культурные, ментальные, исторические, законодательные отличия от американской модели управления проектами.
Помимо классических стандартов, выделяют гибкие подходы – аgile и гибридные методологии.
Agile. Гибкие подходы к управлению проектами, прежде всего в области IT. Само слово означает «проворный». В этих подходах проект разбивается на короткие подпроекты (инкременты) длительностью от 1 до 4 недель. По результатам каждого инкремента появляется промежуточный результат, который затем объединяется с другими. Такой подход позволяет руководителю проекта оперативно и гибко реагировать на изменяющиеся требования заказчиков.
Гибридные Методологии. Объединяют классические и гибкие.
Для эффективного управления проектами, стоит использовать лучшие практики, которые описывают в международных стандартах. В зависимости от проекта, можно выбрать классический или гибкий подход.
Концепция заинтересованных сторон проекта и ключевые роли
Кто участвует в реализации проекта
Как уже говорили выше, спонсор (куратор) проекта не обязательно тот, кто финансирует проект. Например, если компания работает в сегменте b2b и подписала договор с корпоративным клиентом, именно корпоративный заказчик финансирует проект. Но он не будет спонсором проекта.
Спонсор (куратор) проекта обязательно должен оказывать административную или организационную поддержку. Например, если в ходе реализации проекта возникает проблема, с которой руководитель не может справиться, он обращается к куратору (так называемая эскалация проблемы – перенос решения проблемы на более высокий организационный уровень). Стандарт PMBOK рекомендует в качестве куратора проекта, особенно крупного, назначать топ-менеджера компании, чтобы он своевременно мог оказать поддержку проекту – обеспечить ресурсами и т.д.
Как в этом случае действовать руководителю проекта:
· информирует спонсора проекта о проблеме;
· анализирует причины возникновения проблемы и потенциальное влияние на проект (например, перерасход бюджета или увеличение сроков);
· разрабатывает альтернативные решения проблемы, выделяя их достоинства и недостатки;
· описывает ситуацию спонсору проекта, предоставляя варианты решения и рекомендации, объясняет последствия, которые могут возникнуть, если не принять решение;
· фиксирует результат эскалации.
Чтобы проект был успешным, нужно правильно назначить роли заинтересованных сторон. На роль спонсора проекта обязательно нужно выбрать того, кто принимает решения – топ-менеджера компании.
Отличия внешнего и внутреннего проекта
Внешний заказчик, например в сегменте b2b это компания, которая заказывает проект. Тогда внутри компании, исполняющей проект, нужно назначить руководителя проекта и спонсора (куратора). На рисунке 1 пунктирной линией представлена граница интересов – между зоной интересов заказчика и исполнителя проекта. Внешний заказчик часто оказывается капризным, может менять свои требования или затрудняется их четко сформулировать, поэтому представителям компании, исполняющей проект, приходится реагировать на его требования, меняющиеся условия – на этой линии и происходит коммуникация.
При возникновении споров руководитель проекта обращается к спонсору (куратору) проекта. Спонсор вступает в переговоры с заказчиком и находит взаимовыгодное решение.
Во внутреннем проекте, когда заказчиком выступает какой-то отдел компании, треугольник основных стейкхолдеров проекта выглядит так же, как и во внешнем, но взаимоотношения между ними сложнее (см. рисунок 2). Основная сложность в том, что заказчиком и спонсором проекта может выступать одно лицо. А эти роли желательно разделить, ведь они принципиально отличаются. Заказчик заинтересован получить продукт, а спонсор – тот, кто поддерживает проект в ходе его реализации, если возникают проблемы, с которыми руководителю не справиться. Поэтому если заказчик и спонсор – одно физическое лицо, а роли разные, возникает конфликт интересов.
Допустим, у компании есть внутренний проект по разработке CRM системы. Назначен руководитель проекта – специалист IT-отдела, а спонсор и заказчик – директор по продажам. Как заказчик директор по продажам заинтересован в CRM системе, как спонсор – он обязан поддерживать руководителя проекта. Если в таком проекте возникает проблема, например, нужны дополнительные ресурсы, руководитель эскалирует проблему спонсору. Будучи спонсором директор по продажам должен поддержать проект, но как заказчик он может от него отказаться, если у него ограничены ресурсы, ведь кроме CRM системы есть и другие проекты. Возникает борьба двух ролей внутри одного человека. Ее бы не было, если роли распределили бы так: директор по продажам – заказчик, а IT-директор – спонсор.
Искусство и технологии менеджмента руководителя проекта
Какими качествами должен обладать руководитель проекта
В арсенале компетенций руководителя проекта должны быть soft skills – искусство управления (неформальные методы), и hard skills – знание технологий (формальных методов). Важно их сочетание.
Hard skills – технологические знания. Это техники календарного планирования, MS Project, Open Plan, PlanVie, процедуры бюджетирования, использование процедур и шаблонов документов.
Soft skills – искусство, опыт, личные качества, работа с людьми, использование экспертных оценок, управление изменениями и рисками, отношениями с заказчиком проекта. Это часто нетривиальные методы управления изменениями, рисками, отношениями.
В крупных проектах руководитель должен обладать лидерскими качествами (Leadership Qualities):
• вести команду;
• стратегически мыслить;
• вдохновлять и воодушевлять;
• иметь авторитет;
• отличаться от формального руководителя;
• обладать харизмой;
• и т.д.
В отличие от формального руководителя, который просто управляет отделом или проектом, неформальный лидер способен вести команду, расставлять приоритеты, быть проактивным.
Как сочетать технические навыки и лидерские компетенции руководителя проекта
В зависимости от величины и сложности проекта, будет меняться и сочетание Soft skills и Hard skills его руководителя (см. рисунок). Если проект небольшой (содержание, длительность реализации, команда) у руководителя должно быть больше Hard skills. Например, если это IT-проект по разработке программного обеспечения, длительностью в 4 недели, а в команде всего 2 программиста, один из которых – руководит проектом. Такой руководитель должен обладать хорошими техническими навыками – в первую очередь, лидерство – не критично.
Если это средний проект с большим объемом, длительным сроком реализации, командой из нескольких специалистов разного профиля и т.д., руководителю необходимо проявление лидерских качеств, технические при этом так же должны присутствовать, но уже в меньшем объеме.
Если в компании возникает крупный проект, который может длиться годы, с несколькими сотнями стейкхолдеров, важны стратегические компетенции руководителя – в первую очередь Soft skills. Технические компетенции могут быть, но уже в минимальном объеме. Важно – они в любом случае не должны быть равны нулю. Таким лидером может стать сотрудник, который вырос в компании, наращивая Soft skills.
Руководитель проекта должен обладать лидерскими качествами, искусностью (soft skills) и технологиями менеджмента (hard skills) – профессиональными компетенциями. Все эти компетенции должны быть в сочетании. В зависимости от того, насколько крупный проект, сочетание может меняться.
Программное обеспечение для ведения проектов
Какие преимущества дает программного обеспечения при управлении проектами
Наличие специального программного продукта позволит компании лучше управлять проектами:
· интегрирует информацию для принятия управленческих решений;
· обеспечит необходимой информацией всех заинтересованных лиц проекта;
· поддержит динамично изменяющуюся среду и приоритеты проектов компании.
Зачастую, с изменением стратегии компании меняются и ее проекты или их приоритетность. Тогда ресурсы компании перераспределяют на более приоритетные проекты, а остальные могут приостановить, заморозить или отказаться совсем.
Чтобы у топ-менеджмента, который принимает решение и перераспределяет ресурсы, была вся необходимая информация об изменении приоритетов или целей, изменении среды и т.д. по всем проектам, нужно программное обеспечение.
Какие программные продукты использовать для управления проектами
MS Project – простой продукт с понятным интерфейсом, который можно быстро освоить без специальной подготовки. Функционал позволяет:
· вести расписание проектов в форматах сетевых диаграмм, диаграмм Гантта;
· назначать сроки работам проекта;
· распределять ресурсы;
· определять стоимость проекта;
· управлять изменениями в сроках, стоимости работ, логических зависимостях между работами;
· определять критические пути, критические цепи проекта.
Artemis – может получать детализированную проектную информацию из MS Project и добавляет в нее сложные математические методы которые помогут рассчитать вероятности достижения целей проекта по срокам, стоимости и т.д., оптимизировать распределение ресурсов.
PlanView Enterprise™ – включает 3 компоненты для управления портфелями, программами и проектами организации. Работая в этой программе руководитель портфеля может отследить взаимозависимости между программами и проектами компании, обеспеченность результатов проектов и программ для достижения стратегических целей портфеля.
Spider Project – российский продукт, который поддерживает диаграммы Гантта, графики и гистограммы, сетевые и организационные диаграммы проектов. Он комбинирует возможности MS Project и Artemis.
