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