Активная реклама и положительный опыт передовых игроков на рынке поспособствовали тому, что у множества компаний появилось желание перейти на проектное управление. Негативный опыт реже публикуется и распространяется, тем более что критика зачастую воспринимается как субъективное и недостаточно исчерпывающее мнение.
Проектный менеджмент – это не «вакцина»
В этом деле недостаточно один раз привиться и ожидать эффекта. Project-менеджмент – это прежде всего иная культура взаимоотношений и взаимодействий, плюс это методологии, инструменты и подходы.
Внедрение проектного управления обычно связывают с параллельным или предварительным обучением лидеров и команд. Учащиеся приобретают новые знания на тему качества, сроков и бюджетов, которые присущи любому проекту как некие ограничения. Но мало кто критически осмысляет, что проект – это прежде всего деятельность, а у деятельности совсем иные ограничения: бизнес-модель, команда и среда. Под средой тут понимается сложившаяся культура в компании, а также условия, в которой осуществляет деятельность.
В результате обучений и внедрений фокус внимания команд начинает смещаться с деятельности на продукт. Почему на продукт, если речь о проекте? Потому что качество, сроки и бюджеты – это продуктовые характеристики. А как может быть «качественной» деятельность, проект – непонятно и даже спорно.
Что важно учитывать при переходе на проектный менеджмент
Фокус внимания не должен смещаться, и за этим важно следить. Он должен расширяться, охватывая и деятельность и продукты. При переходе на проектный менеджмент мало в каких компаниях занимаются планированием командного состава и средой будущего проекта. Вообще компетенции планирования очень дефицитны на рынке, чаще всего планирование ограничивается составлением бюджета на основе исторических данных или данных с рынка, без учета ограничений и допущений. Не говоря о том, что и планирование и исполнение бюджетов может быть вариативным. Какие команды планируют и контролируют исполнение бизнес-модели проекта? А кто-то вообще занимается планированием качества будущего продукта? На эти вопросы сложно ответить.
Компании, которые анализируют процесс трансформации, реже сталкиваются с негативными последствиями из-за смещения фокуса внимания. Они начинают активно пересобирать команды, формировать среды (информационные и физические), менять модели в зависимости от специфики продукта и прочих условий. Остальные же компании влетают в условия конфликтов между так называемыми «процессниками» и «проектниками». Эти конфликты растягивают время трансформации, появляются «жертвы режима» и иногда принимается решение о приостановке процесса трансформации.
Настойчивые компании пробуют вновь и вновь, меняя составы лидеров и экспертов, цели и задачи, в надежде, что в этот раз получится (авось). Иногда в основе перехода на проектное управление лежит просто желание соответствовать лидерам рынка, которые «смогли» и щедро делятся историями успехов. Такие истории звучат красиво, но не всегда содержат исчерпывающую информацию, которая позволяет взять и просто повторить. Чужой успех, а иногда и собственный, не всегда получается повторить. Дьявол, как всегда, кроется в деталях.
Решение о переходе на проектный менеджмент должно быть осмысленным
Как минимум, нужно отчетливо понимать, зачем это? Осознать, что это нужно для роста и развития компании. Оценить и зафиксировать ROI от поэтапного внедрения. Мерить результаты в конце ненадежно. Анализ текущей деятельности должен стать предтечей для будущих решений. Порой достаточно внедрить отдельные элементы или инструменты проектного управления, и тем самым достичь желаемых результатов. Но опять же, для этого важно анализировать свою деятельность, наблюдать и анализировать деятельность лидеров, формировать гипотезы в т.ч. через инновации.
Условия, которые должны выполняться при переходе на проектный менеджмент
- Создание масштабируемой модели команды в зависимости от сложности проекта, объема и его удаленности.
- Формирование портрета каждого участника команды, для эффективного поиска на рынке и подготовки кадров внутри компании.
- Разработка модели ответственности в проектах (кто? за что? перед кем? чем отвечает?).
- Разработка модели внутренней и внешней коммуникации (включая получение информации, ее обработку, анализ и выдачу).
- Создание модели сводного планирования (увязка действий и ресурсов в проекте и между проектами).
- Создание взаимоувязанной системы контроля соблюдения бизнес-моделей, эффективности команд и условий среды.
- Создание взаимоувязанной системы контроля выполнения сроков и бюджетов, достижения качества.
- Внедрение экономического образа мышления у команд (сценарии реализации, ответственность и управление статьями бюджетов, итерационное планирование и освоение объемов).
Также читайте:
Как Вы считаете, кому BIM важнее - финансистам или строителям? На данном этапе и зная то, что Вы уже об этом знаете.
Важнее и выгоднее проектировщику и девелоперу, который набирает серии и их повторно использует. Строителям тоже может быть выгодно, но нет запроса, поэтому и работают с бумажными версиями
На мой взгляд, дело не в классических СЭД. Я работал в госструктуре, там таких систем сейчас довольно много, они ориентированы на документооборот в масштабах департамента, управления. СЭД однозначно помогает контролировать исполнеие поручений. Согласование, ответы гражданам, решение текущих вопросов она не включает. Ну и финансовые движения упрощает значительно.
После этого работал в больших проектах в нескольких коммерческих ООО. Типичный набор - мессенджеры, аутлук, где-то Jira. Облачное хранилище почти везде, но кто-то использует, например, яндекс-диск. Ни где я не видел относительно приличной СЭД, которая позволяла бы, например, согласовывать документы. Гораздо проще это делать через корпоративное облако. Но сверху этого накладывают массу договорённостей с версионностями, с архивированием, поиском.
Поэтому я бы вёл разговор не о СЭД, а именно об электронной модели в проекте. Но по моей оценке это такое сверхмасштабное мероприятие, что проще ничего не делать и работать по-старому.
Тут я согласен с Дмитрием:
Но как совместить BIM и ту же госэкспертизу я пока не знаю.
Такие вопросы и ответы предполагают изменения на уровне законодательства и регулятора.
Скажем, кое-где в медицине такое есть - и не первый день. И там в правилах и протоколах всё чрезвычайно жёстко. Стандартные системы, версии ПО и пр. и пр.. Тем не менее, серые зоны остаются.
Пожалуй, Вы правы!
В принципе можно понять правительство - в какое-то время нужно было приводить в порядок строительтство. Была куча самостроя, Смотрите в Подмосковье - строили многоквартирные дома на дачных участках, общежития и торговые центры в охраняемой зоне. Все ведь знают борьбу жителей, например, города Пушкино с застройкой речки Учи. Раньше купался весь город, но потом всё загородили заборами, построили коттеджи и распродали. Город судился, но всё бестолку.
Но и надо уточнить - госэкспертиза не требуется на безопасных объектах. Но застройщик чаще всего перестраховывается и подаёт документы на госэкспертизу, а потом при малейшем изменении - на повторную. Хотя ГК этого не требует.
Думаю что BIM сейчас станет востребованнее, на фоне внедрения цифровых моделей городов.
Анатолий, традиционно очень содержательный комментарий! Глаз зацепился за реплику
Часто слышу эту формулировку и у меня создается впечатление, что в ней противопоставляется проектное управление и процессное управление. ... (как будто проект это что-то несистемное, спорадическое и люди не понимают - а как это "броуновское движение" можно планировать?) и каждый раз мое подсознание возмущается, ведь сама по себе PMBoK это и есть ПРОЦЕССНАЯ модель управление проектом! Тогда, как может процессный принцип противопоставляться самому себе? Не может... Наверное это удобный момент, чтобы устранить эту коллизию... Если мы избавимся от нее, то автоматически избавимся от производных недоразумений и путаниц. Где-то прочел, может даже в одной из редакций PMBoK, о том, что вся деятельность человека делится на ОПЕРАЦИОННУЮ и ПРОЕКТНУЮ. И обе они управляются процессами: процессами операционной деятельности и процессами проектной деятельности. И когда мы установим такую терминологию, тогда цитируемая фраза прозвучит так: "Можно долго рассуждать о проектном и операционном подходе." А следовательно, если операционные процессы можно планировать, то могут быть запланированы и процессы проектного управления. ... только приемы планрования немного другие... И, конечно, всегда меньше недоразумений (споров и возражений) там, где вещи называются своими присущими именами, а не обзываются иносказательно...
Я и предлагаю пользоваться этими терминами.
не претендую на истину, но у меня убеждение, что все началось с речи Сталина в 1931 году "«Мы отстали от передовых стран на 50-100 лет. Мы должны пробежать это расстояние в десять лет»". С этого призыва и сформировался запрос в т.ч. и на управленческие кадры высочайшего уровня, т.к. невозможно ускориться в 5 - 10 раз без централизованного высокоэффективного управления именно в проектной деятельности. Только в результате проектной деятельности вновь появляются производственные активы, которые затем передаются в эксплуатацию (операционную деятельность). К тому же за рубежом разные "упражнения" по оптимизации деятельности велись в рамках своего бизнеса, а в СССР в рамках всей экономики. И это очередное достижение мирового уровня.
Спасибо за оценку!
Нет, я не противопоставляю проекты и процессы, ни в коем случае. Я даже напишу оспариваемую многим вещь. Проекты состоят из планируемых процессов. Я убеждён в этом и этому меня учили, правда очень давно.
Я-то занимаюсь ИТ, у нас как-то гораздо логичнее любой проект начинать с планирования или анализа процессов, с чёрного ящика. Я сторонник того, что не бывает оторванных процессов. Не бывает частично используемых методик. Я бы многим рекомендовал уже забываемый IDEF0.
Ведь самое ужасное, что вот к примеру эджайл всех сбила с толку и разработчики стали любые свои промахи, непродуманности сваливать на "гибкую методику". А надо бы взять классический айдеф, посидеть, "расширить и углубить" и затем зафиксировать хоть в каком-то первом варианте. То есть мы закрепим процессы, кторые мы видими или хотим видеть. Из них родится проект.
Так что Вы правы! Я согласен с вами насчёт единства проектного и процессного управления.