Как выстроить комплексное управление проектами: опыт крупной компании

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

В продажах и коммуникациях с клиентами я работаю 16 лет, 7 из них в качестве административного руководителя разных уровней. А последние почти 4 года являюсь лидером Telesales-проекта в крупной телекоммуникационной компании, предоставляющеей услуги мобильной связи на всей территории РФ. В составе моего проекта в разные периоды было до 1000 FTE (Full-Time Equivalent), а это достигать 1500 операторов и более.

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

В рамках нашей практики ведения проектов внутри дирекции мы придерживаемся методики Agile, а с исполнителями в рамках договорных отношений наши позиции четко определены: заказчик и исполнитель. Вместе с тем, система целеполагания, премирования и KPI сохраняется и там, и там. Впрочем, как и принципы открытости, ответственности, уважения и эмпирического подхода к решению задач.

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

Это могут быть kanban-доски, road maps, диаграммы ганта — все то, что помогает четко и структурировано определить этапы проекта с процессами и нужными результатами, сроки и ответственных. Без визуализации и четкого планирования проектных процессов не получится нужного порядка, последовательности и реализации в срок. И естественно, такие инструменты должны быть в актуальном состоянии, регулярно дополняться и детализироваться.

Помимо намеченных планов реализации проекта немаловажным остается и фиксация ретроспективы. Именно это помогает в дальнейшем «вспомнить, как все было» и не допустить ошибок прошлого периода в новом витке проекта. Особенно, если события цикличны.

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

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

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

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

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

Наш проект не имеет финального срока реализации. Но есть временные интервалы, которые мы используем для контрольных точек и для подведения финансовых результатов как внутри компании, так и для взаиморасчетов с нашими внешними исполнителями.

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

Дальше по циклу — реализация плана или непосредственное осуществление всех проектных процессов. Я приверженец работы с системой KPI, которые зафиксированы у нас для внутренних команд и частично транслируются внешним исполнителям. Мой каждый рабочий день (как лидера проекта) начинается с контроля ключевых показателей. Есть показатели, которые можно проконтролировать в коротком периоде времени (например, показатели конверсии), а есть более «долгоиграющие» контрольные точки (например, показатель LTV, за которым мы также активно следим). И на этапе реализации очень важна проактивность участников команд. Если что-то идет не так, важно сообщить сразу. Именно на этом этапе цикла мне нравится применять подход горизонтальной структуры команд, когда участники проявляют проактивность и инициируют самостоятельно коммуникацию и сразу предлагают возможные корректировки действий.

Этап с мотивацией я пропущу. Но не потому что он не нужен, а наоборот. Мне кажется, он настолько must have, что еще раз говорить об этом не стоит. Мотивация может быть совершенно разная и далеко не всегда она определяется только в материальных выражениях. Главное — чтобы она была.

И перехожу к последнему этапу — это контроль. Контроль исполнения процессов и контроль правильности исполнения может быть решающим моментом в успехе проекта. Избежать потери ресурсов (как временных, так и командных) очень помогает правило контрольных точек. И не просто на словах исполнителей, но также и на самостоятельной проверке конечной реализации продукта. Приведу в пример свой проект. Когда выходит новый продукт для продвижения, я прошу не только статуса «done» от проектной команды, но и также рандомные записи диалогов с нашими абонентами, в которых определяю правильность донесения информации о продукте до его конечного потребителя.

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