Документирование проекта во время исполнения
В прошлой статье было спланировано и задокументировано управление взаимоотношениями в проекте, а теперь давай разберёмся, как документировать проект в процессе его исполнения, т.е. как документально оформить выполнение работ по управлению самим проектом и задокументировать достигаемые результаты проекта.
Документирование исполнения в проекте – это подпроцесс управления исполнением проекта. Напомню, что общее управление проектами я стараюсь выносить за рамки этого цикла статей, и описываю только состав и правила заполнения документов для управления проектами.
Подписывайтесь на группу PMDoc в Facebook, и обсуждайте с коллегами вопросы документирования проектов |
Тут стоит, наверное, отметить, что львиную долю документов во время исполнения команда должна составлять для продукта проекта. На то оно и “исполнение”. Именно на этом этапе появляется результат работы команды. Но я не знаю, какой у тебя проект, и, следовательно, даже предположить не могу, как документировать продукт который ты создаёшь с своём проекте. Поэтому просто прошу отнестись к документированию продукта, также ответственно, как мы в этом цикле статей относимся к документированию проекта, поскольку документы проекта позволят тебе развивать систему управления проектами, а документы продукта – грамотно и всесторонне использовать продукт проекта.
Итак, документирование исполнения… Всё раскладывается на “кто выполняет проект” и “что выполняется в проекте”. При этом “кто” раскладывается на “своих” и “привлечённых”.
Сколоти команду “своих”
Команда у тебя уже есть. Костяк мы описали и собрали ещё на стадии запуска проекта, а всю команду продумали во время документирования команды. Во время исполнения проекта мы должны только замерять эффективность работы команды в целом и оценивать индивидуальный вклад каждого участника проекта.
Задокументированная эффективность команды – это результат официальной и неофициальной оценки работы команды проекта. На основании регулярных оценок эффективности могут выполняться действия по решению проблем, улучшению коммуникаций между членами команды, разрешению конфликтных ситуаций и укреплению взаимодействия среди членов команды.
Понятно, что эффективность работы команды должна измеряется в степени соответствия целям проекта. Какой именно будет единица измерения этой степени, зависит только от тебя и особенностей твоего проекта. Классическими параметрами и единицами являются “выполнение проекта вовремя” (отклонение в днях от плана) и “выполнение проекта в рамках бюджета” (отклонение от плана в деньгах). Но не всегда по этим параметрам можно правильно оценить команду. Существует множество косвенных показателей эффективности исполнения проекта. Дополнительно могут использоваться следующие показатели:
- повышение навыков, необходимых для проекта;
- улучшение командного взаимодействия;
- и обмен знаниями в команде.
Документированные индивидуальные оценки являются инструментом управления результативностью деятельности персонала проекта и определяют вклад каждого члена команды в реализацию проекта. Данный документ называется “Оценки команды” и включает в себя:
- Сведения о члене команды (ФИО, дату рождения, образование, стаж).
- Детально заполненную матрицу оценки.
- Суммарную оценку по направлениям: результативность, профессионализм, творчество, коммуникативные и управленческие навыки.
- Общую суммарную оценку.
- Комментарии и замечания руководителя проекта к оценке.
- Рекомендации по профессиональному росту и развитию.
Оба эти документа делаются не единожды. Эффективность команды может вообще стать частью регулярной отчётности по проекту. А индивидуальные оценки могут быть проведены в начале, в середине и в конце проекта. В начале, чтоб понять текущее положение. В середине, чтоб было время провести корректировки. В конце, чтоб предоставить рекомендации для дальнейшего развития человека.
Шаблоны документов для оценок команды во время исполнения проекта:
|
Но часто одной команды мало, чтоб всё выполнить в проекте. Как правило ещё нужны подрядчики и поставщики.
Дополни команду “привлечёнными”
У нас на данный момент уже есть понимание, что и у кого собираемся покупать. Более того оно задокументировано в виде Списка продавцов и Плана поставок. Основываясь на этой информации, организовываем и проводим тендер по выбору подрядчиков и поставщиков. А документирование этого процесса раскладывается на две папки документов:
- Наши запросы
- Их предложения
Как я уже сказал выше, не могу предсказать, каким именно будет твой проект. Соответственно, не могу и описать, какие потребуются запросы и предложения для твоего проекта. Поэтому я просто перечислю, какие они бывают.
Начну с запросов. Как правило, команда проекта отправляет потенциальным подрядчикам следующие типы запросов:
- Запрос первоначального ответа продавца (чтоб познакомиться и понять, что “на другом конце провода” есть ещё кто-то живой; как правило, это просто электронное письмо свободной формы).
- Запрос информации (это уже может быть документ, в котором команда просит потенциального подрядчика предоставить ей ту или иную информацию о продукте, услуге или возможностях подрядчика).
- Запрос предложения (документ, с помощью которого команда официально запрашивает предложения продуктов или услуг у предполагаемого участника тендера).
- Запрос расценок (документ, с помощью которого команда официально запрашивает у предполагаемых продавцов цены на стандартные продукты и услуги).
- Объявление тендера (официальное объявление тендера).
- Приглашение к переговорам (документ или электронное письмо, с помощью которого команда приглашает потенциальных продавцов и поставщиков к переговорам).
Разослали запросы, а теперь получаем предложения. А предложения вообще очень сильно зависят от технологии и жизненного цикла твоего проекта. Поэтому лучше всего папку с предложениями разделить по верхнему уровню WBS проекта и в неё сложить все предложения.
После оценок всех предложений (напоминаю, что само управление проектом я выношу за рамки этого цикла статей, а описываю только как документировать всё это; как проводить тендера смотри в PMBOK или ISO21500), нужно подписать контракты с выбранными подрядчиками и поставщиками, и тем самым официально включить их в состав своей команды.
По форме и содержанию контракты тоже могут быть разными. Вот пример содержания контракта на оказание услуг по управлению проектом:
- Предмет контракта
- Реквизиты и подписи сторон
- Стандартные условия и общие положения
- Определения и интерпретация
- Ответственность Исполнителя
- Ответственность Заказчика
- Соглашения по рискам
- Период действия, изменение и прекращение контракта
- Цена контракта, порядок оплаты и возмещение расходов
- Конфиденциальность
- Урегулирование споров
- Содержание работ проекта и объём услуг
- Иерархическая структура работ
- Отчетность Исполнителя
- Гарантийные обязательства и техническая поддержка
- График исполнения работ проекта
- Персонал, оборудование, вспомогательные средства и услуги третьих сторон, предоставляемые Заказчиком
- Шаблон Запроса на изменения
- Шаблоны Еженедельного и Ежемесячного отчётов
Шаблоны документов для проведения тендеров и выбора подрядчиков во время исполнения проекта:
|
Есть с кем выполнять проект? Выполняй!
Выполняй проект
Самое главное в документировании непосредственного исполнения проекта – это сбор факта и оперативная фиксация проблем.
Сбор факта – это «сырые» отчётности по проекту. Про саму отчётность я расскажу в следующей статье про документирование проекта на этапе контроля. А во время исполнения проекта нужно просто фиксировать факт.
Этим фактом являются наблюдения и измерения, выявленные в ходе выполнения работ проекта, т.е. голые, неприкрытые сводки с полей, такие как:
- процент физически завершённых работ;
- измерения технического исполнения (сколько м3 выкопано, сколько тонн доставлено, сколько строк написано, и т.д.);
- даты начала и окончания плановых операций;
- количество запросов на изменения;
- количество дефектов;
- фактические затраты;
- фактические длительности работ;
- степень достижения метрик качества;
- информация об использовании ресурсов.
Всё это в полном объёме или по отдельности фиксируется каждым исполнителем в документе, который так и называется “Данные о ходе выполнения”. Документ простой и может быть оформлен в виде электронного письма. Хотя в идеале эти данные лучше вносить сразу в график проекта в системе управления проектами, типа MS Project Server.
Это всё касалось фактически выполняемых работ, а данные о ходе проекта должны быть просто рутинной работой исполнителей и администраторов проекта. Но в проектах сплошь и рядом встречаются ситуации, когда работы останавливаются из-за чего-то и информацию об этих проблемах нужно фиксировать и оперативно передавать по инстанциям, ну и конечно отслеживать потом решение этих проблем. Для этого используется Журнал проблем.
Состав его следующий:
- Срочность – определяет, на сколько срочно решение проблемы.
- Влияние – указывает потенциальное воздействие проблемы на сроки, стоимость и другие цели проекта.
- Мероприятие – что нужно сделать для решения проблемы.
- Дата – определенный срок, в течение которого проблема должна быть решена.
- Владелец – Ф.И.О. и контакты лица, ответственного за решение проблемы.
- Состояние – текущий статус решения проблемы (ожидаемая, произошедшая, в процессе решения, закрытая).
Понятно, что это не совсем документ в классическом его понимании. Он может никогда не появиться в бумажном виде, разве что как распечатка на каком-нибудь совещании. Это постоянно изменяемая таблица, в которой, помимо самих проблем, указываются конкретные люди, в обязанности которых входит решение конкретных проблем к определенному сроку.
Решение этих проблем устраняет препятствия, мешающие достижению поставленных целей. Но есть ещё и психологический аспект “фиксации проблем”. Когда исполнители носятся со своими проблемами, а никто их не слышит, то им кажется, что с проектом всё совсем плохо. Если же ты организовал сбор проблем у исполнителей, то людям становится легче – их проблема услышана, зафиксирована и за её решение назначен ответственный.
Шаблоны документов для исполнения проекта:
|
Итого
С точки зрения документирования, итог исполнения проекта выглядит следующим образом:
- Эффективность команды и Оценки команды, которые дают нам оперативную информацию о производительности всей команды проекта и каждого участника в отдельности, а каждому участнику предоставляют обратную связь по его работе.
- Запросы, Предложения продавцов и Контракты, которые формализуют отношения команды проекта с подрядчиками и поставщиками.
- Данные о ходе выполнения и Журнал проблем, которые фиксируют данные о фактическом исполнении проекта, а также фиксируют проблемы и отслеживают их решение.
- Шаблоны всех этих и других документов по исполнению проекта можно получить/полистать здесь:
- ОСУП.Исполнение.Комплект по PMBOK (5th edition).
- ИСО21500:Исполнение по ISO 21500:2012.
- Полный пакет шаблонов, созданных на основе PMBOK (5-й редакции) можно получить здесь: ОСУП.Комплект.v5
- Полный пакет шаблонов, созданных на основе ISO 21500:2012 можно получить здесь: ИСО21500:Комплект
- Все примеры и шаблоны документов портала PMDoc, связанные с исполнением различных проектов, можно получить здесь: Исполнение проекта.
В следующей статье я расскажу, как документировать проект во время мониторинга и контроля.
не согласованное выражение – “Запрос первоначального ответ продавца”
“Приглашение к переговорам (документА или электронное письмо” – предполагалось наверное – “документ”
Andrew, спасибо. Всё исправил.