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

Весь мой 16-летний опыт проектной работы подсказывает, что на курсах и в книгах по большей части учат не тому, как реально запускаются проекты в жизни. В жизни важно понимать как работает офисная политика, как вести конструктивный диалог с коллегами, руководителями и поставщиками даже если вы друг-другу не нравитесь, как оформлять договора так, чтобы не нарушить бюджет и не попасть под раздачу контролеров, как использовать юридический способ мышления при написании отчетов, как структурировать задачи, когда у тебя 200 человек и 15 организаций в проекте. И только если удалось запустить работу, можно думать о планировании, организации регулярного исполнения и контроля, закрытии этапов и накоплении знаний и опыта. Другими словами, в проектной работе важно уметь неплохо играть в политику и работать с реальными людьми в кризисных и стрессовых условиях. А инструменты и практики управления важны только в той мере, в которой они работают на эти задачи.

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

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

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

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

• Сравните футбольную команду и семью. У команды всегда есть конкретная цель - выиграть матч, выиграть чемпионат, выйти на второе место турнирной таблицы. Есть четкое распределение ролей - защитник, полузащитник, нападающий, вратарь. У тренера есть полный контроль играющего состава и тактики игры. У капитана команды есть полный контроль над игроками на поле. Неподчинение командам строго наказывается.

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

• Метафора спортивной команды и семьи применима к управлению подразделением и проектом.

• В подразделении все свое - нельзя прийти и сесть за компьютер чужого отдела или поехать на чужом служебном автомобиле или зайти в 1С бухгалтерского отдела, если вы работаете в отделе разработки. И уж тем более никто не пустит бухгалтера делать чертежи и 3D-модели деталей и узлов в Catia и отправлять их изготовителю дорогого оборудования.

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

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

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

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

• --------------------------------------------------------

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

• А теперь представьте, что вы попытаетесь так спланировать что-нибудь в семье, кроме поездки в отпуск. Не получится, будет сто причин, почему детальный план разобьется об реальность. Цикл "спланировать-сделать нужное-свериться с планом-понять причины отклонений и откорректировать план", цикл, который часто называют циклом Деминга-Шухарта, PDCA, не работает в семье и не работает в стартующих проектах. Потому что политика.

• Ниже я приведу основные причины, по которым в проектах нельзя на старте применять цикл PDCA. После запуска проекта его применять обязательно, но на старте он только помешает. И после того, как мы разберемся, почему планирование на старте проекта отличается от планирования уже запущенного проекта, я объясню, почему запускать проекты надо с помощью цикла [[D-RCSA-P]], цикла исследования действием.

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

• Эпоха "стройки в чистом поле" и утопических замыслов закончилась.

• PDCA нацелен на создание нового в условиях, когда этому созданию мало что мешает. Например, строительство дома на пустом участке, создание нового приложения, которое не требует множества интеграций в инфраструктуру, производство рекламного ролика или открытие еще одного сетевого магазина в новой локации. В этих случаях действительно можно сделать хороший план и реализовать его с достаточной степенью контроля. Программы и их результаты встраиваются в существующие организационно-технические ландшафты проблем и решений (Халл Э., Джексон К., Дик Д. Инженерия требований. – Litres, 2019.), программы почти всегда реализуются в браунфилд, обременены наследственностью, требуют преемственности и учета существующих интересов наравне с новыми. Утопический замысел создателей встретится с повседневными рутинными практиками и они его раздавят, преобразят и поглотят. В результате любой план является гипотезой, которую надо проверять действием.

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

• Они работают на уровне поставки конкретного продукта, но перестают работать на уровне сложных переплетений всего проекта. Да и на уровне продуктов есть множество проблем с реализацией замысла. Поэтому проектный замысел должен порождаться и реализовываться многими участниками, а не небольшой группой из 2-3 человек (допустим, владелец продукта, руководитель проекта, спонсор), как это происходит в случае PDCA.

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

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

• ----------------------------------------------------------------

• Цикл [[D-RCSA-P]] нацелен на создание решений, которые будут выживать в существующем ландшафте и будут изменять его в нужном направлении.

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

• И если вы думаете, что времени и сил на освоение нового подхода нет, то у меня для вас хорошие новости - скорее всего это время и силы появятся, если вы освоите рутинные практики цифрового минимализма.

• Если вы думаете, что нет технологий, то они есть

• Если вы думаете, что нет курсов, то они есть

• Первый сигнал проблем в проекте - это фраза "Верь мне, я знаю, что делаю"

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

• Я начну со случая, описанного Chris Argyris. Flawed Advice and the Management Trap: How Managers Can Know When They’re Getting Good Advice and When They’re Not, 2000, p.53. Это типовая ситуация, которая знакома большинству из нас, надо только подставить вместо дирекции по ИТ другое подразделение, поставщика или проектную группу.

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

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

• Директор по ИТ созвал совещание, которое начал с того, что:

• а) ДИТ не обеспечивает необходимую поддержку бизнеса

• б) польза от ДИТ минимальна

• в) бюджеты на ИТ постоянно растут

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

• Сотрудники ДИТ ответили ему на это так:

• а) мы уже озабочены потребностями бизнеса

• б) но бизнес сам не знает, чего он хочет

• в) бизнес понятия не имеет, сколько времени занимает реализация их запросов, им все надо вчера

• г) нас задрали их бесконечные жалобы

• д) ресурсов не хватает, мы все перегружены

• Директор ответил на эти реплики следующим:

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

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

• (Директор пытается запустить проект трансформации)

• Его подчиненные ответили тем, что поменять подход руководителей бизнес-подразделений не получится. Один из них сказал директору: "Хотите попробовать сами, да пожалуйста!"

• Директор ответил: "Хорошо, если планировать бесполезно, то что вы предлагаете?"

• Его подчиненные уже на эмоциях повторили:
• а) проблему решить нельзя, потому что бизнес требовал, требует и будет требовать невозможного
• б) ДИТ и так работает на пределе, никакое планирование не поможет. Цитата: "Все стоящие специалисты покидают компанию. Починить это невозможно."
• В конце встречи директор воскликнул: "Мы должны исправить ситуацию потому что у нас нет выбора! Мы не можем называть себя взрослыми людьми, если не можем найти выход из сложившейся ситуации."
• Очевидно, что в этой ситуации все разочарованы, расстроены и не доверяют друг другу. Вследствие этого они строят разговор таким образом, что никакой конструктивный диалог становится попросту невозможен. Например, они делают предположения в отношении руководителей бизнес-подразделений и дают им оценки так, что ничего нельзя проверить:
• Бизнес не знает, чего он хочет.
• Бизнес ставит задачи с нереалистичными сроками.
• Когда мы укладываемся в эти нереалистичные сроки, они требуют еще более нереалистичные сроки.
• Проблему нельзя решить потому что бизнес попросту неисправим.
• Директор с одной стороны хочет, чтобы его подчиненные начали сотрудничать, а с другой не хочет выглядеть несправедливым. В отличие от своих подчиненных он скрывает свои чувства и выглядит спокойным и рассудительным, хотя когда я попросил его написать на листке бумаги свои мысли в тот момент, он зафиксировал следующее:
• Это какой-то детский сад
• Они не понимают, как себялюбиво выглядят их претензии
• Мне иногда хочется вызвать их родителей на серьезный разговор. Им надо повзрослеть или всех нас уволят.
• Когда я спросил его, почему они всего этого не сказал вслух, он удивился: "Это бы только ухудшило ситуацию".
• Что интересно, когда я спросил подчиненных директора, что по их мнению он думал во время этого разговора, они слово в слово повторили все, что написал директор на листке. В реальности ему не удалось скрыть свои мысли и чувства от других.
• Что же произошло? Случилось то, что обычно случается на старте любого проекта. Надо решить две проблемы:
• саму бизнес-проблему, из-за которой и затеяли весь проект, и
• проблему, которая возникла из-за того, что люди защищают свои позиции, не доверяют друг другу, пытаются скрыть это недоверие от других и делают вид, что никакой проблемы в реальности нет и все работают в одной команде на общую цель
• Решение второй проблемы занимает куда большее количество ресурсов, чем решение первой, поэтому нечего и надеяться на то, что целей проекта можно достичь, не решив проблемы с недоверием внутри команды и самообманом.
• Вспомним, с чего все начиналось: бизнес-проблема заключалась в высоких затратах на ИТ и слабых результатах. Все согласились с описанием проблемы, но вот по разному определили причины ее возникновения. Директор по ИТ пошел на встречу с тремя предположениям как провести эффективное совещание:
• Я должен провести совещание так, чтобы мои цели и задачи были выполнены. Мое определение успеха заключается в том, что подчиненные разработают убедительный для моего руководства план по снижению затрат.
• Для меня важно вовлечь подчиненных в разработку плана. Тогда у них будет мотив выполнить его.
• Если подчиненные будут недовольны моими действиями, я должен подавить свои чувства и сосредоточиться на рациональных вещах, например, на разработке плана. Чувствам можно дать волю, когда я останусь наедине с собой.
• Подчиненные думали аналогично. Они чувствовали, что должны предлагать решения. Их определение успеха заключалось в том, что директор должен был понять, что корнем проблемы были руководители бизнес-функций. Кроме того, они считали, что директор должен активнее продвигать интересы ДИТ перед топ-менеджментом. И он считали, что их аргументация была абсолютно рациональной, а голос они повышали только для того, чтобы донести всю важность и серьезность ситуации до директора.
• ------------------------------------------
• Как видим, стратегии директора и его подчиненных были очень похожими:
• Высказаться по поводу ситуации двусмысленно либо противоречиво
• Вести себя так, будто никаких проблем с логикой высказывания нет
• Сделать двусмысленность или противоречивость высказывания необсуждаемой
• Сделать необсуждаемость необсуждаемой.
• Мы часто видим такое поведение, например, однажды топ-менеджер сказал мне следующее: "Мы хотим, чтобы вы были применяли инновационные подходы и не боялись рисков. Мы даем вам свободу действий. При этом, конечно, мы ожидаем, что вы не допустите возникновения проблем или неприятностей для компании".
• Другими словами, все участники этого совещания находятся в режиме модели 1
• 
• Они ставят цели и пытаются их достичь, а не пытаются выработать совместное понимание успеха
• Максимизируют выигрыш и минимизируют проигрыш, а значит, воспринимают любое изменение своих целей как признак слабости
• Не показывают отрицательных эмоций, т.к. считают их признаком некомпетентности, недипломатичности или неспособности справиться с ситуацией
• Рассуждают и ведут себя рационально, остаются объективными, рассудительными и подавляют чувства
• Чтобы достичь этих результатов люди пытаются:
• Выстраивать ситуацию и контекст самостоятельно, с полным контролем происходящего, планировать в секрете от всех, убеждать других в верности своей оценки ситуации
• Владеть повесткой и контролировать задачи
• Защищать себя, выражаться абстрактно и обтекаемо, не упоминать конкретные случаи, скрывать свои чувства и мотивацию
• Беречь чужие чувства и решать самостоятельно, что надо знать человеку, а чего не надо, не давать всю информацию, врать во благо, имитировать благодушие.
• Другими словами, они делают все, чтобы сказать окружающим: "Верьте мне, я знаю, что делаю".
• Но такое поведение не позволяет нам научиться ничему новому. Эксперт - это тот, кто знает все, чему он может научиться, тем более не у других экспертов? А в проектах приходится учить что-то новое по определению, в проектах нельзя быть абсолютно уверенным в своих знаниях и навыках. Поэтому хотя успешная реализация стратегии "Верьте мне, я эксперт" позволяет контролировать ситуацию, сохраняет репутацию и авторитет, за это приходится платить высокую цену - люди воспринимают такую позицию как жесткую, необсуждаемую и мало доверяют людям, которые занимают эту позицию. Проектная группа теряет способность учиться, а вместе со способностью учиться теряет способность сделать проект.
• Модель мышления №1
• Тут надо сказать пару слов про способность к обучению. Люди и организации стремятся к эффективности своих действий. В случае, когда надо сделать что-то нестандартное, выполнить не рутинный проект, люди и организации привлекают консультантов, ученых и опытных менеджеров. И привлеченные специалисты дают советы как поступать в той или иной ситуации, учат команду новому. Советы бывают разными - некоторые выглядят привлекательно, некоторые сомнительно. Но большая часть даже привлекательных, интересных советов нереализуема. Слишком много общих слов, идей, нестыковок и логических скачков. Большинство советов и рекомендаций просто слишком далеки от реальности и их нельзя привязать к конкретному контексту конкретной деятельности.
• Это возникает потому, что в основе этих рекомендаций лежат не выраженные явно, но мощные предположения и гипотезы о том, что такое эффективное действие. И эти предположения и гипотезы, когда их применяют в нестандартных проектных ситуациях, как раз и приводят команду и самих экспертов к неспособности учиться. Эти предположения и гипотезы, Модель мышления №1, делает советчиков слепыми не только по отношению к нестыковкам в своих рекомендациях, но и заставляет их не замечать собственную слепоту. Плохие, нереализуемые советы не есть результат их низкой квалификации. Они просто профессионалы по ошибкам, отточившие свой навык до совершенства.
• И это не голословное утверждение, десятки лет исследований показали, что мы все в массе в основном используем Модель мышления №1. И именно эта модель мышления определяет то, как работает большинство организаций и предприятий. В основу работы изначально заложены шаблоны мастерского игнорирования и профессионального совершения и сокрытия ошибок, прикрытых сверху заведенным порядком, который защищает нас (и в особенности руководство) от последствий ошибок и наказания. Поверх этого всего еще и действует запрет на обсуждение этих шаблонов и заведенных порядков. А поверх этого запрета действует запрет на обсуждать этот запрет.
• И эта организационная слепота:
• а) прекрасно работает
• б) не требует сил и времени на исполнение
• в) принимается за должное (мастерство не пропьешь)
• г) работает на автомате и бессознательно
• Разберем, что же произошло на совещании:

• Как видим, обе стороны включили Модель мышления №1, настаивают на верности своей позиции, не слышат и не видят другую сторону. Стратегия "по умолчанию" работает.
• Высказаться по поводу ситуации двусмысленно либо противоречиво
• Вести себя так, будто никаких проблем с логикой высказывания нет
• Сделать двусмысленность или противоречивость высказывания необсуждаемой
• Сделать необсуждаемость необсуждаемой.

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

• 
  
  

  Но прежде, чем мы перейдем к изучению цикла исследования действием [[D-RCSA-P]] применительно к управлению проектами, нам надо развенчать основной миф проектного управления, нашу основную анти-компетенцию. Главный миф проектного управления - нам нужен какой-то подход или инструмент для планирования и контроля исполнения проектов. PMBOK, Agile, канбан, Скрам, SAFe, MS Project, JIRA, Trello, Wrike. Проблема не в планировании и не в коммуникации и не в подходах. Проблема в том, что мы не умеем читать, понимать и исполнять даже свои проектные планы, не говоря уже о планах, которые частично или полностью составили другие. Мы обращаемся с планами проектов точно также, как с планами покупок в магазинах, планами поездок, планами продаж и графиками выхода на работу. Да, планы регулярной, рутинной деятельности очень-очень похожи по виду на проектные планы. Но работать с ними надо кардинально по-другому, там свои лайфхаки.

4 шага системного подхода в управлении проектами. Шаг 4 - Культура организации.

 

ЯЗЫК, ДИАЛЕКТЫ И КУЛЬТУРА ОРГАНИЗАЦИИ

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

Почему чаще всего не получается выстроить хорошо работающий стратегический проектный офис?

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

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

Когда я стал работать на стратегическом уровне, то заметил, что форма стратегической работы везде была примерно одинаковая. SWOT, PEST, дорожные карты, карты рисков, дизайн-мышление, интеллект-карты и тому подобное. А вот наполнение этих форм было принципиально разное. В одних случаях, информация сильно влияла на принимаемые решения, а в других это был просто информационный мусор. Важно научиться отделять одно от другого. На первом этапе сделать это нелегко, ко мне этот навык пришел после множества ошибок, неудачных совещаний и безрезультатных рабочих сессий.

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

Параллельно с выстраиванием стратегического проектного офиса я продолжал консультировать компанию, которая разрабатывала систему отчетности (я рассказывал про нее в предыдущем ролике). Интересно то, что у них похожая задача получилась куда лучше. Что же они сделали по-другому, почему это привело к результатам, и как я перестроил свою работу с портфелем стратегических проектов с учетом их опыта?

КЕЙС

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

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

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

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

СУТЬ ПРОБЛЕМЫ

Проблема заключалась в непонимании, отсутствии общих целей и сложностях в интеграции процессов различных подразделений в дивизионе. Ее емко выразил основатель компании, и в последующем руководитель нового департамента: “Разные бизнес-функции говорят на разных языках, и мы не понимаем друг друга”.

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

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

Для решения проблем коммуникации внутри больших компаний появились инструменты стратегической коммуникации - SWOT, business canvas, wardley maps, PESTLE, инструменты дизайн-мышления и куча других. Все это поддерживается отличными инструментами - от Miro и Mindjet Mindmanager до корпоративных решений типа BizzDesign HoriZZon и Orbus EA.

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

РЕШЕНИЕ

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

Шаг первый

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

Такой язык называется, только не пугайтесь сложного термина, инженерной онтологией. Если вы будете искать что это такое на русском, то попадете на философское толкование этого термина. Это не то. То, что вам нужно, должно быть похоже на примеры с сайта https://www.w3.org/community/groups/

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

Шаг второй

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

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

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

МЫСЛИТЕЛЬНЫЙ ХОД

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

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

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

В ЧЕМ ПОЛЬЗА

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

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

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

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

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

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

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

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

ЧЕМУ НАДО УЧИТЬСЯ?

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

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

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

ИНТРИГА

Это и есть четыре элемента системного мышления - функция, контекст, имплементация и культура организации. А пятый элемент - это вы. И если вы хотите научиться применять эти навыки на практике для успешного ведения проектов, мы ждем вас на вебинаре, который пройдёт 20 августа в 13:00. Подписывайтесь на мой канал, ставьте лайки и пишите свои вопросы в комментариях, я обязательно на них отвечу. Ждем вас, всего доброго.

4 шага системного подхода в управлении проектами. Шаг 3 - Имплементация.

 

Почему SMART-целеполагание в проектах само по себе не работает и как это исправить?

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

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

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

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

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

КЕЙС “IT-система для линейки шоколада”

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

У меня был клиент — компания по разработке заказного софта.

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

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

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

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

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

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

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

ПРОБЛЕМА

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

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

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

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

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

И в этом была его ошибка и стратегический просчет.

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

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

РЕШЕНИЕ

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

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

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

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

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

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

Но для начала можно обойтись и типовой.

Практика применения схемы фокусов внимания опирается на несколько умений и навыков:

- умения вовремя задавать полезные и правильные вопросы во время совещаний;

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

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

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

РЕЗУЛЬТАТ

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

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

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

ЦЕЛЬ СХЕМЫ ФОКУСОВ ВНИМАНИЯ

Схема фокусов внимания работает на имплементацию. Ее главная цель — осуществить стратегический замысел проекта.

Чем имплементация отличается от реализации? 

В проекте есть цели и замысел. Цель — это заработать миллион долларов, замысел — стать счастливым. Цели статичны, их достигают или нет, все однозначно. Замысел динамичен, подвижен, он имплементируется - осуществляется всегда лишь в какой-то степени и никогда на 100%.

Имплементация — это осуществление замысла. Реализация — достижение цели.

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

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

КАК ОСВОИТЬ СХЕМУ ФОКУСОВ ВНИМАНИЯ?

Наиболее распространены две схемы фокусов внимания. Первая — классическая схема 7 фокусов внимания, зафиксированная стандартом OMG Essence, вторая — расширенная схема 9 фокусов внимания авторства Школы системного менеджмента.

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

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

ИНТРИГА

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

Но как это сделать и с чего начать?

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

И ответ на вопрос как это сделать и с чего начать будет в следующем ролике “ЯЗЫК И КУЛЬТУРА ОРГАНИЗАЦИИ”.

4 шага системного подхода в управлении проектами. Шаг 2 - Контекст.

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

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

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

- В смысле? - я стремительно перебирал в голове варианты где и что я не учел.

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

- Но в техническом задании сказано сделать именно так! - ответил ему я.

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

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

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

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

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

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

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

КЕЙС

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

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

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

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

Я стал искать помощи. В конструкторском отделе сидел опытный инженер-конструктор, который собаку съел на проектировании, ЕСКД, ЕСТД, СПДС и ЕСПД. Я отправил ему техническое задание с комментариями заказчика ему и попросил помочь. Он позвонил уже через полчаса и предложил подойти к нему.

СУТЬ ПРОБЛЕМЫ

При встрече эксперт сказал такую штуку.

- Вы в вашем ТЗ постоянно пытаетесь описать то, как система будет устроена внутри. Не надо так делать. Представьте ее “черным ящиком” и представьте, что вы продаете этот “черный ящик” заказчику. Кто у вас заказчик - агрокомбинат? Ну вот, у них уже есть работающая теплица, которую вы оснащаете своей системой. Что эта система делает, когда ее внедряют в тепличный комплекс? С какими частями тепличного комплекса она связывается, к чему подключается, какие параметры этих подключений?

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

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

- Вот это называется “контекстная диаграмма”, без нее лучше никакое, даже самое простое техническое задание не делать, - напутствовал меня он. - А по шаблону ТЗ лучше не делать никогда, понимаете? Все проекты уникальны, и если у вас нет по-настоящему похожего по контексту использования примера технического задания, то надо разрабатывать документ с нуля, а не пытаться натянуть применение на имеющийся неподходящий шаблон.

РЕШЕНИЕ

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

МЫСЛИТЕЛЬНЫЙ ХОД

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

В ЧЕМ ПОЛЬЗА

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

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

ЧЕМУ НАДО УЧИТЬСЯ?

Чтобы правильно, полно и точно описывать контекст, надо учиться 3 вещам:

- моделированию предметной области, 

- анализу контекста, 

- построению объяснительных и предсказательных моделей. 

Я описываю контекст в четыре шага.

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

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

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

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

ИНТРИГА

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

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

4 шага системного подхода в управлении проектами. Шаг 1 - Функция.

 

Откуда берутся цели проектов?

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

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

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

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

КЕЙС

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

СУТЬ ПРОБЛЕМЫ

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

РЕШЕНИЕ

Споры не прекращались, пока я не предложил оставить оба регламента. Эффективный и длинный для "старичков", кто работает давно, и короткий и медленный для всех остальных. И заказы делить на срочные и не очень. Допустим, молочку и другой скоропорт возить по быстрому регламенту, а крупы и сахар по медленному.

МЫСЛИТЕЛЬНЫЙ ХОД

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

В ЧЕМ ПОЛЬЗА

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

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

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

ЧЕМУ НАДО УЧИТЬСЯ?

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

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

ИНТРИГА

Остаётся только один вопрос - а откуда приходят требования? Откуда мы знаем, какую функцию надо делать - быструю или компактную? Ответы на эти вопросы будут в следующем ролике “Контекст”. Подписывайтесь на мой канал, ставьте лайки и пишите свои вопросы в комментариях, я обязательно на них отвечу.