Концепция управления качеством проекта

Владислав Ильин

"Знающие не говорят,

говорящие не знают."

Лао цзы

Бизнес процессы ( БП ) в проектно-ориентированной компании и осуществляются в соответствии с принятыми в этой компании стандартами управления проектами. Напомним, что по общепризнанной методологии PMI (Project Management Institute) -РМВоК 2000 {1}, процессная модель проекта включает несколько стандартных стадий (инициализация, планирование, выполнение, контроль, завершение), каждая из которых предполагает выполнение определенных функций, связанных с управлением временными и стоимостными параметрами проекта, с управлением рисками, проблемами, контрактами, качеством и т.д. {1, 2} -см. Рис. 1.

Рис. 1. Стандартные стадии процессной модели проекта

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

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

Табл. 1

Проектная цель	Процессы	Метрики
Проект должен удовлетворять поставленным целям	Управление требованиями	Степень покрытия тестовыми сценариями
Управление изменениями	Количество запросов на изменения Степень изменений требований Длительность реализации запросов на изменения
Тестирование	Количество тест-раундов Количество ошибок в каждом Общее количество ошибок
Управление качеством	Количество аудитов проекта Количество выявленных замечаний и несоответствий
Проект должен быть завершен в установленные сроки и в рамках бюджета	Оценка	Размер продукта Затраты Размер проектной команды
Планирование	Количество ключевых задач Количество версий Плана Число изменений в проектной команде
Выполнение	Количество задержек на критическом пути Процент задач выполненных в срок Процент увеличения проектной команды Процент увеличения бюджета Процент решенных проблем Процент увеличения количества тест-раундов
Управление рисками	Число возможных рисков Процент сбывшихся рисков Процент рисков для которых были проведены действия по их минимизации
Удовлетворенность заказчика	Качество процессов	Оценка качества проекта заказчиком Количество выявленных замечаний и несоответствий в проекте Процент устраненных замечаний и несоответствий в проекте
Качество продукта	Плотность ошибок Плотность оставшихся ошибок

Главной особенностью БП проектно-ориентированной компании является не только их стандартная структура процессов выполнения проекта ( этапы проекта ) но и стандартные ограничения (срок, себестоимость, персонал) {2}. Именно эти стандартные ограничения по времени и стоимости реализации проектов и по качеству результатов и могут быть использованы для построения интегрального (обобщенного) показателя, характеризующего БП проектно-ориентированной компании через оценку возникающих отклонений - см. Рис. 2

Рис. 2 Модель обеспечения качества проекта

Основной ключевой особенностью всех сложных проектов является неконтрактируемое их качество.

На предконтрактной стадии невозможно заранее описать в полном объеме требования к создаваемой системе или работе.

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

И все это в "ходе игры".

Это означает, что полное определение всех требований к проекту в начале его практически невозможно. Кроме того, необходимо учитывать, что в большинстве случаев цели носят качественный характер и сами по себе не могут служить основой для определения объема работ.

Кроме того, проектный бизнес имеет еще следующие общепризнанные особенности:

• интеллектуалоемкий характер предметной области большинства проектов;
• сильная зависимость успеха проектов от поведения заказчика;
• повышенные риски нарушения сроков и бюджета, прекращения либо приостановки проекта;
• повышенные требования к качеству, имеющие конструктивный, т. е. объективно проверяемый характер;
• высокая степень индивидуализации "под клиента" и важное значение организации "плотной" работы с ним;
• быстрое моральное старение их результатов;
• высокая вероятность появления новых, ранее не выполнявшихся работ, для которых методология, технология и система управления создаются "на лету";
• высокие требования к квалификации менеджеров и исполнителей, их высокая стоимость;
• критическая важность корпоративной офисной системы, поддерживающей и бизнес, и коммуникации, и базу знаний;

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

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

Пример концепции функционала управления качеством при реализации требований ISO 9000:2000 {3} и PM BoK 2000 {1} показан на Рис. 3, а на Рис 4 соответственно представлен пример концепции управления качеством проекта.

Рис. 3 Пример концепции функциональных взаимодействий в СМК проектной компании.

1. Рис. 4 Пример концепции обеспечения качества проекта в СМК проектной компании

Для каждого конкретного проекта в соответствии с ISO 9001 и PM BoK {3, 1} сравнительно нетрудно разработать логичный комплекс мер по обеспечению качества -этот комплекс может быть оформлен, как План обеспечения качества (Quality Assurance -QA {4} ) -см. содержание шаблона QA -плана проекта на Рис.4. QA-план, как правило, является составной частью План- графика всего проекта, но может выделятся для больших проектов и как самостоятельный план (подпроект).

Рис. 4 Пример шаблона Плана обеспечения качества ( QA-План ) проекта

Выполнение QA -плана и процедур управления качеством обычно приводит к удорожанию проекта на 10-15%. И для больших и серьезных проектов это абсолютно оправданно - это как раз пример необходимого предупреждающего действия ( я бы даже назвал "мега-предупреждающего") для снижения риска высокой неопределенности при старте проекта!

Технически это прежде всего связано с постановкой и мониторингом специальных процедур (по ISO, PM BoK или СММ), которые, собственно, и обеспечивают качество проекта- см. Рис. 5

Рис. 5 Процессы обеспечения качества проекта в соответствии с требованиями ISO 9000 и модели СММ

В то же время отказ от управления качеством вообще может привести реализации очень опасных рисков и, даже, к провалу всего проекта. Это наиболее характерно как раз для больших проектов внедрения ERP-систем. Возьму на себя смелость предположить, что широко публикуемый в литературе процент неудачных проектов ( по разным данным от 78 до 84 %) является, как раз следствием, либо отсутствия, либо не выполнения QA -плана!

Внедрение вообще всех типов интегрированных ИC является хорошим примером проекта, который как раз не вполне укладывается в традиционные рамки проектного подхода. Поэтому именно в таких проектах значения QA -плана возрастает многократно - например в модели CMM , предусматривается обязательное наличие QA- плана, разработка которого является одной из ключевых практик -Оценка (гарантирование) качества товаров и процессов (Process and Product Quality Assurance){4}.

И вот почему.

Попробуем проанализировать влияние результатов этапов, например, проекта внедрения ИС Axapta, на качество всего проекта. Практика аудитов таких проектов показывает, что на качество проекта основное влияние оказывают именно начальные этапы: анализа требований, планирования ( и создания QA-плана в том числе), диагностики компании Заказчика и подготовки ТЗ - см. Рис. 6 !

Рис. 6 Экспертная оценка влияния результатов этапов ЖЦ проекта, например, внедрения ИС Axapta, на качество всего проекта

Теперь остановимся на самом важном с точки зрения управления качеством проекта на технике планирования.

Этап планирования является, по моему мнению, самым важным фактором влияющим на качество проекта. На этом этапе определяются задачи, бюджет и сроки проекта. Довольно часто планирование понимают только как составление графика работ, упуская из вида управление ресурсами, составление бюджета, управление рисками и качеством - см. Рис. 7.

Поэтому полноценная техника планирования на практике должна включает в себя следующие этапы:

1) Определение целей проекта и их описание. Довольно часто проекты начинаются без четкой цели.

2) Определение технологических стадий. Для проекта должна быть выбрана технология реализации, определяющая стадии развития проекта. Одной из типичных ошибок планирования является несоответствие плана технологическому циклу.

3) Для технологических стадий необходимо определить список задач, указать их взаимосвязи (последовательность) и прогнозируемую длительность (зависит от назначенных ресурсов).

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

5) Анализ и оценка рисков приводят к возникновению новых задач и к привлечению дополнительных ресурсов.

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

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

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

Рис.7. Концепция техники планирования проекта для обеспечения его качества

И на первом месте в обеспечении качества идет, конечно, анализ рисков {1,2}.

К сожалению, в России культура управления рисками в нефинансовой среде еще недостаточно развита, и именно из-за низкой степени проработки проектных рисков терпят неудачи даже самые типовые проекты!

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

А потери прежде всего сказываются именно на качестве !

Для конкретного проекта потери могут быть выражены в форме:

• недостаточного качества конечного продукта,
• увеличения стоимости проекта,
• превышения сроков
• провала в достижении целей проекта.

Другими словами, риск - это проблема, готовая появиться.

Согласно {1, 2} управление рисками - это процессы, связанные с идентификацией, анализом рисков и принятием решений, которые включают максимизацию положительных и минимизацию отрицательных последствий наступления рисковых событий. Процесс управления рисками проекта обычно включает выполнение следующих общих процедур - см. Рис. 8

Рис. 8 Процедуры управления рисками и оценка ( данные автора) их влияния на качество проекта

Все эти процедуры взаимодействуют друг с другом, а также с другими процедурами СМК и имеют разное влияние ( по экспертной оценке автора) на реализацию качества проекта- см. Рис. 8

Но риск - это только возможность, НО не неизбежность потерь - "кто предупрежден- тот вооружен"!.

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

Неучтенный (или возникший в ходе выполнения) риск - это всегда потеря качества проекта!

Пример варианта реализации этой процедуры приведен на Рис. 9

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

(Эффективный процесс определения рисков подразумевает обстановку, в которой люди, определяющие риски, ограждены от возможного наказания за свободное выражение противоречивых мнений. Негативное восприятие рисков отталкивает членов команды от объективного обсуждения проблем. )

Рис. 9 Пример схемы процедуры идентификации рисков планируемых проектов

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

Вот это и является тем обширным полем, где "засеяны" многочисленные риски процесса реализации проекта!

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

Рис. 10 Концепция взаимовлияния основных процедур управления ( рисками, проблемами, изменениями и качеством) на изменения первоначального плана проекта

Практика проведения проектного аудита ( более ста выполненных проектов) показала, что "потери качества" проекта происходят в основном по одним и тем-же причинам.

На Рис. 11 автор предлагает свой вариант распределения "потерь качества" в течении типового ЖЦ проекта внедрения ИС ( например, Axapta).

Рис. 11 Типовой ЖЦ проекта внедрения ИС и процессы при которых возможны "потери качества".

Вот почему QA -план в первую очередь ( согласно ISO 9001и PM BoK 2000 или СММ ) предусматривает обязательный анализ результатов каждой фазы проекта прежде, чем стоит приступать к следующей.

Понятно, что реализации процессов QA необходимо обеспечить необходимое взаимодействие всех участников проекта. Для этого нужно реализовать правильную модель коммуникаций с Заказчиком { 1 -4}.

В целом модель пример необходимой организации взаимодействия команды Исполнителя и Заказчика для обеспечения качества проекта представлен на Рис. 12

Рис. 12 Организация взаимодействия команды Исполнителя и Заказчика для обеспечения качества проекта

Отдельной темы заслуживает разговор о ключевой роли именно руководителя проекта (РП).

Давайте зададим себе вопрос, чем же реально отвечает РП за проект?

Получается, что фактически ничем, кроме своей репутации.

Ведь он ничего не производит - он лишь планирует ресурсы и контролирует выполнение задач.

Ну, бонус могут не выплатить - но огромные деньги, потраченные на увеличение себестоимости проекта (и зарплату такого менеджера в том числе), уже не вернуть никак.

Это позволяет обладателю сертификата MBA радостно браться за разваливание следующих проектов после каждого предыдущего провала.

Хотя в целом само по себе управление проектом сводится к довольно простым и хорошо известным действиям и концепциям, которые называются "диаграмма Ганта", "сетевой график" и "балансный треугольник" {2}.

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

При "предконтрактных танцах" (пресейле) c Заказчиком его убеждают, что "мы вам сделаем идеальный продукт за минимальное время при минимальных затратах - практически завтра и практически даром!" - а вот дальше уже начинается долгая игра в догоняние собственного хвоста, сопровождаемая жёстким давлением уже на исполнителей проекта.

Что из этого получается - всем давно уже известно: около 80 % проектов не достигают своей цели в запланированные сроки и с запланированной себестоимостью!

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

И одной из многих причин является именно квалификация РП.

РП, отучившийся на MBA, становится управляющим навязанными ему западными моделями, которые, как всем давно уже стало видно, чаще всего просто неадекватны.

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

Множество примеров "западного менеджмента" только подтверждают моё личное мнение об его "качестве".

Я твердо уверен в том, что тот, кто берётся управлять проектом, обязан предварительно поработать в нескольких таких проектах исполнителем - хотя бы для того, чтобы не наступать на грабли, давно уже давшие по лбу предшественникам. РП вышедшие из инженеров реально представляют себе все подводные камни проекта, знают на практике плюсы и минусы каждой методики, и стараются в первую очередь создать нормальные рабочие условия,

а не миф о том, как быстро, дешево и круто будет выполнен проект !

А всякие там MBA могут рассматриваться только как факультативное их дообразование!

А по поводу ответственности -то, по моему мнению, введение практики штрафов для РП (а не просто лишения премии/ бонуса) позволило бы избавиться от большого количества желающих "порулить" проектом !

Но вернемся к реальной жизни.

Ниже приведены примеры ( здесь и далее в среде моделирования ARIS {5}) конкретных процедур и сценариев процессов по управлению проектами в соответствии с требованиями ISO 9000:2000 и PM BoK 2000.

На Рис 13 показан пример роли РП ( здесь и далее в схеме указаны еще другие роли, отвечающие за данные действия, кроме РП ) в процедуре инициации проекта.

На Рис. 13 Пример роли РП в процедуре инициации проекта.

На Рис 14 показан пример роли РП в процессе выполнения проекта.

Рис 14 Пример роли РП в процессе выполнения проекта.

На Рис 15 показан пример роли РП в процедуре завершения фазы проекта.

Рис 15 Пример роли РП в процедуре завершения фазы проекта