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

Управление проектами.РУ
Сообщество тех, кто умеет или хочет научиться
хорошо управлять проектами
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комментария

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

Правильно ли я понял, что :

1) в Вашей внутренней системе для управления проектами созданы шаблоны для 8 типов карточек, соответствующих типовым контрольным точкам проекта?

2) в карточках есть поле, в котором указываются участники проекта (вероятно, из справочника системы) с привязкой к электронной почте участника. После подтверждения завершения или изменения карточки рассылка уведомлений участникам происходит автоматически через почтовую систему, с которой интегрирована Ваша ИСУП?

3) заполненные карточки привязаны непосредственно к проекту, т.е. нет группировки по разделам журнала – типам контрольных точек или по иной структуре?

Как устроена внутренняя навигация в журнале? Как при этом осуществляется поиск нужных решений – в карточках типа History, которых за 2 года проекта может появиться несколько десятков? По ключевым словам или нужно открывать и смотреть сами карточки?

Какие аналитические отчеты по проекту позволяют построить карточки кроме статистических по самим карточкам? В них, если я правильно понял, в основном описания фактов и событий

Автор2
Юлия Бажанова

Андрей, почти правильно=))

1. Типов карточек не 8, а больше (не стала все перечислять). 3 из них – это History, Soft Block и Hard Block, остальные – типовые контрольные точки (их список может меняться и пополняться с эволюцией проектного управления в компании).

2. Да, все верно. Дополнительно могут быть добавлены адреса подрядчиков вне корпоративного домена, если они есть (это отдельный справочник в КСУП).

3. Карточки привязаны к проекту, но для анализа можно открыть список карточек по всем проектам одновременно (или проектам, отобранных по какому-то признаку, например, по конкретному РМу или в рамках какого-то бюджета).

В History на данном этапе можно искать только по заголовку. Два-три десятка за двухлетний проект – это не так много, сориентироваться, имея заголовки, достаточно легко. Если хочется поиска по тексту и подробностей – есть возможность сделать выгрузку в Excel. Поиска по тэгам нет.

Из встроенных отчетов есть только срезы по срокам прохождения контрольных точек, остальной анализ делается в Excel. Основная информация для анализа идет из карточек с блоками, которые содержат ряд обязательных полей (поля меняются в зависимости от типа проблемы, выбранной в блоке). Соответственно, можно в разных вариантах посмотреть, например, взаимосвязь длительности этапов, конкретных РМов, конкретных представителей Заказчика, ситуаций, когда проблема создана Заказчиком, подрядчиком или плохим проектным управлением, срока разрешения в зависимости от типа проблемы и проч.

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

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

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