Регистрация   E-Mail     Пароль   
Портал «Профессионал управления проектами»
!!!! Обращаем внимание регионов!
Первый курс по MS Project 2010 в он-лайн формате, 20-27 июля 2010 года.

123

Ксения
13 февраля 2004 г., 16:15
Работа в проектно-ориентированной (по своей сути) организации заставила в определенный момент задуматься: "А так ли мы работаем?" Как можно оценить, мы работаем по проектной технологии или нет? Наличие на компьютере программы MSP (или другой) не гарантирует этого. Что еще должно быть в компании, чтобы утверждать: «Мы действительно работаем по проектной технологии.»?
И, все эти вопросы, в итоге, приводят к основному, какие элементы должна содержать работающая корпоративная система управления проектами.
Если есть варианты, очень буду рада их узнать.
Спасибо.
Ксения
16 февраля 2004 г., 07:40
С чего начать?
Вадим, в том то и дело, что наша технология пока никак не описана. И, чесно говоря, совершенно непонятно с чего начать?
Ксения
16 февраля 2004 г., 07:44
Еще документы
Владимир, спасибо за ответ. Но процессы PMBOK больше касаются исполнения самого проекта. Нам же, как я понимаю, требуется еще и описание существования проекта в самой организации. Например: проектный офис, организационная структура и проч. В связи с этим возникает необходимость выстраивания некоторой системы регламентирующих документов, которые кроме описание процессов по PMBOK должны содержать еще нечто... Что именно еще должно быть в этих документах ,чтобы избежать избыточного описания и в то же время ничего не забыть?
Ксения
16 февраля 2004 г., 11:49
Алгоритм действий
у нашей компании есть ресурсы для разработки собственной системы УП, но хотелось бы знать алгоритм действий. Может быть он где-то описан?
Natalija
17 февраля 2004 г., 11:34
Начните с модели бизнес-функций.
Сначала просто прорисуйте ваш управленческий функционал "Как есть". Поверьте,очень многое встанет на свои места и выявяться недостающие функции. Ну, а следом,постройте функциональную модель "Как должно быть" в рамках системы УП. Инструменты для моделирования есть. Я пользуюсь BPWin-ом.
Ксения
17 февраля 2004 г., 12:29
Уточнение
Наталья, есть уточняющий вопрос. Если я Вас правильно поняла, вы считаете, что процессная модель адекватно отображает управление проектом? Если это так, то в чем на ваш взгляд разница между процессным и проектным подходом? Может проще управлять только процессами, а не проектами.
Ксения
17 февраля 2004 г., 12:32
Слишком много сарказма
Боюсь наша компания еще не вполне готова к аутсорсингу, ни со стороны наших сотрудников, ни со стороны уже специализирующихся в этой области компаний. Однако, в связи с этим вопрос, вы думаете, что управление проектами компании можно отдать на аутсорсинг. Или аутсорсингу можно подвергнуть только внедрение УП?
Ксения
17 февраля 2004 г., 12:35
Иерархия документов
Может быть у кого-то есть ссылки на материалы, в которых описана иерархия документов, которые закрывают потребность компании в регламентирующих докмуентах в области УП. Или есть "живые примеры", как это уже было реализовано в других компаниях. Что должно являться предметом регламентации, кроме процессов по PMBOK?
Natalija
17 февраля 2004 г., 14:23
"С точки зрения системного подхода...
проект может рассматриваться как процесс перехода из исходного состояния в конечное - результат при участии ряда ограничений и механизмов" (Цитата)
Natalija
17 февраля 2004 г., 17:28
Видели ли вы эту статью:
здесь на сайте по ссылке [ссылка...]
Процессы - это все...
Процесс - это деятельность, использующая ресурсы для преобразования входа в определенный выход (выходной результат), котора руководствуется определенными ограничениями (инструкциями).
С помощью процессов можно описать любую деятельность, в том числе, и проекты.
Если из определения процесса исключить его основную часть (вход, выход, инструкции в широком смысле), мы получим определение работы - деятельность, которая использует ресурсы.
В проектном подходе как раз и применяется определение работы.
(этот подход реализован в программах календарного планирования MS Project, PM3 и т.п.; прошу не путать с программами управления проектами).
Конечно вход, выход и инструкцию можно включить в описание самой работы, но это будет только "заплатка".
Приходится держать информацию о результатах проекта в других программах или документах, а на худой конец в голове. На этапе планирования этот недостаток проектного подхода можно пережить. Но на этапе реализации возникают потребности в маршрутизации и пересылке результатов проекта. Здесь без "примочек" или итеграции с другими продуктами не обойтись.
Ксения
22 марта 2004 г., 15:41
Зачем маленькому проекту стандарт?
В процессе работы над корпоративным стандартом управления проектом получила группу проектов с длительностью в пределах одного года, стоимостью 80 млн. руб., команда менеджмента проекта - 5 человек. Этот проект считается маленьким. Столкнулась с мнением, что такому маленькому проекту регламентирующие документы не нужны, все можно решить на словах и на основе неформальных договоренностей. ощущаю, что это не так, но аргументов не хватает, что делать? Как объяснить, что стандарт всетаки нужен?
Serge
24 марта 2004 г., 11:36
Корпоративная СУП
Ксения, если то, о чем Вы спрашиваете еще актуально, напишите мне лично chelpanov@[ссылка...]
Поделюсь, чем есть.
С уважением Сергей
Ксения
24 марта 2004 г., 11:45
Все и так круто!
Отлично! Но ситуация в том, что альтиписты совсем не хотят никаких стандартов. Когда они первый раз лезли на гору, то каждый был профессионалом и вместе они классно поколбасились. Было неформальное общение, много свободы. И Оои таки залезли на гору и все как один сказали - круто и у нас был классный проект и мы оцениваем его как успешный. Теперь второй раз нужно лезть на гору. Как показать этим альпинистам, что все может быть еще круче, если у них будет стандарт. То есть нужны какие-то реальные данные о том, что проект закончился бы быстрее и с меньшими затратами, если бы они жили по стантарту, то есть более формализованно
Пожалуйста, авторизуйтесь или зарегистрируйтесь для добавления сообщений в этот форум.