Сегодня предлагаю вам сыграть в игру. Я вам расскажу об одном нашем кейсе, а вы попробуете предположить, в чем настоящая причина проблемы👇
Дано: ИТ-компания средней величины, которая занимается консалтингом в области автоматизации бизнес-процессов. Компания зрелая, давно заняла свою нишу, сотрудники – высококвалифицированные эксперты, работающие здесь много лет. Справляются со своей работой без каких-либо регламентов, все держится на неформальных связях.
Несмотря на то, что у ключевых сотрудников большой опыт и широкий кругозор в области управления проектами, часто проекты все равно завершаются с непредсказуемыми результатами и сроками, а некоторые заказчики остаются недовольными.
Собственнику при этом приходится постоянно быть включенным в проекты, откладывая свои задачи по развитию и масштабированию компании.
❓ Как считаете, в чем здесь может быть проблема?
Почему даже при наличии надежных, профессиональных руководителей не получается достигать целей проектов без постоянного вмешательства собственника?
Ниже для вас я подготовил опрос, а правильный ответ выложу завтра🙂
Дано: ИТ-компания средней величины, которая занимается консалтингом в области автоматизации бизнес-процессов. Компания зрелая, давно заняла свою нишу, сотрудники – высококвалифицированные эксперты, работающие здесь много лет. Справляются со своей работой без каких-либо регламентов, все держится на неформальных связях.
Несмотря на то, что у ключевых сотрудников большой опыт и широкий кругозор в области управления проектами, часто проекты все равно завершаются с непредсказуемыми результатами и сроками, а некоторые заказчики остаются недовольными.
Собственнику при этом приходится постоянно быть включенным в проекты, откладывая свои задачи по развитию и масштабированию компании.
Почему даже при наличии надежных, профессиональных руководителей не получается достигать целей проектов без постоянного вмешательства собственника?
Ниже для вас я подготовил опрос, а правильный ответ выложу завтра🙂
Please open Telegram to view this post
VIEW IN TELEGRAM
Компания мудрее одного человека
Вчера большинство из вас распознало истинную причину проблемы в нашем кейсе👇
Если ваши сотрудники, даже самые опытные профи, ведут проекты исходя из собственного опыта, вы все равно никогда не сможете полностью отдать управление проектами под их ответственность. Потому что любой, даже самый богатый профессиональный бэкграунд руководителя проекта ограничивается его личным опытом, а не опытом компании. Поясню, что это значит.
Например, взаимодействие с заказчиками. С кем-то оно происходит неформально, без фиксации результатов, с устными договоренностями. С кем-то постоянно возникают сложности – то доступы не предоставили, то согласование документов затянули…
А с кем-то требуется максимально бюрократизировать взаимодействие, терпеливо добиваться нужных согласований и предоставлять детальную информацию по проекту.
Все это совершенно разный опыт взаимодействия.
И, получается, что сталкиваясь с разными ситуациями, руководитель проекта ограничивается лишь тем опытом, который есть у него. А если этого опыта не хватает, то он начинает изобретать велосипед. Это дорого для компании.
То же самое можно сказать и о специфике проектов. Когда руководитель переходит с одного проекта на другой, то он может столкнуться со сложностями, которые ранее не встречал в своей практике. Потому что опыты ведения проектов поддержки, внедрения или собственной разработки тоже сильно различаются.
А еще этот регулярный менеджмент…
Опытные руководители проектов не любят заниматься регулярными, нужными вещами, потому что они привыкли держаться фокус на решении конкретных проблемных ситуаций. А не на тех профилактических действиях, которые помогают их предотвратить. Но в итоге… Планы не ведутся, регулярные встречи по проекту превращаются в переписку, а отклонения по проекту эскалируются только тогда, когда заказчик начинает жаловаться и писать официальные письма о расторжении договора.
Когда каждый руководитель проекта действует исходя их собственного опыта, самостоятельно решая, как ему взаимодействовать с заказчиком в каждом конкретном случае, пытаясь найти способы устранения проблемы на проекте и забивая на профилактические действия… Собственнику или руководителю организации приходится постоянно действовать в ручном режиме и контролировать все и всех. Давать обратную связь, следить за удовлетворенностью заказчиков, отправлять руководителя «посмотреть», как они эту проблему решали на другом проекте…
💡 Ваша задача не превратить каждого руководителя проекта в самого опытного, универсального и мудрого управленца (это невозможно). А сделать так, чтобы каждый из них получил дозу дистиллированного опыта компании.
Потому что опыт компании богаче, чем опыт одного человека, и учитывает:
🔹 разновидность проектов в компании и проблем, которые могут на них возникать
🔹 успешные практики и инструменты, которые хорошо работают именно в вашей компании
🔹 специфику компании, отрасли, корпоративной культуры, скорости принятия решений и всего того, что влияет на реализацию проектов, и т.д.
👉 Как минимум это позволит перестать вашим руководителям проектов наступать на одни и те же грабли и постоянно сталкиваться с проблемами, которые уже возникали 1000 раз.
👉 Как максимум – вы будете уверены, что вас не будут дергать по каждому поводу. Потому что эти поводы будут минимизированы. А еще сделаете крепкий фундамент для быстрой эволюции новых сотрудников, которым не нужно будет расти и набираться опыта методом проб и ошибок.
Вчера большинство из вас распознало истинную причину проблемы в нашем кейсе👇
Если ваши сотрудники, даже самые опытные профи, ведут проекты исходя из собственного опыта, вы все равно никогда не сможете полностью отдать управление проектами под их ответственность. Потому что любой, даже самый богатый профессиональный бэкграунд руководителя проекта ограничивается его личным опытом, а не опытом компании. Поясню, что это значит.
Например, взаимодействие с заказчиками. С кем-то оно происходит неформально, без фиксации результатов, с устными договоренностями. С кем-то постоянно возникают сложности – то доступы не предоставили, то согласование документов затянули…
А с кем-то требуется максимально бюрократизировать взаимодействие, терпеливо добиваться нужных согласований и предоставлять детальную информацию по проекту.
Все это совершенно разный опыт взаимодействия.
И, получается, что сталкиваясь с разными ситуациями, руководитель проекта ограничивается лишь тем опытом, который есть у него. А если этого опыта не хватает, то он начинает изобретать велосипед. Это дорого для компании.
То же самое можно сказать и о специфике проектов. Когда руководитель переходит с одного проекта на другой, то он может столкнуться со сложностями, которые ранее не встречал в своей практике. Потому что опыты ведения проектов поддержки, внедрения или собственной разработки тоже сильно различаются.
А еще этот регулярный менеджмент…
Опытные руководители проектов не любят заниматься регулярными, нужными вещами, потому что они привыкли держаться фокус на решении конкретных проблемных ситуаций. А не на тех профилактических действиях, которые помогают их предотвратить. Но в итоге… Планы не ведутся, регулярные встречи по проекту превращаются в переписку, а отклонения по проекту эскалируются только тогда, когда заказчик начинает жаловаться и писать официальные письма о расторжении договора.
Когда каждый руководитель проекта действует исходя их собственного опыта, самостоятельно решая, как ему взаимодействовать с заказчиком в каждом конкретном случае, пытаясь найти способы устранения проблемы на проекте и забивая на профилактические действия… Собственнику или руководителю организации приходится постоянно действовать в ручном режиме и контролировать все и всех. Давать обратную связь, следить за удовлетворенностью заказчиков, отправлять руководителя «посмотреть», как они эту проблему решали на другом проекте…
Потому что опыт компании богаче, чем опыт одного человека, и учитывает:
🔹 разновидность проектов в компании и проблем, которые могут на них возникать
🔹 успешные практики и инструменты, которые хорошо работают именно в вашей компании
🔹 специфику компании, отрасли, корпоративной культуры, скорости принятия решений и всего того, что влияет на реализацию проектов, и т.д.
👉 Как минимум это позволит перестать вашим руководителям проектов наступать на одни и те же грабли и постоянно сталкиваться с проблемами, которые уже возникали 1000 раз.
👉 Как максимум – вы будете уверены, что вас не будут дергать по каждому поводу. Потому что эти поводы будут минимизированы. А еще сделаете крепкий фундамент для быстрой эволюции новых сотрудников, которым не нужно будет расти и набираться опыта методом проб и ошибок.
Please open Telegram to view this post
VIEW IN TELEGRAM
Делегируй-не делегируй, но проверять и принимать решения по проектам все-таки придется. Вопрос только в том – будет ли это легко, быстро и удобно или же долго и мучительно?
Если хотите высвободить свое время, то внедряйте прозрачную, понятную отчетность. Она дает возможность опираться на ДОСТОВЕРНЫЕ данные по проекту и быстро принимать НУЖНЫЕ решения по ВАЖНЫМ вопросам. А именно:
🔹 не тратить время на многочасовые совещания в попытках разобраться, что же на самом деле происходит в проектах
🔹 не погружаться в тяжеловесные презентации от сотрудников и ненужные вам детали, отвлекаясь от важных задач развития
🔹 заранее видеть отклонения на проектах и принимать своевременные меры своего уровня, не доводя ситуацию до критической
🔹 понимать вероятность получения запланированных эффектов с учетом уже полученных результатов
🔹 иметь наглядную картину всего происходящего без постоянного пинания сотрудников
💡 Конечно, отчетность идет в связке с регулярными встречами. Без встреч вы можете не узнать, что какие-то планы проектов нереалистичны, что кто-то кого-то недопонимает, что есть незадокументированные риски. То есть если отчеты показывают вам цифры и факты, то встречи – это способ почувствовать, что происходит в проекте такого, что не умещается в отчеты.
Коллеги, откликается вам эта тема?
Если хотите высвободить свое время, то внедряйте прозрачную, понятную отчетность. Она дает возможность опираться на ДОСТОВЕРНЫЕ данные по проекту и быстро принимать НУЖНЫЕ решения по ВАЖНЫМ вопросам. А именно:
🔹 не тратить время на многочасовые совещания в попытках разобраться, что же на самом деле происходит в проектах
🔹 не погружаться в тяжеловесные презентации от сотрудников и ненужные вам детали, отвлекаясь от важных задач развития
🔹 заранее видеть отклонения на проектах и принимать своевременные меры своего уровня, не доводя ситуацию до критической
🔹 понимать вероятность получения запланированных эффектов с учетом уже полученных результатов
🔹 иметь наглядную картину всего происходящего без постоянного пинания сотрудников
💡 Конечно, отчетность идет в связке с регулярными встречами. Без встреч вы можете не узнать, что какие-то планы проектов нереалистичны, что кто-то кого-то недопонимает, что есть незадокументированные риски. То есть если отчеты показывают вам цифры и факты, то встречи – это способ почувствовать, что происходит в проекте такого, что не умещается в отчеты.
Коллеги, откликается вам эта тема?
Коллеги, делюсь важной и долгожданной новостью🔥
Мы опубликовали один из самых масштабных кейсов в России по настройке и автоматизации процессов управления проектами на Jira.
👉А именно: для 300+ участников проектной деятельности в компании Hoff.
ИСУП должна была закрывать потребности десятка подразделений, участвующих в проектной деятельности:
🔹 топ-менеджменту нужна прозрачная картина о том, в каком состоянии находятся их проекты и продукты, информация об общем статусе по портфелю на текущую дату и прогноз на конец года;
🔹 проектному офису — понимание, какие проекты предложить к запуску в первую очередь в зависимости от стратегии, приоритетов и наличия ресурсов, каковы актуальные статусы и сроки по каждому из проектов;
🔹 ресурсным руководителям – информация о текущих проектах и их сроках, а также о проектах, которые стартуют в ближайшее время, чтобы планировать загрузку ресурсов;
🔹 руководителям проектов – инструменты для отслеживания этапов проектов, сроков и отклонений;
🔹 отделу бюджетирования – информация, как и куда расходуются ресурсы и соответствует ли план факту, и прочее.
За 8 месяцев работы моя команда PMLogix совместно с командой Hoff и Hoff Tech провели масштабную работу, включающую разработку более 20 дашбордов для всех ролей проектной деятельности.
Коллеги, читайте кейс целиком на нашем сайте.
Кстати, 4 года назад я проводил вебинар на эту тему «Как использовать Jira для управления проектами», также советую посмотреть.
#кейсы
Мы опубликовали один из самых масштабных кейсов в России по настройке и автоматизации процессов управления проектами на Jira.
👉А именно: для 300+ участников проектной деятельности в компании Hoff.
ИСУП должна была закрывать потребности десятка подразделений, участвующих в проектной деятельности:
🔹 топ-менеджменту нужна прозрачная картина о том, в каком состоянии находятся их проекты и продукты, информация об общем статусе по портфелю на текущую дату и прогноз на конец года;
🔹 проектному офису — понимание, какие проекты предложить к запуску в первую очередь в зависимости от стратегии, приоритетов и наличия ресурсов, каковы актуальные статусы и сроки по каждому из проектов;
🔹 ресурсным руководителям – информация о текущих проектах и их сроках, а также о проектах, которые стартуют в ближайшее время, чтобы планировать загрузку ресурсов;
🔹 руководителям проектов – инструменты для отслеживания этапов проектов, сроков и отклонений;
🔹 отделу бюджетирования – информация, как и куда расходуются ресурсы и соответствует ли план факту, и прочее.
За 8 месяцев работы моя команда PMLogix совместно с командой Hoff и Hoff Tech провели масштабную работу, включающую разработку более 20 дашбордов для всех ролей проектной деятельности.
Коллеги, читайте кейс целиком на нашем сайте.
Кстати, 4 года назад я проводил вебинар на эту тему «Как использовать Jira для управления проектами», также советую посмотреть.
#кейсы
Что самое важное при делегировании проекта?
Возможность видеть достоверные данные по его прогрессу, чтобы заранее отслеживать негативные тенденции и своевременно принимать нужные решения. Только оперевшись на цифры, которые реально отображают происходящее на проекте, можно избежать пожарных ситуаций и необходимости снова все разруливать самому.
👉 В прошлом году у нас был очень необычный кейс. Перед заказчиком, крупнейшим российским банком, стояла задача реализовыть программу ИТ-трансформации. А именно: перейти с западного ПО на свой собственный продукт, разработку которого необходимо завершить в ближайшие несколько лет.
И вот здесь начинается самое интересное. В разработке, которая ведется по Agile, участвует несколько команд от каждого функционального подразделения банка. А сам продукт – с большим количеством кросс-системных интеграций, искусственным интеллектом и сложной архитектурой, которая должна соответствовать различным бизнес-процессам банка. При этом код частично пишется с нуля. Регулярно возникают дополнительные требования по функционалу и работа превращается в бесконечность без возможности что-либо спрогнозировать.
Занимаясь этим продуктом уже год, разработчики все еще не понимают образ конечного результата, итогового функционала. При этом руководству критически важно отслеживать прогресс по проекту, так как есть ограниченные сроки, которые не получится подвинуть. А прогресс разработчики никак не могут подтвердить – можно довериться только их экспертной оценке.
В итоге ситуация максимально критическая: в продукт уже инвестированы миллиарды рублей, но все еще непонятно, будет ли вообще получен результат в указанные сроки. Риски для заказчика слишком высоки, чтобы полагаться только на честное слово разработчиков.
🔥 Как мы помогли заказчику с этой нетривиальной задачей, организацией контроля и планирования прогресса на проекте в Agile среде, буду делиться в следующих постах. Интересно?
#кейсы
Возможность видеть достоверные данные по его прогрессу, чтобы заранее отслеживать негативные тенденции и своевременно принимать нужные решения. Только оперевшись на цифры, которые реально отображают происходящее на проекте, можно избежать пожарных ситуаций и необходимости снова все разруливать самому.
👉 В прошлом году у нас был очень необычный кейс. Перед заказчиком, крупнейшим российским банком, стояла задача реализовыть программу ИТ-трансформации. А именно: перейти с западного ПО на свой собственный продукт, разработку которого необходимо завершить в ближайшие несколько лет.
И вот здесь начинается самое интересное. В разработке, которая ведется по Agile, участвует несколько команд от каждого функционального подразделения банка. А сам продукт – с большим количеством кросс-системных интеграций, искусственным интеллектом и сложной архитектурой, которая должна соответствовать различным бизнес-процессам банка. При этом код частично пишется с нуля. Регулярно возникают дополнительные требования по функционалу и работа превращается в бесконечность без возможности что-либо спрогнозировать.
Занимаясь этим продуктом уже год, разработчики все еще не понимают образ конечного результата, итогового функционала. При этом руководству критически важно отслеживать прогресс по проекту, так как есть ограниченные сроки, которые не получится подвинуть. А прогресс разработчики никак не могут подтвердить – можно довериться только их экспертной оценке.
В итоге ситуация максимально критическая: в продукт уже инвестированы миллиарды рублей, но все еще непонятно, будет ли вообще получен результат в указанные сроки. Риски для заказчика слишком высоки, чтобы полагаться только на честное слово разработчиков.
🔥 Как мы помогли заказчику с этой нетривиальной задачей, организацией контроля и планирования прогресса на проекте в Agile среде, буду делиться в следующих постах. Интересно?
#кейсы
Как загубить проект в самом начале
Представьте, что вы собираетесь отправиться в длительное путешествие на автомобиле. Вы тщательно проверили машину и заполнили бак топливом. Но по какой-то причине вы решаете не использовать навигатор — например, потому что думаете, что знаете маршрут наизусть или рассчитываете следовать указателям на дороге. Однако именно из-за этого вы тратите много сил и времени на ненужные пути, попадаете в пробки и не приезжаете в нужное время в нужное место. То есть результат вашего путешествия совсем не тот, который вы ожидали.
В управлении проектами подобные ситуации также происходят, когда на начальном этапе вы сформировали неточный, неполный образ результата проекта. Это обычно приводит либо к тому, что сроки проекта сильно сдвигаются из-за бесконечного уточнения требований, либо вовсе к отсутствию нужного, полезного результата внедрения, позволяющего быстро окупить вложенные инвестиции.
💼 Как-то раз я внедрял ERP-систему для производственного предприятия. Одной из главных целей внедрения было выполнение плана производства за счет повышения мотивации работников на выполнение этого самого плана.
Но заказчик подходил к внедрению системы только со стороны функциональности программного продукта, т.е. того, что и как должно работать в будущей системе. И в образе результата была упущена управленческая отчетность – она должна была быть создана уже после завершения основного проекта. То есть по сути было упущено то, ради чего вообще внедряли систему – автоматизированной отчетности с достоверными данными для анализа и принятия нужных управленческих решений.
Когда я разработал и внедрил отчетность по отслеживанию брака, ее сразу же стали применять для повышения качества производства. Директор по производству был в полном восторге, даже несмотря на то, что отчет “считался” несколько часов.
Даже один такой сформированный отчет для отслеживания брака помог компании улучшить и оптимизировать производство. Но если бы создание и внедрение отчетности были бы изначально включены в образ результата от проекта внедрения, компания начала бы получать эффект сразу же, не растягивая разработку и внедрение отчетности еще на пару лет.
Как видите, формирование четкого образа результата проекта помогает намного более реалистично оценивать его трудозатраты и быть уверенными, что внедрение завершится в нужные сроки и вы начнете получать нужный эффект.
Продолжение следует🔥
Представьте, что вы собираетесь отправиться в длительное путешествие на автомобиле. Вы тщательно проверили машину и заполнили бак топливом. Но по какой-то причине вы решаете не использовать навигатор — например, потому что думаете, что знаете маршрут наизусть или рассчитываете следовать указателям на дороге. Однако именно из-за этого вы тратите много сил и времени на ненужные пути, попадаете в пробки и не приезжаете в нужное время в нужное место. То есть результат вашего путешествия совсем не тот, который вы ожидали.
В управлении проектами подобные ситуации также происходят, когда на начальном этапе вы сформировали неточный, неполный образ результата проекта. Это обычно приводит либо к тому, что сроки проекта сильно сдвигаются из-за бесконечного уточнения требований, либо вовсе к отсутствию нужного, полезного результата внедрения, позволяющего быстро окупить вложенные инвестиции.
💼 Как-то раз я внедрял ERP-систему для производственного предприятия. Одной из главных целей внедрения было выполнение плана производства за счет повышения мотивации работников на выполнение этого самого плана.
Но заказчик подходил к внедрению системы только со стороны функциональности программного продукта, т.е. того, что и как должно работать в будущей системе. И в образе результата была упущена управленческая отчетность – она должна была быть создана уже после завершения основного проекта. То есть по сути было упущено то, ради чего вообще внедряли систему – автоматизированной отчетности с достоверными данными для анализа и принятия нужных управленческих решений.
Когда я разработал и внедрил отчетность по отслеживанию брака, ее сразу же стали применять для повышения качества производства. Директор по производству был в полном восторге, даже несмотря на то, что отчет “считался” несколько часов.
Даже один такой сформированный отчет для отслеживания брака помог компании улучшить и оптимизировать производство. Но если бы создание и внедрение отчетности были бы изначально включены в образ результата от проекта внедрения, компания начала бы получать эффект сразу же, не растягивая разработку и внедрение отчетности еще на пару лет.
Как видите, формирование четкого образа результата проекта помогает намного более реалистично оценивать его трудозатраты и быть уверенными, что внедрение завершится в нужные сроки и вы начнете получать нужный эффект.
Продолжение следует🔥
Почему важно вовлекать ключевых сотрудников с самого начала?
Не так давно я делился нашим кейсом по настройке и автоматизации проектного управления на Jira для 300+ участников проектов. Это была большая сложная работа, цель которой – обеспечить прозрачность в управлении проектами и портфелем для всех ролей, от исполнителей до бизнеса.
По сути с помощью создания десятков дашбордов в системе для каждой проектной роли мы выстроили вертикаль от стратегических целей бизнеса до каждого отдельного проекта.
Но самым сложным были не технические настройки, не адаптация системы к нужным бизнес-сценариям и даже не необходимость развертывать очередную фичу в ночное время, пока никто не пользуется системой.
🔧 Самым сложным в этом кейсе был этап формирования требований. Потому что:
🔹 ключевые эксперты, участие которых критически важно, были перегружены, и им было трудно выделить время;
🔹 было важно не только сформировать требования, но и донести до каждого руководителя каждого подразделения, для чего в его область работы добавляются те или иные изменения (необходимость отчитываться по срокам, привязывать реализуемые задачи, списывать трудозатраты и т.д.)
Это, конечно, было не просто, но самое главное – приводило к большому количеству доработок, итераций, и было непонятно, когда мы сможем завершить проект. В итоге, уже ближе к концу, я организовал несколько очных сессий (до этого работа велась онлайн) и путем нескольких итераций с ключевыми руководителями доработали систему.
💡 Главная мысль: когда дело касается большого, сложного, нетипового проекта, практически невозможно с самого начала определить 100% всех требований и четкий образ результата, и это нормально. Потому что понять, что именно нужно и как что должно работать, можно только путем разумного количества итераций в режиме постоянной обратной связи. А это, в свою очередь, возможно только при вовлечении ключевых экспертов (и наличии у них выделенного времени).
👉 Нужная степень вовлечения нужных людей в нужные этапы проекта = снижение риска, что ваш проект растянется на несколько лет. Согласны?
Не так давно я делился нашим кейсом по настройке и автоматизации проектного управления на Jira для 300+ участников проектов. Это была большая сложная работа, цель которой – обеспечить прозрачность в управлении проектами и портфелем для всех ролей, от исполнителей до бизнеса.
По сути с помощью создания десятков дашбордов в системе для каждой проектной роли мы выстроили вертикаль от стратегических целей бизнеса до каждого отдельного проекта.
Но самым сложным были не технические настройки, не адаптация системы к нужным бизнес-сценариям и даже не необходимость развертывать очередную фичу в ночное время, пока никто не пользуется системой.
🔧 Самым сложным в этом кейсе был этап формирования требований. Потому что:
🔹 ключевые эксперты, участие которых критически важно, были перегружены, и им было трудно выделить время;
🔹 было важно не только сформировать требования, но и донести до каждого руководителя каждого подразделения, для чего в его область работы добавляются те или иные изменения (необходимость отчитываться по срокам, привязывать реализуемые задачи, списывать трудозатраты и т.д.)
Это, конечно, было не просто, но самое главное – приводило к большому количеству доработок, итераций, и было непонятно, когда мы сможем завершить проект. В итоге, уже ближе к концу, я организовал несколько очных сессий (до этого работа велась онлайн) и путем нескольких итераций с ключевыми руководителями доработали систему.
💡 Главная мысль: когда дело касается большого, сложного, нетипового проекта, практически невозможно с самого начала определить 100% всех требований и четкий образ результата, и это нормально. Потому что понять, что именно нужно и как что должно работать, можно только путем разумного количества итераций в режиме постоянной обратной связи. А это, в свою очередь, возможно только при вовлечении ключевых экспертов (и наличии у них выделенного времени).
👉 Нужная степень вовлечения нужных людей в нужные этапы проекта = снижение риска, что ваш проект растянется на несколько лет. Согласны?
Мы с Юрием Проскурней, как авторы собственных фреймворков по управлению проектами и изменениями, решили собраться и поговорить на эту злободневную тему.
А именно:
Будет интересно! Скоро поделимся записью подкаста.
У Юрия, кстати, есть телеграм канал, где он делится полезными материалами на тему управления изменений, поэтому советую на него подписаться🤝
Please open Telegram to view this post
VIEW IN TELEGRAM
Главное успеть поздравить и пожелать...
... себе на День рождения:
- Энергии и здоровья, чтобы руки не опускались, когда так хочется сдаться или отложить на завтра
- Непреклонности - доводить классные идеи до реализации, а не лелеять в голове и не бросать на полпути
- Ценить, беречь и заботиться о близких, дорожить отношениями
- Найти девушку, с которой мы сможем создать и разделить яркие моменты жизни
- Смелости - делать новое, непривычное, страшное
- Мудрости - заниматься только тем, на что могу повлиять
- Решительности - действовать, а не тонуть в анализе альтернатив
- Масштаба - думать о том, как изменить мир, а не просто срубить бабла
- Сфокусированности - не распылятся, не браться сразу за много дел
- Терпения - не дергаться, если сразу не получилось
- Принципиальности - делать только то, что соответствует принципам, не идти на сделку с совестью
- Счастья - ценить самые простые моменты, когда ешь вкусную еду, вдыхаешь свежий воздух, общаешься с приятными людьми.
И этого более чем достаточно 😅
... себе на День рождения:
- Энергии и здоровья, чтобы руки не опускались, когда так хочется сдаться или отложить на завтра
- Непреклонности - доводить классные идеи до реализации, а не лелеять в голове и не бросать на полпути
- Ценить, беречь и заботиться о близких, дорожить отношениями
- Найти девушку, с которой мы сможем создать и разделить яркие моменты жизни
- Смелости - делать новое, непривычное, страшное
- Мудрости - заниматься только тем, на что могу повлиять
- Решительности - действовать, а не тонуть в анализе альтернатив
- Масштаба - думать о том, как изменить мир, а не просто срубить бабла
- Сфокусированности - не распылятся, не браться сразу за много дел
- Терпения - не дергаться, если сразу не получилось
- Принципиальности - делать только то, что соответствует принципам, не идти на сделку с совестью
- Счастья - ценить самые простые моменты, когда ешь вкусную еду, вдыхаешь свежий воздух, общаешься с приятными людьми.
И этого более чем достаточно 😅
🔹 Пирамида Маслоу – фреймворк или методология?
🔹 Где заканчивается фреймворк и начинается методология?
🔹 Является ли жизненный цикл проекта самодостаточным фреймворком для управления?
🔹 Почему Agile-манифест это не фреймворк?
🔹 Как использование фреймворка помогает бизнесу вести проектную деятельность и внедрять изменения, а в каких случаях он вредит?
🔹 Ламборгини или Феррари? Или почему не надо сравнивать проектный, продуктовый и чендж-менеджмент.
💥Эти и другие темы обсудили в нашем подкасте с Юрием Проскурней. Что такое фреймворки управления проектами и изменениями, чем они отличаются от методологий и для чего они нужны бизнесу – смотрите на Youtube и в ВК видео.
Спасибо Юрию за интересную беседу🤝
#подкасты
🔹 Где заканчивается фреймворк и начинается методология?
🔹 Является ли жизненный цикл проекта самодостаточным фреймворком для управления?
🔹 Почему Agile-манифест это не фреймворк?
🔹 Как использование фреймворка помогает бизнесу вести проектную деятельность и внедрять изменения, а в каких случаях он вредит?
🔹 Ламборгини или Феррари? Или почему не надо сравнивать проектный, продуктовый и чендж-менеджмент.
💥Эти и другие темы обсудили в нашем подкасте с Юрием Проскурней. Что такое фреймворки управления проектами и изменениями, чем они отличаются от методологий и для чего они нужны бизнесу – смотрите на Youtube и в ВК видео.
Спасибо Юрию за интересную беседу🤝
#подкасты
🔥 Коллеги, если вы тоже любите цифры и исследования, то рекомендую канал Дмитрия Ирешева.
Дима – руководитель проектного офиса 5 Post, автор статей и временами спикер на тему проектного и продуктового управления.
Ели вы любите интересные факты, статьи, книги и новости, тогда вы точно найдете, что почитать на этом канале.
Ниже делюсь материалами, которые мне понравились:
🔹 Свежие слухи о PMBOK8
🔹 Каждый десятый разработчик в ИТ-гигантах не работает
🔹 Сотрудники мультимиллионеры NVIDIA
🔹Эволюция Доверия - бесплатная онлайн игра
🔹 Подборка нейронок на все случая жизни
P.S. А еще на канале Димы есть ссылки на полезные в работе (и не только) нейронки👍
Дима – руководитель проектного офиса 5 Post, автор статей и временами спикер на тему проектного и продуктового управления.
Ели вы любите интересные факты, статьи, книги и новости, тогда вы точно найдете, что почитать на этом канале.
Ниже делюсь материалами, которые мне понравились:
🔹 Свежие слухи о PMBOK8
🔹 Каждый десятый разработчик в ИТ-гигантах не работает
🔹 Сотрудники мультимиллионеры NVIDIA
🔹Эволюция Доверия - бесплатная онлайн игра
🔹 Подборка нейронок на все случая жизни
P.S. А еще на канале Димы есть ссылки на полезные в работе (и не только) нейронки👍
Про безответственность и игру в молчанку🫢
Знакома ли вам ситуация, когда из-за того, что вы не можете положиться на своих сотрудников, вам приходится все постоянно контролировать, а то и самому делать работу за них? Ведь без вашего участия точно что-то пойдет не так, и это "что-то" окажется для вас большим сюрпризом.
Так почему вы узнаете о проблемах последним? По какой причине ваши сотрудники не предупреждают вас о рисках, чтобы заранее принять нужные меры? Что это – безответственность или вопиющая некомпетентность?
💡Одна из причин такого поведения – нежелание говорить правду, и вот, почему:
👉 в вашей организации может процветать политика замалчивания, и сотрудники просто боятся говорить о проблемах. Боятся, что их сделают крайними и "повесят" еще десяток задач сверху для разруливания ситуации.
Поэтому наблюдая за тем, как проект улетает в пропасть и приближается неминуемая "жопа", они будут надеяться, что справятся сами.
👉 ваши сотрудники могут не понимать планки (требований) в управлении проектами, к которой нужно стремиться.
Например, считать, что вести календарный план необязательно, ведь все сроки прописаны в договоре с подрядчиком, а отставание проекта на 1-2 месяца от планового срока из-за задержки в готовности кросс-системных интеграций – это норма и "так всегда". Потому что они ориентируются только на предыдущий опыт в реализации подобных проектов. И если по их мнению все норм, зачем лишний раз светиться перед руководителем?
👉 ваши сотрудники могли изначально подписаться под заведомо нереалистичными планами проекта, поэтому любое отклонение – также норма.
В одном из наших кейсов у заказчика, крупной девелопреской компании, была похожа проблема: чтобы подстраховаться и соблюсти внешние сроки сдачи объекта в эксплуатацию, создавался внутренний план с большим сдвигом влево. Под этим планом все подписывались, но никто в него не верил и даже не старался выполнить. В итоге все молча отставали, не предупреждая о невозможности выполнить план, ведь "это и так понятно".
Страх остаться виноватыми, непонимание требований к качеству управления и нереалистичные планы – то, почему вам могут не говорить всей правды о происходящем на проекте.
К каким последствиям приводит эта игра в молчанку? Буду разбирать в следующем посте🔥
Знакома ли вам ситуация, когда из-за того, что вы не можете положиться на своих сотрудников, вам приходится все постоянно контролировать, а то и самому делать работу за них? Ведь без вашего участия точно что-то пойдет не так, и это "что-то" окажется для вас большим сюрпризом.
Так почему вы узнаете о проблемах последним? По какой причине ваши сотрудники не предупреждают вас о рисках, чтобы заранее принять нужные меры? Что это – безответственность или вопиющая некомпетентность?
💡Одна из причин такого поведения – нежелание говорить правду, и вот, почему:
👉 в вашей организации может процветать политика замалчивания, и сотрудники просто боятся говорить о проблемах. Боятся, что их сделают крайними и "повесят" еще десяток задач сверху для разруливания ситуации.
Поэтому наблюдая за тем, как проект улетает в пропасть и приближается неминуемая "жопа", они будут надеяться, что справятся сами.
👉 ваши сотрудники могут не понимать планки (требований) в управлении проектами, к которой нужно стремиться.
Например, считать, что вести календарный план необязательно, ведь все сроки прописаны в договоре с подрядчиком, а отставание проекта на 1-2 месяца от планового срока из-за задержки в готовности кросс-системных интеграций – это норма и "так всегда". Потому что они ориентируются только на предыдущий опыт в реализации подобных проектов. И если по их мнению все норм, зачем лишний раз светиться перед руководителем?
👉 ваши сотрудники могли изначально подписаться под заведомо нереалистичными планами проекта, поэтому любое отклонение – также норма.
В одном из наших кейсов у заказчика, крупной девелопреской компании, была похожа проблема: чтобы подстраховаться и соблюсти внешние сроки сдачи объекта в эксплуатацию, создавался внутренний план с большим сдвигом влево. Под этим планом все подписывались, но никто в него не верил и даже не старался выполнить. В итоге все молча отставали, не предупреждая о невозможности выполнить план, ведь "это и так понятно".
Страх остаться виноватыми, непонимание требований к качеству управления и нереалистичные планы – то, почему вам могут не говорить всей правды о происходящем на проекте.
К каким последствиям приводит эта игра в молчанку? Буду разбирать в следующем посте🔥
Быть костылем для команды, а не руководителем
В прошлом посте я писал, почему ваши сотрудники могут скрывать правду о происходящем на проектах. И когда такое случается, очевидно, что положиться на них трудно – вам приходится не только все перепроверять, но и тратить свое время на то, чтобы каждому объяснить, что и как нужно делать.
В итоге руководитель превращается в костыль для команды, без которого рабочие процессы начинают буксовать. Он постоянно поддерживает сотрудников, берет на себя чужие задачи и разруливает все вручную:
👉 объясняет, как общаться с заказчиком проекта, как предотвратить и уладить конфликт;
👉 договаривается с руководителями других подразделений о выделении ресурсов;
👉 напоминает, что ведение календарного плана — это требование, а не прихоть;
👉 следит, чтобы о нехватке людей или слабом составе команды сообщали заранее, а не когда уже все сроки сорваны;
👉 сам пишет требования и разрабатывает архитектуру, когда дело касается внедрения новой сложной системы.
Может казаться, что при таком положении дел ситуация под контролем, но на самом деле это ловушка, которая:
❌ лишает руководителя времени на выполнение задач его уровня: формирование планов развития, разработку новой продуктовой линейки, внедрение инноваций в процессы, изменение системы мотивации и т.д
❌ делает его узким местом
❌ ограничивает возможность реализации масштабных изменений и, как следствие, развитие компании
Что делать? Отправить сотрудников на обучение или заменить на других, найти новых – более профессиональных и опытных?
Однако это чаще всего слабое решение проблемы. Даже при наличии крутых сотрудников есть свои риски, и в следующем посте поговорим, какие именно.
В прошлом посте я писал, почему ваши сотрудники могут скрывать правду о происходящем на проектах. И когда такое случается, очевидно, что положиться на них трудно – вам приходится не только все перепроверять, но и тратить свое время на то, чтобы каждому объяснить, что и как нужно делать.
В итоге руководитель превращается в костыль для команды, без которого рабочие процессы начинают буксовать. Он постоянно поддерживает сотрудников, берет на себя чужие задачи и разруливает все вручную:
👉 объясняет, как общаться с заказчиком проекта, как предотвратить и уладить конфликт;
👉 договаривается с руководителями других подразделений о выделении ресурсов;
👉 напоминает, что ведение календарного плана — это требование, а не прихоть;
👉 следит, чтобы о нехватке людей или слабом составе команды сообщали заранее, а не когда уже все сроки сорваны;
👉 сам пишет требования и разрабатывает архитектуру, когда дело касается внедрения новой сложной системы.
Может казаться, что при таком положении дел ситуация под контролем, но на самом деле это ловушка, которая:
❌ лишает руководителя времени на выполнение задач его уровня: формирование планов развития, разработку новой продуктовой линейки, внедрение инноваций в процессы, изменение системы мотивации и т.д
❌ делает его узким местом
❌ ограничивает возможность реализации масштабных изменений и, как следствие, развитие компании
Что делать? Отправить сотрудников на обучение или заменить на других, найти новых – более профессиональных и опытных?
Однако это чаще всего слабое решение проблемы. Даже при наличии крутых сотрудников есть свои риски, и в следующем посте поговорим, какие именно.
Худший менеджер в компании
Продолжаю тему предыдущего поста – когда руководитель берет на себя чужую работу, часто он не может делать ее качественно. И выполняя роль рядового проектного менеджера, он становится… худшим проектным менеджером в компании. Почему?
👉 Во-первых, руководитель не может и не должен владеть всеми знаниями, последними технологиями и инструментами для ведения проекта. И часто, вмешиваясь в ход проекта, чтобы понять, что там происходит, он может предлагать не самые эффективные решения.
👉 Во-вторых, ему вообще все это неинтересно. Ему хочется заниматься “своими” делами, развитием, внедрением инноваций в процессы, но приходится делать не свою работу – через силу, с единственной мотивацией “если я не сделаю, то никто не сделает”.
👉 В-третьих, когда ежедневно приходится вникать в десятки задач разного уровня – от написания технических требований к внедряемой системе до разработки стратегии нового направления бизнеса… Фокус внимания размывается и страдает качество выполнения всех его задач.
💡 А еще, так как он не обладает полной картиной происходящего на проектах и в силу ограниченности времени, он становится чайкой-менеджером: неожиданно прилетает, наводит много шума и улетает. Он хочет все быстро порешать и часто может предлагать варианты действий, с которыми никто не согласен, но и спорить тоже не хочет. В итоге команда остается в полном параличе без способности делать что-либо самостоятельно и организованно.
Вот, что происходит, когда мы, как руководители организаций, занимаемся задачами не своего уровня, потому что нам не на кого положиться.
Но даже если в вашей компании есть надежные люди, это еще не значит, что вы сможете легко выбраться из ловушки микроменеджмента. Продолжим эту тему завтра👍
Продолжаю тему предыдущего поста – когда руководитель берет на себя чужую работу, часто он не может делать ее качественно. И выполняя роль рядового проектного менеджера, он становится… худшим проектным менеджером в компании. Почему?
👉 Во-первых, руководитель не может и не должен владеть всеми знаниями, последними технологиями и инструментами для ведения проекта. И часто, вмешиваясь в ход проекта, чтобы понять, что там происходит, он может предлагать не самые эффективные решения.
👉 Во-вторых, ему вообще все это неинтересно. Ему хочется заниматься “своими” делами, развитием, внедрением инноваций в процессы, но приходится делать не свою работу – через силу, с единственной мотивацией “если я не сделаю, то никто не сделает”.
👉 В-третьих, когда ежедневно приходится вникать в десятки задач разного уровня – от написания технических требований к внедряемой системе до разработки стратегии нового направления бизнеса… Фокус внимания размывается и страдает качество выполнения всех его задач.
💡 А еще, так как он не обладает полной картиной происходящего на проектах и в силу ограниченности времени, он становится чайкой-менеджером: неожиданно прилетает, наводит много шума и улетает. Он хочет все быстро порешать и часто может предлагать варианты действий, с которыми никто не согласен, но и спорить тоже не хочет. В итоге команда остается в полном параличе без способности делать что-либо самостоятельно и организованно.
Вот, что происходит, когда мы, как руководители организаций, занимаемся задачами не своего уровня, потому что нам не на кого положиться.
Но даже если в вашей компании есть надежные люди, это еще не значит, что вы сможете легко выбраться из ловушки микроменеджмента. Продолжим эту тему завтра👍
Сильные сотрудники – не повод расслабляться
Если вашим сотрудникам постоянно приходится объяснять, что и как надо делать, вы всегда будете по уши в текущих проектах.
Но даже если у вас работает несколько надежных, опытных, профессиональных сотрудников, которые не нуждаются в контроле... Вы все равно будете по уши в текущих проектах 🤡
Не так давно ко мне обратился заказчик с проблемой: "Я не могу делать столько проектов, сколько нужно для роста компании, потому что все завязано на мне и трех ключевых руководителях проектов."
При этом у компании:
✔ Достаточно отраслевой экспертизы
✔ 20 лет на рынке и огромный опыт
✔ Десятки успешных кейсов
Но:
🚩 Ключевые руководители уже перегружены. Они ведут по 2-3 проекта одновременно и физически не могут взять больше.
🚩 Каждый действует по-своему, опираясь на свой опыт и ожидания заказчика. Когда все знания только в голове у нескольких экспертов, то передать их новым сотрудникам очень сложно, и процесс натаскивания может растянуться на годы.
🚩 Генеральный директор боится потерять контроль. Он понимает, что бизнес зависит от нескольких людей, и вынужден глубоко погружаться в детали идущих проектов, опасаясь, что кто-то уйдет.
В итоге: старички не могут вывезти все, новички не тянут без помощи старших коллег и долго входят в курс дела, а руководство продолжает тонуть в операционке.
Что мы сделали в этом кейсе, как помогли руководству выбраться из ловушки микроменеджмента, а также с чего начинается переход на новый уровень в делегировании сложных задач и проектов – расскажу в статье, которая выйдет уже на этой неделе.
Если вашим сотрудникам постоянно приходится объяснять, что и как надо делать, вы всегда будете по уши в текущих проектах.
Но даже если у вас работает несколько надежных, опытных, профессиональных сотрудников, которые не нуждаются в контроле... Вы все равно будете по уши в текущих проектах 🤡
Не так давно ко мне обратился заказчик с проблемой: "Я не могу делать столько проектов, сколько нужно для роста компании, потому что все завязано на мне и трех ключевых руководителях проектов."
При этом у компании:
✔ Достаточно отраслевой экспертизы
✔ 20 лет на рынке и огромный опыт
✔ Десятки успешных кейсов
Но:
🚩 Ключевые руководители уже перегружены. Они ведут по 2-3 проекта одновременно и физически не могут взять больше.
🚩 Каждый действует по-своему, опираясь на свой опыт и ожидания заказчика. Когда все знания только в голове у нескольких экспертов, то передать их новым сотрудникам очень сложно, и процесс натаскивания может растянуться на годы.
🚩 Генеральный директор боится потерять контроль. Он понимает, что бизнес зависит от нескольких людей, и вынужден глубоко погружаться в детали идущих проектов, опасаясь, что кто-то уйдет.
В итоге: старички не могут вывезти все, новички не тянут без помощи старших коллег и долго входят в курс дела, а руководство продолжает тонуть в операционке.
Что мы сделали в этом кейсе, как помогли руководству выбраться из ловушки микроменеджмента, а также с чего начинается переход на новый уровень в делегировании сложных задач и проектов – расскажу в статье, которая выйдет уже на этой неделе.
Единственный способ вылезти из ловушки микроменеджмента и запустить автопилот
Все верят, что если найти правильных людей или правильно обучить действующих сотрудников, то вопрос менеджмента, делегирования сложных задач и проектов будет закрыт навсегда. Что можно сбросить груз постоянного контроля на пару надежных руководителей и, как минимум, высвободить время для решения задач своего уровня, а, как максимум, начать больше уделять времени семье или личному развитию.
Но это так не работает и никогда не заработает.
Суровая правда жизни такова, что пока не будут созданы нужные условия, вы, как руководитель организации, будете продолжать все вывозить на себе и делать работу не своего уровня.
В этой статье рассказываю о единственном работающем способе, как выбраться из ловушки микроменджмента и какие шаги на примере одного кейса вы можете предпринять уже сейчас.
Все верят, что если найти правильных людей или правильно обучить действующих сотрудников, то вопрос менеджмента, делегирования сложных задач и проектов будет закрыт навсегда. Что можно сбросить груз постоянного контроля на пару надежных руководителей и, как минимум, высвободить время для решения задач своего уровня, а, как максимум, начать больше уделять времени семье или личному развитию.
Но это так не работает и никогда не заработает.
Суровая правда жизни такова, что пока не будут созданы нужные условия, вы, как руководитель организации, будете продолжать все вывозить на себе и делать работу не своего уровня.
В этой статье рассказываю о единственном работающем способе, как выбраться из ловушки микроменджмента и какие шаги на примере одного кейса вы можете предпринять уже сейчас.
Да не работают эти ваши правила управления😡
Действительно, вы и сами наверняка видели такое не раз во многих организациях – придумали и внедрили какие-то новые правила, шаблоны, документы… Сказали – а теперь, Ваня, заполняй наш новый реестр рисков и все будет хорошо.
Ваня, конечно, пару раз заполнил для вида, но… Надолго его не хватило. Потому что ему надо заниматься реальными делами, спасать проект, искать ресурсы, заниматься интеграциями, а не этой бесполезной возней с бумажками.
💡 Ваши новые правила управления проектами никогда не заработают и вы никогда не сможете слезть с ручного управления, пока вы мыслите категориями требований. Пока вы требуете заполнения каких-то форм, которые надо заполнить. Кому надо? Зачем надо?
Во вчерашней статье я затронул такое понятие, как аспект. Наша задача не просто определить важные области управления и инструменты для их контроля, но и договориться о них как на уровне менеджмента, так и на уровне исполнителей.
Например, в рассматриваемом кейсе из статьи аспект сохранения и передачи экспертизы важен прежде всего для менеджмента, но не для команды. И если команда не будет понимать, почему важно заполнять все эти бумажки, реестры для передачи знаний от более старших коллег новичкам, как это поможет лично им в работе и как повлияет на успешность их проектов в будущем, никто не будет этого делать.
Договариваясь об аспектах на уровне руководства и сотрудников, мы договариваемся о том, что для нас действительно важно, что мы не придумываем какие-то правила только ради правил (таких регламентов полно в любой организации). Их необходимость железобетонно обоснована, это не прихоть руководства и не бестолковая бюрократия.
❗️Что еще нужно учитывать: правила управления должны стать единой системой, живым организмом, который может развиваться вместе с организацией. В такой системе все элементы связаны друг с другом. Если у нас есть артефакт, значит должно быть событие, где он используется или создается. Если мы убираем артефакт, то должны проверить, а сможем ли мы без него уделять должное внимание выбранному аспекту и при этом не нарваться на риски.
Например, если мы формируем календарный план проекта, то мы используем его во время обсуждения на встречах. Если его убрать, то сможем ли мы без него обсудить состояние проекта, отклонения, зависимости, текущий прогресс? Сможем ли мы уделять достаточное внимание срокам проекта?
Когда есть целостная система из взаимосвязанных элементов, то мы всегда можем что-то убрать и добавить более релевантное потребностям организации.
Но когда у нас есть просто статичная конструкция из правил, рано или поздно некоторые из них устареют (обычно за 1-3 года), и, если их не изменить, то они будут снова восприниматься как бюрократия.
Единые правила управления проектами – это договоренности, чему мы уделяем внимание (аспекты) и с помощью чего мы это делаем (артефакты и события). А также когда и с какой регулярностью мы это делаем и кто отвечает за их выполнение.
Правила важны, но не менее важен процесс, в рамках которого они создавались. Согласны?
Действительно, вы и сами наверняка видели такое не раз во многих организациях – придумали и внедрили какие-то новые правила, шаблоны, документы… Сказали – а теперь, Ваня, заполняй наш новый реестр рисков и все будет хорошо.
Ваня, конечно, пару раз заполнил для вида, но… Надолго его не хватило. Потому что ему надо заниматься реальными делами, спасать проект, искать ресурсы, заниматься интеграциями, а не этой бесполезной возней с бумажками.
💡 Ваши новые правила управления проектами никогда не заработают и вы никогда не сможете слезть с ручного управления, пока вы мыслите категориями требований. Пока вы требуете заполнения каких-то форм, которые надо заполнить. Кому надо? Зачем надо?
Во вчерашней статье я затронул такое понятие, как аспект. Наша задача не просто определить важные области управления и инструменты для их контроля, но и договориться о них как на уровне менеджмента, так и на уровне исполнителей.
Например, в рассматриваемом кейсе из статьи аспект сохранения и передачи экспертизы важен прежде всего для менеджмента, но не для команды. И если команда не будет понимать, почему важно заполнять все эти бумажки, реестры для передачи знаний от более старших коллег новичкам, как это поможет лично им в работе и как повлияет на успешность их проектов в будущем, никто не будет этого делать.
Договариваясь об аспектах на уровне руководства и сотрудников, мы договариваемся о том, что для нас действительно важно, что мы не придумываем какие-то правила только ради правил (таких регламентов полно в любой организации). Их необходимость железобетонно обоснована, это не прихоть руководства и не бестолковая бюрократия.
❗️Что еще нужно учитывать: правила управления должны стать единой системой, живым организмом, который может развиваться вместе с организацией. В такой системе все элементы связаны друг с другом. Если у нас есть артефакт, значит должно быть событие, где он используется или создается. Если мы убираем артефакт, то должны проверить, а сможем ли мы без него уделять должное внимание выбранному аспекту и при этом не нарваться на риски.
Например, если мы формируем календарный план проекта, то мы используем его во время обсуждения на встречах. Если его убрать, то сможем ли мы без него обсудить состояние проекта, отклонения, зависимости, текущий прогресс? Сможем ли мы уделять достаточное внимание срокам проекта?
Когда есть целостная система из взаимосвязанных элементов, то мы всегда можем что-то убрать и добавить более релевантное потребностям организации.
Но когда у нас есть просто статичная конструкция из правил, рано или поздно некоторые из них устареют (обычно за 1-3 года), и, если их не изменить, то они будут снова восприниматься как бюрократия.
Единые правила управления проектами – это договоренности, чему мы уделяем внимание (аспекты) и с помощью чего мы это делаем (артефакты и события). А также когда и с какой регулярностью мы это делаем и кто отвечает за их выполнение.
Правила важны, но не менее важен процесс, в рамках которого они создавались. Согласны?
This media is not supported in your browser
VIEW IN TELEGRAM
Когда в компании нет единых правил управления проектами и тебя дергают 24/7…