Опыт постановки проектного управления

 В общем случае, проект постановки проектного управления  можно разбить на пять этапов (рис. 1.):

• зарождение идеи: зачем нам проектное управление?
• обсуждение идеи: что же конкретно мы хотим получить?
• детализация задачи: как хотим построить проектное управление?
• исследование поля сил: кто наши сторонники и противники?
• запуск пилотного проекта: начало активных действий.

Ниже мы обсудим их последовательно.

Рис. 1. Этапы проекта по постановке проектного управления.

Этап 1. Зарождение идеи: зачем нам проектное управление?

Для ясности дальнейшего текста введем два определения:

Внедренец — тот, кто должен поставить проектное управление (независимо от того, сотрудник ли это самой компании или внешний консультант).

Инициатор — топ-менеджер или владелец компании, которая хочет поставить это самое проектное управление.

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

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

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

1. Дань моде, или «Все побежали, и я побежал». Ответ звучит как: «Все компании нашей отрасли уже внедряют проектное управление. Мы бенчмаркинг делали, знаем. Наверное, и нам надо. Что мы, отсталые?».
2. Следование совету, или «Доктор сказал «в морг!», значит, в морг!». Здесь руководитель ссылается на консультантов или аудиторов, которые дали рекомендацию внедрить проектное управление, забыв удостовериться, что бедная компания действительно осознала, зачем ей это «счастье». Безусловно, проектное управление относится к хорошим практикам, но это отнюдь не означает, что оно «показано» всем компаниям.
3. «Я хорошо знаю и люблю проектное управление, оно помогает решить многие проблемы». Это из серии поиска ключей под фонарем, потому что там светло, а не потому, что там потерял. Понятный инструмент, который применяется для решения всего, что под руку попадется. По сути, это заблуждение и неверное решение о полезности проектного управления в данной ситуации.
4. «Пинок» функциональной компании в ситуации, когда не хочется использовать процессный подход, или «Что бы такое съесть, чтобы похудеть». Весьма специфическая ситуация, когда существующий уклад почти всех устраивает (ломать то, что работает, не хочется), и поэтому постановка развитого процессного управления не рассматривается, но перемен все же хотелось бы. Как бы так «взбодрить» функциональные подразделения, чтобы они не очень расстроились от вмешательства и результат бы дали выдающийся? Задачка, однако. В поисках ее решения руководство может обратиться к проектному подходу, наивно полагая, что он не многое изменит в текущей работе подразделений.
5. Компенсация слабых функциональных руководителей за счет сильных руководителей проектов. Это как в том анекдоте про чемодан, который нести тяжело, бросить жалко, ключи потеряли и потому не заменить. К сожалению, весьма частая ситуация, когда управленческую слабость в работе с людьми компания пытается прикрыть инновационными управленческими решениями.
6. Осознанная необходимость. К сожалению, редко встречающееся продуманное и выстраданное решение.

Нередко мы имеем дело с действием одновременно нескольких предпосылок. Причем я ни разу не видела случая, когда и аудиторы посоветовали, и руководитель компании осознал необходимость постановки проектного управления, и на самом деле надо. Чаще всего встречается сочетание из двух факторов:

• консультанты посоветовали использовать проектное управление, но руководитель компании не хочет, хотя объективно надо бы;
• консультанты посоветовали («ведь все компании вашей отрасли уже внедряют») и руководитель компании хочет использовать проектное управление, но, объективно говоря, компании оно не нужно – только навредит.

Короткое резюме этапа 1: По сути, в результате этого этапа стороны должны познакомиться друг с другом, присмотреться и сделать первичное исследование сложившейся ситуации и идеи использования проектного управления. А также понять, зрелое это решение (и насколько обдуманное) или эмоциональное и стоит ли вообще дальше идти в этом направлении.

Этап 2. Обсуждение идеи: что же конкретно мы хотим получить?

Понять предпосылки и исходные мотивы руководства компании недостаточно для запуска проекта. Дальше встает вопрос о конкретных целях внедрения проектного управления. Что хотим получить в результате постановки проектного управления? Как узнаем, что мы получили именно это? И чего нельзя допустить ни в коем случае?

И тут начинается сложно формализуемый очень интересный процесс. Для внедренца главная задача на этом этапе – не просто зафиксировать декларируемые задачи, но, что гораздо важнее, понять истинные цели постановки проектного управления, определить зазор между ними, оценить их выполнимость в условиях заданных ограничений.

На этом этапе важно «разговорить» инициатора внедрения, а последнему важно как можно более честно рассказать о том, что на самом деле ему нужно и что именно он ждет от проекта. По сути эта точка – первая встреча взаимных ожиданий и готовности. И первая точка возможных взаимных нестыковок.

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

После того как цели и ожидания озвучены, задача обеих сторон – оценить готовность себя и второй стороны к реальным действиям. Здесь мне приходилось сталкиваться с заверениями:

«Мы действительно готовы к внедрению. Мы будем твердо настаивать на обязательности исполнения проектов по методологии для всех подразделений. Поддержка, полномочия – всё дадим».

На практике после первых шагов внедрения это часто выливалось в:

«Саботируют, не ведут проекты по утвержденной методологии? Нехорошо, ну поговори сама с ними еще раз».

Для успеха проекта жизненно необходимо понять реальную, а не декларируемую готовность и заинтересованность каждой из сторон. Понятно, что это непросто и инструментов для этого практически нет. Но тупиковых и не решаемых задач весьма немного. Вопрос, как правило, в цене решения. Причем для каждой из сторон.

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

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

Комментарии 0