Механизм планирования и интеграции с учетом набегающей волны

[Name_V]

Всем добрый день!

Думаю все сталкивались с тем, что составив декомпозицию работ, начали прорабатывать до элементарных операций только часть фаз. В то время как по остальным фазам нет полного понимания в конкретных работах.
Теперь если вы однажды часть плана закрепили как базовый и ведете сравнение с ним путем учета, возникает вопрос: как в Spider ДОделать базовую версию по "набегающей волне", где будет учтен кусок из первоначальной базы + вновь спланированные работы, но уже с учетом текущей ситуации?

[Сергей Никитенко]

Добрый день.
Любые действия с базовым планом должны четко реагламентироваться соответствующим документом в организации строго обязательным к исполнению всеми сотрудниками, работающими с моделями проектов.
Как действовать с базовым планом в случае детализации по "набегающей волне" вы должны решить самостоятельно внутри организации, догм здесь нет.
С технической стороны приведение базового плана в актуальное состояние может производиться различными способами. Здесь все зависит от ваших методик работы с моделями. Если за время фактического исполнения проекта в модель не вносились штучные изменения и корректировки, то актуализировать базовый план вы можете непосредственно - детализировав в нем нужную фазу. Затем из последней актуальной версии импортируете учет и получаете как базовый измененный план, так и актуальную текущую версию с теми же детализированными блоками.
Если фактическое исполнение "зацепило" ваши обобщающие операции до их детализации, то здесь работа будет более тонкая - помимо внесения новых пакетов работ в базовый и текущий план необходимо будет тщательно разнести деньги, объемы, трудозатраты в той части фактической модели, которая уже попала в факт например по общему бюджету.
Если исполнение проекта уже серьезно подвинуло сроки операций и фаз по сравнению с базовым планом, а детализируемый фрагмент как-бы должен начаться вовремя, а не с набежавшим отставанием, то его в базовом плане необходимо сдвинуть от логического начала (по связям) до реального при помощи маркера НРЧ.
Очень много моментов, которые необходимо учесть. Универсального совета здесь не существует.

[jefferson]

А есть какой нибудь мануальчик, либо передовой опыт как лучше делать? Как есть пример создания проекта, так и пример с базовым планом? Бывает сравнивая файлы недельной давности очень много расхождений - из за постоянного выхода РД, изменения смет. И если это всё ещё добавлять в текущий, а потом и в базовый файл.. выходит эпический фейл)

[Сергей Никитенко]

Мануальчик - это ВАША методология, которую вы разрабатываете для своего проектного офиса с учетом всех особенностей именно вашей компании.
Если у вас в пятницу утверждается базовый план, а в понедельник все начинают его дружно нарушать, а через неделю картина исполнения проекта вообще не похожа на базовый план, потому что изменилось вообще всё, то вам можно только посочувствовать. И никакой чужой мануальчик вас не спасет.
Делайте базовый план укрупненным, сравнивайтесь по срокам и бюджетам на фазах, а не на постоянно меняющихся пакетах работ и их параметрах. Да, подробной детализации при сравнении вы не получите, но хотя бы по основным показателям проекта будете ориентироваться. И исчезнет ваш фэйл с постоянным подкручиванием базового плана.

Реальными примерами с вами могут поделиться только коллеги, эта тема уже неоднократно поднималась на форуме:
http://www.spiderproject.com/forum_ru/viewtopic.php?f=11&t=503

[jefferson]

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

[Сергей Никитенко]

я тут больше имел ввиду какие нибудь советы в руководстве пользователя.

Как правильно создавать модель, описано в нашем учебнике, а также во встроенном в программу руководстве "Первый проект".
Как вообще правильно работать в области управления проектами - изучайте рекомендации PMBOOK и других стандартов.
НО. Никто не сможет написать энциклопедию на все случаи жизни. Спайдер это инструмент, как Эксель, Матлаб, Автокад или Адоб Афтер Эффект. У него есть свои законы работы и богатый набор специальной математики для определенных целей. А что и как вы в нем будете реализовывать - полностью ваше решение.
Как мы можем писать в руководстве "в начале сконцентрируйтесь на...", если даже в строительстве у одних самое важное "на..." вписаться в бюджеты, у вторых - успеть перебросить технику, у третьих - подстроиться под жесткий график какого-то дорогого и уникального механизма и т.д. Кому-то архиважно детализировать работы "до гвоздей", а кто-то принципиально описывает укрупненно. Кто-то считает все как в сметах - вплоть до пакли и строительных рукавиц, а кто-то мониторит только бетоны, отсекая остальное.
Поэтому внедрение подобных систем в компаниях не начинается с усаживания всех за рисование графиков, а начинается именно с поиска, формализации и четкого регламентирования того самого "в начале сконцентрируйтесь на..."

[Цахес]

Как можно заранее обратить внимание на то, что где то возможно изменится состав работ. Просто при анализе изменений выводите показатели из П и из РД что бы их можно было сравнить и отследить степень изменений и причину.
Единственное что можно посоветовать постарайтесь заранее понять по каким показателям Вам важно отслеживать изменения, чётко зафиксируйте эти показатели и контролируйте их изменения и последствия. Сравнить детальную декомпозицию работ по стадии РД с укрупнёнкой по П Вы всё равно не сможете. Всёравно сравнивать по укрупнёнке или искусственно делить, а как правильнее для Вас это выбор только Ваш.