Портал №1 по управлению цифровыми
и информационными технологиями

Another Challenge of Egypt

В этом месяце я всё время играю в The Challenge of Egypt. В середине августа даже приехал для этого из отпуска, проделав на автомобиле путь, равный расстоянию от Москвы до Гизы, где стоят те самые пирамиды, что мы строим на каждом таком тренинге. 1 сентября мы строили их в лесу под Муромом, 4го – в московском офисе SAP Labs и в нашем классе. 

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


План – ничто, планирование – тоже. Одно из самых устойчивых проявлений, объединяющих все команды – сопротивление планам, спущенным сверху. В начале игры команды получают хорошие (лучше, чем бывает в жизни) планы работ и рекомендацию следовать им, если обстоятельства не заставят разрабатывать собственные. Казалось бы, работай в своё удовольствие. Так вот, подавляющее большинство проектных менеджеров как можно раньше уходят от предложенных планов и начинают вносить корректировки в распределение ресурсов, охват работ – практически во всё, что не контролируется сверху жёстко. И добро бы они создавали вместо планов, данных свыше, свои – так ведь нет, они просто отказываются от планов и рулят проектом вручную. В результате работа проектного офиса по отслеживанию объемных характеристик проекта в значительной степени теряет смысл. 
Во второй части игры не все планы даны заранее, часть из них разрабатывают архитекторы в составе управляющего совета проекта. Здесь такая же история: во-первых, они их крайне редко разрабатывают. Во-вторых, менеджеры проекта им почти никогда не следуют, продолжая оперативное ручное управление. 
По моим наблюдениям, так поступают почти все команды – корпоративные и смешанные, из западных и российских компаний, ИТ- и не-ИТ, более и менее зрелые. Я объясняю это недоверием к планам, в формировании которых исполнители не участвовали; желанием управлять/контролировать самостоятельно, выйдя из предложенной колеи; стремлением пилить, а не точить пилу (в части отказа от планирования/перепланирования в пользу работы ad hoc). 

Управление по исключениям – исключение. Есть в проектном менеджменте и используется в игре такая техника – управление по исключениям (management by exceptions). Она предполагает, что для каждого уровня управления (проект – стадии проекта – пакеты работ и соответственно совет проекта – менеджер проекта – менеджеры команд) определяется коридор отклонений от целевых значений по качеству, срокам, стоимости, охвату. В рамках этого коридора решения об обработке отклонений принимаются на текущем уровне управления, в случае риска или фактического выхода за границы коридора – выполняется эскалация на следующий уровень управления. Предполагается, что при таком подходе начальство не занимается микроменеджментом, но, с другой стороны, привлекается к обработке значимых отклонений, или исключений. Так вот, не привлекается. Почти никогда при обработке событий и изменений менеджеры команд и проекта не сравнивают прогнозируемые и фактические отклонения с установленными допусками и не информируют об исключениях своё начальство. Единственно когда используются допуски и сравнения – при формировании и предоставлении итоговой (по стадиям или всему проекту) отчётности. К этому времени проект мог несколько раз выйти за пределы установленного коридора и, возможно, в него вернуться – но руководство об этих отклонениях, скорее всего, не знает. 


В этой связи у меня есть два предложения:

Во-первых, у меня есть предположения о природе описанных общих тенденций в работе команд, и я готов ими поделиться, но сначала хочу попросить об этом читателей: Напишите, что вы думаете об этом? Почему мы так настойчиво отвергаем практики планирования и эскалации, почему предпочитаем управлять вручную и втихаря? (Я ни в коем случае не стремлюсь обидеть тех, кто играл или будет играть с нами в "Египет", выбранные слова – лишь способ подчеркнуть главные тенденции. Не имею в виду никого лично и в то же время имею в виду всех, кто управляет проектами – в играх и в жизни. Включая себя.)

Во-вторых, я предлагаю команде, которая  будет играть 16 сентября в рамках "дня деловых игр" конференции itSMF, попробовать переломить обе описанных тенденции. Давайте посмотрим, как пойдёт проект, если следовать планам, разрабатывать свои, следовать им, а также эскалировать решения всегда, когда положено. Давайте сделаем проект правильно и посмотрим на результаты, а? Если кто хочет принять участие в эксперименте – там ещё есть несколько местДо встречи 16 сентября!

 

«Управление проектами на основе PRINCE2»
Трёхдневный аккредитованный учебный курс

Комментариев: 2

  • Наталия

    Добрый день, Роман. На мой взгляд, немалую роль играет здесь наш «уровень развития». На должностях менеджеров проектов и руководителей у нас мало управленцев, и сути управления как такового многие просто не осознают, хотя находятся на соответствующих должностях. В результате: во-первых, процесс планирования недооценивается, выполняется некачественно, и соответственно, планы доверия не вызывают. Т.е. полноценная система планирования, иерархия планов, как правило, отсутствует. Во-вторых, менеджеры проектов, как правило, творческие люди (бывшие программисты, системные аналитики и т.д.), а не управленцы. Им просто по сути своей творческой тяжело следовать планам, тем более, если у них есть соответствующий опыт в этой области. Плюс опять же нет понимания, что это важно (и требования сверху тоже соответственно нет).

    С отклонениями примерно так же. Отклонения случаются довольно часто (при нашей организации  с позволения сказать процессов). Соответственно, и эскалация будет случаться довольно часто, что у руководителя (не управленца по сути) вызовет подозрения о профпригодности менеджера проекта. В общем, пока на соответствующих уровнях иерархии не сформируется пласт «правильных управленцев», понимающих процесс управления и его принципы, так и будет. Ведь если один управленец, а другой с ним взаимодействующий – нет, то цепочка не работает.

  • Юрий Ерин

    Интересные наблюдения. Не играл. Из своего опыта проектного менеджера могу предположить, что это может быть связано как с отсутствием конкретного человека, стоящего за всеми этими начальными планами, порогами эскалации и прочими атрибутами проектного управления, так и с отсутствием важных "привычек", которые прививаются и приобретаются на практике, и игра просто выявляет их наличие или отсутствие. 


Добавить комментарий для Юрий ЕринОтменить ответ

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM