Основы управления проектами в компании

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

Иными словами, все внутри и вне проекта должно быть качественным. Только тогда мы обеспечиваем всеобщее качество и продукта и проекта.

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

1.Поддержка и участие руководства в управлении качеством.

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

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

Из практики

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

2.Основное внимание заказчику и потребителям продукта/результатапроекта.

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

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

3.Стратегическое планирование.

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

4.Вовлечение всех сотрудников.

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

5.Подготовка персонала.

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

6.Награды и признание.

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

7.Качество поставщиков.

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

8.Информационная система.

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

9.Лучший опыт.

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

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

11.Качество персонала.

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

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

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

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

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

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

Среди основных подходов при планировании качества представлены следующие.

Анализ затрат и выгод.

Это анализ выгод от соответствия планируемого уровня качества продукта и процессов управления проектом, а также затрат на его обеспечение. Нужно обеспечивать ровно то качество, которого ждут от вас заказчик и потребитель, или лучшее (но только если это улучшение не требует дополнительных затрат или приводит к возрастанию ценности продукта, а, значит, прибыли). Если компания строит дом по так называемым экономическим ценам, то обеспечение более высокого качества не приведет к новым выгодам, так как потребитель не сможет заплатить более высокую цену. Незапланированное повышение качества ремонта квартиры, как правило, увеличивает стоимость ремонта (но кто понесет затраты, если при этом строительная компания не уговорит заказчика на новую цену ремонта?).

Сравнительный анализ.

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

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

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

Планирование экспериментов.

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

Определение стоимости работ по планированию, контролю и обеспечению качества.

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

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

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

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

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

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

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

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

Возьмем в качестве примера проведение совещаний по проекту, где один из показателей качества - это длительность совещания. Стандарт определяется корпоративной культурой компании, ее режимной политикой и существующими принципами управления временем (например, это один час). Возможным превышением может быть время в 10 мин. То есть при превышении длительности совещания менее чем на 10 мин качество этого процесса считается допустимым и никаких корректирующих действий не осуществляется. Однако если совещание растягивается на 1 ч 12 мин, то идентифицируется проблема качества управления и производятся необходимые корректирующие действия. Упомянем о так называемом правиле «Джурана», которое гласит, что если при многократном повторении процесса показатели колеблются, не превышая допуска в 10-15%, то это обусловлено внешними причинами. Превышение 15% связано уже с ошибкой данного процесса. Такими многократными процессами в проекте могут быть ограниченное число работ - проведение регулярных совещаний, подготовка типовых отчетов, строительство типовых этажей в большом доме и т. д.

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

9.5 Обеспечение качества

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

9.6 Контроль качества

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

9.7 Основной инструментарий

9.7.1 Диаграмма Парето

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



Рис. 9.1 Диаграмма Парето

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

9.7.2 Диаграмма Исикавы (Ишикавы)

Одним из очень популярных инструментов определения причин возможных нарушений показателей качества процесса в отдельности или всего проекта является причинно-следственная диаграмма, предложенная Каору Ишикавой (Исикавой) и именуемая иногда на сленге менеджеров «Рыбой» (рис. 9.2). Этот инструмент, в отличие от диаграммы Парето, применяется в случае уникальных, неповторяющихся подпроцессов, когда невозможно набрать статистику повторений. В голове диаграммы (более похожей на рыбий скелет), изображаемой справа, располагается возможный сбой качества проекта, например плохое качество изготовляемой документации. Самостоятельно или с помощью целевой группы определяются все возможные причины, которые могут привести к этой проблеме. Для ясности и простоты причины группируются по следующим признакам: люди (men), машины (machines), методы (methods), материалы (materials) и ряд других, например среда (media), менеджмент (management). Часто эту диаграмму также называют диаграммой «пять М». Далее визуально соединяют все причины с проблемой, продолжают поиск и анализируют информацию. Такая структура необходима для уверенности, что исследуется максимальный список возможных причин. Для более детального анализа используются подгруппы, своего рода «косточки» на рыбьем скелете.

Рис. 9.2 Диаграмма причинно-следственных связей для управления качеством

9.7.3 Метод «Пять Почему»

Другим инструментом, тесно связанным с диаграммой Исикавы и помогающим разобраться с первопричинами нарушений показателей качества проекта, является так называемый анализ «Пять Почему». Его суть заключается в следующем.

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

Рассмотрим еще один пример. Обнаружена проблема: не работает компонент продукта проекта - схема, собранная на электронных комплектующих. Почему она не работает? Потому что частично комплектующие оказались влажными и окисленными и некоторые лежали на полу склада рядом с коробкой. Почему это случилось? Например, они рассыпались из коробки. Почему это произошло? Коробка промокла. Почему же она промокла? Дождь проник сквозь дыру в крыше склада. Почему? Потому что иногда идет дождь. Мы не в состоянии повлиять на погоду, но, поднявшись на предыдущий уровень, мы можем уже оказать влияние и заделать дыру в крыше склада. Здесь мы уже дошли до пятого уровня.

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

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

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

Таблица 9.1

Вопросы	Ответ для первопричины
Возможно ли контролировать обнаруженную причину?	Да!
Спросив еще раз «Почему?», можно ли получить другую контролируемую причину?	Нет!
Является ли выявленная причина фундаментальной неисправностью или сбоем процесса?	Да!
Обеспечит ли усовершенствование/корректировка выявленной причины дальнейшее отсутствие случаев возникновения выявленной проблемы?	Да!

9.7.4 Паспортная система

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

9.7.5 Аудит и экспертиза качества управления проектом

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

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

9.8 Документальное и организационное обеспечение

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

общую политику качества в компании и документы по СМК (при ее наличии);

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

план управления качеством отдельного проекта;

рабочие и контрольные инструкции;

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

Организационное обеспечение включает:

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

систему взаимодействия участников проекта и компании по вопросам качества;

материально-технические ресурсы (материалы, оборудование, приборы);

финансовые ресурсы;

ответственного по системе качества от высшего руководства компании;

работу по постоянному совершенствованию системы управления качеством;

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

Глава 10. Внедрение проектного управления

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

10.1 Общие подходы к внедрению проектного управления

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

Из практики

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

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

2. Даже при общей лояльности персонала для запуска методологии и КСУП

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

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

4. Никакое внедрение в настоящее время не сможет обойтись без какого-либо информационного обеспечения или ИСУП. Это может быть модель корпоративной информационной системы, адаптированный для управления проектами специально приобретенный продукт.

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

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

Из практики

Автору приходилось работать с российскими компаниями, которые условно можно разделить на три основные группы:

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

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

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

10.2 Формирование идеологии

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

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

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

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

Из практики

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

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

* «жесткий противник», саботирующий применение всех проектных приемов и инструментов, резко негативно относящийся к нововведениям;

* «мягкий противник», поведение которого выражается выжидательной позицией - подожду, что будет, может мое мнение изменится, но использовать это сейчас точно не стану;

* «равнодушный», следующий принципу: буду работать по-старому, но если административно меня заставят, то что-то придется использовать;

* «осторожный сторонник», который будет что-то использовать; в целом ему подход нравится, он соглашается с перспективой внедрения, но бежать в этом направлении он не будет;

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

10.3 Обучение управлению проектами

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

1.Обязательная предварительная активная диагностика.

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

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

3.Применение единого сквозного учебного или рабочего проекта.

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

4.Использование комбинации активных приемов при обучении.

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

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

5. Четкая проработка условий проведения.

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

Особое внимание необходимо уделить формату проведения программы. На практике оказались интересными следующие форматы:

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

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

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

6.Продуманный и подготовленный раздаточный материал.

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

7.Обязательное тестирование и обратная связь после проведения программы.

Программа заканчивается, и обязательным условием ее завершения является краткий обзор всего представленного материала (эффективно это проходит в виде специального теста по инструментам управления проектами). Это своего рода «полировка и систематизация» полученных знаний и умений. Это можно провести и в более жесткой форме, например в виде имитации сдачи экзамена на РМР (Project Management Professional), только с необходимой адаптацией, меньшим количеством вопросов и в более мягких временных условиях. Иногда используется и завершающая фокус-группа с обсуждением, что получили слушатели, как изменились их представления, оправдались ли их ожидания.

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

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

10.4 Сертификация

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

Институт проектного управления (PMI) сертифицирует по одинаковым для всех стран требованиям. Существует два уровня: Certified Associate in Project Management (САРМ) - дипломированный помощник по управлению проектами и Project Management Professional (PMP) - профессионал управления проектами. Основным источником информации для сертификации является «РМ Body of Knowledge» (РМВоК, издания 2004 г.). PMI требует от кандидата предоставить описание его опыта управления проектами за последние шесть лет, которое должно показать не менее 4500 часов практического опыта с перечислением конкретных управленческих процедур, которые выполнял кандидат в качестве участника проектов, структурированных в рамках пяти основных процессов (инициация, планирование, исполнение, контроль, завершение). Кроме того, кандидат должен пройти обучение на специализированных и аттестованных PMI программах по управлению проектами и получить 35 баллов (PDU - Project Development Unit) для уровня PMP и 23 балла для уровня САРМ.

Экзамен PMI напоминает сдачу онлайнового экзамена по английскому языку. Экзамен базируется на одинаковых вопросах, случайным образом отбираемых из общей базы вопросов. Отвечая на вопросы, кандидат должен выбрать правильный ответ из четырех предложенных вариантов. Для прохождения сертификации нужно ответить правильно не менее чем на 75% из 200 вопросов на РМР и из 150 вопросов на САРМ. На каждый вопрос у кандидата есть примерно 1 мин, всего выделяется 4 ч (РМР) и 2 ч (САРМ). Кандидат может выбрать язык вопросов самостоятельно. Большинство вопросов предполагает детальное знание РМВоК. Однако есть вопросы, предполагающие наличие у кандидата практического опыта и знание межкультурных различий в менеджменте.

Международная ассоциация управления проектами (IPMA) проводит сертификацию по нескольким уровням (А, В, С, D). Чем выше уровень сертификата, тем большие требования предъявляются к знаниям и опыту кандидата. Самым высшим является уровень А. Данный уровень предполагает опыт управления проектно-ориентированной организацией. Уровни В и С предполагают наличие опыта управления отдельными проектами (различаются требованиями к сложности и масштабам проектов). Уровень D - специалист, имеющий квалификацию для выполнения отдельных функций управления проектом, способный работать в команде управления проектом. IPMA формулирует общие условия сертификации, на базе которых разрабатываются требования к компетентности специалистов с учетом национальной специфики. В нашей стране сертификация проводится на основе «Российских национальных требований к компетентности специалистов». Кандидат должен пройти предварительную квалификацию, подтвердив свой опыт в области управления проектами, а затем сдать квалификационный экзамен. По стандартам IPMA кандидат должен предоставить список проектов, в которых он принимал участие, и более подробно (до 20 страниц) описать проект, в котором он выполнял функции руководителя. Данное задание не составит сложности, если у вас под рукой есть рабочая документация (календарные планы, концепция, технические задания и т. п.) одного из завершенных проектов. Однако чисто технической редакцией здесь не обойдешься - требования к данному отчету предполагают осознанное переосмысление менеджером практики управления данным проектом и полученного опыта.