В статье речь пойдет о практическом опыте работы одного из подразделений информационных технологий в рамках компании, бизнес которой не имеет ничего общего с ИТ. Иными словами это подразделение является департаментом, работающим в обеспечение основного бизнеса, который является главным и единственным заказчиком информационного обеспечения своей деятельности на рынке.
Услуги, предоставляемые в области информационных технологий, лежат в области операционной деятельности. Они регламентированы каталогом сервисов и исполняются на повседневной основе с заранее запланированным уровнем качества.
В тоже время постоянно возникает потребность в исполнении тех или иных проектов, результаты которых будут использованы для создания новых сервисов для бизнеса или улучшат уже существующие.
При этом не имеет принципиального значения, кто именно выступает заказчиком проектных работ, а важно сохранение имеющегося уровня уже предоставляемых сервисов при заданном качестве исполнения проектов.
Задача несколько упрощается если работа по проекту передается сторонней организации и ИТ контролирует и принимает к исполнению уже готовые сервисы. Этот случай рассматриваться не будет, поскольку его практическая ценность невелика.
Для руководителя отдела информационных технологий гораздо большее значение имеет проблема совмещения проектной и операционной деятельности, в случае если проектные работы выполняются непосредственно в подразделении пусть даже и с привлечением сторонних субподрядчиков.
Суть проблемы вкратце такова – сотрудники подразделения выполняют не только повседневные операционные задачи, связанные с удовлетворением потребностей бизнеса компании, но и вынуждены нести нагрузку и затраты для выполнения работ по инициированным проектам. И то и другое, как отмечалось ранее, должно выполняться с предсказуемым уровнем качества.
Казалось бы, выход из описанной ситуации изложен в книгах и реализуется с помощью матричной модели управления. Это верно, но основной вопрос, на который следует ответить руководителю операционного подразделения – как практически реализовать этот подход, балансируя между двумя видами деятельности.
Итак, перейдём к рассмотрению практической реализации.
Рассуждения построим на примере некого отдела информационных технологий, который состоит из нескольких функциональных групп, осуществляющих свою деятельность на определенном направлении. У каждой из групп есть непосредственный руководитель, который отвечает за конечное качество работы по предоставлению сервисов.
Следует отметить, что работа по управлению проектами строится на основе проектной методологии, которая должна быть внедрена в департаменте. Подробно на ней останавливаться не станем, но кратко упомянем, что проектная методология это свод документов, правил и процедур регламентирующий проектную деятельность в подразделении информационных технологий, утвержденный на уровне ИТ директора компании. Для дальнейшего понимания статьи установим, что проектная методология создает базовые предпосылки для успешного управления подразделения в матричном стиле и является неотъемлемой частью системы управления подразделением.
Сотрудники, которые могут быть назначены руководителями проектов, должны пройти базовое обучение основам управления проектами и полностью изучить проектную методологию.
Определим цель, которой хотим добиться, а после этого стратегию, успешное исполнение которой приведет нас к этой цели.
Цель сформулируем так – своевременное и качественное предоставление конечных информационных сервисов бизнесу при условии необходимости выполнения проектной деятельности направленной на создание новых сервисов или существенного улучшения уже существующих.
Иначе говоря, во главу угла работы операционного подразделения ставится качество работы в обеспечение повседневной деятельности бизнеса. При этом значимость успешной проектной деятельности исключительно высока, во-первых потому, что она является органичной для работы отдела, во-вторых значительно влияет на предоставление каталожных сервисов, в-третьих меняет ландшафт будущих сервисов.
Для формирования стратегии, то есть создания комплексного плана направленного на достижения заявленной цели определим критические области, формирование которых приведет к успешному управлению проектами в операционной среде.
Эти области таковы:
Рисунок 1. Критические области операционного/проектного управления.
В практической работе этих областей вполне достаточно для корректного управления деятельностью смешанного типа, то есть повседневной и проектной.
Рассмотрим указанные области подробнее.
1. Планирование деятельности подразделения
Для руководителей не является секретом то, что разумно спланированная работа является если и не однозначным ключом к успеху, то уж во всяком случае, серьезным фактором стабильности и основой для правильного распределения ресурсов.
Несмотря на относительную простоту этого подхода, многие начальники предпочитают не утруждать себя таким видом управленческой активности, теряя, таким образом, возможность правильной оценки текущего и перспективного состояния имеющихся в наличии человеческих ресурсов.
В данном случае речь идет, прежде всего, о детальном планировании именно операционной деятельности. Планирование проектов должно осуществляться в рамках проектного управления.
Очень важно не смешивать эти два вида планирования, дабы не допустить неразберихи и избежать планирования ради планирования.
Общий подход к планированию таков – необходимо рассчитывать деятельность персонала таким образом, чтобы совершенно ясно понимать какое количество времени и людских ресурсов может быть задействовано в проектах. Кроме этого планирование позволит учесть, сколько времени может быть отведено на вознаграждаемые переработки персонала, снижая риски отрицательной мотивации сотрудников.
Что касается планирования проектной деятельности, то ее предпочтительнее проводить, условно говоря, в двух плоскостях. Первая плоскость – это общее планирование пакета проектов. Горизонт планирования состоит из интервалов один год, полгода, квартал и служит некоей дорожной картой для руководителя подразделения, позволяющей произвести предварительную оценку и грубое планирование ресурсов. Вторая плоскость – это непосредственное планирование того или иного проекта в кооперативной связке с операционными планами. Ответственность за планирование самих проектов лежит непосредственно на руководителях проектов, которые действуют в соответствии с имеющейся проектной методологией и подконтрольны как непосредственным начальникам, так и руководству проектного офиса (в случае его наличия).
2. Контроль исполнения и управление изменениями
Не будет преувеличением отметить, что успех выполнения проектов неразрывно связан с непрерывным контролем их исполнения как с точки зрения качества прохождения этапов, так и с точки зрения соблюдения сроков их обработки и закрытия.
В первую очередь необходимо остановиться на персональной ответственности менеджеров проектов за промежуточные и финальные результаты их работы в рамках проектной деятельности. Казалось бы, такая ответственность является абсолютно органичной для руководителя проекта, но на практике это не всегда так.
Дело в том, что при работе в рамках смешанной среды ситуация осложняется тем, что руководитель проекта не является персоной, которая занимается исключительно проектной деятельностью и, соответственно, сосредоточена только на проекте или группе проектов.
В традиционных операционных подразделениях руководители проектов продолжают выполнять обычную повседневную работу пусть и в уменьшенном объеме. Занятость работника по двум направлениям естественным образом согласуется с руководителем линейного подразделения, что и порождает тонкую границу разделения зон ответственности между операционным руководством и управлением проектом.
Руководитель проекта продолжает оставаться в линейном подчинении своего начальника и порой склонен относить часть ответственности за качество и сроки выполнения проекта на его счет. Руководитель подразделения при этом понимает, что в конечном итоге он отвечает за все аспекты деятельности своей команды и реагирует на ошибки или нерасторопность руководителя проекта переносом части ответственности на свои плечи.
Для исключения размытия ответственности и немотивированного переноса ее частей на руководство необходимо однозначное информирование назначаемых руководителей проектов об их фактических зонах и рамках ответственности, а также о том, как это контролируется на практике.
Кратко описав концептуальный подход к ответственности руководителей проектов, перейдем к реализации контроля их деятельности.
Практика показывает, что наилучшим образом функционируют модели перекрестного контроля, то есть контроля осуществляемого как минимум с двух независимых позиций. При этом следует понимать, что уровень контроля должен быть необходимым и достаточным, но не более того. В противном случае работа руководителей конвертируется исключительно в беспрерывную реализацию контрольных функций.
Под двумя независимыми позициями подразумевается контроль менеджера проекта со стороны непосредственного руководителя, а также контроль со стороны проектного офиса. Эти два вида контроля не должны влиять друг на друга, взаимодействуя через вышестоящее руководство в лице, к примеру, ИТ директора, который выступает в роли арбитра и разрешает потенциальные или уже возникшие конфликты.
Однако ответственность и контроль это только часть подхода к успешному выполнению проектов. Одной из ключевых составляющих стадии реализации того или иного проекта являются изменения. Причины их возникновения разнообразны, однако совершенно понятно то, что правильно построенное управление проектами подразумевает корректную и своевременную обработку этих изменений вне зависимости от их масштаба. Соответственно контроль исполнения проектов подразумевает и контроль над изменениями в проекте.
В этом случае зоны ответственности тоже очевидны. Руководители проектов отвечают за своевременное информирование о предполагаемых изменениях, подготавливают предложения по реализации мер по внедрению изменений и смягчению последствий их применения, а другие управляющие инстанции (линейное руководство, проектный офис, управляющий комитет) контролирует эту часть деятельности управления проектами и утверждают или отменяют предлагаемые пакеты предложений со стороны менеджера проекта. В любом случае руководитель проекта не вправе принимать самостоятельные решения об изменениях в проекте без согласованного окончательного решения со стороны руководства, что также является частью его непосредственной ответственности.
Можно также добавить, что успешный контроль и корректное разделение зон ответственности категорически зависят от правильно выстроенной системы коммуникаций в подразделении. К такой системе можно отнести взаимодействие линейных руководителей между собой, обмен данными между руководителями и проектным офисом, коммуникации среди руководителей проекта и участниками рабочих групп.
3. Работа с персонала, включая оценку рисков
Эта область является очень чувствительной не только для проектного управления, но и для функционирования подразделения в целом. Рассмотрим некоторые аспекты работы с персоналом, включая оценку возникающих рисков.
Управление проектами является специфичным видом деятельности, регламентируемым проектной методологией, а также особенностями внутренней культуры организации. Соответственно сотрудники, которые могут быть назначены менеджерами проектов, должны хорошо знать и уметь применять положения проектной методологии, а также иметь подтвержденную сертификацию по управлению проектами. Наличие сертификата в той или иной степени подтверждает определенный уровень знаний у лиц, которым поручается ведение проектов. Безусловно, сам по себе сертификат не является абсолютным и окончательным показателем ожидаемого качества проектов, но служит неким фильтром отсекающим персонал, не имеющий правильных компетенций. Уровень сертификации, может быть как внутренним, принятым в той или иной компании, так и внешним, например PMP.
Следует особо подчеркнуть необходимость полного понимания руководителями проектов, особенностей матричной структуры управления подразделением. Имеется в виду то, что менеджеры проектов обязаны аккуратно выравнивать проектную работу с операционной деятельностью подразделения кооперативно взаимодействуя с руководителями, членами проектной группы и проектным офисом. Совершенно недопустимой является ситуация при которой руководитель проекта начинает считать себя обособленной фигурой, которая работает исключительно во исполнение проектных задач невзирая на текущие потребности подразделения в целом.
Говоря о сертификации специалистов и об овладении ими проектной методологией, принятой в организации, необходимо проведение своевременного обучения персонала в этом направлении. Планирование и осуществление обучения, а также сертификация находится в зоне ответственности и непрерывного внимания линейного руководства.
Кроме этого линейное руководство координирует и контролирует набор рабочих групп проектов. Необходимо иметь полную уверенность в том, что группы проектов состоят из сотрудников, имеющих достаточные компетенции и временные ресурсы для выполнения проектных задач.
Значимой стороной работы, как линейных руководителей, так и менеджеров проектов является систематическая и корректная оценка рисков персонала. Под рисками в данном случае подразумеваются некие особенности сотрудников, которые могут сказаться на успешном выполнении проектов. Проблема состоит в том, что в обычной операционной жизни эти риски могут не проявляться или нивелироваться деятельностью других сотрудников, в то время как на проектах они приведут к необходимости проведения незапланированных изменений, включая замену персонала и иным неприятным последствиям.
Руководители должны производить оценку рисков персонала более или менее формальным образом обязательно используя композицию из несколько различных точек зрения на деятельность того или иного сотрудника. Что касается формализации, то для оценки необходимо использовать согласованные критерии, оцениваемые по балльной шкале, скажем от одного до десяти. В качестве примера формальных критериев оценки персонала можно привести фрагмент таблицы со шкалой оценок рисков разделенных по областям.
Рисунок 2. Фрагмент оценки формализованных рисков персонала
В реальной работе количество областей оценки рисков может варьироваться в зависимости от особенностей рабочих процессов, предпочтений руководства, организационной культуры компании и иных факторов.
Важно подчеркнуть, что оценка рисков персонала должна проводиться циклически, скажем ежеквартально или на полугодовой основе. Таким образом, становятся заметны изменения в различных областях, как в лучшую, так и в худшую сторону. Более того история оценки рисков при правильном подходе позволяет выявить не только проблемы с персоналом, но и оценить качество общего руководства подразделением и организацию обучения персонала.
Подводя итоги всему вышесказанному можно сделать вывод, что для достижения заявленной цели необходимо выстроить стратегию, которая будет детализировать описанные области и явится своего рода концептуальным планом для построения корректно работающей модели матричного управления операционным подразделением, которое выполняет дополнительные задачи проектного характера.
Составление и претворение в жизнь стратегического плана лежит в области ответственности линейного руководства, которое, в конечном счёте, и отвечает за качество предоставляемых бизнесу сервисов.