Когда происходят сбои, нет смысла винить или увольнять людей. Виновата внутренняя система. Мы должны относиться ко всем сбоям производства как к его изменениям или сигналам к развалу системы, но не как к ошибкам работников. (Э. Деминг)

Особенности управления качеством в проектно - ориентированной компании

Владислав Ильин, руководитель проектов  и Службы качества компании TopS Business Integrator .

vilyin@topsbi.ru

"Стараться больше - неэффективно. Старайтесь умнее"

Джек Траут.

Согласно опубликованному в начале мая 2005 г. исследованию, проведенному компанией Robbins-Gioia {1} , наиболее приоритетными направлениями для правительственных организаций являются предоставление услуг, а также повышение качества и эффективности. Согласование отдельных проектов со стратегическими целями также названо одной из важнейших областей. Эти данные - результат опроса 120 профессионалов, направленного на выяснение пользы от реорганизации процессов и контроля качества для организаций и правительственных агентств. Конечно, ценность собственно управления проектами уже ни у кого  не вызывает сомнений.

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

Все это и есть составляющие понятия качества реализации проекта.

Рассмотрим это понятие  в плане обеспечения качества проекта в системах менеджмента качества (СМК){2} .

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

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

Особенности Проектного  бизнеса

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

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

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

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

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

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

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

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

Табл. 1

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

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

Рис. 1.

И еще очень важная особенность проектного бизнеса.

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

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

Рассмотрим вопросы создания мотивации персонала проектной компании.

Создание мотивации проектной команды

Можно прямо сформулировать лозунг: "В проектном бизнесе персонал решает все!"

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

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

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

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

Основная идея лежит в ведении показателя  "Личный рейтинг сотрудника".

Личный Рейтинг сотрудника ( ЛРС  ) должен зависить, по крайней мере от двух основных составляющих:

• от его реальной утилизации ( например за год ) -  это уже используемый в компании показатель U,

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

Алгоритм определения ЛРС представлен на Рис. 2

Рис. 2Алгоритм ЖЦ  показателя RU

На Рис 3 показана петля качества для понятия личный рейтинг сотрудника.

Рис. 3 Петля качества для понятия личный рецйтинг сотрудника

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

RU = (Суммарная  занятость в проектах за год в ч\д) / ( Календарное рабочее время за год в ч\д)*( коэффициент личного опыта и  специализаций  сотрудника)  

Или

RU = (Тп \ Тр)*NC = U * NC ,

где: U = Тп \ Тр - утилизация сотрудника ,Тп -суммарная  занятость в проектах в ч\д , Тр- календарное рабочее время в ч\д , NC - коэффициент опыта и  специализаций, которыми владеет сотрудник.

Расчет Коэффициента NC проводится на основании данных  личной матрицы знаний и опыта сотрудника (МЗО), формат которой приведен в примерах -Табл 2

Примечание: cтатус подтверждения -это может быть, либо подпись Руководителя Департамента ( ПРД), либо наличие сертификата.

Табл 2.  ФИО  -Иванов Иван Иванович , U =60% ( за год )

№№	Область знаний	Специализация знаний	Статус подтверждения	Количество проектов , где был опыт применения
1	Управление проектами	Руководитель проекта	сертификат	2
2	Функциональность системы SAP	Модуль FI	сертификат	2
3	Функциональность системы SAP	Модуль CO	сертификат	1
4	Моделирование Бизнес-процессов	ARIS	ПРД	1
5	Моделирование Бизнес-процессов	BP Win	ПРД	0
6	Бухгалтерский учет	GAAP	сертификат	3
		ИТОГО  M= 6		ИТОГО  N =9

Где: М -это число специализаций сотрудника  , N -число проектов, где эти специализации были востребованы.

Для представленной МЗО коэффициент NC будет определятся следующим образом:

NC = ( M * N)=  6*9 = 54

Так, например, для приведеного примера в случае  И.И. Иванова (   имееет среднюю личную утилизацию за год  60%) ,   его личный рейтинг составит:

RU = 0,60 *  54 = 32,4

Безусловно, для любой проектной компании приоритетна и внутренняя ротация.

Это просто более выгодно экономически.

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

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

И , напротив, заметная текучесть кадров  может привести ее даже к катастрофе- однажды глава Microsoft  Билл Гейтс сказал, что увольнение 10% сотрудников приведет его компанию к краху, а Руководство Oracle считает необходимым  сохранять примерно 90% сотрудников подразделений разработки и техподдержки  , чтобы обеспечить непрерывность процесса совершенствования и круглосуточной поддержки своих программных продуктов!

И еще.

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

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

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

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

А теперь перейдем, собственно, к обсуждению возможных моделей СМК для

Проектного бизнеса.

Модели СМК для проектной деятельности

Когда я говорю про СМК, я имею в виду систему качества,  которая адаптирована к выполнению определенных проектов .

Она может быть очень эффективной ( высокая степень вероятности достижения всех запланированных результатов проекта )  для конкретной ИТ -компании,  но, при этом, иметь много ( и подчас существенных ) отклонений именно от модели ISO 9000

И,   например, такая СМК может вообще не иметь "Руководства по качеству" ( а это существенное отклонение!) - его с большим успехом может заменить репозитарий моделей всех БП компании- см. Рис. 4.

Рис . 4. Схема функционирования СМК при последовательном внедрении моделей ISO 9000 и CMM ( стилизация автора)

И уже давным давно  существует ПО ARIS  (Architecture of Integrated Information System),  где в электронной базе  репозитария  БП предусмотрена вся необходимая детализация и их ресурсное окружение  вплоть до уровня рабочего места {5}.

ARIS - это методология и базирующееся на ней семейство программных продуктов , разработанных для структурированного описания, анализа и последующего совершенствования БП - см Рис. 5 .

Инструментальное средство ARIS Toolset представляет процесс в виде иерархии. Перекрестные ссылки, хранящиеся в Репозитарии , обеспечивают целостность и непротиворечивость архитектуры процессов.

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

В такой СМК отпадает необходимость и в должностных инструкциях - все действия персонала "по умолчанию" уже расписаны в процедурах того же репозитария БП!

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

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

Рис. 5 Структура методологии ARIS

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

Поэтому для  проектных Компаний сертификация по ISO 9000 мера вынужденная, так как Заказчики  о других стандартах на  проекты разработки ПО и внедрения  ИС , например, SPICE (ISO/IEC TR 15504-СММ, поэтому у нас более известная под абревиатурой СММ) , Tick-IT ( само название этого стандарта Великобритании говорит о его предметной области  ) и  т.д. , просто ничего не знают и всем ИТ-Компаниям  приходиться втискиваться в "прокрустово ложе" ISO 9000.

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

Качество выполнения например для  ИТ-проектов {3, 4}  складывается из :

• определения требований  Потребителей к ИС или ПО ;

• отображения требований на функциональность ИС или ПО;

•  разработки и внедрения ИС или ПО с характеристиками, обеспечивающими соответствие установленным к ним  требований  Потребителя;

• поддержания характеристик, заложенных при разработке ИС или ПО и при их внедрении в компании Потребителя;

• технической поддержки внедренной ИС или ПО в течение их срока жизни с целью сохранения заложенных в них характеристик.

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

А именно управлению несоответствующей продукцией стандарт ISO 9000 уделяет особое внимание - он и  заточен под то, чтобы Заказчик получал продукт только установленного качества. И для заводов и фабрик это в самый раз!

Понятно,  что  для ИТ -проектов гораздо более уместно Заказчику потребовать от компании соответствие модели управления именно проектами - например, PM BoK 2000 или, более строгой, - SPICE.

PM BoK  как раз и создана для  управления отклонениями именно в процессе выполнения проекта ( а SPICE  и Tick-IT вообще заточены под ИТ-проекты) и для повышения вероятности достижения запланированных в нем

результатов .

Рассмотрим, например, необходимость должностных инструкций персонала.

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

А вот процессу постоянного обучения и повышения квалификации в ИТ -компаниях в этих обстоятельствах надо уделять гораздо больше внимания, чем это требует ISO 9000: для ИТ-услуг это просто жизненно необходимая задача - например , ИТ-системы развиваются "катастрофически" быстро!

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

Рассмотрим  совершенствование уровней качества потенциала компании (уровни КПК) -см Рис 6  .

И для того чтобы добиться этого "мирового класса"  компании необходимо разрбатывать СМК уже совсем по другой модели, :." и мы знаем эту модель" - CMM {6}- см. Рис. 6. Уровни организации КПК по  модели CMM как раз полностью соответствуют необходимым уровням КПК!

Рис. 6

Кстати, именно по этому  на Западе далеко не все ИТ-Компании сертифицированы именно по ISO 9000 (например Microsoft, кстати CMM у нее тоже нет).

Многим это и не нужно.

Для них гораздо важней вместо ISO 9000 иметь хотя бы третий или , лучше  , четвертый уровень CMM.

Рис . 7. Cхема достижения CMM Level 4 при совместном использовании модели СМК по  ISO 9000 и руководства PM BoK 2000.

А если отечественная компания, мобилизовавшись и затратив большие ресурсы, получит даже 4 уровень CMM, то на какого нашего отечественного Заказчика  это произведет хоть какое-то впечатление?

Ни на какого .

А вот ISO 9000 - :."это мы знаем":!

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

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

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

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

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

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

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

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

• интеллектуалоемкий характер предметной области большинства проектов;

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

• повышенные риски нарушения сроков и бюджета, прекращения либо приостановки проекта;

• повышенные требования к качеству, имеющие конструктивный, т. е. объективно проверяемый характер;

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

• быстрое моральное старение их результатов;

• высокая вероятность появления новых, ранее не выполнявшихся работ, для которых методология, технология и система управления создаются "на лету";

• высокие требования к квалификации менеджеров и исполнителей, их высокая стоимость;

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

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

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

Пример модели обеспечения качества проекта уже был показан  выше на Рис.1

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

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

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

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

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

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

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

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

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

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

И на первом месте в QA -плане идет, конечно, анализ рисков {3}.

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

На Рис .12 показан типовой ЖЦ проекта внедрения ИС ( например, Axapta) и соответствующие ему процессы выполнения проекта , при которых возможны "потери качества".

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

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

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

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

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

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

Роль Руководителя проекта

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

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

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

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

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

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

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

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

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

• Бизнес-проекты, ориентированные на получение максимальной прибыли (например, проект по контракту).

• Организационные (инфраструктурные) проекты, нацеленные на улучшение бизнес-процессов и реализуемые за счет внутренних ресурсов организации (сюда относятся ИТ-проекты)

• Социальные или политические проекты - они не имеют целью получение прибыли.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Организация проектного офиса

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

(Информация  по управлению проектами в рисунках  этой статьи в основном базируется на терминах стандарта  PMBOK {3})

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

Поэтому типичными подразделениями проектного офиса являются -см Рис 17:

• Аналитический отдел, в котором ведутся компьютерные модели проектов

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

• Архив, в котором ведутся архивы проектной документации;
  
  

Рис. 17 Пример Структуры  Проектного офиса  в проектной компании

На  сотрудников Проектного офиса  ляжет, например, обязанность по описанию существующих в организации практик управления проектами и сравнении их с лучшими практиками стандарта (best practices). Таким образом, существенно возрастают методические функции офиса проектов. Кроме того, появляются аналитические функции, связанные с оценкой эффективности применяемых методик и выработкой предложений по их улучшению. Расширение учетных функций происходит за счет того, что необходимо наладить сбор, накопление и обработку метрик: количественных показателей выполненных проектов, что является необходимым условием постоянного совершенствования проектного управления. Увеличивается и объем обучения: каждый РП должен хорошо понимать и уметь использовать на практике требования  разработанного стандарта.

На Рис 18 показан пример дерева функций Проектного офиса

Рис. 18 Пример дерева функций Проектного офиса

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

На  Рис. 19  показан пример распределения ответственности Ролей Проектного офиса и СМК.

Рис. 19Пример схемы ответственности ролей  Проектного офиса и СМК

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

Рис. 20 Схема взаимодействия функционалов Проектного офиса и СМК

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

Выбор Информационной системы управления проектами

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

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

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

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

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

Кроме того , как правило ( 90 %всех компаний ) , все отчетные документы ведут в Word и Excel , то есть используют MS Office.

Вот по этому пути и придется  Вам идти дальше -  поэтому для управления проектами я рекомендую пользоваться все-таки MS Project.

Просто для успешной организации Проектного офиса на основе популярного  MS Project  и необходима его интеграция с MS Share Point Team Services.  Это даст возможность легко управлять версиями документов и обеспечит необходимое управление записями по качеству.  Другой важный аспект - MS Share Point  позволяет Вам создавать "виртуальные пространства" для совместной работы.

Еще большее усиление синергетический эффекта наблюдается со средствами групповой работы ( обеспечение эффективных внутренних коммуникаций ) на базе MS Outlook и MS Exchange. -см .Рис. 17

Рассмотрим теперь, как можно реализовать требования более продвинутой для управления проектами модели обеспечения качества СММ при организации проектного офиса на примере его реализации в среде MS Project -см. Табл.3

Табл.3 Пример Матрицы реализации требований модели СММ при управлении проектами  с использованием информационной системы управления проектами (ИСУП) , построенной в среде  MS Project

Уровень модели СММ	Процессы	Комментарии
1 уровень Начальный (Initial)	Не определены	Неуправляемая разработка
2 уровень Уровень повторяемый (Repeatable)	Управление требованиями Requirements management	Требования к системе фиксируются и составляют единое целое с планом их реализации. Если требования изменяются, то изменяется план в MS Project. Требования документированы и выкладываются в проектную библиотеку MS Project.
	Планирование проектов Software project planning	Все задачи по реализации документируются в виде плана, который ведется в  MS Project Все дополнительные требования Потребителя документируются в виде запросов на изменения  ( CR ) и находятся в проектной библиотеке и отражаются в корректировках плана проекта в MS Project
	Отслеживание плана и периодический контроль Software project tracking and oversight	Документируется состояние проекта (выполнение задач) по результатам контрольных проверок. Результат проектного аудита  можно фиксировать  в MS Project в папке QA проектной библиотеки . Для  этих  целей  можно использовать Windows SharePoint Services
	Субконтрактное управление Software subcontract managment	Менеджер и исполнитель достигают договоренности о сроках (ценах) задачи. Задача может быть принята в план только при обоюдном согласии. Можно использовать Team Inbox (Team Assign) для автоматизации согласования плана в MS Project
	Контроль качества Software quality assurance	Группа контроля качества должна сравнивать результаты проекта с документированными требованиями. Результаты испытаний или тестирования сообщаются менеджеру и исполнителям. Требуется документировать ошибки в виде баг-листа и производить регрессивное тестирование. Протокол и акты выкладываются в проектную библиотеку MS Project
	Управление версиями и конфигурациями продукта Software configuration managment	Документируются изменения продукта в различных версиях. Существует описание отличий продукта от базовой версии. Во всех проектных документах ведется лист изменений  и все проектные документы находятся в проектной библиотеке MS Project Для  этих  целей  можно использовать Windows SharePoint Services
3 уровень Уровень определеный (Defined)	Настройка организационной структуры на процесс разработки Organization Process Focus	Проводится в соответствие с технологией ведения проектов организационная структура компании (создаются необходимые подразделения, перераспределяется ответственность). Ведется общий учет, как проектной информации, так и организационных мероприятий, таких как обучение, апробирование новых технологий. Производится стоимостная оценка задач, оценка новых трудоемкости процедур, сводятся результаты обучения, собираются планы всех групп. Данная информация должна быть размещена в централизованной базе данных проектного офиса, на основе данной статистики производится сравнительный анализ организации проектной деятельности. Для  этих  целей  можно использовать Windows SharePoint Services В качестве  базы совместного планирования можно использовать MS Project Central. Необходимо создать в нем межпроектный пул ресурсов.
	Описание организационного процесса разработки Organization Process Definition	Документируется стандартный процесс разработки. Документы и статистика по организации процесса собираются в едином хранилище MS Project на проектном сервере . Для  этих  целей  можно использовать Windows SharePoint Services Периодически по результатам статистических наблюдений за выполнением планов и стоимостей работ производится пересмотр элементов стандартного процесса разработки.
	Программа обучения Traning Program	Согласно потребностям проектов составляется программа обучения. Ведется учет результатов тестирований и сертификаций. Производится периодический аудит программ обучения. Если не зарезервировать время на обучение, то персонал будет самообучаться для проектных целей. Это приведет к "непонятным" потерям времени (неуправляемости проекта), низкому качеству получения знаний.Процесс обучения отражается в MS Project в виде задач.
	Интегрированное управление проектами и технологией Integrated Software Managment	При планировании проектов используется документированный стандарт процесса разработки. По документированной процедуре прилагающейся к технологии разработки используется оценка рисков, критического пути, стоимости и продолжительности работ. Разрабатываемые планы учитываются в специальной  базе данных проектного сервера. Полезна выработка шаблонных документов для ТЗ, договора  , Устава проекта и т.д. Для оценки рисков по PERT-технике и определения критического пути можно использовать MS Project.
	Технология разработки Software product engineering	Документируется технология разработки. Описанные технологические стадии используются при планировании. Технология должна описывать: аналитику (прототипирования, декомпозиция, модели, сценарные описания) хранение исходных текстов версии системы кодирование (структурирование и повторное использование) тестирование и верификация: модульное и интеграционное тестирование, системное тестирование , инспекции кода, тесты соответствия. организация документирования На базе документированной технологии строится план. Ведется учет дефектов выявляемых тестированием и результатов рецензирования проектных документов (peer reviews). В MS Project необходимо выделить отдельные технологические стадии (аналитика, проектирование и т.д.) в виде mile stone (контрольных точек).
	Межгрупповое управление Intergroup Coordination	Требования пользователя утверждаются для реализации в продукт всеми группами разработки. Руководитель проекта отлеживает выявление проблем и мониторит их статус при помощи задач подготовки статус-отчетов в MS Project.
	Периодический осмотр технологического состояния Peer reviews	Производится технологическая инспекция состояния проектов. Выявленные дефекты регистрируются. Проводится рецензирование всех  проектных документов в проектной библиотеке MS Project
4 уровень Уровень управляемый (Managed)	Метрический Процесс Управления Разработкой Quantitative Process Managment	По учетной информации обеспечиваемой Level 4 ведется всесторонняя статистика. Вычисляются эталонные статистические показатели стандартного процесса разработки или внедрения. На основе сравнения с ними ведется управление проектами. Для  этих  целей  можно использовать Windows SharePoint Services На данном этапе нужно воспользоваться накопленной статистикой ведения проектов в MS Project. Построив статистические отчеты по различным технологическим стадиям, можно получить реальные и проверенные практикой оценки трудоемкостей. Их следует использовать в качестве эталонных при последующем планировании в MS Project.
	Управление Качеством Software Quality Managment	Разрабатывается и мониторится План обеспечения качества -QA-план Ведется статистический анализ различных параметров качества процессов и внедряемой системы. Полученные данные сравниваются с эталонными показателями. На основе полученных данных вносятся коррекции в технологических процесс и методы реализации проектов. На данном этапе необходимо базу регистрации дефектов интегрировать с SQL Server и получить статистику по видам дефектов результаты бубликуются в библиотеке MS Project.
5 уровень Уровень оптимизиро ванный (Optimizing)	Предотвращение дефектов Defect Prevention	Ведется анализ и статистический учет причин возникновения проблем или дефектов. Выявленные причины  ранжируются по приоритетам и устраняются организационными мероприятиями. Результаы корректирующих действий документируются в проектной библиотеке MS Project Для  этих  целей  можно использовать Windows SharePoint Services
	Управление сменой технологий Technology Change Managment	Производится плановое апробирование новых технологий. Результаты апробирования регистрируются. Производится плановое внедрение новых технологий, которые показали высокие результаты. Для целей регистрации результатов апробирования можно использовать Windows SharePoint Services

Аудит качества проектов

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

В нашей компании функции проектного офиса выполняет  Центр управления проектами (ЦУП).

Плановое количество и сроки проектных аудитов определяются основными фазами (этапами) проекта, ключевыми событиями (milestones).

Внеплановые проектные аудиты проводятся по запросам Заказчика, руководителей департаментов и отделов.

Аудиты качества проекта проводятся на основе критериев, определяемых набором контрольных списков  (Check Lists).

Каждый критерий, как правило, является следствием требований нормативных документов системы менеджмента качества (это требования ISO 9000 ) и системы управления проектами Компании (это требования PM BoK 2000 ) - см.Табл. 4

Табл. 4 Пример проверочного листа (Check Lists)  по теме: управление проектом и отчетность

Этап / Направление	Ожидаемый результат	Тип	Да	Нет
Сроки выполнения	Соблюдаются сроки создания всех  Продуктов (Deliverables) проекта.	Критическое
Сроки выполнения	Соблюдаются сроки создания всех рабочих продуктов проекта, не являющихся Deliverables.	Серьезное
План-график проекта	Находится в актуальном состоянии и содержит отметки о выполнении	Серьезное
Отчеты о состоянии проекта (Status Reports)	Готовятся в соответствии с процедурой, определенной в Уставе проекта по установленному шаблону.	Серьезное
Регистрация проблем (Problem Tracking)	Ведется в проекте (допустимо отсутствие, если проблем нет и нет упоминания о них в  Status Reports)	Серьезное
Протоколы рабочих совещаний по проекту	Ведутся и хранятся в соответствующей папке проекта	Серьезное
Анализ проекта	Присутствуют протоколы Управляющего  Комитета проекта  по анализу результатов каждой фазы проекта (кроме Инициализации проекта)	Критическое
Управление проектом	В проекте принимаются корректирующие действия по уменьшению или ликвидации нежелательных последствий отклонений от сроков (документирование)	Серьезное
Управление проектом	Управление изменениями происходит в соответствии с процедурой, изложенной в Уставе проекта	Серьезное
Управление изменениями	Все  Запросы на изменения  (CR) оформлены и хранятся в в соответствующей папке проекта	Критическое
Управление изменениями	Отработка каждого CR находит отражение в соответствующих проектных документах	Серьезное
Бумажный архив	Содержит все утвержденные версии проектных документов (все рабочие версии - в электронном виде)	Незначительное
Бумажный архив	Содержит текущую переписку с Заказчиком	Незначительное

Результаты аудита оформляются в документе  "Протокол-Отчет внутренней проверки проекта"  и располагаются в определенной для этого конфигурацией проектных документов проектной папке  и в копии в СК.

Контрольные списки доступны всем РП, находятся у нас на проектном сервере компании и на Интранет-сайте в разделе: Управление качеством\ Документация СМК\ Внутренние проверки -см. Рис. 21 и могут быть использованы для самостоятельной проверки соответствия проекта требованиям Компании.

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

ЦУП планирует три типа возможных проверок качества выполнения проекта:

• Проверка инициализации и планирования проекта;

• Проверка хода проекта и проектных документов;

• Проверка завершения проекта.

Для каждого типа существуют свои наборы Check List'ов.

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

В процессе проведения проектного аудита внутренний аудитор (ВА) руководствуется действующими контрольными списками в соответствии с задачами и направленностью аудита -см. Рис. 22.

Схема проведения проектного аудита:

• Анализ исправления замечаний предыдущего аудита:

• Аудит проекта в соответствии с контрольными списками и оформление Протокола-Отчета.

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

• Информирование РП о появлении очередных отчетных документов по аудиту проекта.

ВА проверяет также устранение отмеченных ранее несоответствий и регистрирует результаты в предыдущем Протоколе-Отчете (существует столбец "Из них исправлено").

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

Рис. 22 Пример сценария Бизнес процесса проведения проектного аудита

В место заключения

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

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

В таких случаях, конечно, никакой QA -план делу уже не поможет .

Использованная литература

1.  https://www.cnews.ru/newsline/index.shtml?2005/06/01/178760

2.  ISO 9000:2000 .Система Менеджмента Качества . Требования.

3.  Guide to the Project Management Body of Knowledge, 2000 Edition, Project Management Institute.

4. Либерзон В. И. Основы управления проектами. М., 1997

5. "Инструментарий ARIS. Методы". Файл pdf. Поставляется вместе с демо-    версией системы ARIS Toolset.

6.  Paulk M.C., Curtis B., Chrissis M.B., Weber C.V. Capability Maturity Model  for Software ( SW-CMM), version 1.1. // CMU/SEI-93-TR-024, - Februaru, 1993.

Также на сайте:
Закон 20/80, или правило Парето, на российском рынке
Четыре фазы внедрения стратегического планирования в контексте поведения организации

Новое на форуме

Наши рассылки

на Subscribe.Ru (описание):

на Mail.ru(описание):

О проекте

quality.eup.ru - один из самых старых в рунете ресурсов, посвященных менеджменту качества во всем его разнообразии.

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

Кроме отличной и действительно большой подборки статей, действует живой форум по менеджменту качества.

Реклама на сайте