Вы пришли со своим проектом в компанию-заказчик или в отдел-заказчик и собираетесь нести разумное, доброе и вечное – автоматизировать чью-то работу, повышать качество взаимодействия и вообще всех тут радовать. А вам почему-то не рады. Рабочая группа тормозит проект – люди не читают документы, находят сто причин, чтобы не прийти на совещание, требуют какой-то неведомой ерунды или наоборот, не читают ваше ТЗ, а потом удивляются «что за ерунду они реализовали». Знакомо? Что же делать в такой ситуации?
Если внимательно пролистать блог, то там есть достаточно много статей по поводу коммуникации и взаимодейтствия, но, думаю, будет полезно свести некоторые из них в этом посте, чтобы получилась цельная картинка. Итак, возвращаемся к вопросу «а что же делать и как управлять рабочей группой проекта?».
Во-первых – понять и смириться с тем, что Вы для рабочей группы никто, скорее даже враг – вы отнимаете их рабочее время и пытаетесь заставить их потратить на то, за что они, скорее всего, денег не получат. Можно сколько угодно апеллировать к выгодам для компании, но начальники отделов или ключевые пользователи, которые обычно входят в рабочую группу, акционерами вряд ли являются. Они делают свою работу, получают за это зарплату и хотят домой к ребенку на утренник. А вы их за те же деньги пытаетесь заставить сделать больше, никакой особенной альтернативы не предлагая. И даже если проект предусматривает материальную мотивацию, деньги – аргумент не для всех, а поколение Y так вообще ценит свободное время гораздо больше денег.
Во-вторых – вспомнить самый детский уровень теории проектного управления – у каждого проекта должен быть спонсор. Отчитываться вам рабочая группа, возможно, и должна (это если вы молодец, подстраховались, уговорили директора подписать приказ и все такое), но она так не считает, так как см. п.1 – вы для них никто. Поэтому изначально, еще на этапе согласования проекта, нужно этого спонсора определить и донести до него, что вы всей душой за результат и что ваш многолетний опыт говорит, что спрашивать с рабочей группы должен он или Заказчик проекта (дальше для простоты буду называть этого человека спонсором).
Как это сделать в реальности? Если есть возможность, организуйте регулярные совещания рабочей группы с участием спонсора проекта, перед совещанием проведите с ним краткий обзор выполненной работы, чтобы он понимал, кто и что не выполнил, и какие последствия для проекта это несет. На совещании спонсор требует от членов рабочей группы отчитаться и выдает живительные пинки, если нужно. Важно! Это работает только если спонсор «настоящий», искренне заинтересованный в успехе, а не «для галки». Если для галки, и реального спонсора у проекта нет – то с этого проекта лучше бежать, пока не поздно, все равно успех маловероятен.
В-третьих – построение взаимоотношений с членами рабочей группы никто не отменял. Будет полезно аккуратно рассказать пару позитивных историй о карьерном росте людей, участвовавших в автоматизации чего-либо (подробнее в этой статье). Если в вашу рабочую группу входят в первую очередь ключевые пользователи – можно подумать о том, что их может мотивировать – повышение их ценности на рынке труда, более интересная проектная работа вместо рутинной и проч.
В-четвертых – и это не противоречит третьему – не бойтесь эскалировать проблему на спонсора, если она уже возникла. Если вы попробовали решить ее с членом рабочей группы и не смогли договориться – это бизнес, честно говорите, что вас такой ответ не устраивает, вам нужен результат проекта. Мол, я вам не руководитель, признаю за вами право иметь свое мнение по этому вопросу (например, вопросу посещаемости встреч рабочей группы), но поймите и меня – мне за это деньги платят, я буду вынужден эскалировать этот вопрос на <тут подставить имя>. Минимум в половине случаев на этом этапе ваш собеседник найдет время, предложит обсудить вопрос еще раз или еще как-то пойдет навстречу. Вы не давите, вы предупреждаете об опасности – вы теперь друг, а не враг. А если до эскалации все-таки дойдет – вы честно предупредили, а не «настучали за спиной», к вам претензий тоже быть не может.
Универсальное правило эскалации, если вы ведете проект в относительно небольшой компании – постарайтесь выйти на собственника или материально заинтересованного руководителя. В среднем бизнесе решение о вложении в автоматизацию принимаются обычно на этом уровне, так как удовольствие для них это достаточно дорогое. Кто-то в рабочей группе недорабатывает и может похоронить вложенные 5 млн. рублей? Да собственник их оторвал от дочки, обучающейся в Оксфорде, и она там теперь перебивается meal deal’ами в Теско за 3 фунта вместо йоркширского пудинга! Будьте уверены, сотрудника из рабочей группы мотивируют так, как вам и не снилось.
Минутка ностальгии – один из моих самых успешных проектов во времена работы в консалтинге – это автоматизация работы с судебными делами в небольшой оценочной компании (около 80 сотрудников), работавшей в области строительной оценки. Буквально на второй эскалации сотрудники поняли, что я не шучу и пойду снова и снова к собственнику при необходимости. До сих пор интересно, что он с ними делал, но после эскалации все были бесконечно милы и исполнительны.
В-пятых – пересмотрите свой план коммуникаций, возможно, это вы перегибаете палку и достали уже всех в этом отделе или этой компании? Нельзя требовать от всех того, что ваш проект будет для них самым приоритетным, они не за это деньги получают, у них есть свои KPI отделов, от которых вы их отвлекаете. Планируйте работу с учетом того, что среднестатический руководитель не сможет тратить на вас больше 10% рабочего времени, и это в случае, если проект действительно важен для компании, и руководство смогло это донести.
Поэтому договаривайтесь об итеративной приемке, например, ТЗ – не «у вас месяц на согласование», а «у вас 3 дня на согласование части «1.7. Основные пользователи системы», так как без этого мы не можем двигаться дальше». Кусочками людям делать проще. То, что руководитель выделит время в своем расписание на чтение 20 страниц раз в неделю на протяжении 6 недель, более вероятно, чем на 120 страниц сразу, в лучшем случае – просто подмахнет, не глядя. Ну и результат, скорее всего, будет более качественным.
Также постарайтесь получать от членов рабочей группы личное подтверждение согласия с план-графиком и работами, которые выполняют они лично или их отдел. Если надо – потратьте время, посидите вместе, пройдите по каждой задаче, обсудите ее содержание, сроки и влияние на весь проект. Тогда и человек лучше поймет, чего вы от него хотите, и психологически ему будет сложнее вам отказать. Иначе при рассылке письма с планом и фразой, мол, кто не согласен – напишите в ответ – вы попадаете в ситуацию коллективной безответственности типа «ну вы же не сказали «нет»! – но и «да» я не сказал!». Чтобы прикрыть тылы – пойдет, чтобы получить результат – не очень.
В-шестых – работает не всегда, сразу предупреждаю – в случае относительно молодого коллектива можно ввести элементы геймификации и современных приемов анализа и взаимодействия – не заставляйте всех читать 120 страниц ТЗ, нарисуйте персонажа, расскажите всем пользовательскую историю так, что бы все зарыдали, покажите прототип, наконец. Вот тут-то и полезут всякие «на самом деле у нас не так все», «нет, это не взлетит, потому что…», только успевай записывать. Клейте стикеры, рисуйте графики, вручайте шоколадки за самое большое количество идей, используйте «методику 6 шляп» (лично я всей душой ее ненавижу, но некоторым нравится). Инструментов сотни, главное – вовлечь в процесс, чтобы встречи с вами ждали с посылом «это будет фан» или «научимся чему-то новому», а не «опять придет унылый чувак с ТЗ по ГОСТу». Тут, кстати, хорошо помогает посещение отраслевых конференций по анализу или фасилитации, там часто интересные фишки проскакивают.
Таким образом, если у вас не складываются отношения с рабочей группой, возможно, “вы просто не умеете их готовить”? Попробуйте воспользоваться рецептами выше и расскажите о результатах. У меня работает, рабочая группа обычно получается очень даже ничего. Но всегда есть куда совершенствоваться, поэтому если есть вопросы или дополнения – пишите в комментариях, буду рада обсудить.
Добавить комментарий