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

Управление проектами Н.В. Павлов Часть 2. Исполнение Управление проектами 1 Н.В. Павлов 1 Часть 2. Исполнение 1 1. Контроль и регулирование проекта 3 1.1. Принцип 3 1.2. Мониторинг 3 1.3. Измерение прогресса и анализ результатов 4 1.4. Принятие решений 5 1.5. Управление изменениями 5 2. Управление содержанием 8 2.1. Матрица координации изменений 9 2.2. Запрос на внесение изменения в проект 13 2.3. Журнал изменений проекта 16 2.4. Свод 18 3. Управление расписанием 18 3.1. Линия исполнения 19 3.2. BCF-анализ 24 3.3. Диаграмма прогнозирования контрольных событий 27 3.4. Диаграмма скольжения 29 3.5. Диаграмма буферов 31 3.6. Сжатие расписания 33 3.7. Свод 37 4. Управление стоимостью 38 4.1. Анализ выполненной стоимости (?) 39 4.2. Анализ контрольных событий 53 4.3. Показатели и их расчет 56 4.4. Отчетность по затратам 59 5. Управление качеством (тут пока только Милошевич, без Разу и Шапиро) 62 5.1. Карта повышения качества 62 5.2. Использование карты повышения качества 67 5.3. Диаграмма Парето 68 5.4. Диаграмма причин и следствий 73 5.5. Контрольные диаграммы 76 5.6. Свод 87 6. Отчетность о ходе исполнения и закрытие 88 6.1. Журнал рисков 89 6.2. Сводный отчет об исполнении 92 6.3. Послепроектный анализ 95 6.4. Свод 103 7. Промышленные применения 103 7.1. Отбор инструментов в «инструментальный ящик» для управления проектами и его адаптация к нуждам пользователя 103 7.2. Заключительные размышления 118 8. Связь между инструментами управления проектами и РМВОК 118 9. Детали 122 9.1. Связь между наборами инструментов управления проектами и размером проекта 122 9.2. Связь между наборами инструментов управления проектами и семейством проекта 124 9.3. Связь между наборами инструментов управления проектами и типом проекта 132 9.4. Ассоциация 135 1. Контроль и регулирование проекта 1.1. Принцип Управление. Англ Control. Переводится как управление. Это активное изменение. Может быть, регулирование – поддержание на указанном уровне. Это имеет право на существование. Но надо понимать. Иногда переводится как контроль = проверка. Последнее неверно. Задача: сравнить план и факт, исправить отклонения. Для этого нужна обратная связь. Изменять можно и процесс, и плановые показатели. Значит, есть несколько контуров. Нижний – для пакета работ. Только устранить отклонения. Еще это называют регулирование. Верхний – можно менять и плановые показатели. Это уже управление. Только 5% проектов не требуют перепланирования. Нужна процедура регулярного контроля (проверки). Эту процедуру, вообще-то, надо разработать до начала проекта. Корректирующие воздействия: перераспределение ресурсов, пересмотр плана (изменяем параметры работ или подлноятью план). Принципы построения эффективной системы контроля. 1. Наличие конкретных планов. Не слишком часто изменяемых. 2. Наличие информативной системы отчетности. Определено, как составлять отчет; единая форма, четкое время. 3. Наличие эффективной системы анализа фактических показателей и тенденций. Надо определить, серьезны ли отклонения. В основном по времени и стоимости (еще есть объем работ и содержание). Тенденции (прогнозы) для того, чтобы понять, насколько удлинится проект, какие будут последствия действий (что-если). 1.2. Мониторинг Мониторинг — контроль, слежение, учет, анализ и составление отчетов о фактическом выполнении проекта в сравнении с планом. Надо все время собирать фактические данные. Вот что пишут наши: Руководство обязано непрерывно следить за ходом выполнения проекта, определять степень завершенности работ и исходя из текущего состояния делать оценки параметров выполнения будущих работ. Зарубежные больше на команду упор делают. Есть наряды на выполнение работ. Они заполняются бригадирами или контролерами и проверяются. Удобно, но не везде. Есть отчеты, заполняемые исполнителями. Не очень достоверно. Строили Беломорканал. Отчитывались за киломертры, получали кто пайку, кто премию. Потом оказалось, что нет 6 км, причем самых сложных. Вот там много погибло! И нелинейно! Что собирать, зависит от цели. Например, если основным приоритетом является своевременность выполнения работ, то можно поменьше собирать про ресурсы и затраты. Обычно количественные показатели собираются на уровне работ или пакетов работ и затем обобщаются для верхних уровней контроля в соответствии со структурой СДР. 1.3. Измерение прогресса и анализ результатов Собранные данные используются для расчета прогресса выполнения работ проекта по показателям [1—3]: • время; • стоимость; • качество; • организация проекта; • содержание работ. Для измерения прогресса могут использоваться различные шкалы в зависимости от специфики выполняемой работы. Измеримые работы, для которых могут определяться дискретные приращения в соответствии с определенным графиком выполнения, завершение которых приведет к конкретным материальным результатам. Работы влияния, которые нельзя разбить на дискретные запланированные приращения — работы типа поддержки и руководства проектом, лоббирования во властных структурах и т. д. Данные о них надо обновлять. По специальной процедуре. Базовый план (подписанный) пока неизменен, служит для сравнения факта с ним. Реальные сроки в измененном плане могут сдвигаться. Итак, все время сравниваем план с фактом. Еще важно: есть выполнение и есть потраченное время. Например, надо потратить 32 нормочаса, то есть 4 рабочих дня. Уже прошло 5 дней, а работа выполнена наполовину. 1.4. Принятие решений Определив отклонения проекта от плана, менеджер должен предпринять соответствующие действия. Как можно раньше. Варианты. Найти альтернативное решение. В первую очередь необходимо рассмотреть возможности повышения эффективности работ за счет новых технологических или организационных решений. Новое решение, например, может заключаться в изменении последовательности выполнения ряда работ; Пересмотр стоимости. Данный подход означает увеличение объемов работ и назначение дополнительных ресурсов. Решение может заключаться в увеличении нагрузки на существующие ресурсы или привлечении дополнительных людей, оборудования, материалов. Данный подход обычно применяется в случае необходимости устранения временных задержек проекта; Пересмотр сроков. Данный подход означает, что сроки выполнения работ будут отодвинуты. Руководство проекта может пойти на такое решение в случае жестких ограничений по стоимости; Пересмотр содержания работ. Данный подход предполагает, что объем работ по проекту может быть уменьшен и соответственно лишь часть запланированных результатов проекта будет достигнута. Надо попробовать не снижать качества результатов проекта. Может быть, меньше испытаний, меньше сбора исходных данных; Прекращение проекта. Это, пожалуй, наиболее сложное решение. Если не ожидается выгоды в итоге. Много проблем. Экономических и психологических. 1.5. Управление изменениями Бывают изменения. Заказчик хочет улучшить характеристики продукта. Проектировщик меняет смету. Подрядчик меняет календарный план. Могут меняться следующие элементы проекта и факторы, влияющие на его реализацию: цели и планы проекта; механизмы реализации проекта; использование ресурсов; контракты и обязательства по ним; используемые стандарты и нормативы; география размещения объектов; внешние факторы, влияющие на проект. Причинами изменений в содержании работ могут быть: изменения конъюнктуры на рынке; действия и намерения конкурентов; технологические изменения, изменения в ценах и доступности ресурсов; экономическая нестабильность; ошибки в планах и оценках; ошибки в выборе методов, инструментов, организационной структуре или стандартах; изменения в контрактах и спецификациях; задержки поставок или поставки, не соответствующие требованиям качества; необходимость ускорения работ; влияние других проектов. Из-за того, что не предвидели изменения (например, технологии); отстали в работах (это вынужденно), захотели как лучше (осознанно). Неконтролируемые изменеиня страшны. Изменения надо контролировать. Надо модифицировать базовый план с учетом изменений; изменять план при изменении результата; координацию изменений в функциях, процессах и процедурах. Все делаетсая по стандартным процедурам. Полномочной комиссией. Вот что пишет то ли Разу, то ли Мазур (рис). Но это же не проактивно!!! И вообще, удивительно опустело содержание. Стало ни о чем! Разочарование в русских книгах. Рис. 15.5.1. Цикл контроля изменений Ну надо же так сказать! «Таким образом, в идеальном случае контроль реализации изменений представляет собой комплексную технологию управления проведением изменения проекта с соответствующим набором документации и распределением обязанностей». Еще раз: есть подход от начала до конца про подсистему (содержание, стоимость, расписание). Но все-таки взяли фазы (инициация, планирование, реализация, завершение) и для каждой фазы смотрим, что можно сделать по подсистемам. 2. Управление содержанием Под содержанием проекта подразумевается деятельность, необходимая для получения результата проекта (продукта) со специфическими характеристиками и функциями. Это процесс. В свою очередь, содержание продукта (результата проекта) определяют характеристики и функции, которые должны быть включены в продукт. Это результат. Работы должны обеспечить результат, без лишних работ. Разу и общее понятие управления: Основными процессами управления содержанием проекта являются: • инициирование проекта; • планирование содержания; • контроль над изменением содержания. Инициирование является процессом выявления необходимости реализации нового проекта или того факта, что проект должен перейти в новую фазу. Результатами инициирования служат: комплект документов (контрактов, приказов, постановлений и т. д.), формально подтверждающих существование проекта. Он должен включать непосредственно или в виде ссылок на другие документы: описание цели, для удовлетворения которой был предпринят проект; описание продукта проекта; определение/назначение руководителя (менеджера) проекта; ограничения по срокам реализации проекта, его финансированию и т. д. При осуществлении проекта по контракту ограничениями обычно являются условия контракта; предположения как элементы, возникающие в результате прогнозирования тех или иных факторов в проекте. В общем случае, предположения несут в себе определенную степень риска. Планирование содержания проекта включает в себя декомпозицию целей проекта на более мелкие и управляемые компоненты для того, чтобы: определить оценки по стоимости, времени и ресурсам проекта; создать базис (основу) для измерения и контроля хода выполнения проекта; распределить права и обязанности по проекту, определить степень ответственности. Результатом планирования содержания служит структура разбиения работ проекта, на основе которой, как расширение, составляется список работ проекта. Он должен содержать описание каждой работы для того, чтобы их исполнители понимали, что от них требуется и каким образом им выполнять свои функции. В результате анализа разработанной структуры разбиения работ проекта может возникнуть необходимость в корректировке или дополнении целей проекта, что в свою очередь отразится на изменении содержания проекта. Но первые части уже были, так что теперь в процессе работы. Рис. 11.1. Время и способ использования инструментов контроля содержания в процессе стандартизованного управления проектами Это обязательно! Все изменения надо регшистрировать! И в документации на изделие, и в документации на проект. Одна из главных причин – если сменится состав команды. 2.1. Матрица координации изменений 2.1.1. Что такое матрица координации изменений? Описывает, как вносятся изменения. ОПАСНОСТЬ НЕКОНТРОЛИРУЕМЫХ ИЗМЕНЕНИЙ: ЕСЛИ ВАМ НЕОБХОДИМО ВНОСИТЬ ИХ, ДЕЛАЙТЕ ЭТО РАНО Неконтролируемые изменения, как известно, могут погубить проект, поскольку они: • вызывают задержки; • увеличивают стоимость. • вредят моральному состоянию и производительности. • ухудшают отношения между участниками проекта. Почему это так? Во-первых, и это чаще верно, чем нет, изменения вызывают необходимость переделывать работы, входящие в затрагиваемую изменением операцию. Во-вторых, любая операция, связанная с затрагиваемой, также потребует изменений. Это значит, что, чем раньше вы внесете изменение, тем меньшему влиянию и меньшему вреду вы подвергнете весь проект. Если изменение производится в начале проекта, то выполнено бывает еще очень небольшое количество операций и потому объем переделываемой работы не слишком велик. Напротив, если в проекте разработки продукта уже выполнено большое количество операций, изменение может потребовать значительного повторного проектирования, покупки новых станков, технических приспособлений и материалов, переделки прототипов и т. д. Даже такое странное изменение, как замена одного члена команды другим в ходе выполнения проекта может отбросить команду назад на месяц. Из этого необходимо извлечь урок: все тщательно продумывать и вносить изменения на ранних стадиях. Вступив в стадию практической реализации, стремитесь вперед и не вносите изменений — это слишком дорого стоит во всех смыслах этого слова. Но изменеиня не должны приводить к расползанию. 2.1.2. Разработка матрицы координации изменений Построение ССМ, которая гармонично объединяет шаги, действия, владельцев и их взаимодействия в деле контроля изменений, требует тщательно отработанного процесса, который бы минимизировал неконтролируемые изменения (см. заштрихованный прямоугольник «Опасность неконтролируемых изменений: если вам необходимо вносить их, делайте это рано»). Ниже мы описываем процесс, изображенный на рис. 11.2. Рис. 11.2. Пример матрицы координации изменений Подготовка исходной информации. Порядок внесения изменений (должен быть составлен на ранних этапах, было про это). Надо назначить координатора изменений. План работ по проекту. Бывает 2 случая. 1. Есть отточенный план контроля изменений. Тогда всй идет по накатанной колее. 2. Нет установившегося порядка. Тогда главная роль у координатора. Работа. Подача (представление) запроса на внесение изменения в проект. Естественно, что любой человек, вовлеченный в проект, находящийся как внутри, так и вовне команды, вполне может по дать PCR — в предположении, что содержание проекта еще не заморожено. Детали, касающиеся PCR, изложены ниже в данной главе. Внесение записи в журнал изменений проекта. Надо внести в журнал и разослать копии в комитет и автору. И, может быть, тем, кто может помочь. Рассмотрение запроса на внесение изменения в проект. Координатор направляет запросы на внесение изменений в орган по изменениям. Надо не все подряд принимать, а проактивно. Пять вопросов проактивного цикла контроля проекта: • Каково будет расхождение между базовым планом содержания и фактическим содержанием, вызванное запрошенным изменением? • Каковы проблемы, вызывающие расхождение, которое, в свою очередь, вызывает запрос на изменение? • Какова существующая тенденция — то есть предсказываемое содержание, которое будет иметь место по выполнении, в случае, если мы примем, предлагаемое изменение? • Какие новые риски могут возникнуть в будущем и каким образом они могут вызвать дальнейшие изменения в предсказанном содержании по завершении? • Какие действия мы можем предпринять для устранения необходимости в запрашиваемом изменении и других возможных изменениях в будущем для того, чтобы выполнить проекта настолько близко к базовому плану содержания, насколько возможно? Принятие решения по запросу на внесение изменения. Утвердить или отклонить. Решение фиксируется в журнале. Если отклонили, то в архив, автору – объяснение. Если приняли, то координатор отправляет исполнителям для реализации. Инофрмируент и автора. Еще одно решение: запросить дополнительную информацию (например, то автора). Мониторинг реализации изменения. Утвердили изменение – нет больше изменения. Но последствия надо контролировать. Для этого используется POL. Обновление информации о расписании и стоимости проекта.. Задание: сделать idef 2.1.3. Использование матрицы координации изменений Когда использовать. Для каждого изменяемого проекта. Чем раньше, тем лучше. Для больших важнее. ДЛяч малых можно и неформально описать процесс. Трудоемкость. Если политика и правила есть, занимает час. Для малых проектов можно неформально объяснить за 20 минут. Выгоды. Упорядочение процесса. Преимущества и недостатки. Визуально и пошагово. Но выглядит как потеря времени. 2.2. Запрос на внесение изменения в проект Запрос на внесение изменений в проект как раз и предназначен для того, чтобы помочь выполнить всестороннее оценивание предлагаемых изменений (см. рис. 11.3). ЗАПРОС НА ВНЕСЕНИЕ ИЗМЕНЕНИЯ В ПРОЕКТ Название проекта: Cage 01 Запрос№:1 21 Детали предлагаемого к внесению изменения и их влияние на содержание / качество: Планы тестирования в пакете работ 4.03.03 должны быть изменены и завершены с задержкой в 1 неделю. Как следствие этого, следующий пакет работ 4.04.01 «Тестирование устройства», первоначально запланированный на 5/07/01, должен будет начаться 5/12/01. Никакого влияния на предметы поставки определения содержания, базовый план содержания остается неизменным. Никакого влияния на качественные спецификации (спецификации качества). Запрос на изменение подан: George Best Дата: 17/04/01 Причина подачи запроса: Ошибки, обнаруженные в планах тестирования. Изменение планов является настоятельной необходимостью. Запрашиваемые чрезвычайные действия (если таковые имеются): Нет Тип изменения: значительное (требует усилий по перепланированию) незначительное: Стоимость обнаружения изменения: $ 105 Влияние на расписание проекта: Оценка сроков согласно документу: СС014 Общая длительность проекта будет увеличена на 1 неделю, и проект будет завершен 6/18/01 Влияние на стоимость проекта: Оценка стоимости согласно документу: СС002 Бюджет изменения составляет $1.840 Финансируется заказчиком? Нет Если да, привести ссылку на документ, подтверждающий утверждение заказчиком: Указания комитета по рассмотрению изменений: Авторизованно (для комитета по рассмотрению изменений): Paul McCartney Дата: 24/04/01 Рис. 11.3. Пример запроса на внесение изменения в проект 2.2.1. Разработка запроса на внесение изменения в проект Хотя запрос выглядит как простая форма (стремитесь к тому, чтобы он укладывался в 1 страницу и включал то количество вспомогательных деталей, которое необходимо), подготовка его требует определенной домашней работы, и начинается эта работа с подготовки исходной информации. Подготовка исходной информации. План проекта, порядок внесения изменений. Когда? Не на этапе определения содержания, а кода план утвержден. Но и, обычно, устанавливается время, когда надо заканчивыать и с изменениями, так как это только всё испортит. Может и заказчик что-то добавить. Так же и в дипломном проекте. PCR используется для изменений, которые [7]: • составляют отход от согласованных технических спецификаций (норм) на проектирование; • влияют на спецификации, выпущенные инженерным отделом для планирования закупок или производства. Это лишь примеры. Описание предлагаемых к внесению изменений и их воздействий на содержание / качество. Достаточно точно для того, чтобы дать надлежащее понимание того, какая часть, предмет поставки или пакет работ должна быть изменена и каким образом. Может быть и длинно, если надо. Объяснение причин изменения. Бывают необходимые и желаемые. А затраты могут быть большими. Идентификация чрезвычайных изменений. По обычному порядку рассмотрение медленное. Надо указать, что срочно, если надо. Объяснение влияния на расписание проекта. По сетевому графику сложно, инстинктивно – неверно. Оценивание влияния на стоимость проекта. То, что люди склонны к недооценке стоимости, хорошо известно и задокументировано в различных книгах и статьях. Десятилетия назад, так же, как и сегодня, ошибка в оценке на 20 с лишним процентов не являлась чем-то странным и необычным. Странным и необычным является неспособность руководства принять эту тенденцию во внимание (учесть эту тенденцию) при оценивании запросов на изменения. Надо правильно определить влияние. Может быьт, запросить независимый источник. Идентификация типа изменения. Слабые, не затрагивающие общий план, и серьезные. И приоритет. Что важнее на данном этапе. Приоритет рассмотрения может быть от 24 часов до 30 дней. Например, приоритет изменений от заказчиков. Надо за 48 часов. Это может быть сложно. Но делаем интернет, заменяем консенсус на шефа. В резлуьтате заказчиков удержали. 2.2.2. Использование запроса на внесение изменения в проект Когда использовать. Проверять измениня надо везде. В крупных важно документировать всё. В малых можно и устно обсудить, времени обычно очень мало. Трудоемкость зависит от серьезности изменений. Само заполнение – минуты. +- Ясно, кратко. Решения осознанные. Всё под контролем. Задокументировано. Но. Времяемко. Изменений до тысяч в большом проекте. 2.3. Журнал изменений проекта 2.3.1. Что такое журнал изменений проекта? Ведет координатор. Было дело. Менялись менеджеры, не вели журнал. Потребовалось несколько месяцев и несколько тысяч долларов, чтобы собрать все изменения. А это нужно было, чтобы говорить с заказчиком. С тех пор вели журнал. Рис. 11.4. Пример журнала изменений проекта 2.3.2. Ведение журнала изменений проекта На вид просто таблица. Но нужно много шагов. Подготовка исходной информации. • План контроля изменений. • Координатор. • Матрица координации изменений. • Запрос на внесение изменения в проект. Фиксируем подачу заявки. Номер, автор, суть. Фиксирование даты подачи заявки. Для координации. Сколько дней прошло, когда срок. Фиксирование факта одобрения / отклонения PCR и даты, на которую намечена его реализация. Решение о судьбе запроса может пойти обоими путями. Если он не одобрен, необходимо вписать «Нет» в столбец «Одобрен?» и вычеркнуть всю запись, обеспечив ее читаемость. В противном случае, когда PCR одобряется, необходимо вписать «Да» в столбец «Одобрен?» и заполнить столбец «Дата выпуска», обозначив тем самым факт официального выпуска наряда на реализацию изменения. Отслеживание реализации изменения. Изменения, которые начинают реализовываться, имеют одно свойство — они иногда могут «проваливаться в никуда» и исчезать из поля зрения проекта. Во избежание этого координатор рассматривает каждое изменение как незавершенное (отсюда и слова «Еще нет» в столбце «Завершено?» на рис. 11.4). Как только изменение оказывается завершенным, в этот столбец будет вписано «Да». Хотя это и выглядит парадоксально, неряшливая координация изменений вполне может привести к тому, что окажется неучтенным изменение, которое никогда не запрашивалось, но было реализовано. Отслеживание текущего значения общих расходов и текущей даты завершения. Отдельные изменения могут повлиять на стоимость проекта и дату его завершения. Чтобы быть осведомленным об истинных бюджете и дате завершения, необходимо добавлять информацию о влиянии всех одобренных изменений на эти параметры и отслеживать текущие общие значения этих параметров. Пример. Инженер-компьютерщик, когда вендор компьютеров обанкротился, заказал компьютеры получше у другого. Так и делел раньше. Получилось дороже. Заказчик отказался оплачивать разницу: денег нет. Но потом все-таки оплатил, спас от увльноения инденера и менеджера проекта. У нас такого может и не случиться, руководитель подписывает счета. У нас система виз. Счет подписывает главбух и диреткор. До этого десятка два виз. Как в командировку. Но в новых организациях может и через голову директору подать заявку. 2.3.3. Использование журнала изменений проекта Когда использовать. Всегда. Для малых можно и на наладоннике, и неформально. Если мало изменений, может, и не очень полезно. Трудоемкость. Трудно себя заставить. Времени немного надо на внесение данных. У нас жуткая пробелма достоверности. Как-то надо стимулировать качество заносимой информации. Боюсь, что менеджер проекта (ответственный исполнитель) должен это делать, ему надо больше всех. +- Вовремя информирует. Ясно. Просто. Но. На вид бюрократия. Преимущества и недостатки. К преимуществам PCL относятся: Можно бобавить столбец стоимости, общей текущей стоимости проеккта. 2.4. Свод 3. Управление расписанием Рис. 12.1. Роль инструментов контроля содержания в процессе стандартизированного управления проектами 3.1. Линия исполнения 3.1.1. Что такое линия исполнения? В традиционном понимании линия исполнения показывает, на какое количество времени каждая операция проекта опережает базовое расписание или отстает от него (Линия, отражающая освоенный объем на фиксированную дату. — Прим. ред.). Таким образом, эта линия показывает выполненную долю каждой операции слева от себя и оставшуюся долю — справа от себя (см. рис. 12.2). Главный смысл – в проактивности. На основе времени, на которое каждая операция проекта опережает базовое расписание или отстает от него, предсказывается дата завершения проекта и возможные корректировки для искоренения задержек. Рис. 12.2. Пример. Линии исполнения для проекта 3.1.2. Построение линии исполнения Подготовка исходной информации: • базовое расписание в виде диаграммы Гантта или диаграммы «операции на стрелках» во временном масштабе (TAD); • отчеты о ходе исполнения или вербальная информация о ходе исполнения; • запросы на внесение изменений. Проведение встречи с владельцами операций. Как и в дни, когда процветало управление посредством общего надзора, мы предлагаем, чтобы менеджер проекта сначала встретился с владельцем каждой операции в приватной обстановке, один на один. Необходимо задать следующие вопросы: • Каков ход исполнения задач, входящих в операцию? • Отличается ли фактическое состояние от запланированного, и если отличается, то какие причины и проблемы привели к этому? • Когда, согласно предположениям владельца, задачи будут завершены? • Что может быть сделано для того, чтобы завершить их согласно плану; какую помощь вы можете предложить? Далее это надо перевести в показатели хода исполнения операции: в то, находится она впереди или позади расписания, какова предсказываемая дата завершения и каковы основные корректирующие воздействия. Потом владельцу придется на совещании выступать и обзоры хода исполнений составлять (тогда и без совещания можно обойтись). Созыв совещания о ходе исполнения. Совещание поможет решить вопросы: Как изменится весь проект Какие возникнут риски, Что сделать для снижения влияния. Владелец на них может и не ответить. Созываются регулярно, например, раз в месяц или раз в неделю, зависит от длительности проекта. Либо формальное сидячее, либо на бегу, либо электронное. ПРОАКТИВНЫЙ ЦИКЛ КОНТРОЛЯ ПРОЕКТА И ЦИКЛ PDSA ПО ДЕМИНГУ Пять вопросов проактивного управления 1. Каково отклонение фактического расписания проекта от базового? 2. Какие проблемы вызывают это отклонение? 3. Каков текущий (существующий) тренд, то есть какова предварительно предсказываемая дата завершения в том случае, если мы будем продолжать выполнение проекта с текущими показателями производительности? 4. Какие новые риски могут возникнуть в будущем и как они могут изменить предварительно предсказываемую дату завершения? 5. Какие действия нам следует предпринять для того, чтобы предотвратить срыв предсказанной даты завершения проекта и выполнить проект в соответствии с базовым планом? Гармонируют с бесконечным циклическим подходом к улучшению «планирование — выполнение — исследование — действие» по Демингу. После того как на шаге планирования установлен базовый план расписания и работы проекта выполняются на шаге выполнения, в игру вступают вопросы 1, 2, 3 и 4 РСРС на шаге исследования. Здесь, на этом шаге определяется отклонение по срокам, выясняется его причина и предсказывается тренд, основываясь на текущих проблемах и будущих рисках. Затем на шаге действия вопрос 5 приводит нас к идентификации связующих действий, которые будут планироваться и претворяться в жизнь (реализовываться) на следующем витке цикла PDSA. Рис. 12.3. Проактивный цикл контроля проекта является частью цикла «планирование — выполнение — исследование — действие» Задание вопросов о фактическом ходе исполнения операции. Те же самые пять вопросов РСРС, которые задавались на встречах с владельцами операций, должны быть заданы снова — для оценивания их успехов. Есть сложность: взаимодействие и зависимость между операциями. Это надо очень внимательно смотреть! Рисование линии исполнения. Рисование линии исполнения включает в себя несколько шагов. • Берем базовое расписание. • Отметить на календаре расписания дату совещания. Это статусная или отчетная дата. • Идем вниз и ищем первую операцию. Владелец скажет, на сколько дней операция опережает расписание или отстает от него. Жизненно важно, чтобы предоставленная владельцем операции информация была надежной. • Делаем изгиб на указанное количество дней. • Повторить данное действие для всех остальных операций. • И завершить опять на отчетной дате. МУСОР НА ВХОДЕ — МУСОР НА ВЫХОДЕ «В ходе совещания о ходе исполнения владелец операции сказал мне, что его операция отстает от расписания на 3 недели. Неделю спустя он заявил, что нагнал расписание и теперь идет строго по расписанию. Зная, что он является единственным человеком, задействованным в данной операции, я опросил нескольких экспертов: «Сколько часов могло бы потребоваться для того, чтобы устранить отставание?» Ответ был: «Около 150 часов». Вы думаете, он смог это сделать? Отнюдь! Он не хватает звезд с неба. Он просто подает неаккуратные отчеты. Ну и скажите мне в таком случае, как я могу упреждать события и предсказывать дату завершения проекта?» Эту историю мы услышали от менеджера проекта одной из ведущих фирм-производителей программного обеспечения, Мораль истории такова: некачественная отчетность об операции — некачественный прогноз тренда. Есть проблема точности получения оценок. Не ищут наилучшего, наиболее точного решения, ищут попроще, обеспечивающее достаточную точность. Возьмем, например, небольшой и несложный проект, являющийся одним из 5 проектов, находящихся под управлением данного менеджера. Менеджера не устраивает, если ему приходится тратить несколько часов своего времени на то, чтобы выяснить, что проект отстает от расписания на 7,2 дня. Стоимость получения этой информации слишком высока для него, хотя это и выглядит как рациональный до совершенства подход. Вместо этого менеджер может потратить полчаса времени на то, чтобы провести со своей командой неформальную встречу в ключе, диктуемом РСРС, и выяснить, что проект опаздывает приблизительно на неделю — десять дней. При поиске удовлетворительного и достаточного решения суть дела заключается в том, чтобы обеспечивать соответствие размера и сложности проекта с возможным решением проблемы и имеющимся в наличии временем. В общем и целом большая часть принимаемых менеджером проекта решений могут только выиграть от применения такого подхода. Дата завершения проекта. Можно подсчитать изменение. 3.1.3. Использование линии исполнения Когда использовать. Всегда. В гантте и в TAD. Трудоемкоить. Проектная команда, обладающая разумным уровнем навыков и подготовки, может подготовить линию исполнения для содержащей 25 операций диаграммы Гантта или TAD за 15—30 минут. По мере увеличения численности команды возрастает и требуемое время. +- История+прогноз. Зримо. Просто. Проактивно. Но. М.б. долго и сложно строить тренд изменения общего срока. Вариации. Хуже. • Метод частичного закрашивания. Несмотря на высокую наглядность, данный метод не показывает, когда началось фактическое выполнение операции, какая часть содержания операции фактически выполнена и на какое время операция опережает расписание или отстает от него. • Метод сравнительного отображения планируемого и фактического состояния. Можно видеть, когда началось фактическое выполнение операции • Метод сравнительного отображения планируемого и фактического состояния в сочетании с отображением доли выполненной работы. Процент работы есть, но не видно, на сколько времени операция отстает от расписания или опережает его. И везде много лент. Рис. 12.4. Менее эффективные альтернативы линии исполнения Вариация. Для мультипроектов по проектам. 3.2. BCF-анализ 3.2.1. Что такое BCF-анализ? BCF анализ (базовый план, текущее состояние, прогноз). Сравнивает базовый план с двумя предсказанными: по текущему состоянию и для наихудшего случая. Видна точка, к которой стремится расписание. Значит, можно увидеть и предотвратить неблагоприятные тенденции. Три расписания могут быть представлены в виде диаграммы Гантта либо TAD. 3.2.2. Выполнение bcf-анализа ИД: • базовое расписание в виде диаграммы Гантта или TAD; • отчеты о ходе исполнения либо словесная (устная) информация о фактической ходе исполнения; • запросы на внесение изменений. Рисование линии исполнения. См. выше. Подготовка текущего расписания. Надо предсказать, когда закончится каждая операция. Получатся новые значения длительности, даты начала и завершения. Строим новоерасписание. Это и есть текущее расписание, отражающее то, как проект, согласно ожиданиям, будет разворачиваться в будущем, основываясь на ходе исполнения, достигнутой на прошлых операциях. Рис. 12.5. Пример BCF анализа Разработка будущего расписания. 1. Идентификация рисков. Для разработки этого расписания следует задаться вопросом: «Какие риски могут возникнуть в будущем и пустить наш проект ко дну?» Это планирование по сценарию наихудшего случая, согласно которому дамоклов меч закона Мэрфи («если дела могут пойти плохо, то весьма вероятно, что они пойдут плохо» (у Мерфи есть еще хуже!)) висит над головой проекта. Хорошо вести базу проблем, которые были. Можно расспросить бывалых менеджеров об их наихудшем опыте выполнения подобных проектов. Например, один из них может рассказать о том, как однажды вендор технологии в проект приказал долго жить, чем отбросил проект на 6 месяцев назад. Проведение мозгового штурма совместно с членами команды также полезно для идентификации подобных рисков, особенно в случае, когда организация имеет контрольный список рисков. 2. Их влияние. На критические или некритические операции? Полностью ли съедают резерв? На какой срок смещение? 3. Изменяем расписание. Действия. Надо исправить. 2 пути. 1. Для быстрого прохода: • вернуться к будущему расписанию и сфокусировать свое внимание на жестких и мягких зависимостях; • преобразовать любые последовательно выполняемые операции, связанные жесткими зависимостями, в перекрывающиеся операции в максимально возможной степени, соблюдая при этом жесткие зависимости; • повторно изучить все мягкие зависимости для того, чтобы произвести перекрытие максимально возможного количества операций; • кроме того, принимая во внимание существующие мягкие зависимости, выделить те операции, которые могут быть выполнены вне последовательности, установленной в расписании. 2. Сжатие расписания путем выделения большего количества ресурсов для уменьшения длительности операций критического пути. 3. Комбинация. Минус: появится много критических путей. 3.2.3. Использование bcf анализа СОВЕТЫ ПО BCF-АНАЛИЗУ • Придать совещаниям по вопросу прогресса проекта и проведения BCF-анализа ритуальную значимость (возвести их в ранг ритуала). Чем лучше проводятся совещания, тем лучше будут результаты анализа. • Стремиться к получению достаточно хороших, но не совершенных текущих и будущих расписаний. Акцент должен делаться на тренде, а не точности. • Настоять на максимально возможном взаимодействии между владельцами операций на совещаниях о прогрессе для того, чтобы помочь им понять, как они влияют друг на друга и на проект. • Понаблюдать за тем, кто из владельцев операций склонен к чрезмерному оптимизму или пессимизму при предсказании времени завершения. Им может потребоваться индивидуальное обучение (тренировка) для преодоления этих тенденций. Когда использовать. Есть Гантт или TAD – можно использовать. Надо быть проактивным. Для малых подходит лучше. Трудоемкость. Проектная команда, обладающая разумным уровнем навыков и подготовки, может подготовить BCF анализ для содержащей 25 операций диаграммы Гантта или TAD за 45— 60 минут. По мере увеличения численности команды возрастает и требуемое время. +- Просто. Готовит видеть будущее. Обеспечивает предсказуемость расписания. Наглядно. Проактивно. Но. Проактивность непривычна. Лучше реагируют, когда проблема уже возникла. Бывает сложно, если большео расписание. Вариации. В мультипроектах. 3.3. Диаграмма прогнозирования контрольных событий 3.3.1. Суть Подобно другим проактивным инструментам контроля расписания, диаграмма прогнозирования контрольных событий предвидит темп будущего продвижения проекта. В отличие от других проактивных инструментов контроля расписания, она фокусируется на предсказании основных событий проекта — его контрольных событий и завершения. Рассмотрим рис. 12.6. Рис. 12.6. Пример диаграммы предсказания контрольных событий Отметим, что на вертикальной оси показаны предсказываемые даты наступления конкретных контрольных событий, а на горизонтальной — фактические даты, в которые выполнялись предсказания. Начальная точка горизонтальной оси — это время, когда было подготовлено базовое расписание. Контрольные события этого расписания отображены на вертикальной оси. Горизонтальная ось представляет собой фактическую временную шкалу проекта. Регулярно предсказываем. Получаемь линию тренда контрольного события. Если линия тренда приближается к линии выполнения, поднимаясь вверх, нам следует знать, что будет иметь место скольжение контрольного события. Если линия тренда приближается к линии выполнения горизонтально, это означает, что контрольное событие должно будет наступить точно в срок. И если, согласно нашим оценкам, контрольное событие наступит раньше срока, то линия тренда будет приближаться к линии выполнения, опускаясь вниз. Предсказания важно, но важнее возможность разработки действий, призванных устранить любое потенциальное отклонение от базового расписания контрольных событий. 3.3.2. Построение диаграммы предсказания контрольных событий ИД: • базовое расписание, предпочтительно такое, на котором отражены зависимости; • отчеты о ходе исполнения или вербальная информация о фактическом ходе исполнения; • запросы на внесение изменений. Определяем фактическое состояние дел. Встреча с владельцами плюс совещание. Лично получается быстро всё выяснить. Рисование диаграммы предсказания контрольных событий. 1. Контрольные события, находящиеся в базовом расписании, наносятся на вертикальную ось диаграммы — это будут контрольные события, наступающие «как запланировано»; 2. Линия выполнения проходит под 45%. 3. Прошло время. На совещании подготовленный надлежащим образом владелец первого контрольного события сжато описывает свой ход продвижения (более детальная информация может быть найдена в заштрихованном прямоугольнике «Выполняя оценивание фактического состояния, стремитесь к достижению удовлетворительного и достаточного решения»), потенциальное отклонение от базового плана, а также текущие проблемы, вызывающие это отклонение, и дает предварительное предсказание даты на ступления контрольного события. Опираясь на расписание, покапывающее зависимости мости между контрольными событиями / операциями, владелец высказывает свое мнение о том, как фактический статус контрольного события может повлиять на ход достижения зависящих от него контрольных событий. Разворачивается целенаправленная дискуссия. Владельцы зависимых контрольных событий запрашивают дополнительную информацию и делятся своим мнением о своем фактическом прогрессе, отклонениях и текущих проблемах. Они также дают предварительное предсказание дат наступления своих контрольных, анализируют их фактическое влияние на зависимые контрольные события и рассматривают возможные будущие риски, которые могут в будущем привести к срыву наступления контрольных событий. Получили предварительное предсказание. Обсуждением. 4. Смотрим, какие меры принять. 5. Делаем прогноз контрольного события. 3.3.3. Использование диаграммы предсказания контрольных событий Когда использовать. События должно быть 6…7 важных, а не десятки малозначимых. Трудоемкость. Небольшой опытной команде проекта должно хватить не более 30 минут на построение диаграммы, содержащей 6 или 7 контрольных событий. Увеличение численности проектной команды неизбежно увеличит требования ко времени. Не верю. Долгое обсуждение, с учетом возможных мер! +- Предсказуемость, проактивность. Ясное представление. Просто. популярно. Но. Если нет стремления к совершенству, тенденция к соскальзыванию рассматривается как угроза. Мало событий. Неточность оценок из-за сложной зависимости между контрольными событиями. Вариации. Только завершение проектов, много проектов. 3.4. Диаграмма скольжения 3.4.1. Что такое диаграмма скольжения? Диаграмма скольжения имеет двойное назначение. Она отслеживает ход исполнения и демонстрирует тренд, характеризующий исполнение расписания проекта. 1. Оценивает отклонение факта от плана (для всего проекта). 2. тренд. 3. Проактив. Рис. 12.7. Пример диаграммы скольжения 3.4.2. Разработка диаграммы скольжения ИД: • базовое расписание, предпочтительно в виде диаграммы критического пути, хотя может быть использована и диаграмма Гантта; • отчеты о ходе исполнения или вербальная информация о фактической ходе исполнения. • запросы на внесение изменений; Определяем текущее состояние как обычно. ПРОБЛЕМЫ И РИСКИ Помните вопросы 2 и 4 РСРС? Вот они: 1. Какие проблемы вызывают это отклонение? 2. Какие новые риски могут возникнуть в будущем и как они могут изменить предварительно предсказываемую дату завершения? Проблемы в прошлом. Это нерешенные вопросы. Риски в будущем. Возможность. Внимание к критическим и околокритическим. Рисование диаграммы скольжения. (Пример изложения материала.) Рисование данной диаграммы включает в себя несколько действий. • Найти на бланке, на котором будет нарисована диаграмма скольжения, время, соответствующее первому совещанию о прогрессе, или статусной дате. • Если имеется опоздание, сдвинуться вдоль вертикальной оси вверх и отметить точку соскальзывания. В случае опережения сделать то же самое, только сдвинуться вдоль вертикальной оси вниз. • Соединить точку нуля (начала отсчета) горизонтальной оси с точкой соскальзывания. • Повторить данные действия для каждой статусной даты, рисуя линию, состоящую из соединенных между собой точек скольжения. Например, на рис. 12.7 показано, что соскальзывание составляет 1 неделю в конце первой недели и 4 недели в конце четвертой недели. При помощи серьезного корректирующего воздействия проект был приведен в состояние 1 недельного опережения к концу седьмой недели. На рисовании линии, соединяющей точки соскальзывания, обычно и заканчивается традиционное применение диаграммы скольжения. Проектные команды, в которых принят упреждающий склад мышления, расширяют использование диаграммы скольжения дальше — на территорию предсказаний. На территории предсказаний. Учитывают то, что можно сделать. Важно! ОКНО МОЖЕТ БЫТЬ ЗАКРЫТО Задержался срок. Использовали резервный вариант – стороннюю организацию. Но она не может все время ждать. Говорит: или сейчас, или через месяц освободимся. Так что может оказаться долго! 3.4.3. Использование диаграммы скольжения Когда использовать. Всегда. Можно на Гантте и на критическом пути сетевого графика. Гантт не дает критического пути, поэтому сложнее. Трудоемкость. Небольшая знающая команда может разработать диаграмму скольжения для диаграммы Гантта или TAD содержащей 25 операций, за время порядка 30 минут. Увеличение численности команды с высокой вероятностью увеличит требования ко времени. Не верю. +- Регистрируется история. Тренд. Прогноз по тренду. Проактив. Наглядно. Просто. Но. Может быть времяемкой и не проактивной. ТРИ ОШИБКИ Руководители высшего звена в одной компании по производству автомобилей обожают диаграммы скольжения. Как следствие этого от всех основных проектов разработки продуктов, находящихся под их надзором, требуется подача (представление) такой диаграммы. Один менеджер проекта говорит так: «Моя команда регулярно собирается вместе и делает основной акцент на отчеты владельцев операций о прогрессе. Затем я сажусь и собственноручно готовлю диаграмму скольжения, которую отсылаю руководителям. Они изучают ее и говорят нам, какие корректирующие воздействия нужно предпринять». Данный способ использования диаграммы грешит по меньшей мере тремя ошибками. Во-первых, команда не использует диаграмму для предсказания будущего тренда. Во-вторых, команда не определяет корректирующие воздействия. И наконец, эти действия определяют руководители, не имеющие полного представления о возникших проблемах, воруя право собственности у команды. Урок, который можно извлечь, состоит в том, что нужно следовать проактивному циклу контроля проекта при использовании диаграммы скольжения. Вариации. В мультипроектах. 3.5. Диаграмма буферов 3.5.1. Что такое диаграмма буферов? Диаграмма буферов измеряет состояние буферов, устанавливаемых расписанием критической цепочки (CCS) с тем, чтобы обеспечить систему раннего предупреждения для того, чтобы защитить дату завершения проекта. Во первых, диаграмма буферов делает «мгновенный снимок» значений израсходованной доли буферов по отношению к доле работы, выполненной на критической цепочке (см. рис. 12.8). Последовательные снимки, выполняемые с регулярными периодическими интервалами, далее связываются в диаграмму для получения линии, отражающей тренд. Например, на рис. 12.8 линия показывает, что скорость расходования буфера превышает скорость выполнения работ критической цепочки. Другими словами, данная линия отвечает на вопрос «Как идут наши сегодняшние дела?», тем самым предоставляя информацию, позволяющую принимать упреждающие решения с целью повлиять на размер буфера. Согласно рис. 12.8, таким решением может являться совершение действия с целью восстановления размера буфера проекта. Рис. 12.8. Пример диаграммы буферов 3.5.2. Построение диаграммы буферов ИД: • расписание критической цепочки; • отчеты о ходе исполнения или вербальная информация о фактическом ходе исполнения; • запросы на внесение изменений. Определяем факт. Как раньше. Главное: сколько дней остается дол завершения каждой операции. Мониторинг проектного буфера и каждого CCFB(питающие буферы критической цепочки, буферы подпитки критической цепочки). Сколько дней осталось  когда закончим какая доля буфера использована. Смотреть надо реалистично. Сравниваем выполненные работы в цепочке и использованный буфер для этой цепочки. Особенно – критической. Строим диаграмму буферов. Использование диаграммы буферов проактивным образом. Чтобы была польза, надо обновлять с частотой в 1/3 длительности буфера. До 1/3 ничего не делаем, до 2/3 думаем, больше 2/3 действуем. Можно и по-другому (рис.). Подумаешь, в конце работ испоьзовали больше 2/3! 3.5.3. Использование диаграммы буферов Когда использовать. Выделенная проектная команда. Трнудоемкоить. Небольшая хорошо обученная и подготовленная команда может разработать диаграмму буферов для содержащего 100 операций расписания критической цепочки за 1—2 часа. При росте численности команды возрастает и требуемое время. Смотря что делать. По процессу с совещанием не получится. +- Частичный проактив (пока хорошо – не делаем. Это ж супер!!!). Наглядность. Виден тренд. Простота (?). Частичная проактивность. Но. Времяемкая, новая, основана на критической цепочке, не так уж и проста. 3.6. Сжатие расписания 3.6.1. Что такое сжатие расписания? Сжатие расписания — это метод сокращения общей длительности проекта без изменения логики проекта, иными словами, с сохранением неизменной последовательности зависимостей между операциями проекта [15]. Чтобы сжать длительность, проект обычно использует большее количество ресурсов при выполнении операций. Как следствие этого общая стоимость проекта возрастает (см. рис. 12.10). Рис. 12.10. Пример сжатия расписания 3.6.2. Выполнение сжатия расписания Сжатие расписания требует упорядоченных и терпеливых шагов. Эти шаги рассмотрены ниже на примере сжатия расписания с 7 до 4 дней (см. рис. 12.10). ИД: • базовое расписание в любом сетевом формате, исключая формат критической цепочки; • отчеты о ходе исполнения или вербальная информация о фактической ходе исполнения; • запросы на внесение изменений; • информация о ресурсах и стоимости. Чтобы определить оптимальный способ сжатия, мы опираемся на информацию о ресурсах и стоимости. Разработка нормального расписания с ориентацией на оптимальную стоимость. Это базовое расписание, разработанное на стадии планирования проекта. Здесь происходит выделение ресурсов в операции проекта и вычисление их стоимости. При отсутствии информации о ресурсах и стоимости сжатие расписания в том виде, в каком мы определяем его здесь, не представляется возможным. На рис. 12.10 мы приводим пример нормального расписания (начальное положение) со значениями длительности и стоимости каждой операции в таблице. Единицы времени надо выбрать. Пусть это будет день. Изменения – по единице! Разработка сжатого расписания с ориентацией на оптимальную стоимость (некорректно. Для каждой операции!). Сохраняя имеющуюся в проекте последовательность зависимостей между операциями, выполняем следующее. • Оцениваем для каждой операции наикратчайшее возможное время, в течение которого она может быть выполнена. • Задаем владельцам операций и команде вопрос: «Какие ресурсы нам необходимы для выполнения каждой операции таким образом? Сколько это будет стоить?» Процедура эта иногда бывает длительной и кропотливой, требующей большого объема оперативной и качественной информации. Кроме того, может потребоваться несколько итераций для выработки этих оценок, называемых сжатыми длительностями и сжатой стоимостью работ. В ходе этого процесса могут возникать различные проблемы. Например, некоторые операции могут не поддаваться выполнению в более краткие сроки, чем определяемые нормальным расписанием, либо, скажем, у вас возникает необходимость арендовать небольшое количество тестового оборудования, в то время как доступным оказывается только большое количество (и потому более дорогостоящее). Некоторые ресурсы, необходимые проекту, могут оказаться недоступны, даже есть имеется бюджет для их оплаты. В общем и целом эти оценки будут разрабатываться в соответствии с правилами оценивания сроков и стоимости, которые в значительной степени зависят от знания проектной технологии и производительности ресурсов. Как только сжатые длительности и сжатые стоимости подготовлены, сжатое расписание может считаться готовым. На рис. 12.10 в таблице приведены длительности и стоимости для каждой операции сжатого расписания. Вычисление крутизны стоимость/время (?). Операции изначально не равнозначны. Сокращение одних операций является более дорогостоящим, чем других. Вычисление крутизны стоимость / время покажет стоимость сокращения длительности каждой операции на один день. Для вычисления крутизны каждой операции (см. таблицу на рис. 12.10) используйте следующую формулу: Крутизна стоимость/время = (сжатая стоимость – – нормальная стоимость)/(нормальная длительность – – сжатая длительность). Эта формула создает основу для определения операции, сжатие которой обойдется наиболее дешево (будет иметь наименьшую стоимость). Однако на этом этапе начинать сжатие еще рано. Определить, в какой последовательности будет производиться сжатие операций. Сжатию подлежит только критический путь. Начинать необходимо со сжатия тех операций критического пути, сжатие которых имеет наименьшую стоимость. Наименьшую крутизну. Сокращаем ее на один день. Теперь наше расписание стало на 1 день короче (6 дней), а его стоимость стала равна стоимости нормального расписания плюс стоимость сокращения выбранной операции, что составило в сумме $210. Далее продолжаем сокращать критические операции на один день за один шаг, начиная с тех, которые характеризуются наи меньшей крутизной стоимость / время — см. Шаги 2 и 3 — до тех пор, пока не будет достигнута желаемая длительность расписания, равная 4 дням, и которая будет иметь стоимость $260. При наличии нескольких критических путей необходимо сжимать их все одновременно. Они появляются при сокращении. После сокращения операции D на Шаге 1 у нас имеются уже два критических пути: A D F и А В Е. Когда это случается, для сокращения общей длительности проекта необходимо сократить длительность всех (в нашем случае двух) критических путей одновременно. Вот почему на Шаге 2 мы «обращаем операцию А, принадлежащую обоим критическим путям, а на Шаге 3 — операцию D), лежащую на одном критическом пути, и операцию В — на другом. Именно из-за наличия нескольких критических путей мы настоятельно рекомендуем правило «сокращать на один день за один шаг» — ведь после того, как первоначальный критический путь оказывается сокращенным на 1 день, может возникнуть новый критический путь. Этот новый критический путь может остаться незамеченным, если мы за один шаг сократим первоначальный критический путь на два дня или больше. В этом случае сокращенное расписание может и не являться расписанием с наименьшей стоимостью, поскольку мы вполне могли пропустить сокращение операции на вновь возникшем критическом пути, имеющее более низкую стоимость, чем стоимость избыточного сокращения операции на первоначальном критическом пути. 3.6.3. Использование сжатия расписания Когда использовать. Вариант 1. Сделали план расписания, дали руководству. Требует сокращения. Вариант 2. Скользит. Надо исправить. Можно сочетать с быстрым проходом, но он меняет логику проекта!!! Трудоемкость. Сжатие сетевого графика, содержащего 250 операций, может потребовать от небольшой опытной проектной команды от половины дня до целого дня. При росте численности команды следует ожидать возрастания требуемого времени из-за усложнившейся коммуникации между членами команды. Сжатие, опирающееся на TAD, способствует уменьшению времени благодаря высокой наглядности, обеспечиваемой такой диаграммой. +- Показывает, что и как делать. Четко, пошагово. Минимизирует стоимость. Но. Сложен для больших проектов. Времяемкий. ПЯТЬ ЗОЛОТЫХ ПРАВИЛ СЖАТИЯ РАСПИСАНИЯ • Сжимать только операции, лежащие на критическом пути. • Сжимать на одну временую единицу расписания за один шаг (например, на один день за один шаг). • Когда существует несколько критических путей, сжимать их все одновременно. • Сначала сжимать те операции критического пути, которые имеют наименьшую стоимость сжатия (наименьшую крутизну стоимость / время). • Не сжимать некритические операции. Вариации. Если критично время, можно стоимость не рассматривать. Просто выделяют запас ресурсов. 3.7. Свод 4. Управление стоимостью Рис. 13.1. Роль инструментов контроля стоимости в процессе стандартизованного управления проектами По Разу: Рис. 17.3.1. Зависимость затрат проекта от его продолжительности 4.1. Анализ выполненной стоимости (?) «Экономическая добавленная стоимость» (EVA). Модель добавленной экономической стоимости Economic Value Added) Показатель EVA определяется как разница между чистой прибылью и стоимостью использованного для её получения собственного капитала компании. Стоимость использования капитала определяется на основе минимальной ожидаемой ставки доходности, необходимой для того, чтобы рассчитаться как с акционерами, так и с кредиторами. На самом деле это метод освоенного объема (Фурта) или метод сметной стоимости (Пресняков) . 4.1.1. Что такое анализ выполненной стоимости (EVA)? Периодическая регистрация прошлого для прогнозирования будущего. Отстает или опережает по срокам и стоимости и почему. Рис. 13.2. График (диаграмма) анализа выполненной стоимости Это всё очень сомнительно. Пресняков подумал ли, когда писал? Основная терминология анализа выполненной стоимости Плановая стоимость (PV) = бюджет = плановые стандарты = эапланированная работа = плановая стоимость планированных работ (ПСПР, BCWS); выражается в часах, долларах, единицах (изделиях) и т.д. Фактическая стоимость (АС) = реальный товар (реально существующие изделия) = фактическая стоимость выполненных работ (ФСВР, ACWP); выражается в часах, долларах, единицах (изделиях) и т.д. Выполненная стоимость (EV) = достигнутое = выполненные стандарты = плановая стоимость выполненных работ (ПСВР, BCWP); выражается в часах, долларах, единицах (изделиях) и т.д. Отклонение по стоимости (CV) = EV – АС, выражается в часах, долларах, единицах (изделиях) и т д. Отклонение от графика (SV) = EV – PV; выражается в часах, доллаpax, единицах (изделиях) И Т.Д. При использовании другой формулы также может выражаться в единицах времени (например, в днях). Отклонение по затратам = PV – АС; выражается в часах, долларах, единицах (изделиях) и т.д. Индекс выполнения стоимости (ИВСТ, СП) = LV / АС. Индекс выполнения сроков работ (ИВСР, SPI) = EV / PV. Бюджет по завершении (БПЗ, ВАС) = первоначальный общий (полный) бюджет, необходимый для выполнения проекта; выражается в часах, долларах, единицах (изделиях) и т д. Оценка по завершении (ЕАС) = (АС / EV) - ВАС; прогнозируемый бюджет на момент окончания проекта; выражается в часах, долларах, единицах (изделиях) и т.д. Расписание по завершении (SAC) = (PV / EV) - первоначальное описание; прогнозируемая длительность проекта на момент окончания проекта, выражается во временных единицах (днях, неделях, месяцах). Прогнозируемый перерасход бюджета = отклонение бюджета по завершении (ОПЗ, VAC),выражается в часах, долларах, единицах (изделиях) и т.д. Прогнозируемая задержка расписания = отклонение по срокам по завершении (SVAC); выражается в часах, долларах, единицах (изделиях) и т. д. Отчетная дата = дата разделения данных (статусная дата) = сегодня = точка во времени, в которой выполняется ЕVA. 4.1.2. Осуществление анализа выполненной стоимости Впервые концепция была предложена промышленными инженерами XIX века. Развился. В правительственных проектах используется, в частных – мало. Надо им попроще. Тут попроще. ИД: • Полностью определенное содержание проекта. • Расписание проекта. Уже твердое, утвержденное. • График использования ресурсов. Иными словами – базовый план. Формирование базового плана измерения хода исполнения (РМВ, Performance Measurement Baseline). Вам необходимо установить РМВ для того, чтобы определять, какую часть запланированной работы вы выполнили в каждый момент временной шкалы проекта. Установка РМВ включает в себя выполнение трех задач: • Определение точек управленческого контроля (контроля со стороны руководства) и лиц, ответственных за них. План контрольных счетов (CAP?) см врезку. • Выбор метода измерения выполненной стоимости. • Установка РМВ. КЛЮЧЕВЫЕ КОМПОНЕНТЫ ПЛАНА КОНТРОЛЬНОГО СЧЕТА • Словесное (повествовательное) описание содержания. • Расположение в СДР, т.е. на каком уровне находится (например, на уровне 1 СДР, в которой уровень 0 соответствует уровню проекта, уровень 1 — САР и уровень 2 — пакетам работ). • Входящие в САР пакеты работ (например, уровень 2 для пакетов работ). • Временная шкала (например, даты начала / завершения каждого пакета работ). • Бюджет (часы работы ресурсов, доллары или единицы (изделия) для каждого пакета работ). • Владелец; лицо, ответственное за САР (например, вице/президент по маркетингу). • Тип работ (например, неповторяющиеся или повторяющиеся). • Методы измерения хода исполнения для EVA (например, взвешенные контрольные события). 1. точки. Надо, чтобы САР был контролируемым. Если взять высокий уровень, что будут завязаны многие подразделения. Но зато менеджер проекта будет меньша анализировать. В каждый САР должно быть назначено лицо, ответственное за его исполнение. На рис. 13.3 приведен пример САР. Тут только бюджет времени, так как большинство менеджеров только и работает с этим. Рис. 13.3. Формирование плана контрольного счета Из Project and Program Risk Management: A Guide to Managing Project Risks and Opportunities, Max R. Wideman, ed, Newton Square, PA: Project Management Institute, Inc., 1992. 2. Измерение хода исполнения САР. Самое важное, нужны четкие методы. Они разные. Легко, точно, согласованно по элементам работ. Метод процента выполненной работы использует периодическую — например, выполняемую раз в неделю или раз в месяц — оценку доли выполненных работ пакета, выражаемую в виде кумулятивной величины (например, 65%) по отношению к 100% — полному объему работ пакета. Считающийся простым и быстрым методом, что, возможно, объясняет его широкую популярность, этот метод также считается и чрезмерно субъективным. Четкое определение содержания пакетов работ и проверка точности оценок помогает снизить степень субъективизма до приемлемого уровня. Фиксированная формула для пакета работ предполагает различные варианты выбора: 25/75, 50/50, 75/25 и т.д. Например, формула 25/75 означает, что, когда исполнение пакета работ начинается, выполненным считается 25 % бюджета пакета, а когда заканчивается —добавляются остальные 75%. Естественно, что любое сочетание чисел, равных в сумме 100%, может быть использовано. Это достаточно быстрый способ оценивания, применимый в ситуациях, когда пакеты работ имеют малую длительность и выполняются каскадно в определенных временных рамках. Довольно точно. Таблица 13.1. Основы основных методов измерения выполненной стоимости Тип метода Когда использовать Основное преимущество Основной недостаток (1) (2) (3) (4) Доля выполненной работы Хорошо определенные пакеты работы; наличие проводимых руководством обзоров; неповторяющиеся задачи Наиболее легкий метод с точки администрирования Осуществляется полностью на субъективной основе Фиксированная формула Пакеты работы детализированы и имеют краткую протяженность Легкий для понимания Довольно субъективен Взвешенные контрольные события Пакеты работ выполняются в течение одного/двух периодов измерения хода исполнения (отчет/ ных периодов); неповторяющиеся задачи Возможно, наиболее объективный метод Труден в планировании и администрировании Доля выполненной работы с шлюзовыми контрольными событиями Работает в любой отрасли, на любом типе проекта; неповторяющиеся задачи Легкий и объективный одновременно Требует времени и сил для определения значимых контрольных событий Выполненные стандарты (нормы) Предварительно установленные стандарты исполнения; неповторяющиеся или повторяющиеся задачи Возможно, наиболее сложный из всех методов Требует наибольшей дисциплинированности Эквивалентные единицы Длинные периодывыполнения; неповторяющиеся или повторяющиеся задачи Простой и эффективный Требует детальной восходящей оценки ФОРМУЛА 50/50 ПРЕДЛАГАЕТ РАЗУМНУЮ ТОЧНОСТЬ Рассмотрим проект, имеющий следующие характеристики: бюджет $ 1.040.000, длительность проекта — 1 год, количество пакетов — 520, средняя длительность пакета — 1 неделя, количество выполняемых пакетов в неделю — 10, ошибка выполнения оценки пакета — 50%, причем все ошибки накапливаются, а не компенсируют друг друга. В этом случае Brandon определил максимальную ошибку с использованием формулы 50/50 как [2]: Максимальная ошибка = (среднее количество выполняемых пакетов в неделю * средняя стоимость пакета * 0.5)/общая стоимость = ()10 * $2.000 * 0.5)/$1.040.000 = 0.009, то есть меньше, чем 1%, что является весьма точным результатом. Взвешенные контрольные события — это метод деления долгосрочного пакета работ контрольными событиями на несколько фрагментов, каждому из которых назначается своя доля бюджета, которая считается выполненной, когда данное событие наступает. Этот метод весьма объективен, однако, успех его применения в значительной степени зависит от того, удастся ли определить значимые контрольные события — материальные, поддающиеся бюджетированию и календарному планированию. Доля выполненных работ в сочетании с шлюзовыми контрольными событиями сочетает в себе легкость применения, свойственную методу определения доли выполненных работ и точность материальных контрольных событий. Пакет работ, имеющий длительность, скажем, 600 часов, разбивается на 3 последовательных контрольных события, каждое из которых бюджетируется в объеме 200 часов и рассматривается как шлюз при оценивании хода исполнения. Вам позволено оценивать выполненную стоимость первого контрольного события в виде процента вплоть до 200 часов. Для того чтобы оценка смогла перешагнуть за 200 часов, вам необходимо удовлетворить предустановленным критериям, определяющим наступление этого контрольного события. Эта же процедура повторяется и для остальных контрольных событий [1]. Выполненные стандарты (нормы) — это метод, часто применяемый промышленными инженерами для установки запланированных стандартов исполнения пакетов работ, которые затем используются в качестве основы для бюджетирования пакетов и последующего измерения их выполненной стоимости. Например, запланированный стандарт для изготовления чашки лимонада, равный $ 0.20 / чашку, используется для бюджетирования пакета работ, включающего в себя изготовление 1000 чашек, в размере $200. Когда будет изготовлено 50 чашек, то, вне зависимости от фактических затрат на изготовление, выполненная стоимость составит 500 чашек * 0.20 $ / чашку = $100. Широко распространенный при оценивании повторяющихся работ проекта, этот метод опирается на запланированные стандарты, разработанные на основе исследования исторических данных о расходах, времени и трудовых движениях [1]. В методе эквивалентных выполненных единиц стоимость запланированного пакета работ считается выполненной, когда исполнение пакета полностью завершено. Например, пакет работ по постройке 5 миль (5 единиц) шоссе оценивается как $3.000.000 / милю, таким образом, его полная стоимость составит $15.000.000. Выполненная стоимость этого пакета работ станет равна своему максимальному значению, когда все 5 миль шоссе будут завершены. Следовательно, когда будет завершена укладка 0.5 мили шоссе, выполненная стоимость этого объема работ составит $1.500.000. Основанный на детальной восходящей оценке, этот метод уважается в строительной промышленности, однако, никогда не назывался в ней своим настоящим именем — методом выполненной стоимости(???). Важно. 1. Пакет работ — это то место, в котором производится измерение, в то время как САР — это место, где происходит суммирование этих отдельных измерений пакетов работ. 2. Наилучшего метода нет. На последнем рисунке проект разработки состоит из 3 САР, по сути, представляющих собой 3 фазы уровня 1 СДР. Внутри САР все пакеты измеряются по одному методу. Контрольная линия. РМВ представляет собой распределенную во времени сумму детализированных и поддающихся индивидуальному измерению САР. Что именно будет включено в САР, зависит от того, как компания определяет обязанности своих менеджеров проектов по части управления стоимостью. Во многих компаниях менеджерам внутренних проектов разрешается управлять только прямыми расходами на оплату труда, которые и являются предметом нашего рассмотрения здесь. Анализируются только часы прямых трудозатрат. Другая противоположность — компании, менеджеры проектов которых управляют всеми расходами проекта, равно как управленческими резервами и прибылью. Соответственно, и РМВ таких проектов будут отражать эту ситуацию. И, наконец, третьи компании устанавливают состав своих РМВ и обязанности своих менеджеров проектов где-то посередине между этими двумя крайностями. Если всё четко, то делаем твердый РМВ с детальными САР еще до начала выполнения проекта. Если неясно, то методом бегущей волны (рис). Если CAP меняется, то нужна процедура изменений. Рис. 13.4. Базовый план измерения хода исполнения: суммма планов контрольных счетов Из Earned Value Project Management, Second Edition, Quintin W. Fleming and Joel M. Koppelman. Newton Square, PA: Project Management Institute, Inc., 2000. Для целей практического использования EVA распределенный во времени РМВ может быть представлен как кумулятивная кривая, отражающая плановую стоимость как функцию расписания проекта. Это кривая показана на рис. 13.5b. Она начерчена для проекта, данные о ходе исполнения которого приведены на рис. 13.5а. Итак, РМВ на данный момент оказывается сформирован. Он состоит из детальных САР, каждый из которых, по сути, является одной из форм субпроекта. Разобрать пример. Рис. 13.5. Осуществление анализа выполненной стоимости Оценивание результатов проекта. Сравнение плана и факта. По счетам, периодически. Можно и на уровне подытогов (элемент СДР) или на уровне элеменгта оргструктуры. Этот шаг включает в себя следующее: • Расписание: оценить отклонение по срокам (SV) и индекс выполнения сроков работ (ИВСР, SPI). • Стоимость: оценить отклонение по стоимости (CV) и индекс выполнения расписания (ИВСТ, CPI). • В случае наличия отклонений идентифицировать их причины. Строим кривые рис. 13.5с. Результаты обманчивы. В примере в конце марта разность между двумя кривыми — называемая отклонением по затратам — отражает тот факт, находится ли проект в пределах одобренного бюджета. Она ни в коей мере не определяет фактический статус проекта по части исполнения стоимости. Рис. 13.5с, показывает, что фактическое исполнение проекта находится в пределах бюджета (300 часов – 270 часов = 30 часов), из чего можно сделать вывод, что ситуация благоприятная. На самом деле есть проблемы, но их не видно. 1. Два графика оцениваею разные работы. 2. Опирается только на стоимость. Лекарство от этих проблем — график, который объединяет истинное исполнение стоимости и расписания. Именно на этом этапе в дело включается кривая выполненной стоимости, как показано на рис. 13.5d. Сравнение выполненной и плановой стоимости в конце марта показывает следующее: Отклонение по срокам (SV) = EV – PV – 225, часов – 300 часов = = –75 часов. Отрицательное отклонение по срокам означает, что исполнение проекта отстает от плана. Взгляд на рис. 13.5d открывает нам два проявления одного и того же отклонения по срокам: одно проявление вертикально и выражается в часах (единицах бюджета), а другое — горизонтально и выражается в единицах времени. Неудивительно, если вы предпочтете использовать второе — выражаемое в единицах времени (днях, неделях, месяцах). Всегда, когда SV отрицательно, проект отстает от плана, и всегда, когда SV положительно, он опережает план. Еще одна задача, относящаяся к определению своего положения по отношению к расписанию, это вычисление ИВСР. В конце марта, согласно рис. 13.5d, ситуация выглядит следующим образом: ИВСР = EV / PV = 225 / 300 = 0.75. ИВСР дает численную оценку того, какова фактическая ценность (стоимостный эквивалент) выполненных работ по сравнению с изначально запланированной. Иными словами, он показывает, какая часть первоначально запланированной работы была выполнена на конкретный момент времени [1]. ИВСР, равный 1, означает безупречное выполнение плана. ИВСР, больший 1, показывает, что проект опережает план, а ИВСР, меньший 1, отражает отставание проекта от плана. Следовательно, полученный в нашем случае ИВСР, равный 0.75, показывает, что выполнено 75% первоначально запланированных работ. Это значит, что наш проект значительно, а говоря точнее, на 25% (1 – 0.75 = 0.25), отстает от базового плана работ. Так как наша отчетная дата в марте соответствует 90 му дню проекта, мы можем сказать, что наш проект отстает от первоначального плана работ на 22.5% (25 процентов от 90 дней). Комментарии по расписанию. Допустим, задержка исполнения расписания (отрицательное SV и ИВСР меньше 1). Но это не по критическому пути. Один пакет плохо, может, другой лучше. Этого анализа мало. Надо одновременно и критический путь анализировать, и анализ рисков. Если опаздывающие пакеты работ / задачи лежат на критическом пути или характеризуются высокими рисками для проекта, необходимо завершать эти пакеты работ / задачи в как можно более короткий срок [1]. Теперь мы можем перейти к нашей второй области интереса на данном шаге — к вычислению отклонения по стоимости (CV) и индекса выполнения стоимости (ИВСТ, CPI). На конец марта, согласно рис. 13.5d, мы имеем: Отклонение по стоимости (CV) = EV – AC = = 225 часов – 270 часов = –45 часов и ИВСТ = EV/AC = 225 / 270 = 0.83. Назначение CV состоит в том, чтобы отразить разницу между выполненной стоимостью физически выполненной работы и фактической стоимостью выполнения этой работы. Следовательно, положительное CV означает, что проект недорасходует бюджет, в то время как отрицательное CV означает, что проект имеет задолженность и испытывает перерасход. Наш случай — это, очевидно, случай перерасхода бюджета на 45 часов сверх того количества, которое было выделено для выполнения данного объема работ. ИВСТ — это показатель эффективности (?) исполнения стоимости (индекс выполнения стоимости). ИВСТ устанавливает кумулятивное (от момента начала и до текущего момента) положение (состояние) проекта по части исполнения стоимости. Когда ИВСТ равен 1, мы имеем безупречное выполнение первоначального бюджета. Значения ИВСТ, большие 1, говорят о том, что проект недорасходует бюджетные средства, в то время как значения ИВСТ, меньшие 1, сигнализируют о проблемах, связанных с перерасходом средств. В частности, ИВСТ, равный 0.83, в нашем примере говорит о том, что выполненная стоимость (созданная ценность, стоимостный эквивалент) физически выполненной работы составляет лишь 83% от фактической стоимости выполнения этой работы. Если это сформулировать по-другому, то 17 % (1 – 0.83 = 0.17) фактически израсходованных часов бюджета — это перерасход бюджета. Откуда взялись эти отклонения в нашем примере? Важно, что кумулятивно. Флуктуации сшлаживаются и тренд виден. Предсказание окончательных результатов проекта. Это очень полезно. Предсказывать можно, когда будет сделано 15% работ и далее (для тренда). Предсказание включает в себя: • предсказание даты завершения проекта; • предсказание стоимости проекта по его завершении; • совершение корректирующих воздействий, если таковые необходимы. Рис. 13.6. Отслеживание кумулятивных значений индекса выполнения сроков (ИВСР) и индекса выполнения стоимости (ИВСТ) Быстрое предсказание даты завершения для нашего примера (рис. 13.5d) на конец марта выглядит следующим образом: Расписание по завершении (SAC) = = первоначальное расписание / ИВСР = 150 дней / 0.75 = 200 дней. Этот быстрый метод, к сожалению, может представлять определенный риск. Как уже упоминалось выше, ситуация, когда проект отстает от расписания и, как в нашем примере, имеет отрицательное отклонение по срокам, а ИВСР, меньший 1, не принимает во внимание информацию о критическом пути и потому может быть обманчивой. Следовательно, более хорошее решение — предсказание даты завершения, основываясь на результатах анализа критического пути в сочетании с анализом отклонения по срокам согласно EVA. Из более чем 20 имеющихся формул оценивания стоимости проекта по завершении [1] мы рассмотрим лишь 2 наиболее часто используемые. Ниже приводится формула для предсказания нижнего значения стоимости: Оценка по завершении (ОПЗ) = бюджет по завершении (БПЗ) / / ИВСТ = 500 часов / 0.83 = 600 часов. Это значит, что по завершении проекта выяснится, что нам понадобилось 600 часов для того, чтобы проект оказался выполненным. Таким образом, отклонение по завершении составит целых 100 часов сверх первоначального бюджета. Ясно, что данный метод — называемый оценкой с постоянной эффективностью исполнения стоимости — опирается на значение перерасхода на сегодняшний день и проецирует его на момент окончания проекта, рис. 13.2 включает в себя предсказание окончательных результатов, полученное с использованием метода быстрого предсказания для расписания по завершении (SAC) и формулы нижнего значения для оценки по завершении (ОПЗ). Более строгий метод, основанный на нашем предсказании, сделанном с использованием значений перерасхода средств и скольжения расписания на текущий момент, называется оценкой с постоянной эффективностью исполнения стоимости и расписания: ОПЗ = БПЗ / (ИВСТ * ИВСР) = 500 часов / 0.625 = 800 часов. Используя этот метод, мы получили значение отклонения о завершении в размере 300 часов. Некоторые исследователи обнаружили, что оценка нижнего значения вполне надежно предсказывает «минимальное» количество часов бюджета, которое может нам понадобиться, а верхнего — «максимальное» количество часов. Разумно использовать 2 метода, так как есть разный опыт. Очевидно, зависит от проекта, можно набраться опыта. Общий результат зависит от того, что сделает руководство. 4.1.3. Использование eva Когда использовать. Всегда, для простых проектов можно попроще. Трудоемкость. Любой проект, нуждающийся в EVA, должен установить содержание, выполнить бюджетирование ресурсов и произвести календарное планирование задач. Когда все это готово, малые проекты могут считаться готовыми к проведению простых версий EVA. В такой ситуации проект, включающий в себя 10 задач с той или иной степенью перекрытия и бюджет, состоящий из 300—500 часов ресурсов, может иметь еженедельно несколько задач, подлежащих оценке. Для их оценки, по всей видимости, потребуется не более часа времени. Для больших проектов – в десятки раз больше. +- Ответ на вопрос, выпоняется ли проект по расписанию, выполняется ли проект в соответствии с бюджетом, недорасходует ли его или перерасходует. Проактивно, даже раннее предупреждение. Поведение стаблиьно обычно после 15% для больших и 10% для малых, так что можно точно предсказывать. Единая картина (например, если в организации разные проекты), а не состаные части. Видно, какие задачи нуждаются в исправлении. Концептуально прост. Легок в освоении. Но. Мало используется. По оценкам некоторых экспертов, возможно, менее 1% всех проектов — главным образом, те, которые включают в себя приобретение крупных систем правительствами — применяют этот метод. Причины этого могут лежать в истории применения данного инструмента, насыщенной сбивающей с толку терминологией и множеством правил и интерпретаций, устанавливаемых правительствами как основными пользователями. Это бюрократическое мышление могло отпугнуть многих потенциальных пользователей, ибо создало анализу выполненной стоимости имидж правительственного инструмента, неспособного принести пользу в частном секто ре. Этот расхожий миф привел к тому, что многие компании упустили возможность адаптировать этот инструмент к своим проектным нуждам и воспользоваться многочисленными предоставляемыми им выгодами. Вариации. Анализ контрольных событий (ниже) Суть у него та же. Анализ стоимости и выполнения кратко рассматривается ниже, а его иллюстрация приведена на рис. 13.7. (не понял!!!) Основываясь на содержании и расписании задачи, определяется ее бюджет (то же самое, что и плановая стоимость в EVA) в часах работы ресурсов. Умножение бюджета на долю выполненных работ дает нам достигнутую ценность (эквивалент выполненной стоимости в EVA). Фактически израсходованные часы (эквивалентные фактической стоимости в EVA), потребовавшиеся для выполнения объема работ, определяемого достигнутой ценностью, также подлежат фиксации. Величины бюджета, достигнутой ценности и фактической стоимости используются затем для предсказания окончательной стоимости задачи. Выполнение этих шагов на регулярной основе для каждой задачи и использование кумулятивных показателей дают возможность суммировать эти величины для получения бюджета, достигнутой ценности и фактической стоимости всего проекта и предсказывать окончательную стоимость проекта. Этот подход предоставляет огромные возможности по проактивному управлению небольшими проектами. Рис. 13.7. Анализ стоимости и выполнения Адаптация. Например, не счета брать, а затраты труда и их самому измерять. 4.2. Анализ контрольных событий 4.2.1. Суть Анализ контрольных событий выполняет сравнение планового и фактического исполнения стоимости для контрольных событий, чтобы определить отклонения по стоимости и срокам, являющиеся показателями хода исполнения проекта (см. рис. 13.8). Стоимость контрольного события планируется и отслеживается по оси у, а его календарь — по оси х. Расхождение между плановой и фактической стоимостью контрольного события представляет собой отклонение по стоимости. Аналогично отклонение по срокам может быть получено как разность между плановым и фактическим расписаниями данного контрольного события. Как плановые, так и фактические величины отражаются в виде кумулятивных кривых. Использование этих двух кривых — в противоположность трем кривым метода EVA — плановой, фактической и выполненной — стало возможным благодаря использованию контрольных событий в качестве платформы для интеграции содержания, расписания и бюджета. Несмотря на свою высокую эффективность в отслеживании исполнения проектов, анализ контрольных событий гораздо более эффективен при проактивном использовании для предсказания окончательной стоимости и даты завершения проекта. 4.2.2. Выполнение анализа контрольных событий Анализ контрольных событий следует выполнять в полной гармонии с проактивным циклом контроля проекта (РСРС), рассмотренным нами в главе 11. ИД: • полностью определенное содержание проекта; • расписание проекта; • распределенный во времени бюджет. Установка и отслеживание контрольных событий. Рис. 13.8. Пример анализа контрольных событий Используя базовый план стоимости (распределенный во времени бюджет), нарисовать кумулятивную кривую плановой стоимости и отметить на ней контрольные события (см. рис. 13.8). В бюджет каждого контрольного события выделяется определенное количество часов работы ресурсов. На момент наступления некоторого контрольного события должно быть израсходовано суммарное количество часов ресурсов этого и предшественников. Собираем фактические данные. Строим кривую фактической стоимости и реальное время событий. Итак, уровень контрольных событий, шкала 0-100. Нет осбытия – 0 затрат настуипло – 100%. Точках контрольных событий ход кривая равна рекльной. Оценивание результатов проекта. Сравниваем с планом. По срокам и стоимости. Встречаемся, совещаемся. Настало время сравнить фактические результаты выполнения проекта с планом. ПЯТЬ ВОПРОСОВ РСРС ПРИМЕНИТЕЛЬНО К КОНТРОЛЮ СТОИМОСТИ Подобно контролю расписания, контроль стоимости должен выполняться с опорой на вопросы проактивного цикла контроля проекта (РСРС). • Каково отклонение фактического исполнения стоимости от базового плана исполнения стоимости? • Какие проблемы вызывают это отклонение? • Каков текущий тренд, то есть какова предварительно предсказываемая оценка стоимости по завершении в том случае, если мы будем продолжать выполнение проекта с текущими показателями производительности? • Какие новые риски могут возникнуть в будущем и как они могут изменить предварительно предсказываемую оценку стоимости по завершении? • Какие действия нам следует предпринять для того, чтобы предотвратить изменение предсказываемой оценки стоимости по завершении и выполнить проект в соответствии с базовым планом? Как EVA, так и анализ контрольных событий должен следовать этому циклу — начиная от встреч-репетиций с владельцами операций / контрольных событий и заканчивая совещаниями о ходе исполнения, проводимыми для определения корректирующих воздействий. В нашем примере на рис. 13.8 отклонения выглядят следующим образом: Отклонение по срокам для контрольного события 2 = = плановое значение – фактическое значение = = 2 месяца – 3 месяца = –1 месяц Отклонение по стоимости для контрольного события 2 = = плановое значение – фактическое значение = = 600 часов – 900 часов = –300 часов. Отрицательное отклонение означает, что проект отстает от плана, а положительное — что опережает его. Отсутствие отклонения означает, что проект выполняется в точном соответствии с планом. Следовательно, в нашем случае проект на 1 месяц отстает от расписания и на 300 часов перерасходовал бюджет. Предсказание окончательных результатов. Формул нет, дело интуитивное. На основе критического пути. Могут понадобится корректирующие воздействия. 4.2.3. Использование анализа контрольных событий Когда использовать. Всем, особенно малобюджетным. В больших – краткий вид дает. Трудоемкость. Если есть плановая кривая, то на 5…6 контрольных событий надо 30…45 минут. +- Проще предыдущего. Стоимость+расписание, так как контрольное событие = точное содержание работ. Хватает двух кривых, а выгоды предыдущего практически сохраняются. Графическое представление. Простота. Но. Много событий – путаница. Возможно манипулирование данными. Вариации. Можно смотреть только расписание. (не та сводная таблица!) Может, названия не те??? 4.3. Показатели и их расчет Показатель Формула или способ расчета Плановая стоимость выполненных работ (BCWP, освоенный объем). Плановая стоимость фактически выполненных работ или количество ресурса, запланированное на фактически выполненный объем работ к текущей дате BCWP = Плановая стоимость х х % использования ресурса Общие бюджетные затраты Полная стоимость работы, принятая в базовом плане Бюджетная стоимость (BCWS). Часть стоимости работы, которая должна быть освоена к текущей дате в соответствии с базовым планом (стоимость работы в расчете за период времени по плану) Общие бюджетные затраты х % по плану Фактические затраты (ACWP) Фактические затраты по работе на текущую дату Индекс освоения затрат = 1 - затраты на текущую дату соответствуют плану > 1 - на текущую дату затрачено меньше средств, чем предусмотрено < 1 - на текущую дату средств затрачено больше, чем предусмотрено Освоенный объем / Фактические затраты Отклонение по затратам < 0 — перерасход средств на текущую дату > 0 - недорасход средств на текущую дату Освоенный объем -Фактические затраты Относительное отклонение по затратам Показывает отношение отклонения по затратам к запланированным по бюджету затратам на текущую дату (BCWS) Оценка стоимости до завершения Базируется на текущих результатах Оценка (прогноз) стоимости по завершении — оценка полной стоимости работы, базирующаяся на текущих результатах Фактические затраты + Оценка стоимости до завершения Индекс выполнения плана — отношение освоенного объема к бюджетной стоимости работ по плану на текущую дату Освоенный объем / Бюджетная стоимость Расхождение по затратам < 0 — перерасход затрат Бюджетные затраты - Оценка стоимости по завершении Процент перерасхода затрат, % Расхождение по затратам / Бюджетные затраты Помимо оценки суммарных затрат на выполнение проекта, на основании наблюдаемых показателей освоенного объема возможно также прогнозирование и других характеристик проекта. Поясним разницу между традиционным методом и методом освоенного объема на примере. Допустим, бюджет проекта составляет 100 ден. ед. На выполнение работ до текущей даты планировалось израсходовать 25 единиц, а фактически было израсходовано 22 ед., т. е. BCWS = 25, а ACWP = 22. При этом, согласно плану, на выполнение работ нужно было израсходовать 20 ед., т. е. BCWP = 20. В соответствии с традиционным подходом отклонение по затратам составляет 25—22=3 ед., т. е. наблюдается экономия. В соответствии с методом освоенного объема реальное отклонение по затратам составляет 20—22—2 ед., т. е. имеет место перерасход денежных средств. При этом отклонение от графика расхода денежных средств составляет 25—20=5 ед., что говорит об отставании реального хода выполнения проекта от запланированного на 20%. Прогнозирование затрат подразумевает оценку конечной стоимости проекта на основании информации о затратах проекта на текущий момент времени. Существуют следующие варианты оценки конечной стоимости проекта (ЕАС), при которых используются как традиционный метод оценки, так и метод освоенного объема: Стоимость по завершении = Фактические затраты на текущую дату + Оставшаяся стоимость проекта, скорректированная с учетом индекса освоения затрат; Стоимость по завершении = Фактические затраты на текущую дату + Оценка оставшейся стоимости проекта (ETC); Стоимость по завершении = Фактические затраты на текущую дату + Новая смета на оставшуюся часть проекта. Индекс освоения затрат (CPI) рассчитывается как отношение освоенного объема к фактическим затратам: Параллельно рассчитывается индекс выполнения расписания (SPI): С использованием этих показателей оценка затрат по завершении (прогнозировании затрат) рассчитывается следующим образом: 1.Традиционный метод ЕАС = ACWP + ETC. 2.Метод освоенного объема Пессимистическая оценка Оптимистическая оценка Также может использоваться показатель прогнозного отклонения стоимости проекта (variance at completion — VAC): VAC=BAC - ЕАС. В этих формулах используются суммарные индексы, а не периодические или дискретные. Периодические данные о затратах в различные моменты времени могут значительно отличаться друг от друга, что в итоге некорректно отразиться на конечной оценке. Суммарные данные сглаживают эти отклонения, оставаясь при этом более надежным инструментом для долгосрочного прогнозирования. В любом случае нельзя забывать, что с какой бы точностью ни была сделана оценка по завершении, она не будет на 100% корректно отражать конечный результат проекта. Чем ближе момент оценки к моменту завершения проекта, тем меньше разница между этими двумя величинами. Пример расчета контрольных показателей стоимости проекта приведен в табл. 14.4.2. Таблица 14.4.2 Пример расчета показателей выполнения бюджета проекта Плановые затраты Освоенный объем Фактические затраты Отклонение по затратам Отклонение по расписанию Работа BCWS BCWP ACWP CV($) CVP(%) SV($) SVP (%) 1 63,000 58,000 62,500 -4,500 -7,8 -5,000 -7,9 2 64,000 48,000 46,800 1,200 2,5 -16,000 -25,0 3 23,000 20,000 23,500 -3,500 -17,5 -3,000 -13,0 4 68,000 68,000 72,500 -4,500 -6,6 0,0 5 12,000 10,000 10,000 0,0 -2,000 -16,7 6 7,000 6,200 6,000 200 3,2 -800 -11,4 7 20,000 13,500 18,100 -4,600 -34,1 -6,500 -32,5 Всего 257,000 223,700 239,400 -15,700 -7,0 -33,300 -13,0 Индекс освоения затрат будет равен 223,700/239,400 = 0,93, а оценка затрат по завершении всего проекта: 257,000 х 0,93 = 239,100. Из этих показателей видно, что проект пока выполняется с экономией стоимости проекта, и если он будет выполняться с теми же параметрами, то экономия в стоимости проекта составит: VAC = 257,000 - 239,100 = 17,900. 4.4. Отчетность по затратам Отчетность обеспечивает основу для координации работ, оперативного планирования и управления. Процесс движения отчетной информации в организации изображен на рис. 14.5.1. Исходной информацией для отчетности являются данные о планируемых затратах работ и фактических расходах на их выполнение. На стадии планирования проекта формируют отчеты о бюджетной стоимости работ (рис. 14.5.2), распределении бюджетных средств по счетам затрат (рис. 14.5.3) и т. д. На стадии контроля, как правило, собираются стоимостные данные о: трудозатратах; материалах; других прямых издержках; перерасходе денежных средств. Рис. 14.5.1. Потоки отчетов в организации Описание работы Бюджет работы Июль Август Сентябрь Определение требований системы 2960 2960 Разработка строительного дополнения 9600 4800 4800 Разработка системы 17 000 17 000 Подготовка чертежей для контроллера системы 2376 2376 Обзор и утверждение разработок 1680 1440 240 Утверждение разработки системы 1873 375 1498 Подготовка чертежей для оборудования контроля температур 2640 528 2112 Рассмотрение и утверждение системы контроллера 3426 685 2741 Сбор технических данных для теплового насоса 540 540 Подготовка площадки 19 608 19 608 Обзор технических данных о тепловом насосе 600 600 Рассмотрение и утверждение оборудования контроля температур 2826 282,6 Подготовка заявки для системного контроллера 784 784 Подготовка площадки 680 680 Всего за месяц 66 593 7760 27 204 31 629 Рис 14.5.2. Отчет о распределении бюджетных затрат на работы по месяцам Счет затрат Бюджетные затраты + 11101 Разработка автоматизированной системы 21 833,00 + 11211 Разработка оборудования термоконтроля 5 466,00 + 11213 Установка оборудования термоконтроля 35 757,90 + 11221 Разработка работы контроллера 500,00 + 11223 Установка работы контроллера 44 482,00 + 11231 Разработка системного контроллера 5801,00 + 11233 Установка системного контроллера 20 299,80 + 11314 Матобеспечение 11 164,00 + 11415 Тренинговые материалы автосистемы 1987,80 + 12101 Разработка конвейерной системы 7299,00 + 12213 Установка конвейерной системы 54 620,00 Рис 14.5.3. Отчет о распределении бюджетных средств по счетам затрат Отчет о перерасходе денежных средств формируется ежегодно либо ежемесячно на весь проект. Значения фактических затрат (ACWP) и освоенного объема (BCWP) для каждой работы являются основными элементами, на которых строится отчетность о состоянии затрат. Эти данные собираются на уровне счетов затрат и попадают в отчеты. Обычно эти отчеты подготавливают ежемесячно для каждого уровня СРР или ССО в зависимости от требуемого уровня агрегирования информации. В дополнение к ним формируют еженедельные отчеты о фактических трудовых затратах, на основе которых можно проводить анализ использования человеческих ресурсов. 5. Управление качеством (тут пока только Милошевич, без Разу и Шапиро) Рис. 14.1. Роль инструментов контроля качества в процессе стандартизованного управления проектами 5.1. Карта повышения качества Карта повышения качества (QIM Quality Improvement Map(?)). Опирается на данные, вявляте главные пролемы. Рис. 14.2. Пример карты повышения качества в высокотехнологической производственной компании 5.1.1. Разработка QIM Не все для управления проектами. Для проектов – 5 стадий: определение проблемы, анализ причин, корректирующие воздействия, результаты и стандартизация (сравнить ее с широко известным циклом «планирование — выполнение — исследование — действие». Последнее – так называемый цикл организации обратной связи в управлении проектом. — Прим. ред.) КАК СООТНОСЯТСЯ ПЛАН ПОВЫШЕНИЯ КАЧЕСТВА И ЦИКЛ «ПЛАНИРОВАНИЕ — ВЫПОЛНЕНИЕ — ИССЛЕДОВАНИЕ — ДЕЙСТВИЕ»? Основное назначение карты повышения качества (QIM) состоит в том, чтобы облегчать повышение качества. Цикл «планирование — выполнение — исследование (изучение) — действие» (PDSA) пo W. Edward Deming также нацелен на улучшение (см. рис. 14.3). Шаг «планирование» концентрируется на планировании изменения (то есть проекта улучшения), который затем выполняется на шаге «выполнение», возможно, в малом масштабе. Изучение результатов выполненного проекта с целью извлечения уроков находится в центре внимания шага «исследование (изучение)». И наконец, принятие результатов, их отклонение или повторение цикла являет собой предмет шага «действие» [6]. Очевидно, что суть PDSA в значительной степени включена в QIM. В то время как цикл POSA является более широкой и общей моделью повышения качества, QIM представляет собой модель более конкретную, ориентированную на практическое применение [9]. Рис. 14.3. Цикл «планирование — выполнение — исследование — действие» (PDSA) по Демингу ИД: политика организации; стратегические планы. Политика: СОВЕРШЕНИЕ ПРОРЫВА И ДОСТИЖЕНИЕ БЕСПРЕЦЕДЕНТНО ВЫСОКОГО УРОВНЯ КАЧЕСТВА ПРОЕКТА Внесение улучшений в качество управления проектами — это просто хороший бизнес. Согласно мнению одного из признанных авторитетов в области управления качеством Джозефа Джурана, подобные улучшения качества есть не что иное, как процесс совершения прорыва к беспрецедентно высоким уровням исполнения. Последовательность шагов, из которой состоит такой прорыв, в развернутом виде приведена ниже. • Подтверждение необходимости. Руководители менеджеров проектов разговаривают на языке денег. Если менеджеры проектов сумеют доказать, что предлагаемые ими улучшения качества принесут их руководителям деньги, они будут на коне — руководители одобрят усилия таких менеджеров проектов по повышению качества. Чтобы подтвердить необходимость, нужно собрать информацию о неудовлетворительном качестве и низкой производительности и перевести ее на язык денег. • Идентификация проекта. Существует только один эффективный путь совершения прорыва: проект за проектом. Это означает, что каждое усилие по улучшению качества организуется как отдельный проект, обычно небольшой и короткий. Постоянный поток таких малых проектов / улучшений — это и есть дорога к прорывам. • Организация прорыва. Кто несет ответственность за руководство проектами/улучшениями? Офис управления проектами на уровне компании? Функциональный отдел? Несколько участников большого проекта? Вне зависимости от конкретного ответа, эта ответственность должна быть четко обозначена. В этом случае станет известно, что данное ответственное лицо будет определять цели проекта повышения качества, содержание работы проекта и выполнять его. • Диагностический обзор. На данном этапе в проекте повышения качества должны быть собраны необходимые данные, а также использована статистика и другие инструменты решения проблем с целью выявления первопричин проблем в сфере качества, ради решения которых предпринимается выполнение проекта. • Обзор с целью поиска путей коррекций. Имея на руках результаты диагностического обзора, проектная команда идентифицирует различные альтернативные решения, выбирает из них одно и претворяет его в жизнь, в течение всего времени борясь с сопротивлением изменениям. • Удержание результатов. Претворенное в жизнь решение должно стать стандартом. Обучение людей умению жить согласно этому стандарту и обеспечение контроля за тем, чтобы этот стандарт не отмер со временем, являются для вас задачами наивысшего приоритета на данной фазе. Определить проблему. Проблема: что есть не соответствует тому, что хотим. Основные шаги на этой стадии — это 1. формирование набора вариантов (мозговой штурм проблем, каждая проблема решается своим проектом), 1.1. определение целевой установки каждого варианта через источники проблем. Оценивается: степень необходимости этих изменений, их срочность, а также соответствие политикам и планам организации. Ранжируем и выбираем. 1.1.1. Разделяем прблему на составляющие. Например, доля достигнутых контрольных событий может иметь компоненты в большом, среднем и малом проектах. Рассматриваемые под другим углом, эти компоненты могут представлять собой контрольные события, которые включают высшее руководство для проведения обзоров контрольных событий, и те, которые не включают. 1.1.2. Эти данные должны быть подвергнуты расслоению с целью определения их вклада во все проекты (например, «70% пропущенных контрольных событий относится к большим проектам, включающим и себя обзоры контрольных событий с участием высшего руководства»). 1.1.3. Определяем акцент проекта — определенный источник проблем. Его и рассматриваем. Например, «сконцентрироваться на контрольных событиях, относящихся к большим проектам и включающих в себя высшее руководство». Один из инструментов, хорошо подходящий для расслоения данных таким образом, — это диаграмма Парето, о которой ниже. 1.1.4. Определяем степень желаемого улучшения. Это целевая установка. Например. Что нужно улучшить («увеличить долю достижения подвергаемых обзору высшего руководства контрольных событий в больших проектах»), когда эта целевая установка должна быть достигнута («в третьем квартале») и на сколько («на 50%»). Источников может быть несколько, надо определить целевые установки для каждого. 1.1.5. Показать, как каждая целевая установка влияет на цель проекта. 1.2. Проект именуется. Пример имени: «Улучшение (Как) наступления контрольных событий (Что) во внутренних проектах разработки программного обеспечения (Гдe)». 1.3. Сбор данных, необходимых для того, чтобы охватить текущее состояние процесса (от прошлого и начтоящего, причем задается нужная степень детализации). 1.4. Представление данных в графической форме – например, посредством гистограмм, - способно помочь отразить а) степень серьезности проблемы и б) ее изменение с течением времени, равно как и выполнить дальнейшее описание ситуации. 1.5. Уточнение цели проекта. Например, «увеличить долю всех контрольных событий проекта, достигаемых (Как) в третьем квартале (Когда), на 20% (На сколько)». Это похоже на диплом или магистерскую диссертацию, постановка задачи, конец 1 главы. Но в дипломе есть немного другой вариант – последовательное сужение проблем. А) показатели, б) что в них плохо, в) чего надо достись, г) какие есть способы, д) отсев способов, е) формирование проблемы и основного способа ее решения (повысить объем продаж за счет рекламы). Некоторые элементы из сказанного будут ниже. 1.6. Разработка предварительного плана проекта. Этот план прост, и его основные части — это диаграмма Гантта и матрица ответственности, охватывающие все шаги оставшихся стадий повышения качества. 1.7. Обычно этот план требует одобрения руководства. 2. Выполнение анализа причин. На этой стадии существует три шага. 2.1. Выявить причины рассматриваемой проблемы. Проведение мозгового штурма и визуальное представление проблемы средствами диаграммы причин и следствий. Надо работать с данными, а не с интуитивными ощущениями. Методы: - контрольные списки, - диаграммы разброса (корреляционные диаграммы) и - гистограммы могут быть полезны при поиске сведений, способных послужить основой для группировки или комбинирования связанных причин. Наясно – прояснить. 2.2. Квантифицировать (выразить в численном виде) важность (значимость) причин. Причины, имеющие максимальную важность, являются наиболее вероятными источниками проблемы, решение которой ищется. 2.3. Выбор причин, на которые команда может повлиять. Может быть, понадобится обновить предварительный план. 3. Реализация корректирующих воздействий. 3.1. Выбор пути. Обычно путей устранения причин проблемы в сфере качества несколько. Путь=корректирующее воздействие. Способ 1. Можно определить и подсчитать за и против. Способ 2. Выбрать корректирующее воздействие, основываясь на: • влиянии. Эффективно ли оно в смысле реализации целевых установок? • осуществимости. Возможно ли оно с технической точки зрения? • экономических соображениях. Насколько дорого будет стоить его реализация? Способ 3. Анализ эффективности, то есть стоимости / выгод каждого корректирующего воздействия. Когда воздействие выбрано, полезно будет оценить его эффективность с точки зрения достижения целевых установок и убедиться, что оно не оказывает неблагоприятного влияния на цель проекта. 3.2. Разработать детальный план проекта, включающий в себя реализацию всех выбранных корректирующих воздействий, а также действий, относящихся к последующим стадиям. Основные части: матрица ответственнотси (на 1 месте!!!) и Гантт. 3.3. Одобрить как базовый план. 4. Подтверждение результатов. 4.1. Осуществили корректирующие воздействия. 4.2. Сбор данных о влиянии этих корректирующих воздействий для подтверждения влияния. 4.4. отображаем графически, можно оценить экономию. 4.3. Формулируенм утверждение о влиянии. Может быть положительное, может быть отрицательное. 4.4. Готовим отчет, предоставляемый руководству. 5. Обеспечение стандартизации. 5.1. Те корректирующие воздействия, эффективность которых будет подтверждена, должны будут стать стандартной частью процесса, в котором встретилась проблема. Способы: • переписывание описания процесса и переделка схемы (блок схемы) процесса; • пересмотр контрольных списков; • информирование и обучение всех лиц, вовлеченных в процесс. Надо показать, как был изменен для того, чтобы проблема больше не повторялась. 5.2. Та же проблемы встречается в других областях организации. Надо передать полученный опыт в другие области проекта или в другие проекты. Полная стандартизация. 6. Подведение итогов. 6.1. Окончательный отчет: усвоенные уроки, выгоды, слабые и сильные стороны проекта. Цель – распространить знания. 6.2. Обсуждение планов на будущее. Бывает, решено не полностью. бывает, открываютсмя новые пути. Бывает, всё ОК, ищем новые проблемы. 5.2. Использование карты повышения качества Когда использовать. Можно индивидуально, но главное – командно. Обычно это суб проекты. Например, в пределах двухгодичного проекта разработки продукта имеется достаточно времени для запуска и завершения нескольких проектов повышения качества, которые обычно охватывают временные интервалы от нескольких недель до нескольких месяцев. В малых это сложно. В потоке проектов – возможно. РЕШЕНИЕ — В РАСПИСАНИИ НА КОРОТКУЮ ПЕРСПЕКТИВУ Было ОК, стали отставать от конкурентов. Делели реинжиниринг планировки фабрики. Делали 2 эшелона: 1) ядро проектной команды — кросс-функциональную группу менеджеров среднего звена, ответственных за управление всеми работами, предпринимаемыми в рамках проекта. 2) расширенная команда специалистов по производству — несла ответственность за выполнение этих работ. Нет опыта в формальных процессах управления проектами и опыта реинжиниринга. Наняли консультанта. Прошли базовое обучение. Но расписание оказалось сложным и было трудно отчитыватся. В результате предложили использовать расписание на короткую перспективу. На ближайшие 2 недели для каждого члена команды. Стало легко контролировать. Трудоемкость. Обычно составляем план на недели-месяцы. Это трудоемко. Обычно 5 чел, обычно по 5 часов в месяц на это. В результате 75 часов сверх плана на качество. +- Данные, а не мнения. Общение в команде. Структурированность. простота, Но. Требуеются изменения в культуре и дисциплине. ПРИМЕР Ушли к конкурентам старшие менеджеры. Вместо них – младшие. Довели старый проект, но затруднились с новым. Разрбаотали стандарт для работ по разработке определения продукта, совместимый с процессом управления проектами. Его краеугольными камнями являлись описание предполагаемой целевой аудитории пользователей, а также концепция, выгоды от использования, позиционирование и функциональные возможности продукта. Новички немедленно воспользовались новым процессом под тщательным надзором руководства. 5.3. Диаграмма Парето 5.3.1. Что такое диаграмма парето? ВАЖНОЕ МЕНЬШИНСТВО ИЛИ НЕЗНАЧИТЕЛЬНОЕ БОЛЬШИНСТВО Изучая распределение доходов, родившийся в Италии швейцарский экономист Вильфредо Парето выяснил в,1898 г., что 85% богатства итальянского города Милана находятся во владении лишь 15% людей. Удивительно? На самом деле нет. Многие менее ученые люди наблюдали подобные картины в своем окружении. Что удивительно, так это то, что этот ценный принцип был забыт на долгие годы — до тех пор, пока недавно он не был открыт заново и не применен к ситуациям сегодняшнего бизнеса. Если говорить более точно, то этот принцип был выражен в численных терминах и превратился в известное правило 80:20, утверждающее, что 80% забот проистекает от 20% причин. Ниже приводятся примеры: Важное меньшинство (обычно 20%) Большинство (обычно 80%) Компонентов расходов Отвечают за Бюджет расходов проекта Типов неудач полевых испытаний Отвечают за Поломок автомобильных двигателей Потребителей Отвечают за Потребление пива Основных проектов Отвечают за Рабочего времени Продуктов Отвечают за Продаж и прибылей Хотя процентное соотношение может никогда не выдерживаться в точности таким, идея состоит в том, что большая часть забот проистекает лишь от немногих причин. Специалист в области качества Джозеф Джуран назвал эту закономерность правилом Парето и следующим образом выразил его суть: «Жизненно важное меньшинство и незначительное (тривиальное) большинство» [8]. Таким образом, если в ходе решения проблем мы будем следовать этому правилу, то нам следует сконцентрироваться на небольшом количестве жизненно важных вопросов. Устранение (разрешение) их даст нам наибольшее улучшение. Аналогично игнорирование незначительного большинства вопросов не повредит нам. Резюмируя, можно сказать, что важное меньшинство — наиболее высокие столбцы диаграммы — имеют наивысший приоритет. 20/80. Здесь изучаются проблемы или причины проблем. Упорядочиваются, строится кумулята. Рис. 14.4. Диаграмма Парето для проблем в процессе разработки нового продукта 5.3.2. Разработка диаграммы Парето 1. Выбор проблемы в сфере качества. Расставляем приоритеты. 2. Выявление причин проблем в сфере качества. Способ 1. Анализ данных. Например, доскональный взгляд на базу данных показал, что новые продукты проводили слишком много времени на стадии концептуального проектирования и достигали момента выпуска готовой продукции со значительным опозданием относительно согласованного с заказчиком графика поставки. Анализ данных помог раскрыть основные области для дальнейшего поиска более специфических (частных, особенных) причин. Способ 2. Мозговой штурм. В ходе 4 часового мозгового штурма группа нашла более 100 причин, которые были сгруппированы по принципу подобия, что свело их к 7 основным категориям причин (эти категории перечислены вдоль оси х на рис. 14.4). 3. Выбор наиболее выразительного метода измерения (?). Можно взять частоту появления. Но лучше – упущенная прибыль. Хотя это сложно бывает. 4. Сбор данных о причинах. 1) История (если есть) или 2) сбор в реальном времени (за определенный временной интервал, скажем, 3 недели). Например, ищем причины малой доли успеха предложений в своих проектах. Сбор данных требует года как минимум. Можно и 3) штурмом (см. пример выше). Ответы специалистов были сведены в контрольный список (см. табл. 14.1), что часто является простейшим способом сбора данных. Таблица 14.1. Контрольный список категорий причин Категория причин / проблем Инкрементная частота % Кумулятивная частота % Слишком высокая сложность 13 36 13 36 Отсутствие принуждения 7 19 20 55 Дисфункциональные элементы проекта 5 14 25 69 Недостаток коммуникации 4 11 29 80 Ригидные (негибкие) процессы 4 11 33 91 Недостаточная подготовка 2 6 35 97 Недостаток ответственности 1 3 36 100 Итого 36 100 36 100 5. Рисование диаграммы Парето. Всё ясно. 6. Интерпретация диаграммы. Высокие – важные, с них начинаем. Наиболее частое не есть наиболее важное! 5.3.3. Использование диаграммы Парето Когда использовать. На ранних стадиях – что исследовать, на поздних – что делать в первую очередь. Можно построить иосле действий, посмотреть, что осталось. Трудоемкость. Сбор данных – долго. Строить – минуты. +- Выявляет важное: бывает, что-то делаешь и усугубляешь другое. Есть соблазн уйти от начальной темы. Просто и наглядно. Нет страха перед вероятностями. Минусов нет. Вариации. Можно взять главную причину и для нее потроить подробнее причины более низкого уровня. ПРОЦЕСС NPD ДО И ПОСЛЕ После анализа основных причин неэффективности процесса NPD QIT Нурех Corp. построила диаграмму Парето (на момент до начала каких-либо действий по улучшению), показанную на рис. 14.4. Чтобы устранить причины неэффективности, QIT разработала и претворила в жизнь план контрмер, влияние которых было отслежено спустя год. Это состояние через год было представлено новой диаграммной Парето, в которой использовались те же самые категории причин. Эти две диаграммы были наложены друг на друга (совмещены), результатом чего явилась диаграмма, изображенная на рис. 14.5. Ценность данной диаграммы состоит в ее способности показывать различия между частотой возникновения причин до и после принятия контрмер, вынося на передний план достигнутые в NPD улучшения. Рис. 14.5. Диаграмма Парето до и после: уменьшение проблем в процессе разработки нового продукта после выполнения проекта повышения качества 5.4. Диаграмма причин и следствий 5.4.1. Что такое диаграмма причин и следствий? Диаграмма причин и следствий (CED) представляет собой инструмент для идентификации, соотнесения и графического отображения причин той или иной проблемы (см. рис. 14.6). Если имеет отношение к процессу, то визуализирует сам процесс. Важна иерархическая структура. Например, основная причина X имеет прямую (непосредственную) связь со следствием, в то время как каждая из причин низкого уровня связана с точностью до уровня (степени) своего влияния с основной причиной. CED называется также диаграммой типа «рыбий скелет» из за ее сходства со скелетом рыбы или диаграммой Ишикавы по имени ее изобретателя Kaoru Ishikawa. Рис. 14.6. Базовый вид диаграммы причин и следствий 5.4.2. Построение диаграммы причин и следствий ИД. План повышения качества. Выбор формата. Существуют два основных типа этой диаграммы: дисперсионный анализ и систематизация процесса. Таблица 14.2. Типы диаграммы причин и следствий Тип диаграммы Основная цель Главное преимущество Главный недостаток Дисперсионный анализ Анализирует дисперсию процесса, соотнося друг с другом причины и следствия Структурирует, отображает (представляет) и соотносит причины со следствиями Может становиться сложной Обеспечивает каркас для проведения мозгового штурма или анализа данных Требует терпения и приверженности Систематизация процесса Идентифицирует шаги процесса, затем перечисляет факторы, влияющие на качество каждого шага Визуально представляет факторы, влияющие на последовательность шагов процесса Отношения между шагами и факторами могут трудно поддаваться пониманию Указывает на тех функциональных владельцев шагов, шаги которых нуждаются в улучшении Определение проблемы. Консенсусом. «Выполнение проектов задерживается». Пишем это утверждение в правой части листа (или экрана) и рисуем вокруг него прямоугольник (голова скелета рыбы), к которому ведем стрелку (позвоночный столб скелета). Следствие готово Примеры. Конкретные характеристики. В качестве примеров можно привести перерасходы бюджета; заказчиков, не удовлетворенных уровнем достижения целей проекта; неэффективные совещания по началу проекта; плохо проводимые обзоры контрольных событий; расползание содержания; неудовлетворительную коммуникацию на наинизшем иерархическом уровне операций. Генерирование идей о том, что вызывает данное следствие. Вопрос: каковы основные причины задержек? Основные причины (кости скелета) представлены ветвями, впадающими в основную ветвь (основной ствол). В нашем случае организация, проблема которой состоит в отставании проектов от расписания, идентифицировала 6 областей, которые могут являться основными потенциальными причинами: процесс управления проектами, системы управления, метрика (система показателей, по которым измеряется ход исполнения), организационная культура, информационные системы и организационная инфраструктура. В том случае, когда возникают трудности в идентификации основных причины (ветвей), можно (и это весьма распространенная стратегия) использовать традиционные заголовки, такие как методы, станки, люди и материалы [14], хотя они могут быть и не очень удобны для многих типов проектов. Идентификация всех возможных причин. Субпричины. Есть приемы, но обычно штурм. Можно из данных что-то определить. Потом дополнительные уточнения. 1. Законным считается иметь одну и ту же причину низкого уровня в нескольких категориях основных причин, предполагая тем самым, что имеет место прямое множественное взаимоотношение [15]. 2. Далее, наличие основных причин дает возможность задаться следующими вопросами: • Что вносит наибольший вклад в каждую из этих причин более низкого уровня? • Почему возникает основная причина? Эти же вопросы необходимо задавать до тех пор, пока не будут достигнуты причины самого низкого иерархического уровня. Надо докапываться, но надо и знать, когда остановиться. Правило. когда причина контролируется руководителем, отстоящим от команды более чем на один управленческий уровень (по иерархической лестнице), нет смысла производить дальнейшее углубление диаграммы [16]. Попросту говоря, поиск еще более глубинных причин в таком случае не повысит эффективность действий команды. Как только наинизший уровень достигнут, иерархическая структура CED может считаться завершенной. Вознаграждения, метрика, поддержка командной работы, методы планирования и отслеживания — это причины следующего уровня. В случае поддержки командной работы, называемой также технологиями обеспечения сотрудничества в команде, потенциальные причины включают в себя электронную почту, видеоконференции и интранет. Если говорить более конкретно, можно сказать, что недостаток подготовки и ненадлежащее оборудование могут внести свой пагубный вклад в неудовлетворительную работу команды. Резюмируя, следует отметить, что в нашем примере имеется 3 уровня причин в дополнение к основной причине. Обзор. (проекрка на полноту и правильность). Командой. Можно привлечь и сторонних людей. Данные нужны дял подтверждения. 5.4.3. Использование диаграммы причин и следствий Когда использовать. Если все работают. Если всё работает. Можно расставить приоритеты, определить цели и действовать. Трудоемкость. Заручившись соответствующей помощью, состоящая из 5 человек команда может разработать диаграмму за время от получаса до пары часов. Увеличение численности команды и менее качественная помощь неизбежно приведут к возрастанию требуемого времени. +- Это ключ к сбору информации. Фокус на вопросах, а не на симптомах. Достигается консенсус, важный для приверженности. И см. таблицу. СОВЕТЫ ПО ПОСТРОЕНИЮ ДИАГРАММЫ ПРИЧИН И СЛЕДСТВИЙ • Думайте глобально, действуйте локально. Понимайте влияние факторов, находящихся за пределами сферы вашего контроля, однако действуйте, опираясь на те, которые вы можете контролировать. • Слушайте идеи участников. Усваивайте их идеи касательно причин и выражайте их одним-двумя словами. • Выполняйте обзор. Потребуйте от каждого члена команды, чтобы он выполнил обзор CED на следующий день, либо попросите его получить мнение еще одного-двоих человек. • Вы можете констатировать желаемые результаты вместо проблемы. Это помогает идентифицировать средства (вместо причин) достижения этих результатов. Рис. 14.7. Пример диаграммы систематизации процесса 5.5. Контрольные диаграммы 5.5.1. Что такое контрольные диаграммы? Рис. 14.8. Пример х– и R диаграммы для оценки общего управления проектом Временной ряд с центральной линией и верхней и нижнгей контрольной границами (равноудаленными от центра). По ним прпнимается решение о ходе процесса. Если внутри, без смещающего тренда и нет долгих отклонений за пределы, всё под контролем. Такой процесс является предсказуемым, последовательным (логически непротиворечивым) и стабильным во времени. (??) Его противоположностью является процесс, который ведет себя плохо и не находится под контролем — процесс, который является непредсказуемым, непоследовательным и изменяется во времени [17]. Итак, видна предсказуемость (?) ПОНИМАНИЕ ВАРИАЦИЙ Для каждого процесса или системы вы можете идентифицировать и измерить показатели исполнения [2]. В управлении качеством эти индикаторы называются характеристиками или переменными качества. Расхождение между бюджетом стоимости проекта и фактической стоимостью проекта либо расхождение между запланированным и фактическим расписаниями проекта представляют собой примеры характеристик качества для процессов управления стоимостью и сроками соответственно. Когда проект рассматривается как система, характеристики качества могут быть соотнесены с его целью. В качестве примеров целей можно привести прибыли проекта или удовлетворение заказчика. Все характеристики качества меняются со временем по причинам, которые могут быть отнесены к одному из следующих типов [7]: • общие причины (называемые также непредвиденным или фоновым шумом). Это те причины, которые являются непосредственной частью (присущи, являются неотъемлемой частью) самого процесса (или системы), час за часом, день за днем и влияют на каждого человека, вовлеченного в процесс. Например, к причинам непостоянства времени разработки расписания проекта могут относиться рабочая нагрузка планировщиков, их опыт и степень их знакомства с программным обеспечением календарного планирования; • особые причины (называемые также могущими быть выделенными причинами или сигналами). Это те причины, которые не являются частью процесса (или системы) в течение всего времени, не влияют на всех участников процесса и возникают в силу специфических (конкретных) обстоятельств. Например, новый член проекта, незнакомый с принятой в проекте процедурой реагирования на риски, может совершать ошибки. Понимание различия — то есть отклонений — между двумя типами причин является необходимым условием для эффективного использования контрольных диаграмм и повышения качества. 5.5.2. Построение контрольных диаграмм Контрольные диаграммы способны принести пользу в трех различных областях [18]: • определение процесса или с целью установить его состояние статистического контроля; • мониторинг процесса и подача сигнала о факте его выхода из-под контроля; • оценивание потенциальных возможностей процесса (это выходит за рамки книги). Планирование контрольной диаграммы. Ключевыми составными элементами планирования являются: • цель диаграммы; • выбор процесса; • измерение; • выборка. Планирование начинается с четкого определения цели диаграммы [19]. В примере рис. 14.8 проектная команда FAB определяет цель диаграммы — определить, является ли стабильным процесс управления проектами в части конкретных характеристик качества, и предпринять улучшения в случае необходимости таковых. Основываясь на цели, можно выбрать одну или несколько характеристик качества, а типы данных, собранных по данной характеристике или переменной, покажут, какой тип диаграммы следует использовать. В примере команда FAB выбирает одну характеристику качества — степень соответствия фактического управления проектом требованиям к управлению проектом, установленным в уставе проекта. Это ведет к использованию х диаграммы и R диаграммы (среднее значение х и диапазон (R, равный разности между наибольшим и наименьшим значением)) (эти диаграммы будут лежать в центре внимания нашего рассмотрения), которые содержат собранные по характеристикам данные. Эта характеристика являет собой совокупность приблизительно 14 требований, среди которых находятся требования по части расписания, бюджета, коммуникации и усиления ценностей компании. Для измерения степени выполнения (достижения, соответствия) каждого из этих 14 требований используется обзор /оценивание по 5 балльной шкале Ликерта, где 1 означает «совсем не соответствует уставу проекта», а 5 — «всегда соответствует уставу проекта». Все 15 членов команды выполняют два оценивания каждую неделю (частота взятия выборки) после регулярно проводимых по вторникам и пятницам совещаний о ходе продвижения, пять из которых выбираются случайным образом для отображения на диаграмме (стратегия выделения подгрупп). Для каждого из 5 оцениваний вычисляется среднее значение рейтинга каждого из 14 требований. ОСНОВЫ КОНТРОЛЬНЫХ ДИАГРАММ Согласно Wheeler, основами контрольных диаграмм являются [1]: 1-я основа. В контрольных диаграммах используются границы контроля, определяемые согласно «правилу трех сигм» — то есть вне зависимости от типа диаграммы эти границы устанавливаются на расстоянии утроенного оцениваемого стандартного отклонения по обе стороны от центральной линии. Располагаясь там, они отделяют возможный шум (общие причины вариаций) от потенциальных сигналов. 2-я основа. Использовать обычную дисперсионную статистику для вычисления пределов по «правилу трех сигм». Не имеет значения, используете вы диапазоны, стандартное отклонение или среднеквадратичное значение. Когда вы используете правильный подход, различные статистические приемы приведут к получению близких результатов. И напротив, различные статистические приемы приведут к получению близких неправильных результатов, если будет использоваться неправильный подход. 3-я основа. Контрольные диаграммы зиждутся на рациональном осуществлении выборки и рациональном выделении подгрупп. Это значит, что способ, посредством которого происходит сбор данных, распределение их по подгруппам и отображение на диаграмме, определяется несколькими факторами. К этим факторам относятся содержание данных, источники вариаций данных, вопросы, на разрешение которых направлены диаграммы, а также предполагаемый способ использования полученного знания. 4-я основа. Контрольные диаграммы представляют собой ценность только в том случае, если вы знаете о том, что их нужно использовать. Иными словами, сбор данных и построение диаграмм без использования контрольных диаграмм бесполезны. Попросту говоря, если вы не будете применять их, ничего не произойдет. Сбор данных. На этом шаге мы фиксируем данные, вычисляем имеющие отношение к делу статистические показатели и рисуем эти показатели на диаграмме. Обычно для контрольной диаграммы выполняются сбор и запись 15—20 выборок (подгруппами по 5), которые отображаются на диаграмме. На этой же диаграмме отображаются и любые необычные события, если таковые наступают. Более детальная информация, касающаяся количества выборок, приведена в заштрихованном прямоугольнике на стр. 481 (27) под названием «Как много (какой объем) данных вам необходимо для вычисления контрольных границ?». Для каждой выборки мы вычисляем среднее значение х и диапазон (R, равный разности между наибольшим и наименьшим значением) и рисуем их на соответствующих контрольных диаграммах. Затем вычисляются суммарное среднее значение (называемое также общим средним) и средний диапазон, что определяет центральные линии для: х диаграммы: и R диаграммы : Детали, касающиеся данных формул, приведены в табл. 14.3. Определение контрольных пределов. КАКОЙ ОБЪЕМ ДАННЫХ ВАМ НЕОБХОДИМ ДЛЯ ВЫЧИСЛЕНИЯ КОНТРОЛЬНЫХ ГРАНИЦ? Вы можете начать с вычисления полезных, но нежестких границ с двумя подгруппами, имеющими размер 4. Эти и другие границы, вычисленные менее чем на основе 15—20 точек данных, рассматриваются как «временные границы» и должны подвергаться пересмотру по мере появления новых данных. Когда вы достигнете 15—20 отдельных значений, границы начнут становиться более жесткими. Разумеется, вы можете использовать и большее количество данных для вычисления границ, однако увеличение их сверх 50 точек приносит мало пользы [4|. Используем средний диапазон и общее среднее для вычисления верхнего (UCL) и нижнего (LCL) контрольных пределов для х и R диаграмм по следующим формулам: Здесь D3, D4 и А2 — константы, которые зависят от размера выборки. Формулы для вычисления контрольных границ и констант приведены в табл. 14.3. Табл. 14.3. Формулы и константы для контрольных диаграмм КОГДА СЛЕДУЕТ ПЕРЕВЫЧИСЛЯТЬ ГРАНИЦЫ КОНТРОЛЬНОЙ ДИАГРАММЫ? Для рассмотрения. необходимости перевычисления границ следует задать себе ряд вопросов [3]: Вопрос 1. Верно ли, что ваша диаграмма демонстрирует существенно отличающийся тип поведения от того, что имело место в прошлом? Вопрос 2. Знаете ли вы, почему произошло это изменение в поведении? Вопрос 3. Является ли новое поведение процесса желательным? Вопрос 4. Ожидаете ли вы и желаете ли вы, чтобы новое поведение процесса продолжалось? Если вы отвечаете «да» на все четыре вопроса и эти ответы основываются на данных, которые вы собрали после изменения в процессе, вам следует перевычислить пределы. Если вы отвечаете «нет» на вопрос 1, то держитесь в старых пределах. Если вы отвечаете «нет» на вопросы 2, 3, 4, не трогайте пределы. В остальных случаях ищите особую причину. ДЛЯ ЧЕГО ИСПОЛЬЗОВАТЬ ПРЕДЕЛЫ В СООТВЕТСТВИИ С «ПРАВИЛОМ ТРЕХ СИГМ»? Пределы, устанавливаемые согласно «правилу трех сигм», преднамеренно выбраны Шехартом, потому что они имеют экономический смысл. Они достаточно широки для того, чтобы отсечь большую часть шума, избавляя пользователей от затрат времени на интерпретацию шума как сигнала (особых причин вариаций). В это же время эти пределы достаточно узки для того, чтобы засечь вероятные сигналы и избежать потери сигналов, имеющих экономическую значимость. Установка пределов согласно «правилу трех сигм» обеспечивает удовлетворительный баланс между этими двумя видами ошибок [5]. Согласно данным FAB на рис. 14.8, центральная линия и контрольные границы выглядят следующим образом: Строим. Продолжаем смотреть. Выявляем, если что. Решая, является ли процесс контролируемым, сначала смотрим на R диаграмму. Поскольку контрольные границы на х диаграмме зависят от среднего диапазона, особые причины могут создавать на R диаграмме необычные картины. Когда R диаграмма оказывается взята под контроль, мы наконец готовы сместить наше внимание и привести х диаграмму также в состояние контроля. Анализ и интерпретация диаграммы. Только общие причины присутствуют в процессе, находящемся в состоянии статистического контроля. На что в действительности похожа контрольная диаграмма процесса, находящегося в состоянии статистического контроля? Такая диаграмма показывает точки, которые флуктуируют случайно между контрольными границами без четко выраженной закономерности. В частности, это значит применимость следующих принципов: 1. Отсутствуют точки за пределами контрольных границ. 2. Количество точек выше центральной линии приблизительно равно количеству точек ниже центральной линии. 3. Точки выглядят как распределенные случайным образом выше и ниже центральной линии. 4. Нормальное распределение (обсудить, всегда ли? Если суммируем подгруппы или берем средние данные, то да) Контрольные границы установлены согласно «правилу трех сигм» — на расстоянии трех стандартных отклонений от общего среднего, подразумевая, что вероятность того, что среднее значение любой подгруппы выйдет за контрольные границы, равна 0.27% — очевидно, это очень малое значение. Остающиеся 99.73% должны находиться внутри контрольных границ. Это корень, первопричина принципа 1. Симметричный характер нормального распределения, предполагающий, что количества точек ниже и выше центральной равны, объясняет принципы 2 и 3. Кроме того, поскольку среднее значение нормального распределения является также его медианой, примерно по половине точек лежит с каждой стороны от центральной прямой. Принцип 4 основывается на знании того, что 68% — то есть большинство — нормально распределенных точек находятся возле центральной линии или, если говорить более точно, на расстоянии не более 1 стандартного отклонения (1 сигмы) от нее. И снова эти принципы верны столь долго, сколь долго процесс остается стабильным и управляемым общими причинами, как в случае на рис. 14.8. Однако все еще слишком часто процессы не ведут себя надлежащим образом. Больше того, они выходят из под контроля, как только в действие вступают особые причины. Рис. 14.9. Примеры контрольных диаграмм процессов, не находящихся под контролем Из The Management and Control of Quality, 4th edition, by J. R. Evans and W. M. Lindsay © 1999. Перепечатано с разрешения South Western College Publishing, подразделения Thomson Learning. Нехарактерное количество точек по одну сторону центральной линии обычно указывает на наличие особых причин (например, введение нового планировщика в уже выполняющийся проект), ведущих к внезапному сдвигу среднего значения процесса (рис. 14.9b). Причины, которые появляются и исчезают регулярно, могут образовывать циклы (рис. 14.9с). Пример — поочередное выполнение оценок стоимости двумя различными людьми, использующими свои эмпирические стандарты производительности. На процесс могут повлиять особые причины, которые постепенно смещают точки на диаграмме вверх или вниз относительно центральной линии, создавая постоянный тренд (рис. 14.9d). В одном проекте, например, после замены опытных программистов неопытными в ходе командного совещания по отображению на диаграмме изменений содержания количество изменений содержания на некоторое время пошло вверх, после чего вернулось к нормальному. И наконец, когда слишком большое количество точек располагается около центральной линии (рис. 14.9е) или контрольных границ (рис. 14.9f), МЫ наблюдаем скученность около центральной линии или контрольных границ соответственно. Первое может быть вызвано, например, систематическим взятием выборок из руководимых разными менеджерами пакетов работ, один из которых имеет очень высокие отклонения по стоимости, а второй — очень низкие. И при высоких, и при низких значениях отклонений среднее значение выборки не будет отражать это, а будет отражать лишь их среднее значение, что будет выглядеть как кучкование около центральной линии. Этим шагом мы заканчиваем описание использования контрольной диаграммы для определения процесса или установление его состояния статистического контроля и переключаем наше внимание на использование контрольных диаграмм как инструмента решения проблем. Применение контрольной диаграммы как инструмента решения проблем. Неподконтрольные изменения означают не взятые под контроль причины. Надо их вскрыть и взять. Но то, что он под контролем, нре значит, что он соответствует спецификациям!!! Тут уж надо воздействовать на процесс. Например, если возникает необходимость в том, чтобы процесс управления проектами, который, выполняясь целостно, обеспечивает сдачу проекта X в течение 12 месяцем, стал удовлетворять новым требованиям заказчика и обеспечивать сдачу проекта в течение 10 месяцев, то вам может потребоваться отказаться от поступенчатого подхода в пользу перекрывающихся стадий. Кроме того, вы можете ослабить контроль со стороны высшего руководства, приводящий к неоперативному проведению обзоров контрольных событий, в пользу проведения таких обзоров самими проектными командами. Приведенные два примера — это примеры изменений структуры процесса. 5.5.3. Использование контрольных диаграмм Когда использовать. Везде полезны. И лишь несравненно большее количество ресурсов в больших проектах является причиной того, что именно в них контрольные диаграммы используются наиболее часто. Трудоемкость. С развитием компьютерных программ для работы с контрольными диаграммами их построение и поддержание не требует существенных затрат времени. В нашем примере на рис. 14.8 команде, состоящей из нескольких опытных людей, потребовалось несколько часов для того, чтобы спланировать диаграмму, разработать инструмент оценивания, выполнить первые измерения и построить диаграмму. При менее сложных измерениях затраты времени могут уменьшиться. +- Понимание процесса. Язык описания. Отличие шума от сигнала. Принятие решений о вмешательстве. Просто. Но. Сложна статистика. Рис. 14.10. Примеры контрольных диаграмм процессов, не находящихся под контролем Вариации. Рис. 14.10. Начните с вопроса: «Имеются ли у меня данные о переменных или атрибутах?» Отдельные типы диаграмм предполагают только данные о переменных, другие — об атрибутах. Данные о переменных измеряются по непрерывной шкале, такой, как время, бюджет проекта, числа (количество изменений проекта) и т. д. х диаграмма и R диаграмма являются наиболее часто используемыми диаграммами для данных о переменных. Для данных об атрибутах применимы только две величины: хорошо или плохо, да или нет. И хотя они обычно не могут быть измерены, имеется возможность наблюдать и подсчитывать их. Например, при мониторинге контрольных событий проекта контрольное событие может либо наступить / быть достигнуто (хорошо), либо нет (плохо). Доля наступивших контрольных событий часто используется в качестве показателя производительности и легко поддается отслеживанию и отображению на диаграмме. Некоторые данные об атрибутах относятся к категории данных «дефект», некоторые — «дефективный». Дефект — одиночная, не соответствующая спецификациям характеристика качества. Например, организация отслеживает степень удовлетворенности более чем 60 своих заказчиков десятью проектными характеристиками качества — от времени цикла до отношения цена / производительность. Эти характеристики измеряются по шкале от 1 (совершенно неудовлетворен) до 6 (в высшей степени удовлетворен). Всякий раз, когда среднее значение характеристики падает до 4 или ниже, это рассматривается как дефект, отслеживаемый по u диаграмме. Когда проект (элемент проекта) содержит два или большее количество дефектов, он считается дефективным. Организация использует р диаграмму для мониторинга дефективных проектов. Теперь, когда мы прояснили имеющиеся типы данных, можем посмотреть на размер выборки, чтобы определить, какая диаграмма нам нужна. 5.6. Свод 6. Отчетность о ходе исполнения и закрытие Рис. 15.1. Роль инструментов ведения отчетности о ходе исполнения и закрытия в процессе стандартизованного управления проектами 6.1. Журнал рисков 6.1.1. Что такое журнал рисков? Управление рисками = формирование базового плана риска, оценивание фактического статуса риска и определение дальнейших действий (рис. 15.2). Рис. 15.2. Пример журнала рисков 6.1.2. Ведение журнала рисков Довольно сложно, несмотря на простой вид. ИД. 1. План управления рисками. Документ, который обеспечивает план работы с рисками в течение жизни проекта, включая детали учреждения и ведения журнала рисков; 2. План реагирования на риски. 3. Базовый план, с которым сравнивается фактический статус риска. 4. Отчеты о ходе исполнения или устная информация о фактическом ходе исполнения, отражающая фактический статус риска. Обращение к базовому плану. В нем – заранее спланированы важные действия на важные риски. Первые 7 столбцов. Номер риска (по работам), описание, ответственный, степень критичности, превентивное действие, точка инициации, действие в случае наступления. Зная это, можно собрать факт. Установление фактического статуса риска. Регулярные совещания по вопросам хода проекта. Обычно смотрят на бюджет и расписание. Риск тоже полезен. Можно и внеплановые совещания. Превентивные действия = ряд задач. Для них есть расписание и ответственные. Например, на рис. 15.2 превентивная мера для риска № 9 (второй ряд) — аутсорсинг тестирования программного обеспечения. Во исполнение этого владелец подразделил превентивную меру на задачи определения содержания тестирования, идентификации вендоров, выпуска запроса на предложение услуг, сбора и оценивания предложений, прореживания и оставления окончательного списка и ведения переговоров и выбора вендора, которому будет поручена эта работа. Были также определены расписание и области ответственности. На совещании по вопросам хода продвижения, проводившемся 23 мая 2002 года, владелец докладывает о состоянии превентивной меры. Она на 2 недели отстает от расписания, или, иными словами, терпит неудачу. Он также информирует собравшихся, что дата воздействия риска (когда было запланировано начать тестирование программного обеспечения) совсем близка. Если превентивное воздействие не будет удачно завершено к 1 июля 2002 года, то выполнение проекта будет задержано на 2 недели. Это сообщение, разумеется, сопровождается детальным обсуждением причин неудачи и возможных способов исправления положения. Определение дальнейших действий. Как исправить ситуацию и ослабить риск. В ходе обсуждения на совещании было высказано единодушное мнение, что продолжение превентивной меры не способно ослабить риск. Совещание заканчивается принятием решения о приостановке превентивной меры и инициировании действий, предусмотренных планом на случай ее неудачи, то есть выбора старого вендора. Владельца события риска просят разработать план действий, который должен быть рассмотрен и утвержден на ближайшем незапланированном рассмотрении риска на следующий день. В общем и целом последовательность, состоящая из: • обращения к базовому плану; • установления фактического статуса ослабления риска; • определения дальнейших действий посредством журнала рисков, — столь же логична, сколь и любая мера по контролю расписания или бюджета. Логично также и то, что она должна быть регулярной практикой. 6.1.3. Использование журнала рисков Когда использовать. Большие и сложные проекты – жестко, формально. Малый проект – неформально. Трудоемкость. Внести запись— дело минуты другой. Но при мониторинге рисков и обсуждении мер, направленных на их ослабление тратится много времени. Но это важно. +- «Что произойдет, если этого журнала не будет?» В проекте, насыщенном рисками, при отсутствии журнала рисков, проект будет испытывать примерно такие же острые ощущения, которые испытывал Дамокл, сидя под лезвием меча, подвешенного на единственном волосе. Наличие журнала рисков может рассматриваться как устранение или ослабление этих острых ощущений. Прояснение источников угроз, прозрачность действий, возможность принимать решения. Ясность. Простота. Но. На вид бюрократично. Не отражает взаимодействие рисков. Вариации. Журнал проблем. Он похож, многие заменяют термины. Новое: график старения проблем, тренд. Рис. 15.3. Диаграмма старения проблем Еще один закономерный путь развития журнала проблем — информационная база проблем (см. приводимый ниже заштрихованный прямоугольник «Информационная база проблем»). В то время как одни компании могут называть эти инструменты диаграммами старения проблем и информационными базами проблем, другие называют их диаграммами старения рисков и информационными базами рисков. ИНФОРМАЦИОННАЯ БАЗА ПРОБЛЕМ Говоря простыми словами, она содержит информацию трех видов: 1) проблемы, возникшие в прошлых проектах и оказавшие или бывшие способными оказать значительное влияние, 2) характер влияния, которое наступило или наступление которого было предотвращено, 3) какие меры были предприняты ли могли быть предприняты для успешного разрешения этих проблем. 1. Изучение журналов рисков прошлых или настоящих проектов и материалов послепроектных обзоров помогает определить необходимую предварительную информацию. 2. Выполняется группировка проблем, имеющих сходную природу. Например, могут быть выделены такие группы: командные проблемы, технологические проблемы,.проблемы, связанные с вендорами, проблемы календарного планирования, проблемы управления рисками и т. д. [1]. Особенной ценностью в данной ситуации обладают компьютерные базы данных, в которых содержится подобная информация и которые позволяют выполнять поиск. Такая база данных может служить в качестве контрольного списка в ходе планирования проекта. Она также может использоваться в качестве контрольного списка в проактивном цикле контроля проекта (РСРС) для идентификации (выявления) проблем и рисков при мониторинге расписания, стоимости и содержания, например: • Каковы причины, вызывающие данное отклонение? • Какие новые риски могут возникнуть в будущем и как они могут изменить предварительно предсказываемое завершение проекта? В дополнение к этому база данных предлагает «предварительно выполненную» (готовую) оценку влияния и действия, которые могут быть предприняты для его ослабления. 6.2. Сводный отчет об исполнении 6.2.1. Что такое сводный отчет о ходе работ? Сводный отчет о ходе работ — это документ, имеющий обычно длину порядка страницы, который выносит на передний план и кратко описывает состояние проекта, выдавая отчеты об отклонениях по содержанию, стоимости, срокам, качеству, отражая значительные достижения, идентифицируя нерешенные проблемы, предсказывая тренд и определяя действия, требуемые для решения проблем и обращения неблагоприятного тренда. Главное – он предсказывает будущее. рис. 15.4. Рис. 15.4. Пример сводного отчета 6.2.2. Разработка сводного отчета о ходе работ ИД: базовый план проекта; результаты работ и проектные документы; • проактивный цикл контроля проекта (РСРС). План, факт, ход. ИД: отчеты по этапам (акты…), расход ресурсов (счета, наряды,…), переписка, протоколы, текущие отчеты. Вообще-то, это улучшенный текущий отчет (РСРС) и отвечает он на те же вопросы в несколько видоизмененной форме: • Каково расхождение между базовым планом и фактическим состоянием проекта? Каковы текущие проблемы, вызывающие это отклонение? • Какие риски могут возникнуть в будущем и как они могут в дальнейшем привести к краху проекта? • Каков тренд — предсказываемые дата завершения, бюджет, содержание и качество — в том случае, если текущие проблемы и риски сохранятся? • Какие действия следует нам предпринять для того, чтобы предотвратить развитие ситуации согласно нашему неблагоприятному прогнозу и удержать проект в рамках базового плана? Большая часть вышеприведенных вопросов относится к будущему проекта. Разработка системы ведения отчетности. Цель, иерархия, частота. Например, для маленьких проектов, типичная длина которых составляет 6 месяцев, — еженедельно; Для средних проектов, типичная длина которых составляет 12 месяцев, — раз в две недели; Для больших проектов, типичная длина которых составляет 24 месяца, — ежемесячно. Эти экспериментально выработанные цифры основаны на принятом в фирме убеждении, согласно которому все проекты должны иметь приблизительно одинаковое количество сводных отчетов (то есть контрольных циклов), в нашем случае 26, 26 и 24 соответственно, если мы хотим контролировать их надлежащим образом. Дело здесь не в самом количестве таких отчетов. Наоборот, именно существующая в фирме ситуация, определенная здесь в терминах политики контрольных циклов, требует данной частоты и данного расписания генерации отчетов, делая их регулярными планируемыми событиями. Еще надо задать обязанности и распространение сводных отчетов. Единство стиля и формата. Бывает для внешнего или внутреннего заказчика. Сводный отчет. 1 страница. Оценка хода и тренд. Части детального отчета — это общий статус проекта и его основных частей, основные результаты, значительные отклонения, основные проблемы, прогнозы окончательных параметров расписания и стоимости, а также детальные описания корректирующих воздействий. По сути, оба отчета — и сводный, и детальный — имеют дело с одними и теми же типами информации, однако с очень различной степенью детализации. Рассмотрим сводный, для детального то же, но детальнее. Инструменты были описаны, например, BCF. Цель и иерархия определяют частоту ведения отчетности. Например, в одной фирме сводные отчеты о ходе работ выпускаются по следующей схеме. ПЕРВАЯ КРАЙНОСТЬ — СЛУЧАЙ ПОДАЧИ ОТЧЕТОВ, СОДЕРЖАЩИХ НЕВЕРНУЮ ИНФОРМАЦИЮ Часто пишут, что затратити 100% времени, хотя бывает и 120% и больше. Все равно нет реакции. Бывают еще незапланированные отчеты, готовящиеся в ответ на неожиданные события критического характера, которые F. L. Harrison называет «красными разбойниками», точно отражая их потенциальную способность вызывать остановку проекта [2]. И наконец, определение областей ответственности по подготовке отчета и лиц, которым необходимо видеть этот отчет» является завершающим звеном разработки системы ведения отчетности. Определение отклонений. Описанными выше методами. Общий подход: обобщение по элементам. Идентификация проблем и рисков. Основа проблемы и возможные проблемы в будущем. Если кто-то может обанкротиться, нгадо заранее подготовиться. Можно пользоваться информационной базой проблем. Предсказание тренда. Важна не точность предсказания сроков, а сигнал раннего предупреждения. Подробное определение действий. Наряду с трендом детализация корректирующих действий является, быть может, наиболее важной частью РСРС и отчета, поскольку она дает проектным командам возможность быть проактивными. Наша единственная возможность изменить течение проекта лежит в его будущем. Эта возможность — то самое, что предлагает нам тренд — возможность предвидеть и формировать будущее нашими действиями сейчас. 6.2.3. Использование сводного отчета о ходе работ Когда использовать сводный отчет о ходе работ. Всегда, плюс детальный для больших. Можно и устно, вообще-то. ВТОРАЯ КРАЙНОСТЬ — СЛУЧАЙ НЕДОСТАТОЧНОЙ ОТЧЕТНОСТИ Некогда отчитываться, некогда исправлять. В результате расписание плывет. Трудоемкость. Команде простого и небольшого проекта может быть достаточно часа или около того, чтобы провести совещание по вопросам исполнения и подготовить типичный сводный отчет о ходе работ. Но сопроводиловка десятки часов. +- Затраты полезны. Проактивно. Вовлечены все. Дисциплинирует. Именно это суть работы менеджера проекта – подумать, спрогнозировать, действовать. И внимание высшего руководства. И история для анализа. Просто, наглядно. Но времяемко. 6.3. Послепроектный анализ 6.3.1. Что такое послепроектный анализ? Это и процесс, и документ. Цель – использовать в будущем, чтбы избежать ошибок и повторить успехи. .Рис. 15.5 – пример. Рис. 15.5. Пример послепроектного анализа (как документа) 6.3.2. Выполнение послепроектного анализа ИД: руководство по проведению послепроектного анализа; примеры прошлых послепроектных анализов; проектная документация (особенно журнал рисков и отчеты). ОСНОВОПОЛАГАЮЩИЕ ПРАВИЛА ПОВЕДЕНИЯ • Не мстите людям. Дайте четко понять с первой секунды послепроектного анализа, что это не место для того, чтобы мстить людям, тыкать пальцем, обвинять окружающих, спускать злость или вырабатывать разумные решения для слишком большого количества проблем. Если вы не объясните этого и не будете на деле поддерживать эту линию поведения, вашу компанию может постичь та же участь, что и многие другие, — идея послепроектного анализа в ней будет отвергнута. Далее, проясните также, что никакие из сделанных комментариев не будут использованы в обзорах производительности присутствующих лиц. • Не будьте слишком чувствительны. Оставьте свое эго за дверью и будьте скромны. Послепроектные обзоры существуют для того, чтобы выявлять ошибки в процессе и работе участников. Если ошибки обнаруживаются в вашей работе, проявляйте способность к самокритике и рассматривайте эти ошибки как возможность совершенствования и роста. • Не нападайте ни на кого. Акцент должен делаться на проблему — но не на людей. Концентрируйтесь на любых нерешенных вопросах, касаются ли они процесса, продукта, динамики команды и т. д. Стремитесь к тому, чтобы ваши комментарии были конструктивны. Обвинения в адрес другого или тычки пальцем в его промахи убили огромное количество послепроектных обзоров, лишив многие компании бесценной возможности учиться и становиться лучше. • Не забывайте о фактах. Еще раз подумайте вот о чем: то, что подвергается измерению, то и подвергается улучшению. Если вы будете собирать данные и факты и класть их в основу дискуссий в ходе послепроектных обзоров и отчетов, вы получите в свои руки метрику (систему показателей) для своего обучения и улучшения исполнения ваших будущих проектов. • Не пишите послепроектный анализ в стиле книги. Люди, которые будут выполнять проекты в будущем, не будут читать длинные отчеты. Хотя во время дискуссии могут возникнуть многие важные вопросы, экономьте слова при написании отчета. Будьте кратки, фокусируйтесь на небольшом количестве жизненно важных рекомендаций, которые обеспечивают наибольший потенциал (возможности) для улучшения. Ознакомьтесь с деталями, изложенными в подразделе «Документируйте обзор». Можно сильно дискредитировать идею. Надо подготовить базу для обсуждения. Подготовка обзора. Надо тщательно. Нужна повестка дня. В дискуссию могут, например, быть включены следующие шаги: • реконструкция фактической временной шкалы проекта и сравнение ее с базовым планом; • слабые места проекта, то есть те части проекта, выполнение которых было неудовлетворительным; • сильные места проекта, то есть те части проекта, выполнение которых было хорошим; • изложение рекомендаций о том, что при выполнении будущих проектов следует делать по-другому и что следует делать так же. Повестка дня зависит от отрасли и стратегической направленности выполняемых в ней проектов. В частности, предыдущий пример относится к высокотехнологичной компании, для которой важно минимальное время выхода на рынок. Обычный же производитель, конкурирующий за счет стоимости, может поставить в центр повестки дня не временную шкалу проекта, а его бюджет. Повестка готовится заранее, распространяется как предварительная. По замечаниям делается окончательная. Общее правило: проектная команда (рабочая группа?) должна проделать максимум работ заранее, чтобы на совещании обсуждать важное. ЛОГИСТИКА (материально-техничекая база?) ПОСЛЕПРОЕКТНЫХ СОВЕЩАНИЙ • Кто должен присутствовать? Пригласите ключевых участников, функциональные группы и заинтересованные стороны, имеющих отношение к областям как неудач, так и успехов проекта, потому что обучение и улучшение возможно только при совместном рассмотрении как успехов, так и провалов проекта. Если набирается чересчур большое количество людей, их можно разделить на основную (ключевую) группу и функциональные группы. После того как функциональные группы проведут свои послепроектные миниобзоры своих участков работы, из представителей этих групп набирается ключевая группа, на которую возлагается проведение окончательного послепроектного анализа. Кроме того, следует обеспечить равное и активное участие всех собравшихся в обсуждении. • Помещение. Когда группа, проводящая послепроектный анализ, в котором идут жаркие дебаты, вынуждена ютиться в тесной комнатке, люди могут ощущать себя загнанными в угол, и их реакцией может быть «бороться или сбежать». Во избежание подобного поведения участников необходимо позаботиться о просторном помещении, в котором могут комфортно разместиться все собравшиеся. Обеспечьте такое расположение людей, которое ставит их в равное положение друг по отношению к другу. Например, рассадите их вокруг круглого стола — чтобы все видели лица друг друга. • Ведущий. Использование помощи непредвзятого лица, которое не принимало участия в проекте и не имеет в нем каких-либо своих интересов, — это ключ к созданию атмосферы, стимулирующей эффективное ведение совещания. Такой человек осуществит проведение совещания и руководство им, оставаясь не вовлеченным в него. Основная роль ведущего — обеспечить соблюдение повестки дня и концентрацию дискуссии на основных проблемах. Он не допустит личных нападок и будет следить за тем, чтобы комментарии были конструктивными, чтобы все участники проявляли равную активность в обсуждении, чтобы временной регламент не нарушался. В осуществление этого ведущий должен разработать твердые и справедливые основополагающие правила (у нас это не привилось пока. Ему надо платить!). • Регистратор (протоколист У нас этого нет). В задачи регистратора входит обеспечение визуальной коммуникации (наглядного информационного взаимодействия), которая будет поддерживать акцентирование на проблемах, а не на людях. Вычленяя из обсуждения ключевую информацию и структурируя ее на листках бумаги, прикрепляемых к стенам или доске, регистратор обеспечивает эффективное протекание такого информационного взаимодействия. Различные тонкости, такие как использование цветных маркеров для обозначения характера комментария / суждения (например, красный цвет обозначает способность привести к остановке проекта) или символов для выражения ощущений группы по части данного комментария / суждения (например,«?» обозначает разногласие точек зрения), еще больше способны повысить качество запротоколированной информации. У нас есть секретарь, который ведет потокол. Слушали – постановили. И какие проблкмы обсуждались, кто выступал (текст выступления прилагается), кто говотил сообщения, какие вопросы задавались. Проведение обзора. Открывающие замечания о цели совещания, оглашены и утверждены основополагающие правила послепроектного анализа. У нас раньше часто собрания проводились. Всё четко было. Оказалось важно. Вот ТСЖ – собрание = базар. Теперь Есть председатель собрания. Он говорит вводные слова. Оглашает повестку. Замечанимя есть? Голосуем открыто: за, против, воздержался. Повестка прингята. Записали в протокол. Регламент (15 минут сообщение, до 2 – замечания, …). Замечания? За, против, воздержались? В протокол. Председатель: теперь основной доклад. Пожалуйста. Основной доклад. Предс. Пожалуйста, вопросы. Еще вопросы…. Больше нет? Заслушаем сообщение … и т.д. Припмерный список вопросов (по порядку): • рассмотреть и проранжировать проблемы (лучше бы подготовить список на 1 странице, раздать заранее или на совещании). Это широко, поэтому нужно направлять; Вариант: каждый указывает по 5 проблем, потом считаем. Иногда с пояснениями. Результат – итоговая пятерка. • задать вопрос о том, что шло неправильно Если важно расписание, то что не так с расписанием. Надо подготовить факт и план. На стену график!; Можно просто мозговым штурмом. Можно написать идею и пояснения. Можно аффинной диаграммой. • задать вопрос о том, что следует делать иначе в будущем; • задать вопрос о том, что шло правильно; • выстроить рекомендации в приоритетном порядке. ПРИМЕРЫ ВОПРОСОВ ИЗ КОНТРОЛЬНОГО СПИСКА ПОСЛЕПРОЕКТНОГО СОВЕЩАНИЯ Планирование проекта • Были ли бизнес-цели проекта ясны для вас? • Были ли действия других функциональных групп (разработки, маркетинга, производства) ясны для вас? • Были ли цели по части содержания, сроков, стоимости и качества ясны для вас? • Насколько адекватным и полным был план проекта, когда фактическая работа была начата? Голос заказчика (требования заказчика) • Был ли услышан голос заказчика и был ли он учтен при планировании, разработке дизайна (проектировании) и практической реализации проекта? • Находились ли процесс проекта, продукт проекта и предметы поставки проекта в соответствии с ожиданиями заказчико (клиентов, заинтересованных сторон, спонсора)? • Было ли информационное взаимодействие с заказчиком эффективным? Продукт и предметы поставки • Удовлетворены ли вы продуктом проекта? Другими предметами поставки проекта? • Каковы отклонения между фактическим и запланированным продуктом и другими предметами поставки? • Насколько эффективны были действия по контролю этих отклонений? Проектные решения по предметной части и спецификации • До какой степени изложенная в спецификации информация была адекватна для того, чтобы приступить к технической / технологической разработке? • Была ли она проведена вовремя? • Знала ли каждая функциональная группа о том, каким участком функционального проекта по предметной части она владеет? • Были ли кросс/функциональные интерфейсы в разработке дизайна / спецификаций четко определены? Календарное планирование и бюджетирование • Были ли базовые планы расписания и бюджета реалистичны? Достаточно детальны? Подкреплены достаточными ресурсами? • Насколько помогли контрольные события при отслеживании расписания / бюджета? • Имели ли место значительные отклонения между базовыми и фактическими расписанием / бюджетом? • Работала ли система показателей измерения прогресса проекта? Организация, команда и ресурсы • Была ли организация проекта адекватной? Была ли она функциональной? Матричной? Выполнялся ли проект выделенной командой? • Хорошо ли работала команда? • Имела ли команда необходимые навыки? Ресурсы? • Были ли роли членов команды и функциональных групп четко определены? Выполнялись ли они? Управление рисками • Были ли идентифицированы риски, связанные с процессом, продуктом и предметами поставки? • Насколько верными оказались предположения о рисках? • Насколько эффективными оказались действия, предпринимавшиеся в ситуациях наступления риска? Информационное взаимодействие • Насколько эффективна была коммуникация с руководством? С функциональными группами, осуществлявшими поставку ресурсов? С другими проектными командами? • Насколько эффективна была коммуникация внутри команды? • Была ли отчетность своевременной? Проактивной? Полезной? Слишком времяемкой? Высшee руководство • Были ли руководители вовлечены в основные обзорные совещания проекта? Были ли они эффективны? • Доводились ли до вашего сведения решения руководства? • Были ли эти решения ясными? Достаточно быстрыми? Понимали ли вы, как именно они делались? • Насколько они помогли вам выполнить вашу работу? Системы и программное обеспечение управления проектами • Как работала методология управления проектами компании — планирование проекта, контроль изменений, поддержка спонсора и т. д.? • Насколько эффективны были программные средства управления проектами, использовавшиеся в проекте? Когда что применять при определении того, что шло неправильно. Мозговой штурм хорош в ситуациях, когда отсутствуют «скрипучие колеса», то есть люди, доминирующие в дискуссии. Вы можете устранить их нежелательное влияние, перейдя к формальной технике командной работы, если только вы не хотите, чтобы было известно, кто является автором каждого конкретного суждения. Если целью является анонимность авторов комментариев, либо если вы хотите видеть, сколько раз делается тот или иной комментарий, вашим выбором может стать аффинная диаграмма. Если комментарии о том, что пошло не так, были собраны до совещания, то на самом совещании возникает возможность рассмотреть дополнительные комментарии. Как только список недочетов приобретет окончательный вид, его следует упорядочить согласно приоритетам, используя, например, метод голосования. Выбор из этого списка трех наиболее значимых недочетов даст команде возможность сосредоточиться на немногих жизненно важных проблемах. Кажется, что медленно. Но можно сделать за 5..10 минут. Затем следующий шаг – пути исправления (третий шиа первой проблемы). Ищем ответы на вопросы. • Были ли какие нибудь сигналы раннего предупреждения, извещавшие о том, что что то идет неправильно? • Что нам следовало сделать иначе, чем мы сделали? Так для каждого недочета. Шаг 4 проблемы 1. Обсудить, что шло хорошо. Аналогично. 5 удач. И вопросы по ним. • Какие методы сделали возможным наступление этих удач? • Какие из этих приемов не использовались в проектах раньше и рекомендуются к включению в выполнение будущих проектов? • Какие из этих приемов использовались в проектах раньше и рекомендуются к продолжению использования в будущих проектах? Результат: • несколько потенциально наиболее эффективных корректирующих стратегий, проистекающих из недочетов проекта и связанного с ними неправильного течения дел; • предлагаемых к использованию в будущих проектах практических приемов, проистекающих из удач проекта. Шаг 5 проблемы 1 – расстановка приоритетов. Можно на совещании, можно потом. Документирование обзора. Послепроектный анализ без финального документа лучше, чем отсутствие послепроектного анализа вообще. Но наличие такого документа обеспечивает значительные преимущества, например, можно распространить информацию, запомнить. Надо назначить ответственное лицо еще на стадии подготовки анализа. Если нет стандарта, надо определиться с содержанием отчета. Это для сравнимости разных отчетов по разным проектам. Например, может быт тело на 1 странице и приложение. Приложение для аутентичных комментов (рассказать о БД Густавсона). Полезно, если все изучат и внескут изменения. Использование уроков, извлеченных из послепроектного анализа. Когда результаты послепроектного анализа не используется, то на ум приходят слова Джорджа Сантаяны: «Тот, кто не помнит свое прошлое, обречен повторять его». Именно это может запросто произойти с любой проектной командой, которая выполняет послепроектный анализ, документирует его, а потом — забывает о нем. А это ценный капитал. Хорошее требование: начинать новый проект с анализа отчетов. В другой ведется база проблем, собранных из отчетов. Можно разобрать по элементам стандартизированнйо СДР. Т.о. это влияет на процесс управления проектами в целом. 6.3.3. Использование послепроектного анализа Когда использовать. По завершении. Для крупных – через нескольк недель, когда напряг спадет. Можно и через 6 месяцев, чтобы определить, как на рынке с результатами от проекта. В крупных можно и по окончании фазы или этапа. Неформально и быстро всё это можно сделать и в малых проектах. Трудоемкость. Вообще-то надо 1…2 дня. Но в некоторых разбивают на четырехчасовые совещания. Чем больше работы вне совещания, тем лучше. В малых проектах совещания от получаса до часа. +- Ускоряется обучение. Признание успеха, закрытие проекта. Отказ от проведения послепроектного анализа — это мелочность, это ограниченный и глупый подход, который могут себе позволить, быть может, только самые невежественные компании, часто извиняющие отсутствие послепроектного анализа необходимостью перебрасывать людей на новые проекты, которые, вероятно, будут обречены на повторение ошибок, сделанных в предшествующих проектах. Вот она — цена отказа от послепроектного анализа. Еще + «низковисящий фрукт». Но. Е сджелать плохо, то может легко привести к возникновению дисфункциональных конфликтов, проистекающих из взаимных личных нападок и указывания пальцем на ошибки друг друга. Вариации. Бывает, делаются менеджерами проектов. 6.4. Свод 7. Промышленные применения 7.1. Отбор инструментов в «инструментальный ящик» для управления проектами и его адаптация к нуждам пользователя 7.1.1. Какие из всех этих инструментов вам действительно нужны? Теперь, когда мы завершили наш обзор пятидесяти с лишним инструментов управления проектами, рассмотренных в предшествующих главах, в голову приходит совершенно естественный вопрос: «Какие из всех этих инструментов и в какой форме мне действительно нужны?» Здесь дается каркас для отбора. 7.1.2. Процесс отбора и адаптации набора инструментов управления проектами Отбор инструментов управления проектами и адаптация набора к специфическим условиям тех или иных проектов состоит из 3 основных шагов, каждый из которых включает в себя несколько задач (см. рис. 16.1): • обеспечение стратегического соответствия; • адаптация набора инструментов управления проектами; • непрерывное совершенствование. Далее по шагам. Рис. 16.1. Процесс отбора и адаптации набора инструментов управления 7.1.3. Обеспечение стратегического соответствия По шагам. 1. Понять конкурентную стратегию. В начале было: набор инструментов управления проектами в организации должен быть приведен в соответствие ее конкурентным целям. Поэтому менеджер проекта должен понимать стратегию. Однако многие ее не понимают. 1. Во мсногих организациях считается, что это дело высшего звена. 2. И интереса не проявляют менеджеры проектов. Надо с двух сторон идти на контакт. В противном случае разработка набора инструментов управления проектами будет подобна стрельбе в тумане — вы не будете знать, ни где находится мишень, ни попали ли вы в нее. 2. Наглядно представить характер обеспечиваемого соответствия. Примеры были выше. Intel испольузет инструменты, ориентированные на расписание. AWI (часы), стремящаяся конкурировать за счет низкой цены, использует набор инструментов, ориентированный на ценовые показатели. И наконец, OAG (OAG Aviation provides airlines, airports and the air transport industry with the most accurate and comprehensive airline information, analytical and forecasting services available today. Our portfolio includes a full range of aviation data products, industry analysis, forecasting and marketing solutions, and airport and airline consulting services from an award winning team.), конкурентная стратегия которой базируется на предоставлении наилучшей цены, использует инструментальный набор, ориентированный на показатель «цена / качество». Сводная таблица, иллюстрирующая эти положения, приведена на рис. 16.2. Рис. 16.2. Примеры приведения наборов инструментов управления проектами в соответствие конкурентным стратегиям (было?) Вот как это бывает у этих трех фирм. NPV на рис. Рис. 16.3. Каждая кривая выполнения проекта отражает использование различных наборов инструментов управления проектами Каждая кривая характеризуется четырьмя важными характеристиками: точкой начала проекта, временем до начала развертывания или использования заказчиками (TTD) (самый минус где-то рядом), временем до точки безубыточности (ТТВ) и точкой утилизации. Intel. Стратегия направлена на дифференциацию. Важна скорость. Это видно. Значит, надо использовать инструменты планирования и контроля расписания, которые и задают тон выполнению проектов в компании, диаграмма Гантта, ТАР, МКП диаграммы, диаграмма контрольных событий и т. д. Проще говоря, большая часть времени и внимания руководства уделяется именно этим инструментам, и они также служат в качестве главной основы в критические времена принятия важных решений. Для Intel важно и другое, значит, и другие инструменты используются, но они менее значимы. Глубокий провал: скорость стоит денег! AWI. Кривая фирмы AWI характеризуется наименее отрицательным потоком денежной наличности по сравнению с двумя остальными кривыми. Это неспроста! Зато длиннее.Оценки стоимости и базовые планы стоимости готовятся в вышей степени тщательно, равно как и оценивание прибыли на инвестированный капитал — даже для небольших проектов снижения стоимости. Еще исспоьзуется стандартизация процессов. Риски анализируются стоимостные. Урпавление упрощается, мало уровней СДР. Стандартные процедуры совещаний. ОАG. Акцент на качественные цели. И стоимостные инструменты. Тредования заказчика, контроль качества. Конечно, и время важно: удовлетворенность заказчика. Но время – не главное. Раекция на риски ориентирована на стоимость. Итак, есть набор довольно общий, но акценты разные. 3. Обеспечить соответствие набора инструментов конкурентной стратегии организации. Задачи: • установить желаемую степень соответствия (ничего внятного. Ну, например, рассмотрим приоритетное направление для начала. Пусть играет центральную роль); • установить текущую степень соответствия (опрос заказчиков, менеджеров, спонсоров); • идентифицировать разрывы между текущей и желаемой степенью соответствия (большой или маленький; сколько убирать); • действовать с целью достижения желаемой степени соответствия Это стратегия. Задает стратегию грубой алаптации. Потм нужна еще тонкая. 7.1.4. Адаптация набора инструментов управления проектами (Тонкая) адаптация стратегически выверенного инструментального набора управления проектами может выполняться в разных направлениях. Возможно, наиболее жизнеспособными являются следующие три направления: • Адаптация в соответствии с размером проекта. • Адаптация в соответствии с семейством проекта. • Адаптация в соответствии с типом проекта. Определяем, что входит в проект, для каждого процесса выбираем инструменты. Адаптация в соответствии с размером проекта. Со стратегией увязали раньше! Размер проекта обычно = мера сложности. Причем в геометрическаой прогрессии (например, количество управленческих операций). Размеры все опрошенные компании определили как малый, средний, крупный. Едизм: уде или челчасы. Что-то общее, что-то раличное. Отчет о ходе везде. Журнал рисков только в больших. • Рекомендации: • идентифицировать небольшое количество классов проектов и соответствующих им стандартных процессов управления; • определить каждый класс с помощью характеризующего размер параметра; • сопоставить каждому классу сложности соответствующий инструментальный набор для конкретной задачи. • Классияикация по размеру проста, но не учитывает индивидуальных тонкостей. Адаптация в соответствии с семейством проекта. Соответствие со тсратегией организации есть. Теперь можно и в отрасли, по семействам. Логика есть: есть близкие конкуренты, ориентированные на схожие проекты, общее окружение, сходные бизнес-задачи. Например, компании, работающие в отрасли высоких технологий, находятся в окружении динамичных технологических перемен. Поэтому их бизнес задача изобилует проектами, для которых важно время выхода на рынок [6]. Семейство, образуемое проектами разработки новых продуктов, выполняемыми в сферах высоких технологий, сталкивается с аналогичными трудностями. То же самое справедливо и для проектов управления производственными мощностями, производственных проектов, маркетинговых проектов и информационно технологических проектов, выполняемых в отрасли высоких технологий. Те же самые семейства проектов демонстрируют похожее поведение и в других отраслях. Поэтому есть тенденция к слиянию. И получается доминирующий стандарт. Бенчмаркинг работает. Вот еще по новизне. (табл. 16.4). Таблица 16.4. Пример классификации проектов в семействе по степени технической новизны Характеристика Класс проекта Простой Средний Сложный Заказчик Существующий Существующий или новый Существующий или новый Характеристики продукта 0—5 изменений черт существующего продукта > 5 изменений черт существующего продукта Отсутствие сходства с каким-либо существующим продуктом Характер конечного использования Тот же самый Тот же самый Тот же самый или новый Процесс производства Существующий Существующий Новый Процесс сборки Существующий Некоторые изменения существующего процесса Новый Три класса: простые, средние и сложные. На основе 11 характеристие , в основном новизны. Еще заказчик, характиристики подукта, характер конечного использования, процесс производства и сборки. Новизна  неопределенность, сложнее определить содержание, требует больших навыков, интенсивнее коммуникации, улучшенное управление измененями. Течет расписание и стоимость, высоки риски. Табл 16.5: у всех есть расписание и отчет о ходе исполнения. Но методы разные, от диаграммы контрольных событий до TAD с бегущей волной. Из-за разной новизны. +- адаптации к семействам. 1 параметр: новизна, просто. Понятно. Но. Непригодно для технологических проектов, в них новизну измерять нельзя!!! Можно создать много смейств, много моделей много инструментальных наборов. Таблица 16.5. Примеры классификации проектов, входящих в одно семейство, в соответствии со степенью технической новизны Класс проекта Фазы проекта Определение Планирование Выполнение Закрытие Простой Устав проекта Модель балльной оценки с акцентом нa NPV Пузырьковая диаграмма Круговая (секторная) диаграмма портфеля проектов Диаграмма контрольных событий Отчет о ходе исполнения Отчет о ходе исполнения Средний Устав проекта Модель балльной оценки с акцентом на NPV Пузырьковая диаграмма Круговая (секторная) диаграмма портфеля проектов Указания по ведению дискуссии, отчет об опросе заказчиков Констатация содержания Диаграмма Гантта с контрольными событиями Отчет о ходе исполнения Обновленная диаграмма Гантта Отчет о ходе исполнения Сложный Устав проекта Четырехстадийная модель Реестр навыков Модель балльной оценки с акцентом нa NPV Пузырьковая диаграмма Круговая (секторная) диаграмма портфеля проектов Различные инструменты работы с голосом заказчика Констатация содержания СДР Матрица ответственности Оценка стоимости, основанная на контрольных событиях Привязанная к временной шкале диаграмма «операции на дугах» (каскадная форма, бегущая волна) Диаграмма контрольных событий План реагирования на риски (качественный) Матрица мотивации Отчет о ходе исполнения Обновленная, привязанная к временной шкале диаграмма «операции на дугах», диаграм/ ма контрольных событий Запрос на внесение изменения Журнал изменений проекта Журнал рисков Матрица мотивации Отчет о ходе исполнения Послепроектный анализ Рекомендации. • Подразделяйте ваши проекты и их процессы стандартизованного управления на несколько классов. • Определяйте каждый класс посредством нескольких технических параметров. • Поддерживайте каждый класс надлежащим набором инструментов — так, чтобы каждый инструмент поддерживал конкретный управленческий предмет поставки. Адаптация в соответствии с типом проекта. Оба параметра. Сложность+новизна. (модель Шенхара [8]). Упрощенно дял практических целей. Шаги: • определить типы проекта; • описать, как наличие двух параметров влияет на процесс стандартизированного управления проектами каждого типа; • описать наборы инструментов для управления четырьмя типами проектов. Каждый из двух параметров включает в себя два уровня: • техническая новизна (уровни: низкая, высокая); • сложность проекта (уровни: низкая, высокая). Отметим, что здесь мы используем масштаб системы (понятие, очень близкое к размеру проекта) как меру сложности проекта. Это помогает создать матрицу размера 2 * 2, которая характеризует 4 основных типа проектов (см. рис. 16.4). Рис. 16.4. Четыре типа проектов Перепечатано с разрешения, Shenhar, J. Aaron, «One Size Does Not Fit All Projects: Exploring Classical Contingency Domains», Management Sci. 47(3) 394—414, 2001. Copyright © 2001, The Institute for Operational Research and the Management Sciences (INFORMS), 901 Elkridge Landing’Road, Suite 400, Linthicum, Maryland 21090—2909, USA. Рутинные проекты уровень сборочной единицы. Уровень технологий от низкого до среднего. Внутри организации или подразделения (отдел маркетинга). Примеры: • непрерывное совершенствование проектов в подразделении; • обновление существующего программного пакета или существующего продукта; • добавление бассейна к существующему отелю; • разработка новой модели традиционного тостера; • расширение существующей производственной линии. Административные проекты. Низкие технологии, но сложные составные продукты. Много организаций, координация. Много административной рбаоты. Примеры: • реструктурирование организации в масштабах корпорации; • развертывание стандартной информационной системы в географически рассредоточенной организации; • строительство традиционного производственного предприятия; • разработка новой модели автомобиля; • усовершенствование нового компьютера или усовершенствование многофункционального программного пакета. Основной приоритет технических проектов сделан на их техническом содержании, отсюда и название. Неопределенность, длительные циклы, изменеиня содержания. Результат – подсистема. В пределах одной организации. Примеры: • реинжиниринг процесса разработки нового продукта в организации; • добавление линии с новейшей производственной технологией к существующей фабрике по производству полупроводников; • разработка новой модели компьютера; • разработка новой модели компьютерной игры. Уникальные проекты На пике системной сложности и технологической неопределенности. Примеры: • построение городской транспортной системы; • разработка нового поколения микропроцессоров; • создание нового многофункционального программного пакета; • сооружение фабрики по производству полупроводников с использованием новых технологий; • разработка платформы для продукта в национально разбросанной (международной) корпорации. Вообще, техническая новизна порождает большую неопределенность. Примеры на рис. 16.5. Рис. 16.5. Адаптация набора инструментов управления проектами в соответствии с типом проекта +-. Унифицирующий каркас. Но прокрустово ложе. 7.1.5. Какой вариант адаптации выбрать? Табл. 16.6. 7.1.6. Непрерывно совершенствуйте набор инструментов управления проектами Набор может деградировать. Надо поддерживать и совершенствовать. Шаги: • сформировать команду по улучшению набора инструментов управления проектами; • определить механизмы генерации идей по улучшению; • следовать процессу улучшения. Формирование команды по улучшению. Неплохо бы из менеджеров проектов, так как им это больше всех надо. Идентификация механизмов генерации идей по улучшению. Нужен непрерывный поток предложений и идей по улучшению адаптированного набора инструментов. Например, из послепроектных отчетов. Можно подавать запросы, можно беседовать. Следование процессу улучшения. Надо реагировать быстро, принимать или отклонять запросы. 7.2. Заключительные размышления См. начало. Зачем набор инструментов. Испоьзовать инструменты для совершенствования набора инструментов. 8. Связь между инструментами управления проектами и РМВОК Pmbok устанавливает фазы (процессы?): • Процессы инициации (Инициац.). • Процессы планирования (План.). • Процессы исполнения (Исполн.). • Процессы контроля (Контр.). • Процессы закрытия (Закр.). И области знаний: • Управление интеграцией проекта (Инт.). • Управление содержанием проекта (Содерж.). • Управление временем (сроками) проекта (Время). • Управление стоимостью проекта (Стоим.). • Управление качеством проекта (Кач.). • Управление трудовыми ресурсами проекта (Труд. рес.). • Управление коммуникацией проекта (Комм.). • Управление рисками проекта (Риски). • Управление поставками (снабжением, обеспечением) проекта (Пост.). Соотвтествия – в табл. 9. Детали 9.1. Связь между наборами инструментов управления проектами и размером проекта 9.2. Связь между наборами инструментов управления проектами и семейством проекта 9.3. Связь между наборами инструментов управления проектами и типом проекта 9.4. Ассоциация Российских Project Management специалистов объединяет АССОЦИАЦИЯ УПРАВЛЕНИЯ ПРОЕКТАМИ «СОВНЕТ» (www.sovnet.ru).