Оценка эффективности выполнения проектов на основе согласования целей и внутренних метрик качества

Оценка качества проекта является сложной задачей, очевидным образом зависящей от контекста оценки. Можно ли считать качественным проект, на момент завершения имеющий минимальные отклонения от первоначального временного и финансового планов, но не достигнувший части поставленных целей? Насколько качественно выполнен проект, если итоговый бюджет и время выполнения превзошли первоначальную оценку на 20%? Были ли целесообразными произведенные затраты на управление процессами и их улучшение или можно было сделать проект с сопоставимым качеством, но заметно сократив их? Ответы на подобные вопросы приводят к постановке задачи качества проекта, как его эффективности в целом. При она должна оцениваться и связываться с потенциальным результатом задолго до завершения проекта, непосредственно в процессе его выполнения [1].

Анализ рекомендуемых в стандартах практик управления качеством показывает, что они сводятся созданию плана управления качеством, выполнения предусмотренных им процессов и их непрерывного совершенствования [2]. Предусмотрены процедуры аудита и анализа отчетов по качеству, дополненные процессами контроля качества. Последний, в большинстве случаев, сводится к получению и анализу данных по наиболее легко доступным для сбора измеримым показателям, таким как время, финансы и количество выполненных задач. Не смотря на очевидную пользу от их реализации, общее качество проекта рассматривается в отрыве от его целей.

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

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

Другим распространенным подходом является управление рисками и качеством в рамках единого процесса [4]. Отдельные категории рисков помещаются в контекст организации, привязываются к жизненному циклу проекта и управляются в соответствии с рекомендациями стандарта по управлению рисками [5]. Данных подход позволяет более релевантно отобразить цели проекта на процесс его выполнения. При этом управление качеством всё равно остается за пределами контекста проекта.

Другая группа метрик основана на том, что качество проектов может быть сведено к оценке прямого или косвенного экономического эффекта их выполнения. В этом случае оценка качества проекта сводится к его вычислению и сопоставлению с ожидаемыми значениями. Для систем менеджмента качества (СМК) широкое распространение получила модель оценки расходов, связанные с предупреждением, оценкой и отказами (далее PAF-модель). Однако, многочисленные попытки применить эту модели для оценки эффекта от управления качеством в проектах [1] показали, что ее практическое применение не дает требуемого результата. Это обусловлено тем, что PAF-модель фокусируется на измерении стоимости качества по всей цепочке производства. В результате объем требуемых для нее ресурсов при адекватной реализации в проектах становится неприемлемым [6].

Альтернативой для PAF-модели является модель стоимости процесса (далее – PCM-модель) [7], разделяющая стоимость качества COQ на стоимость соответствия COC и стоимость несоответствия CONC:

COQ = COC + CONC где COC – стоимость процесса обеспечения продуктов / услуг в соответствии с заданными стандартами или требованиями, для данного процесса в наиболее эффективном его варианте;

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

Действующий стандарт РФ по достижению экономического эффекта в СМК [8] базируется именно на этом методе. Однако, он ориентирован на оптимизацию процессов, приводящих к достижению экономического эффекта, а не на оценку его размера и влияние на него характеристик процессов. Это исключает его применение без существенных изменений.

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

МОДЕЛЬ ПРОЦЕССОВ ДЛЯ ОЦЕНКИ ВЛИЯНИЯ ОПЕРАЦИОННЫХ МЕТРИК НА ЦЕЛИ ПРОЕКТА

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

Необходимо построить модель, которая учитывала бы как прямые, так и косвенные связи между целями и операционными метриками. Такая модель должна позволять взаимно согласовать описание целей, требований и метрик с учетом контекста исполняющей организации и существующих между ними зависимостей. Для описания этих зависимостей возможно использование любой сетевой структуры (графа), на которую эти зависимости будут отображаться. С другой стороны, целесообразность её согласования с процессами декомпозиции, типовыми для организации содержания проекта в иерархическую структуру работ, делает предпочтительной нисходящую древовидную структуру [2].

Выбор количества уровней в дереве будет заметно влиять на удобство использования и восприятия модели участниками проекта. Чем меньше их количество — тем более понятно и интерпретируемой будет модель. С другой стороны, большее количество уровней позволяет строить более сложные модели управления качеством проекта. Рассмотрим возможные варианты.

При анализе процессов уровня компании существуют модели согласования стратегии (Strategic Alignment Model - SAM)) [9], включающая два уровня согласования:

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

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

Можно заметить, что в SAM на верхнем уровне формируется контекст цели в привязке к компании, а второй уровень может быть использован для формирования метрик. Например, если мы имеем дело с информатизацией, такие метрики могут быть взяты из соответствующего стандарта, такого как COBIT5 или ITIL. Проблемы возникают при практическом применении. Даже если ограничиться только относительно высокоуровневыми метриками качества, их количество будет настолько велико, что описание и формирование связей между целями и метриками приведет к чрезмерному количеству связей. Более того, многие из таких связей могут оказаться неочевидными или избыточными и их отслеживание скорее затруднит, чем улучшит управление проектом.

Развитием этой идея является добавление промежуточного транзитного слоя, связывающего через себя цели на верхнем уровне и метрики качества на нижним. Необходимо определить, что должно быть на этом слое. Одним из вариантов является отображение на этот слой операционного уровня функционирования компании или проекта [10]. На него помещаются вопросы, ответы на которых характеризуют способ оценки/достижения конкретной цели. Вопросы предназначены для спецификации объекта измерения (продукта, процесса, ресурса) по отношению к некоторому свойству качества. Можно сказать, что они определяют качество при взгляде с некоторой точки зрения, связанной с участником проекта.

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

Учитывая, что любое усложнение такой модели затрудняет её практическое использование, представляется разумным ограничиться требованиями, которые могут быть помещены на один уровень, либо требованиями, которые могут быть получены из этих требований путем прямой декомпозиции. Это означает, что связи между ними проходят строго «сверху вниз», горизонтальные связи внутри уровня отсутствуют (рис. 1).

Рис. 1. Трехуровневая модель процессов проекта для оценки влияния метрик

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

На втором этапе выбирается общая модель качества проекта. Для информационной системы это может быть ITIL, для промышленной ISO 9001. Следует отметить, что речь идёт не о полном соответствии некоторому стандарту, а об общем подходе, наиболее подходящим предметной области и знакомой участникам проекта. Как правило, это делается в плане управления качеством проекта [2].

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

Приведенная модель процессов является достаточно общей, что позволяет использовать её, как базу для построения специфичных для конкретной области применения моделей. Наиболее очевидным является уже использование с существующей моделью качества, принятой в предметной области, например, информационных системах [11]. Это означает относительно жёсткую фиксацию уровня метрик с построением верхних двух уровней с опорой на неё.

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

Менее очевидным, но потенциально более важным, является возможность построения на базе предложенной модели процессов интегральной модели, сочетающие модель качества с моделями другого вида. В этом случае вторая модель использует данные (узлы и связи) модели процессов на рис. 1 в качестве своих входов и выходов, автоматически обновляя связанную модель на основе собираемых метрик качества [11]. Такие модели можно назвать «вертикально связанными» (рис.2, левая часть).

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

Такие модели хорошо совмещаются с современными подходами к управлению проектами, которые прямо предполагает совместное управление качеством и рисками [4], оставляя большинство вопросов их координации на усмотрение руководителя проекта. Предлагаемая модель процессов позволяет упростить это действие, поскольку в большинстве случаев рисковая модель привязывается к ИСР, построенной на базе собранных, проанализированных и приведенных во взаимное соответствие требований [ 2 ].

Рис. 2. Варианты совместного использования модели процессов с внешними моделями

Другим вариантом модели, которая может использоваться как вертикально связанная, является модель информационных потоков в проекте. Для многих компаний фиксация документарного обеспечения проектов является элементом общей СМК, построенной на базе одного из стандартов. Это характерно для процессов закупок и согласований или реализации на основе существующей информационной системы [11]. В этом случае акцент переносится с предметной области на общую оптимизацию процессов. Команда управления проекта использует эту модель для связи с документами проекта, эффективно встраивая её в существующую СМК.

ЗАКЛЮЧЕНИЕ

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

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

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

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