Национальная ассоциация управления проектами с 1990 года
Национальная ассоциация управления проектами с 1990 года
Заполнить заявку
на сертификацию
IPMA-СОВНЕТ

Ваше сообщение успешно отправлено

Мы свяжемся с Вами в ближайшее время
Социальные сети:
Путеводитель по услугам Ассоциации

Алексей Полковников, «Совнет»: Понятия и язык проектного менеджмента

23.12.2013
Автор: Алексей Кузнецов

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

 

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

 

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

 

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

 

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

 

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

 

Может ли PM являться неким универсальным языком при выполнении крупных проектов автоматизации, в которые вовлечено множество различных департаментов?

 

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

 

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

 

Это и возможно, и необходимо. Управление проектами — дисциплина прикладная, динамически развивающаяся. Развитие PM представляется мне в виде спирали: сначала нарабатывается практический опыт на конкретных проектах, следующим шагом наиболее удачный опыт обобщается и ложится в основу методологии и стандартов PM. Но очень важен третий шаг — адаптация стандартов под конкретные проекты и задачи. Cтандарты PM, как правило, не привязаны к каким-либо типам проектов, соответственно они определяют рекомендации на обобщенном уровне. Адаптация стандартов под конкретные типы проектов позволяет не только повысить эффективность их применения, но и избежать излишней бюрократизации процессов управления. Например, для ИТ-проектов, использующих итерационные и инкрементальные модели жизненных циклов, нет особого смысла с самого начала требовать разработки детальных планов на весь проект, а вот процессы коммуникаций и управления изменениями должны быть спланированы более тщательно. В строительном проекте требования к процессам управления могут, естественно, быть иными.

Развитие управления проектами сегодня во многом идет по отраслевому принципу. Это отражается и на методологии, и на карьере специалистов. Руководителю проектов, имеющему опыт их реализации в строительстве, придется получить дополнительные знания и опыт, если он захочет продолжить карьеру в ИТ-проектах. В ассоциации «Совнет» мы развиваем такую форму взаимодействия, как группы по интересам, в которых специалисты обмениваются опытом в той сфере управления проектами, которая для них более интересна.

 

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

 

Фактически на основе идей PM существует множество своего рода «вторичных» методологий. Классическим примером являются методики внедрения сложных ИТ-продуктов автоматизации бизнес-процессов, и формально тут у каждого производителя своя методология, которую часто подают как некую «фирменную», но которая на самом деле представляет собой адаптацию известных принципов Project Management. 

Признают ли представители «классического» PM такое разнообразие и при каких условиях оно может считаться нормальным?

 

В настоящее время выделяются три группы процессов, которые для эффективной реализации проекта не должны быть оторваны друг от друга: процессы управления проектом, процессы создания продукта и поддерживающие процессы. Наиболее авторитетный сегодня «классический» стандарт управления проектами ISO 21500 (как и другие стандарты для этой области) описывает только требования к процессам управления проектом. Методологии производителей продуктов часто включают описание процессов, прежде всего связанных с их развертыванием и настройкой (Delivery processes) и адаптируют процессы управления под специфику продукта. Поддерживающие процессы (Support processes) могут учитывать специфику обеспечивающих процессов поставщика и организации, реализующей проект. Так что создание «вторичных» методологий лежит в русле развития управления проектами. Важно только, чтобы методологии эти опирались на общепринятые в мире стандарты (ISO 21500, ICB, PMBOK). Это обеспечит интеграцию разных подходов.

 

Со стандартами в области управления проектами всегда была тесно связана сертификация специалистов. Насколько это важно? Насколько вообще с вашей точки зрения значима универсальная связка «стандарт — сертификация»?

 

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

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

В IPMA разработаны требования к компетентности различных уровней специалистов, участвующих в проекте (ICB — IPMA Competence Baseline), которые включают требования не только к управленческим компетенциям, но и к поведенческим, а также к связанным со взаимодействием проекта и выполняющей его организации. На базе этих требований построена международная система сертификации специалистов, обеспечивающая единую структуру знаний и единый язык для менеджеров из разных стран. В настоящее время в IPMA разрабатываются также стандарты, определяющие требования к компетентности команд проектов и организации в целом (PCB — Project Competence Baseline и OCB — Organization Competence Baseline).

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

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

Конечно, Agile будет развиваться по мере накопления и обобщения опыта проектов и может быть стандартизирован на каком-то обобщенном уровне (опять же чтобы не ограничивать проекты, он не должен быть очень жестким). Но я не стал бы противопоставлять этот метод классическому управлению проектами, это некое дополнение, расширение, адаптация.

 

Дисциплина Project Management, с одной стороны, оперирует давно устоявшимися и много раз проверенными методиками, с другой — постоянно развивается. Существуют ли в PM какие-либо направления, куда в должной мере еще не проникла стандартизация, но где она должна непременно появиться?

 

Деятельность по стандартизации в сфере Project Management в последние несколько лет явно активизировалась. Международная организация по стандартизации ISO долгое время не уделяла значительного внимания вопросам управления проектами и лишь четыре года назад создала проектный комитет, который разработал новый стандарт ISO 21500, определяющий требования к процессам РМ. Помимо этого в рамках ISO совсем недавно был создан отдельный технический комитет, единственным направлением работы которого будет стандартизация в области управления проектами. Я как раз являюсь руководителем его российской делегации. Сейчас уже собрана статистика потребности в стандартизации по всем странам, расставлены приоритеты и запущено в разработку четыре новых стандарта.

 

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

 

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

 

Деятельность по стандартизации в сфере Project Management, как я уже сказал, постепенно приобретает отраслевой оттенок. Если ISO эта тенденция еще не коснулась, то американский институт PMI такие отраслевые стандарты уже готовит. В самых общих словах речь здесь идет о том, что на классические прин­ципы Project Management накладываются особенности жизненного цикла проектного управления в каждой конкретной отрасли, будь то государственное управление, внедрение информационных технологий или строительство.

 

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

 

Целесообразно ли создавать на базе международных стандартов отечественные ГОСТы?

 

Сейчас в Росстандарте доминирует концепция, согласно которой необходимо в максимальной степени использовать уже имеющиеся стандарты ISO, а не изобретать велосипед. Так что перевод и популяризация международных документов, как правило, являются достаточной деятельностью с нашей стороны. Однако бывают случаи, когда на базе международных стандартов необходимо разработать соответствующие ГОСТы. Тут мы обычно идем навстречу потребностям рынка (например, некоторым крупным заказчикам, которые при взаимодействии со своими подрядчиками стремятся, с одной стороны, соблюсти базовые принципы, определяемые международными стандартами, а с другой — без необходимости эти отношения все же не усложнять). В этом случае, создавая ГОСТы на базе стандартов ISO, мы следуем по пути их адаптации и возможного упрощения.

Источник: