Проектная организация: варианты реализации и развития.

Лукьянов Д.В.,

Управляющий партнер ООО «Бюро проектов менеджмента»,

IPMA Certificated Senior Project Manager (IPMA level B)

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

Стандартом де-факто, по крайней мере в области терминологии управления проектами, сейчас является классификация оргструктур согласно стандарта ProjectManagement Body of Knowledge (РМВОК), остающаяся практически неизменной с момента первого издания стандарта в 1996 году.  Стандарт рассматривает функциональную, слабую матричную, сбалансированную матричную, сильную матричную и проектную орструктуры. Также неизменной остается матрица анализа состояний «полномочия менеджера проекта – тип оргструктуры». В данной статье приводить их не будем, посчитаем, что читатель либо знаком, либо найдет способ ознакомиться с этим разделом стандарта. С другой стороны, стали появляться издания, посвященные теме, практически в стандарте РМВОК не описанной – теме создания проектного офиса, как структуры, которая занимается управлением либо поддержкой более чем одного проекта в единицу времени. Одной из первых работ на русском языке, доступной нашему читателю, было издание российской компанией PMSoft работы Кендалла «Современные способы построения проектного офиса. Путь к уменьшению затрат и возврату инвестиций» (уточнить и вбить правильное название). Там рассматриваются варианты существования проектного офиса как проектной оргструктуры в вариантах (или, как указано в первоисточнике «моделях») «репозиторий», «наставник» и непосредственно «офис управления проектами». Также существует множество других классификаций, пока еще не стандартизированных, с такими названиями вариантов моделей, как «сторожевая башня», «маяк» и проч. Более того, во многом благодаря этой почве нестандартизации (что в данном случае даже, возможно хорошо), возникли многие концепции в смежных областях знаний, связанных с управлением, например, такие как «управление знаниями», многое взявшие из концепции проектной организации. В целом, по мнению автора, все это варианты состояний структуры, так или иначе связанной с управлением проектами в организации, находятся  в диапазоне между двумя полюсами – поддерживающий вариант проектного офиса (минимальные полномочия) либо полностью управляющий (100% ответственность и, соответственно, полномочия). Так или иначе, как уже отмечалось выше, само выделение подобных структур уже шаг вперед. Например, благодаря тому, что в структурах управления проектами возникают элементы матричной структуры, когда те или иные процессы, связанные с осуществлением проектов в организации (в идеале - перекрывающие все пять групп процессов управления проектами по РМВОК) передаются в соответствующие подразделения структуры, связанной с управлением проектами – например из-за известного «правила 70%» - в результате этого многие процедуры смогут занимать гораздо меньше времени ввиду того, что они станут не просто повторяющимся документированным процессом в организации, а еще и выполняемым одной и той же группой сотрудников.

Что касается материалов рекомендаций либо описанной практики управления проектами в мире, по мнению автора, существует существенное отличие при попытке «дословно» воспользоваться этим рекомендациями в наших, постсоветстких условиях. Во первых, это связано с тем, что, в отличии от остального мира, где управление проектами живет как отдельная дисциплина уже более 40 лет, а такой системе сертификации, как сертификация проектных менеджеров на звание PMP – Project Management Professional  от американского Project Management Institute (PMI), являющегося автором упомянутого РМВОК, свыше 20 лет, у нас эта тема несколько моложе и все еще воспринимается с настороженностью как некое новомодное течение, которое как пришло, так и уйдет. Соответственно, и уровень технологической зрелости в области управления проектами, как организаций, так и общества в целом все еще крайне низок. Зачастую нельзя говорить даже об общем языке – уровне, которого в американской модели ОРМ3 просто нет, потому что наличие профессионального языка подразумевается по-умолчанию. Поэтому все те рекомендации, которые рассматривают некие «модели реализации проектных оргструктур», в наших условиях, следует рассматривать как, скорее, возможные «стадии развития». Соответственно, нужно понимать, что некоторые из этих «моделей» нереализуемы, если попробовать их ввести «в лоб», выполнив рекомендации западных экспертов либо скопировав чью-то best practice. И многие компании, к сожалению, разочаровались в управлении проектами, как управленческой технологии, именно из-за того, что не учтя отличий во внешних условиях, получили работающий и хороший, для другой среды, инструмент, который, после того как он сразу не заработал, отложили в сторону. С другой стороны, можно все же  провести «революцию в отдельно взятой компании» и, по крайней мере, внутреннюю часть бизнес-процессов перестроить максимально используя лучшую мировую практику. В полной мере получить преимущества от применения проектного подхода будут так или иначе невозможно, пока все участники проекта не будут находиться на достаточно высоком уровне технологической зрелости, чтобы они могли состыковать свои бизнес-процессы в процессе взаимодействия по выполнению общего для них внешнего проекта. Но для этого все эти компании, так или иначе, должны уже пережить такую «локальную внутреннюю революцию» (хотя мне очень не нравится слово «революция» применительно к бизнес-процессам, но иначе это зачастую не назовешь) и быть готовы к общению на профессиональном языке (1 уровень зрелости), впоследствии выстраивая общие для всех участников проекта процессы (2 уровень зрелости), обеспечивая единый прозрачный подход к управлению проектом (3 уровень зрелости).

Что может помешать движению компании в сторону проектно-ориентированной? С одной стороны, вроде все только способствует началу такого движения, но это только с одной стороны – со стороны здравого смысла. Пока организации их владельцы владеют прежде всего материальными активами и именно их учитывают, все достаточно предсказуемо. Заводы работают, шахты добывают, поля убирают. Имеем повторяющийся многократно процесс, знания о котором являются чем-то самим собой разумеющимся, передаваемом как внутри таких структур, так и государственной системой образования. Варианта, что такой нематериальный актив, как знания и навыки сотрудников, находящиеся внутри организации, могут безвозвратно быть потеряны, причем это событие поставит организацию на грань краха, практически никто не рассматривает (хотя некоторые промышленные предприятия с этим уже столкнулись). Даже если возникают в таких организациях образования, которые называются «проектный офис» или что-то в этом роде, они, как правило приветствуются на начальных этапах своего развития, т.к. выполняют прежде всего поддерживающую функцию  (отчеты, затраты, исполнители и проч.). При этом, в начале своего пути, такие структуры не являются носителем каких-то уникальных знаний, и оценить их вклад в существующую систему управления предприятием, как некий нематериальный актив, достаточно проблематично. В любой момент компания может все «откатать назад» и завод, к примеру, от этого не рухнет. Вот при дальнейшем развитии, когда в подобной структуре накапливается уже значительный массив информации, и функции такого подразделения расширяются только от предоставления отчетности к еще и аналитической работе с этой информацией и предоставлением рекомендаций/прогнозов развития проектов, и если такие рекомендации успешны, можно говорить о том, что в организации возникает определенный нематериальный актив, прежде всего знания о фактическом способе выполнения как успешных (и неуспешных – тоже очень важно) проектов, так и о способе организации всех бизнес-процессов организации. И если эти знания уже являются отделенными от конкретного носителя – сотрудника либо группы сотрудников, и могут быть тиражируемы, то такие знания могут стать очень значительной силой в руках руководителя, который понимает как такой актив можно применить. Прежде всего, пропадает зависимость от материальных активов – в смысле необходимости иметь их своими. Например, для того, чтобы произвести новый продукт, может оказаться достаточно иметь знания о технологии его производства, предполагаемых рынках и каналах сбыта, которые могут оказаться с подобной структуре. А сам завод-производитель может оказаться любым из способных выполнить подобный заказ. Что значит любым? Прежде всего значит, что вовсе не обязательно может быть задействован тот самый громадный материальный актив, благодаря которому в свое время был рожден тот, тогда еще очень небольшой, нематериальный актив, в виде минимальной структуры, владеющей максимумом знаний, которые необходимы для жизнедеятельности родителя-гиганта. Масштабы картины могут быть различны – и меньше описанной, и больше – вплоть до отрасли целиком. Что это? Возможность или угроза? И то и другое. В нашей практике, к сожалению, чаще рассматривается такой путь развития событий, как угроза. И в какой-то момент в своем движении офис управления проектами в таких структурах застывает пусть в продвинутом, но все же состоянии поддерживающего офиса. Те организации, которые рассматривают подобный путь, как возможность, имеют шанс пройти до конца диапазона, выстроив фактически полноценную управляющую компанию, основными активами которой являются прежде всего нематериальные активы. Может оказаться так, что на этом пути в какой-то момент в организации возникнут центробежные силы (например, в лице нескольких собственников, по разному рассматривающих соотношение возможности-угрозы), причем такие, что организация может разделиться на части – причем и деление в таком случае чаще всего происходит по принципу – с одной стороны будут те, кому дороги заводы-пароходы как материальный актив, с другой стороны оказываются те, кому тоже дороги заводы-пароходы, но уже с точки зрения нематериальных активов – технологий прежде всего. Думаю, ближайшее будущее покажет, что абсолютно правых или неправых в этой полярности нет, все получат то, что захотели. Но, в дальнейшем, судя по мировому опыту, все же больше выиграют те, кто предпочтет нематериальные активы.

Еще нужно понимать, что многие определения, в частности, проектной команды, не стоит во всех всегда воспринимать буквально – по РМВОК’у (например - насчет команды проекта как временного коллектива). Стоит говорить о симбиозе разных типов оргструктур в рамках одной организации: может существовать развивающаяся организация, которая выглядит как клонирующаяся  линейно-функциональная, но имеет часть своей организации, которая представляет собой организованный по принципу матричной структуры корпоративный центр, который взаимодействует с проектными командами, построенными действительно по принципу «временных команд», которые как раз и занимаются проектами «клонирования» линейно-функциональной части организации. Во всех этих подразделениях могут существовать различные принципы мотивации, разный подход к подбору персонала (в первую очередь – руководителей) и могут существовать «переходящие» проектные команды, когда проекты, несмотря на свои признаки уникальности, ограниченности по ресурсам и проч. уже выглядят больше как некий процесс. При этом, если в подобной структуре еще и возникнет, вначале с поддерживающей функцией, один центральный офис управления проектами организации, проектные команды будут выглядеть действительно как описано в РМВОК в случае проектной структуры. Но и здесь, в моделях оргструктур организации, как и в самих моделях проектных офисов, скорее правильно будет говорить о стадиях, которые нужно пройти в своем развитии, чтобы принять тот или иной вид. А возможно и осознанно остановиться в каком-то варианте для того, чтобы быть максимально гибким и способным удовлетворять требованиям рынка, не двигаясь дальше по типам оргструктур и, не выстраивая громоздкой оргструктуры со всевозможными надстройками и многими уровнями иерархии, тем самым оставаясь с одной стороны «вечно молодыми», с другой стороны достаточно технологически зрелыми для того,  чтобы браться за серьезные проекты. Плохих или хороших оргструктур не бывает – бывают подходящие, или не очень, для тех или иных задач, которые стоят перед организацией. И если для этого нужно использовать преимущества того или иного типа оргструктуры, отличного от существующего на данный момент в организации, порой лучше организовать для решения конкретной задачи/блока задач соответствующее бизнес-образование с требуемым типом оргструктуры, организовав ее коммуникации с материнской компанией, решить задачу и не устраивать революций в основной компании. Тогда действительно все будет по РМВОК. Здесь также крайне полезным будет использование сертификационной модели проектных менеджеров 4-L-C IPMA (международной ассоциации управления проектами) как варианта реализации проектной команды. Но это возможно только при действительно высоком уровне технологической зрелости.

И еще один важный момент в функционировании проектной организации – управление коммуникациями. Опять же, если посмотреть на этот блок знаний, как область компетенции по стандарту РМВОК, то можно сделать вывод, что, несмотря на некоторые «добавки» в версии 2004 года, все же больше человек в данном проекте рассматривается как часть некоей механической системы, который получает задания, их выполняет или не выполняет, но обязательно отчитывается об этом и отправляет руководству некие запросы на изменения.  И коммуникации, организованные по принципам «Определить потребности в коммуникациях» - «Своевременно предоставить информацию» - «Собрать отчетность» - «разместить информацию» и т.д., скорее все же еще не коммуникации, а результат, который мы ожидаем от коммуникаций. А достижение тех или иных целей в процессе коммуникаций, нужно планировать не только с учетом формальных систем коммуникаций, например систем документооборота либо других проектно-ориентированный средств организации групповой работы, а и с учетом неформальных принципов коммуникаций и понимания способности (точнее, в некоторых случаях, принципиальной неспособности) организации осуществлять управление  коллективом в том или ином масштабе. Для этого стоит обратиться к классикам – прежде всего к работам Минцберга и рассмотреть возможные типы коммуникаций и структур управления не только с точки зрения опять же «моделей» или «типов», а с точки зрения эволюционной модели, предполагающей возможность появления и эффективного использования того или иного типа коммуникации только на определенном этапе развития компании. Что самое интересное, если рассматривать подобную модель, как модель «коммуникационной зрелости» компании, можно увидеть, что если компания находится на высоких уровнях технологической и коммуникационной зрелости, то многие вещи, необходимые в формальном виде на более низких уровнях, становятся излишними. Но это только тогда, когда корпоративная культура такой компании уже становится «корпоративной религией». И когда в компании есть такой составной элемент нематериального актива, как социальный капитал.

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