Не вижу никакого конфликта интересов. Мы оба мотивированы и на прибыльность проекта и на новые продажи. Только я в рамках своего проекта/клиента, а директор - в рамках N проектов/клиентов. А чтобы новые продажи случились, нужно обеспечить качество производства. Так что продажи и производство - это инь и янь

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

Попробую объяснить на пальцах.

Представьте, что Вы бригадир команды зэков на урановом руднике (не дай бог, конечно) и подчиняетесь начальнику отряда (тоже зэку). Начальник лагпункта, генерал НКВД, вызывает начальника Вашего отряда и говорит:

- Че то, б.., работаешь плохо, х... е... Если хочешь заработать условно-досрочное освобождение - увеличивай выработку, с..., а то сам пойдешь в забой киркой махать.

Начальник отряда приходит к Вам в бригаду и произносит речь:

Братаны, надо поднапрячься! На кону честь нашего коллектива! В соседнем забое бригаду завалило, поэтому половина бригады отправится туда на помощь. А оставшимся увеличиваю норму выработки в два раза. Если справитесь - получите похвальные грамоты, не справитесь - вас всех расстреляют.

По-моему приведённый пример Вы написали не для того чтобы что-то объяснить, а просто так, вдохновение пришло
У нас мотивационные механизмы отличаются от приведённого Вами примера, причём, вроде бы я их объяснил - мы с директором получаем бонусы практически с одинаковых показателей - и с выручки и с новых продаж. То и другое зависят от качества производства, поэтому мы ОБА заинтересованы и в качестве и в снижении издержек (т.е. трудозатрат) и в своевременной сдаче результатов и в сохранении команды и в зарабатывании репутации и пр. А чтобы понять, что приведённый пример к делу не относится достаточно признать, что консультанты - не зеки, просто так уродоваться за чужие бонусы они не будут, их надо ещё суметь мотивировать (никакими расстрелами их не напугаешь), чтобы делали то что нужно в запланированные сроки и с нужным качеством. А то эта братва быстро проест бюджет (они то мотивированы в основном только своими человеко-часами, а вовсе не прибыльностью проекта), а станет ли проект рентабельным - это не их забота, а наша с директором. И если бюджет съеден, а результат не достигнут - вот тут уж нам вдвоём крутиться-выкручиваться. Короче, мы делим и ответственность и проблемы и бонусы и даже личную репутацию. И не могу сказать, что мне жалко делиться

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

Хочу спросить остальных коллег, а как у вас?

Чё-то мне не понятно, а зачем тогда он участвует, если знает, что ничего с этого не получит кроме геморроя? Тогда руководителю проекта надо упираться руками и ногами и не давать расширять рамки проекта ни на миллиметр, сколько бы бабла за это ни обещали. Получается, ему выгодно сделать как можно меньше. Продать что либо, если собственные менеджеры ставят палки в колёса явно нереально.

+1
Вопрос: А сколько надо заложить резерва, чтобы непроеденный бюджет стал мотивирующим бонусом?

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

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

misanthrope, не стану спорить, просто мне это представляется странным. Чтобы что-то сделать хорошо, в т.ч. и продать, для меня важно этого хотеть. Если я не хочу чего-то делать, обычно хорошо у меня не получается. Пропозол на 100 страниц это творческая работа, а не яма 100м3 - плётками и пинками хорошо его сделать не заставишь. ИМХО.

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

Кстати, Баба с веслом была почитаема поболе Венеры на 1/6-й части суши. По идеологическим причинам, разумеется.

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

Вот только не совсем понятно из твоего поста - в чем отличия между руководителем отдела и руководителем программы в данном случае?
И насчет сертификата можно подробнее? (PMP и СОВНЕТовские знаю.)

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

С PMBook-м поймал, поймал... шельма (беззлобно)
Конечно же не все описано в это книжке. В консалте все ведение проекта держится на трех столпах:
- Процессы (читай выстраивание отношений) с заказчиком
- Выстраивание отношений с командой
- Выстраиваний отношение с собственным руководством.
А PMBOK описывает только формальные процедуры проектной технологии. Так вот эта технология частично касается только 1 и 2-ой части, оставив массу важных моментов "за бортом". Но дело в том, что то что остается за бортом формализовать не получится, от того и ноухау не существует. Эта как игра в шахматы. Правила всем известны, есть набор проверенных тактических техник, только кто то играет лучше, а кто то хуже. То бишь опять про венеру и бабу с веслом аллегория. А насчет популярности "весла " на 1/6 части суши я бы поспорил. Т.к единственным конкурентом ее был мальчик с горном. Выбор не велик. Тока венера до сих пор стоит, а где эти горнящие мальчики и гребущие бабы?
Так и с проектами. Делаешь разумно, "по написаному", получается может и дольше и может дороже, но оно потом работет и развивается, а когда лепят побыстрее да поскорее, - посмотришь через год другой на результат - урод уродом.

Процессы, Заказчик, руководство - согласен.

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

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

Вот тут копья ломали должен ли ПМ разбираться в функционале SAP или должен более разбираться в управлении.
По опыту общения со своим руководством (Заказчиком) я сделал вывод, что заказчику хочется, чтобы ПМ не в модулях разбирался, а понимал его бизнес-задачи и мог с ним обсуждать эти задачи в терминах ну никак не функционала, а, в первую очередь, с т.зрения бизнес-процесса.
А функционал натягивать - это задача системного архитектора (of меня побьют).


В общем, нужна метода ближе к бизнесу, т.к. pmbok помогает решить лишь малую часть задачи.

Мнение мое наверняка спорное, ведь у каждого за плечами свой шкаф со скелетами.

Понравились книги ДеМарко. Управление проектом показано со всех сторон (общение с начальством, выстраивание отношений с заказчиком и главное управление командой)




А разве системный архитектор не должен ** понимал его бизнес-задачи и мог с ним обсуждать эти задачи в терминах ну никак не функционала, а, в первую очередь, с т.зрения бизнес-процесса.**???
Тогда очень простой вопрос в чем между ними разница?? ПМ -это куцый системный архитектор?? (беззлобно)), ни кого не хочу оскорбить)

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

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

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