Сущность, основные понятия и принципы управления проектами

I СУЩНОСТЬ, ОСНОВНЫЕ ПОНЯТИЯ И ПРИНЦИПЫ УПРАВЛЕНИЯ ПРОЕКТАМИ 1. Концепция управления проектом. Управление проектами – это искусство руководства людскими и материальными ресурсами и их координация на протяжении всего жизненного цикла проекта с помощью современных методов для достижения результатов, которые бы удовлетворяли заказчика. Объектом проектного управления является проект. Управление проектом должно осуществляться с учётом ожиданий и интересов основных участников. Заинтересованные в проекте стороны (участники проекта) – это лица или организации, активно вовлечённые в проект, а также участники, интересы которых могут быть затронуты в результате выполнения проекта. 2. Определение понятия «Проект». Признаки проекта. Что же представляет собой проект? Понятие «проект» можно трактовать по-разному: • как дело, деятельность, мероприятие, предполагающее осуществление комплекса каких-либо действий, обеспечивающих достижение определенных целей. Близкими по смыслу в этом случае являются термины «хозяйственное мероприятие», «работа», «проект»; • как систему организационно-правовых и расчетно-финансовых документов, необходимых для осуществления каких-либо действий или описывающих такие действия; • как основной документ, устанавливающий необходимость осуществления реального инвестирования, в котором в определенном порядке излагаются основные характеристики проекта и финансовые показатели, связанные с его реализацией. На основании вышеприведённых трактовок понятия «проект» можно выделить общие черты, присущие любому проекту: – наличие перспективной цели; – ограничение во времени; – создание уникального продукта или услуги; – ограниченность требуемых ресурсов; – новый тип взаимодействия; – характеристики уникального продукта (услуги), которые детализируются (и лучше понимаются) по мере выполнения проекта. Следовательно, проект – это ограниченное по времени целенаправленное изменение отдельной системы с изначально чётко определенными целями, достижение которых определяет завершение проекта с установленными требованиями к срокам, результатам, риску, расходованию средств и ресурсов, к организационной структуре. 3. Отличие проекта от функциональной деятельности. В целом деятельность любого предприятия или организации может быть определена либо как функциональная, либо как проектная (возможны их комбинации). Функциональная деятельность сама по себе не имеет ни начальной, ни конечной даты. Работы повторяются по тиражированию одного и того же продукта (услуги). Проекты всегда ограничены во времени, имеют даты окончания, а их результат (продукт или услуга) всегда будут уникальны. Функциональная деятельность и проекты различаются, главным образом тем, что оперативная деятельность — это продолжающийся во времени и повторяющийся процесс, в то время как проекты являются временными и уникальными (см. табл. 1). Отличительные черты проекта • Уникальность • Наличие конкретной цели • Наличие четко очерченных задач • Фиксированная длительность проекта и последовательность работ • Жесткие требования по времени, затратам и качеству работы • Ограниченные ресурсы • Наличие руководителя проекта и развивающейся проектной команды Примерами проектов могут быть: • организация своего дела • разработка нового изделия (продукта, услуги); • осуществление изменений в структуре управления организации; • внедрение нового вида услуг; • запуск в производство нового изделия; • разработка или приобретение новой или усовершенствованной информационной системы; • внедрение новых процедур управления. Проектами не являются: • Контроль и качество выпускаемой продукции; • Замена старой оргтехники на новую; • Ведение документооборота; • Выполнение ежедневных плановых заданий. Таблица 1 Отличия функционального и проектного управления   Функциональное управление Проектное управление Круг задач устойчивый изменяющийся Действия в стабильных организационных структурах в пределах проектного цикла Полномочия определены структурой управления постоянное переопределение Ответственность ограничена утвержденными функциями за возникающие изменения и пакет межфункциональных задач Основная задача руководителя оптимизация процесса создание новых процессов, предупреждения и сглаживания противоречия Условия ограниченная изменчивость постоянно меняющаяся среда Функциональные области управления проектом • Общее управление проектом (управление интеграционными процессами). В первую очередь это разработка плана проекта, в дальнейшем – его исполнение, общее управление изменениями. • Управление содержанием проекта. Прежде всего, к данной области относится четкое определение целей и декомпозиция целей. Достаточно часто, цели проекта в процессе его "жизни" претерпевает изменения и возникает необходимость управления изменениями целей, их согласования. • Управление качеством. Для проекта должны быть установлены требования или стандарты качества результатов, по которым оценивается успешность завершения проекта. Определение этих требований, их контроль и поддержка на протяжении "жизни" проекта требует осуществления управления качеством. • Управление временем. В каждом проекте устанавливается период времени и сроки выполнения проекта. Время – это важнейший, но "негибкий" ресурс, поэтому все работы и взаимодействие всех участников должны быть тщательно спланированы, контролироваться и должны приниматься своевременные меры для ликвидации или предотвращения нежелательных отклонений от установленных сроков. • Управление стоимостью. Каждый проект имеет установленный бюджет, но далеко не каждый проект завершается в рамках бюджета. Стоимость тесно связана со временем, но в отличие от него является гибким ресурсом. Управление предметной областью, качеством, временем и стоимостью образуют ядро УП, которое используется практически во всех случаях. • Управление проектной командой. В течение жизни проекта требуется разное количество специалистов, с разной квалификацией, на различные периоды времени. Ядро этих специалистов образует временную команду проекта, поэтому в проекте возникает необходимость подбора людей, распределения обязанностей и ответственности между ними, организация эффективной работы команды и т.д. • Управление коммуникациями или управление информационными связями. Для контроля состояния хода работ проекта, его окружения и прогноза результатов необходимо иметь обратную информационную связь. Управление информационными связями обеспечивает своевременное реагирование на внешние и внутренние возмущающие воздействия. • Управления контрактами и обеспечением проекта. Исполнители привлекаются к выполнению работ и услуг для проекта на основе контрактов. Закупки и поставки требуемых материально-технических ресурсов и оборудования осуществляются тоже на основе заключенных контрактов. Необходимо управление деятельностью по подготовке, планированию, заключению контрактов, контролю за их выполнением и т.п. • Управление рисками. Осуществление проекта связано с неопределенностью многих элементов, вероятностным характером протекания процессов, а значит и определенным риском. Уровень риска проекта можно снизить путем принятия специальных мер. Причем заданный уровень риска проекта можно обеспечить с минимальными затратами. Это требует глубокого изучения природы проекта и его окружения. 4. Измерения проекта. Результаты проекта. Основными характеристиками проекта (рис. 2) являются: ♦ назначение проекта. Описываются новые продукты или услуги, которые получит потребитель в результате реализации проекта; ♦ стоимость проекта. Определяются сметные затраты, необходимые для выполнения работ проекта; ♦ объёмы работ проекта. Устанавливаются количественные показатели работ проекта; ♦ сроки выполнения проекта. Определяется время выполнения проекта (начало, окончание, продолжительность); ♦ качество проекта. Устанавливается соответствие характеристик проекта и его продукции принятым стандартам качества; ♦ ресурсы проекта. Определяются ресурсы, требующиеся для осуществления проекта: например, оборудование, материалы, персонал, программное обеспечение, информационные системы, производственные площади и др.; ♦ исполнители проекта. Определяются специалисты и организации для выполнения работ проекта, их состав (назначение) и квалификация; ♦ риск проекта. Определяются рискованные события в проекте: вероятность их свершения и ущерб от их воздействия на проект. 5. Ключевые составляющие управления проектом. Управление проектом представляет собой открытую динамическую систему, которая состоит из связанных между собой работ, взаимодействует с окружающей средой, получая от нее необходимые ресурсы и предоставляя ей полученные результаты, а также находится под воздействием различных факторов риска. Таким образом, можно выделить четыре базовых элемента управления любым проектом: 1) работы; 2) ресурсы; 3) результаты; 4) риски. Эти базовые элементы можно назвать основными объектами управления проектом. Работы — это трудовые процессы, направленные на достижение результатов и требующие необходимых затрат времени и ресурсов. К работам следует относить деятельность по созданию материальных объектов (производственные работы), интеллектуально-информационной продукции (научно-исследовательские работы), деятельность по выработке и передаче управляющих воздействий и обратной связи (решения и отчеты), деятельность по перемещению материальных объектов, например, ресурсов (поставки). Под ресурсами следует понимать совокупность объектов, необходимых для выполнения работ. Существуют три основные группы ресурсов, используемых в управлении проектом: 1) человеческие ресурсы— субъекты деятельности, объединенные в системы взаимодействия друг с другом и другими ресурсами. К человеческим ресурсам относят руководителей и работников; 2) материальные ресурсы — средства и предметы деятельности, используемые для выполнения работ. К средствам деятельности относят машины и механизмы (активные средства), здания и сооружения (пассивные средства). К предметам деятельности относят материалы и комплектующие; 3) информационные ресурсы — управляющие воздействия, направляемые субъектами деятельности на объекты деятельности, определяющие цели и результаты работ. К информационным ресурсам следует отнести проектные решения, модели, управляющие команды (приказы, распоряжения, задания), отчетную документацию и пр. Результаты — это продукты деятельности (работ), воплощающие в себе ранее поставленные цели. Результаты могут быть: материальные (продукция, изделия) и нематериальные (информационные — документы, социальный эффект); прямые и косвенные; промежуточные и окончательные. Кроме того, окружающая среда, так же как и внутренняя, является источником различного рода возмущений, прямым или косвенным образом воздействующих на проект в целом и на его отдельные составляющие. Потенциальные последствия этих возмущений можно обобщенно определить как риски. Этот базовый элемент управления проектом по большому счету не является объектом управления. Но термин «управление рисками» используется, хотя его не следует понимать буквально. Управление рисками нужно рассматривать как деятельность по управлению взаимодействием проекта и факторов риска, имеющую своей целью минимизировать отклонения от ранее принятых решений. В силу этого риски, определяемые как совокупность вероятностных взаимодействий проекта с независимыми факторами окружающей и внутренней среды, можно обозначить как базовый элемент управления проектом. Все четыре базовых элемента управления проектом находятся во взаимодействии друг с другом. Ресурсы используются при выполнении работ, в ходе выполнения работ создаются результаты, в результатах содержатся материальные и экономические субстраты ресурсов. Риски воздействуют на ресурсы, на работы, на результаты. Проект воздействует на окружающую среду и на риски. Эффективное управление проектом во многом зависит от множества факторов. К ним можно отнести: 1. Четко поставленные цели. Начиная уже с философии проекта (или его миссии). Приверженность проектной группы заявленным целям. 2. Компетентный руководитель проекта. Грамотный, коммуникабельный руководитель, имеющий необходимый технический и административный опыт. 3. Поддержка со стороны руководителей высшего звена. Все заинтересованные стороны должны знать об этой поддержке и ее чувствовать. 4. Компетентные члены проектной группы. Успех проекту обеспечивает грамотная и подготовленная группа исполнителей. 5. Достаточное ресурсное обеспечение. Финансовые, кадровые, материальные и другие ресурсы в достаточном количестве. 6. Адекватное информационное сопровождение. Наличие необходимой для реализации проекта информации о его целях, статусе, изменениях, организационных условиях и потребностях клиентов. 7. Механизмы управления. Механизмы управления происходящими событиями и выявления отклонений от плана. 8. Обратная связь. Все заинтересованные стороны по проекту должны иметь возможность изучать положение дел и вносить соответствующие предложения и коррективы. 9. Отзывчивость к клиентам. Все потенциальные пользователи проекта получают информацию о состоянии дел по проекту. 10. Механизмы поиска и коррекции отклонений. Система мер по поиску проблем и устранению их причин. 11. Неизменность состава участников проекта. Кадровая составляющая проекта на весь срок его реализации должна в максимально возможной степени оставаться постоянной. Частая смена кадров может привести к распылению накопленного группой опыта. 6. Конкурирующие ограничения проекта. У любого проекта есть три основных ограничения, от которых зависит качество его исполнения: – содержание проекта (что нужно сделать для реализации целей проекта); – сроки проекта (время, за которое нужно реализовать проект); – стоимость (бюджет, выделенный на проект). На эти ограничения влияют неопределённые заранее события – риски. С позиции системного подхода проект можно представить в виде «черного ящика» (рис. 1), входом в который являются технические требования и условия финансирования, а итогом работы – достижение требуемого результата. Рис. 1 Формализованное представление проекта Выполнение работ обеспечивается наличием необходимых ресурсов: материалов и финансов (М), оборудования (Е), человеческих ресурсов (Н). Эффективность работ достигается за счет управления (U) процессом реализации проекта, в результате которого наиболее рационально распределяются ресурсы М, Е, Н, координируется последовательность работ и компенсируются возмущающие внутренние (V) и внешние (W) воздействия. 7. Типология проектов. Различные проекты могут выполняться изолированно (монопроект), а при определённых условиях множество взаимосвязанных проектов объединяются в программу. Программа – это совокупность проектов, объединённых общей целью, выделенными ресурсами, временем на её выполнение, технологией, организацией и др. Программы можно условно разделить на моно-, мульти- и мегапроекты. Монопроекты – это проекты, осуществляемые одной организацией или предприятием. Мультипроекты – комплексные проекты или программы, осуществляемые крупными организациями и предприятиями. Мегапроекты – целевые программы, содержащие множество взаимосвязанных проектов, объединенных общей целью, выделенными ресурсами и временем выполнения Такие программы могут быть международными, государственными, национальными, региональными, межотраслевыми, отраслевыми и смешанными. Проекты могут быть классифицированы по различным признакам: – по классу (по составу и структуре проекта); – типу (по основным сферам деятельности, в которых осуществляется проект); – виду (по характеру предметной области проекта); – длительности (по продолжительности периода осуществления проекта); – масштабу (по размерам бюджета, количеству участников и др.). Рассмотрим подробно некоторые особенности, отличающие проекты друг от друга. Инвестиционные проекты – это проекты с определённой и фиксированной целью, расходами, сроками завершения и продолжительностью. Научно-исследовательские и инновационные проекты – это проекты по разработке нового продукта или услуг, проведению научных исследований. Главная цель таких проектов чётко определена, но отдельные цели должны уточняться по мере достижения частных результатов. Организационные проекты – это проекты, направленные на реформирование организации, реализацию концепции управления, создание новой организации. Цели проекта заранее определены, однако результаты проекта количественно и качественно труднее определить, чем в первых двух случаях, так как они связаны, как правило, с организационным улучшением системы. Экономические проекты – это проекты, целью которых является улучшение экономических показателей функционирования системы, поэтому их оценить значительно труднее, чем в ранее рассмотренных случаях. Социальные проекты (например, реформирование системы социального обеспечения, здравоохранения, преодоление последствий природных и социальных потрясений и др.) имеют свою специфику, и им присуща наибольшая неопределённость. 8. Управление проектами в рамках стратегических целей организации. Каждый проект должен соответствовать стратегическому плану организации, который создается для удовлетворения будущих потребностей ее клиентов. Обеспечение связи стратегического плана и проекта - весьма кропотливая работа, требующая большого постоянного внимания руководителей высшего и среднего уровня. Чем больше организация и разнообразнее направления ее деятельности, тем труднее создать и поддерживать прочную связь между стратегическим и проектным управлением. Как организация может обеспечить такую связь? Только интеграцией проектов в стратегический план. Такая интеграция предполагает, во-первых, наличие стратегического плана и, во-вторых, механизма определения приоритета проектов по степени их соответствия этому плану. Важно, чтобы в процесс стратегического планирования были вовлечены сотрудники всех уровней организации, а не только ее высшее руководство. Особенно важно, чтобы руководители проекта были включены в процесс стратегического планирования и реализации стратегии. Это крайне полезно по следующим причинам: • такое участие дает руководителю проекта понимание общей перспективы целей организации, что ведет к профессиональному росту и принятию более осмысленных решений; • опытные руководители проекта могут высказать ценные мысли относительно использования возможностей организации и ее ограниченных ресурсов; • каждый руководитель проекта может сравнить свой проект с другими; • осознание критериев и механизма отбора способствует более спокойному перераспределению ресурсов и приоритетов между различными проектами. В результате всего этого руководители проектов стремятся к пониманию стратегического управления и процесса выбора проектов. Модель и методология стратегического менеджмента Для того чтобы более детально попять, каким образом проект может быть встроен в стратегию организации рассмотрим общие принципы и подходы стратегического менеджмента, представленные в его модели. В самом общем виде шаги или последовательность операций этой модели представлены на рис. 2. Рис. 2 Основные шаги модели стратегического менеджмента Основные принципы стратегического менеджмента сводятся к следующему. Изучение рынка. Здесь теоретиков и практиков управления интересуют возможности роста рынка и изменений в составе основных "игроков" рыночной конкуренции. Эти исследования являются решающими для определения структуры коммерческих рисков фирмы. Сбор информации. Организация должна иметь достаточное количество каналов ввода информации как относительно внешнего окружения, так и относительно внутриорганизационных процессов и их динамики. Эффективно действующая на рынке коммерческая фирма должна иметь информационную систему, предполагающую не только сбор информации, но и ее обработку, анализ, систематизацию, хранение и определение информационных потребностей в будущем. Эмпирические исследования. Модели нуждаются в постоянной верификации, т.е. подтверждении опытными данными. Это, в свою очередь, определяется тем, что универсальные, абстрактные модели стратегического менеджмента необходимо применять для решения конкретных задач, уникальность которых следует из особенностей конкретной фирмы, действующей на конкретном рынке в строго фиксированный отрезок времени. Транснациональный бизнес. Как научная дисциплина стратегический менеджмент конца 1990-х гг. ориентируется на процессы глобализации бизнеса. Именно это обстоятельство является одной из наиболее ценных и практически полезных характеристик дисциплины в глазах руководителей корпораций. С другой стороны, интернационализация бизнеса порождает ряд проблем в управлении проектами, многие из которых пока еще не получили удовлетворительного решения. В этом отношении стратегический менеджмент изменяет как корпоративное мышление менеджеров проектов, так и приоритеты корпораций. Принятие решений. Процесс стратегического менеджмента — это процесс перманентного принятия решений, их осуществления, контроля, коррекции. Этот процесс носит циклический характер, причем, чем более изменчива и неопределенна среда, тем короче длина цикла принятия решений. Во многом проектное управление также является процессом принятия решений. Приоритеты па пересечении этих процессов обычно отводятся стратегическим решениям, а проектные решения должны адаптироваться к стратегическим. Дух предпринимательства. Хотя стратегический менеджмент строится как систематическая, логически связная теория, базирующаяся на эмпирических данных, успех стратегии определяется не в последнюю очередь предвидением, интуицией, чувством, что так или иначе поступать "правильно", т.е. всем тем, что определяется как предпринимательская инициатива. Как отмечает известный американский теоретик менеджмента И. Ансофф, предпринимательское поведение означает создание потенциала для получения прибыли там, где его раньше не было. Это, в свою очередь, требует формирование новых систем, новых структур и новых навыков менеджеров, в частности, выраженных лидерских черт — "харизмы", умения творчески решать проблемы, брать на себя риск, планировать, основываясь на предпринимательских взглядах. Лучшая форма реализации предпринимательской активности — разработка и осуществление проектов. Видение долговременных перспектив. В то время как операционный менеджмент фокусируется на краткосрочных целях, стратегический менеджмент ориентируется на долгосрочные перспективы. Чаще всего перспективы следующего года деятельности организации рассматриваются как отправная точка стратегического развития и изменений. Проекты, связанные со стратегией, также, как правило, отличаются большими временными интервалами осуществления. Стратегические альтернативы. Методология стратегического менеджмента предполагает выдвижение и оценку альтернативных вариантов стратегического развития. Оценка вариантов — одна из важнейших и наиболее ответственных задач стратегического менеджмента. Даже на этапе осуществления стратегии допускается возможность се существенной коррекции или замены другой, более соответствующей изменившимся условиям. Такие изменения предполагают или внесение существенной коррекции в проекты, или реализацию новой альтернативы через другую совокупность проектов. Междисциплинарный подход. Теория стратегического менеджмента базируется на комплексе поведенческих наук — социологии, психологии, политологии, экономике, праве и др. В ней широко применяются математические, статистические, системные, вероятностные методы исследования. То же самое характерно и для проектного управления: в зависимости от типа проекта и конкретных условий его реализации (контекста) требуются зачастую сильно различающиеся навыки, знания и опыт. Оптимизация использования ресурсов. Исследование ресурсных возможностей организации и выбор стратегии, обеспечивающей эффективное использование ресурсов в долговременной перспективе — определяющий фактор планирования, выбора и осуществления стратегии. Те же требования относятся и к эффективному руководству проектами. Осуществление стратегии и контроль. Значительное внимание в стратегическом менеджменте уделяется человеческому фактору реализации стратегии. Успешная реализация стратегии возможна, когда менеджеры владеют навыками управления организационными инновациями, умеют преодолевать сопротивление изменениям, формировать инновационные команды и управлять ожиданиями людей, повлеченных в процесс стратегических изменений. Контроль осуществления стратегии эффективно осуществляется через контроль проектов, посредством которых стратегия реализуется. Какие преимущества дает проектным менеджерам знание стратегического менеджмента? Кроме того, что стратегический менеджмент заставляет всерьез задумываться о будущем организации, он позволяет: • на рациональной основе сформулировать возможные стратегии и определить, в какой мере подходит организации та или иная стратегия и какие проекты придется реализовать для ее осуществления; • искать альтернативные пути развития проекта, чтобы выбрать оптимальный из них; • развить умение ориентироваться в будущем, что приводит к систематическому учету возможных последствий тех или иных проектных решений; • более эффективно и грамотно размещать ресурсы проекта; • понимать природу и значение неопределенностей и рисков в управлении проектами; • использовать методологию системного подхода в решении организационных проблем и на этой основе развивать более эффективное управление проектом; • связывать в единый комплекс взаимозависимых элементов процессы коммуникации, координации и контроля в рамках проекта как целого; • стимулировать мотивацию и энтузиазм сотрудников, определять миссию проекта и понимание значения достижения целей проекта для индивидуального развития и роста сотрудников; • преодолевать сопротивление переменам, формировать инновационную организационную культуру команды проекта. Стратегический менеджмент развивает широту управленческого мышления руководителей проектов, делает их более полезными для организации. Руководители, имеющие знания и навыки в области стратегического менеджмента имеют больше шансов добиться быстрого роста по служебной лестнице и сделать успешную карьеру. А начинающим менеджерам проектов стратегический менеджмент позволяет достаточно быстро понять, как работает организация, какова взаимосвязь ее структурных компонентов, какова роль отдельных индивидов в принятии важных организационных решений. 9. Жизненный цикл проекта. Структура жизненного цикла и ключевые характеристики. Каждый проект от возникновения идеи до полного завершения проходит ряд фаз. Полный набор фаз – это жизненный цикл проекта. Жизненный цикл проекта (ЖЦП) – это начало и окончание проекта, т.е. промежуток времени между моментом появления проекта и моментом его закрытия. ЖЦП состоит из нескольких фаз, что обеспечивает лучший управленческий контроль и учёт, а фазы разделяются на стадии и этапы. Фаза состоит из одной и более целей. Цель – это достижимый и проверяемый продукт деятельности. Проверки в конце фазы – фазовые выходы, этапные выходы, точки отстрела. Фаза завершается неким достижением (результатом) и даёт возможность (в том числе определить и исправить ошибки) перейти в другую фазу. Общепринятой концепции разделения ЖЦП на фазы нет и быть не может, т.к. каждый проект уникален. 10. Взаимосвязь жизненного цикла проекта и продукта. Важно понимать, что жизненный цикл проекта тесно связан с жизненным циклом продукции, создаваемой как его результат. Жизненный цикл проекта и жизненный цикл продукта являются разными, но связанными концепциями. Так, проект, осуществляемый с целью выпуска на рынок нового персонального компьютера, является лишь одним из аспектов жизненного цикла этого продукта. Чаще всего жизненный цикл проекта считают частью жизненного цикла продукта, покрывающей его начальные стадии (обычно это только разработка продукта и вывод его на рынок). В жизненном цикле продукта следует различать два аспекта: 1) операционную деятельность, связанную с прохождением продукта по определенным операциям в рамках большого производственно-эксплуатационного процесса создания и использования продукта; 2) рыночную деятельность, связанную с присутствием и движением продукта на рынке. Оба аспекта тесно связаны между собой, но при этом имеют различные основные целевые направления. Первый воплощается прежде всего в производственных, сервисных и эксплуатационных операциях; второй целиком и полностью вписывается в рамки коммерческой и финансовой деятельности. Рыночный жизненный цикл продукта — период от возникновения бизнес-идеи о продукте до завершающего свертывания продаж. Этот цикл отражает в первую очередь движение денежных средств при создании продукта (затраты) и его продаже (доходы). Также рыночный жизненный цикл отражает динамику всего объема продукции. В течение жизненного цикла происходят существенные изменения в позиции товара на рынке, которые отражаются на его продажах. Так как увеличение прибыли — одна из важных целей любого предприятия, то и рыночный жизненный цикл продукта является важным инструментом управления предприятием. Жизненный цикл продукта в этом смысле представляет собой общий инструмент планирования и контроля (включая прогнозирование) денежных потоков в рамках общей инвестиционной инициативы и традиционно входит в инструментарий стратегического маркетинга. Во многом он соответствует модели жизненного цикла инвестиционного проекта, отражающей расходы и доходы. Чаще всего в рыночном (или, как было показано выше, инвестиционном) жизненном цикле продукта выделяют пять основных стадий, или фаз: 1) разработка продукта; 2) вывод продукта на рынок; 3) рост продаж; 4) насыщение рынка; 5) спад продаж. Модель рыночного жизненного цикла продукта позволяет планировать и контролировать финансовые, маркетинговые и коммерческие усилия по управлению им на рынке. Также эта модель дает возможность согласовывать различные действия по управлению продуктом как между собой, так и с ситуацией на рынке. Так, рыночный жизненный цикл продукта позволяет определить специфику маркетинговых усилий на протяжении жизненного цикла продукта. Принято выделять пять различных ситуаций, определяющих маркетинговые стратегии поведения на этапах жизненного цикла продукта: 1) кристаллизация спроса — скрытый спрос на продукт пробуждается при разработке и выводе продукта на рынок; 2) экспансия рынка — расширение рынка, увеличение количества покупателей и продавцов; 3) фрагментация рынка — разделение его на самостоятельные фрагменты, связанные либо с деятельность групп компаний, либо с группами модификаций продукта, либо с ценовыми показателями продукта и др.; 4) консолидация рынка — усиление конкуренции, сокращение количества производителей и продавцов, снижение цен, падение прибылей; 5) закрытие рынка — сокращение спроса на продукт, снижение объемов и прекращение производства. Исходя из плановых объемов продаж с помощью жизненного цикла можно управлять также экономическими показателями продукта, например, себестоимостью и ценой. Таким образом, модель рыночного жизненного цикла продукта позволяет интегрировать все усилия по управлению деятельностью, связанной с созданием и продажей товара, и согласовывать их с изменяющейся ситуацией на рынке. На рис. 3 жизненный цикл продукта дополнен некоторыми маркетинговыми и экономическими характеристиками деятельности. В отличие от рыночного операционный жизненный цикл продукта отражает различные операции и процессы, которые выполняются в рамках всей технологической цепочки его разработки, создания, продажи и эксплуатации. Операционный жизненный цикл продукта — логико-временная структура операций над ним. Этот жизненный цикл представляет движение не всего объема продукции, а отдельно взятого экземпляра, естественно, в тесной связи с общим производством, сбытом и эксплуатацией. Операционный жизненный цикл продукта используется не для планирования общих показателей деятельности, но для согласования различных стадий в единый технологический поток. В рамках операционного жизненного цикла представлены не поведение продукта на рынке и не результаты этого поведения, а задачи, работы, процессы, операции, объединенные в блоки в целях выявления в них характерных особенностей и их интеграции. Ввиду того что самые важные, определяющие содержание и облик продукта, операции осуществляются на стадии его разработки, модели операционного жизненного цикла имеют инжиниринговую направленность. Так, достаточно широкую известность получила U-модель операционного жизненного цикла, представленная на рис. 4. Рис. 3 Согласование различных аспектов деятельности в рамках рыночного жизненного цикла продукта Рис. 4 U-модель жизненного цикла проекта Графическая форма модели в виде буквы «U» сознательно передает незавершенность цикла, показанного на модели, демонстрируя, что операции, приведенные в ней, являются частью общей модели жизненного цикла продукта. В модели также представлены области принятия различного рода решений. Выделение этих областей позволяет определять стили и методы управления, приемлемые на различных стадиях, а также степень интеграции деятельности, решения по организационной структуре и регламентации процессов. Библиографический список к Лекции №1 (Тема 1): 1. Коваленок Т.П. Управление проектами: учеб. пособие - СПб. : ПГУПС, 2011. - 73 с. 2. Руководство к Своду знаний по управлению проектами. Project Management Institute (USA). - 5-е изд. - Москва: Олимп-Бизнес, 2014. – 586 с. 3. Управление проектами: учебно-практический курс участникам слетов кадрового резерва молодежи ОАО «РЖД» – М.: Высшая школа управления, 2008. 4. Краткий курс лекций по дисциплине «Управление проектами» [Электронный ресурс] URL: http://studme.org/1181012221327/menedzhment/upravlenie_proektami (дата обращения 22.08.2016) I СУЩНОСТЬ, ОСНОВНЫЕ ПОНЯТИЯ И ПРИНЦИПЫ УПРАВЛЕНИЯ ПРОЕКТАМИ 11. Назначение фазы проекта. Взаимосвязи между фазами. Концептуальная фаза. На этой фазе должен быть определен проект, разработана его концепция, включающая следующие стадии: 1) инициацию проекта – определяет и авторизует проект или фазу проекта; 2) формирование бизнес-идеи, постановку целей; 3) назначение руководителя проекта и формирование ключевой команды проекта; 4) установление деловых контактов и изучение рынка, мотивации и требований заказчика и других участников; 5) сбор исходных данных и анализ существующего состояния; 6) определение основных требований, ограничительных условий, материальных, финансовых и трудовых ресурсов; 7) сравнительную оценку альтернатив; 8) представление предложений, их экспертизу и утверждение. Фаза «Планирование» служит для определения и уточнения цели, планирования действий, необходимых для достижения цели. Планирование в том или ином виде производится в течение всего срока реализации проекта. В самом начале жизненного цикла проекта разрабатывается предварительный план – грубое представление о том, что потребуется выполнить в случае реализации проекта. Разработка плана управления проектом включает в себя операции, необходимые для формирования, координации всех вспомогательных планов и их интеграции в единый план управления проектом. Как правило, план проекта не остается неизменным, и по мере его осуществления он постоянно корректируется с учётом текущей ситуации. Фаза «Осуществление». После утверждения плана следует фаза его реализации. По мере осуществления проекта основная задача руководителя проекта заключается в управлении ходом работ проекта и установлении различных технических и организационных связей. С этой целью проводится постоянный мониторинг и контроль за работами проекта. Фаза «Завершение». Проект заканчивается, когда достигнуты поставленные перед ним цели. Последним процессом, входящим в управление интеграцией проекта, является Закрытие проекта (фазы проекта). Закрытие проекта (фазы проекта) – завершение всех операций по всем группам процессов проекта для формального завершения проекта. На этой фазе разрабатываются процедуры по формальному закрытию проекта (фазы проекта) и закрытию контрактов. В процессе закрытия проекта: • проверяются и документируются продукты проекта; • определяются и документируются причины досрочного завершения проекта; • издается распоряжение о закрытии проекта (формально закрывающее проект так же, как устав формально начинает проект); • документируются «усвоенные уроки» пo проекту; • оформляется и закрывается архив проекта. Связи между фазами Существует три основных типа взаимосвязей между фазами: • Последовательная связь, когда фаза может начинаться только после завершения предыдущей фазы. Пошаговый характер такого подхода уменьшает неопределенность, но может исключать варианты для сокращения сроков. • Перекрывающаяся связь, когда фаза начинается до завершения предыдущей фазы. Иногда это может применяться в качестве примера метода сжатия сроков, называемого «быстрый подход». Перекрывающиеся фазы могут повысить риск и привести к повторению работ, если последующая фаза начнется прежде, чем будет получена точная информация о результатах предыдущей фазы. • Итерационная связь, когда на любое заданное время планируется только одна фаза, а планирование следующей осуществляется по мере выполнения работ в рамках текущей фазы и получения результатов. Данный подход полезен в значительной степени в неопределенных, непостоянных или быстро меняющихся средах, таких как исследования, но он может уменьшить способность обеспечения долгосрочного планирования. В проектах, состоящих из многих фаз, на протяжении жизненного цикла может существовать несколько связей между фазами. Связи, применяемые в периоды между фазами, определяются такими соображениями, как требуемый уровень контроля, эффективность и степень неопределенности. Исходя из этих соображений, в периоды между различными фазами одного проекта могут применяться все три вида связей. 12. Применение итеративного подхода в управлении проектом Итерация (лат. iteratio — повторяю) — повторение какого-либо действия. Основой итеративного подхода является непрерывный анализ выполненных работ, последующее проектирование и физическое воплощение результатов проектирования. Итеративный подход акцентирует работу команды в более предсказуемом и повторяемом направлении. На рис.1 представлен пример применения итеративного подхода. Рис. 1 Пример применения итеративного подхода. Основные преимущества итеративного подхода: - нивелирование воздействия серьезных рисков на ранних стадиях проекта, пока это еще можно сделать с минимальными затратами; -возможность организовать плодотворную обратную связь с будущими конечными пользователями с целью создания системы, реально отвечающей их потребностям; - акцент усилий на наиболее важные и критичные направления проекта; -непрерывное итеративное тестирование конечного продукта, позволяющее оценить успешность всего проекта в целом; - раннее обнаружение несоответствий между требованиями, моделями и программным кодом; - более равномерная загрузка участников проекта; -эффективное использование накопленного опыта; - реальная оценка текущего состояния проекта и, как следствие, большая уверенность заказчиков и непосредственных участников в его успешном завершении. Применение итеративного подхода может снизить уровень риска проекта путем предоставления отдельных готовых частей системы в сжатые сроки. В конце каждого цикла разработки исполнитель должен продемонстрировать заказчику результаты и получить отзывы пользователей о функциональности, работоспособности системы и ее стабильности. Использование такого подхода снижает уровень риска проекта с самого начала разработки. Это происходит по той причине, что команда проекта фокусируется на ключевой функциональности системы и снижает риски с высоким уровнем на ранних этапах разработки (например, разработка ПО). Пример из проектирования ПО Что такое итерационная разработка? Проект, в котором применяется итерационная разработка, имеет жизненный цикл, состоящий из нескольких итераций. Итерация включает приблизительно последовательный набор задач бизнес-моделирования, требований, анализа и проектирования, реализации, тестирования и развертывания в различных пропорциях, в зависимости от расположения итерации в цикле разработки. Итерации на начальном этапе и этапе уточнения фокусируются на управлении, требованиях и проектировании; итерации на этапе построения фокусируются на проектировании, реализации и тестировании; а итерации на этапе внедрения фокусируются на тестировании и развертывании. Итерациями следует управлять как timeboxed, то есть расписание итерации следует считать фиксированным и управлять областью содержимого итерации, чтобы она соответствовала этому расписанию. Зачем нужна итерационная разработка? В начальном проекте по отношению к его ключевым требованиям с большой вероятностью будут содержаться ошибки. Позднее обнаружение дефектов проекта приводит к дорогостоящим затратам и, в некоторых случаях, даже к прекращению проекта. Любой проект влечет за собой определенные риски. Чем раньше в жизненном цикле можно проверить отсутствие рисков, тем более точно можно выполнять планирование. Многие риски не удается обнаружить до тех пор, пока не будет предпринята попытка интеграции системы. Невозможно предугадать все риски, независимо от опыта коллектива разработчиков. В водопадном жизненном цикле невозможно убедиться в отсутствии рисков на ранних этапах жизненного цикла. В итерационном жизненном цикле вы на основании списка ключевых рисков выбираете инкремент для разработки в итерации. Поскольку в итерации создается протестированный исполняемый продукт, то можно проверить, были ли в результате снижены риски или нет. Преимущества итерационного подхода Итерационный подход в целом имеет преимущество перед линейным или водопадным подходом по целому ряду причин. • Риски снижаются ранее, поскольку интеграция элементов выполняется постепенно. • Поддерживается изменение требований и тактики.  • Облегчается улучшение и отладка продукта, что позволяет получить более надежный продукт. • Возможно обучение организаций в этом подходе и улучшение их процессов.  • Увеличивается возможность повторного использования. Однажды заказчик сказал: "При водопадном подходе все выглядит прекрасно практически до конца проекта, иногда вплоть до середины интеграции. А затем все распадается. При итеративном подходе очень трудно долго скрывать правду." Руководители проектов часто оказывают сопротивление итерационному подходу, считая его бесконечным. В Rational Unified Process итерационный подход полностью управляем; планируется число, продолжительность и цели итераций. Определяются задачи и ответственности участников. Собираются объективные показатели выполнения. От одной итерации к следующей существует некоторый объем повторяющихся действий, однако это также тщательно контролируется. Снижение рисков Итерационный подход позволяет снизить риски раньше, поскольку многие риски обнаруживаются только во время интеграции. При развертывании ранней итерации вы проходите через все разделы, изучая многие аспекты проекта: инструменты, готовое программное обеспечение, навыки сотрудников и так далее. Предполагаемые риски могут не подтвердиться, в то время как могут быть обнаружены новые, неожиданные риски. Интеграция не является одним "большим шоком" в конце - элементы объединяются постепенно. В действительности, итерационный подход представляет собой практически непрерывную интеграцию. То, что является длительным, неопределенным и сложным - что отнимает до 40% общих усилий в конце проекта - и что сложно точно спланировать, делится на от шести до девяти меньших интеграций, которые выполняются с гораздо меньшим числом элементов. Внесение изменений Итерационный подход позволяет учитывать изменения в требованиях, поскольку обычно они будут изменяться по мере работы над проектом. Изменения в требованиях и "смещение" требований всегда являются первичными источниками нарушений для проекта, ведущими к задержке поставок, сбоям в расписании, неудовлетворенности заказчиков и разочарованию разработчиков. Двадцать пять лет назад Фред Брукс написал: "Заранее планируйте выкинуть первую версию - все равно придется." Мнение пользователей будет изменяться по мере продвижения работы над проектом. Такова человеческая натура. Неверным было бы принуждать пользователей принять систему такой, какой они представляли себе первоначально. Мнение пользователей меняется, поскольку меняется контекст - они больше узнают о среде и технологии и видят промежуточную демонстрацию разрабатываемого продукта. Итеративный жизненный цикл обеспечивает управление путем внесения тактических изменений в продукт. Например, для того чтобы составить конкуренцию существующим продуктам, вы можете принять решение выпустить продукт с ограниченным набором функций раньше, для того чтобы опередить действия конкурента, либо можно адаптировать другого вендора для данной технологии. Итерации также поддерживают технологические изменения по мере продвижения работы над проектом. Если какая-либо технология изменяется или становится стандартом при появлении новой технологии, то это может дать проекту определенные преимущества. Это в особенности относится к изменениям платформы и изменениям инфраструктуры на более низких уровнях. Достижение более высокого качества Итерационный подход позволяет получить более устойчивую архитектуру, поскольку ошибки исправляются на протяжении нескольких итераций. Первые дефекты обнаруживаются уже в первых итерациях продукта. Обнаруживаются узкие места в производительности, которые можно исправить сразу, а не непосредственно перед доставкой. Итерационная разработка, в отличие от выполнения тестов в конце проекта, позволяет протестировать продукт более тщательно. Наиболее важные функции можно протестировать в нескольких итерациях. Обучение и улучшение Разработчики могут обучаться по мере продвижения работы, и различные умения и специализации более полно используются в течение всего жизненного цикла. Тестеры, вместо длительного ожидания, в течение которого они только строят планы и оттачивают свои навыки, начинают выполнять тестирование раньше, раньше начинается создание технической документации и так далее. При оценке ранних итераций можно обнаружить необходимость в дополнительном обучении или помощи извне. Также можно улучшить сам процесс. Оценка в конце итерации не только дает обзор состояния проекта с точки зрения планирования продукта, но также позволяет проанализировать, что необходимо изменить в организации и проекте для улучшения работы в следующей итерации. Увеличение возможностей повторного применения Итерационный жизненный цикл облегчает повторное применение. Облегчается идентификация стандартных компонентов, если они разрабатываются или реализуются по-отдельности, по сравнению с идентификацией всей общности. Идентификация и разработка многоразовых компонентов является сложной задачей. Обзоры проекта в ранних итерациях позволяют архитекторам программного обеспечения обнаружить возможность потенциального повторного применения, и в последующих итерациях они могут далее разрабатывать и развивать этот стандартный исходный код. Применение итерационного подхода облегчает использование преимуществ коммерческих готовых продуктов. На протяжении нескольких итераций можно выбрать такие продукты, интегрировать их и убедиться, что они соответствуют данной архитектуре. 13. Влияние характеристик организации (структура, культурные нормы, базы знаний и т.д.) при реализации проекта. Ключевые положения влияния организационной структуры компании. Влияние организации на управление проектами Организационная культура, стиль и структура влияют на то, как выполняются проекты. Степень полноты управления проектами организации и ее системы управления проектами также могут оказывать влияние на проект. Если в проект вовлечены сторонние организации в рамках совместного предприятия или партнерства, на проект будут оказывать влияние несколько предприятий. Организационная культура и стили Культура и стили обычно называются «культурными нормами». «Нормы» включают общие знания о том, как подходить к выполнению работы, какие средства считаются приемлемыми для выполнения работы и кто имеет решающее влияние в содействии выполнению работы. Большинство организаций разработали уникальную культуру, которая проявляется различными способами, включая, среди прочего: • общие взгляды, ценности, нормы, убеждения и ожидания; • правила, методы и процедуры; • взгляд на взаимоотношения руководства; и • рабочую этику и часы работы. Организационная культура представляет собой фактор среды предприятия. Следовательно, менеджер проекта должен понимать различные организационные стили и культуры, которые могут оказывать влияние на проект. Например, в некоторых случаях лицо, указанное во главе организационной структуры, на практике может являться лишь номинальным главой, не имеющим фактических полномочий. Менеджер проекта должен знать, кто из сотрудников организации принимает решения, и сотрудничать с ними для содействия успеху проекта. Организационные коммуникации Успех управления проектами в организации в значительной степени зависит от результативного стиля организационных коммуникаций, особенно в свете глобализации профессии управления проектами. Возможности организационных коммуникаций оказывают огромное влияние на то, как выполняются проекты. Как следствие, руководители проектов, находящиеся на расстоянии, способны наладить более результативные коммуникации с соответствующими заинтересованными сторонами внутри организационной структуры с целью содействия принятию решений. Заинтересованные стороны и члены команды проекта также могут использовать электронные средства связи (включая электронную почту, текстовые, мгновенные сообщения, социальные сети, видео- и веб-конференции и другие электронные средства коммуникации) для формального и неформального общения с руководителем проекта. Активы процессов организации Активы процессов организации включают все без исключения активы, относящиеся к процессам, во всех организациях, участвующих в проекте, которые могут быть использованы для оказания влияния на успех проекта. Эти активы процесса включают формальные и неформальные планы, правила, процедуры и приказы. Кроме того, активы процесса включают базы знаний организации, такие как накопленные знания и историческая информация. Активы процессов организации могут включать выполненные сроки, данные о рисках и данные о заработанной стоимости. Обновление и дополнение активов процессов организации по мере необходимости на протяжении проекта, как правило, является обязанностью членов команды проекта. Активы процессов организации могут быть разбиты на две категории: Процессы и процедуры Процессы и процедуры организации для проведения работ включают, среди прочего: • организационные стандартные процессы, такие как стандарты, правила (например, политика безопасности и охраны здоровья, правила этики и политика управления проектом), стандартные жизненные циклы продуктов и проектов, а также правила и процедуры контроля качества (например, проверки технологических процессов, целевые объекты усовершенствования, контрольные списки и описания типовых процессов для использования в организации); • типовые приказы, рабочие инструкции, критерии оценки предложений и критерии измерения исполнения; • шаблоны (например, риск, иерархическая структура работ, сетевая диаграмма проекта и шаблоны договоров); • приказы и критерии для подгонки набора стандартных процессов организации с целью удовлетворения конкретных потребностей проекта; • требования организации к обмену информацией (например, имеющаяся конкретная технология связи, допустимые среды передачи данных, политика сохранения записей и требования по безопасности); • приказы или требования к завершению проекта (например, окончательные проверки проекта, оценки проекта, подтверждения продуктов и критерии приемки); • процедуры финансового контроля (например, отчетность по времени, необходимый анализ расходов и трат, коды бухгалтерского учета и стандартные положения договоров); • процедуры управления открытыми вопросами и дефектами, определяющие средства контроля над открытыми вопросами и дефектами, выявление и разрешение открытых вопросов и дефектов, а также отслеживание мероприятий; • процедуры управления изменениями, включающие действия, согласно которым будут модифицироваться официальные стандарты компании, политики, планы и процедуры или любые проектные документы, а также порядок одобрения и утверждения любых изменений; • процедуры управления рисками, включая категории рисков, определение вероятности и последствия, а также матрицу вероятности и последствий; и • процедуры расстановки приоритетов, утверждения и выдачи разрешений на выполнение работ. Корпоративная база знаний Корпоративная база знаний организации для хранения и извлечения информации включает, среди прочего: • базы данных измерений процессов, используемые для сбора и обеспечения доступа к данным измерений по процессам и продуктам; • файлы проекта (например, содержание, стоимость, сроки, а также базовые планы обеспечения качества, базовые планы исполнения, календари проектов, сетевые диаграммы проектов, реестры рисков, запланированные мероприятия по реагированию и определенные последствия рисков); • историческая информация и базы накопленных знаний (например, записи и документы проекта, вся информация и документация по завершению проекта, информация о результатах решений по отбору предыдущих проектов наряду с информацией о выполнении предыдущих проектов, а также информация о трудоемкости управления рисками); • базы данных по управлению открытыми вопросами и дефектами, содержащие сведения о статусе открытых вопросов и дефектов, информацию об управлении, данные о разрешении открытых вопросов и дефектов, а также результаты проведенных мероприятий; • базы знаний по управлению конфигурацией, содержащие версии и базовые планы по всем официальным стандартам компании, политикам, процедурам и любым проектным документам; и • финансовые базы данных, содержащие такую информацию, как данные о человеко-часах, понесенных затратах, бюджете и любом перерасходе средств по проекту. Факторы среды предприятия Факторы среды предприятия — условия, не находящиеся под непосредственным контролем команды проекта, которые влияют на проект, ограничивают или направляют его. Факторы среды предприятия считаются входами для большинства процессов планирования, могут расширить или ограничить возможности управления проектом, а также положительно или отрицательно сказаться на результате. Факторы среды предприятия широко различаются по типу или характеру. Факторы среды предприятия включают в себя, среди прочего: • организационную культуру, структуру и руководство; • географическое распределение оборудования и ресурсов; • государственные и промышленные стандарты (например, предписания контролирующих органов, кодексы поведения, стандарты на продукцию, стандарты качества, стандарты изготовления); • инфраструктуру (например, существующие сооружения и основное оборудование); • имеющиеся человеческие ресурсы (например, навыки, знания, специализации, такие как проектирование, разработка, юридические вопросы, заключение договоров и закупки); • управление персоналом (например, руководящие указания по приему на работу и увольнению, анализ эффективности и результативности работы и записи об обучении персонала, политика вознаграждений и сверхурочной работы, а также учет рабочего времени); • корпоративная система авторизации работ; • ситуация на рынке; • толерантность к риску заинтересованных сторон; • политический климат; • каналы коммуникаций, принятые в организации; • коммерческие базы данных (например, стандартизированные сметные данные, данные изучения промышленных рисков и базы данных рисков); • информационная система управления проектами (например, автоматизированные системы, такие как программное обеспечение для управления расписанием, система управления конфигурацией, система сбора и распределения информации или веб-интерфейсы к другим автоматизированным системам, работающим в режиме онлайн). Структура организации и её влияние на процесс управления проектами Под организационной структурой обычно понимается совокупность элементов организации (должностей и структурных подразделений) и связей между ними. Идеальных организационных структур управления проектами не существует, однако есть несколько базовых типов включения проекта в вышестоящую организацию: функциональная структура, проектная структура, матричная структура. Функциональная структура. Самой распространенной структурой в России на сегодняшний день является функциональная структура , представляющая собой иерархию, в которой для каждого служащего четко определён один вышестоящий руководитель. При этом сотрудники сгруппированы по специальностям: маркетинг, производство, закупки и т.п. Такая структура оптимальна для хорошо налаженного циклического производства, однако вызывает ряд трудностей при выполнении проектов. Основным недостатком при реализации проектов является её неповоротливость, так как все распоряжения любой сотрудник может получать только от своего функционального руководителя, что вызывает длительные задержки при принятии решений. Такая структура может успешно использоваться в том случае, когда проекты носят рутинный типовой характер, а также в случае, если проекты выполняются в рамках функциональных подразделений. Проектная структура организации отдаёт предпочтение проектам. Каждый сотрудник организации прикреплён к какому-то одному проекту. Такая структура эффективна в крупных проектах продолжительностью более 2 лет, а после завершения проекта команда проекта может потерять работу. Матричная структура организации – это синтез функциональной и проектной структур. В этом случае персонал подотчётен и руководителю отдела, и руководителю проекта. Применяются несколько типов матричных структур, которые различаются соотношением в них функционального и проектного принципов управления: • слабая; • сбалансированная; • сильная. Слабая матричная структура фактически представляет собой функциональную структуру с той лишь разницей, что функции по координации проекта передаются одному из членов команды проекта. Все полномочия по-прежнему остаются в руках функциональных руководителей. Сбалансированная матричная структура представляет собой баланс полномочий между руководителем проекта и руководителем функционального отдела Сильная матричная структура предполагает в дополнение к существующим функциональным подразделениям образование отдела менеджеров проекта. Сотрудники этого подразделения заняты исключительно руководством вверенных им проектов. При этом менеджер проекта обладает значительными полномочиями по управлению ресурсами в проекте. Матричная структура нацелена на конкретный проект, который должен быть выполнен к определенному сроку в пределах установленной сметы расходов. Такая структура обычно появляется при наличии повторяющихся задач, требующих использования сходных ресурсов. Матричная структура способна обеспечить гибкость и инновационность при дальнейшем усложнении технологий, но может оказаться для организации затратной, т.е. двойные полномочия требуют дополнительного администрирования и увеличения накладных расходов. Каждый тип структуры проекта имеет свои плюсы и свои минусы. Используя критерии выбора организационной структуры, можно подобрать тип организационной структуры, наиболее подходящий для данного проекта (табл. 1). Вопрос выбора структуры стоит только перед теми организациями, которые занимаются проектной деятельностью. Для организаций с циклическим и регулярным бизнесом идеально подходит матричная структура, что подтверждает многолетний опыт ее использования подавляющим большинством организаций во всем мире. Таблица 1 Выбор организационной структуры проекта Критерий выбора Структура проекта Функциональная Матричная Проектная Уровень неопределенности Низкий Средний Высокий Технология Типовая Сложная Инновационная Комплексность Низкая Средняя Высокая Продолжительность Малая Средняя Большая Значение для компании Малое Среднее Ключевое Уровень взаимосвязей между частями проекта Низкий Средний Высокий Важность фактора времени (наличие критических сроков) Низкая Средняя Высокая Зависимость от вышестоящей организации Высокая Средняя Низкая Таким образом, организационная структура является наиболее важным механизмом управления проектом. Она дает возможность реализовать всю совокупность функций, процессов и операций, необходимых для достижения поставленных перед проектом целей. Библиографический список к Лекции №2 (Тема 1): 5. Коваленок Т.П. Управление проектами: учеб. пособие - СПб. : ПГУПС, 2011. - 73 с. 6. Руководство к Своду знаний по управлению проектами. Project Management Institute (USA). - 5-е изд. - Москва: Олимп-Бизнес, 2014. – 586 с. 7. Итерационная разработка [Электронный ресурс] URL: http://dit.isuct.ru/Publish_RUP/core.base_rup/guidances/supportingmaterials/develop_iteratively_1F6AE780.html (дата обращения 22.08.2016) 8. Управление проектом разработки информационной системы [Электронный ресурс] URL: http://sergeeva-i.narod.ru/inform/page12.htm (дата обращения 22.08.2016) I СУЩНОСТЬ, ОСНОВНЫЕ ПОНЯТИЯ И ПРИНЦИПЫ УПРАВЛЕНИЯ ПРОЕКТАМИ 14. Способы организации проектной деятельности. Управление проектами осуществляется с помощью процессов, в которых применяются специальные навыки, инструменты и методы. Эта процессы можно разделить на следующие группы: • Процессы инициации, которые определяют и авторизуют проект или фазу проекта; • Процессы планирования, которые служат для определения и уточнения цели и для планирования действий, необходимых для достижения цели. «Процессная» концепция управления проектами приведена на рис. 1. Рис. 1 Классификация процессов управления проектами Под процессами понимаются действия и процедуры, связанные с реализацией функций управления. Соединение отдельных частей системы управления проектом для обеспечения её нормального функционирования представляет собой процесс организации управления проектом. Различные цели проекта на всех этапах и фазах могут быть достигнуты через функции управления проектами, такие как: планирование, контроль проекта, анализ, принятие решений, составление и сопровождение бюджета проекта, организация осуществления, мониторинг, оценка, отчетность, экспертиза, проверка и приёмка, бухгалтерский учёт, администрирование. Наука Техника Общество Экономика Политика Сфера бизнеса Организации – участницы проекта Знания и опыт по реализации проекта Зона реализации проекта Решение по управлению проектом П Р О Е К Т Персонал, участвующий в проекте Трудовые ресурсы Рынок труда Сфера законодательства Правовая зона проекта Контракты и другие правовые документы Финансирование проекта Финансовая зона Рынок капитала Знания и опыт по разработке проекта Зона разработки проекта Проектная документация Материальное хозяйство Зона закупок и поставок Рынок сырья Опыт и методы строительства Зона строительства Здания и сооружения Участок строительства Зона землепользования Рынок земли Инженерные знания и опыт Зона инжиниринга Технологический процесс Производство Производст-венная зона Рынок средств производства Продукция Зона сбыта Рынок сбыта Рис. 24 Проект и его окружение Рядовому участнику проекта, как правило, всё равно, является ли он или какой-либо объект, с которым он работает, его частью или нет, однако для руководителей проекта и организации в целом данный вопрос – один из ключевых для успешной работы. 15. Офис управления проектами (ОУП). Модели ОУП. Современные методы построения ОУП. Управление проектами, как отдельная область менеджмента, продолжает набирать популярность в России и СНГ, однако уровень зрелости большинства организаций в данной области всё ещё довольно низок. И хотя успешного опыта в создании подобной структуры в России не так много, интерес к теме неустанно растёт. Для того, чтобы понять, какую пользу может принести Офис управления проектами (ОУП) и какие проблемы можно решить с его помощью, следует рассмотреть основные цели и задачи ОУП. Цели создания Офиса управления проектами Базовая цель создания проектного офиса: получение выгод от стандартизации методов, процессов и политик управления проектами. За этой простой формулировкой на самом деле стоит достаточно большой большой набор выгод, который, который потенциально можно получить. Ниже список некоторых из них: • Эффективность распределения ресурсов и снижение издержек. ОУП координирует и распределяет ресурсы между проектами, что позволяет избежать конфликтов между проектами. Также Офис управления проектами позволяет оптимизировать ресурсы и сократить их количество, а, следовательно, и снизить затраты. • Поддержание методологии. Унификация процессов, общие метрики и показатели эффективности обеспечивают прозрачность в управлении проектами, позволяют снизить оперативные издержки и уберегают компанию от многих внутренних конфликтных ситуаций. Унификация и прозрачность позволяют лучше прогнозировать деятельность компании в части реализации проектов. • Соответствие стратегии. Сбалансированный портфель проектов, составленный в соответствии со стратегией компании позволяет чётко следовать к поставленным целям. • Обучение сотрудников и распространение проектной культуры в организации. Обучение сотрудников проектному управлению позволяет повысить производительность персонала и компании в целом. Наличие единого центра этого обучения в части проектного управления, а также единой методологии и концентрация информации в одном месте упрощают этот процесс. • Концентрация информации. Концентрация информации по проектам в одном месте позволяет сократить издержки на управление, повысить качество анализа информации, выявить причины перерасходов и отклонений. Основные задачи Офиса управления проектами Для достижения вышеупомянутых выгод от внедрения управления проектами, перед Офисом управления проектами встают четыре основные группы задач. • Методологическая. Разработка методологии управления проектами, внедрение, развитие, поддержка и контроль использования. • Административная. Административная поддержка процессов проектного управления, контроль реализации проектов и формирование отчетности, управление и администрирование проектов, координация ресурсов, поддержка работы Проектного комитета. • Образовательная. Обучение сотрудников компании проектному управлению, развитие проектной культуры • Технологическая. Внедрение информационной системы проектного управления, ее поддержка и развитие. Эти функции, в той или иной степени присущи каждому Офису управления проектами. В зависимости от того, какой результат планируется получить, состав этих функций будет меняться для разных моделей ОУП. Рассмотрим основные модели Офиса управления проектами. Модели Офиса управления проектами Модель «проектной канцелярии» или «репозитория». Согласно данной модели Офис управления проектами — это некий банк знаний, архив отчётности и извлечённых уроков по текущим проектам в организации. Такой Офис решает следующие задачи: • Унификация проектной отчётности. • Оптимизация коммуникаций и информационных потоков. Модель «наставник». Помимо функций предыдущей модели, Офис управления проектами-«наставник» разрабатывает корпоративную методологию управления проектами, следит за её выполнением, занимается бенчмаркингом и внедрением «лучших практик». Модель «центр ответственности». В случае применения такой модели руководители проектов являются сотрудниками Офиса управления проектами. А руководитель ОУП отвечает за их реализацию, результаты, затраты. Такая модель часто встречается в компаниях с большим количеством внешних проектов, осуществляя посреднические и контрольные функции. Офис управления проектами становится в один ряд с другими функциональными подразделениями. Модель «центр прибыли». Самое большое влияние на организацию имеет Офис управления проектами с такой моделью. Его задача – составление оптимального портфеля, соотнесённого с корпоративной стратегией и обеспечение максимальной отдачи от инвестиций. Таким образом Офис управления проектами выполняет функцию координатора действий основных функциональных подразделений. Тогда основной задачей руководителя ОУП становится взаимодействие с высшим руководством и претворение стратегии в конкретные планы реализации портфеля и отдельных проектов. Результаты внедрения Офиса управления проектами Одним из основных вопросов, волнующих сейчас профессиональное сообщество – измерение и оценка эффективности офиса управления проектами. Множество противоречивых результатов получено, а в публикациях звучат голоса как за, так и против. С одной стороны, отмечают невысокий показатель возврата инвестиций (ROI) от проектной деятельности, что, чаще всего, связано с тем, что этот показатель посчитать достаточно сложно, т.к. много качественных эффектов, которые сложно перевести в количественные показатели. С другой стороны, многие сотрудники ОУП отмечают, что на практике с появлением проектного офиса доля успешных проектов возросла. В любом случае, сам факт создания ОУП во многих компаниях говорит о том, что это уже не просто мода. Офис управления проектами – не только способ снизить издержки или повысить производительность проектов. Это важнейший инструмент реализации стратегии конкретной компании. А потому его создание – стратегическая задача, требующая участия и содействия сотрудников и руководства компании. В случае успеха, Офис управления проектами позволяет получить компании конкурентное преимущество на рынке, а если речь про органы власти, то достичь стратегических целей в жестко заданные сроки. Практические вопросы организации проектного офиса Подходы к организации проектного офиса Даже если система управления проектами в компании достаточно развита (методология, информационная система, наличие выделенного проектного офиса), реализацию крупных проектов / программ (в том числе инвестиционно-строительных и программ развития) осложняет «ресурсный голод» — дефицит специалистов, способных взять на себя необходимые управленческие функции. Возможна ситуация, когда организации необходимо реализовать масштабную программу, но практикуемые управленческие подходы и конструкции довольно громоздки и негибки, что характерно для государственных органов власти. В обоих случаях решением задачи по организации общего управления программой или обеспечению выполнения хотя бы части управленческих функций, связанных с администрированием программы, может стать привлечение внешней компании. Наш опыт показывает, что решение о передаче части или всех функций проектного офиса на аутсорсинг может быть полезным для компании практически из любой отрасли. Ключевым в этом случае является обеспечение качества работы такого проектного офиса, на которое влияют опыт и подход предоставляющей аутсорсинговые услуги компании, перечень отработанных практик, используемых специалистами проектного офиса, наличие и функционал используемой проектным офисом информационной системы и другие аспекты. Возможные сложности, связанные с формированием проектных офисов При применении подходов, предусматривающих создание проектных офисов, компания может столкнуться с рядом проблем. Некоторые такие проблемы могут «жить» в организации годами, т.к. почти всегда это связано с очень болезненным разделением полномочий и зон влияния топ-менеджмента. Ниже кратко рассмотрены две наиболее характерные проблемы. Противоречия между базовым и стратегическим проектными офисами В случае одновременного выделения в организации подразделений с функциями стратегического проектного офиса и базового проектного офиса необходимо уделять особое внимание определению / разграничению их зон ответственности и выстраиванию их совместной работы. В своей практике мы не раз встречались с ситуацией, когда деятельность двух подразделений была недостаточно согласованна, что не могло не сказаться на качестве / эффективности проектной деятельности компании. Стратегический проектный офис стремится обеспечить качественную реализацию проектов портфеля (фактически, определить правила управления проектами), а базовый проектный офис — определить процедуры, необходимые для принятия решений о включении проектов в портфель, для скоординированного управления проектами (общие ресурсы, взаимоувязанные по работам / результатам проекты и пр.). В результате может произойти наложение зон ответственности двух проектных офисов. Возможным решением может стать объединение таких проектных офисов для выстраивания сквозной системы управления от портфеля до проектов. Другая разновидность проблемы — выделение наряду со стратегическим проектным офисом базовых проектных офисов в одном или нескольких функциональных подразделениях. В этом случае к описанным выше противоречиям добавляются сложности определения «своих» объектов управления (проектов, программ и портфелей). Особую остроту ситуация приобретает в том случае, когда подходы к управлению проектами стратегического проектного офиса отличаются от подходов подразделений, традиционно сильных в части управления проектами (например, IT-подразделений). Недостаток полномочий у представителей проектного офиса Достаточно распространена ситуация, когда у специалистов проектного офиса, вне зависимости от его типа, недостаточно полномочий для выполнения своих функций. Не секрет, что зачастую положение специалиста в иерархии функциональной структуры влияет на его статус сильнее, чем то, какую роль он выполняет (в том числе в рамках системы управления проектами). Это может приводить к существенному ослаблению влияния руководителя проекта на команду проекта, если, например, в нее входят руководители департаментов компании, а руководитель проекта является специалистом управленческого проектного офиса (уровень отдела), который структурно входит в другой департамент. Другой пример: специалист базового проектного офиса собирает отчетность по проектам компании, направляет запрос о предоставлении информации руководителю проекта, который может являться руководителем другого структурного подразделения. Если такой запрос не подкреплен статусной подписью, то он вполне может быть отложен до момента, «когда появится свободное время». Универсального решения здесь не существует. Тем не менее можно порекомендовать следующее. 1. Не нужно «закапывать» проектный офис, опуская его на дно оргструктуры. Лучше подчинить его одному из топ-менеджеров (например, генеральному директору или директору по развитию). 2. Проектный офис должен использовать процедуры контроля исполнительской дисциплины, формировать рейтинги по исполнению поручений, предоставлению отчетности и пр. Информация по этим рейтингам должна быть общедоступной (можно разместить ее на портале проекта). Следует включать информацию по исполнительской дисциплине в отчетность для высшего руководства, с указанием на возможную недостоверность данных по проектам, которая обусловлена недостаточной исполнительской дисциплины. 3. Необходимо учитывать в системе мотивации факторы, связанные с исполнительской дисциплиной, причем такая форма дополнительной проектной мотивации может существовать вне общей корпоративной системы мотивации. Активы проектного офиса По какой схеме ни был бы организован проектный офис, качество его работы и, в конечном итоге, польза, приносимая им, во многом зависят от компетенций его специалистов и используемых инструментов управления. Под инструментами можно понимать информационные системы, отработанные на многих проектах подходы к реализации отдельных процедур или методические решения. В табл. 3 дано краткое описание некоторых инструментов. Их перечень может показаться довольно очевидным, однако они приносят реальную пользу участникам проектов и способствуют их успешной реализации. Проектный офис, организованный как структурная единица компании, как правило, с течением времени формирует свой набор инструментов, а проектный офис, организованный по аутсорсинговой схеме, должен привнести в компанию свой опыт и свои инструменты, обеспечив тем самым быстрый запуск и качество управленческих процедур. Таблица 3. Наиболее востребованные инструменты проектного офиса Инструменты Описание Информационная система(IT-решение, обеспечивающее поддержку планирования,  отчетности, информирования, анализа и пр.) Может быть решением с разным функциональным наполнением. Для быстрого решения базовых задач можно ограничиться интегрированными с системами календарного планирования интернет- и/или интранет-порталом, посредством которого обеспечиваются процессы планирования и мониторинга проекта / программы. Позволяет ключевым участникам проектов / программ «видеть» актуальную информация в удобном для анализа и принятия решений виде. Система контроля исполнения поручений Несистемный инструмент управления проектом, позволяющий «включать» «ручной» режим управления для решения оперативных вопросов. Основные интересанты — высшее руководство. Позволяет фиксировать поручения, вести историю соответствующих документов, контролировать исполнение, проводить анализ исполнения в различных разрезах. Система управления совещаниями Система, регулирующая процедуры и правила подготовки и проведения совещаний по проекту / программе. Включает шаблоны ключевых документов (повестка, материалы к совещанию, протокол и пр.). Полезность может быть увеличена в случае применения совместно с системой контроля исполнения поручений   Система показателей и модель оценки достижения целей проекта / программы  на основе фактических данных Способствует соблюдению критерия полноты при планировании перечня мероприятий. Позволяет соотнести выполняемые мероприятия с достижением целей проекта. Обеспечивает возможность построения прогнозов по достижению целей проекта с учетом данных о фактической реализации мероприятий и критичности возникающих отклонений Разноуровневое планирование(формирование  календарных планов с детализацией, соответствующей уровню контроля) Подход, предусматривающий формирование системы взаимосвязанных иерархических планов (например, директивного плана, рабочих планов и координационного плана). Позволяет (за счет мониторинга исполнения рабочих планов и использования координационного плана) выявлять проблемы по ключевым аспектам (директивный план) на ранних этапах Требует затрат временных ресурсов на формирование, регулярную актуализацию и мониторинг рабочих (детальных) планов. Шаблоны основных документов: календарные  планы, формы для сбора отчетности, для работы с рисками и проблемами Инструмент, обеспечивающий и облегчающий решение задач планирования, сбора отчетности и др. Позволяет ускорить и унифицировать формирование планов по проектам, обеспечивает такую структуру отчетности, при которой возможны различные уровни детализации сведений Методические рекомендации по разработке календарных планов (на основе шаблонов) Позволяют участникам быстро понять подходы к процессам календарного планирования, повысить качество формируемых планов и снизить нагрузку на проектный офис в части поддержки процесса календарного планирования Система аналитических отчетов Содержит информацию в «свернутом» (агрегированном) виде. Позволяет видеть проблемы и переходить от одного уровня детализации данных к другому (Drill down / Drill up). Должна иметь как IT-, так и документарную реализацию (не путать с электронными (файлами) и бумажными документами) Система развития специалистов проектного офиса Представляет собой, в том числе: • сформированные требования к компетенциям, навыкам, знаниям специалистов проектных офисов; • набор программ обучения практического характера (примеры реальных проектов, кейсы, работа в группах и пр.); участниками могут быть как действующие специалисты проектного офиса, так и специалисты, включаемые в работу проектного офиса при его расширении Сервисный подход к организации и оценке проектного офиса Базовый проектный офис, являющийся, по сути, сервисным подразделением, обеспечивающим разностороннюю поддержку процессов управления проектами, а также информационную поддержку руководителей проектов / программ и руководства компании, изначально можно формировать по сервисно-ориентированной модели. Так, сервисами, оказываемыми проектным офисом, могут быть: • управление бюджетом и контрактами на уровне проекта / программы; • управление рисками; • управление ресурсами; • административная поддержка деятельности ключевых руководителей; • контроль исполнения поручений; • контроль хода реализации проектов и программ; • управление изменениями; • организация совещаний; • обеспечение коммуникаций; • методологическая поддержка и контроль качества. В случае реализации сервисной модели работу проектного офиса должны оценивать потребители услуг. При этом фактически оценивается уровень предоставляемого сервиса. Такая оценка для проектного офиса, созданного своими силами, может отражаться в KPI. Если проектный офис организован по аутсорсинговой схеме, оценка может влиять на размер вознаграждения или на решение о продолжении сотрудничества. Один из возможных подходов к оценке уровня оказываемого сервиса заключается в определении для каждого сервиса / услуги показателей трех типов (см. табл. 4).  Таблица 4. Возможные критерии оценки уровня предоставляемого проектным офисом сервиса  Критерии оценки Описание Количественные Определяют объем работ, используются для расчета планируемых и  фактических трудозатрат и определения затратной стоимости сервиса Качественные Определяют качество процесса (своевременность, скорость выполнения,  наличие критических инцидентов, соблюдение регламентов и пр.).  Могут влиять на KPI или стоимость аутсорсинговых услуг. Ухудшение характеристик (по сравнению с плановыми) может привести к  невыполнению KPI или снижению размера вознаграждения. Улучшение характеристик может потребовать увеличения затрат на предоставление сервиса Индикативные Определяют удовлетворенность ключевых участников проектной деятельности  и руководства организации. Не влияют на KPI и размер вознаграждения, их используют для корректировки процесса Подводя итог описанию различных форм организации проектных офисов, еще раз отметим, что проектный офис является довольно универсальным инструментом, позволяющим обеспечить поддержку проектной деятельности в любой компании. Применение этого инструмента может быть полезно как в коммерческих организациях, так и в органах государственной власти, как в компании с высоким уровнем зрелости КСУП (корпоративной системы управления проектами), так и в процессно-ориентированной компании. В любом случае, создание проектного офиса помогает упорядочить проектную деятельность, повышает эффективность работы всех участников проектов, может служить катализатором развития КСУП и способствовать развитию бизнеса. Предложенная в статье классификация, приведенное описание функций проектных офисов разных типов и особенностей их работы, рассмотренные через призму задач конкретной организации, могут оказаться полезными при определении наиболее подходящих типа проектного офиса и стратегии его создания / развития. 16. Заинтересованные стороны проекта. Определение ключевых участников проекта. Личностные характеристики менеджера проекта. Заинтересованные стороны проекта Заинтересованные стороны проекта - это лица или организации (например, заказчики, спонсоры, исполняющая организация или общественность), которые активно участвуют в проекте или интересы которых могут быть затронуты как положительно, так и отрицательно в ходе исполнения или в результате завершения проекта. Заинтересованные стороны проекта также могут оказывать влияние на проект, его результаты и на членов команды проекта. Команда управления проектом должна выявить как внутренних, так и внешних заинтересованных сторон проекта, чтобы определить требования, предъявляемые к проекту, и ожидания всех вовлеченных сторон. Кроме того, менеджер проекта должен управлять влиянием различных заинтересованных сторон проекта в связи с требованиями, предъявляемыми к проекту, чтобы обеспечить успешное получение результата. На рис. 25 показана взаимосвязь между проектом, командой проекта и другими обычными заинтересованными сторонами проекта. Рис. 25. Взаимосвязь между заинтересованными сторонами проекта и проектом Заинтересованные стороны проекта имеют разные степени ответственности и полномочий при участии в проекте, которые могут меняться на протяжении жизненного цикла проекта. Их ответственность и полномочия могут варьироваться от периодического участия в опросах и целевых группах до полного спонсорства проекта, включающего предоставление финансовой и политической поддержки. Заинтересованные стороны проекта могут оказывать неблагоприятное влияние на цели проекта. Выявление заинтересованных сторон проекта является непрерывным и зачастую трудоемким процессом. Например, можно доказать, что рабочий линии сборки, чья будущая занятость зависит от результата проекта по проектированию нового продукта, является заинтересованной стороной проекта. Выявление заинтересованных сторон проекта и понимание относительной степени их влияния на проект является критически важной задачей. Невыполнение этой задачи может существенно увеличить сроки и повысить стоимость. Примером может являться позднее выяснение того, что юридический отдел является важной заинтересованной стороной проекта, что приводит к задержкам и росту затрат в связи с правовыми ограничениями. Проект может восприниматься заинтересованными сторонами как имеющий и положительные, и отрицательные результаты. Некоторые заинтересованные стороны проекта могут выиграть от успешного завершения проекта, тогда как для других заинтересованных сторон проекта могут наступить в результате его успеха негативные последствия, например руководители ведущих предприятий района останутся в выгоде после завершения проекта промышленного развития, который положительно отразится на экономике района. В случае, когда заинтересованные стороны проекта питают положительные ожидания в отношении проекта, в их интересах будет содействовать его успешному выполнению. Интересы отрицательно настроенных заинтересованных сторон проекта препятствуют выполнению проекта. Неспособность заметить отрицательно настроенных заинтересованных сторон проекта может привести к увеличению вероятности неудачи. Важной составляющей обязанностей менеджера проекта является управление ожиданиями заинтересованных сторон проекта. Это может быть трудной задачей, поскольку зачастую заинтересованные стороны проекта преследуют очень разные или конфликтующие цели. Одной из обязанностей менеджера проекта является поддержание баланса между этими интересами и обеспечение того, чтобы команда проекта взаимодействовала с заинтересованными сторонами проекта профессионально и с позиций сотрудничества. Ниже представлены некоторые примеры заинтересованных сторон проекта. • Заказчики/пользователи. Заказчики/пользователи - это лица или организации, которые будут пользоваться продуктом, услугой или результатом проекта. Заказчики/пользователи могут быть внутренними и/или внешними по отношению к исполняющей организации. Также может существовать несколько уровней заказчиков. Например, в число заказчиков нового фармацевтического продукта могут входить назначающие его врачи, использующие его пациенты и оплачивающие его страховые компании. В некоторых прикладных областях заказчики и пользователи являются синонимами, тогда как в других под заказчиками подразумеваются органы, приобретающие продукт проекта, а под пользователями - те, кто непосредственно будет его использовать. • Спонсор. Спонсор - это лицо или группа лиц, которые предоставляют финансовые ресурсы (наличными или в любом другом виде) для проекта. Когда впервые возникает замысел проекта, спонсор поддерживает его. Сюда входит выступление в роли представителя перед руководством более высокого уровня, чтобы заручиться поддержкой по всей организации и содействовать получению выгод, которые принесет проект. Спонсор сопровождает проект на протяжении процесса вхождения в контакт и отбора до получения официального одобрения и играет важную роль в разработке первоначального содержания и устава. В решении вопросов, лежащих за пределами компетенции менеджера проекта, спонсор выступает в качестве источника расширения возможностей. Кроме того, спонсор также может участвовать в других важных вопросах, таких как одобрение изменений в содержании, завершающий анализ фазы и принятие решений «годен - не годен», когда риски особенно велики. • Менеджер портфеля/комиссия по рассмотрению портфеля. Менеджеры портфеля отвечают за управление на высоком уровне набором проектов или программ, которые могут как зависеть, так и не зависеть друг от друга. Комиссии по рассмотрению портфелей - это комитеты, состоящие, как правило, из должностных лиц организации, которые выступают в качестве отборочной комиссии проекта. Они рассматривают каждый проект с точки зрения его рентабельности, ценности, рисков, связанных с выполнением проекта, и других аспектов проекта. • Менеджеры программ. Менеджеры программ отвечают за управление связанными друг с другом проектами, координируя действия для достижения преимуществ и степени управляемости, недоступных при управлении ими по отдельности. Менеджеры программ взаимодействуют со всеми менеджерами проектов для предоставления поддержки и выдачи приказов по отдельным проектам. • Офис управления проектами. Офис управления проектами (Project Management Office, PMO) - это подразделение организации или орган, осуществляющий различные функции, относящиеся к централизации и координации управления проектами, входящими в его компетенцию. Функции PMO могут варьироваться от предоставления поддержки в управлении проектами до фактического несения ответственности за непосредственное управление проектом. PMO может являться заинтересованной стороной проекта, если он несет прямую или косвенную ответственность за результат проекта. PMO может обеспечивать, среди прочего: • административную поддержку (например, правила, методологии и шаблоны); • обучение, наставничество и инструктирование менеджеров проектов; • поддержку проекта, руководящие указания и обучение управлению проектами и использованию инструментов; • корректировку ресурсов персонала проекта; и/или • централизованный обмен информацией между менеджерами проектов, спонсорами проектов, менеджерами и другими заинтересованными сторонами проекта. • Менеджеры проектов. Менеджеры проектов назначаются исполняющей организацией для достижения целей проекта. Это заметная роль, требующая серьезных усилий, которая подразумевает большую долю ответственности и изменение приоритетов. Она требует гибкости, осмотрительности, сильных лидерских качеств и умения договариваться, а также солидного знания практики управления проектами. Менеджер проекта должен быть способен понимать проект до мелочей, но при этом управлять им, исходя из комплексного видения проекта. Являясь лицом, несущим ответственность за успех проекта, менеджер проекта руководит всеми аспектами проекта, включая, среди прочего: • разработку плана управления проектом и всех сопутствующих составляющих планов; • обеспечение надлежащего выполнения проекта с точки зрения сроков и бюджета; • обнаружение, наблюдение и реагирование на возникающие риски; • предоставление своевременной и точной отчетности по системе показателей проекта. Менеджер проекта является ведущим лицом, отвечающим за обмен информацией со всеми заинтересованными сторонами проекта, в частности со спонсором проекта, командой проекта и другими ключевыми заинтересованными сторонами проекта. Менеджер проекта находится в центре взаимодействий между заинтересованными сторонами проекта и самим проектом. • Команда проекта. Команда проекта состоит из менеджера проекта, команды управления проектом и остальных членов команды, которые выполняют работу, но не обязательно участвуют в управлении проектом. Данная команда состоит из представителей различных групп, обладающих знаниями в конкретной предметной области или набором конкретных навыков и выполняющих работу по проекту. • Функциональные руководители. Функциональные руководители являются ключевыми лицами, играющими руководящую роль в рамках административной или функциональной области предприятия, такой как отдел кадров, финансовый отдел, бухгалтерия или отдел поставок. Им выделяется собственный постоянный персонал для выполнения текущих работ, и они имеют четкие указания управлять всеми задачами в рамках своей функциональной области ответственности. Функциональный руководитель может предоставлять экспертную помощь в предметной области, или его функцией может являться предоставление услуг для проекта. • Управление операциями. Менеджеры по операциям - это лица, выполняющие управляющую роль в основной области деятельности предприятия, например, в области исследований и разработок, проектирования, производства, подготовки к работе, испытаний или технического обслуживания. В отличие от функциональных руководителей, эти менеджеры имеют дело непосредственно с производством и обслуживанием реализуемых продуктов и услуг предприятия. В зависимости от типа проекта формальный переход происходит при завершении, чтобы передать техническую документацию по проекту и другие документы постоянного хранения в руки представителей соответствующей группы управления операциями. Затем группа управления операциями включит переданный проект в число стандартных операций и обеспечит ему долговременную поддержку. • Продавцы/деловые партнеры. Продавцы, также называемые агентами, поставщиками или подрядчиками, - это сторонние компании, заключившие договор на предоставление компонентов или услуг, необходимых для проекта. Деловые партнеры также являются сторонними компаниями, но они имеют с предприятием особую связь, иногда приобретенную посредством процедуры сертификации. Деловые партнеры предоставляют специализированную экспертную помощь или играют отведенную им роль, например, осуществляют установку, настройку в соответствии с требованиями пользователя, обучение или поддержку. В контексте проектного управления перечень и характеристики заинтересованных сторон - ключевых участников проекта можно найти в Своде знаний об управлении проектами PMBoK: менеджер проекта; заказчик/пользователь; исполняющая организация; члены команды проекта; команда управления про­ектом; спонсор; офис управления проектом (PMO). Совместим два перечня заинтересованных сторон проекта, разделив их на внутренние и внешние, и выявим их ключевые интересы. На проект влияют: • его внутренние заинтересованные стороны, которые непосредственно уча­ствуют в реализации проекта (менеджер проекта, команда управления про­ектом, члены команды проекта, офис управления проектами при его наличии, инвесторы проекта, поставщики проекта); • внешнее окружение проекта, внутренняя среда компании, в рамках которой реализуется проект (кредиторы компании, акционеры компании, менеджмент компании, бизнес-партнеры компании, сотрудники компании, будущие поко­ления, прошлые поколения, представители заинтересованных сторон, вну­трикорпоративные потребители);внешнее окружение компании, все бизнес окружение, в котором функцио­нирует организация (внешние потребители, местное сообщество, СМИ, общество в целом, научное сообщество, конкуренты, гражданское общество, органы государственной власти). Для каждой группы лиц, относящихся к заинтересованным странам про­екта, можно определить их основные интересы (см. табл. 5). Таблица 5 Основные заинтересованные стороны проекта и их интересы Наименование стейкхолдера Основные интересы стейкхолдера 1 2 Внутренние заинтересованные стороны проекта Менеджер проекта Выполнение проекта Достижение целевых показателей проекта Карьерный рост Команда управления проектом Достижение целевых показателей проекта Карьерный рост Члены команды проекта Будущая защищенность их рабочих мест Рост заработной платы Карьерный рост Офис управления проектами Сохранение баланса портфеля проектов Достижение целевых KPI Инвесторы проекта Получение запланированной доходности проекта Поставщики проекта Выполнение взятых на себя обязательств Четкая постановка технического задания Внутрикорпоративные заинтересованные стороны проекта Кредиторы компании Своевременная выплата обязательств Сохранение текущего уровня риска, выраженного в целевых показателях Акционеры компании Рост доходности компании Рост дивидендных выплат Рост стоимости компании Менеджмент компании Достижение компанией целевых показателей KPI Рост размера компенсации Сохранение текущего положения Развитие компании Бизнес партнеры компании Сохранение долгосрочных отношений с компанией Прочие сотрудники компании Рост заработной платы Сохранение рабочих мест Карьерный рост Будущие поколения Создание потенциала для развития компании в будущем Прошлые поколения Сохранение преемственности стратегии Представители заинтересованных сторон Улучшение положения подопечных заинтересованных сторон Внутрикорпоративные потребители Выполнение поставленного технического задания точно в срок Упрощение ведения деятельности Внешние заинтересованные стороны проекта Внешние потребители Удовлетворение потребностей Местное сообщество Сохранение окружающей среды Модернизация окружающего пространства СМИ Создание информационных поводов Общество в целом Улучшение текущего положения Научное сообщество Получение материалов для проведения исследований Конкуренты Рост их доли на рынке Рост их капитализации Гражданское общество Защита интересов граждан Развитие института гражданского общества Органы государственной власти Выполнение требований органов государственной власти Увеличение размера отчислений в бюджет Поддержка реализуемой стратегии развития Роль менеджера проекта Менеджер проекта - это лицо, назначаемое исполняющей организацией ответственным за достижение целей проекта. Роль менеджера проекта отличается от роли функционального менеджера или операционного менеджера. Как правило, функциональный менеджер сосредоточен на обеспечении надзора за некоей зоной управления, а операционные менеджеры несут ответственность за определенное направление основной деятельности компании. В зависимости от структуры организации менеджер проекта может подчиняться функциональному менеджеру. В других случаях менеджер проекта может быть одним из нескольких менеджеров проектов, подотчетных менеджеру портфеля или программы, который несет ответственность за проекты в масштабах предприятия. В структуре такого типа менеджер проекта тесно сотрудничает с менеджером портфеля или программы для достижения целей проекта и обеспечения соответствия плана проекта комплексному плану программы. Многие инструменты и методы управления проектами специфичны для управления проектами. Тем не менее, понимание и применение знаний, инструментов и методов, признанных в качестве хорошей практики, недостаточно для эффективного управления проектами. В дополнение к специальным навыкам и знанию общего менеджмента, необходимым для проекта, эффективное управление проектами требует наличия у менеджера проекта следующих характеристик: .1 Знания. Это относится к тому, что менеджер знает об управлении проектами. .2 Результативность. Это относится к тому, что менеджер способен сделать или достичь, применяя свои знания об управлении проектами. .3 Личные качества. Это относится к тому, как менеджер проекта ведет себя во время выполнения проекта или связанной с ним деятельности. Личная эффективность охватывает установки, основные личностные характеристики и лидерские качества - способность управлять командой проекта при достижении целей проекта и уравновешивании ограничений проекта. Библиографический список к Лекции №1 (Тема 1): 9. Коваленок Т.П. Управление проектами: учеб. пособие - СПб. : ПГУПС, 2011. - 73 с. 10. Руководство к Своду знаний по управлению проектами. Project Management Institute (USA). - 5-е изд. - Москва: Олимп-Бизнес, 2014. – 586 с. 11. Офис управления проектами как инструмент повышения эффективности организации. 2015. [Электронный ресурс] URL: http://www.pmservices.ru/project-management-news/ofis-upravleniya-proektami-kak-instrument-povysheniya-effektivnosti-organizacii/ (дата обращения 22.08.2016) 12. Козодаев М. Практика построения проектных офисов (Часть 2). 2013. [Электронный ресурс] URL: http://pmpractice.ru/knowledgebase/publications/?id=1618&detail=Y (дата обращения 22.08.2016) II Группы процессов управления проектами и их взаимодействие 1. Основные положения Управление проектом — это приложение знаний, навыков, инструментов и методов к работам проекта для удовлетворения требований, предъявляемых к проекту. Это приложение знаний требует результативного управления процессами управления проектом. Процесс — это набор взаимосвязанных действий и операций, осуществляемых для создания заранее определенного продукта, услуги или результата. Каждый процесс характеризуется своими входами (основными исходными данными), инструментами и методами, которые могут быть применены, а также результирующими выходами. Для того чтобы проект оказался успешным, его команда должна: • выбрать те процессы, которые необходимы для достижения целей проекта; • использовать определенный подход, который может быть применен для удовлетворения требований; • устанавливать и поддерживать соответствующие коммуникации с заинтересованными сторонами и их вовлечение; • обеспечивать соответствие требованиям, чтобы удовлетворить потребности и ожидания заинтересованных сторон; • находить баланс между конкурирующими ограничениями содержания, расписания, бюджета, качества, ресурсов и рисков, чтобы произвести заданный продукт, услугу или результат. В целом, процессы проекта можно разделить на две основные категории: • Процессы управления проектом. Эти процессы обеспечивают результативное исполнение проекта в течение его жизненного цикла. Эти процессы охватывают инструменты и методы, связанные с применением навыков и возможностей, описанных в областях знаний. • Процессы, ориентированные на продукт. Эти процессы определяют и создают продукт проекта. Процессы, ориентированные на продукт, обычно определяются жизненным циклом проекта и различаются в зависимости от прикладной области, а также от фазы жизненного цикла продукта. Содержание проекта не может быть определено без некоторого базового понимания того, как создать заданный продукт. Например, при определении общей сложности здания, которое необходимо построить, следует учитывать разнообразные строительные технологии и инструменты. Процессы управления проектом и процессы, ориентированные на продукт, накладываются и взаимодействуют в течение жизненного цикла проекта. Процессы управления проектом применяются по всему миру и во всех группах отраслей. Руководители проектов и их команды должны тщательно исследовать каждый процесс и присущие ему входы (основные исходные данные) и выходы (основные результаты) и определять, какие процессы применимы к проекту, над которым они работают. Управление проектом — интегративная деятельность, требующая, чтобы каждый процесс, относящийся к проекту и продукту, был надлежащим образом приведен в соответствие и взаимосвязан с другими процессами для облегчения координации. Действия, предпринимаемые во время одного процесса, обычно влияют на этот процесс и прочие связанные с ним процессы. Например, изменение содержания обычно влияет на стоимость проекта, но может и не оказать влияния на план управления коммуникациями или уровень риска. Эти взаимодействия процессов часто требуют поиска компромиссов между требованиями и целями проекта; кроме того, определенные компромиссы в исполнении будут различаться от проекта к проекту и от организации к организации. Успешное управление проектом должно включать в себя активное управление этими взаимодействиями, чтобы удовлетворить требования спонсора, заказчика и прочих заинтересованных сторон. При некоторых условиях процесс или набор процессов необходимо повторить несколько раз, чтобы достичь требуемого конечного результата. Проекты существуют в рамках организации и не функционируют в качестве закрытой системы. Они требуют наличия входных данных из организации и извне, а в ответ они предоставляют организации новые возможности. Процессы проекта могут создавать информацию, чтобы улучшить управление будущими проектами и активами процессов организации. Процессы управления проектом разделяются на пять категорий, известных как группы процессов управления проектом (или группы процессов): • Группа процессов инициации. Процессы, выполняемые для определения нового проекта или новой фазы существующего проекта путем получения авторизации на начало проекта или фазы. • Группа процессов планирования. Процессы, требуемые для установления содержания работ, уточнения целей и определения направления действий, требуемых для достижения целей проекта. • Группа процессов исполнения. Процессы, применяемые для выполнения работ, указанных в плане управления проектом, с целью соответствия спецификациям проекта. • Группа процессов мониторинга и контроля. Процессы, требуемые для отслеживания, анализа, а также регулирования исполнения проекта; выявления областей, требующих внесения изменений в план; и инициирования соответствующих изменений. • Группа процессов закрытия. Процессы, выполняемые для завершения всех операций в рамках всех групп процессов в целях формального закрытия проекта или фазы. 2. Общие взаимодействия процессов управления проектом Процессы управления проектом представлены в качестве дискретных процессов с определенными границами. Однако на практике они накладываются друг на друга и взаимодействуют такими способами. Наиболее опытные специалисты-практики в области управления проектами признают, что существует более чем один способ управления проектом. Требуемые группы процессов и составляющие их процессы являются руководством для применения подходящих знаний и навыков управления проектом при реализации проекта. Применение процессов управления проектом итеративно, и многие процессы в ходе проекта повторяются. Интегративный характер управления проектом требует, чтобы группа процессов мониторинга и контроля взаимодействовала с другими группами процессов, как показано на рис. 1. Процессы мониторинга и контроля осуществляются в то же самое время, что и процессы, входящие в другие группы процессов. Таким образом, на рис. 1 процесс мониторинга и контроля изображен как «фоновая» группа процессов для других четырех групп. Рис. 1 Группы процессов управления проектом Группы процессов управления проектом связаны посредством выходов, которые они производят. Группы процессов редко бывают дискретными или однократными событиями; они происходят на протяжении всего проекта и накладываются друг на друга. Выход одного процесса, как правило, становится входом для другого процесса или является поставляемым результатом проекта, подпроекта или фазы проекта. Поставляемые результаты на уровне подпроекта или проекта можно назвать инкрементными поставляемыми результатами. Группа процессов планирования предоставляет группе процессов исполнения план управления проектом и документы проекта, по мере развития проекта она обычно создает обновления для плана управления проектом и документов проекта. Рис. 2 демонстрирует, каким образом взаимодействуют группы процессов, и показывает степень наложения в различные моменты. Если проект разделен на фазы, группы процессов взаимодействуют в рамках каждой фазы. Примером подобного взаимодействия может служить завершение фазы проектирования, требующее приемки спонсором проектной документации. После этого проектная документация предоставляет описание продукта группам процессов планирования и исполнения в одной или нескольких последующих фазах. Когда проект разделен на фазы, надлежащее использование групп процессов способствует тому, чтобы проект был результативно доведен до завершения контролируемым образом. В проектах, состоящих из нескольких фаз, процессы повторяются в рамках каждой фазы, пока не будут выполнены критерии завершения фазы. II Группы процессов управления проектами и их взаимодействие 1 Группы процессов управления проектом Следующие разделы определяют и описывают пять групп процессов управления проектом, являющихся обязательными для каждого проекта. Эти пять групп процессов достаточно четко взаимосвязаны и обычно выполняются в каждом проекте, тесно взаимодействуя друг с другом. Они не зависят от прикладной области или конкретной отрасли. Отдельные группы процессов и отдельные процессы часто повторяются вплоть до окончания проекта и могут взаимодействовать в рамках группы процессов или с другими группами процессов. Суть данных взаимодействий различается от проекта к проекту и может проявляться или не проявляться в определенном порядке. Блок-схема процессов на рис. 3 кратко описывает основные зависимости и взаимодействия групп процессов и конкретных заинтересованных сторон. Процессы управления проектом связаны соответствующими входами и выходами, причем результат или выход одного процесса становится входом для другого, но не обязательно в одной группе процессов. Группы процессов не являются фазами жизненного цикла проекта. Фактически, все группы процессов могут быть осуществлены в течение одной фазы. Так как проекты разделены на отдельные фазы или подкомпоненты, такие как разработка концепции, анализ целесообразности, проектирование, прототипирование, создание, тестирование и т. д., все группы процессов обычно повторяются для каждой фазы или подкомпонента. Процессы управления проектом показаны в той группе процессов, в которой происходит большая часть их действия. Например, процесс, который обычно происходит в фазе планирования, отнесен к группе процессов планирования. Если подобный процесс обновлен процессом или действием группы процессов исполнения, он не считается новым процессом в группе процессов исполнения, а все еще является процессом или действием группы процессов планирования. Итеративный характер управления проектом означает, что процессы из любой группы могут быть повторно использованы на протяжении всего жизненного цикла проекта. Например, в ответ на событие риска процесс реагирования на риски может запустить дальнейший анализ, который вызывает другую итерацию процесса идентификации рисков и соответствующие процессы количественного и качественного анализа рисков для оценки воздействия. Рис. 3-3. Взаимодействия процессов управления проектом 2 Группа процессов инициации Группа процессов инициации состоит из процессов, выполняемых для определения нового проекта или новой фазы существующего проекта путем получения авторизации на начало проекта или фазы. В рамках процессов инициации определяется изначальное содержание и выделяются изначальные финансовые ресурсы. Определяются внутренние и внешние заинтересованные стороны, которые будут взаимодействовать и влиять на общий результат проекта. Выбирается руководитель проекта, если он еще не назначен. Данная информация закрепляется в уставе проекта и в реестре заинтересованных сторон. После утверждения устава проекта считается, что проект официально авторизован. Хотя команда управления проектом может оказывать помощь в написании устава проекта, данный стандарт предполагает, что оценка бизнес-кейса, утверждение и финансирование происходит за рамками проекта (рис. 4). Граница проекта определяется как точка во времени, в которой авторизован старт или завершение проекта или фазы проекта. Ключевая цель данной группы процессов — привести в соответствие между собой ожидания заинтересованных сторон и цель проекта, дать заинтересованным сторонам наглядное представление о содержании и целях, а также показать то, каким образом их участие в проекте и связанных с ним фазах может обеспечить удовлетворение их ожиданий. Данные процессы помогают определить видение проекта — что необходимо выполнить. Большие сложные проекты следует разделять на отдельные фазы. В подобных проектах процессы инициации выполняются в последующих фазах для подтверждения решений, принятых во время изначальных процессов разработки устава проекта и определения заинтересованных сторон. Проведение процессов инициации в начале каждой фазы помогает поддерживать ориентацию проекта на бизнес-потребность организации, ради удовлетворения которой он был предпринят. Проводится проверка критериев успеха, а также обзор влияния, побудительных мотивов и целей заинтересованных сторон проекта. Затем принимается решение, должен ли проект быть продолжен, приостановлен или отменен. Вовлечение спонсоров, заказчиков и прочих заинтересованных сторон в ходе инициации дает общее понимание критериев успеха, уменьшает накладные расходы на вовлечение и в целом повышает вероятность приемки поставляемых результатов, а также удовлетворения заказчиков и других заинтересованных сторон. Процессы инициации могут выполняться на уровне организации, программы или портфеля и в этом случае являются внешними по отношению к уровню управления проектом. Например, до начала проекта может быть документально определена необходимость в требованиях высокого уровня в рамках более масштабной организационной инициативы. Целесообразность нового начинания может быть установлена в процессе оценки альтернатив. Могут быть разработаны четкие описания целей проекта, включая причины, объясняющие, почему конкретный проект является лучшей альтернативой для удовлетворения требований. Документация по поводу данного решения также может содержать первоначальное описание содержания проекта, информацию о поставляемых результатах, длительности проекта и прогноз по ресурсам для проведения организацией инвестиционного анализа. В рамках процессов инициации руководитель проекта получает полномочия применять ресурсы организации для последующих операций проекта. 3 Группа процессов планирования Группа процессов планирования состоит из процессов, выполняемых для определения общего содержания работ, постановки и уточнения целей и разработки последовательности действий, требуемых для достижения данных целей. Процессы планирования разрабатывают план управления проектом и документы проекта, которые будут использованы для выполнения проекта. Комплексный характер управления проектом может потребовать использования повторяющихся циклов обратной связи для дополнительного анализа. По мере поступления и осмысления большего объема информации или характеристик проекта, скорее всего, потребуется дополнительное планирование. Значительные изменения, происходящие на протяжении жизненного цикла проекта, приводят к необходимости вновь вернуться к одному или нескольким процессам планирования, а, возможно, и к некоторым процессам инициации. Такая последовательная детализация плана управления проектом называется последовательным уточнением, что указывает на то, что планирование и документирование — повторяющиеся и продолжающиеся процессы. Ключевая выгода данной группы процессов — определение стратегии и тактики, а также последовательности действий или пути для успешного завершения проекта или фазы. При хорошем управлении группой процессов планирования намного проще заручиться поддержкой заинтересованных сторон и повысить их вовлеченность. Данные процессы описывают, каким образом это будет осуществляться и приведет к достижению желаемой цели. План управления проектом и документы проекта, разрабатываемые как выходы группы процессов планирования, описывают все аспекты содержания, сроков, стоимости, качества, коммуникаций, человеческих ресурсов, рисков, закупок и вовлечения заинтересованных сторон. Обновления, возникающие вследствие одобренных изменений во время проекта (обычно во время процессов мониторинга и контроля, и особенно во время процесса руководства и управления работами проекта), могут значительно влиять на части плана управления проектом и документы проекта. Обновления данных документов уточняют расписание, стоимость и ресурсные требования, необходимые для исполнения определенного содержания проекта. Команда проекта собирает мнения заинтересованных сторон и способствует их вовлечению в планирование проекта и разработку плана управления проектом и документов проекта. Так как процесс получения обратной связи и уточнения документов не может длиться неопределенно долго, установленные организацией процедуры диктуют, когда должно закончиться первоначальное планирование. На данные процедуры влияют характер проекта, установленные границы проекта, соответствующие действия по мониторингу и контролю, а также внешняя среда, в которой реализуется проект. Прочие взаимодействия между процессами в рамках группы процессов планирования зависят от характера проекта. Например, в некоторых проектах практически невозможно идентифицировать риски, пока не будут проведены значительные работы по планированию. В этот момент команда может установить, что цели по стоимости и расписанию излишне жесткие и влекут за собой гораздо большие риски, чем можно было предположить ранее. Результаты таких итераций документируются в виде обновлений плана управления проектом или различных документов проекта. 4 Группа процессов исполнения Группа процессов исполнения состоит из процессов, выполняемых для исполнения работ, указанных в плане управления проектом, с целью соответствия спецификациям проекта. Эта группа процессов включает в себя координацию людей и ресурсов, управление ожиданиями заинтересованных сторон, а также интеграцию и выполнение операций проекта в соответствии с планом управления проектом. Во время исполнения проекта результаты могут потребовать внесения обновлений в план и принятия новых базовых планов. Обновления могут включать в себя изменения в ожидаемой длительности операций, изменения в производительности и доступности ресурсов, а также непредвиденные риски. Такие отклонения могут повлиять на план управления проектом или документы проекта, а также могут потребовать детального анализа и разработки соответствующих управленческих мер реагирования. Результаты анализа могут привести к запросам на изменения, которые, в случае их одобрения, могут вызвать изменение плана управления проектом или прочих документов проекта и, возможно, потребуют установления новых базовых планов. На осуществление процессов группы процессов исполнения затрачивается большая часть бюджета проекта. Библиографический список к Лекции №1 (Тема 2): 13. Руководство к Своду знаний по управлению проектами. Project Management Institute (USA). - 5-е изд. - Москва: Олимп-Бизнес, 2014. – 586 с. II Группы процессов управления проектами и их взаимодействие 1 Группа процессов мониторинга и контроля Группа процессов мониторинга и контроля состоит из процессов, требуемых для отслеживания, анализа, а также координации прогресса и исполнения проекта; выявления областей, требующих внесения изменений в план; и инициирования соответствующих изменений. Ключевая выгода данной группы процессов состоит в том, что исполнение проекта измеряется и анализируется регулярно, а также при наступлении соответствующих событий или исключительных обстоятельств, с тем чтобы выявить отклонения от плана управления проектом. Группа процессов мониторинга и контроля также включает в себя: • контроль изменений и разработку рекомендаций по применению корректирующих воздействий или предупреждающих действий для предотвращения возможных проблем; • мониторинг соответствия текущих операций проекта плану управления проектом и базовому плану исполнения проекта; • оказание влияния на факторы, которые могут действовать в обход интегрированного контроля изменений или управления конфигурацией, с тем чтобы в исполнение приводились только одобренные изменения. Такой непрерывный мониторинг дает команде проекта возможность глубже понять общее состояние проекта и определить, на какие области стоит обратить дополнительное внимание. Группа процессов мониторинга и контроля не только осуществляет мониторинг и контроль работ, выполняемых в рамках той или иной группы процессов, но также осуществляет мониторинг и контроль работ всего проекта. В проектах, состоящих из нескольких фаз, группа процессов мониторинга и контроля координирует фазы проекта, чтобы осуществлять корректирующие воздействия и предупреждающие действия для обеспечения соответствия проекта плану управления проектом. Подобный анализ может привести к внесению рекомендованных и одобренных обновлений в план управления проектом. Например, просрочка даты финиша операции может потребовать произвести корректировку или искать компромиссы между целями бюджета и расписания. С целью уменьшения расходов, связанных с контролем, может быть уместным применение процедур управления по отклонениям и других методов. 2 Группа процессов закрытия Группа процессов закрытия состоит из процессов, выполняемых для завершения всех операций в рамках всех групп процессов управления проектом в целях формального завершения проекта, фазы или договорных обязательств. Данная группа процессов, будучи завершенной, подтверждает, что процессы, определенные в рамках всех групп процессов, выполнены необходимым образом для закрытия проекта или фазы проекта, и формально устанавливает, что проект или фаза проекта завершена. Данная группа процессов также формально устанавливает преждевременное закрытие проекта. Преждевременно закрытые проекты включают, например: прерванные проекты, отмененные проекты или проекты, находящиеся в критической ситуации. В определенных случаях, когда некоторые договоры не могут быть формально закрыты (претензии, пункты о прекращении договора и т. д.) либо выполнение определенных операций должно быть передано другим подразделениям организации, могут быть организованы и завершены определенные процедуры по передаче. При закрытии проекта или фазы может происходить следующее: • получение подтверждения заказчика или спонсора для формального закрытия проекта или фазы, • проведение анализа после окончания проекта или фазы, • документирование последствий адаптации любого процесса, • документирование извлеченных уроков, • внесение необходимых обновлений в активы процессов организации, • архивация всех значимых документов проекта в информационной системе управления проектами (project management information system, PMIS) для использования в качестве исторических данных, • завершение всех операций по закупке с целью обеспечения закрытия всех соответствующих соглашений, • выполнение оценки всех членов команды и высвобождение ресурсов проекта. 3 Информация проекта В рамках жизненного цикла проекта происходит сбор, анализ, трансформация и распространение значительного количества данных и информации в различных форматах для членов команды проекта и других заинтересованных сторон. Сбор данных проекта выполняется в результате различных процессов исполнения, после чего они предоставляются членам команды проекта. Собранные данные анализируются в контексте, объединяются и трансформируются в информацию проекта в ходе различных процессов контроля. Информация затем может передаваться устно или храниться и распространяться в виде отчетов, представленных в различных форматах. В процессе исполнения проекта происходит постоянный сбор и анализ данных проекта. Поэтому термины «данные» и «информация» взаимозаменяемо используются на практике. Неизбирательное использование данных терминов может привести к путанице и недопониманию со стороны различных заинтересованных сторон. Следующие руководящие указания сводят к минимуму недопонимание и помогают команде проекта использовать надлежащую терминологию: • Данные об исполнении работ. Необработанные наблюдения и измерения, выявленные во время операций, предпринимаемых для выполнения работ проекта. Примеры включают процентные данные о физически выполненной работе, показатели качества и показатели технического исполнения, даты старта и финиша операций расписания, количество запросов на изменения, количество дефектов, фактическую стоимость, фактическую длительность и т. д. • Информация об исполнении работ. Данные об исполнении, собранные в рамках различных процессов контроля, проанализированные в контексте и обобщенные на основе связей в различных областях. Примеры информации об исполнении включают статус поставляемых результатов, статус реализации запросов на изменения и оценку прогнозов до завершения. • Отчеты об исполнении работ. Физическое или электронное представление информации об исполнении работ, собранное в документах проекта, предназначенное для вынесения решений или формулирования проблем, выполнения действий или формирования осведомленности. Примеры включают отчеты о статусе, служебные записки, обоснования, информационные бюллетени, электронные информационные панели, рекомендации и обновления. На рис. 5 показан поток информации проекта в рамках различных процессов, используемых для управления проектом. II Группы процессов управления проектами и их взаимодействие 1 Роль областей знаний Описанные в Руководстве PMBOK 47 процессов управления проектом разбиты на 10 отдельных областей знаний. Области знаний – функциональные области управления проектом. Область знаний является всеобъемлющей системой понятий, терминов и действий, составляющих профессиональную область, область управления проектами или область деятельности. Эти 10 областей знаний практически постоянно используются в большинстве проектов. Области знаний включают в себя: • управление интеграцией проекта; • управление содержанием проекта; • управление сроками проекта; • управление стоимостью проекта; • управление качеством проекта; • управление человеческими ресурсами проекта; • управление коммуникациями проекта; • управление рисками проекта; • управление закупками проекта; • управление заинтересованными сторонами проекта. Руководство PMBOK определяет важные аспекты каждой области знаний и их взаимодействия с пятью группами процессов. В качестве вспомогательных элементов, области знаний предоставляют подробное описание входов и выходов процессов, а также подробное объяснение инструментов и методов, которые наиболее часто используются в рамках процессов управления проектом, чтобы создать каждый выход. Диаграммы потоков данных приводятся в каждой области знаний. Диаграмма потоков данных представляет собой обобщающую схему входов и выходов, проходящих через все процессы, относящиеся к определенной области знаний (обозначения, представленные на диаграммах потоков данных, см. на рис. 6). Хотя процессы представлены здесь в виде дискретных элементов с четко определенными границами, на практике они являются итеративными, могут накладываться друг на друга и взаимодействовать между собой способами, не описанными здесь. Таблица 1 отражает отнесение 47 процессов управления проектом к 5 группам процессов управления проектом и 10 областям знаний по управлению проектом. Рис. 6. Обозначения на диаграммах потоков данных Таблица 1 Разделение по группам процессов управления проектом и областям знаний Области знаний Группы процессов управления проектом Группа процессов инициации Группа процессов планирования Группа процессов исполнения Группа процессов мониторинга и контроля Группа процессов закрытия Управление интеграцией проекта Разработка устава проекта Разработка плана управления проектом Руководство и управление работами проекта Мониторинг и контроль работ проекта Интегрирован­ный контроль изменений Закрытие проекта или фазы Управление содержанием проекта Планирование управления содержанием Сбор требований Определение содержания Создание ИСР Подтверждение содержания Контроль содержания Управление сроками проекта Планирование управления расписанием Определение операций Определение последовательности операций Оценка ресурсов операций Оценка длительности операций Разработка расписания Контроль расписания Управление стоимостью проекта Планирование управления стоимостью Оценка стоимости Определение бюджета Контроль стоимости Управление качеством проекта Планирование управления качеством Обеспечение качества Контроль качества Управление человеческими ресурсами проекта Планирование управления человеческими ресурсами Набор команды проекта Развитие команды проекта Управление командой проекта Управление коммуника­циями проекта Планирование управления коммуникациями Управление коммуникациями Контроль коммуникаций Управление рисками проекта Планирование управления рисками Идентификация рисков Качественный анализ рисков Количественный анализ рисков Планирование реагирования на риски Контроль рисков Управление закупками проекта Планирование управления закупками Проведение закупок Контроль закупок Закрытие закупок Управление заинтересован­ными сторонами проекта Определение заинтересованных сторон Планирование управления заинтересованными сторонами Управление вовлечением заинтересованных сторон Контроль вовлечения заинтересованных сторон 2 Основные документы проекта Система документационного обеспечения управления проектами – комплекс нормативных, организационно-распорядительных и учебно-методических документов, обеспечивающих эффективное функционирование организационной системы управления проектами и взаимодействие ее компонентов с информационной системой управления проектами (ИСУП) организации (рис. 7). Основным документом системы является «Регламент управления проектами», который должен быть разработан с учетом рекомендаций стандарта управления проектами ANSI PMI РМВОК GUIDE 2000 и требований стандарта ISO 10006 Quality management systems – Guidelines for quality management in projects. Структура «Регламента». ♦ Основные понятия и термины. ♦ Система управления проектами: • организационная система; • информационная система; • система документационного обеспечения. ♦ Статус, права и ответственность управляющего проектом. ♦ Статус и функции Центра управления проектами. ♦ Процессы управления проектами организации:  интеграцией проекта;  содержанием проекта;  сроками проекта;  стоимостью проекта;  качеством проекта;  человеческими ресурсами проекта;  информационным взаимодействием в проекте;  рисками проекта.  Управление контрактами проекта.  Содержание фаз проекта:  фаза 1. Инициация;  фаза 2. Планирование;  фаза 3. Исполнение;  фаза 4. Завершение. ♦ Особенности выполнения внутренних проектов. ♦ Приложения: • № 1 – Схема организационной системы управления проектами. • № 2 – Матрица ответственности организационной системы управ-ления проектами. • № 3 – Требования к составу, содержанию и правилам изложения раздела «Проектное управление» положений о подразделениях и должностных инструкциях. • № 4 – Укрупненная схема бизнес-процесса управления проектами. • № 5 – Схема бизнес-процесса управления интеграцией проекта. • № 6 – Схема бизнес-процесса управления содержанием проекта. • № 7 – Схема бизнес-процесса управления сроками проекта. • № 8 – Схема бизнес-процесса управления стоимостью проекта. • № 9 – Схема бизнес-процесса разработки схемы информационного взаимодействия в проекте. • № 10 – Схема бизнес-процесса управления человеческими ресурсами проекта. • № 11 – Схема бизнес-процесса управления контрактами проекта. • № 12 – Перечень обязательных документов дела проекта. • № 13 – Форма описания проекта. • № 14 – Методика анализа проекта по методу освоенного объема. • № 15 – План задействования участников проекта. • № 16 – Форма матрицы ответственности. • № 17 – Форма плана управления информационным взаимодействием в проекте. • № 18 – Перечень нормативных и справочных документов управляющего проектом. Важнейшими дополнениями к указанному «Регламенту» являются «Регламент управления рисками проектов» и «Регламент обеспечения качества проектов», детально описывающие соответствующие бизнес-процессы и содержащие комплекс методик, обеспечивающих реализацию этих бизнес-процессов. Ответственность за эффективность применения информационной системы управления проектами возлагается на центры управления проектами (ЦУП). ЦУП выполняет методологическую, аналитическую, архивную, контрольную, коммуникативную и др. функции. Рис. 7 Система документационного обеспечения управления проектами Библиографический список к Лекции №2 (Тема 2): 14. Коваленок Т.П. Управление проектами: учеб. пособие - СПб. : ПГУПС, 2011. - 73 с. 15. Руководство к Своду знаний по управлению проектами. Project Management Institute (USA). - 5-е изд. - Москва: Олимп-Бизнес, 2014. – 586 с. III Методы и инструменты управления проектами 1. Ключевые стандарты в области управления проектами В настоящее время существует большое количество стандартов и методологий управления проектами, которые применяются как на международном, так и на национальном уровнях. Основными стандартами являются: 1. РМВОК Guide (PMI, 1996 г.) – является ISO 9001-совместимым. Кроме того, он имеет международное распространение и поддержку. 2. ISO 10006 (Guidelines to Quality in Project Management) (ISO, 1997 г.). 3. BS 6079 (British Standards Board, 1996 г.). 4. DIN 69 900 series x-50-100 series (German standards DIN 69 900 to 69 903 and 69 905). 5. АРМ ВОК (версия. 3.0) (АРМ Association for Project Managers: Body of Knowledge, пересм., март 1996 г. (версия 3) High Wycombe, 1996 г.). 6. ICB IPMA Competence Baseline (IPMA, 1999 г.). 7. Australian National Competency Standards for Project Management (AIPM, 1996 г.). 8. Prince 2 (PRojects IN Controlled Environments). 9. ANSI/EIA"748"98 – Earned Value Management Systems (EVMS), 1998 г. 10. DSDM (Dynamic Systems Development Method). Краткое описание наиболее распространенных стандартов по управлению проектами представлено в табл. 1 Помимо международных нормативных документов и стандартов, в ряде стран разработаны и используются национальные системы стандартов и требований. Наиболее часто используемым национальным стандартом является Project Management Body of Knowledge (PMBOK) Американского института управления проектами (PMI). Стандарт предлагает определение проекта через его отличительные характеристики. Стандарты РФ по управлению проектами: 1. ГОСТ Р 54869-2011 Национальный стандарт РФ. Проектный менеджмент. Требования к управлению проектом; 2. ГОСТ Р 54870-2011 Национальный стандарт РФ. Проектный менеджмент. Требования к управлению портфелем проектов; 3. ГОСТ Р 54871-2011 Национальный стандарт РФ. Проектный менеджмент. Требования к управлению программой. Таблица 1 Стандарты по управлению проектами Название стандарта Краткое описание 1 2 A Guide to the Project Management Body of Knowledge (PMBOK Guide) 1996 Edition Свод знаний по управлению проектами (РМВОК 1996) – стандарт, разработанный Project Management Institute (PMI), версия 1996 г. Является единственным стандартом в области Project Management, который соответствует ISO 9001. В стандарте описаны жизненные циклы проекта и организационные структуры исполняющей организации, определены группы процессов (инициирования, планирования, исполнения, контроля, завершения) и показано их взаимодействие между собой. Выделены основные и поддерживающие процессы. Определены девять областей знаний (управление интеграцией, замыслом, временем, стоимостью, качеством, человеческими ресурсами, коммуникациями, рисками, контрактами и поставками). Стандарт базируется на процессном подходе. Для каждой области знаний определены входы, выходы и процедуры преобразования входных данных в выходные. Полностью определены взаимодействия между всеми процессами, которые включены в области знаний управления проектами. A Guide to the Project Management Body of Knowledge (PMBOK Guide) 2000 Edition Свод знаний по управлению проектами (РМВОК 2000) – стандарт, разработанный Project Management Institute (PMI) версии 2000 г. Принят в качестве национального стандарта ANSI (ANSI/PMI 99-001-2000) 27 марта 2001 г. По содержанию и структуре практически полностью соответствует РМВОК 1996. Полностью переработана глава по «Управлению рисками в проекте». Расширены и добавлены разделы, относящиеся к управлению проектами на основе «Менеджмента освоенного объема» (EVM – Earned Value Management). Добавлены новые процедуры (tools and techniques) по преобразованию входных данных в выходные Project Management Institute Practice Standard for Work-Breakdown Structures (Exposure Draft Version) Стандарт на «Иерархические последовательности работ» проекта. Предварительная черновая версия, 2000 г. Приведено практическое применение WBS (Work Breakdown Structure) для проектов из различных предметных областей. Описано применение стандарта для улучшения процессов планирования и контроля проекта. Приведены стандартизированные структуры для проектов по нефтехимическим производствам, управлению окружающей средой, улучшению процессов, фармацевтическим производствам, строительной индустрии, индустрии сервиса, разработке Web-сайтов, телекоммуникациям, очистке, строительству по государственным контрактам, внедрению программных комплексов. Тесно связан со стандартами РМВОК 1996 г. и РМВОК 2000 г. Revised Exposure Draft the Risk Management SIG Committee, 2000 Управление рисками проекта. Предварительная черновая версия, 2000 г. Заново переписанная глава РМВОК 1996 вошла в РМВОК 2000 ISO 10006:1997 Quality Management – Guidelines to Quality in Project Management Менеджмент качества. Руководство качеством при управлении проектами, 1997 г. Руководство нацелено на обеспечение заданного уровня качества проекта как на уровне процессов, так и на уровне продуктов. В большой мере по содержанию основано на РМВОК 1996, совпадение вплоть до названий областей знаний управления проектами. Первый стандарт ISO серии 9000, в котором применен процессный подход 2. Методы и инструменты управления интеграцией проекта Управление интеграцией проекта включает в себя процессы и операции, необходимые для определения, уточнения, комбинирования, объединения и координации различных процессов и операций по управлению проектом в рамках групп процессов управления проектом. На рис. 1 представлена общая схема следующих процессов управления интеграцией проекта, а именно: 1. Разработка устава проекта—процесс разработки документа, который формально авторизует существование проекта и предоставляет руководителю проекта полномочия использовать ресурсы организации в операциях проекта. 2. Разработка плана управления проектом — процесс определения, подготовки и координации всех вспомогательных планов и интеграции их в комплексный план управления проектом. В план управления проектом могут быть включены интегрированные базовые и вспомогательные планы. 3. Руководство и управление работами проекта — процесс руководства и исполнения работ, определенных в плане управления проектом, и применения одобренных изменений для достижения целей проекта. 4. Мониторинг и контроль работ проекта — процесс отслеживания, проверки и ведения отчетности о ходе исполнения для достижения целей исполнения, определенных в плане управления проектом. 5. Интегрированный контроль изменений — процесс анализа всех запросов на изменения, их одобрения и управления изменениями поставляемых результатов, активов процессов организации, документов проекта и плана управления проектом, а также предоставления информации об их состоянии. 6. Закрытие проекта или фазы — процесс завершения всех операций всех групп процессов управления проектом в целях формального завершения проекта или фазы. Данные процессы взаимодействуют друг с другом и с процессами из других областей знаний Рис. 1. Общая схема управления интеграцией проекта 2.1 Разработка устава проекта: инструменты и методы 2.1.1 Экспертная оценка Экспертная оценка часто используется для оценивания входов (другими словами – необходимых исходных данных), применяемых для разработки устава проекта. В качестве экспертов могут выступать: • другие подразделения в рамках организации; • консультанты; • заинтересованные стороны, в том числе заказчики или спонсоры; • профессиональные и технические ассоциации; • отраслевые объединения; • эксперты по предметной области (subject matter experts, SME); • офис управления проектами (ОУП). 2.1.2 Методы организации групповой работы Методы организации групповой работы имеют широкое применение в рамках процессов управления проектом и способствуют созданию устава проекта. Примеры основных методов включают мозговой штурм, разрешение конфликтов, решение проблем и управление совещаниями. Модераторы используют эти методы, чтобы помочь командам и отдельным лицам выполнять операции проекта. 2.2 Разработка плана управления проектом: инструменты и методы 2.2.1 Экспертная оценка При разработке плана управления проектом экспертная оценка используется для: • адаптации процесса для удовлетворения потребностей проекта; • разработки технических и управленческих деталей, которые будут включены в план управления проектом; • определения ресурсов и уровней развития навыков, необходимых для выполнения работ проекта; • определения уровня управления конфигурацией, который будет применяться в проекте; • определения того, какие документы проекта будут подвержены процессу формального контроля изменений; • приоритезации работы над проектом для обеспечения распределения ресурсов для надлежащих работ в надлежащее время. 2.2.2 Методы организации групповой работы См. п.2.1.2. 2.3 Руководство и управление работами проекта: инструменты и методы 2.3.1 Экспертная оценка См. п.2.1.1. 2.3.2 Информационная система управления проектами Информационная система управления проектами, будучи одним из факторов среды предприятия, предоставляет доступ к инструментам, таким как инструмент составления расписания, система авторизации работ, система управления конфигурацией, система сбора и распределения информации или интерфейсы прочих автоматизированных систем, работающих в режиме онлайн. Частью данной системы может являться автоматический сбор и отчетность в отношении ключевых показателей исполнения (key performance indicators, KPI). 2.3.3 Совещания Совещания используются для обсуждения и решения актуальных вопросов проекта в рамках руководства и управления работами проекта. Совещания, как правило, бывают одного из трех типов: • обмен информацией; • мозговой штурм, оценка вариантов или проектирование; • принятие решений. В соответствии с лучшей практикой, совещания разных типов смешивать не следует. Совещания должны быть подготовлены. Они должны иметь четко определенную повестку дня, цель, задачу и временные рамки, должны быть надлежащим образом документированы, включая протоколы и вопросы, требующие принятия мер. Протоколы совещаний должны храниться в соответствии с требованиями плана управления проектом 2.4 Мониторинг и контроль работ проекта: инструменты и методы 2.4.1 Экспертная оценка См. п.2.1.1. 2.4.2 Аналитические методы Аналитические методы используются в управлении проектом для прогнозирования потенциальных результатов на основании возможных вариаций проекта или переменных окружающей среды и их взаимосвязи с другими переменными. Примеры аналитических методов, используемых в проектах, включают: • регрессионный анализ; • методы группировки; • причинный анализ; • анализ первопричины; • методы прогнозирования (например, динамические ряды, создание сценариев, имитация и т. д.); • анализ характера и последствий отказов (failure mode and effect analysis, FMEA); • анализ дерева решений (fault tree analysis, FTA); • анализ резервов; • анализ тенденций; • управление освоенным объемом; • анализ отклонений. 2.4.3 Информационная система управления проектами См. п.2.3.2. 2.4.4 Совещания См. п. 2.3.3 2.5 Интегрированный контроль изменений: инструменты и методы 2.5.1 Экспертная оценка См. п.2.1.1. 2.5.2 Совещания В этом случае подобные совещания обычно называют совещаниями по контролю изменений. Когда это необходимо для проекта, совет по контролю изменений (CCB) отвечает за организацию совещаний и рассмотрение запросов на изменения, а также за одобрение, отклонение данных изменений или иные действия с ними. CCB также может рассматривать операции по управлению конфигурацией. Роли и обязанности таких советов четко определяются и согласуются с соответствующими заинтересованными сторонами, а также фиксируются в плане управления изменениями. Решения CCB документируются и сообщаются заинтересованным сторонам для информации и последующих действий. 2.5.3 Инструменты контроля изменений Для облегчения управления конфигурацией и изменениями могут использоваться ручные или автоматизированные инструменты. Выбор инструмента должен основываться на потребностях заинтересованных сторон проекта, включая вопросы и/или ограничения организации и среды. Инструменты используются для управления запросами на изменения и принятыми решениями. Следует учитывать дополнительные аспекты для коммуникации, чтобы помочь членам CCB выполнять свои обязанности, а также информировать соответствующие заинтересованные стороны о решениях. 2.6 Закрытие проекта или фазы: инструменты и методы 2.6.1 Экспертная оценка См. п.2.1.1. 2.6.2 Аналитические методы Примеры аналитических методов, используемых при закрытии проекта: • регрессионный анализ; • анализ тенденций. 2.6.3 Совещания См. п. 2.3.3. 3. Методы и инструменты управления содержанием проекта Управление содержанием проекта включает в себя процессы, требуемые для обеспечения того, чтобы проект содержал все и только те работы, которые требуются для успешного выполнения проекта. На рис. 2 представлена общая схема процессов управления содержанием проекта, которые включают в себя следующее: 1. Планирование управления содержанием — процесс создания плана управления содержанием, документирующего, каким образом содержание проекта будет определяться, подтверждаться и контролироваться. 2. Сбор требований — процесс определения, документирования и управления потребностями и требованиями заинтересованных сторон для достижения целей проекта. 3. Определение содержания — процесс разработки подробного описания проекта и продукта. 4. Создание иерархической структуры работ (ИСР) — процесс разделения поставляемых результатов проекта и работ проекта на меньшие компоненты, которыми легче управлять. 5. Подтверждение содержания—процесс формализованной приемки полученных поставляемых результатов проекта. 6. Контроль содержания — процесс мониторинга состояния содержания проекта и продукта, а также управления изменениями базового плана по содержанию. Данные процессы взаимодействуют друг с другом и с процессами из других областей знаний. В контексте проекта термин «содержание» может обозначать: • Содержание продукта. Свойства и функции, которые характеризуют продукт, услугу или результат. • Содержание проекта. Работы, которые необходимо выполнить, чтобы получить продукт, услугу или результат с заданными свойствами и функциями. Термин «содержание проекта» иногда включает в себя содержание продукта. Рис. 2 Общая схема управления содержанием проекта 3.1 Планирование управления содержанием: инструменты и методы 3.1.1 Экспертная оценка См. п.2.1.1. 3.1.2 Совещания См. п. 2.3.3. 3.2 Сбор требований: инструменты и методы 3.2.1 Интервью Интервью представляют собой формальный или неформальный подход, используемый для получения информации у заинтересованных сторон путем прямого разговора с ними. 3.2.2 Фокус-группы Фокус-группы позволяют собрать вместе заранее выбранных заинтересованных сторон и экспертов по предметной области, чтобы узнать их ожидания и отношения к предложенному продукту, услуге или результату. 3.2.3 Семинары с участием модератора Семинары с участием модератора (facilitated workshops) представляют собой сфокусированные обсуждения, объединяющие ключевые заинтересованные стороны с целью определения требований к продукту. Семинары используются в качестве основного метода, позволяющего быстро определить межфункциональные требования и урегулировать различия между требованиями заинтересованных сторон. 3.2.4 Методы группового творчества Для выявления требований к проекту и продукту могут организовываться различные групповые мероприятия. Ниже представлены некоторые из методов группового творчества: • Мозговой штурм. Метод, применяемый для генерации и сбора разнообразных идей, связанных с требованиями к проекту и продукту. Хотя сам по себе мозговой штурм не включает голосование или приоритезацию, его часто используют с другими методами группового творчества, которые предусматривают данные процессы. • Метод номинальных групп. Метод, расширяющий мозговой штурм путем процесса голосования, используемого для ранжирования наиболее полезных идей для последующего мозгового штурма или приоритезации. • Построение ассоциативных карт. Метод, в котором идеи, возникшие во время отдельных сессий мозгового штурма, объединяются в одну карту с целью отражения общности и различий в понимании и для генерирования новых идей. • Диаграмма сходства. Метод, позволяющий классифицировать большое количество идей по группам с целью обзора и анализа. • Анализ решений на основе множества критериев. Метод, использующий матрицу решений для обеспечения систематического аналитического подхода к установлению критериев, таких как уровни рисков, неопределенность и определение ценности, для оценивания и ранжирования многочисленных идей. 3.2.5 Методы группового принятия решения Метод группового принятия решений — это процесс оценки различных альтернатив с ожидаемым результатом в форме будущих действий. Существуют различные методы принятия группового решения, например: • Единогласие. Принятие решения посредством согласия каждого с единым курсом действий. Один из способов достижения единогласия — это метод Дельфи, при котором группа выбранных экспертов отвечает на вопросы анкет, а также высказывает мнение относительно ответов, полученных в течение каждого раунда сбора требований. Для обеспечения анонимности доступ к ответам имеет только модератор. • Большинство. Решение, которое принимается при поддержке более чем 50 % участников группы. Наличие в группе нечетного количества участников может обеспечить принятие решения и исключить ситуацию равного количества голосов. • Относительное большинство. Выбирается решение самого большого блока в группе, даже если не достигнуто большинство голосов. Данный метод обычно используется, когда предлагается более двух вариантов для выбора. • Диктатура. Данный метод предполагает, что одно лицо принимает решение за всю группу. Все данные методы группового принятия решений можно применять в рамках методов группового творчества, которые используются в процессе сбора требований. 3.2.6 Анкеты и опросы Анкеты и опросы представляют собой письменные наборы вопросов, разработанные с целью быстрого сбора информации у большого числа респондентов. 3.2.7 Наблюдения Наблюдения предоставляют непосредственный способ рассмотрения отдельных лиц в окружающей их обстановке, а также того, как они исполняют свои обязанности или задачи и выполняют процессы. 3.2.8 Прототипы Прототипирование представляет собой метод получения предварительных отзывов относительно требований путем предоставления рабочей модели ожидаемого продукта, прежде чем создавать продукт в действительности. Поскольку прототипы реальны, это позволяет заинтересованным сторонам экспериментировать с моделью конечного продукта, а не ограничиваться обсуждением абстрактных представлений своих требований. 3.2.9 Бенчмаркинг Бенчмаркинг — это сравнение используемых или запланированных к использованию практик, таких как процессы и операции, с практиками сопоставимых организаций для выявления лучших практик, генерирования идей в отношении улучшений и предоставления основы для измерения эффективности и результативности. 3.2.10 Контекстные диаграммы Контекстные диаграммы являются примером модели содержания. Контекстные диаграммы визуально отображают содержание продукта, показывая бизнес-систему и то, как люди и другие системы (действующие лица) взаимодействуют с ней. 3.2.11 Анализ документов Анализ документов используется для выявления требований путем анализа существующей документации и идентификации информации, которая имеет отношение к требованиям. Примеры документов, подлежащих анализу: бизнес-планы, маркетинговые материалы, соглашения, запросы предложений, действующий порядок процессов, логические модели данных, репозитории бизнес-правил, документацию по прикладному программному обеспечению, документацию по бизнес-процессам или интерфейсам, сценарии использования, другую документацию по требованиям, журналы проблем, политики, процедуры и нормативную документацию, такую как законы, кодексы или предписания и т. д. 3.3 Определение содержания: инструменты и методы 3.3.1 Экспертная оценка См. п.2.1.1. 3.3.2 Анализ продукта Анализ продукта может стать результативным инструментом для проектов, поставляемым результатом которых является продукт, в отличие от услуги или результата. Анализ продукта включает в себя методы, такие как иерархическое разбиение продукта, системный анализ, анализ требований, системная инженерия, функционально-стоимостной анализ и анализ ценности 3.3.1. Формирование альтернатив Формирование альтернатив — это метод, используемый для разработки как можно большего количества возможных вариантов для определения различных подходов к выполнению работ проекта. 3.3.1 Семинары с участием модератора См. п. 3.2.3. 3.4. Создание ИСР: инструменты и методы 3.4.1 Декомпозиция Декомпозиция — это метод, предполагающий разбиение содержания и поставляемых результатов проекта на более мелкие и легко управляемые элементы. Пакет работ — это элемент работ, расположенный на самом низком уровне иерархической структуры работ, для которого возможна оценка стоимости и длительности, а также управление ими. На уровень декомпозиции зачастую влияет степень контроля, необходимого для эффективного управления проектом. Уровень детализации пакетов работ различается в зависимости от масштаба и сложности проекта. Декомпозиция всей совокупности работ проекта до пакетов работ обычно включает в себя следующие операции: • определение и анализ поставляемых результатов и соответствующих работ; • структурирование и организацию ИСР; • декомпозицию верхних уровней ИСР на детализированные компоненты более низких уровней; • разработку и присвоение идентификационных кодов компонентам ИСР; • проверку приемлемости степени декомпозиции поставляемых результатов. На рис. 3 показана часть ИСР с некоторыми ответвлениями ИСР, декомпозированными до уровня пакетов работ. 3.4.2 Экспертная оценка Экспертная оценка часто используется для анализа информации, необходимой для декомпозиции поставляемых результатов проекта до меньших компонентов с целью создания эффективной ИСР. Экспертную оценку также можно получить в виде предварительно определенных шаблонов, помогающих эффективно разложить на компоненты типовые поставляемые результаты. Рис. 3 Пример декомпозиции ИСР до пакетов работ Структура ИСР может создаваться с помощью различных подходов. Некоторые популярные методы включают принцип нисходящего анализа, использование руководящих указаний конкретных организаций и применение шаблонов ИСР. Во время интеграции подкомпонентов можно использовать принцип восходящего анализа. Структура ИСР может быть создана в различных формах, например: • в качестве второго уровня декомпозиции используются фазы жизненного цикла проекта, на третьем уровне расположены поставляемые результаты, относящиеся к проекту и продукту, как показано на рис. 4; • в качестве второго уровня декомпозиции используются основные поставляемые результаты, как показано на рис. 5; • используются подкомпоненты, которые могут разрабатываться организациями, не входящими в команду проекта, например, работающими по договору. В таких случаях продавец разрабатывает поддерживающую договор ИСР как часть работы по договору. Для декомпозиции компонентов ИСР верхнего уровня требуется разделение работ по каждому поставляемому результату или подкомпонентам на основополагающие элементы, где компоненты ИСР представляют собой поддающиеся проверке продукты, услуги или результаты. ИСР может быть структурирована в виде схемы, организационной диаграммы или другим методом, отражающим иерархическое разбиение. Проверка правильности декомпозиции требует удостоверения в том, что компоненты ИСР низкого уровня — это именно те компоненты, которые необходимы и достаточны для создания соответствующих поставляемых результатов более высокого уровня. Различные поставляемые результаты могут иметь различные уровни декомпозиции. Работы по некоторым поставляемым результатам достаточно декомпозировать всего лишь до следующего уровня, чтобы достичь уровня пакетов работ, однако для других могут потребоваться дополнительные уровни декомпозиции. По мере декомпозиции работ до более глубоких уровней детализации возможность планирования, управления и контроля работ расширяется. Однако чрезмерная декомпозиция может привести к непродуктивным управленческим трудозатратам, неэффективному использованию ресурсов, снижению эффективности выполнения работ и сложности консолидации данных различных уровней ИСР. Декомпозиция может оказаться невозможной для поставляемых результатов или подкомпонентов, которые будут выполняться в далеком будущем. Команда управления проектом обычно дожидается согласования поставляемого результата или подкомпонента, чтобы иметь возможность разработать соответствующие детали ИСР. Этот метод иногда называют «планированием методом набегающей волны». ИСР отображает все работы, связанные с продуктом и проектом, включая работы по управлению проектом. Все содержание работ на самых нижних уровнях должно сворачиваться в более высокие уровни, чтобы ничего не было пропущено и не выполнялась лишняя работа. Иногда это называют «правилом 100 %». 3.5 Подтверждение содержания: инструменты и методы 3.5.1 Инспекция Инспекция включает в себя такие действия, как измерение, обследование и подтверждение, позволяющие определить, соответствуют ли работы и поставляемые результаты требованиям к продукту и критериям его приемки. Инспекции иногда называются «проверками», «проверками продукта», «аудитами» или «сквозным контролем». 3.5.2 Методы группового принятия решений См. п. 3.2.4. 3.6 Контроль содержания: инструменты и методы 3.6.1 Анализ отклонений Анализ отклонений — это метод определения причины и степени различий между базовым планом и фактическим исполнением. Разновидность аналитических методов. 4. Методы и инструменты управления сроками выполнения проекта Управление сроками проекта включает в себя процессы, необходимые для того, чтобы обеспечить своевременное выполнение проекта. На рис. 6 приведена общая схема следующих процессов управления сроками проекта: 1. Планирование управления расписанием — процесс, устанавливающий политики, процедуры и документацию по планированию, разработке, управлению, исполнению и контролю за расписанием проекта. 2. Определение операций — процесс идентификации и документирования конкретных действий, которые необходимо выполнить для создания поставляемых результатов проекта. 3. Определение последовательности операций — процесс определения и документирования связей между операциями проекта. 4. Оценка ресурсов операций — процесс оценки типа и количества материалов, человеческих ресурсов, оборудования или расходных материалов, требуемых для выполнения каждой операции. 5. Оценка длительности операций — процесс оценки количества рабочих периодов, требуемых для завершения отдельных операций с учетом оценки ресурсов. 6. Разработка расписания—процесс анализа последовательностей операций, их длительностей, потребностей в ресурсах и ограничений расписания для создания модели расписания проекта. 7. Контроль расписания — процесс мониторинга статуса операций проекта для актуализации прогресса проекта и управления изменениями базового расписания с целью соответствия плану. Рис. 6 Общая схема управления сроками проекта 4.1 Планирование управления расписанием: инструменты и методы 4.1.1 Экспертная оценка См. п.2.1.1. 4.1.2 Аналитические методы Процесс планирования управления расписанием может включать в себя выбор стратегических средств для оценки проекта и составления его расписания, например, методологию, инструменты и методы составления расписания, подходы по оценке, форматы и программное обеспечение для управления проектом. План управления расписанием также может подробно описывать способы быстрого прохода или сжатия расписания проекта, например, параллельное исполнение работ. Организационные политики и процедуры могут влиять на выбор методов составления расписания в рамках данных решений. Методы могут включать в себя: планирование методом набегающей волны, опережения и задержки, анализ альтернатив и методы анализа исполнения расписания. 4.1.3 Совещания См. п. 2.3.3. 4.2 Определение операций: инструменты и методы 4.2.1 Декомпозиция Декомпозиция — это метод, используемый для разбиения содержания и поставляемых результатов проекта на более мелкие и более управляемые элементы. Операции представляют собой трудозатраты, необходимые для выполнения пакета работ. В процессе определения операций конечные выходы определяются как операции, а не как поставляемые результаты, как это происходит в процессе создания ИСР. Список операций, ИСР и словарь ИСР могут разрабатываться последовательно или параллельно, при этом основой разработки окончательного списка операций служат ИСР и словарь ИСР. Каждый пакет работ в ИСР разделяется на операции, необходимые для получения поставляемых результатов этого пакета работ. Участие членов команды в процессе декомпозиции может привести к получению лучших и более точных результатов. 4.2.2 Планирование методом набегающей волны Планирование методом набегающей волны — это метод итеративного планирования, при котором работа, которую надо будет выполнить в ближайшей перспективе, планируется подробно, в то время как далеко отстоящая работа планируется с меньшей степенью детализации. Это одна из форм последовательного уточнения. 4.2.3 Экспертная оценка См. п.2.1.1. 4.3 Определение последовательности операций: инструменты и методы 4.3.1 Метод диаграмм предшествования Метод диаграмм предшествования (precedence diagramming method, PDM) — метод, используемый для составления модели расписания, в которой операции представлены узлами и графически связаны одной или несколькими логическими связями, которые показывают последовательность выполнения операций. Операции в узлах (activity-on-node, AON) — один из методов представления диаграммы предшествования. Данный метод используется в большинстве пакетов программного обеспечения для управления проектом. PDM включает в себя четыре типа зависимостей, или логических связей. Предшествующая операция — операция, логически находящаяся перед зависимой операцией в расписании. Последующая операция — зависимая операция, логически находящаяся после другой операции в расписании. Эти связи определены ниже и представлены на рис. 7: • Финиш-старт (finish-start, FS). Логическая связь, при которой старт последующей операции зависит от финиша предшествующей операции. Пример: церемония награждения (последующая операция) не может быть начата, пока не закончится гонка (предшествующая операция). • Финиш-финиш (finish-finish, FF). Логическая связь, при которой финиш последующей операции зависит от финиша предшествующей операции. Пример: создание документа (предшествующая операция) должно быть закончено до завершения его правки (последующая операция). • Старт-старт (start-start, SS). Логическая связь, при которой старт последующей операции зависит от старта предшествующей операции. Пример: выравнивание бетонной поверхности (последующая операция) не может начаться до начала заливки фундамента (предшествующая операция). • Старт-финиш (start-finish, SF). Логическая связь, при которой финиш последующей операции зависит от старта предшествующей операции. Пример: первая смена службы охраны (последующая операция) не может закончиться, пока не начнется вторая смена службы охраны (предшествующая операция). В методе диаграмм предшествования чаще всего используется связь предшествования типа «финиш-старт». Связь «старт-финиш» используется редко, но рассматривается для полноты списка типов связей метода диаграмм предшествования. 4.3.2 Определение зависимостей Зависимости характеризуются следующими описанными далее параметрами: обязательная или дискреционная, внутренняя или внешняя. Зависимость может иметь четыре параметра, но одновременно могут применяться только два из них следующими способами: обязательные внешние зависимости, обязательные внутренние зависимости, дискреционные внешние зависимости или дискреционные внутренние зависимости. • Обязательные зависимости. Обязательные зависимости — это такие зависимости, которые требуются по закону или договору или являются неотъемлемым свойством данной работы. Обязательные зависимости часто подразумевают физические ограничения, например, в строительном проекте, где невозможно возвести наземную конструкцию до сооружения фундамента, или в проекте, связанном с электроникой, где прототип должен быть создан до того, как он будет протестирован. Обязательные зависимости также иногда называют «жесткой логикой» или жесткими зависимостями. • Дискреционные зависимости. Дискреционные зависимости иногда также называют «предпочтительной логикой», «предпочитаемой логикой» или «мягкой логикой». Дискреционные зависимости устанавливаются на основе передовых методов организации работ в определенной прикладной области или в рамках необычного аспекта проекта, где предпочтительна особенная последовательность, хотя могут существовать и другие приемлемые последовательности. Дискреционные зависимости должны быть полностью задокументированы, так как они могут создавать необоснованные общие временные резервы и могут ограничить последующие варианты составления расписания. • Внешние зависимости. Внешние зависимости включают связь между операциями проекта и операциями вне проекта. Эти зависимости обычно не поддаются контролю со стороны команды проекта. Например, в проекте по разработке программного обеспечения операция тестирования может зависеть от поставки аппаратного обеспечения сторонней организацией. • Внутренние зависимости. Внутренние зависимости включают в себя связь предшествования между операциями проекта и обычно поддаются контролю со стороны команды проекта. Пример внутренней обязательной зависимости — команда не может испытать прибор, пока он не будет собран. 4.3.3 Опережения и задержки Опережение — это временной интервал, на который может быть сдвинуто исполнение последующей операции относительно предшествующей на более ранний срок. Например, в проекте по строительству нового офисного здания озеленение может быть запланировано на 2 недели раньше завершения составления перечня недоделок. Это может быть представлено в виде связи «финиш-старт» с 2-недельным опережением (см. рис. 8). В программном обеспечении для составления расписания опережение зачастую представлено как отрицательное значение задержки. Задержка — количество времени, на которое необходимо задержать последующую операцию относительно предшествующей. Например, команда технических специалистов может приступить к редактированию проекта большого документа через 15 дней после начала его написания. Это может быть представлено в виде связи «старт-старт» с 15-дневной задержкой (см. рис. 8). 4.4 Оценка ресурсов операций: инструменты и методы 4.4.1 Экспертная оценка См. п.2.1.1. 4.4.2 Анализ альтернатив В отношении многих операций расписания существуют альтернативные методы их реализации. К ним относится использование ресурсов с различными уровнями способностей или навыков, машин различных габаритов или типов, различных инструментов (ручных или автоматизированных), а также принятие решений «производить, арендовать или покупать» в отношении ресурсов. 4.4.3 Опубликованные оценочные данные Некоторые организации регулярно публикуют данные о производительности и единичные расценки ресурсов по широкому спектру рабочих профессий, материальных средств и оборудования по различным странам и регионам отдельных стран. 4.4.4 Оценка «снизу вверх» Оценка «снизу вверх» — метод оценки длительности или стоимости проекта путем консолидации оценок компонентов ИСР более низкого уровня. Когда операция не может быть оценена с достаточной степенью уверенности, работы операции разделяются на более мелкие элементы. Проводится оценка потребностей в ресурсах. Затем эти оценки объединяются в общую величину по каждому ресурсу операции. 4.4.5 Программное обеспечение для управления проектом Такое программное обеспечение для управления проектом, как инструмент составления расписания, способно оказать помощь в планировании, организации и управлении пулами ресурсов, а также в разработке оценок ресурсов. В зависимости от возможностей программного обеспечения можно определять иерархические структуры ресурсов, доступность ресурсов, стоимость ресурсов и разнообразные ресурсные календари, способствующие оптимизации использования ресурсов. Примеры: MC Project, Project Expert и т.д. 4.5 Оценка длительности операций: инструменты и методы 4.5.1 Экспертная оценка См. п.2.1.1. Библиографический список к Лекции №1 (Тема 3): 16. Коваленок Т.П. Управление проектами: учеб. пособие - СПб. : ПГУПС, 2011. - 73 с. 17. Руководство к Своду знаний по управлению проектами. Project Management Institute (USA). - 5-е изд. - Москва: Олимп-Бизнес, 2014. – 586 с. III Методы и инструменты управления проектами 5 5.1 5.2 5.3 5.4 5.5 5.5.1 5.5.2 Оценка по аналогам Оценка по аналогам — метод оценки продолжительности или стоимости операции или проекта с использованием исторических данных аналогичной операции или проекта. Оценка по аналогам подразумевает использование таких параметров, как длительность, бюджет, размер, вес и сложность из предыдущих подобных проектов в качестве основы для оценки тех же параметров или измерений будущего проекта. 5.5.3 Параметрическая оценка Параметрическая оценка — метод оценки, использующий алгоритм для вычисления стоимости или длительности на основе исторических данных и параметров проекта. Параметрическая оценка использует статистические связи между историческими данными и прочими переменными (например, площадью в квадратных метрах в строительстве) для расчета оценки параметров операции, таких как стоимость, бюджет и длительность. Пример: Применение процедуры определения корректирующих коэффициентов, учитывающих различия между объектами по отдельным параметрам в рамках сравнительного подхода (оценки стоимости). Определение корректирующих коэффициентов используется тогда, когда сравниваемые объекты различаются по отдельным параметрам. Данные параметры можно учесть в стоимости путем введения соответствующих повышающих или понижающих коэффициентов. К основным таким параметрам можно отнести: - технические характеристики объекта и объекта-аналога; - продолжительность выполнения работ; - количество персонала, задействованного для выполнения работ; - необходимость в привлечении зарубежного персонала; - дата выполнения работы-аналога (создания объекта-аналога) и др. Пример расчета индекса, учитывающего разницу в датах между оцениваемой работой, продуктом и работой, продуктом-аналогами: где: I1 – индекс, учитывающий текущий уровень цен (например, индекс PPI); I2 – индекс, учитывающий уровень цен на дату выполнения работы-аналога (например, индекс PPI). 5.5.4 Оценка по трем точкам Точность оценок длительности операций по одной точке может быть улучшена путем рассмотрения неопределенностей оценок и рисков. Данная концепция происходит из метода оценки и анализа программ (program evaluation and review technique, PERT). Для определения приблизительного диапазона длительности операции PERT использует три оценки: • Наиболее вероятная (tM). Длительность операции определяется с учетом предварительного выделения ресурсов, их производительности, реалистичной оценки их доступности для выполнения данной операции, зависимостей от других участников, а также с учетом прерываний в работе. • Оптимистичная (tO). Длительность операции основывается на анализе наиболее благоприятного сценария для операции. • Пессимистичная (tP). Длительность операции основывается на анализе наиболее неблагоприятного сценария для операции. Будучи зависимой от предполагаемого распределения значений в диапазоне трех оценок, ожидаемая длительность, tE, рассчитывается по формуле. Две наиболее распространенные формулы—треугольное распределение и бета-распределение. Формулы: • Треугольное распределение. tE = (tO + tM + tP) / 3 • Бета-распределение (из традиционного метода PERT). tE = (tO + 4tM + tP) / 6 Оценки длительности, основанные на трех точках с предполагаемым распределением, предоставляют данные по ожидаемой длительности и проясняют диапазон неопределенности ожидаемой длительности. 5.5.5 Методы группового принятия решений См. п. 3.2.5 Лекции №1 5.5.6 Анализ резервов Оценки длительности могут включать в себя резервы на возможные потери (иногда называемые «резервами времени» или «буферами») в рамках расписания проекта для учета неопределенности расписания. Резервы на возможные потери — это оценочная длительность в рамках базового расписания, выделенная для идентифицированных рисков, которые были приняты и в отношении которых разработаны меры реагирования с целью их снижения или меры реагирования на возможные потери. По мере поступления более точной информации о проекте резервы на возможные потери могут быть использованы, сокращены или исключены. Возможные потери должны быть четко определены в документации по расписанию. Также можно сформировать оценки величины управленческого резерва времени проекта. Управленческие резервы — это указанная часть длительности проекта, зарезервированная для целей управленческого контроля и сохраненная для выполнения непредвиденной работы, находящейся в пределах содержания проекта. Управленческий резерв не включен в базовое расписание, но является частью общих требований к длительности проекта. 5.6 Разработка расписания: инструменты и методы 5.6.1 Анализ сети расписания Анализ сети расписания представляет собой метод создания модели расписания проекта. В нем применяются разнообразные аналитические методы, такие как метод критического пути, метод критической цепи, анализ сценариев «что если» и методы оптимизации ресурсов. 5.6.2 Метод критического пути Метод критического пути — метод, используемый для оценки минимальной длительности проекта и определения степени гибкости расписания на логических путях в сети в рамках модели расписания. Метод анализа сети расписания позволяет рассчитать даты раннего старта и финиша, а также даты позднего старта и финиша для всех операций без учета ресурсных ограничений путем проведения анализа прямого и обратного прохода по сети проекта, как показано на рис. 9. В данном примере самый длительный путь включает в себя операции A, C и D, и поэтому последовательность A-C-D является критическим путем. Критический путь—это последовательность операций, представляющая собой самый длительный путь в расписании проекта, который определяет самую короткую возможную длительность проекта. Критический путь CPM обычно характеризуется нулевым общим временным резервом на критическом пути. При определении последовательности методом диаграмм предшествования критические пути могут иметь положительный, нулевой или отрицательный общий временной резерв, в зависимости от применяемых ограничений. Любая операция на критическом пути называется операцией критического пути. Положительный общий временной резерв возникает, когда обратный проход рассчитывается из ограничения расписания, указанного позже даты раннего финиша, которая была рассчитана в рамках расчета прямого прохода. Отрицательный временной резерв возникает, когда ограничение в отношении поздних дат нарушено длительностью и логикой. В сетях расписания может существовать несколько околокритических путей. Многие пакеты программного обеспечения позволяют пользователю определить параметры, используемые для оценки критического пути (путей). После подсчета общего временного резерва пути в сети также может быть определен свободный временной резерв — промежуток времени, на который можно задержать выполнение операции расписания без задержки раннего старта любых последующих операций и без нарушения ограничений расписания. Например, свободный временной резерв операции B составляет 5 дней (см. рис. 9). 5.6.3 Метод критической цепи Метод критической цепи (CCM) — метод разработки расписания, позволяющий команде проекта размещать буферы на любом пути в расписании, чтобы учесть ограниченность ресурсов и неопределенности, связанные с проектом. Он разработан из метода критического пути и учитывает воздействия распределения, оптимизации, выравнивания ресурсов, а также неопределенность в отношении длительности операции на критическом пути, определенном методом критического пути. Метод критической цепи включает в себя понятия буферов и управления буферами. Метод критической цепи использует операции, длительность которых не включает в себя пределы безопасности, логические связи и доступность ресурсов со статистически определенными буферами, включающими в себя суммарные пределы безопасности операций в определенных точках проекта на пути расписания проекта для учета ограниченных ресурсов и неопределенности, связанной с проектом. Критический путь с ресурсными ограничениями известен как «критическая цепь». Метод критической цепи добавляет буферы длительности в виде операций, не предусматривающих выполнения работ, для управления неопределенностью. Один из буферов, расположенный в конце критической цепи (см. рис. 10), известен как проектный буфер и защищает целевую дату финиша от задержек на критической цепи. Дополнительные буферы, известные как «питающие буферы», располагаются в каждой точке, в которой в критическую цепь входят цепи взаимосвязанных операций извне критической цепи. Питающие буферы, таким образом, защищают критическую цепь от отставания по входящим цепям. Размер каждого буфера должен учитывать неопределенность длительности цепи зависимых операций, ведущих к данному буферу. Как только буферные операции расписания определены, операции расписания планируются на максимально поздние плановые даты старта и финиша. Таким образом, вместо управления общим временным резервом путей в сети метод критической цепи концентрируется на управлении оставшимися длительностями буферов, сопоставляя их с оставшейся длительностью цепей операций. 5.6.4 Методы оптимизации ресурсов Примеры методов оптимизации ресурсов, которые можно использовать для корректировки модели расписания, учитывая спрос на ресурсы и предложение ресурсов, включают в себя, среди прочего: Выравнивание ресурсов. Метод регулирования дат старта и финиша операций с учетом ограничений ресурсов в целях уравновешивания спроса на ресурсы с доступным предложением. Выравнивание ресурсов может быть использовано, когда общие или критически важные необходимые ресурсы доступны только в определенное время или только в ограниченном количестве или при переназначении ресурсов, например, когда ресурс был назначен для выполнения двух или более операций в один и тот же период времени (см. рис. 11), или для поддержания использования ресурсов на постоянном уровне. Выравнивание ресурсов зачастую может приводить к изменению первоначального критического пути, обычно к его увеличению. Сглаживание ресурсов. Метод, корректирующий операции модели расписания таким образом, чтобы требования к ресурсам проекта не превышали определенные предустановленные лимиты. В отличие от выравнивания ресурсов при их сглаживании критический путь проекта не меняется, и дата окончания не может быть отсрочена. Другими словами, операции могут быть отложены только в рамках их свободного или общего временного резерва. 5.6.5 Методы моделирования Примеры методов моделирования включают в себя, среди прочего: • Анализ сценариев «что если». Анализ сценариев «что если» — процесс оценки сценариев с целью прогнозирования их воздействия, положительного или отрицательного, на цели проекта. Это анализ вопроса: «Что произойдет, если ситуация будет развиваться по сценарию «Х»?» В этом случае выполняется анализ сети расписания, при котором с помощью модели расписания просчитываются различные сценарии (например, задержка поставки основных компонентов, увеличение длительности отдельных инженерных операций) или моделируется влияние непредвиденных внешних факторов (например, забастовка или изменение процедуры лицензирования). • Имитация. Имитация включает в себя расчет различных длительностей проекта при использовании различных допущений о длительностях операций, обычно используя распределения вероятностей, полученные из оценок по трем с целью учета неопределенности. Наиболее известен метод Монте- Карло, в котором распределение вероятных значений длительности операции определяется для каждой операции и используется для вычисления распределения вероятных конечных результатов всего проекта. 5.6.6 Опережения и задержки См. п. 4.3.3. 5.6.7 Сжатие расписания Методы сжатия расписания используются для сокращения длительности расписания без сокращения содержания проекта, чтобы соответствовать временным ограничениям, ограничивающим датам или иным целям расписания. Методы сжатия расписания включают в себя: • Сжатие. Метод, используемый для сокращения длительности расписания за счет добавления ресурсов с учетом минимизации дополнительных затрат на уменьшение длительности. Примеры сжатия включают в себя одобрение сверхурочной работы, привлечение дополнительных ресурсов или плату за ускорение поставки для операций на критическом пути. • Быстрый проход. Метод сжатия расписания, заключающийся в том, что операции или фазы, которые в обычной ситуации выполнялись бы последовательно, выполняются параллельно на протяжении по крайней мере некоторой части их длительности. Примером является строительство фундамента здания до подготовки всех архитектурных чертежей. 5.6.8 Инструмент составления расписания Автоматизированные инструменты составления расписания включают в себя модель расписания и облегчают процесс составления расписания, генерируя даты старта и финиша на основе информации об операциях, диаграммах сети, ресурсах и длительностях операций, используя анализ сети расписания. 5.7 Контроль расписания: инструменты и методы 5.7.1 Анализ исполнения При проведении анализа исполнения измеряется, сравнивается и анализируется исполнение расписания, например, фактические даты старта и финиша, процент выполнения и оставшаяся длительность выполняемых работ. Могут применяться различные методы, среди прочего, следующие: • Анализ тенденций. В ходе анализа тенденций изучается исполнение проекта с течением времени с целью определения того, ухудшается оно или улучшается. • Метод критического пути. Сравнение прогресса на протяжении критического пути может оказаться полезным при определении статуса расписания. Отклонение на критическом пути будет иметь непосредственное воздействие на дату завершения проекта. • Метод критической цепи. Сравнение объема оставшегося буфера с объемом буфера, необходимым для обеспечения соблюдения срока завершения, может оказаться полезным при определении статуса расписания. • Управление освоенным объемом. Измерения выполнения сроков, такие как отклонение по срокам (ОСР) и индекс выполнения сроков (ИВСР), используются для оценки величины отклонения от первоначального базового расписания. (см. п. 5.4.1). 5.7.2 Программное обеспечение для управления проектом См. п. 4.4.5. 5.7.3 Методы оптимизации ресурсов Методы оптимизации ресурсов включают в себя составление расписания операций и планирование использования ресурсов, необходимых для выполнения этих операций, с учетом как доступности ресурсов, так и сроков проекта. 5.7.4 Методы моделирования См. п. 4.6.5. 5.7.5 Опережения и задержки См. п. 4.3.3. 5.7.6 Сжатие расписания См. п. 4.6.7. 5.7.7 Инструмент составления расписания См. п. 4.6.8. 1. Методы и инструменты управления стоимостью проекта Управление стоимостью проекта включает в себя процессы, необходимые для планирования, оценки, разработки бюджета, привлечения финансирования, финансирования, управления и контроля стоимости, обеспечивающие исполнение проекта в рамках одобренного бюджета. На рис. 12 представлена общая схема следующих процессов управления стоимостью проекта: 1. Планирование управления стоимостью — процесс, устанавливающий политики, процедуры и документацию по планированию, управлению, расходованию и контролю стоимости проекта. 2. Оценка стоимости — процесс приближенной оценки денежных ресурсов, необходимых для выполнения операций проекта. 3. Определение бюджета — процесс консолидации оценочных стоимостей отдельных операций или пакетов работ для создания авторизованного базового плана по стоимости. 4. Контроль стоимости — процесс мониторинга статуса проекта для актуализации стоимости проекта и управления изменениями базового плана по стоимости. Управление стоимостью проекта должно учитывать требования к управлению стоимостью, предъявляемые заинтересованными сторонами. Различные заинтересованные стороны могут измерять стоимость проекта разными способами и в разные моменты времени. Управление стоимостью проекта касается, прежде всего, стоимости ресурсов, необходимых для выполнения операций проекта. Кроме того, при управлении стоимостью проекта следует учитывать, как принимаемые решения скажутся на последующих периодических затратах на эксплуатацию, обслуживание и поддержку продукта, услуги или результата проекта. Во многих организациях прогнозирование и анализ предполагаемого финансового результата продукта проекта выполняется вне рамок проекта. В других, как например, в проектах капитального строительства, управление стоимостью проекта может включать в себя данную работу. III Методы и инструменты управления проектами 5.1 Планирование управления стоимостью: инструменты и методы 5.1.1 Экспертная оценка См. п. 2.2.1 Лекции №1. 5.1.2 Аналитические методы Разработка плана управления стоимостью может включать в себя выбор стратегических вариантов для финансирования проекта, таких как самофинансирование, финансирование путем выпуска акций и финансирование на заемные средства. План управления стоимостью также может детализировать способы привлечения финансирования на ресурсы проекта, например, изготовление, покупку, аренду или лизинг. Подобно другим финансовым решениям, влияющим на проект, эти решения могут оказывать воздействие на расписание и/или риски проекта. Организационные политики и процедуры могут влиять на выбор финансовых методов, используемых в данных решениях. Методы могут включать в себя, среди прочего, период окупаемости, окупаемость инвестиций, внутреннюю норму доходности, дисконтированный поток денежных средств и чистую приведенную стоимость. Оценка экономической эффективности создания проекта предполагает следующий алгоритм действий: - оценка капитальных затрат; - выбор схемы финансирование и оценка капитальных затрат с учетом погашения и обслуживания кредита; - оценка эксплуатационных затрат; - оценка налоговых платежей; - оценка продолжительности жизненного цикла проекта; - оценка общих затрат и их динамики; - расчет ставки дисконтирования; - дисконтирование денежных потоков и расчет NPV; - расчет IRR; - расчет обычного и дисконтированного срока окупаемости Оценка налоговых платежей Оценка налоговых платежей предполагает расчет сумм следующих налогов: • Налог на добавленную стоимость (НДС); • Налог на добычу полезных ископаемых; • Налог на имущество; • Налог на прибыль. и др. Оценка продолжительности жизненного цикла Проекта Полный жизненный цикл Проекта включает в себя следующие этапы: ▪ проектирование; ▪ строительство; ▪ эксплуатация; ▪ утилизация. Оценка общих затрат Расчет общих затрат для каждого года жизненного цикла Проекта может быть произведен по формуле 1. (1) где: CAPEX – сумма капитальных затрат на i-ом году жизненного цикла Проекта; OPEX – сумма годовых эксплуатационных затрат на i-ом году жизненного цикла Проекта; TAX – сумма налоговых платежей на i-ом году жизненного цикла Проекта; Оценка ставки для дисконтирования экономии затрат Один из методов оценки ставки дисконтирования – это расчет средневзвешенной стоимости капитала. Средневзвешенная стоимость капитала (WACC) рассчитывается стандартно по следующей формуле 2: (2) где – стоимость собственного капитала компании; – стоимость заемного капитала компании; – доля собственного капитала в капитале компании (целевой уровень); T – ставка налога на прибыль. В соответствии с моделью CAPM (Capital Asset Pricing Model) требуемая доходность владельцев собственного капитала рассчитывается следующим образом (см. формулу 3): , (3) где – безрисковая ставка процента; – страновой риск; – бета компании (с учетом долговой нагрузки); – рыночная премия за риск. Расчет NPV Расчет NPV выполняется по формуле 4. (4) где: Et – общая сумма доходов на t-м году жизненного цикла Проекта, руб; Ct – общая сумма затрат на t-м году жизненного цикла Проекта, руб; r – ставка дисконтирования, %; t – порядковый номер года жизненного цикла Проекта; T – жизненный цикл Проекта, лет. Расчет IRR Внутренняя норма доходности (прибыли, внутренний коэффициент окупаемости, Internal Rate of Return - IRR) - норма прибыли, порожденная инвестицией. Это та норма прибыли (ставка дисконтирования), при которой чистая текущая стоимость инвестиции равна нулю, или это та ставка дисконта, при которой дисконтированные доходы от проекта равны инвестиционным затратам. Внутренняя норма доходности определяет максимально приемлемую ставку дисконта, при которой можно инвестировать средства без каких-либо потерь для собственника: IRR = r, при NPV =0 (5) Определение значения IRR связано с некоторыми трудностями, поэтому чаще всего значение IRR рассчитывается с помощью финансовой функции ВСД в таблицах Excel, которая возвращает внутреннюю скорость оборота для ряда последовательных операций с наличными, представленными числовыми значениями. Объемы операций не обязаны быть одинаковыми. Однако они должны происходить через равные промежутки времени, например, ежемесячно или ежегодно. Срок окупаемости – продолжительность периода от начального момента до момента окупаемости. Момент окупаемости – наиболее ранний момент времени в расчетном периоде, после которого чистый доход становится и в дальнейшем остается неотрицательным. Срок окупаемости с учетом дисконтирования – продолжительность периода от начального момента до “момента окупаемости с учетом дисконтирования”. Момент окупаемости c учетом дисконтирования – наиболее ранний момент времени в расчетном периоде, после которого чистый дисконтированный доход становится и в дальнейшем остается неотрицательным. 5.1.3 Совещания См. п. 2.2.3 Лекции №1 5.2 Оценка стоимости: инструменты и методы 5.2.1 Экспертная оценка См. п. 2.2.1 Лекции №1. 5.2.2 Оценка по аналогам В оценке стоимости по аналогам используются значения содержания, стоимости, бюджета и длительности или измерения таких величин, как размер, вес и сложность, из предыдущих подобных проектов в качестве основы для оценки аналогичных параметров или показателей текущего проекта. При оценке стоимости по данному методу в качестве основы оценки стоимости текущего проекта принимается фактическая стоимость предыдущих подобных проектов. Этот подход, позволяющий оценивать общую величину, иногда адаптируется в зависимости от известных различий в сложности проекта. 5.2.3 Параметрическая оценка См. п. 4.5.3. 5.2.4 Оценка «снизу вверх» Оценка «снизу вверх» представляет собой метод оценки компонентов работ. Стоимость отдельных пакетов работ или операций оценивается с самой высокой степенью детализации. Детальная стоимость затем суммируется или «свертывается» до более высоких уровней с целью последующего составления отчетов и отслеживания. На стоимость и точность оценки «снизу вверх» обычно влияют размер и сложность каждой отдельной операции или пакета работ. 5.2.5 Оценка по трем точкам См. п. 4.5.4. 5.2.6 Анализ резервов Оценки стоимости могут включать в себя резервы на возможные потери (иногда называемые «средствами на возможные потери») для учета неопределенности стоимости. Резервы на возможные потери — это бюджет в рамках базового плана по стоимости, выделенный для идентифицированных рисков, которые были приняты, и в отношении которых разработаны меры реагирования с целью их снижения или меры реагирования на возможные потери. Управленческие резервы — сумма бюджета проекта, зарезервированная для целей управленческого контроля и сохраненная для выполнения непредвиденной работы, находящейся в пределах содержания проекта. 5.2.7 Стоимость качества Для подготовки оценки стоимости операций могут быть использованы допущения о стоимости качества (cost of quality, COQ). 5.2.8 Программное обеспечение для управления проектом См. п. 4.4.5. 5.2.9 Анализ предложений поставщиков Методы оценки стоимости могут включать в себя анализ возможной стоимости проекта, основанный на соответствующих предложениях от отобранных поставщиков. В случаях, когда поставщик получает проект в результате конкурса, может потребоваться, чтобы команда проекта провела дополнительную оценку стоимости, определила стоимость отдельных поставляемых результатов и рассчитала окончательную стоимость всего проекта. 5.2.10 Методы группового принятия решений См. п. 3.2.4 Лекции №1. 5.3 Определение бюджета: инструменты и методы 5.3.1 Суммирование стоимости Оценки стоимости суммируются по пакетам работ в соответствии с ИСР. Затем оценки стоимости пакетов работ суммируются до компонентов более высоких уровней ИСР (таких как контрольные счета) и далее до целого проекта. 5.3.2 Анализ резервов См. п. 5.2.6. 5.3.3 Экспертная оценка См. п. 2.2.1 Лекции №1. 5.3.4 Исторические связи Любые исторические связи, дающие в результате параметрические оценки или оценки по аналогам, предусматривают использование характеристик (параметров) проекта для разработки математических моделей, чтобы прогнозировать общую стоимость проекта. Такие модели могут быть простыми (например, строительство жилья основано на определенной стоимости квадратного метра жилой площади) или сложными (например, одна модель учета затрат на разработку программного обеспечения использует интегральные поправочные коэффициенты, каждый из которых состоит из множества элементов). Как стоимость, так и точность параметрических моделей и моделей по аналогам может значительно различаться. Они наиболее достоверны, когда: • историческая информация, используемая для разработки модели, точна; • параметры, используемые в модели, легко поддаются количественному выражению; • модели масштабируемы, т. е. применимы к крупным проектам, к небольшим проектам и к фазам проекта. 5.3.5 Сверка лимитов финансирования Расходование денежных средств должно быть согласовано с любыми финансовыми ограничениями по выделению средств на проект. Расхождения между финансовыми ограничениями и плановыми расходами иногда приводят к необходимости пересмотра расписания работ для выравнивания норм расходов. Это может быть реализовано путем внесения в расписание проекта ограничивающих дат для работ. 5.4 Контроль стоимости: инструменты и методы 5.4.1 Управление освоенным объемом Управление освоенным объемом (EVM) — методология, сочетающая оценки содержания, расписания и ресурсов с целью измерения прогресса проекта и достигнутой эффективности. С помощью EVM разрабатывают и осуществляют мониторинг следующих трех ключевых показателей для каждого пакета работ и контрольного счета: • Плановый объем. Плановый объем (ПО) — авторизованный бюджет, выделенный на запланированные работы. Это авторизованный бюджет, выделенный для работы, которую необходимо выполнить в рамках операции или компонента иерархической структуры работ, за исключением управленческого резерва. Совокупный ПО иногда называется базовым планом исполнения (performance measurement baseline, PMB). Общая величина планового объема проекта также известна как бюджет по завершении (БПЗ). • Освоенный объем. Освоенный объем (ОО) — объем выполненных работ, выраженный в показателях авторизованного бюджета, выделенного на данные работы. Это бюджет, связанный с авторизованной работой, которая была выполнена. Измеряемый ОО должен быть связан с PMB, и измеренный ОО не может превышать авторизованный бюджет ПО для данного компонента. • Фактическая стоимость. Фактическая стоимость (ФС) — фактически понесенные затраты на выполнение работ в рамках операции за определенный период времени. Это общие затраты, понесенные при выполнении работ, измеренных ОО. Также осуществляется мониторинг отклонений от одобренного базового плана: • Отклонение по срокам. Отклонение по срокам (ОСР) — показатель исполнения расписания, выражаемый как разница между освоенным объемом и плановым объемом. Количество времени, на которое проект отстает от запланированной даты поставки или опережает ее в определенный момент времени. Это измерение исполнения расписания проекта. Значение его равно освоенному объему (ОО) за вычетом планового объема (ПО). Отклонение по срокам лучше всего использовать вместе с составлением расписания по методу критического пути (CPM) и управлением рисками. Формула: ОСР = ОО - ПО • Отклонение по стоимости. Отклонение по стоимости (ОСТ) — сумма дефицита или излишка бюджета в определенный момент времени, выражаемая как разница между освоенным объемом и фактической стоимостью. Это измерение эффективности выполнения проекта по стоимости. Отклонение по стоимости в конце проекта будет равно разнице между бюджетом по завершении (БПЗ) и фактически израсходованной суммой. ОСТ чрезвычайно важно, так как оно демонстрирует связь между физическим исполнением и израсходованными средствами. Отрицательное ОСТ зачастую невозместимо для проекта. Формула: ОСТ = ОО - ФС. • Индекс выполнения сроков. Индекс выполнения сроков (ИВСР) — показатель эффективности расписания, выражаемый как соотношение освоенного объема к плановому объему. С помощью него измеряется, насколько эффективно команда проекта использует свое время. Иногда он используется вместе с индексом выполнения стоимости (ИВСТ) для прогнозирования окончательных оценок завершения проекта. Значение ИВСР меньше 1,0 указывает на то, что выполнено меньше работ, чем было запланировано. Значение ИВСР больше 1,0 указывает на то, что выполнено больше работ, чем было запланировано. Так как ИВСР измеряет все работы проекта, также необходимо проанализировать исполнение на критическом пути, чтобы определить, будет проект завершен до или после своей плановой даты финиша. Формула: ИВСР = ОО/ПО • Индекс выполнения стоимости. Индекс выполнения стоимости (ИВСТ) — показатель эффективности ресурсов, включенных в бюджет, по стоимости, выражаемый как соотношение освоенного объема к фактической стоимости. Он считается наиболее важной метрикой EVM и измеряет стоимостную эффективность выполненной работы. Значение ИВСТ меньше 1,0 указывает на перерасход средств для выполненной работы. Значение ИВСТ больше 1,0 указывает на недоосвоение средств при исполнении на конкретную дату. Формула: ИВСТ = ОО/ФС На рис. 13 изображены S-образные кривые, отображающие данные ОО проекта, который перерасходует бюджет и отстает от расписания. Рис. 13. Освоенный объем, плановый объем и фактическая стоимость 5.4.2 Прогнозирование По мере реализации проекта команда проекта может разработать прогноз по завершении (ППЗ), который может отличаться от бюджета по завершении (БПЗ), основываясь на исполнении проекта. Разработка ППЗ включает в себя прогнозирование условий и событий, которые возникнут в будущем проекта, на основании информации о текущем исполнении и других знаний, имеющихся на момент прогнозирования. ППЗ обычно рассчитываются как фактическая стоимость, учтенная для завершенных работ, плюс прогноз до завершения (ПДЗ) оставшихся работ. Наиболее широко используемым подходом прогнозирования ППЗ является ручное суммирование «снизу вверх», проводимое руководителем проекта и командой проекта. Метод ППЗ «снизу вверх», используемый руководителем проекта, основан на учтенной фактической стоимости и опыте, полученном на выполненных работах, и требует построения нового прогноза до завершения в отношении оставшихся работ проекта. Формула: ППЗ = ФС + ПДЗ «снизу вверх». ППЗ, разработанный вручную руководителем проекта, быстро сопоставляется с рядом рассчитанных ППЗ, представляющих разнообразные сценарии рисков. При расчете значений ППЗ, как правило, используются кумулятивные значения ИВСТ и ИВСР. Хотя данные EVM позволяют быстро получить множество статистических ППЗ, ниже описаны только три наиболее распространенных метода: • ППЗ для работ ПДЗ, выполненных по заложенным в бюджет ставкам. Данный метод ППЗ использует фактическое исполнение проекта на конкретную дату (благоприятное или неблагоприятное), представленное фактической стоимостью, и предсказывает, что все будущие работы ПДЗ будут выполнены по заложенным в бюджет ставкам. Формула: ППЗ = ФС + (БПЗ - ОО) • ППЗ для работ ПДЗ, выполненных с текущим ИВСТ. Этот метод допускает, что проект продолжится в будущем так же, как он протекал до этого момента. Формула: ППЗ = БПЗ/ИВСТ • ППЗ для работ ПДЗ с учетом обоих факторов ИВСР и ИВСТ. В данном прогнозе работы ПДЗ будут выполняться с эффективностью, которая учитывает индексы выполнения как стоимости, так и сроков. Формула: ППЗ = ФС + [(БПЗ - ОО)/(ИВСТ x ИВСР)] 5.4.3 Индекс производительности до завершения (ИПДЗ) Индекс производительности до завершения (ИПДЗ) — расчетный показатель эффективности выполнения проекта по стоимости, который необходимо достичь с оставшимися ресурсами, чтобы добиться установленного управленческого показателя, выражаемого в виде отношения стоимости выполнения оставшейся части работ к оставшемуся бюджету. Формула для ИПДЗ, основанного на БПЗ: (БПЗ - ОО)/(БПЗ - ФС). ИПДЗ концептуально представлен на рис. 14. Формула для ИПДЗ показана в левом нижнем углу — оставшаяся работа (определена как БПЗ минус ОО), деленная на оставшиеся средства (которые могут рассчитываться либо как БПЗ минус ФС, либо как ППЗ минус ФС). Если кумулятивный ИВСТ ниже базового плана (как показано на рис. 14), все будущие работы по проекту немедленно должны выполняться в соответствии с ИПДЗ (БПЗ) (что отражено в верхней линии на рис. 14), чтобы оставаться в рамках авторизованного БПЗ. Суждение о том, является ли данный уровень исполнения достижимым, принимается на основе ряда соображений, включая риски, расписание и техническое исполнение. Этот уровень исполнения изображен в виде линии ИПДЗ (ППЗ). Формула для ИПДЗ, основанного на ППЗ: (БПЗ - ОО)/(ППЗ - ФС). Формулы EVM представлены в таблице 2. 5.4.4 Анализ исполнения Анализ исполнения предусматривает сравнение выполнения стоимости в динамике по времени, операций расписания или пакетов работ, по которым присутствует перерасход или недоосвоение бюджета, и оценок денежных средств, необходимых для завершения выполняемых работ. Если используется EVM, то определяется следующая информация: • Анализ отклонений. Анализ отклонений при использовании в EVM — это разъяснение (причина, влияние и корректирующие воздействия) отклонений для стоимости (ОСТ = ОО - ФС), расписания (ОСР = ОО - ПО) и отклонения по завершении (ОПЗ = БПЗ - ППЗ). Наиболее часто анализируются отклонения по стоимости и по срокам. • Анализ тенденций. Анализ тенденций предполагает изучение данных об исполнении проекта с течением времени для определения того, улучшается или ухудшается исполнение проекта. • Исполнение освоенного объема. Исполнение освоенного объема предусматривает сравнение базового плана исполнения с фактическим выполнением сроков и стоимости. Таблица 2. Сводная таблица вычислений освоенного объема 5.4.5 Программное обеспечение для управления проектом Для осуществления мониторинга трех показателей EVM (ПО, ОО и ФС) часто используется программное обеспечение для управления проектом, которое графически отображает тенденции и прогнозирует диапазон возможных окончательных результатов проекта. 5.4.6 Анализ резервов См. п.5.2.6. Библиографический список к Лекции №2 (Тема 3): 18. Руководство к Своду знаний по управлению проектами. Project Management Institute (USA). - 5-е изд. - Москва: Олимп-Бизнес, 2014. – 586 с. 19. "Методические рекомендации по оценке эффективности инвестиционных проектов" (утв. Минэкономики РФ, Минфином РФ, Госстроем РФ 21.06.1999 N ВК 477)