Продолжаю тему: как правильно заимствовать лучшие практики? Расскажу на примере одного недавнего кейса👇

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

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

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

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

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

Выводы: используйте чужие лучшие практики только если они соответствуют контексту и культуре вашей компании, но даже в этом случае АДАПТИРУЙТЕ ИХ, иначе эти лучшие практики станут для вас худшими.

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

❗️Коллеги, если хотите посмотреть, как создаются правила управления проектами с адаптацией инструментов из других фреймворков под культуру компании, приглашаю вас на методологическую экскурсию🔥

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

Чтобы записаться на экскурсию, напишите мне в ЛС @Malakhov_Andrey

Стахановцы проектники, а как у вас дела с ментальным здоровьем?

🔥 горю и еду на велосипеде, который тоже горит
👍 ничего, держимся
🥴 у самурая нет цели, только путь

И еще раз о «лучших» практиках, которые вы пытаетесь внедрить у себя. На скрине выше – комментарий к моей новой статье, где очень хорошо описана ситуация с таким внедрением.

Если реестр рисков всегда заполняется формально, а то и вовсе игнорируется, потому что организация еще не дозрела до такого продвинутого уровня, зачем его оставлять?

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

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

Коллеги, поделитесь, какие инструменты и практики вы пытались внедрить, но они не взлетели?

Кто я и про что этот блог

Коллеги, в моем канале появилось много новых людей, поэтому предлагаю познакомиться!

Меня зовут Андрей Малахов.
Я и эксперт, и предприниматель, и новатор – разработал и успешно внедряю гибридный метод управления проектами Парацельс ПМ. Собственник и руководитель консалтинговой компании PMLogix. 

Почему я считаю, что меня нужно читать? 

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

С чего можно начать знакомство с моим блогом:

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

А также:

👉 советую почитать наши #кейсы, в которых я подробно рассказываю о ходе работы, трудностях и методах их преодоления на наших консалтинговых проектах; 

👉 на моем Youtube канале и в ВК видео вы найдете записи вебинаров и подкасты с топовыми российскими экспертами. 

Коллеги, рассказывайте, кто вы, чем занимаетесь и что нравится в моем блоге?

Принимаю поздравления, коллеги. Наконец-то мой канал обогнал фан страницу Андрея Малахова!

​📣 3 шага, чтобы создать свою технологию управления проектами

Я часто вижу, как в организациях пытаются создать свою технологию управления. И почти всегда все начинается оптимистично: руководство дает отмашку, собирается рабочая группа, пишутся регламенты, сотрудников вводят в курс нововведений… Но в итоге – пару месяцев «поиграли» по новым правилам и вернулись к тому, что было. Или же сделали вид, что поиграли, а по факту продолжили делать, как делали. 

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

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

Как же создать такую технологию управления, чтобы она реально работала? Чтобы через какое-то время не случилось очередного отторжения – как после неудачной пересадки органа?

💡 Идеально встроиться в днк вашей организации и закрыть ее потребности.

Только в этом случае вы увидите результат от ее применения – возможность делегировать проекты и сложные задачи с уверенностью в результате и четкую, автономную работу сотрудников.

💥 Коллеги, сегодня я подготовил для вас 15-минутное видео, где я не только расскажу, но и покажу на примере реального кейса, как создать такую технологию в 3 шага. 

Чтобы получить видео, переходите в чат-бот.

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

Какие ваши доказательства?!

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

И вот, что я думаю, почему так происходит👇

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

И если тут пытаться все сделать по учебнику, по четко выстроенной последовательности шагов, то сделать как надо в итоге заказчику (получить готовый продукт раньше конкурентов), точно не получится. Так зачем нам нужно соблюдать эту последовательность, если на деле она только тормозит? 

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

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

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

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

Поэтому описание шагов, конечно, полезно для общего развития сотрудников и понимания процессов, но на практике нам нужны не шаги, а проверяемые артефакты.

Коллеги, хочу написать пост о том, как оценивать эффективность инструментов. Интересно?

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

🚀 Посты:

🔹Почему качественная отчетность – залог спокойствия руководителя 

🔹 Найм дорогостоящего специалиста – спасение или выкинутые на ветер деньги? 

🔹 Почему опыт компании важнее опыта одного руководителя 

🔹 Почему вовлечение ключевых руководителей компании жизненно необходимо для реализации важного внутреннего проекта 

🔹 Почему ваши сотрудники играют в молчанку и к каким последствиям это приводит 

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

🔹 Почему правила управления проектами не работают 

🔹 Кради художник. Или как нужно заимствовать чужие лучшие практики правильно: часть 1 и часть 2

🚀 Статьи:

🔹 Единственный способ вылезти из ловушки микроменеджмента и запустить автопилот

🔹 Что надо сделать, чтобы проектное управление заработало, а сотрудники начали действовать автономно

🔹 Кейс: как мы настроили и автоматизировали проектное управление для 300+ участников проектов на Jira в Hoff 

А также:

🔹 Запись подкаста с Юрием Проскурней: что такое фреймворки, как они помогают делать проекты и зачем нужны бизнесу

🔥 Кстати, в нашей базе знаний БРИЗ в этом году также появилось несколько новых инструментов:

🔹 Ретроспективные игры - чтобы повысить вовлеченность команды в ретро, создать психологически безопасную атмосферу, направить обсуждение в нужную сторону

🔹 Методика оценки StoryPoints, с помощью которой можно оценить объем усилий и ресурсов, нужных для завершения задачи

🔹 Методика для составления расписания проекта PERT – для планирования и управления проектами, особенно, когда они имеют сложные зависимости

🔹 Метод Дельфи – способствует выработке более точных прогнозов и решений в условиях неопределённости

🔹 Метод критической цепи Critical Chain Method – помогает получить более реалистичное представление о продолжительности проекта, учитывая, что редко всё идёт идеально по плану

#дайджест_PMLogix