Управление человеческими ресурсами проекта

Что следует учитывать при выборе ресурса в проектную команду?

0

Что следует учитывать при выборе ресурса в проектную команду? Когда мы задумываемся над этим выбором – следует рассмотреть ряд вопросов:

  • Доступность - когда и сколько доступен ресурс? Может ли возникнуть ситуация то его заберут на более приоритетный проект а вам будет грозить смена ресурса?
  • Опыт – ресурс решал ранее подобные задачи?
  • Цена – каждый ресурс стоит денег. Сколько он стоит? Ваш бюджет может себе такое позволить?
  • Заинтересованность – перед назначением поговорите с кандидатом.
  • Качество работы – насколько качественно выполняется работа?
  • Скорость работы – как быстро выполняется работа? как быстро ресурс может быть подключен к проекту?
  • Отношения – установлены ли хорошие отношения между ресурсом и текущей командой проекта?

Спрашивайте про отсутствие

0

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

Неизвестное отсутствие ключевых участников проекта как со стороны заказчика так и внутри команды проекта – это риск существенного сдвига сроков. И этот риск один из наиболее часто срабатывающих практически в любой период. Летом отпуска – более прогнозируемое. Зима – люди могут заболеть в любой момент, наибольший риск – эпидемии.

Отсутствие может быть самое разное. Для каждого из типов отсутствия стоит предпринимать разные действия:

  • Отпуск - получайте данные у HR но обязательно сверяйте с сотрудником и его руководителем. Часто встречается ситуация когда отпуск в кадрый подает за год, а потом планы на отпуск меняются.
  • Командировка - уточняйте как у сотрудника так и у его руководителя
  • Обучение - уточняйте как у сотрудника, у его руководителя и у HR. Есть такие виды информации которые могут знать только HR (их планы по обучению сотрудников), только сотрудник (его личные планы по обучению), руководитель (договаривается об обучении сотрудников с тренером)
  • Личные события (свадьба, лечение, небольшие отсутствия, посидеть с ребенком) – у сотрудника.
  • Болезнь - уточните как человек часто болеет. Есть такие люди которые болеют пару дней в году, а есть такие – которые 3-4 раза по неделе за зиму. Уточните есть ли дети и как часто они болеют

 

Отчёты работают только для самодисциплины

0

Отчёты работают только для самодисциплины, а при принудиловки и обязаловке превращаются в профанацию и имитацию.

 

http://habrahabr.ru/blogs/agile/111732/#comment_3567856

Геймификация

0

Только сегодня, честно говоря,  познакомился с новым для себя термином в управлении проектами – Геймификация. А узнал я о нем из новости:

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

Для компании по-умолчанию создается 50 закрытых (locked) бейджей (достижений), которые могут открывать сотрудники. Т.е. получается, компания играет, как единая команда (включая руководителя) против авторов игры (как знатоки против телезрителей). Потенциально сервис даже может устраивать соревнования между девелоперскими компаниями. Заработанные за выполненные задачи и проекты очки сотрудники могут потратить во встроенном магазине призов (Rewards Store).

ИМХО идея не нова – но ее реализация в ядре системы управления проектами уже интересно. Правда говоря – простые методы рассчета компенсации для сотрудников уже много где есть. А тут еще и много нематериальной составляющей ;-)

О Геймификации – http://www.livebusiness.ru/news/9905/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+livebusiness+%28LiveBusiness%29

Компоненты информационной среды управления проектами

0

Для более менее крупных проектов мы задумываемся о построении информационной системы для управления проектами. Прежде чем говорить – да у нас есть MS Project – и в северном варианте (Project Server) он будет очень классно покрывать все нужды – не спешите. Давайте рассмотрим основные компоненты такой среды и какие потенциальные компоненты могут подойти.

Коммуникации - сайт проекта, форум, рассылка, группы. Это может быть как сайт на SharePoint так и любая WiKi/Wordpress/LinkedIn группа. Для небольшого бизнеса вполне удобно создавать закрытые группы в социальных сетях и использовать их как готовые платформы для проектных коммуникаций.

Документы проекта – минимум файловый сервер. Лучше всего – сразу SharePoint или аналогичное средство с функционалом управления версиями. Если документы проекта будут готовиться исключить в веб форме – то вам также отлично подойдут Wiki системы. В них очень легко контролировать версии документов (но несколько сложнее научиться писать их с использованием внутренней разметки)

Записи проекта - это различные типы записей – структура работ, запросы на изменения, вопросы, дефекты, риски, требования, тесты, результаты выполнения тестов. Кроме фиксации самих записей важно чтобы работали хотя бы простые workflow по организации работы над записями – это даже крайне желательно. Для управления такого рода записями нужна система с удобным конструктором как новых записей так и процессов, удобными формами. SharePoint в базовой конфигурации для этого не очень хорошо подходит (но вполне терпимо для малых проектов). Хорошим кандидатом сюда – Microsoft Dynamics CRM  2010, SharePoint + Nintex + кастомные решения для организации документооборота. Также могут подойти ваши существующие ERP системы (в них легко создавать новые сущности и формы но менее просто решаются вопросы по автоматизации процессов)

Календарь проекта и Фактические данные – тут рулит Microsoft Project.

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

 

Неправильные 8 часов в день

0

По умолчанию доступность ресурса участника проекта в день 8 часов. Однако можем ли мы оставить данную оценку по умолчанию? Я думаю нет. И тому есть ряд причин.

Эффективная сосредоточенная работа среднего офисного специалиста – за вычетом рабочих совещаний, звоноков телефона, прочтения почты, шуток коллег, отвлечений в Интернете, после обеденной дремы – я не думаю что превыщает 4 часа. Можно накинуть максимум 2 часа на “тупую” работу за чашкой кофе + в наушнкиках после обеда. Все.

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

Следовательно что правильно сделать – заложить во все ресурсы что у них есть в проекте НЕ БОЛЕЕ 6 ЧАСОВ В ДЕНЬ. И это в идеале – когда нет другой операционной работы и других проектов.

Т.е. закладываю 8 часов в день мы себя обманываем на 30% минимум!

Менеджер проекта по неволе. Как спасти человека и проект?

0

Руководство любит тыкнуть пальцем в одного из инженеров и сказать – ты будешь менеджером этого проекта.

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

Как объяснить руководителю что он сделал неверный выбор, демотивировал сотрудника и поставил под огромный риск успех выполнения проекта?

Критичность закрытия фаз/итераций. Пример из практики

0

Очень важно в крупных корпоративных проектах закрывать фазы (этапа, итерации) согласованием пакета закрывающих документов.

 

Сам факт закрытия фазы позволяет:

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

Из практики отечественных проектов встречались ситуации когда в проекте на этапе зависли на согласовании несколько аналитических документов. Казалось бы согласованным в документах было около 80%. Команда проекта решила что необходимо двигаться к разработке и по ходе решить оставшиеся 20% требований. Однако в течении нескольких последующих месяцев это привело к тому что

  • аналитический документ и зменился более чем на половину
  • объем работ вырос в полтора раза
  • было потеряно около трети времени на разработку в следствии кардинального изменения
  • существенно изменились сроки проекта
  • поставщик понес убытки на потерянном объеме работ
  • клиент был недоволен что “его по-прежнему не пониманию и делают всякую ерунду”
  • клиент наблюдая податливость в протягивании согласования аналитического документа позволял себе “пропихивать” новые изменения и расширять рамки проекта

Дайте возможность людям выбрать проект и команду

0

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

Успех порождает успех

2

ДеМарко в Человеческом факторе замечательно написал про фактор успеха в проектной команде: “Успех порождает успех, а продуктивная гармония – еще более продуктивную гармонию. … Весь проектный опыт состоит из достижения маленьких успехов совместными усилиями. … хорошие руководители стараются как можно чаше предоставлять команде возможности для совместного успеха. Это могут быть маленькие пилотные подпроекты, …, все что помогает создать в команде привычку добавиться успехов вместе.”

Go to Top