Управление проектами.РУ

Управление проектами.РУ
Сообщество тех, кто умеет или хочет научиться
хорошо управлять проектами
26 мая 2017 Из жизни РМа
2

Журнал ключевых решений в проекте, и как он может помочь

Юлия Бажанова
Редактор проекта, РМР, ICP-PPM

Сегодня хочу рассказать об одном из самых эффективных инструментов коммуникации и одновременно интеграции и управления рисками – журнале ключевых решений или logbook’e. Не знаю, есть ли такой инструмент в классическом управлении проектами, я его придумала исключительно под свои нужны года три назад и предложила руководителю включить в нашу систему управления проектами. Поначалу мы все (да и я тоже) относились к нему скептически, но теперь пользуемся ежедневно и не представляем жизни без логбука. Итак, что за зверь?

Все началось с понимания того, что у нас есть 2 проблемы:

  1. На долгих проектах (например, через полтора-два года после старта) очень тяжело вспомнить какие-то ключевые решения, почему именно они были приняты и как все происходило. А иногда вспомнить очень нужно. Это как-то решалось протоколами, но протоклы не всегда уместны, а искать переписку или записи скайпа через два года в папке из 15 000 элементов – занятие очень трудозатратное и неблагодарное.
  2. Отсутствовал эффективный механизм уведомления заинтересованных лиц о серьезных проблемах на проекте. Конечно, мы писали письма, но их не все и не всегда читали, а сохранить письмо с решением проблемы в отдельную папку мы тем более обычно забывали или просто не доходили руки.

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

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

  1. Устав проекта подписан всеми заинтересованными лицами
  2. Проведена установочная встреча по проекту
  3. Требования подписаны Заказчиком
  4.  BRR пройден (что такое BRR – смотрим тут).
  5. …. (еще ряд характерных для нашего процесса  управления проектами вех)
  6. History
  7. Soft Block
  8. Hard Block

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

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

Карточка Soft Block создается в том случае, если на каком-то направлении работ проекта есть ощутимый “затык”, то есть сроки или бюджет проекта в целом еще не страдают, но вскоре будут, если не предпринять корректирующих мер. В карточке указывается причина блока, ответственный за его разрешение и потенциальные последствия. При сохранении информация автоматом уходит всем, включая Заказчика и Спонсора. Статистически на стороне бизнеса после письма в течение 10-15 минут решается 85-90% блоков.

Самое прекрасное в этом – это то, что письма пишете не вы, а бесчувственная система. И даже не потому, что вы экономите уйму времени.  Просто на ваше письмо в норме люди могут ответить что-то типа “сам дурак”, а вот на письмо-уведомление от робота – уже нет, с ним спорить и переходить на личности сложнее.  А еще в отличие от ваших писем никто не воспринимает это письмо как “на меня нажаловались”, еще в начале проекта с этим функционалом всех знакомят и подчеркивают то, что своевременное ведение карточек – это рабочая обязанность РМа. А так он хороший. Психология – наше все.

Карточка Hard Block используется крайне редко, только тогда, когда есть риск полной остановки проекта или еще какой-то риск, угрожающий проекту в целом, либо когда мирные методы исчерпаны. Набор полей тот же, что и в Soft Block, письмо отправляется с высокой важностью и текстом красным шрифтом с текстом типа “Проект такой-то полностью остановлен с такого-то числа по такой-то причине, эскалирую проблему на вас и прошу помощи, сделал все что мог”. Оставшиеся 10% проблем после этого письма решаются еще за 10-15 минут либо происходит мощная встряска, которая в любом случае лучше затягивания или замалчивания проблемы.

Основные приниципы записи в логбуке: пишем только факты, нет места эмоциям.

Таким образом мы:

  1. Не тратим время на написание писем.
  2. Исключаем ситуации типа “а Василию Алибабаевичу-то сказать забыли!” или “ой, а я об этом не знал” для критически важной информации о ходе проекта.
  3. Сохраняем историю проекта и даем такую возможность всем заинтересованным лицам.
  4. Можем легко построить всевозможные графики и посмотреть накопленную статистику по разным проектам для анализа.

Красота же.

 

комментарии

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

Такой e-mail уже зарегистрирован. Воспользуйтесь формой входа или введите другой.

Вы ввели некорректные логин или пароль

Sorry that something went wrong, repeat again!

2комментария

сначала новые
по рейтингу сначала новые по хронологии

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: