Кради как художник🥷
Каждый руководитель, осознавший необходимость единых правил управления проектами, рано или поздно приходит к мысли: «А может, посмотреть, как работают другие и внедрить то же самое у нас?» Ведь успешные компании уже выстроили свои процессы, значит, их можно просто скопировать?
Но это работает не совсем так, и ниже я поясню, почему слепое копирование чужого опыта – плохая идея.
Все лучшие практики являются лучшими только потому, что они хорошо работают в конкретной компании и учитывают корпоративную культуру, внутренние процессы, правила взаимодействия. Сейчас часто даже «лучшие практики» переименовывают в «хорошие» (имея в виду, что не стоит их слепо копировать).
👉 Например, в одной компании процедура согласования документов занимает 3 месяца – для них это норма, встроенная в бизнес-процессы. Для вас такие сроки – катастрофа, которая парализует работу.
👉 В другой компании регламенты и бизнес-правила создаются в электронной доске (типа Miro) или презентациях – быстро, удобно, наглядно. Но у вас такой формат не работает, потому что презентация не считается формальным документом – регламенты должны быть подготовлены в соответствии с внутренними стандартами предприятия и правилами документооборота.
Я не говорю о том, что не нужно смотреть, как делают другие. Но если вы хотите создать единые правила управления проектами, то опираться вам в первую очередь нужно не на чужой опыт, а на свой. И только после этого смотреть, что есть у других, что можно использовать у вас.
Как правильно заимствовать лучшие практики? Расскажу в следующем посте на примере одного недавнего кейса. Если интересно, дайте знать🔥
Каждый руководитель, осознавший необходимость единых правил управления проектами, рано или поздно приходит к мысли: «А может, посмотреть, как работают другие и внедрить то же самое у нас?» Ведь успешные компании уже выстроили свои процессы, значит, их можно просто скопировать?
Но это работает не совсем так, и ниже я поясню, почему слепое копирование чужого опыта – плохая идея.
Все лучшие практики являются лучшими только потому, что они хорошо работают в конкретной компании и учитывают корпоративную культуру, внутренние процессы, правила взаимодействия. Сейчас часто даже «лучшие практики» переименовывают в «хорошие» (имея в виду, что не стоит их слепо копировать).
👉 Например, в одной компании процедура согласования документов занимает 3 месяца – для них это норма, встроенная в бизнес-процессы. Для вас такие сроки – катастрофа, которая парализует работу.
👉 В другой компании регламенты и бизнес-правила создаются в электронной доске (типа Miro) или презентациях – быстро, удобно, наглядно. Но у вас такой формат не работает, потому что презентация не считается формальным документом – регламенты должны быть подготовлены в соответствии с внутренними стандартами предприятия и правилами документооборота.
Я не говорю о том, что не нужно смотреть, как делают другие. Но если вы хотите создать единые правила управления проектами, то опираться вам в первую очередь нужно не на чужой опыт, а на свой. И только после этого смотреть, что есть у других, что можно использовать у вас.
Как правильно заимствовать лучшие практики? Расскажу в следующем посте на примере одного недавнего кейса. Если интересно, дайте знать🔥
This media is not supported in your browser
VIEW IN TELEGRAM
Никого вам не напоминает?😅
Продолжаю тему: как правильно заимствовать лучшие практики? Расскажу на примере одного недавнего кейса👇
Во время разработки единых правил управления мы с заказчиком определили три основных типа проектов в компании. Все они одинаково важны, но цели различны: например, для коммерческого проекта наиболее важны сроки реализации, маржинальность и удовлетворенность заказчика, а для внутренних проектов по совершенствованию процессов – приживаемость результатов.
Что дальше? Мы посмотрели, какие инструменты и практики уже применялись в компании для достижения этих целей. Что показало свою эффективность, а что оказалось бесполезным и от этого стоит отказаться.
Если раньше реестр рисков всегда заполняли формально (риски нарушения сроков, превышения бюджетов и неудовлетворенности заказчиков), а то и вовсе игнорировали, потому что организация еще не дозрела до такого продвинутого уровня, зачем его оставлять? Должны остаться только те инструменты и практики, которые компания в состоянии использовать и которые реально будут влиять на успех проектов.
И вот когда мы разобрались, что можно оставить, а от чего нужно отказаться вовсе… Мы начали смотреть на то, что можно улучшить. И именно на этом шаге полезно обратиться к внешнему опыту, чтобы понять, что может подойти.
Например, если мы говорим о внедрении новой корпоративной ИТ-системы, то в некоторых компаниях в рамках чендж-менеджмента успешно применяют индивидуальные сессии с сотрудниками для коучинга и сбора обратной связи. Но если в вашей компании руководители, проводящие подобные сессии, не обладают необходимыми навыками, а встречи тет-а-тет для сбора обратной связи не сочетаются с корпоративной культурой, то лучше пока забыть про эту практику.
Выводы: используйте чужие лучшие практики только если они соответствуют контексту и культуре вашей компании, но даже в этом случае АДАПТИРУЙТЕ ИХ, иначе эти лучшие практики станут для вас худшими.
Кстати, то же самое происходит с готовыми фреймворками, которые многие пытаются впихнуть в организацию, не адаптировав под ее контекст.
❗️Коллеги, если хотите посмотреть, как создаются правила управления проектами с адаптацией инструментов из других фреймворков под культуру компании, приглашаю вас на методологическую экскурсию🔥
Пошагово расскажу и покажу на примере одного кейса, как мы разрабатывали правила, используя имеющийся опыт организации и внешние практики.
Чтобы записаться на экскурсию, напишите мне в ЛС @Malakhov_Andrey
Во время разработки единых правил управления мы с заказчиком определили три основных типа проектов в компании. Все они одинаково важны, но цели различны: например, для коммерческого проекта наиболее важны сроки реализации, маржинальность и удовлетворенность заказчика, а для внутренних проектов по совершенствованию процессов – приживаемость результатов.
Что дальше? Мы посмотрели, какие инструменты и практики уже применялись в компании для достижения этих целей. Что показало свою эффективность, а что оказалось бесполезным и от этого стоит отказаться.
Если раньше реестр рисков всегда заполняли формально (риски нарушения сроков, превышения бюджетов и неудовлетворенности заказчиков), а то и вовсе игнорировали, потому что организация еще не дозрела до такого продвинутого уровня, зачем его оставлять? Должны остаться только те инструменты и практики, которые компания в состоянии использовать и которые реально будут влиять на успех проектов.
И вот когда мы разобрались, что можно оставить, а от чего нужно отказаться вовсе… Мы начали смотреть на то, что можно улучшить. И именно на этом шаге полезно обратиться к внешнему опыту, чтобы понять, что может подойти.
Например, если мы говорим о внедрении новой корпоративной ИТ-системы, то в некоторых компаниях в рамках чендж-менеджмента успешно применяют индивидуальные сессии с сотрудниками для коучинга и сбора обратной связи. Но если в вашей компании руководители, проводящие подобные сессии, не обладают необходимыми навыками, а встречи тет-а-тет для сбора обратной связи не сочетаются с корпоративной культурой, то лучше пока забыть про эту практику.
Выводы: используйте чужие лучшие практики только если они соответствуют контексту и культуре вашей компании, но даже в этом случае АДАПТИРУЙТЕ ИХ, иначе эти лучшие практики станут для вас худшими.
Кстати, то же самое происходит с готовыми фреймворками, которые многие пытаются впихнуть в организацию, не адаптировав под ее контекст.
❗️Коллеги, если хотите посмотреть, как создаются правила управления проектами с адаптацией инструментов из других фреймворков под культуру компании, приглашаю вас на методологическую экскурсию🔥
Пошагово расскажу и покажу на примере одного кейса, как мы разрабатывали правила, используя имеющийся опыт организации и внешние практики.
Чтобы записаться на экскурсию, напишите мне в ЛС @Malakhov_Andrey
А вот, что говорят те, кто уже приходил ко мне на методологическую экскурсию👆
Пошагово рассказываю на примере одного из кейсов, как создавать такие правила управления проектами, которые решают проблему узких мест в организации и экономят более 30% времени руководства на ежедневном принятии решений и микромененджменте.
Коллеги, экскурсия бесплатная, но в этом месяце у меня есть только 2 места.
Для записи напишите мне в ЛС @Malakhov_Andrey
Пошагово рассказываю на примере одного из кейсов, как создавать такие правила управления проектами, которые решают проблему узких мест в организации и экономят более 30% времени руководства на ежедневном принятии решений и микромененджменте.
Коллеги, экскурсия бесплатная, но в этом месяце у меня есть только 2 места.
Для записи напишите мне в ЛС @Malakhov_Andrey
This media is not supported in your browser
VIEW IN TELEGRAM
Стахановцы проектники, а как у вас дела с ментальным здоровьем?
🔥 горю и еду на велосипеде, который тоже горит
👍 ничего, держимся
🥴 у самурая нет цели, только путь
🔥 горю и еду на велосипеде, который тоже горит
👍 ничего, держимся
🥴 у самурая нет цели, только путь
Потому что в первом случае правила управления создавались с опорой на дистилированный успешный опыт компании, а во втором на «давайте сделаем как у других» или с позиции жестких требований – «врач сказал в морг, значит в морг».
Коллеги, читайте мою новую статью, как создать такие правила управления проектами, которые будут работать, будут приняты сотрудниками и помогут руководству высвободить как минимум 30% своего времени на принятии решений и разруливании кризисных ситуаций.
Please open Telegram to view this post
VIEW IN TELEGRAM
Хабр
Что надо сделать, чтобы проектное управление заработало и ваши сотрудники начали действовать автономно
Как руководителю начать экономить свое время до 30% на ежедневном принятии решений и микроменеджменте? Как перестать контролировать каждого сотрудника и перестать тревожиться, что без вас что-то...
И еще раз о «лучших» практиках, которые вы пытаетесь внедрить у себя. На скрине выше – комментарий к моей новой статье, где очень хорошо описана ситуация с таким внедрением.
Если реестр рисков всегда заполняется формально, а то и вовсе игнорируется, потому что организация еще не дозрела до такого продвинутого уровня, зачем его оставлять?
Да, вести реестр рисков и заранее прорабатывать меры их устранения это полезная и успешная во многих компаниях практика. Но вы должны трезво оценивать уровень зрелости проектного управления в вашей компании, а потому должны остаться только те инструменты и практики, которые компания в состоянии использовать и которые реально будут влиять на успех проектов.
Если у вас не работает реестр рисков, заведите другой артефакт – пусть это будет реестр проблем. Назовите его как угодно, главное, чтобы его заполняли не формально.
Коллеги, поделитесь, какие инструменты и практики вы пытались внедрить, но они не взлетели?
Если реестр рисков всегда заполняется формально, а то и вовсе игнорируется, потому что организация еще не дозрела до такого продвинутого уровня, зачем его оставлять?
Да, вести реестр рисков и заранее прорабатывать меры их устранения это полезная и успешная во многих компаниях практика. Но вы должны трезво оценивать уровень зрелости проектного управления в вашей компании, а потому должны остаться только те инструменты и практики, которые компания в состоянии использовать и которые реально будут влиять на успех проектов.
Если у вас не работает реестр рисков, заведите другой артефакт – пусть это будет реестр проблем. Назовите его как угодно, главное, чтобы его заполняли не формально.
Коллеги, поделитесь, какие инструменты и практики вы пытались внедрить, но они не взлетели?
Провел свой авторский двухдневный курс «Проектный офис» на программе «Управление проектами» MBA РАНХиГС.
Благодарю научного руководителя программы Алексея Владимировича Полковникова за приглашение🤝
Два дня были очень насыщенными: успели пройти все темы, от определения целей, функций, задач проектного офиса до пошагового плана запуска и измерения эффекта его деятельности!
А выше делюсь отзывами слушателей программы. Спасибо за вовлеченность и интересные вопросы!
Благодарю научного руководителя программы Алексея Владимировича Полковникова за приглашение🤝
Два дня были очень насыщенными: успели пройти все темы, от определения целей, функций, задач проектного офиса до пошагового плана запуска и измерения эффекта его деятельности!
А выше делюсь отзывами слушателей программы. Спасибо за вовлеченность и интересные вопросы!
Кто я и про что этот блог
Коллеги, в моем канале появилось много новых людей, поэтому предлагаю познакомиться!
Меня зовут Андрей Малахов.
Я и эксперт, и предприниматель, и новатор – разработал и успешно внедряю гибридный метод управления проектами Парацельс ПМ. Собственник и руководитель консалтинговой компании PMLogix.
Почему я считаю, что меня нужно читать?
Здесь я делюсь инструментами и решениями, проверенными на личном 20-летнем опыте в управлении проектами и изменениями. А еще рассказываю на примере своих консалтинговых кейсов, как реализовывать масштабные цели, проекты и трансформации с помощью эффективной системы управления проектами и изменениями.
С чего можно начать знакомство с моим блогом:
🔹Почему организации нужна скорость, а не срочность
🔹Если на тебя никто не будет жаловаться, я тебя уволю. Почему руководитель проектного офиса должен быть самым неудобным человеком в компании
🔹Что такое револьверный принцип: как реализовывать важные проекты, когда задачи от заказчика летят нон-стоп
А также:
👉 советую почитать наши #кейсы, в которых я подробно рассказываю о ходе работы, трудностях и методах их преодоления на наших консалтинговых проектах;
👉 на моем Youtube канале и в ВК видео вы найдете записи вебинаров и подкасты с топовыми российскими экспертами.
Коллеги, рассказывайте, кто вы, чем занимаетесь и что нравится в моем блоге?
Коллеги, в моем канале появилось много новых людей, поэтому предлагаю познакомиться!
Меня зовут Андрей Малахов.
Я и эксперт, и предприниматель, и новатор – разработал и успешно внедряю гибридный метод управления проектами Парацельс ПМ. Собственник и руководитель консалтинговой компании PMLogix.
Почему я считаю, что меня нужно читать?
Здесь я делюсь инструментами и решениями, проверенными на личном 20-летнем опыте в управлении проектами и изменениями. А еще рассказываю на примере своих консалтинговых кейсов, как реализовывать масштабные цели, проекты и трансформации с помощью эффективной системы управления проектами и изменениями.
С чего можно начать знакомство с моим блогом:
🔹Почему организации нужна скорость, а не срочность
🔹Если на тебя никто не будет жаловаться, я тебя уволю. Почему руководитель проектного офиса должен быть самым неудобным человеком в компании
🔹Что такое револьверный принцип: как реализовывать важные проекты, когда задачи от заказчика летят нон-стоп
А также:
👉 советую почитать наши #кейсы, в которых я подробно рассказываю о ходе работы, трудностях и методах их преодоления на наших консалтинговых проектах;
👉 на моем Youtube канале и в ВК видео вы найдете записи вебинаров и подкасты с топовыми российскими экспертами.
Коллеги, рассказывайте, кто вы, чем занимаетесь и что нравится в моем блоге?
Андрей Малахов | от проектов к изменениям pinned Deleted message
📣 3 шага, чтобы создать свою технологию управления проектами
Я часто вижу, как в организациях пытаются создать свою технологию управления. И почти всегда все начинается оптимистично: руководство дает отмашку, собирается рабочая группа, пишутся регламенты, сотрудников вводят в курс нововведений… Но в итоге – пару месяцев «поиграли» по новым правилам и вернулись к тому, что было. Или же сделали вид, что поиграли, а по факту продолжили делать, как делали.
Потому что технология это, конечно, здорово, но нам вообще-то проекты вывозить надо, а не вашими бумажками заниматься.
Но правда в том, что без правильной технологии вы и ваши ключевые руководители будете продолжать вывозить, выгорать, тушить пожары. Потому что у вас нет времени объяснять каждому, что же конкретно надо делать, чтобы проекты укладывались в сроки и выделенный бюджет.
Как же создать такую технологию управления, чтобы она реально работала? Чтобы через какое-то время не случилось очередного отторжения – как после неудачной пересадки органа?
💡 Идеально встроиться в днк вашей организации и закрыть ее потребности.
Только в этом случае вы увидите результат от ее применения – возможность делегировать проекты и сложные задачи с уверенностью в результате и четкую, автономную работу сотрудников.
💥 Коллеги, сегодня я подготовил для вас 15-минутное видео, где я не только расскажу, но и покажу на примере реального кейса, как создать такую технологию в 3 шага.
Чтобы получить видео, переходите в чат-бот.
Читайте о моем методе сборке технологии управления проектами и сложными задачами подробнее по этой ссылке.
Я часто вижу, как в организациях пытаются создать свою технологию управления. И почти всегда все начинается оптимистично: руководство дает отмашку, собирается рабочая группа, пишутся регламенты, сотрудников вводят в курс нововведений… Но в итоге – пару месяцев «поиграли» по новым правилам и вернулись к тому, что было. Или же сделали вид, что поиграли, а по факту продолжили делать, как делали.
Потому что технология это, конечно, здорово, но нам вообще-то проекты вывозить надо, а не вашими бумажками заниматься.
Но правда в том, что без правильной технологии вы и ваши ключевые руководители будете продолжать вывозить, выгорать, тушить пожары. Потому что у вас нет времени объяснять каждому, что же конкретно надо делать, чтобы проекты укладывались в сроки и выделенный бюджет.
Как же создать такую технологию управления, чтобы она реально работала? Чтобы через какое-то время не случилось очередного отторжения – как после неудачной пересадки органа?
💡 Идеально встроиться в днк вашей организации и закрыть ее потребности.
Только в этом случае вы увидите результат от ее применения – возможность делегировать проекты и сложные задачи с уверенностью в результате и четкую, автономную работу сотрудников.
💥 Коллеги, сегодня я подготовил для вас 15-минутное видео, где я не только расскажу, но и покажу на примере реального кейса, как создать такую технологию в 3 шага.
Чтобы получить видео, переходите в чат-бот.
Читайте о моем методе сборке технологии управления проектами и сложными задачами подробнее по этой ссылке.
Андрей Малахов | от проектов к изменениям pinned «📣 3 шага, чтобы создать свою технологию управления проектами Я часто вижу, как в организациях пытаются создать свою технологию управления. И почти всегда все начинается оптимистично: руководство дает отмашку, собирается рабочая группа, пишутся регламенты…»
Какие ваши доказательства?!
В прошлом году я уже затрагивал эту тему, почему на мой взгляд описание процессов в виде шагов не работает, а большинство готовых фреймворков представляет собой декларацию, но никак не алгоритм, помогающий делать проекты быстрее, результативнее и с минимум рисков.
И вот, что я думаю, почему так происходит👇
Во-первых, шаги – это четкая последовательность, линейный процесс. А в жизни, на реальных проектах, эту последовательность соблюсти практически невозможно: требования постоянно меняются и на какие-то этапы приходится возвращаться. Или наоборот – нужно начинать несколько разных этапов параллельно, если критически важно соблюсти сроки. Например, перейти к реализации, пока этап сбора требований еще в процессе.
И если тут пытаться все сделать по учебнику, по четко выстроенной последовательности шагов, то сделать как надо в итоге заказчику (получить готовый продукт раньше конкурентов), точно не получится. Так зачем нам нужно соблюдать эту последовательность, если на деле она только тормозит?
Во-вторых, опираясь на описание шагов, инструкцию, а не на проверяемые документы о полученном результате, нарваться на риски становится в разы проще. Почему так? Поясню ниже.
Например, во многих фреймворках шаг «Назначить руководителя проекта» часто описывают в виде его функций – быть ответственным за результат проекта, общаться с заказчиками и тд. Вопрос - как это описание может помочь нам на практике?
Откуда мы знаем, назначили руководителя просто на словах (поставим Иванова на такой-то проект) или все-таки официально, с закреплением ответственности и выдачей полномочий? Очевидно, что в зависимости от того, как именно это было сделано, судьба проекта может быть очень разной.
Внедряемые правила управления не должны лежать в качестве энциклопедии, где описано, что надо сделать на каждом шаге. Они должны работать на практике, быть инструментом для достижения целей как проектов, так и организации, бизнеса в целом.
Поэтому описание шагов, конечно, полезно для общего развития сотрудников и понимания процессов, но на практике нам нужны не шаги, а проверяемые артефакты.
Коллеги, хочу написать пост о том, как оценивать эффективность инструментов. Интересно?
В прошлом году я уже затрагивал эту тему, почему на мой взгляд описание процессов в виде шагов не работает, а большинство готовых фреймворков представляет собой декларацию, но никак не алгоритм, помогающий делать проекты быстрее, результативнее и с минимум рисков.
И вот, что я думаю, почему так происходит👇
Во-первых, шаги – это четкая последовательность, линейный процесс. А в жизни, на реальных проектах, эту последовательность соблюсти практически невозможно: требования постоянно меняются и на какие-то этапы приходится возвращаться. Или наоборот – нужно начинать несколько разных этапов параллельно, если критически важно соблюсти сроки. Например, перейти к реализации, пока этап сбора требований еще в процессе.
И если тут пытаться все сделать по учебнику, по четко выстроенной последовательности шагов, то сделать как надо в итоге заказчику (получить готовый продукт раньше конкурентов), точно не получится. Так зачем нам нужно соблюдать эту последовательность, если на деле она только тормозит?
Во-вторых, опираясь на описание шагов, инструкцию, а не на проверяемые документы о полученном результате, нарваться на риски становится в разы проще. Почему так? Поясню ниже.
Например, во многих фреймворках шаг «Назначить руководителя проекта» часто описывают в виде его функций – быть ответственным за результат проекта, общаться с заказчиками и тд. Вопрос - как это описание может помочь нам на практике?
Откуда мы знаем, назначили руководителя просто на словах (поставим Иванова на такой-то проект) или все-таки официально, с закреплением ответственности и выдачей полномочий? Очевидно, что в зависимости от того, как именно это было сделано, судьба проекта может быть очень разной.
Внедряемые правила управления не должны лежать в качестве энциклопедии, где описано, что надо сделать на каждом шаге. Они должны работать на практике, быть инструментом для достижения целей как проектов, так и организации, бизнеса в целом.
Поэтому описание шагов, конечно, полезно для общего развития сотрудников и понимания процессов, но на практике нам нужны не шаги, а проверяемые артефакты.
Коллеги, хочу написать пост о том, как оценивать эффективность инструментов. Интересно?