Статья в оригинале: How to avoid and Manage Troubled Projects: Applying the Zen Approach to Project Management™ By George Pitagorsky, PMP
Для начала, советую прочесть первую часть перевода статьи. Во второй части речь идет о процессе управления проблемами.
Процесс
Процесс управления проблемными проектами включает в себя три фазы: планирование проблем, решение проблем и обзор.
Планирование проблем - процесс разработки системы по избеганию, обнаружению и устранению проблем. Составной частью такого планирования является разработка оценок и способов отчетности по проекту, и других частей плана управления коммуникациями. К этому этапу также относится планирование рисков, анализ рисков и планирование реагирования на риски. Планирование проблем - весьма существенная часть планирования проекта.
Решение проблем - приведение плана работы с проблемами в действие. Этот этап имеет место в фазе исполнения проекта и состоит из следующих шагов:
- Обнаружение проблемы
- Анализ причины и следствия
- Планирование реакции
- Выполнение
Обзор - третий этап в решении проблем, включает в себя анализ успешности решения проблем в течение проекта. Обратите внимание, что обычные отчеты и обзоры во время проекта и по его завершении дополняют специальные отчеты, сфокусированные на том, как устраняются проблемы проекта.
Когда проект завершен, формируется специальный отчет, содержащий извлеченные уроки и информацию о том, как избежать подобных проблем в будущем.
Позже мы подробнее остановимся на каждом из этих этапов.
Подход Дзен
Какое отношение имеет подход Дзен к тому, как мы управляем проблемными проектами?
Подход Дзен к управлению проектами основан на идее о том, что мы должны сохранять спокойствие и собранность перед лицом любого испытания. Несмотря на хаос, царящий вокруг, мы постоянно помним, что жизнь - игра (важная, но все же игра). Помня об этом, мы можем заранее справиться со страхом и другими эмоциями, которые возникают при встрече с проблемами. Мы действуем с точностью, осознавая, что наши поступки и слова непосредственно влияют на происходящее вокруг. Мы оцениваем ситуацию, и реагируем в должные сроки и согласно планам.
Если мы правильно планировали проект, правильно следили за ним и контролировали, нам будет намного сложнее столкнуться с проблемами. А если мы все-таки встретимся с проблемой, мы будем готовы ее решить. Мы действуем реалистично. Мы называем вещи своими именами. Мы избегаем отрицания.
В подходе Дзен несовершенство признается частью совершенства. Во всем есть недостатки, и принятие реальности - путь к совершенству. Более того, сложные ситуации непредсказуемы по своей природе. Мы можем пытаться их контролировать, но полностью от неопределенности нам не избавиться.
Планирование проблем
Парадокс: если мы планируем проблемы, мы избегаем их.
На первом этапе управления проблемами мы планируем их, потому что честно признаем, что проблемы возможны. Как только мы признаем это, мы начинаем серъезно заниматься управлением рисками и коммуникациями. Мы должны убедиться, что наш список рисков включает в себя возможные причины проблем, и используем этот список для определения, избегания ситуаций и условий, которые приведут к проблемам. Ведь самый эффективный способ борьбы с проблемами - предотвращение. И самый хороший способ избежать проблемы - по-честному и реалистично все запланировать.
В рамках плана управления коммуникациями мы описываем способы, которыми мы будем измерять прогресс, сообщать участникам о прогрессе. Оценки для этих измерений должны быть согласованы и должны использоваться в реальной работе. По мере необходимости согласовывается процесс решения проблем. Выполняется назначение ресурсов, описание ролей и ответственностей.
Ключевая роль в процессе решения проблем - помощник или посредник. Это может быть консультант или член ОУП (офиса управления проектами), которого назначают на ранних стадиях проекта для помощи в решении проблем. Этот сотрудник может также привлекаться к проекту во время его выполнения для решения проблем, требующих его вмешательства и для проверки “состояния здоровья” проекта.
Благодаря этому наш проект полностью прозрачен и понятно, кто за что отвечает. Это существенно снизит вероятность получения проблем в проекте. Отсутствие четких зон ответственности и непрозрачность проекта - один из баръеров для решения проблем. Признание необходимости плана управления проблемами проекта помогает пробраться через дебри безответственности.
Чтобы эффективно решать проблемы, все договариваются быть разумными.
Что это значит, быть разумным? Это значит, что мы не будем обвинять сотрудников в опозданиях в их работе или в недостаточном качестве выполненных ими задач. Мы ожидаем определенную степень задержек и ошибок в выполненных задачах. Мы признаем, что проблемы с производительностью очень часто являются системными проблемами (например, постоянное изменение приоритетов и перегрузка ресурсов, а не низкая личная производительность сотрудника могут вызывать задержки).
Это не означает, что все должны расслабиться, делать работу невовремя и некачественно. Конечно же, люди должны нести ответственность за свою производительность, но не следует использовать обвинения для повышения ответственности.
Обвинения разрушительны. Они убивают честную отчетность. Для повышения ответственности за постоянное неуспевание могут применяться различные наказания, вплоть до исключения из команды проекта. Ответственность повышает личную и командную эффективность.
Вся команда должна признать, что “прятать голову в песок” и скрывать правду - очень плохо, и что лучше рассказать о проблеме сразу и подумать, как ее решить.
Составляется план, и проект идет своим чередом. В процессе контроля может загореться красный или желтый “сигнал светофора”, мы сразу это заметим и примем меры. Если все будет происходить именно так, то с проектом все будет в порядке.
Этап исполнения: признание проблем
Этап исполнения начинается с признания того, что проблема есть.
Подход Дзен учит нас объективности и принятию вещей такими, какими они являются на самом деле. Главное препятствие на пути эффективного управления проблемными проектами - отрицание. Даже перед лицом неопровержимого доказательства менеджеры проектов, их руководители, спонсоры проектов и другие заинтересованные стороны не хотят признавать “болезнь” проекта.
Бывают случаи, когда менеджеров проекта и членов команды заставляют игнорировать явные симптомы проблем или их самих считают виновниками проблем, которые уже существуют и на которые они лишь указали.
Отрицание в проектах длится настолько долго, насколько это возможно. Обычно, лишь некая внешняя сила вынуждает участников проекта признать проблемы. Например, публикация ужасно критического обзора, или необходимость сдать очень важную работу, которая не готова и полностью должна быть переделана, может заставить отрицателей признать существование проблем.
Хотя, иногда даже в таких условиях отрицание может продолжаться. Оно может выродиться в очень оптимистичный прогноз сроков исправления проблем (этот прогноз часто не соответствует действительности и призван просто отсрочить момент, когда станет ясно, что все еще хуже).
И отрицание, и проблемы, почти невозможны в проекте, который правильно контролируется и в котором налажены коммуникации. Трудно использовать отрицание, когда все статусы выполнения работ фиксируются в автоматизированной системе, в которой есть механизм для оповещения всех заинтересованных сторон об отклонении от плана.
Если есть внешние наблюдатели, такие как ОУП или команда управления, которые контролируют состояние проекта, периодически проводят совещания-обзоры, и задают трудные вопросы, требующие честных ответов, то в проекте не будет места отрицанию. Естественно, что эти части системы являются результатом хорошего планирования и дисциплированного исполнения.
Отрицанию трудно появиться там, где люди разумно реагируют на появляющиеся проблемы, а не используют общепринятую практику запугиваний, обвинений и штрафов.
Признание проблем может быть быстрым и простым, или долгим и сложным. Это зависит как от культуры организации, в которой протекает проект, так и от профессионализма руководителя проекта и ключевых заинтересованных сторон.
Например, отклонение от запланированного бюджета и сроков очень легко заметить, если проект управляется с помощью методики освоенного объема и для него существуют критерии “зеленого”, “желтого” и “красного” статуса; отчеты от исполнителей содержат в себе правду, а не вымысел; отчеты и анализ формируются в автоматизированной системе. Если количество задач, находящихся в желтой или красной зоне превышает допустимый предел, появилось отклонение от сроков в периоде нескольких недель, количество ошибок при тестировании превышает ожидаемое, то становится ясно, что у проекта проблемы. Если эти тенденции сохраняются или даже усиливаются, то приближается беда.
Вопросы, связанные с межличностным общением в команде намного труднее оценивать, потому что не существует объективных количественных критериев. Поэтому здесь приходится полагаться на общем впечатлении всех заинтересованных сторон, включая участников проекта и наблюдателей. Предполагается, что мы все взрослые люди и понимаем, что вопросы личных отношений в проекте можно и нужно обсуждать.
В проекте очень много споров и конфликтов? Или слишком мало? Сколько это - “очень много”, “слишком мало”? Разрешаются ли конфликты? В чем главная причина споров: личное отношение между участниками, политические вопросы или содержание проекта? Довольны ли клиенты и спонсоры прогрессом проекта, насколько активно они участвуют в проекте? Доверяют ли участники проекта друг другу настолько, чтобы их сведения и отчеты были честными? Не принимают ли они за личное оскорбление критику своей работы? Кто-нибудь управляет их взаимоотношениями?
Все эти вопросы позволят осветить лишь часть симптомов, связанных со взаимоотношениями. Довольно часто мы даже не задумываемся об этих проблемах до тех пор, пока у нас не выйдут за рамки бюджет, сроки или качество проекта. Но к этому моменту проблемы уже не избежать.
В реальности все еще сложнее, и часто превышения бюджета и сроков переплетены с проблемами взаимоотношений. Иногда из-за личных отношений срываются сроки и бюджет, а иногда наоборот: из-за задержек и некачественной работы атмосфера в коллективе накаляется. Когда растет уровень стресса в команде, люди могут становиться агрессивными, расстроенными или занимать защитную позицию, в зависимости от своего характера, степени осознания происходящего и их эмоционального уровня развития.
В любом случае, необходимо разрешать все межличностные проблемы как можно раньше.
Когда проблема опознана, нужно определить степень ее “проблемности”. Является ли проблема настолько серьезной, что требуется неотложное вмешательство, которое позволит сохранить финансирование или спасет взаимоотношения с клиентом? Или это ситуация, которая позволяет подумать и принять более взвешенное решение?
Признание проблем начинает процесс работы с проблемой. Процесс состоит из анализа, планирования реагирования, и непосредственных действий.
Кто справляется с проблемой?
Часто проблемные проекты лучше видны со стороны. К тому моменту, когда проект оказывается в затруднительном положении, уже нужно внешнее вмешательство. Почему? Да потому что если руководитель проекта и команда занимались решением проблем, возникающих в ходе проекта, то дело бы не дошло до “хронических, неизлечимых” проблем.
Велика вероятность, что член ОУП, советник, консультант, или временный руководитель проекта будет назначен для решения проблемы. Чем ближе роль нового управленца к консультативной, тем менее радикальным будет вмешательство. Также степень вмешательства зависит от того, насколько высшее руководство (спонсор, команда управленцев, наблюдательный комитет) верит в возможности текущего руководителя проекта по спасению проекта. Иногда РП является источником проблемы, а иногда - жертвой сложившихся обстоятельств. В любом случае, нужно трезво оценивать способность конкретного сотрудника по решению непростых вопросов.
Пробуйте и анализируйте
Как только мы признали факт существования проблемы, нам нужно делать следующий шаг. Мы пробуем и анализируем разные варианты, чтобы определить причины и ожидаемый результат. Одной из основных ошибок, которая мешает правильному анализу, является желание срочно предпринять какое-нибудь действие.
Конечно, бывают ситуации, в которых нужно срочно что-то сделать, но чаще всего сначала подумать и спланировать лучше, чем бросаться в омут с головой.
Например, руководитель проекта, который подгоняет команду проекта и заставляет всех постоянно трудиться сверхурочно, чтобы устранить отставание по срокам, может еще более ухудшить положение - работники начнут делать больше ошибок, или брать больше больничных. РП, который сразу же берет быка за рога и говорит, что все решения принимает только он, может переборщить. Внешний консультант, или новый РП, который сразу же начинает все перепланировать, не разобравшись, что происходит, только усугубит и без того нехорошее положение.
Если ситуация еще не стала критической (еще нет “кровотечения”, или “кровотечение” взято под контроль), умный РП определит источник проблемы (которым может быть плохой дизайн системы, плохие требования и/или чересчур оптимистичный базовый план). Причиной также может быть потеря ключевых ресурсов (они могут быть отвлечены на другие работы с более высокими приоритетами); дело может быть в клиенте или команде управленцев, которые не хотят слышать плохие новости, и в РП, у которого не хватает духа озвучить назревшие проблемы. Даже если будет принято работать быстрее, или добавить ресурсов, есть вероятность не достичь планируемых результатов.
Проекты - это сложная вещь. Проблемные проекты - это еще более сложно. Это означает, что существует постоянное взаимосвязь между многими факторами, особенно между факторами людей и способами, которыми они реагируют на проблемы. В сложных ситуациях мы не можем точно сказать, что сработает, пока не рассмотрим проблему под разными углами, оценим разные варианты и выработаем план действий. Обычно, как только “кровотечение” проекта взято под контроль, нужно оценить сложившуюся картину, спокойно и коллективно. Вмешательство не должно быть спасательной акцией или военным переворотом. Вместо этого, основная команда проекта, с помощью эксперта, должна быть активно вовлечена в решение проблем.
Решение должно появиться в результате совместного творчества. Следует избегать шаблонных решений, которые будут предлагать одержимые “решатели проблем”, несмотря на их слова о том, что “мы так уже делали”. Каждый проблемный проект уникален.
Итак, сначала мы пробуем и анализируем. Насколько критична ситуация? В чем причины? Можем ли мы устранить причины или пока нужно бороться с симптомами? Каковы ожидаемые последствия проблемы? Связаны ли проявления проблемы с рисками, которые были описаны на этапе планирования? Актуальны ли стратегии реагирования на риски?
Каковы ожидаемые финансовые последствия? Как проблема скажется на взаимоотношениях участников проекта? Именно последствия дадут нам информацию, которая поможет выбрать оптимальный план действий. Например, если последствия превышения бюджета или срыва сроков менее страшны, чем последствия потери работников из-за чрезмерной нагрузки, то следует привлечь дополнительное финансирование и выработать новый план действий. Если опоздание может повлиять на взаимоотношения с клиентом, тогда нужны совместные усилия руководства проекта, спонсоров и РП для выработки пути выхода.
Какие ресурсы у нас есть под рукой? Как мы их можем использовать? Каковые ближайшие и долговременные последствия каждого решения? Часто команда будет работать вместе и над будущими проектами. Принимаемое решение не должно включать в себя действий, которые могут подорвать будущие взаимоотношения.
Остановитесь
Остановка в проекте - это период времени в проекте, когда основная команда проекта останавливается для анализа и планирования проекта от текущей точки до окончания проекта. Остановка может быть буквальной, когда все работы по-настоящему приостанавливаются, или фигуральной. Фигуральная остановка не предполагает прекращения работ, просто ключевые участники занимаются анализом и планированием, на основе сложившейся ситуации.
Решение о том, нужно ли прекращение работ, зависит от причины проблемы. Если продолжение текущих работ только усилит негативные последствия, тогда лучше эти работы прекратить. Частые остановки и частые проблемные ситуации в проекте - показатель того, что предыдущие остановки и проблемы не были эффективно отработаны. Это признак более глубоких проблем, например, отрицания того факта, что оригинальный план неверен. Не используйте метод трех конвертов.
Планируйте реакцию
Второй шаг в фазе исполнения - планирование реакции. Он начинается с определения вариантов решения проблемы. В сущности, это соответствует планированию реагирования на риски. Но в данном случае мы уже с головой в проекте. Проблема определена; также определены ее причины и последствия. Если мы выяснили, что проблема возникла из-за рисков, которые были описание при планировании рисков, то мы используем то реагирование на риски, которое было запланировано, предполагая, что оно еще актуально.
Реакция может быть какой-угодно: от принятия проблем такими, какие они есть, до отмены проекта. Между этими крайностями, для устранения превышения бюджета и сроков, используется сжатие (добавление новых ресурсов, сверхурочная работа), и ускорение графика (устранение взаимосвязей между задачами, их совместное выполнение, чтобы получить время). Чтобы мы ни делали, мы начинаем новый этап планирования нашего проекта.
Но вопросы с бюджетом и графиком - это еще цветочки. Намного сложнее решить проблемы со взаимоотношениями и с качеством продукта. В зависимости от причины проблемы, нужны различные типы вмешательства, которые позволят открыто общаться, осознать трудности в общении или в качестве продукта. Иногда требуются радикальные изменения в штате. И хотя мы говорили, что нужно избегать обвинений, бывают случаи, когда обязательно нужно что-то сделать с персональными неудачами и ошибками.
Для правильного планирования у нас должен быть кратковременный и долговременный обзор и анализ “что если”, с помощью которого мы оценим влияние решения не только на эту проблему, но и на все остальные аспекты проекта. Слишком часто желание успеть сделать проект по графику приводило к выпуску низкокачественного продукта. Проект завершен вовремя, бюджет не превышен, но мост через несколько лет падает, или космический корабль взрывается из-за неполадок в программном обеспечении. Эти негативные последствия возникают из-за страха или жадности.
Наверное, самая важная вещь, которую следует помнить при управлении проектами - сохраняйте спокойствие и собранность даже в условиях очень сильного давления. Если вы будете реагировать неправильно, то текущие проблемы будут усугублены, или появятся новые.
Сделайте и оцените результаты
Как это ни странно, но вы уже предпринимаете действия, если началось вмешательство и выполняется планирование реакции. Основное дело - признание проблемы и прерывание текущего хода проекта. После этого действия предпринимаются согласно плана.
Если команда проекта участвовала в анализе и планировании, то члены команды с большей вероятностью будут участвовать в решении проблемы.
Поскольку мы признаем сложную природу проекта, мы приложим много усилий и потратим достаточно времени на то, чтобы оценить, как исправляется проект. Мы признаем необходимость изменений в плане решения проблем. Мы помним, что мы работаем в рамках сложной системы, в которой способность точно предсказывать результаты наших действий ограничена. Мы пробуем что-нибудь сделать и потом изменяем это действие для достижения цели. Мы надеемся, что наше вмешательство принесет плоды с первого раза, но трезво оцениваем вероятность того, что с первого раза может и не получиться.
Заключение
Проблемные проекты - это проекты, в которых хронические проблемы не излечиваются. Часто они становятся проблемными, потому что существование проблем отрицается участниками. Отрицание - главная причина проблем.
Эффективное управление проблемами начинается с признания существования или возможности появления проблем и признания того факта, что проблемы являются неотъемлемой частью проекта.
Признавая, что проблема возможна, мы сможем использовать управление рисками и будем здраво оценивать ситуацию, что поможет нам избежать проблем.
Когда проблема возникает, признайте ее существование, и начните процесс решения. Остановите “кровотечение”, сделайте реалистичную оценку состояния, и действуйте, помня о том, как важны взаимоотношения людей.
Используйте подход Дзен к управлению проектами - оставайтесь спокойными. Будьте достаточно храбрыми, чтобы искренно признать источник проблемы, ее причины и возможные последствия. Реагируйте взвешенно, а не реактивно. Предпринимайте шаги, которые хорошо обдуманы и учитывают кратковременные и долговременные последствия.

5 ответов на данный момент ↓
1 Алексей // Feb 16, 2008 at 5:22 pm
Крохотная опечатчка в названии раздела - “Планируйте реацию”
Когда руководство спокойно решает проблемы - обычные сотрудники больше ценят своё рабочее место. Наверное, это положительно сказывается на качестве работы каждого сотрудника.
Нередко, развитый в философском плане человек вызывает раздражение у окружающих. Ведь если в группе - один человек на голову лучше всех, то у остальных есть два пути - подняться самим, либо осадить того возмутителя спокойствия.
На сколько мне известно, после того как Стаханов прославился, нормы выработки обычных людей на много поднялись. Обычные сотрудники жутко нелюбили стохановцев, и на то были причины.
Помимо Дзена, есть ещё Лао-Цзы, Конфуций, Мо-цзы и др. У В.В.Малявина вышла книга “Искусство управления”, где даются переводы древних китайских текстов, касающихся управления в целом. Наверное, будет полезно как продолжение к данному посту.
2 Андрей Куликов // Feb 17, 2008 at 6:25 pm
Спасибо за опечатку. Немного подредактировал текст - после копипейста из Mind Manager частично потерялась разметка и переносы строк.
“Спокойствие, только спокойствие” - помните?
Это работает. Нужно быть нацеленым на результат и всегда возвращаться в мыслях к той цели, которую участники проекта все вместе должны достигнуть.
Насчет других философских доктрин из Китая и Японии - хорошая мысль. Надо сделать подборку самых ярких цитат из Сунь Цзы “Искусство войны”.
3 Алексей // Feb 17, 2008 at 7:48 pm
Сунь Цзы - велик, но больше как теоретик. Есть более практичный трактат Сунь Биня (по предположениям учёных - прмой потомок Сунь Цзы), а ещё - У Цзы.
Кроме того Вей-ляо Цзы намного более интересен Сунь Цзы, но менее раскручен. Одна из его мыслей: “лучшее 100 тысяч дисциплинированных солдат, чем миллион не выполняющих приказы. Лучше 10 тысяч солдат рвущихся в бой, чем 100 тысяч просто хороших войнов” (к сожалению самой книги под рукой нет, но смысл вроде правильно передал).
Кроме того некий Ле Цзы уже сделал подборку цитат, и перевод её есть у В.В.Малявина в книге “Китайская военная стратегия” (http://www.ozon.ru/context/detail/id/1158638/)
4 Lamer // Feb 18, 2008 at 6:53 pm
Спасибо за перевод. Хоть моё IMHO состоит в том, что первая честь не сильно полезна. Зато вторая - то что надо.
Очень интересна ваша беседа насчёт книжек по военной стратегии и т.п. А нет ли ссылок на электронные версии этих книг?
5 Андрей Куликов // Feb 18, 2008 at 9:03 pm
Да, первая часть получилась уж совсем вводной. Я, пожалуй, сделаю на основе обеих частей карту с самыми главными мыслями.
Насчет книг по военной стратегии - Сунь Цзы можно посмотреть вот здесь:
http://fictionbook.ru/ru/author/sun_cziy/iskusstvo_voyiniy/
Оставить комментарий