УПРАВЛЕНИЕ КОМПАНИЕЙ С ИСПОЛЬЗОВАНИЕМ

МЕТОДА КРИТИЧЕСКОЙ ЦЕПИ

Евгений Пикулев,

Компания «Гибкие технологии»

Август 2014 года

Меня зовут Евгений Пикулев

Профессиональный руководитель проектов

Бизнес-тренер и консультант по дисциплинам, связанным с управлением проектами

Руководитель Екатеринбургского клуба РП при ЕФ МО PMI

Преподаватель трех бизнес-школ

Участник конференций, автор статей

Вице-президент Казахстанского отделения Международного Института управления проектами (PMI)

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

• Введение в теорию ограничений 2

• Проблемы одного проекта 3

Содержание презентации

ПОДХОД PMI. МЕТОД

КРИТИЧЕСКОГО ПУТИ

Зачем нужно управлять проектами?

Проект – это средство организации операций, которые не

могут быть проведены в рамках обычной деятельности

организации – PMBOK

Проект – это выполнения стратегического плана

организации

Проект – это средство достижения

конкурентных преимуществ

Проект – это средство управления

организационными

изменениями

Управленческая деятельность

Обеспечивающая деятельность

Основная производственная

деятельность

Деятельность по развитию

Упр

авл

ени

е

Развитие

Об

есп

ечен

ие

Основное допущение докладчика

Проекты = процессы

Сборник «лучших практик» в области управления проектами мирового масштаба

Стандарт для управления проектами без привязки к конкретной отрасли индустрии или бизнеса

Не включает в себя знания в области общего менеджмента и прикладные решения

Существует консенсус по ее применению

Содержит общий словарь терминов

Возможность применения PMBOK определяется командой управления проектом

Что такое Project Management Body of Knowledge (PMBOK) ?

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

Статистика успешных проектов

Статистика Standish Group 2008 г.

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

Определение взаимосвязей

Разработка

Разработка

ТестированиеРазработка должна завершиться перед тем,

как начинается Тестирование, + 5 дней

FS+5

ТестированиеРазработка должна начаться до того, как

может начаться Тестирование

Разработка

Разработка

Тестирование

Тестирование

SS

FF

SF

Разработка должна завершиться до того, как может закончиться Тестирование

Разработка должна начаться перед тем, как может закончиться Тестирование

Старт Работа 1 Работа 2

Работа 3 Работа 4

Работа 5

Финиш

Сетевая диаграмма

Календарь ресурсов (The resource pool description) должен подсказывать вам какой ресурс доступен и в какое время.

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

Критерии оценки человеческих ресурсов

Доступность: Какие человеческие ресурсы доступны сейчас, какие будут доступны после и в какое время?

Способность: Какая у этих людей квалификация?

Опыт работы: Имеют ли эти люди опыт такой или подобной работы? Каковы их прошлые успехи?

Заинтересованность: Интересно ли людям работать над данным проектом?

Стоимость: Сколько надо будет платить каждому члену команды?

Определение ресурсов

Методы оценки

Экспертная оценка

- Обычно выполняется «снизу-вверх»

- Выполняется заинтересованными сторонами

Оценка по аналогам

- Форма экспертной оценки, которая использует информацию по оценке подобной работы в этом проекте или ранее проведенном проекте.

Метод оценки «сверху-вниз»

- Используется когда проекты подобны по фактическому составу работ

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

- Используется, когда отсутствует детализация ряда работ проекта.

Параметрическая оценка

- Используется для повторяющихся задач

- Количество строк программного кода

- Количество кубометров бетона

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

Определение длительностей

Оценка по трем точкам (Three-Point Estimation) – получение трех оценок

Оптимистичная (О)

Наиболее вероятная (М)

Пессимистичная (Р)

Оценка PERT = (P + 4M + O) / 6

(O) (M) (P)

Задача

А 3 5 12

Задача

В 4 7 13

Задача

С 3 4 9

Всего 10 16 34

PERT = 10 + (4*16) + 34

6 = 18

Пример расчета Оценка PERT

Определение длительностей - PERT

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

Критический путь может меняться во время исполнения проекта.

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

Метод критического пути

Составление сетевой диаграммы

Сетевая диаграмма

1 15 дней

Пн 12.06 Пт 30.06

2 5 дней

Пн 03.07 Пт 07.07

4 4 дня

Пн 10.07 Пт 13.07

9 10 дней

Ср 19.07 Вт 01.08

10 20 дней

Пт 15.09 Чт 12.10

3 4 дня

Пн 10.07 Чт 13.07

11 5 дней

Пт 13.10 Чт 19.10

5 3 дня

Пт 14.07 Вт 18.07

6 15 дней

Пн 10.07 Пт 28.07

7 30 дней

Пн 31.07 Пт 08.09

8 4 дня

Пн 11.09 Чт 14.09

Одобрение участниками проекта

Выбор участка установки

Оценка и выбор поставщиков

Проверка аппаратного обеспечения

Приобретение аппаратного обеспечения

Завершение установки. Одобрение

Интеграция

Проектирование программного обеспечения

Написание кода Тестирование

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

Расчет Операция Описание Длит-ть Предш. ES EF LS LF Резерв

1 Определение результатов поставки проекта 15 нет 1 15 1 15 0

2 Одобрение участниками проекта 5 1 16 20 16 20 0

3 Выбор участка установки 4 2 21 24 86 89 65

4 Оценка и выбор поставщиков 4 2 21 24 53 56 32

5 Приобретение аппаратного обеспечения 3 4 25 27 57 59 32

6 Проектирование программного обеспечения 15 2 21 35 21 35 0

7 Написание кода 30 6 36 65 36 65 0

8 Тестирование 4 7 66 69 66 69 0

9 Проверка аппаратного обеспечения 10 5 28 37 60 69 32

10 Интеграция 20 9,8 70 89 70 89 0

11 Завершение установки. Одобрение 5 3,10 90 94 90 94 0

Метод критического пути

Пн 12.06 Пт 30.06 Пн 03.07 Пт 07.07 Ср 23.08 Пн 28.08 Пт 01.09 Чт 14.09 Пт 15.09 Чт 12.10

Пн 09.10 Чт 12.10 Пт 13.10 Чт 19.10

Вт 29.08 Чт 31.08

Пн 10.07 Пт 28.07 Пн 31.07 Пт 08.09 Пн 11.09 Чт 14.09

Одобрение участниками проекта

Выбор участка установки

Оценка и выбор поставщиков

Проверка аппаратного обеспечения

Приобретение аппаратного обеспечения

Завершение установки. Одобрение

Интеграция

Проектирование программного обеспечения

Написание кода Тестирование

Пн 12.06 Пт 30.06 Пн 03.07 Пт 07.07

Пн 10.07 Пт 28.07 Пн 31.07 Пт 08.09 Пн 11.09 Чт 14.09

Пт 15.09 Чт 12.10

Пт 13.10 Чт 19.10Пн 10.07 Чт 13.07

Пн 10.07 Пт 13.07 Ср 19.07 Вт 01.08

Пт 14.07 Вт 18.07

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

Сжатие расписания

• Метод критического пути важен для определения последовательности задач не имеющих резерва

1

• Использование этого метода не защищает проект от сдвига сроков (провала) так как не связано с рисками

2

• Метод критического пути требует доработки !!! 3

Основные выводы

Элияху Голдратт (1948 – 2011) – создатель теории ограничений

Теория ограничений (Theory of Constraints TOC)

Метод «Барабан» – «Буфер» – «Веревка» • «Барабан» — производство должно работать по некоторому ритму; • «Буфер» — перед ограничением должен находиться некоторый

буфер запасов; • «Верёвка» — материалы должны подаваться в производство только

тогда, когда запасы перед ограничением достигли некоторого минимума, не раньше.

Виды потерь (яп. 無駄 муда)

ОСНОВНАЯ ЧАСТЬ

Проблемы одного проекта (1)

Создание резервов

Проблемы одного проекта (1)

• Длительность задач оценивается с использованием 90+% резерва

– «Я думаю, что данная задача должна быть выполнена за 5 дней, но, на всякий случай, оцениваю ее в 8 дней. Итак, я уверен, что за 8 дней я точно ее выполню».

• Эффект: встроенный в длительность задачи буфер безопасности

Проблемы одного проекта (2)

«Синдром студента»

Проблемы одного проекта (2)

• Синдром студента: поздний старт работы над задачей

– «У меня целых 8 дней. Этого хватит с избытком. Значит я сейчас могу использовать это время на непроектную работу, которая более легкая и также важна для меня».

• Эффект: вспомните молодость… Кто начинал работу вовремя?

Проблемы одного проекта (3)

Закон Паркинсона

Проблемы одного проекта (3)

• Закон Паркинсона: работа занимает все выделенное на нее время

– (после 5 дней) «Я почти закончил эту задачу. Оставшееся время я могу потратить на дополнительные «фантики» по этой задаче. Или подумаю над юзабилити. Или еще что-то...».

• Эффект: задача всегда занимает спланированное под нее время. И никогда меньше.

Проблемы одного проекта (4)

Эффект «торопыжки»

Проблемы одного проекта (4)

• Эффект торопыжки

– «Как ты можешь завершить задачу за 4 дня, когда по плану она должна быть выполнена за 8 дней. Ты наверняка что-то забыл сделать. И качество твоей работы под вопросом».

• Эффект: исполнителей никогда не поощряют за досрочно выполненную работу.

Проблемы одного проекта (5)

Перегрузка ресурсов

Проблемы одного проекта (5)

• Когда несколько задач

– «Я занят в задачах А и В, а еще должен участвовать в реализации задачи С».

• Эффект: реализация всех задач займет больше времени. Вместо трудоемкости 3*3 дня, более вероятная трудоемкость 3*4 дня из-за временных затрат для переключения между задачами.

Проблемы одной организации (6)

Игнорирование статистики

Проблемы одной организации (6)

• Ошибки при использовании экспертной оценки длительности задач

• «Нежелание» использовать статистику для нормирования процессов

• «Нежелание» и/или «неумение» использовать современные методы контроля качества (контрольные карты, диаграммы Ишикава и пр.)

Выводы: Проблемы одного проекта

• Буфер безопасности в каждой задаче, но не в проекте в целом

• Синдром студента – поздний старт работы над задачей

• Закон Паркинсона: работа занимает все выделенное на нее время

• Досрочное завершение не поощряется

• Эффект переключения между задачами

И еще кое-что…

• Если мы говорим, что задача с плановой длительностью 8 дней будет выполнена за 5 дней, то можно сразу начать выполнять последующую задачу? Или ресурс для ее выполнения будет ЕЩЕ недоступен?

• Худший случай: если задача будет выполнена с просрочкой, т.е. более 8 дней. Будет ли ресурс для выполнения последующей задачи ЕЩЕ доступен?

Что мы можем сделать?

• Убрать буферы безопасности с уровня задач на уровень всего проекта

• Избегать параллельное выполнение задач одним ресурсом в пользу назначения приоритетов. Если начал выполнять задачу – выполни до конца! Не переключайся на другую!

Несколько цифр

• Если в проекте мы используем двух людей с доступностью 50%, то их совместная работа будет реальна на 25%.

• Если таких людей четверо, то их совместная работа оценивается в 6%, т.е. требуется 8 рабочих дней, чтобы собрать их вместе на половину дня совместной работы.

• И, наконец, из 10 членов команды проекта с 50% занятостью: 3 придут на оба совещания по проекту, 5 из них – либо на то, либо на другое, 2 – пропустят оба совещания!

Определить критическую цепь

1. Сначала исключить конфликты ресурсов в нашем проекте.

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

Метод критической цепи

1. Поделить буфер безопасности в каждой задаче пополам и половину от этой оценки определить в проектный буфер.

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

3. Определить ресурсные буферы как «тревогу» для обеспечения доступности ресурсов.

Проектный буфер

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

• Буфер защищает проект от сдвига сроков.

• В ходе проекта проектный буфер начинает расходоваться.

Задача C

Задача B

Задача A Проектный буфер

Дата завершения проекта

Проектный буфер

Задача C

Задача B

Задача A

Задача C

Задача A Проектный буфер

Буфер составляет, как правило, 25-33 % от длины критической цепи

Длительность проекта остается неизменной

Задача B

На практике

Питающие буферы

1. Каждая задача в проекте становится либо частью критической цепи либо частью питающей цепи.

2. Мы должны защитить критические задачи от каких-либо задержек.

3. Поэтому мы начинаем задачи на питающих цепях Как Можно Раньше и для гарантии размещаем за ними питающие буферы.

Задача C

Задача B

Задача A

Задача D

Проектный буфер

ПБ

Питающий буфер (ПБ)

Новая работа

Кривая изучения технологии

Критическая цепь на фазе исполнения 1. Избегайте распыление ресурсов на

несколько задач.

2. Начинайте работу над задачей как можно раньше с учетом доступности ресурса и завершения предыдущей.

3. Помните, что оценки, расставленные в плане – это оценки для планирования, а не для исполнения задач.

Критическая цепь на фазе исполнения 1. Ранний финиш задач на критической

цепи приближает досрочную сдачу проекта.

2. Ранний финиш задач на питающей цепи увеличивает защиту задач на критической цепи.

3. Самое плохое: если ресурс остановит исполнение критической задачи и переключится на другую задачу. Это приведет к задержке всего проекта.

Фиксируя отставание задач от плана, мы сокращаем Проектный буфер Фиксируя опережение задач по плану, мы пополняем Проектный буфер

C

B

D

A

На 5 день задача A будет длиться еще 8 дней(из 10 по плану) – Проектный буфер сократился на 3 дня Задача D is завершена – она не оказала никакого эффекта на Проектный буфер

Измерения и управление

• Использование метода критической цепи повышает вероятность успешного финиша

1

• Использование этого метода требует искусства и гибкости от руководителя проекта

2

• В России пока еще не сформирована наилучшая практика использования МКЦ

3

Основные выводы

Книги и ресурсы

«Критическая цепь" Элияху Голдратт

http://www.toc-center.ru/projects.html

"Critical Chain Project Management" by Lawrence P Leach ISBN 1-58053-903-3

"Enterprise-Focused Management" by Ted Hutchin ISBN 0-72772-979-9

ВОПРОСЫ?

НАПИСАТЬ: EVGENY.PIKULEV@GIBTECH.RU ПОЗВОНИТЬ: 8 919 394 7636 ПРИСОЕДИНИТЬСЯ: HTTP://WWW.FACEBOOK.COM/GROUPS/EF.MO.PMI/