Гибкие методологии управления (Agile) изначально использовались в IT-сфере, а потом перешли в маркетинг, HR и другие сферы. Следуя модному тренду многие забывают, что Agile подходит не каждой компании и случается, что реорганизация процессов не приносит пользы. С чего начинали трансформацию в ILF, какую оргструктуру выбирать в зависимости от проектов и коммуникаций внутри, проясняем в этой статье.
На старте мы описали действующие бизнес-процессы в компании и поняли, что прошлые методики управления проектами работают не так эффективно, как раньше. Это происходит по трем причинам:
-
Высокая степень неопределенности юридических проектов. Цели и задачи, часто меняются по ходу: всплывают новые обстоятельства, выясняются ранее неизвестные факты или клиент вспоминает о том, что не всё рассказал на старте. Учитывая стремление клиентов к фиксированным бюджетам и изначальную готовность компании их давать, такая неопределенность мешает сделать проект финансово успешным.
-
Неравномерное распределение нагрузки на юристов: кто-то неделю выполняет одну задачу, а на кого-то сваливается остальная работа. Чем больше сотрудников под началом одного партнера, тем сложнее следить за нагрузкой каждого по отдельности.
-
Отсутствие прозрачности ‒ неочевидный вклад каждого из сотрудников в общий результат работы компании. Работа разных департаментов может отличаться настолько, что два сотрудника, работая много лет в компании, могут ни разу не пересекаться в общих проектах. Из-за этого возникает непонимание, кто чем занимается и за что отвечает.
В поисках инструментов для починки системы управления проектами мы обратились к Agile (подробнее в предыдущей статье) и начали с изменения организационной структуры.
Функциональная, проектная или матричная структура
Изначально у ILF была распространенная на юридическом рынке функциональная организационная структура ‒ юристы со схожими компетенциями объединены в практики (департаменты), а вся работа организовывается и управляется партнером - руководителем практики. Такая модель организации юридической компании имеет свои преимущества. Сотрудники на одной волне, могут помогать друг другу или даже выполнять работу “соседа”, обмениваются знаниями, что ведет к быстрому профессиональному росту, а руководитель, как правило, является еще и прекрасным специалистом, а значит и ментором, в той же области.
Но зачастую для успешного выполнения одного проекта необходимы знания и навыки из различных областей права, а значит нужно привлекать сотрудников других практик. В такой ситуации функциональная организационная структура показывает себя не с лучшей стороны. Ведь участники проекта не имеют единого руководства и усложняется управление стоимостью проекта: в каждом департаменте управляют своей частью бюджета проекта независимо, составление общего расписания требует сессий совместного планирования с участием руководителей всех задействованных практик. И это не говоря уже об управлении рисками и ожиданиями заинтересованных сторон. В результате проект, являющийся приоритетным для одной практики, может быть абсолютно не интересен другой.
Трудности в организации работы над комплексными разносторонними проектами заставили нас обратить внимание на проектную организационную структуру, при которой специалисты разных областей знаний объединяются в проектные команды. Команда во главе с менеджером проекта успешно планирует и осуществляет проект, поскольку в сумме обладает всеми необходимыми навыками и знаниями. Такая организационная структура хорошо зарекомендовала себя в IT.
Но проектная структура не подошла из-за специфики юридических проектов. Так, например, общий объем работ по одному проекту для 4-х специалистов может составлять 70 часов в течение 9 недель. В то же время один юрист в течение такого же промежутка времени может работать над 50 проектами. То есть если организовать работу по принципу IT-компаний, только планерки будут занимать 90% рабочего времени.
К счастью, существует матричная организационная структура, которая совмещает в себе эти два подхода. Ее можно представить в виде решетки, где по вертикали находятся уже знакомые нам практики, а по горизонтали ‒ проекты. На пересечении вертикальных и горизонтальных линий находятся конкретные юристы, работающие в практике, но над проектом. Что это дает? Все лучшее из обеих моделей.
Руководитель проекта, находясь в рамках своей горизонтали, может действовать словно в проектной организации. Все атрибуты проекта, будь-то бюджет, риски или план-график выполнения работ, находятся под его полным контролем. На менеджере проекта так же завязаны и все коммуникации с заказчиком. Имея полную картину и полномочия управлять расписанием работ, руководитель проекта может координировать работу команды так, чтобы адвокат, защищающий клиента в суде, заблаговременно получил экспертное заключение специалиста по международным договорам и имел достаточно времени для корректировки стратегии защиты.
В то же время и партнер - руководитель практики чувствует себя уверенно, организовывая работу департамента. Задачи со всех проектов, в которых участвуют сотрудники департамента, собираются и превращаются в один поток, обработку которого и нужно организовать руководителю практики. При этом ему больше не нужно отвлекаться на всякие проектные штучки вроде таблицы заинтересованных сторон, бюджетирование каждого отдельного проекта, расчеты и перерасчеты рисков и т.д. Можно сконцентрироваться на создании комфортной атмосферы в коллективе, быстром решении всех возникающих у его сотрудников вопросов, равномерно распределять задачи между сотрудниками и не забывать об их личностном и профессиональном развитии.
А как на практике
Что же получается, матричная структура ‒ серебряная пуля, святой грааль, утопия? Скептический читатель наверняка уже понял, что в чем-то есть подвох, и оказался прав. Матрицу сложно организовать и она очень хрупкая. Причина этому ‒ большая вероятность возникновения конфликтов между руководителями горизонтальных и вертикальных структурных единиц, а также опасность двойного менеджмента для сотрудников.
Чтобы справиться с этими трудностями, необходимо изначально продумать и установить правила игры, которые будут регламентировать, кто и в каких случаях принимает решения и за что отвечает. При этом необходимо установить баланс полномочий между руководителями проектов и практик.
В зависимости от того, в какую сторону смещен этот баланс, мы можем получить различные подвиды матричной структуры:
-
сильную, если руководители проектов наделены большей властью нежели главы департаментов;
-
сбалансированную, если полномочия поделены приблизительно 50 на 50;
-
слабую, если решение большинства вопросов остается на усмотрение партнеров руководителей практик.
Для ILF мы выбрали сбалансированный вариант, отдав руководителям проектов вопросы общения с клиентами, формирования команд, управления содержанием, расписанием и стоимостью. В ведении партнеров осталось операционное управление, подбор и менторинг юристов практики, а также краткосрочное планирование работ. И остаются проекты типа “мозги” (уникальные, сложные проекты с высокими рисками), где партнеры могут выполнять роль проектных менеджеров.
Более подробно о том, как юристы и неюристы сегодня планируют в ILF, как Scrum и Kanban работает в юридической компании, и как замерять промежуточные результаты от Agile-трансформации мы проясним в следующей статье.
