ГЛАВА 12

Модели «Цепочка решения проблемы» и «Пентабазис»

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

В. И. Ленин

Начнем мы с двух тесно связанных между собой моделей — «Цепочки решения проблемы» и «Пентабазиса». Базовое утверждение — общее для обеих: каждый проект должен решать реально существующую проблему. Вот простое правило, которое я не устаю повторять: нет проблемы — нет проекта.

Проект, точнее его замысел, начинается с того, что ЕСТЬ БОЛЬ. Иначе говоря, кого-то что-то не устраивает или что-то где-то идет не так, как кому-то хочется. Причем «болит» настолько сильно, что он готов найти существенные ресурсы для того, чтобы от этой боли избавиться. Как говорил великий Стивен Кинг в «Противостоянии», «боль — причина перемен».

С этого момента начинается первый этап цепочки решения проблемы — предпроектная деятельность. Идея в том, что понимание будущего проекта нам необходимо сформировать еще до его официального запуска. Фактически проекта еще нет, соответственно и проектных ролей тоже — заказчика, руководителя проекта… Но уже должен появиться тот, кому «не все равно». И он должен сформировать первичный «контур слона». Обычно человека, который выступает «голосом боли», называют инициатором проекта. И им может быть кто угодно.

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

Ведь всегда есть вероятность, что проблему решать и не надо. Я люблю вопрос, который сэкономил много миллиардов рублей и долларов: «Что произойдет, если не делать проект?»

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

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

Однако если проблему решать все-таки надо, то необходимо сформулировать ответы еще на несколько вопросов. Давайте их разберем на нашей сквозной метафоре — метафоре слона (рис. 12.1).

Итак, первый вопрос — ЗАЧЕМ слон пустился в путь? Почему ему не сиделось на месте?

Второй вопрос — ЧТО должно быть на выходе, куда мы хотим привести слона? Как будет выглядеть «счастливое завтра»? Иными словами, нужно определить состояние, которого мы хотим достичь, — цель проекта. По сути, это проблема, переформулированная в позитивном ключе. И хорошо бы понять, как измерить, что «счастливое завтра» действительно наступило; это метрики проекта. Важно, чтобы цель была измеримой. Как говорится, «если вы не можете измерить цель, значит, эта цель — мечта!». Поэтому нужно определить целевые показатели, с помощью которых мы сможем оценить ее достижение.

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

В 2005 году я работал в крупной ретейловой компании, которая столкнулась с проблемой: на складе постоянно воровали продукты свои же грузчики. Как правило, пропадали мелочи по стандартной схеме: утром то один, то другой сотрудник брал себе бутылку кефира, сока, воды. Предыдущий вечер был у них слишком тяжелый… Казалось бы, пустяк. Но в масштабах компании за месяц / квартал / полгода проблема стала ощутимой. И к тому же намечалось слияние с другой крупной компанией — перед конкурентами / коллегами было неудобно.

Ответственные менеджеры рассматривали два варианта решения:

1) поставить видеокамеры, чтобы выследить, кто виновен;

2) ввести солидарную ответственность: кто бы ни украл, распределять ущерб на всех сотрудников смены.

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

Разница в финансовых, временны́х и людских затратах колоссальная. Получается, проблема и цель одна, а вот проекта два — и совершенно разных.

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

После того как мы разобрались с ЗАЧЕМ, ЧТО и КАК, нужно думать, КТО поведет слона. Найти тех самых слоновщиков. Мы дальше будем говорить о лицах, принимающих решения, команде проекта и тех, кто заинтересован в нем. Часто, очень часто, если нет людей, которые будут делать проект, его просто не запускают. И это правильно.

Следующий вопрос — ЧЕМ надо обеспечить участников: что нужно слоновщикам для прохождения маршрута? Важно верхнеуровневое понимание необходимых ресурсов (помещения, специализированное оборудование, компетенции, материалы, доступ к информации и так далее). Для каждого проекта свой уникальный набор необходимых ресурсов.

Последнее, с чем надо разобраться, — определить УСЛОВИЯ, в которых реализуется проект. Это все его ограничения и возможности — как в математической задаче. Некая данность, с которой мы соглашаемся еще до запуска проекта и начинаем выстраивать логику его реализации с учетом конкретных условий. Где, в каком окружении мы будем делать проект? Какие факторы окружения нужно учитывать? Какие у нас ограничения по срокам, бюджету, ресурсам и так далее? Какие есть угрозы? А возможности? В каких случаях проект будет успешным, в каких провальным? В общем, все то, что будет влиять на «извилистость» дороги, по которой вы поведете слона.

Например, необходимо отремонтировать и открыть для пользования общественное пространство в срок до 10 сентября 2018 года. Все закупки свыше 100 тыс. рублей осуществляются только через портал государственных закупок по Федеральному закону № 44-ФЗ. Все помещения должны быть доступными для маломобильного населения.

Хочу еще раз напомнить: проект — это всегда про ограничения. В первую очередь по срокам, хотя не только по ним. Это могут быть ограничения по деньгам, например сделать все строго в рамках выделенного бюджета (очень частая история для государственных проектов). Или соблюсти какие-то строгие регламентирующие правила. Да что угодно может оказаться ограничением; и чем крупнее проект, тем обычно их больше. Например, в Оргкомитете «Сочи-2014» мы посчитали, сколько у нас было ограничений / требований со стороны МОК, МПК, национальных олимпийских комитетов, спортивных федераций и других заинтересованных сторон. Получилось порядка трех тысяч… В общем, может быть очень много разных ограничений. И еще раз напомню: проект всегда конечен — есть обязательное ограничение по срокам.

Если вам кажется, что у вас нет ограничений, — может быть, и не нужно запускать проект… Если есть прямая понятная дорога и можно пройти по ней, то это простой домен «Киневин». Не нужно проектное управление — как-нибудь, когда-нибудь в рамках текущей деятельности результат будет получен. Или не будет. Здесь уж как сложится.

В графическом виде эти вопросы можно представить в виде пятиугольника — я называю его «Пентабазис» (рис. 12.2).

Обратите внимание, что ответы на вопросы Пентабазиса, анализ базовых аспектов проекта — итерационная работа! Пройдя последовательно по кругу один раз, важно минимум еще раз пройти цикл и ответить на те же вопросы с учетом уже имеющихся ответов по другим аспектам. Нужно убедиться, что все сочетается — а хватит ли ресурсов, чтобы решить всю проблему? Может, стоит взять только какую-то часть проблемы? Или уменьшить охват проекта? Может, поменять подход? Может быть, те лица, принимающие решения, которых мы выявили, не согласны с таким подходом? Тогда нам нужен еще один цикл. И еще. Пока все не сойдется.

Ответы должны быть даны ДО ЗАПУСКА проекта! Мы еще поговорим о детализации ответов на эти вопросы. Но базово с ними нужно определиться в самом начале. Это очень важно, потому что, как я показал на примере ретейловой компании выше, изменение ответов на эти вопросы дает вам совершенно другой проект!

И вот теперь мы можем пойти дальше по цепочке решения проблемы (рис. 12.3).

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

Следующий шаг (и да, он совершается ТОЛЬКО сейчас) — официальный запуск. Проектный подход в обязательном порядке требует фиксации решения о запуске, чаще всего путем утверждения официального документа, в котором прописаны все ключевые параметры. Он называется «Устав проекта», «Запрос на проект», «Паспорт проекта» или «Приказ о запуске». Английский вариант — Project charter. Мы будем называть этот документ «Описание проекта». В нем фиксируются:

• проблема;
• цели, ожидаемые результаты и эффекты;
• этапы и большие блоки работ;
• ответственные за ключевые роли.

Шаблонов, в которых готовятся Описания, очень много. Часть из них можно найти на сайте книги (см. ).

Желательно в этом документе также зафиксировать вознаграждение за получение результатов и наказание за неполучение. Документ непременно должен быть утвержден тем, у кого есть на это соответствующие права, — уполномоченным лицом. Очень часто это группа лиц по предварительному сговору… Ой, нет, это из другой области. Это группа, которая называется проектным комитетом, или инвестиционным комитетом, или другим словосочетанием. Главное — чтобы она была уполномочена запускать проекты.

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

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

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

• Заказчик подтверждает, что продукт проекта он принял, нерешенных вопросов нет.
• Проводим взаиморасчеты и закрываем все договоры.
• Сравниваем план и факт, фиксируем уроки.
• Награждаем и распускаем проектную команду.

Ура!

Думаете, на этом все? Нет, еще не все! Последний этап «Цепочки решения проблемы» — постпроектная деятельность. Проект на этом действительно заканчивается, но цепочка продолжается. Продукты начинают применяться пользователями в рамках их операционной деятельности. Ведь смысл не просто в том, чтобы сделать продукт. Важно получить эффект, выгоду от того, что он теперь есть. Если продуктом нашего проекта становится IT-система, то люди должны начать ее использовать в своей ежедневной деятельности. Если здание, то в нем должны появиться признаки жизни. Если новый бизнес, то он должен начать приносить деньги, и так далее. Это называется «проект перешел в процесс».

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

Эта цепочка может тянуться месяцами и даже годами. Часто, кстати, по ходу воплощения длительного проекта люди вообще забывают, ЗАЧЕМ его изначально запускали. Поэтому одинаково важны и предпроектная работа, и сам проект, и постпроектная деятельность.

Однажды на выступлении в Школе управления «Сколково» Андрея Амбарцумяна, директора проектов с огромным практическим опытом реализации сложнейших инвестиционных проектов, спросили: что самое плохое может случиться с руководителем проекта? Он практически мгновенно, не задумываясь, ответил: «Самое плохое, что может произойти с руководителем проекта, — это если в конце проекта он обнаружит, что его проект не нужен…» Именно поэтому предпроектная и постпроектная деятельность (верхняя половина схемы) ничуть не менее важны, чем сам проект (нижняя часть).

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

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

Пример 1. Сиднейский оперный театр

Изначально оперный театр планировали построить за четыре года и семь миллионов долларов (это цены конца 1950-х). В итоге его построили за четырнадцать лет и 102 миллиона. Как видите, сроки превышены более чем втрое, а бюджет — в тринадцать раз.

Но вернемся к цели проекта: создать здание, которое станет лицом Сиднея.

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

Сиднейский оперный театр — провальный проект, но успешный продукт.

Вообще, ситуация «проект провальный — продукт в конце концов, после многочисленных доработок напильником, успешный» очень у нас распространена. , про то же: провальный проект, но в целом успешный продукт — «довели до ума».

Пример 2. Kodak Advantix system

Проект по созданию нового продукта от гиганта Kodak получил от Международной ассоциации управления проектами премию «Лучший проект года». Его реализовали с экономией бюджета, быстрее предполагаемых сроков и с выполнением всех требований. Более того, в этом проекте Kodak применили семь инновационных практик проектного управления.

И вот когда продукт вышел в продажу… он с треском провалился. На дворе стояли 2000-е, рынок уже переходил к цифровым технологиям, а продуктом проекта стал новый формат пленки Kodak. Многие считают, что именно с него и началось падение компании, которая в итоге в 2012 году объявила себя банкротом.

Иначе говоря — идеальный проект и полностью провальный продукт. Цепочка не замкнулась: исходная проблема, ради которой запускался проект (захватить долю рынка, заработать денег), не решена. Kodak Advantix System — успешный проект, но провальный продукт.

Наша с вами задача — чтобы у вас и проект, и продукт были идеальными!

Часто встречается такая проблема: проект запускается до того, как заказчики и заинтересованные стороны точно определились, что именно и как хотят делать. Поэтому, прежде чем что-то начинать, нужно дать себе четкий ответ на вопросы: ЧТО ты делаешь и ЗАЧЕМ? В психологии это называется осознанностью. Четкая постановка проблем, целей и результатов проекта — важнейшее условие его успеха. Не менее важно и общее ви́дение этих вопросов всеми, кто задействован в проекте. По зарубежным оценкам, 40–80% неудачных проектов провалились именно из-за разного понимания участниками этих вопросов.

Чтобы не повторить провал Kodak, серьезно отнеситесь к предпроектной фазе: хорошо продумайте проблему, цели и результаты. Проработка проекта подразумевает все более и более детальные ответы на вопросы Пентабазиса (рис. 12.6).

В начале проекта, еще до его запуска, нужно провести первичную проработку: ответить на вопросы базово, высоко­уровнево.

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

Его можно разместить на одной странице презентации или просто на расчерченном на шесть частей листе флипчарта. Я часто так делаю на своих курсах.

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

Поэтому, пожалуйста, будьте внимательны, когда составляете описание. Подумайте: ту ли проблему вы решаете? Нужно ли вообще вам ее решать? Есть такая шутка: «Ты сильный — ты справишься! — Нет, я умный, я даже не возьмусь!»

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

Чтобы модель была понятнее, рассмотрим ее на примере уже известной нам компании «Кварк» (напоминаю: в  есть ее детальное описание). Пора ввести сквозной кейс, по которому мы будем разбирать все дальнейшие модели и инструменты (проектные «листы сыра»).

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

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

Процесс формализации и объявления первого конкурса зай­мет около полугода. К моменту его объявления у компании должен быть запущен и нормально функционировать филиал в ДФО.

Далее мы будем разбирать проект «Открытие филиала компании “Кварк” в Дальневосточном федеральном округе».

Генеральный директор поручил вам возглавить этот проект. Он также рассказал, что некоторые топ-менеджеры выступают за то, чтобы не открывать филиал, а заключить договоры о партнерстве с компаниями в ДФО. Генеральный директор считает, что этот вариант не гарантирует защиту конкурсной заявки. Кроме того, есть риски, что партнеры не смогут обеспечить необходимый уровень работы с клиентами и обслуживания техники при масштабных поставках. Так что этот вариант был отклонен. Генеральный директор посоветовал обязательно подключить к проекту административного директора — филиал будет в его ведении. Также нужно включить советника директора — у него есть опыт открытия филиалов. Проект должен быть проработан и вынесен на заседание высшего коллегиального органа компании — Комитета по координации, планированию и контролю (КПК), который включает всех топ-менеджеров.

Вот с такими вводными мы имеем дело.

Отправить