Как работать в рабочее время: Правила победы над офисным хаосом

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

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

В такой схеме руководитель занят обработкой заявок и принятием решений – кому из своих сотрудников какую задачу поставить. Такие решения он мог бы и не принимать, делегируя полномочия сотрудникам, но почему-то он этого не делает. К тому же процесс вместо 2 итераций передачи информации проходит в 4 итерации, что увеличивает затраты и снижает эффективность. А причиной этому может быть всего лишь желание менеджера остаться незаменимым. Хотя часто бывает, что просто «нет времени» на наведение порядка и делегирование полномочий. Однако теперь благодаря главам 3 и 6 мы с вами знаем, что делать с такими словами, как «нет времени»!

В крупной корпорации на одну из первых сессий по управлению ожиданиями между функциональными менеджерами больше всех не хотел идти руководитель юридического департамента. Он работал по 14 часов 6 дней в неделю и был очень занят, а здесь целый день нужно было потратить на формирование договоренностей. В начале сессии каждый из менеджеров на листе флипчарта написал цели, процессы и проекты своей должности. А потом каждый дал обратную связь остальным с помощью специальных обозначений.

Директор юридического департамента собрал максимальное число стрелочек вниз, означающих необходимость делегировать процесс согласования договоров, который он держал под «ручным» управлением, а многие договоры правил лично. Для него это оказалось настоящим откровением, и прямо на сессии он дал обязательство описать и делегировать бизнес-процесс согласования договоров, что и произошло сразу после сессии. Через месяц скорость согласования договоров увеличилась в 2 раза[31].

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

На этом уровне взаимодействия важны следующие понятия:

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

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

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

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

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

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

Существует множество подходов к проектному управлению – PMBOK, Agile, P2M, Scrum, PRINCE2 и др. Но при использовании любого или даже нескольких из них часто возникает конфликт с другими уровнями взаимодействия. И первая ошибка – это конфликт между проектными задачами и оперативной работой сотрудников в виде просьб, задач и заявок. Ведь ресурсы всегда ограничены, и один из главных – рабочее время сотрудников.

Увы, часто мы встречаем ситуацию, когда непосредственный руководитель сотрудника, участвующего в проекте, изменяет приоритеты выполнения проектных задач, откладывая их, сдвигая сроки и не оповещая об этом руководителя проекта. Именно это часто является причиной распространенной традиции делать проекты в последний момент. Эффективное же управление проектами подразумевает регулярный ритм достижения запланированных результатов проекта.

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