ОПЕРАТИВНЫЙ КОНТРОЛЬ ИСПОЛНЕНИЯ ПРОЕКТОВ

Гайлунь Вячеслав Владимирович
ООО “АББ”
Автор является руководителем подразделения ИТ инфраструктуры компании, которое предоставляет информационные сервисы и осуществляет внедрение проектов в области информационных технологий.

Аннотация
Статья посвящена практическим аспектам оперативного управления проектами в операционной среде.

Ключевые слова: внутренняя отчетность, контроль, операционная деятельность, планирование, управление проектами


OPERATIVE CONTROL OF PROJECTS EXECUTION

Gaylun Vyatcheslav Vladimirovich
"ABB Ltd."
The author is Head of IS infrastructure department of ABB Russia. The department is covering both the set of operational activities and IT infrastructure project management.

Abstract
The article is about practical aspects of the Project management into operational environment.

Keywords: personnel management


Библиографическая ссылка на статью:
Гайлунь В.В. Оперативный контроль исполнения проектов // Экономика и менеджмент инновационных технологий. 2013. № 8 [Электронный ресурс]. URL: https://ekonomika.snauka.ru/2013/08/2912 (дата обращения: 11.03.2024).

Введение

В предыдущей статье (“Управление проектами в операционной среде”) был рассмотрен концептуальный подход к разделению проектных и операционных видов деятельности в подразделении, которое занимается как повседневным предоставлением ИТ сервисов так и управлением и внедрением проектов в области информационных технологий.

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

Общие положения

Деятельность департамента информационных технологий делится на операционную и проектную.

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

Проектная деятельность не имеет строго цикличной последовательности планирования.

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

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

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

Контрольный лист проекта представляет собой последовательный список контрольных точек проекта, выполненный в формате электронной таблицы.

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

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

Контрольный лист проекта неоконченного в текущем году копируется в электронную книгу следующего года с соответствующими пометками о переносе.

Контрольный лист проекта выполняет следующие функции:

  1. Оперативный мониторинг выполнения проекта, ответственность за который возлагается исключительно на руководителя проекта.
  2. Своевременное выявление отклонений в сроках выполнения проекта, формирование предложений управляющему комитету для принятия обоснованных решений о проведении изменений в рамках проекта. Руководитель проекта не вправе самостоятельно изменять сроки этапов проекта, содержание контрольных точек проекта или вносить дополнительные точки без утвержденного решения управляющего комитета.
  3. Накопление информации обо всех изменениях в сроках исполнения проекта. Руководитель проекта не вправе вносить изменения в прошедшие контрольные точки. Таблица должны быть точным слепком качества исполнения проекта на всем его протяжении с точки зрения соблюдения утвержденных временных нормативов и интервалов.
  4. Формирование проактивного подхода к управлению проектом. Руководитель проекта имеет право и обязан представлять управляющему комитету свои заблаговременные предложения по успешному выполнению проекта в случае появления предупреждений о возможном возникновении проблем, могущих повлиять на сроки и качество проекта.
  5. Централизованное хранилище контрольных точек проекта, доступное всем заинтересованным лицам.
  6. База сведений необходимая для формирования отчета по извлеченным урокам проекта.

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

Ведение контрольного листа проекта

  1. Контрольные точки проекта перечисляются в таблице последовательно в соответствии с ИСР проекта. Произвольное заполнение таблицы по времени недопустимо.
  2. Все контрольные точки, перечисленные в таблице проекта, обозначаются тремя цветами:
    1. Контрольная точка, дата выполнения которой еще не наступила, цветом не выделяется. Соответствующая ей строка имеет белый цвет.
    2. Контрольная точка, не имеющая отклонений от базового плана, выделяется зеленым цветом.
    3. Контрольная точка, имеющая отклонения от базового плана выделяется красным цветом.
  3. В каждой контрольной точке с наступлением даты её выполнения производится оценка соответствия базовому плану проекта.
  4. Градация отклонений от базового плана проекта имеет два уровня – «нулевой» / «ненулевой». Промежуточных оценок не предусмотрено.
  5. В случае отсутствия нарушений сроков в выполнении базового плана проекта уровень отклонений считается «нулевым». Строка отчета с контрольной точкой, которая имеет «нулевой» уровень отклонения, подсвечивается зеленым цветом. Дополнительных действий не предпринимается.
  6. «Ненулевым» считается отставание сроков выполнения контрольной точки на 1 день и более. В этом случае строка отчета подсвечивается красным цветом.
  7. При «ненулевом» отклонении руководитель проекта обязан заполнить дополнительные поля отчета – «Отклонение от базового плана», «Причины отклонения», «Корректирующие действия», а также инициирует встречу Управляющего комитета проекта для обсуждения ситуации и принятия решения. Заполнение перечисленных полей и инициация созыва управляющего комитета должны происходить не позднее одного рабочего дня после наступления даты прохождения контрольной точки.
  8. Руководитель проекта обязан активно инициировать собрание управляющего комитета для недопущения нарастания временных потерь в проекте. В случае наличия проблем со сбором управляющего комитета руководитель проекта обязан обратиться к вышестоящему руководству вплоть до ИТ директора с целью разрешения этого вопроса в кратчайшие сроки.
  9. Возвращение к базовому плану проекта может осуществляться двумя способами:
    1. Возврат к первоначальному плану путем активизации текущих работ, и перераспределением усилий по просроченным задачам. Применение изменений к проекту в этом случае не производится, но контрольная точка остается отмеченной красным цветом для сохранения истории о том, что в этом месте проекта возникли проблемы с его выполнением. Помимо этого контрольная точка снабжается комментариями о решении принятом управляющим комитетом.
    2. Пересмотр базового плана проекта – изменение первоначального плана проекта. Решение об изменениях в проекте может быть принято исключительно управляющим комитетом. При принятии решения управляющий комитет принимает во внимание мнение и оценки руководителя проекта, но не делегирует ему право на принятие решении о проведении изменений. После принятия решения о внесении изменений в проект, реконфигурация базового плана проекта осуществляются в соответствии с действующей проектной методологией, с соблюдением всех формальностей и заполнением необходимых документов. Информация о выбранных мероприятиях, дате принятия решения, документах, закрепляющих решение, заносится в поле – «Реализованные действия».
  10. Изменение базового плана проекта подразумевает пересмотр ИСР, других связанных с ним документов, а также пересмотр контрольных точек оперативного контроля. После согласования и утверждения новые контрольные точки и даты должны быть внесены в отчет. Контрольная точка, повлёкшая за собой утвержденные изменения, остается отмеченной красным цветом для сохранения истории о том, что в этом месте проекта возникли проблемы с его выполнением.
  11. Дальнейший оперативный контроль выполняется по утвержденным контрольным точкам нового базового плана проекта.
  12. Статус контрольной точки в отчете устанавливается единожды и не пересматривается при возвращении/переходу к новому базовому плану.
  13. В случае опережения графика выполнения проекта и достижения результата контрольной точки раньше плановой даты отклонение считается «нулевым», но в поле «Отклонение от baseline» указывается количество целых дней со знаком «-» – строка отмечается зеленым цветом.

Описание контрольного листа проекта.

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

  1. Название проекта
  2. Плановая дата открытия
  3. Плановая дата закрытия
  4. Руководитель проекта
  5. Код проекта
  6. Фактическая дата открытия
  7. Статус проекта
  8. Фактическая дата закрытия

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

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

Контрольный лист проекта включает в себя 8 полей:

  1. – порядковый номер строки (контрольной точки проекта)
  2. Контрольная точка - задача нулевой длительности. Используется для контроля состояния проекта в указанный момент времени.
  3. Дата выполнения по плану проекта – плановая дата достижения уровня готовности, указанного в контрольной точке.
  4. Отклонение от базового плана – действительное отклонение от базового плана проекта на запланированную дату контроля. Указывается в днях.
  5. Причины возникших отклонений – описание причин, приведших к отклонению от базового плана. Описывается в текстовом виде.
  6. Корректирующие действия – предлагаемые варианты шагов и мер, направленных на приведение проекта в базовый план. Описывается в текстовом виде. При заполнении рекомендуется использовать реестр рисков проекта.
  7. Реализованные действия – мероприятия, которые в конечном итоге были выполнены для успешного выполнения проекта. Описывается в текстовом виде.
  8. Прогноз отклонения от baseline – поле для описания действий по проактивному реагированию. Заполняется руководителем проекта в случае наличия предпосылок к возникновению отклонений на следующей контрольной точке, до момента ее наступления.

Описание электронной книги проектов

Электронная книга проектов состоит из контрольных листов проектов, каждый из которых должен иметь официальное наименование проекта.

Заключение

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



Все статьи автора «Гайлунь Вячеслав»


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

Связь с автором (комментарии/рецензии к статье)

Оставить комментарий

Вы должны авторизоваться, чтобы оставить комментарий.

Если Вы еще не зарегистрированы на сайте, то Вам необходимо зарегистрироваться: