Основы проектного менеджмента. Классическое руководство - страница 30

В Руководстве к Своду знаний по управлению проектами (PMBOK® Guide) управление рисками проекта определяется в качестве одной из областей знаний. PMBOK описывает управление рисками проекта как «процессы, связанные с планированием управления рисками, идентификацией, анализом, планированием реагирования, а также с мониторингом и контролем рисков в проекте» (PMBOK, 555). Таким образом, эти процессы нужно понимать как строящиеся по заданным правилам и контролируемые мероприятия, не допускающие вариаций или допускающие их в минимальной степени. Применительно к процессам проекта вариации обычно равнозначны неэффективности. Важно управлять рисками правильно, хотя с учетом реальностей и переменных в типичной среде проекта какая-то степень гибкости, конечно, возможна. По мере накопления опыта в управлении рисками у вас начнет развиваться интуитивное ощущение возможных пределов этой гибкости в зависимости от типа, продолжительности, объема, глубины и широты проекта.

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

Мозговой штурм. Составление списка потенциальных рисков проекта не должно носить характер аналитической разработки; нужен настоящий мозговой штурм, когда подхватываются на лету все идеи. Шаги 2 и 3 позволяют подробно рассмотреть их. В идентификацию потенциальных угроз и того, что может пойти не так, важно вовлечь всю команду. Некоторые руководители проектов пытаются проделать эту работу самостоятельно, чтобы дать членам коллектива возможность выполнить другие задачи. Это близорукий и вредный подход. Начальный шаг должен осуществляться в атмосфере тесного сотрудничества и включать в себя всех членов команды, являющихся специалистами в своих сферах и отвечающих за свои части проекта. Максимально задействуйте интеллектуальный капитал всей команды. Если за пределами такого мозгового штурма окажется хотя бы один член коллектива, весьма вероятно, что часть рисков останется неидентифицированной и успех проекта будет под угрозой. Помните, что нужно вовлекать всех: специалисты по закупкам (снабженцы) не помогут определить возможные проблемы разработки программного обеспечения, а программисты – проблемы с закупками.

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

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

Я объединяю шаги 2 и 3, поскольку они оба связаны с классификацией рисков по приоритетности. Они помогают расставить риски в порядке очередности и определить, сколько времени, усилий, человеческих ресурсов и денег следует направить на предотвращение каждой из идентифицированных угроз или на смягчение ее негативных последствий. Это также следует осуществлять с полным участием членов команды и привлеченных экспертов по предметной области (Subject Matter Experts, SME).