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 месяцев, выглядело непозволительной роскошью.

РЕШЕНИЕ

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

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

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

В ЧЕМ ПОЛЬЗА

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

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

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

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

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

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

ИНТРИГА

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