Как мотивировать участников проекта

Проблемы в управлении проектами известны всем. Зачастую проекты завершаются с нарушением сроков, с превышением бюджета и неудовлетворенностью клиентов полученным результатом, отличающимся от ожидаемого. Часть из проектов останавливаются на полпути и заканчиваются крахом. Для решения этих проблем в компаниях внедряется система Project Management, используется программное обеспечение и разрабатывается система вознаграждения.

Система вознаграждения в проектах

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

При этом используются два варианта взаимосвязи с вознаграждением:

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

Таблица 1. Расчет размера вознаграждения в зависимости от срока завершения проекта

Время выполнения этапа (проекта)

Сумма вознаграждения, тыс.рублей

Задержка более 30 дней

0

20-30

20

10-19

50

5-10

70

1-5

80

В срок

100

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

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

Таблица 2. Таблица целей и показателей менеджера (руководителя) проекта


Цели

KPI

Вес, %

1

Выполнение стандартов

Количество отклонений от стандарта

20

2

Выполнение плана по загрузке

Количество чел. часов.

15

3

Соблюдение сроков проекта

Отклонение от срока

20

4

Выполнение бюджета

Норматив по бюджету

15

5

Достижение удовлетворенности клиента

CSI-индекс удовлетворенности клиентов

30

В данном случае мы видим сбалансированную таблицу показателей, в которой используются:

  • финансовый показатель – бюджет,
  • клиентский: CSI – индекс удовлетворенности клиентов,
  • процессный показатель – количество отклонений от стандарта проекта.

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

Таблица 3. Зависимость вознаграждения от результативности

% результативности,

Ri

Вознаграждение, % от оклада

Менее 80

0

80-84

15

85-89

20

90-94

30

95-99

40

100-109

50

110 и более 110

60

В данном примере используются два порога: нижний, в котором при результативности менее 80% премия не выплачивается, и верхний – при результативности более 110% и выше руководитель проекта получает максимальное вознаграждение 60% к окладу.

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

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

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

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

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

Это конфликт, о котором говорил еще Эдвард Деминг: «работа во имя отдельной части системы не ведет к успехам всей системы». Таким образом, система вознаграждения, поддерживающая такое поведение, неэффективна для бизнеса. Если выразиться конкретней, то вознаграждение сотрудников только за выполнение своих индивидуальных показателей не работает. Очень важно, чтобы участники вознаграждались именно за выполнение системной цели всего проекта (бизнеса). Еще Элияху Голдратт в своих работах писал «Жесткая привязка системы премиальных к срокам выполнения операций в проекте – пример неэффективного менеджмента». Голдратт видит решение проблемы (конфликта) во внедрении ССPM – Critical Chain Project Management – управления проектом по методу критической цепи. Данная система предусматривает наличие метода критической цепи – мощного инструмента, управляющего с помощью буферов, использующего работу участников проекта в стиле «эстафеты» и учитывающего ограничения в проекте.

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

На практике (пока в основном в зарубежных компаниях) внедрение ССPM показало свою универсальность и состоятельность на проектах разных типов. Один из самых успешных (проект завершился раньше срока и в рамках бюджета) реализован в компании Lucent Тechnologies. Однако внедрить данный подход совсем непросто: мешают установки, сложившиеся годами, стереотипы в поведении, сложившиеся в течение нескольких лет, управленческие парадигмы, системы оценки и устаревшие системы вознаграждения сотрудников. Для внедрения метода ССPM, способствующего выполнению проекта в срок (или раньше запланированных сроков) и без превышения бюджета необходимы:

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

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

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

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

Какое решение может быть принято?

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

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

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

Конечно, такой подход неидеален, так как в нем есть наличие некой доли субъективности оценщика: руководителя проекта. Поэтому HR-менеджерам или специалистам по компенсации необходимо время от времени контролировать результаты оценки и их корреляцию с показателями (по использованию процента буфера бюджета проекта и процента использования временного буфера).

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

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

Впервые статья была опубликована на Executive.ru 16 мая 2013 года в рубрике «Творчество без купюр». Реанонсирована в контентном блоке в рамках специального проекта редакции

Источник фото: facebook.com

Расскажите коллегам:
Комментарии
Управляющий директор, Украина
Владимир Токарев пишет: там есть Ваш комментарий, но, к сожалению, нет ответа экспертов ТОС)
Давайте немного уточним предмет разговора. Я не говорю, что ТОС не работает и совсем не выступаю против данного метода управления. Но я утверждаю, что на сегодняшний день между ТОС и РМ нет принципиальных различий, на что так любят указывать апологеты ТОС. Я так дуиаю, что именно поэтому любое предложение к апологетам ТОС обосновать эти различия остаются без ответа. По крайней мере я их не получил еще ни разу. Я более 10 лет изучаю и применяю в работе РМ (в изложении PMBoK) и уже более трех лет изучаю ТОС и на своем опыте могу сказать следующее: 1. Противопоставление ТОС и РМ является сущей ерундой, которую пишут как правило те, кто явно плохо знаком с РМ. На сегодняшний день между ними нет принципиальных различий. ВСЕ (без исключения) подходы ТОС применяются и в РМ. 2. Полезен ли метод ТОС? Безусловно полезен. 3. Но еще более полезным является РМ. Просто в силу того, что ТОС - всего лишь часть методов РМ. РМВоК охватывает гораздо больший круг методов управления проектами. Можно с уверенностью утверждать, что ТОС - это упрощенный современный РМ.
Управляющий директор, Украина

P.S. Весьма рекомендую ознакомиться с ответом Сергея Вратенкова по данной вами ссылке

http://www.e-xecutive.ru/knowledge/announcement/1389208/?page=11

Генеральный директор, Нижний Новгород
Владимир Глинский пишет: P.S. Весьма рекомендую ознакомиться с ответом Сергея Вратенкова по данной вами ссылке
Я уже отмечал, Владимир, что я всего лишь практик (управляю проектами, и скорее интуитивно, чем по какой-то методе, проблемы есть - и по срокам, и по бюджету, и по содержанию - потому и интерес к УП по ТОС) но не теоретик (пока) этих методов. Однако: - также рекомендую почитать ответы Федурко (там же) на указанные Вами комменты. - и если бы нового не было, зачем включать раздел 6.5.2.6 ?
Управляющий директор, Украина
Если вы обратите внимание, то ответы Федурко и других аппологетов ТОС (включая Л.Лича) построены на одной логической ошибке (уж не знаю сознательно или не осознанно), а именно Fallacia fictae universalitatis. Термин логики Fallacia fictae universalitatis обычно на русский язык переводят как «Ложное обобщение». Эту ошибку совершают те, кто выносит вердикт обо всем классе предметов или явлений на основании вывода о нескольких представителях данного класса. Т.е., когда говорят о РМ, то ссылаются на статистику - ОБЩУЮ картину по всему классу. А когда говорят о ТОС, то ссылаются на ОТДЕЛЬНЫЕ проекты, по которым нельзя судить об успешности всего класса. Для корретного сравнения нужно применять одинаковые подходы. Статистику по ТОС нигде не видел (подозреваю что ее и нет), но есть у меня весьма серьезное мнение, что ОБЩАЯ картина по ТОС будет хуже чем по РМ. В силу того, что ТОС, как я уже писал, - это весьма упрощенный вариант РМ. Инструментарий ТОС намного меньше чем в РМ и в силу этого РМ более гибкая, адаптивная и всеобъемлющая система чем ТОС. Но опять же, я не говорю, что ТОС нельзя успешно применять. В определенных случаях (относительно небольших проектах или в управлении производством) ТОС вполне может быть успешным. Но я против того, чтобы позиционировать ТОС как лучшую альтернативу РМ. Это абсолютно не верно. Чтобы убедиться в этом, достаточно всего лишь посмотреть на перечень групп процессов управления, которыми оперирует РМ и которыми оперирует ТОС. Упоминание раздела 6.5.2.6 не понял. Это раздел чего? Ссылку можна?
Генеральный директор, Нижний Новгород
Владимир Глинский пишет: Упоминание раздела 6.5.2.6 не понял. Это раздел чего? Ссылку можна?
Владимир Токарев пишет: я просто дам цитату из Лича, первый доклад которого по теме был в Калифорнии в 1998 году: ''метод критической цепи как один из способов составления графика проекта (он новый - ВТ) должен быть официально включен в руководство PMBOK издания 2004 года'' (редактор книги Лича отметил - CCPM уже описана в редакции 2004 года в разделе 6.5.2.6)
Владимир Глинский пишет: ТОС, как я уже писал, - это весьма упрощенный вариант РМ. Инструментарий ТОС намного меньше чем в РМ и в силу этого РМ более гибкая, адаптивная и всеобъемлющая система
Беру тайм-аут как минимум до осени (сейчас другая срочная работа) - тогда почитаю указанную книгу Лича. Но в этой книге Лич не противопоставляет классику методу критической цепи, а описывает как они полезно дополняют друг друга. Спасибо за общение.
Управляющий директор, Украина

1. Совершенно верно, Л. Лич нигде не противопоставляет ТОС и РМ. В отличие от некоторых современных апологетов ТОС. Может быть потому, что Лич хорошо знал РМ, а нынешние знают о современном РМ весьма поверхностно.
2. РМ - синтетическая, динамично развивающаяся дисциплина, впитывающая в себя все лучшие достижения в управлении проектами. РМВоК уже в 5 редакции. В отличие от ТОС, которая на протяжении уже нескольких десятилетий остается без существенных изменений.
3. Всегда рад приятному собеседнику. Удачи вам в работе и жизни.

Нач. отдела, зам. руководителя, Москва

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

1 4 6
Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
3
Евгений Равич
Могут быть совершенно обычные лекарства, но в другой дозировке или не показанные конкретному чел...
Все дискуссии