Текст книги "Проектное управление. Как правильно делать правильные вещи"

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

Итак, чем же она может быть полезна в практической работе над проектом? Дело в том, что в разных доменах «Киневин» у управленца будут разные объекты внимания и, соответственно, разные управленческие рамки (рис. 2.6).

Рис. 2.6. Разные объекты внимания в разных доменах «Киневин»

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

Рис. 2.7. Применимость управленческих рамок в разных доменах «Киневин»

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

Компания «Кварк» более 30 лет занимается разработкой и производством сложной медицинской техники: флюорографов, цифровых рентгеновских аппаратов, телеуправляемых аппаратов, компьютерных томографов и так далее. Аппараты собираются под заказ, с учетом индивидуальных требований заказчиков. В штате несколько сотен сотрудников. Продажи и сервис присутствуют в 50 регионах РФ. Всего по стране установлено и обслуживается несколько тысяч аппаратов. Детально бизнес компании описан в приложении 1.

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

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

Пример для компании «Кварк» – разработка и постановка на производство нового аппарата, например для искусственной вентиляции легких (ИВЛ), – такие устройства стали очень востребованы в связи с распространением COVID-19. Этот проект очень хорошо и эффективно может быть реализован через классический проектный подход. Или другой пример, который мы рассмотрим дальше: открытие нового филиала.

Для запутанного домена очень хорошо подходят agile-практики – здесь есть большая неопределенность и необходима работа в итеративном ключе, проверка гипотез. Это область продуктового подхода.

Примером для компании «Кварк» будет выход на новый рынок. Например, рынок Индонезии. Но что вы знаете про Индонезию? Скорее всего, ничего… Да и вообще, в России мало кто о ней знает. А между тем это четвертая страна мира по населению. Так что будет сложно все детально спланировать и сразу открыть успешный бизнес в Индонезии. Поэтому имеет смысл сформировать постоянную кросс-функциональную команду, включающую технологов, маркетологов, логистов, которые вместе будут прорабатывать вопрос и через целый ряд экспериментов постепенно начнут развивать новый рынок. Альтернатива – оформление этой деятельности как программы отдельных классических проектов, открытие представительства, анализ рынка, разработка линейки аппаратов под его потребности.

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

Проекты иногда попадают в этот режим, например при сваливании в кризис. Со многими это недавно случилось – при введении ковидных ограничений. В том же «Кварке», например. Но в целом этот домен не про проектное управление. Сначала нужно стабилизировать ситуацию, и только потом запускать проекты. Хотя есть отдельный вид проектов, специфический для России, – форсированные, или, как их еще называют, мобилизационные. Они запускаются в очень высокой степени неопределенности и под большим давлением внешних факторов. Я как раз исследую такие проекты и даже с коллегами в 2023 году выпустил доклад «Форсированные мегапроекты. Российский опыт двух столетий»[1]1
  URL: http://skolkovo.ru/researches/forsirovannye-megaproekty-rossijskij-opyt-dvuh-stoletij.


[Закрыть]. Но о том, как управлять такими проектами, видимо, будет отдельная книжка…

Вернемся к примеру нефтяной компании, который мы рассматривали ранее. Помните стикеры, попавшие в разные домены? Эти проекты управлялись как раз по-разному.

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

• То, что попало в СЛОЖНЫЙ домен («Эксперт знает»), запускалось как классические проекты.

• То, что попало в ЗАПУТАННЫЙ домен («Никто не знает, но мы узнаем»), запускалось как гибкие проекты.

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

…

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

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

У меня есть такая метафора: раньше в нашем условном корпоративном зоопарке было два основных «животных» (две управленческие рамки) – проекты и процессы. Но сейчас к ним прибавилось много других, и каждое «животное» требует своего ухода. Под каждый из них придуман свой набор подходов, методик и инструментов для планирования, организации и контроля работ. Многие инструменты полезны и используются в разных рамках, и часто возникает идея, что нет нужды делить «животных» в зоопарке и специально за ними ухаживать. Какая разница – проект, процесс, продукт, стартап?! Но это на самом деле важно. Если вы скажете: «Какая разница, что это за животное, – я со всеми буду обращаться одинаково. Все у меня будут собаки. Буду кормить, вычесывать и выгуливать два раза в день!» – ну, кошка, может, напряжется и привыкнет, а вот рыбкам станет от такого ухода плохо…

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

КРАТКОЕ РЕЗЮМЕ ДЛЯ СЛОНОВЩИКА

• Модель «Киневин» (CYNEFIN) – базовая для определения, требуется ли вам проектное управление.

• Проектное управление не нужно там, где все абсолютно понятно (простой домен) и где много непонятного (запутанный и хаотический домены).

Рис. 2.8. Модель «Киневин»

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

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

Глава 3. Характеристики проекта. Сложность, уникальность, ограничения

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

Сенека

Когда мы с коллегами разрабатывали российский ГОСТ по проектному управлению, то обнаружили, что единого, общего для всех определения проекта не существует. Каждый автор стандарта писал свое.

• ПРОЕКТ – это временное предприятие, направленное на создание уникального продукта, услуги или результата. PMBOK-7.

• ПРОЕКТ – это уникальный процесс, состоящий из набора взаимоувязанных и контролируемых работ с датами начала и окончания и предпринятый, чтобы достичь цели соответствия конкретным требованиям, включая ограничения по времени, затратам и ресурсам. ISO/TR 10006:1997.

• ПРОЕКТ – это уникальная совокупность взаимосвязанных действий (работ) с определенными датами начала и окончания, предназначенных для успешного достижения общей цели. Australian National Standard for PM.

• ПРОЕКТ – это уникальная совокупность скоординированных действий (работ) с определенными точками начала и окончания, предпринятая индивидуумом или организацией для достижения определенных целей с установленными сроками, затратами и параметрами выполнения. BS 6079-1:2000.

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

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

И это определение, и вышеперечисленные выделяют три основные особенности любого проекта: сложность, уникальность и ограничения (рис. 3.1).

Рис. 3.1. Три основные характеристики проекта

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

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

Таким образом, нужны все три элемента.

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

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

Учитывая все эти особенности, в организациях обычно прописывают некоторую границу, выше которой необходимо применять проектный подход. Обычно это комбинация нескольких параметров: длительность, затраты, количество вовлеченных подразделений, рискованность и так далее. И если по этим параметрам деятельность оказывается достаточно масштабной, ее заворачивают в проектную рамку (табл. 3.1).

Таблица 3.1. Пример определения проекта для небольшой компании

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

** Возможно наличие затрат на единоразовые активности (закуп лицензий, оборудование и так далее).

Этот набор критериев может быть и совсем коротким (табл. 3.2).

Таблица 3.2. Пример критериев для регионального банка

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

Важно отметить, что проектный подход, кроме непосредственно проекта, предполагает и другие объекты управления – программу проектов и портфель проектов (табл. 3.3).

Таблица 3.3. Проект, портфель и программа

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

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

Продолжая слоновью метафору: проект – это отдельный слон, программа проектов – несколько слонов, которые вместе идут к одной цели (на водопой ), а портфель проектов – это целое стадо слонов, осваивающих определенную территорию.

Сравнение проектного, программного и портфельного подходов

Программное и портфельное виды управления нужны, когда проект становится настолько большим, что управлять им целиком уже очень сложно (рис. 3.2).

Рис. 3.2. Схема управления проектом

Важно понимать, что программный и портфельный виды управления – это высшая математика проектного подхода. На сотню организаций, внедривших проектный подход, приходится всего несколько, которые доходят выше. И это очень жаль, потому что, согласно исследованиям (PMI Pulse of Profession 2021[2]2
  URL: http://pmi.org/-/media/pmi/documents/public/pdf/learning/thought-leadership/pulse/pmi_pulse_2021.pdf.


[Закрыть]), попытка запустить слишком много проектов – самая большая проблема управления проектами для многих организаций. А управление портфелем должно как раз приоритизировать и отбирать самые важные проекты.

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

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

Вы знаете, что это за здание (рис. 3.3)?

Рис. 3.3. Храм Святого Семейства (Temple Expiatori de la Sagrada Família). Rodrigo Garrido / Shutterstock

У этого храма очень интересная история. Строительство началось еще в 1882 году. В 1883-м руководить стройкой был приглашен знаменитый архитектор Антонио Гауди, и вплоть до смерти в 1926 году он занимался ею. Он успел достроить крипту, частично фасад и одну из 100-метровых колоколен. После смерти Гауди руководство работами принял на себя его ближайший соратник Доменек Сугранес. Ему тоже не удалось закончить строительство, но были возведены три дополнительные колокольни. Во время гражданской войны в Испании в 1938 году строительство прервалось и возобновилось только в 1952-м. И продолжается по сей день. Ожидаемая дата окончания – 2030 год.

Я часто задаю своим студентам вопрос: можно ли назвать это проектом? И ответ, который не все угадывают, – конечно же, нет. Потому что нет главного ограничения – по срокам.

На самом деле строительство храмов часто ведется подобным образом. Чтобы это увидеть, не обязательно ездить в Барселону. Недавно я был в Кирове – точно так же там восстанавливают Спасский собор, разрушенный во времена СССР (рис. 3.4).

Рис. 3.4. Спасский собор, Киров. Вид с ул. Казанской. Novingalina / Wikimedia Commons

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

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

Яркий пример – Международный экспериментальный термоядерный реактор (ITER; рис. 3.5). Его задача заключается в демонстрации возможности коммерческого использования термоядерной реакции синтеза и решении физических и технологических проблем, которые могут встретиться на этом пути. Когда он будет построен, у человечества появится принципиально новый источник чистой электроэнергии.

Рис. 3.5. Строительство ITER. Wikimedia Commons

Проект (хотя правильнее назвать его мегапроектом) начал разрабатываться в середине 1980-х. В 1992 году было подписано четырехстороннее (ЕС, Россия, США, Япония) межправительственное соглашение о разработке инженерного проекта ITER, который был завершен в 2001 году. Проектирование реактора было полностью закончено, и в 2005-м выбрано место для его строительства – исследовательский центр «Кадараш» на юге Франции, в 60 километрах от Марселя. Подготовка строительной площадки началась в январе 2007 года. В 2010-м стартовало строительство. В 2020 году – сборка реактора. Запуск планируется на 2025-й, но, скорее всего, сроки сдвинут.

В итоге мегапроект будет длиться около 40 лет. Но это действительно проект. Здесь используется соответствующий подход. Есть все, что мы с вами будем изучать: руководитель проекта, планы, контрольные точки и прочее.

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

В связи с этим давайте посмотрим на важную модель, которая называется «Треугольник ограничений» (рис. 3.6). Еще ее называют «Железный треугольник» или «Тройственное ограничение».

Рис. 3.6. Треугольник ограничений

В чем суть идеи? Это способ наглядно показать взаимосвязь ключевых аспектов, влияющих на реализацию проекта. Считается, что есть три базовых ограничения: по срокам, по затратам и по содержанию. Иными словами, проект должен быть реализован в определенные сроки, не превысить установленный бюджет и создать то, что нужно заказчику. Последнее как раз и есть содержание.

Лингвистическое отступление. Вообще, слово «содержание» очень любопытное. Это перевод английского scope. Оно обозначает все работы и результаты, которые должны быть получены в проекте. То есть одно английское слово scope переводится аж четырьмя разными русскими словами: «содержание проекта», «объем проекта», «рамки проекта», «границы проекта» (это все скоуп). Нет! Даже пятью – еще есть «периметр проекта». Часто, кстати, его сейчас так и пишут: «скоуп» – и все.

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

Документация для создания какого-либо продукта; эскизный проект; технический проект. Английский термин – design.

Проект как черновая версия документа – draft.

Проект как идея, задумка – idea.

Проект как деятельность – project.

Исходя из принципа треугольника, все три аспекта соединены между собой в трех углах. Геометрически этот закон управления проектом может быть проиллюстрирован так: если потянуть один из отрезков (например, сроки), то, согласно правилам геометрии, изменятся и остальные. В русском языке этот закон отражен в известной поговорке «Мы сделаем вам быстро, качественно и недорого – выберите два из трех». Важная особенность связей между параметрами – их нелинейность и слабая предсказуемость. Особенно часто это проявляется в IT-проектах: одно небольшое изменение, например объема путем добавления нескольких новых требований, может вызвать непропорциональное увеличение бюджета и (или) сроков выполнения проекта.

Ценность треугольника в том, что он легко передает следующую идею: если вы увеличиваете содержание, вам нужно добавить либо бюджет, либо время. Если вы уменьшаете бюджет без изменения времени, придется уменьшить содержание. И так далее. Это может помочь провести интересную дискуссию с заказчиком, если он пришел с таким запросом.

Вроде хорошая модель. Правильная. Но есть нюанс. Посмотрим на то, как по-разному изображают треугольник (рис. 3.7).

Рис. 3.7. Изображения треугольника ограничений

Видите? Четыре ограничения, пять ограничений, шесть ограничений… Так что уже достаточно давно понятно, что это не треугольник. У руководителей проектов появилась даже такая шутка: «Если сломать треугольник, качество просочится наружу». Она как раз о том, что качество – важное ограничение.

Так что в какой-то момент стало ясно, что «Треугольник ограничений» – модель очень полезная, но для реальной практики слишком простая. У проекта может быть много разных ограничений, из них самое важное – сроки. Как мы видели выше, если нет ограничения по срокам, то и проектное управление не нужно. Но в реальности это не треугольник, а N-угольник. И исходя из наложенных на проект ограничений формулируются критерии его успешности (или неуспешности).

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

• в полном объеме;

• в рамках бюджета;

• в установленные сроки;

• с заданным уровнем качества;

• при удовлетворении заказчика.

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

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

Подводя итоги, необходимо сказать, что из-за сложности, уникальности и ограничений возникает необходимость этим сложным уникальным объектом специальным образом управлять. Помните метафору проекта как слона? А ведь слоновщиком быть непросто – проекты часто проваливаются. Печальный факт. Давайте разберемся.

КРАТКОЕ РЕЗЮМЕ ДЛЯ СЛОНОВЩИКА

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

Рис. 3.8. Три основные характеристики проекта

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

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

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

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

• Постулат № 2. Нет дедлайна – нет проекта! Должна быть точная дата его завершения. Проект может быть без денег и почти без ресурсов, но без финального срока проекта быть не может.

• Постулат № 3. Нет ограничений – не нужно проектное управление! Проект реализуется в условиях ограничений (не только по срокам). Ограничения определяют важные аспекты проекта.