Продолжу вчерашнюю тему: почему летящий астероид это шанс, а не катастрофа 💥
В управлении изменениями есть такой термин «горящая платформа» – фактор, мотивирующий на изменения (откуда он появился – я уже писал в этом посте). Это значит, что только критическая ситуация может быстро замотивировать человека на изменения (прыгнуть в воду с 45 метров), потому что иначе, если он останется на платформе, то сгорит вместе с ней.
С одной стороны, это правда так – большинство людей начинает что-то менять в жизни или бизнесе только когда «пригорело». С другой стороны, я считаю, что критическая ситуация не лучшая почва для изменений, потому что тут только два пути развития событий:
👉 кто-то запаникует, крикнет «спасайся, кто может» и прыгнет в воду с огромной высоты, надеясь на везение;
👉 кого-то парализует от страха и он останется на горящей платформе и примет судьбу, также надеясь на везение.
Конечно, прыгнуть в воду лучше, чем остаться на месте, так как это единственно возможный выход, хоть и с минимальными шансами на выживание. Но все равно перспективы такой ситуации не очень оптимистичные – ты либо точно умрешь, либо скорее всего умрешь.
Поэтому говоря об управлении изменениями, я считаю, что ситуация с летящим астероидом гораздо лучше описывает реальные условия для изменений, потому что она дает время для принятия обдуманных решений. Время, чтобы подготовиться, без паники спланировать порядок действий, провести инструктажи и прочее. Чтобы в итоге не полагаться только на везение.
Летящий астероид – это шанс на выживание, а горящая платформа – проверка удачи во время катастрофы.
О том, как внедрить изменения и подготовиться к летящему астероиду, расскажу 27 мая на своем вебинаре «Как не провалить проектное управление».
Поговорим о том, какие шаги должна пройти организация, чтобы подготовить сотрудников к новой системе управления проектами и дать ей шанс на выживание.
В управлении изменениями есть такой термин «горящая платформа» – фактор, мотивирующий на изменения (откуда он появился – я уже писал в этом посте). Это значит, что только критическая ситуация может быстро замотивировать человека на изменения (прыгнуть в воду с 45 метров), потому что иначе, если он останется на платформе, то сгорит вместе с ней.
С одной стороны, это правда так – большинство людей начинает что-то менять в жизни или бизнесе только когда «пригорело». С другой стороны, я считаю, что критическая ситуация не лучшая почва для изменений, потому что тут только два пути развития событий:
👉 кто-то запаникует, крикнет «спасайся, кто может» и прыгнет в воду с огромной высоты, надеясь на везение;
👉 кого-то парализует от страха и он останется на горящей платформе и примет судьбу, также надеясь на везение.
Конечно, прыгнуть в воду лучше, чем остаться на месте, так как это единственно возможный выход, хоть и с минимальными шансами на выживание. Но все равно перспективы такой ситуации не очень оптимистичные – ты либо точно умрешь, либо скорее всего умрешь.
Поэтому говоря об управлении изменениями, я считаю, что ситуация с летящим астероидом гораздо лучше описывает реальные условия для изменений, потому что она дает время для принятия обдуманных решений. Время, чтобы подготовиться, без паники спланировать порядок действий, провести инструктажи и прочее. Чтобы в итоге не полагаться только на везение.
Летящий астероид – это шанс на выживание, а горящая платформа – проверка удачи во время катастрофы.
О том, как внедрить изменения и подготовиться к летящему астероиду, расскажу 27 мая на своем вебинаре «Как не провалить проектное управление».
Поговорим о том, какие шаги должна пройти организация, чтобы подготовить сотрудников к новой системе управления проектами и дать ей шанс на выживание.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3🔥2
Коллеги, я переоценил свои силы и из-за высокой загрузки на этой неделе вынужден перенести завтрашний вебинар «Как не провалить проектное управление» на следующий вторник, 27 мая. Поэтому если вы еще не успели зарегистрироваться, то обязательно регистрируйтесь, потому что ссылка на трансляцию будет доступна только зарегистрированным участникам!
👍10😁5❤1
Мы тут много говорим про технологии и методологии управления проектами изменениями.
Но порой ограничения в нашем росте находятся у нас в голове. Чтобы их проработать, вписался в наставничество к Ильмиру Такаеву @ILMIR_TAKAEV психологу и гипнотерапевту в бизнес-клубе Terra.
Помогать в трансформациях может только тот, кто трансформируется сам.
Буду делиться своими изменениями с вами!
Но порой ограничения в нашем росте находятся у нас в голове. Чтобы их проработать, вписался в наставничество к Ильмиру Такаеву @ILMIR_TAKAEV психологу и гипнотерапевту в бизнес-клубе Terra.
Помогать в трансформациях может только тот, кто трансформируется сам.
Буду делиться своими изменениями с вами!
👍5🤯2🤣1
А что не так с девелоперскими проектами?
Кто работает в этой отрасли, тот знает, что увеличение сроков строительства и, как следствие, снижение прибыли, это главная боль всех девелоперов. И причин может быть много: то внесли изменения в проект уже по ходу строительства, то нужное разрешение не получили вовремя, то банк долго согласовывал план для финансирования. А то и вовсе сдвинули старт продаж на три недели, потому что из-за разруливания более важных вопросов «забыли» про установку офиса продаж на объекте.
Многие компании постоянно пытаются решить эту проблему: улучшают качество планирования, нанимают больше людей, мотивируют руководителей проектов по выполнению сроков… Однако ситуация не меняется. Потому что, например, система мотивации – это отлично, но она не поможет в управлении сроками, когда требования к проекту постоянно меняются.
Так что знать, почему происходит то, что происходит, это еще не значит решить проблему. Потому что чаще всего та проблема, которая на поверхности, это всего лишь симптом настоящей «болезни». Например, если установка офиса продаж на объекте постоянно откладывается, пока все сроки не сгорели, то это не потому, что руководитель проекта или отдел продаж «забыли». Такое часто происходит, когда у негорящих вопросов отсутствует приоритизация, при этом более важные задачи, связанные со сдачей объекта, горят всегда.
Поэтому важно разобраться с первопричинами – где здесь брешь? В отчетности, планировании взаимосвязанных работ, коммуникации между подразделениями, ресурсах?
В ближайшее время поделюсь нашим прошлогодним кейсом, как мы провели глубинную диагностику проектного управления в крупной девелоперской компании, чтобы выявить первопричины проблем и подобрать инструменты для их устранения. Заодно подробно поделюсь, какие методы диагностики мы используем, и расскажу, почему субъективная оценка ключевых участников проектов важнее, чем анализ проектных документов.
Киньте реакций, если интересно!
Кто работает в этой отрасли, тот знает, что увеличение сроков строительства и, как следствие, снижение прибыли, это главная боль всех девелоперов. И причин может быть много: то внесли изменения в проект уже по ходу строительства, то нужное разрешение не получили вовремя, то банк долго согласовывал план для финансирования. А то и вовсе сдвинули старт продаж на три недели, потому что из-за разруливания более важных вопросов «забыли» про установку офиса продаж на объекте.
Многие компании постоянно пытаются решить эту проблему: улучшают качество планирования, нанимают больше людей, мотивируют руководителей проектов по выполнению сроков… Однако ситуация не меняется. Потому что, например, система мотивации – это отлично, но она не поможет в управлении сроками, когда требования к проекту постоянно меняются.
Так что знать, почему происходит то, что происходит, это еще не значит решить проблему. Потому что чаще всего та проблема, которая на поверхности, это всего лишь симптом настоящей «болезни». Например, если установка офиса продаж на объекте постоянно откладывается, пока все сроки не сгорели, то это не потому, что руководитель проекта или отдел продаж «забыли». Такое часто происходит, когда у негорящих вопросов отсутствует приоритизация, при этом более важные задачи, связанные со сдачей объекта, горят всегда.
Поэтому важно разобраться с первопричинами – где здесь брешь? В отчетности, планировании взаимосвязанных работ, коммуникации между подразделениями, ресурсах?
В ближайшее время поделюсь нашим прошлогодним кейсом, как мы провели глубинную диагностику проектного управления в крупной девелоперской компании, чтобы выявить первопричины проблем и подобрать инструменты для их устранения. Заодно подробно поделюсь, какие методы диагностики мы используем, и расскажу, почему субъективная оценка ключевых участников проектов важнее, чем анализ проектных документов.
Киньте реакций, если интересно!
👍9🔥7❤3
Как создать систему управления проектами в ИТ-интеграторе и не выкинуть деньги на ветер?
90% новых правил управления проваливается на стадии внедрения, потому что опытные сотрудники не видят в них смысла – у них свои методы управления и вытаскивания проектов из жопы, которые пока что не подводили. А навязывать им готовый фреймворк и вовсе бесполезно, потому что в реальности все эти «лучшие» практики не работают.
Что делать? Какой должна быть система управления проектами, чтобы даже ветераны вашей компании превратились из скептиков в амбассадоров новых правил? Ведь только в этом случае у организации будет шанс окупить вложенные инвестиции в их разработку.
Читайте мою новую статью на хабре, где я рассказываю о четырех принципах разработки такой системы управления проектами🔥
90% новых правил управления проваливается на стадии внедрения, потому что опытные сотрудники не видят в них смысла – у них свои методы управления и вытаскивания проектов из жопы, которые пока что не подводили. А навязывать им готовый фреймворк и вовсе бесполезно, потому что в реальности все эти «лучшие» практики не работают.
Что делать? Какой должна быть система управления проектами, чтобы даже ветераны вашей компании превратились из скептиков в амбассадоров новых правил? Ведь только в этом случае у организации будет шанс окупить вложенные инвестиции в их разработку.
Читайте мою новую статью на хабре, где я рассказываю о четырех принципах разработки такой системы управления проектами🔥
🔥3❤1
Как я не долетел на конференцию, но все-таки выступил
На прошлой неделе я собрался в Ижевск, чтобы выступить на конференции «Инструменты повышения операционной эффективности бизнеса» с докладом о сборке технологии управления проектами. Купил билеты на самолет, приехал в Домодедово, расположился в зале ожидания, но… Наш самолет не успел выполнить посадку и улетел на запасной аэродром в Нижний.
В общем, просидел я в аэропорту около 12 часов. При этом мы несколько раз заходили в салон самолета и снова выходили – то закрывалось воздушное пространство, то время пилота вышло, то еще что-то пошло не так. И на протяжении всего этого времени нам говорили «сейчас все будет, подождите еще чуть-чуть». Каждый раз, когда я это слышал, в голову приходила аналогия с большим сложным проектом, где кто-то сильно накосячил, но продолжает кормить стейкхолдеров завтраками🤡
Рейс должен был состояться в 9 вечера. Наступило 8 утра… Приехала новая бригада и нас снова запустили в салон самолета. И, покатав нас какое-то время по летному полю, пилот снова попросил покинуть самолет🤬
Немного раздосадованный и уставший я вернулся домой и выступил на конференции онлайн. Спасибо слушателям за вовлеченность и вопросы😁
На прошлой неделе я собрался в Ижевск, чтобы выступить на конференции «Инструменты повышения операционной эффективности бизнеса» с докладом о сборке технологии управления проектами. Купил билеты на самолет, приехал в Домодедово, расположился в зале ожидания, но… Наш самолет не успел выполнить посадку и улетел на запасной аэродром в Нижний.
В общем, просидел я в аэропорту около 12 часов. При этом мы несколько раз заходили в салон самолета и снова выходили – то закрывалось воздушное пространство, то время пилота вышло, то еще что-то пошло не так. И на протяжении всего этого времени нам говорили «сейчас все будет, подождите еще чуть-чуть». Каждый раз, когда я это слышал, в голову приходила аналогия с большим сложным проектом, где кто-то сильно накосячил, но продолжает кормить стейкхолдеров завтраками🤡
Рейс должен был состояться в 9 вечера. Наступило 8 утра… Приехала новая бригада и нас снова запустили в салон самолета. И, покатав нас какое-то время по летному полю, пилот снова попросил покинуть самолет🤬
Немного раздосадованный и уставший я вернулся домой и выступил на конференции онлайн. Спасибо слушателям за вовлеченность и вопросы😁
❤12😁7🔥2
Главная ошибка самых опытных руководителей проектов
В прошлом году мы с командой PMLogix проводили диагностику проектного управления в крупной девелоперской компании (часть 1 тут). Проблема – потеря внушительной части прибыли из-за увеличения сроков строительства. А именно: требования к проектам постоянно меняются, и новые затраты на переделки «съедают» запланированную маржу.
Кажется очевидным, что если проблема со сроками из-за разрастания требований, то и диагностировать тут нечего – и так все понятно. Однако смысл глубинной диагностики заключается в определении первопричин возникновения проблем, которые часто могут быть очень неожиданными.
Подробностями поделюсь позже. Но вот, что я хочу отметить сейчас по мотивам этого кейса – даже самые опытные, мудрые и профессиональные руководители проектов часто совершают одну и ту же ошибку. Какую? Используют проектные документы по принципу «чтобы было». И нужные, полезные документы превращаются из инструментов управления в бесполезную формальность.
💡 Пример: в реестре стейкхолдеров есть раздел «интересы сторон», где прописывается, какую информацию нужно предоставлять всем заинтересованным сторонам по ходу проекта. Если мы пишем в этом разделе что-то вроде «предоставлять своевременную информацию о ходе проекта», то это чистая абстракция. Которая по факту означает, что руководство не получит нужную информацию в нужное время для принятия нужных решений. То есть данные о прогрессе проекта, отклонениях, маржинальности на текущую дату и прочее. И в итоге важные решения будут приниматься не на основе достоверных цифр, а «с потолка».
Почему так происходит? Часто недобросовестное отношение к использованию документов кроется в высокой загрузке руководителей. Понятно, что им надо вывозить проект, а не вычитывать формулировки в документах. Но на самом деле первопричина этой проблемы обычно заключается в том, что руководители просто не видят практической пользы от всей этой «бюрократии».
Коллеги, завтра на вебинаре по внедрению новых правил управления расскажу, как это делать с умом – чтобы ваши сотрудники понимали, зачем от них требуют то, что требуют, и видели ценность в «бумажной» работе. Регистрируйтесь здесь.
В прошлом году мы с командой PMLogix проводили диагностику проектного управления в крупной девелоперской компании (часть 1 тут). Проблема – потеря внушительной части прибыли из-за увеличения сроков строительства. А именно: требования к проектам постоянно меняются, и новые затраты на переделки «съедают» запланированную маржу.
Кажется очевидным, что если проблема со сроками из-за разрастания требований, то и диагностировать тут нечего – и так все понятно. Однако смысл глубинной диагностики заключается в определении первопричин возникновения проблем, которые часто могут быть очень неожиданными.
Подробностями поделюсь позже. Но вот, что я хочу отметить сейчас по мотивам этого кейса – даже самые опытные, мудрые и профессиональные руководители проектов часто совершают одну и ту же ошибку. Какую? Используют проектные документы по принципу «чтобы было». И нужные, полезные документы превращаются из инструментов управления в бесполезную формальность.
Почему так происходит? Часто недобросовестное отношение к использованию документов кроется в высокой загрузке руководителей. Понятно, что им надо вывозить проект, а не вычитывать формулировки в документах. Но на самом деле первопричина этой проблемы обычно заключается в том, что руководители просто не видят практической пользы от всей этой «бюрократии».
Коллеги, завтра на вебинаре по внедрению новых правил управления расскажу, как это делать с умом – чтобы ваши сотрудники понимали, зачем от них требуют то, что требуют, и видели ценность в «бумажной» работе. Регистрируйтесь здесь.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍7❤1
This media is not supported in your browser
VIEW IN TELEGRAM
👍2
Что важнее – дизайн методологии или качество её внедрения?
Вот с такого каверзного вопроса я начал свой вчерашний вебинар.
Однозначного ответа здесь нет, потому что:
👉 если методология не подходит компании (не закрывает потребности, не учитывает контекст проектов, особенности процессов), то внедрение такой методологии будет провалено;
👉 если же мы разработаем качественную методологию, но не проведем нужные мероприятия по вовлечению людей, включая руководство, то и её внедрение тоже будет провалено.
Дизайн методологии и процесс её внедрения – это инь и ян. Две части одного целого, необходимые для того, чтобы все в итоге заработало, а новые правила управления приносили пользу проектам. Так что, процесс внедрения всегда идет рука об руку с процессом разработки.
🔥 Вчерашний вебинар побил все рекорды по длительности: 1 час и 40 минут плотного структурированного контента. Тем, кто досмотрел до конца и задал вопросы – отдельный респект.
Запись вебинара доступна в боте PMLogix здесь. Обязательно посмотрите его вместе с моим вебинаром по разработке кастомной системы управления проектами, потому что успех внедрения напрямую зависит от качества самой методологии.
Вот с такого каверзного вопроса я начал свой вчерашний вебинар.
Однозначного ответа здесь нет, потому что:
👉 если методология не подходит компании (не закрывает потребности, не учитывает контекст проектов, особенности процессов), то внедрение такой методологии будет провалено;
👉 если же мы разработаем качественную методологию, но не проведем нужные мероприятия по вовлечению людей, включая руководство, то и её внедрение тоже будет провалено.
Дизайн методологии и процесс её внедрения – это инь и ян. Две части одного целого, необходимые для того, чтобы все в итоге заработало, а новые правила управления приносили пользу проектам. Так что, процесс внедрения всегда идет рука об руку с процессом разработки.
🔥 Вчерашний вебинар побил все рекорды по длительности: 1 час и 40 минут плотного структурированного контента. Тем, кто досмотрел до конца и задал вопросы – отдельный респект.
Запись вебинара доступна в боте PMLogix здесь. Обязательно посмотрите его вместе с моим вебинаром по разработке кастомной системы управления проектами, потому что успех внедрения напрямую зависит от качества самой методологии.
🔥6
Парацельс ПМ – готовый метод управления проектами, на базе которого можно создать собственную технологию реализации проектов. Уже много лет успешно применяю его в своих консалтинговых кейсах. И сегодня поделюсь одним из ключевых принципов метода, который позволяет:
🚀 быстро внедрять новые правила управления с минимальным сопротивлением со стороны сотрудников;
🚀 получать первые результаты от внедрения уже в ходе разработки;
🚀 делать методологию понятной, небюрократичной и максимальной практичной.
Итак, главный принцип – нужно делать то, что нужно, а что не нужно – делать не нужно 😁 (это правило, которому меня когда-то научила моя начальница, директор по консалтингу Светлана Шлыкова в компании Frontstep, немного перефразировав цитату Винни-Пуха).
💡 Казалось бы очевидно, но на самом деле это ключевая проблема большинства готовых фреймворков. А именно: использование стандартного набора аспектов (областей внимания), что в итоге порождает бесполезную бюрократию, формальное заполнение шаблонов, трату времени и негатив со стороны руководителей проектов.
Да, в готовом решении Парацельс у нас есть минималистичный набор аспектов (цели и эффекты, содержание и качество, сроки и т.д.), которыми важно управлять практически в любых типах проектов.
Однако этот набор всегда трансформируется в зависимости от специфики конкретной компании и ее внутренних процессов. Например, если у вас работают выделенные команды, вам не нужно уделять особое внимание такому аспекту, как ресурсы. Или же если бюджет ваших проектов зависит от банковских займов (например, девелоперские проекты), то одного стандартного аспекта бюджет будет недостаточно (нужно вводить дополнительный, например – финансирование).
Так что, отказываясь от стандартного набора и адаптируя состав аспектов под конкретную организацию, мы создаем максимально простую, но при этом закрывающую реальные потребности проектов и организации проектную методологию.
А еще, так как каждый аспект железобетонно обоснован, потому что решает конкретные проблемы, договориться о важности уделять ему внимание с помощью новых правил управления намного проще. И это тоже критически важно, так как работоспособность любого регламента зависит от того, является ли он результатом реальных договоренностей или же директивным требованием.
🔹 Подробнее о методе Парацельс ПМ, для каких проектов он подходит лучше всего и из чего состоит, читайте здесь
🔹 Здесь можете скачать руководство по методу, чтобы начать применять его для управления проектами самостоятельно
🔹 А если хотите подробнее разобраться в методе и получить от меня личную консультацию, записывайтесь здесь (возможны два формата)
🚀 быстро внедрять новые правила управления с минимальным сопротивлением со стороны сотрудников;
🚀 получать первые результаты от внедрения уже в ходе разработки;
🚀 делать методологию понятной, небюрократичной и максимальной практичной.
Итак, главный принцип – нужно делать то, что нужно, а что не нужно – делать не нужно 😁 (это правило, которому меня когда-то научила моя начальница, директор по консалтингу Светлана Шлыкова в компании Frontstep, немного перефразировав цитату Винни-Пуха).
Да, в готовом решении Парацельс у нас есть минималистичный набор аспектов (цели и эффекты, содержание и качество, сроки и т.д.), которыми важно управлять практически в любых типах проектов.
Однако этот набор всегда трансформируется в зависимости от специфики конкретной компании и ее внутренних процессов. Например, если у вас работают выделенные команды, вам не нужно уделять особое внимание такому аспекту, как ресурсы. Или же если бюджет ваших проектов зависит от банковских займов (например, девелоперские проекты), то одного стандартного аспекта бюджет будет недостаточно (нужно вводить дополнительный, например – финансирование).
Так что, отказываясь от стандартного набора и адаптируя состав аспектов под конкретную организацию, мы создаем максимально простую, но при этом закрывающую реальные потребности проектов и организации проектную методологию.
А еще, так как каждый аспект железобетонно обоснован, потому что решает конкретные проблемы, договориться о важности уделять ему внимание с помощью новых правил управления намного проще. И это тоже критически важно, так как работоспособность любого регламента зависит от того, является ли он результатом реальных договоренностей или же директивным требованием.
🔹 Подробнее о методе Парацельс ПМ, для каких проектов он подходит лучше всего и из чего состоит, читайте здесь
🔹 Здесь можете скачать руководство по методу, чтобы начать применять его для управления проектами самостоятельно
🔹 А если хотите подробнее разобраться в методе и получить от меня личную консультацию, записывайтесь здесь (возможны два формата)
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4👍1
«Это лучшее, что я услышал на тему управления проектами за последнее время.»
«Встреча помогла мне добавить уверенности в том, что подход Парацельс более правильный, но при грамотном внедрении.»
«Повысился уровень доверия к методологии Парацельс ПМ, потому что когда что-то новое появляется, это всегда вызывает недоверие. Сейчас будет уже проще двигаться в сторону внедрения Парацельса как методологии управления проектами. Сначала начнем в рамках отдела внедрения, потом на уровне управления, потом, возможно, и на уровне всей компании.»
Вот такой отзыв получил о моем недавнем вебинаре про Парацельс ПМ и личной сессии от коллеги по цеху. Приятно получать такие отзывы 🤝 Если хотите попасть ко мне на бесплатную личную консультацию, переходите в бот PMLogix – там доступны два формата сессии.
#отзывы
«Встреча помогла мне добавить уверенности в том, что подход Парацельс более правильный, но при грамотном внедрении.»
«Повысился уровень доверия к методологии Парацельс ПМ, потому что когда что-то новое появляется, это всегда вызывает недоверие. Сейчас будет уже проще двигаться в сторону внедрения Парацельса как методологии управления проектами. Сначала начнем в рамках отдела внедрения, потом на уровне управления, потом, возможно, и на уровне всей компании.»
Вот такой отзыв получил о моем недавнем вебинаре про Парацельс ПМ и личной сессии от коллеги по цеху. Приятно получать такие отзывы 🤝 Если хотите попасть ко мне на бесплатную личную консультацию, переходите в бот PMLogix – там доступны два формата сессии.
#отзывы
❤3🤣1
Новый кейс🔥
Помните, я рассказывал вам про кейс диагностики проектного управления в девелоперской компании?
Сегодня делюсь подробностями:
🔹 зачем нужна диагностика проектного управления, если «и так понятно», почему сроки постоянно сдвигаются;
🔹 особенности и сложности реализации девелоперских проектов – от неуправляемого разрастания требований до использования заемных средств;
🔹 почему наш заказчик не мог справиться с постоянными срывами внутренних графиков самостоятельно;
🔹 из чего состоит глубинная диагностика проектного управления и почему для определения первопричин проблем важно привлекать функциональных руководителей в том числе;
🔹 как формировать пул вопросов для интервью и какие методы групповой оценки мы используем; о чем говорит большой разброс мнений при оценке одной и той же области управления;
🔹 какие первопричины проблем мы выявили по результатам интервью и анализа документов;
🔹 что важно учесть при составлении новых требований к проектному управлению, чтобы заказчик мог их реально внедрить, не перегружая операционные процессы компании.
Переходите по ссылке и читайте. Жду ваших комментариев и вопросов🤝
#кейсы
Помните, я рассказывал вам про кейс диагностики проектного управления в девелоперской компании?
Сегодня делюсь подробностями:
🔹 зачем нужна диагностика проектного управления, если «и так понятно», почему сроки постоянно сдвигаются;
🔹 особенности и сложности реализации девелоперских проектов – от неуправляемого разрастания требований до использования заемных средств;
🔹 почему наш заказчик не мог справиться с постоянными срывами внутренних графиков самостоятельно;
🔹 из чего состоит глубинная диагностика проектного управления и почему для определения первопричин проблем важно привлекать функциональных руководителей в том числе;
🔹 как формировать пул вопросов для интервью и какие методы групповой оценки мы используем; о чем говорит большой разброс мнений при оценке одной и той же области управления;
🔹 какие первопричины проблем мы выявили по результатам интервью и анализа документов;
🔹 что важно учесть при составлении новых требований к проектному управлению, чтобы заказчик мог их реально внедрить, не перегружая операционные процессы компании.
Переходите по ссылке и читайте. Жду ваших комментариев и вопросов🤝
#кейсы
🔥2
Формат 1. Сессия Ясности
Разбираем вашу ситуацию и отвечаем на главный вопрос: что мешает ее разрешить и что с этим делать.
Что вы получите в зависимости от запроса:
🚀 рекомендации по целям проектного менеджмента, проектного офиса в вашей организации
🚀 экспресс-оценку проблем и барьеров, с которыми вы сталкиваетесь
🚀 рекомендации по способам решения проблем в проектной деятельности и ближайшим шагам по их устранению
🚀 рекомендации по критериям выбора ИТ-решений по управлению проектами или стратегии их внедрения
🚀 понимание, как вовлечь руководителей в проектную деятельность и преодолеть сопротивление сотрудников организации при внедрении проектной методологии
🚀 мощный импульс к действиям по улучшению своей ситуации и решению затруднений
Формат 2. Методологическая экскурсия
Покажу, как устроена наша методология изнутри, и помогу понять, как может выглядеть ваша.
Вам будет полезна экскурсия, если вы хотите:
🚀 увидеть внутреннюю методологию управления проектами PMLogix
🚀 обсудить её опыт разработки, использования и развития
🚀 увидеть реальную клиентскую методологию (обезличенную) с разбором элементов
🚀 узнать, что нужно сделать, чтобы оценить «идеальность» своей методологи
Кому моя консультация будет полезнее всего?
🔹 Собственникам организаций
🔹 Руководителям проектных офисов и всем, кто занимается построением системы управления проектами и изменениями
🔹 Топ-менеджерам, отвечающим за реализацию портфеля проектов, трансформации или стратегии развития
#отзывы
Чтобы записаться — перейдите в бот PMLogix и заполните небольшую анкету.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤6👍3