Как заранее знать, где в проекте можно облажаться?

Елена Филипова, руководитель корпоративного проектного офиса «Адванта Консалтинг», сертифицированный специалист Project Management Institute, квалификация Project Management Professional (PMP), автор книги «С чего начать внедрение проектного управления? Готовая методология контроля проектов организации»

«Знал бы – соломку подстелил», – гласит известная пословица, намекая на то, что знать наперед не получится. Но падение в проекте означает не только срыв сроков или увеличение бюджета, часто речь о потере клиентов, рынка, репутации и даже бизнеса. Поэтому проектный менеджмент прочно вписал в свои области знаний управление рисками проекта. Это связано со статистикой, вероятностями, методами качественного и количественного анализа в управлении рисками проектов. Даже звучит сложно, не правда ли? Как упростить эту работу и не запугать сотрудников? И можно ли компании с низким уровнем зрелости проектного управления сделать управление рисками простым и эффективным?

С чего начать?

Самое простое управление рисками лежит на поверхности. Каждый из нас, начиная что-то новое, всегда чего-то боится. Мы меняем работу, машину, путешествуем и заранее спрашиваем себя о том, что может пойти не так и почему. Нам важно, чтобы у нас все было хорошо, и задуманное получилось. Эти страхи и есть риски, только выражены они неправильно, неосознанно. Но мы всегда четко понимаем, как мы будем с ними бороться: берем запас денег в поездку, захватываем лекарства от насморка, улетая в теплые края, нанимаем репетитора, чтобы ребенок поступил в вуз. Проект – тоже начало чего-то нового для компании, и с началом каждого проекта всегда есть, чего опасаться. Так почему многие отказываются делать оценку рисков, утверждать планы реагирования и управления рисками при запуске проекта? Именно поэтому компания должна позаботиться, чтобы риски проектов и планы реагирования были зафиксированы.

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

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

Так вы научите заказчика и руководителя проекта договариваться и заранее «подстелете соломку» вашему проекту. В паспорт (Устав) проекта включите обязательный для заполнения пункт «Высокоуровневые риски» и требуйте его заполнения. Этот раздел следует наполнить для каждого проекта.

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

Готовое решение по управлению рисками проектов

Как просто работать с рисками в ходе проекта?

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

Регулярная встреча с командой проекта – это ОЧЕНЬ и ОЧЕНЬ важно! В ходе такой встречи производится мониторинг и контроль выполнения работ, определяются планы, решаются конфликты и просто крепнет взаимодействие людей. А с точки зрения сбора информации о рисках – это просто неоценимый инструмент. Ежедневно или еженедельно неформально общаясь с участниками проекта, проектный менеджер может понимать, что происходит, с чем есть проблемы, какие возможности открываются и т.п. PMBoK утверждает, что самая важная причина организации таких встреч именно в выявлении рисков. Самый большой вопрос вызывает формат такой встречи и ее организация. С одной стороны, не все руководители могут проводить их эффективно, с другой, не все согласны делать это регулярно.

В своем проектном офисе мы поступали так:

1. Для каждого проекта уже на старте фиксировали время для регулярных коммуникаций. По каждому проекту создавали заранее расписание встреч и приглашали на них всех участников.
2. В карточке проекта настроили отдельный справочник Отчет о статусе, в котором можно было фиксировать принятые командой решения, планы, поручения и риски.
3. Сотрудник проектного офиса собирал всех участников (но не более 10 человек) в формате веб-конференции, знакомил с текущим планом и фиксировал в справочнике информацию по проекту.
4. Обязательно в каждом таком коротком совещании руководитель проекта или сотрудник проектного офиса задавал вопрос: Что вы знаете о наших угрозах или возможностях?

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

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

Чем полезны грабли?

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

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

Чтобы использовать накопленный опыт, мы (проектный офис) через 2 недели после завершения проекта собирали у себя команду проекта и задавали им всего три вопроса:

• Что пошло не так: какие были проблемы или достижения?
• Что можно сделать, чтобы: предотвратить проблему/организовать процесс управления рисками/ повторить успех?
• Как бы вы выполняли проект, если бы вам пришлось его выполнить вновь?

по трем темам:

• Сроки;
• Бюджет;
• Содержание.

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

Все задачи управления заключаются в цикле Деминга-Шухарта (планируй-делай-проверяй-действуй), нужно делать то же самое и для управления проектами. Проверка вашего плана всегда будет выполнена при работе над проектом, все несовершенства вылезут, и «война план покажет». Но вот под «действуй» я понимаю обработку рисков таким образом, чтобы усовершенствовать управление. Если делать это регулярно на уровне микро-менеджмента внутри команды проекта и на уровне управления проекта в целом, то вероятность облажаться будет стремиться к нулю.