Irvuz

Планирование качества проекта

Журнал УПРАВЛЕНИЕ ПРОЕКТАМИ ‐ Оцениваем качество планов проектов. Подходы и практика применения

Планирование качества проекта

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

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

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

В статье рассматривается опыт ООО «Аэроэкспресс» при использовании показателей контроля качества календарных планов, анализируются рекомендации DCMA (The USA Defense Contract Management Agency) по контролю качества календарных планов проектов, формируются рекомендации по развитию системы оценки планов в задачах проектного управления.

Уже внедряя систему управления проектами, мы в «Аэроэкспрессе» продолжали анализировать опыт и варианты построения информационных систем управления проектами (ИСУП).

В одной из организаций нам представили ИСУП собственной разработки.

Сразу оговоримся: компания была строительная; система, в отличии от нашей, строящейся на базе MS Project Server и SharePoint, строилась на базе программного обеспечения с открытым кодом.

Систему презентовал сам генеральный директор. Было видно, что он разбирается в функционале. При наличии достаточно качественных буклетов с описаниями, демонстрация проводилась «вживую» и на ведущихся проектах. Это еще больше вызывало уважение и подтверждало практическую возможность применения ИСУП.

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

Тут выяснились некоторые нюансы работы и особенности использования презентуемой ИСУП в принятии управленческих решений.

Тогда мы эту систему не купили. Поняли, что наша ИСУП, разрабатываемая совместно с ООО «Бастион Интегратор», не хуже. Но возникло чёткое понимание того, что отчёты по проекту нельзя даже рассматривать, если они построены на основе неактуальных данных. При этом, «ручные» проверки или фиксация новых требований в регламентах проблему не снимут.

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

Опыт и некоторые уроки применения оценок качества планов проектов в ООО «Аэроэкспресс»

Начав в ООО «Аэроэкспресс» использование функционала автоматизированного оценивания качества планов проектов с лета 2015 г. и с 6 показателей, количество оцениваемых показателей на конец 2016 г. возросло до 12.

  1. Не актуальные строки плана — строки плана, которые на дату оценивания должны начаться, но фактически не начаты, или должны закончиться, но фактически не завершены. Устранение «проблемных» мест связано с корректировками дат начала/окончания в исполняемом плане, либо с вводом актуального % по фактическому исполнению.
  2. Вехи без подтверждения — те завершенные вехи, по которым не прикреплены подтверждающие документы к строке плана. Проведённые доработки функционала совместной работы с документами позволили упростить прикрепление документов, размещенных на сайте проекта, к строкам календарного плана. Это сделало планы более пригодными для совместной работы с документами и облегчило администрирование исполнения задач. Устранение «проблемных» мест связано с размещением недостающих подтверждающих документов на сайт проекта и с их прикреплением к завершенным вехам.
  3. Работы и вехи без взаимосвязей — «висящие» задачи, т.е. не содержащие предшественников и/или последователей в сетевой модели. Устранение «проблемных» мест связано с дополнением сетевой модели: корректировка логических взаимосвязей между задачами и добавлением новых задач, при необходимости.
  4. Лишние взаимосвязи — взаимосвязи с блоками работ. Устранение «проблемных» мест связано с анализом необходимости таких взаимосвязей и их переключением на «внутренние» вехи/работы блока.
  5. Неактивные строки плана — деактивированные строки плана. Устранение «проблемных» мест связано с анализом возможности исключения строк из исполнения в рамках реализации проекта.
  6. Ручное планирование — строки плана с ручным режимом планирования. Устранение «проблемных» мест связано с анализом необходимости режима «ручное планирование» для соответствующих задач и с переключением режима планирования на автоматический.
  7. Локальные ресурсы — работая с серверной версией MS Project мы исключаем возможность некорректного назначения «неучтенных» или фактически отсутствующих ресурсов на работы плана. Устранение «проблемных» мест связано с корректировкой пула ресурсов проекта и переназначением локальных ресурсов на корпоративные.
  8. Недостаточная детализация работ — работы календарного плана ближайшего интервала планирования с длительностями более интервала планирования. Устранение «проблемных» мест связано с анализом необходимости/возможности декомпозиции работ и проведением соответствующей декомпозиции.
  9. Блоки без вех — блоки календарного плана, в рамках которых не заданы вехи. Устранение «проблемных» мест связано с анализом необходимости фиксации контролируемого события/результата в рамках блока с соответствующим дополнением плана.
  10. Блоки с назначенными ресурсами — блоки календарного плана, по которым назначены ресурсы. Проведённая разработка функционала матрицы ответственностей позволила назначать различные роли из числа участников проекта на блоки работ (например, ответственный исполнитель, принимает результат, информируется и проч.). Это позволило избежать возможных ошибок и несоответствий в расчетах исполнения, обусловленных назначением ресурсов на блоки, а также формировать дополнительные уведомления по блокам для соответствующих ролей на них назначенных. Устранение «проблемных» мест связано с удалением ресурсов с назначений на блоки и назначением ролевых ответственностей, при необходимости.
  11. Декомпозиция блока 1 в 1 — блоки календарного плана, являющиеся единственными в рамках родительского блока. Устранение «проблемных» мест связано с анализом необходимости/возможности и уточнением структурной декомпозиции родительского блока.
  12. Блок как веха — блоки календарного плана, помеченные как вехи. Устранение «проблемных» мест связано с удалением признака «веха» с блока работ.

Все показатели объединяются в сводную таблицу (см. рис.1), и по каждому дополнительно формируется аналитическая таблица с указанием выявленных/возможных «проблемных» мест (см. рис.2). При этом, показатели разбиты на две группы:

  1. Оцениваемые показатели — по данным показателям оценки должны находиться в «зеленой» зоне;
  2. Информационные показатели — по данным показателям значения качества еще не установлены, либо сами оцениваемые критерии носят информационный характер.

Рис. 1. Сводная таблица оценивания календарного плана

Рис. 2. Примеры некоторых таблиц, указывающих на выявленные/возможные «проблемные» места в плане

Имея цифровые оценки и индикацию «проблемных мест» можно анализировать существенность проблем для качества плана и проекта в целом.

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

Время подтвердило и полезность данного функционала: начав с сотен «проблемных мест» по некоторым из показателей, что соответствовало 15–20% строк плана, сейчас по отчёту получаем единицы «проблемных мест», причем, практически ни одно из них проблемным и не является, а обусловлено особенностями конкретного проекта. Фактически можно говорить о развитии культуры планирования проектов.

Сейчас на повестке дня стоят следующие задачи:

  • дальнейшее развитие и уточнение показателей и алгоритмов оценивания;
  • внедрение критериальных требований к планированию в проекте для различных фаз управления (в т.ч. инициирование, открытие, реализация) и к качеству планов проекта для различных функциональных областей управления (в т.ч. управление сроками, управление затратами, управление закупками и проч.) с соответствующей поддержкой различным набором целевых и оценочных показателей;
  • применение оценок к планам и отчётам, представляемых контрагентами по «своим» участкам/блокам выполняемых работ;
  • освоение широким кругом руководителей и сотрудников организации подходов и принципов проектно–ориентированного планирования и управления в целом (см.,в частности [1 и 2]).

Стандарты / рекомендации оценивания качества планов

Какие еще подходы и параметры можно использовать для контроля качества проектов? В стандартах PMI нет прямых и точных рекомендаций по этому вопросу. Речь идет и о широко известном PMBОK [3] и о практических стандартах PMI (в частности, о Work Breakdown Structure Practice Standard, Practice Standard for Scheduling, Practice Standard for Project Estimating [5 – 7]).

Источник: https://pmmagazine.ru/articles/ocenivaem-kachestvo-planov-proektov-podxody-i-praktika-primeneniya/

Документирование качества проекта

Планирование качества проекта

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

Продолжаем цикл статей и видео-уроков по управленческому документированию проектов. Перед тобой седьмая статья из этого цикла – «Документирование качества проекта».

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

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

Поэтому оставляй глобальное управление качеством на совести менеджеров по качеству всей компании, а сам сосредоточься только на важном для проекта.

Пойми, что необходимо и достаточно

В статье о документировании объёмов работ, я описал как выяснить и оформить требования. Частным случаем требований являются требования к качеству исполнения проекта и к качеству продукта проекта. Называется это «метрики качества».

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

диапазон значений в котором величине каждого параметра разрешено изменяться.

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

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

  1. Частота совещаний по проекту должна быть не чаще 1 раза в неделю, но не реже 1 раза в 3 недели. Длительность совещания не может быть более 1 часа. А количество участников совещания должно быть не более четырёх.
  2. Отчёт должен выходить каждый четверг в 16:00 +/- 2 часа.

Таким образом собираем все нужные нам параметры с характеристиками и всё это аккуратненько заносим в таблицу «Метрик качества».

Но метрики качества — это так, для разминки. Теперь самое интересное.

Напиши, как будешь делать

Любой подход к управлению качеством сводится к трём «простым» действиям:

  1. Напиши, как будешь делать (планирование качества)
  2. Делай, как написал (обеспечение качества)
  3. Чтоб независимый специалист мог сверить делаемое и написанное (контроль качества)

Мы разделим эти действия на стратегический и тактический уровни. На стратегическом уровне нужно создать план управления качеством, на тактическом уровне — чеклисты для каждого типа работ в проекта.

План управления качеством — это многостраничный документ, типа «процедура», в которой как раз и описывается то, что описано в этой статье, только чуток шире. В состав плана управления качеством входят следующие разделы:

  1. Метрики качества
  2. Обеспечение качества
  3. Контроль качества
  4. Постоянное совершенствование процессов
  5. Шаблон чеклиста

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

Постоянное совершенствование процессов — это то, что команде проекта достаётся в нагрузку от ОУП или от системы управления проектами в компании.

Единичному проекту, этот раздел ничего полезного не несёт, а вот если проекты идут на потоке, то качество от проекта к проекту можно совершенствовать. Каждый исполнитель проекта может улучшать качество на своём уровне.

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

Делай, как написал

Самым важным моментом в обеспечении качества проекта, является передача этого «обеспечения» непосредственному исполнителю работ. Поэтому, друг мой, пиши чеклисты! Причём сколько в проекте типов работ, столько должно быть и чеклистов, а может и больше (если учесть подтипы работ).

Чеклист — это список самопроверки исполнителем своей работы. Когда исполнитель выполняет работу он может увлекаться или, наоборот, халтурить. Поэтому нужно дать ему список характеристик его работы или продукта, по которым он сам себя может проверить ещё до того, как он передаст результаты своей работы ПМ-у или своему руководителю.

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

  1. На верхнем уровне график проекта полностью соответствует WBS проекта.
  2. Все задачи увязаны связями.  У всех задач (кроме первой и последней) есть предшественник и последователь. Ни одна задача не привязана жестко к определённым датам.
  3. Для задач, которым требуются конкретные даты по контракту или уставу, установлены параметры «дедлайна».
  4. В графике нет задач с длительностью превышающей управленческий (или отчётный) период проекта.
  5. На суммарные задачи назначены резервы.
  6. Ресурсы выровнены и не перегружены.
  7. Выгружаемая из графика S-кривая напоминает букву S.

И т.д. Здесь я не буду перечислять все характеристики графика, которые должен проверить в своём графике планировщик, поскольку такие чеклисты желательно иметь для всех исполнителей в проекте и не хватит букв, чтоб все их перечислить для всех проектов.

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

С точки зрения документирования, итог планирования управления качеством проекта выглядит следующим образом:

  1. Метрики качества, дающие нам описание характерных свойств проекта и/или продукта и способы оценки этих свойств.
  2. План качества, который объединяет политики нашей компании в области качества с конкретными действиями по обеспечению качества в нашем проекте.
  3. Чеклисты, содержащие структурированный список параметров и характеристик, используемый для проверки выполнения работы.
  • Шаблоны всех этих и других документов по управлению качеством проекта можно получить/полистать здесь:
  • Полный пакет шаблонов, созданных на основе PMBOK (5-й редакции) можно получить здесь: ОСУП.Комплект.v5
  • Полный пакет шаблонов, созданных на основе ISO 21500:2012 можно получить здесь: ИСО21500:Комплект
  • Все примеры и шаблоны документов портала PMDoc, связанные с управлением качеством различных проектов, можно получить здесь: Качество проекта.
  • Документация Системы Менеджмента Качества проектно-ориентированной организации, которая используется для проектов разработки, внедрения и развития систем управления качеством: СМК.Комплект (бесплатно).

В следующей статье я расскажу, как документировать поставки проекта.

Источник: http://www.pmdoc.ru/docs_of_project_quality/

Управление качеством проекта. Как достичь нужного результата

Планирование качества проекта

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

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

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

Однако управление качеством проекта направлено не только на продукт проекта, но и на сам проект. В этом случае подходы к управлению качеством будут одинаковы.

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

Критерии качества проекта

Мы говорим, что проект осуществляется качественно, когда:

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

К более мягким критериям качества проекта можно отнести:

  • положительный отзыв заказчика и его повторное обращение;
  • малое количество утвержденных изменений;
  • перспективность использования продукта/результата и др.

Очевидно, что если в компании уже внедрена Система менеджмента качества (СМК, или Total Quality Management), есть служба качества, прописаны процедуры и стандарты, то часть вопросов по управлению качеством реализуемого компанией проекта отпадает. Существующие культура и технология управления качеством в компании переносятся и на проект.

Стандартизированные процедуры

Чтобы добиться высокого качества проектной работы, нужно внедрить стандартизированные процедуры.

Установление приоритетов проектов. Как правило, эта процедура выполняется раз в год.

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

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

Ее предназначение – создать хорошую основу для продуманного планирования. Она гарантирует, что планы составляются на обоснованно выбранные временные горизонты.

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

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

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

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

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

Его прохождение очень важно для ROI при внедрении проектных практик в организации в целом и для составления и накопления, а также использования базы знаний.

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

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

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

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

Поддержка руководства и финансовое обеспечение

Для качественной реализации проекта важна поддержка на уровне руководства. Не только формальная, но и практическая (в том числе ресурсная) в сфере управления качеством.

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

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

Управление качеством должно быть обеспечено финансовыми и иными ресурсами. Затраты на управление качеством входят в общую смету проекта, а сами работы — в план управления проектом.

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

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

  1. Составляется перечень измеряемых показателей качества проекта, например: требования к продукции и проектной документации; требования к компетенции членов команды; время начала совещаний; время поступления сырья и т. д.
  2. Далее определяются стандарты или нормативы качества, с которыми эти показатели будут сравниваться. К ним могут относиться внешние стандарты: ГОСТы, ТУ, СНиП, ЕСКД, ЕНиР, внутренние стандарты компании, регламент по управлению проектами, моральный кодекс сотрудника компании, политика документооборота, международные стандарты (ISO), план контрольных точек и т. п.
  3. Устанавливается необходимый уровень показателей качества проекта исходя из сравнения с соответствующими показателями других проектов, экспертной оценки, результатов тестирования и т. д. Если одним из показателей выбрано время начала совещания по проекту, а стандартом — правила внутреннего распорядка работы компании (наиболее близкий стандарт), то установленная задержка начала совещания не должна превышать общепринятой в компании.
  4. Устанавливаются возможные допуски отклонения показателей качества от стандарта, т. е. измеримые границы показателя, при превышении которых следует предпринимать действия по корректировке качества.
  5. После определения величины допуска указываются используемые инструменты и методы, погрешность измерения. Определяются ответственные и пути документирования, а также лица, принимающие решение о корректировке качества при его нарушении, процедуры проведения такой корректировки, даты контроля и наименование используемой документации.

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

Документация включает:

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

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

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

И пусть ваши проекты всегда будут успешны!

Марина Кирилина

Источник: https://e-mba.ru/knowledge-base/upravlenie-kachestvom-proekta-kak-dostich-nuzhnogo-rezultata

Лекция 4- Планирование обеспечения качества в проекте Разработка плана обеспечения качества

Планирование качества проекта
Работа добавлена на сайт samzan.ru: 2016-03-13

Лекция 4: Планирование обеспечения качества в проекте

  1.  Разработка плана обеспечения качества.
  2.  Регламент по управлению качеством в проекте.
  3.  Примеры процедур планирования качества.
  4.  Процедура документирования.
  5.  Процедура согласований документов проекта.
  6.  Процедура утверждения документов.
  7.  Организация управления качеством.

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

 Планирование качества проекта начинается с определения объектов, качество которых необходимо обеспечивать. Планирование качества проекта начинается с определения объектов, качество которых необходимо обеспечивать. В табл. 4.

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

Разработка плана обеспечения качества

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

План содержит в себе список работ, которые необходимо выполнить в сфере управления качеством проекта, а также время (график) выполнения работ. Мероприятия по обеспечению качества должны быть разработаны в самом начале проекта и должны проводиться на основе независимых экспертных оценок [11].

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

Регламент по управлению качеством в проекте

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

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

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

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

Итак, сначала определим процессы, на которых возможны потери, и сами потери качества (табл. 4.2).

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

Процедура документирования – предназначена для управления документированием в проекте.

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

Процедура согласований документов проекта – подготовка документов осуществляется рабочими группами проекта. В процессе обсуждения участники рабочих групп могут консультироваться по обсуждаемым вопросам с другими участниками проектной команды СДО.

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

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

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

Рабочие группы производят анализ замечаний и в течение 3-х дней подготавливают исправленную версию документа. Исправленный документ и отчет направляется согласующему лицу для высказывания своей оценки по корректности внесенного исправления в течение 3-х дней.

По каждому из замечаний необходимо наложить резолюцию “принять” либо “отклонить” (с объяснением причин). В случае необходимости руководители групп обсуждают замечания и возможные решения с авторами замечаний.

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

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

Формируется пакет документов, состоящий из двух электронных копий документов на CD и листов, на которые ставятся подписи (обложка и лист согласования на каждый утверждаемый документ). Два идентичных пакета документов предназначены для заказчика и исполнителя.

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

Утверждающие лица после получения извещения детально знакомятся с пакетом документов. После ознакомления и согласования утверждающее лицо подписывает документ. После этого документ считается утвержденным.

Подписанные листы и соответствующие электронные версии документов являются утвержденными версиями проекта.

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

Обеспечение качества – процесс выполнения плановых систематических операций по качеству, которые обеспечивают выполнение всех предусмотренных процессов, необходимых для того, чтобы проект соответствовал установленным требованиям по качеству [23].

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

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

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

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

 табл. 4.4). Контрольные списки качества – это метрики качества, которые определены для каждого этапа проекта на основании ожиданий заказчика, этим метрикам присвоен свой статус: критический, серьезный, важный.

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

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

Таблица 4.4. Пример контрольных списков проверки качества

Этап проекта

Ожидаемый результат

Тип

Да

Нет

Регулирование настроек

Процент настроек, соответствующих описанию в документации (допустимая погрешность 3%)

Критичный

Определение требований к среде

Список требований

Критичный

Настройка инфраструктуры

Список настроек

Критичный

Разработка функциональных характеристик

Количество возникших ошибок при работе. Процент ошибок в ходе работы

Критичный

Определение параметров разработки и плана тестирования

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

Критичный

Анализ проекта

Наличие протоколов по анализу результатов каждой фазы проекта

Серьезный

Управление изменениями

Документирование всех запросов на изменение в соответствии с принятой формой и их сохранение в единой базе

Критичный

Пояснения к заполнению формы контрольных списков

  1.  Этап проекта – процесс, для которого необходимо прописать ожидаемый результат.
  2.  Ожидаемый результат – метрика качества, которую необходимо достичь.
  3.  Тип – присвоенный тип данной метрики, может быть критический, серьезный, желательный.
  4.  Да/Нет – достигнут ли ожидаемый результат. Заполняется на этапе контроля и обеспечения качества проекта.

Данные о результатах контроля передаются исполняющей организации для использования в процессе обеспечения качества, для повторной оценки и анализа стандартов качества на последующих фазах ЖЦ ИС. Пример формы представления результатов контроля качества приведен в табл. 4.5.

Таблица 4.5. Форма представления результатов контроля качества

№ п.п.

Объект контроля качества

Дата замечания

Замечание

Автор замечания

На рис. 4.1 приведено графическое изображение процедуры разработки контрольных списков качества.

Рис. 4.1. Процедура разработки контрольных списков (графическое изображение)

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

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

Внеплановые аудиты проводятся по запросам заказчика, руководителей департаментов и отделов. Аудиты качества проводятся на основе критериев, каждый из которых является следствием требований нормативной документации системы менеджмента качества (требование ISO 9000) и системы управления проектами (PMBOK).

Схема проведения внутреннего аудита качества проекта может выглядеть следующим образом:

  1.  анализ исправления замечаний предыдущей проверки;
  2.  проведение проверки проекта в соответствии с контрольными списками ;
  3.  оформление отчета о контроле качества;
  4.  информирование команды проекта о появлении новых отчетных документов.

Ниже приведен шаблон для регистрации списка отклонений и описание процедуры обеспечения качества (табл. 4.6).

Таблица 4.6. Шаблон регистрации отклонений

№отклонения

Дата выявления

Название работы

Описаниеотклонения

Статус отклонения

Предпринятые действия

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

[отложено – работа будет принята несмотря на выявленное отклонение, поэтому нет необходимости предпринимать какие-либо действия

серьезное – отклонение необходимо устранить, чтобы качество проекта соответствовало заданному уровню

в работе – отклонение передано в рассмотрение в процедуре управления проблемами, ответ ожидается

критическое – работа полностью не соответствует требованиям заказчика]

исправлено – отклонение исправлено и работы завершены]

Рис. 4.2. Графическое описание процедуры управления качеством

Таблица 4.1. Анализ процессов управления качеством

Название

Описание

Последствия невыполнения

Последствия при  выполнении

Оценка процесса

Владелец

Источник: http://samzan.ru/62645

ovdmitjb

Add comment