Comments 6
Отличная статья и интересные мысли! По поводу внедрения правил наблюдала интересные ситуации. Например, про упомянутое управление рисками. Когда внедряли их в компании, то понимали значимость, и это работало - на основе них корретировались сроки, собирались мини0рабочие группы по предотвращению риска и тд. В последствии это стало просто очередным шаблоном, который заполнялся "на отвали", где риски копипастились из проекта в проект. То есть изначально хорошая системность потеряла актуальность и перестала работать, а даже начала напрягать. Ну ок, оставили их как формальный документ. Но в процессе реализации проектов возникали проблемы, сотрудники неожиданным образом выявляли, что можно было проблемы предостеречь, собирались "поштурмить", создавали реестр возможных проблем, и очень радовались своей находчивости. А когда показываешь им, что вообще-то это устория про управления рисками, и вообще-то уже давно внедренная в компании, начинали говорить "это другое". И такое случается очень часто в больших корпорациях. Как итог, для своих команд поняла, что вообще-то дурацкие шаблоны часто не дурацкие, а полезные, и регламентные процедуры вообще-то не для формальности, а реально помогают улучшить проект. Так что очень правильный совет даете - посмотреть, что есть в компании, посмотреть на лучшие практики, и внедрить, если это новое и необходимое (а если это старое, то можно сделать реинжиниринг :))
Спасибо за комментарий. Действительно важно не только наличие правила или шаблона, а чтобы они органически выросли внутри компании, чтобы она до них дозрела. Лучше пусть "реестр рисков" и необходимые ритуалы называются "реестром проблем" и работают, чем формы, к которым все относятся как к бюрократии. Кстати часть правил отторгается потому что они не приземлены на реальные проекты, а как-будто повешены в воздухе - типа "делайте и все". А вот если что-то неполезно или не используется, хотя полезно, нужно выпиливать или допиливать, чтобы работало или выкидывать в корзинку. Нет ничего хуже, чем правило, которые не работает, и все знают об этом.
А были ли в вашей практике еще примеры правил, которые проросли снизу, из конректных проектов, а потом прижились во всей компании?
Да, конечно. Но опять таки, команды изобрели в своем роде новый велосипед. Например, мы рисовали критический путь проблемных проектов и тиражировали это на остальные. Или еще пример, на совещаниях загружали материал по всему проекту, и помечали их зеленым цветом, то есть просто для чтения, материалы и вопросы, которые касались управленческих развилок, помечали оранжевым. И на встрече модератор следил за тем, чтобы не обсуждалось зеленое. Так как ранее все зеленое уже было согласовано, но на встречах с большим количеством участников все хотели высказаться и часто возвращались к уже пройденному. Получился такой интересный инструмент модерации иныестиционных комитетов с топ-менеджерами - очень полезно
Рекомендуете ли вы базы знаний для реализации мыслей из вашей статьи? Или предпочитаете другие инструменты?
У меня есть 2 ответа на ваш вопрос в зависимости от его интерпретации.
Если вы имеете ввиду, что база знаний может являться артефактом - то, конечно, это хорошая практика, которая помогает избежать изобретения велосипеда на новых проектах.
Если же речь идет о том, можно ли использовать базы знаний с инструментами управления, то тоже да. Мы с профессором Сколково Павлом Алферовым создали такую базу, с которой можно ознакомиться по ссылке https://brizpm.ru/. Там под каждый аспект проекта можно подобрать необходимые инструменты.
Если же речь про то, в каком пространстве собираются необходимые практики, то мы много использовали виртуальную доску Miro, а сейчас периодически используем МТС Линк.
Что надо сделать, чтобы проектное управление заработало и ваши сотрудники начали действовать автономно