Вовремя и в рамках бюджета. Управление проектами по методу критической цепи

Оглавление

Лоуренс Лич. Вовремя и в рамках бюджета. Управление проектами по методу критической цепи

Предисловие

Благодарности

Глава 1. Начнем с начала

1.1. Успешный проект

1.2. Определение проблемы

1.2.1. Насколько состоятельна существующая проектная система

1.2.1.1. Типы проектов

1.2.1.2. Некоторые факты

1.2.1.3. Некоторые цифры

1.2.2. Прибыль от реализации проектов

1.2.3. Правильная постановка проблемы

1.2.4. Правильное решение

1.2.4.1. Сделать еще лучше…

1.2.4.2. Вариабельность и неопределенность

1.2.5. Правильное выполнение

1.3. Добиваемся успеха при помощи ССРМ

1.4. Honeywell Defense Avionics Systems [16]

1.5. Lucent Technologies [17]

1.6. Авиационная промышленность Израиля

1.7. Американское судостроение

1.8. Итоги

Литература

Глава 2. ТОС, РМВОК, бережливое производство и шесть сигм

2.1. Свод знаний по управлению проектами (РМВОК)

2.1.1. Общая координация (интеграция) проекта

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

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

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

2.1.5. Другие области знаний РМВОК

2.1.6. ОРМ3

2.2. Бережливое производство

2.3. Agile, или Облегченные методы управления проектами

2.4. Шесть сигм

2.5. Система глубинных знаний

2.5.1. Понимание системы

2.5.1.1. Системная динамика

2.5.1.2. Рычаги воздействия

2.5.1.3. Непреднамеренные последствия

2.5.1.4. Разрушение системы

2.5.2. Понимание вариабельности и неопределенности

2.5.3. Психология

2.5.4. Теория познания

2.6. Теория ограничений

2.6.1. Управленческий учет по ТОС

2.6.2. Производственное решение

2.6.3. Пять направляющих шагов ТОС

2.6.3.1. Найти ограничение системы

2.6.3.2. Найти способ ослабить влияние ограничения

2.6.3.3. Подчинить всю работу нуждам ограничения

2.6.3.4. Снять ограничение системы

2.6.3.5. Если на предыдущих этапах ограничение было снято, возвращайтесь к шагу 1

2.6.4. Процесс логических рассуждений по ТОС

Дерево текущей реальности

Диаграмма разрешения конфликтов «грозовая туча»

Дерево будущей реальности

Ветвь негативного развития событий

Дерево перехода

План преобразований

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

2.8. Большой синтез

2.9. Итоги

Литература

Глава 3. Выбираем подход к решению

3.1. Решаем, что менять

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

3.1.2. Провал проекта как Нежелательное Явление

3.2. Определяем ограничение

3.3. Максимально используем ограничение

3.3.1. Длительность проектов растет

3.3.2. Проекты часто идут с нарушением графика работ

Студенческий синдром

3.3.3. «Многозадачность»

3.3.4. Ключевой конфликт ведет к нежелательным явлениям

3.4. К желаемым результатам

3.4.1. Разрешаем ключевой конфликт

3.5. Реализуемость решения (доказательства)

3.6. Определяем, на что менять

3.7. Итоги

Литература

Глава 4. Комплексное решение для отдельного проекта

4.1. От системных требований к модели системы

4.1.1. Матрица требований

4.1.2. Критическая цепь для отдельного проекта: краткое изложение

4.2. Разработка решения «критическая цепь»

4.2.1. Определение ограничения в проекте

4.2.2. Максимальное использование ограничения

4.2.2.1. Извлекаем выгоду из оценок

4.2.2.2. Используем законы статистики для управления общими причинами вариабельности

4.2.2.3. Работаем с доступностью ресурсов

4.2.3. Иерархическое подчинение путей при слиянии

4.2.4. Выполнение работ

4.2.4.1. Искореняем привязанность к датам

4.2.4.2. Улучшаем качество работ, устранив многозадачность

4.2.5. Ранний старт или поздний финиш?

4.3. Получаем максимум из плана, управляя при помощи буферов

4.4. Некоторые понятия РМВОК

4.4.1. Устав проекта

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

4.4.2.1. Иерархическая структура работ

4.4.2.2. Роли и обязанности

4.4.2.3. График ключевых событий

4.4.2.4. Пакеты работ

4.4.2.5. Сетевая диаграмма проекта

4.4.3. Оценка и контроль выполнения проекта

4.4.4. Управление изменениями в проекте

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

4.5. Итоги

Литература

Глава 5. Запуск нового проекта

5.1. Процесс инициации проекта

5.2. Устав проекта

5.3. Определение участников проекта

5.4. Иерархическая структура работ (ИСР)

5.4.1. Подход теории ограничений

5.4.2. Традиционная ИСР

5.4.3. Организационная структура проекта

5.5. Назначение ответственных

5.6. Последовательность контрольных событий

5.7. Пакеты работ

5.7.1. Исходные установки

5.7.2. Диаграмма проекта

5.7.2.1. Логика проекта

5.7.2.2. Назначение ресурсов в диаграмме проекта

5.7.2.3. Степень детализации плана

5.7.3. Оценка длительности операции

5.7.4. И снова про неопределенность

5.8. Буфер на затраты

5.9. Оценка затрат

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

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

5.12. Завершение проекта

5.13. Итоги

Литература

Глава 6. Создание плана отдельного проекта по методу критической цепи

6.1. Процесс

6.2. «Достаточно хороший»

6.3. Примеры и упражнения

6.3.1. Простой пример

6.3.2. Сложный пример

6.3.3. Сложное упражнение

6.4. Определение размера буфера и нахождение границ принятия решений

6.4.1. Статистическое обоснование

6.4.2. Определение размера буферов: проектного и на слияние путей

6.4.3. Границы принятия решений по буферу

6.4.4. Ресурсные буферы

6.5. Определение размера буфера на непредвиденные расходы

6.6. Способы создания плана

6.6.1. Ручной способ

6.6.2. Программы с алгоритмом критического пути

6.6.3. Программы с алгоритмом критической цепи

6.7. Внешние ограничения

6.8. Сокращение запланированного времени (или навязанная дата окончания работ)

6.8.1. Ускорение работ без влияния на уровень затрат (ослабить ограничение и подчинить ему все)

6.8.2. Ускорение работ с увеличением затрат на сырье (устранение ограничения)

6.9. Планирование ресурсов предприятия

6.10. Часто задаваемые вопросы о планировании

6.11. Итоги

Глава 7. Создание сводного плана нескольких проектов методом критической цепи

7.1. Как определить ограничение системы проектов

7.2. Как снизить влияние ограничения системы проектов

7.3. Важные аспекты управления несколькими проектами методом критической цепи

7.3.1. Расстановка приоритетов

7.3.2. Определение ресурса-«барабана»

7.3.3. График «барабана», или наладка конвейера проектов

7.3.4. Буфер на доступность ресурса

7.3.5. Буфер ограничивающего ресурса

7.3.6. Расписания проектов

7.4. Еще один взгляд на ограничение одновременных проектов

7.5. Запуск новых проектов

7.6. Вопросы, часто задаваемые по системному планированию нескольких одновременных проектов

7.7. Итоги

Глава 8. Оценка и контроль выполнения плана

8.1. Роли в проекте

8.1.1. Менеджер операции

8.1.2. Менеджер проекта

8.1.3. Менеджер ресурсов

8.2. Управление при помощи буфера

8.2.1. Совещания по проекту

8.2.2. Отчет о состоянии буфера

8.3. Буфер на затраты

8.3.1. Состояние буфера на затраты

8.3.2. Метод освоенного объема вкратце

8.3.3. Расходование буфера на затраты

8.3.4. Проблема

8.3.5. Затраты на оплату труда

8.3.6. Затраты на материалы

8.3.7. Как совместить метод освоенного объема и управление при помощи буфера

8.3.8. Так называемое отклонение по срокам

8.4. Оценка качества

8.5. Ответная реакция на сигналы буфера

8.5.1. Расход временного буфера перешел желтую границу

8.5.2. Расход буфера на затраты перешел желтую границу

8.5.3. Рост показателя «доллар/день»

8.5.4. Расход временного буфера перешел красную границу

8.5.5. Расход буфера на затраты перешел красную границу

8.5.6. Расход буфера превысил 100%

8.6. Контрольные события

8.7. Действия по управлению изменениями

8.8. Вопросы, наиболее часто задаваемые по оценке и контролю

8.9. Итоги

Литература

Глава 9. Как внедрить метод ССРМ

9.1. Модель внедрения ССРМ

9.1.1. Утвердить проект по внедрению изменений

9.1.2. Разработать устав проекта по внедрению изменений

9.1.3. С самого начала нужно иметь видение конечной цели

9.1.4. Разработать план управления проектом по внедрению изменений

9.1.5. Спланировать действия по предотвращению или снижению рисков

9.1.6. Действуйте!

9.1.7. Оценка и контроль внедрения

9.1.8. Как быть, если внедрение буксует?

9.2. Теория организационных преобразований

9.2.1. Модель «семь С»

9.2.2. 3–4–3

9.2.3. Понимание системы

9.2.4. Сопротивление изменениям

9.2.5. В плену парадигмы

9.3. Модель сопротивления изменениям по Голдратту

9.4. Нужен ли пилотный проект

9.5. Примеры возражений

9.6. Итоги

Литература

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

10.1. Что такое управление рисками в проекте

10.2. Процесс управления рисками

10.2.1. Матрица рисков

10.2.2. Оценка рисков как часть процессов управления проектом

10.3. Идентификация рисков

10.3.1. Реестр рисков

10.3.1.1. Допущения проекта

10.3.1.2. Проверочные списки

10.3.1.3. Критическое осмысление плана

10.3.1.4. Группирование рисков

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

10.3.2.1. Высокая вероятность (3)

10.3.2.2. Средняя вероятность (2)

10.3.2.3. Низкая вероятность

10.3.3. Классификация рисков по последствиям

10.3.3.1. Высокое воздействие (3)

10.3.3.2. Среднее воздействие (2)

10.3.3.3. Низкое воздействие (1)

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

10.4.1. Мониторинг рисков

10.4.2. Превентивные меры

10.4.3. Меры реагирования

10.5. Итоги

Литература

Глава 11. Логические инструменты ТОС в управлении проектами

11.1. Синтез принципов

11.2. Используем логические рассуждения по ТОС в управлении проектом

11.3. Дерево текущей реальности

11.3.1. Политики, оценки, модели поведения

11.3.2. Циклы обратной связи

11.3.3. Критический анализ

11.3.4. Поддержка участников

11.4. Дерево будущей реальности

11.4.1. Желаемый результат

11.4.2. Прорывные решения

11.4.3. ДБР как руководство по проведению преобразований

11.4.4. Циклы обратной связи

11.4.5. Нежелательные последствия и негативные ветви

11.5. Дерево перехода

11.6. План преобразований

11.7. Системное управление несколькими проектами

11.7.1. Дополнительные элементы ДТР для системы проектов

11.7.2. Дополнения к ДБР по системе одновременных проектов

11.7.3. Дополнения к ДП по системе одновременных проектов

11.8. Перспективные направления применения ТОС

11.9. Итоги

11.10. В заключение

Литература

Словарь ключевых понятий и сокращений

Об авторе

Отрывок из книги

Когда концепция критической цепи увидела свет, мне посчастливилось тут же разглядеть, насколько удачно она дополняет свод знаний по управлению проектами PMBOKTM. Я принялся работать над синтезом этих двух областей – над управлением проектами методом критической цепи (Critical Chain Project Management, CCPM). Тогда специалисты, знакомые с теорией ограничений систем (ТОС), и те, кто являлся частью профессионального сообщества менеджеров проектов, не очень-то пересекались между собой, отчасти потому, что теория ограничений зародилась в производственной сфере.

Когда менеджеры проектов впервые услышали о ССРМ (некоторые – во время моего выступления на ежегодном съезде PMI (Project Management Institute), проходившем в Лонг-Бич, штат Калифорния, в 1998 году), мнения их о теории разделились. Большинство вдохновилось новым подходом, желая освоить его как можно быстрее и применять на практике. Небольшая, но заметная группа, оказавшаяся в меньшинстве, составила движение протеста, лозунги которого сводились по большому счету к тому, что «ничего нового в этом нет». В издания PMI (PM Network, PM Journal) полетели письма, разгорелись дебаты, и ряд авторов, в том числе и я, в своих статьях сформулировали некоторые ключевые аспекты проблемы. Я был открыт для конструктивной критики, однако меня совершенно не вдохновляли аргументы типа «это уже было». К счастью, в PMI преобладали люди рассудительные. Мою книгу взяли к распространению и помогли организовать двухдневный семинар. Недостатка в желающих посетить его не наблюдалось, и отзывы участников были самые лестные.

.....

Позже мы поговорим о том, какие факторы помогут вам определить степень детализации при создании плана. Иногда в случае с крупными проектами речь действительно может идти о тысячах операций. Забегая вперед, скажу: как правило, план должен быть более скромным по размерам – операций на 100. Простейшие подсчеты показывают, что одна операция в среднем составляет при этом 1 % от всего проекта (в долл., или в человеко-днях, или даже в днях). Большинство менеджеров проектов были бы счастливы, если бы реализация их проекта расходилась с планом всего на 1 %. Однако в основе проблем лежит нечто, вызывающее отклонения более чем на 1 %. Поэтому, на мой взгляд, увеличение детализации плана и количества составляющих его операций (чтобы их было более 100) никак не поможет добиться успеха. Дело должно быть в чем-то другом.

Иногда в поддержку детализации слышатся следующие аргументы: проблема, хотя она и значительно больше 1 %, связана с тем, что при планировании мы что-то пропустили. Но недостающие 20 % не могут скрываться внутри имеющегося 1 %. Поиски крупных пропущенных составляющих среди деталей задачи, являющейся 1 % от проекта, напоминают анекдот о подвыпившем прохожем, который обронил ключи на углу улицы, но ищет их под фонарем, потому что там светлее, а на углу темно и ничего не видно. Если боитесь упустить что-то важное, лучше смотрите, чего не хватает между выделенными 100 операциями, а не пытайтесь разбить эти уже выявленные задачи на все более мелкие элементы.

.....