С помощью наглядной схемы мы обсудили методологию расстановки промежуточных контрольных точек (рис. 6).
Рис. 6. Расстановка контрольных точек
Мы определили, что в ходе каждого проекта существует некий временной или событийный период, после которого уже ничего не возможно изменить. Это точка невозврата, или «все пропало», «опять не успели», «ой, что сказать клиенту» и т. д. При планировании проекта подобные «критические» периоды необходимо предупреждать. Для того чтобы не попасть в точку невозврата, следует осуществить контрольную процедуру (промежуточный контроль) заблаговременно. Время от промежуточной контрольной точки до точки невозврата должно быть достаточным для того, чтобы откорректировать действия и предпринять все необходимые для устранения неблагоприятного события мероприятия.
Количество контрольных точек для промежуточного контроля руководитель отдела определяет самостоятельно. В качестве общих практических рекомендаций мы решили использовать следующие.
• Чем ниже квалификация членов проектной команды и/или опыт управления проектами у менеджера проекта, тем больше контрольных точек.
• Чем значительнее последствия рисков, тем больше контрольных точек.
• Если работу выполняют новые внешние подрядчики – промежуточный контроль должен быть более тщательным.
• Чем масштабнее проект (большая зависимость между вехами проекта, этапы проекта невозможно реализовать параллельно, только последовательно, большие финансовые потери в случае невыполнения запланированных показателей и т. д.), тем больше контрольных точек.
Руководитель-стажер расставляет контрольные точки, чтобы проверять основные показатели по всем проектам отдела. Каждый менеджер проекта расставляет собственные «маяки» в рамках своего проекта.
В случае возникновения отклонения менеджер проекта проводит анализ причин неблагоприятного события и принимает решение (если у него имеются соответствующие полномочия) либо инициирует принятие решения, обратившись к руководителю отдела.
Общее правило реагирования на сбои такое: сначала необходимо определить, была ли случайной данная проблема, выявить корневую причину, а затем разработать план мероприятий по устранению (обучить, изменить технологию и т. д.). Для того чтобы не держать в голове информацию по сбоям, мы решили фиксировать специальным образом все инциденты, назначать ответственных за их устранение лиц, определять срок и необходимые ресурсы для ликвидации помех. Наглядно это изображено в Таблице 11.
Мы установили еще одно важное правило, которое позволило не «наступать на одни и те же грабли» и не заниматься исправлением повторяющихся однотипных ситуаций. Способ простой, но эффективный: проводить регулярную работу над ошибками путем анализа удачных и провальных практик. Собранная таким образом информация по сбоям и отклонениям формирует базу знаний – основу для обучения сотрудников. Управленческая выгода заключается в том, что сотрудники учатся на чужих недоработках, внедряя лучшие практики и избегая повторения чужих промашек.
Вот как выглядит подобная база знаний (Таблица 11).
Таблица 11. База знаний по устранению сбоев
Для облегчения процесса планирования и контроля мы использовали специальный программный продукт по управлению проектами. Сегодня существует огромное количество автоматизированных систем, упрощающих проектный менеджмент. Однако не стоит забывать, что любое программное обеспечение – это инструмент, позволяющий автоматизировать правильно смоделированный бизнес-процесс. При отсутствии управленческой логики автоматизация бессильна.
В моей практике были случаи успешного управления проектами без применения программного обеспечения (с использованием начерченного на флип-чарте плана-графика и самоклеящихся стикеров), а также с применением различных программных продуктов. Результат проектов, позволю себе это отметить, зависел скорее не от наличия программы-планировщика, а от реализации системных принципов управления (планирование – организация – мотивация – координация – контроль). Хотя, безусловно, хороший и простой программный продукт очень облегчает регулярный менеджмент.