Главная Случайная страница


Категории:

ДомЗдоровьеЗоологияИнформатикаИскусствоИскусствоКомпьютерыКулинарияМаркетингМатематикаМедицинаМенеджментОбразованиеПедагогикаПитомцыПрограммированиеПроизводствоПромышленностьПсихологияРазноеРелигияСоциологияСпортСтатистикаТранспортФизикаФилософияФинансыХимияХоббиЭкологияЭкономикаЭлектроника






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

 

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

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

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

Другие говорят о том, что надо сделать работу как можно более привлекательной. Здесь на первое место выходит роль ритуалов. Люди чувствуют приверженность проекту, так как им просто нравится работать вместе. А кто-то из управляющих проектами сделал признание, что стопроцентная явка на рабочие совещания главным образом объяснялась желанием попить кофе с превосходными пончиками, которые подавали во время совещания.

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

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

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

 

 

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

А 1. Работник решает задачу или принимает решение самостоятельно, пользуясь имеющейся в его распоряжении информацией.

А 2. Работник получает необходимую информацию от других членов команды. Он может сказать, а может и не сказать другим работникам, в чем заключается проблема, перед тем, как получить у них информацию. Члены команды предоставляют информацию, но не вырабатывают и не оценивают решения.

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

С 2. Работник делится проблемой с командой, выясняет мнение и получает советы от команды в целом. Он принимает решение на основе своего понимания полученной информации.

G. Работник делится проблемой с командой, обсуждает ее с группой, и принимает решение на основе группового консенсуса.

 

С целью помочь работнику проанализировать ситуацию и выбрать наиболее приемлемый метод принятия решений, Врум и Джаго использовали схему, аналогичную показанной на рис. 10 - 4. Ключевыми параметрами являются качество принимаемых решений, наличие и местонахождение необходимой информации, и приверженность, необходимая для полного внедрения решения. Модель неприемлема для срочных проблем, требующих немедленного внимания, таких, как экстренные ситуации. И все же модель четко указывает, что время играет важную роль, и решение дольше принимается группой, чем отдельным работником. Следовательно, рекомендуется принимать групповое решение только в тех случаях, когда это диктуется ситуацией.

 

Чтобы понять, как работает схема, давайте применим ее к конкретной ситуации. Допустим, что управляющий проектом руководит небольшой группой, состоящей из 15 специалистов по информационным системам (IS), которая должна разработать работающую модель электронной системы заказов через Web-страницы. Проект разрабатывается ровно половину отведенного на него времени и отстает от графика на пять дней. Вас беспокоит возможность не разработать проект в срок. Вы взвешиваете возможные варианты. Один из них состоит в том, чтобы согласиться с отставанием от графика и соответственно этому график пересмотреть. Это значит, что команда не получит премии за выполнение работы в срок. Другой вариант - пригласить на работу еще одного программиста, который будет заниматься кодированием. Мнения членов вашей команды о статусе проекта разделились. Одни боятся, что в первоначальную схему вкралась ошибка,которая и привела к отставанию от графика. Другие считают, что ошибки неизбежны, и худшее уже позади. Кто-то даже готов работать по выходным, чтобы вернуться к первоначальному графику.

 

Используем схему на рис. 10 - 4 и выберем подходящий для этой проблемы процесс принятия решений. Первый квадрат слева — это QR (требование к качеству решения). Нужно определиться, высокое или низкое будет требование. Определившись, переходим к следующему квадрату, или CR (приверженность). Вам снова надо принять решение, насколько важна приверженность членов команды итоговому решению. После принятия этого решения вы должны принять следующее и т.д. Принимая решение, идите по соответствующей линии к следующему квадрату. В итоге, приняв 8 решений, на противоположном конце схемы рис. 10 - 4 вы придете к рекомендуемому процессу принятия решения. Проверьте, совпадают ли ваши решения с выбором авторов (см. таблицу 10 - 1).

 

Параметры проблем Ключевые вопросы
QR Качество решений Степень важности технического качества решения
CR Приверженность Степень важности приверженности команды решениям
II Информированность работников Наличие достаточной информации для принятия качественного решения
ST Структура проблемы Насколько хорошо структурирована проблема?
CP Вероятность приверженности Если это единоличное решение, то есть ли уверенность в том, что остальные члены команды с ним согласятся?
GC Совпадение целей Согласны ли остальные с целями, которых нужно достичь, решая данную проблему?
CO Разные мнения членов команды Вероятность несовпадения мнений остальных членов команды относительно принятого решения
TI Информированность команды Обладают ли члены команды достаточной информацией для принятия качественного решения?

 

 

Рис. 10 - 4. Модифицированная схема процесса принятия решений Врума и Джаго

 

Таблица 10 - 1. Анализ принятия решений

 

Параметр Ключевой вопрос Ответ
QR Степень важности технического качества решения Высокая
CR Степень важности приверженности команды решениям Высокая
II Наличие достаточной информации для принятия качественного решения Вероятно, нет
ST Насколько хорошо структурирована проблема? Нет
CP Если это единоличное решение, то есть ли уверенность в том, что остальные члены команды с ним согласятся? Вероятно, нет
GC Согласны ли остальные с целями, которых нужно достичь, решая данную проблему? Да
CO Вероятность несовпадения мнений остальных членов команды относительно принятого решения  
TI Обладают ли члены команды достаточной информацией для принятия качественного решения? Вероятно, да
Ответ:G (принятие решения на основе консенсуса)

 

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

- Выбирают ли члены команды наиболее подходящий подход, когда сталкиваются с проблемой?

- Не тратим ли мы драгоценное время на совещаниях, обсуждая проблемы, не требующие всеобщего обсуждения?

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

 

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

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

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

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

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

2. Выработка альтернатив.Когда достигнуто общее согласие относительно сути проблемы, на первое место выходит необходимость выработать альтернативные решения. Если проблема творческая, необходим мозговой штурм. Команда вырабатывает перечень возможных решений. Это период моратория на критику и оценку предлагаемых идей. Нужно поощрять членов команды развивать предполагаемые коллегами идеи или объединять их и получать новую. Задача в том, чтобы было как можно больше вариантов, какими бы неприемлемыми они ни казались. Некоторые управляющие проектами предпочитают проводить обсуждение особо сложных проблем не на основном рабочем месте: изменение обстановки стимулирует творчество.

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

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

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

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

 

Последнее изменение этой страницы: 2016-08-11

lectmania.ru. Все права принадлежат авторам данных материалов. В случае нарушения авторского права напишите нам сюда...