Алина Прасковина

Руководитель проектов в MONS, «КОРУС Консалтинг»

Поменять РП… А если без шуток, то у нас есть два стула, два пути:
1) Действительно поменять РП (руководителя проектов)
2) Провести работу над ошибками и (или) ожиданиями.

Меня зовут Алина Прасковина, я руководитель проектов (РП) в MONS, «КОРУС Консалтинг». И за свою РП-шную карьеру я успела побывать в обоих сценариях. Давайте их рассмотрим чуть подробнее, и разберем, как выйти победителем в наступившем кризисе.

Вариант 1. Смена РП. Как входить в проект, где вашей ролью уже не довольны

1. Проведите аудит проблемы и состояния проекта.

Важно не сразу подхватить проектные задачи и начать их решать «хорошо», как нам кажется, а понять, что же делали не так и в чем кроется недовольство Заказчика.

Шаг 1: Соберите всю информацию о проекте от старого РП, в т. ч. матрицу коммуникаций и RACI, если они есть, или проведите встречу на эту тему. При передаче проекта намного важнее правильно верифицировать всех участников и заинтересованные стороны, чем задачи (о них вам и так расскажут/напомнят).

Шаг 2: Проведите 1 to 1 с каждым стейкхолдером проекта (в т.ч. и командой). Попросите рассказать о их функциях и задачах на проекте, о + и -, которые они видят на текущий проект, о том, что бы им хотелось изменить.

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

2. 1 to 1 с Заказчиком, честный разговор чем он недоволен.

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

Необходимо выслушать что же именно не нравится ЛПР со стороны Заказчика.

«Мало коммуникации» – регулярные встречи.
«Мы постоянно забывали про задачи» – ведение протокола задач.
«Я не понимаю на какой мы стадии, процесс выполнения не прозрачен» – доп. информирование всех заинтересованных сторон.

И т.д.

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

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

3. Постарайтесь изучить характер команды, язык их общения и традиции. Особенно с командой Заказчика.

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

Очень важно попасть в этот ритм. Вы должны как можно быстрее стать частью этого «организма», иначе будет очень сложно его понять и что-то изменить.

4. Вы наладили процессы, закрыли все критичные боли отлично, можно выдыхать?

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

Важно не упустить вновь из фокуса те пункты, отсутствие которых когда-то поставило существование проекта под угрозу.

Вариант 2. Заказчик недоволен Вами, что делать?

В этой ситуации может быть два варианта: он не доволен Вами объективно или субъективно. Давайте разбираться.

1. Если Заказчик не доволен Вами по объективным причинам, необходимо пойти на честный разговор, провести тот же 1 to 1 и выявить все боли. Потому что не всегда понятно, что действительно кроется за недовольством Заказчика.

Если это и правда простой ряд ошибок тех. команды – отлично! Это исправить намного проще) Главное – не закрывайте на них глаза. Признайте перед Заказчиком, что да, недочеты были, разработайте шаги их устранения и покажите результат. Но иногда, казалось бы, ошибки настолько мелкие, что большинство людей бы их не заметили: кто-то прощал вам и бОльшие провалы, а тут отчитывают за каждый чих. Почему так? Потому что в первом случае вы с Заказчиком выстроили доверительные и приятные человеческие отношения, а во втором случае – где-то серьезно в этом процессе промахнулись.

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

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

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

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

Главная цель на проекте у Заказчика – чтобы данный проект приносил пользу его бизнесу. И если в процессе реализации окажется, что пользу принесут еще +10 доработок, еще более маленький SLA, или пару фитчей – то Заказчик будет на них настаивать. Тут важно вовремя верифицировать что это превышение условий проекта и пойти на разговор с Заказчиком.

Только пожалуйста, не начинайте его со слов: «Это не было заложено в проект, мы это реализовывать не будем. В ТЗ было указано не так, мы будем делать как в ТЗ. У нас другой SLA в контракте, на этом точка».

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

И вот вы уже не говорите Заказчику нет, не тычете его в Договор, а находите вместе выход, пусть он и будет для него платным.

Вместо заключения

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

О стену мы в лепешку не расшибаемся — это никто не оценит и нам будет не полезно. Найдите золотую середину, и будет вашему проекту счастье.