Поток в проектной деятельности. Типизация и балансировка

В среде интеграторов и проектно-ориентированных организаций часто встречается явление, известное как «проектные качели»: то делать нечего, то делать некем.

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

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

Итого:

• первая проблема – нет ритмичности;

• а вторая проблема – нет повторяемости.

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

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

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

 

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

 

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

• разобраться с заказчиком, понять его текущую ситуацию;

• отработать входящие требования и ожидания (зачастую это про разное);

• продумать будущую архитектуру и базовую концепцию реализации;

• сделать оценку проекта – какие ресурсы необходимы, рассчитать трудоемкость, риски, длительность, стоимость.

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

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

При этом в процессе работы над проектом происходят постоянные изменения:

• изменения в предметной области;

• изменения рамок проекта;

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

• смена постановщиков задач или, что еще хуже – изменения среди спонсоров проекта;

• и еще могут быть провокации со стороны партнера-интегратора – например, выдергивание ключевых специалистов на другие проекты, в которых «загорелось», то самое обескровливание текущего проекта;

• а еще и постоянно изменяется внешняя обстановка по отраслям – у заказчиков, у компаний-интеграторов или у партнеров.

Тема не гибкая, не управляемая, требует суперквалификации, суперресурсов – вы работаете с этими уникальными проектами в режиме пожарника, без конца тушите пожары.

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

 

 

Взамен, естественно, хочется:

• Перейти от пожарника к менеджеру, более спокойно жить – планомерно работать и не думать про постоянные авралы.

• Работать не с набором уникальностей, а с набором типовых историй.

• Иметь плановые объемы работ с пониманием, в какой период времени они приходят.

• И возможность еще управлять этой ритмичностью.

Таким образом, нужен:

• качественный переход от потока уникальных запросов к управляемому потоку запросов;

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

 

Аспекты проектной деятельности

 

 

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

1. аспект заказчиков;

2. аспект решений, которые выдаем заказчикам;

3. аспект проектных команд;

4. аспект балансировки этого всего.

 

Заказчики

 

Работу с заказчиком можно поделить на две основные части:

• работа с потоком запросов;

• и далее – индивидуальная работа с каждым заказчиком:

  • в предконтрактной стадии – на пресейле;

  • в проектной стадии – при разработке проекта;

  • и после проекта – если мы оказываем техподдержку или сервис.

 

 

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

Основное:

• Внутри компании заказчика (а еще сложнее это сделать в холдинговой компании), нам нужно найти именно то конкретное физическое лицо (а иногда группу лиц), кто является истинным заказчиком проекта. У него есть разные названия: спонсор, инвестор, ЛПР и т.д.

• Далее мы должны понять, что конкретно нужно этому ЛПР, каковы его ожидания. Он может ожидать от нас намного больше, чем просто установленное программное обеспечение.

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

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

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

 

Типизация входящего потока запросов

 

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

Но для этого компании нужно специализироваться, потому что, если говорить про проекты 1С, на рынке бывают компании:

• всеядные, которые могут, готовы и хотят делать любые объемы работ на проектах в любых направлениях с любыми заказчиками от мала до велика;

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

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

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

 

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

• Мы для себя просегментировали заказчиков:

  • по видам деятельности. Например: НИПИ (научно-исследовательские проектные институты), инжиниринг, девелопмент, приборостроение, судостроение и так далее;

  • по масштабу компании от оборота и от численности: SMB, Enterprise и холдинговые компании;

• Далее мы классифицировали потребности организации, разделили их на накопленные или новые практики.

• И для каждого целевого сегмента заказчиков, с которым мы знаем, что делать, подготовили УТП (уникальное торговое предложение).

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

Годовые планы формируются, исходя из связки с производством и продажами. Здесь очень важно, что это взаимное обязательство между руководителями, которые на основании планов берут на себя обязательство их выполнить. Потому что конкретные договоренности между людьми – это очень важно. Итого, работает связка:

• производство проектов – техподдержка и сервис;

• продажи – производство проектов;

• продвижение – продажи;

• и в нашем случае еще продукт (разработка отраслевого решения) – продвижение.

Для внутренних интеграторов, работающих внутри холдинга, продвижение не так важно.

И на всем этом строится процесс контрактации и производство сервиса.

 

В результате проработки входящего потока запросов мы получаем:

• понимание, где наше предложение соответствует рыночным потребностям;

• анализ «серых зон», где наше предложение не подходит – либо там рынок не проработан, либо наше предложение не проработано;

• оценку рынка – ту самую сегментацию заказчиков, про которую я говорил;

• в результате получается управляемый объем правильных заказов на входе в производство, который имеет:

  • плановость;

  • и понимание, когда нужно «подруливать», когда что-то пошло не так – объемы выпадают или, наоборот, приходит больше, чем нужно.

 

Решения

 

 

Далее – типизация решения.

Решение – это то, что в итоге мы даем заказчику.

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

Но на входе, чтобы получить решение, нужны:

• Продукт – его типовая функциональность

• Проект для внедрения и запуска продукта

• И, кроме этого, еще есть различные модели.

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

Что здесь можно типизировать?

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

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

• Модели мы унифицировали в разных видах, поскольку иметь на входе к конкретному заказчику референсную модель по процессам – это всегда хорошо.

• И эффекты – накопление практик реальных эффектов, получающихся после эксплуатации проекта, например, через 3-5 лет. Это очень интересно и круто.

 

 

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

Обычная схема взаимодействия в ходе жизненного цикла проекта:

• предконтрактная работа – выявление потребностей и дорожная карта проекта;

• сам проект – реализация целей заказчика и результаты конкретного проекта;

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

 

В компании UNK после 5 лет эксплуатации продукта «1С:ERP+PM Управление проектной организацией 2» это были следующие эффекты:

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

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

• разные стандарты – они сформировали пакет стандартов, куда входят: регламенты, процессы, правила действия, какое программное обеспечение надо использовать и много другого;

• все это используется для самого главного – успешного масштабирования на новые компании. Компания входит, получает пакет стандартов и через 2-3 месяца начинает работать, не разбираясь с тем, как же им все это выстроить. Круто – быстрый старт новых бизнесов! Масштабирование работает.

 

 

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

 

Типизация функциональных блоков продукта. В 1С:ERP+PM Управление проектной организацией и 1С:УНФ+PM Управление проектной фирмой мы типизируем функциональные блоки по сложности внедрения – Базовая, ПРОФ, КОРП. Взяли знакомые слова, но применяем их для другой логики:

• Базовая – блоки функциональности на схеме зеленого цвета. Когда учет по проектам в компании очень простой, достаточно внедрения только этих функциональных блоков – тогда в 90% случаев доработки конфигурации не нужны

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

• И КОРП – розово-фиолетовые блоки функциональности. Это экспертная функциональность, где однозначно нужно анализировать данные на входе, методики и так далее.

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

 

 

В зависимости от типизации функциональных блоков делим свои проекты по степени внедрения на Базовые функции; Проф. функции и Экспертные функции.

И условно выделяем типы проектов:

• «Кейс»;

• «Проф»;

• «Заказной»;

• «Корпоративный».

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

 

 

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

 

 

По каким характеристикам проводится параметризация расчета проектов.

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

  • моделирование системы и подготовка базы – это фикс;

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

• В ПРОФ-проектах помимо стоимости моделирования и обучения пользователей расчет проекта зависит также от:

  • сторипоинтов по ПРОФ-функциональности. От нормы по одному сторипоинту мы можем рассчитать плановую трудоемкость проекта по этапам: сбор требований, постановка задачи, доработка, запуск.

• И КОРП-проекты. Здесь помимо вышеперечисленного появляется еще:

  • КОРП-функциональность;

  • методические решения и консалтинг;

  • здесь может быть большая доработка системы, и всегда есть желание разделить эти проекты отдельно: отдельно консалтинговая часть, отдельно проекты разработки, запуска, внедрения;

  • из-за масштаба системы возникает потребность в нагрузочном тестировании и оптимизации производительности;

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

  • еще важная история – КОРП-заказчик. У холдингового заказчика могут быть внутренние противоречия: у управляющей компании одни цели, а у ДЗО, в рамках которого делается пилот, – другие цели; возникают противоречия;

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

 

 

Взгляд на проекты. Мы делаем несколько взглядов на проекты.

Взгляд со стороны руководителя проекта – это структурная декомпозиция работ по проекту и актируемые этапы.

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

 

 

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

 

 

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

Таким образом мы имеем взгляд на проект и проектную продукцию с двух сторон.

 

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

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

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

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

• Итого: можно выстроить технологичный конвейер по выполнению проектов.

 

Проектные команды

 

 

В командах есть:

• soft skills – это такие прекрасные и высокие вещи, как боевой дух и взаимодействие (с заказчиком, внутри организации и внутри команды) оставим за рамками рассмотрения.

• И есть то, что можно типизировать – это структура команды и компетенции.

 

Типовые роли проектной команды. Мы для себя выделяем:

• Функциональный архитектор;

• Технический архитектор;

• Аналитик;

• Программист;

• Руководитель проекта.

 

 

На конференции Infostart Event 2018 я делал доклад про матрицу грейдирования, как мы это выстраивали у себя. Сейчас просто скажу, что мы для разных видов проектов выделяем у себя по матрице грейдов разные команды.

Например, кейс-проект:

• В роли РП – РП-администратор третьего грейда

• И системный аналитик второго грейда.

Такого состава команды для кейс-проекта достаточно, справятся.

 

 

Для ПРОФ-проекта другой состав:

• Старший программист – третий грейд.

• РП-администратор – третий грейд.

• Старший системный аналитик – третий грейд.

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

 

 

КОРП-проект:

• РКП (руководитель корпоративного проекта) – пятый грейд

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

• Среди разработчиков и аналитиков работает третий уровень.

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

 

 

Результаты по типизации команды:

• Мы понимаем потребности в компетенциях на разных уровнях.

• Понимаем, какие проекты можем взять по текущей загрузке.

• Понимаем, как можем расти.

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

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

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

• на первом уровне он еще ученик;

• на первый проект он привлекается на условиях, что 30% инвестиций идут в его время, которое не приносит результатов;

• на втором проекте он уже работает наравне с аналитиками 3-го грейда;

• и после третьего проекта мы рассматриваем для него повышение грейда.

 

Баланс

 

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

Здесь наша задача – обеспечение долгосрочной сбалансированности продаж и производства, проектной загрузки и ресурсов.

 

 

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

Мы создаем:

• профиль портфеля;

• делаем оперативное планирование;

• и среднесрочное планирование – на 12 месяцев вперед от текущей даты.

 

 

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

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

Сначала мы загружаем портфель большими проектами, потом – проектами поменьше, потом – маленькими.

Итого, мы для себя по профилю приняли следующее выстраданное решение:

• КОРП-проектов должно быть в портфеле не более половины,

• ПРОФ-проектов – 30-40%.

• КЕЙС-проектов – не менее 20%.

Это разделение дает нам возможность балансироваться и расти.

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

 

Результаты по балансировке проектов в портфеле:

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

• Понимаем, что КОРП-проекты – это не всегда хорошо. Иногда хорошо, очень интересно, очень драйвово, а иногда надо приостановиться.

• Понимаем, как этот конкретный профиль позволяет нам расти.

• Понимаем целевые проценты типов проектов в объемах контрактации и лидогенерации, которую мы делаем в своих планах.

• Оцениваем и балансируем риски портфеля от типов проектов. Риски по проектам не должны зашкаливать – пусть в текущей ситуации хотя бы проектные риски будут управляемыми.

 

Кратко про среднесрочное планирование:

• у нас есть портфель проектов;

• мы по нему строим тематический план – в зависимости от текущих проектов и от заказов с процентами вероятности;

• далее переходим к такой кривой, как здесь показано, и по ней работаем.

 

На процессах планирования не буду подробно останавливаться

 

 

В итоге мы в системе работаем с таким дашбордом .

• Нам нужно попасть в целевой горизонт планирования – у нас есть прогноз «Минимум», «Максимум» и «Реалистичный».

• Смотрим плановые объемы выполнения накопительно по месяцам: «Законтрактованные» и «Перспективные».

• Смотрим, что с загрузкой по конкретным ролям.

Это пример для инжиниринга, но мы примерно так и работаем.

 

 

Еще естественно, есть регулярные планерки:

• как внутри проектов;

• так и проектные совещания по организации.

 

 

На проектном совещании мы синхронизируемся по статусам:

• выделяем конкретные ресурсы;

• контролируем, что у нас по факту.

 

 

Можем мониторить загрузку по конкретным специалистам на разных проектах.

 

 

В отчете «Анализ бюджета проектов» смотрим бюджет движения денежных средств, актирование – что с актами, выполнение работ – фиксируем риски, и так далее.

 

 

Общие проектные совещания дают нам возможность:

• синхронизироваться по компании;

• держаться ритма по проектам – по организации в целом и по портфелю;

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

 

Заключение

 

 

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

 

 

Вспоминая еще раз проектные качели – то делать нечего, то делать нечем.

В противовес можно выстроить управляемую проектную деятельность:

• типизировать входящий поток проектов по аспектам, о которых поговорили;

• обеспечить объемы – столько, сколько нужно;

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

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

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

Успешных вам всех проектов, берегите себя и близких.

 

Вопросы и ответы

 

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

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

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

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

Здесь все зависит от того, какой был договор.

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

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

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

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

Еще можно посмотреть, есть ли человек над этим человеком – можно ли выйти на него и можно ли поговорить, чтобы они все-таки вспомнили ценность проекта, попробовать его реанимировать.

Наша компания по вашей классификации – всеядная. Но лично мое мнение – надо переходить на те рекомендации, о которых вы говорите. Можете порекомендовать какие-то ближайшие первые шаги – как двигаться в этом направлении?

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

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

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

И еще влияет то, какая внутренняя культура у вас в организации.

 

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event 2022 Saint Petersburg.