ISO, менеджмент, консалтингпользователи сайтаRSSФОРУМСТАНДАРТЫГОСТ РСЛОВАРЬНАВИГАТОРКОНСУЛЬТАНТЫ 
Логин : Пароль:   
       [регистрация] [напомнить пароль]
 

ФОРУМ
• Re: методики описания БП 
 23. Окт 08:43 от PrilipkoAI
• ISO 22000:2018 
 10. Сент 23:29 от GurbanovR
• HACCP vs FSMS 
 23. Авг 10:52 от PrilipkoAI
• Re: план контроля качества 
 13. Авг 12:07 от Facebook



 

Стандарты управления (менеджмента) проектами.

 
Версия для печати
Автор Сообщение
AD
5 http://www.klubok.net/index.php?name=PNphpBB2&file=viewtopic&p=5564#5564
30 Окт, 2007 г. - 12:25
консультант [качество]
консультант [качество]

Откуда : Узбекистан, Ташкент
Добрый день! Извините, что предлагаю открыть новую тему, близкой тематики не нашел.
Интернет забит древними публикациями - примерами ошибок при переводе с английского в ГОСТ Р ИСО 9001:2001.
А может ли кто-нибудь высказаться по качеству перевода в ГОСТ Р ИСО 10006-2005 (ISO 10006:2003) - http://www.klubok.net/pageid358.html ?
Меня смущает уже само название стандарта - "Руководство по менеджменту качества при проектировании".
Сомневаюсь, что это является точным эквивалентом "Guidelines for quality management in projects".
Rolling Eyes А что же тогда дальше по тексту? Кто-нибудь сопоставлял?

Ответить с цитатой
 
OsipovIY
http://www.klubok.net/index.php?name=PNphpBB2&file=viewtopic&p=6172#6172
04 Июль, 2008 г. - 14:12
ученик

Откуда : Россия, Москва
Уважаемые Господа!

Мне нужно разработать стандарты управления (менеджмента) проектами на предприятии, кто-нибудь может подсказать, какие существующие документы можно использовать для этого?

Заранее благодарен

Ответить с цитатой
 
AD
http://www.klubok.net/index.php?name=PNphpBB2&file=viewtopic&p=6173#6173
05 Июль, 2008 г. - 11:48
консультант [качество]
консультант [качество]

Откуда : Узбекистан, Ташкент
ГОСТ Р ИСО 10006-2005

на первой странице посмотрите документы по управлению рисками, это тоже необходимо при менеджменте проектов.

CTAHДAPTЫ УПРАВЛЕНИЯ PИCKAMИ FERMA & AIRMIC

Ответить с цитатой
 
SorokinaAN
http://www.klubok.net/index.php?name=PNphpBB2&file=viewtopic&p=7429#7429
30 Июнь, 2010 г. - 10:53
ученик

Откуда : Россия, г. Москва
Кто-нибудь интегрировал эти 2 темы в одну? как закрыть в документации и требования ИСО 9001 и рекомендации по управлению проектами (американский PMBOK)? как должен выглядеть перечень разрабатываемой документации и т.д.?-дайте пищу для ума!!

Ответить с цитатой
 
AD
http://www.klubok.net/index.php?name=PNphpBB2&file=viewtopic&p=7432#7432
30 Июнь, 2010 г. - 11:21
консультант [качество]
консультант [качество]

Откуда : Узбекистан, Ташкент
SorokinaAN писал(а):
Кто-нибудь интегрировал эти 2 темы в одну? как закрыть в документации и требования ИСО 9001 и рекомендации по управлению проектами (американский PMBOK)? как должен выглядеть перечень разрабатываемой документации и т.д.?-дайте пищу для ума!!

А ISO 10006 "Менеджмент качества проектов" - не подойдет в качестве пищи для ума?

Ответить с цитатой
 
Alex9994
http://www.klubok.net/index.php?name=PNphpBB2&file=viewtopic&p=7436#7436
30 Июнь, 2010 г. - 18:23
консультант [качество]
консультант [качество]

Откуда : Россия, Санкт-Петербург
SorokinaAN писал(а):
Кто-нибудь интегрировал эти 2 темы в одну? как закрыть в документации и требования ИСО 9001 и рекомендации по управлению проектами (американский PMBOK)? как должен выглядеть перечень разрабатываемой документации и т.д.?-дайте пищу для ума!!
Интегрировал в СМК проектного инстититута
ДП "Проектирование. Управление"
AD писал(а):
А [ISO 10006 "Менеджмент качества проектов"

Как вариант...

Ответить с цитатой
 
KvyatkovskiyYA
http://www.klubok.net/index.php?name=PNphpBB2&file=viewtopic&p=7438#7438
01 Июль, 2010 г. - 11:17
студент

Откуда : Украина, Хмельницкая область, г. Нетишин
М.б. и боян, но очень нравится эта статья:

>-------

Чепуха Проектного Менеджмента

Свет принципов управления, как и свет маяков, является путеводным лишь для тех,

кто знает вход в гавань. Голый принцип без средств его осуществления ничего не значит.


Анри Файоль

В советской интерпретации под «проектом» вообще подразумевался набор проектно-сметной документации, но эту терминологическую путаницу удалось побороть достаточно быстро, в первую очередь благодаря применению УП (управления проектами) в нестроительных сферах. Но появилась другая, более устойчивая чепуха. Справедливости ради заметим, что повсеместно распространена не вся из описанной чепухи, но поскольку она была замечена хоть раз, то должна быть упомянута и вывешена на «доску позора».

Чепуха первая (распространенная) - Платформой УП является программный продукт

Давайте обратимся к Своду знаний по УП (PMBOK, 3-е издание, русская версия, стр. 371). Там черным по белому написано «Программное обеспечение для управления проектами (Project Management Software) [Инструмент] …». И это верно – Программное Обеспечение (далее по тексту - ПО) было и всегда будет лишь инструментом для какой-либо деятельности, а строить деятельность вокруг инструмента крайне нецелесообразно. Фраза «построение системы УП на основе ПО» звучит так же несуразно, как и «построение процесса копания на основе лопаты». Если у Вас есть потребность копать, Вы сначала определяетесь, что Вы будете копать (траншею, котлован, колодец или что-то еще) и какие там почвы, а уже потом решаете, чем Вы будете копать – лопатой, экскаватором, буром или вообще будете вызывать бригаду подрывников. Почему же с ИТ-инструментами должно быть наоборот, типа «внедрим лопату, а уже потом посмотрим, что мы сможем выкопать». Или того хуже - «внедрили экскаватор, а нужно копать лунки для гольфа».
Если консультанты предлагают Вам внедрение методологии УП и создание офиса УП на основе какого-либо ПО, скорее всего, они сами производят это ПО, связаны обязательствами с производителем данного ПО или имеют прямую выгоду от его продажи. На самом деле их легко понять – продать эфемерное «управление проектами» намного сложнее, чем конкретный широко разрекламированный программный продукт. А кто же из нас ищет трудные пути, тем более при добыче денег?
Даже если консультанты берут некоторый срок перед внедрением на исследование процессов УП, существующих у заказчика, эту информацию они будут использовать, в первую очередь, для грамотного обоснования, почему они перестраивают процессы заказчика под конкретное ПО, а не для адаптации ПО, как об этом громко заявляют вначале. А компетенции у консультанта в области внедряемых им систем всегда больше, чем у заказчика, и ему легко будет убедить заказчика в правильности любого решения, даже если оно неэффективно работает в данном месте и выбрасывает «за борт» уникальные процессы компании, возможно, являющиеся ее конкурентным преимуществом. В итоге заказчик получает проинсталлированное ПО и «натянутые» не него процессы управления проектами. А ведь есть простое правило: «если процессы невозможно автоматизировать при помощи Excel и Word, то их невозможно автоматизировать нигде». Так давайте не будем больше культивировать чепуху относительно главенства ПО в системах УП.

Чепуха вторая (библейская). - Об абсолютной правильности процессов описанных в PMBOK.

В библии проектного менеджмента PMBOK описано, как все должно быть в идеале в большом проекте. Это как в Палате мер и весов, где самый длинный метр, самый тяжелый килограмм и т.д., так и PMBOK - самая долгая и дорогая методология УП. Всех описанных в PMBOK процессов не достаточно для управления комплексным проектом (программой), но этих процессов слишком много для простых и средних проектов. Поэтому компании создают свои корпоративные стандарты УП (далее по тексту - КСУП), которые являются симбиозом собственных наиболее эффективных процессов УП и рационального зерна из методологии.

Если консультант сообщает Вам, что нужно изменить такой-то процесс только потому, что в мире так никто не делает, а Вы знаете, что этот процесс – Ваше конкурентное преимущество именно потому, что в мире так никто не делает, то гоните этого консультанта прочь.

Чепуха третья (проектно-ориентированная). - О высокой эффективности внедрения УП в проектно-ориентированных отраслях.

Да, действительно, в конечном итоге внедрение методологии УП приносит эффект и в этих отраслях. Но и до внедрения эти компании каким-то образом умудрялись реализовывать проекты, и у них была своя, пусть не совсем формализованная методология. Менять эту методологию очень тяжело, а в некоторых случаях и не возможно, поскольку «матерые спецы», создавшие ее, утверждают, что они так делали всегда, эта система вырабатывалась годами, и она в данной организации наиболее эффективна. Даже если руководство компании, из стратегических соображений, очень заинтересовано в этом внедрении, то старую систему отбросят, а новую будут некоторое время саботировать (гласно или негласно). В это самое время может наблюдаться провал в эффективности реализации проектов. В таких отраслях нужно постепенное вынужденное внедрение необходимых инструментов и методик, которые придут на смену или расширят возможности элементов существующей методологии. Участники проектов должны почувствовать в них потребность, но на такое медленное постепенное внедрение никто из консультантов не решится. Зачем им нужна эта жвачка?

В действительности, наибольший эффект внедрение системы УП приносит в изначально непроектных отраслях: финансы, производство, дистрибуция, транспорт и т.д. В этих отраслях запускается сейчас огромное количество проектов и за неимением собственных накатанных техник и средств УП они наступают на все грабли, на которые только можно было наступить. Наложение же методологии УП на них как на чистый лист позволяет достигать наибольшее преимущество и эффект. Как сказал Дмитрий Литвак в одном из своих интервью – «операционной деятельностью мы рубим капусту, а проектной – создаем нож для рубки, улучшаем его капусто-рубящие свойства. И чем быстрее мы получаем этот нож, чем лучше его свойства, тем выше показатель капусто-отдачи».

Чепуха четвертая (эзотерическая). - УП – это дорогое секретное оружие для достижения небывалых результатов.

Эта чепуха появилась, вероятнее всего, от желания недостаточно компетентных консультантов набить себе цену. Поэтому они делали вид, что это все очень таинственно, дорого, мало понятно, но крайне эффективно. Просто эзотерика какая-то!

На самом деле, здесь не может быть никакой секретности, поскольку единоличное владение этой методологией сродни владению единственным мобильным телефоном или e-mail в мире. Какая польза от них в таком случае? Представьте, если заказчик владеет методологией УП, а исполнитель и слухом о ней ничего не слыхивал (или наоборот). Что происходит в этом случае? Правильно! Все разговаривают на разных языках. Получается своего рода Вавилонская башня и разные языки. Поэтому во многих странах создают системы профессионального образования в области управления проектами на государственном уровне для создания критической массы проектных менеджеров в стране. Практическими примерами создания таких систем государственного обучения могут послужить Украина и Китай.

Нужно постоянно культивировать компетенции команд, управляющих проектами. Благо сегодня уже нет недостатка в информации, литературе, курсах и различных «гуру» в области УП. Отдача от любого вида повышения компетенции будет очень высокой, если следовать простому правилу: «Знания не дают, их берут».

Чепуха пятая (богатырская). - Методологию УП могут внедрить только внешние консультанты.

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

Чепуха шестая (документальная). - Корпоративный стандарт УП – это набор шаблонов и документов.

Хоть мы и называем это чепухой, нужно отдать должное, что она ближе всего к реальности, но все же и она требует небольшого «расшатывания своих основ». Давайте обратимся к тому же PMBOK и посмотрим определение «документа». Это «носитель и информация на нем, которые обычно имеют определенную устойчивость к воздействиям…». Да, при создании КСУП без маломальской формализации процессов УП и формирования набора шаблонов не обойтись. Но если мы формализуем процессы, впишем их в бумагу и положим пылиться на полку, тем самым обеспечив указанную «устойчивость к воздействиям», то получим мертворожденное дитя. Стандарт же должен жить и постоянно развиваться, а вместе с ним должны развиваться входящие в него документы. Даже в Конституцию вносят поправки!

Проекты уникальны по определению, и чем больше компания выполнит различных проектов, чем больше накопит опыта в области УП, тем изящнее должен становиться ее КСУП.

Взгляните на технологию Microsoft Solutions Framework. Билл Г. приоткрыл коммерческую тайну и выпустил для общего обозрения одну технологию из своей богатой методологии УП. Если посмотреть на историю развития этой технологии, то видно, какой долгий путь она прошла. А теперь давайте проведем небольшой эксперимент: возьмем эту документацию, сменим логотипы и названия Microsoft на свои и издадим ее у себя в виде КСУП. Что в итоге получим? Ровным счетом ничего. Просто наша техническая библиотека пополнится еще несколькими документами.

Если же поразмыслить над этим экспериментом, то получаем, что КСУП – это в первую очередь компетенция. Компетенция персонала создающего, использующего, изменяющего и влияющего на КСУП. Компетенция, вылитая на бумагу. Можно даже сказать, компетенция в твердом состоянии.

Чепуха седьмая (бумажная). - Очень важно быть сертифицированным специалистом в области УП.

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

Возможно, где-то в Европе или Штатах так и есть, но у нас, где любую бумажку можно купить, к сертификатам относятся скептически. В результате сертификат в нашей стране – это просто очередная корочка для утешения самолюбия.

Но с другой стороны, при подготовке к сертификационному экзамену, происходит вынужденная структуризация каркаса знаний по УП (причем как у начинающих, так и у опытных проектных менеджеров). Причем такой эффект не наблюдается при простом прохождении тренингов по УП. Так что сертифицируйтесь, но не для очередной медальки на «дряхлой груди генсека», а для улучшения своей компетенции и самоуверенности.

источник: http://www.spiderproject.com.ua/news/detail.php?ID=5906&phrase_id=30234

Ответить с цитатой
 
Показать:     
Перейти к:  
Время в формате GMT + 3
Версия для печати
 

менеджмент качества ( процессы | школа качества | нормирование | управление качеством | хассп)
книги: стандарты | качество | ХАССП | маркетинг | торговля
управленческий консалтинг ( планирование и контроль | конфликтменеджмент)
новости и события: пресс-релизы | новые стандарты | новости партнеров | новости | архив новостей, статей
новая торговля (автоматизация | магазиностроение | маркетинг и экономика)
интернет-маркетинг (создание сайта | интернет - бизнес)
финансы & страхование (страхование | бизнес-школа)
обзоры и интервью: маркетинг | консалтинг | торговля | управление качеством )
энциклопедия: это интересно | глоссарий | о семье | менеджмент семьи | каталог ресурсов