М: Манн, Иванов и Фербер, 2024. 365 стр.
Управление проектами – известная и хорошо изученная дисциплина. За последние 15–20 лет в России ее освоили не менее полумиллиона человек. Но где все эти люди? Где сотни тысяч проектных профессионалов и почему мы видим так мало красивых и правильно реализуемых проектов?
Павел Алферов, профессор бизнес-практики Школы управления «Сколково», считает, что проблема в том, что теория проектного управления не учитывает национальные особенности. И поэтому он написал книгу, цель которой – сделать управление проектами более применимым к российским условиям.
Алферов – автор российской инструментальной трехуровневой модели управления проектами (РИМ-III).
Она появилась как попытка заполнить драматический (такой эпитет выбирает автор) разрыв между теорией и практикой. Между богатым спектром зарубежных и российских проектных методологий, с одной стороны, и практическими подходами к реализации проектов – с другой. Разрыв этот очень велик.
Что такое проект
Для начала автор предлагает разобраться, что именно считать проектом. Общего для всех определения проекта не существует. Павел Алферов использует такое: «Проект – это комплекс мероприятий, направленный на создание уникального продукта или услуги в условиях временных и ресурсных ограничений».
Проект – это всегда про сложность, пишет автор. Мы создаем то, что требует коллективной скоординированной работы группы людей.
Это всегда про уникальность: мы делаем что‑то исключительное, то, чего мы еще не делали. По крайней мере, не делали в этих условиях.
Проект – это всегда про ограничения, в первую очередь по срокам.
Постулат Алферова: «Нет дедлайна – нет проекта!» Должна быть точная дата его завершения. Проект может быть без денег и почти без ресурсов, но без финального срока проекта быть не может.
Например, строительство в Барселоне собора Sagrada Família, возведение которого началось в 1882 году и продолжается по сей день, по мнению автора, нельзя назвать проектом. Потому что нет главного ограничения – по срокам. Появились деньги – построили часть. Закончились средства – остановились. Каждый отдельный блок работ можно рассматривать как проект, а в целом – нет.
Впрочем, замечает автор, мы – как человечество – очень плохо умеем работать с масштабом в сотни лет. Наш предел – пара-тройка десятилетий.
В разных проектах может быть разное представление об успешности: где‑то превышение срока на день – это полный провал, а где‑то некритично. Так что при запуске проекта очень важно определиться с ключевыми ограничениями и исходя из них строить свою работу.
Проект и процесс
К концу XX века в науке о менеджменте сложилось мнение, что основная задача менеджера – организовать плановую работу вверенной ему компании или ее подразделения. Внеплановая деятельность организации должна быть минимизирована, потому что эффективно управлять можно только плановой работой.
При этом выделялись два подхода к организации работ – проектный и процессный. И два основных объекта управления – проект и процесс. Для проекта работа организуется одним образом, для процесса – иначе.
Чтобы четко понять, когда нужно проектное управление, а когда нет, Алферов предлагает рассмотреть модель «Киневин» (Cynefin). Она была разработана Дейвом Сноуденом, который отвечал за управление знаниями в компании IBM.
Модель «Киневин» определяет тактики поведения в различных условиях и контекстах.
Первый вид систем – простые (simple). В них связи между причинами и следствиями ясны, неизменны и поддаются предсказанию. Здесь тоже могут быть проекты, но достаточно простые, типовые. Например, внесение в уже работающие на производстве механизмы или аппараты минимальных модификаций.
Второй вид – упорядоченные сложные (complicated). В них связи между причинами и следствиями неясны. Нужно посидеть, подумать, проанализировать, привлечь экспертов, чтобы разобраться. Здесь хорошо работают практики классического проектного управления. Например, для разработки и постановки в серию нового аппарата. Или работа по открытию нового филиала.
В запутанных (complex) системах связи между причинами и следствиями не только неясны, но и полностью ясны не будут, разве что в ретроспективе. Приходится с этим жить. Для запутанного домена очень хорошо подходят agile-практики – здесь есть большая неопределенность и необходима работа в итеративном, поэтапном ключе, проверка гипотез. Пример: выход на новый рынок, скажем, рынок Индонезии. Здесь будет сложно все детально спланировать и сразу открыть успешный бизнес. Поэтому имеет смысл сформировать постоянную кросс-функциональную команду, включающую технологов, маркетологов, логистов, которые вместе будут прорабатывать вопрос и через ряд экспериментов постепенно развивать новый рынок.
Четвертый вид систем – хаотические (chaotic). Как ни анализируй, все равно не поймешь. Да и анализировать здесь нечего, надо действовать, пишет Алферов. Вопрос: как лучше делать проекты в хаотическом домене? Ответ: в хаотическом домене проекты лучше не делать. Это антикризисное управление в реальном времени. Сначала нужно стабилизировать ситуацию и только потом запускать проекты. Хотя есть отдельный вид проектов, специфический для России, – форсированные или мобилизационные. Они запускаются в очень высокой степени неопределенности и под большим давлением внешних факторов.
Наконец, есть еще пятый домен – середина между всеми моделями. Это беспорядок (Disorder) – когда непонятно, с какой системой имеем дело.
Провальные проекты
Проекты проваливаются везде – и в России, и в других странах. Так, по данным Haos Chronicles, только 35% IT-проектов успешны; 19% проваливаются и 46% оцениваются как Challenged (оказываются проблемными) – они превысили сроки и/или бюджет.
9 из 10 крупных инфраструктурных проектов сталкиваются с превышением бюджета. Везде главной проблемой оказывается сложность проектов.
Автор коллекционируют провальные проекты. И мир полон впечатляющих примеров. Самый известный в современной России – строительство «Зенит Арены». В 2004 году стадион планировали построить за 3 года и 6,7 млрд рублей. Финальный срок – почти 10 лет, общие затраты – 43,8 млрд рублей. Причины: дефицит бюджета из‑за девальвации рубля, постоянно меняющийся проект и отсутствие полного комплекта строительной документации, смены подрядчиков, отсутствие внятного заказчика. Вывод: проблема в том, что не было налажено управление проектом.
В то же время исследование Standish показывает, что за последние 25 лет проектное управление сделало очень большой шаг вперед: доля успешных проектов в мире выросла более чем вдвое, доля провальных проектов сократилась в полтора раза.
В целом управление проектом с использованием тех практик и инструментов, которые разбирает автор в книге, дает ощутимый эффект. За 20–30% можно точно ручаться, уверяет Павел Алферов. Специфика России заключается в том, что у нас результаты часто не на 20–30% улучшаются, а в разы. Это доказало использование проектного подхода на нескольких российских нефтяных мегапроектах.
Национальные особенности
Первая отечественная особенность управления проектами построена на поговорке – русский человек на трех сваях крепок: авось, небось и как‑нибудь:
– как‑нибудь мы проект сделаем,
– как‑нибудь продукт получим,
– как‑нибудь жизнь наладится без всяких сложностей.
В России рассчитывают на работу в стабильном режиме. Это когда никто не напрягается, все дружат против руководителя, чтобы не нагрузил работой.
А если выясняется, что это не работает, то отдельное подразделение или вся компания переходят в мобилизационный режим, когда делают за ночь или неделю то, что не делалось месяцами и годами.
Темой национальных особенностей наука занимается очень давно. Одним из ее основоположников был ученый Герт Хофстеде. Он выделял шесть проблемных зон.
1 Дистанция власти (Power distance).
2 Индивидуализм (Individualism).
3. Напористость (Masculinity).
4. Избегание неопределенности (Uncertainty avoidance).
5. Ориентация на долгосрочную перспективу (Long term orientation).
6. Ориентация на наслаждение жизнью (Indulgence).
Одна из основных особенностей России по модели Хофстеде – дистанция власти (Power distance). По этому параметру у России показатель равен 95 (максимум – 100).
В нашей стране очень большая дистанция власти. Любая деятельность должна быть поддержана сверху, и должен быть четкий мандат на ее выполнение. Снизу инициатива приветствуется крайне посредственно.
Как это влияет на проектное управление? Проектное управление – это способ делегирования. Генеральный директор передает часть своих полномочий куратору проекта, тот – руководителю проекта, руководитель – членам рабочей группы. Нет делегирования – нет проектного управления.
В России очень сложно выстроить такую иерархию. Руководитель проекта и команда не получают прав на принятие самостоятельных решений. Принятые руководителем и командой решения могут быть оспорены в любой момент первыми лицами.
То есть в России результат достигается непосредственным участием первых лиц. И эти первые лица в режиме ручного управления постоянно занимаются разруливанием возникающих вопросов. Таким образом, в проекте становится абсолютно критичной роль куратора проекта как руководителя высшего звена. Также критично наделение руководителя проекта правом на «доступ к телу» для быстрого принятия решений.
По параметру «Избегание неопределенности» у России показатель также очень высокий – 93. Наши люди не любят новое, боятся любых неожиданностей, страшатся незнакомых ситуаций. Кстати, Хофстеде считал, что именно этим объясняется любовь россиян к бюрократизации: это попытка максимально уменьшить неопределенность.
Еще одна национальная особенность. Часто говорят, что в России ориентация на процесс, а не на результат. Но это заблуждение, уверяет Павел Алферов. На самом деле в России ориентация не на процесс и не на результат, а на отношения.
Соответственно, одним из ключевых фокусов внимания руководителя проекта должны стать заинтересованные стороны – ему необходимо учитывать их интересы, требования и запросы.
Непредвиденные ситуации
У непредвиденной ситуации всегда есть причина, скорее всего не одна. Тут важно, пишет автор, что мы предпримем, чтобы эту ситуацию исправить.
Если мы быстро ее разрешим, то сможем вернуться к запланированным действиям. Если инцидент игнорировать, то эта бомба взорвется, полностью разломав первоначальный план. При самом неблагоприятном развитии бездействие приведет к катастрофе.
Допустим, пишет Алферов, вы работаете в компании, которая выполняет проект для внешнего заказчика. И вот случился инцидент: вовремя не оплатили счет поставщику за оборудование, необходимое для проекта. На ранних стадиях устранить инцидент достаточно просто – он еще не оброс последствиями и не начал порождать новые проблемы. Пока ситуация остается внутри организации, можно все исправить – объяснить финансовому директору важность срочной оплаты счета за оборудование, получить нужные согласования. А вот если затянуть устранение инцидента, то сложность решения начинает возрастать.
Поставщик видит, что вы задерживаете оплату. Понизит приоритет ваших заказов и затормозит поставку. В итоге недоволен внешний заказчик. У него возникают сомнения: а вдруг вы не сможете выполнить проект? И тогда он принимается требовать все новых и новых гарантий, выдвигая дополнительные условия. Члены команды расценивают проект как проблемный, не хотят в нем работать и стараются перейти в более успешный. Закончиться все это может катастрофой: проект закроют, а вашу организацию включат в реестр недобросовестных поставщиков.
Нештатная ситуация запускает цепную реакцию. После определенного момента устранить первоначальный инцидент становится гораздо сложнее. Все происходит в соответствии с поговоркой: «Даже самые большие проблемы можно было решить, пока они еще были маленькими».
Поэтому менеджер проекта всегда должен понимать причину инцидента и последствия, к которым он может привести. Можно сказать, пишет автор, что проект похож на велосипед: устойчив, пока едет, но стоит ему остановиться – падает.
Три модели управления
Западные модели и методики управления проектами терпят фиаско, если их пытаются внедрить без учета национальных особенностей России. Обычно у нас проект либо горит в аврале, либо застревает в бесконечной бюрократии. При этом эффективность процессов управления проектами нередко низкая.
Выделяют три национальные модели работы с инцидентами.
Японская модель управления. Нацелена на то, чтобы вообще не допускать инцидентов. Много внимания уделяют именно тому, чтобы предугадать, что может пойти не так, и профилактике этих вариантов.
Американская модель управления. Фокусируется на том, чтобы устранить все нештатные ситуации как можно быстрее и таким образом не допустить настоящего кризиса.
Российская модель управления. Нацелена на борьбу с возникающими кризисами. Мы на мелочи не размениваемся. Инциденты? Да зачем ими заниматься? Само рассосется? И часто, надо сказать, рассасывается. А вот если кризис – то да! Фокус внимания постоянно удерживается не на системной работе, а на том, чтобы предотвратить катастрофу.
Любая из этих моделей управления имеет право на жизнь, считает автор. Более того, в ряде обстоятельств российская система оказывается эффективнее японской или американской. Например, в случае быстрых существенных изменений во внешней среде (финансовый кризис, революция, катастрофа).
Как бороться
«Модель швейцарского сыра» (дырки характерны для швейцарских сыров, отсюда и название) – один из способов избежать инцидентов. Эта концепция пришла к нам из авиации. Она предлагает ставить на пути вероятного происшествия как можно больше преград. Например, мы не хотим, чтобы самолет упал из‑за поломки двигателя. И чтобы этого не произошло, ставим барьеры: осмотр двигателя перед вылетом, регулярное техобслуживание, датчики и пр. Если бы эти барьеры были плотными, то никогда бы самолеты не падали из‑за поломок. Но в каждой преграде есть дырки – отдельные упущения и ошибки.
Такие дыры имеются в любой системе на любом уровне. Но на каждом уровне они образуются в разных местах, поэтому, когда на одном уровне событие проходит в дыру ошибки, то на следующем уровне дыры нет. Это останавливает развитие нежелательного явления. Такие преграды защищают всю систему от масштабных инцидентов. Происшествие станет возможным, только если все упущения выстроятся в ряд.
Несколько переформулированная идея «модели швейцарского сыра» – модель «Галстук-бабочка». Это когда в центре находится нежелательное событие, а мы предпринимаем действия, чтобы его предотвратить, или предусматриваем меры, чтобы уменьшить ущерб, если событие все‑таки произойдет.
Павел Алферов считает эту модель ключевой для работы с национальными особенностями. Приводит простой пример. Один из типовых рисков проекта – задержка принятия ключевых решений, например, согласования технического задания (ТЗ). Причиной может быть, например, то, что согласующих сотрудников нет на месте (скажем, уехали в отпуск).
Получается, согласующих нет, ТЗ вовремя не согласовано, обязательства заказчика не выполнены, команда не вписывается в ограничения по срокам.
Но если с самого начала будет подготовлен план проекта с прописанными ответственными, на пути возникнет преграда.
И всегда, пишет автор, могут помочь еще два инструмента: стартовое совещание и система мотивации.
От старта к финишу
Первый вопрос, на который нужно ответить инициатору проекта еще до его запуска: зачем и для кого он реализуется? Еще до запуска важно выяснить, кто страдает от проблемы и хочет ее решить, кто выделит на проект ресурсы.
А может, проблему и не надо решать? Вопрос, который сэкономил много миллиардов рублей и долларов: «Что произойдет, если не делать проект?»
Проектный подход в обязательном порядке требует фиксации решения о запуске, чаще всего путем утверждения официального документа, в котором прописаны все ключевые параметры. Документ может называться «Паспорт проекта» или «Приказ о запуске». В нем фиксируются:
– проблема;
– цели, ожидаемые результаты и эффекты;
– этапы и большие блоки работ;
– ответственные за ключевые роли.
Желательно в этом документе также зафиксировать вознаграждение за получение результатов и наказание за неполучение. Документ непременно должен быть утвержден тем, у кого есть на это права.
Только после того как проект официально запущен, мы начинаем его реализовывать. Сначала идет этап «Подготовка» – собираем команду, она более детально прорабатывает проект: анализирует требования, определяет, как их удовлетворить, готовит планы. Дальше команда переходит к этапу «Выполнение» – реализует планы, получает промежуточные результаты, потом финальные. А затем идет важный этап «Завершение»:
– заказчик подтверждает, что продукт проекта он принял, нерешенных вопросов нет,
– проводим взаиморасчеты и закрываем все дого-воры,
– сравниваем план и факт, фиксируем уроки,
– награждаем проектную команду.
Но на этом еще не все. Затем начинается постпроектная деятельность. Продукты начинают применяться пользователями. Ведь смысл не просто в том, чтобы закончить проект. Важно получить эффект, выгоду от того, что новый продукт теперь есть.
Контрольные точки
На пути проекта к финишу необходимо расставить промежуточные отметки – вешки, показывающие наше продвижение. У контрольной точки может быть только два статуса: она или пройдена, или нет. Поэтому мы всегда должны отслеживать статус: продвинулась команда на пути к результату, прошла нужную веху или нет.
Наличие промежуточных вех особенно важно для долгосрочных проектов. Обманчивое впечатление, что впереди много времени и мы все еще успеем сделать, сгубило немало хороших идей.
Чтобы большое начало не закончилось пшиком, важно расставить контрольные точки. Тогда, во-первых, картина становится намного четче: мы видим, что нужно сделать на этой неделе, а что закончить к концу месяца. Во-вторых – зафиксированные промежуточные результаты мобилизуют команду. Здесь дело и в человеческой психологии. Четко обозначенные вехи помогают интенсифицировать усилия. Точка не пройдена – плохо, но еще не критично. Это просто повод напрячься и устранить проблему.
Важный момент: контрольные точки формулируются исключительно как ответ на вопрос «Что сделано?». Главное – результаты. Члены рабочей группы несут ответственность за их получение.
Руководители проекта не контролируют ни членов рабочей группы, ни их работы. Они контролируют результаты через контрольные точки.
Необходимо регулярно проверять статус контрольных точек. Обычно это делают раз в одну-две недели. Для всех точек за предыдущий период руководители получают подтверждение «сделано» либо объяснения, почему не сделано.
Как это должно происходить на практике. По версии Алферова, ответственных за контрольные точки просят присвоить им один из трех статусов:
– зеленый – получение результатов гарантировано в запланированный срок;
– желтый – есть несущественные риски неполучения результата в срок, но помощь не требуется;
– красный – получение результата под угрозой, ведется активная работа по преодолению сложностей.
Для желтых и красных точек пишутся комментарии с пояснениями, в чем состоят риски и угрозы и как планируется их преодолеть.
Обсуждения статуса всего проекта и входящих в него контрольных точек проводятся на управляющем комитете, у куратора или на уровне встречи команды – это зависит от компании и масштаба проекта. Но проводить их нужно в обязательном порядке, говорит Алферов.
Самое важное на этих встречах – вовремя получить информацию о том, что какого-то результата добиться не удастся. Самые серьезные вопросы задаются в ситуации, когда сотрудник на собраниях по оценке статуса красил свою задачу из раза в раз зеленым («все будет сделано в лучшем виде»), а потом взял и не выполнил свою контрольную точку. Это причина для прямого штрафа или другого наказания. Если же человек ставил своей точке желтый статус, предупреждал о затруднениях, а в итоге в срок его задача не выполнена, то его можно «понять и простить».
Есть такая правдивая шутка: «Что такое результат по-русски? Это отсутствие результата плюс интересный рассказ». Система работы с контрольными точками по методу Алферова предлагает другой вариант: регулярный интересный рассказ до результата.
Инструменты управления проектом
Церемонии. Регламентированные совещания, на которых обсуждаются различные вопросы по аспектам проекта.
Артефакты. Официальные и рабочие документы, которые описывают различные аспекты и фиксируют договоренности по ним. Очень распространенная ошибка – сведение всего управления проектами к подготовке и утверждению многочисленных документов. Но документы действительно нужны – это важный элемент всей системы управления проектом.
IT-системы и каналы связи. Мир стремительно идет «в цифру», так что без цифровых инструментов проекты сейчас не обходятся.
Менеджер проекта управляет будущим. Ключевая парадигма, база проектного подхода – «Смотри вперед! Управлять в проекте можно только его оставшейся частью!»
Три следствия из этого утверждения:
Следствие 1: чем меньше времени осталось до окончания проекта, тем меньше возможностей у руководителя что‑то изменить.
Следствие 2: для управления необходимо создать план по ключевым аспектам («модель будущего») на весь период проекта.
Следствие 3: будущее неизвестно, поэтому план должен постоянно обновляться и уточняться.
Проектные тезисы
10 постулатов, которые автор вынес из своего проектного опыта.
1. Нет проблемы – нет проекта! Проект всегда запускается для решения проблемы. Проблема – это понимание разрыва между желаемым будущим и реальностью. И именно этот зазор закрывает проект.
2. Нет дедлайна – нет проекта! Должна быть точная дата завершения проекта. Без этого невозможны планирование и связка действий.
3. Нет ограничений – не нужно проектное управление! Проект реализуется в условиях ограничений (не только по срокам).
4. Нет полномочий – нет руководителя проекта! Невозможно чем‑то управлять, когда у тебя нет на это прав.
5. Нет приоритета – нет результата! Если для руководства компании проект не приоритетен, то шансы на успешное завершение минимальны. Вовлечение лиц, принимающих решение, и стейкхолдеров необходимо. Куратор – критическая роль в проекте.
6. Нет решения – нет движения! Скорость принятия решения выше качества. Решения по важным аспектам должны приниматься максимально быстро, даже если они могут оказаться неверными. Часто первая мысль и (или) коллективный разум дают наилучшие результаты.
7. Нет контрольных точек – нет понимания продвижения! Главное в проекте – получение конкретных результатов.
8. Нет команды – нет проекта! Реализация проекта – это командная работа, если нет выделенной на проект команды, один руководитель не сможет сделать проект.
9. Нет веры и мотивации – нет продукта! Отчаявшийся руководитель – горе в проекте. Эта вера позволяет достигать результата вопреки, а не благодаря.
10. Нет фактов – нет разговора по существу! Отсутствие четко зафиксированных результатов проекта, критериев приемки, может привести проект в критическую точку.
