25.05.2005, 10:41 | #21 |
Участник
|
Цитата:
Сообщение от serge kotov
Цитата:
Сообщение от bobkov
Приведу пример: целью проекта являлось определенное снижение себестоимости продукции. Для достижения цели было решено реализовать проект по учету себестоимости в необходимых разрезах. Проект закончился, себестоимость должным образом учтена, но снизить ее должным образом не удалось.
... Учет - это только одна из задач в направлении снижении себестоимости продукции, а не цель. Подмена бизнес цели одной или несколькими частными задачами очень распространенная ошибка, которая приводит к провалу проектов. В данном случае РП сработал неудачно, т.к. имея перед собой бизнес цель по снижению себестоимости он занялся реализациеций в сущности другой цели по учету. Правильный ход со стороны РП в данном случае (да и в других также) первоначальный анализ достижимости бизнес цели и информирование стэйкхолдеров о результатах анализа для согласования разумной концепции решения. По хорошему бизнес цель определяет заказчик (спонсор), а как ее достичь определяет РП, если не сам, то с помощью других членов команды проекта или внешних экспертов. Не всегда так бывает конечно, поэтому и много проблем возникает. Видимо, в ходе такого бизнес-анализа должны были быть выработаны какие-то подцели, некоторые из которых достигались бы проектом. Подцели должны были бы быть релевантны основной бизнес-цели и одновременно такими, чтобы проект был максимально "изолирован" от влияния других бизнес-факторов. Такая изоляция, конечно, относительна, поэтому в рамках бизнес-анализа необходимо было бы явно указать на внешние (по отношению к проекту) факторы, влияющие на достижение цели проекта. Я согласен с тобой, что отсутствие такого бизнес-анализа и является предпосылкой неуспешности проекта. Может быть, ты (или другие участники форума) предложишь варианты формулировок таких подцелей в рамках развития приведенного примера? |
|
25.05.2005, 11:15 | #22 |
Участник
|
Цитата:
Сообщение от bobkov
В своем примерея хотел показать, что для достижения такой бизнес-цели (и даже для анализа достижимости) РП должен выйти за рамки управления проектом, должен стать бизнес-консультантом с соответствующими правами.
... РП не обязан быть бизнес - консультантом, каждый должен профессионально заниматься своим делом. Хотя знания предметной области конечно не помешают. В данном случае нужно проанализировать всю цепочку формирования себестоимости. Используя диаграммы процессов, причинно следственные диаграммы и диаграмму Паретто определить факторы наиболее влиящие на себестоимость, с которыми в первую очередь нужно поработать. В общем типичный бизнес - анализ. |
|
25.05.2005, 14:20 | #23 |
Участник
|
Цитата:
Сообщение от serge kotov
Цитата:
Сообщение от bobkov
В своем примерея хотел показать, что для достижения такой бизнес-цели (и даже для анализа достижимости) РП должен выйти за рамки управления проектом, должен стать бизнес-консультантом с соответствующими правами.
... РП не обязан быть бизнес - консультантом, каждый должен профессионально заниматься своим делом. Хотя знания предметной области конечно не помешают. В данном случае нужно проанализировать всю цепочку формирования себестоимости. Используя диаграммы процессов, причинно следственные диаграммы и диаграмму Паретто определить факторы наиболее влиящие на себестоимость, с которыми в первую очередь нужно поработать. В общем типичный бизнес - анализ. Мне кажется, что честное выявление подходящих целей проекта не является целью РП, к тому же, как ты пишешь, "РП не обязан быть бизнес - консультантом, каждый должен профессионально заниматься своим делом." Возложение на РП такой ответственности ставит его в противоречивое положение по отношению к проекту - он должен обосновать необходимость реализации проекта, даже если ее объективно нет! |
|
25.05.2005, 14:45 | #24 |
Участник
|
Профессиональное проектное управление имеет свои принципы, отработанные и проверенные годами успешной практики.
Вполне возможно, что в результате бизнес анализа проект будет трансформирован или он будет прекращен. Это гораздо лучше чем впустую потраченное время, ресурсы и подмоченная репутация РП. "Обоснование необходимости реализации проекта, даже если ее объективно нет" - прямой путь к провалу проекта во-первых, а во-вторых у профессиональных РП есть вполне определенный кодекс чести, который они соблюдают и эта ситуация просто недопустима. Я бы мог рекомендовать в сложных случаях ссужать scope проекта. В приведенном выше случае с себестоимостью можно было сделать учет именно целью и прописать эту цель в первоначально утверждаемом проектном задании (project charter). По крайней мере в данном случае ни у кого не возникнет иллюзий, что данный проект будет решать то, для чего он не предназначен. |
|
25.05.2005, 19:05 | #25 |
Участник
|
Значит, получается, главная цель РП лежит в области бизнес-процессов - вне проекта:
РП должен достигнуть какой-нибудь (согласованной) бизнес-цели Заказчика путем создания автоматизированной системы. РП должен добиться этого, несмотря на то, что это выходит за рамки собственно управления проектом. А почему ты считаешь, что именно РП должен заниматься определением цели проекта? Почему этим не может заниматься другой специалист - бизнес-аналитик? Или это неэффективно? |
|
25.05.2005, 22:13 | #26 |
Участник
|
Цитата:
Сообщение от bobkov
Значит, получается, главная цель РП лежит в области бизнес-процессов - вне проекта:
РП должен достигнуть какой-нибудь (согласованной) бизнес-цели Заказчика путем создания автоматизированной системы. РП должен добиться этого, несмотря на то, что это выходит за рамки собственно управления проектом. А почему ты считаешь, что именно РП должен заниматься определением цели проекта? Почему этим не может заниматься другой специалист - бизнес-аналитик? Или это неэффективно? Это как бы твои выводы, но на основании чего они были сделаны и связи между ними - не понял, признаюсь. Выше в этой ветке я говорил о другом. |
|
04.04.2007, 12:32 | #27 |
Участник
|
Цитата:
Сообщение от mazzy
А какая разница? Оба должны завершить проект. У них немного разные условия по ресурсам и деньгам. Но принципиально они не отличаются. ИМХО.
А кому нибудь доводилось слышать про проекты, где ПМ от Заказчика был грамотнее и вел проект сам, используя команду Исполнителя как ресурс, и ими рулил? |
|
04.04.2007, 14:38 | #28 |
Участник
|
Цитата:
Сообщение от bobkov
Значит, получается, главная цель РП лежит в области бизнес-процессов - вне проекта:
РП должен достигнуть какой-нибудь (согласованной) бизнес-цели Заказчика путем создания автоматизированной системы. РП должен добиться этого, несмотря на то, что это выходит за рамки собственно управления проектом. А почему ты считаешь, что именно РП должен заниматься определением цели проекта? Почему этим не может заниматься другой специалист - бизнес-аналитик? Или это неэффективно? Например цель это то, к чему необходмо стремиться решая что-то (Функциональная ОБЯЗАННОСТЬ работы ПМ, но не цель - управлять проектом. А вот цель - получить завершенный проект, чтобы ПОТОМ получить удовлетворенного заказчика, акты и оплату, ...). Функции и цели это совершенно разные вещи. И естественно дополнительно нужно определять рамки проекта, критерии успеха и .... ({творчество людей}) |
|
04.04.2007, 17:03 | #29 |
Участник
|
Цитата:
И слышал. И работал "как ресурс". |
|
05.04.2007, 11:23 | #30 |
Участник
|
|
|
05.04.2007, 11:57 | #31 |
Участник
|
Да помоему сейчас это уже не редкость и даже переходит во внедренческие конторы, когда проекты пускаются на самотек и консультанту (если он дошей болеет за проект), чтобы не завалить проект, нужно делать все возможное!!
|
|
05.04.2007, 12:03 | #32 |
Участник
|
Нет, тут специфика в том, что РП от заказчика - грамотный и понимает что надо его конторе. А не просто - человек, что подписывает проектные документы.
по сути - он должен сам внедрять ПО в компании, но есть проблема - он же не знает это ПО. Но рулит им , потому что он - грамотный ПМ! А вот это как раз и редкость! |
|
05.04.2007, 12:34 | #33 |
Участник
|
Цитата:
Сообщение от egen
Нет, тут специфика в том, что РП от заказчика - грамотный и понимает что надо его конторе. А не просто - человек, что подписывает проектные документы.
по сути - он должен сам внедрять ПО в компании, но есть проблема - он же не знает это ПО. Но рулит им , потому что он - грамотный ПМ! А вот это как раз и редкость! Если САМ внедряет его, то естественно он должен знать его (кстати, это наилучший вариант для заказчика). И тем более тогда он 100% может быть уверен, что бизнес-процессы корректно переложены в систему. Если ПМ действительно грамотный, то он порулит не только внедрением этого продукта, но и различных сразу. |
|
16.04.2007, 11:53 | #34 |
Участник
|
А должен ли РП управлять рисками и как это выглядет на практике, если в договоре отражена сумма и сроки, и обычно никаких допуском на риски не предусмотренно?
|
|
08.07.2007, 21:40 | #35 |
Участник
|
Черт, форум так медленно развивается, что я уже готов сам себе ответить. потому что теперь то я знаю правильный ответ.
|
|
08.07.2007, 23:06 | #36 |
Участник
|
И какой ответ вы считаете правильным?
|
|
09.07.2007, 09:32 | #37 |
Участник
|
Человек постигший нирвану, напоминает человека который, зубами держиться на ветку, и что бы ответить на вопрос тех, кто внизу - что он познал - ему придеться разжать зубы и упасть вниз. (ц) Вольный перевод
Так что ответить я могу, да только это никому не надо. профессионалы на форумах не тусуются, а новичкам сие знание непонятно. Я сам еще в каком то переходном состоянии. Хотелось бы в дискусии отточить формулировки. |
|
09.07.2007, 11:25 | #38 |
Участник
|
Значит, не можете ответить
|
|
09.07.2007, 12:08 | #39 |
Участник
|
|
|
09.07.2007, 12:19 | #40 |
Участник
|
Сакральный вопрос:
Цитата:
Сообщение от egen
Черт, форум так медленно развивается, что я уже готов сам себе ответить. потому что теперь то я знаю правильный ответ.
Цитата(egen @ 16.04.2007,11:53) А должен ли РП управлять рисками и как это выглядет на практике, если в договоре отражена сумма и сроки, и обычно никаких допуском на риски не предусмотренно? РП должен управлять рисками. Точнее он только и делает что управляет рисками, так что это его обязанность. Как? Наверно у каждого свое понимание, но лично я решил следовать канону PMBOK, и не столько потому что это идеальное решение, а потому что на следущий год собираюсь получить PMP сертификат и мне нужна реальная практика по методологии PMI. С такой практикой ведения договоров, как указывал раньше - борюсь. Сейчас мы в договор начинаем писать бизнес цели, а не просто список планируемых работ. Это чуть сложнее, но с точки зрения проекта - правильнее. Причем, еще не все получилось сделать качественно, новые договора будем заключать рамочно, а пока по старым форматам - добавили в план проекта работы, которые берет на себя Заказчик. Вот на эти работы и накладываем управление рисками, что бы ключевые вехи проекта были в рамках плана. Вот типа так... |
|