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

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

Часть 2. Организация управления проектами

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

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

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

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

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

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

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

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

Кроме того, несколько изменяется понимание ключевых ролей в управлении проектом. В нашем понимании менеджер проекта — это не роль, а специальность (project ma­nager — специалист по управлению проектами). В России существует приблизительный аналог — главный инженер проектов. Гораздо шире становятся функции координатора проекта (наименование роли остается таким же): это специалист по управлению проектами. Координатор осуществляет оперативное управление ходом проекта согласно проектным документам, которые приняты управляющим советом или руководителем проекта. Функция координатора исключительно важна, но объективно конфликтна, поскольку по одну сторону от него находится высшее руководство, которое, как правило, недовольно ходом проекта, а по другую — пользователи и средний менеджмент, которых заставляют выполнять дополнительную работу (особенно на этапе опытной эксплуатации, когда необходим двойной ввод), менять привычную методологию, приемы и вообще нарушают сложившийся уклад жизни.

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

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

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

  • линейно-функциональная;
  • проектная;
  • матричная.

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

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

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

В табл. 1 приводятся принципы выбора организационных структур проекта и соответствующие примеры из об­­ласти ИТ.

Сильный и слабый руководители проекта

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

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

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

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

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

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

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

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

  • управляющий совет — по функциям заменяет комитет по управлению;
  • методический совет — заменяет комитеты по контролю за изменениями и по анализу спорных вопросов;
  • координационный комитет — это управляющий плюс методический совет.

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

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

Функции управляющего и методического советов

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

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

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

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

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

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

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

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

***

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

Алексей Головин
Заместитель исполнительного директора
по бизнес-процессам и информационным технологиям
ОАО «Калужский завод “Ремпутьмаш”»
a_golovin@inbox.ru