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

ПАРАДИГМЫ И ПАРАДОКСЫ ПРОЕКТНОГО МЕНЕДЖМЕНТА Конспект учебного курса

Павел Шестопалов 30.12.2015 На основе материалов учебных курсов ГК «Проектная ПРАКТИКА»

Оглавление ВВЕДЕНИЕ ............................................................................................................................................... 2

МОДУЛЬ 1 Основная парадигма проектного менеджмента ............................................................. 3

МОДУЛЬ 2 Парадоксы жизненного цикла проекта ............................................................................ 7

МОДУЛЬ 3 Парадокс постановки цели проекта ................................................................................ 11

МОДУЛЬ 4 Организационно – ролевая парадигма проекта ............................................................ 16

МОДУЛЬ 5 О жизни в матрице............................................................................................................ 21

МОДУЛЬ 6 Парадоксы планирования ................................................................................................ 27

МОДУЛЬ7 О рисках и шампанском для менеджера......................................................................... 33

МОДУЛЬ 8 Парадоксы отслеживания и контроля проекта .............................................................. 38

ВВЕДЕНИЕ

Здравствуйте, друзья!

Меня зовут Павел Шестопалов. Более 10 лет я занимаюсь вопросами эффективной реализации проектов и созданием систем управления проектной деятельностью. За это время удалось познакомиться с опытом многих успешных компаний и организаций.

Именно поэтому сегодня мне хочется поговорить о дисциплине “Проектный менеджмент”. О дисциплине, которая в современном, быстро меняющемся мире, становится все более востребованной и актуальной. Не зря в атласе новых профессий, который недавно выпустило Агентство стратегических инициатив, Управление проектами является надпрофессиональным навыком, то есть навыком, который потребуется большинству специалистов будущего.

Наш курс не будет похож на классические занятия по управлению проектами. Мы не будем изучать инструменты календарно - сетевого планирования или статистические методы работы с рисками. Здесь мы постараемся взглянуть на работу руководителя проекта в несколько необычном ракурсе. Я расскажу вам, как должен мыслить эффективный менеджер, чтобы довести проект до успешного завершения.

Конечно, можно формально освоить большинство из инструментов и методов, которые описаны в международных стандартах и учебниках по проектному управлению. Но пока не поймешь почему они такие, пока не изменишь свой способ думать о проекте, сложно рассчитывать на успех.

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

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

МОДУЛЬ 1 Основная парадигма проектного менеджмента

Очень часто на курсах по управлению проектами приходится слышать такую фразу «Управление проектами – это наука здравого смысла» Действительно, управление проектами это не математика и не физика, здесь нет законов правил и теорем, которые работают всегда и везде. Но иногда опора на наш с вами здравый смысл играет с нами очень злую шутку. Потому что, как сказал Альберт Энштейн «Здравый смысл — это собрание предрассудков, приобретенных нами до восемнадцатилетнего возраста». И иногда стоит только нарушить этот здравый смысл получишь эффект, которого никто не ожидал. Правда потом этот самый нелогичный поступок тоже со временем превращается в стереотип, но такова философия. Это как в прыжках в высоту. До 1968 года прыгуны в высоту прыгали лицом к планке. Ну действительно, это казалось супер логичным. И вот в 1968 году Дик Фосбери начинает прыгать спиной вперед. Супер нелогично и контринтуитивно, но результат – Олимпийское золото! Давайте учится мыслить контринтуитивно, и самое главное, учить этому других. Я сейчас про Заказчиков, Руководителей организаций, Исполнителей, поставщиков и т.д.

Давайте в самом начале нашего курса договоримся о терминах. Есть такое правило эффективных менеджеров, а тем более менеджеров проектов, - «О терминах не спорят, о них договариваются!». Под словом «проект» в рамках нашего курса я всегда буду иметь ввиду некую ДЕЯТЕЛЬНОСТЬ, у которой в отличие от всех остальных видов деятельности, есть ряд особенностей. Именно они дают нам право называть ее проектом.

Итак, первое, проект - это всегда деятельность для кого-то и в интересах кого –то. И чаще всего, этот кто-то называется Заказчик. Поэтому, хочу дать совет начинающему руководителю проекта – не приступайте к проекту, пока лично не познакомитесь с заказчиком.

Главный вопрос, который нужно ему задать еще на первом этапе: «А зачем это нужно?». То есть необходимо попробовать вместе сформулировать цель проекта. Сформулировать как можно понятнее вам обоим и, очень желательно зафиксировать ее в специальном документе. Ведь проект - это всегда деятельность по достижению цели. И эта цель не в вашей голове, а в голове Заказчика.

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

Еще одна отличительная черта проекта в том, что скорее всего такого никто раньше не делал, или не делал в таких условиях, или не делал такими силами. Другими словами, проект - это всегда что – то новое и уникальное. Но эта новизна и уникальность становится для руководителя проекта основной проблемой, имя которой – неопределенность и риски.

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

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

Давайте вспомним их.

Если, например, я назначен новым директором конфетной фабрики, то первым делом я планирую деятельность по выпуску нового вида конфет. Дальше организую людей. Делаю необходимый запас ингредиентов, даю необходимые инструкции и выпускаю первую партию конфет. Следующий шаг – проверка. Проверка готовой продукции на соответствие требованиям, и даже если первая партия только наполовину залита шоколадом, я не переживаю, а, возвращаясь назад по конвейеру, ищу причину случившейся неудачи. Устраняю проблему в надежде, что следующая партия будет лучше. И так цикл повторяется многократно. У меня будет третья, десятая, сотая, тысячная партия и каждый раз я работаю по знаменитому управленческому циклу PDCA: Планируй, Исполняй, Контролируй, Корректируй. А каждая новая партия становится лучше, лучше и лучше, пока не достигну идеала.

А теперь вопрос, как считаете это применимо для Проекта? Скорее всего, нет. Потому что в проекте даже второго шанса чаще всего не будет! Не можем мы через неделю после начала олимпиады сказать: «Ну что-то с первого раза не получилось, вторая олимпиада точно будет лучше!» А поэтому и мыслить Руководитель проекта должен иначе.

Первая и основная парадигма проектного менеджмента вытекает именно из этой особенности проекта. Если руководитель операционного производства всегда оглядывается назад для устранения причин дефектов, то у руководителя проекта такой возможности чаще всего нет. Его взор всегда должен быть устремлен вперед.

Проект от латинского Прожектус – заброшенный вперед. Но очень часто мы пытаемся в проекте действовать как на цикличном производстве. И очень много времени тратим в ходе совещания по проблеме на выяснение вопросов, кто виноват, почему так случилось и в чем причина отставания. 90 процентов времени совещания тратится на, так называемый «разбор полетов». В этом случае, мы смотрим назад, не осознавая, что управлять прошлым в проекте уже не в наших силах, и от того, что мы найдем крайнего ситуация совсем не улучшится. Из этого вытекает главная парадигма проектного управления: “Управлять в проекте можно только тем, что осталось, то есть только его будущей частью”.

А отсюда два следствия:

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

2. Второе следствие. Основные трудозатраты и усилия менеджера и его команды по управлению должны быть сосредоточены в самом начале проекта. В отличии от операционного управляющего - его трудозатраты равномерно распределены на протяжении всего времени выпуска тех самых конфет.

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

МОДУЛЬ 2 Парадоксы жизненного цикла проекта В этом разделе мы с вами поговорим о парадоксе жизненного цикла проекта.

Итак, Жизненный цикл проекта - это ключевое понятие в дисциплине проектный

менеджмент. Оно, как ни странно, пришло к нам из уроков биологии. Но в приложении

к проекту оно приобрело ряд особенностей. Как говорит мой любимый преподаватель

по системной инженерии: «Самое важное, что мы должны запомнить про жизненный

цикл, это две вещи: первое – он не жизненный! Второе он не цикл!»

Действительно, в самом начале курса мы говорили о том, что проект - это

ограниченная временем деятельность, т.е. после часа Х проект перестает существовать.

И уж точно второго такого-же проекта не будет! Но идея разбить проект на фазы очень

полезная. Большую, недостижимую, непонятную цель проекта нужно разбить на

понятные управляемые этапы и определить порядок их прохождения. В этом и

заключается ключевой управленческий смысл жизненного цикла.

Этапов у проекта может быть разное количество. Все определяется потребностями

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

управленческий жизненный цикл из четырех этапов. Давайте рассмотрим каждый из

них.

На первом этапе - он называется концепция - Заказчик и Руководитель проекта

договариваются о целях, результатах и содержании проекта. Устанавливаются

основные ограничения. Итогом этого этапа чаще всего является формальный документ

- Устав проекта.

На следующем этапе - организации и подготовки - Руководитель проекта собирает

команду специалистов. Он организует работу по разработке необходимого количества

планов: календарный план, финансовый план или бюджет проекта, ресурсный план,

план поставок, план реагирования на риски и другие. В ходе этого этапа дается более

точная оценка сроков и затрат, что кстати, часто приводит к пересмотру устава проекта.

Для профессионального менеджера это нормальная допустимая процедура, но о ней

нужно договориться с Заказчиком еще на этапе концепции. Формально этап

организации и подготовки завершается утверждением планов проекта. Именно в этот

момент они получают статус Базовых. Американский стандарт по управлению

проектами PMBOK, например, предлагает фиксировать три базовых плана: Базовый

план по содержанию, Базовое расписание и Базовый план выполнения стоимости. То

есть по трем ключевым характеристикам проекта должно быть три согласованных

между собой плана. Каждая работа по содержанию должна иметь даты начала и

окончания в календарном плане, а также полный перечень ресурсов и затрат в плане

финансовом.

Следующий этап - реализация. Здесь выполняются все работы проекта, а полученные

результаты - промежуточные и итоговые - передаются Заказчику. И последний этап -

этап завершения. Он необходим для приемки результатов Заказчиком, подведению

итогов проекта, извлечению уроков. И чаще всего, формальным итогом проекта

является приказ о завершении. Или, что гораздо лучше, приказ – премия – банкет!

Но! Основной парадокс жизненного цикла проекта заключается в том, что в его рамках

цель Заказчика чаще всего не достигается. Чаще всего продукт проекта сам по себе

Заказчику не нужен. А нужен результат работы или эксплуатации продукта.

Например, если наш проект – это строительство конфетной фабрики, то цель Заказчика

- получить прибыль от продажи конфет, а не сама фабрика как таковая. И чаще всего,

именно в точке передачи продукта проекта, то есть передачи той самой фабрики в

эксплуатацию, происходит много неприятностей для заказчика. Поэтому Он не

рассматривает изолированно только жизненный цикл проекта. Заказчик всегда

смотрит чуть дальше и соотносит как минимум жизненный цикл проекта и жизненный

цикл продукта.

Ведь у фабрики тоже есть свой жизненный цикл. Кто – то, когда – то ее задумал. И

думал долго, а может даже нанял для этого думания целую консалтинговую компанию.

Чаще всего этот этап называют Замысел или Инвестиционный замысел. Потом фабрика

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

называют чаще всего проектирование. Дальше фабрика рождается в железе и бетоне.

Возводится здание, монтируется техника, набирается персонал. Этап Изготовление или

Реализация. Как только построили нужно предавать в эксплуатацию и выпускать

конфеты. Но и наступит в конце концов момент, когда фабрику нужно будет закрыть,

разобрать или сильно модернизировать, так что уже сложно ее будет назвать именно

той фабрикой, которую задумали в самом начале. Этот этап вывод из эксплуатации или

утилизация.

И на этом большом, чаще всего многолетнем, жизненном цикле продукта необходимо

определить место жизненного цикла проекта. Важно понять, в какой момент, в какой

точке мы проект начинаем, а в какой точке руководитель проекта будет передавать

заранее оговоренный результат. Ведь возможны варианты. Проект может начаться

только после завершения этапа замысла. А может даже только после проектирования.

То же самое можно сказать и о завершении. Все зависит от возможностей

Руководителя и договоренностей с Заказчиком. Если вспомнить нашу фабрику, то я,

например, как руководитель проекта предпочел бы начать свою работу, свой проект

перед началом проектирования, а закончить точкой передачи фабрики в эксплуатацию.

Правда, боюсь, большинство опытных Заказчиков с такими границами проекта не

согласятся! Они попробуют растянуть границы моего проекта, то есть моей

ответственности до момента, когда точно будут уверены в том, что фабрика устойчиво

работает и приносит прибыль.

Но одно неоспоримо – грамотный руководитель проекта всегда договаривается и

точно знает, где на жизненном цикле продукта начинается и где заканчивается его зона

ответственности. Т.е. определяются так называемые границы проекта, для конкретного

руководителя.

Но для Заказчика, чаще всего, с окончанием одного проекта деятельность по

достижению целей не закачивается. Для этого может потребоваться еще некоторое

время эксплуатации, а возможно и еще несколько проектов.

Особенно, это ярко видно, если рассмотреть инвестиционную деятельность, для

которой основной выгодой является получение финансового результата. Для того,

чтобы управлять всем комплексом действий по достижению этой стратегической цели

чаще всего все мероприятия объединяют в Программу проектов. А Руководитель

программы отвечает за получение итоговых выход и эффектов. Программа и Проект

очень похожи по сути. И до сих пор многие компании спорят, чем же отличается

большой проект от небольшой программы. Основное отличие в масштабах

мероприятия и в способе управления. Проект, чаще всего краткосрочное, обычно до

года, мероприятие с четко описанными целями и содержанием, а также с

установленными ограничениями по срокам и затратам. Основная задача руководителя

проекта минимизировать возможные отклонения по срокам, содержанию и затратам.

Программа - это мероприятие со стратегическим замыслом на несколько лет.

Руководитель программы не минимизирует отклонения, а наоборот, сознательно их

вносит и использует для максимизации основных выгод программы. Но для

руководителя отдельного проекта всегда важно и полезно представлять всю картину

происходящего, и самое главное знать ту большую, стратегическую цель Заказчика,

ради которой он и тратит бюджет. Даже если программа формально не определена

есть смысл поговорить с Заказчиком на тему его ключевых стратегических целей.

Давайте подведем итоги:

Начиная проект договоритесь с Заказчиком о его границах. Удобнее всего отметить эти

границы на жизненном цикле продукта. По сути, это договоренность о зоне

ответственности руководителя проекта. Именно она во многом определит его

содержание.

Второе. После определения границ, внутри проекта выделите несколько этапов. Для каждого этапа определите условия завершения и условия перехода к следующему этапу. Это сделает ваш проект более управляемым и снимет существенное количество рисков. Чаще всего достаточно будет воспользоваться стандартным набором из 4-х этапов: Концепция, Организация и подготовка, Реализация и Завершение.

МОДУЛЬ 3 Парадокс постановки цели проекта Друзья! В данном разделе мы поговорим о парадоксах постановки целей проекта. Самые крупные неудачи проектов в мире связывают с ошибками процесса целеполагания.

Давайте разбираться подробнее в том, как правильно думать, рассуждать и фиксировать цели проекта.

Конечно, первое, что приходит в голову, когда вспоминаешь о целях - это принцип SMART, предложенный Питером Друккером еще в 1954 году.

SMART – это пять букв, означающие, что хорошо сформулированная цель должна быть четкой и специфичной - это S, измеримой - это M, достижимой -это A, должна соответствовать или быть релевантна целям более высокого уровня - это R, и должна иметь временное ограничение по ее достижению - это T.

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

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

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

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

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

Для того, чтобы соблюсти все условия принципа SMART для проекта, конечно, одной формулировки цели явно недостаточно. Все выверенные предложения чаще всего вносят в документ под названием Устав проекта. Встречаются и другие названия: Паспорт проекта, Проектная декларация, Концепция проекта, Резюме проекта. Формы тоже встречаются разные. В настоящее время очень популярным стало делать Устав проекта в виде презентации. В некоторых компаниях это корпоративный стандарт.

Что обычно включает в себя Устав проекта. Ответ простой: все то, что сделает нашу цель, как минимум, соответствующей принципу SMART. Поэтому чаще всего первым в Уставе следует раздел Стратегические цели или обоснование проекта. Здесь дается описание текущей ситуации, чаще всего, в терминах бизнеса. Наиболее часто в этом разделе описывают либо существующую бизнес - проблему, которая требует решения. Либо дается описание потенциальной бизнес - возможности, которую хотим использовать. Этот раздел отвечает на вопрос «Почему или для чего мы начинаем проект?», этим самым мы снижаем риск постановки нерелевантных целей, то есть соответствующих критерию Р по Друкеру.

Дальше следует непосредственно формулировка цели, как я уже говорил, очень желательно с указанием ключевого способа ее достижения! Например, «снижение производственных потерь за счет внедрение системы менеджмента качества на основе технологий 5С» или «Обеспечение условий для территориального развития путем открытия филиальной сети». Так мы сделаем цель соответствующей букве S из SMART-принципа. Сделаем ее ясной, конкретной, специфичной. Но самое главное цель проекта должна отвечать на вопрос «Зачем?». Поэтому я очень не люблю цели начинающиеся со слов «Создание» или «Внедрение» или «Строительство»…. Если вы прочитали сформулированную цель в Уставе и вам хочется задать вопрос «А зачем?», значит, что – то не так в этой формулировке. Обязательно идите к Заказчику и уточняйте.

Например, если цель звучит как “Создать центр обслуживания абонентов для улучшения качества обслуживания клиентов сети”, то руководитель проекта посчитает

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

Правильнее было бы сформулировать эту цель так: “Повышение качества обслуживания клиентов сети за счет создания центра обслуживания абонентов” Согласитесь, совсем другая цель. И теперь Руководитель проекта будет отвечать прежде всего за то, что создаваемый им центр действительно улучшит качество обслуживания, а не просто за то, что он есть!

Основной раздел, за который бьется Руководитель проекта – критерии успеха. Это некий чек – лист показателей (как качественных, так и количественных), который всплывет на этапе завершения проекта. Формально, именно он станет основным при определении успешности проекта. Поэтому руководитель проекта особенно тщательно должен подойти к согласованию данного раздела. По Друкеру это буква M, которая обозначает возможность измерения. В примере с созданием центра обслуживания абонентов такими критериями достижения цели могут, например, максимальное время ожидания ответа оператора, количество жалоб на некачественное обслуживание, уровень удовлетворенности клиента по заранее оговоренной шкале и т.д. Ну и конечно, нельзя забывать о критериях “в срок” и без превышения бюджета.

Ну и раздел, который, наконец – то, ответит на вопрос «Что все – таки строим?» Это раздел Устава под названием - продукт проекта. Кстати, именно высокоуровневое описание продукта проекта в большинстве случаев даст ответ на вопрос, а сможем или нет, достижима цель или нет? Буква А в смарте.

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

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

Больше всего трудностей на практике вызывает заполнение разделов Цель и Продукт проекта. Поэтому остановлюсь на них отдельно. К сожалению, очень часто в этих разделах встречается одно и то же описание. Цель – построить фабрику по производству стеновых панелей. Продукт – фабрика по производству стеновых панелей. Давайте попробуем разобраться, почему такая формулировка содержит в себе много рисков, прежде всего для Руководителя проекта.

Для этого я предлагаю вам совсем немного погрузиться в основы дисциплины системная – инженерия. Системный инженер - это человек, способный организовать создание сложной технической системы: ракеты, самолета, буровой платформы. Поэтому в его голове мыслительный процесс целиком и полностью основан на понятии система. Но он, в отличие от, казалось бы, логичного взгляда на описание системы как совокупности некоторых элементов, в первую очередь смотрит не внутрь её, а наружу. Например, если рассмотреть обычный маркер как систему, то, наверное, большинство из вас, да и я сам начнут, описание со слов: Маркер - это совокупность элементов, состоящая из корпуса, стержня, чернил, колпачка и т.д. Но с точки зрения системного инженера - это прибор, который оставляет синий след на бумаге толщиной не менее 3 миллиметров, длиной не менее 15 миллиметров, не допускающий пролива чернил на рубашку пользователя.

Т.е. любую систему можно описать как с точки зрения ее Функции, так и с точки зрения ее Конструкции. А между этими описаниями всегда есть место архитектуре, т.е.

Описанию того как элементы конструкции во взаимодействии будут обеспечивать функцию. Так вот ключевой парадокс целеполагания в проекте состоит в том, что Заказчик всегда желает получить именно функцию. А руководитель проекта настоятельно пытается сдать ему конструкцию. Но даже если он, руководитель проекта, в уставе убедит заказчика написать в цели: «Построить фабрику по производству стеновых панелей», то Заказчик предпримет все усилия, чтобы фабрику не принять, пока она не выйдет на производственную мощность, т.е. не станет обеспечивать свою функцию.

В таком случае, совет один. Руководители проекта должен думайте о проекте от лица Заказчика. В уставе проекта в разделе Цели описывайте функцию, и дальнейшее планирование проекта осуществляйте исходя из необходимости обеспечить эту самую цель. Конечно, практически во всех стандартах по управлению проектами разработка Устава – это функция Заказчика. Но в наших условиях, чаще всего этим занимается Руководитель проекта. Поэтому, когда будете писать очередной устав, вспомните картинку из системной инженерии, и по-новому пересмотрите ограничения проекта. Функция – всегда дороже, но именно ее выжмет из вас Заказчик. И не забудьте проверить записанные вами цели на предмет соответствия принципу SMART.

МОДУЛЬ 4 Организационно – ролевая парадигма проекта Друзья, мы с вами продолжаем обсуждать парадигмы проектного менеджмента. У

самого понятия менеджмент или менеджер есть очень много определений, но

совершенно точно, что их всех объединяет одна мысль: Менеджмент - это про то, как

грамотно расставить людей и организовать их на совместное эффективное

взаимодействие. И это совершенно точно про людей. Ведь глупо звучит фраза,

например, менеджмент станка с числовым программным управлением или

менеджмент автомобиля. Поэтому, хоть прямой перевод слова менеджмент — это

управление, но менеджер – всегда управляет людьми.

Поэтому тема этого раздела: Организационно – ролевая парадигма проекта. Именно

она позволит вам правильно организовать взаимодействие сотрудников в проекте.

Вообще людей вокруг проекта довольно много. Очень часто всех, кто так или иначе

участвует или заинтересован в проекте называют участники проекта. Но это не совсем

корректно. Мне больше нравится термин стейкхолдеры. Дословно стейкхолдер

переводится как держатель части, держатель интереса или заинтересованная сторона.

К стейкхолдерам относятся не только непосредственные участники проекта, такие как

Заказчик, Руководитель проекта, Команда, но и те лица и организации, чьи интересы

могут быть затронуты в ходе проекта. Либо, наоборот, у этих лиц и организаций есть

свой интерес в проекте, о котором чаще всего и менеджер не подозревает. Например,

довольно часто к стейкхолдерам проекта относят органы власти, общественные

организации и даже конкурентов. Но мы сегодня поговорим об основных

стейкхолдерах, т.е. тех лицах, которые принимают непосредственное участие в

проекте. И хотя все они в проекте заинтересованы – а это факт, ключевой парадокс

состоит в том, что интересы этих стейкхолдеров совершенно разные, а иногда и прямо

противоречащие друг другу.

Давайте разбираться во всем этом подробно. Например, в голове очень активного

бизнесмена возникла идея: выиграть гран – при в Формуле-1, и он инициирует проект

по созданию нового супер – болида. В этом проекте он будет выполнять роль

Заказчика. Основная цель проекта - это победа, как минимум на одном этапе гонки, а

как максимум - в сезоне. Если у этого бизнесмена будет недостаточно средств на

проект, он будет вынужден обратиться к Инвестору. В этот момент появляется еще

один стейкхолдер. Инвестор, конечно, тоже заинтересован в проекте, но у него другая

Цель. Он говорит нашему бизнесмену: «Денег дам, но скажи, как будешь возвращать?

За победу, насколько я знаю столько не дают, сколько ты у меня просишь» Бизнесмен,

конечно рассказывает о том, сколько рекламных контрактов он сможет заключить и

сколько просмотров обеспечит трансляции болида с логотипами рекламодателей.

Инвестор соглашается, но может потребовать увеличения рекламного пространства на

болиде и времени проезда под телекамерами, а еще минимизации затрат на создание

самого болида. У инвестора совсем другие цели, он хочет вернуть свои деньги с

прибылью. А это сильно противоречит интересам Заказчика. В этот момент появляется

еще один важный участник событий. Это пилот, без которого победы не будет. Он

будет эксплуатировать продукт проекта для достижения цели Заказчика. И он

предъявляет свои требования к проекту, а точнее к продукту проекта к болиду. Выше

динамика, комфорт и удобство управления, климат-контролю последнего поколения и

т.д. Что во многом противоречит интересам и Инвестора, и Заказчика.

Коллеги, ситуация почти вымышленная, но, к сожалению, очень часто встречающаяся в

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

основных стейкхолдеров проекта, я имею в виду Заказчика, Инвестора, Пользователя

(или иногда его называют функциональным заказчиком) и Руководителя проекта

состоит в том, что изначально все эти участники находятся в состоянии конфликта

интересов. И конечно, пострадает от этого конфликта больше всего конечно

Руководитель проекта.

Встает вопрос - Что делать, когда возникает такой конфликт интересов разных

стейкхолдеров? Первое: знать и понимать, что такой конфликт существует! Для

подавляющего большинства проектов существуют свои Заказчики, Инвесторы и

Функциональные заказчики. Даже если они так не называются они есть, поверьте.

В связи с чем второе действие: четко персонифицировать все роли в проекте, и не

только для себя, но и для всех участников. Т.е. договориться о том, кто какую роль на

себя берет, и закрепить это на бумаге. Ключевые роли, чаще всего фиксируются в

Паспорте или Уставе проекта. Фиксируются, это значит напротив каждой роли написана

Фамилия, имя и отчество, а так же перечень полномочий и ответственности.

Ну и третье, и самое важное. Чтобы не быть жертвой этого самого конфликта

интересов, грамотный руководитель проекта всегда договаривается о том, кто будет

самым главным его начальником, с кем он будет обсуждать стратегические вопросы

проекта, у кого он будет просить ресурсы, и с кем будет взаимодействовать по всем

ключевым моментам. Чаще всего этого человека называют Куратор проекта, в

западных стандартах используют термин Спонсор. Это может быть специально

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

себя эту роль. Обычно, Куратор — это человек высокого уровня полномочий и власти с

одной стороны, и заинтересованный в стратегическом успехе проекта, с другой

стороны.

Все шаги, которые я перечислил, а также сам процесс формирования организационно –

ролевой структуры проекта, называется организационное планирование. И этот

процесс очень важен. Потому что проект требует новых видов коммуникаций и

каналов взаимодействия. По сути мы должны создать маленькую мини организацию

для конкретно взятого проекта в которой будут свои начальники и подчиненные, свои

отделы и департаменты, свое распределение полномочий и обязанностей. И как в

любой организации в такой структуре нужно выделить блок руководства и основной

исполнительский блок.

Поэтому в проекте обычно выделяют две команды: команду управления проектом и

непосредственно команду проекта. Давайте разберемся, как они формируются.

Чаще всего в команду управления входят самый главный технарь в проекте, который

лучше всех разбирается в предметной области. В разных отраслях его по-разному

называют: главный инженер проекта, генеральный конструктор, режиссёр, системный

инженер, системный архитектор, технический руководитель проекта. Для небольших

проектов эту роль берет на себя сам Руководитель. Отдельно в команду управления

назначают экспертов, ответственных за различные направления: финансиста,

экономиста, маркетолога, специалиста по набору персонала и пр. Плюс, для больших

проектов, в команду управления назначают представителей поставщиков и

подрядчиков, вовлеченных в проект. Основное правило формирование команды

управления – пофамильное назначение сотрудников на ту или иную роль. Конечно

допускается совмещение ролей, но это тоже должно быть зафиксировано. Таким

образом формируется команда управления проектом. В некоторых организациях ее

называют рабочая группа. Она собирается на регулярной основе, осуществляет

планирование проекта и совместно решает все возникающие трудности и проблемы в

ходе реализации.

Все остальные участники проекта, исполнители поставщики, подрядчики, образуют

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

запланированные работы и своевременно отчитаться о результатах выполнения.

Очень часто, для более конкретного распределения ролей и ответственности в проекте

формируется документ Матрица ответственности. По вертикали перечисляют работы

или функциональные области проекта, по горизонтали - список участников, чаще всего

из команды управления проектом. На пресечении расставляются буквы,

соответствующие некой легенде. О – ответственный, И – исполнитель, С – согласует, К –

например, консультирует и т.д. Буквы могут быть разные, но две из них в любом случае

должны быть. По каждой работе должен быть назначен Ответственный, и только один

Ответственный. По каждой работе должен быть как минимум один Исполнитель.

Посмотрите после этого модуля на представленный фрагмент матрицы

ответственности и попробуйте найти в ней методические ошибки и неточности.

А мы подводим итоги. В любом проекте существует конфликт интересов его основных

участников. Для его минимизации грамотный Руководитель проекта формирует

организационно – ролевую структуру и распределяет между участниками роли и

ответственность. Очень важной ролью в проекте является роль Куратора или Спонсора.

Не начинайте проект пока не познакомились с Куратором и не убедились, что он

понимает свою роль.

Все роли в проекте должны быть закреплены за конкретными людьми со своими

Фамилией, именем и отчеством. Это как в театре. В программке спектакля всегда

напротив роли подчеркнута фамилия актера, который сегодня ее играет. Так и в

проекте я могу занимать вполне определенную должность в штатной структуре

организации, но мои роли в проектах могут быть совершенно разными.

МОДУЛЬ 5 О жизни в матрице Друзья, в этом разделе мы с вами обсудим, как выделить людей в команду проекта,

если они работают в рамках организационно – штатной структуры компании. Вопрос,

как организовать людей в структуру, соответствующую потребностям проекта часто

вызывает много споров и разногласий. И вот почему. Штатное расписание любой

компании складывается, обычно, довольно долго. Формируются отделы,

подразделения, департаменты. Между людьми распределяются обязанности, пишутся

должностные инструкции. И все это ориентировано на выполнение основных задач

организации. Для большинства компаний эти задачи операционные, циклично-

повторяющиеся.

Но для проекта, в подавляющем большинстве случаев, требуется участие нескольких

сотрудников из разных отделов, служб и подразделений. Т.е. организационная

структура проекта чаще всего не соответствует штатному расписанию компании. И это

серьезная проблема. Основной организационный парадокс проектного управления

состоит в том, что большинство компаний и организаций, с точки зрения штатной

структуры, не приспособлены для эффективной реализации проектов.

Где же выход из такой ситуации? Предлагаю обратится за советом к международным

стандартам по проектному менеджменту. А стандарты предлагают нам несколько

вариантов, или, я бы сказал, - подходов к формированию команды проекта. Это

функциональный подход, проектный подход и матричный подход. Ну и, конечно,

возможна комбинация этих трех способов. Давайте попробуем понять достоинства и

недостатки каждого из них.

Подход функциональный. Как известно, многие из руководителей организаций могут

совершенно небезосновательно заявить: «Мы не готовы ломать сложившуюся

вертикаль власти. И в проектах будем работать в соответствии с утвержденной

функциональной структурой!» Правомерно? Почему бы и нет. Действительно, если

требуется выполнить небольшой проект. Например, организовать участие компании в

международной выставке. То, в соответствии с функциональной структурой назначаем

руководителем проекта - главного маркетолога. Он, в свою очередь, вовлекает в

команду проекта своих подчиненных, перераспределяя между ними обязанности с

учетом новой задачи. И все бы хорошо и здорово, но мы забыли о том, что скорее

всего наступит момент, когда маркетологу потребуется, пусть на короткое время, но

сотрудник другого отдела. Юрист, например. В этом случае наш назначенный

руководитель проекта приходит к начальнику юридического отдела и требует в

срочном порядке, выставку никто не перенесет, выделить ему юриста для

согласования договора с организаторами. Начальник Юридического отдела спокойно

говорит: “А у меня регламент, складывай свой проект договора в папку входящие,

через 5 дней (по регламенту) согласуем”.

И вот тут возникает конфликт. Который чаще всего выходит на уровень вышестоящего

руководителя. Там, он конечно разрешается, но потрачено много времени и, как ни

парадоксально, денег. Ведь в разрешении этого мелкого вопроса поучаствовали

дорогостоящие руководители высокого уровня. И это типичная проблема

функционального подхода. Когда два сотрудника из разных отделов не могут между

собой договориться, то в этот процесс вовлекаются их начальники отделов, плюс два

начальника департаментов, плюс генеральный директор, ну или заместитель.

Наверное, каждый из вас не раз принимал участие в таком совещании. Можно в таком

режиме работать - спросите вы? Да, в принципе, можно. Но это с точки зрения проекта

- это долго, а с точки зрения организации еще и дорого.

Где выход? Его может предложить генеральный директор, когда ему надоест

заниматься микроменеджментом и вникать в суть всех мелких конфликтов своих

подопечных. Он может издать приказ следующего толка: Начальнику маркетингового

отдела, переложить свои обязанности на заместителя и подать список сотрудников

необходимых для проведения выставки. Начальникам отделов выделить на время

проекта сотрудников руководителю проекта, а их текущую нагрузку перераспределить

между оставшимися сотрудниками. Т.е. для проекта формируется временное

подразделение с нужным числом специалистов, которые исключаются из основного

процесса. Такой подход называется проектный. Подавляющее большинство

конфликтов функционального подхода снимается. Все решается очень быстро.

НО. Теперь страдает сама организация - это, во-первых, а сотрудники, выделенные в

команду проекта, не загружены на 100%. Юрист быстро согласовал свой документ и в

лучшем случае ничего не делает. В худшем руководитель проекта назначает его на

другие задачи, например, разгрузку оборудования для стенда на выставке. А платим

мы ему как юристу… В итоге, проектный подход к формированию команды позволяет

существенно выиграть в сроках, но это очень дорого. Да и проект не один выполняется

в организации. Под каждый проект не напасешься юристов. Однако, для больших,

приоритетных проектов такой вариант единственно возможен.

Где же золотая середина. И специалисты по проектному управлению нашли ее. Это

матричная структура. Приказом по организации в команды руководителя проекта

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

полномочия ставить им задачи и требовать их выполнения. Но передаются эти

сотрудники не на все время проекта, а только на время необходимое для выполнения

конкретных задач. И никто не снимает с них задач по основной работе. В принципе все

выглядит на первый взгляд логично и стройно. Руководитель проекта ставит задачи по

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

сам сотрудник. У него появляется два начальника, которые одновременно требуют с

него выполнения своих задач. Возникает конфликт интересов. У которого даже есть

свое название. Матричный конфликт или порок матрицы. Ни одной компании в мире

не удалось на 100% преодолеть или разрешить матричный конфликт. Но многие

научились его довольно хорошо сглаживать или минимизировать. Основной причиной

такого конфликта является то, что в борьбе за ресурс сталкиваются две структуры:

штатная структура компании и организационная структура проекта.

Но матричная структура, с точки зрения компании в целом, - самый эффективный

способ реализовать проекты без существенного ущерба для основного

производственного процесса.

Когда же матричная структура будет хорошо работать? Есть несколько условий,

которые требуется выполнить руководству компании для построения эффективной

матрицы.

Первое, и, наверное, самое главное. Желание и воля первого лица организации. Во

всех своих выступлениях, на всех совещаниях он должен прежде всего сам следовать

этим принципам и требовать их выполнения от своих подчиненных. Вплоть до

ситуации, когда он может быть назначен в какую-либо из команд проекта и так же как

все будет выполнять указания руководителя этого проекта. Это сложно, но без такой

внутренней корпоративной проектноориентированной культуры, скорее всего,

матрица не заработает.

Второе условие. Необходимо убедить функциональных руководителей в нормальности

ситуации, когда их сотрудники начинают выполнять задачи по проектам для других

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

наоборот всячески содействовать такой работе своих подчиненных. Такие

руководители должны четко осознать свою роль в проектах, эта роль называется

«менеджер ресурсов». Менеджер ресурсов не выполняет работу самостоятельно, а

отвечает за своевременное выделение в проект квалифицированных специалистов, а

также отвечает за качество их работы в проекте.

Третье условие, которое нужно соблюдать - загрузку сотрудников по проектам нужно

как можно раньше определять и согласовывать с функциональными руководителями.

Здесь для руководителей проектов очень важны навыки ресурсного планирования. И

самое главное, сотрудники, вовлекаемые в проекты не должны чувствовать в этом

никакой угрозы для себя. Они должны нормально воспринимать нескольких

руководителей, понимая, что те, прежде чем поставить задачи, договорились как будут

использовать один и тот же ресурс.

Дополнительно способствует эффективной работе в матричной структуре - системы

финансового стимулирования за участие в проектах. Причем как самих сотрудников,

так и их функциональных руководителей. Иногда, хорошо помогает выделение

руководителей проектов в отдельное подразделение. Потому что многим сотрудникам

порой сложно смириться с фактом, что назначенный руководитель проекта - это такой

же рядовой специалист из соседнего отдела.

И еще одним способствующим фактором является применение единого центра

коммуникаций по проекту. Людям из разных отделов нужно просто помочь научиться

общаться по проекту между собой. Вплоть до того, что собираться командой проекта

по пятницам - просто для обмена информацией о том, кто чем занимался в это время.

Все эти условия очень сложно одновременно соблюдать и выполнять.

Давайте подведем итоги:

Функциональная структура чаще всего является самой неэффективной для

формирования команд проекта.

Для больших сложных проектов самым подходящим является проектный подход, когда

люди выделяются в проект на 100% своей загрузки.

Во всех остальных случаях наиболее эффективным способом организации является

матричный подход. Он связан с рядом проблем, возникающих из-за матричного

конфликта. Но научиться работать в матричной структуре можно. И это, порой,

открывает много возможностей как для организации, так и для самих сотрудников

выйти за рамки каждодневной процессной рутины своего отдела. А может даже

возглавить сложный интересный проект. Проектная карьерная лестница гораздо

короче. Вчера администратор проекта, завтра руководитель, а в перспективе куратор, а

это как минимум уровень ТОП минус один.

МОДУЛЬ 6 Парадоксы планирования Друзья, в этом разделе я предлагаю обсудить одну из самых важных тем в проектном

менеджменте - планирование. Мы все, так или иначе, сталкивались с задачами

планирования. Сами писали планы, подчиненных обязывали, начальники нам давали

поручения создать план. Но, за этой будничностью задачи порою мы забываем

ответить на один вопрос. А зачем мы планируем? Ведь все равно все пойдет не по

плану, говорят многие менеджеры. Кстати, во многом они правы. В этом и заключается

основной парадокс планирования. Планы меняются, но без планов не обойтись. Много

великих людей подтверждают эту мысль.

Великий немецкий полководец Гельмут Фон Мольтке говорил, что ни один план не

выдерживает столкновения с противником. Поэтому план ничто, но планирование все!

Эту же мысль повторил и дополнил в свое время генерал Эйзенхаурер. Любой план –

ничто, так как устаревает в тот момент, когда вы закончили его составлять. Но

планирование – это всё, так как обеспечивает единое понимание целей и способов их

достижения, что позволяет вашим подчинённым действовать самостоятельно.

И мне очень импонирует высказывание Генри Киссенжера. Он говорил, что выработка

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

Это высказывание я бы отнес к основным парадигмам проектного менеджмента.

Совершенно точно, что план должна разрабатывать команда проекта под

руководством его менеджера.

Так какой же план они должны сделать? Какой план будет полезен, прежде всего в

ходе реализации проекта. Задавая многим руководителям проектов вопрос: “Зачем

нужен план?” - я получал практически всегда одни и те же ответы. И вот какие:

Ничего не забыть! Определить полный состав работ

Зафиксировать точки получения важных результатов в проекте

Определить последовательность действий по получению результатов

Оценить: Сроки, Ресурсы и Затраты

Для анализа и учета рисковых ситуаций

Для поиска оптимального пути достижения цели

Для координации, отслеживания и контроля в ходе реализации

И самое главное, о чем очень часто забывают. План нужен для ПРОГНОЗИРОВАНИЯ и

своевременного (проактивного) принятия решений по корректировке оставшейся части

плана.

А вот для того, чтобы ответить на вопрос “Что именно планируем?” руководителям

проектов на помощь приходит, так называемый, магический треугольник проектного

управления. Его вершины - это цели и содержание, затраты, а также сроки. Конечно,

все ограничения нашего проекта должны быть сбалансированы и представлены в виде

соответствующих планов.

В первую очередь, нам нужен план по содержанию. То есть полное описание того, что

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

календарный план, который даст ответ на вопрос: “а когда эти самые результаты мы

получим?”. И конечно, нам потребуется ответ на вопрос, какими силами мы сделаем

это и сколько потребуется денег для реализации проекта.

Обратите внимание, что первично все – таки содержание. А уже вторым шагом

определяем потребности в сроках и затратах. Именно такая последовательность даст

нам самый реалистичный план. Конечно, при недостатке средств или сжатых сроках,

возможно, мы с Заказчиком скорректируем содержание, но это шаг номер два.

Парадоксальное правило профессионального руководителя проекта звучит следующим

образом: «Начиная планирование не думай о сроках, не думай о деньгах! Определи

сколько надо денег и времени для достижения цели, и только потом обсуди с

Заказчиком возможные изменения в содержании, сроках или затратах”.

Итак, рассмотрим каждый из шагов подробнее. Планирование содержания! Основным

инструментом в планировании содержания является построение, так называемой,

структурной декомпозиции работ. Т.е. все работы по проекту мы детализируем до

уровня, когда станут понятны исполнители, длительности отдельных задач и

необходимые ресурсы. Причем не нужно для каждого конкретного элемента

добиваться идеальной точности. Сама декомпозиция увеличивает точность

планирования всего проекта.

Вспомните задачку по теории вероятностей для первого курса. Если требуется

проложить сто километров железнодорожного полотна, а станок по производству

рельс выпускает километровые отрезки с точностью плюс минус 10%, то какова будет

погрешность всего пути. Как ни парадоксально, точность всего пути будет плюс минус

1%. Т.е. в корень из N раз точнее каждого отрезка. Загляните на досуге в учебник по

«Терверу», это действительно так. Для нас с вами это означает, что если в структурной

декомпозиции работ будет сотня элементов нижнего уровня, то в оценках каждой

работы мы можем ошибиться достаточно сильно, например, в полтора два раза, т.е. на

50 – 100%. Но при этом общий результат по проекту, например, в финансовом

выражении, будет иметь погрешность всего 10%. Но здесь нужно соблюсти одно

условие. Все элементы декомпозиции должны быть примерно одинаковы как по

длительности, так и по затратам. Суммируя снизу-вверх получим довольно точные

оценки по объему ресурсов и затратам.

Но длительности задач, т.е. планирование сроков, так складывать неправильно.

Потому, что многие из задач будут выполняться параллельно. Здесь на помощь

приходят методы календарно-сетевого планирования. Все задачи нужно выстроить в

одну определенную технологическую последовательность. После чего рассчитать

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

мы поймем, какие именно задачи будут напрямую влиять на общий срок проекта.

Именно они называются критическими.

Срыв сроков критической задачи влечет за собой срыв сроков проекта. Обычно такие

задачи в системах календарного планирования и контроля обозначаются красным

цветом.

И в этом еще один парадокс проектного менеджмента. Для соблюдения требований по

срокам, совсем не обязательно все без исключения задачи завершать в соответствии с

планом. Важно следить за тем, чтобы вовремя завершались только критические

задачи. И еще один важный для практики результат мы получим, если установим

взаимосвязи между задачами. В ходе реализации проекта мы сможем получать

прогноз выполнения по срокам. Т.е. своевременно, на основе фактического времени

исполнения критических задач сможем дать ответ на вопрос укладываемся или нет в

установленные временные ограничения. И если нет, у нас будет время

подкорректировать нашу оставшуюся часть планов.

Но, рассчитать критический путь недостаточно. На каждую задачку нужно назначить

соответствующие ресурсы. А они могут быть трудовые, те что можно померить рублями

в час. Материальные, те что измеряем литрами, штуками, километрами и так далее. Ну

и финансовые затраты - тоже ресурс, и его нужно учесть. Зачем нужно назначать

ресурсы при планировании сроков? Да ровно за тем, чтобы до начала работ

обнаружить возможные ресурсные конфликты. Когда один и тот же человек,

например, назначен на несколько одновременно выполняемых задач. Пока мы не

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

Кстати именно на основе такого календарно – ресурсного плана создается и план

финансовый. Или бюджет проекта. Бюджет отличается от обычной сметы тем, что в

нем присутствует календарная шкала. То есть только на основе бюджета затрат мы

сможем сформировать подходящий график финансирования проекта.

Только после ресурсной оптимизации и добавления рисковых запасов по срокам и

ресурсам можно сохранить план для того, чтобы в ходе реализации осуществлять его

отслеживание и контроль. Такой сохраненный план, чаще всего называют базовым.

Именно он жестко привязан к датам и срокам. А текущий план, как раз наоборот, - не

должен содержать никаких фиксированных дат и ограничений. Только в этом случае

мы сможем, сравнивая эти два плана, спрогнозировать возможные будущие

отставания. Предлагаю записать этот факт в копилку наших парадоксов проектного

менеджмента.

Давайте подведем итоги. Так какой же план будет хорошим рабочим инструментом

руководителя проекта? А это план в котором:

• В основе календарного плана лежит структурная декомпозиция работ (WBS)

• Календарный план содержит необходимое количество контрольных точек (вех)

• Работы и вехи связаны между собой зависимостями (задана сетевая диаграмма)

• Задачи и вехи текущего плана не имеют фиксированных ограничений

• Определен критический путь проекта

• Задан базовый план проекта (задающий директивные сроки)

• Перед ключевыми вехами проекта заданы временные буферы

• На каждую задачу назначены ресурсы (трудовые, материальные, финансовые)

• В календарном плане отсутствуют ресурсные конфликты

И главное. Такой план – это инструмент Руководителя проекта по прогнозированию

возможных отклонений. Не показывайте его Заказчику. Для заказчика всегда имейте

под рукой укрупненный план по контрольным событиям. Этого для его уровня вполне

достаточно.

МОДУЛЬ7 О рисках и шампанском для менеджера Друзья! Сейчас мы с вами поговорим о том, что по большому счету и отличает

отношение к жизни руководителя проекта от всех других руководителей. Я говорю об

отношении к рискам.

Давайте договариваться о терминах. Когда вы слышите слово риск, наверняка, в голову

приходят страшные ассоциации: угрозы, потери, неопределенность, срывы сроков,

опасность и так далее. Во многом вы правы, но! Очередной парадокс проектного

менеджмента состоит в том, что у успешного руководителя должна быть совершенно

другая основная ассоциация с понятием риск. Кто не рискует, тот не пьет шампанское!

Грамотный менеджер сознательно идет на риск для того, чтобы увеличить выгоду

проекта. Но, конечно, работает он по большей части с рисками – угрозами. Давайте

разбираться с этим.

С точки зрения определения мне очень нравится происхождение слова риск. Оно

образовано от испано – португальского и на русский язык дословно переводится как

«подводная скала». Посмотрите, какой хороший образ получается. Если мы с вами

участвуем в кругосветной регате и вдруг на пути встречается та сама подводная скала.

Надводную ее часть мы отчетливо видим. Но неизвестность состоит в том, что под

водой? У нас, как у капитана парусника есть выбор. Вариант номер один, рискнуть,

обойти слева и победить! Сэкономить время, ресурсы, путь. Вариант номер два,

рискнуть и обойти справа. И все потерять, разбиться, сесть на мель.

Вы спросите, как можно не рисковать? Есть два варианта. Либо вообще остановиться,

либо обойти по большому радиусу. Но при этом, если не рисковать, мы железно

проигрываем! А если рискнуть – есть шанс на победу!

Поэтому мне лично импонирует определение понятия риск американского института

PMI. Итак, риск - это неопределённое событие или условие, наступление которого

может иметь как положительное, так и отрицательное влияние на проект.

Остается вопрос, как все-таки рискнуть правильно. Обойти скалу с нужной стороны.

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

случаях с подводными скалами очень помогает. Вот еще вариант - можно нанять

опытного лоцмана из этих мест. Или можно отправить на разведку шлюпку.

Пожертвовать малым, чтобы выиграть в большом. В этом основной смысл грамотного

управления рисками. Мы заранее предпринимаем какие-то дополнительные меры,

которые конечно чего – то стоят, но все это делаем ровно для того, чтобы избежать или

максимально минимизировать большие потери!

Давайте поразмыслим, так в чем же кроется основная причина появления рисков? В

примере с подводной скалой самую большую опасность для нас представляет, как ни

странно, не сама скала, а отсутствие у нас достоверной информации о ее подводной

части - для нас эти данные неизвестны, мы их не можем определить. И действительно,

именно неопределенность – основная причина всех рисков в проекте.

Отмечу, что неопределенность может быть существенно разной. Все события, которые

могут произойти в проекте с точки зрения уровня неопределенности можно разделить

на три условные группы.

Первые, так называемые неизвестные – неизвестные. Это события, о которых мы

ничего не знаем и даже предположить не можем, что они могут произойти. К

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

знаешь. Такие события, обычно не попадают в зону управления рисками.

Другая сторона неопределенности — это события известные, которые с высокой долей

вероятности произойдут и повлияют на наш проект. Коллеги, такие события тоже не

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

соответствующий раздел паспорта проекта под названием список ограничений.

Рисками же, давайте договоримся называть события Известные – неизвестные.

Известность в данном случае заключается в том, что мы можем событие описать,

обсудить, рассказать о возможных последствиях. А неизвестность состоит в том, что мы

не знаем: произойдет это событие или нет. А если произойдет, то как сильно повлияет

на проект? Именно такие события мы будем рассматривать как объект для управления.

Теперь давайте рассмотрим основные две характеристики риска. Это его вероятность и

уровень последствий. Причем, в начале проекта условная общая вероятность рисков

выше. Т.е. все еще может произойти. А вот последствий в начале проекта не стоит

сильно боятся, впереди еще довольно много времени чтобы исправить ситуацию. К

тому же, проект в самом начале скорее всего только на бумаге. Но вот к окончанию -

возможные последствия могут быть очень критичными. Зато вероятность снижается. В

связи с этим общая условная опасность риска, как произведение вероятности на

последствия, в ходе проекта примерно одинакова.

Поэтому все специалисты по управлению проектами рекомендуют на протяжении

всего проекта вести регулярную работу с рисками. А порядок данной работы

следующий.

В первую очередь необходимо собраться команде управления проектом и в режиме

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

и угроз. Включая вторжение инопланетян и остановку вращения Земли. Здесь можно

не бояться переборщить, важно наоборот - ничего не забыть. Шаг второй. Для каждого

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

это делают эксперты по заранее согласованной шкале. Здесь важно, чтобы все

участники использовали единую шкалу. Только в этом случае мы будем иметь право

сравнивать в последствии эти оценки между собой.

Шаг третий. Перемножаем вероятность на последствия и ранжируем все риски от

самых опасных, их еще часто называют риски – тигры, до самых не опасных их иногда

называю риски – мыши.

С тиграми начинаем работать. Т.е. для каждого риска из списка тигров определяем

способ реагирования и разрабатываем в общем случае два плана. Первый план - это

план антирисковых мероприятий. То есть то, что мы предпримем заранее, для того

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

называют План – А. И второй план. План на случай если риск все-таки состоялся. Как мы

будем ликвидировать последствия. Это план – Б.

В ходе проекта характеристики рисков могут меняться. Также могут появляться риски,

которые мы в самом начале на идентифицировали, поэтому необходим регулярный

мониторинг рисков в проекте.

Но давайте вернемся к этапу планирования реагирования на риски. В зависимости от

опасности риска и от наших возможностей, существует выбор из четырех стратегий

реагирования. Давайте рассмотрим их с точки зрения формирования планов А и Б.

Стратегия избежание. Мы предпринимаем чаще всего дорогостоящие, трудозатратные

планы А для того, чтобы полностью исключить либо вероятность этого риска, либо его

последствия. Т.е. план Б в этом случае нам не потребуется.

Стратегия Минимизация. Заранее предпринимаем действия по снижению вероятности

риска, либо заранее защищаемся от возможных его последствий. Но мы понимаем, что

риск все-таки может произойти. Поэтому план Б тоже составляем.

Стратегия Передача – это частный случай минимизации. Передаем возможные

последствия риска третьей стороне. Чаще всего, это страхование или разделение

рисков между подрядчиком и заказчиком. Здесь план А нужен, т.к. потребуется

заключить страховое соглашение. И план Б тоже необходим на случай, если страховое

событие произошло.

Последний вариант стратегии – Принятие. Осознанно, для несущественных рисков

ничего заранее не предпринимаем. Но на всякий случай, как говориться в конверте, у

нас есть план Б.

И во что получается, друзья. Очередной парадокс проектного менеджмента в том, что

самый идеальный и подробный план реализации проекта никогда не будет выполним,

если мы не включим в него необходимое количество планов А, и не заготовим, на

всякий случай, достаточное количество планов Б. А в бюджет проекта нам придется

внести полную стоимость планов А. Т.к. они должны быть выполнены заранее, до того,

как риски могут состояться. Плюс в бюджет необходимо будет заложить резерв на

возможные планы Б, с учетом вероятности соответствующих рисков. Но и это еще не

достаточный резерв. Мы же забыли те самые «неизвестные неизвестные», события,

которые не поддаются управлению, но все-таки могут произойти. Для ликвидации

последствий таких неизвестных – неизвестных еще придется добавить несколько

процентов к рисковому бюджету.

Ключевой вывод по этому разделу следующий: для успешной реализации проекта

требуется плотная работа с рисками. Итогом которой должен стать перечень

антирисковых планов и сформированный рисковый бюджет.

Остается ответить на вопрос, а где же тут на шампанское менеджеру? Все просто. На

шампанское останется то, что нам удастся сэкономить из рискового бюджета на планы

Б и неизвестные неизвестные. А это во многом зависит от того, как эффективно мы

реализуем планы А.

Управляйте рисками - это выгодно!

МОДУЛЬ 8 Парадоксы отслеживания и контроля проекта Друзья! Мы на финишной прямой. В заключительном модуле нашего курса поговорим

о принципах организации эффективной системы отслеживания и контроля проекта во

время его реализации. Думаю, вы обратили внимание, что предыдущие семь блоков

были посвящены процедурам запуска и планирования проекта. И только сейчас мы

говорим про контроль.

В этом и заключается ключевой парадокс этого процесса. Если грамотный

руководитель проекта уделит достаточное количество сил, времени и трудозатрат

задачам грамотного старта и планирования, то на этапе реализации ему останется

лишь собирать отчетность и вносить коррективы в оставшуюся часть проекта.

Немецкий фельдмаршал Гельмут Фон Мольтке-старший говорил: “План – ничто,

планирование все!”. Про этого военачальника ходят истории, что даже в ходе

ожесточенного сражения он позволял себе после обеда часок – другой вздремнуть. И

даже если во время его отдыха вдруг прибегал его подчиненный, например, с

сообщением о прорыве французами обороны, он спокойно выслушивал доклад и

говорил: «Ящик номер пятнадцать, план номер 2Б, передайте в войска и действуйте по

плану» после чего продолжал свой отдых. Мне кажется, это отличный образ

эффективного, профессионального руководителя проекта. Чем детальнее и подробнее

мы проработаем план нашего сражения, извините, проекта, тем спокойнее и

увереннее будем чувствовать себя в ходе его реализации.

Давайте разбираться. Прежде всего нужно понять, что будем контролировать в

проекте? К окончанию нашего курса у вас, дорогие слушатели, уже сомнений в ответе

на этот вопрос быть не должно. Мы контролируем три ключевые характеристики

любого проекта: это содержание, сроки и затраты. Но, не сочтите меня занудой, нам

снова придется вернуться на этап планирования. Именно в рамках организации и

подготовки проекта необходимо задуматься о построении эффективной системы

контроля проекта. Что она из себя представляет?

Итак, для построения системы контроля обязательно вам обязательно потребуются

планы, которые нужно будет сравнивать. В основе любой системы контроля лежат три

плана. Их принято называть базовыми. Это базовый план по содержанию, т.е.

утвержденная структурная декомпозиция работ, так называемая WBS с подробным

описанием каждой работы. Второй план, который потребуется, это базовый

календарный план, или его иногда называют базовое расписание. В нем утверждены

конкретные сроки выполнения задач, а самое главное согласованы все конкретные

директивные сроки ключевых контрольных событий, вех проекта. Третий базовый план

- это план выполнения стоимости, или базовый бюджет проекта. Он необходим для

отслеживания стоимостных параметров.

Давайте разбираться с каждым планом подробно. С точки зрения контроля

содержания обычно возникает меньше всего вопросов. Для каждой работы мы

должны определить самый подходящий тип контроля. Если работу можно померить в

единицах физического объема, то так и нужно поступать. Копаем в кубометрах,

штукатурим в квадратных метрах, прокладываем дорогу в километрах. Бывает, объем

работ сложно определить, например, в чем измерить выработку программиста, или

дизайнера, или разработчика учебных курсов? Не понятно. Для таких случаев

необходимо договориться с конкретным исполнителем о применяемой шкале

измерения прогресса. Можно использовать так называемый простой контроль, когда в

шкале два значения 0-100. 0 еще не сделано, 100 готово. Такая шкала допустима, но

исключительно для небольших задач, то есть задач длительность которых меньше, чем

период контроля. Кстати, о нем тоже нужно договориться: как часто я буду требовать

отчет от исполнителей. Если задача длительная, есть смысл разбить ее на условные

этапы. И с каждым из них соотнести определенный процент выполнения работы.

Например, 0% - не приступил к исполнению тот же дизайнер. 25% - сделал эскиз в

карандаше и согласовал его с Заказчиком. 50% - сделал эскиз в цвете. 75% - перенес

эскиз в систему моделирования и представил 3Д модель. 100% - работа завершена.

Подобного рода договоренности и шкалы должны быть определены для всех задач

нашего проекта.

Теперь рассмотрим контроль сроков. Для его осуществления потребуется тот самый

календарно – сетевой план, который мы рассматривали в предыдущем модуле. И я

настаиваю, что он должен быть именно сетевым, то есть все задачи этого плана

должны быть связаны зависимостями. Только в этом случае план сможет стать

инструментом прогнозов. А именно прогнозы мы должны получать в ходе проекта, так

как просто фиксация факта не поможет в его реализации. Давайте вспомним основную

парадигму проектного менеджмента. Проект всегда заброшен вперед. А управлять

можно только оставшейся частью проекта. Факт - это то, что было вчера. И если этот

самый факт сильно отличается от плана, то в проекте с этим уже ничего не поделаешь.

Так что же тогда сравнивать, если не план с фактом спросите вы? Давайте разбираться!

Итак, предположим, что мы с вами хорошо поработали и у нас есть детальный

календарно – сетевой план проекта, который был утвержден заказчиком. Прошел

первый отчетный период, мы собираем фактическую информацию. По завершенным

задачам нас интересуют, конечно, фактические даты начала и окончания каждой из

них. А по незавершенным, прежде всего, мы должны узнать прогнозную дату

завершения. Все эти даты вносим в наш календарный план. Эта процедура называется

– актуализация календарного плана. Дальше, если конечно мы используем

современную систему календарно – сетевого планирования, софт сделает все за нас. То

есть пересчитает даты по оставшейся части проекта с учетом введенного нами факта.

Именно поэтому ни одна дата в вашем текущем плане не должна быть зафиксирована

жестко. Парадокс, но без этого нельзя будет спрогнозировать будущие отклонения.

Зафиксированным остается только Базовый план.

После актуализации мы сможем увидеть отклонения. Причем отклонениями в

прошлой части проекта, ка вы понимаете мы уже не в силах управлять. Поэтому наш

основной взор должен быть устремлен на возможные отклонения в будущем. С ними

мы еще можем что – то сделать, если здесь и сейчас скорректируем наши планы. А

поэтому, друзья, эффективный контроль проекта - это не план – фактный анализ, а

сравнение базовых показателей плана с прогнозными. Только в этом случае можно

вообще говорить об управлении!

Итак, сравнили базовый план с прогнозным. Кстати прогнозный план очень часто

называют текущим планом. Сравнили базовые и текущие показатели, и, если есть

отклонения, собираем проектное совещание для того, чтобы обсудить возможные

действия по корректировке оставшейся части плана. Вариантов действий на самом

деле не так много. Можно, конечно, сократить длительность критических задач, чаще

всего для этого потребуются дополнительные ресурсы или сверхурочные работы, что

тоже дополнительные ресурсы. Второй вариант, можно запараллелить некоторые

задачи критического пути. Но тогда возможны технологические риски, а возможны и

новые ресурсные конфликты, если по плану эти задачи должны были выполнять одни и

те же люди. Третий вариант. Пожертвовать содержанием, то есть не доделать часть

работ. Заказчик конечно не одобрит, но если срок приоритетнее, то почему нет. И

четвертый вариант: в случае, если в базовый срок никак не укладываемся, то идем к

Заказчику и обсуждаем перенос базового плана. В этом и есть суть управления.

На регулярной основе проводим актуализацию планов, и если видим расхождение

базовых и прогнозных показателей принимаем решение по корректировке плана.

Самое важное, если эта корректировка требует согласия Заказчика, то это решение

оформляем в виде специального документа, который называется Запрос на

изменение. И все запросы на изменение подписываем у Заказчика и подшиваем в

отдельную папочку.

Только теперь, после корректировки оставшейся части плана мы с полной

уверенностью можем сказать: «В моем проекте все по плану!». И это будет означать,

как не парадоксально, не то что в прошлом я соблюдал все сроки, а то, что в будущем

мой текущий план по всем ключевым директивным вехам совпадает с базовым!

С точки зрения контроля стоимости все проще. Из утвержденного бюджета проекта

нам известна сумма расходов, которые должны состояться к текущей дате. С места

работ запрашиваем фактическую сумму понесенных затрат. Вычисляем отклонение.

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

не сможем сделать, сколько-нибудь объективный вывод о финансовых параметрах

проекта. Допустим мы сравнили плановые показатели бюджета с фактическими и о

чудо! отклонений не обнаружили. Сколько должны были потратить столько и

потратили. А ведь успокаиваться рано. Ведь возможны варианты. Например, по

деньгам отклонений нет, а объем выполненных работ больше запланированного. Это

означает, что мы идем с экономией. Но скорее всего все наоборот. Работ сделали чуть,

а денег потратили в соответствии с бюджетом на сегодняшний день. Вывод. Для

контроля стоимости обязательно необходимо собрать информацию о содержании

выполненных работ. И только на сопоставлении данных о стоимости и содержании

делать выводы.

Успешных вам проектов друзья! Учитесь делать прогнозы и тогда вы действительно

будете управлять, а не расстраиваться из – за план – фактных отклонений!

Мы завершаем этим модулем наш курс. Хочется верить, что те парадигмы, а самое

главное парадоксы проектного управления, о которых я рассказал станут для вас и

ваших соратников по проектам нормальной, каждодневной практикой.

Желаю всем, чтобы парадоксы проектного менеджмента перестали быть для вас

парадоксами! Однако - это заключительный парадокс! Успешных проектов!