Полномочия менеджера проекта

[OldPilot]

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

[theHelg]

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

[mpopov]

ИМХО заказчику не нужно знать тонкости и проблемы реализации. Но ему необходимо знать о проектных рисках связанных с проблемами реализации. Часто заказчик не понимает, что задержка одной из активностей (на критическом пути проекта) может сорвать весь проект. И необходимо напоминать ему о влиянии таких рисков всегда, когда вероятность риска повышается.

[slowcountry2]

Полностью поддерживаю, что не стоит оповещать заказчика о каждом шаге, сделанном командой на пути к решению его задач. Но! Отделываться общими фразами «Все ОК!» — тоже не к добру. Ибо если вдруг что — как вы объясните, почему сегодня «Все не ОК!». И вашу задачу мы решим не в оговоренный срок. Клиент может подумать, что вы вообще все это время ничего не делали, а только видимость работы создавали. И да, «Еженедельный статус-отчет исполнения проекта» — отличная мысль.

П.С. Первая фраза статьи — рассмешила. Спасибо.

[itwarwar]

У себя в компании я обычно предоставляю заказчику «Еженедельный статус-отчет исполнения проекта» в табличной форме, с целевыми показателями, план/факт/отклонения, риски и т.д… Как пример, в нем в одной из таблиц (общая ситуация) может быть прописано, что стейкхолдер от заказчика заболел, а его зам (все роли прописаны в матрице RACI) был в командировке, в связи с чем заказчик не смог принять (официально) один из этапов (фазы, milestone) проекта и сроки проекта сдвинулись на несколько дней (что прописано в таблицах — отчет о выполненных работах за период такой-то, что повлияло на таблицы — отклонения в проекте, запланированные работы, риски).
И заказчик все это видит наглядно.

Я считаю, что обо всем можно договориться, желательно на берегу и всегда защититься документом (реально работающим и находящемся в работе с начала проекта). В случае если заказчик начинает в начале с данным документом (статус-отчетом) «буксовать» (типа — да зачем это надо, кто это будет читать, вы там всякого по напишите), то мы ссылаемся, что у нас «регламент и процессы и начальник ругается, и в связи с этим мы не сможем эффективно отрабатывать фазы и задачи вашего проекта», заказчик соглашается. А потом сам втягивается, были случаи когда настойчиво звонили-просили статус-отчет прислать до обеда в четверг, а не как обычно в пятницу к 16:00.

Могу сказать, что стараемся работать «по этим уже нашим» ITIL, PRINCE, PMBoK, ISO и прочим сводам знаний. Удобно, приятно и четко, просто стараемся мягко приучать заказчика и своих сотрудников переносить эти знания к себе work progress и status bar ))).

[tdvsdv]

Успешный проект – проект, уложившийся в проектный треугольник (сроки, стоимость, содержание), при наличии удовлетворенного результатами заказчика.

Нет ничего подобного в PmBok. Это чья-то неудачная интерпретация успеха проекта, которая завирусилась и, более того регулярно, повторяется бизнес-тренерами разного уровня.

В PmBok (речь о 6-ой версии) описаны два документа: бизнес-кейс и план управления выгодами, которые создаются еще до того как проект инициирован. И вот в этих документах написано, что будет являться успехом. Более того, в PmBok написано, что стоит фиксировать хотя бы одну грань, которых на самом деле не три (сроки, бюджет, содержание) а больше (риски, качество и т.д.) Так вот ничего не мешает и более того чаще так происходит зафиксировать одну грань, например, сроки.