30 мар 2018

Как контроль качества процессов помогает в настройке проектного управления? Часть 1

Для кого:
  • Владельцы бизнеса
  • Руководители проектного офиса
  • Руководители проектов
Знания и навыки:
  • Внедрение проектного управления
  • Контроль качества
  • Пилотирование проектов
Время на чтение:
  • 13 минут

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

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

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

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

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

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

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

Внедрение изменений по циклу PDCA

При внедрении новых процессов мы применяем классический (но почему-то редко используемый при внедрении КСУП) цикл Деминга PDCA (Plan, Do, Check, Act).

В нашем проекте на этапе «Plan» задача заключалась в разработке целевой модели, на этапе «Do» – пилотирование, на этапе «Check» — проверка работоспособности целевой модели, сбор открытых вопросов, предложений и замечаний, на этапе «Act» — корректировка процессов и запуск цикла заново.

 

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

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

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

Часто после таких внедрений заказчик в лице генерального директора или топ-менеджера получает «как бы» внедренные (но на самом деле – только описанные и согласованные) процессы, про которые невозможно объективно сказать, работают они или нет. Также непонятна, какова динамика изменений во времени – есть ли тенденция к их принятию людьми и организацией или они наоборот отторгаются и саботируются.

К моменту полноценного применения (этап «Check»), то есть к началу пилота или тиражирования консультантов может уже не оказаться рядом. А необходимой экспертизы, персонала или инструментов для осуществления замеров выполнения или корректировки процессов (этап «Act») у компании может не хватить.

Также важно понимать, что если не сделать качественный контроль качества на этапе «Act», то внесение изменений в целевую модель по итогам пилотирования после «как бы» запуска будет теоретическим упражнением. Многие активные генераторы идей по улучшению реально не попробовали работать по новым процессам и часто заинтересованы не в их совершенствовании, а в сохранении status quo. Поэтому они готовы предлагать все новые и новые способы «улучшения» лишь бы ничего не менять и не брать на себя дополнительной работы.

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

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

Кейс. Цели и задачи проекта

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

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

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

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

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

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

Прочие задачи:

  • Оценить соответствие сотрудников занимаемым ролям
  • Ответить на возникшие в процессе пилотирования вопросы
  • Внести изменения в описанные процессы по результатам пилотирования на основе реальной работы, а не голословных предложений

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

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

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

Вопросы, на которые нам предстояло ответить в рамках «ручного» контроля качества:

  • Как проконтролировать выполнение процесса и его качество?
  • Можно ли это делать оперативно и регулярно, например, еженедельно?
  • Как понять, что поступающие от участников пилота вопросы и предложения конструктивны и основаны на опыте работы в новых условиях?

Что контролировали

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

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

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

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

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

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

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

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

Регулярные практики менеджмента, которые мы проверяли:

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

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

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

Подготовка к проведению контроля качества при внедрении нового процесса

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

До контроля качества:

  • Ограничить количество проектов для проверки.

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

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

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

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

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

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

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

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

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

В нашем случае ответственным был координатор проектного комитета. В первые 1-2 месяца загрузка контролем качества доходила до 40-50% рабочего времени, включая обучение новому процессу и устранение технических проблем (см. далее) и ответы на вопросы участников пилота.

  • Заранее обеспечить и проверить доступ к архивам проектов.

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

 

Во время контроля:

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

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

  • Регулярно собирать вопросы и предложения от участников.

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

  • Фиксировать активность участников в пилоте: кто и сколько задавал вопросов, давал предложений.

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

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

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

 Результаты контроля качества

В итоге проекта мы достигли поставленных Заказчиком целей и получили следующие результаты:

  • На этапе пилотирования топ-менеджмент знал состояние процесса внедрения новых процессов (т.е. что и кто работает, а что – нет).
  • Мы смогли дать обратную связь сотрудникам, когда они не работали по процессу, до того, как об этом узнавало высшее руководство.
  • Были приняты и внедрены предложения по улучшению. Например, поработав с новой структурой папок сотрудники поняли, что нужно в ней изменить.
  • В отчетах о ходе пилота мы смогли отразить текущее состояние перехода проектов на новую модель управления.
  • Методологически результатом контроля качества стала методика и инструменты, которые помогают провести контроль качества процессов без ИТ-системы силами заказчика и может быть частично или полностью автоматизирована в дальнейшем.

Выводы

Стоит помнить, что в проекте внедрения КСУП с использованием цикла PDCA поддержка консультантов на этапах C (Check) и A (Act) является жизненно-важной.

Контроль качества в проекте настройки КСУП даже без ИТ-системы возможен и дает результаты. В дальнейшем возможна частичная автоматизация процесса контроля качества, что позволит контролировать дисциплину в полном объеме и более оперативно.

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

При этом необходимо ограничить частоту проверок с учетом их трудоемкости (один раз в две недели – вполне достаточно) и возможности обсуждения с руководством организации и другими участниками.

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

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

Авторы статьи:
Андрей Малахов, Ирина Хан
Смотрите также:
22 Мар 2024
Бюджет проекта: суть и правила составления
Недавнее исследование Outlook показало, что вопрос финансов и прогнозирования бюджета входит в тройку самых распространенных проблем в области управления проектами.
14 Мар 2024
Виды рисков в проектах и управление ими
Чтобы разобраться в понятии “управление рисками” и его роли в проектной деятельности, мы обратимся к истории и рассмотрим кейс по строительству здания парламента в Эдинбурге. Изначально стоимость работ была оценена в 40 миллионов фунтов стерлингов, но к моменту сдачи проекта смета выросла почти в 10 раз: строительство завершилось на цифре в 430 миллионов фунтов.
29 Фев 2024
Управление проектами: как это работает, для чего нужно и какие методы использовать
Главное об управлении проектами: зачем и кому это нужно, из каких этапов состоит проект, как подобрать метод, что должен уметь ваш проджект менеджер. Также вас ждут полезные рекомендации и лайфхаки для эффективного менеджмента.
Подписаться на рассылку
Высылаем анонсы статей и полезные материалы
Прокомментировать статью
Текст сообщения
Имя, Отчество, Фамилия
Email

Комментарий успешно отправлен

Произошла ошибка при отправке. Попробуйте еще раз

Наверх
Здравствуйте! Если возникли вопросы, мы на связи.
Скопировано в буфер обмена