Управление знаниями в проектном менеджменте

Четвертая статья с экспертом в управлении знаниями Владимиром Бароновым (“ЛУКОЙЛ”, ConocoPhillips). Обсудим, как нужно и можно грамотно управлять знаниями на старте, в течение проекта и после его окончания, включая использование опыта в повседневной практике.

Результаты проекта напрямую зависят от того, как мы управляем знаниями. Казалось бы – банальщина, известная всем, или же, наоборот, - полная галиматья, т.к. есть еще бюджет, менеджеры проекта и многое другое… Давайте разбираться.

Владимир Баронов*:

“Я, как системный аналитик, буду настаивать на том, что результат проекта зависит от управления знаниями. Ведь “исправление ошибки, выявленной на этапе проектирования, обходится на порядок дешевле, чем на этапе программирования, и на 2 порядка дешевле, чем на этапе эксплуатации”. Результаты всегда будут лучше в проекте, который плохо управляется, но хорошо спроектирован, чем для хорошо управляемого, но плохо проработанного решения.

Кирилл Кузнецов**:

“На вопрос “как управление знаниями влияет на результаты проекта” ответить очень сложно. Я не встречал ни одного проекта, где бы на системном уровне использовалось управление знаниями, полученными из предыдущих проектов. Именно системно: с помощью информационной системы найти релевантный для себя опыт, экспертов, с которыми можно было бы посоветоваться и т.п. Хотя у меня обширная практика внедрения больших масштабных IT проектов, в том числе, в госсекторе.

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

А это, соглашусь с Владимиром, ключевой фактор использования знаний в проектном управлении. И это говорит о том, что отсутствие передачи знаний не осознается - “все так делают”, привыкли и с этим живут. Но это не значит, что так правильно”.

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

Владимир Баронов:

“Приведу пример коллег из Schlumberger – одной из крупнейших нефтесервисных компаний в мире. Например, стояла задача найти «специалиста, умеющего бурить на депрессии, знающего арабский язык, с опытом реализации проектов на Ближнем Востоке»… Условия могли меняться, но внутри такого «простого» решения – информация о компетенциях сотрудников, их проектом опыте и планах по загрузке, потому что из тех, кто потенциально подошел, выбирали тех, кто будет свободен на время проекта”.

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

Менее формально обмен опытом может проходить в формате помощи коллег (Peer Assist, про который мы писали здесь) или простого установочного совещания, где все знакомятся друг с другом. Иногда установочное совещание проводится параллельно с другими форматами. Сейчас такие встречи могут проводиться и виртуально - в сообществе размещается вся разработанная документация, и команда совместно с экспертами обсуждает, что можно улучшить.

Владимир Баронов:

“Как гласят “легенды” из моей собственной практики, - удавалось снизить бюджет на 20%, либо предложить расширенную функциональность. Или повысить в 2 раза коммерческую скорость бурения, - пустячок, а приятно”.

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

Не нашли ответ? Можно попробовать функционал управления идеями, если он позволяет создавать запросы от руководства или проектных команд.

Теперь представим, что сотрудник только присоединился к команде проекта. Что поможет быстро «въехать» в текущее положение дел и начать активно работать? Возможно, какая-то минимальная программа онбординга, в рамках которой будет проведено ознакомление с ходом и результатами проекта. С другой стороны, полезно обратиться к имеющимся записям и статьям экспертов, просмотреть несколько вебинаров и подключиться к общему пространству проекта.

Если все еще нет понимания, то нужно найти эксперта и уточнить у него.

Владимир Баронов:

“Другое дело, если вы покидаете проект. По-хорошему, как минимум стоило бы провести «выходное интервью». Очень часто в рамках таких интервью фиксируют опыт “ветеранов”, которые должны покинуть компанию. Но ведь ничто не мешает нам адаптировать этот подход и к проектам? Очень полезно использовать и сторителлинг в том или ином виде, даже если это будет запись видео-ролика. Например, я сталкивался с тем, что уходящих участников команды разработки просили записать видео-ролик с комментариями по настройкам того блока, за который они отвечали. Потом такие ролики становились хитами. И, конечно, если человек покидает только команду, а не компанию, то как минимум его можно будет привлекать к встречам с будущими проектными командами, а запись об опыте должна сохраниться в его профиле”.

Фиксация полученного в ходе проекта опыта и ознакомление с этим опытом всех заинтересованных сторон - это близкие понятия.

Какой-то опыт может быть передан "с колес", - особенно, если отработавшая команда только собирается его зафиксировать, а новая проектная команда вот-вот стартует. Здесь отлично подойдет методика "эстафеты проектов”, о которой мы уже говорили.

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

Самый известный - это “разбор полетов” или After Action Review, когда в конце фазы проекта или его отдельного крупного блока команда сравнивает фактический результат с плановым, что было сделано хорошо и за счет чего, что можно было улучшить и как.

Если проект закончен, то тот же самый разбор полетов, но применительно к проекту в целом, станет уже ретроспективой.

Владимир Баронов:

“И, конечно, как же обойтись без извлеченных уроков? Вот только для реального эффекта важно эти уроки не просто зафиксировать в табличном виде и вспоминать о них только накануне нового этапа или другого проекта, а внести в систему управления извлеченными уроками. Ведь часть проектного опыта наверняка пригодится в обычной работе подразделений. И, поняв, что полезного команда получила, было бы неплохо реализовать определенную программу действий. Здесь много инструментов - от профессиональных сообществ до статей в базу знаний, изменений в нормативных документах и т.п. А еще полезно задуматься о ситуациях, когда проектные знания могут потребоваться, скажем, лет через 10. Или 100… «Дальний перенос» знаний, как это называет ряд экспертов. В этом случае помогут любые детали, позволяющие понять контекст тех задач, которые решались, и адаптировать опыт к новым условиям”.

Кирилл Кузнецов:

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

Платформы уровня “Confluence + Jira” сложно назвать проектным управлением для инфраструктурных проектов, в 90% случаев они используются только в разработке информационных систем”.

Об авторах

* Владимир Баронов - генеральный директор и совладелец "КМ Эксперт", генеральный директор "Интеллектуальные сервисные решения".

Более 10 лет руководил подразделением, отвечающим за разработку и внедрение управления знаниями в нефтепереработке и добыче ЛУКОЙЛ.

С 2007 по 2010 работал совместно с Дэном Рантой (Dan Ranta) – Директором по обмену знаниями в ConocoPhillips – одной из ведущих нефтегазовых компаний в части управления знаниями в мире.

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

Является соавтором книг “Автоматизация управления предприятия” и “Информационные технологии и управление предприятием”.

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

Более 15 лет руководит сложными инфраструктурными проектами по созданию информационных систем в таких областях, как: госуправление; экономика и финансы региона; управление имуществом, ЖКХ, торговлей; цифровой туризм, цифровая культура, цифровизация промышленности и многие другие.

Имеет десятки успешно реализованных IT проектов, награжденных престижными российскими и международными премиями:

• mos.ru;

• Облачная бухгалтерия - централизация учета всех госучреждений Москвы;

• data.mos.ru - первый российский портал открытых данных;

• um.mos.ru - Узнай Москву (навигатор по достопримечательностям Москвы);

• Создание ОЦО РЖД - централизованная бухгалтерия РЖД;

• Автоматизация инвестиционной деятельности РЖД и всех структурных подразделений РЖД.