Артему спасибо за полезную ссылку! :P

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

Очевидно, что при нарушении сроков и бюджета (в сторону уменьшения эти показатели никогда не ходют) заказчик точно не обрадуется, но получит ли он то что заказывал?

Про специфику России. Не думаю, что открою америку сказав, что на начальной стадии проекта много чего у нас не делается, что должно... Так что оценивать потом что проектная команда реализовала не просто. Заказывать аудит в SAP, с тем чтобы потом трясти консалтеров, что они плохо сваяли? Думаю не стоит.Как правило в провальном проекте клиент виноват не менее консультанта, если не более.

Это написано в противопоставление моим высказываниям или в унисон?

Собственно и так и так, просто я не успел дописать как мысли кончились.

С одной стороны, я хотел сказать, что в силу своей специфики оценки проектных работ по ходу проекта изначально формальны.

Цитата:

"Focusing on process, not results
Does this mean that there are no useful met-rics for processes with long cycle times? The Japanese often say, “Focus on process, not on results.” This is particularly good advice for processes with long cycle times. Process metrics such as “percentage of planned milestones missed or rescheduled,” “error based engineering change orders,” and “forecasting and planning process checklist items not completed” have been used effectively for driving improvement.
It is often tempting to define a metric as the gap between actual and planned results rather than process capability. However, that gap is linked to defects in the planning process or its implementation, not the under-lying process itself. In other words , it leads to the question “Why did we not achieve plan?” instead of “Why is the process pro-ducing these defects?”
"

С другой стороны сложно согласиться с положением о том что итоги подводить вредно.

Да конечно, снявши голову по волосам не плачут. То есть, когда ясно что проект провалился "пить боржом поздно" но итоги подвести все равно нужно. Провальный проект и последний проект немного различаются.

Вы знаете я тоже где-то согласен, а где-то не согласен с Вами.
Согласен в том, что после окончания проекта не эффективно нанимать кого-либо на аудит. Наш проект далеко не провальный и review это показало, в принципе отзывы SAP были только положительные. Но вот это и вредно... Думаю понимаете почему.

С другой стороны под контролем качества понимают не только контроль качества выполнения проекта, но и качество продукта этого проекта.

Если качество проекта и правдо контролируется по формальным признакам, то качество продукта контролировать возможно по прямым метрикам, главное их правильно выбрать. Как говорил один мой преподаватель: "Главное выбрать систему координат и меру отсчета".

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

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

P.S. А про совместную вину клиента и консалтера в продукте плохого качества могу сказать только одно, недавно заходил на работу к своей жене и у неё над столом висит меморандум о клиентах. Мне понравился один тезис, точно не помню, но примерно так: "Если Вы понимаете что ваше сотрудничество не принесет пользу клиенту, то постарайтесь убедить его в несвоевременности вашего сотрудничества, в противном случае вся ответственность в неполучении клиентом пользы ложится на вас". Там конечно покрасивее, но смысл такой же.

И еще.

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

Согласен, мне и самому "формально" не понравилось. Речь идет о том, что качество обычно контролируют по конечному продукту, насколько он попадает под требования и ожидания клиента, но в случае, если продукта нет, как в случае с проектом внедрения, результат следует ждать после окончания внедрения, и производственный цикл соизмерим со временем изменения требований и ожиданий клиента. Поэтому хитрые джопанюги предлагают использовать показатели процесса а не продукта.

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


зы. Собственно цитата взята из Metrics for the Order Fulfillment Process от Arthur M. Schneiderman.

Ссылку в инете не помню, но в гугле можно найти быстро. У него несколько статей об одном и том же. Мне понравилось.