Может быть, мы не так уж плохо оцениваем
Когда проект отклоняется от графика, это редко происходит из-за того, что запланированная работа просто заняла больше времени, чем все думали; гораздо чаще это объясняется тем, что проект застрял из-за выполнения работ, которые вообще не были запланированы. Наша деятельность в качестве консультантов по судебным тяжбам ежегодно снабжает нас новыми примерами этого. Большое количество этих свидетельств привело нас к следующему, на первый взгляд поразительному выводу:
Большинство руководителей проектов по созданию программного обеспечения проделывают приемлемую работу по предсказанию задач, которые должны быть выполнены , и слабую работу по предсказанию задач, которые может потребоваться выполнить .
Здесь есть хорошая и плохая новости. Плохая новость: из-за того, что все реальные проекты преподносят свою долю сюрпризов, руководители часто не в состоянии выполнить свои обещания, захлебнувшись в появляющихся одна за другой задачах, которые «может потребоваться выполнить». Хорошая новость: эти вызванные определенными условиями задачи являются, по крайней мере на общем уровне, отлично предсказуемыми.
Вчерашняя проблема
Простой перечень пары дюжин главных проблем организации, с которыми пришлось столкнуться в проектах нескольких последних лет, — отличный первоначальный перечень рисков для следующего проекта. Это предполагает совершенно механическое начало дела управления риском: Произведите «разбор полетов» по нескольким хорошим и плохим проектам и посмотрите, в чем они отклонились от первоначальных ожиданий. Проследите каждое отклонение вплоть до его причины и назовите эту причину риском. Присвойте ему номер и следуйте дальше.
|
|
|
В основе этого подхода лежит следующий принцип:
Вчерашняя проблема — это сегодняшний риск.
В каждом из нас найдется какая-то струна, которую заденет эта формулировка. Мы захотим «подправить» ее на что-то вроде «Сегодняшняя проблема — это вчерашний риск» или «Сегодняшний риск — это завтрашняя проблема». От таких переформулировок проку мало. Именно уравнивание прошлых проблем и нынешнего риска (другими словами, признание повторяющегося характера проблем проекта) помогает вам на практике управлять риском. Если вы обнаруживаете, что с недавно завершенным вами проектом возникли трудности, когда несколько ключевых работников ушли из компании, тогда потери персонала автоматически входят в ваш перечень рисков по новому проекту. Слово «автоматически» стоит здесь подчеркнуть: потеря работников, в особенности ключевых, настолько серьезная угроза, что управление в стиле «будет сделано» может отказываться рассматривать ее. Никогда не вздумайте недооценивать соблазнительный комфорт фразы: «Брррр, я просто не хочу об этом думать».
|
|
|
Итак, один из способов расширить перечень рисков — по крайней мере первоначально — состоит в методичном использовании анализа результатов после окончания проектов. Это предполагает, что ваша компания уже является достаточно просвещенной для проведения «разбора полетов» после завершения каждого успешного и неуспешного проекта, чтобы выявить, что произошло. Если вы этого не делаете, то, возможно, вам захочется взглянуть на ссылки в конце книги, где можно найти две рекомендации по анализу результатов законченных проектов.
Едва ли разбор предыдущих проектов является новинкой. Новым является только использование результатов этого процесса, как входных данных в процессе управления рисками:
Дата добавления: 2018-10-26; просмотров: 167; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!