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