Управление проектами.РУ

Управление проектами.РУ
Сообщество тех, кто умеет или хочет научиться
хорошо управлять проектами
20 августа 2016 Все для начинающего РМа
415 0

Неадекват в рабочей группе – данность или с этим можно работать?

Юлия Бажанова
Редактор проекта, РМР, РМЕ, PRIME

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

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

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

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

Как это сделать в реальности? Если есть возможность, организуйте регулярные совещания рабочей группы с участием спонсора проекта, перед совещанием проведите с ним краткий обзор выполненной работы, чтобы он понимал, кто и что не выполнил, и какие последствия для проекта это несет. На совещании спонсор требует от членов рабочей группы отчитаться и выдает живительные пинки, если нужно. Важно! Это работает только если спонсор «настоящий», искренне заинтересованный в успехе, а не «для галки». Если для галки, и реального спонсора у проекта нет – то с этого проекта лучше бежать, пока не поздно, все равно успех маловероятен.

В-третьих – построение взаимоотношений с членами рабочей группы никто не отменял. Будет полезно аккуратно рассказать пару позитивных историй о карьерном росте людей, участвовавших в автоматизации чего-либо (подробнее в этой статье). Если в вашу рабочую группу входят в  первую очередь ключевые пользователи – можно подумать о том, что их может мотивировать – повышение их ценности на рынке труда, более интересная проектная работа вместо рутинной и проч.

В-четвертых – и это не противоречит третьему – не бойтесь эскалировать проблему на спонсора, если она уже возникла. Если вы попробовали решить ее с членом рабочей группы и не смогли договориться – это бизнес, честно говорите, что вас такой ответ не устраивает, вам нужен результат проекта. Мол, я вам не руководитель, признаю за вами право иметь свое мнение по этому вопросу (например, вопросу посещаемости встреч рабочей группы), но поймите и меня – мне за это деньги платят, я буду вынужден эскалировать этот вопрос на <тут подставить имя>. Минимум в половине случаев на этом этапе ваш собеседник найдет время, предложит обсудить вопрос еще раз или еще как-то пойдет навстречу. Вы не давите, вы предупреждаете об опасности – вы теперь друг, а не враг. А если до эскалации все-таки дойдет – вы честно предупредили, а не «настучали за спиной», к вам претензий тоже быть не может.

Универсальное правило эскалации, если вы ведете проект в относительно небольшой компании – постарайтесь выйти на собственника или материально заинтересованного руководителя. В среднем бизнесе решение о вложении в автоматизацию принимаются обычно на этом уровне, так как удовольствие для них это достаточно дорогое. Кто-то в рабочей группе недорабатывает и может похоронить вложенные 5 млн. рублей? Да собственник их оторвал от дочки, обучающейся в Оксфорде, и она там теперь перебивается meal deal’ами в Теско за 3 фунта вместо йоркширского пудинга! Будьте уверены, сотрудника из рабочей группы мотивируют так, как вам и не снилось.

Минутка ностальгии – один из моих самых успешных проектов во времена работы в консалтинге – это автоматизация работы с судебными делами в небольшой оценочной компании (около 80 сотрудников), работавшей в области строительной оценки. Буквально на второй эскалации сотрудники поняли, что я не шучу и пойду снова и снова к собственнику при необходимости. До сих пор интересно, что он с ними делал, но после эскалации все были бесконечно милы и исполнительны.

В-пятых – пересмотрите свой план коммуникаций, возможно, это вы перегибаете палку и достали уже всех в этом отделе или этой компании? Нельзя требовать от всех того, что ваш проект будет для них самым приоритетным, они не за это деньги получают, у них есть свои KPI отделов, от которых вы их отвлекаете. Планируйте работу с учетом того, что среднестатический руководитель не сможет тратить на вас больше 10% рабочего времени, и это в случае, если проект действительно важен для компании, и руководство смогло это донести.

Поэтому договаривайтесь об итеративной приемке, например, ТЗ – не «у вас месяц на согласование», а «у вас 3 дня на согласование части «1.7. Основные пользователи системы»,  так как без этого мы не можем двигаться дальше». Кусочками людям делать проще. То, что руководитель выделит время в своем расписание на чтение 20 страниц раз в неделю на протяжении 6 недель, более вероятно, чем на 120 страниц сразу, в лучшем случае – просто подмахнет, не глядя. Ну и результат, скорее всего, будет более качественным.

Также постарайтесь получать от членов рабочей группы личное подтверждение согласия с план-графиком и работами, которые выполняют они лично или их отдел. Если надо – потратьте время, посидите вместе, пройдите по каждой задаче, обсудите ее содержание, сроки и влияние на весь проект. Тогда и  человек лучше поймет, чего вы от него хотите, и психологически ему будет сложнее вам отказать. Иначе при рассылке письма с планом и фразой, мол, кто не согласен – напишите в ответ – вы попадаете в ситуацию коллективной безответственности типа «ну вы же не сказали «нет»! – но и «да» я не сказал!». Чтобы прикрыть тылы – пойдет, чтобы получить результат – не очень.

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

Также полезная мысль по этому поводу есть тут и тут.

Таким образом, если у вас не складываются отношения с рабочей группой, возможно, “вы просто не умеете их готовить”? Попробуйте воспользоваться рецептами выше и расскажите о результатах. У меня работает, рабочая группа обычно получается очень даже ничего. Но всегда есть куда совершенствоваться, поэтому если есть вопросы или дополнения – пишите в комментариях, буду рада обсудить.

комментарии

Добавить комментарий

Такой e-mail уже зарегистрирован. Воспользуйтесь формой входа или введите другой.

Вы ввели некорректные логин или пароль

Sorry that something went wrong, repeat again!

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: