Предположим ваш проект заключается в модернизации сетевой инфраструктуры, включая и приложение для управления взаимоотношениями с клиентами (CRM), которое будет использовать трехуровневую модель базы данных. Один из рисков, которые вы установили, заключается в том, что прежнее приложение не будет занесено в список модернизации и должно будет просто привязываться к новому приложению, но для этого нет нужного интерфейса.
Естественно, у этой проблемы высокая вероятность для реализации и сильное воздействие на проект. Вполне возможно, что задача создания интерфейса лежит на критичном пути. Какие запасные планы можете вы с вашей группой разработать, чтобы решить эту проблему? Есть много возможностей, хотя лишь некоторые из них окажутся логичными, желаемыми, позволительными и выполнимыми (четыре элемента, которые мы обсуждали в одной из предыдущих статей).
Например, вы можете решить модернизировать приложение перед началом работы над проектом; вы можете купить интерфейс у другой компании; вы можете отдать задачу разработки интерфейса на аутсорсинг; вы можете принять решение встроить функциональность существующего приложения в этот проект (что потребует от вас отступления назад и пересмотра всего плана проекта, включая формулировку новой проблемы и миссии, а также пересмотра функциональных и технических спецификаций и определения объема, WBS и т. д.). Как видите, есть целый спектр возможностей (вы возможно сможете придумать еще несколько альтернатив) и непонятно, по какому пути идти до тех пор, пока вы не вернетесь к определению вашего проекта и не посмотрите на проблему, которую проект должен решить. В этот момент возможно и станет ясна оптимальная альтернатива. В любом случае вы можете выбрать лучшую возможность и соответствующий ей план. Как мы уже отмечали, IT-проект легко подвергается модернизации, как, к примеру, торговые электронные весы, которые буквально за последние десять лет благодаря модернизации превратились из огромных и нелепых «динозавров» в лёгкие, элегантные и сверхточные приборы.
Давайте обратимся к другому сценарию. Предположим, планируется начать три важных проекта примерно в один и тот же момент. Каждый из трех проектов в тот или иной момент требует привлечения четырех программистов. Вы являетесь менеджером IT-проекта для одного из этих трех проектов и хотя у вас есть определенная политическая поддержка в компании, вы понимаете, что велика вероятность того, что все эти четыре программиста будут заняты, когда их усилия понадобятся вашему проекту.
Вы уже говорили с другими менеджерами IT-проектов о расписании их проектов и о том, когда им понадобятся эти программисты, но вы знаете и о том, что расписание любого проекта может существенно меняться. Без усилий этих четырех программистов ваш проект оказывается под угрозой. Поскольку у этого риска высокая вероятность реализации и сильное воздействие на проект он должен заранее планироваться. У вас должны быть определенные стратегии для того, чтобы совсем избежать этого риска, но вы также знаете, что есть шанс, что эти программисты будут в наличии (естественно, в этом примере мы предполагаем, что у вас нет специального подразделения для управления проектом или программой, которое заведует выделением всех ресурсов проекта).