2.7.8. Запросы на изменения

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

Для эффективного управления запросами на изменения используется файл с автоматическим расчетом затрат на выполнение требования с учетом вовлечения сотрудников компании в зависимости от ставок (стоимости) привлекаемых позиций консультантов (см. Рисунок 13).

Рисунок 13 – Иллюстрация шаблона для расчета запросов на изменения

2.7.9. Управление рисками

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

Для управления рисками мы разработали и используем специальный инструмент – матрицу рисков и контрольных процедур проекта (см. Рисунок 14).

Рисунок 14 – Иллюстрация шаблона для реестра рисков проекта

Каждый риск оценивается по трем критериям:

• Вероятность возникновения риска – насколько вероятно возникновение риска на проекте.

• Влияние на проект – на сколько реализованный риск оказывает влияние на эффективность проекта

• Оценка риска общая рассчитывается на основании произведения баллов по вероятности и критичности возникновения рисков.

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

2.7.10. Управление задачами клиента

Чтобы организовать системный контроль над исполнением задач, необходимо вести единый реестр задач клиента и консалтинговой компании. По мере реализации проекта неизбежно будут возникать дополнительные задачи, для контроля исполнения которых важно поддерживать единый реестр в актуальном состоянии (см. Таблица 14).

Таблица 14 – Шаблон реестра всех задач проекта

Единый реестр задач позволяет систематизировать работу по многочисленным задачам крупного проекта:

1. Вести полный учет всех задач по проекту.

2. Приоритизировать работу по наиболее важным из множества задач.

3. Контролировать сроки исполнения задач.

4. Своевременно выявлять сложности на проекте для принятия управленческих решений.

Также структурируют работу с клиентом и играют роль единого реестра задач облачные инструменты, такие как Trello, Jira, YandexTracer.

2.7.11. Организация работы над ошибками

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

В 2013 г. в московском офисе Accenture новый руководитель практики management consulting ввела практику: каждый руководитель проекта и его команда докладывали о результатах выполненного проекта. С тех пор я взял себе это на вооружение. Материалы для такого собрания специально не готовили, показывали презентации с проекта «как есть». Цель сессии – поделиться опытом с другими руководителями и командами, рассказать про проблемы, с которыми столкнулись, и показать решения, которые принимались.

В EY существует практика knowledge sharing session (KSS). Практика представляет собой проведение регулярных совещаний (не реже, чем один раз в квартал) с участием всех команд консалтинга. В рамках сессии готовятся презентации по реализованным проектам по стандартной форме, и с ними выступают команды, реализовавшие проект.

Они включают:

• содержание проекта, чтобы были понятны масштаб и предметное поле (1 слайд);

• выработанный подход, который позволил достичь результата (1–2 слайда);

• «находки» (findings) – «ноу-хау», которые были реализованы в проекте и должны тиражироваться на всю консалтинговую практику;

• выученные уроки (lessons learned) – ошибки, которые совершила команда, способы их митигации или предотвращения, о которых должна знать вся практика во избежание повторения другими командами.

Подобные сессии – это и формирование базы знаний, и обучение подходам, и знакомство консультантов с другими командами.

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

2.8. Закрытие проекта

2.8.1. Сбор данных по бенчмаркам

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

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

2.8.2. Оформление результатов проекта

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

Оформляйте результаты работ сразу по окончании проекта, а лучше в процессе, так как потом может не оказаться времени.

Best-in-class (лучший в своем РОДЕ) итоговый набор документов включает:

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

• Описание ситуации.

• Что было сделано?

• Подход к решению.

• Достигнутый результат.

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

Типовая структура презентации:

• План проекта (верхнеуровневый).

• Организационная структура.

• Основные направления на проекте, результаты по этим направлениям.

• Подходы.

• Команда, вовлеченная в проект.

3. Структурирование архива. Обычно в команде консультантов 3–5 человек, но иногда 10–15. При этом проект всегда состоит из нескольких модулей. Вся команда и модули накапливают огромное количество информации, которая потенциально может понадобиться для бенчмаркингов и обучений. Важно провести ревизию и:

– удалить всю информацию с персональными данными;

– санитизировать клиентские данные;

– удалить все промежуточные или временные файлы;

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

Рисунок 15 – Иллюстрация шаблона для фиксирования результатов проекта

2.8.3. Предложения по допродажам

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

Также многое зависит от того, частная или государственная компания, от отношения менеджмента к консультантам (не является секретом распространенное мнение собственника: «Я вам плачу огромные бонусы, чтобы вы работали сами, а не нанимали консультантов»), цикла смены руководства. В любом случае хорошие партнеры умеют управлять этими факторами и получать проекты не от тендерной команды (см. Рисунок 16).

Рисунок 16 – Иллюстрация шаблона для реестра «opportunities» проекта

2.9. Одиннадцать правил консультанта

Мы наблюдали, как приходили ребята из индустрии и становились хорошими консультантами, драйвили наш бизнес. И замечали тех, кто не становился. Вот список правил поведения, которые, насколько нам известно, отличают хорошего консультанта от плохого. Не нужно переспрашивать у вашего руководства по каждому правилу: «Действительно ли это нужно делать?». Просто следуйте им.

Выводы и рекомендации