Вы узнаете, как бороться с типовыми проектными рисками и использовать модель Швейцарского сыра в управлении проектов. Рассказывает Павел Алферов, профессор бизнес-практики СКОЛКОВО.
Современный менеджер похож на охотника, который идет в джунгли на животное, но вот на какое — он не знает. Может быть, это не он охотится, а на него охотятся — сложно сказать. Поэтому у него должен быть патронташ, как у революционных матросов, увешанный разными моделями, с разными теориями и концепциями, а их сейчас очень много. И когда у него перед носом возникает какая-то проблема, то он должен найти правильный патрон, который её и завалит. Суть в том, что чем больше вы знаете, тем проще вам справляться с теми проблемами, которые будут появляться.
Стандартное управление рисками, хорошо описанное в большом количестве учебников, в российских условиях не приживается, но есть модель, которая очень удобна для работы именно в наших условиях. Называется «модель Швейцарского сыра», она придумана в 1990 году Джеймсом Ризоном для наглядного представления причин авиапроисшествий. Она может быть хорошо применена в проектном управлении. Суть ее проста: есть проблема, например, в авиации – катастрофа, несчастный случай. На пути этой катастрофы в виде листов стоят барьеры. И причина, которая может превратиться в реальную катастрофу, должна пройти через них. Если бы эти листы были непроницаемыми — она бы не добралась. Но, к сожалению, они с дырками, отсюда и название теории.
Модель швейцарского сыра применительно к проекту
У каждого проекта есть свои ограничения – сроки, бюджет, удовлетворенность заказчиков – а как известно, проект успешен, если он уложился в ограничения. Также есть угрозы, из-за которых можно не уложиться в ограничения. Элементы системы управления проектом и отдельные активности выступают в качестве листов сыра. Например, у нас происшествие — не согласовано вовремя техническое задание, причина — человек, ответственный за согласование, ушел в отпуск. Но мы на пути этой причины ставим правило — любой отпуск должен быть согласован с проектным менеджером, тогда эта причина у нас не пройдет, и не произойдет несогласование ТЗ вовремя.
Но есть другая причина — перегрузка операционной работой. Это типовая проблема, и работать с ней надо в обязательном порядке. Если мы не поставили ничего на пути (а можно было взять дополнительных людей или добавить проектную мотивацию), то в результате не выполняется работа, соответственно, и вовремя не согласованное ТЗ. Обязательства заказчика не выполнены, как итог — мы не вписались в ограничения.
Типовые риски проектов
Вот 8 типовых рисков проекта, которые являются частой причиной провала проектов. Первые связаны с ключевыми участниками или стейкхолдерами, заинтересованными в проекте:
1. Команда не знает, для чего нужен проект. Они знают, что кто-то его запустил, есть инициатор, какой-то менеджер, но он не смог донести до всех причину, проблему, которую решает проект, куда мы движемся и для чего мы решили этим заниматься.
2. Команда не понимает, что именно будет результатом проекта. Не все понимают, как выглядит образ будущего, где мы хотим оказаться, что именно у них должно получиться в итоге .
Следующие риски связаны с членами команды:
3. Члены команды не понимают, что они должны делать на проекте. Их кто-то включил в команду, что-то им говорит, но что конкретно они должны делать — непонятно.
4. Члены команды не проявляют инициативу на проекте. Не замотивированы, не готовы или не хотят делать, ограничиваются только поставленными задачами.
5. Нет времени на выполнение задач проекта. Сотрудники перегружены своей текущей операционной работой, работа над проектом для них не является приоритетной.
Проект, он как велосипед. Велосипед устойчив, пока едет. Стоит ему остановиться — падает. Так и проект — он двигается вперед и развивается согласно плану, пока быстро принимаются решения. Стоит проекту остановиться в ожидании какого-то решения, все начинает рассыпаться. Поэтому следующие три пункта связаны с принятием решений:
6. Непонятно, кто должен принимать решения. Есть решения, которые повисают в воздухе.
7. Принятие решений тормозится конфликтами между подразделениями. Разные подразделения имеют разные взгляды, интересы, начинают сражаться между собой за то, чтобы было принято решение, выгодное именно им. И опять-таки, решение затягивается, и проект начинает давать крен, пока не упадет.
8. Принятие решений затягивается руководством. Есть руководители, которые имеют отношение к этому проекту, но они не готовы принять решение.
По-хорошему, когда в компании постоянно реализуются проекты, должна вестись эта база типовых рисков и уже реализовавшихся, которые тормозили движение проекта.
Система управления проектом
Ниже минимальный набор компонентов стандартной системы управления, обязательный для любого проекта. В каждом конкретном случае она может дополняться чем-то, некоторые роли могут поменяться, вноситься новые правила, механизмы и так далее. Но практически для всех проектов нужно то, что здесь перечислено:
- Этапы и точки принятия решений — для небольших проектов этих этапов три: подготовка, реализация, завершение.
- Организационные структуры и роли. Обязательные роли: куратор — человек, который принимает стратегические решения; заказчик — он формулирует требования к результатам; руководитель проекта — планирует, организует, контролирует работу, осуществляет целеполагание, мотивирование участников, распределяет ответственность между ними, и команда — те, кто непосредственно делают работу.
- Совещания. Должны быть стартовые совещания, когда всем рассказывается, что проект стартует. Должны быть регулярные встречи команды, где все обмениваются информацией. Регулярные встречи с заказчиком, руководителем проекта и ключевыми членами команды. С заказчиком уточняют требования, понимание и рассказывают, что происходит. Регулярные встречи с куратором проекта — по той же схеме.
- Правила и механизмы. Чаще их называют политики, процедуры, регламенты. Механизм запуска проекта — это набор шагов, которые нужно пройти для того, чтобы зафиксировать, что проект начался, что проходит не просто обсуждение идеи, проект делается. Механизм приемки результатов фиксирует, каким образом продукт проекта реально соответствует тому, что нужно. Механизм завершения проекта, соответственно, закрывает проект. Механизм внесения изменений — последовательность шагов, которые нужно пройти, чтобы согласовать изменения по сравнению с тем, что было в начале. И механизм фиксации требований к результатам — набор шагов, которые нужно пройти, чтобы зафиксировать требования всех участников к продукту.
- Официальные рабочие документы. Они должны быть на проекте обязательно, в современных условиях на проекте должна быть общая рабочая область, единая точка права, где хранятся все документы по проекту, и общая группа в мессенджерах. Это позволяет всем участникам оставаться на одной странице, одинаково понимать, что происходит, и быстро поднимать и решать вопросы.
Подробно управление проектами можно изучить на онлайн-интенсиве Павла Алферова «Управление проектами: как правильно делать правильные вещи». Во время обучения вы научитесь работать с самыми эффективными и результативными практиками и инструментами, а к концу курса вы сформируете собственный профиль управления проектом и пройдете путь от планирования, утверждения и запуска, до реализации и завершения проекта.
