Pull to refresh
8K+
0
Андрей Малахов@PMLogix

Управление проектами и изменениями PMLogix

3
Rating
11
Subscribers
Send message

ИТ-проект это ИТ-проект. А вот когда изменение 50-70% ИТ ландшафта это уже серьезная трансформация, затрагивающая бизнес. Конечно, бывают и другие трансформации (культуры, бизнес-модели, операционной модели, ИИ...)

Да, вот здесь можете почитать подробнее https://habr.com/ru/articles/988194/

Ну и в первом примере – там была замена 8 ключевых ИТ-систем.

А эти критерии под любой тип трансформации. Примеры, что описал выше, – первое, что пришло в голову.

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

Из личного опыта могу привести два примера (без конкретики):

1. IT-трансформация в крупном логистическом провайдере. По сути, замена IT-ландшафта и инфраструктуры – достаточно масштабное и именно трансформационное изменение. В самом начале управление было организовано не идеально, но в процессе многие моменты довольно быстро были скорректированы и учтены. Если интересно, могу прислать подробный кейс.

2. Программа замены автоматизированной банковской системы. Здесь сценарий был другой: программа сначала попала в кризис – уехала по срокам примерно на полтора года. И именно после этого, благодаря качественной перестройке управления – включая внимание первого лица и другие пункты из статьи – ситуацию удалось полностью развернуть.

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

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

Сначала подумал, что "конгениально" – это хейт, а потом загуглил, и оказалось, что нет! Спасибо!

Предложенная вами интерпретация неточна. С нашей помощью в управлении (имхо странно весь менеджмент сводить к "вагону бумаги") клиент все успешно и главное вовремя импортозаместил, при этом не имея профессиональных РП и проектного офиса в штатной структуре, ну конечно же заслуга в успехе не только нас, но и самого клиента и ИТ-интеграторов отдельных систем. Мы выступили в виде "клея", которых из отдельных частных не всегда точно согласованных решений помог руководителю программы собрать полную картинку и своевременно решить найденные проблемы и предотврать риски.

Судя по тому, что ты описываешь, у вас не было ПМ. У вас были котята с улицы, которые до этого работали в общепите/доставке/маркетплейсах/любомместедлястудентов.

Вывод не имеет отношения к реальности, был РП с опытом в пару лет, до этого были более опытные РП.

Решения, который ты принимал, не являются уникальными, а являются базовыми для ПМ. То есть, твой уровень принятия решений находится на стандартном для ПМ уровне. Понимаешь идею?

Уникальные решения в менеджменте требуются не так часто. Решение управленческих задач в принципе лежат не в категории "удиви меня", а в категории - как решить проблему так, чтобы она была решенной. Я более 20 лет успешно занимаюсь менеджментом в роли руководителя и консультированием по менеджменту (своя консалтинговая практика 10 лет).

Я не представляю, как вы определили, что решения являются "базовыми для ПМ". Что это за база? Где она описана? Просьба дать ссылки на конкретные источники, а не на свой "здравый смысл". На всякий случай подчеркну, что я много лет в ведущих вузах типа ВШЭ, РАНХиГС и т.д. провожу тренинги по управлению проектами.

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

И если предыдущие котята не спасли проекты, то это не их вина, действительно.

Вина не котят, а тех, кто тебя и их нанял. Эти наниматели абсолютно не понимают, что такое менеджмент, и как управлять проектами. Отсюда и проблемы с наймом ПМов - ты не умеешь управлять, как ты поймешь, что перед тобой хороший управляющий?

Они бизнесом занимаются, не их задача детально понимать в менеджменте.

Статья действительно про самонахваливание, как написали выше, потому что вы сравниваете свою работу с людьми, которые не умеют в менеджмент. Это все равно, что я сейчас скажу, что я уже 30 лет абсолютный чемпион в яслях по тхеквондо. С одного удара всех выношу =) Ну или если бы я начал себя сравнивать с джунами-программистами и говорить, что я крут, а они - нет.

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

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

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

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

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

Рад, что понравилось! Уверен, что в ваших проектах с менеджментом все прекрасно. Но если есть сомнения, зовите, помогу найди области для улучшений)

Он и управлял проектом как понимал это дело. Не самый плохой проджект, как и предыдущие, кстати.

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

Все было, как и почти везде бывает, но не работало как надо. Сделали, чтобы работало!

Да, такое бывает редко, но иногда все же косвенно признают ошибки через усилия по исправлению. Тоже не плохо, я считаю.

Лучше даже не "продавать", а сделать так, чтобы толковые идеи пришли им на ум сами, но с нашей помощью. Так и закрепляются, и работают!

Да без внутренней мотивации никуда. Вопрос только в том, на что мотивация - что-то узнать или просто отдохнуть.

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

Это мой клиент сомневается в квалификации своих РП и обратился ко мне за помощью. Остальное просто смелые, но необоснованные догадки). А как бы вы оценили квалификацию РП, если есть чем дополнить мои способы?

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

Information

Rating
1,284-th
Registered
Activity

Specialization

Директор проекта
Ведущий
Управление проектами
Управление бизнес-процессами
Стратегическое управление
Развитие бизнеса
Организация бизнес-процессов
Управление людьми
Построение команды
Стратегическое планирование
Автоматизация процессов
Оптимизация бизнес-процессов