Comments 5
«держать заказчика в курсе, несмотря на сопротивление» — не выходит ли такое поведение «боком»?
Не раз сталкивался, что заказчик не желает погружаться в тонкости и проблемы реализации. А подобную активность расценивает как желание «переложить с больной головы на здоровую».
Не раз сталкивался, что заказчик не желает погружаться в тонкости и проблемы реализации. А подобную активность расценивает как желание «переложить с больной головы на здоровую».
0
Конечно, не всегда это работает. Если это не уровень заказчика, например, слишком технические детали, то не стоит.
Но если это принесет пользу проекту, когда заказчик просто «прячет голову в песок, мол вы там сами уж как-нибудь» — то подключение его к решению проблем втягивает его в процесс и облегчает принятие последующих менеджерских решений
Но если это принесет пользу проекту, когда заказчик просто «прячет голову в песок, мол вы там сами уж как-нибудь» — то подключение его к решению проблем втягивает его в процесс и облегчает принятие последующих менеджерских решений
0
ИМХО заказчику не нужно знать тонкости и проблемы реализации. Но ему необходимо знать о проектных рисках связанных с проблемами реализации. Часто заказчик не понимает, что задержка одной из активностей (на критическом пути проекта) может сорвать весь проект. И необходимо напоминать ему о влиянии таких рисков всегда, когда вероятность риска повышается.
0
Полностью поддерживаю, что не стоит оповещать заказчика о каждом шаге, сделанном командой на пути к решению его задач. Но! Отделываться общими фразами «Все ОК!» — тоже не к добру. Ибо если вдруг что — как вы объясните, почему сегодня «Все не ОК!». И вашу задачу мы решим не в оговоренный срок. Клиент может подумать, что вы вообще все это время ничего не делали, а только видимость работы создавали. И да, «Еженедельный статус-отчет исполнения проекта» — отличная мысль.
П.С. Первая фраза статьи — рассмешила. Спасибо.
П.С. Первая фраза статьи — рассмешила. Спасибо.
0
У себя в компании я обычно предоставляю заказчику «Еженедельный статус-отчет исполнения проекта» в табличной форме, с целевыми показателями, план/факт/отклонения, риски и т.д… Как пример, в нем в одной из таблиц (общая ситуация) может быть прописано, что стейкхолдер от заказчика заболел, а его зам (все роли прописаны в матрице RACI) был в командировке, в связи с чем заказчик не смог принять (официально) один из этапов (фазы, milestone) проекта и сроки проекта сдвинулись на несколько дней (что прописано в таблицах — отчет о выполненных работах за период такой-то, что повлияло на таблицы — отклонения в проекте, запланированные работы, риски).
И заказчик все это видит наглядно.
Я считаю, что обо всем можно договориться, желательно на берегу и всегда защититься документом (реально работающим и находящемся в работе с начала проекта). В случае если заказчик начинает в начале с данным документом (статус-отчетом) «буксовать» (типа — да зачем это надо, кто это будет читать, вы там всякого по напишите), то мы ссылаемся, что у нас «регламент и процессы и начальник ругается, и в связи с этим мы не сможем эффективно отрабатывать фазы и задачи вашего проекта», заказчик соглашается. А потом сам втягивается, были случаи когда настойчиво звонили-просили статус-отчет прислать до обеда в четверг, а не как обычно в пятницу к 16:00.
Могу сказать, что стараемся работать «по этим уже нашим» ITIL, PRINCE, PMBoK, ISO и прочим сводам знаний. Удобно, приятно и четко, просто стараемся мягко приучать заказчика и своих сотрудников переносить эти знания к себе work progress и status bar ))).
И заказчик все это видит наглядно.
Я считаю, что обо всем можно договориться, желательно на берегу и всегда защититься документом (реально работающим и находящемся в работе с начала проекта). В случае если заказчик начинает в начале с данным документом (статус-отчетом) «буксовать» (типа — да зачем это надо, кто это будет читать, вы там всякого по напишите), то мы ссылаемся, что у нас «регламент и процессы и начальник ругается, и в связи с этим мы не сможем эффективно отрабатывать фазы и задачи вашего проекта», заказчик соглашается. А потом сам втягивается, были случаи когда настойчиво звонили-просили статус-отчет прислать до обеда в четверг, а не как обычно в пятницу к 16:00.
Могу сказать, что стараемся работать «по этим уже нашим» ITIL, PRINCE, PMBoK, ISO и прочим сводам знаний. Удобно, приятно и четко, просто стараемся мягко приучать заказчика и своих сотрудников переносить эти знания к себе work progress и status bar ))).
0
Sign up to leave a comment.
Полномочия менеджера проекта