6 сигм

Продолжаю публиковать конспекты семинаров, посвященных методологиям управления проектами. Сегодня пишу о системе 6 сигм (Six Sigma)

Оглавление

Введение в 6 сигм

Статистические основы «Шесть Сигм»

DMAIC (Define-Measure-Analyze-Improve-Control) — методология улучшения существующих процессов.

DFSS — (Design for six sigma) — методология создания новых процессов.

Организационная схема

Принципы 6 сигм

Программное обеспечение для 6 сигм.

Что мне показалось полезным

Практические наработки по числовым методам

Умение сделать и продвигать брэнд

Подход «сверху вниз» к оцениванию проекта

Введение в 6 сигм

Как отмечают многие специалисты, в 6 сигмах нет ничего оригинального. Тоесть это — компиляция ранее имевшихся подходов.

Фактически 6 сигм можно описать четырьмя утверждениями (наиболее сложно — первое, наиболее важно - третье)

1. Для оценки качества проекта используется средней сложности мат модель, основанная на нормальном распределении отклонения качества изделия от идеала. Модель в итоге выражает количество бракованных изделий через отношение максимально допустимого отклонения от идеала к среднему отклонению. Среднее отклонение называется сигмой. Отношение, к которому надо стремиться по мнению авторов методологии равно 6ти. Отсюда — 6 сигм. При этом отношении количество брака на миллион изделий — 3,4. (Для сравнения при отношении равном трем — 66800 дефектов.)

   Вся эта мат модель сама по себе НИЧЕГО не предлагает в плане улучшения качества, потому что в нее не заложено никаких методов собственно улучшения. Грубо говоря, все что следует из этой модели, (которая разрекламирована как ЯДРО подхода) это такой факт: Нужно стремиться выпускать изделия, которые в 6 раз лучше самых плохих допустимых изделий и тогда все будет здорово и никакие случайности будут не страшны. Таким образом, сама мат модель НИКАК не используется в процессе работы над проектом, а служит симпатичной иллюстрацией и придает подходу солидности. (используется только эта цифра 6, полученная раз и навсегда из модели)

2. Для собственно улучшения процессов, ничего особенного не предлагается. Точнее утверждается, что методология основана на постановке агрессивных краткосрочных целей в борьбе за долгосрочные цели. Что вся работа по улучшению состоит из маленьких проектиков, каждый из которых строится согласно циклу, с умным названием DMAIC (Define-Measure-Analyze-Improve-Control). Подобный же цикл используется в туче других подходов.

3. Реальным смыслом и рациональным зерном подхода является стремление к полной измеримости всех факторов, влияющих на конечный результат и к построению модели зависимости количества дефектов от каждого из факторов. С последующим выявлением групп, от которых каждый фактор зависит и планированием мероприятий по улучшению наиболее значимых факторов. Создается полное ощущение, что так называемые, черные пояса по 6 сигм — это стандартные хорошие управленцы с некоторым перекосом в сторону измеримости процессов. А все остальное — антураж, созданный для повышения их рыночной стоимости.

4. Для придания цветистости и зарабатывания на подходе денег, придуманы степени крутости с цветными поясами, как в карате и создана целая индустрия по подготовке этих поясов за большие деньги.

При этом, все вышесказанное не умаляет достоинств специалистов по 6 сигм. Многие из них — очень сильные управленцы. Скорее стоит говорить об удачном маркетинге, сделавшем термин 6 сигм раскрученным. Я бы говорил о 6 сигм, как об одной из профессиональных школ управления с акцентом на применение численных методов. Стоит отметить также большой набор математических моделей проектов, проверенных специалистами этой школы на практике. Эти модели отличает простота и практическая применимость. Хотя, многие из моделей созданы вовсе не в рамках 6 сигм. Хорошие специалисты по 6 сигм являются фактически специалистами в области управления проектами и в области прикладной математики (в основном численных методов и статистического анализа)

Далее немного подробнее.

Статистические основы «Шесть Сигм»

Этот раздел написан не мной, а взят с сайт www.six-sigma.ru. Переписывать своими словами смысла не было. Раздел носит справочный характер и рассказывает подробнее о математической модели из которой получена цифра 6 (из названия методологии). Раздел рассчитан на любознательных, желающих понять эту модель. Практического смысла в этом, как уже отмечалось, не много.

Любой процесс может быть представлен в виде математической модели, где основными параметрами результата процесса выступают среднее значение и стандартное отклонение. Параметр среднее значение отвечает на вопрос как работает процесс в среднем и обозначается символом µ (мю). Стандартное отклонение показывает степень вариабельности результата процесса и обозначается символом σ (сигма).

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

Рисунок 1. Типичный вид плотности и функции нормального распределения

Геометрически, хорошая наглядная картина получается, рассматривая плотность нормального распределения, где среднее значение – это пик плотности распределения, а стандартное отклонение

определяется как расстояние между средним значением и точкой перегиба кривой (рис 2).

Рисунок 2. Среднее значение и стандартное отклонение

Свойства нормального распределения:

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

Рисунок 3. Чем больше сигм процесса укладывается между средним значением и ближайшим контрольным пределом, тем меньше дефектов имеет процесс. Процесс работает на уровне 2,6 сигмы.

Из статистического обоснования известно, что при уровне процесса 4,5 сигм, из миллиона единиц продукции, дефектов будет не более 3,4, и это условие выполняется для стабильных процессов. В настоящих же условиях, поведение процессов может меняться со временем года, временем суток и т.п. (рис. 4).

Рисунок 4. Изменение процесса с течением времени.

Основываясь на эмпирических данных, исследователи пришли к выводу, что отклонения процесса, вызванные его естественной нестабильностью, дают отклонения качества на уровне 1,5 сигма. Таким образом, если целевой уровень качества составляет 4,5 сигма (3,4 дефекта на миллион возможностей), то с учетом перестраховки 1,5 сигма на отклонения, необходимо обеспечивать уровень качества 6 сигм.

Рисунок 5. Уровень качества 6 Сигм.

Таблица пересчета % в сигма уровни с учетом 1,5 сигма сдвига и ДНМВ:

Чем меньше сигм — тем больше дефектов. Оптимальное число сигм — 6. При котором число дефектов на миллион операций — 3,4

При сигма = 3 дефектов будет уже 66800. А при единице — 690 тысяч....

%	Сигма уровни	Дефектов на миллион возможностей		%	Сигма уровни	Дефектов на миллион возможностей
99.9997	6.00	3.4		93.3200	3.00	66800
99.9995	5.92	5		91.9200	2.90	80800
99.9992	5.81	8		90.3200	2.80	96800
99.9990	5.76	10		88.5000	2.70	115000
99.9980	5.61	20		86.5000	2.60	135000
99.9970	5.51	30		84.2000	2.50	158000
99.9960	5.44	40		81.6000	2.40	184000
99.9930	5.31	70		78.8000	2.30	212000
99.9900	5.22	100		75.8000	2.20	242000
99.9850	5.12	150		72.6000	2.10	274000
99.9770	5.00	230		69.2000	2.00	308000
99.9670	4.91	330		65.6000	1.90	344000
99.9520	4.80	480		61.8000	1.80	382000
99.9320	4.70	680		58.0000	1.70	420000
99.9040	4.60	960		54.0000	1.60	460000
99.8650	4.50	1350		50.0000	1.50	500000
99.8140	4.40	1860		46.0000	1.40	540000
99.7450	4.30	2550		43.0000	1.32	570000
99.6540	4.20	3460		39.0000	1.22	610000
99.5340	4.10	4660		35.0000	1.11	650000
99.3790	4.00	6210		31.0000	1.00	690000
99.1810	3.90	8190		28.0000	0.92	720000
98.9300	3.80	10700		25.0000	0.83	750000
98.6100	3.70	13900		22.0000	0.73	780000
98.2200	3.60	17800		19.0000	0.62	810000
97.7300	3.50	22700		16.0000	0.51	840000
97.1300	3.40	28700		14.0000	0.42	860000
96.4100	3.30	35900		12.0000	0.33	880000
95.5400	3.20	44600		10.0000	0.22	900000
94.5200	3.10	54800		8.0000	0.09	920

DMAIC (Define-Measure-Analyze-Improve-Control) — методология улучшения существующих процессов.

Тот же самый сайт www.six-sigma.ru так описывает эту методологию:

Из программы по борьбе с дефектами концепция «Шесть сигм» превратилась в философию качества, основанную на постановке агрессивных краткосрочных целей в борьбе за долгосрочные цели. Работа по совершенствованию процессов происходит в виде небольших проектов. Проекты совершенствования по системе «Шесть сигм» могут быть разными по длительности и экономическому эффекту, могут затрагивать одно или сразу несколько подразделений компании, но все они следуют методологии DMAIC

Основные цели каждого из этапов:

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

DFSS — (Design for six sigma) — методология создания новых процессов.

В отличие от методологии DMAIC подход DFSS (Design for Six Sigma) применяется при разработке новых продуктов или услуг в соответствии с критериями и принципами «Шести сигм».

Это означает что новый продукт будет иметь минимально возможное количество дефектов. А для этого нужно понять потребности и ожидания клиента еще до того как новый продукт будет создан.

Одна из наиболее распространенных методологий, которые применяются в данном подходе это DMADV:

Define - Определение

Определение цели и масштабов проекта и требований заказчика (как внешнего так и внутреннего).

Measure - Измерение

Измерение потребностей и спецификаций клиентов. Бенчмаркинг в данной отрасли.

Analyze - Анализ

Анализ параметров процесса для достижения соответствия требованиям заказчиков.

Design - Проектирование

Детальная разработка процесса для достижения соответствия требованиям заказчиков.

Verify – Проверка

Проверка разработанного процесса, в том числе на его соответствие нуждам клиента.

Проекты DFSS осуществляются по тем же принципам и с опорой на ту же инфраструктуру, что и проекты совершенствования DMAIC.

Проекты осуществляют межфункциональные команды.

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

На самом деле большой разницы между DMAIC и DMADV я не заметил. Improve-Control в применении к существующим процессам против Design — Verify в применении к вновь сконструированным. Похоже на тавтологию.

Организационная схема

В основе орг схемы -

• руководящий совет - который планирует стратегию внедрения, осуществляет выбор и утверждение проектов. Руководство проходит минимальный курс обучения, необходимый для контроля и управления программой «Шесть сигм».

• За поддержку проекта и его результаты будет отвечать «чемпион» - один из представителей высшего руководства. Чемпионы проходят 1-2 дневный ознакомительный курс обучения, где большое внимание уделено выбору проектов.

• есть парни с цветными поясами, которые овладели статистическими методами и опытом ведения проектов по 6ти сигмам. «Продажа» поясов — основной бизнес консультантов, специализирующихся в этой теме. Собственно, поясов два — черный и зеленый. Отличаются крутизной. Последнее время появляются еще белый и желтый, которые, как я понял, щедро дают людям, что-то слышавшим о 6 сигмах и что-то из этого понявших соответственно.

Принципы 6 сигм

Чистой воды слоганы (кроме принципа №2) , подобранные, чтобы принципов было ровно 6 (по числу сигм) , но все же вот они:

1. Искренний интерес к клиенту

2. Управление на основе данных и фактов

3. Ориентированность на процесс, управление процессом и совершенствование процесса

4. Проактивное (упреждающее) управление

5. Сотрудничество без границ (прозрачность внутрикорпоративных барьеров)

6. Стремление к совершенству плюс снисходительность к неудачам

Программное обеспечение для 6 сигм.

Есть много готового софта для работы по 6 сигм.

Список здесь. http://www.six-sigma.ru/page_207.html

Что мне показалось полезным

Практические наработки по числовым методам

Ребята с черными поясами наработали немалый опыт применения конкретных числовых методов (например, методов Монте Карло) и массу эмпирических уравнений, которым подчиняются численные характеристики проектов. Они проверили все это статистически и имеют готовые методы, которые позволяют на основе ранее сделанных организацией проектов найти различные коэффициенты, характерные для этой организации и далее, подставив их в уравнения, получать, например, весьма достойные оценки для проектов (в том числе IT проектов).

Хорошо об этом написано , например , в статье (http://software.isixsigma.com/library/content/c030514a.asp)

Они красиво показывают, что их методы (хотя и не идеальны), работают намного точнее и лучше, чем оценки на основе интуиции.

В математике ребята в целом не очень сильны, поэтому уравнения простые и очень приблизительные, но я чувствую, что они полезны.

Умение сделать и продвигать брэнд

Стоит подробнее изучить — как именно авторам удалось, не придумав ничего нового, раскрутить торговую марку «6 сигм» до такой степени. Наработки могут быть полезны в раскрутке своего продукта.

Подход «сверху вниз» к оцениванию проекта

Кроме широко используемого нами подхода снизу вверх (когда проект бьется на задачи и оценивается, а затем оценки суммируются используя PERT + находится критический путь и дается календарная оценка), специалисты по 6 сигм (на самом деле не только они, конечно) активно используют подход сверху вниз, когда оценка дается исходя из числовых характеристик проекта, который надо сделать (к-во строк кода, кэйсов, функций, объектов и т п) и количественных характеристик проектной команды (которые получаются с использованием статистических методов). Подход и используемая математика хорошо описан в той же самой статье (см выше). Очень удобен при раскрутке проекта и наборе статистических данных. Понравилось, что при оценке используются, например эмпирические знания о количестве людей, необходимых на разных стадиях проекта, что позволяет избежать глупых ошибок с оценка длительности проекта (типа проект в человеко-год делается 3мя людьми за 4 месяца). Забавно, что график «потребления людей» практически одинаков для всех проектов и выглядит примерно так:

Подход обычно оказывается пессимистичнее и точнее привычного, поскольку учитывает эмпирические зависимости затрат от размера проекта, от требуемого календарного дидлайна, от конкретной команды. Кроме того, основываясь на исторических данных, он лучше оценивает риски. (поскольку в реальных проектах они были). Однако, есть у него и недостатки. Например, он плохо учитывает динамику развития как команды так и технологий, предполагая, что и то и другое неизменно. Предлагается использовать этот подход наряду с традиционным.

Читать полностью...

Что такое PRINCE2

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

Оглавление

Введение

Личные впечатления

Об описание методологии

Процесс и активности

Организационная структура

Business case oriented

О продуктах и проектах

Чего в PRINCE нет

Описания техник для остальных 5ти из 8ми компонентов

Управления людьми

Управления поставками и контрактами

Воды

Введение

PRINCE2 — английский стандарт на ведение проектов. Изначально создан для IT проектов, потом расширен для использования в любых проектах.

PRINCE2 — основан на четком процессе, разбитом на 8 стадий и 45 подстадий. В этом он подобен RUP. У каждой стадии есть свой набор целей, активностей а также входных и выходных артефактов. Есть критерии, по которым можно судить о качестве артефактов. Они позволяют контролировать отклонения от качества в течение жизненного цикла проекта.

Особенностью стандарта является его масштабируемость. В каждой стадии и подстадии описано, какую ее часть можно опустить, если проект маленький и гигантский масштаб процессов не требуется. С одной стороны, это очень мило, с другой, отмечается появление большого количества так называемых PINO (Prince in name only) проектов, в которых опущено почти все, но они гордо зовутся сделанными по методологии PRINCE2.

Личные впечатления

Писано Itшниками и для Itшников, что бы там не говорили про пригодность для любого проекта.

Причем Itшниками практикующими. Авторы имели личный опыт управления IT проектами. А к самому документу отнеслись как к софту. Очень четко его написали. Воды (в отличие от PMBOK) почти нет. Нет также пространных размышлений что с одной стороны важно то, с другой это, и нужно обладать опытом, чтобы бла бла (этим также изобилует PMBOK)

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

Документ очень хорошо и четко структурирован. Позволяет изучать его последовательно.

Стандарт является методологией, пригодной к непосредственному использованию для выполнения проектов (по крайней мере IT проектов).

Об описание методологии

В официальном документе методология описывается «сверху — вниз». От абстрактных уровней, к конкретному их наполнению.

Начато с того что там 8 стадий процесса (например старт проекта, стратегическое управление проектом) и 8 компонентов/аспектов (планирование, управление изменениями и т п).

Затем детализирована каждая стадия по активностям (или подстадиям) (их уже 45), входящим и исходящим артефактам, критериям, позволяющим активность начать.

Затем описаны связи между активностями (в итоге получаем некую «трехмерную сеть», как оно в жизни и бывает). Указаны какие из 8ми компонентов (аспектов) являются актуальными для каких из 45ти подстадий. Забавно, что у каждой из 45 подстадий есть уникальный идентификатор из одной буквы (первая в названии стадии) и цифры — (порядковый номер в стадии). Сразу видно руку Itшников. :-)

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

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

Процесс и активности

Стадии в PRINCE не являются последовательными. Зависимости между ними более сложные , но прописаны они четко.

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

А при описании активностей часто попадаются ссылки на другие активности, которые должны идти в параллель и с которыми надо обмениваться информацией (артефактами)

Понравилась, что PRINCE выделяет в отдельные процессы старт проекта и его инициацию, подготовку нужных групп людей, пониманию осмысленности (или не осмысленности проекта).

Организационная структура

Интересен подход PRINCE к оргструктуре проекта.

Есть менеджер проекта в традиционном понимании.

Есть совет проекта (project board), перед которым регулярно отчитывается менеджер. Состоит из 3х человек — Заказчика, Главного пользователя и Главного специалиста. Совет проекта ответственен за принятие стратегических решений. Менеджер проекта обязан отслеживать возможные проблемы и предлагать совету альтернативные решения. Совет решает — какой путь лучше.

Есть служба project assurance цель которой предоставлять независимое мнение о проекте с точки зрения тех же трех групп людей — заказчиков, пользователей и специалистов (в предметной области)

Служба готовит три отчета — buniness report, user report & technical report.

В первый входит отчет о финансовом состоянии проекта и выгодности проекта в целом.

Во второй — отслеживание того, насколько хорошо выполняются требования пользователей

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

В маленьких проектах роль project assurance выполняет совет проекта. В больших это — отдельная группа.

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

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

Стадии и компоненты

Стадии:

• Starting Up a Project (SU)

  Смысл стадии — понять, а надо ли вообще проект делать. Описать причины проекта в документе Мандат Проекта. Выбрать подход к выполнению проекта.

• Initiating a Project (IP)

  Здесь описывается Бизнес Кейс проекта, формируется орг структура. Планируется сроки и цена проекта.

• Planning (PL)

  Планирование и перепланирование проекта. Идет все время жизни проекта.

• Directing a Project (DP)

  Стратегическое управление проектом. Выполняется Project Board-ом на основе документов, предоставленных менеджером проекта и Project Assurance. Менеджер обязан отслеживать возможные риски и возможности проекта и формулировать вопросы к PB. Желательно, чтобы на них можно было ответить да или нет. PB принимает решения. Причем каждый член PB должен отстаивать свой аспект — бизнес, usability и технологический соответственно.

• Controlling a Stage (CS)

  Стандартные активности по ежедневному управлению проектами при помощи контура управления. Осуществляются менеджером проекта.

• Managing Product Delivery (MP)

  Активности по обеспечению создания нужных продуктов в нужные моменты времени. Осуществляются менеджером проекта.

• Managing Stage Boundaries (SB)

  Активности по подготовке и предоставлению информации Project Boardу.

• Closing a Project (CP)

  Активности по контролируемому закрытию проекта.

Компоненты :

• Business case

• Организация

• Контроль

• Управление рисками

• Управление конфигурациаями

• Планы

• Управление качеством

• Управление изменениями

Business case oriented

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

О продуктах и проектах

Забавен «рекурсивный» подход, продвигаемый авторами PRINCE. Например, вместо выделения скажем прототипирования в отдельный этап проекта, утверждается что проекты могут состоять из проектов и прототипирование — отдельный проект, который можно делать по методологии PRINCE. Как отдельный проект может быть выделен проект по пониманию, а нужно ли вообще наш проект делать и тп. Явно прослеживается стремление к обобщению и борьба с расползанием, которого так много в PMBOK

Аналогично, термином «продкут», называют как сам продукт, который надо произвести, так и любую его часть, а также существующие продукты, которые надо задействовать при производстве и продукты, которые при производстве произвести придется (например любой проектный документ — тоже продукт, а написание его можно считать проектом, который можно делать по методологии PRINCE) :-)

При планировании, вместо традиционного WBS используют PBS — Product Breakdown Structure, которая разбивает целевой продукт на непересекающиеся подпродукты (в том числе и проектная документация туда входит)

Чего в PRINCE нет

Описания техник для остальных 5ти из 8ми компонентов

Тоесть для

• Business case

• Organisation

• Controls

• Management of Risk

• Configuration management

Хотя первые три «разжеваны» очень хорошо, а вторые две сильно зависят от характера проекта.

Для остальных трех техники описаны:

• Plans

• Quality Management

• Change control

Управления людьми

Остаётся вне контекста, кроме описания орг. Структуры. Ничего про мотивацию и т п

Управления поставками и контрактами

Утверждается что, например, заключение контракта - проект, который надо делать по методологии PRINCE2 (см о продуктах и проектах)

Воды

Никаких лишних рассуждений за жизнь

Читать полностью...

Что такое PMBOK

Внимание ! Здесь идет речь о 3м издании PMBOK.

В 4м издании все очень сильно изменилось !

Вместо эпиграфа:

PMI не несет ответственность за любые травмы, повреждения, нанесенные собственности,

или любые другие убытки, будь то реальные, косвенные или компенсаторные,

произошедшие непосредственно или косвенно

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

(PMBOK, 3е издание 2004г)

Оглавление

О чем этот документ

Что такое PMBOK

Основная концепция PMBOK

Что еще есть в PMBOK

Много базовых определений

Определение места PMBOK относительно управления проектами

Определение жизненного цикла проекта

Классификация участников проекта

Место проектов в организациях различных типов

Группы процессов

Области знаний

Управление интеграцией проекта

Управление содержанием проекта

Управление сроками проекта

Управление стоимостью проекта

Управление качеством проекта

Управление человеческими ресурсами проекта

Управление коммуникациями проекта

Управление рисками проекта

Управление поставками проекта

Распределение процессов по группам и областям знаний

Основные документы проекта

Описание процессов PMBOK на примере процессов планирования качества

Входы

Инструменты и методы

Выходы

Развитие PMBOK

О чем этот документ

Данный документ не пытается заменить собой PMBOK , путем пересказа его своими словами. Вместо этого он пытается дать ответ на вопрос — что такое PMBOK, какова основная концепция данного стандарта и какова структура документа, стандарт описывающего. Далее приводится краткое описание 5ти групп процессов и 9ти областей знаний.

Наконец, в качестве примера разбирается несколько процессов. Цель примера — дать представления о способе подачи информации о процессе и о соотношении между такими базовыми для PMBOK понятиями как процесс, группа процессов и область знаний.

Цель документа — дать общее представление о стандарте и отправную точку для его изучения.

Что такое PMBOK

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

Характерным является такое наблюдение: на официальных сайтах практически всех методологий управления проектами (RUP, PRINCE2, MSF и т п) в обязательном порядке присутствует статься «Наша методология и PMBOK». В статье сравнивается PMBOK с соответствующей методологией и делается один и тот же вывод — наша методология и PMBOK ни в коей мере не противоречат друг другу.

Таким образом, PMBOK — наиболее полное изложение знаний, признаваемых сообществом менеджеров проектов. Он задает некоторые рамки для более практических и узконаправленных методологий, но сам методологией пригодной к непосредственному практическому применению не является. Является основой для создания практических методологий.

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

Основная концепция PMBOK

PMBOK выделяет 44 основных процесса, которые происходят при управлении проектами. Эти процессы с одной стороны распределяются по 5ти группам процессов (например группа процессов планирования или группа процессов исполнения) а с другой, каждый из них относится ровно к одной из 9ти, определяемых PMBOK областей знаний. (например — управление сроками или управление качеством).

Каждый из процессов подробно описан. Описания процессов и составляют основной объем 400 страничного мануала. Описания хорошо структурированы. В частности, каждое из описаний процессов обязательно включает 3 основные части:

1. Входы

2. Выходы

3. Инструменты и методы

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

Выходами процесса являются некоторые артефакты. Это или документы, или части создаваемого продукта ну или сам продукт.

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

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

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

Хотя все процессы очевидным образом связаны — поскольку четко определены выходы каких процессов являются для каких процессов входами, PMBOK несколько раз акцентирует внимание на том, что в реальности процессы не идут последовательно один за другим, а происходят параллельно и являются взаимосвязанными.

Цитата:

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

PMBOK отказывается устанавливать эти связи между процессами, заявляя, что они слишком сложны, разнообразны и зависимы от конкретного наполнения проекта и ситуации. Вместо установления таких связей, PMBOK определяет в качестве одной из своих девяти областей знаний «управление интеграцией проекта». Именно этот аспект призван установить и поддерживать нужные связи в актуальном состоянии. На мой взгляд, среди девяти определенных PMBOK областей знаний, управление интеграцией занимает особое место. Это, например, подтверждается тем фактом, что план проекта, согласно PMBOK, состоит из 8ми документов, каждый из которых прямо соответствует планированию активностей в одной из областей знаний. Всех, кроме управления интеграцией. Этим PMBOK как бы хочет сказать, что управление интеграцией не поддается планированию :-). Таким образом, фактически, управление интеграцией выглядит как область «мета-знаний» и находится «над» остальными областями. (эти утверждения — мое личное мнение)

Характерно, что в методологиях (вроде PRINCE2) связи между процессами заданы четко.

Что еще есть в PMBOK

Кроме основной концепции и описания процессов, PMBOK содержит множество дополнительной информации. Здесь перечисляю наиболее значимую.

Много базовых определений

Будучи «энциклопедией», PMBOK включает такие базовые определения, как определение проекта, результатов проекта, управления проектом, последовательной разработки а также описывает отличия проектной деятельности от операционной.

Определение места PMBOK относительно управления проектами

Утверждается, что кроме всего прочего, в каждом проекте должны участвовать эксперты из как минимум 5ти областей знаний

• Свод знаний по управлению проектами

• Знания, стандарты и нормативные акты, относящиеся к данной области

приложения

• Понимание окружения проекта

• Знания и навыки в области общего менеджмента

• Навыки межличностных отношений.

Далее показывается место PMBOK в этих знаниях:

Потом рассказывается о каждой из этих экспертных областей. Что она такое и что в нее входит. На уровне определений.

Определение жизненного цикла проекта

Далее дается определение жизненного цикла проекта. Говорится, что проект можно бить на фазы.

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

Классификация участников проекта

К ключевым участникам любого проекта относятся:

• Менеджер проекта. Лицо, ответственное за управление проектом.

• Заказчик/пользователь. Лицо или организация, которые будут использовать продукт проекта. Может существовать множество уровней заказчиков.

• Исполняющая организация. Предприятие, чьи сотрудники непосредственно участвуют в исполнении проекта.

• Члены команды проекта. Группа, которая выполняет работы по проекту.

• Команда управления проектом. Члены команды проекта, непосредственно занятые в управлении его операциями.

• Спонсор. Лицо или группа лиц, предоставляющая финансовые ресурсы – деньгами или в натуральном выражении – для проекта.

• Источники влияния. Лица или группы, которые напрямую не связаны с получением или использованием продукта проекта, но которые, в связи с их положением в организации-заказчике или исполняющей организации, могут положительно или отрицательно повлиять на ход выполнения проекта. Сюда иногда вносят внешние источники, например, зеленых, не дающих построить дом в центре заповедного болота.

• Офис управления проектом (PMO). Если в исполняющей организации имеется этот офис, он может быть участником проекта, если он несет прямую или непрямую ответственность за результаты проекта.

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

Место проектов в организациях различных типов

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

Рассматривается роль Project Management Office в управлении проектами и в частности в создании и поддержании корпоративной системы управления проектами, под которой понимаются «набор инструментов, методов, методологий, ресурсов и процедур, используемых для управления проектом.»

Группы процессов

Все процессы разделены на пять групп

• Группа процессов инициации. Определяет и авторизует проект или фазу проекта.

• Группа процессов планирования. Определяет и уточняет цели и планирует действия, необходимые для достижения целей и содержания, ради которых был предпринят проект.

• Группа процессов исполнения. Объединяет человеческие и другие ресурсы для выполнения плана управления проектом данного проекта.

• Группа процессов мониторинга и управления. Регулярно оценивает прогресс проекта и осуществляет мониторинг, чтобы обнаружить отклонения от плана управления проектом, и, в случае необходимости, провести корректирующие действия для достижения целей проекта.

• Группа завершающих процессов. Формализует приемку продукта, услуги или результата и подводит проект или фазу проекта к правильному завершению.

Говорится о переходе от простейшего взгляда на процесс как контур управления к «интеграционному пониманию процессов»

Области знаний

PMBOK определяет и описывает девять областей знаний и распределяет по ним 44 процесса управления проектами.

Управление интеграцией проекта

Как уже отмечалось — интеграция — это магический термин для определения всего непонятного и непрогнозируемого :-)

А вот так определяет управление интеграцией сам PMBOK:

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

Процессы управления проектами обычно представляются в виде дискретных элементов с хорошо разработанными интерфейсами, в то время как на практике они накладываются друг на друга и взаимодействуют между собой такими путями, которые не могут быть достаточно подробно описаны в Руководстве PMBOK®

Управление содержанием проекта

Процессы по включению в план проекта всех необходимых и только необходимых работ для

успешного выполнения проекта. Эта область знаний содержит следующие процессы управления проектами:

• планирование содержания проекта,

• определение содержания,

• создание ИСР,

• подтверждение содержания

• управление содержанием.

Управление сроками проекта

процессы, касающиеся выполнения проекта в установленные сроки. Эта область знаний содержит следующие процессы управления проектами:

• определение состава операций,

• определение взаимосвязей операций,

• оценка ресурсов операций,

• оценка длительности операций,

• разработка расписания и управление расписанием.

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

Управление стоимостью проекта

процессы, касающиеся планирования, оценки, разработки бюджета и контролирования

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

• стоимостная оценка,

• разработка бюджета расходов и

• управление стоимостью.

Управление качеством проекта

процессы по выполнению целей проекта. Эта область знаний содержит следующие процессы

управления проектами:

• планирование качества,

• процесс обеспечения качества и

• процесс контроля качества.

Управление человеческими ресурсами проекта

процессы по организации и управлению командой проекта. Эта область знаний содержит

следующие процессы управления проектами:

• планирование человеческих ресурсов,

• набор команды проекта,

• развитие команды проекта и

• управление командой проекта.

Управление коммуникациями проекта

процессы, касающиеся своевременного и достоверного составления, сбора, распределения,

хранения и использования информации по проекту. Эта область знаний содержит следующие процессы управления проектами:

• планирование коммуникаций,

• распространение информации,

• отчетность по исполнению и

• управление участниками проекта.

Управление рисками проекта

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

процессы управления проектами:

• планирование управления рисками,

• идентификация рисков,

• качественный анализ рисков,

• количественный анализ рисков,

• планирование реагирования на риски,

• мониторинг и управление рисками.

Управление поставками проекта

приобретения или получения продуктов, услуг и результатов, а также процессы

управления контрактами. Эта область знаний содержит следующие процессы управления

проектами:

• планирование покупок и приобретений,

• планирование контрактов,

• запрос информации у продавцов,

• выбор продавцов,

• администрирование контрактов и

• закрытие контрактов.

Распределение процессов по группам и областям знаний

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

Таблицу привожу исключительно для любопытных. Без полного изучения PMBOK толку от нее никакого.

Основные документы проекта

В Руководстве PMBOK® описываются три основных документа, каждый из которых имеет определенное назначение:

• Устав проекта. Является официальной авторизацией проекта.

• Описание содержания проекта. Содержит описание работы, которую предстоит выполнить, и результатов поставки, которые надлежит произвести.

• План управления проектом. Содержит описание того, как работа будет выполняться.

Последний документ (план управления проектом) делится на 8 кусочков в соответствии с областями знаний. На самом деле областей знаний 9, но мы планируем только 8, не планируя управление интеграцией проекта. Видимо потому, что управление интеграцией не поддаётся планированию и не является самостоятельным аспектом проекта. Управление интеграцией — это понимание того, что все процессы в проекте взаимосвязаны и действие в соответствии с этой установкой.

Описание процессов PMBOK на примере процессов планирования качества

В область знаний «Управление качеством» входит три процесса. Процесс планирования качества, процесс обеспечения качества и процесс контроля качества. Здесь рассмотрим только процесс планирования качества. Цель — иллюстрировать метод подачи материала в PMBOK.

Как и во всех других случаях, для процессов планирования качеством описываются входы, выхода а также инструменты и методы. Я даю их в сокращенном варианте, достаточном для того чтобы понять о чем идет речь.

Входы

.1 Факторы внешней среды предприятия

На проект могут оказывать влияние нормативные акты правительственных организаций, правила, стандарты и предписания, свойственные определенным областям приложения

.2 Активы организационного процесса

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

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

.3 Описание содержания проекта

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

В состав описания содержания проекта могут входить допустимые пороговые величины, критерии приемки проекта. Также могут быть описаны потенциальные проблемы и откуда можно их ждать.

4. План управления проектом

Инструменты и методы

.1 Анализ прибыли и затрат

При планировании качества необходимо принимать во внимание соотношение прибыли и затрат. Основная выгода от выполнения требований к качеству заключается в уменьшении числа доработок.

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

.2 Бенчмаркинг

Бенчмаркинг включает в себя сопоставление действующего или планируемого проекта с другими проектами с целью выработать идеи для усовершенствования и критерии оценки исполнения.

.3 Планирование экспериментов

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

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

Анализ экспериментальных данных должен способствовать разработке оптимальных условий для продукта или процесса, обнаружению факторов, оказывающих влияние на результат, и выявлению взаимодействий и синергизма этих факторов.

Очень похоже на методы, пропагандируемые в 6 сигмах.

.4 Стоимость качества (СК)

Стоимость качества – это совокупная стоимость всех действий, направленных на повышение качества продукта или услуги и обеспечение их соответствия определенным требованиям, а также на предупреждение факторов, способных вызвать снижение качества продукта или услуги и их несоответствие требованиям (доработка). Издержки вследствие отказа часто подразделяются на внутренние и внешние. Такие издержки иначе называют "стоимостью низкого качества".

.5 Дополнительные инструменты планирования качества

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

номинальных групп, матричные диаграммы, диаграммы зависимостей и матрицы назначения приоритетов.

Выходы

.1 План управления качеством

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

2. Результаты оценки качества

На мой взгляд термин результаты не удачен, поскольку речь идет не о результатах процесса, а о выборе величин, которые мы будем контролировать и на основе которых будем судить о качестве. И выборе способа измерений этих величин.

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

результаты поставки, и если так, то какие именно. В качестве примеров результатов оценки качества можно привести: плотность вероятности дефектов, частота отказов, степень готовности, надежность и тестовое покрытие (неисправностей).

.3 Контрольные списки процедур контроля качества

Контрольный список – это структурированный документ, обычно относящийся к определенным элементам, который используется для подтверждения выполнения всех намеченных операций. Контрольные списки могут быть простыми или сложными. Они обычно формулируются в повелительном наклонении ("Сделайте ... !") или вопросом ("Сделали ли Вы ... ?").

.4 План совершенствования процессов

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

.5 Базовый план по качеству

В базовом плане по качеству содержатся требования к качеству данного проекта. Служит

основой для оценки и составления отчетов по исполнению требований качества.

.6 План управления проектом (обновления)

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

Здесь речь идет о том, что в процессе управления качеством затрагиваются некоторые проектные документы и их нужно менять, согласно процессу управления изменениями.

Развитие PMBOK

Важно отметить, что в последнюю версию PMBOK внесли agile методы, как имеющие право на жизнь, наряду с водопадами.

Читать полностью...