Управление знаниями: 5 резервов для проектного управления |

Что думают руководители проектов и проектных офисов?

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

  • Эффективность и результативность растет от проекта к проекту.
  • Лучше управление, более взвешенные и верные решения.
  • Преемственность знаний, информации, опыта.
  • Создание новых знаний, идеетворчество.
  • Более доверительные отношения в командах, сплоченность, лояльность, вовлеченность, «командный дух» крепнет.
  • Растут компетенции всей проектной команды.
  • Самоорганизация и самообучение команды.

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

Из истории вопроса

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

История дисциплины управления рисками уходит корнями в конец XVII — начало XIX веков, когда английский галантерейщик Джон Грант опубликовал результаты предпринятого им исследования продолжительности жизни, английский астроном и математик Эдмунд Галлей развил идеи Гранта, а швейцарский математик Даниил Бернулли дополнил сделанные «коллегами» выводы.

Большой вклад в дисциплину проектного риск-менеджмента сделала команда специалистов, работавших над первой редакцией PMBoK’а (PMBoK — Project Management Body of Knowledge (англ.) — Свод знаний по управлению проектами), вышедшей в 1996 году. Тогда были выделены четыре процесса управления рисками:

  • идентификация риска;
  • оценка риска;
  • разработка методов реагирования на риск;
  • контроль реагирования на рисковые события.

С тех пор PMBoK обновлялся каждые четыре года, и к 2004 году список процессов был дополнен стартовым процессом «планированием управления рисками». Оценка риска была разбита на два процесса: качественный и количественный анализ риска.

Навскидку

Еще Даниил Бернулли в далеком 1738 году заметил, что в процессе принятия решения людям свойственно уделять больше внимания размеру последствий разных исходов, нежели их вероятности. В действительности рационально ориентироваться не на величину последствий (влияние) риска, а на влияние риска с поправкой на вероятность его наступления (метрику риска):

Метрика риска = Влияние риска х Вероятность риска

И сразу при упоминании вероятности приходят на ум законы больших чисел и статистика, после чего руки опускаются: как можно говорить о точной количественной оценке вероятности таких событий, как, например, «повышение курса валюты контракта на Х%» или «несоответствие техническим требованиям», да и какой в этом смысл?

Но ведь помимо количественной оценки рисков есть и качественный их анализ. Для этого используются вербальные (словесные) шкалы (см. Табл. 1).

Таблица 1. Таблица качественной оценки рисков проекта

Влияние/ вероятность

Очень высокое

Высокое

Среднее

Низкое

Очень высокая

Очень высокий

Очень высокий

Высокий

Высокий

Высокая

Очень высокий

Высокий

Высокий

Средний

Средняя

Высокий

Высокий

Средний

Средний

Низкая

Высокий

Средний

Средний

Низкий

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

Таблица 2. Таблица преобразования качественных оценок рисков в баллы

Метрика риска

Оценка в баллах

Очень высокий

14

Высокий

9

Средний

5

Низкий

2

Теперь мы можем ранжировать риски по их метрикам. Вверху списка окажутся риски с максимальной оценкой. По известному правилу Парето уделять внимание следует, прежде всего, «верхним строчкам» ранжированных рисков.

Полезным инструментом верхнеуровневого управления проектными рисками (с точки зрения руководства компании) является КБРП — комплексный балл рисков проекта. Его мы получаем, сложив численные значения метрик десяти (методология компании может устанавливать иное количество рисков, учитываемое при расчете КБРП, однако оно должно быть единым для всех проектов) максимальных рисков проекта.

Если компания практикует технологичный подход к управлению проектами и регулярно составляет реестр проектов, то в нем будет полезно иметь колонку с КБРП. Тогда руководитель компании (либо директор проектов или другое ответственное за проектную деятельность лицо) всегда будет иметь информацию, какие из актуальных проектов на текущий момент содержат в себе больше рисков.

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

Страна невыученных уроков

«Видеть легко, трудно предвидеть», — говорил Бенджамин Франклин. И если вы не наделены даром провидца, то в помощь вам — опыт других.

Главной мечтой руководителей (и одновременно главной проблемой компаний, чья деятельность связана с проектами) остается накопление и распространение внутри компании опыта, приобретенного в проектах. Проблема не в том, что люди ошибаются (не ошибается тот, кто ничего не делает), а в том, что они повторяют ошибки.

Для накопления опыта пока не придумано ничего лучше, чем написание отчета по закрытию проекта. Отчет этот называется по-разному, но наиболее «говорящее» название — «посмертный отчет», или PMR (PMR – от Post Mortal Report — посмертный отчет (англ.)). Руководители проекта часто ленятся писать его или отделываются формальной отпиской.

PMR обязательно должен содержать раздел, метко названный «lessons learned» (Lessons learned — усвоенные уроки (англ.)). Какие уроки извлекла команда проекта из сложных ситуаций, с которыми она столкнулась в ходе его реализации?

Написать раздел «lessons learned» легче, если ответить на вопросы:

· Что было сделано правильно, а что нет?

· Какие ошибки были допущены?

· Что можно было сделать лучше?

· Что бы вы сделали иначе?

· Какие сюрпризы вы не предвидели?

· Пришлось ли тратить резерв на ошибки?

· Пришлось ли отходить на запасные позиции?

· Какие уроки можно почерпнуть на будущее?

Помимо «усвоенных уроков» PMR может содержать разделы:

  • Название проекта (код реестра)
  • Руководитель и команда проекта
  • Заказчик (спонсор) проекта
  • Первоначальные и фактические рамки проекта (Рамки проекта – общая продолжительность, стоимость (трудоемкость) и обобщенные требования к результату (объем поставки))
  • Отклонения от рамок и причины отклонений
  • Открывшиеся возможности
  • Упущенные возможности

Практика показывает, что руководители проектов охотнее делятся опытом (читай — пишут PMR’ы), когда сами набивают шишки. Для привития и закрепления полезной привычки можно применять материальные стимулы: не считать проект формально закрытым (а значит, и не производить «финальный расчет» по проектным премиям и бонусам), пока не будет написан и «выложен» в общедоступное место (в проектную папку на сервере) «посмертный отчет».

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

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

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

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

Таблица 4. Пример шкалы оценки влияния и вероятности для риска задержки оплаты со стороны заказчика (во внешнем проекте)

Оценка влияния

Очень высокое

Высокое

Среднее

Низкое

Убытки свыше 50% бюджета проекта

Убытки в размере упущенной выгоды

Прибыль будет меньше запланированной

Прибыль будет получена позже

Оценка вероятности

Очень высокая

Высокая

Средняя

Низкая

Есть достоверные сведения о задержке заказчиком платежей (задержка платежей в прошлом)

Есть косвенная информация о задержке заказчиком платежей (третьим лицам)

Нет ни положительной, ни отрицательной информации о платежной дисциплине заказчика

Прошлый опыт подтверждает хорошую платежную дисциплину заказчика

Если руководство компании не стремится к тому, чтобы проекты с серьезными проблемами неуклонно шли к своей гибели, а руководители проектов до последнего скрывали негативную информацию (пытаясь «разрулить» проблемы самостоятельно либо оттягивая неприятный момент неизбежного «вскрытия»), в компании должно культивироваться особое отношение к ошибкам как к ценному приобретенному опыту, а не как к личному поражению менеджеров.

Итак, для эффективного управления проектными рисками в компании необходимо:

  • создать регулярный механизм накопления и использования опыта, полученного в проектах;
  • подкреплять менее опытных руководителей проектов (привлекать в проект экспертов, кураторов);
  • создать в компании регулярный механизм обмена опытом между руководителями проектов (совещания, мини-семинары);
  • регулярно оценивать и «мониторить» проектные риски, в том числе на уровне руководства компании (с помощью реестра проектов и КБРП);
  • создать в компании атмосферу «поощрения» ошибок;
  • развивать корпоративную методологию управления проектными рисками.

Таблица 5. Пример выбора различных стратегий реагирования на риски в проекте поставки оборудования

Описание риска

Стратегия реагирования

Антирисковое мероприятие

Возможности

1

Гибель (порча) оборудования в пути

Передача

Страхование оборудования в пути

2

Несоответствие оборудования от нового поставщика техническим требованиям

Уклонение

Отказ от покупки оборудования у нового поставщика

3

Случаи травматизма при монтаже оборудования вследствие несоблюдения правил техники безопасности

Снижение

Проведение инструктажей по ТБ, назначение ответственного за соблюдение правил ТБ

4

Задержка оборудования на таможне

Пассивное принятие

Урегулирование претензий таможни (устранение замечаний)

5

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

Активное принятие

Создание резерва командировочных расходов

Угрозы

6

Возможность получить дополнительную скидку от производителя оборудования при осуществлении предоплаты

Использование

Получение аванса от заказчика для осуществления предоплаты поставщику

7

Возможность поставить заказчику сопутствующее оборудование

Совместное использование

Поставка сопутствующего оборудования совместно с партнерами

8

Возможность стать постоянным поставщиком заказчика

Усиление

Подготовка для заказчика «стратегического предложения» и заключение «рамочного» соглашения на будущее

Таблица 6. Пример выбора различных стратегий реагирования на риски в проекте проведения бизнес-конференции

Описание риска

Стратегия реагирования

Антирисковое мероприятие

Возможности

1

Накладки, связанные с обеспечением уюта гостей конференции

Передача

Привлечение турагентства для организации трансферта, проживания и досуга гостей конференции

2

Сложности с переводом с/на редкие языки

Уклонение

Отказ от привлечения докладчиков, не поддерживающих распространенные языки

3

Отказ спонсора от участия в конференции незадолго до конференции

Снижение

Частичная предоплата спонсорского пакета

4

Расходы на переводчиков, билеты и проживание иностранных гостей сверх ожидавшихся

Активное принятие

Создание резерва средств на указанные расходы

5

Отказ одного из докладчиков от выступления (за несколько дней до конференции)

Пассивное принятие

Экстренный поиск другого докладчика

Угрозы

6

Интерес к конференции со стороны центральных СМИ

Использование

Использование для бесплатного продвижения бренда компании и конференции

7

Возможность привлечения на конференцию клиентской аудитории компании-конкурента

Совместное использование

Проведение партнерской конференции совместно с компанией-конкурентом

8

Возникновение на конференции клиентов на услуги компании-организатора

Усиление

Работа на конференции консультантов, компетентных ответить на интерес к услугам компании

Понравилась статья? Поделиться с друзьями:
Юрист
Adblock
detector