Введение в управление проектами

Лекция 1 ВВЕДЕНИЕ В УПРАВЛЕНИЕ ПРОЕКТАМИ Что такое проект? Проект – временное начинание, предпринятое для создания уникального товара, услуги или получения уникального результата. Как и большинство начинаний компании, главная цель проекта заключается в удовлетворении потребностей заказчика. Если не учитывать этой общей цели, то проект отличается от прочих начинаний компании, и для этого можно выделить некоторые характеристики, присущие проекту. – у проекта всегда есть четкая цель. Эта цель обычно отсутствует в повседневной деятельности компании, в которой сотрудники совершают повторяющиеся операции каждый день. – так как цель конкретна, у проектов конкретная конечная точка. – для проектов характерно комбинирование и объединение усилий самых разных специалистов, в отличие от большинства видов организационной работы, которая делится по принципу функциональной специализации. – проект никогда не бывает одним и тем же. Он всегда содержит какие-либо уникальные элементы. – проект ограничен по времени, затратам и особым требованиям к выполнению работ. Таким образом, можно выделить следующие основные характеристики проекта: 1. Заданная цель; 2. Определенная продолжительность или срок жизни проекта с началом и окончанием; 3. Участие в нем нескольких отделов и профессионалов; 4. Как правило, это нечто новое, что никогда раньше не делали; 5. Конкретные требования ко времени, затратам и результатам. Проекты нельзя смешивать с ежедневной работой. Проект – это не обычная и без конца повторяющаяся работа, которая требует выполнения рутинных действий снова и снова, проект выполняется только один раз. Программа – это группа связанных проектов, задуманных для достижения общей цели на продолжительном отрезке времени. Управление программой – процесс управления группой синхронных взаимосвязанных проектов скоординированным образом для достижения стратегических целей. Жизненный цикл проекта Каждый проект в своем развитии проходит несколько стадий: от определения проекта до его закрытия, в совокупности представляющих жизненный цикл проекта. Жизненный цикл означает, сто проекты имеют ограниченный отрезок времени существования, и на протяжении этого отрезка в проекте будет меняться уровень затрачиваемых усилий и направления работы. Жизненный цикл проекта Жизненный цикл проекта последовательно проходит четыре стадии. Старт происходит в тот момент, когда получена официальная команда о начале проекта. 1. Стадия определения. Определены спецификации проекта, установлены проектные цели, сформирована команда, обозначены основные обязанности. 2. Стадия планирования. Составляются планы для более точного контроля проекта: когда будет выполнен, кому это принесет пользу, какой уровень обслуживания стоит поддерживать и каким будет бюджет. 3. Стадия выполнения. Основная часть работы над проектом состоит из двух аспектов – создания материального продукта и контроля основных параметров проекта (времени, стоимости, спецификации и др.) 4. Стадия поставки (закрытия) – состоит из двух частей: поставка продукта заказчику и перераспределения ресурсов. Важность управления проектами Важность управления проектами определяется тем, что доля деятельности обычной компании, посвященная проектам, непрерывно растет. Это обусловлено следующими причинами: 1. Сжатие жизненного цикла продукта. По данным исследований, сегодня в отраслях высоких технологий жизненный цикл продукта в среднем составляет от 1 года до 3 лет, в то время как 30 лет назад циклы, как правило, длились от 10 до 15 лет. Также установлено, что полугодовая задержка выполнения проекта в отраслях высоких технологий влечет за собой потерю прибыли в размере 33%. 2. Увеличение объема знаний. Рост объема знаний обусловил усложнение проектов, так как проекты, как правило, основываются на самых последних достижениях науки и техники. 3. Больше внимания к клиенту. Усилившаяся конкуренция сделала прибыль компаний более зависимой от удовлетворенности клиента. Это привело к производству товаров и услуг по индивидуальным заказам. Интегрирование проектов со стратегическим планом Сегодня проекты являются способом действия для реализации стратегии компании. В связи с этим необходима «подгонка» проектов под стратегию компании, что, в конечном счете, обеспечит эффективность использования ресурсов компании. «Подгонка» по сути – это отбор тех проектов, реализация которых вносит вклад в достижение стратегических целей компании. Из отобранных проектов формируется портфель проектов компании. Для эффективного управления проектами всей организации используется портфельный менеджмент, позволяющий соединить в одно целое управление проектами всей организации. Основные функции портфельного менеджмента следующие: 1. контролировать отбор проектов; 2. отслеживать, как распределяются ресурсы и навыки; 3. способствовать внедрению передовых методов; 4. уравновешивать проекты в портфеле, чтобы они соответствовали уровню риска данной компании; 5. улучшать взаимодействие между всеми участниками проектов; 6. создавать общую перспективную точку зрения, которая выходит за пределы частного субъективного мнения; 7. улучшать весь процесс управления проектами с течением времени. Портфельный менеджмент осуществляет интеграцию элементов стратегического плана с проектами и делает их взаимозависимыми. Лекция 2 СТРАТЕГИЯ КОМПАНИИ И ОТБОР ПРОЕКТОВ Стратегия определяет, как та или иная компания будет опережать конкурентов. Организации или компании используют проекты с целью конвертирования стратегии в новые продукты, услуги и процессы, которые необходимы для успеха. Стратегия описывает, как организация намеревается опередить конкурентов с имеющимися у нее ресурсами (как правило, ограниченными) в текущий момент и в обозримом будущем. Двумя основными аспектами стратегического управления являются реагирование на изменение внешней среды и распределение ограниченных ресурсов фирмы таким образом, чтобы улучшить ее конкурентоспособность. Стратегическое управление определяет характер и основные направления будущего развития фирмы. После того, как определены долгосрочные перспективы, поставлены цели и разработаны общие подходы для их достижения, предпринимаются действия по осуществлению проектов. Большинство организаций достаточно успешно формулируют стратегию того курса, который они должны осуществить. Однако проблема многих организаций заключается в неспособности осуществить эти стратегии. Объявленная стратегия часто расходится с «делом». Процесс стратегического управления представляет собой следующую последовательность действий: 1. Анализ и определение миссии организации. Миссия определяет, «чем мы хотим стать», или смысл существования организации. Традиционные элементы миссии – основные продукты и услуги, определение клиентов, рынков и географической сферы деятельности. 2. Постановка долгосрочных целей и задач. Задачи позволяют представить миссию организации в виде определенных, конкретных измеримых понятий. В каждом случае задачи должны быть настолько оперативными, насколько это возможно, т.е. должны включать временные рамки, быть измеримы, определяемы и реалистичны. 3. Анализ и формулирование стратегий для достижения целей. Первый шаг – реалистичная оценка прошлого и настоящего положения предприятия. На этом этапе происходит анализ: «кто клиенты» и «что является их потребностями в том виде, в каком они эти потребности видят». Второй шаг – оценка внутренней и внешней окружающей среды. Каковы сильные и слабы стороны предприятия? Анализ возможностей и угроз, которые обычно исходят от внешнего окружения. На основе этого анализа определяются критические моменты и портфель стратегических альтернатив. Эти альтернативы сравниваются с уже имеющимся портфелем, и предварительно оценивается возможность их реализации с учетом имеющихся ресурсов. После этого выбирают стратегии, которые должны поддерживать основную миссию и цели организации. Формулировка стратегии заканчивается постановкой каскадных задач или проектов, рассчитанные более низкие уровни компании. 4. Осуществление стратегии посредством управления проектами. Осуществление стратегии – ответ на вопрос, как она будет реализована на основе имеющихся ресурсов. Осуществление стратегии требует действий и выполнения заданий (задач), которые часто представляют ценные для мисси компании проекты. Процесс стратегического управления Поскольку реализация стратегии осуществляется через выполнение набора проектов, то необходима эффективная система управления портфелем проектов. Основные проблемы при реализации большого количества проектов обусловлены отсутствием системы приоритетов. Рассмотрим три основные проблемы, вызванные указанным обстоятельством: 1. Разрыв в реализации стратегии – отсутствие понимания по поводу реализации стратегии компании между высшим руководством и менеджерам среднего звена. 2. Политика организации оказывает существенное влияние на финансирование проектов и выстраивание приоритетов. Это обстоятельство оказывает особенно сильное влияние, если критерии выбора проектов плохо сформулированы. 3. Конфликты ресурсов и многопроектная среда. В большинстве случаев многие проекты организации оказываются взаимозависимыми, в том числе с точки зрения совместного использования ресурсов во всех проектах. Количество ресурсов в портфеле зачастую превышает доступные ресурсы. Эта перегрузка неизбежно ведет к беспорядочному и неэффективному использованию ограниченных ресурсов организации. Для решения указанных проблем необходима разработка и использование состоятельного процесса выстраивание приоритетов для максимально эффективного отбора проектов. Портфельная система управления Задачи портфельного управления связаны с вопросом: «Что имеет стратегическую ценность для нашей организации?». Проектная портфельная система должна включать классификацию проектов, критерии отбора в зависимости от классификации, источники предложений, оценку предложений и управление портфелем проектов. Классификация проектов Обычно выделяют четыре основных вида проектов: 1. Вынужденные проекты – проекты, которые заключаются в определении обязательных требований, распространенных законодательно в определенном регионе, где осуществляет свою деятельность компания. 2. Неотложные проекты – например, проект по восстановлению производства после аварии или стихийного бедствия. 3. Оперативные (операционные) проекты – те, которые необходимы, чтобы поддержать текущие операции компании, т.е. поддержать ее на плаву, обеспечив прибыль. Эти проекты предназначены для улучшения системы поставки, уменьшения затрат на производство изделия и улучшения производительности. 4. Стратегические проекты – те, которые непосредственно поддерживают миссию организации на перспективу. Они часто направлены на увеличение выручки или рыночной доли. Примеры стратегических проектов – производство новых изделий, проведение НИОКР. Стратегическая ценность предложенного проекта должна быть определена прежде, чем он будет помещен в портфель. Безоговорочно выполняются лишь проекты первого типа – вынужденные проекты. Все остальные проекты отбирают с использованием определенных критериев, связанных со стратегией организации. Критерии отбора проектов, как правило, подразделяют на две основные категории: финансовые и нефинансовые. 1) к финансовым критериям можно отнести период (срок) окупаемости и чистый дисконтированный доход. 2) нефинансовые критерии. Несмотря на значимость, прибыль в денежном выражении не всегда отражает стратегическую важность. Поэтому в ход идут и другие критерии, помимо финансовой эффективности. Компания может поддержать проекты, которые не обещают большой прибыли, по следующим причинам стратегического характера: - чтобы захватить большую долю рынка; - помешать конкурентам выйти на рынок; - развить основную (новую) технологию, которая будет использоваться в продуктах нового поколения; - уменьшить зависимость от ненадежных поставщиков и др. Поскольку никакой отдельно взятый критерий не может отразить стратегического значения, то портфельное управление требует многочисленных критериев, объединенных на основе скрининговых моделей. Отбор проектов происходит по этим моделям, чтобы вывести на первый план те проекты, которые вносят вклад в достижение самых важных стратегических целей. Рассмотрим два метода отбора проектов по множественным критериям: метод опросника и метод отбора с количественно измеряемыми критериями. 1) Модели на основе опросника. Опросник – это список вопросов, через которые «прогоняют» проекты, определяя их приемлемость или несоответствие. Преимуществом модели на основе опросника является ее гибкость при выборе между различными типами проектов. Такие модели могут легко использоваться разными подразделениями. Указанный метод обладает рядом существенных недостатков. Большая их часть заключается в том, что он не в состоянии отразить относительную важность или ценность потенциального проекта для компании и не в состоянии сравнить проект с другими потенциальными проектами. Каждый потенциальный проект будет по-разному отражен в опроснике, с разным набором положи­тельных и отрицательных ответов. Как сравнить их между собой? Сопоставить проекты по важности и выстроить соответствующую схему приоритетов бы­вает трудно, а иногда просто невозможно. Этот подход также открывает воз­можности для потенциальных интриг, политики и прочего манипулирования. Упомянутые недостатки могут быть устранены путем применения метода отбора с количественно измеряемыми критериями. Возможные вопросы: Тема Вопрос Стратегия / «подгонка» Под какую конкретную стратегию организации подогнан данный проект? Движущая сила Какую проблему бизнеса разрешает данный проект? Индикаторы успеха Как нам измерить успех? Спонсорство / финансовая поддержка Кто является спонсором проекта? Риск Что будет в случае отказа от данного проекта? Риск Каков риск по проекту для вашей компании? Риск Как именно предложенный проект вписывается в нашу схему рисков? Выгоды, ценность, доходность Какова ценность проекта для этой организации? Выгоды, ценность, доходность Когда проект даст результаты? Задачи Каковы задачи проекта? Культура компании Культура нашей организации подходит для этого типа про­екта? Ресурсы Имеются ли внутренние ресурсы для этого проекта? Подход Мы строим или покупаем? Время на проект Сколько он займет времени? Обучение / ресурсы Потребуется ли обучение персонала? Финансы / портфель Какова приблизительная смета на проект? Портфель Это новая инициатива или часть существующей инициативы? Портфель Как данный проект скажется на текущих проектах? Технология Технология уже опробована или новая? 2) Метод отбора с количественно измеряемыми критериями. Этот метод, как правило, использует несколько измеряемых критериев отбора для оценки проектных предложений. В него входят качественные и/или количе­ственные критерии. Оценочная матрица проектов Каждый критерий отбора имеет две характеристики: «вес» и степень важности для проекта. Вес и выигрышность критериев учитываются совместно для оценки значимости проекта в целом. Используя данные многочис­ленные критерии, проекты можно сравнивать между собой. Проекты с более вы­сокими суммарными показателями считаются лучшими. Процесс скрининга проекта Управление портфельной системой. Балансировка портфеля по рискам и типам проектов Главная задача команды по приоритетам состоит в том, чтобы сбалансиро­вать проекты по типам, рискам и ресурсам. Это требует видения полной пер­спективы организации. Следовательно, предложенный проект, который имеет высокую оценку по большинству критериев, не может быть отобран, если порт­фель организации уже включает слишком много других проектов с теми же самыми характеристиками, например: уровень риска проекта, использование ключевых ресурсов, высокая стоимость, убытки, большая продолжительность. Балансировка портфеля проектов так же важна, как и отбор проекта. Орга­низации должны оценить каждый новый проект с точки зрения того, что он добавляет к проектному объединению. Краткосрочные потребности должны быть сбалансированы с долгосрочным потенциалом. Использование ресурсов должно быть оптимизировано по всем проектам, а не только для самого важ­ного проекта. С проектами связаны два типа риска. Первый – это риски, ассоциируемые с общим портфелем проектов. Эти риски должны соответствовать профилю ри­ска организации. Второй – риски по конкретному проекту, которые могут пре­пятствовать реализации проекта. Это риски графика (календарного плана), риски, связанные с затратами, и технические риски. Рассмотрим только риски самой организации, присущие портфелю проектов – рыночные риски, риск неисполнения, риск не успеть вовремя вывести новый товар на рынок и риск появления новых технологий. Группа исследователей изучила ряд научно-исследовательских организаций и предложила матрицу для оценки проектного портфеля. В представленной матрице вертикальная ось отражает степень сложности, а горизонтальная – потенциальную коммерческую ценность. Сетка имеет четыре сектора, каждый из которых отражает следующие проектные направления: 1. Проекты типа «бутерброд», как правило, включают последующие усовер­шенствования текущих товаров и услуг, разработку программного обеспе­чения, модернизацию усилий по сокращению стоимости производства. Матрица для оценки проектного портфеля 2. Проекты типа «жемчуг» представляют собой революционные коммерче­ские проекты, использующие результаты научно-технического прогресса, например, чипы интегральных схем следующего поколения и технологии, позволяющие отображать то, что находится под землей, для определения месторождений нефти и газа. 3. Проекты типа «устрица» включают крупные технологические достижения с высокими коммерческими инвестициями (определе­ние ДНК для эмбрионов и разработка новых видов металлических сплавов). 4. «Белые слоны» – проекты, которые были многообещающими, но теперь не жизнеспособны, например изделия для насыщенного рынка или мощный источник энергии с негативными побочными эффектами. В ходе исследования было выявлено, что организации часто име­ют слишком много «белых слонов» и слишком мало «жемчуга» и «устриц». Для поддержания стратегического преимущества рекомендуется организациям сконцентрироваться на «жемчуге», устранить позицию «белых слонов» и сба­лансировать ресурсы, выделенные под проекты типа «бутерброд» и «устрица», в соответствии с общей стратегией компании. Хотя исследование посвящено научно-исследовательским организациям, выводы применимы ко всем типам проектных компаний. Лекция 3 СТРУКТУРА ОРГАНИЗАЦИИ Многие организации испытывали огромные трудности, создавая систему организации проектов и одновременно управляя текущей деятельностью. Одна из главных причин таких трудностей заключается в противоречиях между проектами и фундаментальными структурными принципами, на которых основаны традиционные компании. Проекты являются уникальными, единичными ме­роприятиями с вполне определенным началом и концом. Большинство же орга­низаций созданы для эффективного управления непрерывной деятельностью. Эффективность, прежде всего, достигается путем разделения сложных заданий на более простые, повторяющиеся операции по типу сборочного конвейера. Организация проектов в рамках функциональной структуры компании Один из подходов к организации проектов – простое управление ими в рам­ках существующей функциональной иерархии организации. Как только на­чальство принимает решение осуществить проект, работа над различными сег­ментами проекта поручается соответствующим функциональным единицам, при этом каждое подразделение отвечает за выполнение работ по своему сег­менту проекта. Функциональная структура также обычно используется, когда из-за характера самого проекта одна функциональная область играет доминирующую роль в за­вершении проекта или особо заинтересована в успехе проекта. При этих услови­ях менеджер высшего звена становится ответственным за координацию проекта в целом. Существуют как преимущества, так и недостатки использования корпоратив­ных функциональных структур для управления и руководства проектами. Глав­ные преимущества перечислены ниже: 1. Неизменность. Проекты осуществляются в пределах основной функцио­нальной структуры организации. Не происходит никакого радикального изменения ни в проекте, ни в действиях организации-учредителя. 2. Гибкость. Персонал используется с максимальной гибкостью. Соответствующие специалисты в различных функциональных подразделениях по­лучают задания по работе над проектом на время его разработки, а после окончания они возвращаются к своей основной деятельности. Поскольку в каждом функциональном подразделении достаточно много технических специалистов, то их легко подключить к работе над различными проектами. 3. Тщательная экспертиза. Если объем проекта узко специализирован и ос­новная ответственность возлагается на соответствующий функциональный отдел, то наиболее важные аспекты проекта можно подвергнуть особо де­тальному и тщательному изучению специалистами. 4. Легкий постпроектный переход. Внутри функциональной структуры ор­ганизации карьерный рост не связан напрямую с проектами, следовательно, специалисты не будут переживать постпроектный «синдром» (переходный, подчас осложненный период возвращения к рутинным обязанностям). Специалисты вносят значительный вклад в проекты, но их основная работа является для них профессиональным «домом» и источни­ком их профессионального роста и продвижения по службе. Наряду с преимуществами организации проектов в рамках существующей функциональной структуры имеются и недостатки. Эти недостатки особенно сильно проявляются, если объем проекта велик и ни один из функциональных от­делов не берет на себя смелость возглавить руководство им. 1. Недостаток концентрации. Каждое функциональное подразделение зани­мается своей обычной работой, поэтому иногда выполнением проекта пре­небрегают в пользу выполнения основных функциональных обязанностей. Эта проблема усугубляется, когда приоритетность проекта разная в разных подразделениях. Например, для отдела маркетинга проект может быть важным и срочным, в то время как отдел эксплуатации оборудования считает его второстепенным. Легко представить себе напряженность, которая может воз­никнуть, если работники отдела маркетинга будут вынуждены ждать. 2. Слабая интеграция. Связи между функциональными отделами могут ока­заться слабыми. Соответствующих функциональных специалистов интересует только их конкретный сегмент проектных работ, но никак не проект в целом. 3. Медлительность. На работу над проектом в рамках функциональной ор­ганизации обычно уходит больше времени. Отчасти это объясняется бо­лее продолжительным временем реагирования – информация о проектных решениях должна пройти по обычным структурным каналам управления. Кроме того, недостаточность горизонтального, прямого обмена информа­цией между функциональными группами приводит к необходимости посто­янно переделывать работу, когда специалисты слишком поздно обнаружи­вают ошибку другого отдела. 4. Слабая мотивация. Мотивация людей, занятых в проекте, может быть очень слабой. Проект может рассматриваться как дополнительное бремя, которое непосредственно не связано с их профессиональным развитием или продви­жением, и так как они работают только на одном сегменте проекта, то со всем проектом они себя не отождествляют. Недостаток мотивации препятствует готовности обязательно выполнить все, что необходимо сделать по проекту. Функциональная структура компании Организация проектов по принципу независимых команд Принципиально противоположная структура управления проектом – независимые проектные команды, действующие как отдельные единицы независимо от остальной части организации-учредителя. Управляющий проектом должен организовать основную группу специалистов, которые будут заняты полный рабочий день над проектом. Управляющий проектом принимает на работу необходимый персонал для деятельности как внутри, так и за пределами организации-учредителя. Сформированная таким образом команда физически отделяется от организации-учредителя. В компаниях, где проекты доминируют как форма бизнеса (строи­тельных или консалтинговых) вся организация поддерживает проектные команды. Вместо ведения одного или двух специальных проектов организация набирает полунезависимые команды, работающие на определенных проектах. Главная задача обычных функциональных организаций состоит в том, чтобы помочь и поддержать эти проектные команды. Например, усилия отдела маркетинга направлены на развитие нового бизнеса, который даст большое количество новых проектов, в то время как отдел управления персоналом отвечает за решение различных проблем, связанных с персоналом, наймом и обучением новых служащих. Этот тип организации в теории описан как форма организации проектного типа. Важно заметить, что не все проекты – независимые проектные команды; персонал может работать на разных проектах одновременно. Подход на основе независимых проектных команд имеет свои сильные и слабые стороны. Перечислим его преимущества: 1. Простота. Кроме использования специалистов, назначенных на проект, функциональная организация сохраняет свою целостность, а проектная команда работает независимо от нее. 2. Быстрота. Наблюдается тенденция осуществления проектов за более ко­роткое время, если их участники все силы направляют на проект и не связа­ны другими обязательствами. Более того, в такой системе реакция на приня­тое решение наступает гораздо быстрее, так как информация уже не ходит по вертикалям функциональной иерархии. 3. Сплоченность. У членов проектной команды появляется высокий уро­вень мотивации и взаимопонимания. Участники объединены общей целью и личной ответственностью за проект и команду. 4. Многофункциональная интеграция. Происходит перекрестное обучение (все учатся друг у дру­га), и, таким образом, уровень подготовленности команды значительно воз­растает. Специалисты из разных областей работают вместе и при надлежащем руководстве стараются оптимизировать проект целиком, а не только те его участки, в которых они выступают экспертами. Независимая проектная команда Организационная структура проектного типа Во многих случаях независимая команда является оптимальным решением для организации управления проектом. Однако слабые стороны данного подхода проявляются сразу же, как только принимаются во внимание потребности основной организации. Они перечислены ниже: 1. Дороговизна. Мало того, что создается новая должность (менеджер проекта), выделяются также ресурсы по отдельному рабочему штату. Это может привести к дублированию работы в разных проектах и увеличивает издержки. 2. Внутренняя борьба. Иногда независимые проектные команды начинают считать себя абсолютно самостоятельными и независимыми от основной организации. Возникает резкое противопоставление «мы–они» между проект­ной командой и остальной компанией. Противостояние может затруднить не только соединение возможных результатов проекта в единое целое, но и возвращение членов проектных команд назад в их функциональные отделы после завершения работы над проектом. 3. Ограниченность технологической экспертизы. Создание отдельных ко­манд мешает профессиональному разрешению проблем, так как оно ог­раничивается только профессиональным уровнем специалистов, работа­ющих над проектом. В то же время ничто не мешает специалистам консультироваться с другими функциональными подразделениями, однако проблема «мы–они» и тот факт, что такие консультации формально не санкционированы организацией, препятствуют подобным контактам. 4. Трудный постпроектный переход. Назначение персонала для выполнения проекта создает проблему: что с ним делать после того, как проект будет завершен? Если нет других проектов, то возникают трудности с обратным переводом специалистов в функциональные отделы из-за долгого отсутс­твия и необходимости вникать во все произошедшее, во все новинки и но­вовведения в их функциональной области. Организация проектов в матричной системе Матричное управление – гибридная организационная форма, в которой горизонтальная структура руководства проектом «накладывается» на нормальную функциональную иерархию. В матричной системе обычно существуют два канала управления: управление через функциональных менеджеров (начальников отделов) и через проектных менеджеров. То есть не происходит делегирования отдельных сегментов проекта различным отделам и не создаются независимые команды проекта, а участники проектов подотчетны одновременно и функциональным менеджерам, и управляющим про­ектами. Матричная структура предназначена для оптимального использования ресурсов, так как одновременно с разработкой многочисленных проектов органи­зация способна выполнять свои обычные функциональные обязанности. В то же время матричный подход пытается достичь большей интеграции проектной ра­боты через наделение управляющего проектом достаточными полномочиями. Теоретически матричный подход «убивает» сразу двух зайцев: дает максимум технических знаний и опыта через подключение к работе целых отделов и одно­временно позволяет видеть проект изнутри (т.е. связывать отдельные сегменты в одно целое и подгонять это целое под требования проекта). Таким образом, ком­пенсируются некоторые слабые стороны независимых команд и функционально­го подхода. Разделение ответственности между управляющим проектом и функциональным менеджером в матричной структуре Управляющий проектом Обсуждаемые вопросы Функциональный менеджер Что должно быть сделано? Кто выполнит задание? Как будет выполняться задание? Когда необходимо выполнить задание? Где? - Какой суммой можно оперировать для выполнения задания? Зачем? Как работа над проектом повлияет на обычную функциональную работу? Насколько хорошо сделан весь проект Удовлетворительно ли выполнено задание? Насколько хорошо был использован функциональный вклад? Матричная структура компании На практике различают несколько видов матричных систем в зависимости от способа и глубины разграничения полномочий проектных и функциональных менеджеров. Ниже в общих чертах представлены три вида матриц: 1. Слабая матрица – эта форма сходна с функциональным подходом, за исклю­чением того, что существует официально назначенный управляющий проек­том, ответственный за координацию проектных действий. Функциональ­ные управляющие отвечают за управление своим сегментом. Управляющий проектом в основном действует как помощник, который составляет гра­фики и контрольные списки, собирает информацию по состоянию работы и облегчает завершение проекта. Управляющий проектом имеет непрямые полномочия ускорять и контролировать проект. Функциональные управля­ющие принимают решения о том, кто какую работу будет выполнять, и оп­ределяют сроки ее выполнения. 2. Сбалансированная матрица – это классическая матрица, в которой управ­ляющий проектом отвечает за определение того, что нужно сделать, а функ­циональные управляющие – за то, как это будет сделано. Иными словами, управляющий проектом вырабатывает полный план проекта, интегрирует вклад различных отделов, составляет календарный план и руководит рабо­той. Функциональные управляющие отвечают за назначение специалистов и выполнение своего сегмента проекта согласно стандартам и календарно­му плану, указанным управляющим проектом. Слияние «что и как» требует тесного сотрудничества обеих сторон и совместного одобрения техниче­ских и эксплуатационных решений. 3. Сильная матрица – эта форма направлена на то, чтобы создавать «ощути­мое присутствие» проектной команды в пределах матричной окружающей среды. Управляющий проектом контролирует практически все аспекты проекта, включая компромиссные решения по объему проекта и назначе­ние функционального персонала; когда и что делают специалисты. Он имеет право на решающее слово в принятии решений. Функциональный управ­ляющий руководит специалистами из своего отдела и консультирует, когда это необходимо. В некоторых случаях отдел функционального начальника может играть роль «субподрядчика» для проекта, в этом случае его сотруд­ники больше контролируют специализированную работу по своему сегмен­ту проекта. Например, развитие новой серии ноутбуков может потребовать привлечения команды экспертов из различных областей к работе над дизай­ном и техническими параметрами. Как только спецификации определены, ответственность за окончательный дизайн и производство определенных компонентов (например, источника питания) может быть возложена на со­ответствующие функциональные группы. Матричное управление в целом и в его конкретных формах имеет уникальные сильные и слабые стороны. Прежде всего, следует отметить следующие преимуще­ства матричных структур. 1. Эффективность. Ресурсами можно коллективно пользоваться и на много­проектах, и в функциональных отделах. Работники могут распределять свою энергию по множественным проектам в том объеме, в каком это необходимо в каждом конкретном случае. Благодаря этому можно избежать «раздвоения», когда один специалист задействован в разных проектах, но объем работы превышает его возможности. Это характерно для проектной структуры. 2. Сильный упор на проекте. Упор на проекте обеспечивается через офи­циальное назначение управляющего проектом, ответственного за коор­динацию и интеграцию работы, выполняемой различными отделами. Это помогает сохранять целостный подход к решению проблемы, часто отсут­ствующий в функциональных организациях. 3. Более легкий постпроектный переход. Поскольку проектная организация накладывается на функциональную, специалисты проектных команд под­держивают отношения со своими функциональными группами, поэтому им есть куда вернуться после завершения работы над проектами. 4. Гибкость. Матричная структура дает возможность гибко использовать ре­сурсы и специалистов в рамках компании. В некоторых случаях функцио­нальные отделы могут выделить специалистов, которыми затем будет ру­ководить управляющий проектом. В других случаях руководителем может быть функциональный менеджер. Сильные стороны матричной структуры значительны. К сожалению, потенци­ально слабые стороны тоже серьезны. Во многом это происходит из-за того, что матричная структура более сложна и появление множества руководителей явля­ется радикальным отходом от традиционной структуры вертикальной иерархии. Кроме этого матричную структуру нельзя установить внезапно. Эксперты заявляют, что требуется 3-5 лет для возникновения и утверждения зрелой матричной системы. Поэтому проблемы, приведенные ниже, в основном могут быть отнесе­ны к этому периоду «становления» матричной системы: 1. Дисфункциональный конфликт. Матричный подход основан на прямых от­ношениях между функциональными менеджерами и управляющими проек­тами, которые привносят в проект компетентность и свое видение. Это рас­сматривается как необходимый механизм для достижения соответствующего баланса между сложными техническими вопросами и уникальными требова­ниями к проекту. При всем благородстве намерений эффект иногда аналоги­чен открыванию ящика Пандоры. Закономерный конфликт, являющийся ре­зультатом противоречий в интересах, графике работы и системе отчетности, может перейти на более личный уровень. Дискуссии могут превратиться в перепалки, лишь усугубляющие неприязнь вовлеченных в них менеджеров. 2. Борьба. Любая ситуация, в которой оборудование, ресурсы и люди востре­бованы как по проектной, так и по функциональной линии, чревата кон­фликтами и ожесточенной борьбой за обладание ограниченными ресурса­ми. Борьба может произойти и среди менеджеров проектов, которые, прежде всего, интересуются тем, что является лучшим для их проектов. 3. Стресс. Матричное управление нарушает управленческий принцип едино­началия. У работников проектов существуют по меньшей мере два руково­дителя – непосредственный функциональный управляющий и менеджер проекта (или несколько менеджеров, если проектов несколько). Работа в матричной окружающей среде может быть чрезвычайно стрессовой. Во­образите, каково работать, когда три разных менеджера дают вам три взаи­моисключающих задания. 4. Замедление. В теории присутствие управляющего проектом, коорди­нирующего работу, должно ускорять выполнение проекта. На деле приня­тие решений может завязнуть в вынужденных согласованиях между много­численными функциональными группами. Это особенно часто происходит в сбалансированной матрице. При рассмотрении трех вариантов матричной организации видно, что преимущества и недостатки не всегда могут быть отнесены ко всем трем разно­видностям. Сильная матрица, вероятнее всего, усилит проектную интеграцию, уменьшит внутреннюю борьбу за власть и в конечном счете улучшит контроль над проектными действиями и затратами. Вместе с тем может пострадать техни­ческое качество, так как функциональные специалисты меньше контролируют свой вклад. И, наконец, может возникать доминирование автономной команды, так как у членов проектной группы часто возникает чувство избранности в связи с принадлежностью именно к такой команде. Слабая матрица, вероятно, улучшит техническое качество, а также обеспечит лучшую систему улаживания противоречий между проектами, так как функцио­нальный управляющий занимается распределением персонала для работы над раз­ными проектами. Проблема состоит в том, что функциональный контроль часто осуществляется за счет недостаточной проектной интеграции. Сбалансированная матрица может улучшить баланс между техническими и проектными требовани­ями, но это очень тонкая система, ее трудно создать, ею трудно управлять, и она, очевидно, может не выдержать многих проблем, связанных с матричным подходом. Какую структуру управления проектом считать правильной? Все больше доказательств, добытых опытным путем, говорят в пользу того, что успех проекта напрямую связан с количеством автономности и полномочий, ко­торыми располагают менеджеры проектов в отношении этих проектов. Однако большая часть этих исследований основана на том, что лучше всего для управления конкретными проектами. Важно помнить: лучшая система уравновешивает потребности проекта с потребностями основной организации. Тогда какую структуру проекта должна задействовать организация? Это сложный вопрос, не имеющий точного ответа. Ряд вопросов дол­жен быть рассмотрен на уровне как организации, так и проекта. – С точки зрения организации. На уровне организации первый вопрос, на который следует дать ответ, – на­сколько важно руководство проектом для успеха фирмы? Если организация осуществляет очень небольшое количество проектов, тог­да, скорее всего, самое лучшее – менее официальная структура. Можно создать независимые проектные команды, в которых члены будут задействованы по мере необходимости их услуг, и поручить работу по проектам внешним подрядчикам (аутсорсинг). Второй ключевой вопрос – о наличии и распределении ресурсов. Помните, что матрица возникла из потребности коллективно использовать ресурсы на множе­ственных проектах и в различных функциональных областях и одновременно обе­спечивать должное руководство проектом. Для организаций, которые не могут позволить себе «привязать» необходимый персонал к отдельным проектам, подойдет матричная структура. В качестве альтернативы должна быть создана независимая команда, использующая внешние ресурсы проекта (аутсорсинг), когда внутренние ресурсы недоступны. Отвечая на первые два вопроса, организация должна оценить текущие мето­ды и определить, какие изменения необходимо произвести, чтобы более эффек­тивно управлять проектами – С точки зрения проекта На уровне рассмотрения проектов возникает вопрос, насколько автономным должен быть проект, чтобы его завершили успешно. Можно выделить семь факторов, которые оказывают влияние на выбор структуры руко­водства проектом: - размер проекта; - стратегическая важность; - новизна и потребность в инновациях; - потребность в интеграции; - сложность среды за пределами проекта (количество посредников/зон взаимодействия); - ограничения по бюджету и по времени; - стабильность потребностей в ресурсах. Чем выше уровень вышеназванных семи факторов, тем большими автономи­ей и полномочиями должны обладать проект-менеджер и проектная команда для успешного завершения проекта. То есть нужно использовать либо 1) независи­мую проектную команду, либо 2) матричную проектную структуру. Например, такие структуры должны использоваться для крупных проектов, которые явля­ются для компании новыми и критическими, требующими, таким образом, боль­ших новшеств. Названные структуры также необходимы для сложных проектов, требующих взаимодействия со многими отделами, а также для проектов, которые требуют постоянного контакта с клиентами, чтобы оценить ожидания последних. Независимые проектные команды также должны использоваться для выполнения срочных проектов, специфика работы над которыми предполагает, что персонал должен работать от начала и до конца проекта. Многие компании, вовлеченные в руководство проектом, создали гибкую систему управления, которая организовывает проекты согласно проектным требованиям. Например, проекты Chaparral Steel – производителя мини-заводов по производству стальных брусков и переработке металлолома – подразделяются на проекты про­грессивного развития, платформы и пошаговые. Проекты прогрессивного развития относятся к проектам большого риска, использующим при создании нового продук­та крупные достижения или процессы. Проекты-платформы – это проекты средне­го риска, которые модернизируют новые продукты и процессы. Пошаговые проек­ты – проекты с низким риском, краткосрочные; вносят незначительные изменения в существующие продукты и процессы. В любое время у Chaparral Steel могло быть 40-50 проектов в стадии реализации, из которых только один или два относились к категории прогрессивного развития, 3-5 – к платформам и остальные – к пошаго­вым. Почти все пошаговые проекты выполняются через слабую матрицу, в которой управляющий проектом координирует работу функциональных подгрупп. Сильная матрица используется для завершения проекта-платформы, в то время как независимые проектные команды, как правило, создаются для завершения прогрессивных проектов развития. Все больше компаний используют такой «смешанный» подход к управлению проектами. Лекция 4 Определение проекта В случае руководства несколькими малыми проектами или одним большим и сложным управляющему необходимо использовать строгий структурированный метод избирательного отбора информации на всех стадиях жизненного цикла проекта с целью удовлетворения потребностей всех заинтересованных сторон и для определения того, насколько выполнение проекта соответствует стратегическому плану организации. Такой метод, являясь своеобразной схемой проекта, называется методом разбивки работ (структурированием работ по этапам) и включает пять этапов. 1. Определение объема проекта. Основная цель здесь – дать как можно более четкое определение задач проекта с точки зрения конечного пользователя и планов проекта. Очевидно, что объем проекта – это краеугольный камень, к которому привяза­ны все элементы плана проекта. Чтобы убедиться, что составленный объем проекта является правильным, можно воспользоваться следующим контрольным перечнем: 1) Цель проекта. Первый этап в определении объема – определение основных целей для удовлетворения потребностей вашего клиента. Например, в ре­зультате глубокого анализа рынка компания, занимающаяся разработкой программного обеспечения, решает разработать программу, способную автоматически переводить с английского языка на русский. Проект должен быть закончен в течение трех лет при затратах, не превышающих 1,5 млн. долл. Другой пример: необходимо спроектировать и выпустить полностью портативную систему термической переработки вредных отходов за 13 месяцев при затратах, не превышающих 13 млн. долл. Цель проекта отвечает на вопросы, что, когда и сколько. 2) Задачи. Далее нужно определить задачи работы на протяжении всего жизненного цикла проекта. Так, например, задачей работы на ранней стадии разработки проекта может быть список спецификаций. На следующем этапе это могут быть кодирование программного обеспечения и техническое руководство. Затем – проверка опытных образцов. Заключительный этап обычно включает тестирование и одобрение программного обеспечения. 3) Контрольные точки. Контрольная точка – значительное событие в процессе работы над проектом, которое происходит в определенный момент времени. График контрольных точек отражает только основные сегменты работы; он показывает первую, приблизительную оценку затрат времени, стоимости и необходимых ресурсов для проекта. Этот график составляется с использованием задач работы как основы для определения основных сегментов работы и конечной даты. Например, испытания должны быть проведены и полностью закончены к 1 июля текущего года. Контрольные точки служат естественными и важными контрольными пунктами в проекте. Они должны быть понятными для всех участников проекта. 4) Технические требования. Обычно товар или услуга должны отвечать определенным техническим требованиям. Например, таким требованием к персональному компьютеру может быть способность работать от сети переменного тока в 120 вольт или от постоянного тока в 240 вольт без адаптеров. Другим известным примером является способность системы 911 определить местонахождение и номер телефона звонящего. 5) Ограничения и исключения. Следует четко определить границы объема проекта (работ по нему). Невыполнение этого требования приведет к пустым ожиданиям и трате ресурсов и времени. Примером такого ограничения является местная доставка грузов воздушным транспортом до места назначения к основному лагерю; обслуживание системы и ремонт будут выполнены только через месяц после заключительного осмотра; клиенту будет объявлено о необходимости дополнительного обучения, хотя это и не было включено в контракт. Далее определяют границы проекта, отмечая то, что не было включено. Еще одним примером служит сбор данных клиентом, а не подрядчиком; какой дом нужно будет построить, а не то, как он вписывается в пейзаж, или какие приборы, обеспечивающие охрану и безопасность, нужно установить; какое программное обеспечение будет установлено, а не какую подготовку дать персоналу. 6) Анализ совместно с клиентом. Контрольный перечень заканчивается пунктом касательно совместной с заказчиком проверки выполнения работы. Основной проблемой остается понимание и согласие заказчика с ожидаемыми результатами. Получает ли заказчик в виде задач то, что он хочет? Точно ли формулирует определение проекта ключевые достижения, сметы, сроки и требования к выполнению работ? Рассматриваются ли вопросы ограничений и исключений? Обсуждение всех этих вопросов крайне необ­ходимо во избежание недопонимания. 2. Выстраивание приоритетов по проекту Качество и окончательный успех проекта традиционно зависят от того, насколько удовлетворены или превзойдены ожидания заказчика или высшего руководства по отношению к стоимости (смете), времени (графику) и результатам (объему) проекта. Взаимоотношения между этими критериями варьируются в зависимости от ситуации. Одна из основных задач проект-менеджера – управление соотношением между временем, стоимостью и результатами. Чтобы этого добиться, менеджеры долж­ны определять и понимать природу приоритетов проекта, уметь беспристрастно обсуждать все приоритеты с заказчиком проекта и с высшим руководством для установления относительной важности каждого критерия. Достигается это путем построения матрицы проекта, определяющей: какого из критериев нужно при­держиваться любой ценой, какой усилить, а каким можно в крайнем случае пренебречь. Матрица приоритетов проекта - Соблюдать обязательно. Первоначальные параметры установлены. Проект должен уложиться в сроки, в смету и соответствовать спецификациям и масштабу. - Усилить (оптимизировать). Какой критерий должен быть оптимизирован при определении масштаба проекта? Применительно ко времени и стоимости опти­мизация обычно означает использование в своих интересах возможностей либо для сокращения затрат, либо для сокращения времени работ. И наоборот, приме­нительно к результативности улучшение обычно означает добавление чего-то ценного к проекту. - Можно пренебречь. Каким из критериев можно пренебречь? Когда нужно из­менить соотношения, можно ли позволить отклониться от графика, уменьшить масштаб, или «ужать» выполнение проекта, или превысить смету? 3. Разбивка работ по этапам Как только объем и задачи проекта определены, работу над проектом можно разделить на более мелкие элементы. Этот процесс называют разбивкой работ по этапам (WBS – work breakdown structure). WBS – это карта проекта. Использование WBS помогает управляющему проектом удостовериться, что все продукты и рабочие элементы обозначены, интегрировать проект с организацией-учредителем (проекта) и установить отправную точку для контроля. В основном WBS – это схема проекта с различными уровнями детализации. WBS начинается с того, что проект в целом рассматривается как конечный результат. Сначала выделяют основные задачи работы над проектом, затем определяют «подзадачи», чтобы прийти к основным запланированным задачам. Процесс повторяют до тех пор, пока не выделяют самый маленький, поддающийся управлению уровень работы, за который будет отвечать только один человек. Эта подзадача потом делится на наборы работ. Так как самая маленькая подзадача обычно включает несколько наборов работ, последние группируются по типу (например, «железо», «софт», тестирование). Эти группы в пределах подзадачи называют счетами по учету расходов. Такая разбивка на группы облегчает мониторинг продвижения проекта с точки зрения выполненных работ, затрат и ответственности. Иерархическая разбивка WBS Набор работ – основная единица, ис­пользуемая в планировании, составлении графиков и контроле над проектом. Каждый набор работ в WBS: 1. Определяет, какая работа будет выполняться (что?); 2. Указывает время выполнения набора работ (как долго?); 3. Определяет смету с учетом времени на выполнение набора работ (затраты); 4. Определяет ресурсы, необходимые для выполнения набора работ (сколько?); 5. Назначает определенного человека, ответственного за выполнение набор работ (кто?); 6. Определяет контрольные пункты для измерения хода выполнения (насколько хорошо?). Схема разбивки работ (WBS) 4. Интегрирование WBS с организационной структурой компании WBS используется для связи подразделений компании, ответственных за про­ведение работ. На практике результатом этого процесса является схема разбивки компании (OBS – organization breakdown structure). OBS показывает, как организована фирма с точки зрения рас­пределения ответственности. Цели OBS – обеспечение основы для оценки выпол­нения работ подразделениями, определение отделов, отвечающих за выполнение работ, и привязка подразделений к конкретным издержкам в виде счетов по учету затрат. OBS связывает задачи с организацией в виде иерархической схемы, в кото­рой на каждом следующем уровне идут все более мелкие структурные подразде­ления. Часто используется традиционная структура организации. Даже если продукт полностью выполняет одна команда, необходимо структурировать команду по степени ответственности за смету, время и качество. 5. Кодирование WBS Извлечение максимальной пользы из разбивки работ зависит от системы кодирования (обозначения). Коды используют для определения уровней и элементов в WBS, организационных элементов (отделов), наборов работ, информации о бюджете и расходах. Коды позволяют консолидировать отчеты на любом уровне структуры. Наиболее часто используется схема числового обозначения. Интегрирование WBS и OBS Матрицы ответственности Во многих случаях размер и возможности проекта не гарантируют примени­мость сложных WBS или OBS. Но есть инструмент, который широко используется проект-менеджерами и лидерами целевых групп небольших проектов, – матрица ответственности (RM – responsibility matrix). Матрица (иногда ее еще называют линейной диаграм­мой ответственности) суммирует цели, которые будут достигнуты, и определяет, кто и за что отвечает при выполнении проекта. В самом простом виде матри­ца имеет форму диаграммы или таблицы, включающей весь проект, предприни­маемые действия и ответственных за каждое действие. Матрица ответственности для проекта по исследованию рынка В вышеобозначенной матрице R обозначает лицо, отвечающее за координацию действий других членов команды, занятых реше­нием задачи, и проверяющее выполнение задачи (т.е. что задание выполнено). S обозначает лицо, оказывающее поддержку и/или помощь. Такая простая матрица полезна для того, чтобы организовывать и распределять обязанности не только для маленьких проектов, но и для больших, более слож­ных проектов. Более сложная RM не только определяет индивидуальные обязанности, но и разъясняет критические посреднические функции между отделами и работника­ми, которые требуют координации. Матрица ответственности для проекта конвейера В матрице более сложного проекта по разработке нового автоматизированно­го оборудования для каждой ячейки используется числовая схема кодирования, чтобы определить характер вовлечения в решение определенной за­дачи. Такая матрица обеспечивает ясный и краткий метод опре­деления ответственности, полномочий и каналов связи. Матрица ответственности дает возможность всем участникам проекта разо­браться со своими обязанностями и урегулировать рамки этих обязанностей. Она также помогает определить степень или тип полномочий, осуществляемых каждым сотрудником в процессе деятельности, в которой участвуют две сторо­ны или более. Используя матрицу ответственности и определяя полномочия, ответственность и коммуникацию в пределах ее структуры, можно легко уста­новить связь между различными организационными единицами и содержанием Коммуникационный план проекта Как только задачи и работа по проекту четко определены, необходимо создать внутренний коммуникационный план или план обмена информацией по проекту. Коммуникационный план обычно составляется менеджером проекта и/или командой проекта на ранней стадии его планирования. Нормальная коммуникация между всеми участниками – ключевой фактор координации и отслеживания графиков выполнения, определения проблемных об­ластей и необходимых действий. План отображает схему передачи информации различным участниками и становится неотъемлемой частью общего плана проекта. Цель коммуникационного плана проекта – ответить на вопросы, кто и когда должен передавать информацию участникам проекта, каким способом и какого рода должна быть данная информация, с тем чтобы можно было отслеживать графики, проблемы и действия. Коммуникационные планы проекта направлены на следующие основные во­просы: - какая информация должна быть собрана и когда; - кто получит эту информацию; - какие методы будут использоваться для сбора и хранения информации; - каковы ограничения, если таковые имеются, и кто будет иметь доступ к опреде­ленным видам информации; - когда информацию необходимо передать; - каким образом будет передаваться информация. Развитие коммуникационного плана, позволяющего ответить на все вышепри­веденные вопросы, обычно требует следующих основных шагов: 1. Анализ участников проекта. Выявите целевые группы. Типичные группы: заказчик, спонсор, команда проекта, отдел по управлению проектами (ОУП) и все, кому необходима инфор­мация по проекту для принятия решений и/или вклада в продвижение про­екта к цели. 2. Потребности в информации. Какого рода информация необходима для групп участников, которые вносят вклад в успех проекта? Например, то, как продвигается проект, возникают ли в ходе выполнения критические пробле­мы и насколько будут реализованы цели проекта, – все это очень интересует высшее руководство. Эта информация необходима, чтобы они могли при­нять стратегическое решение и управлять портфелем проектов. Члены ко­манды проекта должны видеть графики, списки задач, спецификации и т.п., чтобы знать, что необходимо делать в следующую очередь. Внешние группы должны быть осведомлены обо всех изменениях в графике и техни­ческих требованиях к компонентам, которые они поставляют для проекта. Наиболее часто встречаются в коммуникационных пла­нах следующие информационные потребности: отчеты по состоянию проекта, изменения в объеме, решения в ключевых точках, действия, задачи, собрания команд для обсуждения состояния проекта, принятые просьбы по изменениям, отчеты по основным вехам или контрольным точкам. 3. Источники информации. Когда информационные потребности определены, следующий шаг – определить источники информации. То есть, где эта информация содержится? Как ее можно собрать? Например, информация по отчету по основным контрольным точкам, собраниям команды и собраниям для обсуждения состояния проекта содержится в протоколах и отчетах различных групп. 4. Режимы распространения. В сегодняшнем мире традиционные собрания по состоянию проекта проводятся с помощью электронной почты, теле­конференций, программ Lotus Notes, SharePoint и самых разнообразных программ по обмену данными и циркулирования информации. В част­ности, многие компании используют мировую паутину, чтобы создать виртуальный ОУП для хранения информации по проекту. Программное обеспечение по управлению проектом напрямую «складирует» всю ин­формацию на сайте, чтобы различные участники могли в любой момент получить к ней доступ и узнать то, что их интересует. В некоторых случаях соответствующая информация перенаправляется автоматически участни­кам проекта. Дублирующий вариант в бумажной копии для конкретных участников по-прежнему необходим для многих изменений и действий по проекту. 5. Ответственность и сроки. Определитесь, кто высылает информацию. На­пример, общая методика – назначать секретарей для заседаний, которые пе­редают протоколы или особую информацию соответствующим участникам. В некоторых случаях ответственность за это ложится на менеджера проекта или ОУП. Сроки и частота распределения информации должны устанавли­ваться в соответствии со спецификой передаваемой информации. Преимущество создания коммуникационного плана в том, что, вместо того, чтобы отвечать на бесчисленные запросы выслать информацию, вы контролируе­те поток информации. Это уменьшает количество неприятных моментов, когда процесс работы нарушается в общем-то неожиданным вмешательством, и по ука­занным выше причинам менеджеры проекта могут работать более автономно. По­чему? Отчитываясь регулярно о том, как идут дела и что происходит, вы даете воз­можность высшему начальству почувствовать себе более спокойно, им не нужно думать о том, что придется вмешиваться в работу команды проекта. Коммуникационный план по проекту исследований будущего месторождения нефти Лекция 5 Оценка временных и денежных затрат по проекту Учитывая срочность и безотлагательность начала работы над проектом, проект-менеджеры иногда сводят до минимума или совсем не подсчитывают временные и денежные затраты на проект. Такой подход к работе – огромная и дорогостоящая ошибка. Существуют следующие важные причины для дополнительных усилий и расходов на процесс оценки: - оценки необходимы, чтобы поддержать хорошие решения; - оценки необходимы, чтобы хронометрировать работу; - оценки необходимы, чтобы определить, как долго будет осуществляться проект, и его стоимость; - оценки необходимы, чтобы определить, стоит ли осуществлять проект; - оценки необходимы, чтобы учесть потребность в наличных средствах; - оценки необходимы, чтобы определить, насколько хорошо продвигается проект; - оценки необходимы, чтобы определить бюджеты по временным этапам и разработать бюджет проекта. Оценка – процесс прогноза или приблизительного подсчета времени и стоимости выполнения задач проекта. На практике процессы оценки часто делятся на нисходящие (макро) и восходящие (микро). Нисходящая оценка обычно производится высшим руководством; как правило, используется метод аналогий, метод консенсус-прогноза группы (т.е. когда все мнения рассматриваются одновременно и на их основе вырабатывается «усредненный» показатель) или на основе математических формул. Восходящая оценка, как правило, базируется на оценках непосредственных исполнителей работ. При этом они отталкиваются от WBS, оценивая каждый элемент разбивки работ. Все заинтересованные в проекте лица (так называемые стейкхолдеры) предпочи­тают точную оценку стоимости и времени, но они также понимают, что отсутствие яс­ности – отличительная черта любого проекта. Неточные оценки ведут к ложным ожи­даниям и неудовлетворенности заказчика. Точности можно добиться ценой больших затрат (денежных и временных), но стоит ли оно того? Одним словом, оценка проекта становится удачно найденным компромиссом между выгодами точной оценки и затратами на эту более точную оценку. Оценка стоимости, времени и бюджета – главные пути контроля; они служат стандартом для сравнения реальных и плановых затрат по ходу выполнения проекта. Подготовка отчета о состоянии зависит от надежных оценок, которые являются главным критериями при определении отклонений и осуществлении корректирующих дей­ствий. Факторы, влияющие на качество оценок 1. Планирование горизонта Качество оценки зависит от горизонта планирования; оценки текущих событий близки к 100%, а для отдаленных событий они не столь точны. Точность оценки времени и затрат будет повышаться, по мере того как вы двигаетесь от концепту­альной стадии к индивидуальным наборам работ. 2. Продолжительность проекта Время осуществления нового проекта имеет тенденцию к увеличению в нели­нейной зависимости. Иногда плохо сформулированный документ об объеме про­екта приводит к ошибкам в оценке времени и затрат. Долговременные проекты увеличивают неясность в оценках. 3. Персонал Фактор персонала также может приводить к ошибкам в оценке времени и за­трат. Например, точность оценок зависит от навыков людей, их осуществляющих. Компетентность в выполнении задачи будет влиять на производительность и время обучения (со следующей задачей такого же типа работник справится быстрее). Работали ли сотрудники на подобных про­ектах раньше в составе одной проектной команды, также будет иметь значение влиять на время, которое потребуется, чтобы соединиться в эффективную команду. Иногда смена персонала также может влиять на оценку. Необходимо отметить, что ввод новых людей в проект увеличивает время взаимодействия. Как правило, люди имеют только пять-шесть производительных часов в течение рабочего дня; другие часы тратятся на «второстепенную» работу, например, встречи, оформление документов, ответы на электронную почту. 4. Структура проекта и организация Оценки времени и затрат зависят от того, какая структура проекта будет выбрана. Одно из главных преимуществ независимой проектной команды, как уже отмечалось, – скорость при решении задач. Эта скорость достигается не бесценно – это дополнительные затраты при объединении персонала в одной команде на полный рабочий день (они не выполняют других обязанностей). И наоборот, проекты, осуществляемые в матричной среде, могут уменьшить затраты путем ее «производительного» распределения персонала по различным проектам, но работа займет больше времени – трудно сосредоточиться на всех проектах од­новременно, да и требования к координации намного выше. 5. Завышение оценок с целью создания «подушки безопасности» В некоторых случаях люди склонны умышленно завышать оценки. В процессе работы, где от вас требуется назвать время и оценить затраты, большинство берут время с небольшим запасом (же­лая обезопасить себя), чтобы уменьшить риск задержки. Если так будет поступать каждый на всех уровнях проекта, то продолжительность и стоимость проекта окажутся серьезно завышенными. Этот факт побуждает некоторых управляющих проектами или заказчиков настаивать на 10-15%-ном сокращении времени и/или стоимости выполнения проекта. Конечно, в следующий раз при такой «игре» оценщик увеличит стоимость и/или время на 20% или более. Такое положение ве­щей, как правило, мешает реальным оценкам конкурентоспособности проекта. 6. Культура организации Культура организации может серьезно влиять на проектные оценки. В одних организациях завышенные оценки допускаются и даже неофициально поощря­ются. Другие организации назначают премии за точность оценки и настойчиво борются с ошибками в определении стоимости или времени выполнения проекта. Организации различаются по степени важности, которую они придают оценке. Какие-то организации считают, что детальная оценка занимает слишком много времени и не стоит тратить усилия, если невозможно точно предсказать будущее. В других организациях полагают, что точные оценки являются основой эффек­тивного руководства проектом. Культура организации формирует каждый аспект управления проектами, и оценка – не исключение. 7. Другие факторы И, наконец, есть факторы за пределами проекта, которые могут воздейство­вать на оценку времени, например время простоя оборудования. Национальные праздники, каникулы, юридические препоны могут влиять на проектные оценки. Приоритетный уровень проекта может влиять на выделение ресурса и, как след­ствие, – на время и стоимость. Оценка проекта – сложный процесс. Если все эти факторы учитывать в про­цессе оценки, ее качество можно повысить. В совокупности оценки времени и стоимости дают возможность управляющему проектом хронометрировать бюджет, без чего невозможно контролировать проект. Выработка основных критериев для подсчета времени, затрат и необходимых ресурсов Управляющие проектами признают, что оценки времени, стоимости и необ­ходимых ресурсов должны быть точны, без них невозможны эффективное планирование, управление и контроль над проектом. Существуют убедительные до­казательства того, что неточные и неполные оценки неминуемо ведут к неудачам. Поэтому должно быть сделано все, для того чтобы начальные оценки были максимально точны, иначе придется от них отказаться вообще и действовать наудачу, а такой подход неприемлем для серьезных управляющих проектами. Даже если данный проект никогда прежде не выполнялся, проект-менеджер может следовать семи руководящим принципам, которые будут полезны при оценке наборов работ. 1. Ответственность. На уровне набора работ оценки должны быть выполнены человеком (людьми), лучше других понимающими задачу. Привлекайте их! За исключением очень сложных технических задач, ответственными за сделанную по графику и в пределах бюджета работу обычно являются наблю­датели первого эшелона либо технические специалисты, которые знакомы с данным видом работ. Эти люди определяют продолжительность выполне­ния задачи, исходя из собственного опыта и обоснованных заключений, им не свойственно принимать на веру оценки «сверху». Вторая выгода от при­влечения таких ответственных сотрудников в том, что они, по идее, долж­ны проследить, чтобы наборы работ укладывались в отмеренное им время. Если не проводить консультации с такими сотрудниками и не полагаться на их мнение, то будет трудно винить их за несоблюдение выделенного вре­мени. Наконец, привлечение в качестве экспертов членов команды, ответ­ственных за выполнение проекта, позволяет как можно раньше установить каналы связи. 2. Пусть оценку выполнят нескольких человек. Известно, что оценка за­трат или времени бывает разумной и реалистичной, когда привлекаются несколько человек, обладающих опытом и/или знанием задачи. Как прави­ло, работники при обсуждении задач основываются на своем опыте, и за­частую их оценки отличны друг от друга. Но при анализе индивидуальных различий можно выработать консенсус-решение и исключить наиболее ра­дикальные суждения. Этот подход подобен методу Delphi, который также может быть использован при проведении оценки. 3. Нормальные условия. Процесс определения времени, денежных затрат и ресурсов для конкретной задачи строится на определенных допущениях. Оценки должны базироваться на нормальных условиях, эффективных ме­тодах и нормальном объеме ресурсов. Нормальные условия иногда трудно определить, но в организации необходимо прийти к консенсусу относи­тельно того, какие условия являются нормальными для данного проекта. Если нормальный рабочий день – восемь часов, оценка времени должна исходить из восьмичасового рабочего дня. Точно так же, если нормальный рабочий день состоит из двух смен, оценка времени должна базироваться на двухсменном рабочем дне. Любая оценка времени должна отражать эффективные методы разработки доступных ресурсов. Оценка времени должна отражать нормальный уровень человеческих ресурсов или оборудования. Например, если на данный момент доступны только три программиста для кодирования или двое дорожных рабочих для дорожного строительства, оценка времени и стоимости должна базироваться на этих двух нормальных уровнях ресурсов, если не ожидается, что в ходе осуществления проекта будут изменены условия, которые в настоящее время рассматриваются как нормальные. Следует добавить, что на данном эта­пе возможные конфликты спроса на одни и те же ресурсы, используемые в параллельных операциях, не рассматриваются. 4. Единицы времени. Используемые единицы времени должны быть выбраны на ранней стадии построения проектной сетевой модели. Все оценки вре­мени и задач нужно производить в одних и тех же единицах. Оценки времени должны быть рассмотрены в соответствии с тем, представлено ли нор­мальное время календарными днями, рабочими днями, рабочими неделями, человеко-днями, единичным изменением, часами, минутами и т.д. 5. Независимость. Оценщики должны рассматривать каждую задачу как независимую от других задач, которые могут быть объединены в WBS. Исполь­зование менеджеров низшего звена обычно обеспечивает эту независимость, и такой подход – правильный. Высшее руководство, наоборот, склонно агре­гировать много заданий в общую оценку времени, а потом «додумывать», сколько времени каждое задание «вкладывает» в это суммарное время. Если задания должны выполняться последовательно и одним и тем же отделом (группой), лучше не требовать сразу определить все время на задания из этой цепочки. Причина – плановики не преминут подогнать время конкретных за­даний под это, в некотором роде, взятое «с потолка» суммарное время. Этим способом невозможно устранить неясности касательно отдельных операций, и итогом будет оптимистичная оценка времени. Короче говоря, необходимо каждую оценку времени и задач рассматривать независимо от других дей­ствий. 6. Непредвиденные обстоятельства. Оценка набора работ не должна вклю­чать поправки на непредвиденные обстоятельства. Оценка должна со­держать нормальные или средние условия, даже если каждый набор работ может не осуществляться, как было запланировано. По этой причине топ-менеджмент должен создавать дополнительный фонд на случай непредви­денных обстоятельств. 7. Добавление оценки риска к рассмотренным выше оценкам позволит избежать неприятных сюрпризов заинтересованным в проекте лицам. Очевидно, что одни задачи требуют больше времени и больше подвержены рискам, чем другие. Например, новая технология обычно более подвержена риску превышения затрат и сроков, чем давно начавшийся процесс. Про­стая идентификация степени риска позволяет заинтересованным в проекте лицам принимать во внимание альтернативные методы и изменять ход про­цесса. Методы оценки времени и затрат по проекту 1. Макроподходы для оценки времени и затрат по проекту На стратегическом уровне используется макрометод оценки проектного предложения. Иногда на начальной стадии отсутствует большая часть информации, так что взять точную оценку времени и затрат просто неоткуда, например, когда еще не доведен до конца сам замысел. В этих ситуациях используются макрооцен­ки, пока задачи в WBS ясно не определены. а) консенсус-метод При этом методе зачастую используется объединенный опыт менеджеров среднего или высшего звена, которые и будут подсчитывать суммарную продол­жительность проекта и затраты на него. Это выливается в заседание, на котором эксперты обсуждают, спорят и в конечном счете приходят к единому мнению по оценке предположения. Фирмы для выполнения макрооценки используют ме­тод Delphi. Важно признать, что эти первые макрооценки являются грубыми и, как пра­вило, происходят на «концептуальной» стадии проекта. Нисходящие оценки по­лезны для развития плана в целом, так как на данном этапе собрано незначи­тельное количество информации. На этой стадии еще не определено, какие работы будут проводиться. В ряде случаев нисходящие оценки нереалистичны, потому что руководство высшего звена «просто хочет, чтобы проект был». Одна­ко начальные нисходящие оценки полезны в определении того, требует ли про­ект более формального планирования, которое включило бы более детальные оценки. Следите, чтобы макрооценки, сделанные высшим руководством, не на­вязывались проект-менеджерам низшего уровня, которые, будучи подчиненны­ми, могут посчитать обязательным принять их, даже если знают, что ресурсов недостаточно. б) метод коэффициента Макрометоды (иногда называемые параметрическими) обычно основаны на коэффициенте, т.е. на множителе. Макроподходы часто применяются на кон­цептуальной или «определяющей потребности» стадии, чтобы получить началь­ную продолжительность и оценку стоимости для проекта (например, оценка затрат на строитель­ство нового завода по его мощности). в) распределительный метод Распределение затрат на проект на основе WBS Представляет собой видоизмененный вариант метода коэффициента. Пропорциональное распределение используется, когда параметры проектов близки к параметрам предыдущих проектов, особенно по затратам. Учитывая предыдущий опыт, оценки можно сделать быстро, без особых усилий и с достаточной точностью. Распределительный метод обычно используется для проектов, которые являются в целом стандартными, но имеют небольшие различия или близкие параметры. г) кривые обучения Некоторые проекты требуют, чтобы та же самая задача, группа задач или про­дуктов были повторены несколько раз. Менеджеры заранее знают, что время вы­полнения задачи уменьшается с числом повторений. Это утверждение особенно верно в отношении трудоемких задач. В данных обстоятельствах может использо­ваться модель усовершенствования для предсказания сокращения времени, необ­ходимого для выполнения задачи. На основании эмпирического свидетельства всех отраслей промышленности модель или шаблон данного усовершенствования был количественно определен в кривой обучения (также известной как кривая усовершенствования, кривая испытания или кривая индустриального прогресса), которую можно представить в виде следующей взаимосвязи: каждый раз, когда количество продукции удваивается, количество затраченного труда в единицах рабочих часов уменьшается в определенной зависимости. На практике коэффициент усовершенствования может варьироваться от 60% (очень высокая степень усовершенствования) до 100% (никакого усовершен­ствования вообще). Поскольку трудность работы уменьшается, ожидаемое усовершенствование также уменьшается и коэффициент усовершенствования, который используется, становится больше. Необходимо учитывать один суще­ственный фактор – пропорцию рабочей силы в задаче. Очевидно, высокая степень усовершенствования может иметь место только в действиях с высоким содержа­нием труда. Главное неудобство оценки на основе макроподхода – то, что время и затраты для выполнения определенной задачи не подсчитываются. Объединение многих задач в общей корзине способствует появлению ошибок при подсчете времени и затрат. Микрооценки обычно более точны, чем макрооценки. 2. Микроподходы для оценки времени и затрат по проекту а) метод шаблона Если проект похож на предыдущие, то затраты по прошлым проектам могут стать отправной точкой для нового проекта. Нужно учесть отличия нового проек­та и откорректировать старые цифры соответственно этим отличиям. Например, фирма по ремонту кораблей в сухих доках имеет набор стандартных проектов ре­монта (шаблоны для электрического и механического переоборудования и т.д.), которые используются как отправные точки, для того чтобы рассчитать стоимость и сроки выполнения любого нового проекта. Для стандартных проектов отличиями считаются сроки, затраты и ресурсы, и соответственно им в стандартный проект вносят изменения. Такой подход позволяет фирме за короткий промежуток времени разработать потенциальный график работ, рассчитать затраты и соста­вить смету. Наличие таких шаблонов в базе данных поможет быстро уменьшить ошибки при расчетах. б) параметрические прикладные процедуры для конкретных задач Подобно тому, как параметрические методы могут использоваться для проведения макрооценок, тот же прием может быть применен и к конкретным задачам. Например, при переустановке пакета программ MS Office 2000 необходимо переоборудовать 36 различных компьютерных рабочих мест. Основываясь на прошлых конверсионных проектах, управляющий проектом посчитал, что в среднем один человек может преобразовать три автоматизированных рабочих места за день. Поэтому для выполнения задачи переустановки программного обеспечения на этих 36 персональных компьютерах потребовалось бы три техника и четыре дня: (36/3)/3. в) оценка диапазона, или значения в интервале «от сих до сих» - когда вы используете оценку диапазона? Этот метод лучше всего работает, когда по пакету работ нельзя судить о времени, расходах или других параметрах. Если набор работ самый обычный и в нем все определенно и понятно, обычно самым лучшим подходом будет привлечение человека, который лучше других знаком с набором работ. На основании собственного опыта или зна­ния источников, из которых можно почерпнуть необходимую информацию, такой человек сможет оценить сроки выполнения работ и расходы. Однако, если ввиду большой неопределенности по набору работ крайне сложно рассчи­тать сроки и расходы, благоразумным решением будет представить три уровня оценки – низкий, средний и высокий (подход заимствован из методологии PERT, использующей распределение вероятности). Имея низкий и высокий уровни, можно получить диапазон средних значений. Определение низкого и высокого уровней в отношении деятельности зависит от таких факторов, как сложность, технологичность, новизна и уровень предыдущего знакомства с данной деятельностью. - как вы получаете такие оценки? Поскольку оценка в виде диапазона лучше всего срабатывает там, где набор работ сильно озадачивает, для определения низкого, среднего и высокого значений расходов или сроков лучше всего пользоваться групповой оценкой. Оценка группой в основном позволяет избавиться от заведомо неправильных оценок с помощью нескольких суждений по срокам, времени и потенциальному риску. Суждения других сотрудников в группе по­зволяет снизить степень риска, сопутствующего оценке сроков и затрат. Вовлекая других в оценочную деятельность, вы делаете оценку правдоподобной. 3. Гибрид: оценка по стадиям Этот подход начинается с макрооценки проекта, после чего по мере реализации проекта выполняются оценки по стадиям. Некоторые проекты по своему характеру не могут быть строго определены из-за присущей им неопределенности или отсут­ствия четких представлений о конечном продукте. Хотя и редко, но такие проекты встречаются. К ним относятся космические проекты, IT-проекты, технологические проекты, строительные проекты, где проект объекта разработан не полностью. В этих проектах часто используется метод оценки по стадиям или циклу жизни проекта. Оценка по стадиям используется, когда слишком много неопределенности по проекту и непрактично оценивать время и затраты для полного проекта. На протяжении выполнения проекта используется система с двумя оценками. Де­тальная оценка разрабатывается для текущей стадии, а макрооценка выполняется для оставшихся стадий проекта. Оценка по стадиям на протяжении жизненного цикла проекта Например, когда определены потребности проекта, делают оценку затрат и про­должительности проекта, чтобы можно было приступить к анализу и принятию решений. Одновременно осуществляется детальная оценка, чтобы получить про­ектные спецификации, и макрооценка для оставшейся части проекта. По мере ре­ализации проекта, когда спецификации принимают более-менее реальные очерта­ния, можно сделать детальную оценку для стадии разработки и макрооценку для оставшейся части проекта. Ясно, что с продвижением жизненного цикла проекта надежность оценок должна улучшаться. Указанному методу отдают предпочтение те, кто работает с проектами, в кото­рых конечный продукт неизвестен, а неопределенность велика, например, в интег­рации беспроводных телефонов и компьютеров. Стоимость и график нужны только на следующей стадии проекта, и необходимо исключить нереалистичные графики и стоимость, базирующуюся на некорректной информации. Этот про­грессивный макро-/микрометод обеспечивает более обоснованную оценку сроков и стоимости для управления продвижением на следующей стадии. Различия между макро- и микрооценкой Корректировка оценок Детальные оценки наборов работ объединяются вместе и суммируются по задачам, для того чтобы оценить суммарные затраты на проект. Точно так же оценка продолжительности введена в проектную сеть, чтобы составить проектный график и определить полную продолжительность проекта. Опыт подсказывает, что для многих проектов суммарные оценки не осуществляются и фактические затраты и продолжительность неко­торых проектов значительно превышают первоначальные оценки в этом плане на основе набора работ. Чтобы нивелировать проблему «недооценки», т.е. ситуацию, когда реальные сроки и стоимость превышают сделанные оценки, некоторые менеджеры проектов регулируют общую стоимость мультипликатором (например, умножают суммарные прогнозируемые затраты на коэффициент 1,2). Практика «корректировки» первоначальных оценок с помощью коэффициента 20 или даже 100% вызывает законный вопрос: как после огромных усилий, потраченных на детальные оценки, их значения оказываются настолько выше? Для этого есть ряд причин, в т.ч. большинство из которых связаны с процессом оценки. 1. Затраты взаимодействия скрыты в оценках. Согласно руководящим принципам каждая оценка задачи, как предполагается, будет сделана неза­висимо от других. Однако задачи редко выполняются в изолированном пространстве. Работа над одной задачей зависит от предшествующих задач, и связь между задачами так или иначе вносит коррективы в оценки. На­пример, специалисты, работающие с опытным образцом, должны взаимо­действовать с инженерами-разработчиками после того, как разработка за­вершена, задавая вопросы или внося изменения в первоначальный чертеж. Точно так же время, необходимое для координации действий, как правило, не отражается в независимых оценках. Координация проявляется на встре­чах и брифингах, а также в виде времени, используемого для ликвидации разрыва между задачами. Время, а следовательно, стоимость, связанная с управлением взаимодействием как людей, так и различных факторов, уве­личивают затраты на проект. 2. Нормальные условия не применяются. Оценки, как предполагается, базируются на нормальных условиях. Это является хорошей отправной точкой, но редко наблюдается в реальной жизни. Это особенно верно, когда дело касается наличия ресурсов. Нехватка ресурсов – людей, оборудования или материалов – расширяет первоначальные оценки. Например, при нормальных условиях четыре бульдозера используются, чтобы очистить некоторый участок за пять дней, но при наличии только трех бульдозеров продолжительность задачи увеличится на восемь дней. Решение обратиться к внешним исполнителям (аутсорсинг) некоторых задач может увеличить затраты и продлить выполнение – потребуется время на адаптацию подряд­чиков под специфику работы и культуру компании. 3. На проектах все всегда идет не так, как ожидали. Недостатки проекта вы­являются из-за чрезвычайных погодных условий, несчастных случаев и т.д. Хотя вы не должны планировать эти риски при оценке конкретной задачи, но вероятность и воздействие таких событий нужно учитывать. 4. Изменения в объеме проекта и планах. По мере реализации проекта менеджер лучше понимает, что должно быть сделано, чтобы завершить проект. Это может вести к большим изменениям в проектных планах и затратах. Аналогично, если проект коммерческий, часто вносятся изменения, чтобы удовлетворить новые требования клиента. Постоянное изменение объема проекта – главный источник роста расходов. И хотя каждое усилие должно быть направлено на то, чтобы оставит объем про­екта неизменным любой ценой, сделать это в нашем быстро изменяющем­ся мире все труднее. На самом деле бывает так, что для многих проектов сделать точные оценки не всегда возможно, как и предсказать будущее. Без твердых оценок доверие к проектному плану падает. Крайние сроки становятся бессмысленными, бюджеты – слишком эластичными, а ответственности никто на себя брать не желает. Даже при максимально правильном методе оценок может возникнуть необхо­димость в их пересмотре исходя из свежей информации, и желательно, чтобы это произошло до того, как будут утверждены основной график и бюджет. Эффективные компании вносят коррективы в оценки определенных задач, ког­да риски, ресурсы и особенности по ситуациям становятся более ясными. Они признают, что суммарные оценки, производные от детальных оценок после раз­бивки работ, – только отправная точка. Просчитывая на несколько шагов вперед процесс планирования, они вносят соответствующие изменения в сроки и стои­мость конкретных операций, умножая окончательные оценки на коэффициент. Тем самым получают новый бюджет и сроки. Например, когда они понимают, что доступны только три бульдозера вместо четырех, чтобы очистить участок, то ре­гулируются и затраты, и сроки по операции. Чтобы смягчить потенциальные ри­ски по проекту, корректируют оценки. Например, чтобы уменьшить возможно­сти ошибок кодирования разработки, добавляют к графику и бюджету затраты на независимых экспертов. Наконец, организация вносит коррективы в оценки, чтобы учесть отклонения от нормальных условий. Например, если образцы по­чвы показывают чрезмерную заболоченность земли, при оценке времени и затрат делают поправки на строительство фундамента. Ошибки, существенные упущения и поправки, которые потребуют дополнитель­ных изменений в оценках, будут всегда. К счастью, в каждый проект должна быть включена система управления изменениями, чтобы справиться с такими ситуациями и с любым воздействием на основной план проекта. Создание базы данных для совершенствования оценок Лучший способ совершенствовать оценки состоит в том, чтобы собирать и архивировать оценки и реальные цифры по прошлым проектам. Создание такой базы данных – лучшая практика среди ведущих организаций руководства проектом. Некоторые организации, например, такие как Boeing, Kodak, IBM, имеют большие отделы профессиональных оценщиков, которые затратили много времени и денег для создания базы данных. Другие собирают эти данные через проектный офис. База данных позволяет проектному оценщику выбрать опре­деленный пункт из набора работ для включения его в проект. Оценщик осущест­вляет любые необходимые изменения, касающиеся материалов, рабочей силы и оборудования. Конечно, любые пункты, не найденные в базе данных, могут быть добавлены к проекту и в конечном счете – к базе данных, если есть необходимость. Качество оценок, входящих в базу данных, зависит от опыта оценщиков, но через какое-то время качество данных должно улучшиться. Структурированные базы данных используются для оценки стоимости и времени каждого проекта. Кроме того, сравнение оценок и фактов для различных проектов может выявлять риск, свойственный оценкам. Шаблоны для базы данных, в которой хранятся оценки Лекция 6 ПОСТРОЕНИЕ И АНАЛИЗ СЕТЕВЫХ ГРАФИКОВ Сетевой график является основанием для распределения рабочей силы и оборудования. Каждая область имеет свою терминологию, которая позволяет коллегам поддерживать разговор друг с другом о методах, которые они используют. Управ­ляющие проектами – не исключение. Для менеджеров проектов деятельность, или опе­рация, – элемент проекта, который требует времени. А вот ресурсов она иногда требует, иногда – нет. Как правило, деятельность требует затрат времени – это время, когда люди работают, или время, когда люди ждут. Примеры последне­го – время перед подписанием контрактов, которые должны быть подписаны, или перед получением ожидаемых материалов. Деятельность (операция) обыч­но представляет собой одну или несколько задач, включенных в наборы работ. Описание операций должно использовать формат «глагол/существительное», например – «разработайте спецификации для продукта». Операция слияния – это деятельность, которой напрямую предшествует более одной операции. Параллельные операции – это операции, которые могут осуществляться одновременно, если это необходимо, по мнению управляющего проектом. Однако управляющий проектом может предусмотреть параллельные операции, которые будут происходить неодновременно. Путь – последовательность связанных, зависимых действий. Критический путь – самый длинный путь в сетевом графике; если деятельность, входящая в критический путь, отсрочена, про­ект также задерживается на то же самое время. Событие – этот термин используется, чтобы представить точку начала дея­тельности или ее конца, когда время не расходуется. Операция с разбивкой (дробящая операция) – деятельность, имеющая более одной операции, следующих непосредственно за ней. Обычно различают два подхода в построении сетевых графиков: подход, когда операция отображается блок-схемой (AON – Activity on Node), и подход, когда операция изображается в виде стрелки (АОА – Activities on Arrows). В обоих методах используются два стандартных элемента – стрелка и блок. В большинстве проектов доминирует метод построения сетевых графиков на основе блок-схем (AON). Основные правила, которым необходимо следовать при построении сетевых графиков проекта: 1. Поток (рабочая деятельность) в сети идет, как правило, слева направо. 2. Новый этап деятельности не может начаться, пока все предыдущие связан­ные с ним действия не закончены. 3. Стрелки в сетях указывают предшествующие и будущие шаги. Стрелки мо­гут пересекаться. 4. Каждая деятельность (действие) должна иметь уникальный номер иден­тификации. 5. Номер идентификации деятельности должен быть больше, чем номер лю­бых действий, которые предшествуют этой деятельности. 6. Возврат к предыдущей операции не разрешен (т.е. повторное прохождение через цикл операций не допускается). 7. Действия «при условии...» не допускаются (т.е. не может быть подобного: «при успешном завершении, сделайте то-то – в противном случае не делайте ничего»). 8. Опыт подсказывает, что, когда существуют многочисленные стартовые операции, может использоваться общий блок, чтобы ясно указать на точ­ку начала сетевого графика. Точно так же один конкретный блок может использоваться для ясного указания его окончания. Метод AON Распространение персональных компьютеров и графических программ послужило стимулом для использования метода AON (его еще иногда называют методом построения диаграммы по принципу предшествования). Типичные конструкции сетевого графика, построенного методом AON Блок отражает определенную операцию (деятельность). Он может иметь различные формы, но в последние годы блок все чаще изображают в виде прямоугольника. Зависимость между операциями – стрелки между прямоугольниками (блоками) в сети AON. Стрелки показывают, как действия связаны между собой, и отображают последовательность их выполнения. Длина и наклон стрелок произвольны и служат для удобного отображения сети. Буквы в блоках пишутся для идентификации операций. На практике операциям соответствуют определенные номера и краткое описание. При включении любой операции в сетевой график необходимо дать ответы на следующие три вопроса: 1. Какие операции должны быть завершены непосредственно перед этой операцией? Эти операции называют предшествующими по отношению к данной. 2. Какие операции должны следовать непосредственно за этой операцией? Эти операции называются последующими. 3. Какие действия могут выполняться во время выполнения данной операции? Такие операции можно назвать параллельными данной операции. Информация для построения сетевого графика Процесс вычисления операций В сетевом графике операции размещены в правильной последовательности, для того чтобы вычислить их начало и конец. Оценки времени деятельности проводятся на основе затрат времени для решения всех задач, составляющих набор работ операции. Сделав нескольких простых вычислений, управляющий проектом может произвести прямой и обратный анализ сетевого графика. Этот анализ дает ответы на следующие вопросы: – прямой анализ – определение самых ранних возможных сроков начала и за­вершения операций. 1. Насколько рано может начаться операция? (Самое раннее возможное на­чало – ES); 2. Насколько рано она может закончиться? (Самое раннее возможное окон­чание – EF); 3. Как скоро проект может быть закончен? (Ожидаемое время – ТЕ). Сетевой график по методу AON – обратный анализ – определение самых поздних сроков начала и завершения операций. 1. Каковы самые поздние сроки начала операции? (Самое позднее возможное начало – LS); 2. Как поздно может закончиться деятельность? (Самое позднее возможное окончание – LF); 3. Какие действия относятся к критическому пути? Это самый длинный путь; при задержке выполнения операций на этом пути задерживается выполнение проекта; 4. На какое время может быть задержано выполнение операции? (Резерв времени – SL). а) Прямой анализ: определение ранних сроков начала операций. Процесс прямого анализа разворачивается от первых операций проекта, и проходя по всем путям (цепочкам последовательных операций) сетевого графика до самой последней операции проекта. По мере продвижения по любому из путей производится добавление времени выполнения операций. Самый длинный путь показывает время завершения проекта в целом и называется критическим путем (СР). Прямой анализ начинается со времени начала проекта, которое обычно принимается равным нулю. Иными словами, прямой анализ предполагает, что каждая операция начинается в тот момент, когда завершается последняя по продолжительности предшествующая ей операция. При расчете времени самого раннего возможного времени начала операции в процессе прямого анализа необходимо помнить следующее: 1. Суммируется время операции по каждому пути в сетевом графике (ES + Dur = EF). 2. Самое раннее возможное окончание (EF) предшествующей операции переносится до следующей, у которой оно же становится временем самого раннего возможного начала (ES), если только... 3. ... последующая операция не является операцией слияния. В этом случае выбирается самое большое по значению время раннего окончания (EF) среди всех непосредственно предшествующих операций. Таким образом, на все три вопроса, которые ставятся в процессе прямого анализа, были получены ответы, т. е. было рассчитано время самого раннего начала (ES), самого раннего окончания (EF) и определена продолжительность проекта (ТЕ) в целом. б) Обратный анализ: определение поздних сроков завершения операций. Обратный анализ начинается с самой последней операции сетевого графика. Каждый раз, выполняя шаг назад к началу сетевого графика, необходимо вычитать время рассматриваемой операции из общей продолжительности проекта в целом с тем, чтобы определить сроки ее самого позднего возможного начала (LS) и окончания (LF) выполнения. Сетевой график по методу AON – прямой анализ За исходную временную точку при выполнении обратного анализа принимается время максимально позднего окончания самой последней операции проекта. У этой операции данное время совпадает с временем раннего окончания ее выполнения (EF) или, в случае нескольких завершающих операций, операции с самым большим EF. В некоторых случаях имеются установленные крайние сроки продолжительности проекта, тогда будут использоваться именно эти сроки. Обратный анализ похож на прямой анализ. Выполняя его, следует помнить три вещи: 1. Время операции вычитается на каждом шаге, начиная с последней операции проекта (LF – Dur = LS). 2. Вы переносите LS на предшествующую операцию и приравниваете к нему ее LF, если... 3... предшествующая операция не является операцией дробления. В этом случае вы выбираете наименьшее LS из всех операций, которым данная операция дает начало, и приравниваете к этому значению ее LF. в) Определение резервов времени Когда завершен прямой и обратный анализ, можно определить, какие операции могут быть просрочены. Для этого необходимо просчитать резерв времени. Суммарный резерв говорит нам о количестве времени, на которое может быть задержан данный вид деятельности, не приведя при этом к задержке проекта. Иными словами, суммарный резерв – количество времени, на которое может быть превышен (по продолжительности) данный вид деятельности относительно ранее оговоренной даты окончания, не приведя при этом к переносу даты сдачи проекта. Суммарный резерв по операции представляет разницу между поздним и ранним началом (LS – ES = I = SL) или между поздним и ранним окончанием (LF – EF = SL). Если происходит задержка одной операции, то ES для цепочки всех последующих операций сдвигается вперед, а их резерв соответственно уменьшается. Использование суммарного резерва должно координироваться всеми участниками последующих операций цепочки. После вычисления резерва для каждой операции легко определить критический путь. Когда LF = EF для конечной операции проекта, критический путь можно определить как те операции, у которых LF = EF, или резерв = 0 (LF – EF = 0) (или LS – ES = 0). Критический путь – это путь в сетевом графике, где практически нет резервов времени. Проблема возникает, когда последняя операция проекта имеет LF, которое отличается от EF этой операции, полученного в результате прямого анализа, – например из-за того, что сроки выполнения установлены жестко. А если это так, то резерв на критическом пути будет не нулевым, а равным разнице между EF проекта и установленным LF последней операции проекта. Сетевой график по методу AON – обратный анализ Свободный резерв (FS) – количество времени, на которое можно задержать вид деятельности, не вызывая задержку последующего вида (видов) деятельности. Или, иными словами, свободный резерв – это то время, на которое может быть перенесена дата самого раннего возможного завершения данного вида деятельности таким образом, что это никак не скажется на самом раннем возможном времени начала последующего вида деятельности. Свободный резерв никогда не бывает отрицательным. Только виды деятельности из цепочки опе­раций, где имеются операции слияния, могут иметь свободный резерв. Свободный резерв имеет место у последней операции (вида деятельности) в цепочке операций. Во многих случаях цепочка может иметь только одно звено. На рисунке вид деятельности 6 имеет свободный резерв в 15 дней, а виды деятельности 2 и 3 – нет. В этом случае вид деятельности 6 – последняя операция в верхнем пути, и она сливается с видом деятельности 7. Отсюда – задержка вида деятельности до 15 временных единиц не приведет к задержке последующих видов деятельности и не потребует координации с управляющими других видов деятельности. Наоборот, если задержаны будут виды деятельности 2 или 3, управляющие следующими видами деятельности должны быть извещены, что будет использоваться резерв, так что им необходимо перенести даты начала. Например, если вид деятельности 2 откладывается на 5 временных единиц, менеджер, управляющий этой операцией, должен уведомить тех, кто занимается последующими операциями 3 и 6, что их резерв снижен до 10 единиц. Свободный резерв операции 6 также снижается до 10 единиц. Резервы времени Улучшающие методы построения сетевых графиков Метод отображения взаимосвязи между операциями, описанный выше, называется методом отношения типа «от конца к началу», так как он предполагает, что все непосредственно предшествующие операции должны быть завершены до того, как начнет выполняться следующая за ними операция. С целью приблизить проекты к реальности этот метод был несколько усовершенство­ван. Одним из таких полезных дополнений стал ступенчатый метод. Предположение, что все предшествующие операции должны быть завершены на 100%, не всегда можно реализовать на практике. Очень часто этого не происходит из-за того, что выполнение одной операции перекрывает начало другой. По условиям выстраивания отношений по типу «от конца к началу», если операция продолжительна и задерживает начало следующей непосред­ственно за ней операции, ее можно разбить на части и начертить сеть, используя ступенчатый метод, чтобы последующая операция могла начаться быстрее, не задерживая надолго общую работу. Разбивка на части продолжительных операций ведет к появлению «ступенек», о чем говорит и название метода. Например, прокладка трубы длиной 1 км: необходимо выкопать траншею, уложить в нее трубу и засыпать траншею. При этом нет необходимости сразу рыть траншею длиной в 1 км, после чего только начинать прокладку труб, по завершении которой переходить к засыпке траншеи. На рисунке показано, как эти перекрывающие операции могут быть представлены в сетевом графике, построенном по методу AON. Пример использования ступенчатого метода «от конца к началу» Использование задержек (лагов) Для достижения большей гибкости при разработке сетевых графиков были придуманы задержки (лаги). Лаг – это минимальный отрезок времени, на которое должно быть отложено начало или окончание зависимой операции. Лаги использу­ется при разработке сетевых графиков по двум основным причинам: 1. Когда более продолжительные операции задерживают начало или завер­шение последующих операций, то разработчик сетевого графика, как правило, разбивает такую операцию на более мелкие, чтобы избежать большого отставания последующей операции. Использование лагов помогает избежать такого отставания и уменьшает потребность в детализации сетевого графика. 2. Лаги могут использоваться для ограничения времени начала и окончания операции. а) тип лага «от конца к началу» Бывают ситуации, когда последующая операция в цепочке должна быть задержана, даже если предшествующая операция завершена. Например, выемка бетонных форм не мо­жет начаться, пока залитый цемент не будет выдержан в течение двух единиц времени. Тип лага «от конца к началу» Лаги в отношениях «от конца к началу» часто используются при отображении операций, связанных с заказами ресурсов. Например, может потребоваться 1 день, чтобы выполнить заказ, но 19 дней, чтобы получить заказанный товар. Использование лага «от конца к началу» дает возможность определить продолжительность операции в 1 день и лаг в 19 дней. Такой подход увязывает стоимость операции только с раз­мещением заказа, а не со стоимостью операции за 20 дней работы. Подобные лаги «от конца к началу» полезны и для описания транспортных, юридических и почтовых операций. Использование лагов типа «от конца к началу» должно быть тщательно выверено и обосновано. Простое правило, которому надо следовать: использование лагов «от конца к началу» должно быть проанализировано и одобрено тем, кто отвечает за большой раздел проекта. Закономерность использования лагов обычно нетрудно понять. Обосно­ванное использование лагов может значительно повысить качество сети, давая бо­лее точное представление о проекте. б) тип лага «от начала к началу» Альтернативой дроблению операций является использование отношений типа «от начала к началу». Важно отметить, что эти отношения могут использоваться как с лагом, так и без него. Если устанавливается время, то это обычно показано с по­мощью стрелки зависимости в сети AON. На рисунке (B) операция Q не может начаться раньше, чем пройдет время в 5 единиц после начала операции Р. Этот тип отношений обычно отражает ситуацию, в которой часть операции может быть выполнена и следующая операция начата, хотя первая еще не завершена. Тип лага «от начала к началу» Эти лаги могут применяться в проекте по прокладке труб. Лаги типа «от начала к началу» уменьшают уровень детализации и отставание проекта. Использование лагов для уменьшения уровня детализации Можно найти возможности сжатия графика, изменив отношения «от конца к началу» на отношения «от начала к началу». Пересмотр отношений «от конца к началу» между критическими операциями открыл возможности запараллеливания работ с использованием отношений типа «от начала к началу». Например, вместо операций, связанных с отношением типа «от конца к началу»: сначала проектирование дома, затем закладка фундамента, можно установить, что закладка фундамента начинается, скажем, через 5 дней (лаг) после начала проектирования, допустив, что проектирование фундамента дома является первым этапом всей операции проектирования. Отношения типа «от начала к началу» с небольшим лагом дают возможность осуществлять последовательные операции параллельно и сокращать общую продолжительность критического пути. Такой подход часто используется в строительных проектах, когда одновременно проводятся проектно-конструкторские и строительные работы для ускорения выполнения проекта в целом. При одновременном выполнении проектно­-конструкторских и строительных работ операции разбиваются на более мелкие части, чтобы работа могла проводиться параллельно и проект мог быть уско­рен. В таких условиях могут использоваться лаги типа «от начала к началу», и за счет них можно уменьшить необходимый уровень детализации сетевого графика. Такой же результат может быть получен с помощью разбивки операции на небольшие наборы, которые могут осуществляться параллельно, но этот подход значительно увеличивает размер сетевого графика и уровень детализации. Раньше, если компания решала начать проект разработки нового продукта, он на­чинался с отдела НИОКР. Там вырабатывались творческие концепции и идеи, далее переходившие в технический отдел, где на дело смотрели свежим взглядом и иногда перекраивали весь новый продукт. Результат уходил в производственный отдел, где еще раз вносили изменения, с тем чтобы изделия можно было изготовить исходя из имеющихся механизмов и методов. Когда в ходе производства обнаруживались скрытые дефекты, начинался процесс улучшения качества изделия. Этот последовательный подход к развитию нового товара требовал большого количества времени и мог заметно изменить конечный продукт по сравнению с первоначальными специфи­кациями. Учитывая необходимость быстрого «выброса» продукта на рынок, компании пришлось отка­заться от последовательного подхода и разработать более целостный механизм, который получил название параллельной разработки. Метод параллельной разработки объединяет все специаль­ные области по всему процессу развития и проекту. Процесс разработки продукта Традиционные связи между последовательны­ми операциями «от конца к началу» заменяются лаговыми связями «от начала к началу» так, чтобы можно было начать существенную часть работы для следующей стадии. в) тип лага «от конца к концу» Время окончания одной деятельности зависит от окончания другой деятельности. Например, тестирование не может быть закончено раньше, чем через 4 дня после того, как выполнен опытный образец. Тип лага «от конца к концу» Обратите внимание, что это не отношения «от конца к началу», потому что испы­тание предварительных компонентов может начаться прежде, чем будет завершен опытный образец, но в течение 4 дней после того, как опытный образец закончен, «система» будет тестироваться. г) тип лага «от начала к концу» Эти отношения относятся к ситуациям, в которых конец одной деятельности зависит от начала другой. Например, документация системы не может быть за­кончена раньше, чем через 3 дня после начала испытания. В этом случае вся необходимая информация для оформления документации по системе будет получена после первых трех дней испытаний. Тип лага «от начала к концу» д) комбинации лагов Лагов может быть более одного. Сочетание лагов обычно идет по схеме «от на­чала к началу» + «от конца к концу», привязанной к двум операциям. Например, наладка не может начаться, пока не пройдут 2 единицы времени после коди­рования. Кодирование должно быть закончено за 4 дня до того, как может быть закончена наладка. Комбинация лагов Пример использования лагов – прямой и обратный анализ Процедуры прямого и обратного анализа те же самые, о которых говорилось ранее для взаимосвязей между операциями «от конца к началу» (без лагов). Модификация состоит в том, чтобы проверить все новые связи и по­нять, изменяют ли они время начала или конца другой операции. Пример результата прямого и обратного анализа показан на рисунке ниже. Заказ комплектующих зависит от разработки системы («от начала к началу»). Спустя 3 дня после начала разработки системы (операция А) можно заказы­вать комплектующие (В). После заказа комплектующих (В) необходимо прождать 4 дня для их доставки, чтобы начать установку (С). После 2 дней установки системы программного обеспечения (D) может начаться тестирование системы (Е). Те­стирование системы (Е) может быть закончено спустя 2 дня после того, как программное обеспечение будет установлено (D). Разра­ботка документации системы (F) может начаться, как только раз­работка системы (А) будет закончена, но может быть закончена только через 2 дня после тестирования системы (Е). Эта заключительная связь – пример лага «от конца к концу». При этом деятельность может иметь критический конец и/или начало. Операции Е и F имеют критические концы (нулевой резерв времени), но начала данных операций имеют 4 и 12 дней резерва соответственно. Иными словами, только окончания действий Е и F являются критическими. И, наоборот, операция А не имеет ни одного дня в резерве, чтобы начаться, но имеет за­пас в 5 дней, чтобы закончиться. Критический путь проходит следующим обра­зом: от начала А, по лагам между операциями в середине процесса и по ограничениям в окончании операций (критические концы операций Е и F). Критический путь обозначен пунктир­ной линией. Если в схему включены лаги, то каждая деятельность должна быть проверена, чтобы видеть, есть ли ограничения по времени начала или окончания операций. Например, в прямом анализе показатель EF (самое раннее возможное окончание) операции Е (тестирование системы) (18 дней) контролируется окончанием операции D (установка программного обеспечения) (16 дней) и лагом в 2 еди­ницы времени (16 + 2 = 18). Наконец, в обратном анализе показатель LS (самое раннее возможное начало) операции А (разработка системы) контролируется операцией В (заказ комплектующих) и лагом к операции А (3 – 3 = 0). Сетевой график, использующий лаги Метод «гамака» Еще один видоизмененный метод использует операцию типа «гамак». Этот тип деятельности получил свое название, потому что охватывает доли (сегменты) про­екта. Продолжительность деятельности «гамака» определяется после того, как се­квой график уже создан. Метод «гамака» часто используется, чтобы установить, сколько точно ресурсов должно быть использовано в сегменте проекта или каковы затраты по данному сегменту. Типичные при­меры – инспекционные услуги, консалтинг или управление строительством. Операция «гамак» возникает в промежутке времени между другими действиями. Например, на специализиро­ванной выставке понадобилось задействовать цветную копировальную машину. Чтобы опре­делить необходимость в данном ресурсе и во что обойдется «участие» копира в выставке, используется операция «гамак», которая примыкает к началу первой операции сегмента и кон­цу последней операции того же сегмента, где задействуется копировальная машина. Про­должительность операции типа «гамак» в данном примере является просто разницей между EF последней операции и ES первой операции. Продолжительность вычисляют путем прямого анализа, и поэтому она никак не сказывается на времени начала и конца других операций. На рисунке показан пример «гамака» в сетевом графике. «Гамак» длится от самого ран­него возможного начала операции В и самого раннего возможного окончания операции F, т.е. продолжительность равна разнице между 13 и 5, или 8 единицам времени. Продолжительность «гамака» изменится, если любые ES или EF в последовательности изменятся. Пример операции по типу «гамак» Лекция 7 КАЛЕНДАРНОЕ ПЛАНИРОВАНИЕ РЕСУРСОВ И ЗАТРАТ Предложенных проектов всегда больше, чем доступных ресурсов. Система приоритетов отбирает проекты, которые вносят наибольший вклад в цели организации с учетом нехватки доступных ресурсов. Если все проекты и соответствующие им ресурсы спланированы, степень осуществимости нового «добавленного» проекта к тем, что уже запущены, а также его последствий для них можно быстро оценить. Поэтому проектная команда, ответственная за определение приоритетов, которая владеет такой информацией, согласится с новым проектом, только если есть ресурсы и их можно передать данному конкретному проекту. Процесс планирования по проекту После того как штат и другие ресурсы для проекта определены, менеджер проекта должен найти ответы на следующие вопросы: - Будет ли назначенная рабочая сила и/или оборудование соответствовать проекту и можно ли будет ими воспользоваться (т.е. будут ли они в наличии, а не задействованными в других проектах)? - Нужны ли внешние подрядчики? - Существует ли непредвиденная зависимость от ресурсов? Есть ли новый критический путь? - Достаточно ли гибкости в использовании ресурсов? - Действительно ли реальным является срок сдачи? Ясно, что любой управляющий, отвечающий за проект, должен нивелировать проблемы, с которыми сталкивается. И любая система календарного планирования должна помогать находить простые и понятные ответы на указанные вопросы. Построенный сетевой график и время операций по проекту, рассмотренные выше, не позволяют проанализировать использование ресурсов и их наличие. Оценка времени для набора работ и операций делалась изолированно исходя из допущения, что ресурсы будут доступны. А этого может и не быть. Если ресурсы соответствуют проекту, но требования к проекту могут кардинально меняться на протяжении его жизненного цикла, желательно «выравнивать» спрос на ресурсы, откладывая во времени выполнение операции, не лежащих на критическом пути (вводя по ним резервы времени), чтобы снизить скачки спроса и, таким образом, использовать ресурсы оптимальным образом. Этот процесс называют выравниванием ресурсов, или сглаживанием. С другой стороны, если ресурсы не способны удовлетворить пиковый спрос (резкое увеличение потребности в ресурсах), самое позднее возможное начало некоторых операций должно быть отсрочено, а продолжительность проекта увеличена. Этот процесс называют планированием ресурсов, в условиях нехватки. Одно исследование, проведенное более чем на 50 проектах, выявило интересный факт: после планирования ресурсов продолжительность сетевых графиков увеличивалась на 38%. Отсутствие планирования ограниченных ресурсов обходится недешево, а задержки обычно становятся видны в середине проекта, когда трудно предпринять какие-либо действия для быстрого исправления ситуации. Кроме этого отсутствие планирования ресурсов – это невнимание к скачкам и спадам потребности в них на протяжении проекта. Поскольку ресурсы обычно ограниченны и редко требуются именно в то время, когда они совершенно доступны, нужны специальные процедуры, чтобы разобраться с этими проблемами. До настоящего момента начало и последовательность операций базировались исключительно на технических и логических предпосылках. Например, сетевой график проекта по возведению каркаса здания состоит из трех последовательных операций: (1) заливка фундамента, (2) возведение каркаса и (3) покрытие крыши. Иными словами, логически невозможно приступить к операции 2, пока не завершена операция 1, и т.д. На рисунке (А) ниже сетевой график проекта отражает технические ограничения. Примеры нехватки ресурсов Сетевой график предполагает, что для выполнения требуемых работ имеются соответствующий персонал и оборудование. Но очень часто в действительности все не так. Отсутствие или нехватка ресурсов может серьезно изменить технические ограничения. Проектный планировщик сети может принять наличие соответствующих ресурсов как данность и наметить параллельные действия. Однако параллельные действия потенциально грозят конфликтом ресурса. Предполо­жим, что планируется свадебный прием, который включает четыре действия: (1) план, (2) найм оркестра, (3) украшение зала и (4) закупку закусок. На каждую операцию отводится один день. Действия 2, 3 и 4 могли быть сделаны параллельно различными людьми. Нет никакой технической причины или зависимости одного от другого (рисунок (В)). Однако если один человек должен исполнить все действия, ограничение ресурса требует, чтобы эти действия были выполне­ны последовательно. Четкая последовательность – это задержка действий и со­вершенно другие отношения в сетевом графике (рисунок (С)). Важно: зависимость от ресурса имеет приоритет над технической зависимостью, но не нарушает ее, т.е. найм, украшение и закупку, вероятно, теперь придется делать последовательно, а не одновременно, но они должны быть закончены прежде, чем начнется прием. Взаимосвязи и взаимодействия среди временных и ресурсных ограничений сложны даже для небольших сетевых графиков. Попытки исследовать эти вза­имодействия перед началом проекта часто раскрывают удивительные проблемы. Менеджеры проектов, которые не «берут на карандаш» доступность ресурсов в проектах средней сложности, обычно обнаруживают проблему, когда ее уже слишком поздно исправлять. Дефицит ресурсов может значительно изменить проектные отношения зависимости, даты завершения и суммы планируемых затрат. Проект-менеджеры должны быть осторожны при планировании ресурсов, чтобы гарантировать их доступность в соответствующем количестве и в нужное время. К счастью, существуют компьютерные программы, которые позволяют идентифицировать проблемы ресурсов на ранней стадии проекта, когда корректирующие изменения еще можно внести в график. Достаточно ввести данные потребности в ресурсах и их наличии, чтобы спланировать их использование в проекте. Виды ограничений по ресурсам Ресурсы – это люди, оборудование и материалы, которые могут быть привлечены или использованы для достижения определенных целей. Наличие или отсутствие ресурсов будет часто влиять на способ управления проектами. 1. Люди. Самый очевидный и важный проектный ресурс. Человеческие ресурсы обычно классифицируются по навыкам, которыми обладают специалис­ты, например: программист, технический инженер, сварщик, инспектор, директор по маркетингу, контролер. В редких случаях некоторые навыки бывают взаимозаменяемыми, но обычно с потерей производительности. Многообразие различных человеческих ресурсов усложняет планирование проектов. 2. Материалы. Материалы охватывают большой спектр компонентов: например, химические компоненты для научного проекта, бетон для проекта строительства дорожного полотна, данные для проекта маркетинга. Доступность и нехватка материалов могут служить причинами задержки многих проектов. В некоторых случаях особенности материалов важны для проект­ного плана сети и графика. Например, период поставки и размещения башни нефтяной платформы на сибирском нефтяном месторождении ограничен крайне маленьким отрезком времени – одним летним месяцем. Любая задержка поставки означает дорогостоящую задержку на год. Другим примером, в котором материал был главным ресурсом, влияющим на график работ, является замена некоторых конструкций моста «Золотые ворота» в Сан-Франциско. Работы по проекту были ограничены интервалом между полуночью и пятью утра с уплатой штрафа в размере 1000 долл. за минуту «сверхурочной» работы после 5:00. Замену конструкций было чрезвычайно важно увязать с пятичасовым окном. Планирование материальных ресурсов также необходимо для продвижения нового продукта, где время выхода на рынок крайне важно: если оно окажется чуть больше, чем планировали это может закончиться потерей доли на рынке. 3. Оборудование. Оборудование обычно различается по типу, размеру и количеству. В некоторых случаях оборудование можно перебрасывать с одной работы на другую, чтобы улучшить рабочий график, но это не типичный случай. Оборудование часто ошибочно не относят к «ограниченным» ресурсам. Самая большая ошибка – допускать, что его более чем достаточно для проекта. Например, если проект нуждается в одном тракторе на период в шесть месяцев, а у владельца есть четыре машины, то можно предположить, что это не задержит ожидаемый проект. Однако, когда трактор понадобится на объекте, все четыре трактора могут использоваться в других проектах. В многопроектных окружающих средах следует использовать общий ресурс – единый для всех проектов. Этот подход заставляет следить за наличием общего ресурса и резервировать оборудование для конкретного проекта в будущем. Установка ограничений на оборудование на стадии планирования проекта поможет избежать затрат на урезание проекта или затрат, вызванных задержкой. Классификация проблем планирования Большинство методов планирования требуют, чтобы менеджер проектов классифицировал проект как ограниченный по времени или ограниченный по ресурсам. Менеджеры проектов должны соотносить их с матрицей приоритета (Лекция 4), определяя, какой случай соответствует их проекту. Чтобы определить, является ли проект ограниченным по времени или по ресурсам необходимо поставить вопрос: «Если критический путь отсрочен, нужно ли добавить ресурсы, чтобы вернуться в график?» Если ответ «да», то проект ограничен по времени; если «нет», то проект ограничен по ресурсам. Ограниченный по времени проект – тот, который должен быть закончен к определенной дате. Если потребуется, то ресурсы могут быть добавлены, чтобы гарантировать завершение проекта к определенной дате. Хотя время – критический фактор, использовано ресурсов должно быть не больше, чем это необходимо. Ограниченный по ресурсам проект – тот, в котором доступный уровень ресурсов не может быть превышен. Если ресурсов недостаточно, необходимо будет задержать проект, насколько это возможно. С точки зрения планирования «ограниченный временем» означает, что время (длительность проекта) строго определено при гибком использовании ресурсов; а «ограниченный ресурсами» означает, что допускается гибкость по времени, но количество ресурсов не будет выходить за установленные рамки. Методы распределения ресурсов Для наглядности стоит прибегнуть к ограничениям: - во-первых, необходимо исключить дробление работ. Это означает, что, как только операция включается в график, она будет осуществляться непрерывно, вплоть до завершения; следовательно, она не может быть начата, прервана на время и затем закончена. - во-вторых, уровень ресурсов, используемых в проекте, не может быть изменен. Эти ограничения не существуют на практике, но упрощают изучение. Проект-менеджеры, взявшись за проект, обычно легко справляются с дроблением операций и изменени­ем уровня ресурсов, когда сталкиваются с этим в работе. а) Проекты, ограниченные по времени: метод выравнивания ресурса. Планирование ограниченных по времени проектов сосредоточивается на использовании ресурсов. Когда потребность в конкретном типе ресурса то увеличивается, то снижается, управлять им трудно, поэтому его использование может быть очень неэффективным. Практики справляются с проблемой использования, опираясь на методы, которые балансируют или выравнивают спрос на ресурс. В основном все методы выравнивания сводятся к задержке некритических операций, они используют положительный резерв времени для уменьшения скачка спроса на ресурс и переноса спроса на ресурс на отрезки, где спрос был незначи­телен. Общая процедура для проекта, ограниченного по времени В примере выше для упрощения использован только один тип ресурсов – экскаваторы. Все ресурсы (экскаваторы) в рамках этого проекта взаимозаменяемы. На главной диаграмме изображены действия в масштабе времени. Зависимости показаны вертикальными стрелками. Горизон­тальные стрелки после действий говорят о резерве времени по конкретной операции (например, рытье оросительных каналов требует 6 дней для завершения и имеет резерв в 6 дней). Число экскаваторов, необходимых для каждой задачи, показано в блоке (прямоугольнике), закрашенном серым цветом. После того как определен участок и составлен план, начинаются одновременно работы по рытью каналов для орошения и строительству ограждений. Средняя диаграмма показывает профиль ресурса для экскаваторов. В течение периодов 4-10 необходимы четыре экскаватора. Поскольку этот проект ограничен по времени, необходимо уменьшить пиковый спрос на ресурс и таким образом увеличить его использование. ES (самое ран­нее возможное начало) на диаграмме нагрузки на ресурс показывает, что только две операции: 1) забор и стены и 2) ирригационные работы, имеют резерв, кото­рый можно использовать, чтобы выровнять спрос на ресурс. Лучше всего исполь­зовать забор и стены. Другой выбор – ирригационные работы, но тогда мы будем иметь скачкообразный профиль ресурса. Выбор, вероятно, будет сделан в пользу деятельности с наименьшим риском и завершиться с опозданием. Результаты за­держки операции по строительству стен и забора показаны на диаграмме, где ре­сурсы выравнены. Обратите внимание на различия в профилях ресурса. Важный пункт – максимальное количество ресурсов, необходимых для жизненного цикла проекта, уменьшилось с четырех до трех (на 25%). Кроме того, был сбалансирован профиль, что облегчает управление План проекта ботанического сада удовлетворяет трем целям выравнивания: 1. снижен «пиковый» спрос на ресурсы; 2. максимальное количество ресурсов, задействованных в жизненном цикле проекта, уменьшено; 3. колебания в спросе на ресурс минимизированы. Последнее улучшает использование ресурсов. Экскаваторы не легко перемещать от места к месту. Есть и затраты, связанные с изменением уровня необходимых ресурсов. Аналогичная ситуация складывается, когда людей переводят с проекта на проект. Известно, что люди действуют более эффективно, если могут сосредоточить свои усилия на одном проекте, а не на трех. Обратная сторона процесса выравнивания – потеря эластичности, которая происходит от сокращения резервов времени. Риск операций, задерживающих проект, также увеличивается, потому что сокращение резервов может привести к возникновению новых критических или подкритических операций. Стремление слишком сильно выровнять график ресурсов рискованно. Каждая операция становится критической. Пример проекта ботанического сада дает представление о проблеме ограничения по времени и методе выравнивания. б) Проекты, ограниченные по количеству ресурсов. Когда число людей и/или оборудования недостаточно для удовлетворения скачка спроса и их количество невозможно увеличить, управляющий проектом оказывается перед проблемой нехватки ресурсов. Ис­кусство менеджмента заключается в выстраивании приоритетов и распределении ресурсов таким образом, чтобы минимизировать проектную задержку, не превышая предел ресурса и не изменяя технические отношения в сети. Проблемы с ресурсами требуют комбинаторного подхода. Это означает, что даже сеть проекта скромного размера с несколькими типами ресурсов может иметь несколько тысяч выполнимых решений. Только некоторые исследователи продемонстрировали оптимальные математические решения проблемы распреде­ления ресурса и только для небольших сетей и очень немногих типов ресурсов. Огромное количество данных для решения больших проблем делают иные мате­матические решения непрактичными. Альтернативный подход к проблеме – это использование эвристики (правил, полученных на практической основе) для решения больших комбинаторных проблем. Эвристика не всегда приводит к оптимальному графику, но способна обеспечить «хороший» график для очень сложных сетей со многими типами ресурсов. Была доказана эффективность различных правил и комбинаций правил. Однако, так как каждый проект уникален, следует проверить несколько наборов эвристики в сети, чтобы определить правила распределения приоритетов, которые минимизируют задержку проекта. Современное программное обеспечений делает крайне легким для управляющего проектом создание хорошего плана использования ресурсов по проекту. Эвристика распределяет ресурсы по видам деятельности (операциям), с тем чтобы запаздывания по проекту были минимальными; иными словами, эвристика выстраивает последовательность приоритетов по операциям – какие операции получат необходимые ресурсы, а какие будут отложены из-за нехватки ресурсов. Параллельный метод – самый известный и наиболее распространенный эвристический подход. Параллельный метод – повторяющийся процесс, который начинается с начала жизни проекта и, когда требуемые ресурсы превосходят имеющиеся ресурсы, сохраняет операции по следующей схеме приоритетов: 1. минимальный резерв времени; 2. наименьшая продолжительность; 3. наименьший номер операции. Те операции, которые невозможно спланировать без задержки других, пере­носятся в более обозримое будущее выполнения проекта. Однако не нужно пытаться переносить уже начатые операции. Когда следует решить, какие операции не бу­дут задержаны, необходимо определить ресурсы, которые используются в каждой операции. В любой период, когда для двух операций или более требуется один и тот же ресурс, применяются правила приоритета. Например, если в период 5 начинаются три действия (т.е. у них одинаковый ES), требующие использования одного и того же ресурса, то первая деятельность, помещенная в график, будет операцией с минимальным резервом (правило 1). Однако, если резерв у всех операций одинаковый, действует другое правило (правило 2), и деятельность с наименьшей продолжительностью будет помещена в график в первую оче­редь. В очень редких случаях, когда у всех подходящих операций одинаковый резерв времени и одинаковая продолжительность, приоритет отдается деятель­ности с минимальным идентификационным кодом/порядковым номером (пра­вило 3) – ведь каждая деятельность имеет собственный идентификационный код или номер. Когда предел ресурса достигнут, самое раннее начало (ES) для последующих операций в графике должно быть отсрочено (как и все последующие действия, имеющие нулевой резерв времени). В последующие периоды процедура будет по­вторяться до тех пор, пока проект не будет полностью представлен в виде графика. На Рисунках А и В ниже изображена данная процедура. Параллельный метод График по периоду 2-3 при ограниченных ресурсах (Рисунок А) Заштрихованные области в ресур­се на диаграмме представляют собой «интервал планирования», ограниченного временем графика (ES через LF). Можно запланировать ресурс в любом месте в пределах интервала и не задерживать проект. Планирование деятельности в точке, выходящей за время LF, приведет к задержке проекта. Число программистов ограничено тремя. Следуя за действиями, представленными на Рисунках А и В, обращает на себя внимание задержка времени проекта при существующем ограничении трудовых ресурсов. График по периоду 5-6 при ограниченных ресурсах (Рисунок В) При использовании метода параллельного планирования сетевой график на рисунке В отражает новую дату графика – 14 временных единиц, а не ограниченную временем проектную продолжительность в 12 единиц. Сетевой график также изменился, чтобы отразить новое начало, конец и резерв времени для каждой деятельности. Обратите внимание, что деятельность 6 является все еще критической и ее резерв – 0 единиц, потому что недоступны никакие ресурсы (они используются в операциях 2 и 5). Сравните резервы времени для каждой деятельности, отраженных на рисунках А и В, – резервы времени значительно сократились. Отметьте также, что деятельность 4 имеет только 2 единицы резерва времени, а не 6 единиц, как раньше. Это происходит потому, что задействованы только три программиста, и необходимо, чтобы они удовлетворили спрос на ресурсы по операциям 2 и 5. Важно, что число критических действий (1,2, 3, 5, 6 и 7) увеличилось с четырех до шести. Этот небольшой пример показывает сценарий планирования ресурсов в реальных проектах и результат такого планирования, который заключается в увеличении риска задержки сроков проекта. На практике это огромная проблема. Менеджеры, которые не смогли спланировать ресурсы, обычно сталкиваются с таким риском уложиться в график, когда уже ничего нельзя сделать (слишком поздно), и проект задерживается. Дробление (разбивка) операций Разбивка операций – прием планирования, используемый для улучшения графика проекта и/или более эффективного использования ресурсов. Плановик разбивает непрерывную работу, включенную в операцию, следующим образом: работа прерывается, а ресурс на некоторый период отправляется на другую операцию, после чего ресурс возвращается на исходную опе­рацию и возобновляет прерванную работу. Этот прием может быть полезен, если работа не требует значительных затрат на ввод в работу или выключение из нее – например, перевозка оборудования с одной операции на другую. Са­мая распространенная ошибка – прервать трудовой процесс, в котором велики расходы на ввод и выключение из операции. Например, если конструктора моста оторвать от работы и переключить на устранение пробле­мы на другом проекте, это может привести к потере 4 дней, так как ему придется 4 раза входить и выходить из двух операций. Затраты могут быть неявными, однако они есть. Считается, что если разбираться с нехваткой ресурсов с помощью разбивки операций – это станет основной причиной, по которой проекты не сда­ются в срок. Плановикам следует избегать дро­бления, насколько это возможно, за исключением тех ситуаций, где известно, что расходы на дробление будут незначительны или где нет возможности разрешить проблему нехватки ресурсов другим способом. Лекция 8 ИЗМЕРЕНИЕ И ОЦЕНКА ХОДА РАБОТ Оценка и контроль – часть работы каждого менеджера проекта. Контроль методом неформального общения и/или с помощью непосредственного участия в работе может решить большинство проблем на небольших проектах. Большие проекты требуют формального подхода. Контроль делает работников подотчетными, предотвращает разрастание небольших проблем в крупные, ставит четкую цель. Для эффективного контроля менеджер проекта должен иметь единую информационную систему для сбора данных и отчета по затратам, срокам и техническим требованиям. Структура информационной системы контроля над проектом Система мониторинга проекта включает следующие аспекты: а) какого рода данные необходимо собрать. Данные зависят от выбора критери­ев контроля над проектом. Типичные ключевые данные – фактическая продолжи­тельность операций, использование и ставка ресурсов и фактические затраты – все это сравнивается с плановыми сроками (продолжительностью), ресурсами и бюджетом. Так как основная задача системы мониторинга – отслеживать затра­ты и сроки, необходимо выяснить такие вопросы, как: - Каково текущее состояние проекта с точки зрения сроков и затрат? - Сколько будет стоить выполнение проекта? - Когда проект будет завершен? - Есть ли потенциальные проблемы, которыми нужно заниматься сейчас? - Что, кто и где стало причиной превышения затрат и сроков? - Что мы получили на один вложенный рубль? - Если в середине проекта превышены затраты, можно ли спрогнозировать превышение по выполнении? б) сбор данных и анализ. После того как определено, какие данные собирать, не­обходимо решить, кем, когда и как эти данные будут собраны. Это будет работа команды проекта, подрядчика, независимых инженеров или менеджера проекта? Или данные получат с помощью программы по таким параметрам, как поток де­нежных средств, часы работы станков, трудовые часы или материалы? Что при­нять за отчетный период – час, день, неделю или другую единицу времени? Есть ли центральный накопитель для собранных данных, и будет ли за распространение отвечать конкретное лицо? Значительно улучшают сбор данных, их анализ и распространение электрон­ные средства. Для анализа индивидуальных данных существует много программ и инструментов, которые облекают их в форму, способствующую мо­ниторингу проекта, позволяющую установить источники проблем и вносить необходимые изменения в план. в) отчеты. Сначала нужно разобраться, кто получит отчеты о ходе проек­та. Различные уровни стейкхолдеров и руковод­ства требуют разной информации по проекту. Для высшего руководства это обычно ответы на два вопроса: 1) по графику ли мы идем и не превышаем ли бюджет; 2) если нет, то какие предпринимаются корректирующие действия. Отчеты должны составляться для конкретного полу­чателя. Обычно отчеты о ходе проекта составляются как в устной, так и в письменной форме, и включает: прогресс со времени последнего отчета, текущее состояние проекта (сроки, затраты, объем), общие тенденции; проблемы с момента последнего отчета (действия в решении ранее выявленных проблем, выявление новых проблем и пути их решения), корректировки плана. Процесс контроля над проектом Контроль – процесс сравнения фактических результатов с планом с целью установить отклонения, оценить альтернативное развитие событий и принять соответствующие корректирующие меры. Шаги по осуществлению контроля над проектом: 1. Разработка основного плана. Основной план позволяет измерить результаты, достигнутые по ходу проекта. Основной план строится на основе информации по затратам и продолжи­тельности, полученной при разбивке работ (WBS) и из сетевой модели проекта, а также при хронометрировании ресурсов. Полученный календарный (хрономе­трированный) план использования ресурсов затем используется для хронометри­рования всей работы, ресурсов и бюджетов, т. е. для создания основного плана проекта. 2. Измерение прогресса и результатов. Время и бюджеты – количественные показатели результатов, которые легко интегрировать в информационную систему. Качественные показатели, такие как удовлетворение технических требований заказчика и функции продукта, как пра­вило, определяются экспертизой на объекте или реакцией пользователя. В данном случае рассматриваются только количественные показатели – время и бюджет. Измерение временных характеристик относительно легко и понятно. То есть нужно опреде­лить ход по критическому пути: самое раннее возможное время, время по плану или самое позднее возможное время; сокращается ли резерв по некритическим операциям, который может привести к новым критическим операциям. Измере­ние результатов по бюджету (т. е. деньги, отделы, трудовые часы) – более слож­ный способ. Он сводится не только к сравнению фактических затрат с бюджетом. Необходима заработанная стоимость – она даст возможность реалистично оце­нить достигнутые результаты по проекту относительно хронометрированного бюджета. Заработанная стоимость (EV) – это бюджетные, сметные затраты со­вершенной работы. 3. Сравнение плана с фактами. Так как планы редко реализуются так, как ожидалось, необходимо обязательно измерять отклонения от плана, чтобы решить, нужно ли принимать меры. Пери­одический мониторинг и отслеживание состояния проекта позволяют сравнить факты с планом. Периодичность выхода отчетов о состоянии должна быть такой, чтобы можно было заранее определить отклонения от плана и скорректировать причины. Обычно отчет о состоянии выходит один раз в 1-4 недели – этого до­статочно для упреждающих корректирующих действий. 4. Принятие мер. Если отклонения от плана значительны, требуются корректирующие действия, чтобы вернуть проект рамки первоначального или пересмотренного плана. Иногда условия или объем могут меняться, что, в свою очередь, потребует изменения основного плана с учетом новой информации. Мониторинг сроков Главная задача отчета о ходе проекта – как можно раньше уловить негативные отклонения от плана для принятия своевременных мер (если они необходимы). При этом, мониторинг хода проекта относительно календарного плана достаточ­но прост. Для этой цели служит основной план, разработанный из WBS/OBS и се­тевой модели. Диаграммы Гантта и контрольные графики – типичные инструменты, ис­пользуемые для отслеживания состояния проектов, которые очень хорошо помогает отследить ход про­екта во времени и определить тенденции. Их формат доступен для понимания и очень подходит для высшего руководства, которое не имеет лишнего времени для подробного изучения. По диаграмме Гантта очень легко ориентироваться при изменении фактических сроков и определять состояние проекта в конкретный момент времени. а) Диаграмма Гантта На рисунке ниже показана диаграмма Гантта, которая отображает состояние про­екта в конце 6-го периода. На нижнем графике сплошные участки (ниже линий первоначального плана, которые заштрихованы) отражают фактическое время на­чала и окончания операций или какую-то часть завершенной операции (операции А, В, С, D и F). Например, фактическое начало операции С – период 2; фактиче­ское окончание – период 5; фактическая продолжительность – 3 единицы времени в отличие от запланированной продолжительности в 4 единицы. Операции, кото­рые выполняются, но еще не завершены, показывают фактическое время начала; продолжение линии со штриховкой в виде сетки отражает ожидаемое, оставшееся до завершения время (операции D и Е). Операция F, которая не начиналась, пока­зывает перенесенное ожидаемое начало (период 9) и время окончания (период 13). Диаграмма Гантта График отображает различия между плановой и фак­тической продолжительностью (операции С, D и Е). Завершена ли операция и известно ее фактическое время, или появляется новая информация – в этих случаях необходимо пересмотреть время на диаграмме и указать его в отчете о состоянии. Пересмотренная продолжительность операции D приведет к ожидаемой задерж­ке начала операции F. Теперь проект должен, по оценкам, продлиться на 1 период дольше, чем планировалось. б) Контрольный график. Контрольный график позволяет понять разницу между запланированным временем на критическом пути на отчетную дату и фактической точкой на критическом пути, в которой находится проект. На рисунке ниже показано, что проект отстал еще на ранней стадии, схема предполагает, что корректирующие меры снова вернули проект в нормальное русло. Если тенденция не изменится, проект будет сдан раньше срока. Так как запланированные продолжительности операций отражают средние показатели, наличие четырех фактов, выстраивающих тренд в одном направлении, говорит о высокой вероятности определяемой причины. Нужно локализовать причину и при необходимости принять меры по ее устранению. Контрольные графики выявляют тенденции и дают сигнал о потенциальных проблемах, требующих принятия соответствующих мер. Контрольный график Контрольные графики также часто используют для мониторинга прогресса касательно контрольных точек, которые фиксируют событие и как таковые не имеют протяженности во времени. Контрольные точки – это значительные события по проекту, сигнализирующие о значительных подвижках. Для максимального эффекта точки должны быть конкретными, подлежащими точной оценке событиями. Они должны быть понятны каждому участнику проекта – например, завершение испытаний продукта. Отлич­ные кандидаты для контрольных точек – критические операции слияния. Контрольный график часто используют, чтобы фиксировать продвижение к определенной контрольной точке. Известно: как только работа начинает, отставать от графика, потерянное время, скорее всего, не будет наверстано, так как это трудно сделать. Причинами, вызывающими отставание от графика, могут быть, например: ненадеж­ные оценки времени, незначительные изменения в проекте, разрастание объема и недостающие ресурсы. Если предусмотрен резерв времени в самом начале пути и этот резерв расходуется, это создает проблему для того, кто ответствен за более позднюю операцию; ликвидация недостатка времени достигается ценой гибкости и потенциальных возможностей. По этим причинам крайне важно иметь четкие критерии мони­торинга наборов работ и отслеживать результаты как можно чаще – тогда сигналы об отставании от графика поступят незамедлительно. Раннее выявление снижает шансы превращения небольших задержек в крупные, когда принять корректи­рующие меры уже не так просто. Создание системы заработной стоимости по затратам/срокам Система заработанной стоимости начинается с хронометража затрат, по ко­торым создается основной план проекта. Его еще называют плановой бюджет­ной стоимостью запланированной работы (PV). Располагая таким хронометри­рованным планом, можно сравнивать запланированные и фактические сроки и затраты, используя метод заработанной стоимости. Суть в том, что отчет о состоянии проекта можно получить в любой момент времени. Основные термины и обозначения EV Заработанная стоимость задания – часть (или вся работа), выполненная к какому-то моменту (в процентах от всего количества), умноженная на первоначальный бюджет, который предусмотрен на работу, выполненную целиком. Если сформулировать по-другому, EV – это процент первоначального бюджета, который заработан фактически выполненной работой. PV Стоимость запланированной работы, которая должна быть закончена к конкретному моменту времени (по плану). Одобренная оценка затрат на ресурсы в хронометрированном сводном плане. AC Фактические затраты на законченную работу. Сумма затрат, понесенных при выполнении работы. CV Разница в затратах между заработанной стоимостью и фактическими затратами на выполненную работу к дате: CV = EV – АС. SV Разница в стоимости: разница между планируемой (в деньгах) стоимостью фактически выполненной работы и стоимостью работы (в деньгах), как она оценивалась до выполнения, т.е. по плану, в конкретный момент времени: SV = EV – PV. (На конкретный момент по плану запланировано, что такая-то работа должна быть выполнена, но она еще не выполнена полностью, т.е. не заработала весь свой бюджет. От этого «всего» бюджета отнимают ту часть, которую успела заработать работа, – это и есть SV). BAC Бюджетные затраты при выполнении. Суммарные бюджетные затраты плана или счетов по учету расходов проекта. EAC Прогнозируемые затраты по выполнении. ETC Прогнозируемые затраты для выполнения оставшейся работы. VAC Разница затрат по выполнении. Показатель отражает фактический перерасход или недорасход средств по выполнении. Для интегрирования системы по отслеживанию затрат/сроков необходимо выполнение пяти шагов, первые три из которых выполняются на стадии планирования, последние два – на стадии выполнения проекта. 1. Определить работу, используя метод WBS (объем, наборы работ, задачи, отделы, ресурсы, бюджеты для каждого из набора работ). 2. Составить план работ и использования ресурсов (распределение ресурсов по операциям; хронометраж набора работ и построение на этой основе сетевой модели). 3. Составить схему бюджета по операциям (хронометраж бюджета), используя включенные в них наборы работ. Сводные показатели этих бюджетов станут основным планом и будут называться запланированными бюджетными затратами на хронометрированную работу (PV) (т.е. эти затраты должны произойти в указанную планом дату). Сумма должна равняться бюджетным затратам на все наборы работ, входящие в счета по учету затрат. 4. На уровне набора работ собрать фактические затраты на выполнение работ. Это фактические затраты на выполненную работу (АС). Узнайте, какой процент работ выполнен, и умножьте этот процент на первоначальный бюджет – получится показатель заработанной стоимости, т. е. сколько заработано совершенной работой. 5. Вычислить разницу в стоимости (SV = EV – PV) (на самом деле разница в стоимости говорит о том, выполнена ли работа в срок или нет, но соблюдение сроков выражается в денежных единицах) и разницу в затратах (CV = EV – АС). Подготовьте отчет о состоянии в соответствии с иерархией для каждого уровня руководства – от менеджера набора работ до заказчика или менеджера проекта. Отчет также должен включать проектные сводные данные по отделам и задачам. Кроме того, нужно сверить сроки по факту выполнения с календарным планом, указанным в сетевой модели. Рисунок ниже дает схематическое представление об интегрированной информационной системе, которая включает приемы и системы, рассмотренные в лекциях выше. Анализ информационной системы управления проектом Главная цель создания основного плана – отследить и отчитаться о ходе выполнения проекта, и оценить денежный поток. Таким образом, решающим моментом будет интеграция основного плана с системой измерения результатов. Затраты «хро­нометрируются» в план именно так, как менеджеры ожидают получить заработанную стоимость по ним. Этот подход помогает отследить затраты до их источника. Основной план (PV) – это сумма счетов по учету затрат, а каждый счет – это сумма наборов работ, входящих в этот счет по учету затрат. В основной план обыч­но включают три типа затрат – труд, оборудование и материалы, поскольку это прямые затраты, которые контролирует менеджер проекта. Накладные затра­ты и прибыль обычно добавляются позднее, в процессе бухгалтерского подсчета. Большинство наборов работ должны быть дискретными, короткими по времени и иметь измеряемые итоги. Если материалы и/или оборудование составляют зна­чительную часть затрат в наборах работ, их можно бюджетировать в отдельные наборы работ и счета по учету затрат. Метод анализа разниц­. Метод измерения достигнутого базируется на двух ключевых положениях: 1. Сравнение заработанной стоимости с ожидаемой стоимостью к дате кален­дарного плана. 2. Сравнение заработанной стоимости с фактическими затратами. Эти сравнения могут быть произведены на уровне проекта или вплоть до уров­ня счета по учету затрат. Состояние проекта может определяться для последнего периода, для всех периодов по текущую дату и прогнозироваться до конца проекта. Оценка текущего состояния проекта при использовании метода заработанной стоимости требует наличия трех элементов: планируемых затрат запланирован­ной (к такой-то дате) работы (PV); бюджетных (т.е. плановых) расходов на про­цент выполненной работы (EV) и фактических затрат на процент выполненной работы (АС). По этим данным вычисляются разница в стоимости (SV) и разница в затратах (CV) за каждый отчетный период. Если разница положительная, это говорит о том, что состояние соответствует желаемому, а отрицательная разни­ца – есть проблемы или произошли изменения. Разница в затратах говорит, что затраты на выполненную работу больше или меньше, чем это было запланировано в любой точке жизненного цикла про­екта. Если труд и материалы не разделили, разница в затратах должна быть про­анализирована, с тем чтобы определить, в чем причина – в труде или материалах либо и в том и в другом. Разница в стоимости выражает суммарную оценку всех наборов работ в про­екте, которые должны быть выполнены к отчетной дате. Важно учитывать, что разница в стоимости не содержит никакой информации по критическому пути. Разница в стоимости измеряет прогресс в денежных, а не во временных единицах. Таким образом, маловероятно, что любой перевод денег во время даст точную информацию по раннему, плановому или позднему прохождению контрольных точек или крити­ческого пути. Единственным точным методом определения подлинного хода проекта во временных координатах, чтобы выяснить, не запаздывает ли он, будет сравнение календарной схемы сетевой мо­дели проекта с фактической календарной схемой (см. рисунок «Диаграмма Гантта»). Рисунок ниже – образец графика затрат относительно плана с разницами (SV и CV) относительно отчетной даты проекта. График так­же дает представление о том, что предстоит еще выполнить (какая часть работ осталась), и демонстрирует благоприятные/неблагоприятные тенденции. От­метка «сегодня» – отчетная дата (период – 25) – точка, в которой проект пре­бывает в настоящее время. Так как система иерархична, графики одной и той же формы могут быть созданы для различных уровней руководства. На рисунке верхняя линия отражает фактические затраты (АС), понесен­ные в связи с работами по проекту к отчетной дате. Средняя линия – основ­ной план (PV), который заканчивается на 45 днях продолжительности проекта. Нижняя линия – бюджетная стоимость фактически выполненной к отчетной дате работы (EV). Пунктирная линия, продолжающая фактические затраты от отчетной даты до новой прогнозируемой даты окончания проекта, показы­вает пересмотренный прогноз ожидаемых фактических затрат; иными слова­ми, это дополнительная информация предполагает, что затраты на выполнение проекта будут отличаться от запланированных. Про­должительность проекта увеличена и разница в стоимости по выполнении от­рицательна (VAC = ВАС – ЕАС). График затрат относительно плана Еще один уровень графика – проценты. По окончании периода 25 по плану должно быть выполнено 75% работ. По окончании периода 25 стоимость выпол­ненной работы – 50%. Фактические затраты на выполненную к отчетной дате ра­боту – 340 долл., или 85% суммарного бюджета проекта. График предполагает, что проект примерно на 18% превысит затраты и отстанет от графика на 5 единиц вре­мени. Текущее состояние проекта показывает отрицательную разницу в затратах (CV), превосходящую бюджет на 140 долл. (EV – АС = 200 – 340 = -140). Разница в стоимости (SV) отрицательная: -100 долл. (EV – PV = 200 – 300 = -100), т.е. проект отстал от графика. Коэффициенты для отслеживания хода проекта На практике иногда предпочтительней использовать для отслеживания хода проекта и затрат коэффициенты, а не абсолютные значения SV и CV, так как коэффициен­ты можно расценивать как относительные показатели эффективности. Интерпретация коэффициентов а) коэффициенты эффективности. - коэффициент эффективности затрат измеряет эффективность затрат на выполненную к такой-то дате работу, т.е. сколько приходится выполненной работы в денежном выражении на одну единицу вложенных средств. Данный коэффициент является наиболее универсальным и распространенным. CPI = EV/AC. - коэффициент выполнения плана отража­ет эффективность в стоимости (т.е. отражает ход проекта относительно плана) на отчетную дату, т.е. сколько в денежном выражении выполнено работ на каждую денежную единицу запланированного бюджета на отчетную дату. SPI = EV/PV. б) коэффициенты выполнения проекта в процентах. - коэффициент процентного выполнения исходя из бюджетных затрат показывает на сколько процентов в денежном выражении выполнена работа относительно общего бюджета на отчетную дату. PCIB = EV/BAC. - коэффициент процентного выполнения на основе фактических затрат показывает завершенность с точки зрения фактически потраченных денежных средств на выполнение работы на отчетную дату и будущих затрат, которые будут иметь место при реализации проекта. PCIC = АС/ЕАС. Прогнозирование окончательных затрат по проекту Обычно применяют два метода пересмотра будущих затрат. 1) Первый метод позволяет экспертам на месте изменить первоначальную про­должительность основного плана и затраты, так как новая информация говорит им о том, что первоначальные оценки не точны. ЕАСre = АС + ЕТСre, где ЕАСге – пересмотренные прогнозируемые затраты по выполнении; АС – общие фактические затраты на выполненную работу к отчет­ной дате; ЕТСге – пересмотренные прогнозируемые затраты на выполнение оставшейся работы. 2) Второй метод используется на больших проектах, где на первоначальный бюджет нельзя слишком полагаться. Этот метод использует фактические затраты к отчетной дате с учетом коэффициента эффективности CPI примени­тельно к оставшейся работе по проекту. EACf = ETC + AC, ETC = оставшаяся работа / CPI = (BAC – EV) / (EV/AC). где EACf – прогнозируемые суммарные затраты по выполнении; ЕТС – прогнозируемые затраты на выполнение оставшейся работы; АС – общие фактические затраты на работу, завершенную к отчет­ной дате; CPI – коэффициент эффективности затрат к отчетной дате; ВАС – суммарный бюджет основного плана; EV – общие затраты бюджета на работу, которая должна быть выполнена к отчетной дате. В рамках второго метода часто рассматривается еще один коэффициент – коэффициент будущей эффектив­ности, который показывает, сколько должна принести каждая оставшаяся в бюджете денежная единица, чтобы проект уложился в бюджет. TCPI = (BAC – EV) / (BAC – AC). Прочие вопросы контроля 1. Разрастание объема. Крупные изменения в объеме легко установить. Проблема возникает тогда, когда незначительные улучшения перерастают в крупные изменения объема. Эти небольшие улучшения или повышение качества носят название «разрастание объема». Хотя изменения объема в основном расцениваются отрицательно, могут быть ситуации, когда разрастание объема приводит к положительным итогам. Небольшие изменения в процессе производства могут вывести продукт на рынок на месяц раньше срока или снизить затраты на производство. Разрастание объема наступает в основном на проектах ново­го продукта. Требования заказчика на дополнительные функции, новые технологии, изменение дизайна, – все это формирует давление на проект с целью разрастания его объема. Часто эти изменения незначи­тельны и проходят незамеченными, пока не станут очевидны задержки во времени или перерасход средств. Тогда разрастание объема скажется на проекте, компании и по­ставщиках. Изменения в объеме меняют требования к потокам денежных средств компании – требуется меньше или больше ресурсов, а это может сказаться и на дру­гих проектах. Частые изменения неизбежно снизят мотивацию команды и уровень сплоченности. Ясные цели команды изменяются, они уже не настолько полно конт­ролируются и перестают быть центром командных действий. Начиная все заново, команда деморализуется – нарушен ритм, снижается производительность. Постав­щики по проекту не любят частые изменения, так как они приводят к росту затрат и сказываются на их командах так же, как и на команде проекта. Чтобы избежать подобной ситуации важно, чтобы первоначальный основной план был хо­рошо определен и согласован с заказчиком проекта. Прежде чем проект начнется, необходимо, чтобы процедуры изменения объема были согласованы между заказ­чиком и проектной командой. Если изменение объема необходимо, его влияние на основной план должно быть ясно и понятно, т.е. должно быть задокументиро­вано. Речь идет о влиянии на затраты, время, зависимости, спецификации, обязан­ности и т.д. Наконец, изменение объема должно быть быстро внесено в основной план – его необходимо перестроить с точки зрения бюджета и сроков; эти измене­ния и их последствия должны быть переданы всем стейкхолдерам проекта. 2. Изменения в основном плане. Изменения на протяжении жизненного цикла проектов неизбежны и будут происходить в любом случае. Некоторые изменения могут быть очень выгодными для итогов проекта; изменений, которые скажутся отрицательно, необходимо из­бегать. Скрупулезное определение проекта может минимизировать потребность в изменениях. Ценой плохой формулировки проекта могут стать изменения, которые приведут к перерасходу средств, поздним срокам, низкому моральному духу и потере контроля. Изменения приходят от внешних источников или изну­три. Внешний вариант: заказчик может затребовать изменений, которые не были включены в первоначальный документ об объеме и которые потребуют значи­тельных изменений проекта и основного плана. Или регулирующие органы могут принять новую резолюцию. Внутренний вариант: стейкхолдеры могут выявить непредвиденные проблемы или улучшения. В редких случаях изменения исходят от нескольких источников. Обычно менеджеры проекта тщательно отслеживают изменения в объеме. Они должны соглашаться с такими изменениями только в том случае, когда ясно, что проект не состоится без этих изменений, когда его можно значительно улуч­шить с их помощью или когда их желает и оплачивает заказчик. На рисунке ниже отражены последствия по затратам после изменения объема – как это сказалось на основном плане в конкретный момент – «на сегодня». Изменения объема, отразившиеся на основном плане Линия А – изменения в объеме, результатом которых станет рост затрат. Линия В – изменения в объеме, результатом которых станет снижение затрат. Если быстро ввести изменения в объеме в основной план, можно пересчитать заработанную стоимость. Если этого не сделать – будут использоваться не те значения разниц в затратах и стоимости. Однако не следует изменять план, чтобы скрыть плохую эффективность прошлой или текущей работы. Распространенный сигнал о такого рода изменениях плана – когда их делают регулярно, словно подгоняют под результаты. На практике такую ситуацию называют «резиновым планом». Большая часть изменений не приведет к серьезному изменению объема, и они должны быть урегулированы как положительные или отрицательные отклонения. Изменения задним числом по выполненной работе допускать нельзя. Нельзя допускать перевода средств со счета на счет, если работа уже выполнена. Непредвиденные изменения можно урегулировать с помощью резерва на случай непредвиденных обстоятельств. Решение на этот счет обычно принимает менеджер проекта. На некоторых крупных проек­тах все решения об изменениях принимаются партнерской группой, куда входят члены команд проекта и заказчика. Лекция 9 ЗАКРЫТИЕ ПРОЕКТА Тщательное управление стадией закрытия не менее важно, чем управление любой другой стадией проекта. Компании, которые умело осуществляют закрытие и анализ, в дальнейшем процветают. Это те компании, которые не имеют проектов, продолжающихся бесконечно долго, и которые не повторяют ошибок. Заключительная фаза проекта включает большое количество заданий. В прошлом и на небольших проектах обязанностью менеджера проекта было проконтролировать, чтобы все задания были завершены и не было нерешенных вопросов, так называемых «свободных концов». Этот подход уже не актуален в наши дни. Сегодня в проектных организациях, в которых много проектов выполняются одновременно, ответственность за задачи по закрытию распределены между менеджером проекта, проектными командами, офисами по управлению проектами, надзорным органом и независимым экспертом по извлечению уроков ретроспективным методом. Многие задания накладываются друг на друга, проис­ходят одновременно и требуют координации и сотрудничества среди указанных сторон. Три главные задачи закрытия проекта описаны и представлены на рисунке ниже. Задачи по закрытию проекта и анализ 1. Сворачивание проекта. Главное задание по сворачиванию проекта – убе­диться, что проект одобрен и принят заказчиком. Прочие виды деятель­ности по сворачиванию включают: оплату и закрытие счетов, перераспределение оборудования и персонала, поиск новых возможностей для работников проекта в плане дальнейшей работы, закрытие объектов и окончательный отчет. 2. Оценка результатов (хода проекта) и качества управления проектом. Оце­нивается эффективность команды, отдельных членов команды и проект-менеджера. Оценка главных игроков дает важную информацию на будущее. 3. Извлечение уроков ретроспективным методом. Извлечение уроков должно способствовать успеху текущих и будущих проектов. Сегодня извлечение уроков по ретроспективной методологии большей частью входит в ком­петенцию независимого эксперта. Этот эксперт также обеспечивает главные данные для отчета о закрытии проекта, который включает полученные уроки. Эти послепроектные заключения должны обсуждаться командой на предмет охвата всех вопросов. Проекты закрываются по многим причинам. Не все проекты получают четкое определение «завершен» и сдаются заказчику. Безотносительно к условиям, по которым проект заканчивается, сам процесс закрытия однотипен, хотя итоги могут быть самыми разными. Типы закрытия проектов а) Нормальное. Наиболее распространенная ситуация с закрытием проекта – просто завершенный проект. б) Раньше положенного срока. Для некоторых проектов возможна такая ситуация: досрочное завершение, когда некоторые части проекта исключаются. Например, в проекте развития нового продукта менеджер по маркетингу может настаивать на производстве моделей перед испытаниями с целью завершить его быстрее и начать производство. Прежде чем поддаться этой форме давления, должны быть тщательно проанализированы и оценены высшим руководством и всеми участниками последствия и риски, которые ассоциируются с этим давлением. в) «Вечные» проекты. Некоторые проекты могут длиться неопределенно долгое время, так что люди свыкаются с мыслью, что они «вечные». Отличительная особенность такого проекта – постоянные добавления, что предполагает плохо сформулированный объем проекта. В какой-то момент группа, занимающаяся анализом, должна рекомендовать, как с этим покончить или как начать новый проект. Например, добавив новую функцию к старому проекту, можно заменить целый сегмент «нескончаемого» проекта. г) Провальные проекты. Это проекты, которые обычно легко идентифицировать и после анализа особой группой – закрыть. Однако необходимо всеми средствами сообщить остальным технические или прочие причины отмены проекта; ни при одном раскладе нельзя допускать, чтобы участники проекта несли на себе чувство вины за отмененный проект или чтобы у них возникло чувство, что они просто участвовали в нем. Многие проекты заканчиваются неудачей, потому что есть обстоятельства, над которыми команда проекта не властна. д) Изменение приоритетов. Приоритеты компании часто меняются, а страте­гия приобретает иное направление. Например, во время финансового кризиса 2008-2010 гг. компании сменили приоритет – они перешли от проектов для полу­чения прибыли к проектам по сохранению и экономии средств и снижению затрат. Группа по надзору непрерывно пересматривает отбор проектов в соответствии с изменениями в направлении развития компании. Проекты, которые не заверше­ны, могут быть заменены или отменены. Иными словами, проект может начать­ся с высоким приоритетом, но его статус будет значительно снижен или отменен во время жизненного цикла, по мере того как меняются условия. Если меняются приоритеты, то и проекты могут стать ненужными. Операции по закрытию проектов Для менеджера проекта и участников операции по сворачиванию проекта часто бывают проблематичными. Большая часть ра­бот рутинна и скучна. Мотивация может стать проблемой номер один. Например, отчет за передачу оборудования и составление окончательных отчетов выглядят примитивной административной работой для профессионалов проекта, так как они ин­дивидуалисты, ориентированные на действия. Проблема для менеджера проекта заключается в том, чтобы заставить команду все же думать об оставшейся работе и сдаче заказчику. Передав участникам план-график закрытия заранее, получится: (1) что команда примет факт, что проект рано или поздно закончится, и (2) будет подготовлена к переходу на другие проекты. Идеальный сценарий – подготовить назначение для членов команды и объявить об этом, когда проект завершен. Этим можно тонко подогреть энтузиазм членов в плане завершения про­екта и требовать от подчиненных соблюдения сроков. Осуществлять процесс закрытия следует через несколько операций сворачи­вания. Ниже указаны шесть главных из них: 1. Получить «добро» от заказчика, что проект принят. 2. «Отключиться» от используемых ресурсов и высвободить их для новых проектов. 3. Объявить о новых назначениях членов команды. 4. Закрыть счета и проверить, все ли счета оплачены. 5. Сдать проект заказчику. 6. Написать заключительный отчет. Выполнение всех деталей по закрытию проекта может показаться непосильной ношей. Некоторые компании имеют контрольные перечни, включающие более сотни пунктов. Там подробно расписано, что делать с объектами, командами, пер­соналом, заказчиками, продавцами и самим проектом. Фрагмент такого списка приводится ниже. Контрольный перечень вопросов по закрытию проекта Задание Выполнено (да/нет) Команда 1 Готов и утвержден ли график роспуска персонала? 2 Объявили ли членам команды, что они свободны / или получили новое назначение 3 Были ли сделаны оценки работы членов команды 4 Были ли персоналу предложены услуги по дальнейшему трудоустройству и консультации по карьерному росту? Подрядчики 5 Был ли проведен анализ работы каждого подрядчика? 6 Закрыли ли счета по проекту и оплачены ли они? Заказчик / пользователи 7 Выдал ли заказчик документ по приемке продукта? 8 Состоялась ли с заказчиком беседа для анализа проекта «вглубь» и его оценки? 9 Опрошены ли пользователи – насколько они довольны результатом, командой проекта, подрядчиками, техническим обслуживанием и пр. Оборудование и объекты 10 Были ли ресурсы по проекту переданы на другие проекты? 11 Закрыли ли договоры по аренде оборудования? 12 Назначена ли дата для анализа по случаю закрытия проекта и извещены ли об этом участники? Получить «добро» от заказчика при сдаче проекта – главная и критическая операция закрытия. Сдача заказчику на одних проектах проста, на других – бо­лее сложная и трудная. Условия для завершения и сдачи проекта должны быть заданы еще до того, как начнется проект. Один из известных подходов к сдаче проекта относится к аутсорсингу – «строй, получай в собственность, рабо­тай и передавай». При таком варианте подрядчик строит объект, получает его на время в собственность и опробирует результаты проекта. В течение этого времени изъяны и проблемы устраняются, так что появляются благоприятные условия для сдачи объекта. Роспуск команды проекта обычно наступает постепенно на стадии заверше­ния. Для некоторых людей отмена их обязанностей происходит еще до того, как проект сдан заказчику. Новые назначения для этих участников должны быть произведены задолго до даты окончания проекта. Для остальных членов команды (как совместителей, так и штатных участников) прекращение обязанностей может привести к назначению на новый проект или возврату к своим прямым обязанностям. Иногда при развитии продукта члены команды назначаются на операционные должности и активно участвуют в про­изводственной части нового продукта. Для подрядчиков это может означать конец работы по данному проекту. Так как многие счета-фактуры не выставляются до тех пор, пока проект не будет официально завершен, закрытие контрактов становится хлопотливым занятием. Контрактная документация (отчеты о выполнении, счета-фактуры, записи об изменениях и записи об оплате) оформляется на случай претензий или судебных разбирательств. Часто, торопясь уложиться в сроки, менеджеры пренебрегают «бумажной» работой, а потом это оборачи­вается крупной головной болью – когда приходит время готовить окончатель­ную документацию. Есть еще много других операций по сворачиванию проекта; важно выполнить их все. Опыт показывает, что, если оставить часть этих небольших заданий невыполненными, появятся проблемы в будущем. Заключитель­ная операция сворачивания, которая дает ясный сигнал о завершении проекта, – представление окончательного отчета о проекте. Окончательный отсчет по проекту подытоживает результаты проекта и дает полезную информацию для непрерывного улучшения. Содержание окончательного отчета обычно включает следующие части: а) Отчет о проделанной работе. Этот отчет просто освещает ключевые откры­тия и факты, связанные с реализацией проекта. Например, были или не были до­стигнуты цели проекта по заказчику; удовлетворены ли стейкхолдеры тем, что их стратегические намерения реализовались; как среагировал пользователь на каче­ство и результаты; задачи проекта использовались, как было задумано, и они дали ожидаемые выгоды; окончательное время проекта, затраты и объем. Указывают­ся все главные проблемы, с которыми столкнулись на проекте, и как ими занима­лись. Ключевые уроки, которые извлекли. б) Анализ. Данные о ходе проекта, эффективности руководства и извлеченных уроках изучаются с целью улучшить будущие проекты. Анализ детально опи­сывает основополагающие причины проблем и успехов. Кратко делается разбор «по факту» – как следовали миссии проекта и целям, процедурам, как исполь­зовали ресурсы компании. Принято собирать данные, «увиденные» компанией и командой проекта. ОУП или эксперты часто используют вопросники, чтобы выбрать те вопросы и события, которые должны быть рассмотрены в дальней­шем. Например, «Был ли у команды достаточ­ный доступ к ресурсам компании – людям, бюджету, отделам, оборудованию?» ОУП также представляет графики по проекту, сравнение затрат, данные по объ­ему и прочие необходимые данные, по которым можно составить «историю» результативности. Эта информация используется при создании окончательного отчета по проекту. в) Рекомендации. Обычно рекомендации – это главное, что можно сделать для улучшения. Они зачастую технические по своей природе и сфокусированы на решении возникших проблем. Например, чтобы избежать переделок, отчет по строительному проекту рекомендовал перейти на более прочные строитель­ные материалы. В других случаях они могут включать отказ от подрядчика или приостановку работы с ним. г) Извлечение уроков. Вероятно, извлеченные уроки – самый ценный вклад про­цесса закрытия. Если получены данные и оценки от стейкхолдеров, уроки должны быть кратко и четко сформулированы. На практике команды новых проектов, изучающие отчеты по прошлым проектам, подобным их нынешнему, извлекают немало по­лезной информации. д) Приложение. Приложение может включать дублирующие данные или под­робности анализа, который позволит другим «углубиться» в тему, если есть желание. Сюда не нужно включать лишнее, только критически важную информа­цию. Оценка по завершении проекта Цель оценки проекта – выяснить, насколько хорошо работали команда про­екта, члены команды и менеджер проекта. Оценка команды. Оценка результативности крайне важна в том плане, что она стимулирует к из­менениям в поведении и поддерживает индивидуальные карьерные амбиции, а также непрерывное улучшение работы самой компании. Оценка подразумева­ет сравнение с конкретными критериями. Перед тем как начать оценку работы команды проекта и для того, чтобы она была максимально эффективной и полезной, необходимо установить минимум главных условий этой оценки до того, как начнется проект. Некоторые типичные условия перечислены ниже в форме вопросов. 1. Существуют ли стандарты для измерения результатов? (Невозможно управ­лять тем, что нельзя измерить.) Ясны ли для команды и отдельных членов цели? Являются ли они дости­жимыми? Приводят ли к положительным результатам? 2. Знают ли отдельные члены команды индивидуальные и командные обязан­ности и стандарты результативности? 3. На должном ли уровне награда для команды? 4. Намечен ли карьерный путь для успешных проект-менеджеров? 5. Есть ли у команды полномочия для решения текущих проблем без привле­чения вышестоящих начальников? 6. Обеспечивает ли достаточно высокий уровень доверия корпоративная культура? 7. Оцениваться команда должна не только на основе сроков, затрат и качества работы. Есть ли еще критерии оценки? Эти установленные заранее условия поддержат любой подход к оценке команд­ной работы и отдельных членов. На практике реальный процесс оценки команды принимает много форм, осо­бенно когда выходит за пределы сроков, бюджета и качества. Типичный механизм оценки команд – опрос, который выполняют консультант, работник отдела ка­дров или который проводится автоматизированно с помощью электронной по­чты. Опрос обычно ограничен членами команды, но иногда к нему подключаются другие участники. Ниже приведен фрагмент опроса. После того как результаты занесены в таблицу, команда встречается с экспертом и/или высшим руководством, и результаты анализируются. Пример опроса по оценке командной работы По приведенной шкале оцените утверждение: не согласен согласен 1. Команда имеет коллективное чувство общих целей, и каждый член делал все для достижения целей проекта. 1 2 3 4 5 2. С уважением относились к точке зрения других членов. Мнения выражались свободно и различия во мнениях поощрялись. 1 2 3 4 5 3. Любое взаимодействие между членами проходило в дружественной, поддерживающей обстановке. 1 2 3 4 5 Результаты опроса следует исполь­зовать для оценки развития команды, ее сильных/слабых сторон и извлечения уроков, которые могут быть применены к будущей работе. Результаты опроса по оценке командной работы помогают улучшить коммуникацию, усилить командный подход и повысить результативность. Оценка отдельных работников. Компании очень по-разному организуют процесс повышения в должности членов команды по рекомендации проект-менеджера. Если в компании про­екты не выходят за рамки какой-либо области, начальник отдела, а не менед­жер проекта, будет характеризовать члена команды. Начальник отдела может полагаться на мнение менеджера проекта в плане оценки работника по кон­кретному проекту; но потом он все равно присовокупит эту оценку к общей оценке работника. В таком случае оба менеджера совместно оценивают результативность работника. В компаниях, где львиная доля работы отдельных работников связана с проектами, менеджер проекта будет сам оценивать работу подчиненного. Сегодня все бо­лее распространенным становится метод оценки по принципу «360 градусов», который заключается в том, что работника оценивают на основании оценок всех людей, с которыми он взаимодействовал и кого так или иначе касается его работа. Сюда входят не только начальники отделов и менеджеры проек­тов, но и конкуренты, подчиненные и даже заказчики. Оценка результатов работы обычно выполняет две важные функции. Пер­вая – развитие: акцент делается на идентификации сильных/слабых сторон индивидуума, составлении плана развития для улучшения результатов. Вторая функция – оценочная и заключается в оценке результатов, чтобы решить вопрос с жалованьем или квалификацией. Компании задействуют широкий спектр методов, призванных оценить инди­видуальную результативность по проекту. В целом методы анализа индивидуаль­ной результативности проверяют технические и межличностные навыки, которые необходимы при выполнении проекта. Многие компании используют рейтинговую шкалу, аналогичную используемой при оцен­ке команды, в которой проект-менеджер оценивает работника согласно опреде­ленной шкале (например, от 1 до 5) по ряду аспектов (работа в коман­де, отношения с заказчиком, пр.). Менеджер проекта должен сесть с каждым членом за стол и обсудить его результативность. При этом еще в ходе реализации проекта менеджеру необходимо постоянно давать членам команды обратную информа­цию – они должны совершенно ясно представлять, насколько они хорошо справляются со своей работой и что им ска­жет менеджер во время беседы. Оценка менеджера проекта Хотя во многих случаях процесс, который применен при анализе членов ко­манды, используется и в отношении менеджера проекта, многие компании рас­ширяют этот процесс с учетом важности этой должности для их компании. Имен­но тогда подход «анализ на 360 градусов» становится более популярным. Там, где главное – проекты, сбором информации от заказчиков, подрядчиков, членов ко­манды, конкурентов и других менеджеров по конкретному менеджеру проекта бу­дет заниматься ОУП. Данные собираются не только для оценки результатов работы, но и для извле­чения уроков. Извлечение уроков Усвоенные уроки отражают анализ, осуществляемый во время и сразу по за­вершении жизненного цикла проекта; они нацелены на то, чтобы усвоить как по­ложительный, так и отрицательный опыт. Процесс усвоения уроков постоянно эволюционирует, но на сегодняшний день есть еще много барьеров, препятствующих эффективному использованию результатов работы. Ниже приводятся некоторые из таких барьеров. - самая распространенная причина – нет времени; - большую часть работы над ошибками можно провести уже после того, как проект закончен; это значит, что после доклада об уроках команды уже не получают значимой поддержки и их реальные действия мало кому инте­ресны; - извлечение уроков часто переходит в поиски виновных – это только разру­шает людей эмоционально; - даже когда работа над ошибками произведена и уроки усвоены, они не ис­пользуются в других ситуациях; - никогда или почти никогда не практикуется подход, при котором работа над ошибками делается еще в ходе самого проекта, чтобы улучшить остав­шуюся работу по нему; - слишком часто работа над ошибками не используется на будущих проек­тах – по той причине, что в корпоративной культуре не заложена ценность обучения на собственном опыте. Один из приемов, нивелирующий барьеры – ретроспективный метод. Этот метод уже давно использу­ется военными, чтобы улучшить боевые действия (например, после каждого ма­невра). Ретроспективная методология анализирует события прошлых проектов на предмет того, что получилось, а что нет, делает работу над ошибками и создает план действий, который гаран­тирует, что извлеченные уроки будут использованы в будущем – для управления будущими проектами. Главные цели ретроспективного метода – использовать найденные решения повторно и прекратить делать одни и те же ошибки всей компанией. Ретроспективная методология имеет несколько отличных характеристик, кото­рые делают ее эффективной и ценной: - использует независимого эксперта; - включает минимум трое «ворот» для извлечения уроков на протяжении жизненного цикла проекта; - имеет куратора; - создает базу данных, удобную в применении; - обязывает к применению извлеченных уроков. Процесс анализа зависит главным образом от размера компании и размера проекта. В небольших компаниях и на проектах, где контакт лицом к лицу на всех уровнях превалирует, закрытие может иметь неофициаль­ную форму и включать только очередное собрание персонала. Но даже в таких средах содержание официального анализа проекта должно быть рассмотрено и помечено сносками на полученные уроки. В некоторых компаниях инициатива по анализу исходит от официальной группы для анализа проекта или подразуме­вается по умолчанию. В большинстве других многопроектных компаний анализ подогнан под основные контрольные точки. При этом неважно, как организован анализ, его структуру нужно создать на стадии планирования проекта – до того, как начнется проект. Ретроспективная методология задействует независимого эксперта для сбо­ра и внедрения полученных уроков с целью повышения уровня управления те­кущими и будущими проектами. Эксперт по проекту – это проводник, который направляет команду проекта через анализ операций проекта, которые прошли успешно и не очень успешно, и помогает составить план последующих действий с целями и подотчетными лицами. При этом эксперт по закрытию проектов обязательно должен обладать следующими характеристиками: - не должен напрямую иметь интересы в проекте; - его должны воспринимать окружающие как не относящегося ни к чьей сто­роне и справедливого. - его должны уважать высшее руководство и другие стейкхолдеры проекта. - желание и умение выслушать. - независимость и авторитет в том плане, что он не должен бояться доложить о таких результатах анализа, которые могут навредить ему или чьим-либо интересам. - должен восприниматься как лицо, принимающее решения и исключитель­но в интересах компании. - разносторонний опыт в делах компании или отрасли. Иметь своего эксперта предпочтительней уже на старте проекта. Подход рас­считан специально на сбор усвоенных уроков во время выполнения проекта и ис­пользования этих знаний для изменения оставшейся работы. Если не усвоить получен­ные уроки сразу же, потом может быть поздно. Большая часть методов ретроспективного анализа основана на мини­мальном количестве из трех «ворот» на протяжении жизненного цикла проек­та, где и происходит усвоение уроков, с тем, чтобы скорректировать дальнейший курс. На рисунке ниже изображена схема потока, показывающая, как усваиваются уроки. Процесс извлечения уроков из ретроспективного анализа Извлеченные уроки – это часто единственная и самая лучшая информация, которую может использовать менеджер проекта или команда при планировании будущих проектов. При ретроспективном подходе эксперт использует несколько анкет как отправную точку для проведения послепроектного анализа. Через такие опросы можно докопаться до скрытых причин, о которых до анкетирования не было известно. Анализ процесса начинается с анализа стратегических целей проекта, крите­риев отбора, устава проекта, задач проекта, объема проекта и критериев приемки. Эта отправная точка усиливает и проясняет бизнес-кейс проекта и окончательные результаты проекта. Сбор дополнительных данных для анализа процесса произ­водится с помощью вопросника, который передают главным стейкхолдерам про­екта, чтобы те выразили свое мнение. Некоторые типичные вопросы, которые используются, приведены в таблице ниже. Вопросник для анализа проекта Вопрос Комментарии 1 Были ли ясно и прямо переданы всем цели проекта и стратегическое значение? 2 Соответствуют ли друг другу цели и стратегия? 3 Были ли идентифицированы и включены в планирование стейкхолдеры? 4 Были ли ресурсы проекта достаточными для проекта? 5 Обладал ли необходимыми навыками персонал, назначенный на проект? 6 Были ли реальными и достижимыми сроки? 7 Правильно ли оценили риски перед тем, как начался проект? 8 Соответствовали ли этому типу проекта процессы и методы? Должны ли проекты такого же размера и типа использовать те же системы? Почему? Почему нет? 9 Сделали ли внешние подрядчики все так, как от них ожидали? Объясните. 10 Были ли методы коммуникации соответствующими относительно всех стейкхолдеров? Объясните. 11 Был ли заказчик доволен результатом проекта? 12 Используют ли пользователи результаты проекта как ожидалось? Они удовлетворены? 13 Достигнуты ли цели проекта? 14 Были ли достигнуты стратегические задачи, к удовлетворению стейкхолдеров? 15 Заказчик или спонсор принял официальное заявления, что условия устава проекта и документа об объеме были соблюдены? 16 Были ли соблюдены сроки, бюджет и стандарты объема? 17 Есть ли какая-нибудь важная область, которую необходимо проанализировать и улучшить? Можно ли идентифицировать причину? Располагая информацией на основе ответов, эксперт потом наедине беседует с каждым членом команды, проект-менеджером и другими участниками, чтобы глубже погрузиться в поиск причин. Его задача заключается главным образом в отборе «нехватка х привела к у». Важно выделить наиболее значимые уроки. Вооруженный информацией, полученной из индивидуальных бесед и других источников, эксперт проводит ретроспективную сессию. Эта сессия сначала по­священа анализу отчета эксперта и призвана добавить ключевую информацию. Фактически одна из ролей эксперта – направлять команду на поиск новых путей решения проблемы. Как только команда достигнет консенсуса по ключевым вопросам, она составляет план действий для улучшения будущих проектов. Каждые «ворота» должны строиться минимум в течение одного урока, что улучшит теку­щие или будущие проекты. Один человек должен стать ответственным за усвоенный урок и «куратором», к которому остальные будут обращаться за разъяснени­ями. Дополнительной задачей эксперта является анализ архивных уроков, чтобы можно было определить тенденцию по схожим проектам. Например, есть ли сходство между неудачами или успехами среди многих проектов? Достаточными ли были ресурсы? Поддерживало ли внедрение извлеченных уроков высшее руководство? Какие фундаментальные аспекты культуры компании влияют на успехи/неудачи проектов или мешают проектным командам? Еще одна задача эксперта по ретроспективному анализу – гарантировать, что су­ществует четкий процесс, в ходе которого урок будет усвоен и использован, чтобы улучшить управление будущими проектами. Если используется ретроспективный подход, некоторые компании ставят обязательное условие, чтобы команда нового проекта проводила анализ ошибок аналогичных проектов. При ретроспективном методе важно создать хранилище, где отчеты и извле­ченные уроки будут удобны для доступа. Обычно это делается с помощью сайта в Интернете или посредством других электронных средств. За таким хранилищем обычно следят ОУП или надзорная комиссия, которые должны также стимулировать других к пользованию ресурсом. Последнее зависит от того, насколько легко искать информацию, которая отвечает проекту. Заключительная операция для экс­перта – отметить закрытие проекта. Необходимо, чтобы каждый порадовался по­лученному опыту и с открытой душой попрощался с коллегами. Празднование – это возможность отдать должное заслугам каждого участника проекта. Даже если проект не решил поставленных задач, необходимо публично признать те усилия и достигнутые цели, которые все-таки имели место. А если проект был успешным, нужно пригласить всех, кто, так или иначе, внес свой вклад в общее дело.