Документирование проекта во время исполнения

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

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

Подписывайтесь на группу PMDoc в Facebook, и обсуждайте с коллегами вопросы документирования проектов

Тут стоит, наверное, отметить, что львиную долю документов во время исполнения команда должна составлять для продукта проекта. На то оно и “исполнение”. Именно на этом этапе появляется результат работы команды. Но я не знаю, какой у тебя проект, и, следовательно, даже предположить не могу, как документировать продукт который ты создаёшь с своём проекте. Поэтому просто прошу отнестись к документированию продукта, также ответственно, как мы в этом цикле статей относимся к документированию проекта, поскольку документы проекта позволят тебе развивать систему управления проектами, а документы продукта – грамотно и всесторонне использовать продукт проекта.

Итак, документирование исполнения… Всё раскладывается на “кто выполняет проект” и “что выполняется в проекте”. При этом “кто” раскладывается на “своих” и “привлечённых”.

Сколоти команду “своих”

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

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

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

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

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

  1. Сведения о члене команды (ФИО, дату рождения, образование, стаж).
  2. Детально заполненную матрицу оценки.
  3. Суммарную оценку по направлениям: результативность, профессионализм, творчество, коммуникативные и управленческие навыки.
  4. Общую суммарную оценку.
  5. Комментарии и замечания руководителя проекта к оценке.
  6. Рекомендации по профессиональному росту и развитию.

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

Шаблоны документов для оценок команды во время исполнения проекта:

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

Дополни команду “привлечёнными”

У нас на данный момент уже есть понимание, что и у кого собираемся покупать. Более того оно задокументировано в виде Списка продавцов и Плана поставок. Основываясь на этой информации, организовываем и проводим тендер по выбору подрядчиков и поставщиков. А документирование этого процесса раскладывается на две папки документов:

  1. Наши запросы
  2. Их предложения

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

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

  1. Запрос первоначального ответа продавца (чтоб познакомиться и понять, что “на другом конце провода” есть ещё кто-то живой; как правило, это просто электронное письмо свободной формы).
  2. Запрос информации (это уже может быть документ, в котором команда просит потенциального подрядчика предоставить ей ту или иную информацию о продукте, услуге или возможностях подрядчика).
  3. Запрос предложения (документ, с помощью которого команда официально запрашивает предложения продуктов или услуг у предполагаемого участника тендера).
  4. Запрос расценок (документ, с помощью которого команда официально запрашивает у предполагаемых продавцов цены на стандартные продукты и услуги).
  5. Объявление тендера (официальное объявление тендера).
  6. Приглашение к переговорам (документ или электронное письмо, с помощью которого команда приглашает потенциальных продавцов и поставщиков к переговорам).

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

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

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

  1. Предмет контракта
  2. Реквизиты и подписи сторон
  3. Стандартные условия и общие положения
  4. Определения и интерпретация
  5. Ответственность Исполнителя
  6. Ответственность Заказчика
  7. Соглашения по рискам
  8. Период действия, изменение и прекращение контракта
  9. Цена контракта, порядок оплаты и возмещение расходов
  10. Конфиденциальность
  11. Урегулирование споров
  12. Содержание работ проекта и объём услуг
  13. Иерархическая структура работ
  14. Отчетность Исполнителя
  15. Гарантийные обязательства и техническая поддержка
  16. График исполнения работ проекта
  17. Персонал, оборудование, вспомогательные средства и услуги третьих сторон, предоставляемые Заказчиком
  18. Шаблон Запроса на изменения
  19. Шаблоны Еженедельного и Ежемесячного отчётов
Шаблоны документов для проведения тендеров и выбора подрядчиков во время исполнения проекта:

Есть с кем выполнять проект? Выполняй!

Выполняй проект

Самое главное в документировании непосредственного исполнения проекта – это сбор факта и оперативная фиксация проблем.

Сбор факта – это «сырые» отчётности по проекту. Про саму отчётность я расскажу в следующей статье про документирование проекта на этапе контроля. А во время исполнения проекта нужно просто фиксировать факт.

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

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

Всё это в полном объёме или по отдельности фиксируется каждым исполнителем в документе, который так и называется “Данные о ходе выполнения”. Документ простой и может быть оформлен в виде электронного письма. Хотя в идеале эти данные лучше вносить сразу в график проекта в системе управления проектами, типа MS Project Server.

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

Состав его следующий:
issue_log

  • Срочность – определяет, на сколько срочно решение проблемы.
  • Влияние – указывает потенциальное воздействие проблемы на сроки, стоимость и другие цели проекта.
  • Мероприятие – что нужно сделать для решения проблемы.
  • Дата – определенный срок, в течение которого проблема должна быть решена.
  • Владелец – Ф.И.О. и контакты лица, ответственного за решение проблемы.
  • Состояние – текущий статус решения проблемы (ожидаемая, произошедшая, в процессе решения, закрытая).

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

Решение этих проблем устраняет препятствия, мешающие достижению поставленных целей. Но есть ещё и психологический аспект “фиксации проблем”. Когда исполнители носятся со своими проблемами, а никто их не слышит, то им кажется, что с проектом всё совсем плохо. Если же ты организовал сбор проблем у исполнителей, то людям становится легче – их проблема услышана, зафиксирована и за её решение назначен ответственный.

Шаблоны документов для исполнения проекта:

Итого

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

  1. Эффективность команды и Оценки команды, которые дают нам оперативную информацию о производительности всей команды проекта и каждого участника в отдельности, а каждому участнику предоставляют обратную связь по его работе.
  2. Запросы, Предложения продавцов и Контракты, которые формализуют отношения команды проекта с подрядчиками и поставщиками.
  3. Данные о ходе выполнения и Журнал проблем, которые фиксируют данные о фактическом исполнении проекта, а также фиксируют проблемы и отслеживают их решение.

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

3 ответы

Оставить ответ

Хотите присоединиться к дискуссии?
Не стесняйтесь вносить свой вклад!

Добавить комментарий