Сегодня хочу рассказать об одном из самых эффективных инструментов коммуникации и одновременно интеграции и управления рисками – журнале ключевых решений или logbook’e. Не знаю, есть ли такой инструмент в классическом управлении проектами, я его придумала исключительно под свои нужны года три назад и предложила руководителю включить в нашу систему управления проектами. Поначалу мы все (да и я тоже) относились к нему скептически, но теперь пользуемся ежедневно и не представляем жизни без логбука. Итак, что за зверь?
Все началось с понимания того, что у нас есть 2 проблемы:
- На долгих проектах (например, через полтора-два года после старта) очень тяжело вспомнить какие-то ключевые решения, почему именно они были приняты и как все происходило. А иногда вспомнить очень нужно. Это как-то решалось протоколами, но протоклы не всегда уместны, а искать переписку или записи скайпа через два года в папке из 15 000 элементов – занятие очень трудозатратное и неблагодарное.
- Отсутствовал эффективный механизм уведомления заинтересованных лиц о серьезных проблемах на проекте. Конечно, мы писали письма, но их не все и не всегда читали, а сохранить письмо с решением проблемы в отдельную папку мы тем более обычно забывали или просто не доходили руки.
В 2014 году мне надоело постоянно перерывать многогигабайтные папки в поиске нужного письма, и я предложила попробовать внедрить и использовать журнал ключевых решений проекта. Было решено, что если через 2 месяца “не полетит” – то мы от этого инструмента откажемся.
В нашу систему мы добавили простой элемент – возможность прикрепить к проекту что-то типа карточки. Карточек может быть неограниченное количество, и они имеют разные виды, в том числе:
- Устав проекта подписан всеми заинтересованными лицами
- Проведена установочная встреча по проекту
- Требования подписаны Заказчиком
- BRR пройден (что такое BRR – смотрим тут).
- …. (еще ряд характерных для нашего процесса управления проектами вех)
- History
- Soft Block
- Hard Block
Соответственно, при прохождении каждой из обязательных вех проекта руководитель проекта заходит в систему, отмечает в карточке дату, прикладывает ссылку на упоминаемый документ и добавляет в поле “Комментарий” детали, которые он хотел бы сохранить “для истории” и отмечает карточку как завершенную. После сохранения карточки все заинтересованные лица автоматически получают уведомление о том, что такая-то веха пройдена (и это мотивирует человека писать только факты). В зависимости от вехи в карточках незначительно отличается состав обязательных полей.
В случае, если в ходе проекта принято какое-то важное решение, руководитель проекта может зафиксировать его в карточке с типом History. Важно то, что эту карточку может добавить любой участник проекта, в том числе – Заказчик или его представитель, и что для нее можно поменять состав получателей, в отличие от остальных. То есть через карточку History мы сохраняем важную информацию и информируем о ней только тех, кого требуется информировать.
Карточка Soft Block создается в том случае, если на каком-то направлении работ проекта есть ощутимый “затык”, то есть сроки или бюджет проекта в целом еще не страдают, но вскоре будут, если не предпринять корректирующих мер. В карточке указывается причина блока, ответственный за его разрешение и потенциальные последствия. При сохранении информация автоматом уходит всем, включая Заказчика и Спонсора. Статистически на стороне бизнеса после письма в течение 10-15 минут решается 85-90% блоков.
Самое прекрасное в этом – это то, что письма пишете не вы, а бесчувственная система. И даже не потому, что вы экономите уйму времени. Просто на ваше письмо в норме люди могут ответить что-то типа “сам дурак”, а вот на письмо-уведомление от робота – уже нет, с ним спорить и переходить на личности сложнее. А еще в отличие от ваших писем никто не воспринимает это письмо как “на меня нажаловались”, еще в начале проекта с этим функционалом всех знакомят и подчеркивают то, что своевременное ведение карточек – это рабочая обязанность РМа. А так он хороший. Психология – наше все.
Карточка Hard Block используется крайне редко, только тогда, когда есть риск полной остановки проекта или еще какой-то риск, угрожающий проекту в целом, либо когда мирные методы исчерпаны. Набор полей тот же, что и в Soft Block, письмо отправляется с высокой важностью и текстом красным шрифтом с текстом типа “Проект такой-то полностью остановлен с такого-то числа по такой-то причине, эскалирую проблему на вас и прошу помощи, сделал все что мог”. Оставшиеся 10% проблем после этого письма решаются еще за 10-15 минут либо происходит мощная встряска, которая в любом случае лучше затягивания или замалчивания проблемы.
Основные приниципы записи в логбуке: пишем только факты, нет места эмоциям.
Таким образом мы:
- Не тратим время на написание писем.
- Исключаем ситуации типа “а Василию Алибабаевичу-то сказать забыли!” или “ой, а я об этом не знал” для критически важной информации о ходе проекта.
- Сохраняем историю проекта и даем такую возможность всем заинтересованным лицам.
- Можем легко построить всевозможные графики и посмотреть накопленную статистику по разным проектам для анализа.
Красота же.
Правильно ли я понял, что :
1) в Вашей внутренней системе для управления проектами созданы шаблоны для 8 типов карточек, соответствующих типовым контрольным точкам проекта?
2) в карточках есть поле, в котором указываются участники проекта (вероятно, из справочника системы) с привязкой к электронной почте участника. После подтверждения завершения или изменения карточки рассылка уведомлений участникам происходит автоматически через почтовую систему, с которой интегрирована Ваша ИСУП?
3) заполненные карточки привязаны непосредственно к проекту, т.е. нет группировки по разделам журнала – типам контрольных точек или по иной структуре?
Как устроена внутренняя навигация в журнале? Как при этом осуществляется поиск нужных решений – в карточках типа History, которых за 2 года проекта может появиться несколько десятков? По ключевым словам или нужно открывать и смотреть сами карточки?
Какие аналитические отчеты по проекту позволяют построить карточки кроме статистических по самим карточкам? В них, если я правильно понял, в основном описания фактов и событий
Андрей, почти правильно=))
1. Типов карточек не 8, а больше (не стала все перечислять). 3 из них – это History, Soft Block и Hard Block, остальные – типовые контрольные точки (их список может меняться и пополняться с эволюцией проектного управления в компании).
2. Да, все верно. Дополнительно могут быть добавлены адреса подрядчиков вне корпоративного домена, если они есть (это отдельный справочник в КСУП).
3. Карточки привязаны к проекту, но для анализа можно открыть список карточек по всем проектам одновременно (или проектам, отобранных по какому-то признаку, например, по конкретному РМу или в рамках какого-то бюджета).
В History на данном этапе можно искать только по заголовку. Два-три десятка за двухлетний проект – это не так много, сориентироваться, имея заголовки, достаточно легко. Если хочется поиска по тексту и подробностей – есть возможность сделать выгрузку в Excel. Поиска по тэгам нет.
Из встроенных отчетов есть только срезы по срокам прохождения контрольных точек, остальной анализ делается в Excel. Основная информация для анализа идет из карточек с блоками, которые содержат ряд обязательных полей (поля меняются в зависимости от типа проблемы, выбранной в блоке). Соответственно, можно в разных вариантах посмотреть, например, взаимосвязь длительности этапов, конкретных РМов, конкретных представителей Заказчика, ситуаций, когда проблема создана Заказчиком, подрядчиком или плохим проектным управлением, срока разрешения в зависимости от типа проблемы и проч.
Нельзя сказать, что возможности для анализа фантастические, но мне, как руководителю проектного офиса, на данном этапе этого хватает.