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

| статьи | печать

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

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

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

В многочисленных стандартах и публикациях функции администратора проекта определяются довольно широко. Среди наиболее распространенных — такие функции, как:

  • организация информационного обмена между участниками проекта;

  • организация и протоколирование совещаний;

  • ведение архива проекта;

  • выполнение отдельных поручений руководителя проекта.

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

Какими функциями наделяют администраторов проектов?

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

Стандартной ситуацией является использование АП по принципу «свободные руки» — его привлекают к подготовке презентаций, выполнению локальных неожиданно «прилетевших» задач, подготовке многочисленных огромных таблиц в Microsoft Excel, в которых одни и те же цифры структурированы по-разному, и т.д.

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

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

Иногда ситуация доходит до абсурда — руководитель проекта отправляет АП в магазин за чаем, а пока тот ходит за покупками, сам руководитель выполняет работу АП, например составляет протокол только что закончившегося совещания или обновляет Журнал контроля поручений (далее — Журнал). Такие руководители объясняют это так: «Лучше я сделаю сам, но без ошибок, и буду точно уверен в корректности, чем потом буду перепроверять за администратором».

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

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

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

Какие функции нужно делегировать администратору проекта?

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

  • формирование и обновление реестра контактов;

  • кодирование;

  • создание и ведение архива;

  • организация и протоколирование совещаний;

  • сбор и обработка табелей учета рабочего времени;

  • разработка отчетных форматов;

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

  • разработка и актуализация календарно-сетевого графика проекта (опционально).

Рассмотрим каждую из них более подробно.

Формирование и обновление реестра контактов

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

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

Кодирование

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

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

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

Создание и ведение архива

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

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

Организация и протоколирование совещаний

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

Поручения из протоколов сразу же заносятся в Журнал — один из основных инструментов управления. Его ведение можно переложить на АП. Именно его задачей является напоминание исполнителям о том, что подходит срок исполнения поручения, а также отслеживание выполнения, получение документа, подтверждающего выполнение поручения, размещение документа в архиве и внесение в Журнал ссылки на данный документ. Подключать РП имеет смысл тогда, когда поручение не выполнено или есть сомнения в качестве его выполнения.

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

Сбор и обработка табелей учета рабочего времени

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

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

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

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

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

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

  • Увеличение времени, затрачиваемого на совещания и подготовку к ним

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

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

Разработка отчетных форматов

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

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

Контроль предоставления регулярной отчетности (и отчетов по запросу) в проектную команду, интеграция отчетов

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

Разработка и актуализация календарно-сетевого графика проекта (опционально)

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

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