SlideShare une entreprise Scribd logo
1  sur  43
Télécharger pour lire hors ligne
Управление проектами
ПАРАДИГМЫ И
ПАРАДОКСЫ
ПРОЕКТНОГО
МЕНЕДЖМЕНТА
Конспект учебного курса
Павел Шестопалов
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)
• Календарный план содержит необходимое количество контрольных точек (вех)
• Работы и вехи связаны между собой зависимостями (задана сетевая диаграмма)
• Задачи и вехи текущего плана не имеют фиксированных ограничений
• Определен критический путь проекта
• Задан базовый план проекта (задающий директивные сроки)
• Перед ключевыми вехами проекта заданы временные буферы
• На каждую задачу назначены ресурсы (трудовые, материальные, финансовые)
• В календарном плане отсутствуют ресурсные конфликты
И главное. Такой план – это инструмент Руководителя проекта по прогнозированию
возможных отклонений. Не показывайте его Заказчику. Для заказчика всегда имейте
под рукой укрупненный план по контрольным событиям. Этого для его уровня вполне
достаточно.
Конспект учебного курса парадигмы и парадоксы проектнного менеджмента
Конспект учебного курса парадигмы и парадоксы проектнного менеджмента
Конспект учебного курса парадигмы и парадоксы проектнного менеджмента
Конспект учебного курса парадигмы и парадоксы проектнного менеджмента
Конспект учебного курса парадигмы и парадоксы проектнного менеджмента
Конспект учебного курса парадигмы и парадоксы проектнного менеджмента
Конспект учебного курса парадигмы и парадоксы проектнного менеджмента
Конспект учебного курса парадигмы и парадоксы проектнного менеджмента
Конспект учебного курса парадигмы и парадоксы проектнного менеджмента
Конспект учебного курса парадигмы и парадоксы проектнного менеджмента

Contenu connexe

Tendances

Павел Шестопалов
Павел ШестопаловПавел Шестопалов
Павел Шестопаловa-dolgih
 
Управление проектами. Слайды к семинару.
Управление проектами. Слайды к семинару.Управление проектами. Слайды к семинару.
Управление проектами. Слайды к семинару.Kate Koltunova
 
Cравнение российских и зарубежных подходов по выполнению крупных капитальных ...
Cравнение российских и зарубежных подходов по выполнению крупных капитальных ...Cравнение российских и зарубежных подходов по выполнению крупных капитальных ...
Cравнение российских и зарубежных подходов по выполнению крупных капитальных ...Проектные сервисы
 
Управление проектами. Основы Project Management
Управление проектами. Основы Project ManagementУправление проектами. Основы Project Management
Управление проектами. Основы Project ManagementBmotion Communications
 
Презентация курса: "Управление проектами".
Презентация курса: "Управление проектами".Презентация курса: "Управление проектами".
Презентация курса: "Управление проектами".Tetiana Goncharova
 
презентация курса управление проектом
презентация курса управление проектомпрезентация курса управление проектом
презентация курса управление проектомАлександр гущин
 
Управление проектами информатизации. Введение. Тема 1
Управление проектами информатизации. Введение. Тема 1Управление проектами информатизации. Введение. Тема 1
Управление проектами информатизации. Введение. Тема 1Olya Kollen, PhD
 
Проектное предложение: разработка стратегии развития и внедрение системы стра...
Проектное предложение: разработка стратегии развития и внедрение системы стра...Проектное предложение: разработка стратегии развития и внедрение системы стра...
Проектное предложение: разработка стратегии развития и внедрение системы стра...Strategium.Space
 
Почему не работают проектные офисы (PMO)
Почему не работают проектные офисы (PMO)Почему не работают проектные офисы (PMO)
Почему не работают проектные офисы (PMO)Ivan Selikhovkin
 
Введение в управление проектами
Введение в управление проектамиВведение в управление проектами
Введение в управление проектамиValerii Kosenko
 
Дмитрий Маев - Внедрение проектного управления в инновационной девелоперской ...
Дмитрий Маев - Внедрение проектного управления в инновационной девелоперской ...Дмитрий Маев - Внедрение проектного управления в инновационной девелоперской ...
Дмитрий Маев - Внедрение проектного управления в инновационной девелоперской ...Проектные сервисы
 
Юрий Шойдин (Газпромнефть): Мастер-класс "Основы проектирования проекта"
Юрий Шойдин (Газпромнефть): Мастер-класс "Основы проектирования проекта"Юрий Шойдин (Газпромнефть): Мастер-класс "Основы проектирования проекта"
Юрий Шойдин (Газпромнефть): Мастер-класс "Основы проектирования проекта"Expolink
 

Tendances (20)

Павел Шестопалов
Павел ШестопаловПавел Шестопалов
Павел Шестопалов
 
Управление проектами. Слайды к семинару.
Управление проектами. Слайды к семинару.Управление проектами. Слайды к семинару.
Управление проектами. Слайды к семинару.
 
Cравнение российских и зарубежных подходов по выполнению крупных капитальных ...
Cравнение российских и зарубежных подходов по выполнению крупных капитальных ...Cравнение российских и зарубежных подходов по выполнению крупных капитальных ...
Cравнение российских и зарубежных подходов по выполнению крупных капитальных ...
 
Управление проектами. Основы Project Management
Управление проектами. Основы Project ManagementУправление проектами. Основы Project Management
Управление проектами. Основы Project Management
 
Презентация курса: "Управление проектами".
Презентация курса: "Управление проектами".Презентация курса: "Управление проектами".
Презентация курса: "Управление проектами".
 
презентация курса управление проектом
презентация курса управление проектомпрезентация курса управление проектом
презентация курса управление проектом
 
Управление проектами информатизации. Введение. Тема 1
Управление проектами информатизации. Введение. Тема 1Управление проектами информатизации. Введение. Тема 1
Управление проектами информатизации. Введение. Тема 1
 
Проектное предложение: разработка стратегии развития и внедрение системы стра...
Проектное предложение: разработка стратегии развития и внедрение системы стра...Проектное предложение: разработка стратегии развития и внедрение системы стра...
Проектное предложение: разработка стратегии развития и внедрение системы стра...
 
Почему не работают проектные офисы (PMO)
Почему не работают проектные офисы (PMO)Почему не работают проектные офисы (PMO)
Почему не работают проектные офисы (PMO)
 
Введение в управление проектами
Введение в управление проектамиВведение в управление проектами
Введение в управление проектами
 
Артемий Анцупов "Agile PMO"
Артемий Анцупов "Agile PMO"Артемий Анцупов "Agile PMO"
Артемий Анцупов "Agile PMO"
 
Павел Алферов, Интер РАО. Стратегия развития управления проектами в организации
Павел Алферов, Интер РАО. Стратегия развития управления проектами в организацииПавел Алферов, Интер РАО. Стратегия развития управления проектами в организации
Павел Алферов, Интер РАО. Стратегия развития управления проектами в организации
 
Дмитрий Маев. Внедрение проектного управления в инновационной девелоперской к...
Дмитрий Маев. Внедрение проектного управления в инновационной девелоперской к...Дмитрий Маев. Внедрение проектного управления в инновационной девелоперской к...
Дмитрий Маев. Внедрение проектного управления в инновационной девелоперской к...
 
Елена Копылова. Лёгкий контроль за сложными проектами. Как проектному офису о...
Елена Копылова. Лёгкий контроль за сложными проектами. Как проектному офису о...Елена Копылова. Лёгкий контроль за сложными проектами. Как проектному офису о...
Елена Копылова. Лёгкий контроль за сложными проектами. Как проектному офису о...
 
Мария Романова. Развитие проектного управления с переходом к портфельному и п...
Мария Романова. Развитие проектного управления с переходом к портфельному и п...Мария Романова. Развитие проектного управления с переходом к портфельному и п...
Мария Романова. Развитие проектного управления с переходом к портфельному и п...
 
Дмитрий Маев - Внедрение проектного управления в инновационной девелоперской ...
Дмитрий Маев - Внедрение проектного управления в инновационной девелоперской ...Дмитрий Маев - Внедрение проектного управления в инновационной девелоперской ...
Дмитрий Маев - Внедрение проектного управления в инновационной девелоперской ...
 
Евгения Дмитриева. Добились первых результатов, что дальше? Точки роста КСУП,...
Евгения Дмитриева. Добились первых результатов, что дальше? Точки роста КСУП,...Евгения Дмитриева. Добились первых результатов, что дальше? Точки роста КСУП,...
Евгения Дмитриева. Добились первых результатов, что дальше? Точки роста КСУП,...
 
Андрей Бадин. Проектные сервисы. Ускоренный метод внедрения проектного управл...
Андрей Бадин. Проектные сервисы. Ускоренный метод внедрения проектного управл...Андрей Бадин. Проектные сервисы. Ускоренный метод внедрения проектного управл...
Андрей Бадин. Проектные сервисы. Ускоренный метод внедрения проектного управл...
 
Основы управления проектами
Основы управления проектамиОсновы управления проектами
Основы управления проектами
 
Юрий Шойдин (Газпромнефть): Мастер-класс "Основы проектирования проекта"
Юрий Шойдин (Газпромнефть): Мастер-класс "Основы проектирования проекта"Юрий Шойдин (Газпромнефть): Мастер-класс "Основы проектирования проекта"
Юрий Шойдин (Газпромнефть): Мастер-класс "Основы проектирования проекта"
 

Similaire à Конспект учебного курса парадигмы и парадоксы проектнного менеджмента

образование гладкова
образование гладковаобразование гладкова
образование гладковаVera Kovaleva
 
Канвас "Думай как создатель": дизайн-мышление-трендвотчинг-прототипирование
Канвас "Думай как создатель": дизайн-мышление-трендвотчинг-прототипированиеКанвас "Думай как создатель": дизайн-мышление-трендвотчинг-прототипирование
Канвас "Думай как создатель": дизайн-мышление-трендвотчинг-прототипированиеLumiknows Consultancy
 
Гладкова образование
Гладкова образованиеГладкова образование
Гладкова образованиеVera Kovaleva
 
Андрей Вербицкий: Ошибки IT-аналитика
Андрей Вербицкий: Ошибки IT-аналитикаАндрей Вербицкий: Ошибки IT-аналитика
Андрей Вербицкий: Ошибки IT-аналитикаRaum7
 
будущее проектной методологии
будущее проектной методологиибудущее проектной методологии
будущее проектной методологииПавел Алферов
 
«Вот был бы еще день на дизайн...»
«Вот был бы еще день на дизайн...»«Вот был бы еще день на дизайн...»
«Вот был бы еще день на дизайн...»GRAPE
 
«Вот был бы еще день на дизайн...»
«Вот был бы еще день на дизайн...»«Вот был бы еще день на дизайн...»
«Вот был бы еще день на дизайн...»Alexander Stogov
 
марк коммуникации2
марк коммуникации2марк коммуникации2
марк коммуникации2Margarita Makzhanova
 
Ускоренное внедрение проектного управления в Оргкомитете Сочи 2014 или«как вс...
Ускоренное внедрение проектного управления в Оргкомитете Сочи 2014 или«как	вс...Ускоренное внедрение проектного управления в Оргкомитете Сочи 2014 или«как	вс...
Ускоренное внедрение проектного управления в Оргкомитете Сочи 2014 или«как вс...Проектные сервисы
 
Ускоренное внедрение проектного управления в Оргкомитете Сочи 2014 или как вс...
Ускоренное внедрение проектного управления в Оргкомитете Сочи 2014 или как вс...Ускоренное внедрение проектного управления в Оргкомитете Сочи 2014 или как вс...
Ускоренное внедрение проектного управления в Оргкомитете Сочи 2014 или как вс...Andrey Badin
 
Киев. Как внедрить SCRUM без трупов и остаться довольным
Киев. Как внедрить SCRUM без трупов и остаться довольнымКиев. Как внедрить SCRUM без трупов и остаться довольным
Киев. Как внедрить SCRUM без трупов и остаться довольнымVladimir Zavertaylov
 
Мастерство тотального факапа
Мастерство тотального факапа Мастерство тотального факапа
Мастерство тотального факапа Slava Tsyrulnik
 
CEE-SECR-2011. Презентация Александра Калугина
CEE-SECR-2011. Презентация Александра КалугинаCEE-SECR-2011. Презентация Александра Калугина
CEE-SECR-2011. Презентация Александра КалугинаAlexander Kalouguine
 
Useful meetup#1 design sprint
Useful meetup#1 design sprintUseful meetup#1 design sprint
Useful meetup#1 design sprintusefulagency
 
Разработка инноваций
Разработка инновацийРазработка инноваций
Разработка инновацийAnna Metsik
 
Проектный офис. культура управления проектами
Проектный офис. культура управления проектамиПроектный офис. культура управления проектами
Проектный офис. культура управления проектамиЕвгений Пикулев
 
Управление проектами, водопадная модель
Управление проектами, водопадная модельУправление проектами, водопадная модель
Управление проектами, водопадная модельOleg Vainberg
 
Software craftsmanship 11 online: мотивация и эффектисность разработчика
Software craftsmanship 11 online: мотивация и эффектисность разработчикаSoftware craftsmanship 11 online: мотивация и эффектисность разработчика
Software craftsmanship 11 online: мотивация и эффектисность разработчикаPavel Veinik
 

Similaire à Конспект учебного курса парадигмы и парадоксы проектнного менеджмента (20)

Agile
AgileAgile
Agile
 
образование гладкова
образование гладковаобразование гладкова
образование гладкова
 
Канвас "Думай как создатель": дизайн-мышление-трендвотчинг-прототипирование
Канвас "Думай как создатель": дизайн-мышление-трендвотчинг-прототипированиеКанвас "Думай как создатель": дизайн-мышление-трендвотчинг-прототипирование
Канвас "Думай как создатель": дизайн-мышление-трендвотчинг-прототипирование
 
Гладкова образование
Гладкова образованиеГладкова образование
Гладкова образование
 
Андрей Вербицкий: Ошибки IT-аналитика
Андрей Вербицкий: Ошибки IT-аналитикаАндрей Вербицкий: Ошибки IT-аналитика
Андрей Вербицкий: Ошибки IT-аналитика
 
будущее проектной методологии
будущее проектной методологиибудущее проектной методологии
будущее проектной методологии
 
«Вот был бы еще день на дизайн...»
«Вот был бы еще день на дизайн...»«Вот был бы еще день на дизайн...»
«Вот был бы еще день на дизайн...»
 
«Вот был бы еще день на дизайн...»
«Вот был бы еще день на дизайн...»«Вот был бы еще день на дизайн...»
«Вот был бы еще день на дизайн...»
 
марк коммуникации2
марк коммуникации2марк коммуникации2
марк коммуникации2
 
Ускоренное внедрение проектного управления в Оргкомитете Сочи 2014 или«как вс...
Ускоренное внедрение проектного управления в Оргкомитете Сочи 2014 или«как	вс...Ускоренное внедрение проектного управления в Оргкомитете Сочи 2014 или«как	вс...
Ускоренное внедрение проектного управления в Оргкомитете Сочи 2014 или«как вс...
 
Ускоренное внедрение проектного управления в Оргкомитете Сочи 2014 или как вс...
Ускоренное внедрение проектного управления в Оргкомитете Сочи 2014 или как вс...Ускоренное внедрение проектного управления в Оргкомитете Сочи 2014 или как вс...
Ускоренное внедрение проектного управления в Оргкомитете Сочи 2014 или как вс...
 
Киев. Как внедрить SCRUM без трупов и остаться довольным
Киев. Как внедрить SCRUM без трупов и остаться довольнымКиев. Как внедрить SCRUM без трупов и остаться довольным
Киев. Как внедрить SCRUM без трупов и остаться довольным
 
Мастерство тотального факапа
Мастерство тотального факапа Мастерство тотального факапа
Мастерство тотального факапа
 
1.1. семинар
1.1. семинар1.1. семинар
1.1. семинар
 
CEE-SECR-2011. Презентация Александра Калугина
CEE-SECR-2011. Презентация Александра КалугинаCEE-SECR-2011. Презентация Александра Калугина
CEE-SECR-2011. Презентация Александра Калугина
 
Useful meetup#1 design sprint
Useful meetup#1 design sprintUseful meetup#1 design sprint
Useful meetup#1 design sprint
 
Разработка инноваций
Разработка инновацийРазработка инноваций
Разработка инноваций
 
Проектный офис. культура управления проектами
Проектный офис. культура управления проектамиПроектный офис. культура управления проектами
Проектный офис. культура управления проектами
 
Управление проектами, водопадная модель
Управление проектами, водопадная модельУправление проектами, водопадная модель
Управление проектами, водопадная модель
 
Software craftsmanship 11 online: мотивация и эффектисность разработчика
Software craftsmanship 11 online: мотивация и эффектисность разработчикаSoftware craftsmanship 11 online: мотивация и эффектисность разработчика
Software craftsmanship 11 online: мотивация и эффектисность разработчика
 

Конспект учебного курса парадигмы и парадоксы проектнного менеджмента

  • 1. Управление проектами ПАРАДИГМЫ И ПАРАДОКСЫ ПРОЕКТНОГО МЕНЕДЖМЕНТА Конспект учебного курса Павел Шестопалов 30.12.2015 На основе материалов учебных курсов ГК «Проектная ПРАКТИКА»
  • 2. Оглавление ВВЕДЕНИЕ ...............................................................................................................................................2 МОДУЛЬ 1 Основная парадигма проектного менеджмента .............................................................3 МОДУЛЬ 2 Парадоксы жизненного цикла проекта ............................................................................7 МОДУЛЬ 3 Парадокс постановки цели проекта................................................................................11 МОДУЛЬ 4 Организационно – ролевая парадигма проекта............................................................16 МОДУЛЬ 5 О жизни в матрице............................................................................................................21 МОДУЛЬ 6 Парадоксы планирования................................................................................................27 МОДУЛЬ7 О рисках и шампанском для менеджера.........................................................................33 МОДУЛЬ 8 Парадоксы отслеживания и контроля проекта..............................................................38
  • 3. ВВЕДЕНИЕ Здравствуйте, друзья! Меня зовут Павел Шестопалов. Более 10 лет я занимаюсь вопросами эффективной реализации проектов и созданием систем управления проектной деятельностью. За это время удалось познакомиться с опытом многих успешных компаний и организаций. Именно поэтому сегодня мне хочется поговорить о дисциплине “Проектный менеджмент”. О дисциплине, которая в современном, быстро меняющемся мире, становится все более востребованной и актуальной. Не зря в атласе новых профессий, который недавно выпустило Агентство стратегических инициатив, Управление проектами является надпрофессиональным навыком, то есть навыком, который потребуется большинству специалистов будущего. Наш курс не будет похож на классические занятия по управлению проектами. Мы не будем изучать инструменты календарно - сетевого планирования или статистические методы работы с рисками. Здесь мы постараемся взглянуть на работу руководителя проекта в несколько необычном ракурсе. Я расскажу вам, как должен мыслить эффективный менеджер, чтобы довести проект до успешного завершения. Конечно, можно формально освоить большинство из инструментов и методов, которые описаны в международных стандартах и учебниках по проектному управлению. Но пока не поймешь почему они такие, пока не изменишь свой способ думать о проекте, сложно рассчитывать на успех. Мой опыт показывает, что эффективными руководителями проектов становятся не те, кто формально применяет все правила, предписанные стандартом или регламентом. Успеха добиваются те, кто научился думать и принимать важные решения на базе основных принципов проектного управления. Вне зависимости от того, чем каждый из нас занимается, у каждого в жизни очень много проектов. Давайте вместе учиться проектному мышлению!
  • 4. МОДУЛЬ 1 Основная парадигма проектного менеджмента Очень часто на курсах по управлению проектами приходится слышать такую фразу «Управление проектами – это наука здравого смысла» Действительно, управление проектами это не математика и не физика, здесь нет законов правил и теорем, которые работают всегда и везде. Но иногда опора на наш с вами здравый смысл играет с нами очень злую шутку. Потому что, как сказал Альберт Энштейн «Здравый смысл — это собрание предрассудков, приобретенных нами до восемнадцатилетнего возраста». И иногда стоит только нарушить этот здравый смысл получишь эффект, которого никто не ожидал. Правда потом этот самый нелогичный поступок тоже со временем превращается в стереотип, но такова философия. Это как в прыжках в высоту. До 1968 года прыгуны в высоту прыгали лицом к планке. Ну действительно, это казалось супер логичным. И вот в 1968 году Дик Фосбери начинает прыгать спиной вперед. Супер нелогично и контринтуитивно, но результат – Олимпийское золото! Давайте учится мыслить контринтуитивно, и самое главное, учить этому других. Я сейчас про Заказчиков, Руководителей организаций, Исполнителей, поставщиков и т.д.
  • 5. Давайте в самом начале нашего курса договоримся о терминах. Есть такое правило эффективных менеджеров, а тем более менеджеров проектов, - «О терминах не спорят, о них договариваются!». Под словом «проект» в рамках нашего курса я всегда буду иметь ввиду некую ДЕЯТЕЛЬНОСТЬ, у которой в отличие от всех остальных видов деятельности, есть ряд особенностей. Именно они дают нам право называть ее проектом. Итак, первое, проект - это всегда деятельность для кого-то и в интересах кого –то. И чаще всего, этот кто-то называется Заказчик. Поэтому, хочу дать совет начинающему руководителю проекта – не приступайте к проекту, пока лично не познакомитесь с заказчиком. Главный вопрос, который нужно ему задать еще на первом этапе: «А зачем это нужно?». То есть необходимо попробовать вместе сформулировать цель проекта. Сформулировать как можно понятнее вам обоим и, очень желательно зафиксировать ее в специальном документе. Ведь проект - это всегда деятельность по достижению цели. И эта цель не в вашей голове, а в голове Заказчика. Но тот же заказчик после договоренности о целях скажет о наличии ограничений. И, прежде всего, ограничений по срокам, ресурсам и затратам. И это вторая особенность деятельности, которую мы будем называть проектом. Еще одна отличительная черта проекта в том, что скорее всего такого никто раньше не делал, или не делал в таких условиях, или не делал такими силами. Другими словами, проект - это всегда что – то новое и уникальное. Но эта новизна и уникальность становится для руководителя проекта основной проблемой, имя которой – неопределенность и риски. Итак, проект это чаще всего деятельность, у которой есть цель, которая конечна во времени, ограничена ресурсами и затратами и это деятельность с существенным уровнем неопределенности и рисков.
  • 6. Но давайте попробуем сделать одно предположение. Раз это деятельность, то и управление ею может базироваться на классических подходах общего менеджмента. Давайте вспомним их. Если, например, я назначен новым директором конфетной фабрики, то первым делом я планирую деятельность по выпуску нового вида конфет. Дальше организую людей. Делаю необходимый запас ингредиентов, даю необходимые инструкции и выпускаю первую партию конфет. Следующий шаг – проверка. Проверка готовой продукции на соответствие требованиям, и даже если первая партия только наполовину залита шоколадом, я не переживаю, а, возвращаясь назад по конвейеру, ищу причину случившейся неудачи. Устраняю проблему в надежде, что следующая партия будет лучше. И так цикл повторяется многократно. У меня будет третья, десятая, сотая, тысячная партия и каждый раз я работаю по знаменитому управленческому циклу PDCA: Планируй, Исполняй, Контролируй, Корректируй. А каждая новая партия становится лучше, лучше и лучше, пока не достигну идеала. А теперь вопрос, как считаете это применимо для Проекта? Скорее всего, нет. Потому что в проекте даже второго шанса чаще всего не будет! Не можем мы через неделю после начала олимпиады сказать: «Ну что-то с первого раза не получилось, вторая олимпиада точно будет лучше!» А поэтому и мыслить Руководитель проекта должен иначе.
  • 7. Первая и основная парадигма проектного менеджмента вытекает именно из этой особенности проекта. Если руководитель операционного производства всегда оглядывается назад для устранения причин дефектов, то у руководителя проекта такой возможности чаще всего нет. Его взор всегда должен быть устремлен вперед. Проект от латинского Прожектус – заброшенный вперед. Но очень часто мы пытаемся в проекте действовать как на цикличном производстве. И очень много времени тратим в ходе совещания по проблеме на выяснение вопросов, кто виноват, почему так случилось и в чем причина отставания. 90 процентов времени совещания тратится на, так называемый «разбор полетов». В этом случае, мы смотрим назад, не осознавая, что управлять прошлым в проекте уже не в наших силах, и от того, что мы найдем крайнего ситуация совсем не улучшится. Из этого вытекает главная парадигма проектного управления: “Управлять в проекте можно только тем, что осталось, то есть только его будущей частью”. А отсюда два следствия: 1. Первое. Чем меньше времени осталось до окончания проекта, тем меньше возможностей у менеджера чем-либо вообще управлять. Как это не парадоксально, ближе к концу проекта менеджер перестает быть управленцем, а становится просто наблюдателем не имеющим, в большинстве случаев, возможности сколько-нибудь существенно повлиять на результаты проекта. 2. Второе следствие. Основные трудозатраты и усилия менеджера и его команды по управлению должны быть сосредоточены в самом начале проекта. В отличии от операционного управляющего - его трудозатраты равномерно распределены на протяжении всего времени выпуска тех самых конфет. Давайте подведем итог. Начиная проект вспомните основную парадигму проектного менеджмента и уделите в самом начале достаточно времени, трудозатрат и ваших усилий для того, чтобы разработать необходимое количество планов, договориться о взаимодействии, назначить людей, поработать с рисками. И, поверьте, это с лихвой окупится в ходе реализации проекта.
  • 8. МОДУЛЬ 2 Парадоксы жизненного цикла проекта В этом разделе мы с вами поговорим о парадоксе жизненного цикла проекта. Итак, Жизненный цикл проекта - это ключевое понятие в дисциплине проектный менеджмент. Оно, как ни странно, пришло к нам из уроков биологии. Но в приложении к проекту оно приобрело ряд особенностей. Как говорит мой любимый преподаватель по системной инженерии: «Самое важное, что мы должны запомнить про жизненный цикл, это две вещи: первое – он не жизненный! Второе он не цикл!» Действительно, в самом начале курса мы говорили о том, что проект - это ограниченная временем деятельность, т.е. после часа Х проект перестает существовать. И уж точно второго такого-же проекта не будет! Но идея разбить проект на фазы очень полезная. Большую, недостижимую, непонятную цель проекта нужно разбить на понятные управляемые этапы и определить порядок их прохождения. В этом и заключается ключевой управленческий смысл жизненного цикла. Этапов у проекта может быть разное количество. Все определяется потребностями управления конкретного менеджера или организации. Но чаще других, встречается управленческий жизненный цикл из четырех этапов. Давайте рассмотрим каждый из них. На первом этапе - он называется концепция - Заказчик и Руководитель проекта договариваются о целях, результатах и содержании проекта. Устанавливаются основные ограничения. Итогом этого этапа чаще всего является формальный документ - Устав проекта. На следующем этапе - организации и подготовки - Руководитель проекта собирает команду специалистов. Он организует работу по разработке необходимого количества планов: календарный план, финансовый план или бюджет проекта, ресурсный план, план поставок, план реагирования на риски и другие. В ходе этого этапа дается более точная оценка сроков и затрат, что кстати, часто приводит к пересмотру устава проекта. Для профессионального менеджера это нормальная допустимая процедура, но о ней нужно договориться с Заказчиком еще на этапе концепции. Формально этап
  • 9. организации и подготовки завершается утверждением планов проекта. Именно в этот момент они получают статус Базовых. Американский стандарт по управлению проектами PMBOK, например, предлагает фиксировать три базовых плана: Базовый план по содержанию, Базовое расписание и Базовый план выполнения стоимости. То есть по трем ключевым характеристикам проекта должно быть три согласованных между собой плана. Каждая работа по содержанию должна иметь даты начала и окончания в календарном плане, а также полный перечень ресурсов и затрат в плане финансовом. Следующий этап - реализация. Здесь выполняются все работы проекта, а полученные результаты - промежуточные и итоговые - передаются Заказчику. И последний этап - этап завершения. Он необходим для приемки результатов Заказчиком, подведению итогов проекта, извлечению уроков. И чаще всего, формальным итогом проекта является приказ о завершении. Или, что гораздо лучше, приказ – премия – банкет! Но! Основной парадокс жизненного цикла проекта заключается в том, что в его рамках цель Заказчика чаще всего не достигается. Чаще всего продукт проекта сам по себе Заказчику не нужен. А нужен результат работы или эксплуатации продукта. Например, если наш проект – это строительство конфетной фабрики, то цель Заказчика - получить прибыль от продажи конфет, а не сама фабрика как таковая. И чаще всего, именно в точке передачи продукта проекта, то есть передачи той самой фабрики в эксплуатацию, происходит много неприятностей для заказчика. Поэтому Он не рассматривает изолированно только жизненный цикл проекта. Заказчик всегда смотрит чуть дальше и соотносит как минимум жизненный цикл проекта и жизненный цикл продукта. Ведь у фабрики тоже есть свой жизненный цикл. Кто – то, когда – то ее задумал. И думал долго, а может даже нанял для этого думания целую консалтинговую компанию. Чаще всего этот этап называют Замысел или Инвестиционный замысел. Потом фабрика появляется на свет в виде чертежей, схем, документов, описаний, смет. И этот этап
  • 10. называют чаще всего проектирование. Дальше фабрика рождается в железе и бетоне. Возводится здание, монтируется техника, набирается персонал. Этап Изготовление или Реализация. Как только построили нужно предавать в эксплуатацию и выпускать конфеты. Но и наступит в конце концов момент, когда фабрику нужно будет закрыть, разобрать или сильно модернизировать, так что уже сложно ее будет назвать именно той фабрикой, которую задумали в самом начале. Этот этап вывод из эксплуатации или утилизация. И на этом большом, чаще всего многолетнем, жизненном цикле продукта необходимо определить место жизненного цикла проекта. Важно понять, в какой момент, в какой точке мы проект начинаем, а в какой точке руководитель проекта будет передавать заранее оговоренный результат. Ведь возможны варианты. Проект может начаться только после завершения этапа замысла. А может даже только после проектирования. То же самое можно сказать и о завершении. Все зависит от возможностей Руководителя и договоренностей с Заказчиком. Если вспомнить нашу фабрику, то я, например, как руководитель проекта предпочел бы начать свою работу, свой проект перед началом проектирования, а закончить точкой передачи фабрики в эксплуатацию. Правда, боюсь, большинство опытных Заказчиков с такими границами проекта не согласятся! Они попробуют растянуть границы моего проекта, то есть моей ответственности до момента, когда точно будут уверены в том, что фабрика устойчиво работает и приносит прибыль. Но одно неоспоримо – грамотный руководитель проекта всегда договаривается и точно знает, где на жизненном цикле продукта начинается и где заканчивается его зона ответственности. Т.е. определяются так называемые границы проекта, для конкретного руководителя. Но для Заказчика, чаще всего, с окончанием одного проекта деятельность по достижению целей не закачивается. Для этого может потребоваться еще некоторое время эксплуатации, а возможно и еще несколько проектов.
  • 11. Особенно, это ярко видно, если рассмотреть инвестиционную деятельность, для которой основной выгодой является получение финансового результата. Для того, чтобы управлять всем комплексом действий по достижению этой стратегической цели чаще всего все мероприятия объединяют в Программу проектов. А Руководитель программы отвечает за получение итоговых выход и эффектов. Программа и Проект очень похожи по сути. И до сих пор многие компании спорят, чем же отличается большой проект от небольшой программы. Основное отличие в масштабах мероприятия и в способе управления. Проект, чаще всего краткосрочное, обычно до года, мероприятие с четко описанными целями и содержанием, а также с установленными ограничениями по срокам и затратам. Основная задача руководителя проекта минимизировать возможные отклонения по срокам, содержанию и затратам. Программа - это мероприятие со стратегическим замыслом на несколько лет. Руководитель программы не минимизирует отклонения, а наоборот, сознательно их вносит и использует для максимизации основных выгод программы. Но для руководителя отдельного проекта всегда важно и полезно представлять всю картину происходящего, и самое главное знать ту большую, стратегическую цель Заказчика, ради которой он и тратит бюджет. Даже если программа формально не определена есть смысл поговорить с Заказчиком на тему его ключевых стратегических целей. Давайте подведем итоги: Начиная проект договоритесь с Заказчиком о его границах. Удобнее всего отметить эти границы на жизненном цикле продукта. По сути, это договоренность о зоне ответственности руководителя проекта. Именно она во многом определит его содержание. Второе. После определения границ, внутри проекта выделите несколько этапов. Для каждого этапа определите условия завершения и условия перехода к следующему этапу. Это сделает ваш проект более управляемым и снимет существенное количество рисков. Чаще всего достаточно будет воспользоваться стандартным набором из 4-х этапов: Концепция, Организация и подготовка, Реализация и Завершение.
  • 12. МОДУЛЬ 3 Парадокс постановки цели проекта Друзья! В данном разделе мы поговорим о парадоксах постановки целей проекта. Самые крупные неудачи проектов в мире связывают с ошибками процесса целеполагания. Давайте разбираться подробнее в том, как правильно думать, рассуждать и фиксировать цели проекта. Конечно, первое, что приходит в голову, когда вспоминаешь о целях - это принцип SMART, предложенный Питером Друккером еще в 1954 году. SMART – это пять букв, означающие, что хорошо сформулированная цель должна быть четкой и специфичной - это S, измеримой - это M, достижимой -это A, должна соответствовать или быть релевантна целям более высокого уровня - это R, и должна иметь временное ограничение по ее достижению - это T. И действительно, чтобы исключить неопределенность в понимании целей всеми участниками проекта важно, чтобы она была ясной, четкой и конкретной. А это, в свою очередь, означает, что в формулировке должен присутствовать основной способ достижения этой цели. Поэтому при формулировке вполне уместны слова «за счет», или «путем», или «с помощью» и.т.д. Например, «Увеличение уровня добычи месторождения за счет создания и оптимизации системы поддержания пластового давления». Цель обязательно должна быть определена в цифрах. На каком бы языке мы бы не говорили, но самые понятные слова на земле по-прежнему – цифры. Каждая цель проекта должна быть декомпозирована на один или несколько показателей с указанием их целевых значений. В некоторых международных стандартах такие показатели называют результатами или индикаторами достижения целей. Конечно, когда видишь целевые показатели сразу возникает вопрос, а когда они будут достигнуты. Поэтому грамотно поставленная цель должна содержать временные ограничения по ее достижению. Далее, цель должна быть релевантна. С позиции руководителя проекта я бы сказал, что цель должна соответствовать чему-либо: целям более высокого уровня, стратегической цели Заказчика, стратегии организации в целом или миссии компании, в конце концов.
  • 13. Важно также, чтобы менеджер проекта с Заказчиком, как минимум, верили, что с учетом наших ограничений данная цель достижима. И достижима в установленные сроки. Для того, чтобы соблюсти все условия принципа SMART для проекта, конечно, одной формулировки цели явно недостаточно. Все выверенные предложения чаще всего вносят в документ под названием Устав проекта. Встречаются и другие названия: Паспорт проекта, Проектная декларация, Концепция проекта, Резюме проекта. Формы тоже встречаются разные. В настоящее время очень популярным стало делать Устав проекта в виде презентации. В некоторых компаниях это корпоративный стандарт. Что обычно включает в себя Устав проекта. Ответ простой: все то, что сделает нашу цель, как минимум, соответствующей принципу SMART. Поэтому чаще всего первым в Уставе следует раздел Стратегические цели или обоснование проекта. Здесь дается описание текущей ситуации, чаще всего, в терминах бизнеса. Наиболее часто в этом разделе описывают либо существующую бизнес - проблему, которая требует решения. Либо дается описание потенциальной бизнес - возможности, которую хотим использовать. Этот раздел отвечает на вопрос «Почему или для чего мы начинаем проект?», этим самым мы снижаем риск постановки нерелевантных целей, то есть соответствующих критерию Р по Друкеру. Дальше следует непосредственно формулировка цели, как я уже говорил, очень желательно с указанием ключевого способа ее достижения! Например, «снижение производственных потерь за счет внедрение системы менеджмента качества на основе технологий 5С» или «Обеспечение условий для территориального развития путем открытия филиальной сети». Так мы сделаем цель соответствующей букве S из SMART- принципа. Сделаем ее ясной, конкретной, специфичной. Но самое главное цель проекта должна отвечать на вопрос «Зачем?». Поэтому я очень не люблю цели начинающиеся со слов «Создание» или «Внедрение» или «Строительство»…. Если вы прочитали сформулированную цель в Уставе и вам хочется задать вопрос «А зачем?», значит, что – то не так в этой формулировке. Обязательно идите к Заказчику и уточняйте. Например, если цель звучит как “Создать центр обслуживания абонентов для улучшения качества обслуживания клиентов сети”, то руководитель проекта посчитает
  • 14. скорее всего, что цель будет достигнута в момент, когда создан тот самый центр обслуживания. Но ведь совсем не этого хочет Заказчик. Правильнее было бы сформулировать эту цель так: “Повышение качества обслуживания клиентов сети за счет создания центра обслуживания абонентов” Согласитесь, совсем другая цель. И теперь Руководитель проекта будет отвечать прежде всего за то, что создаваемый им центр действительно улучшит качество обслуживания, а не просто за то, что он есть! Основной раздел, за который бьется Руководитель проекта – критерии успеха. Это некий чек – лист показателей (как качественных, так и количественных), который всплывет на этапе завершения проекта. Формально, именно он станет основным при определении успешности проекта. Поэтому руководитель проекта особенно тщательно должен подойти к согласованию данного раздела. По Друкеру это буква M, которая обозначает возможность измерения. В примере с созданием центра обслуживания абонентов такими критериями достижения цели могут, например, максимальное время ожидания ответа оператора, количество жалоб на некачественное обслуживание, уровень удовлетворенности клиента по заранее оговоренной шкале и т.д. Ну и конечно, нельзя забывать о критериях “в срок” и без превышения бюджета. Ну и раздел, который, наконец – то, ответит на вопрос «Что все – таки строим?» Это раздел Устава под названием - продукт проекта. Кстати, именно высокоуровневое описание продукта проекта в большинстве случаев даст ответ на вопрос, а сможем или нет, достижима цель или нет? Буква А в смарте. Осталась не охваченной только буква T, которая означает наличие установленных ограничений по времени. Для этого в Уставе используют специальный раздел. Он так и называется Ограничения, куда записывают все существующие ограничения по срокам, затратам, привлечению ресурсов и прочее. Например, для многих проектов вводится ограничение “своими силами”, т.е. проект должен быть реализован без привлечения внешних поставщиков и подрядчиков. Но еще один очень важный раздел, о котором ни в коем случае не должен забыть Руководитель проекта, это список так называемых допущений или предположений. В этом разделе описываются факторы, на которые руководитель проекта повлиять не может, но они могут оказать существенное воздействие на показатели проекта. Т.е. это некие условия, при которых цель проекта будет достижима. По сути это описание стратегических рисков проекта.
  • 15. Больше всего трудностей на практике вызывает заполнение разделов Цель и Продукт проекта. Поэтому остановлюсь на них отдельно. К сожалению, очень часто в этих разделах встречается одно и то же описание. Цель – построить фабрику по производству стеновых панелей. Продукт – фабрика по производству стеновых панелей. Давайте попробуем разобраться, почему такая формулировка содержит в себе много рисков, прежде всего для Руководителя проекта. Для этого я предлагаю вам совсем немного погрузиться в основы дисциплины системная – инженерия. Системный инженер - это человек, способный организовать создание сложной технической системы: ракеты, самолета, буровой платформы. Поэтому в его голове мыслительный процесс целиком и полностью основан на понятии система. Но он, в отличие от, казалось бы, логичного взгляда на описание системы как совокупности некоторых элементов, в первую очередь смотрит не внутрь её, а наружу. Например, если рассмотреть обычный маркер как систему, то, наверное, большинство из вас, да и я сам начнут, описание со слов: Маркер - это совокупность элементов, состоящая из корпуса, стержня, чернил, колпачка и т.д. Но с точки зрения системного инженера - это прибор, который оставляет синий след на бумаге толщиной не менее 3 миллиметров, длиной не менее 15 миллиметров, не допускающий пролива чернил на рубашку пользователя.
  • 16. Т.е. любую систему можно описать как с точки зрения ее Функции, так и с точки зрения ее Конструкции. А между этими описаниями всегда есть место архитектуре, т.е. Описанию того как элементы конструкции во взаимодействии будут обеспечивать функцию. Так вот ключевой парадокс целеполагания в проекте состоит в том, что Заказчик всегда желает получить именно функцию. А руководитель проекта настоятельно пытается сдать ему конструкцию. Но даже если он, руководитель проекта, в уставе убедит заказчика написать в цели: «Построить фабрику по производству стеновых панелей», то Заказчик предпримет все усилия, чтобы фабрику не принять, пока она не выйдет на производственную мощность, т.е. не станет обеспечивать свою функцию. В таком случае, совет один. Руководители проекта должен думайте о проекте от лица Заказчика. В уставе проекта в разделе Цели описывайте функцию, и дальнейшее планирование проекта осуществляйте исходя из необходимости обеспечить эту самую цель. Конечно, практически во всех стандартах по управлению проектами разработка Устава – это функция Заказчика. Но в наших условиях, чаще всего этим занимается Руководитель проекта. Поэтому, когда будете писать очередной устав, вспомните картинку из системной инженерии, и по-новому пересмотрите ограничения проекта. Функция – всегда дороже, но именно ее выжмет из вас Заказчик. И не забудьте проверить записанные вами цели на предмет соответствия принципу SMART.
  • 17. МОДУЛЬ 4 Организационно – ролевая парадигма проекта Друзья, мы с вами продолжаем обсуждать парадигмы проектного менеджмента. У самого понятия менеджмент или менеджер есть очень много определений, но совершенно точно, что их всех объединяет одна мысль: Менеджмент - это про то, как грамотно расставить людей и организовать их на совместное эффективное взаимодействие. И это совершенно точно про людей. Ведь глупо звучит фраза, например, менеджмент станка с числовым программным управлением или менеджмент автомобиля. Поэтому, хоть прямой перевод слова менеджмент — это управление, но менеджер – всегда управляет людьми. Поэтому тема этого раздела: Организационно – ролевая парадигма проекта. Именно она позволит вам правильно организовать взаимодействие сотрудников в проекте. Вообще людей вокруг проекта довольно много. Очень часто всех, кто так или иначе участвует или заинтересован в проекте называют участники проекта. Но это не совсем корректно. Мне больше нравится термин стейкхолдеры. Дословно стейкхолдер переводится как держатель части, держатель интереса или заинтересованная сторона. К стейкхолдерам относятся не только непосредственные участники проекта, такие как Заказчик, Руководитель проекта, Команда, но и те лица и организации, чьи интересы могут быть затронуты в ходе проекта. Либо, наоборот, у этих лиц и организаций есть свой интерес в проекте, о котором чаще всего и менеджер не подозревает. Например, довольно часто к стейкхолдерам проекта относят органы власти, общественные организации и даже конкурентов. Но мы сегодня поговорим об основных стейкхолдерах, т.е. тех лицах, которые принимают непосредственное участие в проекте. И хотя все они в проекте заинтересованы – а это факт, ключевой парадокс состоит в том, что интересы этих стейкхолдеров совершенно разные, а иногда и прямо противоречащие друг другу. Давайте разбираться во всем этом подробно. Например, в голове очень активного бизнесмена возникла идея: выиграть гран – при в Формуле-1, и он инициирует проект
  • 18. по созданию нового супер – болида. В этом проекте он будет выполнять роль Заказчика. Основная цель проекта - это победа, как минимум на одном этапе гонки, а как максимум - в сезоне. Если у этого бизнесмена будет недостаточно средств на проект, он будет вынужден обратиться к Инвестору. В этот момент появляется еще один стейкхолдер. Инвестор, конечно, тоже заинтересован в проекте, но у него другая Цель. Он говорит нашему бизнесмену: «Денег дам, но скажи, как будешь возвращать? За победу, насколько я знаю столько не дают, сколько ты у меня просишь» Бизнесмен, конечно рассказывает о том, сколько рекламных контрактов он сможет заключить и сколько просмотров обеспечит трансляции болида с логотипами рекламодателей. Инвестор соглашается, но может потребовать увеличения рекламного пространства на болиде и времени проезда под телекамерами, а еще минимизации затрат на создание самого болида. У инвестора совсем другие цели, он хочет вернуть свои деньги с прибылью. А это сильно противоречит интересам Заказчика. В этот момент появляется еще один важный участник событий. Это пилот, без которого победы не будет. Он будет эксплуатировать продукт проекта для достижения цели Заказчика. И он предъявляет свои требования к проекту, а точнее к продукту проекта к болиду. Выше динамика, комфорт и удобство управления, климат-контролю последнего поколения и т.д. Что во многом противоречит интересам и Инвестора, и Заказчика. Коллеги, ситуация почти вымышленная, но, к сожалению, очень часто встречающаяся в реальных проектах, многие из вас, наверное, узнали себя в этой ситуации. Парадокс основных стейкхолдеров проекта, я имею в виду Заказчика, Инвестора, Пользователя (или иногда его называют функциональным заказчиком) и Руководителя проекта состоит в том, что изначально все эти участники находятся в состоянии конфликта интересов. И конечно, пострадает от этого конфликта больше всего конечно Руководитель проекта. Встает вопрос - Что делать, когда возникает такой конфликт интересов разных стейкхолдеров? Первое: знать и понимать, что такой конфликт существует! Для
  • 19. подавляющего большинства проектов существуют свои Заказчики, Инвесторы и Функциональные заказчики. Даже если они так не называются они есть, поверьте. В связи с чем второе действие: четко персонифицировать все роли в проекте, и не только для себя, но и для всех участников. Т.е. договориться о том, кто какую роль на себя берет, и закрепить это на бумаге. Ключевые роли, чаще всего фиксируются в Паспорте или Уставе проекта. Фиксируются, это значит напротив каждой роли написана Фамилия, имя и отчество, а так же перечень полномочий и ответственности. Ну и третье, и самое важное. Чтобы не быть жертвой этого самого конфликта интересов, грамотный руководитель проекта всегда договаривается о том, кто будет самым главным его начальником, с кем он будет обсуждать стратегические вопросы проекта, у кого он будет просить ресурсы, и с кем будет взаимодействовать по всем ключевым моментам. Чаще всего этого человека называют Куратор проекта, в западных стандартах используют термин Спонсор. Это может быть специально назначенный человек, а может кто – то из перечисленных уже стейкхолдеров взять на себя эту роль. Обычно, Куратор — это человек высокого уровня полномочий и власти с одной стороны, и заинтересованный в стратегическом успехе проекта, с другой стороны. Все шаги, которые я перечислил, а также сам процесс формирования организационно – ролевой структуры проекта, называется организационное планирование. И этот процесс очень важен. Потому что проект требует новых видов коммуникаций и каналов взаимодействия. По сути мы должны создать маленькую мини организацию для конкретно взятого проекта в которой будут свои начальники и подчиненные, свои отделы и департаменты, свое распределение полномочий и обязанностей. И как в любой организации в такой структуре нужно выделить блок руководства и основной исполнительский блок. Поэтому в проекте обычно выделяют две команды: команду управления проектом и непосредственно команду проекта. Давайте разберемся, как они формируются. Чаще всего в команду управления входят самый главный технарь в проекте, который лучше всех разбирается в предметной области. В разных отраслях его по-разному называют: главный инженер проекта, генеральный конструктор, режиссёр, системный инженер, системный архитектор, технический руководитель проекта. Для небольших проектов эту роль берет на себя сам Руководитель. Отдельно в команду управления назначают экспертов, ответственных за различные направления: финансиста, экономиста, маркетолога, специалиста по набору персонала и пр. Плюс, для больших проектов, в команду управления назначают представителей поставщиков и подрядчиков, вовлеченных в проект. Основное правило формирование команды управления – пофамильное назначение сотрудников на ту или иную роль. Конечно допускается совмещение ролей, но это тоже должно быть зафиксировано. Таким образом формируется команда управления проектом. В некоторых организациях ее называют рабочая группа. Она собирается на регулярной основе, осуществляет планирование проекта и совместно решает все возникающие трудности и проблемы в ходе реализации.
  • 20. Все остальные участники проекта, исполнители поставщики, подрядчики, образуют одну большую команду проекта. Основная задача этих участников выполнить запланированные работы и своевременно отчитаться о результатах выполнения. Очень часто, для более конкретного распределения ролей и ответственности в проекте формируется документ Матрица ответственности. По вертикали перечисляют работы или функциональные области проекта, по горизонтали - список участников, чаще всего из команды управления проектом. На пресечении расставляются буквы, соответствующие некой легенде. О – ответственный, И – исполнитель, С – согласует, К – например, консультирует и т.д. Буквы могут быть разные, но две из них в любом случае должны быть. По каждой работе должен быть назначен Ответственный, и только один Ответственный. По каждой работе должен быть как минимум один Исполнитель.
  • 21. Посмотрите после этого модуля на представленный фрагмент матрицы ответственности и попробуйте найти в ней методические ошибки и неточности. А мы подводим итоги. В любом проекте существует конфликт интересов его основных участников. Для его минимизации грамотный Руководитель проекта формирует организационно – ролевую структуру и распределяет между участниками роли и ответственность. Очень важной ролью в проекте является роль Куратора или Спонсора. Не начинайте проект пока не познакомились с Куратором и не убедились, что он понимает свою роль. Все роли в проекте должны быть закреплены за конкретными людьми со своими Фамилией, именем и отчеством. Это как в театре. В программке спектакля всегда напротив роли подчеркнута фамилия актера, который сегодня ее играет. Так и в проекте я могу занимать вполне определенную должность в штатной структуре организации, но мои роли в проектах могут быть совершенно разными.
  • 22. МОДУЛЬ 5 О жизни в матрице Друзья, в этом разделе мы с вами обсудим, как выделить людей в команду проекта, если они работают в рамках организационно – штатной структуры компании. Вопрос, как организовать людей в структуру, соответствующую потребностям проекта часто вызывает много споров и разногласий. И вот почему. Штатное расписание любой компании складывается, обычно, довольно долго. Формируются отделы, подразделения, департаменты. Между людьми распределяются обязанности, пишутся должностные инструкции. И все это ориентировано на выполнение основных задач организации. Для большинства компаний эти задачи операционные, циклично- повторяющиеся. Но для проекта, в подавляющем большинстве случаев, требуется участие нескольких сотрудников из разных отделов, служб и подразделений. Т.е. организационная структура проекта чаще всего не соответствует штатному расписанию компании. И это серьезная проблема. Основной организационный парадокс проектного управления состоит в том, что большинство компаний и организаций, с точки зрения штатной структуры, не приспособлены для эффективной реализации проектов. Где же выход из такой ситуации? Предлагаю обратится за советом к международным стандартам по проектному менеджменту. А стандарты предлагают нам несколько вариантов, или, я бы сказал, - подходов к формированию команды проекта. Это функциональный подход, проектный подход и матричный подход. Ну и, конечно, возможна комбинация этих трех способов. Давайте попробуем понять достоинства и недостатки каждого из них. Подход функциональный. Как известно, многие из руководителей организаций могут совершенно небезосновательно заявить: «Мы не готовы ломать сложившуюся вертикаль власти. И в проектах будем работать в соответствии с утвержденной функциональной структурой!» Правомерно? Почему бы и нет. Действительно, если требуется выполнить небольшой проект. Например, организовать участие компании в международной выставке. То, в соответствии с функциональной структурой назначаем
  • 23. руководителем проекта - главного маркетолога. Он, в свою очередь, вовлекает в команду проекта своих подчиненных, перераспределяя между ними обязанности с учетом новой задачи. И все бы хорошо и здорово, но мы забыли о том, что скорее всего наступит момент, когда маркетологу потребуется, пусть на короткое время, но сотрудник другого отдела. Юрист, например. В этом случае наш назначенный руководитель проекта приходит к начальнику юридического отдела и требует в срочном порядке, выставку никто не перенесет, выделить ему юриста для согласования договора с организаторами. Начальник Юридического отдела спокойно говорит: “А у меня регламент, складывай свой проект договора в папку входящие, через 5 дней (по регламенту) согласуем”. И вот тут возникает конфликт. Который чаще всего выходит на уровень вышестоящего руководителя. Там, он конечно разрешается, но потрачено много времени и, как ни парадоксально, денег. Ведь в разрешении этого мелкого вопроса поучаствовали дорогостоящие руководители высокого уровня. И это типичная проблема функционального подхода. Когда два сотрудника из разных отделов не могут между собой договориться, то в этот процесс вовлекаются их начальники отделов, плюс два начальника департаментов, плюс генеральный директор, ну или заместитель. Наверное, каждый из вас не раз принимал участие в таком совещании. Можно в таком режиме работать - спросите вы? Да, в принципе, можно. Но это с точки зрения проекта - это долго, а с точки зрения организации еще и дорого.
  • 24. Где выход? Его может предложить генеральный директор, когда ему надоест заниматься микроменеджментом и вникать в суть всех мелких конфликтов своих подопечных. Он может издать приказ следующего толка: Начальнику маркетингового отдела, переложить свои обязанности на заместителя и подать список сотрудников необходимых для проведения выставки. Начальникам отделов выделить на время проекта сотрудников руководителю проекта, а их текущую нагрузку перераспределить между оставшимися сотрудниками. Т.е. для проекта формируется временное подразделение с нужным числом специалистов, которые исключаются из основного процесса. Такой подход называется проектный. Подавляющее большинство конфликтов функционального подхода снимается. Все решается очень быстро. НО. Теперь страдает сама организация - это, во-первых, а сотрудники, выделенные в команду проекта, не загружены на 100%. Юрист быстро согласовал свой документ и в лучшем случае ничего не делает. В худшем руководитель проекта назначает его на другие задачи, например, разгрузку оборудования для стенда на выставке. А платим мы ему как юристу… В итоге, проектный подход к формированию команды позволяет существенно выиграть в сроках, но это очень дорого. Да и проект не один выполняется в организации. Под каждый проект не напасешься юристов. Однако, для больших, приоритетных проектов такой вариант единственно возможен.
  • 25. Где же золотая середина. И специалисты по проектному управлению нашли ее. Это матричная структура. Приказом по организации в команды руководителя проекта назначаются сотрудники из разных отделов. И этим же приказом ему делегируются полномочия ставить им задачи и требовать их выполнения. Но передаются эти сотрудники не на все время проекта, а только на время необходимое для выполнения конкретных задач. И никто не снимает с них задач по основной работе. В принципе все выглядит на первый взгляд логично и стройно. Руководитель проекта ставит задачи по проекту. Начальник отдела не теряет сотрудника. Страдает, к сожалению, в этом случае сам сотрудник. У него появляется два начальника, которые одновременно требуют с него выполнения своих задач. Возникает конфликт интересов. У которого даже есть свое название. Матричный конфликт или порок матрицы. Ни одной компании в мире не удалось на 100% преодолеть или разрешить матричный конфликт. Но многие научились его довольно хорошо сглаживать или минимизировать. Основной причиной такого конфликта является то, что в борьбе за ресурс сталкиваются две структуры: штатная структура компании и организационная структура проекта. Но матричная структура, с точки зрения компании в целом, - самый эффективный способ реализовать проекты без существенного ущерба для основного производственного процесса. Когда же матричная структура будет хорошо работать? Есть несколько условий, которые требуется выполнить руководству компании для построения эффективной матрицы. Первое, и, наверное, самое главное. Желание и воля первого лица организации. Во всех своих выступлениях, на всех совещаниях он должен прежде всего сам следовать этим принципам и требовать их выполнения от своих подчиненных. Вплоть до ситуации, когда он может быть назначен в какую-либо из команд проекта и так же как все будет выполнять указания руководителя этого проекта. Это сложно, но без такой
  • 26. внутренней корпоративной проектноориентированной культуры, скорее всего, матрица не заработает. Второе условие. Необходимо убедить функциональных руководителей в нормальности ситуации, когда их сотрудники начинают выполнять задачи по проектам для других менеджеров. И что самое сложное, научить начальников отделов не препятствовать, а наоборот всячески содействовать такой работе своих подчиненных. Такие руководители должны четко осознать свою роль в проектах, эта роль называется «менеджер ресурсов». Менеджер ресурсов не выполняет работу самостоятельно, а отвечает за своевременное выделение в проект квалифицированных специалистов, а также отвечает за качество их работы в проекте. Третье условие, которое нужно соблюдать - загрузку сотрудников по проектам нужно как можно раньше определять и согласовывать с функциональными руководителями. Здесь для руководителей проектов очень важны навыки ресурсного планирования. И самое главное, сотрудники, вовлекаемые в проекты не должны чувствовать в этом никакой угрозы для себя. Они должны нормально воспринимать нескольких руководителей, понимая, что те, прежде чем поставить задачи, договорились как будут использовать один и тот же ресурс. Дополнительно способствует эффективной работе в матричной структуре - системы финансового стимулирования за участие в проектах. Причем как самих сотрудников, так и их функциональных руководителей. Иногда, хорошо помогает выделение руководителей проектов в отдельное подразделение. Потому что многим сотрудникам порой сложно смириться с фактом, что назначенный руководитель проекта - это такой же рядовой специалист из соседнего отдела. И еще одним способствующим фактором является применение единого центра коммуникаций по проекту. Людям из разных отделов нужно просто помочь научиться общаться по проекту между собой. Вплоть до того, что собираться командой проекта по пятницам - просто для обмена информацией о том, кто чем занимался в это время. Все эти условия очень сложно одновременно соблюдать и выполнять.
  • 27. Давайте подведем итоги: Функциональная структура чаще всего является самой неэффективной для формирования команд проекта. Для больших сложных проектов самым подходящим является проектный подход, когда люди выделяются в проект на 100% своей загрузки. Во всех остальных случаях наиболее эффективным способом организации является матричный подход. Он связан с рядом проблем, возникающих из-за матричного конфликта. Но научиться работать в матричной структуре можно. И это, порой, открывает много возможностей как для организации, так и для самих сотрудников выйти за рамки каждодневной процессной рутины своего отдела. А может даже возглавить сложный интересный проект. Проектная карьерная лестница гораздо короче. Вчера администратор проекта, завтра руководитель, а в перспективе куратор, а это как минимум уровень ТОП минус один.
  • 28. МОДУЛЬ 6 Парадоксы планирования Друзья, в этом разделе я предлагаю обсудить одну из самых важных тем в проектном менеджменте - планирование. Мы все, так или иначе, сталкивались с задачами планирования. Сами писали планы, подчиненных обязывали, начальники нам давали поручения создать план. Но, за этой будничностью задачи порою мы забываем ответить на один вопрос. А зачем мы планируем? Ведь все равно все пойдет не по плану, говорят многие менеджеры. Кстати, во многом они правы. В этом и заключается основной парадокс планирования. Планы меняются, но без планов не обойтись. Много великих людей подтверждают эту мысль. Великий немецкий полководец Гельмут Фон Мольтке говорил, что ни один план не выдерживает столкновения с противником. Поэтому план ничто, но планирование все! Эту же мысль повторил и дополнил в свое время генерал Эйзенхаурер. Любой план – ничто, так как устаревает в тот момент, когда вы закончили его составлять. Но планирование – это всё, так как обеспечивает единое понимание целей и способов их достижения, что позволяет вашим подчинённым действовать самостоятельно. И мне очень импонирует высказывание Генри Киссенжера. Он говорил, что выработка планов — напрасная трата времени, если это не поручено тем, кто будет их исполнять. Это высказывание я бы отнес к основным парадигмам проектного менеджмента. Совершенно точно, что план должна разрабатывать команда проекта под руководством его менеджера. Так какой же план они должны сделать? Какой план будет полезен, прежде всего в ходе реализации проекта. Задавая многим руководителям проектов вопрос: “Зачем нужен план?” - я получал практически всегда одни и те же ответы. И вот какие:  Ничего не забыть! Определить полный состав работ  Зафиксировать точки получения важных результатов в проекте  Определить последовательность действий по получению результатов  Оценить: Сроки, Ресурсы и Затраты
  • 29.  Для анализа и учета рисковых ситуаций  Для поиска оптимального пути достижения цели  Для координации, отслеживания и контроля в ходе реализации И самое главное, о чем очень часто забывают. План нужен для ПРОГНОЗИРОВАНИЯ и своевременного (проактивного) принятия решений по корректировке оставшейся части плана. А вот для того, чтобы ответить на вопрос “Что именно планируем?” руководителям проектов на помощь приходит, так называемый, магический треугольник проектного управления. Его вершины - это цели и содержание, затраты, а также сроки. Конечно, все ограничения нашего проекта должны быть сбалансированы и представлены в виде соответствующих планов.
  • 30. В первую очередь, нам нужен план по содержанию. То есть полное описание того, что мы будем делать в проекте, описание ключевых его результатов. Нам нужен календарный план, который даст ответ на вопрос: “а когда эти самые результаты мы получим?”. И конечно, нам потребуется ответ на вопрос, какими силами мы сделаем это и сколько потребуется денег для реализации проекта. Обратите внимание, что первично все – таки содержание. А уже вторым шагом определяем потребности в сроках и затратах. Именно такая последовательность даст нам самый реалистичный план. Конечно, при недостатке средств или сжатых сроках, возможно, мы с Заказчиком скорректируем содержание, но это шаг номер два. Парадоксальное правило профессионального руководителя проекта звучит следующим образом: «Начиная планирование не думай о сроках, не думай о деньгах! Определи сколько надо денег и времени для достижения цели, и только потом обсуди с Заказчиком возможные изменения в содержании, сроках или затратах”. Итак, рассмотрим каждый из шагов подробнее. Планирование содержания! Основным инструментом в планировании содержания является построение, так называемой, структурной декомпозиции работ. Т.е. все работы по проекту мы детализируем до уровня, когда станут понятны исполнители, длительности отдельных задач и необходимые ресурсы. Причем не нужно для каждого конкретного элемента добиваться идеальной точности. Сама декомпозиция увеличивает точность планирования всего проекта. Вспомните задачку по теории вероятностей для первого курса. Если требуется проложить сто километров железнодорожного полотна, а станок по производству рельс выпускает километровые отрезки с точностью плюс минус 10%, то какова будет погрешность всего пути. Как ни парадоксально, точность всего пути будет плюс минус 1%. Т.е. в корень из N раз точнее каждого отрезка. Загляните на досуге в учебник по «Терверу», это действительно так. Для нас с вами это означает, что если в структурной
  • 31. декомпозиции работ будет сотня элементов нижнего уровня, то в оценках каждой работы мы можем ошибиться достаточно сильно, например, в полтора два раза, т.е. на 50 – 100%. Но при этом общий результат по проекту, например, в финансовом выражении, будет иметь погрешность всего 10%. Но здесь нужно соблюсти одно условие. Все элементы декомпозиции должны быть примерно одинаковы как по длительности, так и по затратам. Суммируя снизу-вверх получим довольно точные оценки по объему ресурсов и затратам. Но длительности задач, т.е. планирование сроков, так складывать неправильно. Потому, что многие из задач будут выполняться параллельно. Здесь на помощь приходят методы календарно-сетевого планирования. Все задачи нужно выстроить в одну определенную технологическую последовательность. После чего рассчитать возможные даты начала и окончания каждой из них. И, главное, только после расчета мы поймем, какие именно задачи будут напрямую влиять на общий срок проекта. Именно они называются критическими. Срыв сроков критической задачи влечет за собой срыв сроков проекта. Обычно такие задачи в системах календарного планирования и контроля обозначаются красным цветом. И в этом еще один парадокс проектного менеджмента. Для соблюдения требований по срокам, совсем не обязательно все без исключения задачи завершать в соответствии с планом. Важно следить за тем, чтобы вовремя завершались только критические задачи. И еще один важный для практики результат мы получим, если установим взаимосвязи между задачами. В ходе реализации проекта мы сможем получать прогноз выполнения по срокам. Т.е. своевременно, на основе фактического времени исполнения критических задач сможем дать ответ на вопрос укладываемся или нет в установленные временные ограничения. И если нет, у нас будет время подкорректировать нашу оставшуюся часть планов.
  • 32. Но, рассчитать критический путь недостаточно. На каждую задачку нужно назначить соответствующие ресурсы. А они могут быть трудовые, те что можно померить рублями в час. Материальные, те что измеряем литрами, штуками, километрами и так далее. Ну и финансовые затраты - тоже ресурс, и его нужно учесть. Зачем нужно назначать ресурсы при планировании сроков? Да ровно за тем, чтобы до начала работ обнаружить возможные ресурсные конфликты. Когда один и тот же человек, например, назначен на несколько одновременно выполняемых задач. Пока мы не разрешим все ресурсные конфликты, календарный план не будет выполним. Кстати именно на основе такого календарно – ресурсного плана создается и план финансовый. Или бюджет проекта. Бюджет отличается от обычной сметы тем, что в
  • 33. нем присутствует календарная шкала. То есть только на основе бюджета затрат мы сможем сформировать подходящий график финансирования проекта. Только после ресурсной оптимизации и добавления рисковых запасов по срокам и ресурсам можно сохранить план для того, чтобы в ходе реализации осуществлять его отслеживание и контроль. Такой сохраненный план, чаще всего называют базовым. Именно он жестко привязан к датам и срокам. А текущий план, как раз наоборот, - не должен содержать никаких фиксированных дат и ограничений. Только в этом случае мы сможем, сравнивая эти два плана, спрогнозировать возможные будущие отставания. Предлагаю записать этот факт в копилку наших парадоксов проектного менеджмента. Давайте подведем итоги. Так какой же план будет хорошим рабочим инструментом руководителя проекта? А это план в котором: • В основе календарного плана лежит структурная декомпозиция работ (WBS) • Календарный план содержит необходимое количество контрольных точек (вех) • Работы и вехи связаны между собой зависимостями (задана сетевая диаграмма) • Задачи и вехи текущего плана не имеют фиксированных ограничений • Определен критический путь проекта • Задан базовый план проекта (задающий директивные сроки) • Перед ключевыми вехами проекта заданы временные буферы • На каждую задачу назначены ресурсы (трудовые, материальные, финансовые) • В календарном плане отсутствуют ресурсные конфликты И главное. Такой план – это инструмент Руководителя проекта по прогнозированию возможных отклонений. Не показывайте его Заказчику. Для заказчика всегда имейте под рукой укрупненный план по контрольным событиям. Этого для его уровня вполне достаточно.