пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅ

Вадим, в том то и дело, что наша технология пока никак не описана. �, чесно говоря, совершенно непонятно с чего начать?

Владимир, спасибо за ответ. Но процессы PMBOK больше касаются исполнения самого проекта. Нам же, как я понимаю, требуется еще и описание существования проекта в самой организации. Например: проектный офис, организационная структура и проч. В связи с этим возникает необходимость выстраивания некоторой системы регламентирующих документов, которые кроме описание процессов по PMBOK должны содержать еще нечто... Что именно еще должно быть в этих документах ,чтобы избежать избыточного описания и в то же время ничего не забыть?

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

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

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

Боюсь наша компания еще не вполне готова к аутсорсингу, ни со стороны наших сотрудников, ни со стороны уже специализирующихся в этой области компаний. Однако, в связи с этим вопрос, вы думаете, что управление проектами компании можно отдать на аутсорсинг. �ли аутсорсингу можно подвергнуть только внедрение УП?

Может быть у кого-то есть ссылки на материалы, в которых описана иерархия документов, которые закрывают потребность компании в регламентирующих докмуентах в области УП. �ли есть "живые примеры", как это уже было реализовано в других компаниях. Что должно являться предметом регламентации, кроме процессов по PMBOK?

проект может рассматриваться как процесс перехода из исходного состояния в конечное - результат при участии ряда ограничений и механизмов" (Цитата)

здесь на сайте по ссылке [������...]

Процесс - это деятельность, использующая ресурсы для преобразования входа в определенный выход (выходной результат), котора руководствуется определенными ограничениями (инструкциями).
С помощью процессов можно описать любую деятельность, в том числе, и проекты.
Если из определения процесса исключить его основную часть (вход, выход, инструкции в широком смысле), мы получим определение работы - деятельность, которая использует ресурсы.
В проектном подходе как раз и применяется определение работы.
(этот подход реализован в программах календарного планирования MS Project, PM3 и т.п.; прошу не путать с программами управления проектами).
Конечно вход, выход и инструкцию можно включить в описание самой работы, но это будет только "заплатка".
Приходится держать информацию о результатах проекта в других программах или документах, а на худой конец в голове. На этапе планирования этот недостаток проектного подхода можно пережить. Но на этапе реализации возникают потребности в маршрутизации и пересылке результатов проекта. Здесь без "примочек" или итеграции с другими продуктами не обойтись.

В процессе работы над корпоративным стандартом управления проектом получила группу проектов с длительностью в пределах одного года, стоимостью 80 млн. руб., команда менеджмента проекта - 5 человек. Этот проект считается маленьким. Столкнулась с мнением, что такому маленькому проекту регламентирующие документы не нужны, все можно решить на словах и на основе неформальных договоренностей. ощущаю, что это не так, но аргументов не хватает, что делать? Как объяснить, что стандарт всетаки нужен?

Ксения, если то, о чем Вы спрашиваете еще актуально, напишите мне лично chelpanov@[������...]
Поделюсь, чем есть.
С уважением Сергей

Отлично! Но ситуация в том, что альтиписты совсем не хотят никаких стандартов. Когда они первый раз лезли на гору, то каждый был профессионалом и вместе они классно поколбасились. Было неформальное общение, много свободы. � Оои таки залезли на гору и все как один сказали - круто и у нас был классный проект и мы оцениваем его как успешный. Теперь второй раз нужно лезть на гору. Как показать этим альпинистам, что все может быть еще круче, если у них будет стандарт. То есть нужны какие-то реальные данные о том, что проект закончился бы быстрее и с меньшими затратами, если бы они жили по стантарту, то есть более формализованно