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

С другой стороны, можно добиться 100% качества продукта, но стоимость его будет такой, что его никто не купит (например, вечные трубы для канализации, сделанные из чистого золота). Поэтому вводят понятие стоимости качества. Необходимый уровень качества на производстве оценивают, как правило, с помощью подобной диаграммы:

quality

Проекция точки пересечения этих двух кривых на ось Х и будет достаточным уровнем качества для продукции.

Следует также различать качество проекта и качество продукта:

Высококачественный продукт - продукт, который полностью удовлетворяет спецификации.

Высококачественный проект - проект, который по завершении остался в проектном треугольнике и был исполнен в соответствии с правилами исполняющей организации.

Разумеется, одно не вытекает из другого автоматически. Так, например, мы можем создать высококачественный продукт в результате низкокачественного выполнения проекта (сорваны сроки и бюджет). И наборот, мы можем создать низкокачественный продукт (спецификациям соответсвует, но работать с ним невозможно) в результате высококачественного выполнения проекта (уложились в сроки и бюджет).

Для того, чтобы получать высококачественные продукты в результате исполнения высококачественных проектов, и служит планирование качества.

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

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

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

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