Отправляет email-рассылки с помощью сервиса Sendsay

Совет недели менеджеру проекта

Подписаться Бесплатная «Серебряная» новостная рассылка Подписчиков 398 RSS
←   Октябрь 2014   →
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31


За последние 60 дней ни разу не выходила


Сайт рассылки: http://tenstep.com.ua/open/miscpages/94.4Sign-Up.htm
Открыта: 18-06-2008

Автор
TenStep Inc.

Статистика

398 подписчиков
0 за неделю
←   Все выпуски   →

Совет недели менеджеру проекта: Обходим 'грабли' при оценке участников команды проекта


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

Обходим «грабли», оценивая участников команды проекта

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

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

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

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

Грабли №1 — шаблонность, она же бездумность. Если мы будем монотонно «клеймить позором» любого, кто не уложился в плановый срок, то больше всего достанется не тем, кто плохо или мало работает, а тем, кто оптимистически оценивает свою работу. Часть из них будет терять оптимизм и мотивацию (а Вы хотели бы работать с командой демотивированных пессимистов?). Другие будут торопиться и косячить (кстати, Вы уверены, что это лучшая альтернатива отставанию?). Притом, и те, и другие начнут завышать исходные оценки, делая Ваш проект или бизнес Вашей компании неконкурентоспособным.

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

Менее частое, но не менее важное приложение индивидуальной оценки — обратная связь по производительности, которую мы даем членам команды при подведении итогов фаз или при завершении проекта в целом. Главной целью оценки при этом (твердо запомним это) является непрерывное улучшение производительности команды. Безусловно, к такой оценке тоже стоит подходить разумно, поскольку нас подстерегают…

Верно. Грабли №2 — игнор социального аспекта. Мне не раз приходилось сталкиваться с тем, что усиление проекта в его решающей фазе путем замены «слабеньких» членов команды «крутыми спецами» приводило к серьезному падению производительности, внутренним конфликтам или вовсе вводило команду в ступор. Давайте не забывать, что команда — это социум или особая система, где каждый участник играет не только проектную, но и социальную роль (как там у Белбина?). Причем, социальная ролевая структура складывается далеко не один день: Forming, Storming, Norming и только потом Performing. Такмана тоже помните? А вот разрушить социальное равновесие в один день — очень даже запросто.

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

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

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

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

Грабли №3 — Key Performance Indicators (KPI) для членов команд проектов. Очень модно звучит. Очень много умных слов сказано и написано. Очень много денег заработано внешними и внутренними консультантами. Но за 20+ лет проектной карьеры я не встретил ни одного примера успешной реализации, зато провальных — хоть отбавляй. В отличие от KPI для команд проектов, где это вполне работает, внедрение формальных метрик на уровне отдельной личности (особенно, если эта личность интеллектуальна, а то еще и креативна) чаще всего теряет тот смысл, ради которого все это затевается. На будущее, акцентируем внимание на этом смысле: рост индивидуальной и коллективной производительности путем привязки к ней материального и прочего стимулирования.

Установить и измерить показатели производительности отдельно взятого члена команды конечно же можно. Но в какой-то не совсем прекрасный для проекта момент, обычно оказывается, что проект в штопоре, а KPI каждого из членов команды вполне даже и ничего. Не раз я восхищался интеллектом и находчивостью своих и чужих коллег именно по такому поводу. Причем особенно быстро процесс адаптации работы «под KPI» происходит в случаях, если индивидуальные KPI каким-то образом влияют на уровень денежного вознаграждения. А между тем, в этом и есть смысл KPI.

Так что же делать? Да ничего особенного. Как говорится, чтобы не разочаровываться, давайте не будем очаровываться. Не пытайтесь улучшить и доработать систему индивидуальных KPI, это борьба с интеллектом Ваших коллег, перспективы в которой у Вас не будет. Если все же Вашу команду упорно «обкладывают» индивидуальными KPI, не так уж трудно бывает саботировать или даже дискредитировать эту идею. Взамен, покажите руководству, что традиционные командные показатели проекта, да хотя бы CPI и SPI, более объективны, информативны и более показательны для бизнеса компании и для заказчика. Покажите результаты Вашей оценки 360 градусов, руководству это тоже понравится. На крайний случай, если у Вас не получилось отвертеться, не особенно расстраивайтесь: разумный человек способен обернуть себе на пользу и не такие обстоятельства.

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

Юрий Плахов, PMP, TSPM

Читать статью в блоге...

Подготовка к PMP и PMI-ACP в Харькове, Днепропетровске и Киеве

Уважаемые коллеги,

Приглашаем принять участие в семинарах по подготовке к сертификациям PMP и PMI-ACP, которые пройдут до конца осени в Харькове, Днепропетровске и Киеве.

Занятия проводятся по выходным дням. Действуют скидки и опции поэтапной оплаты.

Подробности и предварительная регистрация на мероприятия на нашем сайте.

Вечер профессионального развития

ТенСтеп Украина и PMI Ukraine Chapter проводят вечер профессонального развития, который состоится в Харькове 30 октября с 19 до 21 часов. В программе вечера обсуждение следующих тем:

- Инструменты и методы УП: Визуализация рисков проекта

- Виды контрактов для сервисных IT компаний: преимущества и недостатки

- Инструментарий результативности: Использование Microsoft OneNote в качестве ежедневника и персональной базы знаний

- Разбор практических кейсов экспертами.

Участникам вечера засчитываются 2 PDU. Детальная информация, регистрация и подача интересующих тем и кейсов - на сайте PMI Ukraine Chapter.

В каждой шутке есть доля шутки:

Топ 10 вещей, которые ПМ не должен говорить заказчику:

10. Раз это Вас так же удивляет, как и меня, то вероятно, Вы и знаете не больше меня.
9. Не огорчайтесь. Это проще, чем кажется.
8. Не понимаю, что случилось. В прошлый раз это работало.
7. Эксплуатация? Мы подумаем об этом, когда подойдет срок.
6. Проблема в том, что у нас слишком много работы и слишком мало людей.
5. Мой последний проект был тотальной катастрофой.
4. Мы можем сделать поставку гораздо раньше, чем вы просите.
3. Бюджет? Я уверен, что нам его не хватит.
2. Я обещаю, что все будет идти по плану.
1. Вы идиот?

Поделитесь этим письмом с друзьями. Адрес формы для подписки на еженедельную рассылку: http://tenstep.com.ua/open/miscpages/94.4Sign-Up.htm
В избранное