Стандарты руководителя проекта

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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