Как появилась идея написать статью
Мне захотелось осмыслить свой опыт и те системные проблемы с которыми я сталкивался работая на позиции проектного менеджера (ПМа) в IT. Практически всегда я видел похожую картину — руководитель компании хотел передать часть ответственности линейному менеджменту, чтобы освободить себя для более стратегических задач. Поскольку работа в IT чаще всего проектная, найти ПМа кажется логичнее всего. Ищут человека, который не боится брать ответственность за проект целиком. При этом, остальные процессы в компании (инициация проекта, подписание контрактов) практически не меняются и остаются завязаны на ТОП менеджменте. В итоге к ПМу проект приходит на стадии, когда уже все решено: определена команда, выстроены ожидания заказчика, цель проекта, бюджет. И далее ПМ работает с тем что есть, не имея полномочий изменить состав команды, бюджет проекта, заказчика.
Но без делегирования полномочий не решается проблема загруженности ТОП менеджмента. Происходит интересная ситуация, когда есть человек «отвечающий» за проект, но все решения принимает ТОП менеджмент. Проблема становиться менее видимой, потому что «виноват» во всех принятых решениях ПМ. ПМ, как правило, ответственный человек, то он упорно ищет причины неудач в себе. В компании могут звучат красивые слова про то, что каждый может повлиять на ситуацию, у нас Lean, Agile и вот это все. Но это только мешает увидеть несоответствие обязанностей и полномочий.
Тут можно было бы поставить точку в статье и сказать, что все решается должностными инструкциями, описанием ролей, но это скучно. И все мастерство заключается не в инструментах, а в том как их применять на реальной ситуации. А для того чтобы применить их, нужно сперва увидеть что вообще происходит. О чем я и напишу.
Кстати, я слышал что в строительстве дела с ПМами обстоят лучше. Буду рад, если кто‑то поделиться в комментариях.
Название роли
В случае с ролями, очень важно найти подходящее название роли ее назначение. У этого выбора есть свои последствия:
Публикуется резюме с этим заголовком
На него откликнется Вася, который прошел курсы по управлению проектами. На этих курсах ему сказали, что он отвечает за исполнение контракта (проектный треугольник: график, бюджет, объем работ), работу с командой, стейкхолдерами.
Васю поставят ПМом на проект Х. А внутри компании у всех сформируются ожидание, что теперь за проект Х отвечает Вася. Он им управляет, чтобы это не значило.
Если на проекте появится проблема, то все будут смотреть на Васю и ждать что он ее решит.
Давайте разберемся в названиях. Меня часто называли ПМом, но как бы называлась роль в соответствии с ее полномочиями?
Администратор
Бывает, что ТОП менеджмент хочет отдать ПМу функцию контроля за сроками и бюджетом. Фактически это выглядит так, что ПМ собирает отчеты о производительности команды и расходу бюджета. Много механистической работы, в которой, опять же нет принятия решений, а есть отправка отчетов ТОП менеджменту и информирование команды о том, что мы работаем согласно плану или отстаем от него. Поскольку на состав команды ПМ повлиять не может, то ему остается надеется на благоразумность каждого участника, проводить мотивационные беседы или же эскалировать проблему выше, находя в компании людей, которым не все‑равно на проект, за который он несет ответственность. Тут он может перерасти в роль консультанта.
Консультант
Если ПМу повезет со своими навыками, окружением и своим влиянием, то он становиться консультантом. То есть, опять же, из-за отсутствия полномочий он своими руками ничего сделать не может, но зато может сделать руками других людей. Собственно это то, чем и занимаются консультанты. Это не плохо и не хорошо. Просто консультант не может отвечать за реализацию целей проекта, он может отвечать только за информированность всех участников процесса о проблемах и рисках.
Scrum Master
Когда у ПМа появляется экспертиза в гибких методологиях, то из роли простого консультанта он может стать консультантом по Scrum, Agile, Lean. Здесь появляется еще одна несостыковка, ведь в философии Agile нет проектного менеджера. Попадая в такую ситуацию, я обычно использовал роль-костыль “внутренний product owner”, поскольку был не только хранителем процессов, но и коммуницировал команде приоритеты.
Бизнес Аналитик
Ответственный ПМ зачастую затыкает собой все пробелы между бизнесом и инженерами. Один из таких пробелов - это работа с требованиями и преобразование бизнес требований в технические задачи. В таком случае ПМ становится не только носителем эксперитизы по выстраиванию процессов производства, но и экспертом в доменной области проекта. Здесь он становится непосредственным участником производства продукта как на этапе постановки задачи, так и на этапе валидации результатов.
Какие полномочия имеет смысл делегировать ПМу
Я напишу о двух полномочиях, которые наиболее ярко проявлялись в моем опыте и которые, в моем понимании, превращают Консультанта в Менеджера Проекта.
Валидация и контроль договоренностей
Бывало так, что я не был вовлечен в составление контракта и инициацию проекта. Клиент договаривается о всех условиях контракта с одним человеком, а реализует его другой. В IT я сталкивался с этим как со стороны исполнителя, так и со стороны заказчика. Вводить дополнительные слои коммуникации в IT считается нормой.
Порой клиент сталкивается с такой цепочкой:
Sales→Account Manager→Solution Architect→PM c пресейла→ PM производства → команда
Передача информации и контекста между разными ролями — это сложная задача. На старте проекта формируются ожидания всех стейкхолдеров, создается общее видение, доверие. Как правило, много нюансов в ожиданиях и договоренностях остается в устной форме. В случае аутсорсинговых компаний, ситуация усугубляется еще тем, что есть задача «продать» себя, пообещать максимум из того что мы можем сделать. Конфликт между продажами и производством хрестоматийный и требует создание дополнительных связей между людьми работающими в продаже и производстве.
Чем раньше ПМ и команда вовлечены в коммуникацию, тем более синхронизированы они будут относительно целей проекта. Как правило после старта у всех есть ощущение что все уже обсудили и задавать «глупые» вопросы кажется не комильфо.
Совет ПМам, которым пришел уже подписанный контракт: устройте себе «медовый месяц» со всеми стейкхолдерами. Не бойтесь показаться тупыми, поймите на что тут вообще подписались и насколько, по вашему, реально соблюсти эти договоренности, можно ли сейчас, текущими ресурсами решить задачу такой сложности?
Самые частые и дорогие ошибки происходят из‑за того, что люди усердно делают вид, что понимают друг друга.
Определение и изменения состава команды
Люди в IT это основной ресурс, главный риск и соответственно фактор определяющий производительность, маржинальность и успех проекта. Логично предположить, что у ПМа должны быть полномочия по изменению состава команды, но это далеко не всегда так. Я встречал ситуацию, где была отдельная роль — ресурсный менеджер. Этот человек следит за тем, чтобы все инженеры были заняты и пытался балансировать «занятость» с интересами проектов. У такой роли есть фокус на показателях процента бенча, общей маржинальности компании, но нет в фокусе целей отдельных проектов. Это приводит к усреднению результатов проектов и постоянным ротациям. Плюс добавляется сорревновательность за ресурсы между проектными менеджерами — побеждает самый убедительный или тот, у кого сложился хороший контакт с ресурсным менеджером.
Так же, у меня был опыт, когда я сам открывал вакансии, собеседовал инженеров и строил команду — в этом случае получилось сделать результативную команду, где есть доверие, хорошая групповая динамика и ресурс для решения сложных задач.
Делегирование полномочий VS пропаганда влияния
Делегирование полномочий — это изменение\создание таких бизнес процессов в которых у ПМа есть возможность принять решение и есть ресурсы на его осуществление.
Пропаганда влияния — это слова о том, что мы Lean, Agile, о том, что каждый может повлиять на процесс. Но без соответствующего бизнес процесса и ресурсов необходимых для осуществления этого влияние.
Пока встречи с обсуждением состава команды проходят без ПМа и контракты согласовываются без участия ПМа, ни какие Agile‑Lean практики не сделают работу этой роли результативной.
Самоуправление и самоорганизация
В моем понимании, хороший менеджер — это тот, который смог выстроить структуру работающую самостоятельно, без его участия. Эволюционная цель ПМа, которая мне откликается — сделать так, чтобы роли ПМа больше не понадобилось. Путь к самоуправлению долог и тернист, у меня тут нет достаточной экспертизы и опыта, чтобы описать его целиком. Тем не менее пересмотр организационной структуры и ролей занимает в этом пути немаловажную роль. Мне хочется верить, что эта статья может помочь в том числе и с этим процессом. В случае с самоуправлением делегирование полномочий может производиться не отдельному человеку, а проектной команде целиком. Роли ПМа может не быть, а вместо него можно добавить, к примеру, бизнес аналитика и сделать переходящей роль фасилитатора встреч. Можно почерпнуть конкретные реализации таких организационных структур в сообществе практиков Социократии 3.0. В международном сообществе регулярно проходят вебинары на которых компании делятся своим успешным опытом и граблями, которые они насобирали.
Комментарии (18)
retar
00.00.0000 00:00+1Нет, в стройке не лучше, в стройке многограннее: очень сильно зависит и от типа строительства, и от вида контракта. Если ты ПМ от EPC-контрактора, то ты Царь и Бохъ проекта, у тебя есть только жестко зафиксированные ТЗ и бюджеты и цель. Если ты ПМ от контрактора в Multi-lot, то в тебе находится нечто огромное, но ты за всё отвечаешь практически не принимая решения (у тебя документация уровня Detailed Design documentation и шаг в сторону - это чужая территория). Если ты ПМ от инвестора/заказчика, то тут много разных вариантов: чем меньше компания и чем меньше она ведет контрактов, тем меньше зона принятия решений у ПМ, чем больше компания и чем больше контрактов, тем ближе к "Царь и Бохъ".
Но самое главное отличие: в стройке ПМы гораздо компетентнее, ответственнее и профессиональнее. Плюс в стройке нет дробления задач и гордого наименования какой-нибудь мелочи проектом: проект в стройке - это ведение какого-нибудь этапа или этапов жизненного цикла объекта капитального строительства полностью. Например EPC-контракт покрывает весь цикл от задумки до сдачи объекта в эксплуатацию (Engineering, procurement and construction) и ПМ им полностью рулит. Представьте EPC на какой-нибудь Арктик-СПГ ;)
danilNik Автор
00.00.0000 00:00Спасибо! А подпись на контракте под цифрами и планом кто ставит? Интересно услышать как реализуются полномочия ПМа в конкретных бизнес процессах.
Komrus
00.00.0000 00:00А если ты Руководитель Проекта от генподрядчика, выигравшего российский гос.тендер (или муниципальный) на ремонт чего-нибудь вроде детского садика - то всё печальнее. Сроки, финансы и вообще возможность принятия решений - крайне зажаты. А ответственности - много.
itGuevara
00.00.0000 00:00+2В русском языке слово «управлять» - не конкретное. Предлагаю заменить на другие: руководить и манагерить. Руководить проектом – это Главный конструктор / Главный инженер проекта (как в ГОСТах), т.е. реальный руководитель, т.е. руководитель проекта. Королев в ракетах или Берия в атомном проекте – это про руководить. Есть полномочия и ответственность и не важно при этом, что Королев хорошо знал про устройство ракет, а Берия плохо как устроен атом.
Манегер - это менеджер по PMBOK, точнее администратор проекта (ведет регистры проектного учета, примерно как регистры бухгалтерского, складского и т.п.) + методолог и «проводник». Методолог не прикладной области, а PM-бучной.
Например, тут идут споры: Жуткий сценарий использования ChatGPT
https://habr.com/ru/post/714792/
должен ли менеджер быть спецом в прикладной (по теме проекта) области? Там говорят, что «да», но PMBOK говорит, что нет.
Задача менеджера проекта (в рамках PMBOK) представить и формализовать проект как процесс. Это не ответственность за выбор проектных решений, это про показать, какие формальные стадии должны быть (методолог), «за руку» провести проектную команду по этим стадиям (проводник) и формализовать результаты каждой стадии (учетная часть, включая сроки и бюджет). Отдельная роль - менеджер портфеля проектов (не рассматриваем).
Это позволяет достичь главного результата проектного менеджера – формализовать результат проекта и документально подтвердить, кто «завалил проект» (если такое случилось). Т.е. на упрек: «как ты завалил проект», проектный менеджер показывает на «крайнего» с фактурой, т.е. доказательствами. Конечно ТОПы уклоняются от такого контроля, но искусство менеджера - такой контроль обеспечить. В РФ могут изредка под названием менеджера проекта давать власть и обеспечить тем самым роль Главного конструктора (руководителя проекта), тогда это «два в одном».
В РФ обычно не понимают классического образа Манагера, его не стимулируют как требуется, например, если зарплата манагера не будет зависеть от сроков проекта, то это уже не эффективный проектный менеджмент. Манагеру должно быть выгодно неэффективный проект закрыть (и переключиться на другой), нежели его годами "волочить до победного".
Итого: Главные конструктора – в ТОМ-менеджменте (поиск и принятие проектных решений), а секретари проектов – в PMBOKах (организация проектных работ как процесс). В зрелых проектных компаниях изначально проекты организованы как процесса, но вот в проектных командах заказчика (внедрение своими силами, с привлечением вендора или интегратора) – проекты редко организованы как процесс (выстроенный процесс, когда понятно чем закончится конкретная стадия и что делать далее, как все это оформлять и т.п.).
хороший менеджер - это тот, который смог выстроить структуру работающую самостоятельно, без его участия. Эволюционная цель ПМа, которая мне откликается - сделать так, чтобы роли ПМа больше не понадобилось.
Да. Это и есть конечная цель управления процессами. Только вначале нужно из проекта сделать процесс.
danilNik Автор
00.00.0000 00:00Читаю PMBOK 7 издание. Не вижу там закрепление конкретных функций за ролью ПМа. Очень размыто об этом написано.
Project manager. The person assigned by the performing organization to lead the project team that is responsible for achieving the project objectives. Project managers perform
a variety of functions, such as facilitating the project team work to achieve the outcomes and managing the processes to deliver intended outcomes. Additional functions are identified in Section 2.3.2.3 FUNCTIONS ASSOCIATED WITH PROJECTS
People drive project delivery. They do so by fulfilling functions necessary for the project to run effectively and efficiently. Functions related to the project can be fulfilled by one person, by a group of people, or combined into defined roles.
Coordinating a collective work effort is extremely important to the success of any project. There are different types of coordination suitable for different contexts. Some projects benefit from decentralized coordination in which project team members self-organize and self-manage. Other projects benefit from centralized coordination with the leadership and guidance of a designated project manager or similar role. Some projects with centralized coordination can also benefit from including self-organized project teams for portions of the work. Regardless of how coordination takes place, supportive leadership models and meaningful, continuous engagements between project teams and other stakeholders underpin successful outcomes.
Regardless of how projects are coordinated, the collective effort of the project team delivers the outcomes, benefits, and value. The project team may be supported by additional functions depending on the deliverables, industry, organization, and other variables. Sections 2.3.1 through 2.3.8 provide examples of functions that are often found on projects, though these are not a comprehensive list. In addition to these functions, other functions may be necessary to enable project deliverables that produce the desired outcomes. The needs of the project, organization, and environment influence which functions are used on a project and how those functions are carried out.itGuevara
00.00.0000 00:00Конечно размыто, впрочем как и размыт в PMBOK сам бизнес-процесс проектного управления. Тем не менее общая концепция понятна из самой книжки, не уверен, что 7 (ее не читал, но полагаю, что она мало чем отличается от предыдущих).
retar
00.00.0000 00:00PMBOK так то сборник рекомендаций, а не руководство к действию, хоть на нём и стоит штамп ANSI. А вот руководство - это скорее ISO 21500.
avf48
00.00.0000 00:00При применении ГОСТ Р ИСО 21500, стоит помнить, что сейчас, например в нём нет рисков, но это не значит что на них можно положить, это значит, что они в другом ГОСТе.
Без возможности применять стандарты, ГИП превращается.... в зицпредседателя Фунта.
retar
00.00.0000 00:00В целом да, но на крупных стройках ГАП/ГИП/конструктор/итд давно уже не выполняют роль РП, хотя и несут уголовную ответственность. Ирония. Но про уголовку пойду уточню на всякий случай.
upd.: угловка несёт ГИП, по крайней мере на технологических объектах нефтянки.itGuevara
00.00.0000 00:00Не знаю как сейчас, но 15 лет назад на всех проектах, которые через меня проходили на титуле (титульный лист проекта) была надпись:
я ГИП этого проекта несу Уголовную ответственность за то что тут написано (что то типа того) и роспись.
Сейчас "среднестатистический" менеджер проекта, как правило, ни за что не отвечает, т.к. ответственность требует наличия полномочий.
retar
00.00.0000 00:00РП отвечает за полное руководство проектом: финансирование, выбор подрядчиков, контроль процессов, выход на экспертизу, получение разрешений и тд. А ГИП, да, за технические и технологические решения, за которые можно присесть.
avf48
00.00.0000 00:00Набор компетенций можно уточнить в Профстандарте, а уже идентифицированные/закрепленные трудовые функции, по возможности, делегировать.
Профстандарт: 06.016 "Руководитель проектов в области информационных технологий"
danilNik Автор
00.00.0000 00:00Кажется я что-то такое у себя в должностной инструкции читал. ????
Не видел, чтобы по этому стандарту кто-то реальный бизнес процесс выстраивал. На сколько я понимаю, этот стандарт применяется только для урегулирование отношений между работодателем и сотрудниками. Чтобы, к примеру, можно было уволить сотрудника за неисполнение той или иной трудовой функции.
Или есть реальные примеры компаний, которые его используют?avf48
00.00.0000 00:00"Кажется я что-то такое у себя в должностной инструкции читал.... "
"На сколько я понимаю, этот стандарт применяется только для урегулирование отношений между работодателем и сотрудниками. Чтобы, к примеру, можно было уволить сотрудника за неисполнение той или иной трудовой функции."
"Или есть реальные примеры компаний, которые его используют? "
В этом то и проблема... По закону, вы(все) работайте по ДИ и ПСП(положение о подразделении), а по факту, видели их 1 раз за всю трудовую деятельность.
Конкретно этот стандарт - нет, не видел в применении. Но с другими работал и в правы, они нужны для урегулирования трудовых отношений, "говорилок" очень хорошо помогают идентифицировать.
lolekaheheka
00.00.0000 00:00-1У менеджера проекта есть всего 1 проблема, а именно не облажаться на старте. Нанять удачно нормальных лидов и чтоб повезло. Дальше команда сама всё сделает, или не сделает. Рассказы, что ПМом быть сложно - преувеличены. Да, один ПМ хостит на себе по 24-32 человека. А Продакт и по 72+. Но опять же, всегда можно спихнуть, что команда не вывезла.
PereslavlFoto
А также определяет раскладку расходов, то есть сам решает, на что тратить деньги, а что сделать бесплатно. А также планирует работы.
или же управлять расходами, доплачивая премию успевающим и недоплачивая премию неуспевающим.
ПМ назначают именно для того, чтобы сейчас и текущими ресурсами решить задачу такой сложности. Его обязанность — решить данную задачу при таких ресурсах.
danilNik Автор
Если есть такие полномочия, - замечательно.
Делай что должен и не задавай вопросов? У ПМа уровень обязательств слишком высокий, чтобы уповать на то, что кто-то сверху поставил задачу корректно. С опытом приходят ясные аргументы, для того чтобы бюджет изменить на старте или помочь собственнику бизнеса принять решение о закрытии проекта.
PereslavlFoto
Конечно, у ПМ всегда есть такие полномочия.
По второму пункту тоже всё правильно. Получив бюджет от работодателя, ПМ может изменить бюджет на старте за счёт своих ресурсов. А вот кто помогает «принять решение о закрытии проекта», те просто не справляются со своей работой и срывают её.