Pull to refresh

Comments 17

ПМ собирает отчеты о производительности команды и расходу бюджета.

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

остаётся надеяться на благоразумность каждого участника, проводить мотивационные беседы

или же управлять расходами, доплачивая премию успевающим и недоплачивая премию неуспевающим.

поймите… можно ли сейчас, текущими ресурсами решить задачу такой сложности?

ПМ назначают именно для того, чтобы сейчас и текущими ресурсами решить задачу такой сложности. Его обязанность — решить данную задачу при таких ресурсах.

или же управлять расходами, доплачивая премию успевающим и недоплачивая премию неуспевающим.

Если есть такие полномочия, - замечательно.

ПМ назначают именно для того, чтобы сейчас и текущими ресурсами решить задачу такой сложности. Его обязанность — решить данную задачу при таких ресурсах.

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

Конечно, у ПМ всегда есть такие полномочия.

По второму пункту тоже всё правильно. Получив бюджет от работодателя, ПМ может изменить бюджет на старте за счёт своих ресурсов. А вот кто помогает «принять решение о закрытии проекта», те просто не справляются со своей работой и срывают её.

Нет, в стройке не лучше, в стройке многограннее: очень сильно зависит и от типа строительства, и от вида контракта. Если ты ПМ от EPC-контрактора, то ты Царь и Бохъ проекта, у тебя есть только жестко зафиксированные ТЗ и бюджеты и цель. Если ты ПМ от контрактора в Multi-lot, то в тебе находится нечто огромное, но ты за всё отвечаешь практически не принимая решения (у тебя документация уровня Detailed Design documentation и шаг в сторону - это чужая территория). Если ты ПМ от инвестора/заказчика, то тут много разных вариантов: чем меньше компания и чем меньше она ведет контрактов, тем меньше зона принятия решений у ПМ, чем больше компания и чем больше контрактов, тем ближе к "Царь и Бохъ".

Но самое главное отличие: в стройке ПМы гораздо компетентнее, ответственнее и профессиональнее. Плюс в стройке нет дробления задач и гордого наименования какой-нибудь мелочи проектом: проект в стройке - это ведение какого-нибудь этапа или этапов жизненного цикла объекта капитального строительства полностью. Например EPC-контракт покрывает весь цикл от задумки до сдачи объекта в эксплуатацию (Engineering, procurement and construction) и ПМ им полностью рулит. Представьте EPC на какой-нибудь Арктик-СПГ ;)

Спасибо! А подпись на контракте под цифрами и планом кто ставит? Интересно услышать как реализуются полномочия ПМа в конкретных бизнес процессах.

А если ты Руководитель Проекта от генподрядчика, выигравшего российский гос.тендер (или муниципальный) на ремонт чего-нибудь вроде детского садика - то всё печальнее. Сроки, финансы и вообще возможность принятия решений - крайне зажаты. А ответственности - много.

В русском языке слово «управлять» - не конкретное. Предлагаю заменить на другие: руководить и манагерить. Руководить проектом – это Главный конструктор / Главный инженер проекта (как в ГОСТах), т.е. реальный руководитель, т.е. руководитель проекта. Королев в ракетах или Берия в атомном проекте – это про руководить. Есть полномочия и ответственность и не важно при этом, что Королев хорошо знал про устройство ракет, а Берия плохо как устроен атом.

Манегер  - это менеджер по PMBOK, точнее администратор проекта (ведет регистры проектного учета, примерно как регистры бухгалтерского, складского и т.п.) + методолог и «проводник». Методолог не прикладной области, а PM-бучной.

Например, тут идут споры: Жуткий сценарий использования ChatGPT

https://habr.com/ru/post/714792/

должен ли менеджер быть спецом в прикладной (по теме проекта) области? Там говорят, что «да», но PMBOK говорит, что нет.

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

Это позволяет достичь главного результата проектного менеджера – формализовать результат проекта и документально подтвердить, кто «завалил проект» (если такое случилось). Т.е. на упрек: «как ты завалил проект», проектный менеджер показывает на «крайнего» с фактурой, т.е. доказательствами. Конечно ТОПы уклоняются от такого контроля, но искусство менеджера - такой контроль обеспечить. В РФ могут изредка под названием менеджера проекта давать власть и обеспечить тем самым роль Главного конструктора (руководителя проекта), тогда это «два в одном».  

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

Итого: Главные конструктора – в ТОМ-менеджменте (поиск и принятие проектных решений), а секретари проектов – в PMBOKах (организация проектных работ как процесс). В зрелых проектных компаниях изначально проекты организованы как процесса, но вот в проектных командах заказчика (внедрение своими силами, с привлечением вендора или интегратора) – проекты редко организованы как процесс (выстроенный процесс, когда понятно чем закончится конкретная стадия и что делать далее, как все это оформлять и т.п.).

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

Да. Это и есть конечная цель управления процессами. Только вначале нужно из проекта сделать процесс.

Читаю 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.

Конечно размыто, впрочем как и размыт в PMBOK сам бизнес-процесс проектного управления. Тем не менее общая концепция понятна из самой книжки, не уверен, что 7 (ее не читал, но полагаю, что она мало чем отличается от предыдущих).

PMBOK так то сборник рекомендаций, а не руководство к действию, хоть на нём и стоит штамп ANSI. А вот руководство - это скорее ISO 21500.

При применении ГОСТ Р ИСО 21500, стоит помнить, что сейчас, например в нём нет рисков, но это не значит что на них можно положить, это значит, что они в другом ГОСТе.

Без возможности применять стандарты, ГИП превращается.... в зицпредседателя Фунта.

В целом да, но на крупных стройках ГАП/ГИП/конструктор/итд давно уже не выполняют роль РП, хотя и несут уголовную ответственность. Ирония. Но про уголовку пойду уточню на всякий случай.

upd.: угловка несёт ГИП, по крайней мере на технологических объектах нефтянки.

Не знаю как сейчас, но 15 лет назад на всех проектах, которые через меня проходили на титуле (титульный лист проекта) была надпись:

я ГИП этого проекта несу Уголовную ответственность за то что тут написано (что то типа того) и роспись.

Сейчас "среднестатистический" менеджер проекта, как правило, ни за что не отвечает, т.к. ответственность требует наличия полномочий.

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

Набор компетенций можно уточнить в Профстандарте, а уже идентифицированные/закрепленные трудовые функции, по возможности, делегировать.

Профстандарт: 06.016 "Руководитель проектов в области информационных технологий"

https://profstandart.rosmintrud.ru/obshchiy-informatsionnyy-blok/natsionalnyy-reestr-professionalnykh-standartov/reestr-professionalnykh-standartov/index.php?ELEMENT_ID=50432

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

Или есть реальные примеры компаний, которые его используют?

"Кажется я что-то такое у себя в должностной инструкции читал.... "

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

"Или есть реальные примеры компаний, которые его используют? "

В этом то и проблема... По закону, вы(все) работайте по ДИ и ПСП(положение о подразделении), а по факту, видели их 1 раз за всю трудовую деятельность.

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

Sign up to leave a comment.

Articles