Проектная Среда СОВНЕТ
Открыть в Telegram
Рабочий чат профессионального сообщества "Проектная Среда СОВНЕТ" Наш канал в YouTube - https://www.youtube.com/@sovnetipma4774
БольшеСтрана не указанаКатегория не указана
1 021
Подписчики
Нет данных24 часа
Нет данных7 дней
Нет данных30 дней
Архив постов
Гм. Если к "желаемой" дате приурочен вывод продукта на рынок с соответствующими финансовыми результатами и это не проблема... то что тогда проблема?))
Миссия - это предназначение компании помимо зарабатывания прибыли. От неё к портфелю проектов не придешь.
Коллеги, теперь внутри чата у нас есть темы. Обратите внимание на правый верхний угол, там происходит выбор тем
Не знаю точно, как сейчас учат в строительных вузах и готовят ли "средний" уровень управленцев для стройки?!
Кстати, если спросить у профессиональных строителей: чем отличается сетевая модель работы на дугах" от "работы в узлах"? — они смогут ответить и объяснить, что, как и почему нужно применять? И еще, интересно проанализировать ответы разных поколений строителей...
Тут, как говорится: "понимание некоторых принципов может заменить необходимость знания множества фактов"
Опрос явно показывает 2 вещи: PMBOK не рулит и большинство плывут по течению.
Остальное сгладит логика и экономика: если для этого полезно открывать фцк, рцк, учить, автоматизировать, механизировать и т.п. это надо сделать. Но истинная цель производительности ТРУДА (фактора производства) - рост благополучия человека
Наверное, Николай, надо будет собрать их в файлик: "Руководство по подключению на поддерживаемых платформах" ))
Чтобы во всем этом флуде не потерялся основной запрос.
Буду рад сотрудничеству и приглашаю всех желающих выступить с экспертным вебинаром для Молодежного крыла СОВНЕТ - Young Crew Russia
самый радикальный способ - посчитать стоимость 1 дня (1 месяца) строительства и прибыль от работающего производства, после чего определить бонус за сокращение срока
Судя по скриншотам новой версии, которую разрабатывали в (тогда еще) компании Primavera в 2008-м, готовилось серьезное обновление системы по многим параметрам. Но потом на сцене появился Оракул и все пошло в ... другую сторону. ))
Repost from СППУ|сообщество практиков проектного управления
☝️ Коллеги, сегодня последний день опроса. Вечером остановлю голосование.
Кто ещё не успел отметиться сделайте это прямо сейчас 😁
Перейдите по ссылкам и оставьте свой след в истории 👇
https://t.me/CommunityProject/976
https://t.me/CommunityProject/977
https://t.me/CommunityProject/978
https://t.me/CommunityProject/979
https://t.me/CommunityProject/980
https://t.me/CommunityProject/981
https://t.me/CommunityProject/982
В Спайдере изначально закладывалась возможность создания и использования множественных иерархических структур одного проекта. То, что вы на лету переключитесь в другую группировку работ, не даст возможность сравнения и анализа по отношению к базовому графику, в которой такой структуры нет. Так что группировка на лету не заменяет множественных иерархических структур для анализа исполнения проектов. А про процент освоения нужно определиться по какому показателю. Этот показатель обычно нужен для отчета руководству и ни на что более не влияет. Тема сильно второстепенная с точки зрения управления проектами.
Я тоже на курсах обязательно рассказываю о разных нотациях, потому что при переходе от работ на дугах к работам в узлах фактически свершился переход от планирования результатов к планированию процессов. И это важно понимать. Кроме того, я ещё даю практику анализа больших графиков. Одно дело, когда ты делаешь график сам И совсем другое, когда к тебе его принесли на согласование.
непроектные материалы - понятно там куча времени на согласование - некомплект по оборудованию и различные поломки в процессе доставки
Чего я ждал от семинара и не дождался:
1. Разбор 4 методов реагирования на риски в проектах.
2. Разбор взаимосвязи и взаимовлияния рисков проекта: уровни ответственности, риски по направлениям (сроки-стоимость-технологии), связи многие-ко-многим и т.д.
3. Разбор проблем идентификации рисков: открытость, уровень ответственности, безопасность, журналирование и т.д.
4. Разбор проблем формирования реестра и карты рисков: организационные, технические, человеческий фактор и т.д.
5. Разбор количественной оценки рисков и ее взаимосвязи с качественной оценкой.
6. Взаимосвязь реального управления рисками и стандартов (ГОСТ, ИСО и т.п.).
Все пункты 1-6 с примерами из реальных проектов.
Мантры "управление рисками это хорошо и рисками надо управлять" интересны участникам семинара, которые в проектах не работали и книг по УП не читали... наверное.
PS. Большущее спасибо Олегу Мележникову, который попытался перевести обсуждение в практическую плоскость. При этом не теряя связь с методологией риск-менеджмента.
