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

Про подмену понятий За годы работы я не раз сталкивался с тем, что под проектом понимают что угодно. Но самое частое — презентацию. Приходишь на защиту проекта, а тебе показывают слайды. Красивые. С текстами про «успешный успех» который будет чудесным образом получен в результате проекта. И всё. Ни паспорта, ни календарного плана, ни бюджета, ни реестра рисков. Только презентация и вера в чудо. Самый болезненный момент — когда такую же логику транслируют на некоторых "курсах" по управлению проектами. Слушателям дают задание: «подготовьте проект». И они приносят презентацию. Потому что их так научили. Потому что «проект» в их понимании — это слайды. А где календарный план? Где ресурсы? Где бюджет с оценкой затрат? Где план управления рисками? Где критерии успеха и приёмки результата? Этого нет. Презентация. И вот здесь происходит тихая, но разрушительная вещь: обесценивание проектного управления. Слушатель уходит с курса с мыслью, что проект — это набор красивых слайдов. Что управлять проектом — значит хорошо делать слайды. Что глубокая проработка — это лишнее. А потом такой "специалист" приходит на реальный проект, где нужно считать, планировать, управлять рисками, договариваться с подрядчиками, контролировать бюджет. И оказывается, что презентация здесь дело десятое. Нужна система. Нужно проектное управление. Проект — это не презентация. Это расчёты. Это план. Это работа. Если на "курсе" требуют презентацию вместо проектных документов — это не курс по управлению проектами. Это курс по подготовке слайдов. Называйте вещи своими именами. #УправлениеПроектами #PMO #ПроектноеУправление #ПодменаПонятий

Устав проекта: нужен ли этот документ Работала как-то моя команда над созданием системы управления проектами в одной крупной компании. Мы потратили месяцы на обучение сотрудников: как правильно ставить цели, как распределять ответственность, как определять критерии успеха. Люди вроде научились, начали применять. И вот директор на одном совещании мне говорит: — Александр, давайте обойдёмся без формальностей. Не нужен нам устав проекта. У меня все сотрудники сознательные и уже обученные. Люди взрослые, опытные, зачем лишняя бюрократия? Но вот в чём проблема. Устав проекта — это не формальность. Это фиксация договорённостей. Когда мы «просто обсуждаем» проект на встрече, у каждого участника в голове своя картинка: - Заказчик думает, что на проекте делается одно. - Команда делает другое. - Спонсор думает, что проект займёт три месяца. - А разработчики вообще молчат, но про себя думают: «Это невозможно». Потом выясняется, что цель была «немного другая», сроки «плавали», а ответственность каждый пытается переложить на другого. Устав проекта нужен не потому, что сотрудники несознательные. Он нужен потому, что человеческая память избирательна, а договорённости имеют свойство трактоваться по-разному. Это не бюрократия. Это страховка от: - Разных ожиданий — когда заказчик ждёт одно, а команда делает другое. - Размытой ответственности — когда непонятно, кто за что отвечает. - «Плавающих» критериев успеха — когда в конце проекта выясняется, что «успех» все понимали по-разному. Одна страница с чётко зафиксированными целями, границами, сроками и ответственными может сэкономить месяцы переделок и споров. Сознательные и обученные сотрудники — это прекрасно. Но даже они иногда забывают, о чём договорились. Итак, заказчик просит исключить Устав из обязательных документов проекта. Как вы поступите в этом случае? Варианты: 1. Требование заказчика нужно выполнить. Лишняя бюрократия не нужна. 2. Убедить заказчика, что устав (паспорт) проекта должен быть – это требование стандарта. 3. Свой вариант в комментариях. Обсуждаем в комментариях. #УправлениеПроектами #PMO #УставПроекта #ProjectCharter

Ростех внедрил ИИ-агентов для управления стоимостью и сроками строительства «РТ-Инжиниринг»* перевела оценку стоимости промышленного строительства на ИИ-агентов. От первых тестов до промышленного применения — два месяца. Результаты: Точность автоматизированной оценки — 90% Сроки подготовки — с недель до дней Система работает в защищённом контуре, данные не покидают периметр холдинга Принцип «не додумывать»: если по сложной позиции нет данных, агент не генерирует ответ, а оставляет пробел или указывает аналог с пометкой для ручного расчёта. Это исключает риск некорректных данных — ключевое отличие от «чистого» генеративного ИИ. Экосистема агентов: Агент оценки стоимости — обрабатывает ведомости объёмов работ и материалов, сопоставляя с нормативными расценками. Агент мониторинга — анализирует открытые источники для картины рынка перспективных проектов. Агент проверки КП — сверяет коммерческие предложения с требованиями ТЗ, выявляя расхождения. Ключевой момент: агентам передаются операции с понятным экономическим эффектом. Финальные решения остаются за человеком. Это не замена PM, а инструмент для снятия рутины с понятными правилами. РТ-Инжиниринг — российская инжиниринговая компания, входящая в структуру Госкорпорации Ростех. Она позиционируется как генеральный EPC-подрядчик полного цикла, специализирующийся на строительстве промышленных объектов, в первую очередь в горнорудной и металлургической отраслях. http://elements.rostec.ru/media/news/ii-agenty-rostekha-uskorili-otsenku-stoimosti-stroitelstva-promyshlennykh-obektov-s-nedel-do-dney/#start #УправлениеПроектами #ИИ #Ростех #PMO #Строительство #Автоматизация