Самое странное, с чем мне приходилось иногда сталкиваться в девелоперских компаниях (работая внутри и консультируя их снаружи), – это невысокий уровень проектного мышления и управления. К сожалению, это весьма несложное знание нельзя получить в школе, и очень редко оно дается в вузах. Проектное мышление – необходимое условие для достижения целей, а проектное управление – необходимый инструмент.
Инвестиционно-строительные (ИСП), или девелоперские, проекты – пожалуй, одни из самых сложных в сфере недвижимости. Сложные, потому что они очень высокорискованные, то есть выполняются в окружении высокой неопределенности и конкуренции. Неопределенность тем выше, чем длиннее проект. Длительность также оказывает влияние на способность команды проекта выдержать весь путь. К этому добавьте высокую капиталоемкость, значительную зависимость успеха от неопределенной коммерческой составляющей. Как правило, в ИСП вовлечены сторонние интересы (например, участие банка, города, землевладельца, местного населения), которые нельзя игнорировать. Короче говоря, все это понимают, и кого ни спросишь – все говорят о проектной основе как сути организации и о проектном управлении, но видно, что проектное управление и мышление почти отсутствуют.
В различных системах есть до 40 разных аспектов управления проектом. Принципиальные для ИСП – это:
Устав проекта, иначе говоря, описание проекта, где сформулированы цели, описан ожидаемый результат, дана оценка необходимых ресурсов – денег, специалистов (компетенций), дан общий план развития, главные вехи, перечислены главные риски и ожидаемый финансовый результат. Для ИСП это описание типа комплекса, места, где он будет построен, оценка расходных и доходных бюджетов и необходимой команды, приблизительные даты завершения основных этапов, финансовая оценка по грубой модели и перечень главных рисков. Уже этот основной документ, который может дорабатываться и уточняться, частенько отсутствует у компании, хотя это не только инструмент контроля проекта, но и гарантия правильной коммуникации между членами команды, а главное, между различными уровнями иерархии, где обычно и теряется управляемость.
Команда проекта. Ясно, что, так или иначе, в компании она существует. Однако насколько она формализована? Как хорошо члены команды проекта знают свою зону ответственности, способы передачи информации коллегам, свои функции в согласовании и утверждении параметров проекта из смежных зон ответственности? Как этот коллектив сопряжен с административной структурой компании? Утверждены ли команда и распределение ролей приказом по предприятию, или всем «и так все ясно»? Проблемы начинают нарастать как снежный ком, когда в компании ведется параллельно несколько проектов. Методика проектного менеджмента, заточенная на ИСП, разрешает эти вопросы.
Деньги. Как правило, в проектном управлении следить за деньгами – значит, контролировать, прогнозировать и оптимизировать бюджет, то есть затратную часть. Расходы в компаниях учитываются, но вот способ учета часто не позволяет принимать вовремя управленческие решения и реагировать на слабые негативные сигналы, предупреждающие об опасности, – их просто не разглядеть. Правильно структурированный бюджет инвестиционных и операционных затрат и процедуры по его формированию и авторизации расходов помогают не просто иметь план/факт перед глазами, но и своевременно (делая постатейный прогноз и соотнося с продвижением работ) корректировать работу менеджера проекта, помогая ему принимать более осознанные решения и контролировать их сверху.
Финансы. Это даже больше про деньги. Ведь инвестиционно-строительный проект без доходной части – это просто строительный проект, значительно более определенный и менее рискованный, – речь не о нем. Формирование доходной части – это один из самых важных подпроектов, требующий своего ответственного менеджера и своей дорожной карты. Кроме этого, баланс доходов и расходов для инвесторов и банков сводится к расчету различный инвестиционных, финансовых показателей, таких как IRR, прибыль и т.д. Без контроля расходов, доходов и финансовых показателей успешный проект быстро и незаметно залезает в «красную зону».
Время. Аспект времени вообще отличает проект от процесса. У проекта есть начало и конец, есть продолжительность, он конечен и единичен. Более того, расходы и доходы проекта, растянутые во времени, согласуются не просто в столбик, а более сложным методом, учитывающим в своей математике время, а точнее, стоимость денег, зависящих от времени и рисков. Контроль проводится на самом верхнем уровне с помощью распределенных по оси времени вех, которые отмечают завершение неких существенных этапов или наступление событий, без которых дальнейшее развитие проекта невозможно или сильно затруднено. У существенных событий есть вполне четкие критерии их наступления. Кроме этого, они знаменуют собой переход объекта инвестиций в некоторое новое состояние, которое характеризуется исключением группы рисков. Таких главных вех в девелоперском проекте может быть 8-15, не больше. Самые главные из них при наступлении определяют новый продукт, который можно оценить и продать, а главное, передать. Одновременно они становятся опорой для формирования системы проектной мотивации команды.
Риски. Этот аспект управления проектом позволяет прогнозировать отрицательные события, минимизировать их влияние или вообще предотвращать их реальное наступление или проявление. Есть простая, связанная с другими аспектами управления методика их предсказания, оценки влияния и контроля, которая позволяет существенно улучшить качество принятия решений. В текущем, незавершенном состоянии оценка объекта строительства зависит от прогноза доходов, расходов и рисков. Учет, контроль и принятие своевременных действий по минимизации рисков повышают стоимость проекта.
Качество. Этот аспект управления проектом, как правило, вообще отсутствует. Следить за качеством в строительстве (хотя, кроме строительства, в девелопменте есть вопросы формирования концепции, генерации пула арендаторов, юридической практики и т.д.) принято с помощью независимых сюрвейерных компаний. Как правило, этого никто не делает, так как стоит это 2-3% от генподрядного контракта – и рассматривается как ненужные расходы. В результате – расходы на доделки и переделки всегда превосходят эти инвестиции во много раз. К тому же, сюрвейер, как и хороший банк с архитектором, – это «флаги» проекта, повышающие его капитализацию.
Изменения. Это самая «пропащая» часть проектного управления в девелоперских компаниях. То есть, изменения, конечно, есть, а вот управления ими – нет. В результате, если разные члены команды (в том числе и руководители) знают о разных изменениях и у всех разная картина того, что было согласовано, а что нет, – значит, у каждого в голове уже свой проект. Чем это кончается, знает любой, кто наблюдал за коллективным строительством в песочнице, причем в песочнице шансов договориться больше. Настройка регулярной процедуры согласования изменений в любых аспектах, с учетом финансового прогноза по измененным параметрам – необходимый элемент проектного управления, если, конечно, владелец проекта не готов увидеть в результате плохую школу вместо хорошего офисного центра.
Status review. Проверка статуса – это регулярный контроль продвижения проекта с участием всех членов команды и руководства сверху. Любой инвестор естественным образом интересуется, что происходит с его деньгами. Как далеко продвинулись, и все ли движется по плану? Этому посвящены заседания комитетов с различными названиями – мне нравится «инвестиционный комитет». Он собирается ежемесячно или ежеквартально по каждому проекту. На стол перед каждым членом комитета должен лечь набор простых и наглядных документов, характеризующих продвижение за отчетный период по плану работ, бюджетам, рискам, качеству, изменениям. Наличие и регулярное проведение собраний инвестиционного комитета, нацеленного на подробный «осмотр» проекта и процесса со всех сторон, подготовки к заседаниям комитета без надрыва для всей компании – это квинтэссенция практики проектного управления.
Эскалация проблемы. Этот элемент управления очень важен для понимания на всех уровнях. Речь идет о том, что если менеджер проекта не может решить проблему, он должен вовремя донести ее до руководителя следующего уровня, например, директора компании. Если эскалация происходит слишком часто, то либо проект еще не находится в той фазе, в которой его воспринимает руководство, либо менеджер проекта некомпетентен, либо в команде проекта есть разрыв ответственности и не налажена эффективная коммуникация (что происходит чаще всего – и решается как раз постановкой проектного менеджмента в компании).
Офис проекта. Речь здесь не о помещении, где находится компания. Это термин проектного менеджмента, означающий организацию хранения и сопровождения всей документации проекта, от переписки, документов, бюджетов до графиков и чертежей. Правильно поставленный офис проекта следит и за целостностью документов, их непротиворечивостью, а также их принадлежностью. То есть, он не только может в любой момент выдать любую справку, документ или историю переписки по любой части проекта, но и подтвердить, кто и когда инициировал документ, к чьей зоне ответственности он относится и кто его авторизовал. Фактически, это жесткая система документооборота, но в практике девелоперских компаний не слишком жесткая, дабы не тормозить процесс. Вся информация классифицируется в 15-20 директориях (папках), и порядок в офисе проекта обычно говорит о том, что ситуация действительно под надежным контролем.
Если этих 10-12 элементов нет в проектах компании или они слабо выражены и плохо взаимоувязаны – можно сказать, что проектный менеджмент в компании не налажен. Соединение элементов работ, времени и денег должно быть наглядным и простым для понимания. Не потому, что сложные схемы трудно понять, а потому, что они резко понижают качество коммуникации внутри команды и между уровнями управления проектом. Возможность быстрой и ясной коммуникации по всем вопросам и проблемам, влияние на результат (по всем аспектам – времени, деньгам, качеству и рискам) и становится главным и обязательным свойством системы управления проектом в девелоперской компании.
Структурировать бюджеты, этапы проекта, риски можно по видам работ (группам работ), получаемому результату (решению задач) по распределению ответственности.
В идеальном проекте, из науки о проектном менеджменте, структурирование, основанное на декомпозиции работ, одновременно удовлетворит всем трем условиям, то есть будет тождественно структурированию по решаемым задачам и распределению зон ответственности. К сожалению, это не так в реальной жизни, особенно у девелоперов. Поэтому приходится выбирать, что брать за основу структурирования проекта.
Понимая, что основной управленческий риск любого сложного и продолжительного проекта, исполняемого в условиях высокой неопределенности и быстро изменяющихся обстоятельствах, лежит в разрыве ответственности членов команды проекта, я предлагаю «танцевать» от распределения ответственности, а не от декомпозиции работ. Декомпозиция, конечно, никуда не девается и остается основой углубления планирования и контроля проекта. Но приоритет при разработке (структурировании) всех аспектов управления (устав, сроки, деньги, риски, качество) остается за распределением ответственности и формированием структуры, в которой каждый член команды понимает, за что он отвечает, каковы процедуры согласования изменений в его зоне ответственности, какая часть расходного или доходного бюджета находится в его ведении и в каком качестве (авторизация, согласование, информирование).
Почему в практике управления девелопментом недвижимости (или ИСП) не используются MS Project, Primavera, Spider, хотя все эти программы (на сегодня уже мало отличающиеся друг от друга по функционалу) широко и успешно используются в строительстве? Когда дело доходит до планирования и контроля строительства, связь и последовательность задач жестко задана. Соответственно, любые изменения, скорее, касаются продолжительности той или иной работы, что не приводит к радикальному изменению всего плана. Если бетон для фундамента заливали дольше и его ушло больше, то мы имеем два (план и факт) довольно похожих между собой документа. И, несмотря на тысячу других работ, автоматически отодвинутых из-за задержки, – обе картинки (диаграммы Ганта) можно легко сравнить, получив, таким образом, визуально понятную информацию для контроля и принятия последующих решений. В ИСП же, куда строительство входит как составная часть, изменения на уровне, скажем, согласования бумаг, или проектирования, или концепции приводят к таким последствиям, что из офисного центра могут получиться апартаменты с торговыми помещениями, после чего нужно перепланировать все. Два плана в нотации Ганта невозможно сравнить друг другом, они слишком разные, поэтому осмысленной информации для контроля проекта они не дают (хотя сжирают массу ресурсов для переделки).
Иначе говоря, MS Project и похожие программы полезны для глубоко детализованных проектов с небольшими изменениями – тогда они помогают управлять. Это ситуация строительства, причем когда подписан генподрядный договор или во время его подготовки к его заключению. Для ситуации, характеризующейся высокой неопределенностью, нужна более гибкая и менее детальная система контроля, которая не столько увязывает различные этапы работ между собой, сколько направляет движение к цели с помощью наглядности взаимосвязи всех аспектов управления (цена, сроки, риски, качество) и вводит прозрачную систему ответственности членов команды.
Собственно, используемая мною система основана на людях и их зонах ответственности, то есть процессах и подпроектах, за которые они отвечают, в отличие от других систем проектного управления, отталкивающихся от работ, то есть от изначальной декомпозиции проекта на работы. Система не предполагает, что все функциональные менеджеры, отвечающие за различные составляющие проекта, откажутся от их повседневных инструментов. Так, например, строитель не должен отказываться от MS Project для контроля строительных работ. Это же касается и юриста, который контролирует юридическую часть ему удобным способом. Описываемая система отслеживает не детали этих работ, а исполнение задач специалистами по небольшому набору контрольных точек. Их количество доступно для контроля и анализа руководителям компаний, акционерам. Детализация есть только там, где из практики девелоперских проектов понятно, что это действительно нужно для контроля сверху. Потеряв в детальности рассмотрения работ (которая и не требуется руководителям и главным заинтересованным лицам: акционерам, инвесторам, банкирам и т.д.), система приобретает (на самом деле, на это она изначально и заточена) в целостности управления всеми аспектами ИСП и в ясности распределения ответственности за все элементы.
Система, кроме объективной картины, дает четкое понимание ролей и ответственности членов команды за ситуацию и за изменения. Исходя из сравнения факта и плана по всем аспектам управления (бюджет, время, риски и т.д.), она дает объективные и неоспоримые ключевые показатели для оценки работы и мотивации всех членов команды проекта. Фактически, мы получаем подсистему ключевых индикаторов эффективности (KPI – Key Performance Indicators) для выстраивания в компании системы сбалансированных показателей, упрощающих управление стоимостью бизнеса и управление по целям в рамках современных систем регулярного менеджмента. Однако подсистема KPI – это не цель, а следствие правильного (ориентированного на людей) взгляда на управление реализуемым ИСП.
Девелоперская компания сталкивается с рядом сложностей формирования структуры компании и распределения ролей и ответственности. Это естественно для проектно-ориентированной, по сути, организации, так как если в компании больше одного проекта, то начинает вырисовываться матричная структура, и подчинение команды руководителю проекта входит в противоречие с линейным подчинением специалистов в функциональных подразделениях. То есть, управляемость в компании (из-за изначальной внутренней противоречивости матричной структуры), как бы хитро она ни была выстроена, гораздо больше зависит от конкретных людей, их опыта и умения работать в коллективе, чем в простых линейных или дивизиональных структурах.
К этим сложностям нужно добавить и извечный вопрос девелоперских компаний – кто действительно руководитель проекта? Строитель, который глубоко владеет вопросами проектирования и строительства (работами, которые по времени и бюджету составляют большую часть проекта)? Или коммерческий директор, который формирует концепцию и, вроде как, более способен следить за общим коммерческим результатом? Как правило, кстати, первый слишком погружен в детали проектирования и строительства, что понятно и важно, а второй – слишком вольная птица, почти художник. Поэтому целиком за всей картиной частенько следит либо генеральный директор, либо даже владелец компании. Собственно, внедрение формализованной системы управления проектом помогает разрешить и эту дилемму. Такая система, исходя из целей компании, более четко определяет, что же такое проект, какие риски в первую очередь нужно закрывать, в чем разница между директором, менеджером и спонсором проекта, как можно разделить источники власти и компетенций в компании и т.д.
Внедрение проектного мышления и управление в девелоперской компании проходит в несколько разных по длительности этапов. Во-первых, формулируется цель, и, несмотря на всю ее очевидность, необходимо ее обсудить и записать. Далее вся команда проекта, а также все ее начальники (вплоть до гендиректора и владельца, если он вмешивается в управление) должны пройти один из многочисленных общих курсов проектного менеджмента в объеме двух-трех полных дней. Далее начинается работа по внедрению проектного управления в организации, формируется временная группа (комитет по внедрению), которая раз или два в неделю разрабатывает документы, соответствующие описанным выше 11 аспектам проектного управления, необходимым для девелоперской компании. Последний этап – самый длинный и важный, здесь формируется общий язык и понимание принципов совместной работы, распределяется ответственность, формируется проектное мышление. Этот процесс, в зависимости от интенсивности, занимает от месяца до шести.
Фото: pixabay.com
Спасибо Александру за хороший материал. Must read.
Ценность статьи еще в том, что с небольшими коррективами, материал может быть отнесен практически к любым проектам, выполняемым в компании.