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

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

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

Подписывайтесь на группу 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 комментария

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