PMBoK 2008: обзор по главам

[Andruxa]

Хорошо, спасибо. У меня кстати вот эта редакция. Даже не знаю, вторая ли она. Понял, как возьмусь за книгу - напишу.

[Евгений_Кс]

Хорошо, спасибо. У меня кстати вот эта редакция. Даже не знаю, вторая ли она. Понял, как возьмусь за книгу - напишу.

Первая, первая. Это перевод с английского издания 1997 года

[Ольга Кряжич]

Насчет программ. Я работал с Project Expert - не по работе, по собственным проектам, по работе работал с MS Project (в общем и в целом, не так уж с ним всё и плохо при коллективной работе). Сейчас работаю в компании, в которой используют скорее issue tracking, который более удобен для Agile-процессов, нежели Project. Скажем так, управлять бюджетом лучше в Project, поручениями - в issue-tracking-системах.

В Project Expert я постоянно работаю. Конечно, не в восторге - у него столько несостыковок, особенно если ориентироваться на украинские условия.
Сейчас вот тоже более детально знакомлюсь с РМВоК и осваиваю Спайдер...
Так что жду пополнений Вашей темы!

[Andruxa]

Процессы - оценка затрат (определение необходимых денежных ресурсов для выполнения задач по проекту), определение бюджета (агрегация затрат для получения cost baseline - базовой стоимости), управление затратами (Control Costs - процесс мониторинга статуса и обновления бюджета и управления изменениями в базовой стоимости).

Да, я пропустил в изложении предыдущих глав. Базовый план - baseline - всегда фиксируется до старта работ. Соответственно текущий, актуальный план, получается суммированием всех изменений примененных к базовому. Особенно это актуально к стоимости. Думали стоит А, а вышло-то Б... в ИТ нередки случаи Б < А. Сранивая базовый план с результатами проекта можно много чего наковырять.

Особенно интересная штука - план управления стоимостью (cost management plan), который включает в себя - уровень точности, единицы измерения, связь с WBS, управление пороговыми (thresholds) величинами, правила контроля и прогноза исполнения (perfomance management), формат отчетности, описание всех трёх процессов. Не знаю как в каждом проекте, но на организацию такая штука нужна. Так скажем, там где я работаю, она есть, и эффект от неё есть - всё предсказуемо и относительно управляемо.

Оценка стоимости по PMBoK включает в себя принятия решений покупать или производить или брать в аренду. Как меня и учили, PMBoK пишет, что оценка на первом этапе может быть менее точной, чем в последующие.

Тут отстутплюсь и расскажу, в чем фишка разбиения на подзадачи при оценке (времени, стоимости и прочего). Как Мишин пишет в книге "Проектный бизнес" про Закон Больших Чисел, ошибка для суммы одинаково распределенных случайных величин с ходом накопления нивелируется (приводится пример про рельсы. если в каждом ошибка 10 см в любую сторону, то чем больше рельсов, тем меньше ошибка). Правда для этого надо разбивать всё на одинаковые промежутки. В случае ИТ это не так сложно как может показать - разбивать проект на задачи по два дня длительностью, формируя из них пакеты длительностью две недели. Это реально, и я этим пользуюсь. Правда полагаюсь в этом вопросе на теорию, статистику ошибок к сожалению не имею (вел issue log по проектам раньше, но сейчас что-то... как-то... устал. трудно в Excel, нужны интегрированные средства и более удобные).

С оценкой стоимости кстати всё серьезно, очень много входов. Про инструменты оценки лучше самому читать полностью. Все серьезно.

Составление бюджета. Budgets constitute the funds authorized to execute the project. В выходе процесса - cost perfomance baseline - приведена знаменитая S-кривая кумулятивных затрат (кажется, в прошлом-то её и не было). Короче говоря, тоже надо всё это читать.

В процессе управления бюджетом подробно описан всё-таки нетривиальный для практики метод освоенного объёма. Без физических аналогий он трудно догоняется. Опять же, у Мишина есть хорошая метафора метода освоенного объема с передвижением пешехода из точки А в точку Б. Мол, выйти-то он мог и попозже или пораньше, да и пойти не с той скоростью... что выглядет сдвижкой и наклоном S-кривой.

Очень серьезная глава, хоть и короткая.

[Bend]

...В случае ИТ это не так сложно как может показать - разбивать проект на задачи по два дня длительностью, формируя из них пакеты длительностью две недели...

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

[Andruxa]

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

нет, разбивается всё на более-менее равные задачки. бьётся, если постараться. тут конечно свои заморочки, архитектурные и прочие, но это уже детали.

[Andruxa]

Три процесса - планирование качества, выполнение quality assurance (аудит качества), управление качеством (мониторинг выполнения плана качества).

Управление качеством относится как к продукту проекта, так и к самому проекту. Качество определяется как "степень, с которой ряд характеристик удовлетворяет требованиям". Утверждается, что написан PMBoK совместимо с ISO. В частности, указывается на важность:
1. Удовлетворения потребителя,
2. Предупреждение вместо инспектирования,
3. Непрерывное улучшение (plan-do-check-act).
Напомнено, что неплохо бы иметь ввиду ещё cost of quality. Мол, обслуживание по гарантии может впоследствии дороже обойтись, нежели своевременный подход по устранению дефектов.

Очень интересно определяется процесс планирования качества. Понимается как процесс идентификации требований по качеству (и/или стандартов качества) для проекта и продукта, и документирование того, как проект продемонстрирует соответствие. Демонстрация соответствия - на практике вещь нетривиальная и необходимая в том смысле, что обойти её нельзя. Поэтому важно уделять внимание критериям приемки-сдачи всегда - не только для того, чтобы застраховаться подрядной организации, а ещё и для уверенности в качестве продукта.

В качестве одного из входов процесса, обращаю внимание, используется реестр стэйкхолдеров. То есть (как например и экономическая эффективность) качество зависит ещё и от "наблюдателя". Очень интересные техники планирования качества приведены. Но это надо их смотреть. Даны ссылки на Six Sigma, Lean, CMM... На одном выходе остановлюсь. Контрольные списки (checklists) качества: очень полезная вещь, не только для качества, но и вообще. Хорошие чеклисты - одна из основ управления проектом, к сожалению, в России пока не сильно прижившаяся. A checklist is a structured tool, usually component specific, used to verify that a set of required steps has been performed. Ещё один интересный выход - это план улучшения процесса! Является входом для процесса Quality Assurance.

При рассмотрении процесса Quality Assurance, утверждается что он является "зонтиком" для процесса непрерывного совершенствования, который итерационным способом (так и хочется добавить "своего сущестовования") повышает качество всех процессов. И что самое интересное, этот процесс непрерывного совершенствования "отбрасывает" не добавляющие ценности активности.

Процесс управления качеством иницирует процесс quality assurance - по результатам измерения качества. Для контроля качества используются по-моему все те же старые приёмы, но не менее ценные оттого.

[Andruxa]

Есть такая книга: "Critical Chain Project Management by Lawrence P. Leach", ее выставляли на http://www.forum.mbq.ru/viewtopic.php?p=521#521 , но ссылка устарела, поэтому дублирую файл вложением.

Спасибо огромное! Я как-то сразу Ваш пост не увидел, только сейчас почему-то.

[Евгений_Кс]

Спасибо огромное! Я как-то сразу Ваш пост не увидел, только сейчас почему-то.

И я. Такое ощущение, что он позже появился.

[via]

Тут отстутплюсь и расскажу, в чем фишка разбиения на подзадачи при оценке (времени, стоимости и прочего). Как Мишин пишет в книге "Проектный бизнес" про Закон Больших Чисел, ошибка для суммы одинаково распределенных случайных величин с ходом накопления нивелируется (приводится пример про рельсы. если в каждом ошибка 10 см в любую сторону, то чем больше рельсов, тем меньше ошибка).

Хм. Странно. Может быть, практика этот тезис подтверждает, но теория, точнее, теория вероятности, нет.
Есть такое явление – аддитивность дисперсий. Из этой самой аддитивности, следует, что если для одной рельсы дисперсия плюс/минус 10 см., то, скажем, для 100 рельс уложенных в ряд, дисперсия будет плюс/минус 100*10 = 1000 см. При гауссовском (нормальном) распределении, вероятность того, что «ошибка для суммы одинаково распределенных случайных величин с ходом накопления нивелируется», т.е. 100 рельсов уложенных в ряд дадут суммарную погрешность «0», равна только 50%. Остальные 50% за то, что такого не произойдёт. Более того, вероятность, что мы получим погрешность +/- 1000 см., хоть и не велика, но отнюдь не нулевая. Стоит ли тратить усилия на то, чтобы добиться 50% вероятности успешного достижения запланированного? Может проще монетку подбросить?

[Bend]

Стоит ли тратить усилия на то, чтобы добиться 50% вероятности успешного достижения запланированного? Может проще монетку подбросить?

А всегда ли изначальная вероятность успешного достижения запланированного равна нулю?

[Andruxa]

Есть такое явление – аддитивность дисперсий. Из этой самой аддитивности, следует, что если для одной рельсы дисперсия плюс/минус 10 см., то, скажем, для 100 рельс уложенных в ряд, дисперсия будет плюс/минус 100*10 = 1000 см. При гауссовском (нормальном) распределении...

Тут дело не в нулевой погрешности, согласен, если быть точным, в снижении (кстати ЗБЧ не зависит от распределения величин) вероятности высокой погрешности, с ростом n она стремится к нулю. При этом достаточно быстро (может быть я и не прав?), как 1/n.

Домой ещё приду перечитаю - у него (у Мишина) какое-то следствие было использовано, более подробно приведу о чем речь. Возможно по памяти я и нагрешил. У него как сейчас помню был очень наглядный пример с 36 рельсами.

[hilton]

нет, разбивается всё на более-менее равные задачки. бьётся, если постараться. тут конечно свои заморочки, архитектурные и прочие, но это уже детали.

эти детали - основа организации проектов в ИТ, особенно небрежно названные "архитектурные заморочки".

[Andruxa]

эти детали - основа организации проектов в ИТ, особенно небрежно названные "архитектурные заморочки".

Я не про ИТшные проекты рассказываю здесь, они мне интересны здесь постольку-поскольку я примеры из них приводить могу.

Я уже говорил про разделение процессов разработки и управления проектом. Так вот - разбиение задач - это из области управления, сами задачи - из предметной области, на которой я не стал здесь останавливаться. Конечно, эти "заморочки" - на практике весьма замороченные. Но при подходящем уровне специалистов, при наличии опыта, да и в основном делает оценку команда - это всё делается. Да, чуть не забыл - при хорошо описанном содержании.

Самое главное в этом деле из моего опыта - это срочность. Чем она ниже - тем качественнее оценку можно сделать.

[Andruxa]

Открыл Мишина, читаю:

Например, строительный кирпич керамический полнотельный должен иметь по ГОСТ 530-95 вес 3,5 кг, а размеры 250 х 120 х 65 мм. Реальные кирпичи будут иметь отличающиеся от стандарта, случайные значения. Это отличие будем называть ошибкой.
...
отклонение фактических показателей от плановых является ошибкой проекта...
... приведем качественную формулировку закона применительно к нашему случаю:

• ошибка суммы случайных (неопределенных) величин меньше, чем ошибка самой величины

Далее приведен пример про рельсы, при этом отклонение показано в процентах. С ростом количества рельс оно падает.

Темп скорости зависит от так называемого в математике распределения вероятностей значений первичной величины. В большинстве случаев действует простое правило:
Ошибка суммы случайных величин меньше ошибки самой величины в корень из N, где N - количество суммируемых величин.
...
Допустим, нам надо подсчитать бюджет (смету) проекта. Разобъем все работы на 100 различных по типу работ, но примерно одинаковых по стоимости. Если стоимость каждой работы на начальном этапе нам известна с точностью 50% относительно будущей фактической величины, то точность всего бюджета составит 5%! Корень из 100 равняется 10, и именно в 10 раз улучшится точность.
...
При применении закона больших чисел нужно учитывать следующие замечания.
...
Закон эффективно работает, если производится разбиение на примерно равнообъемные работы.
...
Не вдаваясь в дебри математики, можно привести эмпирическое правило: достаточно разбиения на 100-300 величин. Это увеличение дает вполне приемлемое увеличение точности с экономической точки зрения.
...
При выполнении декомпозиции необходимо учесть все возможные работы.
...
Не столь важно, как точно и детально мы управляем отдельными элементами проекта, важно, чтобы мы управляли всеми элементами проекта!

[Тишкин Михаил]

Приветствую

Классная работа проделана. Слежу внимательно.

Но по восьмой главе у меня есть вопрос, который давно меня мучает.
Возможно Вы сможете его разрешить

Процесс Управления качеством контролирует качество следующих объектов:
1. Результаты (в т.ч. промежуточные) проекта
2.1. Процедуры управления проектом
2.2. Работы по созданию результата

Но ведь два из вышеперечисленных объектов описаны и контролируются через процесс Управления содержанием (в частности пп. 1 и 2.2.
Вот я пытаюсь понять, в чем тогда особа роль (что он делает) процесса Управления качеством, если например требования к результату определяется в процессе "Определение содержания", а контроль за ним осуществляют процессы "Подтверждение содержания" (verify scope) и "Управление содержанием" (control scope)?

[Andruxa]

Спасибо. Читаю сейчас 9 главу, скоро изложу выжимку.

По поводу вопроса.
Процесс verify scope относится к анализу deliverables. Он - вход для закрытия фазы. В описании процесса сказано так:
Scope verification differs from quality control in that scope verification is primarily concerned with acceptance of deliverables, while quality control is primarily concerned with correctness of the deliverables and meeting the quality requirements specified for the deliverables. Quality control is generally performed before scope verification, but this two processes can be performed in parallel (страницы 99-100 PDF-документа).

В качестве входа для процесса проверки содержания являются Validated Deliverables, "проверенная поставка" так сказать, которые образуются после процесса проверки качества.

Лично я для себя провел следующие черту:
1. Контроль качества осуществляется по своим, особенным методам - диаграммы Ишикавы, Парето, выборки и прочее. При этом контроль качества - это контроль степени соответствия продукта требованиям (для меня не только по качеству, но и по функционалу и прочему).
2. Проверка содержания - новый процесс, хотя на практике я как сейчас помню я его использовал. Прежде чем отдать клиенту продукт - сам лично проверял наличие всех заявленных features + проверял (хоть на словах), что все необходимые работы выполнены (поскольку не всё глазами и руками проверишь). Напомню, что по разделяется содержание продукта и содержание проекта (работы), а также разделяются процессы производства продукта и процессы управления (к которым относятся control quality и verify scope).

Резюмируя: проверка качества - проверка технологии производства продукта (с точки зрения процессов производства продукта), проверка содержания - проверка продукта как продукта проекта (с точки зрения проекта).

Пример может быть наверное следующий. Проверка качества построенного дома (я к сожалению не силен в строительстве, но думаю там это различие есть) - проверка соответствия его ГОСТу (проводка, водные коммуникации, наклон стен и прочего). Проверка содержания - это наличие "фич" - что фасад красный, а двери синие, что есть балконы и другое. Если, например, на площадке нет пепельницы и диванчика - не значит что дом некачественный. Хотя если это гостиница, подобное может входить в содержание проекта.

И ещё я бы мог сказать, что подтверждение содержания может производиться вместе с Заказчиком.

[Andruxa]

Управление человеческими ресурсами в проекте включает в себя процессы организации, управления и ведедения проектной команды.

В целом, тут вообще ничего нового. Как бы даже и не сократили главу.

Интересно и правильно отмечено, над чем по привычке уже не задумываешься, что проектная команда включает в себя людей с назначенными ролями и ответственностью за завершение проекта.

Различается команда управления проектом, и команда проекта.

Процессы следующие:
1. Разработка плана управления человеческими ресурсами,
2. Набор проектной команды,
3. Развитие проектной команды,
4. Управление проектной командой.

Что можно выделить. В процессе разработки плана приведены различные форматы "документирования" команды - иерархическая, матрицы ответственности, текстовый (форма). Выход - план управления человеческими ресурсами:
1. Роли и ответственности (роль, полномочия, ответственность, компетенции),
2. Орг. схемы,
3. План управления персоналом (когда привлекать, когда и сколько работать человеку, когда отпускать, какие тренинги нужны, какие награды и система вознаграждения, соответствие неким политикам, безопасность - тоже в соответствии с некими политиками).

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

Развитие проектной команды. Что мне понравилось, что это не есть просто вбухивание денег в обучение и командопостроение, но ещё и assessment - как выход процесса развития. Так, например, сказано,
Оценка эффективности команды может включать следующие индикаторы:
1. Улучшение навыков, позволяющих выполнять работу по назначению (assignment имеется ввиду) более эффективно,
2. Улучшения в компетенциях, которые позволят команде быть "больше командой" (нежели сборищем),
3. Снижение текучести (turnover rate),
4. Улучшение связей внутри команды.
В качестве результата предусматривается общая оценка производительности команды.

Управление командой. Как и всегда для manage or control, на входе, в основном, (в данном случае) назначения и отчеты, на выходе в основном изменения и новые планы. Какие же инструменты управления командой рекомендует PMBoK. А это:
1. Наблюдение и разговоры
2. (Вольный перевод) Донесение до команды информации о ходе выполнения проекта (project perfomance appraisals). Преподавали мне HR, говорили это работает так: вешаете график, а в конце - "морковку". Копают люди канаву, а через столько дней - домой. Говорят, мотивирует. А вот программистов сроки не мотивируют... зато работает премия. "Премии осталось столько-то", главное тактично промолчать когда её не осталось
3. Конфликт-менеджмент. Всё как в старом добром 2004ом PMBoK.
4. Issue log - журнал событий. Полезный инструмент, как его не применяй. Можно писать issue по проекту какие кому выполнить, можно просто для себя записывать... а потом смотреть и анализировать. Главное с детализацией разобраться, этого issue log. Ежедневной процедурой это у меня было - взять на карандаш, что происходило. В конечном итоге чуть ли не книжка получалась. Поэтому я это дело прекратил. А в принципе - удобная и интересная вещица, всем рекомендую.
5. Навыки коммуникаций (Interpersonal skills). Тут вроде всё те же старые Лидерство, Влияние, Эффективное Принятие Решений. Приведены рекомендации.

В целом, можно сказать что для управления проектом в первую очередь важны роли, компетенции и назначения. Развитие тоже важно, но оно часто реализуется в рамках компании. Важно развитие именно команды проекта как целого, если особенно проект долгосрочный. В изложении процесса развития проектной команды указан team-building. В отличие от Мазура =), у которого изложен цикл команды весьма детально, в PMBoK красиво перечислено и только:
1. Forming - формирование,
2. Storming - "утряска",
3. Norming - нормализация,
4. Performing - выполнение,
5. Adjourning - распад.

Пытался пронаблюдать, но в ИТ-шных компаниях, где проекты не сильно длинные, а команды не очень большие, это сложно. Но пронаблюдать тоже можно. Это - чувствуется. Формирование - тут всё понятно. Все знакомятся. Утряска - это когда люди в процессе формирования мнений друг о друге, как по жизни, так и по работе. Нормализация - это когда все уже определились, кто тут пыльным мешком ударенный, кто ударник соц. труда, а кто тот ещё лентяй. Выполнение - это исходя из представлений продуктивная работа насколько представления какие есть. Распад, тут всё понятно.

[Михаил_Шустер]

Резюмируя: проверка качества - проверка технологии производства продукта (с точки зрения процессов производства продукта), проверка содержания - проверка продукта как продукта проекта (с точки зрения проекта)

Полагаю, на этот вопрос нет ответов, а есть только личные мнения.
Подозреваю, что авторы пошли на поводу. Всегда, когда слово "качество" пытаются вынести за скобки, получается непонятка. Вон стандартам ИСО9000 скоро тыщща лет, а до сих пор не выяснят, что такое "в области качества", а что в другой области.
Имхо. РМВОК является стандартом на систему качества предприятия, исповедующего проектный подход. Детальным и с лихвой удовлетворяющим все требования ИСО9000. Если не придавать слишком большого значения словам и искать аналогии. Наверное, на их сравнении можно нарыть научную новизну и прочее такое

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

[Andruxa]

Управление коммуникациями в проекте включает в себя процессы, необходимые для уверенности в своевременных и подходящих создании информации, сбору, распространению, получению и правильному размещению информации по проекту.

Всего пять процессов,

1. Идентификация стэйкхолдеров,
2. Планирование коммуникаций,
3. Распространение информации,
4. Управление ожиданиями стэйкхолдеров,
5. Отчетность об исполнении.

Проектные коммуникации делят на (но не ограничиваются этим):

• Внутренние и внешние для проекта,
• Формальные и неформальные,
• Вертикальные и горизонтальные,
• Официальные и неофициальные,
• Письменные и устные,
• Вербальные и невербальные.

Идентификация стэйкхолдеров - процесс определения всех людей и организаций, на которых оказывает влияние проект, документирование соответствующей информации об их интересах, вовлеченности, и влиянию на успех проекта. Предлагаются вниманию интересные инструменты анализа стейкхолдеров - различные решетки (по типу власть/интерес и другие), потом их классификация для выработки подхода к построению коммуникаций. На выходе процесса - реестр стэйкхолдеров + Stakeholder Management Strategy (подход к увеличению поддержки и минимизации негативных эффектов на протяжении всего жизненного цикла).

Планирование коммуникаций - определение кто будет от когда как и когда получать какую информацию. Инструмент - анализ коммуникационных каналов, коих n(n-1)/2, определение потребностей в информации, коммуникационные модели (отправитель-получатель) и тому подобное. На выходе он самый - communications management plan.

Распространение информации - процесс предоставления информации стэйкхолдерам как запланировано.

Управление ожиданиями - это процесс работы со стэйкхолдерами по удовлетворению их потребностей и адресации им проблем и задач (issues), если возникают. Вот так странно, если честно. Далее поясняется: управление ожиданием включает активности направленные на то, чтобы повлиять на их ожидания. Утверждается, что управление ожиданиями увеличивает вероятность project success, путем уверенности в том, что стэйкхолдеры в курсе и понимают проектные выгоды и риски.
В качестве инструментов управления ожидания нам предлагается использовать в том числе и interpersonal skills, установление доверия, разрешение конфликтов, активное слушание, преодоление сопротивления к изменениям.

Ну и последний процесс - отчетность по исполнению. Из практики - это самое важное для стэйкхолдеров (в основном, стэйкхолдеры из практики, это Заказчик, Руководство и Команда). Про процесс написано много и хорошо. Из моей же практики, отчетность для Заказчика и Руководства по проекту должна быть еженедельная. И включать как минимум следующее:

• Достигнутые результаты,
• Затраченные ресурсы (человеко-часы, оборудование, ПО),
• Поступления и затраты за неделю (только для руководства),
• Отклонения по затратам (фактические от плановых),
• Текущая планируемая премия проектной команды (только для руководства),
• Планируемые действия (с датами осуществления),
• Открытые вопросы (к руководству и к Заказчику).

[Andruxa]

Управление рисками - самое, пожалуй, сложное в проектах. Если всё остальное можно пощупать, то это надо осознавать (а сперва осознать - всё равно сложно). И тем не менее, рисками управлять необходимо, сколько раз видел, как теряется код продукта, слетают сроки из-за замен исполнителей, недостаток анализа выливается в коренные переделки прямо посреди проекта, решения у Заказчика принимаются дольше чем необходимо, короче говоря риски - они стреляют то там то тут в проектах. А маржа падает и падает

По PMBoK - цель управления рисками - увеличить вероятность положительных для проекта событий, и снизить вероятность отрицательно влияющих.

Процессы следующие (ничего не поменялось):
1. Планирование управления рисками,
2. Идентификация рисков,
3. Качественный анализ рисков,
4. Количественный анализ рисков,
5. Планирование реагирования на риски,
6. Управление рисками (Monitor and Control Risk).

Хорошо поясняется, что риск - всегда в будущем. Риск - неизвестное событие или условие, которое при проявлении затрагивает минимум одну цель проекта. Риск-менеджмент должен осуществляться в течении всего ЖЦ проекта.

Создание плана - это берем все другие планы, и на рабочей встрече по анализу рисков (только один инструмент) вырисовываем план управления рисками. План носит общий характер и описывает методологию управления рисками и ответственности в основном.

Идентификация рисков же - итеративный процесс сквозь весь ЖЦ. Для идентификации предлагаются как стандартные инструменты - брэйнстормы, дельфи, экспертная оценка, диаграммы, так и достаточно нестандартные в качестве анализа рисков. Например, SWOT-анализ попал в эту категорию. На выходе - такая важная штука, как реестр рисков.

Качественный анализ рисков - это процесс их структуризации (приоритезации, классификации...) для дальнейшего анализа или действий. Работа здесь идёт по оценке вероятности (occurence) и влияния (impact). Составляется как всегда табличка Вероятность-Влияние, теперь с подразделами Opportunities-Threats (раньше такого не было.... говорили что риск позитивное или негативное событие, теперь в анализе их делят). Ну и по произведению влияния на вероятность риск относят либо к терпимым, средним, и совсем неудобным.

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

Планирование реагирования на риски. Предлагается выбрать стратегии реагирования на оцененные риски. На выбор предлагается - избежание (avoid), передача на сторону (transfer), смягчение (mitigate) и принятие. Ну впрочем, те, кто хоть что-нибудь читал про риски, ничего тут нового не найдут. Однако. Выписываются и стратегии для позитивные "рисков", возможностей так скажем. Вот этого я нигде ранее не встречал в литературе. Что предлагается - использовать возможность (exploit) - это когда делается всё, чтобы событие наступило, делиться (share) - организовывать что-то совместно, улучшать (enhance) - увеличивать вероятность, принимать (accept) - не преследовать, а расслабиться и ждать. Весь этот процесс даёт нам изменения в проектном плане, других документах и контрактах.

Мониторинг и контроль рисков (вот что странно - в перечне процессов области содержания написано Monitor and Control Risk Responses, а в самой подглаве - Monitor and Control Risk). Ну, вобщем, это выполнение плана по риск-менеджменту в проекте, плюс определение, верны ли предположения проекта (assumptions - важная кстати штука), изменилось ли состояние каждого риска, процедуры по управлению рисками выполняются, резервы стоимости и времени соответствуют текущему состоянию рисков. Управление во многом аналогично многим другим процессам управления другими объектами.

[Andruxa]

Мое мнение по вопросу: управление содержанием и управление качеством разделили зря.

Да, есть тут сложности. До сих пор на практике жалобы на качество можно аргументированно отметать высказыванием "вне содержания" . Отсюда методологические проблемы - треугольник "объем работ - время - бюджет" дополняется качеством.

С другой стороны, качество такая категория, потери от которой можно оценить. В том же PMBoK приводится понятие "стоимости качества", так, в проекте может быть принято решение делать продукт среднего качества, а потом по гарантии устранять дефекты - это может быть дешевле чем производить сразу качественный продукт. В разработке ПО это вообще называется "отыграться на поддержке" - сначала сделаем как получится, а потом - на поддержку. Проблема в том, что стоимость поддержки куда сложнее оценить, нежели качественной разработки.

Резюмируя, на мой взгляд вся собака зарыта в следующем. Понятие качества - из области ЖЦ продукта, а понятие содержания - из области ЖЦ проекта. Проблема в том, что ЖЦ продукта и проекта могут пересекаться двумя способами:
1. Продукт - результат проекта. Проект завершается по разработке продукта (как, в общем-то PMBoK его и рассматривает, проект). Тогда качество и содержание можно сказать совпадают - с точки зрения WBS,
2. Продукт - промежуточный результат проекта. В проекте главное выйти на показатели ROI или что-то в этом роде. Тогда качество продукта - элемент содержания проекта.

[Andruxa]

Управление поставками - последняя область знаний PMBoK. Тут по-прежнему всё - поставки - они есть поставки, неважно поставляет компания, которая ведет проект, или этой компании поставляют.

Процессов тут четыре:
1. Планирование поставок,
2. Управление (conduct) поставками,
3. Администрирование поставок,
4. Закрытие поставок.

Далее речь идёт о контрактах. Что бывают мол простые, а бывают и сложные. По жизни так оно обычно сложности оформляются рамочным договором, а простота - доп. соглашениями.

Говорится о том, что у контракта есть жизненный цикл. Да и вообще, у всех объектов проекта есть свой жизненный цикл. Но вот уследишь ли вот за всем. "Вот в чем вопрос!". Но за контрактами следить необходимо. Всё остальное ерунда на самом деле. А вот что в договоре написано - то и будет в конечном итоге. Доходило в практике дело и до такого... но это - плохое проектное управление.

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

Управление (conduct, а не managing! в том смысле что это руководство, или ближе даже инициирование) поставками - это процесс получения ответов от продавцов, выбор продавца, заключение контракта. Тут всё более-менее понятно. Хотя написано всякого...

Администрирование (administer) поставок - это как раз управление отношениями, мониторинг выполнения контрактов, внесение изменений если надо. Английским по белому сказано, что администрирование контрактов включает в себя компоненты финансового менеджмента (что касается мониторинга платежей).

Мечта у меня. Чтобы все проекты были разбиты на равные кусочки с платежами. Поэтапно что называется. Но как ни крути - в разработке всегда провал. А ещё мечта о единой информационной системе для Заказчика и Поставщика. И чтобы changes в ней все жили. И чтобы все могли в неё ходить. И видеть что положено. А по жизни... кто куда. Сообщают хоть тушкой, хоть чучелом. А, ты - дорогой менеджер - всё секи (четыре чата, два телефона, несколько почт и вообще помни что сам сказал)!

Вот и в администрировании контрактов есть такой инструмент - Records Management System.

Закрытие поставок. На выходе - закрытые поставки. И обновления организационного процесса (описание поставки, deliverable acceptance - акт приемки-сдачи, усвоенные уроки).

На том поставка обзора закрывается. Усвоенные уроки - надо четче ставить цели перед изложением.

[john644]

Закрытие поставок. На выходе - закрытые поставки. И обновления организационного процесса (описание поставки, deliverable acceptance - акт приемки-сдачи, усвоенные уроки).

На том поставка обзора закрывается. Усвоенные уроки - надо четче ставить цели перед изложением.

А про усвоенные уроки можно подробнее

[Andruxa]

Да это моя личная привычка - слегка обесценивать сделанное ;)
У Козьмы Пруткова - "исполненное предприятие приятно щекочет самолюбие" - не мой случай.

Надо было как-то действительно чуть более подробнее вначале определиться с целями изложения. Тогда и получилось бы более полезно для тех, кто PMBoK знает, или не знает. А так для тех кто знает - ничего нового, а для тех кто не знает - всё равно всё читать.

Не графоман я однако.

[Михаил_Шустер]

Тогда и получилось бы более полезно...

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

[Евгений_Кс]

На том поставка обзора закрывается. Усвоенные уроки - надо четче ставить цели перед изложением.

Присоединяюсь к Шустеру - другими словами.
Мой способ преодоления собственной лени - связать себя внешними обязательствами.
Вы наверняка сами лучше разобрались в последнем PMBoK'е, попрактиковались в английском.
Многим, уверен, Ваши посты были полезны, в частности, мне.
Так что все нормально.
Форум - отличное место повышения собственной квалификации.

[Еремченко Сергей]

Спасибо, с PMbok знаком не был. Наверное, поэтому обзоры последних глав в совокупности с личным опытом вызвали интерес.

[Andruxa]

тут был урл

[Владимир Либерзон]

Навели... делюсь. http://ifolder.ru/16715269

PMBOK Guide на русском языке еще не вышел.