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

1. Основные понятия управления проектами 1.1. Управление проектом Ключевым понятием управления проектами является проект. Существует много определений этого понятия. Проект – усилие, направленное на создание уникальных продуктов, услуг или получение результатов с надлежащим качеством, в рамках ограничений по срокам и бюджету. В различных статьях, учебных пособиях и научных трудах специалистов много внимания уделяется понятию «проект», приводится множество вариантов определений, например: Прое́кт — это уникальная (в отличие от операций) деятельность, имеющая начало и конец во времени, направленная на достижение определённого результата/цели, создание определённого, уникального продукта или услуги, при заданных ограничениях по ресурсам и срокам, а также требованиям к качеству и допустимому уровню риска. Термин проект происходит от латинского слова projectus, что в переводе означает «брошенный вперед», «выступающий», «выдающийся вперёд», «торчащий»». США, Институт Управления Проектами (PMI): «Проект — это временное предприятие, осуществляемое с целью создания уникального продукта или услуги». Великобритания, Английская Ассоциация менеджеров проектов: «Проект — это отдельное предприятие с определенными целями, часто включающими требования по времени, стоимости и качеству достигаемых результатов». Германия, DIN 69901: «Проект — это предприятие (намерение), которое в значительной степени характеризуется неповторимостью условий в их совокупности, например:  задание цели;  временные, финансовые, людские и другие ограничения;  разграничения от других намерений;  специфическая для проекта организация его осуществления». Мировой Банк, «Оперативное руководство» № 2.20: «Понятие «проект» обозначает комплекс взаимосвязанных мероприятий, предназначенных для достижения, в течение заданного периода времени и при установленном бюджете, поставленных задач с четко определенными целями». Проект - это средство стратегического развития. Цель – описание того, что мы хотим достичь. Стратегия – констатация того, каким образом мы собираемся эти цели достигать. Проекты преобразуют стратегии в действия, а цели в реальность. Таким образом, каждая работа, которую выполняет конкретный сотрудник, привязывается к достижению стратегических целей организации. 1 Цель Стратегия Портфель Программа Проект Работа Рис. 1. Взаимосвязь проектов со стратегией компании. Причина такого внимания к понятию «проект» в том, что методы и инструменты управления проектами эффективно применять именно к проекту. Однако, далеко не вся работа, ведущаяся в организации, является проектами. Поэтому компании, внедряющие управление проектами, часто испытывают затруднения с разделением проектов и операционной деятельности. К примеру, является ли курс обучения сотрудников проектом? Любой курс имеет ограниченные сроки проведения, бюджет, требования к качеству. Для курса могут быть определены цели. Таким образом, курс обучения можно рассматривать как проект. Но, если компания проводит десятки курсов в год, и деятельность по организации обучения является рутинной, повторяющейся, не несет никакой уникальности в плане управления, – является ли курс проектом? Необходимо ли применять методы управления проектом для каждого курса, например, назначать руководителя проекта и создавать график проекта? Аналогичная ситуация может возникать на заводе, производящем машины. Каждая машина может рассматриваться как небольшой проект. В приведенных примерах, скорее всего, курс обучения и производство машины проектами не являются. Фактически, в предложенном контексте массового производства машин и проведения курсов, компания реализует серийное производство типовых продуктов и услуг без явного ограничения этой деятельности по срокам. У каждого проекта есть четко определенные начало и окончание. Проект заканчивается вместе с достижением всех его целей или наоборот, когда становится ясно, что эти цели не могут быть достигнуты. Временность не означает краткосрочность проекта - многие проекты могут продолжаться несколько лет. В любом случае, проект конечен и не может состоять из постоянно продолжающихся действий. 2 Очень многие предприятия временны в том смысле, что в какой-то момент работа на них остановится. Например, понятно, что конвейер по производству определенной модели автомобилей когда-то остановится, так как машина будет снята с производства. Однако такой род временности не делает конвейер проектом, поскольку работа по сборке машин является типичной рутинной операционной деятельностью. Фундаментальное отличие проекта заключается в том, что проект заканчивается, когда поставленные цели достигнуты, тогда как при непроектной деятельности перед исполнителями ставятся новые цели и работа продолжается. Временная природа проектов сказывается и на других аспектах проектной деятельности. Например, проекты обычно имеют четко очерченные временные рамки для создания продукта или услуги, поскольку благоприятная для них ситуация на рынке складывается на ограниченное время. Кроме того, проектная команда, как правило, по его окончании распадается, а ее члены переходят в другие проекты. В отличие от конвейера по сборке автомобилей хорошим примером проекта может быть разработка нового автомобиля. Разработка осуществляется в ограниченные сроки и продолжается до достижения определенного результата - прототипа нового автомобиля. Когда результат достигнут, автомобиль отправляется в производство, а проектная команда - конструкторы, дизайнеры, инженеры и прочие - могут быть вовлечены в новый проект, хотя и не обязательно в том же составе. Таким образом, операционная деятельность состоит из постоянного повторения одних и тех же операций с целью производства одного и того же продукта (или предоставления одной и той же услуги). Примерами могут служить серийное производство, продажи типовых продуктов, бухгалтерские операции. Основная разница между операционной и проектной деятельностью в том, что операционная деятельность оперирует привычными результатами в устоявшихся бизнеспроцессах, а проектная работа подразумевает уникальные результаты и ограниченный срок работ. Отличия проектной деятельности от операционной: Характеристики Проекты Операции Длительность Временны – имеют начало и Рутинная деятельность окончание (даже если длительность проекта 1 год или 1 день) Конечные цели После достижения поставленных После достижения поставленных целей проект закрывается целей ставятся новые цели и операции продолжаются Результаты Создаются уникальные продукты Поддержка бизнеса или услуги Постепенное уточнение Постепенное уточнение проекта Не обязательно уточнение постепенное Таблица 1. Отличия проектной деятельности от операционной При проведении анализа необходимости применения проектных методов управления необходимо помимо формальных критериев руководствоваться здравым смыслом. Даже небольшая задача может управляться как проект, если например, она является стратегически важной для компании. Управление проектом, это – применение знаний, навыков, инструментов и методов к работам проекта для удовлетворения требований к проекту (PMI). 3 Управление проектом реализуется посредством интеграции групп процессов управления проектами:  Инициация.  Планирование.  Исполнение.  Мониторинг и управление.  Завершение. Процессы управления проектом являются итеративными, производится постоянное совершенствование процессов в жизненном цикле проекта. 1.1.1. Результат и продукт проекта Результат проекта – любой уникальный и проверяемый продукт, результат или услуга, которые необходимо произвести для завершения процесса, фазы или проекта. Часто используется в более узком значении для обозначения внешнего результата проекта, т. е. результата, требующего утверждения спонсором или заказчиком. Результатами проекта также могут являться документы проекта, например, Устав проекта. Продукт проекта - производимое изделие или услуга, которые можно измерить и которое может быть как конечным звеном производственной цепи, так и элементом. (Продукт проекта - более узкое понятие, чем результат). 1.2. Управление программой проектов Помимо проекта, дисциплина управления проектами оперирует таким понятием, как программа проектов. Программа – совокупность взаимосвязанных проектов, управление которыми координируется для достижения преимуществ и степени управляемости, недоступных при управлении ими по отдельности. В большинстве случаев проекты программы объединены общей целью. Например, программой проектов можно считать проведение Олимпиады. Проведение Олимпиады возможно рассматривать как один большой проект. Такой проект будет включать большое количество разнообразных работ (строительство новых зданий, дорог, рекламные компании, подготовка команды спортсменов, уборка города, создание талисмана и так далее), объединяет огромное количество участников и заинтересованных лиц, предусматривает множество детальных целей, которые ведут к главной цели – успешному проведению Олимпиады. Из-за сложности и комплексности большие объемы работ принято подразделять на отдельные блоки или проекты. Примером программы, реализуемой конкретной организаций, можно считать развитие нового микрорайона города. Программа включает проекты: строительство домов, строительство дорог, благоустройство территории, строительство общественных зданий, продажа площадей и так далее. Программы могут также включать повторяющиеся, или циклические, работы, например, периодическое издание журнала само по себе является непрерывным процессом операций, тогда как подготовка отдельного номера - это проект. 1.3. Управление портфелем проектов Портфель проектов – набор проектов, программ и других работ, объединенных вместе с целью эффективного управления данными проектами для достижения стратегических целей организации. 4 Портфель проектов компании Стратегии и приоритеты Управление Изменения по другим проектам, программам, портфелям, влияющие на проект Указания на перспективу Портфель проектов бизнеснаправления Отчеты по проектам Запросы на изменения, связанные с другими программами и проектами Проекты Стратегии и приоритеты Управление Изменения по другим проектам, программам, портфелям, влияющие на проект Указания на перспективу Программы Отчеты по проектам Запросы на изменения, связанные с другими программами и проектами Программы нижнего уровня Проекты Проекты Программы Программы нижнего уровня Проекты Проекты Рис. 2. Взаимосвязь портфелей, программ и проектов В отличие от программы, портфель проектов может не иметь ограничений по времени реализации. Таким образом, отличие программы проектов от портфеля состоит в том, что в программе проекты в ней объединены для достижения лучшей управляемости, а портфель объединяется для достижения стратегических целей, чаще всего выраженных в финансовых показателях. Если программу проектов можно сравнить с большим проектом, состоящим их маленьких связанных между собой проектов, то портфель проектов схож с портфелем акций, в котором элементы могут быть никак не связаны друг с другом, но схожи по сути выполняемых работ. В компаниях портфелем проектов чаще всего называют совокупность проектов одного бизнес-направления, реализуемых для достижения стратегических целей данного бизнеснаправления. Например, портфелем проектов можно считать портфель ИТ-проектов, или портфель маркетинговых проектов. Управление программами и проектами фокусируется на том, чтобы «делать вещи правильно», в то время как управление портфелями фокусируется на том, чтобы «делать правильные вещи». 1.4. Цели проекта и критерии успешности Как уже говорилось выше, каждый проект должен иметь определенные заранее цели. 5 Цели проекта – важнейший элемент управления проектом, от которого в итоге во многом зависит успешность проекта. Приведем следующий пример. В крупной компании начинается внедрение информационной системы управления взаимодействием с контрагентами. Руководство компании декларирует для команды проекта и будущего подрядчика по выполнению работ цели:  Повысить эффективность взаимодействия с контрагентами.  Увеличить клиентскую базу компании.  Увеличить количество положительных отзывов потребителей и уменьшить количество жалоб. Определены сроки проекта – 31 декабря и бюджет проекта – 1 000 000 рублей. Команда проекта реализует проект в рамках бюджета, однако, с запаздыванием сроков на два месяца. По окончании проекта информационная система не используется пользователями, руководство компании признает проект неуспешным и увольняет руководителя проекта. Необходимо отметить, что во многом причина такого провала кроется в неправильной постановке целей проекта. Во-первых, цели поставлены неконкретно. Клиентская база могла быть увеличена на 20 контрагентов, что, конечно, очень мало, но, тем не менее, обеспечивает выполнение поставленной цели «Увеличить клиентскую базу компании». Аналогичная ситуация с количеством отзывов потребителей. Кроме того, достижение данных целей можно оценить только после того, как пользователи информационной системы начнут в ней работать и внесут соответствующие данные по истечению периода времени. Во-вторых, как выяснилось к концу проекта, главной целью, которую команда проекта не учла, являлось завершение проекта именно к 31 декабря, так как к этой дате руководство компании должно было отчитаться управляющему совету о выполнении цели. Так как отчитаться о результатах было нельзя, деятельность руководителей была признана неуспешной в целом. В третьих, в целях проекта и в ходе работ были не учтены интересы и желания сотрудников компании - конечных пользователей информационной системы, что привело к саботажу использования системы. Таким образом, небрежная постановка целей зачастую приводит проект к провалу. Цели проекта должны соответствовать требованиям SMART (Specific Специализированные, Mesurable - Измеримые, Actively Influencible - Актуальные, Realistic - Реалистичные, Time Limited – Ограниченные по времени). Для приведенного примера необходимо было определить цели:  Проект завершен к 31 декабря.  После завершения проекта 90% сотрудников используют информационную систему.  Система содержит актуальные данные.  Увеличить клиентскую базу компании на 20 % за полгода использования системы.  Увеличить количество положительных отзывов потребителей на 10% и уменьшить количество жалоб на 10% за полгода использования системы. Такие цели соответствуют требованиям SMART и позволяют команде проекта и руководству компании отслеживать показатели успешности проекта объективно. Для оценки выполнения целей проекта вводят критерии успешности проекта. Проект успешен, если он:  Завершен в установленные сроки.  В рамках выделенного бюджета.  При удовлетворении заказчика. 6 1.5. Руководитель проекта Важнейшим фактором успеха проекта в целом являются личность и навыки руководителя проекта. В качестве лучшей практики и фактически аксиомы в проектном менеджменте можно считать, что для любого проекта должен быть назначен руководитель проекта. Роль руководителя проекта отличается от роли функционального руководителя (например, руководителя отдела). Функциональный руководитель обычно фокусируется на управлении операционным подразделением и ресурсами, и поддержке функциональной области деятельности компании. Руководитель проекта занимается планированием, контролем и мониторингом ресурсов, вовлеченных в проект. Руководитель проекта также несет ответственность за работу с заинтересованными лицами проекта для достижения целей проекта в рамках требований к содержанию, срокам, стоимости и качеству. В зависимости от организационной структуры компании, руководитель проекта может отчитываться функциональному руководителю. В других случаях руководитель проекта может быть одним из нескольких руководителей, подчиняющихся руководителю программы. Обычно это требуется в крупных международных проектах. В структуре такого типа руководитель проекта тесно работает с руководителем программы проекта для того, чтобы интегрировать план проекта с планом программы. Руководитель проекта управляет параметрами проекта, такими как базовые и фактические значения стоимости, сроков текущих и завершенных работ, анализирует эти параметры и отчитывается по ним руководителю программы или портфеля проектов, а также внешним заинтересованным лицам проекта (например, заказчику). 1.5.1. Навыки руководителя проекта Что является идеальной «спецификацией» личности руководителя проекта? Если цели управления проектом заключаются в ответственности за обеспечение выполнения работ в заданные сроки и бюджеты расходов, то существует множество подходов к достижению этих целей. Один менеджер проекта может успешно действовать, внушая своим коллегам страх и дрожь, тогда каждое его слово воспринимается как команда, которой нужно сразу же подчиниться. Другой может получать те же результаты путем спокойного, но твердого убеждения. Основной признак здесь – это способность мотивировать людей любыми способами. Опытный эксперт может изменять стиль руководства в зависимости от типа личности каждого человека, находящегося в его подчинении. Обычный участник проекта будет доволен, если менеджер проекта, который им руководит будет компетентным, способным принимать решения, давать точные и выполнимые инструкции, хорошо делегировать полномочия, слышать и воспринимать устные советы, демонстрировать энтузиазм и уверенность, и таким образом, своим примером и качествами лидера вызывать уважение. Существует много инструментов и методик для управления проектами. Понимание и применение знаний, инструментов и методик, которые признаются лучшими практиками, недостаточно для эффективного управления проектами. В добавление к специфичным для управления проектами знаниям, для успешного ведения проекта требуется, чтобы руководитель проекта и команда проекта овладела тремя областями компетенций управления проектами:  Компетенция по управлению проектами. (Что команда проекта знает об управлении проектами).  Компетенция по реализации проекта. (Что команда проекта может сделать или чего достичь, применяя свои знания по управлению проектом.) 7  1.6. Персональная компетенция. (Как команда проекта ведет себя при выполнении проекта. Персональная компетенция говорит о пригодности и персональных характеристиках). Жизненный цикл проекта Каждый проект независимо от его сложности и объема работ, необходимых для его выполнения, проходит в своем развитии определенные состояния: от состояния, когда «проекта еще нет», до состояния, когда «проекта уже нет». Начало проекта связано с началом его реализации и началом вложения денежных средств в его выполнение. Окончанием существования проекта может быть:  ввод в действие объектов, результатов проекта, начало их эксплуатации и использования результатов выполнения проекта;  перевод персонала, выполнявшего проект, на другую работу;  достижение проектом заданных результатов;  прекращение финансирования проекта;  начало работ по внесению в проект серьезных изменений, не предусмотренных первоначальным замыслом (модернизация);  вывод объектов, результатов проекта из эксплуатации. Обычно как факт начала работ над проектом, так и факт его ликвидации оформляются официальными документами. Состояния, через которые проходит проект, называют фазами (этапами, стадиями). Универсального подхода к разделению процесса реализации проекта на фазы не существует. Решая для себя такую задачу, участники проекта должны руководствоваться своей ролью в проекте, своим опытом и конкретными условиями выполнения проекта. Поэтому на практике деление проекта на фазы может быть самым разнообразным – главное, чтобы такое деление выявляло некоторые важные контрольные точки («вехи»), во время прохождения которых просматривается дополнительная информация и оцениваются возможные направления развития проекта. Каждая фаза должна заканчиваться измеримым, проверяемым результатом. В конце каждой фазы принимается решение об инициации новой фазы или закрытия (консервация) проекта. В свою очередь, каждая выделенная фаза (этап) может делиться на фазы (этапы) следующего уровня (подфазы, подэтапы) и так далее. 8 Пример жизненного цикла проекта приведен на рисунке ниже. Запрос от инициатора GO/NO GO (решение Компании) 1 Принятие решения о запуске проекта GO/NO GO (решение Заказчика) 2 3 Предпроектная подготовка 1.Запрос от инициатора 2.Заявка на проект 3.Руководитель проекта назначен утвержден 4. Укрупненный график проекта Работы проекта, сроки и ресурсы спланированы Договоренности формализованы 4 Формализация договоренности 1.Распряжение о разработке договора 2.Коммерческое предложение Разработка графика работ 1.Договор 2.Приказ об открытии проекта 4.Устав проекта 5.Бюджет проекта 6. Окончательное описание содержания проекта Работы завершены и приняты Заказчиком Пакеты работ завершены 6 5 Реализация 1.Детальный планграфик проекта 2.План управления проектом Завершение работ 1.Результаты работ 2.Отчеты о состоянии проекта 3. Запросы на изменение Проект закрыт 7 Административное завершение Акты 1.Итоговый отчет о проекте 2. Приказ о закрытии проекта 3.Документация по проекту передана в архив 4. Опросный лист Рис. 3. Пример жизненного цикла проекта 9 Отражены:  Фазы проекта.  Вехи по началу и окончанию каждой фазы.  Результаты каждой фазы. Выделение множества этапов в крупных проектах связано не только с большой продолжительностью строительства этих объектов (10-15 лет), но и необходимостью более тщательного согласования действий организаций - участников проекта. Рассмотрим изменение характеристик проекта в течение жизненного цикла. Что нарастает в ходе проекта и резко снижается к завершению:  Уровень затрат.  Уровень загрузки персонала. Рис 4. Изменение уровня загрузки персонала и затрат в ходе проекта. Что увеличивается в ходе проекта:  Вероятность успешного завершения проекта.  Стоимость изменений.  Стоимость исправления ошибок. Рис. 5. Изменение стоимости изменений, исправления ошибок и вероятности успешного завершения в ходе проекта. 10 Что уменьшается в ходе проекта:  Неопределенность / риски проекта.  Возможность участников оказать влияние на конечные характеристики продукта проекта.  Возможность участников оказать влияние на стоимость продукта проекта. Рис. 6. Изменение уровня риска, возможностей участников в ходе проекта. Существует взаимосвязь жизненного цикла проекта и жизненного цикла продукта. Жизненный цикл продукта состоит из фаз, которые отслеживаются для производственных и контролирующих нужд компании. В основном жизненный цикл проекта состоит из одного или более жизненных циклов продукта. Если итоги проекта связаны с продуктом, возможно много видов взаимосвязей между жизненными циклами. Например, разработка нового продукта сама по себе может быть проектом. В качестве альтернативы можно привести пример, когда проект реализуется для улучшения характеристик существующего продукта. 2. Стандарты в управлении проектами и участники проектов С развитием дисциплины управления проектами в мире появляется все больше стандартов, авторы которых пытаются систематизировать накопленные знания по управлению проектами. Польза стандартов, прежде всего, выражается в том, что они содержат лучшие практики в области управления проектами. Стандарты аккумулируют опыт многих экспертов, причем данный опыт постоянно пополняется, стандарты регулярно дополняются и обновляются. Стандарты управления проектами позволяют разным компаниям разговаривать на одном языке при реализации совместных проектов. Распространение стандартов способствует лучшему пониманию принципов управления организаций-партнеров. Например, практика создавать устав проекта является общепринятой в крупных проектах. Стандарты являются основой для сертификации руководителей проектов и других специалистов. Международный сертификат принимается как своеобразная «гарантия качества» при найме и сотрудничестве. Основные стандарты управления проектами и страны разработки: 11 Основные стандарты управления проектами и страны разработки Китай С-PMBOK Япония P2M США PMBOK США NASA Project Management Стандарты Германия V-Modell ICB IPMA На основе европейских стандартов Великобритация PRINCE2 Великобритация APMBOK Швейцария Hermes Рис. 7. Основные стандарты управления и страны разработки. PMBOK. Cвод знаний по управлению проектами от PMI. Применяется в большинстве стран мира. Наибольшее распространение получил в США, России, ЮАР, Финляндии, Швеции, Дании, Норвегии, Литве. Стандарт PMBOK основан на общепризнанных практиках и знаниях, которые могут применяться по отношению к большинству проектов. ICB (IPMA Competence Baseline). ICB сочетает в себе ряд европейских стандартов. Был разработан на основе британского, швейцарского, немецкого и французского стандартов компетенций. Включает 28 основных областей знаний в управлении проектами и 14 дополнительных. Описывает компетенции менеджеров проектов. Наибольшее распространение получил в Евросоюзе, Украине, Индии, Казахстане, Азербайджане. PRINCE2. Изначально был разработан как стандарт для ведения государственных ИТпроектов Великобритании, но вскоре стал использоваться как универсальный метод управления проектами. PRINCE2 представляет собой процессно-ориенированный подход к управлению проектами. Выделяет 8 основных процессов управления проектами и 45 подпроцессов. Популярен в Бельгии, Хорватии, Польше. ARMBOK Национальный стандарт Великобритании, охватывает 52 области знаний, необходимых для успешного ведения проекта. ARMBOK был одним из основных стандартов, используемых при разработке ICB. C-PMBOK. Китайский стандарт разработан на основе PMBOK. Существует также CsPMBOK – китайская версия ICB IPMA. P2M. Японский P2M фокусируется на управлении программами. Имеет целью реализацию сложных инновационных идей и интеграцию их с областями деятельности предприятия. Также широко распространен в Южной Корее. V-Modell. VEE представляет собой набор стандартов в области проектов, касающихся разработки новых продуктов. Является основным в первую очередь для немецких федеральных административных и оборонных проектов. Во многом схож с PRINCE2 и описывает методы как для проектного управления, так и для системного развития. Современной версией V-Modell является V-Modell-XT, которая была утверждена в феврале 2005 года. 12 Hermes. Швейцарский Hermes в основном применим для управления проектами в сфере информационных технологий. Используется в Люксембурге и федеральных органах власти Швейцарии. При его разработке многое было взято из V-Modell. NASA Project Management. Стандарт разработан для управления космическими проектами (для внутреннего использования NASA). Рассмотрим подробнее наиболее распространенный в России PMBOK. Данный стандарт будет использоваться в курсе обучения для изучения областей знаний и процессов управления проектами. PMBOK разрабатывает Институт управления проектами (Project Management Institute). PMI основан в 1869 году и является самой крупной в мире некоммерческой ассоциацией профессиональных руководителей проектов. Основные сферы деятельности PMI, это:  разработка стандартов в управлении проектами;  проведение конференций и семинаров;  организация обучения;  профессиональная сертификация. Основная профессиональная сертификация PMI – степень PMP (Project Management Professional). Основные требования к кандидатам, это опыт управления проектами не менее 3 лет и прохождение 35 часов учебных курсов по управлению проектами. Стандарты, которые разработаны PMI:  ANCI PMI PMBOK Guide 4th Edition, 2008. Основной стандарт PMI, описывающий все процессы управления проектами.  The Standard for Program Management. Стандарт управления программами проектов.  The Standard for Portfolio Management. Стандарт управления портфелями.  Practice Standard for Work Breakdown Structure. Практический стандарт по построению иерархической структуры работ проекта.  Project Management Competency Development Framework. Руководство по оценке и развитию профессиональных навыков менеджеров проектов.  Organization Project Management Maturity Model. Стандарт зрелости управления проектами.  Practice Standard for Earned Value Management Project. Стандарт управления освоенным объемом в проекте. Содержание ANCI PMI PMBOK Guide 4th Edition, 2008:  Предмет и основные понятия управления проектами (Проект, жизненный цикл проекта, фазы и стадии проекта, основные участники проекта и т.д.).  5 групп процессов управления проектами.  9 областей знаний управления проектами.  42 процесса управления проектами (Описание каждого процесса включает в себя входные данные, методы и инструменты, выходные данные). Стандарты отражают системную картину дисциплины управления проектами. Положения стандартов обычно носят рекомендательный характер и отвечают на вопрос «Что делать, чтобы эффективно управлять проектами», оставляя компаниям свободу выбора в вопросе «Как делать?». Подробное описание, как управлять проектами должно содержаться в корпоративном стандарте управления проектами каждой компании (регламенты, положения, инструкции, приказы, методология, шаблоны), обязательном для исполнения в организации или проекте и соответствующем (не противоречащем) выбранному стандарту. 13 2.1. Корпоративный стандарт управления проектами Естественное логическое развитие методологии управления проектом, доказавшей свою прибыльность и эффективность для отдельных проектов организации или предприятия, переходит в управление всеми проектами. В компаниях появляется квалифицированный управленческий персонал. Жесткие конкурентные условия и реальный экономический эффект подталкивают предприятия и организации к формализации и распространению методов и средств управления разнообразными проектами для предприятия в целом. Такой подход требует создания корпоративного стандарта управления проектами (КСУП), как свода информации о процессах, процедурах, методах и инструментах управления проектами на предприятиях и организациях. КСУП состоит из:  Методологии управления проектами.  Информационной системы управления проектами.  Структур, осуществляющих функции управления проектами (Проектный офис и Проектный комитет). Рис. 8. Составляющие КСУП Подробно о создании КСУП Вы прочтете в разделе 5 «Создание КСУП». 2.2. Заинтересованные лица (участники) проекта Заинтересованными лицами являются люди и организации, такие как потребители, спонсоры, внешние организации, общества, государственные органы, которые могут позитивно или негативно влиять на проект. Команда проекта должна идентифицировать всех заинтересованных лиц, их требования и ожидания, а также связанные с их воздействием риски. 14 Другие заинт. лица Заинтересованные лица проекта Спонсор Менеджер портфеля Функциональные руководители Команда проекта Менеджер программы Операционные руководители Команда проекта Менеджер проекта Офис управления проектами Другие команды члены проекта Партнеры / Вендоры Потребители / Пользователи ПРОЕКТ Рис. 9. Взаимосвязь между заинтересованными лицами и проектом. Заинтересованные лица имеют разный уровень ответственности в проекте, который может меняться с течением жизненного цикла проекта. Иногда бывает трудно идентифицировать всех заинтересованных лиц. Например, не сразу удается определить всех партнеров, если тендер на их услуги проводится уже в ходе проекта. Очень важно разделять заинтересованных лиц на позитивных и негативных. Позитивные заинтересованные лица обычно заинтересованы в успехе проекта – это спонсор, менеджер программы, команда проекта. Негативных заинтересованных лиц необходимо стараться привлечь на свою сторону – например, в проекте строительства автостоянки жители окрестных домов могут быть недовольны строительством и сильно задержать сроки выполнения работ. В задачу команды проекта в этом случае входит кропотливая разъяснительная работа и поощрительные меры для жителей. Выделяют следующих основных заинтересованных лиц проекта: Потребители / Пользователи. Потребители или пользователи – это лица в организации, которые будут использовать результаты проекта. Потребители являются важнейшим источником информации для уточнения требований к проекту. Команда проекта должна максимально тесно сотрудничать с будущими потребителями результатов проекта для улучшения качества будущего результата. Необходимо учитывать, что зачастую заказчик проекта и пользователи результата – это разные лица. Таким образом, даже удовлетворив заказчика, команда проекта может впоследствии столкнуться с недовольством потребителей, так как заказчик может не знать или намеренно игнорировать нужды потребителей. Ярким примером такого рода ситуации является строительство дешевых домов с неудобной планировкой, производившееся в советский период. Заказчик в лице правительства города был удовлетворен результатом проекта, так как недорогое жилье помогло решить жилищные проблемы граждан. Однако, жители малогабаритных, неудобных квартир, то есть пользователи результата, до сих пор неоднозначно воспринимают результаты данных проектов. Спонсор. 15 Спонсор, это лицо или группа лиц, которые предоставляют финансирование для проекта. Спонсор может принимать активное участие в проекте или занимать пассивную позицию. В любом случае, удовлетворенность спонсора работой команды проекта является жизненно важным фактором успеха. Поэтому необходимо регулярно предоставлять спонсору требуемую отчетность и по возможности привлекать его к участию в проекте. Спонсор проекта и заказчик проекта могут совпадать или быть одним лицом. Руководитель портфеля проектов. Руководитель портфеля проектов несет ответственность за высокоуровневое управление группой проектов и программ проектов, которые могут быть связаны или не связаны между собой. Руководитель портфеля проектов принимает решение о старте и закрытии проекта, а также участвует в согласовании значительных изменений по проекту. Руководитель программы проектов. Руководитель программы проектов отвечает за группу взаимосвязанных проектов, объединенных для получения выгод, которые нельзя получить при управлении этими проектам по отдельности. Руководитель программы проектов отвечает за интеграцию ресурсов, бюджетов, сроков задач и содержания программы проектов в целом. Офис управления проектом. Офис управления проектом, это структура, созданная для поддержки процессов управления проектом. Подробно о целях, задачах и структуре офиса управления проектами в разделе 3.1. «Офис управления проектами». Проектный комитет. Проектный комитет – коллегиальный орган, предназначенный для руководства и координации проектной деятельности компании на стратегическом уровне. В компетенцию Проектного комитета входит управление всем портфелем проектов компании. Основная цель работы: максимальное увеличение ценности портфеля проектов с помощью идентификации и оценки потенциальных проектов для включения в портфель и своевременного исключения проектов, не соответствующих стратегическим целям. Членами проектного комитета обычно являются топ-менеджеры компании. Функции Проектного комитета:  управление видением, миссией, стратегией компании;  стратегическое планирование;  оценка результатов и корректировка плана работ по портфелям проектов всех уровней;  одобрение инициации проектов;  принятие решений о старте, приостановке или прекращении проекта;  утверждение приоритетов проектов;  утверждение бюджетов инициируемых проектов;  утверждение решений о корректировке бюджета проекта;  утверждение документов, регламентирующие проектную деятельность Компании;  анализ выполнения проектов;  обеспечение сбалансированности портфеля проектов и его нацеленности на достижение стратегических целей компании. Управляющий совет проекта. Управляющий совет проекта – коллегиальный орган, предназначенный для руководства и координации проектной деятельности на уровне проекта или программы. В компетенцию Управляющего совета проекта входит управление одной программой или проектом. Основная цель работы: обеспечение своевременного принятия ключевых решений по программе и достижение целей программы. Функции Управляющего совета: 16  решение вопросов по проекту, выходящих за рамки компетенции Руководителя программы;  принятие решений по критичным изменениям проекта;  контроль хода реализации проекта;  обеспечение соответствия принимаемых решений по проекту стратегии портфеля проектов. Руководитель проекта. Руководитель проекта это лицо, назначенное для организации работ проекта с целью выполнения требований к проекту. Подробно о роли руководителя проекта и требованиях к нему в разделе 1.5. «Роль руководителя проекта». Команда проекта. Команда проекта состоит из руководителя проекта, членов команды проекта и других участников, не вовлеченных непосредственно в процесс работы над проектом. Такими участниками могут быть, например, сотрудники юридического отдела, которые не глубоко вовлечены в процесс работы, но проверяют или готовят важные документы, необходимые команде проекта в работе. В команду проекта может входить также и спонсор проекта. Главное для членов команды проекта – это умение работать вместе. Если какой-то из сотрудников не умеет работать в группе и конфликтует с другими членами команды, даже при условии высокой квалификации сотрудника, успешный руководитель проекта постарается в первую очередь решить проблемы взаимодействия членов команды в общих интересах команды, а не отдельной личности. Функциональные менеджеры. Функциональные руководители, это лица, руководящие административными или функциональными подразделениями, например, кадровым отделом, отделом поставок, бухгалтерией, ИТ и так далее. Часто функциональные руководители являются владельцами ресурсов (сотрудников), которыми руководит менеджер проекта в рамках проекта. В этом случае может возникать проблема двойного подчинения работника. Подробнее о проблемах двойного подчинения в разделе 3.2. «Организационные структуры управления проектом». Операционные менеджеры. Операционные руководители, это лица, руководящие такими подразделениями как исследовательский отдел, тестирование, сервисные отделы. Эти подразделения могут после завершения проекта заниматься эксплуатацией результатов проекта Каждому участнику процесса управления проектами, присваивается роль. Роль определяет функции участника в ходе управления проектом. Один специалист может исполнять несколько ролей. Функции каждой роли описываются в регламентах для управления проектами и должностных инструкциях сотрудников. Типовые функции ролей участников проекта приведены в таблице: Роль Краткое описание функций  Управляет видением, миссией, стратегией компании. Член  Оценивает результаты и корректировки плана работ по Проектного портфелям проектов всех уровней управления. комитета  Утверждает инициацию проектов. Принимает решения о старте, приостановке или прекращении проекта  Утверждает основные параметры проекта (бюджет, приоритет и т.д.).  Утверждает документы, регламентирующие проектную деятельность компании. 17 Роль Краткое описание функций Член Управляющег о совета проекта  Заказчик   Руководитель портфеля проектов      Администрат ор портфеля проектов Продавец Руководитель программы            Руководитель проекта     Администрат ор проекта        Решает спорные вопросы по проекту, выходящие за рамки компетенции Руководителя программы/проекта Принимает решения по критичным изменениям в проектах. Согласует постановку задачи и условия договора. Осуществляет мониторинг и контроль выполнения работ проекта. Принимает результат проекта. Осуществляет управление портфелем проектов ТД. Принимает решения по вопросам, эскалированным от нижних уровней управления (по балансировке загрузки ресурсов по портфелю проектов, расстановке приоритетов, управлению критичными изменениями в проектах и т.п.). Принимает решения по балансировке загрузки ресурсов по портфелю проектов департамента и управлению критичными изменениями в проектах. Помогает руководителю портфеля проектов. Отслеживает выполнение проектов своего портфеля, предоставляет по нему регулярный отчет. Осуществляет сбор данных для анализа и балансировки загрузки ресурсов по портфелю проектов. Ведет отчетность по портфелю проектов. Осуществляет работы в рамках продажи. Ведет переговоры с Заказчиком по продаже и изменениям условий договора в ходе проекта. Осуществляет мониторинг и контроль хода работ проекта. Участвует в приемке результатов проекта. Управляет программой. Сводит воедино все элементы по проектам, входящим в программу (сроки, риски, ресурсы, цели, концептуальные подходы и т.д.). Организует коммуникации участников проектов, входящих в программу. Управляет проектом. Осуществляет планирование и мониторинг показателей проекта. Формирует отчетность по прохождению контрольных точек проекта и достижению результатов проекта. Анализирует изменения по проекту, принимает решения по некритичным изменениям. Контролирует работы субподрядчиков. Помогает Руководителю программы (проекта). Осуществляет мониторинг хода работ проекта. Организует коммуникации участников проекта. Вносит фактическую информацию в ИСУП. Ведет отчетность по проекту и проектную управленческую документацию. Архивирует проектную документацию. 18 Роль Краткое описание функций    Контролирует характеристики продукта проекта. Участвует в планировании проекта. Осуществляет постановку задач Исполнителям по разработке технического решения.  Управляет качеством результатов проекта.  Несет ответственность за реализуемость и качество технического решения проекта.  Выделяет ресурсы для работы в проекте, участвует в Владелец разрешении ресурсных конфликтов. ресурсов  Согласовывает изменения в назначениях ресурсов.  Выполняет поставленные задачи в рамках проекта. Исполнитель  Отчитывается Руководителю проекта о ходе выполнения работ в ИСУП.  Согласует постановку задачи. Представител  Отвечает за выполнение работ или пакетов работ в рамках ь проекта. субподрядчик а  Отчитывается Руководителю проекта о ходе выполнения работ по электронной почте.  Осуществляет руководство работой ОУП, обеспечивает Руководитель административную поддержку деятельности ОУП. ОУП  Является владельцем процессов управления проектами, портфелями проектов.  Назначает Руководителей проектов. Если Руководитель проекта не работает в структуре ОУП, Руководитель ОУП утверждает его назначение по представлению Руководителя портфеля проектов.  Разрабатывает стандарты и инструменты управления Методолог проектами и поддерживает их в актуальном состоянии.  Оценивает правильность применения руководителями проектов и программ принятой методологии управления проектами, выявляет существующие препятствия и факты сопротивления исполнителей применению существующей методологии, вырабатывает необходимые меры и предложения по совершенствованию процессов управления проектами.  Отвечает на вопросы по методологии от участников проектов.  Организует обучение сотрудников по управлению проектами.  Проводит регулярные и выборочные проверки качества Контролер управления проектом (по разному набору критериев). качества  Проверяет расчет мотивационного фонда проекта.  Осуществляет настройки ИСУП по запросам пользователей, Администрат поддержку пользователей при работе в ИСУП. ор ИСУП  Ведет нормативно-справочную базу ИСУП.  Отслеживает единство настроек конфигурации ИСУП.  Отвечает на вопросы пользователей ИСУП. Таблица 2. Функции участников проекта Архитектор проекта 19 3. Организация управления проектами 3.1. Офис управления проектами Для успешного функционирования корпоративного стандарта управления проектами целесообразно создавать офис управления проектами (ОУП) – структурное подразделение компании, осуществляющее поддержку реализации процессов управления проектами. Наличие в организации множества проектов в условиях постоянной нехватки ресурсов и кадрового голода также обуславливает необходимость создания централизованного офиса управления проектами. Единая точка управления ограниченными ресурсами, используемых в разных проектах, позволяет снять с менеджеров проектов и руководителей подразделений достаточно сложную задачу диспетчеризации своих людских ресурсов между проектами. Современным способом решения задачи централизованного управления ресурсами является использование информационных систем управления проектами, позволяющих одновременно планировать множество проектов и распределять работу персонала по задачам этих проектов, а также создание ОУП, позволяющего решать конфликты между руководителями подразделений и менеджерами проектов, используя административный ресурс. ОУП может иметь разную структуру и цели деятельности, например:  Методологическая и административная помощь менеджерам проектов в выполнении проектов.  Уменьшение загрузки менеджеров проектов путем делегирования вспомогательных функций и перераспределения части аналитической работы по управлению проектами.  Управление знаниями.  Выявление и поддержка реализации проблемных проектов.  Аудит проектов, контроль качества.  Аудит бизнес процессов управления проектами.  Поддержка и обновление системы управления проектами.  Распределение ограниченных ресурсов между проектами, решение спорных вопросов.  Внедрение и поддержка единого стандарта и методологии управления и отчетности по проектам.  Внедрение единой системы информирования заинтересованных сторон о ходе работы над проектами.  Создание архивной базы успешно завершенных проектов.  Осуществление процедур эффективного мониторинга и контроля планирования и исполнения в целях оптимизации работ по проектам. Цели деятельности ОУП могут планироваться на ограниченный период времени (например, один год). По истечении этого срока, должен быть проведен анализ работы ОУП и достигнутых целей, показателей деятельности. На основании анализа, руководство компании принимает решение о дальнейших перспективах и целях работы ОУП. Основными функциями деятельности ОУП могут являться:  Контроль качества процессов управления проектами.  Участие в решении ресурсных конфликтов, определение компетенции сотрудников с использованием базы данных по навыкам ресурсов.  Контроль и согласование межфункциональных и межпроектных связей.  Содействие в решении проблем с использование административного ресурса.  Сбор накопленного опыта для использования в будущих проектах. 20   Регулярный аудит текущих проектов. Анализ запросов и предложений сотрудников по улучшению качества процесса управления проектами.  Распространение терминологии управления проектами.  Обучение сотрудников по методологии ведения проектов и программному обеспечению по управлению проектами и документооборотом.  Поддержка информационной системы управления проектами.  Регулярная отчетность. Основными результатами деятельности проектного офиса могут являться: 1. Реализация соответствия управления качеством проектов регламентам по управлению проектами, основанным на стандартах PMI. 2. Повышения скорости и достоверности планирования проектов путем использования единых стандартов управления проектами. 3. Создание базы данных эффективных решений, инструментов, типовых фрагментов и нормативов для будущих проектов. 4. Увеличение процента завершенных проектов. 5. Сокращение средней продолжительности реализации проектов. Функции ролей членов офиса управления проектами: Роль Функции  Осуществляет руководство работой ОУП, обеспечивает Руководитель административную поддержку деятельности ОУП. ОУП  Является владельцем процессов управления проектами, портфелями проектов и программами.  Назначает Руководителей проектов. Если Руководитель проекта не работает в структуре ОУП, Руководитель ОУП утверждает его назначение по представлению Руководителя портфеля проектов.  Разрабатывает стандарты и инструменты управления Методолог проектами и поддерживает их в актуальном состоянии.  Оценивает правильность применения руководителями проектов и программ принятой методологии управления проектами, выявляет существующие препятствия и факты сопротивления исполнителей применению существующей методологии, вырабатывает необходимые меры и предложения по совершенствованию процессов управления проектами.  Отвечает на вопросы по методологии от участников проектов.  Организует обучение сотрудников по управлению проектами.  Проводит регулярные и выборочные проверки качества Контролер управления проектом (по разному набору критериев). качества  Проверяет расчет мотивационного фонда проекта.  Осуществляет настройки ИСУП по запросам пользователей, Администратор поддержку пользователей при работе в ИСУП. ИСУП  Ведет нормативно-справочную базу ИСУП.  Отслеживает единство настроек конфигурации ИСУП.  Отвечает на вопросы пользователей ИСУП. Таблица 3. Функции членов офиса управления проектами. Необходимо заметить, что ОУП в своем развитии также проходит несколько уровней зрелости:  Уровень 1. ОУП находится на стадии определения своих целей и задач; 21      Уровень 2. ОУП организован. Уровень 3. ОУП ищет пути более эффективного управления проектами; Уровень 4. ОУП перешел к управлению проектами; Уровень 5. ОУП завоевал признание руководителей и исполнителей проектов; Уровень 6. ОУП добился соблюдения графиков выполнения проектов всеми командами проектов;  Уровень 7. ОУП добился четкого распределения исполнителей по проектам, входящим в портфель, компания получила возможность выполнять большее число проектов;  Уровень 8. ОУП охватывает всю деятельность компании по управлению проектами. В соответствии с мировыми тенденциями к снижению формализма и жесткой регламентации процессов управления, выделяются два типа ОУП, один из которых является наиболее отвечающим современным требованиям российских компаний – это «ОУП нового поколения». Традиционные ОУП ОУП нового поколения Нацеленность на решение Нацеленность на решение стратегических задач и преимущественно тактических изменение корпоративной культуры задач Применение научных основ Управление проектами как искусство управления проектами Рассмотрение организации как Рассмотрение организации как сложного сложного механизма организма Основное внимание – Основное внимание – установлению мониторингу и контролю сотрудничества между службами Применение методик и средств Применение методик и средств управления, управления, которые можно которые можно уподобить компасу, уподобить точным картам указывающему направление развития местности Ориентированность на Ориентированность на совершенствование совершенствование конечного продукта, выходные результаты, производственных процессов удовлетворение потребностей потребителей Процессный подход Комплексный подход Применяются жестко Применяются гибкие, адаптируемые методы и стандартизированные методы и методики методики Строго придерживается Руководствуется базовыми принципами, установленных правил соблюдает установленные правила, но при необходимости прибегает к импровизациям Четко определенный, Адаптируемый к условиям и инновационный повторяющийся, управляемый и порядок работы оптимизированный порядок работы Нацеленность на обеспечение Нацеленность на эффективность и инновации производительности Управление процессами Интеллектуальное лидерство Жесткое управление и Сбалансированное управление и руководство с руководство элементами неформального лидерства Таблица 4. Характеристики типов ОУП. 22 3.2. Организационные структуры управления проектом Реализация проекта происходит в рамках организации, структура которой в значительной степени влияет на успех проекта. Выделяют следующие принципиальные организационные формы: 3.2.1. Функциональная структура Функциональная структура предполагает использование существующей функциональной иерархической структуры организации. Менеджер проекта осуществляет лишь общую координацию работ. В функциональной структуре проекты ведутся, как правило в пределах функционального подразделения. При необходимости привлечения специалистов других подразделений координация осуществляется на уровне руководителей. ВЫСШЕЕ РУКОВОДСТВО Функциональный руководитель Функциональный руководитель Функциональный руководитель Сотрудник Сотрудник Сотрудник Сотрудник (участник проекта) Сотрудник (участник проекта) Сотрудник Сотрудник Сотрудник (участник проекта) Сотрудник (участник проекта) Рис. 10. Функциональная организационная структура Преимущества структуры:  Каждый сотрудник имеет одного руководителя.  Сотрудники постоянно повышают свой профессиональный уровень, работая вместе в одном подразделении над проектами и задачами.  Централизованное управление специалистами, высокий уровень управляемости. Недостатки структуры:  Осложнена координация выполнения работ между подразделениями.  Не назначается руководитель проекта, если назначается – у него недостаточно полномочий влиять на сотрудников других подразделений и их руководителей.  Ограничен контроль над исполнением проекта. Слабая мотивация персонала для работы в проекте, так как сотрудники прежде всего заинтересованы выполнять свои функциональные обязанности и подчиняться функциональному руководителю, не отвлекаясь на работу в проекте и команды менеджера проекта.  Затруднены коммуникации в проекте между разными подразделениями. 23 Вывод: недостатки перевешивают преимущества с точки зрения проектной работы, управлять проектом в функциональной структуре очень сложно. 3.2.2. Проектная структура Проектная структура предполагает, что комплекс работ проекта разрабатывается независимо от иерархической структуры организации. В проектной структуре каждое подразделение создается для отдельного, как правила, большого проекта. В это подразделение (команду проекта) входят различные специалисты, полностью занятые в проекте. ВЫСШЕЕ РУКОВОДСТВО Менеджер проекта Менеджер проекта Менеджер проекта Сотрудник (участник проекта) Сотрудник (участник проекта) Сотрудник (участник проекта) Сотрудник (участник проекта) Сотрудник (участник проекта) Сотрудник (участник проекта) Сотрудник (участник проекта) Сотрудник (участник проекта) Сотрудник (участник проекта) Рис. 11. Проектная организационная структура Преимущества структуры:  Руководитель проекта имеет все полномочия для руководства проектом.  Сотрудники полностью подчиняются руководителю проекта.  Большая вовлеченность руководителей в проект. Недостатки структуры:  Снижается профессиональный уровень специалистов из-за того, что нет центров компетенций по профессиональным областям, которые обычно сосредоточены у функционального руководителя, который одновременно является экспертом в своей области. В такой структуре обычно некому заниматься развитием компетенций компании по профессиональным областям и специалисты мало общаются друг с другом по данным вопросам.  Неясные перспективы для исполнителей проекта после его окончания.  Проблема простоя (недогрузки) специалистов из-за временного отсутствия работы в проекте. Вывод: проектная структура может использоваться в крупных, критически важных проектах или в проектно-ориентированных компаниях. 3.2.3. Матричная структура Матричная структура – это промежуточная форма, объединяющая преимущества проектной и функциональной структур управления. 24 Могут быть выделены три разновидности матричной структуры организации: cлабая матрица, когда координатор проекта отвечает за координацию задач по проекту, но имеет ограниченную власть над ресурсами; cбалансированная матрица, когда менеджер проекта координирует все работы и разделяет ответственность за достижение цели с руководителями функциональных подразделений; жесткая матрица, когда менеджер проекта обладает максимальными полномочиями, но и несет полную ответственность за выполнение задач проекта. Управление проектами в различных матричных структурах: Матричная Функциона Слабая Сбаланси Сильная Проектная льная матрица рованная матрица матрица Полномочия Низкий Незначитель Ограничен Средний или Высокий или Менеджера или но или нет но высокий полный контроль проекта средний Наличие Низкий Незначитель Ограничен Средний или Высокий или ресурсов или но или нет но высокий полный контроль средний Кто Функц. Функц. контролируе Смешанн Менеджер Менеджер руководител руководите т бюджет ый проекта проекта ь ль проекта Роль Частично Частично Полность Полностью Полностью занят Менеджера занят на занят на ю занят на занят на на проекте проекта проекте проекте проекте проекте Администрат Частично Частично Частично Полностью ивный Полностью занят занят на занят на занят на занят на персонал на проекте проекте проекте проекте проекте проекта Таблица 5. Различия принципов управления в матричных структурах 25 3.2.4. Слабая матрица ВЫСШЕЕ РУКОВОДСТВО Функциональный руководитель Функциональный руководитель Функциональный руководитель Сотрудник Сотрудник (участник проекта) Сотрудник Сотрудник Сотрудник Сотрудник Сотрудник (участник проекта) Сотрудник (участник проекта) Координатор проекта Рис. 12. Организационная структура – слабая матрица. Основной недостаток матричной структуры – каждый исполнитель имеет двух начальников, в связи с чем часто возникают конфликты приоритетов между работами проекта и функциональными обязанностями (как и в любой матричной структуре). Ситуация осложняется тем, что власть руководителя в слабой матрице существенно ниже, чем у функционального руководителя. Может не существовать роли руководителя проекта, - руководитель проекта называется координатором проекта. 3.3. Сбалансированная матрица ВЫСШЕЕ РУКОВОДСТВО Функциональный руководитель Функциональный руководитель Функциональный руководитель Сотрудник Сотрудник (участник проекта) Сотрудник Сотрудник Сотрудник Сотрудник Сотрудник (участник проекта) Сотрудник (участник проекта) Руководитель проекта Рис. 13. Организационная структура – сбалансированная матрица. 26 В сбалансированной матрице выделяют роль руководителя проекта. Руководитель проекта занимается только руководством проектами, и освобожден от функциональных обязанностей. Это позволяет руководителю проекта повышать свой профессионализм полностью сосредоточиться на достижении целей проекта. Такая структура все чаще применяется на российских предприятиях. 3.3.1. Сильная матрица ВЫСШЕЕ РУКОВОДСТВО Функциональный руководитель Функциональный руководитель Функциональный руководитель Руководитель менеджеров проектов Сотрудник Сотрудник (участник проекта) Сотрудник Менеджер проекта Сотрудник Сотрудник Сотрудник Менеджер проекта Сотрудник (участник проекта) Сотрудник (участник проекта) Сотрудник (участник проекта) Менеджер проекта Рис. 14. Организационная структура – сильная матрица. Преимущества сильной матрицы в том, что есть должность руководителя менеджеров проектов, который осуществляет координацию между всеми проектами, а также является центром компетенций по управлению проектами. Подразделение, которым управляет такой руководитель называется офисом управления проектами, центром управления проектами, отделом управления проектами и т.д. 3.4. Группы процессов и области знаний управления проектами Все проекты независимо от своей специфики имеют сходство, которое касается, прежде всего, протекающих бизнес-процессов управления. Например и для масштабного проекта запуска новой ракеты и для небольшого проекта корпоративного праздника должен быть назначен руководитель проекта, описаны результаты проекта, спланирован график работ и так далее. Согласно PMI, существует 5 групп процессов управления проектами:  Группа процессов инициации. Определяет и авторизует проект или фазу проекта.  Группа процессов планирования. Определяет и уточняет цели и планирует действия, необходимые для достижения целей и содержания, ради которых был предпринят проект.  Группа процессов исполнения. Объединяет человеческие и другие ресурсы для выполнения плана управления проектом данного проекта.  Группа процессов мониторинга и управления. Регулярно оценивает прогресс проекта и осуществляет мониторинг, чтобы обнаружить отклонения от плана управления проектом, и, в случае необходимости, провести корректирующие действия для достижения целей проекта. 27  Группа завершающих процессов. Формализует приемку продукта, услуги или результата и подводит проект или фазу проекта к правильному завершению. Активность групп процессов в течение жизненного цикла проектов неодинакова: Рис. 15. Активность групп процессов в течение жизненного цикла проекта Как показано на рисунке, процессы планирования повторяются в течение всего жизненного цикла. Также практически постоянно используются процессы управления и мониторинга. Процессы управления проектами могут повторяться в течение жизненного цикла проекта на каждой его фазе. Все процессы управления в проекте подразделяются на две категории:  Процессы управления проектом (различные процессы по областям знаний управления проектами – управление качеством, управление рисками, управление содержанием и так далее).  Процессы управления продуктом проекта (различные процессы, определяемые жизненным циклом продукта проекта – например, процесс тестирования продукции). Далее мы в курсе будем рассматривать только процессы управления проектом. Помимо групп процессов существуют также области знаний управления проектами. В курсе мы будем рассматривать девять областей знаний:  Управление интеграцией проекта.  Управление содержанием проекта.  Управление сроками проекта.  Управление стоимостью проекта.  Управление качеством проекта.  Управление человеческими ресурсами.  Управление коммуникациями проекта.  Управление рисками проекта.  Управление поставками проекта. Всего в группах процессов содержится 42 процесса управления проектом, которые распределены по областям знаний. 28 Все группы процессов и области знаний управления проектами представлены в таблице: Процессы и Группы процессов управления проектом области Группа Группа процессов Группа Группа Группа знаний процессов планирования процессов процессов процессов инициации исполнени мониторинг завершени я аи я контроля Управление интеграцией проекта Разработка Устава проекта Разработка управления проектом плана Управлени е исполнение м проекта Мониторинг Закрытие и контроль проекта над (или фазы) работами проекта Общее управление изменениям и Управление содержанием проекта Сбор требований Проверка содержания Определение содержания Управление содержание м Создание иерархической структуры работ Управление сроками проекта Определение состава операций Контроль расписания Определение взаимосвязей операций Оценка ресурсов операций Оценка длительности операций Разработка расписания Управление стоимостью проекта Стоимостная оценка Управление Планирование Контроль стоимости Разработка бюджета расходов Обеспечен Контроль 29 качеством проекта качества ие качества Управление человеческим и ресурсами Планирование человеческих ресурсов Набор команды проекта качества Развитие команды проекта Управлени е командой проекта Управление коммуникаци ями проекта Идентифика Планирование ция коммуникаций участников проекта Распростра нение информаци и Отчетность по исполнению Управлени е ожиданиям и участников проекта Управление рисками проекта Планирование управления рисками Мониторинг и контроль над рисками Идентификация рисков Качественный анализ рисков Количественный анализ рисков Планирование реагирования риски Управление поставками проекта Планирование поставок на Организац Администри ия рование проведения поставок поставок Закрытие поставок Таблица 6. Группы процессов и области знаний управления проектами 30 3.4.1. Активы организационного процесса и факторы внешней среды предприятия Важными понятиями для изучения процессов управления проектами являются активы организационного процесса и факторы внешней среды предприятия. Факторы внешней среды – это внешние по отношению к проекту объекты, которые могут быль использованы командой проекта в качестве инструмента для выполнения работ:  Государственные и отраслевые стандарты.  Инфраструктура организации (например, имеющиеся фонды и капитальное оборудование).  Имеющиеся человеческие ресурсы.  Коммерческие базы данных (например, данные о нормативах трудозатрат, отраслевые риски, базы контактов).  Информационные системы управления проектами. Активы организационного процесса, это внешние по отношению к проекту объекты, которые тем или иным образом регламентируют деятельность команды проекта, такие как:  Типовые бизнес-процессы (стандарты, политики, положения, регламенты, инструкции). Например, корпоративный стандарт управления проектами, регламент управления коммуникациями, правила трудового распорядка компании и т.п.  Шаблоны. Например, шаблоны календарно-сетевых графиков проектов или шаблоны отчетности по проекту.  Историческая информация и извлеченные уроки. 4. Управление интеграцией проекта Управление интеграцией проекта включает в себя процессы и работы по идентификации, определению, объединению, унификации и координации различных процессов и работ по управлению проектом различных групп управления проектом. Цель интеграции состоит в достижении эффективного взаимодействия процессов управления проектами, обеспечивающих достижение целей проекта. Интеграция управления проектом требует, чтобы все процессы управления проектами были выстроены и связаны с другими процессами для облегчения их координации. В контексте управления проектом интеграция – это принятие решений о том, где концентрировать ресурсы на каждую конкретную дату, предугадывание потенциальных проблем, и их решение до того, как эти проблемы станут критическими, и хорошая координация работы проекта в целом. Интеграция также подразумевает нахождение компромиссов между пересекающимися целями и альтернативами. Управление интеграцией подразумевает интеграцию всех остальных процессов управления. Зачастую связи между процессами в группах процессов управления проектами неоднократно повторяются. Например, группа процессов планирования на ранней стадии проекта предоставляет группе процессов исполнения подготовленный план управления проектом; впоследствии она участвует в его обновлении по мере появления изменений по ходу выполнения проекта. Управление интеграцией проекта включает в себя процессы: разработка устава проекта, разработка плана управления проектом, управление исполнением проекта, мониторинг хода выполнения, общее управление изменениями, закрытие проекта или фаз. 31 4.1.1. Разработка устава проекта Входы в процесс Методы и инструменты Выходы из процесса  Обоснование проекта  Содержание работ проекта  Контракт  Экспертная  Устав проекта оценка  Факторы внешней среды предприятия  Активы организационного процесса Таблица 7. Разработка устава проекта Устав - это первый официальный документ проекта. Устав проекта является документом, формально авторизующим проект. Устав проекта наделяет менеджера проекта полномочиями задействовать ресурсы организации на операциях проекта. Менеджер проекта определяется и назначается как можно раньше. Менеджера проекта необходимо всегда назначать до начала планирования и желательно на этапе разработки Устава проекта. Устав проекта включает в себя:  Требования, удовлетворяющие потребности, пожелания и ожидания заказчика, спонсора и других участников проекта.  Производственная необходимость, самое общее описание проекта или требования к продукту, который является предметом проекта.  Цель или обоснование проекта.  Информацию о назначенном менеджере проекта и уровне его полномочий.  Расписание контрольных событий.  Отношения между участниками проекта  Функциональные организации и их участие.  Допущения относительно организации и окружения, а также внешние допущения.  Ограничения относительно организации и окружения, а также внешние ограничения.  Реальная бизнес-ситуация, служащая обоснованием проекта с данными о прибыли на инвестиции.  Бюджет проекта. Пример формы устава проекта приведен в Приложении 1. Метод экспертной оценки часто применяется для оценки входов, необходимых для разработки Устава проекта. Такая оценка и экспертиза применяются ко всем техническим и организационным деталям в ходе этого процесса. Экспертиза осуществляется любым лицом или группой лиц, имеющими специальные знания или подготовку; источники в таких случаях могут быть разными:  другие отделы данной организации;  консультанты;  участники проекта, в том числе заказчики или спонсоры;  профессионально-технические ассоциации;  отраслевые группы. 32 4.1.2. Разработка плана управления проектом Входы в процесс Методы инструменты и Выходы процесса из   Устав проекта Выходы процессов планирования (для итерационного  План обновления  Экспертная управления плана) оценка проектом  Факторы внешней среды предприятия  Активы организационного процесса Таблица 8. Разработка плана управления проектом План управления проектом может быть либо резюмирующим, либо детализированным и состоять из одного или нескольких вспомогательных планов и приложений. Каждый из вспомогательных планов описывается настолько подробно, насколько того требует конкретный проект. Пример Плана проекта приведен в Приложении 2. Вспомогательные планы включают в себя (список не исчерпывающий):  План управления содержанием проекта.  План управления расписанием.  План управления стоимостью.  План управления качеством.  План совершенствования процессов.  План управления обеспечением проекта персоналом.  План управления коммуникациями.  План управления рисками.  План управления поставками. Приложения включают в себя (перечень не исчерпывающий):  Перечень вех (контрольных событий).  Календарь ресурсов.  Базовый план расписания.  Базовый план по стоимости.  Базовый план по качеству.  Реестр рисков. Различают базовый и текущий план проекта. Базовый план – это официально утвержденный документ, относительно которого измеряется выполнение проекта и который будет использоваться для управления и контроля за исполнением проекта. Базовый план изменяется только в крайних случаях, обычно по согласованию со спонсором проекта, заказчиком, управляющим комитетом проекта. Текущий план проекта – это документ или набор документов, который изменяется по мере выполнения проекта и поступления информации о фактическом выполнении работ. Как правила, такой план всегда отличается от базового, так как ни один проект не может 33 идти в точности согласно первоначальному плану. Текущий план изменяет руководитель проекта. Очень часто в больших проектах невозможно сразу сформировать детальный план проекта. В действительности, если проект рассчитан на годы (например, строительство здания), то определить в точности до одного дня сроки всех детальных работ невозможно. В этом случае используется планирование методом набегающей волны. Метод набегающей волны - вид планирования последовательной разработки, при котором работа, которую надо будет выполнить в ближайшей перспективе, подробно планируется с глубоким раскрытием иерархической структуры работ, в то время как далеко отстоящая работа планируется с относительно неглубоким раскрытием иерархической структуры работ, но по мере выполнения работ производится подробное планирование работ, которые надо будет выполнить в ближайшие временные периоды. Таким образом, на первом этапе планируются укрупненные этапы работ, ресурсы и суммы бюджета по этапам, а в дальнейшем перед приближением каждого следующего этапа план уточняется до деталей. Такой метод часто применяется в авиастроении, например, при разработке новой модели самолета, когда неизвестно в точности, какие технологические решения будут применяться. 4.1.3. Управление исполнением проекта Входы в процесс     Методы и инструменты Выходы из процесса  План управления проектом Одобренные запросы на изменения Факторы внешней среды предприятия Активы организационно го процесса    Экспертная оценка Информационная система управления проектами    Результаты проекта Информация об исполнении работ Запросы на изменения Обновления плана управления проектом Обновления документации проекта Таблица 9. Управление исполнением проекта Процесс управления исполнением фактически подразумевает выполнение работ проекта для создания результата проекта. Одобренные запросы на изменение – это документированные, согласованные изменения, изменяющие содержание проекта. Согласованные запросы на изменение могут также изменять внутренние правила, планы управления проектом, процедуры, затраты или бюджет, а также графики работ. Процесс руководства и управления исполнением проекта требует от менеджера и команды проекта выполнения ряда действий по выполнению плана управления проектом. Вот некоторые из этих действий:  Выполнение операций для достижения целей проекта.  Расходование трудовых ресурсов и денежных средств для достижения целей проекта.  Подбор, обучение и управление членами команды проекта.  Получение предложений от потенциальных поставщиков.  Выбор подрядчиков. 34  Приобретение, управление и использование ресурсов, в том числе материалов, инструментов, оборудования и сооружений.  Внедрение запланированных методов и стандартов.  Создание, контроль, проверка и утверждение результатов проекта.  Управление рисками и реализация мер реагирования на риски.  Управление подрядчиками.  Адаптация одобренных изменений к содержанию, планам проекта.  Создание и управление каналами коммуникаций, как внешних, так и внутрипроектных.  Сбор данных проекта и отчеты по расходам, выполнению графика, техническому и качественному прогрессу, а также предоставление информации о текущем состоянии для прогнозирования.  Сбор и документирование накопленных знаний и осуществление операций по улучшению одобренных процессов. Менеджер проекта вместе с командой управления проектом управляет ходом запланированных операций проекта и различными техническими и организационными взаимосвязями, существующими в рамках проекта. 4.1.4. Мониторинг и контроль над работами проекта Входы в процесс Методы и инструменты Выходы из процесса  План управления проектом  Запросы на изменения  Отчеты об исполнении  Обновления работ  Экспертная плана управления оценка проектом  Факторы внешней среды  Обновление предприятия документации проекта  Активы организационног о процесса Таблица 10. Мониторинг и контроль над работами проекта Мониторинг и контроль над работами проекта – это процесс непрерывного наблюдения, анализа и регулирования прогресса проекта для достижения целевых показателей эффективности, определенных в плане управления проектом. Процесс мониторинга и управления работами проекта затрагивает следующие моменты:  сравнение текущего хода исполнения проекта с планом управления проектом;  оценка хода исполнения для выявления моментов, требующих корректирующих или предупреждающих действий, после чего такие действия предписываются как необходимые;  анализ, отслеживание и мониторинг рисков проекта для своевременного их выявления, отчета об их статусе и контроля выполнения планов реагирования на риски;  ведение вплоть до завершения проекта достоверной и актуальной информационной базы, касающейся продуктов проекта, и сопутствующей документации для этих продуктов;  предоставление информации для составления отчетов о текущем состоянии, оценки прогресса и прогнозирования; 35  предоставление прогнозов для обновления текущих данных о затратах и расписании проекта;  мониторинг обработки одобренных изменений по мере их появления. Основным результатом мониторинга (наблюдения) и контроля (сравнение плана и факта) является выявления отклонений от плана проекта. Такие отклонения обычно регистрируются в Запросе на изменение. Запрос на изменение может инициировать любой участник проекта, однако в формальной форме запрос обычно регистрируется руководителем проекта. 4.1.5. Общее управление изменениями Входы в процесс Методы и инструменты Выходы из процесса  План управления проектом  Обновление  Информация об статуса запроса исполнении работ на изменение  Совещания по  Запросы на  Обновления управлению изменения плана изменениями управления  Факторы внешней  Экспертная проектом среды оценка предприятия  Обновление документации  Активы проекта организационного процесса Таблица 11. Общее управление изменениями Внесение изменений – это цикличный процесс, который повторяется в течение всего исполнения проекта. Внесение изменений включает процесс контроля выполнения плана проекта, анализ полученных данных и отчетности, принятие решений по результатам анализа и внесение изменений в план при необходимости. Менеджер проекта несет ответственность за полное и своевременное обновление плана проекта в соответствии с возникшими изменениями. Менеджер проекта должен обновлять план проекта ежедневно. Источниками отклонений может служить как внутренние факторы в проекта (срыв сроков, болезнь исполнителей и т.п.), так и внешние (Новые запросы заказчика с дополнительными требованиями). Анализ внесения изменений проводится с целью учета последствий изменений плана проекта. Анализ может производиться менеджером проекта по показателям:  Отклонения от плана по срокам;  Отклонения по качеству проекта. Контроль качества результатов проекта в соответствии с Планом управления качеством проекта и Описанием содержания проекта;  Отклонение от Плана по составу и содержанию работ;  Отклонения от Бюджета;  Доступность и потребность в ресурсах;  Показатели рисков.  Выполнение обязательств по контрактам. Если показатели выходят за допустимые ограничения Менеджер проекта должен инициировать процедуру согласования изменений с руководителем программы проектов, портфеля проектов, заказчиком, спонсором и так далее. Если изменение не выходит за рамки ограниченных параметров, менеджер проекта сам принимает решение по изменению. 36 Менеджер проекта отслеживает статус Запроса на изменение (инициирован, на анализе, отклонен, принят, закрыт). Запросы на изменение обычно регистрируются в Регистрационном журнале изменений. Регистрационный журнал изменений содержит перечень всех Запросов на изменения по проекту, дату их поступления, статус, сроки выполнения, инициатора изменения и другую справочную информацию. Пример Запроса на изменение приведен в Приложении 3. Пример Регистрационного журнала изменений приведен в Приложении 4. Если изменение согласовано руководством (например, по запросу заказчика добавляется новый блок работ в проект), руководитель проекта меняет базовый план проекта (увеличивает сроки, планирует новые работы и бюджет). В проектах для внешнего заказчика главной целью команды проекта при управлении изменениями является ограничение разрастания рамок работ по проекту. Если же изменение действительно необходимо, желательно, чтобы спонсор (заказчик) проекта финансировал дополнительные работы и заключил дополнительное соглашение к контракту на данные работы. 4.1.6. Закрытие проекта (или фазы) Входы в процесс Методы и инструменты Выходы из процесса  План управления  Окончательный проектом продукт, услуга или  Одобренные результат результаты  Экспертная  Обновление проекта оценка активов  Активы организационного организационног процесса о процесса Таблица 12. Закрытие проекта или фазы Закрытие проекта или фазы – это процесс завершения всех выполненных операций во всех группах процессов управления проектом для формального закрытия проекта или проектной фазы. Процесс закрытия проекта также определяет процедуры исследования и документирования причин отклонений. Необходимо отметить, что процессу формального завершения проекта очень часто не уделяется достаточно внимания, что ведет к серьезным проблемам в работе с заказчиками. Самая распространенная ситуация, когда результата проекта передается заказчику в недоработанном виде, или с заказчиком остаются невыполненные договоренности о доделках каких-либо работ. Например, команда проекта реализует проект открытия нового торгового центра. Торговый центр должен открыться к определенной заранее дате, так как именно к этой дате приурочена рекламная компания и церемония открытия, перенести сроки которых очень сложно. Сроки выполнения работ по проекту задерживаются, и команда проекта к открытию доделать все работы не успевает. Торговый центр открывается с небольшими недоделками – не работает лифт, не установлена система кондиционирования в рабочих помещениях и так далее. Все недостатки собственными силами доделывает служба эксплуатации здания, что приводит к дополнительным затратам времени и средств. Команда проекта не несет ответственности за свои недоработки, но получает положенную премию и считает проект завершенным. Таким образом, на этапе завершения проекта должны быть проанализированы критерии закрытия проекта:  Все работы проекта завершены, подписаны акты сдачи-приемки работ. 37  Заказчик оплатил все работы, все финансовые обязательства с подрядчиками закрыты.  Нет договоренностей с заказчиком о доделке работ.  Документация проекта заархивирована.  Полученные уроки проекта учтены.  Команда проекта распущена.  Премия по проекту рассчитана.  и так далее. Только после выполнения всех требований к завершению проект может быть закрыт. 5. Управление содержанием проекта Управление содержанием проекта включает процессы, необходимые для того, чтобы удостовериться в том, что проект включает все необходимые работы (и только их) для достижения успеха проекта. Процессы этой области знаний: сбор требований, определение содержания, создание ИСР (иерархической структуры работ), проверка содержания, управление содержанием. Управление содержанием осуществляется на протяжении всего жизненного цикла проекта. Содержание проекта – работы, которые необходимо выполнить, чтобы получить продукт, услугу или результат с указанными свойствами и функциями. Содержание продукта – свойства и функции, которые характеризуют продукт, услугу или результат. Определение содержания и управление им определяет общий успех проекта. При работе над каждым проектом важно соблюдать баланс средств, источников данных и методологий, процедур и других факторов для того, чтоб усилия, потраченные на работу с содержанием, соответствовали размеру, сложности и важности проекта. Многие проекты терпят неудачи чаще всего из-за того, что их содержание и границы плохо определены. Ожидания стороны, заинтересованной в реализации проекта (в частности, заказчика или спонсора), зачастую не совпадают с ожиданиями команды, занятой в проекте. Сделать так, чтобы ожидания совпадали, — задача трудная, однако крайне важно решить ее для успеха проекта в целом. Когда речь заходит об определении содержания проекта, команда проекта и клиент как бы меняются ролями. До этого момента с заказчиком в основном контактируют люди, в задачи которых входит «продать» проект. «Продавец» пытался убедить заказчика, что проект — дело стоящее, на него стоит потратиться. Иногда «продавец» описывает проект в столь ярких красках, что намеренно или непроизвольно заставляет клиента поверить: все, что мог себе представить последний в самых невероятных мечтах, благодаря проекту превратится в реальность. На деле такое происходит весьма редко. У заказчика формируются завышенные ожидания, что очень опасно для проекта. Когда команда проекта сформирована, и определение содержания проекта происходит в процессе переговоров, заказчик считает, что проект уже согласован. В итоге весь процесс определения содержания и границ проекта заказчик считает пустой тратой времени. Клиент может даже воспротивиться определению содержания проекта. Это происходит в том случае, если заказчик не знает в точности, что ему необходимо. Одно из наиболее сложных испытаний для команды проекта — убедить представителей заказчика, что их цели в проекте во многом схожи. Другими словами, главная цель проекта — дать заказчику то, что ему действительно нужно и очень важно, и описать содержание проекта. Команда проекта, должна войти в положение заказчика. То, что заказчик знает о проекте немного, не помешает его успешно реализовать. В конечном счете, причина, по которой на проекте работают определенные люди, как раз в том и состоит, что это специалисты 38 именно в данной области. Что бы представители заказчика ни думали, они специалистами не являются, иначе не обратились бы к подрядчику. Иногда для определения границ проекта должны быть использованы неординарные средства. Возможно, одному или нескольким сотрудникам проекта придется поработать какое-то время у заказчика, чтобы войти в курс дела и осознать, каких усовершенствований он ждет от проекта. Это хороший прием, если клиент не желает или не способен выделить необходимые временные и кадровые ресурсы для работы с командой проекта. Представитель проекта как бы перевоплощается в заказчика и, узнав о нем достаточно много, начинает выступать от его имени. 5.1.1. Сбор требований Входы в процесс Методы и инструменты      Устав проекта Реестр участнико в проекта      Интервью Фокусные группы Вспомогательные семинары Методы коллективной работы Методы коллективного принятия решений Вопросники и анкетирование Мониторинг Прототипы Выходы из процесса    Документированные требования участников проекта План управления требованиями Матрица отслеживания требований Таблица 13. Сбор требований Сбор требований – это процесс определения и документирования требований участников проекта относительно результатов проекта. Реестр участников проекта должен включать:  Перечень участников проекта.  Идентификационную информацию: имя, должность, роль в проекте, контакты.  Содержательную информацию: основные требования, основные ожидания, их потенциальное влияние на проект.  Классификацию участников проекта: внешний / внутренний поддерживающий / нейтральный / препятствующий и так далее. Документированные требования участников проекта должны содержать:  Бизнес-цели проекта.  Функциональные и нефункциональные требования.  Требования к качеству.  Влияние на окружение внутри и снаружи исполняющей организации.  Допущения и ограничения требований. План управления требованиями определяет порядок анализа, документирования и управления требованиями в течение жизненного цикла проекта. 39 План управления требованиями Управление изменениями требований Планирование, учет и отчетность по управлению изменениями Процесс приоритезации требований Метрики продукта и обоснование их использования Порядок оперативного учета Рис 16. План управления требованиями Матрица отслеживания требований – это таблица, в которой показана корреляция между требованиями к проекту и его элементами, как то:  Бизнес-целями и возможностями.  Целями проекта.  Содержанием проекта / Результатами ИСР.  Проектированием продукта.  Созданием продукта.  Стратегией и порядком испытаний.  И т.д. Пример матрицы отслеживания требований: № Описание Цель Обоснование Источник Приоритет п/п требования проекта 1. Требование 1 2. Требование 2 3. Требование 3 Таблица 14. Пример матрицы отслеживания требований В российской практике требования к проекту оформляются в Техническом задании на проект. Зачастую техническое задание является приложением к договору. Необходимо отметить, что в российской специфике бизнеса только договор с подписями и печатями сторон является несокрушимым аргументом в споре с заказчиком при разрастании требований к проекту. Поэтому команда проекта должна всеми силами стараться включить максимально подробные требования к проекту со всеми ограничениями и допущениями в контракт. Ограничения по проекту – это, все, что ограничивает рамки проекта. Например, ограничение содержания проекта по проведению учебного курса будет являться программа курса. При желании заказчика программа курса может быть расширена, то есть 40 количество работы увеличивается, но расширение программы дет сделано за дополнительную плату. Допущения проекта – это все предположения, которые делает команда при планировании работ. Например, при проведении курса, мы делаем допущение, что заказчик самостоятельно подготовит учебный класс и предоставит компьютеры слушателям. 5.1.2. Определение содержания Входы в процесс Методы и инструменты Выходы из процесса   Устав проекта  Экспертная оценка  Описание Документированные  Анализ продукта содержания требования проекта  Анализ участников проекта альтернатив  Обновления  Активы документаци  Вспомогательные организационного и проекта семинары процесса Таблица 15. Определение содержания Определение содержания – это создание детального документа, отражающего цели и задачи проектный работ («Описание содержания проекта», согласно PMI). Необходим отметить, что из-за плохого перевода термина в России никто не использует подобное название документа. Обычно, подобный документ называется Технически проектом, Концепцией или просто Проектом, содержащим проектную документации (например, чертежи здания). Основой для разработки Описания содержания проекта (Технического проекта) служит Устав проекта, который детализируется в Требованиях к проекту (Техническом задании). Включает следующие разделы:  Описание содержания продукта.  Критерии приемки продукта.  Результаты проекта.  Границы проекта.  Ограничения проекта.  Допущения проекта. В крупных технологически сложных проектах, к которым предъявляются серьезные требования к безопасности и технологии проведения работ, российские предприятия применяются требования ГОСТ для создания проектной документации. Примерами таких сложных проектов могут служить бурение нефтяных скважин, строительство дорог, зданий и так далее. Однако, даже в небольших проектах, нужно очень подробно описывать все характеристики будущих результатов проекта, для того, чтобы избежать потом разногласий с заказчиком по приемке работ. Даже если заказчик считает подобный документ ненужным, команда проекта должна убедить его подписать документ. Всегда есть риск, что руководитель проекта не сможет доказать, что проект завершен изза появления новых требований заказчика. Чаще всего невозможно описать все содержание проекта подробно. Поэтому Описание содержания может детализироваться и уточняться в ходе проекта. 5.1.3. Создание иерархической структуры работ Входы в процесс  Описание Методы и инструменты  Декомпозиция Выходы из процесса  ИСР 41 содержания  Словарь ИСР проекта  Базовый план  Документация по по содержанию требования  Обновления  Активы документации организационного проекта процесса Таблица 16. Создание ИСР Создание иерархической структуры работ – это декомпозиция целей проекта на более мелкие и более управляемые компоненты. ИСР – согласованная с результатами проекта иерархическая декомпозиция работ, которые команда проекта должна выполнить для достижения целей и создания результатов проекта. Декомпозиция – это разбиение основных целей и результатов на более мелкие и управляемые с целью:  Повышения точности оценок по стоимости, времени ресурсам.  Определения базы для измерения и контроля хода выполнения проекта.  Создания четкого распределения ответственности. Этапы декомпозиции: 1. Определение основных целей проекта 2. Декомпозиция основных целей 3. Разбиение каждой цели на фундаментальные компоненты. Обычно применяют следующие виды ИСР:  Продуктовая, когда проект разбивается по элементам продукта проекта, например: Строительство дома 1. Фундамент 2. Стены и кровля 3. Отделка 4. Благоустройство участка 1.1. Закупка материалов 2.1. Закупка материалов 3.1. Закупка материалов 4.1. Закупка материалов 1.2. Траншея 2.2. Стены 3.2. Пол 4.2.Ограда 1.3. Опалубка и заливка фундамента 2.3. Кровля 3.3. Стены и потолок 4.3.Дорожки Рис 17. Пример продуктовой ИСР  Функциональная: декомпозиция по функциональным областям менеджмента, например: 42 Строительство дома 1. Поиск подрядчика 2. Логистика 3. Маркетинг 4. Организация строительства 1.1. Сравнение предложений 2.1. Закупка материалов 3.1. Подготовка рекламы 3.1. Размещение рабочих 1.2. Заключение договора 2.2. Доставка 3.2. Размещение рекламы 3.2. Строительство 3.2.1.Фундамент 3.3. Освещение 3.2.2. Стены 2.3. Размещение и хранение 5. Юридическое сопровождение Рис 18. Пример функциональной ИСР  По этапам жизненного цикла проекта: Строительство дома 1. Инициация проекта 2. Планирование проекта 3. Реализация проекта 4. Закрытие проекта 1.1. Оценка идеи 2.1. Разработка ИСР 3.1. Этап 1 3.1. Сдача-приемка работ 1.2. Маркетинговые исследования 2.2. Формирование команды 3.2. Этап 2 1.3. Анализ инвестиционной привлекательности 2.3. Создание графика проекта 1.4. Разработка Устава проекта 3.2. Архивирование документации 3.3. Этап 3 2.4. Финансовое планирование Рис. 19. Пример ИСР по этапам Могут быть и другие, в том числе смешанные типы. Основное требование при декомпозиции – на одном уровне иерархии не должно быть смешении принципов декомпозиции (то есть, нельзя смешивать классификацию яблок по принципам цвета, сорта и размера на одном уровне). На каждый блок ИСР должен быть назначен ответственный сотрудник, что позволит закрепить ответственность за конкретными членами команды. На практике ИСР формируется обычно в информационной системе управления проектами. Словарь ИСР - документ, появляющийся при создании ИСР и обеспечивающий работу с ней. Словарь ИСР используется для расширения информации о каждом элементе ИСР. Каждый элемент словаря должен содержать описание элементарной работы, связанные с 43 ней операции, ее стоимость и длительность, ответственного за эту работу и риски, связанные с этой работой. Словарь ИСР представляет собой реестр всех элементов ИСР и их характеристики, например: № Название Описание Ответственный № договора 1. Инициация проекта Описание… Иванов П. 345 2. Планирование проекта Описание… Петров В. 567 3. Реализация проекта Описание… Сидоров К. 34 3.1. Фундамент Описание… Кошкин А. 123 3.2. Стены Описание… Дымов М. 34 3.2.1. Монтаж стен Описание… Петров В. 674 4. Завершение проекта Описание… Сорокин К. 364 4.1. Закрытие договоров Описание… Водкин Р. 345 4.2. Архивирование документов Описание… Зеленов А. 345 Таблица 17. Пример словаря ИСР 5.1.4. Проверка содержания Входы в процесс Методы и инструменты Выходы из процесса  План управления  Принятые проектом результаты  Документация по проекта требованиям  Запросы на  Инспекция  Матрица изменения отслеживания  Обновление требований документации  Подтвержденные проекта результаты проекта Таблица 18. Проверка содержания Проверка содержания – это формальная (официальная) приемка содержания и результатов проекта. Инспекция включает в себя такие операции, как измерение, изучение и проверка, и служит для определения соответствия работ и результатов требованиям и критериям приемки продукта. Инспекции называются различными терминами: "проверка", "проверка продукта", "аудит" и "сквозной контроль". 44 Приемка результатов проекта оформляется актами сдачи-приемки работ или другими официальными документами. Непринятые результаты проекта также должны быть отражены в документации. По ним формируются запросы на изменения и доработку. 5.1.5. Контроль содержания Входы в процесс Методы и инструменты Выходы из процесса      План управления проектом Информация от исполнении работ Матрица отслеживания требований Активы организационного процесса    Анализ отклонений   Измерения исполнения работ Запросы на изменения Обновление активов организационного процесса Обновления плана управления проектом Обновления документации проекта Таблица 19. Контроль содержания Контроль содержания заключается в контроле и координации изменений содержания. Необходимо учитывать, что изменения содержания являются причиной неудачи проекта примерно в 80% случаев. Поэтому руководитель проекта должен уделять внимание отклонениям содержания и отслеживать риски возникновения незапланированных работ. Для оценки величины отклонений используются измерения эффективности проекта. Важные аспекты контроля содержания проекта включают в себя определение причины отклонений по сравнению с базовым планом по содержанию и принятие решения о необходимости корректирующих действий (формировании Запроса на изменение). 6. Управление сроками проекта Управление сроками проекта включает в себя процессы, обеспечивающие своевременное завершением проекта. Управление сроками по PMI включает в себя шесть процессов, пять из которых касаются планирования сроков. Однако, в большинстве случаев, результатом планирования сроков является расписание, то есть календарно-сетевой график проекта. Поэтому многие компании рассматривают процесс планирования сроков проекта как единый процесс, не разбивая его на подпроцессы. В нашем курсе мы будем рассматривать процесс планирования сроков как единый процесс с учетом входов, выходов и инструментов по всем пяти процессам PMI. 6.1.1. Планирование сроков Планирование сроков включает в себя следующие процессы:  Определение состава операций – определение конкретных плановых операций, которые необходимо выполнить для получения различных результатов проекта.  Определение взаимосвязей операций – выявление и документирование зависимостей между плановыми операциями.  Оценка ресурсов операций – оценка типов и количества ресурсов, необходимых для выполнения каждой плановой операции. 45  Оценка длительности операций – оценка количества рабочих периодов, необходимых для выполнения отдельных операций.  Разработка расписания – составление расписания проекта с учетом последовательностей операций, их длительности, требований к ресурсам и ограничений на сроки. Так как в реальности все эти процессы происходят одновременно, причем для их выполнения чаще всего используется информационная система, мы будем рассматривать процессы как единое целое и в одном разделе. Входы в процесс Методы и инструменты Выходы из процесса Определение состава операций  Факторы внешней среды  Декомпозиция предприятия  Шаблоны  Активы  Планирование организационн методом ого процесса набегающей волны  Базовый план  Экспертная оценка по содержанию Определение взаимосвязей операций    Список операций Параметры операций Список контрольных событий  Список операций  Параметры операций  Список контрольных событий  Описание содержания проекта  Активы организационн ого процесса Оценка ресурсов операций      Список операций Параметры операций Календари ресурсов Факторы внешней среды предприятия Активы организационн ого процесса          Метод диаграммы предшествования Определение видов зависимостей Применение опережений и задержек Шаблоны сетевых диаграмм расписаний Экспертная оценка Анализ альтернатив Опубликованные оценочные данные Оценка «снизувверх» Программное обеспечение для управления проектами      Сетевые диаграммы расписания проекта Обновления документации проекта Требования к ресурсам Иерархическая структура ресурсов Обновления документации проекта 46 Оценка длительности операций  Список операций  Параметры операций  Требования к ресурсам  Календари ресурсов  Описание содержания проекта  Факторы внешней среды предприятия  Активы организационн ого процесса Разработка расписания      Экспертная оценка Оценка по аналогам Параметрическая оценка Оценка по трем точкам Анализ резервов   Оценки длительности операций Обновления документации проекта  Список операций  Параметры  Анализ сети операций расписания  Сетевые  Метод диаграммы критического пути расписания проекта  Метод критической  Расписание цепи проекта  Требования к ресурсам  Выравнивание  Данные для ресурсов модели  Календари расписания ресурсов  Анализ возможных сценариев  Базовый план по  Оценки расписанию длительности  Применение операций опережений и  Обновления задержек документации  Описание проекта содержания  Сокращение проекта расписания  Факторы  Инструмент внешней среды календарного предприятия планирования  Активы организационн ого процесса Таблица 20. Планирование сроков Итогом выполнения всех процессов является Расписание проекта (которое в России из-за неудачного перевода PMI чаще всего называют Графиком работ проекта). Пример графика проекта: 47 Пример сетевой диаграммы: 48 Пример диаграммы контрольных точек (отображены только вехи проекта): 6.1.2. Определение состава операций Определение состава операций предполагает дальнейшую декомпозицию ИСР до самых нижних элементов - простейших операций, которые дальше нет необходимости детализировать. После того, как определен состав операций, мы получаем перечень всех задач проекта. Декомпозиция проводится до тех пор, пока возможно определить сроки и ресурсы по работам. 6.1.3. Определение взаимосвязей операций Определение взаимосвязей операций (задач) позволяет выявить и документировать взаимосвязи между задачами. В настоящее время наиболее часто используется метод диаграмм предшествования – метод построения сетевой диаграммы проекта с использованием узлов для представления работ и соединением их стрелками для показа зависимостей. Пример диаграммы предшествования (A, B, C, D, E, F – задачи проекта): Рис 20. Пример диаграммы предшествования Существует несколько типов логических связей, отражаемых в сетевой модели проекта. Все они охватывают по две работы, одну из которых будем называть работойпредшественником, а другую - работой-последователем. Начало после окончания FS. Последователь не может начаться раньше предшественника. Используется для большинства видов работ. Например, строительство стен не может начаться раньше окончания строительства фундамента. 49 A B Первая Работа Вторая Работа Рис 21. Взаимосвязь «Начало-Окончание» Начало после начала SS. Последователь не может начаться раньше начала предшественника. Например, встреча гостей должна начаться одновременно с началом открытия мероприятия. A Первая Работа B Вторая Работа Рис 22. Взаимосвязь «Начало-Начало» Окончание после окончания FF. Последователь не может завершиться ранее завершения предшественника. Например, подача освещения на строительную площадку не может завершиться ранее окончания работы строителей. A Первая Работа B Вторая Работа Рис 23. Взаимосвязь «Окончание-Окончание» Окончание после начала SF . Последователь не может завершиться до начала предшественника. A Первая Работа B Вторая Работа Рис 23. Взаимосвязь «Окончание-Начало» Между задачами могут вводиться задержки (лаги) и опережения. Например, зависимость «Финиш-Старт» с лагом два дня, будет означать, что вторая работа может начаться только на третий день после окончания первой работы. 50 100 Строительство фундамента FS 7 110 Возведение каркаса и внешних стен Рис 24. Пример взаимосвязи с задержкой Кроме того, существуют виды зависимостей между работами:  Жесткая зависимость – последовательность операций не может изменяться (в силу технологии или природы работ).  Нежесткая зависимость – последовательность операций определяется командой проекта и может изменяться.  Внешняя зависимость – последовательность операций определяется внешними по отношению к проекту воздействиями (например, могут быть связаны задачи двух разных проектов в одной программе проектов). 6.1.4. Оценка ресурсов операций Оценка ресурсов операций призвана определить, какие ресурсы (человеческие, оборудование, материальные средства) будут использоваться и в каком количестве, и когда каждый из ресурсов будет доступен для выполнения проектных операций. Процесс оценки ресурсов тесно координируется с процессом оценки стоимости. Оценку доступности ресурсов часто выполняют владельцы ресурсов – функциональные руководители подразделений, у которых менеджер проекта запрашивает информацию. Руководитель проекта должен четко фиксировать все договоренности с другими руководителями по выделению их ресурсов для избегания конфликтных ситуаций в дальнейшем. Если ресурс (Сотрудник) выделяется в проект не на 100% времени, и частично занимается другой работой, необходимо оговорить график работы такого сотрудника и процент его загрузки в проекте. 6.1.5. Оценка длительности операций Процесс оценки длительности плановых операций использует информацию о содержании работ плановой операции, типах требуемых ресурсов, количестве ресурсов, календарях работы ресурсов с указанием времени их доступности. Очень редко на практике существуют нормативы по длительности тех или иных операций, поэтому длительность чаще всего оценивается по аналогам (то есть по уже реализованным аналогичным работам), либо экспертным путем:  Экспертная оценка – метод Delphi, использование внешних и внутренних экспертов, баз данных.  По аналогам – по аналогии с предыдущими проектами.  Параметрическая – по объемам работ и производительности.  Оценка по трем точкам (метод PERT) – получение трех оценок – оптимистичная (О), наиболее вероятная (М), пессимистическая (Р): Оценка PERT = (Р + 4М + О)/ 6. 6.1.6. Разработка расписания При разработке расписания используется два основных метода: 51  Метод критического пути.  Метод критической цепи. Критический путь - максимальный по продолжительности полный путь в сети (в сетевой модели) называется критическим; работы, лежащие на этом пути, называются критическими работами. Именно длительность критического пути определяет наименьшую общую продолжительность работ по проекту в целом. Как правило, критические работы составляют небольшую часть всех работ сети, но именно они определяют продолжительность выполнения комплекса в целом. Длительность выполнения всего проекта в целом может быть сокращена за счет сокращения длительности задач, лежащих на критическом пути. Соответственно, любая задержка выполнения задач критического пути повлечет увеличение длительности проекта. Вехой называется работа нулевой продолжительности, вводимая для обозначения важного для проекта события. Например, начало работ или поступление денег на счет. Входными данными для расчета расписания являются:  Перечень задач.  Зависимости между задачами.  Оценки продолжительности каждой задачи.  Календарь рабочего времени проекта (определение собственного календаря для каждой задачи).  Календари ресурсов.  Ограничения на сроки начала и окончания отдельных работ или этапов.  Календарная дата начала проекта. Расчет расписания вперед - вычисление ранних сроков начала и завершения невыполненных частей всех операций. Расчет расписания начинается с работ, не имеющих предшественников. Эти работы начинаются в первый рабочий период. Рабочий день начинается утром и заканчивается в конце дня. Расчет расписания вперед определяет ранние даты работ (Early start, early finish). Ранние даты - наиболее раннее возможное время старта и финиша работ при условии, что предыдущие работы завершены. Ранний старт (в методе критического пути) - самый ранний из возможных моментов времени, в который могут начаться плановые операции проекта. Ранний финиш - самый ранний из возможных моментов времени, в который могут завершиться плановые операции проекта. Ранний старт и ранний финиш вычисляются на основании логики сети расписания, отчетной даты и любых ограничений на расписание и могут меняться по ходу исполнения проекта и внесения изменений в план управления проектом. Ранний Старт + Длительность - 1 = Ранний Финиш 52 Рис 25. Пример расчета расписания вперед Расчет расписания назад - определение позднего финиша и позднего старта незавершенных частей всех плановых операций. Определяется в результате расчета проекта от даты завершения проекта к началу на основании логики сети расписания. Дата завершения определяется в результате расчета расписания вперед или задается заказчиком или спонсором проекта. Поздний старт - самый поздний момент времени, в который может быть начата плановая операция, определяемый на основании логики сети расписания, даты завершения проекта и любых ограничений в отношении плановых операций без нарушения ограничений на график или отсрочки даты завершения проекта. Поздний финиш - самый поздний момент времени, в который может быть завершена плановая операция. Поздний старт и поздний финиш определяются с помощью Обратного прохода в сети расписания проекта. Поздний Финиш - Длительность + 1 = Поздний Старт Рис 26. Пример расчета расписания назад Общий резерв - это время, на которое может быть задержана работа относительно раннего старта без задержки проекта. Резерв- это разница между датами позднего и раннего финиша работы. 53 Работы, имеющие нулевой резерв – критические. Рис 27. Примеры общего резерва Свободный резерв - время, на которое работа может быть задержана без задержки раннего старта ее последующих работ. Может отличаться от полного резерва Свободный Резерв = РС Последующий – РФ Текущей –1 С учетом задержки по зависимости: Свободный Резерв = РС Последующий – РФ Текущей – LAG - 1 Таким образом, Основные правила расчета расписания Ранний Старт + Длительность - 1 = Ранний Финиш Поздний Финиш - Длительность + 1 = Поздний Старт Свободный Резерв = РС Последующей – РФ Текущей – 1 Полный Резерв = ПФ Текущей – РФ Текущей Метод критического пути - является основным математическим средством для вычисления ранних и поздних начал и окончаний работ и резервов времени. Длительность выполнения всего проекта в целом может быть сокращена за счет сокращения длительности задач, лежащих на критическом пути. Соответственно, любая задержка выполнения задач критического пути повлечет увеличение длительности проекта. Концепция критического пути обеспечивает концентрацию внимания менеджера на критических работах. Однако, основным достоинством метода критического пути является возможность манипулирования сроками выполнения задач, не лежащих на критическом пути. В результате анализа графика проекта по методу критического пути мы должны получить ответы на вопросы:  Совпадает ли полученная конечная дата с ожидаемой? Приемлемо ли это с точки зрения целей проекта?  Какие работы являются критическими? Совпадают ли они с теми, которые предполагались предварительно членами команды?  Какие из некритических работ имеют наименьший общий резерв? Какова вероятность или риск того, что эти работы станут критическими и будут задерживать дату завершения?  Какие работы имеют достаточный полный резерв? Существует ли возможность перераспределения их ресурсов на критические работы? 54  Какие календарные даты могут быть зафиксированы в графике проекта и действительно ли они соответствуют реальным намерениям руководства и плану по вехам? При расчете графика проекта методом критического пути необходимо обращать внимание на Календари и Ограничения задач проекта. Календари назначаются на работы и ресурсы для определения, когда может быть запланировано выполнение работы и/или использование ресурса. Рабочее время:  Определяет, какие дни недели являются рабочими.  Определяют количество рабочих часов в день. Нерабочее время:  Используется для праздников, отпусков, перерывов на обед, частичной занятости. Ограничения задач – это навязанные даты, использующиеся для отражения требований, которые невозможно формализовать сетевой логикой или календарями. Они используются в построении расписания, более точно отражающего реальную жизнь проекта и обеспечивают дополнительный контроль расписания. Типы ограничений:  Навязанная дата финиша. При этом расписание будет рассчитано так, что все работы проекта будут закончены к этой дате по поздней дате.  Ограничения на дату старта.  Ограничения на дату финиша.  Ограничения на резерв. Ограничения на дату старта определяют, когда работа должна начаться. Типы ограничений на старт:  Старт не позже, чем (Start No Later Than). o Принуждает работу начаться не позже, чем дата ограничения. o Смещает поздний старт к дате ограничения. o Влияет на поздние даты предшествующих работ.  Старт не раньше, чем (Start No Earlier Than) o Принуждает работу начаться не раньше, чем дата ограничения. o Смещает ранний старт к дате ограничения. o Влияет на ранние даты последующих работ.  Старт на дату (Must Start On). o Принуждает работу начаться в дату ограничения. o Смещает и ранние, и поздние даты старта. Ограничения на дату финиша определяют, когда работа должна быть закончена. Типы ограничений на финиш:  Финиш не позже, чем (Finish No Later Than). o Принуждает работу закончиться не позже, чем дата ограничения. o Смещает поздний финиш к дате ограничения. o Влияет на поздние даты предшествующих работ.  Финиш не раньше, чем (Finish No Earlier Than). o Принуждает работу закончиться не раньше, чем дата ограничения. o Смещает ранний финиш к дате ограничения. o Влияет на ранние даты последующих работ.  Финиш на дату (Must Finish On). o Принуждает работу закончиться на дату ограничения. o Смещает и ранние, и поздние даты финиша. Метод критической цепи предназначен для вычисления дат раннего и позднего начала для каждой работы без учета ограниченности ресурсов. 55 Критическая цепочка предназначена для вычисления дат раннего и позднего начала для каждой работы с учетом ограниченности ресурсов. Метод критической цепи описывается достаточно просто:  выявляются задачи, которые влияют на дату окончания проекта (находится критическая цепочка задач);  выполняется перестройка плана под эту цепочку с учетом ограничений, накладываемых ресурсами;  организовывается единый буфер ресурсов для критической цепочки (КЦ), который помещается в конец проекта, и отдельные буферы для некритических задач. Общий буфер - ключевой элемент Метода критической цепи, фактически защищает каждую задачу своим большим запасом ресурсов, так как вероятность того, что сорвутся все задачи, очень мала. Разработка расписания использует метод выравнивания ресурсов. При составлении графика работ, можно заметить, что многие работы идут параллельно, то есть выполняются одновременно. Если на такие работы назначены одни и те же ресурсы, есть риск, что данные ресурсы будут перегружены и не смогут выполнить работу. Поэтому, используется выравнивание ресурсов – сглаживание пиковых нагрузок на персонал. При выравнивании параллельные работы могут быть перенесены по срокам таким образом, чтобы следовать одна за другой. Это приводит в конечном итоге к увеличению сроков проекта. В настоящее время расчет календарно-сетевых графиков и выравнивание ресурсов ведется специалистами в специализированном программном обеспечении. Для оптимизации расписания используется также метод сжатия. Сжатие – это привлечение дополнительных ресурсов для ускорения выполнения работ, находящихся на критическом пути:  Добавьте ресурсы для сокращения длительности.  Используйте зависимости для определения одновременно выполняемых работ.  Декомпозируйте работы.  Измените назначенные календари.  Установите для работ критического пути более длинную рабочую неделю.  Добавьте исключения из нерабочих периодов. Сжатие обычно увеличивает стоимость работ проекта. Графические представления расписания, это:  Сетевая диаграмма.  Сетевая диаграмма Ганта.  Диаграмма контрольных точек. Когда расписание сформировано, необходимо выполнить следующие действия:  Согласовать расписание с исполнителями или их функциональными руководителями.  Утвердить расписание у руководства.  Довести расписание до сведения участников проекта. Утвержденное расписание называется базовым. 6.1.7. Контроль расписания Входы в процесс   План управления проектом Расписание Методы и инструменты   Анализ эффективности исполнения Анализ отклонений Выходы из процесса   Измерения эффективности работ Обновления 56   проекта Данные об исполнении работ Активы организационно го процесса       Программное обеспечение для управления проектами Выравнивание ресурсов Анализ возможных сценариев Применение опережений и задержек Сокращение расписания Инструмент календарного планирования    активов организационног о процесса Запросы на изменения Обновления плана управления проектом Обновления документации проекта Таблица 21. Контроль расписания Основные действия процесса, это:  Определение текущего статуса расписания проекта.  Оказание влияния на факторы, которые могут привести к изменениям в расписании.  Выявление фактов изменения расписания проекта.  Управление изменениями при их возникновении. Ключевой функцией управления расписанием является проведение анализа отклонений по срокам. Сравнение директивных дат начала и выполнения с фактическими/прогнозируемыми дает полезную информацию для выявления отклонений и осуществления корректирующих действий в случае задержек. Изменения общего временного резерва также является важным элементом планирования, позволяющим оценить исполнение сроков проекта. Методы измерения эффективности выдают отклонение по срокам и индекс выполнения сроков, используемые для оценки величины любых возникающих отклонений от расписания. Важной частью управления расписанием является принятие решения о том, требует ли отклонение от расписания применения корректирующего действия. Например, значительная задержка выполнения какой-нибудь плановой операции, находящаяся вне критического пути, может оказать минимальное влияние на расписание проекта, а небольшая задержка выполнения критической или околокритической операции может потребовать немедленного принятия мер. 7. Управление стоимостью проекта Управление стоимостью проекта объединяет процессы, выполняемые в ходе планирования, разработки бюджета и контролирования затрат, и обеспечивающие завершение проекта в рамках утвержденного бюджета. Управление стоимостью проекта касается прежде всего стоимости ресурсов, необходимых для выполнения плановых операций. Однако при управлении стоимостью проекта следует учитывать, как принимаемые решения скажутся на стоимости эксплуатации, обслуживания и технической поддержки продукта, услуги или результата проекта. Например: уменьшение количества контрольных оценок на этапе проектирования может снизить стоимость проекта за счет повышения эксплуатационных расходов заказчика. Управление стоимостью проекта в таком более широком значении часто называют "учетом затрат в течение жизненного цикла". Учет затрат в течение жизненного цикла в сочетании с методами оптимизации выгод могут способствовать оптимизации процесса 57 принятия решений, а также снижению стоимости и времени выполнения проекта, повышению качества и эффективности результата поставки проекта. Финансовый цикл проекта - промежуток времени между моментом открытия финансирования по проекту и прекращением обязательств перед инвестором. Финансовый цикл проекта Финасирование проекта Возврат денежных средств инвестору Платеж 1 Платеж 2 Платеж 3 Платеж 4 Начало работ Завершение работ Жизненный цикл проекта Инициация Планирование Исполнение и управление Заврешение Послепроектное сопровождение Рис 28 . Финансовый цикл проекта Таким образом, финансовый цикл проекта может быть сдвинут относительно даты старта проекта. 7.1.1. Стоимостная оценка Входы в процесс       Методы и инструменты Базовый план по содержанию Расписание проекта План управления персоналом Реестр рисков Факторы внешней среды предприятия Активы организацион ного процесса          Экспертная оценка Оценка по аналогам Параметрическая оценка Оценка снизувверх Оценка по трем точкам Анализ резервов Стоимость качества ПО для управления проектами Анализ предложений исполнителей Выходы из процесса    Оценка стоимости операции Вспомогательные данные для оценки стоимости операции Обновления документации проекта Таблица 22. Стоимостная оценка 58 Оценка стоимости заключается в определении приблизительной стоимости ресурсов проекта для компании. На предпроектной стадии первоначально может определяться только порядок величины стоимости. Точность оценки порядка величины стоимости проекта может колебаться от (50%) до (+100%). Точность концептуальной оценки находится в интервале (-30%) (+50%). Точность предварительной оценки проекта колеблется от (-20%) до (+30%). На этапе окончательной оценки точность колеблется от (-15%) до (+20%). Контрольная оценка имеет точность от -10% до +15%. Таким образом, каждая последующая стадия жизненного цикла проекта имеет более точную стоимостную оценку. Рис. 29. Взаимосвязь жизненного цикла проекта и точности стоимостной оценки Стоимостная оценка обычно выражается в единицах валюты (доллары, рубли и т. д.) для облегчения сравнения проектов и операций внутри проекта. Стоимость плановых операций оценивается для всех ресурсов, задействованных в проекте. К ресурсам относятся, в частности, специалисты, оборудование, телефонная связь, Интернет, арендованные помещения, а также особые статьи расходов, например учет уровня инфляции или расходы на непредвиденные обстоятельства. Стоимостная оценка по аналогам означает, что при оценке стоимости текущего проекта в качестве основы принимается фактическая стоимость предыдущих схожих проектов. Этот метод часто используется при стоимостной оценке в условиях недостатка детальной информации о проекте (например, на ранних фазах проекта). Стоимостная оценка по аналогам производится с использованием экспертной оценки. Метод стоимостной оценки по аналогам, как правило, является более дешевой, чем другие методы, но он также и менее точен. Наиболее точные результаты этот метод дает в случаях, когда предыдущий проект подобен текущему не только по внешним признакам, но и по сути, а у лиц или групп, занятых подготовкой оценки, есть необходимые знания. Оценка "снизу вверх". Этот метод включает в себя оценку стоимости отдельных пакетов работ или отдельных плановых операций с максимальной степенью детализации. Эта подробно рассчитанная стоимость суммируется или "переходит" на более высокие уровни и используется при составлении отчетов и для контроля за исполнением. Стоимость и точность оценки стоимости по методу "снизу вверх" обычно зависят от размеров и сложности отдельных плановых операций или блоков работ. Обычно чем меньше трудоемкость операций, тем выше точность стоимостной оценки плановых операций. Параметрическая оценка – это метод, при котором для стоимостной оценки ресурсов плановой операции используется статистическая зависимость между историческими данными и другими переменными (например, величина площади конструкции в строительстве, количество строк в коде программы, количество часов рабочего времени). При помощи данного метода можно получить более точную оценку стоимости. Уровень точности оценки зависит от сложности, количества ресурсов, выделенных для такой 59 работы и данных о стоимости, встроенных в модель. Например: для того, чтобы получить оценку стоимости, нужно запланированный объем работ умножить на стоимость одной единицы в прошлом. Другим методом стоимостной оценки являются анализ предложений исполнителей и анализ необходимой стоимости проекта. В случаях, когда проект получают в результате конкурентной борьбы, может потребоваться, чтобы команда проекта провела дополнительную стоимостную оценку и определила стоимость отдельных результатов поставки и окончательную стоимость проекта в целом. Анализ резервов. Многие специалисты по оценке включают в стоимость плановых операций резервы (иначе называются "средства на непредвиденные обстоятельства"). При этом возникает проблема потенциального завышения стоимостной оценки плановой операции. Резерв на непредвиденные обстоятельства – это оценка стоимости, используемая по усмотрению менеджера проекта в случае возникновения ожидаемых, но не определенных событий. Стоимость качества – это изменение стоимости работ в зависимости от необходимости достижения определенного качества и затраты проверки качества. 7.1.2. Разработка бюджета расходов Входы в процесс Методы и инструменты Выходы из процесса  Оценка стоимости операции  Суммирование  Вспомогательные стоимости  Базовый план данные для оценки  Анализ резервов по стоимости стоимости операции  Экспертная  Требования к  Базовый план по оценка финансирован содержанию ию проекта  Историческая  Расписание проекта информация  Обновления  Календари ресурсов документации  Согласование  Контракты проекта объемов  Активы финансирования организационного процесса Таблица 23. Разработка бюджета расходов Стоимостные оценки отдельных плановых операций объединяются в группы по пакетам работ в соответствии с ИСР. Затем стоимостные оценки пакетов работ объединяются в элементы более высоких уровней также согласно ИСР, и, в конце концов, образуется оценка стоимости всего проекта. Каждая компания использует свои формы бюджет проекта. Бюджет проекта связан с управленческими статьями затрат компании, например:  Затраты на фонд оплаты труда.  Затраты на оборудование.  Затраты на услуги подрядчиков.  Затраты на непредвиденные расходы.  Затраты на командировки.  Затраты на налогообложение.  И так далее. Бюджет проекта распределяется по статьям затрат и контролируется руководителем проекта. Кроме того, бюджет проекта контролируется обычно финансовым отделом компании или бухгалтерией, а также руководителем портфеля проектов. Иногда в проекте отдельно выделяется роль финансового контролера для управления бюджетом проекта. 60 В обязанности руководителя проекта входит также контроль финансовых потоков проекта – то есть сроки оплаты работ подрядчикам и поставщикам, а также получение средств от спонсора или заказчика. Так как выделение средств из общего бюджета предприятия управляется чаще всего специальными подразделениями, руководитель проекта должен своевременно подавать заявки на выделение средств на затраты проекта и отчитываться по затратам. Базовый план по стоимости - распределенный по времени бюджет, используемый для мониторинга и контроля исполнения стоимости проекта. Он разрабатывается путем суммирования оценок стоимости расходов по периодам времени и обычно имеет вид Sкривой, например: Рис. 30. Пример базового плана по стоимости Базовый план по стоимости является элементом плана управления проектом. 7.1.3. Контроль стоимости Входы в процесс Методы и инструменты Выходы из процесса      План управления проектом Требования к финансировани ю проекта Данные об исполнении работ Активы организационно го процесса       Измерение освоенного объема Прогнозирование Показатель эффективности выполнения TCPI Анализ эффективности выполнения проекта Анализ отклонений ПО для управления проектами      Измерение эффективности работ Прогнозы по бюджету расходов Обновление активов организационно го процесса Запросы на изменения Обновление плана управления проектом Обновления документации проекта Таблица 24. Контроль стоимости Управление стоимостью проекта включает в себя: 61     Воздействие на факторы, вызывающие изменения базового плана по стоимости. Проверка того, что запрошенные изменения получили одобрение. Управление фактическими изменениями по мере их возникновения. Обеспечение того, что потенциальное превышение стоимости не приведет к увеличению расходов сверх авторизованных пределов финансирования, как периодических, так и проекта в целом.  Осуществление мониторинга выполнения стоимости с целью обнаружения и анализа отклонений от базового плана по стоимости.  Точное фиксирование и ведение записей всех соответствующих изменений в затратах, имеющих отличия от базового плана по стоимости.  Защита правил использования утвержденных ресурсов или денежных средств от того, чтобы в них не были внесены неверные, несоответствующие или неутвержденные изменения.  Информирование соответствующих участников проекта об утвержденных изменениях  Выполнение действий, необходимых для того, чтобы превышения стоимости затрат оставались допустимых пределах. Метод освоенного объема - интегрированный анализ исполнения календарного плана проекта и бюджета по стоимостным оценкам, наиболее распространенный метод измерения исполнения проекта и его управления. (Освоенный объем задачи - это утвержденный бюджет, выделенный на ее решение.) Метод позволяет получить ответы на вопросы:  Фактические затраты меньше запланированных на данный момент. Выигрывает ли мой проект или он, напротив, есть отставание от расписания?  Фактические затраты на проект выше плановых, хотя проект выполнен лишь наполовину. Какова будет его стоимость к моменту завершения всех проектных работ?  Менеджер проекта или инженер убеждает меня, что нет смысла беспокоиться о перерасходе бюджета. Оставшаяся доля работы будет стоить меньше предполагаемых затрат. Может ли такое быть?  Если ли у меня исполнители для выполнения нового контракта?  Будут ли влиять изменения в ставках оплаты исполнителей и в курсе валют на стоимость моего проекта?  Как сокращение финансирования проекта повлияют на план движения денежных средств в проекте? Данный метод позволяет представить сведения об исполнении расходов и расписания, причем и расписание и расходы измеряются в валюте, в которой ведется бюджет проекта. Измерение и расходов, и расписания проекта в денежных единицах является наиболее информативным описанием состояния проекта. Метод использует систему отчетности с нарастающим итогом, которая основана на отслеживании трех показателей проекта:  Плановая стоимость запланированных работ или плановый объем - PV (Planned Value). Плановый объем рассчитывается на основании базового плана по стоимости и базового расписания, где каждая операция имеет свои сроки и оценку стоимости. Плановый объем представляет бюджет с нарастающим итогом и отображающий во времени, когда предполагается делать затраты согласно плану проекта;  Фактическая стоимость выполненных работ - AC (Actual Cost). Фактическая стоимость с нарастающим итогом отображается во времени для каждого отчетного периода;  Плановая стоимость выполненных работ или освоенный объем - EV (Earned Value). Объем работы эквивалентен бюджету, установленному для 62 данной работы. Освоенный объем изображается на графике в конце каждого отчетного периода на основании информации о фактической выполненной работе. Если проект выполняется в соответствии с планом, все три показателя будут иметь одинаковое значение. Отклонения между показателями могут стать сигналом об отставании проекта по срокам или перерасходе бюджетных средств. Рис.31. Управление стоимостью методом освоенного объема Трудными задачами методики освоенного объема является сбор данных и составление отчетности о выполнении работ. Ключевыми показателями методики освоенного объема являются:  отклонение по стоимости - CV (Cost Variance). Равно разнице между плановой стоимостью выполненной работы и ее фактической стоимостью. CV = EV - AC.  отклонение по срокам - SV (Schedule Variance). Равно разнице между плановой стоимостью выполненной работы и плановой стоимостью запланированных работ. SV = EV - PV.  коэффициент выполнения бюджета (или индекс выполнения стоимости) CPI (Cost Performance Index). CPI = EV/AC.  коэффициент выполнения календарного плана (или индекс выполнения сроков) - SPI (Schedule Performance Index). SPI = EV/PV. Индексы - относительные показатели, используемые для сравнения хода выполнения проектов разной величины, когда сравнение абсолютных показателей проектов невозможно. На рис. представлены различные варианты состояния проекта и соответствующие им значения показателей. 63 Рис. 32. Анализ показателей методики освоенного объема Метод освоенного объема объединяет параметры содержания проекта, стоимости (или ресурсов) и сроков, которые помогают команде управления проектом оценить эффективность исполнения проекта. Прогнозирование включает в себя оценку или описание условий, которые возникнут в будущем проекта, на основании информации и знаний, доступных на момент прогнозирования. По мере выполнения проекта прогнозы создаются, обновляются и переиздаются на основе поступающей информации об исполнении работ. 8. Управление качеством проекта Качество – это совокупность характеристик объекта, позволяющая ему удовлетворять заявленным или подразумеваемым требованиям. Критическим аспектом качества в контексте управления проектами является необходимость отражения подразумеваемых требований в содержании проекта. Важно удовлетворить требования всех групп заказчиков и заинтересованных сторон (по возможности). Основные принципы управления качеством, согласно PMI:  Удовлетворение заказчика. Обеспечение как формальные требований заказчика (отраженных в контракте), так и неформальных ожиданий конечных пользователей заказчика от использования ими продукта (результата проекта).  Предотвращение прежде, чем устранение. Один из фундаментальных принципов современного управления качеством – предотвращение появления, а не устранение уже появившегося брака (потерь качества продукта).  Непрерывное улучшение. Вся команда проекта непрерывно работает над улучшением процессов выполнения проекта и повышением качества продукта. Основной подход PMI PMBOK к управлению проектом соответствует стандартам качества ISO 9000 и ISO 10000 и современным концепциям качества. 8.1.1. Стандарты и сертификация Основные требования к товару (в том числе к качеству товара) содержатся в стандартах на товар (продукцию, работу, услугу). Стандарты преследуют следующие основные цели: 64  унификация деталей сложных технических устройств, выпускаемых различными производителями;  обеспечение безопасности товара;  отражение требований потребителей товара. Изначально стандарты стали появляться в требованиях заказчиков продукции. Позднее были установлены общегосударственные стандарты. Со слиянием рынков отдельных стран в общемировой рынок стали появляться международные стандарты. Все это сопровождалось развитием соответствующих организаций по стандартизации. Так, в октябре 1946 г., по решению ООН была создана Международная организация по стандартизации (ИСО). В уставе ИСО определено: “целью организации является содействие развитию стандартизации в мировом масштабе для облегчения международного товарообмена и взаимопомощи, а также для расширения сотрудничества в области интеллектуальной, научной, технической и экономической деятельности”. По соглашению между ИСО и Международной электротехнической комиссией (МЭК) деятельность ИСО не затрагивает стандартизацию в областях электротехники, радиоэлектроники и связи. Стандартизацией в них занимается МЭК. ИСО и МЭК совместно формируют систему международной стандартизации. В рамках этой системы ими была определена терминология по стандартизации и сертификации продукции. В частности, было принято следующее определение стандартизации: Стандартизация - это деятельность, направленная на достижение оптимальной степени упорядочения в определенной области посредством установления положений для всеобщего и многократного использования в отношении реально существующих или потенциальных задач. Хотя сертификат на продукт и повышает конкурентоспособность предприятия, психология потребителя изменилась. Он считает, что при подготовке к сертификации предприятие предъявит повышенные требования к предоставляемому на сертификацию образцу и он будет отличаться от серийной продукции. Таким образом сертификат на товар рассматривается потребителем скорее как показатель технических возможностей фирмы, а не как гарантия качества товара. Чтобы быть уверенным, что все поставляемые товары будут соответствующего качества, потребитель требует уже не сертификат на продукт, а сертификат на систему качества, т.е. гарантию, что на предприятии существует система, обеспечивающее требуемое качество, система управление качеством. При этом сертификат на сам продукт уже может и не требоваться, потребитель может полагаться на контрольные службы производителя. Международные стандарты ИСО серии 9000 и устанавливают требования к системе качества предприятия. По определению ИСО: система качества - это совокупность организационной структуры, методик, процессов и ресурсов, необходимых для осуществления общего руководства качеством. В ходе управления качеством используются стандарты и нормативы. Стандарт – это документ, утвержденный уполномоченным органом и содержащий общепринятые правила, руководства или характеристики продуктов, процессов или услуг, соответствие которым не является обязательным. Норматив – это документ, устанавливающий требования к характеристикам продуктов, процессов или услуг, в том числе соответствующие условия административного права, соответствие которым является обязательным. Различают качество продукта проекта и качество управления проектом. Качество продукта регламентируется требованиями к продукту проекта, описанными в Описании содержания проекта, а также ГОСТ, и другими государственными и корпоративными стандартами. Качества управления проектом – это прежде всего качество работы менеджера проекта и команды проекта. 65 8.1.2. Эволюция управления качеством В истории философии качества существуют 4 перекрывающиеся и продолжающиеся фазы, которые развивались под давлением противоречия между внутренними и внешними целями производителя - обеспечением качества выпускаемой продукции и соответственно укреплением положения производителя на рынке (внешняя цель) и повышением эффективности производства, то есть увеличением прибыли компании (внутренняя цель). Фаза отбраковки Фаза отбраковки началась вместе с ремеслом и вошла в практику отдельных мастеров, которые проверяли свою собственную работу, мастеров, которые наблюдали за работой подмастерьев, покупателей, которые тщательно перебирали изделия, чтобы сделать покупку. Цеховые организации средневековых городов, если выражаться современным языком, сертифицировали мастеров - присуждали звание мастера после серьезных испытаний качества изделия. Каждое изделий было индивидуальным. В 70х гг. XIX века в оружейном производстве (заводы Сэмюэля Кольта) родилась идея стандартного качества - изделия собирались не из подогнанных друг к другу деталей, а из случайно выбранных из партии, то есть взаимозаменяемых деталей. Перед сборкой эти детали проверялись с помощью калибров, и негодные отбраковывались. Контроль и отбраковку осуществляли специально обученные контролеры. Выдающийся вклад в развитие этой фазы внесли американские автомобилестроители Генри Мартин Леланд (основатель фирмы "Кадиллак") и Генри Форд. Леланд впервые применил в автомобильном производстве работу по калибрам и придумал пару «проходной» и «непроходной» калибр. В марте 1908 г. эксперты Британского автомотоклуба отобрали случайным образом 3 экземпляра из экспортной партии автомобилей «Кадиллак», прибывшей в Англию, и разобрал их до последнего винтика. Все детали свалили в кучу, а затем кое- какие детали из этой кучи изъяли и заменили запчастями, позаимствованными опять же наугад в местном агентстве по продаже и обслуживанию автомобилей «Кадиллак». Потом группа механиков, вооруженная только отвертками и гаечными ключами, собрала машины заново и запустила моторы. Две машины завелись с первой попытки, а одна - со второй, и все они отправились на длительную обкатку по только что сданному в эксплуатацию автодрому Бруклэндс. И когда вновь собранные машины подтвердили полную идентичность своих ходовых характеристик параметрам автомобилей заводской сборки, Британский автомотоклуб выдал фирме «Кадиллак» диплом и серебряный кубок с надписью «За стандартизацию». После этого на табличке с гербом фирмы на автомобилях «Кадиллак» появилась надпись «Standart of the world» - образец для подражания для всего мира. Форд применил сборочный конвейер и ввел вместо входного контроля комплектующих на сборке выходной контроль на тех производствах, где эти комплектующие изготавливались, то есть на сборку стали поступать только годные, качественные изделия. Он также создал отдельную службу технического контроля, независимую от производства. Научным обобщением и обоснованием опыта, накопленного на этой стадии, стали работы американского ученого, инженера и менеджера Фредерика У. Тейлора, соратника Г. Форда. Именно им предложена концепция научного менеджмента, включившая системный подход, кадровый менеджмент, идею разделения ответственности между работниками и управленцами в обеспечении качественной и эффективной работы организации, идею научного нормирования труда. Он разработал основные идеи иерархической структуры управления организацией, которые в окончательном виде сформулировали Анри Файоль и Макс Вебер. Можно сказать, что благодаря деятельности Ф. У. Тейлора и Г. Форда была создана концепция организации машинного производства (производственная система Форда - Тейлора), которая в основных чертах просуществовала до настоящего времени, и является моделью организации производства 66 большинства современных предприятий. Только в 70-е годы ей на смену стала приходить другая концепция (производственная система Тойота). Основу концепции обеспечения качества этой фазы можно сформулировать так: «Потребитель должен получать только годные изделия, т.е. изделия, соответствующие стандартам. Основные усилия должны быть направлены на то, чтобы не годные изделия (брак) были бы отсечены от потребителя». Последовательное воплощение в жизнь этой концепции привело уже в 20-е годы к тому, что численность контролеров в высокотехнологичных отраслях (авиационная, военная промышленность) стала составлять до 30 - 40% от численности производственных рабочих, иногда и более. В рамках этой концепции повышение качества всегда сопровождается ростом затрат на его обеспечение, т.е. цели повышения эффективности производства и повышения качества изделий являются противоречивыми (не могут быть достигнуты одновременно). Фаза управления качеством Эта фаза начинается с 20х гг. ХХ века как попытка если не разрешить, то ослабить противоречие в форме, свойственной предыдущей фазе. Точкой отсчета считаются работы, выполненные в Отделе технического контроля фирмы Вестерн Электрик, США. В мае 1924 г. сотрудник отдела доктор Шухарт передал своему начальнику короткую записку, которая содержала метод построения диаграмм, известных сейчас по всему миру как контрольные карты Шухарта. Статистические методы, предложенные Шухартом, дали в руки управленцев инструмент, который позволил сосредоточить усилия не на том, как обнаружить и изъять негодные изделия до их отгрузки покупателю, а на том, как увеличить выход годных изделий в техпроцессе. Одним из замечательных достижений практики управления качеством стало создание аудиторской службы по качеству, которая в отличие от отделов технического контроля занималась не разбраковкой продукции, а путем контроля небольших выборок из партий изделий проверяла работоспособность системы обеспечения качества на производстве. Ядром концепции обеспечения качества на этой фазе стало: "Сохраняется главная цель - потребитель должен получать только годные изделия, т.е. изделия, соответствующие стандартам. Отбраковка сохраняется как один из важных методов обеспечения качества. Но основные усилия следует сосредоточить на управлении производственными процессами, обеспечивая увеличение процента выхода годных изделий". Внедрение концепции обеспечения качества в практику позволило значительно повысить эффективность производства при достаточно высоком качестве изделий и услуг, что создало условия для формирования глобального рынка товаров и услуг. В то же время, росло понимание того, что каждый производственный процесс имеет определенный предел выхода годных изделий, и это предел определяется не процессом самим по себе, а системой, то есть всей совокупностью деятельности предприятия, организации труда, управления, в которой этот процесс протекает. При достижении этого предела с новой остротой действует то же противоречие, что и на предыдущей стадии, - цели повышения эффективности производства и повышения качества изделий становятся противоречивыми. Фаза менеджмента качества Начало фазы менеджмента качества принято отсчитывать с 1950 г. Поворотным событием стало выступление с лекциями перед ведущими промышленниками Японии доктора Эдвардса Деминга, американца. За 12 лекций доктор Деминг встретился с сотнями ведущих менеджеров японских фирм. Им, а также Джозефом М. Джураном, другим американцем, также приглашенным в порядке правительственной технической помощи в Японию, была разработана программа, основной идеей которой было: «Основа качества продукции - качество труда и качественный менеджмент на всех уровнях, то есть такая 67 организация работы коллективов людей, когда каждый работник получает удовольствие от своей работы». Программа базировалась уже не на совершенствовании только производственных процессов, а на совершенствовании системы в целом, на непосредственном участии высшего руководства компаний в проблемах качества, обучении всех сотрудников компаний сверху донизу основным методам обеспечения качества, упора на мотивацию сотрудников на высококачественный труд. Место концепции недопущения брака к потребителю и концепции увеличения выхода годных изделий заняла концепция «0 дефектов». Именно благодаря последовательному осуществлению идей Деминга, Джурана и Каори Ишикавы Япония, страна, более чем бедная природными ресурсами и разоренная войной, стала одной из богатейших стран мира. Основной вклад в развитие как этой фазы, так и последующей, внесли: Кросби (Crosby, Philip B.) - в 1964 г. предложил программу «0 дефектов»; являлся в течение многих лет вице-президентом компании ITT, был президентом американского общества по управлению качеством (ASQS), в настоящее время консультант многих компаний по всему миру, возглавляет консалтинговую фирму Philip Crosby Associates, Inc. Деминг (Deming W. Edwards) - являясь одним из ведущих специалистов по статистическим методам обеспечения качества, в 1950 получил приглашение от японского союза ученых и инженеров (JUSE)принять участие в программе восстановления японской промышленности. Там он и предложил программу менеджмента качества из 14 пунктов, разработал принцип постоянного улучшения качества, которые произвели революцию в японской промышленности. В его честь JUSE в 1951 г. учредил очень престижную ежегодную премию его имени - приз для японской фирмы, внесший наибольший вклад в развитие идей менеджмента качества, аналогичный приз для иностранной фирмы и индивидуальный приз. С 1980 г. американская ассоциация статистики также присуждает премию имени Деминга. Деминг был одним из наиболее известных в мире консультантов в области менеджмента качества, автор более 200 книг в этой области, почетный доктор десятков американских университетов. В 1987 г. получил персональное поздравление президента США. Умер в 1995 г. Фейгенбаум (Feigenbaum Armand V.) - разработал принципы тотального управления качеством и параллельного (одновременного) инжиниринга; более 10 лет проработал в General Electric, затем основал собственную консалтинговую фирму General Systems Company, Ltd, президентом которой является до настоящего времени. Эта фирма - один из мировых центров консультаций в области менеджмента качества. Ишикава (Ishikawa, Kaori) - придумал «круг качества», предложил диаграммы «причины – следствие» (диаграмма Ишикавы), разработал концепцию управления качеством, в котором участвует весь коллектив предприятия. С начала 50-х годов принимает активнейшее участие в программе JUSE по качеству. Является одним из разработчиков новой концепции организации производства, воплощенной на фирме «Тойота» (производственная система «Тойота», ТПС). Джуран (Juran, Joseph M.) - разработал принцип «триад качества»; является одним из ведущих бизнес - консультантов в области качества. Месинг (Masing Walter) - предложил «справочник по качеству» как основной документ системы обеспечения качества предприятия. Можно сказать, что именно на этой фазе обеспечения качества сложился менеджмент качества в его современном понимании. Противоречие между повышением качества и ростом эффективности производства в его прежних формах было преодолено применение новых идей управления позволило одновременно повышать качество и снижать затраты на производство. Потребитель практически во всех странах стал получать товары и услуги высочайшего качества по доступной цене - идея «общества потребления» воплотилась в жизнь. В то же время, концепция стандартизованного 68 качества, согласно которой под качественным изделием понимается изделие, требования к которому определил и зафиксировал в нормах производитель, а потребитель вправе либо купить предложенный продукт, либо отвергнуть его, привела к обострению противоречия между качеством и эффективностью в новой форме, - при ошибке в определении запросов потребителей при выходе годных, с точки зрения производителей, изделий на рынок затраты чрезвычайно велики. Фаза планирования качества Эта фаза стала зарождаться в середине 60х гг. как развитие идей предыдущей фазы в направлении более полного удовлетворения запросов потребителей. Необходимость развития этой фазы связана с развитием мирового рынка товаров и услуг, резким обострением конкуренции на этом рынке и политикой государственной защиты интересов потребителей. Все это привело к ситуации, когда выпуск на рынок продукции, имеющей «детские болезни» или удовлетворяющей запросы потребителя в меньшей степени, чем изделия конкурентов, связана с одной стороны, с развитием теории надежности изделий, и с другой стороны, с широким внедрением вычислительной техники и систем автоматизированного проектирования в процесс разработки изделий. Основой концепции новой фазы стали:  идея, что большая часть дефектов изделий закладывается на стадии разработки из-за недостаточного качества проектных работ;  перенос центра тяжести работ по созданию изделия с натурных испытаний опытных образцов или партий на математическое моделирование свойств изделий, а также моделирование процессов производства изделий, что позволяет обнаружить и устранить конструкторские и технологическое дефекты еще до начала стадии производства;  место концепции «0 дефектов» заняла концепция «удовлетворенного потребителя»;  высокое качество необходимо предоставить потребителю за приемлемую цену, которая постоянно снижается, т.к. конкуренция на рынках очень высока. Основные идеи новой фазы высказаны в работах Генити Тагути, доктора Мицуно, в научных разработках компаний «Тойота» и «Мицубиси». Тагути ( иногда употребляется написание Тагучи - Taguchi, Genichi) - предложил функцию потерь качества, разработал методику планирования промышленных экспериментов. В рамках фазы планирования качества удается практически преодолевать противоречие между качеством и эффективностью производства в его существовавших формах, и новая фаза возникает при проявлении новой формы этого противоречия. Например, требования потребителя, чтобы не только продукция, но и производственный процесс были бы экологичными, т.е. не наносили бы ущерб окружающей среде. В настоящее время эта фаза только зарождается, и ее концепция еще окончательно не сформировалась. 8.1.3. Планирование качества Входы в процесс  Базовый план по содержанию  Реестр участников проекта  Базовый план по стоимости  Реестр рисков Методы и инструменты  Анализ прибыли и затрат  Стоимость качествам  Контрольные диаграммы  Бенчмаркинг (сравнение с Выходы из процесса  План управления качеством  Метрики качества  Контрольные списки по качеству  План совершенствования 69  Активы организационного процесса  Факторы внешней среды предприятия эталоном) процессов  Планирование  Обновления экспериментов документации проекта  Выборочные оценки  Диаграммы зависимостей  Собственные методологии управления качеством  Дополнительные инструменты планирования качества Таблица. 25. Планирование качества Планирование качества – это документирование того, каким образом будет достигнуто соответствие:  Требованиям к качеству продукта и проекта.  Стандартам качества, применимым к продукту и проекту. Анализ прибыли и затрат. Цель метода - выдержать необходимое соотношение между доходами и затратами в проекте. Обеспечение качества проекта, несомненно, приводит к дополнительным расходам, поэтому для каждого предложенного метода обеспечения качества необходимо анализировать коэффициент рентабельности. На рисунке представлен выбор оптимальной пропорции затрат на профилактику дефектов и устранение дефектов.  Рис. 33. Соотношение затрат и выгод в обеспечении качества. Сравнение с эталоном (бенчмаркинг) включает в себя сопоставление действующего или планируемого проекта с другими проектами с целью выработать идеи для усовершенствования и критерии оценки исполнения. Другие проекты могут быть как внутри исполняющей организации, так и за ее пределами, а также могут относиться, как той же области приложения, так и к другой. Стоимость качества включает стоимость соответствия (затраты на систему качества) и стоимость несоответствия (то есть исправления ошибок). 70  Рис 34. Слагаемые стоимости качества Планирование экспериментов - статистический метод, позволяющий определить факторы, которые оказывают влияние на определенные переменные величины продукта или процесса. План управления качеством описывает, каким образом команда управления проектом будет претворять политику исполняющей организации в области качества. План управления качеством является частью или вспомогательным планом в составе плана управления проектом. План управления качеством может быть формальным и неформальным, очень подробным или обобщенным, в зависимости от потребностей проекта. В плане управления качеством мероприятия по обеспечению качества должны быть изложены в самом начале проекта. Это необходимо для обеспечения того, чтобы решения, принимаемые в начале проекта, например, относящиеся к концепции, разработке и испытаниям, были верными и безошибочными. Эти мероприятия должны проводиться на основе независимых экспертных оценок, а в составе исполнителей не должно быть тех, кто уже работал с материалами данных экспертных оценок. Результатом таких мероприятий могут быть снижение стоимости и создание расписания расходования дополнительных средств, вызванных доработкой. 8.1.4. Обеспечение качества Входы в процесс  План управления качеством  Метрики качества  Данные об исполнении работ  Измерения контроля качества Методы и инструменты  Инструменты методы планирования контроля качества  Аудиты качества  Анализ процесса Выходы из процесса и и  Обновления активов организационного процесса  Запросы на изменения  Обновления плана управления проектом  Обновления 71 документации проекта Таблица 26. Обеспечение качества Обеспечение качества – это проведение систематических проверок процессов проекта на предмет соответствия установленным стандартам и процедурам проекта. Обеспечение качества – это не проверка конченого продукта (конечным продуктом занимается аудит качества). Аудит качества - независимая экспертная оценка, определяющая, насколько операции проекта соответствуют, и соответствуют ли, установленным в рамках проекта или организации правилам процессам и процедурам. Целью аудита качества является выявление неэффективных и экономически не оправданных правил, процессов и процедур, используемых в проекте. Количество и сроки плановых проектных аудитов могут определяться основными этапами проекта или ключевыми событиями. Внеплановые аудиты проводятся по запросам Заказчика, руководителей департаментов и отделов. Аудиты качества проводятся на основе критериев, каждый из которых является следствием требований нормативной документации системы менеджмента качества (требование ISO 9000) и системы управления проектами (PMBOK). Схема проведения внутреннего аудита качества проекта может выглядеть следующим образом:  анализ исправления замечаний предыдущей проверки;  проведение проверки проекта в соответствии с контрольными списками;  оформление отчета о контроле качества;  информирование команды проекта о появлении новых отчетных документов. Анализ процесса предусматривает выполнение действий, описанных в плане улучшения процесса и направленных на выявление организационных и технических моментов, которые нуждаются в улучшении. Для проверки качества управления проектом могут использоваться следующие критерии: Критерии качества процесса управления проектом Контроль качества процесса управления проектом в фазе Инициации проекта Контроль качества процесса управления Качество документирования этапов:  Должна быть создана Служебная записка на открытие проекта, Устав, Договорные документы и Приказ на открытие проекта. В Карточке проекта, Служебной записке на открытие проекта и Уставе должна быть отображена вся требуемая в регламенте управления проектами информация.  Все необходимые документы утверждены.  Документы сохранены в соответствии с регламентом по управлению коммуникациями.  Соблюдены сроки согласования Устава и Служебной записки на открытие проекта. Качество управления проектом:  Назначен Менеджер проекта.  Должен быть создан проект в информационной системе управления проектом и введены все требуемые в регламенте управления проектами параметры.  Исполнители отчитались о затраченном времени на этап Инициации в системе управления проектами.  Все работы по фазе Инициации закрыты. Качество документирования этапов:  Создан План проекта в соответствии с требованиями регламента; 72 проектом в фазе Планирования Контроль качества процесса управления проектом в фазе Исполнения и управления Контроль качества процесса управления проектом в фазе Завершения  Создан Бюджет проекта в соответствии с требованиями регламента;  Создано Окончательное описание содержания проекта.  Информация, запрашиваемая от внешних участников проекта, предоставлена своевременно.  Сроки работ этапа Планирования не вышли за рамки допустимых отклонений (в том числе согласование документов Заказчиком). Качество управления проектом:  Создан Базовый план проекта.  Учтены риски проекта.  Учтены работы по снабжению, оплате, заключению договоров.  Разрешены ресурсные конфликты.  Менеджер проекта отчитался о затраченном времени на этап Планирования в системе управления проектами.  Введены фактические данные (сроки и трудозатраты по работам этапа Планирования) в План проекта. Качество документирования этапов:  По проекту была создана вся необходимая документация, указанная в Плане управления коммуникациями проекта.  Была своевременно предоставлена вся необходимая отчетность по проекту.  По всем изменениям должны быть созданы и завизированы Запросы на изменение проекта.  Все запросы на изменение проекта зарегистрированы в Регистрационном журнале изменений.  Согласованы новые Базовые планы проектов (по необходимости).  Предоставлялась отчетность (Исполнители – ежедневно, другие участники – по согласованным срокам).  Своевременное реагирование Менеджером проекта на критические ситуации и предоставление отчетности Руководителю портфеля проектов. Качество управления проектом:  Каждый участник проекта своевременно получал необходимую информацию.  Своевременно обновлялась фактическая информация по проекту.  Своевременно вносились изменения по проекту.  Создан новый Базовый план проекта (по необходимости);  Менеджер проекта должен отчитался о затраченном времени на этап Исполнения и контроля в системе управления проектами. Качество документирования этапов:  Заказчику предоставлен Итоговый отчет.  Закрыт Акт приемки работ.  Утвержден Приказ о закрытии проекта.  Итоговый отчет предоставлен в согласованные сроки.  Акт приемки разработки закрыт в согласованные сроки. 73  Все документы по проекту заархивированы. Качество управления проектом:  Все работы завершены.  Оплаты от заказчика получены. Таблица 27. Критерии качества процесса управления проектом Проверка качества по данному контрольному листу производится регулярно в проекте, а также по окончании каждой фазы проекта. 8.1.5. Контроль качества Входы в процесс  План управления качеством  Метрики качества  Контрольные списки процедур контроля качества  Измерение исполнения работ  Одобренные запросы на изменения  Результаты проекта  Активы организационного процесса Методы и инструменты  Диаграмма причинноследственных связей  Контрольная диаграмма  Диаграммы зависимостей  Гистограмма  Диаграмма Парето  Линейный график  Диаграмма разброса  Выборочные оценки  Инспекция  Анализ утвержденных запросов на изменения Выходы из процесса  Измерения контроля качества  Утвержденные изменения  Утвержденные результаты проекта  Обновления активов организационного процесса  Запросы на изменения  Обновления плана управления проектом  Обновления документации проекта Таблица 28. Контроль качества Диаграмма Парето Применяется, когда требуется оценить относительную важность выявленных проблем. Диаграмма Парето представляет из себя график, где по горизонтальной оси расположены проблемы, а по вертикальной - их относительная важность, оцененная по какому-либо единому для всех них параметру (например, по стоимости наносимого ущерба, или частоте возникновения). Проблемы расположены в порядке убывания важности. Данные для построения диаграммы Парето могут быть взяты, например, из контрольных листков. Диаграмма Парето названа так по принципу Парето, по которому 80% ущерба наносят 20% проблем. Диаграммы Парето позволяют аналитикам принять решение, какие проблемы следует решать, а решение каких не принесет большого эффекта, а также выработать последовательность решения проблем. 74 На рис. приводится пример диаграммы Парето. Ущерб, наносимый проблемой 100% Кумулятивная кривая Прочие проблемы 1 2 3 4 5 6 7 Проблемы Рис. 35. Диаграмма Парето Диаграмма причинно-следственных связей Она также называется диаграмма Ишикавы или диаграмма рыбий скелет. Причинноследственная диаграмма позволяет выявить и наглядно представить факторы, влияющие на появление какой-то проблемы или результата, и взаимосвязи между этими факторами. Она применяется для изучения процессов, выявления причин проблем и при планировании, чтобы выделить, что влияет на качество результата. Как правило, выявленные факторы располагают слева, а результат - справа. Порядок построения причинно-следственной диаграммы: 1. Подробно опишите проблему (ситуацию или результат) ее особенности, где она возникает, когда проявляется и как далеко распространяется. 2. Выявите и запишите все возможные проблемы и факторы, влияющие на результат (на возникновение проблемы). Проблемы и факторы как правило разбивают на 5 категорий: оборудование, персонал, методы, материалы, внешние условия. Описание проблемы и факторов, влияющих на результат, может быть сделано с помощью мозгового штурма. 3. Постройте по описанной проблеме и факторам причинно-следственную диаграмму. При построении диаграммы старайтесь, чтобы все формулировки были как можно более краткими. 4. Попытайтесь дать толкование всем взаимосвязям. На рис. приводится фрагмент причинно-следственной диаграммы. 75 Рис. 36. Фрагмент причинно-следственной диаграммы Контрольная диаграмма Контрольная диаграмма позволяет визуализировать изменение какой-либо контрольной величины во времени. Он представляет из себя график зависимости этой величины от времени. Данные для его построения могут быть взяты, например, из контрольных листков. После его построения можно выявить, в какой период произошло что-то, что повлияло на эту величину, и определить, что это было. Например: износ оборудования, изменение субподрядчика, применение другого материала, набор новых сотрудников и т.д. При анализе графика важно отделять несущественные изменения, которые нормальны для исследуемого процесса, от существенных. Лучше всего использовать временной ряд для выявления изменения средней величины. При построении графика важно не перепутать последовательность. На рис. приведен пример контрольной диаграммы. 76 Рис. 37. Контрольная диаграмма понедельных потерь рабочего времени Гистограмма Гистограмма применяется для исследования распределения измеряемой величины по возможным интервалам значений. Для ее построения промежуток значений, которые может принимать исследуемая величина делится на несколько интервалов. После этого для каждого интервала определяется количество измерений, значения которых лежат в этом интервале и на графике строится столбик высота которого пропорциональна полученному количеству. Примером исследуемого значения может быть толщина изготовленной детали. Если распределение имеет максимум, то оно называется критическим. При определении количества и длины интервалов надо учитывать количество сделанных измерений, точность измерений и представления о результате анализа (т.е. чтобы можно было выявить предполагаемые факты). Некоторые процессы по своей природе несимметричны, так что не обязательно каждое распределение будет иметь вид колоколообразной кривой. Если на гистограмме имеется два пика, то это означает, что данные собраны из нескольких разных источников, например, разных мастеров, смен, станков и т.д. На рис. приведен пример гистограммы. 77 Рис. 38. Гистограмма распределения диаметра втулки Диаграмма разброса Диаграмма разброса применяется для определения зависимости двух величин друг от друга. Ограничением применения диаграммы разброса является то, что по ней можно с уверенностью сказать, что связи между величинами нет. То, что связь есть, однозначно утверждать нельзя. Это лишь является предпосылкой для дальнейшего исследования. На рис. приводятся два примера диаграмм разброса для случая, когда зависимость есть и когда ее нет. Рис. 39. Примеры диаграмм разброса Диаграмма зависимостей Диаграммы зависимостей помогают анализировать причины возникновения проблем. Диаграмма зависимостей представляет собой графическое отображение процесса. Существует множество различных стилей представления этих диаграмм, но все они отображают операции, точки принятия решений и порядок обработки данных. Диаграммы зависимостей дают представление о том, как различные элементы системы взаимодействуют между собой. На рис. приведен пример диаграммы зависимостей для контрольных оценок. Такая диаграмма зависимостей может оказать помощь команде 78 проекта в прогнозировании, где и какие могут возникнуть проблемы с качеством, - и, следовательно, в разработке мер по их предотвращению. Диаграммы зависимостей часто использует для описания бизнес-процессов. Процесс инициации фазы проекта Руководитель портфеля Управляющий комитет Генеральный директор Начало процесса 1. Анализ итогов предыдущей фазы: - Результаты фазы - Отклонение по срокам работ - Отклонение по стоимости - Риски - Отклонение по качеству - Наличие ресурсов для следующей фазы План управления проектом Документация по итогам предыдущей фазы Приказ о старте фазы проекта Обсуждение решения о старте следующей фазы Старт следующей стадии? Нет, отложить Приказ о переносе сроков старта проекта Да Приказ о старте фазы проекта Конец процесса К процессу Планирования фазы Рис 40. Пример диаграммы зависимостей Линейный график Линейный график является самым простым из типов графиков. Каждая точка соответствует определенному показателю за какой либо период (день, неделю, месяц и т.п.). Одиночная непрерывная линия соединяет все эти точки. 9. Управление персоналом проекта Управление персоналом проекта - это процесс обеспечения эффективного использования человеческих ресурсов проекта, к которым относятся все участники проекта (спонсоры, заказчики, команда проекта, субподрядчики, подразделения компании и другие участники проекта). Для успешного достижения целей проекта критически важным является следующее: 79     идентифицировать состав участников проекта; определить роли участников проекта и порядок их взаимодействия; сформировать команду проекта и команду управления проектом; построить необходимую и достаточную для управления проектом организационную структуру. Роль в проекте (проектная роль) - определенный набор функций и полномочий в проекте, созданный с целью распределения обязанностей между членами команды проекта. Проектную роль можно рассматривать как временную должность в организации (компании). Участники проекта - организации Заказчика и Исполнителя и специалисты от организаций Заказчика и Исполнителя, а также другие организации и лица, которые участвуют в работе проекта или чьи интересы могут быть затронуты при исполнении или завершении проекта. Участники оказывают влияние на проект и его результаты. Команда проекта - временная рабочая группа, выполняющая работы по проекту и ответственная перед Руководителем проекта за их выполнение. Команда проекта состоит из команды управления, участников проекта, выполняющих работы в рамках проекта, Исполнителей проекта. Команда управления проектом - члены команды проекта, уполномоченные принимать управленческие решения по управлению проектом. Состав команды управления должен быть достаточным, чтобы осуществлять:  Управление ресурсами проекта, в том числе: o определение требуемых для достижения целей проекта ресурсов o подготовка предложений по изменению состава группы управления проектом; o утверждение персональных изменений в составе рабочих групп проекта; o оценка стоимости проекта, подготовка бюджетов проекта и отчетов об исполнении бюджетов.  Управление сроками выполнения проекта, в том числе: o подготовка плана работ проекта; o контроль над выполнением проекта; o подготовка отчетов о ходе работ проекта.  Управление качеством проекта, в том числе: o контроль соответствия разрабатываемых проектных решений Техническому заданию; o организация экспертизы проектных решений.  Управление рисками проекта, в том числе: o анализ рисков проекта; o разработка планов мероприятий по снижению рисков; o реализация мероприятий по снижению рисков.  Управление проблемами проекта, в том числе: o анализ проблем проекта; o разработка мероприятий по разрешению проблем проекта; o реализация мероприятий по разрешению проблем проекта.  Контроль над организацией работ в проектных группах, в том числе: o согласование отчетов о ходе работ; o контроль над функционированием системы сбора и распределения информации; o контроль документирования проектных результатов. Персональный состав команды управления приведенных организационных единиц определяется Уставом проекта. 80 Для того чтобы распределить функции и обязанности по проекту, составляют ролевые инструкции или Положение по проектной роли. В ролевой инструкции должно быть определено следующее:  какие цели стоят перед сотрудником, назначенным на данную роль;  кому подчиняется сотрудник, назначенный на ту или иную роль;  каковы его функции, обязанности, полномочия. Незнание ключевых участников проекта, их функций и полномочий может привести к большим сложностям при исполнении проекта. 9.1.1. Разработка плана управления персоналом Входы в процесс Методы и инструменты Выходы из процесса  Требования к  Организационные ресурсам диаграммы и описания  Факторы внешней  План управления должностных среды предприятия персоналом обязанностей  Активы  Налаживание связей организационного процесса  Теория организации Таблица 29. Разработка плана управления проектом Определение ролей и ответственности в проекте должны производиться с учетом того, как будет осуществляться привлечение к проекту существующих организаций, а также каким образом в настоящее время осуществляться взаимодействие между различными людьми по различным техническим аспектами. К факторам внешней среды предприятия, затрагивающим корпоративную культуру и структуру предприятия, относятся:  Организационные. Какие организации или отделы привлекаются к участию в проекте? Каковы механизмы взаимодействия, существующие на данный момент между ними? Каковы сложившиеся на данный момент формальные и неформальные отношения между ними?  Технические. Какие различные навыки и специальности необходимы для выполнения данного проекта? Существует ли необходимость в обеспечении координации между языками программного обеспечения, инженерными подходами или различными типами оборудования? Существуют ли какие-либо специфические сложности при переходе от одной фазы жизненного цикла к другой?  Межличностные. Какие официальные и неофициальные отношения подотчетности существуют на данный момент между кандидатами в члены команды проекта? Каковы должностные обязанности кандидатов? Каковы существующие между ними отношения типа начальник-подчиненный? Каковы существующие между ними отношения типа поставщик-заказчик? Какие культурные или языковые отличия между членами команды могут оказать влияние на рабочие взаимоотношения? Каков существующий на данный момент уровень доверия и уважения между ними?  Логистика. Какое расстояние отделяет людей от модулей, которые будут частями проекта? Находятся ли эти люди в различных зданиях, часовых поясах или странах?  Политические. Каковы цели и интересы каждого из потенциальных участников проекта? Какие люди или группы людей имеют неформальное влияние в областях, представляющих важность для проекта? Какие существуют неформальные связи между потенциальными участниками проекта? 81 Помимо вышеперечисленных факторов, на выбор членов команды проекта влияют ограничения. В качестве примеров ограничений, способных повлиять на гибкость процесса планировании человеческих ресурсов, можно привести следующее:  Организационная структура. В организации со слабой матричной базовой структурой роль менеджера проекта будет относительно слабой.  Коллективные договоры. Наличие договоров с профсоюзами или другими объединениями работников может потребовать создания определенных ролей или отношений подотчетности.  Экономические условия. В качестве примеров экономических условий, ограничивающих возможности по подбору персонала, можно привести ограничения по набору, сокращение бюджета по обучению персонала или недостаток средств на командировочные расходы. План управления персоналом - это часть Плана управления проектом, описывающая, когда и как будут выполнены связанные с персоналом требования. План управления персоналом включает в себя следующие пункты:  Набор персонала.  График рабочего времени.  Критерии высвобождения ресурсов.  Система поощрения и мотивации.  Потребность в обучении.  Ссылки на регламентирующие документы (трудовые договоры, правила внутреннего трудового распорядка и т.д.)  Вопросы безопасности. Организационные диаграммы и назначения по проекту Иерархические организационные диаграммы являются простым и наглядным инструментом для определения иерархии подотчетности, начиная с нижнего уровня организации до руководителя проекта. Существуют различные форматы документирования распределения ролей и ответственности членов команды проекта, например иерархический, матричный или текстовый. Независимо от формата документирования организационные диаграммы позволяют для каждого пакета работ назначить ответственного за его исполнение, а также обеспечивают понимание своей роли и ответственности каждым членом команды. На рис. представлен пример документирования распределения ролей и ответственности членов команды проекта, выполненного в виде организационной структуры. Организационная структура является иерархической организационной схемой существующих подразделений организации (отделов, групп или команд). Под каждым отделом указывается список операций проекта или пакета работ. Таким образом, можно увидеть закрепление ответственности в проекте для данного функционального отдела (например, отдела информационных технологий или отдела закупок) в одном месте рядом с названием отдела. 82 Куратор проекта от Исполнителя Куратор проекта от Заказчика Руководитель проекта от Исполнителя Руководитель проекта от Заказчика Группа обучения Группа программистов Группа внедрения Пользователи информационной системы Тренер Архитектор системы Специалист по внедрению Постановщик задачи Менеджер по подготовке к обучению Технический писатель Системный аналитик Системный администратор Методист Тестировщик Программисты – 3 чел Рис. 41. Организационная структура проекта Для определения иерархии подотчетности может быть применена матрица ответственности, которая является компактной формой представления взаимосвязи между отдельными ролями команды проекта и возложенными на них обязанностями. Матрица имеет следующую структуру: в левом столбце представлены работы проекта, названия столбцов справа содержат перечень ролей, обеспечивающих выполнение указанных работ. На пересечении строк и столбцов в ячейке указывается степень участия роли в данной работе - консультация, разработка, приемка работы, утверждение и др. В таблице приведен пример матрицы ответственности проекта. Ответственные за работы Работы проекта Спонсор Менеджер Куратор Финансист проекта проекта проекта Согласование целей С О С У Разработка плана вех С О, И У Разработка бюджета У О И С проекта Составление плана И,О проекта Утверждение плана С О С У Таблица 30. Пример матрицы ответственности Условные обозначения: У - утверждение, И - исполнение, С - согласование, О – ответственный. Текстовые форматы - еще один формат для описания распределения ответственности. В документах, закрепляющих ответственность на проекте, в краткой форме содержится следующая информация: обязанности, полномочия и необходимая квалификация. Реестр навыков - инструмент для определения навыков, необходимых членам команды проекта. Реестр навыков - это список категорий и компонентов навыков для определенного класса персонала: 83  Навыки  Вес (Критичность) навыка (1-5)  Технические навыки  Оценка (1-5)  Знание предметной области проекта  Взаимодействие с техническими специалистами  Возможность заменить технического специалиста на каком-либо участке работы  Навыки системного анализа  2   2   1   4    4  Умение проводить презентации  Административные навыки  Эффективные переговоры по обеспечению проекта ресурсами  Умение делегировать полномочия  4   5   Соблюдение правил и  5 регламентов работы над проектом  Умение своевременно  5 эскалировать проблемы руководству  Умение завершить проект в срок и  5 в рамках бюджета  Знание информационных систем  3 управления проектом  Навыки межличностного общения и лидерства      Навыки эффективного общения  4   Умение мотивировать команду  4   5   5   5   5   Управление конфликтами внутри команды  Умение получить поддержку руководства  Решение конфликтов с заказчиками  Умение принимать решения   Стратегические навыки Стратегическое планирование  3  84   Умение работать в условия  4 кризиса   Разработка и применение новых  2 методов работы Таблица. 31. Пример реестра навыков для руководителя проекта Реестры навыков должны быть составлены для каждого класса персонала, как, например, для руководителя проекта, системного архитектора, специалиста по качеству. Критичность навыков для руководителя проекта определяется во многом масштабом проекта и организационной структурой проекта. Наибольшими полномочиями наделен руководитель проекта в проектных организационных структурах, и, следовательно, к нему должны предъявляться самые высокие требования. Распределение навыков зависит от уровня административной ответственности. Рейтинг критичности смещается от "технических" в сторону "административных", а затем в сторону "межличностного общения" и "стратегических навыков" по мере роста административной ответственности. Налаживание связей - метод планирования команды проекта, состоящий из операции по установлению связей с потенциальными членами команды, таких как предварительная переписка, неформальные беседы и собрания по специальности. Использование этого метода может быть полезно не только на этапе планирования, но и до начала проекта. Методом планирования команды проекта является использование теории организации, которая дает информацию о поведении людей, команд и подразделений. Применение проверенных принципов позволяет сократить время планирования и повысить его качество. 9.1.2. Набор команды проекта Входы в процесс Методы и инструменты Выходы из процесса План управления  Назначение  Предварительное проектом персонала в проекте назначение  Факторы внешней  Календари ресурсов  Переговоры среды предприятия  Обновления плана  Набор персонала  Активы управления  Виртуальные организационного проектом команды процесса Таблица 32. Набор команды проекта При наборе членов команды проекта необходимо учитывать следующее:       Доступность - возможность привлечения специалиста на проект в запланированные сроки. Квалификация - наличие у потенциального члена команды квалификации, отвечающей требованиям проекта. Опыт работы - наличие опыта выполнения работы, которую планируется закрепить за потенциальным членом команды. Заинтересованность - наличие интереса в работе над проектом. Стоимость - величина оплаты труда потенциального члена команды. Переговоры. Набор команды для многих проектов является предметом переговоров с руководителями функциональных подразделений или руководителями других проектов для гарантии обеспечения соответствующим штатом квалифицированных сотрудников на требуемый период времени. Критерии отбора команды проекта: 85     Профессиональные знания и навыки в предметной области, необходимые для решения профессиональных задач. Профессиональны опыт / стаж, уровень участия в профессиональной деятельности, участие кандидата в проектах в определенной роли. Мотивация кандидата, готовность к работе в данном проекте, роли, должности. Деловые компетенции, уровни развития деловых и личностных качеств. Один из инструментов, используемых в наборе команды – предварительное назначение. Это означает, что зачастую сложно определить доступность сотрудника для реализации долгосрочных проектных работ. В этом случае владельцы ресурсов назначают сотрудников предварительно, и оповещают руководителя проекта о замене на кандидатов с аналогичными навыками по необходимости. Все чаще используется практика виртуальных команд в проектах. Современные технические средства позволяют общаться с членами команды в любой точке мира. Очень распространены виртуальное взаимодействие в проектах разработки программного обеспечения, когда команды разработчиков могут находиться в разных странах, а также в проектах крупных корпораций, когда руководитель проекта находится в центральном офисе (например, в Москве), а члены команды на объекте (например, в Сургуте). Календари ресурсов. Для указания доступности ресурсов документально фиксируется период времени, в течение которого каждый член команды проекта может принимать участие в выполнении проекта. Информация о доступности ресурсов необходима для корректировки расписания проекта с учетом отпусков и обязательств по другим проектам. Назначение персонала должно ознаменоваться Приказом о назначении персонала, формально закрепляющим ответственность за конкретными сотрудниками. 9.1.3. Развитие команды проекта Входы в процесс Методы и инструменты Выходы из процесса  Навыки межличностного общения  Оценки  Назначение  Обучение эффективности персонала в проекте  Тимбилдинг команды проекта  План управления  Принципы  Обновление проектом взаимодействия факторов внешней  Календари ресурсов среды предприятия  Сорасположение  Поощрение и премирование Таблица 33. Развитие команды проекта Развитие команды проекта предусматривает повышение квалификации членов команды проекта и укрепление взаимодействия между ними для повышения эффективности исполнения проекта. Цели развития команды проекта:  Повышение навыков членов команды для повышения их способности выполнять операции проекта.  Укрепление чувства доверия и сплоченности среди членов команды для повышения морального климата, снижения вероятности конфликтов, повышения продуктивности работы команды.  Создание динамичной и сплоченной командной культуры для повышения как коллективной, так и индивидуальной эффективности, командного духа и взаимодействия. 86 Выделяют следующие стадии развития команды:  Стадия формирования.  Стадия психологической напряженности.  Стадия нормализации.  Стадия деятельности.  Стадия расформирования. Первая стадия, стадия формирования, характеризуется тем, что члены будущей команды осторожно исследуют границы приемлемого поведения в группе. Это – стадия перехода индивида от состояния независимого лица к статусу члена команды. Вторая стадия – стадия психологической напряженности. Это стадия «бурления» и мощного противостояния различных тенденций и устремлений членов команды. Для этой стадии характерно:  Сопротивление выполнению задачи и новым подходам к совершенствованию качества (отличным от тех, которые каждый индивидуальный член находит удобным для использования).  Резкие колебания отношения к членам команды и к успеху проекта.  Продолжение обсуждения проблем среди членов группы, даже когда они договариваются о конкретном результате.  Оборонительность и соревновательность, разбивка на фракции и выбор союзников, борьба за лидерство.  Установление нереалистических целей. Со временем, однако, членам команды удается по большей части спорных вопросов выработать единую позицию, зафиксировать свои командные роли, взаимные статусы и правила взаимодействия друг с другом. Происходит процесс выработки некой «командной культуры» (по аналогии с «корпоративной культурой»). Это – стадия нормализации. На этой стадии члены группы соглашаются с ролями, предложенными им командой, критика становится конструктивной, появляется и активно развивается взаимопомощь, вырабатываются механизмы «мягкого» разрешения конфликтов, возникает «командная солидарность» и чувство принадлежности к команде, между членами команды возникают личные взаимоотношения. Следующая стадия – стадия деятельности. Это та стадия, ради которой и шла эволюция команды. На этой стадии команда начинает эффективно выполнять поставленные задачи. Члены команды уладили свои отношения и сформулировали ожидания, выявили и приняли сильные и слабые стороны друг друга, узнали, каковы их роли. Теперь они начинают работать – проводить диагностику и решать проблемы, осуществлять необходимые изменения. На стадии деятельности члены команды понимают личностные и групповые процессы, происходящие в команде, сильные и слабые стороны друг друга. Одним из главных мотивирующих факторов становится удовлетворение от результатов командной деятельности. Как и любой объект или процесс в природе, командная деятельность также имеет свой конец. В конечную стадию расформирования, команда может вступить по разным причинам. Однако основных причин две: это достижение командой стоящей перед ней целей или потеря веры ее членов в возможность её осуществления в реальное время. И в первом, и во втором случае, если команда не расформировывается достаточно быстро (как, например, в проектных командах, где закрытие проекта одновременно означает и роспуск проектной команды), то в ней начинают прогрессировать деструктивные процессы: расцветает интриганство, начинают происходить явления саботажа, члены команды начинают терять доверие к своему лидеру и перестают поддерживать «командную культуру». Для формирования команды используются инструменты: Навыки в области межличностного общения. 87 Для управления и развития команды проекта важны навыки межличностных отношений, такие как, умение сопереживать, оказывать влияние, творческий подход к работе. Регулируя настроение внутри команды, создавая атмосферу уважения и доверия, руководитель проекта и команда управления проектом могут многократно снизить количество возникающих проблем и повысить взаимодействие сотрудников. Обучение. Если члены команды проекта не обладают профессиональными навыками, необходимыми для выполнения какой-либо работы, то развитие таких навыков нужно предусмотреть как часть работы проекта. Для обеспечения обучения составляют план обучения. Обучение включает в себя операции, направленные на повышение квалификации членов команды проекта. Тимбилдинг. Для того чтобы команда представляла собой единое целое, проводятся мероприятия по ее укреплению. Операции по укреплению команды могут выполняться в виде специальных тренингов. Укреплению команды способствует проведение регулярных обсуждений хода проекта, совместная работа над плановыми задачами, проведение неформальных совместных мероприятий. Принципы взаимодействия. Командам проектов рекомендуется следовать формальным принципам, которые позволяют сделать ожидания членов команды понятными и снизить вероятность возникновения конфликтов внутри команды. При помощи принципов устанавливаются правила поведения членов команды проекта. Принципы могут касаться таких пунктов, как свободный рабочий график, добровольная или обязательная работа сверхурочно, обучение, командировки, премии. Соблюдение правил поведения способствует повышению производительности труда. Со-расположение. Сплочению команды способствует размещение членов команды проекта в одном месте. Стратегия со-расположения предполагает наличие комнаты, оснащенной электронными средствами связи, досками для расписаний и другими приспособлениями, которые способствуют взаимному общению. Поощрение и премирование. Стимулирование и поощрение желаемого поведения членов команды является частью процесса развития команды. План поощрения создается в процессе планирования команды проекта. Решения о премировании принимаются на основании результата оценки эффективности работы команды. Выходом из процесса является оценка эффективности команды проекта Для оценки эффективности работы команды могут использоваться следующие показатели:  Отзывы заказчиков.  Количественные показатели проекта (сроки, бюджет).  Повышение навыков членов команды.  Повышение квалификации.  Сокращение текучести кадров. 9.1.4. Управление командой проекта Входы в процесс  Назначение персонала в проекте  План управления проектом Методы и инструменты  Наблюдение обсуждение  Оценка эффективности Выходы из процесса и  Запросы изменения  Обновления управления на плана 88  Оценка эффективности команды проекта  Отчеты об исполнении  Активы организационного процесса проекта проектом  Управление  Обновления конфликтами факторов внешней среды предприятия  Журнал регистрации потенциальных  Обновления проблем активов организационного  Навыки процесса межличностного общения Таблица 34. Управление командой проекта Согласно PMBOK, управление командой проекта включает в себя контроль за деятельностью членов команды проекта, обеспечение обратной связи, решение проблем и координацию изменений, направленных на повышение эффективности исполнения проекта. Для управления командой используются инструменты: Наблюдение и обсуждение Наблюдение и обсуждение являются инструментами для контролирования процесса выполнения работ и настроения внутри команды проекта. Многие руководители проектов имеют низкую коммуникабельность и испытывают сложности в общении. Для таких руководителей рекомендуется осуществлять управление командой проекта методом "прогулки". Руководитель проекта регулярно обходит пространство офиса, в котором работает команда. Встречая члена команды, руководитель начинает разговор произвольной фразой, например, "С каким счетом закончился вчерашний матч?". Член команды, как правило, после некоторого обсуждения результатов игры перейдет (с таким же увлечением) к рассказу о выполнении проекта. Метод "прогулки" позволяет сделать процесс коммуникации более свободным и искренним. Оценка эффективности выполнения работ проекта Оценка эффективности - это инструмент, позволяющий:  уточнить правильность распределения ролей и ответственности;  организовать получение исполнителями оценки их работ (особенно положительных оценок, стимулирующих производительность труда);  выявить неизвестные ранее проблемы;  разработать индивидуальные планы повышения квалификации;  определить ближайшие цели. Урегулирование конфликтов Конфликт возникает, когда одна из конфликтующих сторон полагает, что другая сторона делает что-то, препятствующее достижению поставленной цели. Мерой конфликта является неудовлетворенность несогласованных сторон. Конфликт считается разрешенным, когда неудовлетворенность обеих сторон снижается до приемлемого уровня. Существуют специальные методы для разрешения конфликтов. К ним относятся: принуждение, сглаживание, компромисс, решение проблемы, уклонение. Выбор метода связан с желанием получить немедленное влияние на конфликт или долгосрочное воздействие.  Способ разрешения конфликта «Принуждение» заключается в принуждении к согласованию одной стороной другой стороны и применяется, когда одно лицо имеет власть над другим лицом, участвующим в конфликте.  Способ «Сглаживание» минимизирует противоречия, породившие конфликт, но полностью его не устраняет, поэтому через некоторое время конфликт может повториться. 89  Способ «Компромисс» подобен сглаживанию, однако, если компромиссы закрепляются документально, то это может быть окончательным решением конфликта.  Способ «Решение конфликта» основан на предположении, что все разногласия должны иметь правильное решение. Это наилучший способ разрешения конфликта, поскольку работа над разногласиями раскрывает факты, подтверждающие правоту одной из сторон.  «Уклонение» является самым плохим способом разрешения любой конфликтной ситуации. Разрешение конфликта откладывается на неопределенный срок, что оказывает отрицательное воздействие на команду проекта. Журнал регистрации проблем В процессе управления командой проекта следует вести журнал регистрации проблем, где в письменной форме указать конкретных людей, в обязанности которых входит решение конкретных проблем к определенному сроку. Такой журнал поможет членам команды следить за тем, как и когда будут решены те или иные проблемы. Проблемы могут возникать из-за разногласия во мнениях, из-за неожиданно возникших непредвиденных обязанностей, выполнение которых необходимо поручить кому-либо из членов команды. Запрошенные изменения Если изменения в кадровых назначениях, вызванные плановыми перестановками или непредвиденными обстоятельствами, могут оказать влияние на план проекта (увеличение сроков в расписании проекта или увеличение бюджета), необходимо оформить запрос на изменения, который будет рассмотрен в рамках процесса общего управления изменениями. Активы организационного процесса (обновления) При завершении процесса управления персоналом обновляются:  Входы для оценки эффективности работы организации. Для оценки эффективности работы организации руководителем проекта должны быть подготовлены представления на каждого члена команды проекта, с которым ему приходиться взаимодействовать.  Документация о накопленных знаниях. Все накопленные знания, приобретенные во время проекта, должны быть документированы и могут включать в себя: o организационные диаграммы проекта, описания позиций и планы управления обеспечением проекта персоналом; o принципы, методы урегулирования конфликтов и процедуры поощрения; o специальные навыки и квалификация определенных членов команды, обнаруженные в процессе исполнения проекта; o проблемы и способы их решения, зафиксированные в журнале регистрации проблем проекта. Очень важное значение при управлении командой проекта играют лидерские качества руководителя проекта. Основные виды власти в проекте:  Формальная – «Делай то, что я говорю, потому, что я твой начальник».  Поощрительная – «Ты очень хорошо сделал работу, и я решил выписать тебе премию».  Взыскательная – «Если не сделаешь работу вовремя, лишишься премии».  Экспертная - «Наш руководитель – мировой эксперт, мы уважаем его мнение и сделаем так, как он сказал».  Ссылочная - «Выполнение требований регламента –не моя прихоть, а требование генерального директора компании». Допустимо использовать все виды власти для достижения целей проекта. 90 10. Управление коммуникациями В процессе коммуникаций первоначальная идея собеседника неизбежно искажается. Без хорошо отлаженного взаимодействия заинтересованных сторон все усилия по реализации проекта, тем более такого, в котором задействовано большое количество людей или даже компаний, могут оказаться тщетными. Эффективные коммуникации могут намного повысить вероятность успешного завершения любого проекта. Это касается как общения «внутри» команды, так и представления проекта руководству, будущим пользователям продукта или прессе. Положительного эффекта можно добиться еще на стадии инициации. Распространение информации о проекте, разъяснение его целей и значения позволяет на ранних стадиях выявить сторонников и противников предстоящих изменений. На практике это значительно облегчает работу менеджера проекта в будущем, при наборе команды проекта или при составлении плана коммуникаций. При помощи этих несложных, но необходимых действий можно значительно сократить подготовительный этап проекта. Нередко подготовка занимает столько же времени, сколько длится весь последующий проект. Это происходит из-за несогласованности интересов сторон, недооценки значения проекта или нечеткого понимания планируемых результатов. Например, план важного для организации проекта внедрения системы электронного документооборота занимал около 60 страниц. В связи с этим у руководства ушло полтора месяца на его согласование, хотя предполагалось, что работы по проекту начнутся через неделю. Из-за возникшего отставания пришлось пересматривать график финансирования проекта, что повлекло за собой задержку еще в две недели. В результате этих проволочек вместо ожидаемых результатов в текущем году система была внедрена только на следующий год. Между тем 30-минутная общая презентация проекта для руководства могла бы ликвидировать риск серьезного отставания уже на начальном этапе работ, и проект завершился бы успешно в запланированные сроки. Для точного, своевременного и полного донесения информации до всех участников проекта необходимо управлять коммуникациями. Управление коммуникациями проекта включает в себя процессы, необходимые для гарантии своевременных и соответствующих требованиям процессам генерации сбора, хранения и распространения информации проекта между его участниками. 10.1.1. Входы в процесс Идентификация участников проекта Методы и инструменты Выходы из процесса  Устав проекта  Документация по  Реестр участников поставщикам проекта  Анализ участников  Факторы внешней  Стратегия проекта среды предприятия управления  Экспертная оценка участниками  Активы проекта организационного процесса Таблица 35. Идентификация участников проекта Идентификация участников проекта это определение всех людей или организаций, воздействующих на проект и документирование важной информации, касающейся их интересов, вовлечения или влияния на успех проекта. Шаги идентификации участников проекта:  Идентификация всех потенциальных участников проекта и всей значимой информации  Определение потенциального влияния на проект каждого участника. 91  Определение, как ключевые участники проекта могут реагировать на различные ситуации. После того, как участники проекта определены необходимо определит стратегию работы с ними:  Поддерживать удовлетворение (для участников с большими полномочиями и слабым интересом к проекту, например, руководителей высшего звена).  Тесно сотрудничать (Для участников с большими полномочиями и большим интересом к итогам проекта, например для заказчика).  Информировать (для участников с небольшими полномочиями, но значительным интересом к проекту)  Наблюдать (для участников с маленькими полномочиями и слабым интересом к проекту). Стратегия управления участниками проекта определяет подход для повышения поддержки и уменьшения негативного влияния участников на протяжении всего жизненного цикла. Стратегия включает такие элементы как:  Выявление ключевых участников, которые могут значительно повлиять на проект.  Желаемый уровень участия каждого идентифицированного участника в проекте.  Группировка участников проекта и управление ими (как группами). Пример общего представления стратегии управления участниками проекта – матрица анализа участников проекта:  Участник  Роль  Влияние  Стратегия проекта работы         Таблица 36. Пример матрицы анализа участников проекта 10.1.2. Входы в процесс Планирование коммуникаций Методы и инструменты Выходы из процесса  Реестр участников проекта  Анализ требований к коммуникациям  Стратегия  План управления управления  Средства коммуникациями участниками проекта коммуникации  Обновления  Факторы внешней  Модели документации среды предприятия коммуникации проекта  Активы  Методы организационного коммуникации процесса Таблица 37. Планирование коммуникаций Планирование коммуникаций определяет информационные и коммуникационные нужды заинтересованных лиц (Кто они, уровень их заинтересованности и степень влияния в проекте; кому, когда, какая необходима информация и как она будет передана). Команда проекта должна описать правила хранения информации по проекту, например: № Документ Формат Место хранения документа 92 Регламентирующие документы 1. 2. Проектные документы 1. 2. Таблица 38. Пример описания правил хранения информации по проекту Должны быть описаны требования к документированию проекта, например: № Документ Использование Использование документа в первой фазе документа во второй проекта фазе проекта 1. Регламенты, Обязательно/По Обязательно/По документы, согласованию с согласованию с шаблоны Заказчиком/По Заказчиком/По необходимости/Не используется 2. необходимости/Не используется … Таблица 39. Пример требований к документированию проекта Необходимо описать каналы коммуникаций участников проекта, например: Исполнители и менеджер проекта образуют сеть каналов взаимодействия типа «каждый с каждым». Сеть позволят быстро делиться информацией и принимать оперативные решения. Исполнитель Исполнитель Исполнитель Менеджер проекта Рис. 41. Пример сети каналов взаимодействия типа «Каждый с каждым» Руководитель портфеля проектов и менеджеры проектов образуют сеть каналов взаимодействия типа «колесо». В этой сети вся информация о проекте поступает для руководителя только через менеджера проекта. 93 Менеджер проекта Менеджер проекта Менеджер проекта Руководитель портфеля проектов Менеджер проекта Рис.42. Пример сети каналов взаимодействия типа «Колесо» Взаимодействие менеджера проекта с заказчиком происходят напрямую, с привлечением руководителя портфеля проектов при необходимости решения конфликтных ситуаций и принятии решений, в которых требуется согласование или утверждение руководителя портфеля проектов. Исполнитель Исполнитель Исполнитель Менеджер проекта Заказчик Руководитель портфеля проектов Рис. 43. Пример сети каналов взаимодействия с участием заказчика. 94 Взаимодействие по проектам с руководством компании происходят только через руководителя портфеля проектов. Руководитель портфеля проектов Руководитель компании Рис. 44. Пример взаимодействия с генеральным директором. План коммуникаций должен содержать:  Требования к коммуникациям со стороны участников проекта.  Сведения о передаваемой информации, включая формат, содержание и уровень детализации.  Имя сотрудника, ответственного за передачу информации.  Имя сотрудника или группы – получателей данной информации.  Методы или технологии, используемые для передачи информации (например, служебная записка, электронная почта и/или пресс-релизы).  Частота коммуникации (например, еженедельно).  Схема передачи по инстанциям, определяющая сроки и порядок передачи на вышестоящие уровни (цепочка) проблем, которые не могут быть решены персоналом на низшем уровне.  Метод обновления и уточнения плана управления коммуникациями по мере продвижения и развития проекта.  Глоссарий общепринятой терминологии. Общее представление о плане коммуникаций, можно привести в таблице: 95 № Задача Входящая информация От кого Кому Частота, срок получения Способ коммун икаций Результат Условие Инициация проекта 1. 2. Планирование проекта 1. 2. Исполнение и контроль проекта 1. 2. Завершение проекта 1. 2. Таблица 40. Пример формы плана коммуникаций  96 10.1.3. Распространение информации Входы в процесс Методы и инструменты Выходы из процесса Исполнитель, Менеджер ресурсов, Ведущий специалист Администратор проекта Менеджер проекта информация Генеральный директор, Спонсор, Инициатор Руководитель портфеля проектов Заказчик № Документ/ Президент  План управления проектом  Методы  Обновления коммуникаций  Отчеты об активов исполнении  Способы организационного распространения  Активы процесса информации организационного процесса Таблица 41. Распространение информации Распространение информации это своевременное предоставление необходимой информации участникам проекта. Средства распространения информации:  Переговоры.  Расширенные совещания.  Телефонные звонки.  Электронная почта (E-mail).  Информационная система управления проектом.  И другие. Для эффективного распространения информации может быть составлена матрица документации проекта, например: Обозначения:  - Разрабатывает.  - Согласует.  - Обязательное знание: активный участник.  - Желательное знание: пассивный участник. * - Звездочка означает, что функция выполняется по необходимости. Проектные документы 1. Заявки 2. 3. Описание содержания проекта Устав проекта 4. План проекта 5. Бюджет проекта * * * *                    97 6. 7. 8. 9. 10 . 11 . 12 . 13 . Отчет по состоянию проекта Итоговый отчет по проекту Запрос на изменение параметров проекта Регистрационный журнал изменений Протокол совещания по проекту Акт приемки работ Отчетность Исполнителей по проекту Отчетность Менеджера проекта перед Руководителем портфеля проекта Информация от Заказчика Приказы * * Исполнитель, Менеджер ресурсов, Ведущий специалист Администратор проекта Менеджер проекта информация Генеральный директор, Спонсор, Инициатор Руководитель портфеля проектов Заказчик Документ/ Президент №                          14  * * . 15     * * * . 16 Инструкции        . Таблица 42. Матрица документации проекта Регулярные отчеты и регулярные совещания Как часто нужно делать регулярные отчеты? Стандартных требований не существует, но чаще всего используется еженедельная отчетность: именно этот срок чаще всего отводится руководителем проекта на выполнение очередного этапа. Кроме того, регулярный статус-отчет позволит вовремя справляться с затруднениями, связанными, например, с изменением бизнес-процессов в компании заказчика. В отчет включается информация о ранее запланированных и ныне выполненных работах, задействованных ресурсах, мониторинг рисков. Если в статус-отчете присутствует информация, несущая в себе элементы коммерческой тайны, то полная версия отсылается руководству собственной компании, а сокращенная заказчику. 98 Что касается отчетности по ресурсам, то здесь есть тесная взаимосвязь между управлением персоналом и коммуникациями. Руководитель проекта в организации, имеющей матричную структуру, должен заранее, а не спонтанно набирать команду. Он же должен оценивать и повышать качество работы персонала, что в крупной компании довольно сложно, так как отсутствуют инструменты стимулирования, имеющиеся у руководителя функционального подразделения. Таким образом, важной составной частью управления коммуникациями является взаимодействие с владельцами ресурсов. Совещания нужно проводить регулярно. Участники проектной команды обмениваются подробностями текущей работы, выявляют проблемы, требующие коллективного решения, распределяют дальнейшие обязанности. На таких митингах часто рождаются ценные коллективные идеи, актуальные для уникальных проектов. Встречи «один на один» с ключевыми заинтересованными лицами могут дать тот результат, который невозможно получить в аудитории. В частности, можно в чем-то убедить собеседника, найти единомышленника для защиты своей идеи на предстоящем совещании, заручиться его поддержкой. Правила проведения эффективного совещания В ходе совещания необходимо следовать основным принципам: во-первых, совещание должно быть проведено в строго назначенное время, не рекомендуется несколько раз подряд переносить его на более поздний срок. Во-вторых, первым пунктом обсуждения должна быть повестка, которая рассылается заранее и утверждается всеми участниками совещания. Если во время совещания возникают вопросы, на которые невозможно найти ответ за пять минут, то их следует зафиксировать и внести в повестку следующего совещания. Лучше всего проводить часовые совещания. Даже если на обсуждение объективно требуется два часа, то лучше назначить два часовых совещания, чтобы не утомлять участников. И главное — доброжелательность. Никогда не следует переходить на личности. Критикуя идеи, не критикуйте людей. Извлеченные уроки Чтобы каждый раз не «изобретать велосипед», опыт необходимо архивировать, складывать в корпоративную базу знаний, в простейшем; виде — в файловое хранилище, в более совершенном — в специализированную информационную систему управления документами, Во втором случае инструмент архивирования может быть включен в информационную систему управления проектами (ИСУП). Как правило, современные ИСУП состоят из двух частей: инструмента календарно-сетевого планирования проекта и веб-сайта с библиотеками документов, форумами, реестрами рисков и проблем и т. п. Все это наполняется в оперативном порядке. Когда проект закончится, останется лишь сохранить те части, которые можно использовать повторно в новых проектах. 10.1.4. Управление ожиданиями участников проекта Входы в процесс  Реестр участников проекта  Стратегия управления участниками проекта  План управления проектом Методы и инструменты  Методы коммуникации  Навыки межличностных отношений  Навыки общего менеджмента Выходы из процесса  Обновление активов организационного процесса  Запросы на изменения  Обновления плана управления 99 проектом  Журнал регистрации потенциальных  Обновления проблем документации проекта  Журнал регистрации изменений  Активы организационного процесса Таблица 43. Управление ожиданиями участников проекта Управление ожиданиями участников проекта относится к управлению коммуникациями для удовлетворения потребностей участников проекта и решения возникающих проблем. Активное управление ожиданиями участников проекта повышает вероятность того, что не произойдет сбоя исполнения проекта из-за нерешенных проблем с участниками, способствует укреплению слаженности работы сотрудников, а также снижает вероятность нарушения нормального хода исполнения проекта. Обычно управление ожиданиями участников проекта входит в обязанности менеджера проекта. Журнал регистрации потенциальных проблем – это инструмент, который может быть использован для документации и мониторинга решений спорных вопросов и проблем.  Потен  Д  Ответс  Пл  С  Д  Оп циальная ата твенный ановая татус ата исание проблема регистр дата решен решения ации решения ия        Таблица 44. Форма журнала регистрации проблем К навыкам межличностного общения относят  Умение установить доверительные отношения.  Умение решать конфликты.  Умение активно слушать.  Умение преодолевать сопротивление изменениям. К навыкам общего менеджмента относят:  Презентационные.  Ведения переговоров.  Изложения мыслей на бумаге.  Публичных выступлений. 10.1.5. Отчетность по исполнению Входы в процесс  План управления проектом  Данные о исполнении работ  Измерение эффективности  Прогнозы по исполнению бюджета Методы и инструменты  Анализ отклонений  Методы прогнозирования  Методы коммуникации  Системы отчетности Выходы из процесса  Отчеты о исполнении  Обновления активов организационного процесса  Запросы на изменения 100  Активы организационного процесса Таблица 45. Отчетность по исполнению Отчетность по исполнению проекта включает в себя сор и распространение информации о ходе проекта с целью предоставления участникам проекта достоверной информации о выполненных работах и потраченных ресурсах. Отчетность по исполнению может включать в себя: Отчет о состоянии проекта. Описывает, де мы сейчас находимся относительно базовых планов (по стоимости, содержанию, расписанию, качеству).  Отчет о прогрессе. Описывает, что было сделано за прошедший период.  Отчет о тренде. Оценивает улучшается или ухудшается ситуация.  Прогноз. Предсказывает будущее состояние проекта.  Отчет об освоенном объеме.  Другие отчеты по запросу руководства. 11. Управление рисками проекта Управление рисками проекта включает в себя процессы, связанные с определением, анализом и реагированием на риски проекта с целью повышения вероятности и степени влиянии положительных и снижения вероятности и степени влияния негативных событий в проекте. Риск проекта – это неопределенное событие или условие, которое в случае возникновения, имеет позитивное или негативное воздействие, по меньшей мере на одну из целей проекта, например, сроки, стоимость, содержание или качество. Возможность наступления риска, а также возможность воздействия на ход проекта и конечный результат уменьшается по ходу проекта. Стоимость риска в случае его возникновения увеличивается от этапа к этапу и достигает максимума на последнем из них. Риски подразделяются на известные и неизвестные. Известные риски идентифицируются и подлежат управлению - создаются планы реагирования на риски и резервы на возможные потери. Неизвестные риски нельзя определить, и, следовательно, невозможно спланировать действия по реагированию на такой риск. Событие риска - потенциально возможное событие, которое может нанести ущерб или принести выгоды проекту. Вероятность возникновения риска - вероятность того, что событие риска наступит. Все риски имеют вероятность больше нуля и меньше 100%. Риск с вероятностью 0 не может произойти и не считается риском. Риск с вероятностью 100% также не является риском, поскольку это достоверное событие, которое должно быть предусмотрено планом проекта. Последствия риска, если он случится, выражаются через дни расписания, трудозатраты, деньги и определяют степень воздействия на цели проекта. Величина риска - показатель, объединяющий вероятность возникновения риска и его последствия. Величина риска рассчитывается путем умножения вероятности возникновения риска на соответствующие последствия. Резерв для непредвиденных обстоятельств (или резерв для покрытия неопределенности) - сумма денег или промежуток времени, которые необходимы сверх расчетных величин для снижения риска перерасхода, связанного с достижением целей проекта, до приемлемого для организации уровня; обычно включаются в базовый план стоимости или расписания проекта. 101 Управленческий резерв - сумма денег или промежуток времени, не включаемые в базовый план стоимости или расписания проекта и используемый руководством для предотвращения негативных последствий ситуаций, которые невозможно спрогнозировать. Толерантность к риску - это готовность или неготовность лица или организации рисковать. Некоторые организации берут на себя риск, в то время как другие его избегают. Одни компании рискуют потерять очень много денег ради шанса получить их еще больше. Другие компании не идут на риски, связанные с финансовыми потерями. 11.1.1. Входы в процесс Планирование управления рисками Методы и инструменты Выходы из процесса  Описание содержания проекта  План управления стоимостью проекта  План управления расписанием проекта  Совещания по  План управления планированию и  План управления рисками анализу коммуникациями проекта  Факторы внешней среды предприятия  Активы организационного процесса Таблица 46. Планирование управления рисками К планированию управления рисками следует относиться так же серьезно, как к планированию стоимости и расписания проекта. Качественное планирование повышает вероятность получения положительных результатов остальных процессов управления рисками. Планирование управления рисками - это процесс определения подходов и планирования операций по управлению рисками проекта. План управления рисками включает:  Методология. Определение подходов, инструментов и источников данных, которые могут использоваться для управления рисками в данном проекте.  Распределение ролей и ответственности. Список позиций выполнения, поддержки и управления рисками для каждого вида операций, включенных в план управления рисками, назначение сотрудников на эти позиции и разъяснение их ответственности.  Разработка бюджета. Выделение ресурсов и оценка стоимости мероприятий, необходимых для управления рисками. Эти данные включаются в базовый план по стоимости проекта.  Сроки. Определение сроков и частоты выполнения процесса управления рисками на протяжении всего жизненного цикла проекта, а также определение операций по управлению рисками, которые необходимо включить в расписание проекта. 102  Категории рисков. Структура, на основании которой производится систематическая и всесторонняя идентификация рисков с нужной степенью детализации; такая структура способствует повышению эффективности и качества идентификации рисков. Организация может использовать разработанную ранее классификацию типичных рисков.  И другие. Источниками входной информации для процессов планирования рисков являются:  Факторы внешней среды предприятия. Отношение к риску и толерантность к риску организаций и лиц, участвующих в проекте, оказывает влияние на план управления проектом и может проявляться в конкретных действиях.  Активы организационного процесса. Организации могут иметь заранее разработанные подходы к управлению рисками, например категории рисков, общие определения понятий и терминов, стандартные шаблоны, схемы распределения ролей и ответственности, а также определенные уровни полномочий для принятия решений.  Описание содержания проекта.  План управления проектом. В качестве инструментов и методов планирования управлением рисками используют совещания по планированию и анализу. Команда проекта проводит совещания для разработки плана управления рисками, в которых могут принимать участие менеджер проекта, отдельные члены команды проекта и участники проекта, представители организации, отвечающие за операции по планированию рисков и реагированию на них. На совещаниях составляются базовые планы по проведению операций управления рисками. Также разрабатываются элементы стоимости рисков и плановые операции, которые включаются соответственно в бюджет проекта и расписание. Утверждается распределение ответственности в случае наступления риска. Имеющиеся в организации общие шаблоны, касающиеся категорий рисков и определения терминов (например, уровни рисков, вероятность возникновения рисков по типам, последствия рисков для целей проекта по типам целей, а также матрица вероятности и последствий), приспосабливаются для каждого конкретного проекта с учетом его специфики. Выходы этих операций сводятся в план управления рисками. Иерархическая структура рисков может быть построена по следующему принципу: 103 ПРОЕКТ Технический Внешний Организационный Управление проектом Сложные или нереализуемые требования Поставщики и подрядчики У заказчика сменится руководитель проекта Занижена оценка внутренних затрат Несовершенство технологии Предписания контролирующих органов Сотрудники могут быть перегружены в других проектах Руководитель проекта планирует отпуск во время работ проекта Отказ оборудования Увеличение требований Заказчика Заказчик несвоевременно выполнит свою часть работ по проекту Заказчик не подписал договор Рис. 47. Пример иерархической структуры рисков. Определение вероятности возникновения рисков и их последствий. Общие определения уровней вероятности и уровней воздействия адаптируются отдельно для каждого проекта в ходе процесса планирования управления рисками и используются в процессе качественного анализа рисков. Можно применить относительную шкалу, на которой вероятность обозначена описательно, со значениями от "крайне маловероятно" до "почти наверное", или шкалу, на которой вероятности соответствует цифровое значение, например: 0,1 - 0,3 - 0,5 - 0,7 - 0,9. В таблице представлено семиуровневое разделение вероятности. Для каждого интервала вероятностей выполнена относительная и числовая оценка.  Таблица. Семиуровневая оценка вероятности возникновения риска  Интервал вероятностей  Значение вероятности, используемое для вычислений  Словесная формулировка  Числовая оценка  14% От 1% до  7%  крайне маловероятно  1  28% От 15% до  21%  низкая вероятность  2  42% От 29% до  35%  скорее нет  3  57% От 43% до  50%  50-50  4  72% От 58% до  65%  возможно  5  86% От 73% до  79%  весьма правдоподобно  6 104  7  От 87% до  93%  почти 99% наверняка Таблица 48. Семиуровневая оценка вероятности возникновения риска При оценке воздействия риска определяется потенциальный эффект, который он может оказать на цель проекта (например время, стоимость, содержание или качество). В таблице представлена шкала для оценки угрозы риска, определенного в денежном выражении.  Таблица. Шкала для оценки последствий риска, измеряемого в деньгах  Денежное выражение 1  до $100  2  $100-$1000  3  $1000-$10,000  4  $10,000-$100,000  5  $100,000-$1,000,000  6  $1,000,000-$10 миллионов  7  $10 миллионов-$100 миллионов  8  $100 миллионов-$1 миллиард  9  $1 миллиард-$10 миллиардов  10  свыше $10 миллиардов  Оценка  Таблица 49. Шкала для оценки последствий риска, измеряемого в деньгах Когда денежные единицы не могут быть применены, проектная группа может использовать другие шкалы оценки последствий риска. Система оценки воздействий должна отражать политику и ценности организации и проектной группы.  Таблица. Шкала для оценки последствий риска, измеряемого отклонениями в стоимости, сроках и технических условиях проекта  Технические условия  Перерасход средств  Календарный график  1 (низкая)  до 1%  сдвиг на 1 неделю  небольшая потеря производительности   до 5%    Оценка 2 сдвиг на 2 умеренное 105 (средняя) недели снижение производительности  3 (высокая)  до 10%  сдвиг на 1 месяц  серьезный ущерб для производительности  4 (критическая)  от 10%  мес.  задача не может быть выполнена сдвиг более 1 Таблица 50. Шкала для оценки последствий риска, измеряемого в деньгах Относительная шкала последствий разрабатывается каждой организацией самостоятельно. Шкала содержит только описательные обозначения, например "очень низкий", "низкий", "средний", "высокий" и "очень высокий", расположенные в порядке возрастания максимальной силы воздействия риска согласно определению данной организации. То же самое можно сделать иначе, путем присвоения данным последствиям цифровых значений, которые могут быть линейными и нелинейными, например 0,1 - 0,3 - 0,5 - 0,7 - 0,9 или 0,05 - 0,1- 0,2 - 0,4 - 0,8. Матрица вероятности и последствий содержит комбинации вероятности и воздействия, при помощи которых рискам присваивается определенный ранг: низкий, средний или высший. Матрица может содержать описательные термины или цифровые обозначения и строится на основании шкал оценки вероятности и оценки степени влияния возможного риска. Левый столбец матрицы содержит значения вероятности возникновения риска, в первой строке расположена шкала со значениями возможных последствий. Ячейки заполняется результатами перемножения значений этих шкал. Сопоставляя значение ячейки матрицы со шкалой оценки воздействия, риски можно разделить по категориям - малые, средние и большие. Рассмотрим матрицу вероятности и последствий, представленную на рисунке. Риски, имеющие очень высокие вероятности, но незначительные последствия, а также риски, имеющие низкие вероятности и незначительные последствия, считаются рисками, не оказывающими воздействия (клетки таблицы серого цвета). Риски с очень большими последствиями, но малой вероятностью, как и риски с незначительными последствиями и высокой вероятностью (клетки светло-серого цвета) имеют среднее воздействие на проект. Риски, которым необходимо уделять особое внимание, имеют достаточно высокую вероятность и существенные последствия (клетки таблицы, окрашенные темно-серым цветом).  Таблица. 51. Матрица вероятности и последствий. 106 11.1.2. Входы в процесс Идентификация рисков Методы и инструменты Выходы из процесса  План управления рисками  Оценка стоимости операций  Оценка длительности операций  Анализ документации  Базовый план по содержанию  Методы сбора информации  Реестр участников проекта  Анализ контрольных списков  План управления  Реестр рисков стоимостью  Анализ допущений  План управления  Методы расписанием отображения с помощью диаграмм  План управления качеством  SWOT-анализ  Другие документы  Экспертная оценка проекта  Факторы внешней среды предприятия  Активы организационного процесса Таблица 52. Идентификация рисков Идентификация рисков - процесс определения рисков, способных повлиять на проект, и документирование их характеристик. Идентификацию рисков выполняют члены команды проекта и эксперты по вопросам управления рисками, в ней могут принимать участие заказчики, участники проекта и эксперты в определенных областях. Это итеративный процесс, поскольку по мере развития проекта в рамках его жизненного цикла могут обнаруживаться новые риски. Частота итерации и состав участников выполнения каждого цикла в каждом случае могут быть разными. В процессе идентификации должны принимать участие члены команды проекта, чтобы у них вырабатывалось чувство "собственности" и ответственности за риски и за действия по реагированию на них. Входной информацией для процесса идентификации рисков служат:  Факторы внешней среды предприятия - информация из открытых источников, в том числе коммерческие базы данных, научные работы, бенчмаркинг и другие исследовательские работы в области управления рисками.  Активы организационного процесса - информация о выполнении прежних проектов.  Описание содержания проекта. Допущения проекта приводятся в описании содержания проекта. Неопределенность в допущениях проекта следует рассматривать в качестве потенциального источника возникновения рисков проекта. 107  План управления рисками. Входами для процесса идентификации рисков из плана управления рисками являются схема распределения ролей и ответственности, резерв на операции по управлению рисками в бюджете и в расписании, а также категории рисков.  План управления проектом. Для идентификации рисков необходимо понимание планов управления расписанием, стоимостью и качеством, которые входят в план управления проектом, и анализ выходов этих процессов. Методы и инструменты идентификации рисков Анализ документации заключается в просмотре материалов проекта, разработанных до проведения данного анализа. Анализируется качество планов, согласованность планов, соответствие требованиям Заказчика, допущения проекта, базовые планы по содержанию срокам, стоимости, - все, что может служить показателями возможности риска в проекте. Методы сбора информации:  Мозговой штурм. Целью мозгового штурма является создание подробного списка рисков проекта. Список рисков разрабатывается на собрании, в котором принимает участие 10-15 человек - члены команды проекта, часто совместно с участием экспертов из разных областей, не являющихся членами команды. Участники собрания называют риски, которые считают важными для проекта, при этом не допускается обсуждение выдвинутых рисков. Далее риски сортируют по категориям и уточняют.  Метод Дельфи аналогичен методу мозгового штурма, но его участники не знают друг друга. Ведущий, с помощью списка вопросов для получения идей, касающихся рисков проекта, собирает ответы экспертов. Далее ответы экспертов анализируются, распределяются по категориям и возвращаются экспертам для дальнейших комментариев. Консенсус и список рисков получается через несколько циклов этого процесса. В методе Дельфи исключается давление со стороны коллег и боязнь неловкого положения при высказывании идеи.  Метод номинальных групп позволяет идентифицировать и расположить риски в порядке их важности. Данный метод предполагает формирование группы из 710 экспертов. Каждый участник индивидуально и без обсуждений перечисляет видимые им риски проекта. Далее происходит совместное обсуждение всех выделенных рисков и повторное индивидуальное составление списка рисков в порядке их важности.  Карточки Кроуфорда. Обычно собирается группа из 7-10 экспертов. Ведущий сообщает, что задаст группе 10 вопросов, на каждый из которых участник письменно, на отдельном листе бумаги, должен дать ответы. Вопрос о том, какой из рисков является наиболее важным для проекта, ведущий задает несколько раз. Каждый участник вынужден обдумать десять различных рисков проекта.  Опросы экспертов с большим опытом работы над проектами.  Идентификация основной причины. Цель этого процесса: выявить наиболее существенные причины возникновения рисков проекта и сгруппировать риски по причинам, их вызывающим.  Анализ сильных и слабых сторон, возможностей и угроз (анализ SWOT). Цель проведения анализа - оценить потенциал и окружение проекта. Потенциал проекта, выраженный в виде его сильных и слабых сторон, позволяет оценить разрывы между содержанием проекта и возможностями его выполнения. Оценка 108 окружения проекта показывает, какие благоприятные возможности предоставляет и какими опасностями угрожает внешняя среда.  Анализ контрольных списков. Контрольные списки представляют собой перечни рисков, составленные на основе информации и знаний, которые были накоплены в ходе исполнения прежних аналогичных проектов.  Метод аналогии. Для идентификации рисков этот метод использует накопленные знания и планы по управлению рисками других аналогичных проектов.  Методы с использованием диаграмм. К методам отображения рисков в виде диаграмм относятся диаграммы причинно-следственных связей и блок-схемы процессов, которые позволяют проследить последовательность событий, происходящих в данном процессе. Сравнение методов идентификации рисков проекта представлено в таблице. Таблица. Сравнение методов идентификации рисков Метод Преимущества Недостатки идентификации Может проявиться преобладание Мозговой штурм Способствует взаимодействию членов группы. Быстрый. одной личности. Можно Недорогой. сосредоточиваться только в конкретных областях. Требует сильного ведущего. Для оценки необходимо контролировать склонности группы. Нет доминирования одной Занимает много времени. Метод Delphi личности. Может проводиться Высокая загрузка ведущего. дистанционно через электронную почту. Исключается проблема ранней оценки. Требует участия каждого члена группы. Уменьшается эффект Требует много времени. Высокая Метод доминирующей личности. загрузка ведущего. номинальных Обеспечивает взаимодействие групп участников. Дает упорядоченный список рисков. Быстрый. Легко реализуется. Меньшее взаимодействие между Карточки Должен участвовать каждый участниками. Кроуфорда член группы. Вырабатывается большое количество идей. Можно проводить с группами больше обычного размера. Уменьшает эффект доминирующей личности. Эксперт может быть предвзятым. Опрос экспертов Используется прошлый опыт. Требует много времени. Конкретный и упорядоченный. Предвзятость. Может не Контрольные Легко использовать. содержать конкретных элементов списки для данного проекта. Метод аналогии Использует прошлый опыт для Требует много времени. Легко 109 исключения проблем в будущем. получить результаты, не Подобные проекты содержат подходящие для данного случая. много сходных черт. Аналогия может быть некорректной. Ясное представление Иногда вводит в заблуждение. Методы с Может занимать много времени. использованием участвующих процессов. Легкость построения. Для них диаграмм имеется много компьютерных инструментов. Таблица 53. Сравнение методов идентификации рисков проекта Результатом процесса идентификации рисков является Реестр рисков, содержащий:  список идентифицированных рисков;  список потенциальных действий по реагированию;  основные причины возникновения риска;  уточнение категорий рисков. В процессе идентификации список категорий рисков может пополняться новыми категориями, что может привести к расширению иерархической структуры рисков, разработанной в процессе планирования управления рисками. Пример формы Реестра рисков приведены в таблице. Дата Дата Наименован Инициат Причин Последств Владеле Дата возникновен регистрац ие риска и ор ы риска ия ц риска окончан ия риска ии риска описание ия действия риска Таблица 54. Пример формы Реестра рисков 11.1.3. Качественный анализ рисков Входы в процесс  Реестр рисков  План управления рисками  Описание содержания проекта  Активы организационного процесса Методы и инструменты  Определение вероятности и степени влияния рисков  Матрица вероятности и степени влияния  Оценка качества данных риска  Классификация рисков  Оценка срочности реагирования на риски  Экспертная оценка Выходы из процесса  Обновления реестра рисков 110 Таблица 55. Качественный анализ рисков Качественный анализ рисков – это процесс приоритезации идентифицированных рисков путем совместной оценки вероятности их возникновения и степени влияния, результаты которого используются впоследствии, например в ходе количественного анализа рисков. Обновленный реестр рисков включает:  Сравнительный рейтинг или приоритетный список рисков  Сгруппированные по категориям риски.  Причины рисков или области проекта, требующие особого внимания.  Список рисков, реагирование на которые должно произойти в кратчайшие сроки.  Список рисков для дополнительного анализа и реагирования.  Список рисков низкой приоритетности.  Тенденции рисков. Пример матрицы оценки риска: Вероятность Величина риска = Вероятность х Степень влияния 0,9 0,045 0,09 0,18 0,36 0,72 0,7 0,035 0,07 0,14 0,28 0,58 0,5 0,025 0,05 0,1 0,2 0,4 0,3 0,015 0,03 0,06 0,12 0,24 0,1 0,005 0,01 0,02 0,04 0,08 0,05 0,1 0,2 0,4 0,8 Степень воздействия Таблица 56. Пример матрицы оценки риска Критические риски больше или равно 0,18. Умеренные риски – больше 0,04. Незначительные риски – меньше или равно 0,04. Вероятность и степень воздействия рисков меняются в ходе исполнения проекта, в результате чего изменяется величина рисков. Критические риски могут стать незначительными и наоборот. 11.1.4. Количественный анализ рисков Входы в процесс  Реестр рисков  План управления рисками  План управления стоимостью  План управления расписанием  Активы Методы и инструменты  Методы сора и предоставления данных  Количественный анализ рисков и методы моделирования  Экспертная оценка Выходы из процесса  Обновления реестра рисков 111 организационного процесса Таблица 57. Количественный анализ рисков Количественный анализ рисков - это количественный анализ потенциального воздействия идентифицированных рисков на общие цели проекта. Количественный анализ рисков обычно выполняется для рисков, которые были квалифицированы в результате качественного анализа. При количественном анализе также оцениваются вероятности возникновения рисков и размеры ущерба/выгоды; здесь анализируются риски, имеющие высокие и умеренные ранги. Выбор методов анализа определяется для каждого проекта и зависит от наличия времени и от бюджета. Наиболее распространенными методами количественного анализа являются:  Методы сбора и представления данных, к которым относятся опросы и экспертная оценка, были описаны в разделе идентификации рисков.  Анализ чувствительности помогает определить, какие риски обладают наибольшим потенциальным влиянием на проект. Идея метода состоит в отслеживании параметров, которые оказывают влияние на исследуемую ситуацию проекта. Фиксируя все параметры и изменяя только один из них, можно определить его воздействие на исследуемую ситуацию. Скажем, исследуя вопрос об ожидаемой прибыли Исполнителя проекта, выделяем влияющие на нее параметры, например такие: отсутствие квалифицированного персонала и необходимость в его привлечении, отсутствие помещения под проектный офис и необходимость аренды проектного офиса, отсутствие необходимых технических средств для оборудования рабочих мест и необходимость в закупке требуемых средств. Затем выполняем анализ чувствительности для выделенного параметра, обладающего наибольшим потенциальным риском.  Анализ дерева решений. В сложных ситуациях, когда трудно вычислить результат проекта с учетом возможных рисков, используют метод анализа дерева решений.  Дерево решений - это графический инструмент для анализа проектных ситуаций, находящихся под воздействием риска. Дерево решений описывает рассматриваемую ситуацию с учетом каждой из имеющихся возможностей выбора и возможного сценария. Дерево решений имеет пять элементов. Точки принятия решений - это моменты времени, когда происходит выбор альтернатив. Точка случайного события (точка возникновения последствий) - момент времени, когда с тем или иным результатом наступает случайное событие. Ветви - линии, соединяющие точки принятия решений с точками случайного события. Ветви, исходящие из точки принятия решений, показывают возможные решения, а линии, исходящие из узлов случайных событий, представляют возможные результаты случайного события. Вероятности - числовые значения, расположенные на ветвях дерева и обозначающие вероятность наступления этих событий. Сумма вероятностей в каждой точке принятия решений равна 1. Ожидаемое значение (последствия) - это расположенное в конце ветви количественное выражение каждой альтернативы. Модель создается слева направо. Построение начинается с отображения точки принятия решения, имеющей вид квадрата. Из этой точки рисуют количество ветвей, равное числу проектных альтернативных решений. В конце каждой ветви рисуют кружок, обозначающий возникновение допустимого случайного события, из которого выходят две ветви - возможные результаты вероятностного события. Ветви дерева 112 берут свое начало в точке принятия решений и разрастаются до получения конечных результатов. Путь вдоль ветвей дерева состоит из последовательности отдельных решений и случайных событий. Рассмотрим пример. Торговая компания открывает новый магазин, который должен быть укомплектован оборудованием. Оборудование производят два конкурирующих поставщика (П1 и П2), объявивших одну и ту же дату появления на рынке нового оборудования. Для увеличения эффективности работы компания планирует осуществить внедрение информационной системы. Разработаны три варианта расписания внедрения информационной системы: (Вариант 1, Вариант 2, Вариант 3). Длительность проекта рассматривается как параметр первостепенной важности. Расписание внедрения информационной системы зависит от поставки и монтажа оборудования. Команда проекта оценила вероятность того, что поставщик 1 (П1) или поставщик 2 (П2) поставит нужное оборудование первым. Анализ информации о прежних разработках поставщиков позволил предположить, что поставщик 1 поставит на рынок новое оборудование с вероятностью 60%, соответственно для поставщика 2 эта вероятность будет равна 40%. Команда проекта разработала сетевые графики трех альтернативных вариантов расписания внедрения информационной системы при условии, что оборудование уже поставлено, и оценила возможные значения продолжительности проекта. Рис. 46. Дерево решений для проектной ситуации, находящейся под воздействием риска Рассчитаем возможную длительность проекта для каждого точки случайного события:  ожидаемая длительность для случайного узла А: (80дней* 0,6) + (70дней *0,4) = 76 дней.  ожидаемая длительность для случайного узла Б: (70дней * 0,6) + (75дней *0,4) = 72 дня. 113  ожидаемая длительность для случайного узла В: (75дней * 0,6) + (80дней *0,4) = 78 дней. Результат дерева решений - вариант расписания с наименьшей продолжительностью, равной 72 дням. Дерево решений - инструмент, который позволяет наглядно провести анализ проектных решений, содержащих несколько путей решения. Реестр рисков (обновления) В процессе идентификации рисков начинается формирование реестра рисков, в процессе качественного анализа рисков выполняется его обновление, во время количественного анализа рисков происходит повторное обновление реестра. Реестр рисков является составной частью плана управления проектами, поэтому обновлению подлежат следующие основные элементы плана:  Вероятностный анализ проекта, который выполняет оценку потенциальных выходов расписания и стоимости проекта и составляется перечень контрольных дат завершения и стоимости. Результат анализа, в виде распределения кумулятивных вероятностей, с учетом толерантности к риску участников проекта, позволяет корректировать стоимостную и временную составляющие резерва на непредвиденные обстоятельства.  Вероятность достижения целей по стоимости и времени. При помощи результатов количественного анализа рисков можно оценить вероятность достижения целей проекта на фоне текущих плановых показателей.  Список приоритетных оцененных рисков, куда включены риски, которые представляют наибольшую угрозу или наилучшие благоприятные возможности проекту.  Тренды результатов количественного анализа рисков могут способствовать принятию решений, влияющих на реагирование на риски. 11.1.5. Входы в процесс Планирование реагирования на риски Методы и инструменты Выходы из процесса  Стратегия реагирования на  Обновления негативные риски реестра рисков (угрозы)  Контрактные  Стратегия соглашения,  Реестр рисков реагирования на касающиеся рисков позитивные риски  План управления  Обновления плана (возможности) рисками управления  Стратегия проектом реагирования на  Обновления непредвиденные документации обстоятельства проекта  Экспертная оценка Таблица 58. Планирование реагирования на риски Планирование реагирования на риски – это процесс разработки путей и определения действий по увеличению возможностей и снижению угроз для целей проекта. Данный процесс начинается после проведения качественного анализа рисков и количественного анализа рисков. Он включает в себя определение и назначение одного или нескольких ответственных лиц ("ответственных за реагирование на риски"), в обязанности которых входит реагировать на каждый согласованный и подкрепленный бюджетом риск. В 114 планировании реагирования на риски рассматриваются риски согласно их приоритетам; при необходимости новые ресурсы и операции добавляются в планы управления стоимостью, расписанием и проектом. Запланированные операции по реагированию на риски должны соответствовать серьезности риска, быть экономически эффективными в решении проблемы, своевременными, реалистичными в контексте проекта и согласованными со всеми участниками, а выполнение мероприятий должно быть возложено на ответственное лицо. Часто требуется выбор наилучшего способа реагирования на риски из нескольких возможных вариантов. Возможные стратегии для негативных рисков и угроз:  Уклонение. Уклонение от риска предполагает изменение плана управления проектом таким образом, чтобы исключить угрозу, вызванную негативным риском, оградить цели проекта от последствий риска или ослабить цели, находящиеся под угрозой (например, расширить рамки расписания или уменьшить содержание проекта). Некоторые риски, возникающие на ранних стадиях проекта, можно избежать при помощи уточнения требований, получения информации, улучшения коммуникации.  Передача. Передача риска подразумевает переложение негативных последствий угрозы с ответственностью за реагирование на риск на третью сторону. Передача риска просто переносит ответственность за его управление другой стороне; риск при этом не устраняется. Передача ответственности за риск является наиболее эффективной в отношении финансовых рисков. Передача риска практически всегда предполагает выплату премии за риск стороне, принимающей на себя риск. Инструменты передачи рисков многочисленны и разнообразны; они включают в себя, в частности, использование страховки, гарантии выполнения контракта, гарантийные обязательства и т. д. Условия передачи ответственности за определенные риски третьей стороне могут определяться в контракте. Во многих случаях в контракте с оплатой фактических издержек затраты на риски могут перекладываться на покупателя, а в контракте с фиксированной ценой риск может перекладываться на продавца, если разработка проекта уже находится в стабильном состоянии.  Снижение. Снижение рисков предполагает понижение вероятности и/или последствий негативного рискованного события до приемлемых пределов. Принятие предупредительных мер по снижению вероятности наступления риска или его последствий часто оказываются более эффективными, нежели усилия по устранению негативных последствий, предпринимаемые после наступления события риска. В качестве примеров мероприятий по снижению рисков можно привести: внедрение менее сложных процессов, проведение большего количества испытаний или выбор поставщика, поставки которого носят более стабильный характер. Для снижения рисков может потребоваться разработка прототипа, на основе которого производится пропорциональное увеличение вероятности риска от стендовой модели до процесса или продукта. Если невозможно снизить вероятность, ослабление риска должно быть направлено на последствия риска, а именно на те связи, которые определяют их серьезность. Например, разработка дублирующей подсистемы может сократить последствия отказа основной системы. Стратегия реагирования на позитивные риски:  Использование. Эта стратегия может быть выбрана для реагирования на риски с позитивным воздействием, если необходимо, чтобы данная благоприятная возможность гарантированно была бы реализована. Данная стратегия 115 предназначена для устранения всех неопределенностей, связанных с риском верхнего уровня, при помощи мер, обеспечивающих появление данной благоприятной возможности в различных формах. К числу мер прямого реагирования на данную возможность относятся: привлечение к участию в проекте более талантливого персонала с тем, чтобы сократить время, необходимое для его завершения, либо обеспечение более высокого качество, нежели было предусмотрено первоначальным планом.  Совместное использование. Совместное использование позитивных рисков предусматривает передачу ответственности третьей стороне, способной наилучшим образом воспользоваться представившейся благоприятной возможностью в интересах проекта. К числу мероприятий с совместным использованием благоприятных возможностей относятся: o образование партнерств с совместной ответственностью за риски, команд, o специализированных компаний или совместных предприятий, созданных o специально для управления благоприятными возможностями.  Усиление. При применении этой стратегии изменяется "размер" благоприятной возможности путем повышения вероятности возникновения и/или положительного воздействия, а также путем выявления и максимизации основных источников этих позитивных рисков. Для повышения этой вероятности можно попытаться облегчить или укрепить причину, вызывающую благоприятную возможность, и целенаправленно усилить условия ее появления. Можно также повлиять на источники воздействия, стараясь повысить чувствительность проекта к этой благоприятной возможности. Принятие риска – стратегия, при которой риск принимается. Команда проекта не пытается повлиять на риск. Часто применяется для ситуаций, возможности воздействия на которые ограничены и влияние риска несущественно. Обновленный Реестр рисков содержит:  Идентифицированные риски, их описания, области проекта, на которые они влияют (например, элемент ИСР), причины рисков (например, компонент ИСРс) и как они могут повлиять на цели проекта.  Лица, ответственные за риски, их ответственность.  Выходы качественного и количественного анализов, включая список рисков проекта, упорядоченных по приоритетности, и вероятностный анализ проекта.  Согласованные стратегии реагирования на риски.  Конкретные действия, необходимые для применения выбранной стратегии реагирования.  Симптомы и признаки возникновения риска.  Бюджет и плановые операции, необходимые для выполнения выбранных способов реагирования на риски.  Временной и бюджетный резервы на непредвиденные обстоятельства, предназначенные для обеспечения толерантности к риску участников проекта.  Планы на случай возникновения непредвиденных обстоятельств и условия, при которых они вводятся в действие.  Резервные планы, используемые в качестве ответной реакции на возникновение риска в случае, если первоначальное реагирование на риск оказалось неадекватным.  Остаточные риски, оставшиеся после планового реагирования на риски, а также те, которые были приняты сознательно. 116  Вторичные риски, возникающие в результате применения реагирования на риски.  Резервы на непредвиденные обстоятельства, рассчитанные на основе данных количественного анализа проекта и порогов рисков организации. 11.1.6. Мониторинг и контроль над рисками Входы в процесс  Реестр рисков  План управления рисками  Данные о исполнении работ  Отчеты об исполнении Методы и инструменты  Пересмотр рисков  Аудит рисков  Анализ отклонений и трендов  Техническое измерение исполнения  Анализ резервов  Совещания по текущему состоянию Выходы из процесса  Обновления реестра рисков  Обновления активов организационного процесса  Запрошенные изменения  Обновления плана управления проектом  Обновления документации проекта Таблица 59. Мониторинг и контроль над рисками Плановые операции по реагированию на риски, включенные в план управления проектом, выполняются в течение жизненного цикла проекта, однако, в отношение работ проекта должен проводиться постоянный мониторинг и контроль на предмет обнаружения новых и измененных рисков. Мониторинг и управление рисками – это процесс идентификации, анализа и планирования вновь возникших рисков, отслеживания идентифицированных рисков и тех, которые отнесены в список для постоянного наблюдения, а также проверки и исполнения операций реагирования на риски и оценки их эффективности. Инструменты и методы:  Пересмотр рисков. В процессе мониторинга и управления рисками часто возникает необходимость в проведении идентификации новых рисков, и пересмотре известных рисков с использованием процессов, описанных в данной главе. Пересмотр рисков должен проводиться регулярно, согласно расписанию. Управление рисками проекта должно быть одним из пунктов повестки дня всех совещаний команды проекта. Объем и степень детализации повторений зависят от хода выполнения проекта по отношению к поставленным целям. Например, если возникает риск, отсутствующий в реестре рисков или в списке рисков, подлежащих наблюдению, или если его последствия на цели проекта отличаются от ожидаемых, то плановые мероприятия по реагированию на риски могут оказаться недостаточными. В этом случае для управления риском потребуется провести дополнительное планирование мероприятий по реагированию на риски.  Аудит рисков. Аудит рисков предполагает изучение и предоставление в документальном виде результатов оценки эффективности мероприятий по реагированию на риски, относящихся к идентифицированным рискам, изучение основных причин их возникновения, а также оценку эффективности процесса управления рисками. 117  Анализ отклонений и трендов. Тренды в процессе выполнения проекта подлежат проверке с использованием данных о выполнении. Для мониторинга выполнения всего проекта могут использоваться анализ освоенного объема и другие методы анализа отклонений проекта и трендов. На основании выходов этих анализов можно прогнозировать потенциальные отклонения проекта на момент его завершения по показателям стоимости и расписания. Отклонения от базового плана могут указывать на последствия, вызванные угрозами или благоприятными возможностями.  Техническое измерение исполнения. При техническом измерении исполнения сравниваются получаемые в процессе реализации проекта технические результаты с запланированными. Такие отклонения, как большие или меньшие функциональные возможности по отношению к запланированным на момент контрольного события, способствуют облегчению составлению прогноза о степени успешности в достижении целей содержания проекта.  Анализ резервов. В процессе выполнения проекта могут возникнуть риски, оказывающие позитивное или негативное воздействие на бюджет или на резервы на непредвиденные обстоятельства. При анализе резервов для определения адекватности остатка резерва производится сравнение объема оставшихся резервов на непредвиденные обстоятельства с количеством оставшихся рисков по состоянию на любой момент времени процесса выполнения проекта.  Совещания по текущему состоянию. Управление рисками проекта может быть одним из пунктов повестки дня периодических совещаний о текущем состоянии. В зависимости от идентифицированных рисков, их приоритетности и трудностей реагирования, этот пункт повестки дня может требовать большого количества времени или не требовать вовсе. Чем чаще применяется управление рисками, тем легче оно происходит, а частые обсуждения вопросов, связанных с рисками, делают разговоры о рисках, в особенности об угрозах, более легкими и точными. 12. Управление поставками проекта Управление поставками проекта включает в себя процессы покупки или приобретения тех необходимых продуктов, услуг или результатов, которые производятся вне исполняющей организации. Поставки рассматриваются с двух точек зрения: продавца и покупателя. Согласно условиям контракта организация может выступать в качестве продавца или покупателя продукта, услуги или результатов. Управление поставками проекта включает в себя процессы управления контрактом и управления изменениями, необходимые для администрирования контрактов или заказов на покупку, подготовленных членами команды проекта. Управление поставками проекта также предусматривает администрирование всех контрактов на приобретение проекта, заключенных сторонней организацией (покупателем) с исполняющей организацией (продавцом), а также администрирование контрактных обязательств команды проекта. 12.1.1. Планирование поставок Входы в процесс  Базовый план содержанию Методы и инструменты по  Анализ «производить покупать» или Выходы из процесса  План управления поставками 118  Документация по  Экспертная оценка  Содержание работ требованиям контракта  Типы контрактов участников проекта  Решения  Соглашения о «производит или партнерстве покупать»  Реестр рисков,  Запрошенные изменения  Контракты, касающиеся рисков  Документация по поставкам  Требования к ресурсам операций  Критерии выбора поставщиков  Расписание проекта  Оценки стоимости операций  Базовый план по стоимости  Факторы внешней среды предприятия  Активы организационного процесса Таблица 60. Планирование поставок В процессе планирования поставок устанавливается, какие нужды проекта можно удовлетворить путем закупок товаров, услуг или результатов у сторонних по отношению к проекту организаций, а какие нужды проекта можно удовлетворить силами команды проекта в процессе выполнения проекта. Команда проекта должна принять решение – что выгоднее – произвести продукты или услуги самостоятельно или купить? Факторы анализа производить или покупать приведены в таблице: Производить Покупать Может быть менее затратно Может быт менее затратно Использует простаивающие мощности При малом размере партии может быть невыгодно производить Сохраняет контроль над процессом Использует специфические знания и умения внешних поставщиков Сохраняет коммерческую тайну Подходит при ограниченных возможностях производства Не создает зависимости от ненадежных Усиливает имеющийся персонал за счет поставщиков привлечения внешней рабочей силы Таблица 61. Факторы анализа производить или покупать Основные типы контрактов, используемые в проекте:  Контракты с фиксированной ценой (Fixed Price or Lump Sum) – обычно заключаются для продукта с четко определенными характеристиками. Наиболее часто встречающийся вид контрактов.  Такие контракты представляют риск получения убытков для продавца – себестоимость может превысить цену контракта. В контракте могут быть оговорены стимулирующие платежи, в случае выполнения продавцом определенных условий (например, соблюдение или перевыполнение графика поставок). 119  Контракты с возмещением затрат (Cost-reimbursable) – покупатель оплачивает оговоренные затраты продавца и дополнительно оговоренную сумму, составляющую прибыль продавца. В российской практике встречается редко, так как не все компании готовы посчитать свои затраты и согласовать их с заказчиком. Для заказчика контракт представляет риск увеличения цены при увеличении затрат продавца. Время и материалы (Time and Materials) – гибрид предыдущих типов контрактов, в контракте нет оговоренной общей суммы – она растет с выполнением работ. Обычно используется там, где невозможно сразу точно определить цели и результаты. Основным результатом процесса является План управления поставками, описывающий:  Используемые виды контрактов.  Кто будет готовить независимые оценки, и нужны ли они в качестве критериев оценок  Операции, которые команда управления проектом может выполнить самостоятельно, если в составе исполняющей организации имеются отдел поставок, контрактов или закупок.  Стандартизованные контрактные документы, если они необходимы.  Управление несколькими поставщиками.  Координирование поставок с другими аспектам проекта (например, с отчетностью по соблюдению расписания и по исполнению проекта).  Ограничения и допущения, способные оказать воздействие на планирование покупок и приобретений.  Отслеживание времени опережения, необходимого для закупки или получения предметов от продавцов, и координация графика поставок с разработкой расписания проекта.  Отслеживание решений "производить или покупать" и согласование их с процессами оценки ресурсов операций и разработкой расписания.  Установление для каждого контракта контрольных сроков сдачи результатов поставки и координация с процессами разработки расписания и контроля. Определение необходимости гарантий выполнения контракта или заключения договоров страхования для снижения некоторых форм рисков проекта.  Определение формы и формата для содержания работ контракта.  Осуществление выбора продавцов, если необходимо.  Определение метрик поставок, используемых для управления контрактами и оценки продавцов. 12.1.2. Организация проведения поставок Входы в процесс  План управления проектом  Документация по поставкам  Критерии выбора поставщиков  Список аттестованных Методы и инструменты  Конференции контрагентов  Методы оценки предложений  Независимые оценки  Переговоры о поставках  Экспертная оценка Выходы из процесса  Выбранные продавцы  Решение заключении контракта  Календари ресурсов  Запросы о на 120 поставщиков изменения  Рекламные объявления  Предложения  Обновления плана поставщиков управления  Поиск через проектом Интернет  Документация проекта  Обновления документации  Решения проекта «производить или покупать»  Соглашения о партнерстве  Активы организационного процесса Таблица 62. Организация проведения поставок В процессе организации проведения поставок происходит получение предложений от продавцов, выбор продавца и заключение контрактов. Предложения – это подготовленные поставщиком документы, описывающие намерения и возможности поставщика поставить продукты или услуги, указанные в документации по поставкам:  Готовятся в соответствии с требованиями, изложенными в документации по поставкам.  Представляют собой официальную, имеющую юридическую силу оферту. (Таким образом, предоставляя предложение заказчику, поставщик не имеет юридического и морального права отказаться от заключения договора. При выборе поставщика используются:  Система весов.  Экспертные оценки.  Система рейтинговых оценок поставщиков  Система отсева. Контракт – это взаимно согласованный документ, обязывающий заказчика и подрядчика выполнить оговоренные условия. Споры по контракту решаются в судебном порядке. Основные разделы контракта, это:  Содержание работ или результаты.  Расписание выполнения работ.  Вид и периодичность отчетности по исполнению.  Обязанности и ответственность сторон.  Цены и порядок оплаты.  Критерии приемки.  Гарантийные обязательства и поддержка продукта.  Штрафные санкции.  Механизм прекращения действия контракта и разрешение споров. 12.1.3. Администрирование поставок Входы в процесс  Документация по поставкам  План управления Методы и инструменты  Система управления изменениями контракта  Анализ исполнения Выходы из процесса  Документация по контракту  Обновления 121 проектом поставок активов организационного  Контракт  Инспекции и аудиты процесса  Отчеты об  Отчетность по  Запрошенные исполнении исполнению изменения  Одобренные  Схемы оплаты  Обновления плана запросы на  Администрирование управления изменения претензий проектом  Информация об  Система оперативного исполнении работ учета Таблица 63. Администрирование поставок Администрирование поставок – процесс проверки, что выполнение обязательство поставщиком соответствует контрактным требованиям. Управление контрактами также имеет компоненты управления финансами. Система управления изменениями контракта. Система управления изменениями контракта определяет процесс внесения изменений в содержание контракта. Система включает документы, системы отслеживания, процедуры разрешения конфликтов и уровни иерархии, на которых производится авторизация изменений. Система управления изменениями контрактов должна быть интегрирована в систему общего управления изменениями. Инспектирование и аудит. Инспектирование и аудит проводятся по требованию покупателя и поддерживаются продавцом на основании положений контракта. Они могут проводиться во время исполнения проекта, и предназначены для определения недостатков в процессах выполнения работ продавцом или в результатах работ. Некоторые команды инспекций и аудита могут иметь в своем составе сотрудников покупателя, занимающихся поставками, если это предусмотрено условиями контракта. Отчетность по исполнению. Отчетность по исполнению предоставляет руководству информацию о том, насколько эффективно поставщик продвигается к целям контракта. Отчетность по исполнению контракта является частью общей отчетности по исполнению. Схемы оплаты. Платежи продавцу обычно отслеживаются и осуществляются при помощи системы оплаты счетов, имеющейся на предприятии покупателя. Для больших проектов со сложным расписанием поставок или многоступенчатыми поставками может быть разработана особая схема оплаты. В любом случае, схема оплаты пересматривается и одобряется командой управления проектом, а осуществление платежей производится согласно условиям контракта. Администрирование претензий. Оспариваемые изменения и подразумеваемые изменения представляют собой запрошенные изменения, по которым покупатель и продавец не могут прийти к соглашению о размерах компенсаций изменений, или не могут прийти к соглашению о внесении данных изменений. Оспариваемые изменения называются иногда "претензии", "разногласия" или "апелляции". Претензии подлежат оформлению в документальном виде, обработке, мониторингу и управлению на всем протяжении жизненного цикла проекта, обычно, на основе условий, предусмотренных контрактом. Если стороны не могут сами договорится о решении претензии, то вступают в силу предусмотренные контрактом способы и механизмы разрешения разногласий. Эти статьи контракта могут предусматривать решение спорных вопросов посредством арбитражных или судебных разбирательств, и могут быть инициированы как в период действия, так и по окончании периода действия контракта. Система оперативного учета. Система оперативного учета – это особый комплекс процессов, соответствующих контрольных функций и инструментов автоматизации, объединенных в единое целое, и являющегося частью информационной системы 122 управления проектами. Система оперативного учета используется менеджером проекта для управления контрактной документацией и учетно-отчетными материалами. Данная система используется для поддержания каталога контрактной документации и корреспонденции, а также для поиска и архивирования подобных документов. 12.1.4. Закрытие поставок Входы в процесс  План управления проектом  Документация по поставкам Методы и инструменты  Аудит поставок  Урегулирование путем переговоров  Система оперативного учета Выходы из процесса  Закрытые поставки  Обновления активов организационного процесса Таблица 64. Закрытие поставок Закрытие поставок – процесс завершения всех поставок проекта путем подтверждения, что все работы и результаты по контракту приняты. Досрочное завершение контракта является частным случаем этой процедуры. Обязанности менеджера проекта по закрытию поставок:  Формальная приемка всех предоставленных результатов, работ по контракту.  Содействие завершению всех действий компании по закрытию поставок и перечислению окончательного платежа.  Размещение в архиве документов по поставкам. Документация, размещаемая в архиве:  Первоначальный запрос на предложение от заказчика и все его модификации.  Копии предложения и всех поправок к нему.  Протоколы переговоров.  Корреспонденция по контракту.  Подписанные оригиналы или ксерокопии контракта и всех дополнительных соглашений к нему.  Акты сдачи-приемки.  Счета и платежные поручения. 13. Модели зрелости и корпоративные стандарты управления проектами 13.1. Модели зрелости управления проектами Каждая организация в своем развитии проходит определенные этапы, характеризующиеся различной миссией, стратегией, технологией работы, организационной структурой, уровнем компетенции персонала и другими качественными и количественными характеристиками. Переход на каждый следующий, более высокий уровень развития, делает организацию более конкурентоспособной, динамично реагирующей на требования рынка и оптимально использующей свои внутренние ресурсы. Модели, описывающие этапы (уровни) развития организации, называются моделями уровней зрелости. Организации создают и развивают системы управления проектами, уделяя особое внимание четырем основным их компонентам: 123  персонал;  методология;  организационная структура;  технологии (в т.ч. информационные). Модели организационной зрелости управления проектами предоставляют организациям, преследующим цель создания эффективного управления проектами, возможность оценки текущего состояния системы управления проектами и определения стратегии и тактики развития СУП на предприятии. На сегодняшний день в мире существует достаточно много разработок по моделям зрелости, например:  CMM® SE (Capability Maturity Model for Software Engineering, модель зрелости процессов по разработке программного обеспечения) – модель, разработанная SEI (Software Engineering Institute, Институт инженерии программного обеспечения) с целью предоставить инструмент для системного развития внутренних процессов компаний, разрабатывающих программное обеспечение;  Project FRAMEWORKTM компании ESA (США);  Модель зрелости компании PMSolutions (США);  и др. Компании во всем мире развиваются, становятся более зрелыми и получают выгоды от этого в виде признания, авторитета, влияния и т.д. Теперь, после выхода Модели Организационной Зрелости Управления Проектами (Organization Project Management Maturity Model – OPM3), эти компании смогут оценивать свою зрелость по управлению проектами, планировать свое развитие и получать соответствующие выгоды. OPM3 – это стандарт, выпущенный Американским Институтом Управления проектами (PMI), представляющий собой всесторонний подход, который помогает организациям оценивать и развивать свои возможности по эффективной реализации проектов. OPM3 является своего рода ключом к организационной зрелости управления проектами и содержит три взаимосвязанных элемента:  элемент ЗНАНИЕ (KNOWLEDGE) представляет собой сотни лучших практик по управлению проектами, характеризующих те или иные уровни организационной зрелости УП;  элемент ОЦЕНКА (ASSESSMENT) является инструментом, помогающим организациям оценить текущую зрелость по УП и определить области улучшения;  если организация принимает решение развивать практики управления проектами и переходить на новые, более высокие уровни зрелости по УП, то в дело вступает элемент УЛУЧШЕНИЕ (IMPROVEMENT), который помогает компаниям построить схему развития управления проектами таким образом, чтобы обеспечить максимально эффективное достижение своих стратегических целей. Стандарт ОРМ3 включает в себя опросник, с помощью которого предприятия могут оценить свой уровень зрелости в сфере профессионального управления проектами, а также каталог лучших практик, которые дают основу для сравнения своей деятельности с опытом, близким к эталону. Использование стандарта предполагает циклическую последовательность действий, включающую подготовительный этап, собственно оценку уровня зрелости процессов управления проектами в компании, планирование улучшений на базе результата этой оценки и их реализацию и, наконец, выявление необходимости проведения новой оценки. Уровни зрелости организации в управлении проектами можно оценить следующим образом: 124 Уровень Уровень 1: Начальный Начальные процессы Уровень 2: Повторяющийся Структурированные процессы и стандарты Признаки уровня Оценк а  Нерегламентированные процессы.  Все решения принимаются на основе опыта и компетенции менеджмента.  Смешение информации промежуточного (средний уровень менеджмента) и суммарного уровня (топ-менеджмент).  Оценки и графики основаны на знаниях менеджмента.  Базовых планов нет, сбор фактической информации неформальный.  В основном внимание сосредоточено на проектах.  Анализ качества процесса управления проекта не производится.  Основные процессы, не стандартизованные для всех проектов, используются для больших, очевидных для управления проектов.  Менеджмент только поддерживает и ободряет сотрудников, то есть, нет инструментов и процедур, позволяющих корректно распределить мотивационный фонд по проекту и принимать решения.  Смешение информации промежуточного (средний уровень менеджмента) и суммарного уровня (топ-менеджмент).  Оценки и графики основаны на знаниях экспертов и настраиваемых инструментах.  Создаются планы-графики проектов, сбор фактической информации неформальный, планы-графики проектов не актуализуются своевременно.  В основном внимание сосредоточено на проектах.  Анализ качества процесса управления проекта не производится. 125 Уровень Уровень 3: Определенный Организационные стандарты и утвержденные процессы Уровень 4: Управляемый Управляемые процессы Признаки уровня Оценк а  Все процессы стандартизованы для всех проектов и повторяются в каждом проекте.  Менеджмент управляет утвержденными процессами.  Суммарная и детализированная информация по всем уровням управления.  Существуют Базовые планы, сбор фактической информации неформальный.  Оценки, графики базируются на промышленных стандартах и организационной специфике.  Внимание сосредоточено в основном на организации.  Производится Анализ качества процесса управления проекта.  Все процессы стандартизованы для всех проектов и повторяются в каждом проекте. Процессы интегрированы с корпоративными процессами.  Менеджмент управляет утвержденными процессами. Согласует решения. Анализирует организацию в целом. Использует данные для принятия решений. Непрерывный анализ выполнения.  Оценки, графики обычно базируются на организационных стандартах и спецификациях.  Существуют Базовые планы, сбор фактической информации формализован.  Внимание сосредоточено в основном на организации.  Производится Анализ качества процесса управления проекта. 126 Уровень Признаки уровня Оценк а  Все процессы стандартизованы для всех проектов и повторяются в каждом проекте. Процессы интегрированы с корпоративными процессами.  Менеджмент управляет утвержденными процессами. Согласует решения. Анализирует организацию в целом. Использует данные для принятия решений. Непрерывный анализ выполнения.  Оценки, графики обычно базируются на Уровень 5: Улучшаемый организационных стандартах и Оптимизация процессов спецификациях.  Существуют Базовые планы, сбор фактической информации формализован.  Внимание менеджмента сосредоточено на непрерывном улучшении.  Производится Анализ качества процесса управления проекта. Производится процесс измерения эффективности и результативности проектов. Непрерывное улучшение процессов. Таблица 65. Критерии оценки уровня зрелости 13.2. Анализ корпоративных стандартов управления проектами в России Многие компании в России стремятся развивать методы и инструменты управления проектами. Одним из основных показателей развития КСУП в России в целом можно назвать развитие рынка программного обеспечения ИСУП. Взаимосвязь непрямая, однако большинство компаний, внедряющих ИСУП в том или ином виде разрабатывают КСУП, и наоборот – компании, начинающие разрабатывать стандарты нуждаются в инструментах для автоматизации рутинных расчетов и организации совместной работы, то есть ИСУП. Развитие отечественного рынка систем управления проектами началось с удовлетворения потребностей западных компаний, финансирующих проекты в России и странах СНГ, а также отечественных, работающих с иностранными партнерами. Кризис 1998 года заметно изменил ситуацию, так как после резкого сокращения ИТрасходов крупнейшим российским и зарубежным компаниям потребовалось внедрение технологий, повышающих эффективность восстановления отложенных и реализации новых проектов. По данным нового отчёта IDC Services 2005-2009 Forecast and 2004 Vendor Shares, устойчивый рост российского рынка информационных услуг в 2004 г. продолжился и составил 26,3%, что соответствует 1,9 млрд. долл. По темпам роста он значительно опережает рынки IT-услуг в странах, как Восточной, так и Западной Европы. Одной из основных движущих сил рынка информационных услуг в России в 2004 г. IDC считает продолжающийся уже третий год бурный рост рынка программного обеспечения для автоматизированных систем управления предприятием, темпы роста которого 127 превышают аналогичный показатель IT-отрасли в целом. Прирост объёма этого рынка достиг в 2004 г. почти 52,8% и достиг 194 млн. долл. Главными потребителями систем управления проектами стали предприятия нефтегазовой отрасли, машиностроительные предприятия, строительные и ITкомпании, финансовый и банковский сектора. Каждый год объем продаж на российском рынке ИСУП удваивается. Многие в компании России работают с КСУП. В основном это предприятия: 1. Крупные корпорации, например Лукойл, РАО ЕЭС, Российские Железные Дороги, ГАЗПРОМ, РУСАЛ и другие. Такие компании с одной стороны располагают финансовыми средствами и квалифицированными кадрами для развития, а с другой управляют множеством разнообразных проектов. Необходимо заметить, что основная проблема создания КСУП в подобных компаниях, это большое количество подразделений, самостоятельных юридических лиц, разнородность мнений среди основных сотрудников корпорации, которое не позволяет унифицировать не только процессы управления проектами, но и сильно усложняет создание общей стратегии развития и принципов работы в компании. Кроме того большой размер компании затрудняет внедрение управленческих решений руководства. 2. Крупные компании, открывающие офисы большое количество подразделений в разных регионах. Например, это торговые компании, такие как Снежная Королева, МВИДЕО, Седьмой континент, Евросеть а также банковские структуры, например, Альфа-Банк, Русский Банк Развития, Внешторгбанк. Проблема внедрения КСУП в данных компаниях связана с ускоренным ростом предприятия. Множество проектов создания новых офисов, магазинов, открытие новых бизнесов требует привлечения большого количества ресурсов компании. Организационная структура управления предприятия не успевает «самостоятельно» перестроиться под новый уровень требований к организации работ по проектам. Не хватает квалифицированных кадров, в компаниях не существует понимания приоритетности проектов, что приводит к тому, что подразделения неохотно выделяют сотрудников для участия в приоритетных проектах развития. 3. Компании, работающие с инновационными технологиями. Даже небольшие компании, работающие с современными технологиями, такие как информационные системы, сложное оборудование, научные разработки стремятся внедрить КСУП. Это обусловлено также постоянной работой с иностранными партнерами, использующими подобные стандарты. В этой категории можно назвать такие компании, как IBS, CBOSS, Microsoft и другие. Проблемы данных предприятий связаны с нехваткой ресурсов (как людских, так и финансовых) для полноценного внедрения КСУП. 4. Строительные компании и предприятия, реализующие крупные проекты. Строительство – отрасль, исторически использующая методологию управления проектами. В советском периоде истории нашей страны были развиты методы управления проектами (например, календарно-сетевое планирование). Сейчас строительные компании активно возрождают методологию управления проектами. Сложные масштабные проекты для различных организаций, требующие тщательного планирования и контроля, также требуют использования КСУП. Проблемные моменты для внедрения КСУП в таких компаниях – это низко квалифицированный персонал и нехватка ресурсов. В целом, специфика создания корпоративных стандартов управления проектами в российских предприятиях это:  Низкий уровень зрелости организаций. Как уже говорилось выше, уровень зрелости играет большую роль в успехе создания КСУП. Для большинства 128     российских предприятий уровень зрелости определяется как первый, второй или третий. Стандарты разрабатываются с недостаточными исследованиями бизнеспроцессов предприятия. Регламенты и положения передаются сотрудникам руководством в жесткой форме, без учета всех проблем и задач предприятия, а также уровня квалификации сотрудников и корпоративной культуры; Нежелание руководства предприятий менять однажды созданные стандарты. КСУП должен развиваться по мере роста и развития предприятия. Постоянно меняются рыночные условия, методы работы, квалификация специалистов. В стандарте могут быть выявлены недочеты и ошибки. Инертность руководства и длительные, сильно бюрократизированные процедуры согласования документов тормозят развитие компании. Жесткая регламентация деятельности сотрудников. В настоящий момент для компаний характерно стремление к жесткому регламентированию деятельности сотрудников. Низкий уровень квалификации персонала заставляет руководство устанавливать жесткие требования и рамки деятельности в процессах управления проектами. Однако, механическое выполнение процедур без понимания сути производимых действий вызывает у персонала компании отторжение новых процессов. Внедрение КСУП должно производиться одновременно с обучением сотрудников, а строгий контроль применяться только для ключевых элементов КСУП, например, формы отчетности. Создание корпоративных стандартов управления проектами охватывает в большинстве случаев все предприятие в целом. Внедрение КСУП во всей компании обусловлено переоценкой собственных ресурсов руководством предприятий и недостаточными знаниями процесса внедрения КСУП. Для более быстрого создания КСУП внедрение должно производиться постепенно, захватывая все новые области деятельности компании, проекты, подразделения. При полном охвате всей организации, высок риск неудачи проекта, так как неизбежные допущенные ошибки отражаются на всей компании, и их исправление требует больших средств и усилий. Отсутствие четко оговоренных целей, критериев успешности создания корпоративных стандартов. Без четкого понимания целей создания КСУП невозможно регулировать развитие стандарта, правильно оценить эффективность внедрения. 14. Создание КСУП 14.1. Проектный подход к созданию КСУП Создание КСУП представляет собой описание проекта внедрения организационных изменений в компании. Как уже говорилось выше, компании постоянно развиваются для сохранения конкурентных преимуществ, меняются уровни зрелости в области управления проектами. Переход организации с одного уровня зрелости на другой должен производится последовательно и осознанно. Такой переход подразумевает изменения целей компании, бизнес-процессов, функций сотрудников, методов и инструментария управления, корпоративной культуры, возможно, структуры управления, и других элементов организации. Таким образом, переход на новый уровень зрелости – это организационные изменения на предприятии. Для достижения четвертого уровня зрелости компаниям, управляющим проектами, рекомендуется создать КСУП, согласно критериям, описанным в разделе 5.1. «Модели зрелости управления проектами». 129 Можно выделить два основных подхода к организационным изменениям в компании:  Саморазвитие организации;  Насильственные изменения. Теория о саморазвивающихся компаниях, гласит, что развитие компании определяется внешними и внутренними условиями. Однако, коллективный разум поддается конъюнктурному давлению сиюминутных интересов, фактору сохранения стабильности отношений, решает важнейшие задачи лишь в рамках сложившегося баланса власти и имеющейся корпоративной культуры. Такие организации оказывают сильное сопротивление изменениям. В ходе развития успешно работающих предприятий неизбежно наступает этап, когда необходимо проводить насильственные изменения, так как от персонала требуется выполнение новой работы, новая ответственность за результат, новая система взаимоотношений. Необходимо заметить, что многие компании стремятся создать КСУП, не достигнув третьего уровня зрелости. Последствия такого решения могут выражаться в провале внедрения организационных изменений, так как в организации не созданы необходимые условия для функционирования КСУП, персонал не готов воспринять новые правила работы. Стремление компаний создать КСУП определяется следующими условиями:  Рост компании;  Освоение новых рынков сбыта;  Создание новых подразделений;  Переход на холдинговые отношения, слияния, поглощения, разделение компаний;  Рост холдинговых подразделений до «дивизиональных», совершенствование. Для производства требуемых организационных изменений реализуется проект создания КСУП. Преимущества проектного подхода к работе по созданию КСУП: 1. Формирование команды проекта из сотрудников предприятия и внешних консультантов (по необходимости). Возможность формирования команды очень важна, так как позволяет формально выделить время и трудозатраты сотрудников компании на реализацию изменений. Таким образом персоналу не приходится отрываться от своих обычных обязанностей сверх выделенного времени и работать сверхурочно. Каждый член команды должен знать свои обязанности, ответственность, права, а также задачи проекта и сроки их выполнения. Руководители сотрудников имеют возможность выделить ресурсы для данного проекта и оценить качество их работы. Все члены команды должны быть мотивированы для работы в проекте, только тогда они будут выполнять свои работы максимально качественно. 2. Планирование конечных целей проекта и оценка достижения целей. Для проекта могут быть сформулированы цели, достижение которых для компании означает ее успех. Цели должны быть достигнуты в ограниченные сроки и с привлечением ограниченных ресурсов. 3. Управление сроками, ресурсами, стоимостью содержанием проекта. Методы календарно-сетевого планирования, контроля освоенных объемов, отслеживания загрузки ресурсов, применяемые в методологии управления проектами, помогают оптимизировать выделяемые ресурсы и время на проект. Кроме того, в проекте реализации организационных изменений происходят постоянные изменения. Как свидетельствует практика, ни один проект не соответствует в точности разработанной в процессе планирования модели. Методы управления проектами дают понимание, что если на все изменения реагировать хаотично, например, сразу отправлять в производство, или, наоборот, исключить любые изменения, может пострадать качество результатов проекта, либо не 130 будут достигнуты ожидания заинтересованных лиц. Наконец, могут быть превышены сроки и бюджет. Поэтому в начале проекта фиксируются процедуры управления изменениями. 4. Назначение менеджера проекта. Менеджер проекта несет ответственность за управление проектом. Деятельность менеджера проекта направлена на достижение результатов проекта. Менеджер является основной «движущей силой» для создания КСУП. 5. Управление рисками проекта. Современные методики управления много внимания уделяют управлению рисками. Следует отметить, что эта область наименее развита в российских компаниях, что связано с одной стороны с незнанием методов управления рисками, а с другой - традицией российского бизнеса рисковать, полагаясь в своих решениях на собственную интуицию. Любой проект уникален по определению, а проект создания КСУП уникален вдвойне, поскольку используемые технологии и методики управления проектами меняются очень быстро. В большинстве своем российские компании не имеют опыта производства организационных изменений, и проект является инновационным. Поэтому выполнение простых процедур управления рисками позволяет уменьшить затраты проекта. 6. Управление качеством проекта. Одной из важнейших составляющих успеха создания КСУП является качество стандарта и качество управления проектом по созданию КСУП. 7. Управление коммуникациями проекта. Коммуникации всех участников проекта – менеджера проекта, членов команды, руководства предприятия, пользователей КСУП, функциональных руководителей компании должны планироваться и контролироваться в ходе создания КСУП. Управление коммуникациями помогает избежать многих проблем непонимания, отсутствия информации, несвоевременной отчетности о проблемах и т.п. Например, требования руководства компании, предъявляемые к КСУП, могут быть зафиксированы командой проекта, выполнены и переданы в эксплуатацию. Однако, если на этапе реализации проекта не происходило постоянных консультаций с руководством компании, первоначальное видение проекта может быть искажено и финальный результат не соответствовать ожиданиям и потребностям. В большинстве случаев менеджер проекта отвечает за коммуникации команды проекта, опираясь на организационные документы, регламентирующие управление проектом (Устав проекта, План управления проектом и другие). Таким образом, применение методов и средств управления проектами является наиболее оптимальным путем создания КСУП. 14.2. Этапы создания КСУП Рекомендации по созданию КСУП включают в себя 11 этапов, которые можно отразить в схеме: 131 Рис. 47. Этапы создания КСУП 14.2.1. Инициация проекта создания КСУП Первый этап проекта создания Корпоративного стандарта управления проектами – это создание проектных документов и согласование их со всеми заинтересованными сторонами: 132 1. Подготовка организационных документов Подготовка организационных документов завершена Подготовка форм отчетности и рабочих документов Старт проекта Подготовка Плана управления проектом Планирование рисков, коммуникаций, качества проекта Создание Устава проекта РЕЗУЛЬТАТЫ 1. Устав проекта 2. План управления проектом (Риски, качество, коммуникации, календарно-сетевой график, рамки, критерии успешности) 3. Список открытых вопросов по проекту 4. Контрольные списки по качеству результатов проекта 5. Формы регулярного Отчета о состоянии проекта, Итогового отчета Рисунок. 48. Этап подготовки организационных документов Менеджер проекта на данном этапе курирует формирование команды проекта и создание Устава проекта – документа, который формально санкционирует существование проекта и предоставляет менеджеру проекта полномочия использовать ресурсы компании в задачах проекта. Устав – основной рабочий документ проекта, отвечающий на вопросы: а) каково содержание проекта и б) как управлять конкретным проектом. Должна быть подробно описана организационная структура и команда проекта, зоны ответственности членов команды проекта. Основным элементом Устава является закрепление ответственности за участниками проекта и формулирование целей проекта. Цели проекта создания КСУП зачастую формулируются организациями в расплывчатых, неконкретных терминах и не учитывают специфику организации. Для определения целей необходимо на ранних этапах проекта выделить три основных элемента оптимизации в компании, а именно:  Стратегический ресурс. Стратегический ресурс компании - это ресурсы (подразделения, сотрудники), определяющие способность компании выполнять несколько проектов одновременно.  Стратегический актив. Стратегический актив – это все необходимые для выполнения производственной деятельности компании компоненты (финансирование основные средства, интеллектуальная собственность и т.д.).  Стратегические цели компании. Определив данные элементы для конкретной организации, можно выделить конкретные цели создания самого КСУП, соответствующие требованиям SMART 133 (Specific - Специализированные, Mesurable - Измеримые, Actively Influencible Актуальные, Realistic - Реалистичные, Time Limited – Ограниченные по времени). Например, определение стратегического актива, как знаний и квалификации сотрудников, а стратегического ресурса – подразделения консультационных услуг, становится очевидным, что необходимо повышать квалификацию персонала или набирать более квалифицированных людей и оптимизировать деятельность отдела консультационных услуг. Менеджер проекта формирует План управления проектом – утвержденный формальный документ, в котором указано, как проект будет исполняться и как будет происходить мониторинг и управление проектом. В процессе планирования проекта проводятся тендеры на выбор субподрядчиков предприятия на реализацию проекта (если необходимо). Если компания для реализации проекта или этапов проекта принимает решение привлечь внешних консультантов (например, в случае проведения специализированных курсов обучения, покупки, установки, настройки программного обеспечения для управления проектами), проводится исследование соответствующих рыночных предложений и тендер для выбора субподрядчиков. Менеджер проекта контролирует заключение договоров с выбранными субподрядчиками и корректирует бюджет проекта, по необходимости. Менеджер проекта должен сформировать следующие документы: Список открытых вопросов по проекту – это документ, фиксирующий статус вопросов, возникающих у команды проекта к другим участникам проекта и участников проекта к команде проекта. Одним из критериев успешности проекта может являться закрытие все вопросов данного списка. Контрольные списки по качеству результатов проекта – это документы, по которым оценивается качество созданных в проекте результатов. Полный список контрольных вопросов включает все возможные факторы – технический, коммерческий, законодательный, фактор окружающей среды, социальный и т.д. Форма Отчета о состоянии проекта должна быть согласована с заказчиком проекта (например, с руководством предприятия). Отчет о состоянии проекта включает описание выполненных за отчетный период работ, план на следующий период, проблемы и вопросы по проекту. На основе Отчета о состоянии принимаются основные решения по проекту, анализируется ход реализации проекта, и инициируются изменения в проекте. Форма Итогового отчета о проекте необходима для аккумулирования накопленного полезного опыта и описания созданных результатов проекта. Итоговый отчет согласуется заказчиком проекта. Все перечисленные документы должны быть согласованы согласно Плану коммуникаций проекта. Документы используются для управления проектом создания Корпоративного стандарта управления проектами. 14.2.2. Обследование бизнес-процессов организации Вторым этапом проекта является обследование бизнес-процессов управления проектами. Диагностика проводится в ходе интервью с основными сотрудниками, работающими в бизнес-процессе. Для каждой из групп сотрудников (руководители высшего звена, менеджеры проектов, руководители подразделений и другие) формируется вопросы к интервью. Основным результатом этапа является описание бизнес процессов «как есть» и выявление проблем, возможностей улучшения в соответствии со стандартами PMI. 134 2. Обследование бизнес-процессов управления проектами Обследование завершено Описание бизнеспроцессов «Как есть» Подготовка Отчета об интервью, рекомендаций Старт обследования Проведение интервью, выявление проблем и возможностей улучшения процессов Определение групп сотрудников для проведения интервью РЕЗУЛЬТАТЫ 1. Мнения всех ключевых сотрудников компании собраны и учтены 3. Выявлены проблемы и возможности улучшения бизнес-процессов 4. Отчет об интервью, рекомендации по изменению бизнес-процессов на основе методологии PMI 5. Бизнес-процессы «Как есть» Рисунок. 49. Этап обследования бизнес-процессов управления проектами. Для интервью определяются группы ключевых сотрудников, мнение и знания которых необходимо учесть при диагностике бизнес-процессов. Обычно выделяются следующие группы:  Руководители высшего звена;  Руководители портфелей проектов;  Руководители подразделений;  Менеджеры проектов;  Члены команд проектов. После проведения интервью с каждой группой достигается понимание всех проблем и точек зрения на существующие и будущие бизнес-процессы управления проектами. На данном этапе менеджер проекта проводит работу по организации интервью, пересылает специализированные вопросники каждому участнику интервью для ознакомления, согласует время, место и состав участников интервью и отвечает на поступающие вопросы участников. При согласовании состава участников интервью необходимо учитывать психологический фактор. Не рекомендуется проводить беседу одновременно с руководителями и подчиненными, так как велика вероятность того, что подчиненные не смогут открыто высказать свое мнение о проблемах управления проектами. Количество интервью с каждой группой сотрудников определяется индивидуально для каждой компании. 135 Для каждой группы участников интервью подготавливается вопросник: Группа Темы вопросника участников Руководители высшего звена Руководители портфелей проектов Руководители подразделений Менеджеры проектов  Стратегия развития компании;  Организационная структура управления компании;  Основные цели создания Корпоративного стандарта управления проектами;  Основные стратегические задачи, которые призван решить Корпоративный стандарт управления проектами;  Результаты, которые ожидают получить руководители высшего звена от Корпоративного стандарта управления проектами;  Управление стоимостью проектов;  Схемы мотивации членов команд проектов;  Показатели отклонений параметров проектов (возможное отклонение от плана сроков, бюджета проекта);  Классификации проектов.  Обязанности, права, ответственность руководителей портфелей проектов и их подчиненных;  Стратегические цели, поставленные перед руководителем портфеля проектов;  Проблемы, возникающие в ходе управления портфелем проектов;  Результаты, которые ожидают получить руководители портфелей проектов от Корпоративного стандарта управления проектами;  Процессы управления проектами портфеля;  Принятые методы и инструменты управления проектами портфеля;  Области знаний управления проектами портфеля (управление стоимостью, рисками, качеством и т.д.)  Обязанности, права, ответственность руководителей подразделений и их подчиненных;  Процесс и проблемы взаимодействия с командами проектов;  Распределение ресурсов в проектах, выделение рабочего времени сотрудников для работы в проекте;  Проблемы, возникающие в ходе управления портфелем проектов;  Результаты, которые ожидают получить руководители подразделений от Корпоративного стандарта управления проектами.  Обязанности, права, ответственность менеджеров проектов и членов команд проектов;  Проблемы, возникающие в ходе управления проектами;  Результаты, которые ожидают получить менеджеры проектов от Корпоративного стандарта управления проектами; 136  Процессы управления проектами;  Принятые методы и инструменты управления проектами;  Области знаний управления проектами (управление стоимостью, рисками, качеством и т.д.). Члены команд  Обязанности, права, ответственность членов команд проектов проектов;  Процессы управления проектами;  Области знаний управления проектами (управление стоимостью, рисками, качеством и т.д.);  Принятые методы и инструменты управления проектами. Таблица. 66. Темы вопросников для сотрудников компании Подготовка Отчета об интервью, рекомендаций. Описание бизнес-процессов «как есть» Отчет должен включать:  Описание бизнес-процессов «как есть», то есть фиксирование нынешнего состояния управления проектами в компании.  Описание основных проблем в бизнес-процессах управления проектами.  Рекомендации по улучшению бизнес-процессов управления проектами. Полученные отчеты и рекомендации согласуются с руководством компании, и корректируются по необходимости. Руководство принимает решение о дальнейших шагах по созданию КСУП согласно рекомендациям. На данном этапе менеджер проекта должен подготовить и согласовать уточненный по срокам, содержанию, стоимости План управления проектом на основе принятых по рекомендациям решений. 137 14.2.3. Определение основных принципов Рис. 50. Этап определения основных принципов КСУП До начала создания регламентов рекомендуется сформировать основные принципы управления проектами компании, с которыми будут согласны все руководители компании. 14.2.4. Создание регламентирующей документации После проведения обследования и формирования основных принципов управления проектами описываются бизнес процессы «как должно быть». Для сотрудников разрабатываются Регламенты, Положения и Должностные инструкции, описывающие систему управления проектами, обязанности, ответственность и права каждого участника процесса. 138 4. Разработка регламентирующей документации для управления проектами Разработка регламентирующей документации завершена Корректировка документов в соответствии с замечаниями заказчика Согласование документов заказчиком Старт формирования документации Создание регламентирующей документации Описание бизнеспроцессов «Как должно быть» РЕЗУЛЬТАТЫ 1. Регламент по управлению проектами 2. Регламент по управлению рисками 3. Регламент по управлению стоимостью 4. Регламент по управлению качеством 5. Регламент по управлению коммуникациями 5. Регламент по управлению человеческими ресурсами 6. Положения об отделах и должностные инструкции Рисунок. 51. Этап разработки регламентирующей документации для управления проектами. Выявленные проблемы в ходе диагностики и подготовленный глоссарий служат основой для создания регламентов и оптимизации основных элементов КСУП:  Стратегический ресурс, пул ресурсов. Пул ресурсов должен включать информацию о загрузке ресурса, полное описание ресурса, навыки, специальность сотрудников, принадлежность ресурса к функциональному подразделению, стратегическую цель предприятия, для которой используется данные ресурс, основной актив предприятия, связанный с ресурсами, проекты, в которых участвует ресурс.  Стратегические цели. Должен быть сформирован портфель стратегических целей компании, а именно – описание каждой цели, подразделения, спонсирующие достижение целей, даты начала и окончания работ, направленных на достижение цели, перечень проектов по достижению данной цели, перечень активов, используемых для достижения цели.  Стратегические активы. Должна быть произведена инвентаризация всех активов предприятия для правильного распределения планируемых активов на новый финансовый год и их развития. Формируется портфель активов компании. Портфель активов должен содержать полное описание активов, состояние 139 актива, подразделение компании, отвечающее за данный актив, планируемые ассигнования для развития актива, стоимость актива, стратегическую цель предприятия, связанную с активом, проекты, в которых задействован актив.  Оптимизированные бизнес-процессы управления проектами. Команда проекта создания КСУП разрабатывает новые процессы управления проектами. Преимущества нового процесса с точки зрения удовлетворения потребностей клиентов или сокращения простоев имеют смысл только тогда, когда затраты не перевешивают выгод. Поэтому баланс между технической и экономической целесообразностью имеет решающее значение в реинжиниринге процессов, реализуемом в следующей последовательности: 1. Первым этапом является разработка общей концепции нового процесса. Общая концепция – это примерное видение того, как будет реализован тот или иной процесс управления проектами. Полезным предварительным шагом для формулирования концепции нового процесса является сравнение существующего процесса с аналогичными процессами. Команда проекта должна рассмотреть стратегические цели компании, стратегический ресурс и стратегические активы, и их соотношение с процессом управления проектами. Если активов или ресурсов для нормальной работы не хватает, для руководства компании должно быть сделано обоснование привлечения новых специалистов и средств. Последним шагом в выработке концепции процесса является письменная формулировка концепции процесса, включающая разработку карты и схемы алгоритма процесса. 2. Вторым этапом является разработка карты процесса. Одно из самых важных средств, используемых при реинжиниринге процесса — это карта процесса. Карта позволяет команде увидеть все части процесса и насколько эти части соответствуют друг другу, а также слабые стороны и излишние сложности в процессе наряду с сильными сторонами, которые нужно сохранить в новом процессе. 3. Третий этап - разработка схемы алгоритма процесса. Схемы алгоритмов — это зрительная интерпретация шагов процесса, и их обычно используют на том уровне детализации, где фигурируют отдельные задачи, действия и решения. На уровне же алгоритма требуется больше деталей для того, чтобы показать шаги, людей и решения, относящиеся к этой задаче. Зачастую сотрудники компании на интервью указывают слишком общий процесс, без должной детализации. Другой общей проблемой является то, что часто люди, описывая шаги процесса, представляют его в идеализированном виде. Они описывают, что должно происходить, если все идет по плану, а не то, что происходит, когда люди и обстоятельства, словно сговорившись, ломают эти планы. В ходе реинжиниринга команды должны поставить под вопрос ограничения, которые в настоящий момент существуют в бизнес-процессах. Иногда эти ограничения настолько глубоко укоренились в человеческом сознании, что стали почти невидимыми. Таким образом команда проекта определяет, что именно нужно улучшить в бизнес-процессах управления проектами, например: 1. Как можно меньше людей должно быть вовлечено в процесс. Распространенной является ситуация, когда документы, подготавливаемые командами проектов предприятия проходят длительные согласования сотрудников, которые не понимают важность документов и затягивают процесс. Это могут быть юридические подразделения, отдел кадров и т.п. Многие проекты не могут начаться из-за формального согласования Бюджета проекта несколькими сторонами. Менеджер проекта тратит большое количество усилий на получение согласований вместо реализации работ по проекту. 140 2. Клиент процесса должен выполнять этот процесс. Этот принцип похож на первый тем, что он способствует улучшению в работе процесса главным образом за счет уменьшения числа вовлеченных в него людей. Примером может являться отчетность проектов. Менеджер проекта может тратить много времени на подготовку регулярных формальных отчетов руководству, которые в большинстве случаев не отражают реального положения дел. Следовательно, клиенту процесса (руководству) необходимо предоставить возможность самостоятельно формировать и просматривать отчетность. Для этого используются ИСУП, в которых руководители могут просматривать любую информацию по проектам, отчетность формируется автоматически. А менеджер проекта в свою очередь должен иметь право в любое время сигнализировать руководству о возникающих проблемах (например, на совещаниях). 3. Поставщики должны восприниматься как часть организации. Практическое применение этого принципа означает, что иногда от внешних поставщиков требуется выполнять шаги процесса, которые раньше выполнялись внутри организации. Например, очень часто возникает ситуация, когда для отдельных частей проекта техническую документацию подготавливает поставщик. Привлеченные в проект внешние сотрудники (например, консультанты), также играют большую роль в успехе проекта. По российской традиции отношения с внешними поставщиками часто бывают враждебными. Доверие возможно только, если с поставщиком установлены понастоящему партнерские отношения. Такое партнерство должно быть основано на взаимной выгоде: и поставщик, и клиент только выигрывают от сотрудничества. 4. Множество версий сложных процессов. Множество версий позволяют экономить время сотрудников, и, следовательно, средства компании. Например, процесс контроля проектов отделом качества могут реализовываться только в масштабных долгосрочных проектах, а небольшие проекты проверяются по критериям качества по необходимости. 5. Должно быть уменьшено количество входов в процессы. Огромное количество времени во многих организациях тратится на сопоставление и сведение воедино разных форм представления одного и того же. Процессы, которые содержат в себе подпроцессы и задачи, включающие подобные сверки, скорее всего, окажутся медленными и запутанными, потребуют участия большого количества людей. Уменьшение количества входов в процесс — один из способов уменьшения количества проводимых сверок, ускорения процесса и уменьшения численности задействованного персонала. 6. Сохранение децентрализованных подразделений, централизованный обмен информацией. Примером может служить компания, выполняющая множество проектов в разных подразделениях. Для получения общей картины по всем подразделениями нужно долго собирать информацию с каждого. Упрощение этой процедуры может быть произведено путем создания офиса управления проектами и использованием ИСУП. Таким образом, новые процессы управления проектами, портфели стратегических целей, активов, ресурсов помогают сформировать регламенты, положения и должностные инструкции для управления всеми аспектами работы над проектами. Отдельно в документах должно быть описано:  Типовые роли в процессе управления проектами, матрица ответственности ролей;  Классификация проектов, задач, ресурсов организации;  Инструменты и методы управления проектами. 141 Для ролей в процессе управления проектами не разрабатываются должностные инструкции, так как каждый сотрудник может выполнять несколько ролей. Должностные инструкции разрабатываются (или изменяются существующие) для новых должностных позиций в компании (например, сотрудники офиса управления проектами) и должностей сотрудников, занятых в процессе управления проектами. В инструкции могут быть добавлены новые обязанности сотрудников, изменены правила взаимодействия с другими подразделениями компании и так далее. Роли процессов описаны в разделе 3 «Заинтересованные лица (участники) проекта». Все документы КСУП должны проходить проверку качества. Команда проекта создания КСУП согласует документы с руководством компании и другими участниками проекта и вносит изменения и корректировки по необходимости. На данном этапе проекта создания КСУП важно участь все комментарии согласующих сторон, как по содержанию, так и по форме документов. Согласование является первой проверкой документов на удобство использования, понимание сотрудниками и соответствие целям проекта. 14.2.5. Создание шаблонов документов Шаблоны документов позволяют облегчить сотрудникам компании работу в новых бизнес-процессах управления проектами. Приведенный ниже перечень документов отражает основные документы по стандартам PMI и может быть дополнен любыми документами из стандартов PMI или специализированными для деятельности организации документами. Для каждого шаблоны документа должен быть создан пример заполнения. Примеры могут быть сформированы для каждого подразделения компании или типа проекта. Шаблоны документов и примеры заполнения обсуждаются с сотрудниками компании. Формируемые шаблоны должны быть максимально удобными и краткими. Если некоторые положения PMI по составу и содержанию документов затрудняют работу персонала и являются излишними, ими можно пожертвовать с целью привлечь каждого сотрудника к обязательному заполнению. Очень важно, чтобы информация в документах не дублировалась, что вызывает негативный отклик персонала компаний. 142 5 . Разработка шаблонов документов проектов Старт разработки шаблонов документов Анализ требований и существующих шаблонов компании Разработка шаблонов документов завершена Создание шаблонов документов Согласование документов Корректировка документов в соответствии с замечаниями РЕЗУЛЬТАТЫ 1. Заявка на проект 2. Приказ об открытии проекта 3. Первоначальное описание содержания проекта 4. Устав проекта 5. Карточка проекта 6. Окончательное описание содержания проекта 7. План управления проектом 8. Бюджет проекта 9. Коммерческое предложение 10. Отчет о состоянии проекта 11. Запрос на изменение параметров проекта 12. Регистрационный журнал изменений 13. Протокол совещания по проекту 14. Итоговый отчет по проекту 15. Служебная записка на закрытие проекта 16. Приказ о закрытии проекта 17. Служебная записка о распределении мотивационного фонда проекта 18. Акт приемки работ (с учетом требований процесса управления проектами) 19. Опросный лист 20. Репозиторий 21. Контрольный список по качеству 22. Контрольный список по рискам Рисунок 52. Этап разработки шаблонов документов проекта Документ Описание 143 1. Заявка на проект 2. Приказ об открытии проекта 3. Первоначальное описание содержания проекта 4. Устав проекта 5. Карточка проекта 6. Окончательное описание содержания проекта 7. План управления проектом 8. Бюджет проекта 9. Коммерческое предложение 10. Отчет о состоянии проекта Инициатива на реализацию проекта. Служит для утверждения начала проекта. Описывает цели, задачи, основные этапы и результаты, рамки и границы проекта. критерии завершения проекта. Периодичность отчетности участников проекта, управление проектной документацией, ответственность команды и т.д. Краткая информация о проекте. Подробно описывает продукт проекта, процесс утверждения промежуточных и конечных результатов проекта. Включает планы: - Расписание проекта План управления ресурсами, рисками, коммуникациями и другие планы проекта. Перечень статей затрат по работам проекта, распределенный по времени. Предложение для утверждения проекта внешним заказчиком. Отчет по текущему состоянию проекта для заказчика. 11. Запрос на изменение Запрос на изменение предметной области, состава работ параметров проекта проекта и других существенных параметров. 12. Регистрационный журнал изменений 13. Протокол совещания по проекту 14. Итоговый отчет по проекту 15. Служебная записка на закрытие 16. Приказ о закрытии проекта 17. Служебная записка о распределении материального фонда 18. Акт приемки работ 19. Опросный лист 20. Репозиторий 21. Контрольный список по качеству 22. Контрольный список по рискам Перечень всех запросов на изменения и статуса по ним. Регистрирует вопросы, поднятые в ходе совещания по проекту, и принятые решения по ним. Анализ плановых и фактических показателей, реакции заказчика. Сбор накопленного опыта. Причины закрытия, основные итоги, результаты приемки проекта, реакция заказчика проекта. Служит для утверждения окончания проекта. Служит для утверждения премий по проекту. Служит для утверждения закрытия работ по проекту. Реакция заказчика по итогам реализации проекта. Перечень всех документов проекта. Контрольный список по критериям качества процесса управления проектами. Перечень типовых критериев качества для анализа по итогам завершения этапов проекта. Контрольный список по рискам проекта. Перечень наиболее часто встречающихся рисков, на основе которого команда проекта создает План управления 144 рисками. Таблица. 67. Шаблоны документов КСУП 14.2.6. Создание шаблонов проектов Для того чтобы минимизировать время на планирование проекта для менеджеров проектов формируются шаблоны проектов в ИСУП. Во многих случая блоки работ проектов повторяются из проекта в проект. Это позволяет накапливать опыт для создания шаблонов проектов. Шаблоны содержат календарно-сетевой график, отражающий типовые работы вида деятельности компании или подразделения. Шаблоны должны быть согласованы руководством соответствующих подразделений. После согласования вносятся необходимые корректировки командой проекта. Рисунок. 53. Этап разработки шаблонов проектов 145 14.2.7. Разработка требований к ИСУП Рисунок. 55. Этап разработки требований к ИСУП Очень важно не формировать к ИСУП завышенных требований. На российском рынке существуют 3 основные ИСУП – Microsoft Project, Primavera, Спайдер Проджект. ИСУП предназначена для автоматизации рутинных операций и организации совместной работы. 146 14.2.8. Настройка ИСУП Рис. 56. Этап настройки ИСУП Настройка ИСУП должна автоматизировать утвержденные процессы управления. Для каждой группы пользователей ИСУП должны быть сформированы небольшие инструкции. 14.2.9. Создание ОУП Рис. 57. Этап создания ОУП Для успешного функционирования Корпоративного стандарта управления проектами и ИСУП целесообразно создавать офис управления проектами (ОУП) – структурное 147 подразделение компании, осуществляющее поддержку реализации процессов управления проектами. Наличие в организации множества проектов в условиях постоянной нехватки ресурсов и кадрового голода также обуславливает необходимость создания централизованного офиса управления проектами. Единая точка управления ограниченными ресурсами, используемых в разных проектах, позволяет снять с менеджеров проектов и руководителей подразделений достаточно сложную задачу диспетчеризации своих людских ресурсов между проектами. Современным способом решения задачи централизованного управления ресурсами является использование информационных систем управления проектами, позволяющих одновременно планировать множество проектов и распределять работу персонала по задачам этих проектов, а также создание ОУП, позволяющего решать конфликты между руководителями подразделений и менеджерами проектов, используя административный ресурс. Для офиса управления проектами разрабатывается Положение о подразделении, Регламент взаимодействия с другими подразделениями, шаблоны документов, инструкции. 14.2.10. Обучение сотрудников Рис. 58. Этап обучения сотрудников Обучение помогает нейтрализовать угрозу отторжения новых бизнес процессов сотрудниками. В ходе курсов проводится сбор замечаний и предложений от сотрудников по изменению регламентирующих документов и шаблонов. Обучение сотрудников преследует несколько целей:  Получение сотрудниками необходимых навыков для работы с КСУП и ИСУП. Для быстрого привыкания к новым бизнес-процессам требуется первоначальное обучение и регулярное повышение квалификации по элементам КСУП, а именно теории управления проектами, использованию методов и инструментов 148 управления проектами, знания бизнес-процессов компании и навыки работы в ИСУП.  Тестирование КСУП на сотрудниках компании, проверка реакции сотрудников на созданные процессы. Обучение должно в полной мере освещать все процессы управления проектами компании. Учась работать в процессе, сотрудники сразу могут обратить внимание команды проекта на несоответствия и ошибки, допущенные при разработке процессов. Обучение должно носить характер свободного обсуждения с обучающимися новых правил работы. Все пожелания, возражения и предложения должны учитываться командой проекта, анализироваться, и КСУП корректируется в соответствии с приятыми в работу изменениями.  Пропаганда КСУП среди сотрудников компании. Обучение является своего рода рекламой КСУП для участников семинаров и лекций. Все без исключения вопросы сотрудников, должны найти ответы на обучении. Лектор, проводящий семинары должен максимально корректно и доброжелательно относится к слушателям и помнить о том, что основная его задача – убедить сотрудников компании использовать созданный КСУП. В то же время лектор не должен идти на поводу у провокаций и реагировать на негативные высказывания сотрудников. 14.2.11. Поддержка процессов и постоянное улучшение Рис 59. Этап поддержки процессов и постоянного улучшения КСУП не может существовать как неизменный объект. Все правила, принципы управления изменяются, так как компания накапливает новый полезный опыт, а также под влиянием факторов внешней среды. За постоянное улучшение и обновление КСУП несет ответсвенность ОУП. 15. Мотивация и кадровый аспект создания КСУП Практически неизбежно, что проект создания КСУП затрагивает вопросы, касающиеся людей. Изменение обязанностей, прав, ответственности, цели деятельности влияет 149 прежде всего корпоративную культуру, взаимоотношения сотрудников компании, и может повлечь:  увольнения сотрудников;  изменение корпоративной культуры;  изменение организационной структуры;  изменение должностей, обязанностей, ответственности, прав сотрудников. 15.1. Увольнения сотрудников Увольнения, появление «лишних» людей в результате оптимизации процессов – болезненная тема для компании. Основная задача руководства компании при внедрении КСУП - изучить позицию, которую они займут еще до начала проекта. Многие организации, которые этого не делают, попадают в двусмысленные ситуации. Персонал начинает задавать вопросы относительно возможных последствий создания КСУП для них и для их работы, в частности, почему они должны участвовать в том, что, возможно, повлечет увольнения. Руководство компании не может отвечать на подобные эмоциональные вопросы экспромтом, и почти также неэтично просить у работников время подумать. Если эти вопросы не продуманы заранее и не определена четкая, объяснимая и обоснованная позиция, то желание скрыть правду всегда приводит к серьезным неприятностям в конце проекта. Таким образом, заблаговременное обоснование позиции руководства в кадровых вопросах поможет предотвратить многие проблемы. Рекомендации по увольнению персонала можно привести следующие: 1. Гарантирование отсутствия увольнений и декларирование того, что сотрудники должны быть готовы сменить свою должность. Довод может быть приведен следующий: процесс создания КСУП должен сделать организацию более конкурентоспособной и, следовательно, обеспечить улучшение ее рыночных позиций, а высвободившийся персонал будет использован на реализацию этой стратегии. Такие компании сокращают свою численность за счет естественной убыли персонала, т. е. ухода людей на пенсию и естественной текучести кадров, и готовы к тому, что такой подход означает, что ожидаемые выгоды будут получены нескоро. 2. Организация признает, что у них могут появиться лишние люди, но соглашается, чтобы эта проблема была решена на добровольной основе. Преимущество этого подхода в том, что он уменьшает страх и опасения, которые часто окружают любой процесс изменений. Недостаток его, однако, состоит в том, что организация не может контролировать, какие именно сотрудники уволятся; часто это наиболее талантливые и уверенные в себе сотрудники, готовые рискнуть, тогда как менее ценные на рынке труда люди остаются. 3. Еще один вариант — признание того, что появление лишних людей вполне вероятно, и эту проблему решать прямым путем. Многие организации, принявшие данный подход, уверены, что компенсации, предлагаемые высвободившимся сотрудникам, достаточно щедры, чтобы избежать любых неприятностей, связанных с данным подходом. Однако компенсации в российских условиях не являются развитым инструментом, поэтому чаще всего увольнения производятся волевым решением руководства. 15.2. Изменение корпоративной культуры Изменение корпоративной культуры означает изменение мышления людей. В первую очередь необходимо, чтобы менеджеры проектов и сотрудники научились мыслить в терминах объемов работ. Обычно специалисты планируют свою деятельность по 150 срокам, с учетом текущей загрузки, не стараясь оценить трудозатраты. Полученная таким образом информация о сроках, использованная при планировании, требует при любом изменении плана переоценки с привлечением специалиста. Планирование же в терминах объемов позволяет получить оценку, независимую от календаря и занятости специалиста, на основе которой план может корректироваться практически без привлечения специалиста. Следующее изменение корпоративной культуры связано с формализацией процессов управления проектами. Необходимо предусмотреть опасность излишнего бюрократизма, которая порождается вводом регламентов и положений. Сотрудники стремятся защититься от излишних обязанностей с помощью документов. Поэтому документы должны в некоторых частях носить рекомендательный характер. КСУП подразумевает стремление компании к открытости, командной работе, обмену опытом. Одно из основных направлений изменений корпоративной культуры это управление знаниями по проектам. Управление знаниями это достаточно новая область управления, которая ориентируется на ценность одного из основных активов любой компании- знания. Знания могут храниться как на материальных носителях (например, базах данных), так и непосредственно у сотрудников. Трудности в управлении знаниями, связанные с персоналом, это нежелание делится знаниями, сложности в использовании ИСУП для накопления знаний о проектах, плохая структурированность знаний, отсутствие правильной системы мотивации для извлечения знаний, непонимание сотрудниками концепции управления знаниями. Все перечисленные проблемы могут быть решены Офисом управления проектами, который берет на себя ответственность за управление знаниями компании. 15.3. Изменение организационной структуры По итогам реинжиниринга бизнес-процессов может быть измена организационная структура предприятия, состав подразделений компании и их функции. Изменение должностей, обязанностей, ответственности, прав сотрудников. Общие способы преодоления организационных изменений приведены в таблице: Предпосылки Меры Преимущества Недостатки применения Обучение и предоставление информации Недостаток информации, недостоверная информация или ее неправильная интерпретация При убежденности сотрудников в необходимости мероприятия они активно участвуют в преобразованиях Требует очень много времени, если надо охватить большое число сотрудников Привлечение к участию в проекте Дефицит информации у инициаторов проекта относительно программы изменений и предполагаемого сопротивления им Участники заинтересованно поддерживают изменения и активно предоставляют релевантную информацию для планирования Требует очень много времени, если участники имеют неправильное представление о целях изменений Стимулирование Сопротивление в связи Предоставление помощи Требует много и поддержка со сложностью при адаптации и учет времени, а также индивидуальной индивидуальных крупных расходов, 151 адаптации к отдельным изменениям пожеланий облегчают достижение целей изменения что может привести к неудаче проекта Переговоры и соглашения Сопротивление групп в руководстве предприятия, опасающихся потерять свои привилегии в результате изменений Предоставление стимулов в обмен на поддержку может оказаться относительно простым способом преодоления сопротивления Часто требует больших расходов и может вызвать претензии у других групп Кадровые перестановки и назначения Несостоятельность других "тактик" влияния или недопустимо высокие затраты по ним Сопротивление относительно быстро ликвидируется, не требуя высоких затрат Угроза будущим проектам из-за недоверия затрагиваемых лиц Скрытые и явные меры принуждения Острый дефицит времени или отсутствие соответствующей властной базы у инициаторов изменений Угроза санкций заглушает сопротивление, делает возможной быструю реализацию проекта Связано с риском, порождает стойкую озлобленность по отношению к инициаторам, пассивное сопротивление возможной переориентации проекта Таблица. 68. Общие способы преодоления организационных изменений Основной механизм внедрения организационных изменений – достижение конкретных соглашений с менеджерами по их участкам работы с последующим контролем исполнения. Основную консультационную работу составляет агитация и пропаганда. Для того, чтобы люди двигались вперед, им необходимо доказать невозможность остаться на месте, и блокировать движение в неверных направлениях. Первая часть задачи решается разъяснением всех причин создания КСУП. Причины, выявленные на этапе инициации проекта создания КСУП должны быть озвучены сотрудникам (замедление роста фирмы по сравнению с рынком, недостаточная прибыль, снижение управляемости предприятия, перегрузка руководства, замедление принятия важных решений). Кроме того, как уже говорилось выше, внедрение КСУП должно сопровождаться полным информированием участников проектов обо всех этапах проекта создания КСУП. Это помогает сотрудникам компании включится в работу и высказать свои замечания, по которым команды проекта создания КСУП на ранних этапах проекта может скорректировать результаты. Вторая часть задачи реализуется посредством знакомства с чужим опытом. Неудачные примеры внедрений КСУП позволяют избежать ошибочных решений. Полезные предложения сотрудников должны пропагандироваться командой проекта с указанием авторства. Чтобы получить результат в таком сложном деле, как создание КСУП, необходимо использовать все возможные приемы стимулирования. Причем, как правило, команда проекта создания КСУП на данном этапе не имеет возможности применить материальную мотивацию, а должен ограничиваться моральной. В отрицательной 152 части стимулирования применяются метод предъявления неприятных альтернатив решения проблемы (например, сотрудники, отказывающиеся вести портфель проектов в ИСУП должны предоставлять все формы отчетности в твердой копии, а не электронном виде). В положительной области стимулирования на раннем этапе внедрения КСУП можно озвучить принципы стимулирования, которые будут применяться в дальнейшем, и это даст положительный стимул. Еще одним методом стимулирования является измерение результатов труда. Простой подсчет прибыли по проектам компании позволит менеджерам проектов аргументировать перед руководством требования по увеличению штата сотрудников, финансирования проектов и собственных премий. Одной из важнейших составляющих КСУП, относящихся к области управления кадрами является система материальной мотивации сотрудников. Принципы построения данной системы могут быть различны в разных компаниях (например, анализ сбалансированных показателей /51/ и другие), однако очевидно, что мотивация должна быть привязана к результатам и качеству работы в проектах. Основные проблемы материального стимулирования это: 1. Фонд материального стимулирования в компании по проектам не выделяется. Сотрудники получаю фиксированную премию по итогам года, квартала или другого периода, равную фиксированному проценту от заработной платы. Такое стимулирование никак не связано в эффективностью работы сотрудника, и фактически просто увеличивает зарплату на определенную сумму. 2. Фонд материального стимулирования выделяется, но не привязан к результатам проекта и качеству работ. Данная мотивация чаще всего применяется, когда используется только один критерий оценки команды проекта – получение прибыли. Если средства от заказчика получены, некоторая часть распределяется между командой. Недостаток такого метода в том, что не учитываются достижения команды и провалы. Например, оплата работ может быть от клиента получена, но из-за некачественного управления, клиент отказывается от дальнейшего сотрудничества с компанией. 3. Мнение менеджера проекта и команды не учитывается при распределении мотивационного фонда. Нередки ситуации, когда мнение участников проекта о работе коллеги не учитывается при распределении премий, например, при стимулировании сотрудников сторонних подразделений, участвующих в проекте. Стимулирование данных сотрудников является ответственностью функционального руководителя, который не имеет достаточно информации для объективного премирования, и часто не заинтересован в премировании сотрудников своих подразделений по проектам, так как проекты «отвлекают» людей от их функциональных задач. 4. Получить премию практически невозможно. Такая проблема характерна для компаний, соблюдающих жесткую экономию расходов. Многочисленные условия, которые требуется достичь для получения премии, превращают весь процесс премирования в формальность, и снижают уровень энтузиазма сотрудников. Так как реализация проектов – это творческая деятельность, требующая неравномерного напряжения сил, обманутые ожидания могут отрицательно сказываться на командах проектов, резко снижая их производительность, что ведет к увольнениям. Таким образом, чрезмерная экономия приводит к еще большим потерям для компании. 5. Премия распределяется необъективно. Мотивационный фонд проекта, распределяемый отдельными сотрудниками (например, менеджером проекта совместно с финансовым директором) обычно разделяется необъективно. Отсутствие четких 153 критериев оценки и системы подсчета премий приводит к конфликтам и напряженности в коллективе. 6. Выплата премии привязана к оплате заказчиком проекта всех счетов по проекту или полному завершению проекта. Так как многие проекты длятся годами, привязывать премии команды к завершению проекта не представляется эффективным. Также оплата счетов, как один из рычагов давления на менеджера проекта, который должен добиться получения всех денег по проекту, неэффективно для исполнителей работ проекта, которые на данный процесс не влияют. Для облегчения внедрения системы мотивации можно применить тестовую эксплуатацию. Новая система вводится для испытания – например, персоналу в течение трех месяцев гарантируются выплаты по старой схеме с одновременным расчетом по новой. В процессе испытания люди «примеряют» новую схему, плавно приспосабливают поведение под целевое состояние. Тестовая эксплуатация позволяет безболезненно ввести новую систему через три месяца или (при явных просчетах) скорректировать ее до негативного воздействия на компанию. Наиболее вероятная опасность, которая ожидает фирмы, внедряющие КСУП – это снижение эффективности на первом этапе преобразований, когда старые технологии выходят из употребления, а новые применяются персоналом с ошибками и иногда саботажем. В начале преобразований нагрузка на менеджеров растет, а результат падает, и лишь с определенного этапа наблюдается устойчивый рост эффективности. Так как данная ситуация типична, начинать реформы лучше во время сезонного спада, когда у менеджеров есть резерв времени, а падение эффективности минимально в абсолютных цифрах. Еще одна опасность заключается в желании персонала привлечь излишних сотрудников для выполнения дополнительных функций. Например, необходимость выделить время для планирования проектов нейтрализована следующим доводом – подразделение инициирующее прием на работу новых сотрудников должно принимать их за счет своих затрат . Следующая проблема – во время внедрения КСУП и производства организационных изменений сотрудники, квалификация которых низка, могут требовать повышения статуса и заработных плат. Команде создания КСУП и руководству компании следует вести разъяснительную работу среди сотрудников, помогающую избежать подобных заявлений. Одним из наиболее эффективных способов борьбы с кадровыми проблемами при создании КСУП является обучение. 154