Успешный руководитель проекта

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

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

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

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

Редко используемый в нашей стране стандарт, утвержденный правительством Великобритании, – PRINCE2. Очень многое говорит его название – PRINCE (PRojects IN Controlled Environments). Перевод звучит следующим образом: «Проекты в управляемой среде». Как видите, акцент делается на тот факт, что проект не развивается сам по себе. Должно быть управляемое окружение. В отличие от PMBOOK, является менее формализованным, позволяющим адаптировать его под свои внутренние процессы. На мой взгляд, в изменчивой среде данный стандарт в большей степени обеспечивает гибкость взаимодействия в рамках проекта. Однако он требует и большей гибкости мышления от руководителя проектов.

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

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

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

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

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

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