Проектная Среда СОВНЕТ

В теории все просто: проект сверху-вниз последовательно делим на контролируемые пакеты задач (работ). Останавливаемся когда достигаем детализации, при которой пакет контролируется по единственному измерителю. Затем поднимаемся снизу-вверх, укрупняя задачи по выбранному показателю (вид работ, контракт с подрядчиком и т.п.) и это у нас будет так называемый контрольный счет - за который можно назначить ответственного (менеджер контрольного счета). Что характерно, этот подход работает не только в стройке, но и в других отраслях.

Был в свое время заместителем министра промышленности одного ищ регионов. Вы даже представить себе не можете, "как далеки мы от народа" в части "стратегического проектирования" ..)))

Коллеги, представляем итоги недели в сфере УП с комментариями наших экспертов из Сообщества практиков проектного управления https://sovnet.ru/news/obzor-novostey-za-nedelyu-s-kommentariyami-ekspertov

Мне кажется, что решение задачи: "каким "сложным" оценить проект" будет менее полезна, чем определение инструментария повышения структурированности проекта с доведением [возможно, итерационным или "набегающей волной"] нереализуемого проекта до практической реализации. Об этой тривиальной мысли уже говорилось в части рекомендаций: "упрощайте". Если не можете упростить сейчас, — прорабатывайте то, что можете, и двигайтесь итерационно. PS Если бы план ГОЭЛРО, абсолютно нереализуемый на момент его представления, не стали бы реализовывать, то и мы вряд-ли могли бы собираться на этой "площадке"

Да, я заезжал под вечер пообщаться.

Честно говоря хочется понять, что потом с этим счастьем делать ? Попробуйте ограничить его на основе подобного теста и потом долго будете с трудинспекцией или прокуратурой общаться )))

Коллеги, прошу готовить вопросы к нашим докладчикам на Проектной Среде завтра, пишите прямо здесь. Начинаем, как обычно, в 16:00 по Москве.

Всем добрый день. Мне кажется адекватность и качество модели проекта (представленной в любой форме) опрелеляется не процессами и об'ектами проекта, а наличием анализа какие риски отклонений и изменений они могут порождать, анализа источников и последствий этих рисков и разработанного на основе результатов этого анализа CAPA-плана (Corrective And Preventive Actions). Вот тогда ЛПР и не будет "брошен" в одиночестве ответственности с той кучей показателей, которые мы ему накидали. У него на руках будут готовые, возможные, обоснованные решения, как довести проект до побелы, а не пресловутые никому не нужные NPV, IRR, DPBP и PI

Мои комментарии

Запас нужен, по-любому. Проект- мероприятие уникальное, а раз так, то любая неожиданность не должна выбивать проект из ограничений. Но резервы должны быть экономически обсчитаны и обоснованы. А еще должно быть правило, как их расходовать, иначе их сразу выберут по нашей традиции - осваивать как можно больше… а отчетность правильную сваять - тоже все научены. Таким образом, нужна система балансирующая интересы участников, мотивирующая их на результаты проекта. Тогда и РП будет обсуждать и решать проблемы по мере их прогнозирования, а не по факту невозможности их сокрытия.

Всем, кто хочет красоваться: я приложу все усилия, чтобы этого не допустить. Все эксперты, все профи, выступления тезисные, по паре минут, лекции друг другу читать не нужно.

все графы и прочие "блоки" есть по сути имитационное моделирование, где пытаются смоделировать физику протекания процессов. надо уходить от попыток угадать как будет ))

думаю, для Оксаны более понятно будет такой симбиоз: проектный+процессный подход )) где реализация проекта в целом управляется по проектному подходу, а конкретные типовые "пакеты" работ проекта реализуется в процессной парадигме... здесь проектная суть это триггеры и контроль для подключения процессных кусков (и задание параметров пакета на запуске)... я обычно дерево с ветками рисую для визулизации :)

В этом плане мне интересно было изучать MSF (Microsoft Solutions Framework). В этой методологии основные решения по проекту принимаются "тройкой" - Client manager, Product manager, Chief architect. При этом роль Project manager отсутствует. И, на мой взгляд, это правильно ... хоть и противоречит PM-библиям.

А я думал ESG это департамент устойчивого развития 😀

Я побуду занудой, но приложение 1 и 2 вполне себе отвечают на вопрос - и там корректно используется терминология. Изначально, сетевой график - не инструмент календарного планирования. Можно ли наложить? Да. Гант - не инструмент работы с загрузкой. Можно ли использовать? Да.

⭕️ Был у меня соратник, который обладал интересным качеством - в каждом абзаце текста совершал одну или две орфографических ашибки. ✔️ Впервое время это вызывало бурю эмоций. "Ну тебе что, сложно нажать кнопку проверки орфографии?" ⭕️ Принятие того, что писать иначе он не может и, возможно, даже ценит эту сваю индивидуальность, убрало негативные эмоции. Наоборот, вызывало добрую улыбку и автматическую привычку быстро исправлять за ним текст. ✔️ При этом, у сотрудника была маса положительных качеств, навыков и достоинств. Но время, потраченное на адаптацию к особености было немного конфликтным. ✔️ Навык не влезать в детали неизбежных ошибок на отрезках проекта, а создавать поток с узлами их устраняющими - важнейший руководителя проекта. ✔️ Именно фокуссировка на результате, а не на совершенстве процесса отличает отношение к людям и их ошибкам в проектной деятельности.

Пользуясь скрытной аватаркой, хочу поблагодарить спикеров, организаторов - получилось очень интересно! Отдельное спасибо участникам!