Разбор ситуации(кейса) 7 для ПМа. Отчет по проекту.

Продолжая разбор кейсов для ПМа. Вот ссылка на предыдущие разборы кейсов

Седьмой кейс будет про то, как писать статус отчеты по проекту в проекте на заказную разработку (на аутсорсе).

Условие кейса

Клиент просит вас, как ПМа, присылать периодический отчет по проекту. Какими бывают такие отчеты, как часто их надо слать, какую информацию вы будете включать в такой отчёт?

Решение

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

Начнем с того, что одного универсального шаблона отчета не существует. Хорошая новость в том, что в пределах определенного бизнес домена или группы клиентов вашей компании вы можете стандартизировать этот отчет и использовать шаблон для основы написания отчета для этих клиентов.Стандартизацией и разработкой такого шаблона в рамках компании занимается структура PMO (Project Management Office). С ростом уровня зрелости этой структуры в компании этот шаблон будет становится все более эффективным и по возможности заполнение некоторых его разделов удастся автоматизировать.

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

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

  1. по частоте
    а) еженедельные (weekly).
    b) 2х недельные (bi-weekly). Часто такие отчеты привязаны к окончанию Спринта разработки, при его длительности в 2 недели.с) в контрольных точках или при поставках какого то функционала клиенту
  2. по формеа) свободная форма — шаблон вашей компании или что-то, что вы обсудили с клиентом устно и скомпоновали самиb) содержание прописано в контрактеc) форма и содержание прописаны в контракте и шаблон отчета является приложением к контракту
  3. по способу доставки клиенту
    а) в теле письма email
    b) файл (docx, excel, pdf, ppt) в аттачменте к email
    c) распечатанный на а4
    d) презентация клиенту с помощью проектора лично

Содержание отчета

Какие разделы может содержать отчет:

  1. Шапка.
    Содержит название проекта/клиента, имя получателя на стороне клиента, кто составил, дата и период, который отчет покрывает. Если это отчет по спринту, то можно добавить и номер спринта
  2. Контрольные точки
    Перечисление контрольных точек проекта и статус каждой в формате “completed”, “in progress”, “risk” или с помощью иконок
  3. Общая информация о статусе важных параметров проекта:
    — Общее уже затраченное время на проекте (в часах или процентах)
    — Завершенный объем работ по отношению к запланированному (в процентах)
    — Ожидаемая/планируемая на текущий момент дата завершения проекта
    — Если на проекте используется метод расчета статуса с помощью формул освоенного объема (EVM) то здесь можно привести их, при условии что клиент понимает их значение.
    Здесь можно по необходимости сделать отдельные разделы “Бюджет” и “Сроки”.
    Пример раздела Бюджет
    — вся сумма контракта
    — потраченная/использованная сумма
    — прогноз затрат
    — отклонение от планируемой
    — причины отклонений
    Пример раздела Сроки
    — дата завершени по конракту
    — текущая планируемая дата завершения
    — отклонение
    — причина отклонений
  4. Задачи, которые были сделаны за прошедший период
  5. Задачи, которые запланированы на текущий период
  6. Риски проекта. Эту секцию можно озаглавить также как “открытые вопросы и риски” и т.д
    Не все, а только:
    — наиболее важные с точки зрения количественного и качественного анализа,
    — новые риски,
    — риски, статус которых изменился
  7. Контактная информация (опционально)
    Укажите контактную информацию людей с вашей стороны проекта (ПМа, Деливери, сейлза и т.д)

Опционально тут могут быть такие разделы как “новые задачи/изменения объема работ проекта — change requests”, «

Советы по использованию

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

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

Вот пример, картинка взята с сайта http://pm-compass.biz/

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

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

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

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

Отдельно порекомендую как можно больше автоматизировать отчет. Это можно сделать с помощью шаблонов excel, куда вы выгружаете данные из вашего таск трекера, плагин к вашему таск трекеру (например, Tempo для JIRA), макросы и т.д. Чем легче вас создавать отчет, тем больше времени вы сможете уделить продумыванию целей и назначения отчета, а не на собирания данных. 
Нет универсального отчета для всех типов контрактов, клиентов. Также вам вряд ли удастся написать идеальный отчет для нового клиента/проекта с первого раза. Собирайте обратную связь от получателей вашего отчета, следите за их реакцией и на основании этих данных итеративно улучшайте ваш отчет, чтобы он содержал минимально эффективную релевантную информацию для получателей. Это ваша задача, как ПМа.

Шаблон отчета

Дополнительное чтение по теме

  1. PMBOK® Guide – 6е издание, Глава 10 — Управление коммуникациями проекта
  2. Отчет о статусе проекта
  3. Управление проектом на одной странице