28 окт 2022

Почему проджект-менеджеры не любят проджект-менеджмент?

Для кого:
  • Владельцы бизнеса
  • Руководители проектного офиса
  • Руководители проектов
Знания и навыки:
  • Управление проектами
  • Мотивация
Время на чтение:
  • 4 минуты

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

Ответ на него очень простой: проектный менеджмент для руководителя проекта — это миф.

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

Но давайте вообразим, что у вагонов есть какая-то свобода воли. Хотят ли вагоны ехать в таком составе, везти именно этот груз, двигаться именно из пункта А в пункт В? Грузоотправителю ничего об этом неизвестно. Может быть, один вагон мечтал всю жизнь простоять в тупике, а другой желает ехать в пункт С? Делает ли это его плохим вагоном? Нет. Просто вам нужно, чтобы все происходило именно так, а не иначе.

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

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

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

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

За это не платят

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

Нежелание лишнего контроля со стороны топ-менеджмента

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

Привязанность к прошлому опыту

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

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

Невозможность переложить ответственность на исполнителя

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

Дополнительная нагрузка

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

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

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

Отсутствие актуальных проблем

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

Невостребованность инструментов проектного менеджмента командой или стейкхолдерами

Члены команды и стейкхолдеры могут найти отдельные инструменты, предусмотренные правилами проектного менеджмента, излишними. Например, им может показаться ненужным ежемесячное совещание, так как команда и так «общается каждый день». Очередной еженедельный/ежемесячный отчет тоже представляется необязательным, особенно если речь идет о заказчиках, которые «и так в курсе». Кроме того, использование ряда инструментов — нагрузка для команды и риск поставить себя под удар. Например, нужно готовиться к докладу по задачам на еженедельной планерке, отвечать за озвученные сроки и говорить о возможных проблемах. Это побуждает руководителей проектов не соблюдать правила в дальнейшем, и управленческие документы не обсуждаются, не предоставляются на обсуждение, что увеличивает вероятность ошибок.

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

Еще больше актуальной информации про полезные методы и инструменты проектного менеджмента, внедрения организационных изменений и ИТ-решений ищите в нашем Телеграм-канале: Уж&Ёж. Управление проектами. PMLogix

Авторы статьи:
Андрей Малахов, Анастасия Тимофеева
Прокомментировать статью
Подписаться
Уведомить о
0 комментариев
Межтекстовые Отзывы
Посмотреть все комментарии
Смотрите также:
13 Мая 2024
Что такое уровни управления
Уровни управления в организации — это ступени иерархической структуры, которая обеспечивает порядок, а также распределение ответственности и полномочий между сотрудниками. Во главе структуры стоит тот, кто управляет компанией: генеральный или исполнительный директор, которому подчиняются управленцы нижестоящего уровня. Менеджеры, стоящие “под” главой предприятия, контролируют следующий, также нижестоящий, уровень руководителей.
26 Апр 2024
Что такое проектный треугольник и зачем он нужен проджекту
Что из себя представляет проектный треугольник и как его применяют в  управлении проектами? Как использование этого инструмента позволяет объяснить заказчику, что качественный продукт, сделанный в короткие сроки, стоить дешево не может?  В чем отличия треугольника при использовании в гибких методологиях от применения в классическом подходе Waterfall?
16 Апр 2024
Что такое декомпозиция и чем она отличается от других видов планирования
Декомпозиция – это метод разделения большой цели, продукта, задачи, работы или процесса на маленькие части, этапы, подзадачи. Часто декомпозицию применяют для составления плана работ и контроля реализации большого сложного проекта. Как её применять, читайте в этой статье.
Подписаться на рассылку
Высылаем анонсы статей и полезные материалы
Прокомментировать статью
Текст сообщения
Имя, Отчество, Фамилия
Email

Комментарий успешно отправлен

Произошла ошибка при отправке. Попробуйте еще раз

Наверх
Здравствуйте! Если возникли вопросы, мы на связи.
Скопировано в буфер обмена