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

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

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

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

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

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

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

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

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

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

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

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. Шаблоны Еженедельного и Ежемесячного отчётов

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

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

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

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

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

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

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

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

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

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