question:теперь нужно отвечать по этому конспекту: 1 Тема 2 Основы проектного управления Вопросы темы 1. Основные понятия и определения проектного управления 2. Классификация проектов 3. Актуальность управления проектами 4. Управление проектом, программой, портфелем и операционной деятельностью 5. Управление проектами и стратегия предприятия 6. Компоненты управления проектами 7. Данные и информация управления проектом 8. Бизнес-документы управления проектом 9. Показатели успеха проекта 10. Международные стандарты управления проектами 11. Методология и адаптация 12. Методология и адаптация 1. Основные понятия и определения проектного управления Проект – то, что задумывается или планируется. Проект – процесс перехода из исходного состояния (вход) в конечное (результат) при участии ряда ограничений и механизмов. Проект – это документально оформленный план мероприятий. Проект – это временное бизнес-предприятие (в смысле предпринимательство, бизнес), направленное на создание уникального продукта или результата. Отличие проекта от серийной производственной деятельности заключается в том, что проект – однократная, уникальная, не циклическая деятельность. Серийный выпуск продукции не имеет заранее определенного окончания во времени и зависит лишь от наличия и величины спроса. Производственные циклы в чистом виде не являются проектами, однако в последнее время проектный подход часто применяется и в производстве (например, проекты увеличения программы выпуска до конкретного уровня в течение установленного периода при наличии определенного набора ресурсов). Таблица 2.1 – Сравнительные характеристики традиционного и проектного управления Характеристика Традиционное управление Проектное управление Ответственность За поддержание статус-кво За возникающие изменения Полномочия Определены структурой управления Не определены или перераспределены между участниками проекта (программы, портфеля) Круг задач Устойчивый Меняющийся Выполнение работ В стабильных организационных структурах В структурах, действующих в пределах проектного цикла Круг задач, подлежащих выполнению Не меняется В нестандартной, инновационной, изменчивой среде проекта Основная задача Оптимизация Разрешение конфликтов Успех определяется Достижением промежуточных функциональных результатов (целей) Достижением установленных конечных целей Изменчивость условий и ситуаций Ограниченная Высокая 2 ♦ Уникальные продукт, услуга или результат. Проекты реализуются для достижения целей путем создания поставляемых заказчику результатов. Цель – конечный результат, на который должны быть направлены работы; стратегическая позиция, которую следует занять; задача, которую следует решить; результат, который следует получить; продукт, который следует произвести; или услуга, которую следует оказать. Поставляемый заказчику результат – это любой уникальный и поддающийся проверке продукт, результат или способность оказать услугу, которые необходимо получить для завершения процесса, фазы или проекта. Поставляемые результаты могут быть материальными и нематериальными. Достижение целей проекта может произвести один или несколько из перечисленных ниже поставляемых заказчику результатов: − уникальный продукт, который может быть либо компонентом другого продукта, либо улучшением или исправлением какого-то продукта, либо сам по себе новым конечным продуктом; − уникальная услуга или способность предоставлять услугу; − уникальный результат, такой как конечный результат проекта или документ; − уникальное сочетание одного или нескольких продуктов, услуг или результатов. Те или иные элементы могут повторяться в некоторых поставляемых результатах и операциях проекта. Данное повторение не меняет фундаментальных и уникальных характеристик работ проекта. Однако каждый строительный проект остается уникальным по своим главным характеристикам. Проекты предпринимаются на всех уровнях предприятия. В проекте могут участвовать один или несколько человек. В проекте может участвовать одно структурное подразделение предприятия или несколько структурных подразделений различных предприятий. ♦ Временное бизнес-предприятие. Временный характер проектов указывает на наличие определенного начала и окончания. Определение «временный» не обязательно означает, что проект рассчитан на короткое время. Окончание проекта наступает, когда верным является одно или несколько из следующих утверждений: − достигнуты цели проекта; − цели не будут или не могут быть достигнуты; − финансирование на осуществление проекта исчерпано или больше не может быть выделено; − потребность в проекте отпала; − исчерпаны человеческие или материальные ресурсы; − проект прекращается по юридическим причинам или соображениям целесообразности. Проекты являются временными, но их поставляемые заказчикам результаты могут существовать и после окончания проекта. Проекты могут давать поставляемые результаты социального, экономического, материального или экологического характера. ♦ Проекты служат движущей силой изменений на серийных предприятиях и в организациях. С точки зрения бизнеса, цель проекта состоит в переходе предприятия из одного состояния в другое для достижения конкретной цели (см. рис. 2.1). Обычно считается, что до начала проекта предприятие находится в исходном состоянии. А желаемый результат изменения в ходе осуществления проекта описывается как будущее состояние. Некоторые проекты могут предполагать создание переходного состояния, когда выполняется несколько вытекающих один из другого шагов для достижения будущего состояния. Результатом успешного завершения проекта является переход предприятия к будущему состоянию и достижение конкретной цели. 3 Рис. 2.1 – Переход предприятия к новому состоянию с помощью проекта ♦ Проекты позволяют создавать бизнес-ценность. Бизнес-ценность – чистая, количественно определяемая выгода, получаемая от проекта. Бизнес-ценностью считается полученная выгода в таких формах, как время, деньги, товары или нематериальные активы, в обмен на какое-то вложение. Бизнес-ценность проектов – выгода, которую в результате осуществления конкретного проекта получают заинтересованные стороны. Выгода от реализации проекта может быть материальной, нематериальной или и той, и другой. Примеры материальных элементов: денежные средства, акционерный капитал, инженерные сети, основные средства, инструменты, доля рынка. Примеры нематериальных элементов: гудвилл (деловая репутация и коммерческий опыт), узнаваемость марки, общественное благо, товарные знаки, соответствие стратегии, репутация. ♦ Контекст инициации проекта. Руководители предприятия инициируют проекты в ответ на факторы, влияющие на состояние дел на предприятиях. Существует четыре основных категории данных факторов, которые позволяют лучше понять контекст проекта (см. рис. 2.2): = обеспечение соответствия нормативно-правовым, юридическим или социальным требованиям; = удовлетворение запросов или потребностей заинтересованных сторон; = реализация или изменение бизнес- или технологических стратегий; = создание, совершенствование или исправление продуктов, процессов или услуг. Данные факторы влияют на текущую операционную деятельность и бизнес-стратегии предприятия. Руководители реагируют на данные факторы с целью обеспечить жизнеспособность предприятия. Проекты дают предприятиям средство для успешного осуществления изменений, необходимых для принятия мер в отношении данных факторов. Данные факторы должны быть, в конечном счете, увязаны со стратегическими целями предприятия и бизнес-ценностью каждого проекта. Конкретные факторы можно сопоставить с одной или несколькими основными мотивами инициации проектов. Текущее состояние Будущее состояние Время Бизнес- ценность (результат) Операции проекта: 1. 2. 3. … n. 4 Рис. 2.2 – Контекст (факторы) инициации проекта Таблица 2.2 – Факторы, которые вызывают необходимость инициации проекта Мотив инициации проекта Факторы инициации проекта Обеспечение соответствия нормативно- правовым или социальным требованиям Удовлетворение запросов или потребностей заинтересованных сторон Создание, совершенствовани е или исправление продукта или процесса Разработка (изменение) и реализация бизнес- стратегий или технологических стратегий Новая технология ✓ ✓ Силы конкуренции ✓ Проблемы материалов ✓ ✓ Трансакционные издержки ✓ Спрос на рынке ✓ ✓ ✓ Экономические изменения ✓ Требования заказчика ✓ ✓ Требования заинтересованной стороны ✓ Экологические требования ✓ ✓ ✓ Совершенствовани е бизнес-процесса ✓ Благоприятная стратегическая возможность, конъюнктура или потребность бизнеса ✓ ✓ Социальная потребность ✓ ✓ Проект Обеспечение соответствия нормативно- правовым или социальным требованиям Создание, совершенствование или исправление продукта или процесса Удовлетворение запросов или потребностей заинтересованных сторон Разработка (изменение) и реализация бизнес- стратегий или технологических стратегий 5 2. Классификация проектов Можно выделить некоторые особенности, отличающие отдельные типы проектов друг от друга. Классификация проектов представлена на рис. 2.3. Инвестиционные проекты. Это проекты, для которых:  определены и фиксированы цель, расходы, срок завершения и продолжительность;  требуемые ресурсы и фактическая стоимость проекта зависят в первую очередь от хода выполнения работ и прогресса каждого проекта;  требуемые мощности должны предоставляться в соответствии с графиком и сроком готовности этапов и завершения проекта. Классифика- ционные признаки Типы проектов По уровню проектов Проект Программа Портфель По масштабу (размеру) проекта Малый Средний Мега проект По сложности Простой Организа- ционно сложный Технически сложный Ресурсно- сложный Комплексно- сложный По срокам реализации Краткосроч- ный Средний Перспективный По требованиям к качеству и способам его обеспечения Мультипроект Монопроект По характеру проекта/ уровню участников Международный (совместный) Отечественный: − частный − государственный − территориальный − местный По характеру целевой задачи проекта Антикризисный Реформирование/реструктуризация Маркетинговый Инновационный Образовательный Чрезвычайный По объекту инвестиционн ой деятельности Финансовый Реальный Инвестиционный Инвестиционный По главной причине возникновени е проекта Открывшиеся возможности Необходимость структурно- функциональных преобразований Реорганизация Чрезвычайная ситуация Реструктуризация Реинжиниринг Рис. 2.3 – Классификация проектов Научно-исследовательские и инновационные проекты. Проекты по разработке нового продукта или услуг, проведению научных исследований характеризуются следующими особенностями:  главная цель проекта четко определена, но отдельные цели должны уточняется по мере достижения частных результатов; 6  срок завершения и продолжительность проекта определены заранее, желательно их точное соблюдение; однако они должны также корректироваться в зависимости от полученных промежуточных результатов и общего прогресса проекта;  планирование расходов на проект часто зависит от выделенных ассигновании и меньше от прогресса проекта;  основные ограничения связаны с лимитированной возможностью использования мощностей (оборудования и специалистов). Организационные проекты. Реформирование предприятия, реализация концепции управления, создание новой организации или проведение форума, как проекты, характеризуются следующим:  цели проекта заранее определены, однако, результаты проекта количественно и качественно труднее определить, чем в первых двух случаях, так как они связаны, как правило, с организационным улучшением системы;  срок и продолжительность задаются предварительно;  ресурсы предоставляются по мере возможности;  расходы на проект фиксируются и подвергаются контролю на экономичность, однако, требуют корректировок по мере прогресса проекта. Экономические проекты. Такие проекты (приватизация предприятий, создание аудиторской системы, введение новой системы налогов, стратегии развития отраслей и т.п.) обладают следующими особенностями:  целью проектов является улучшение экономических показателей функционирования системы, поэтому их оценить значительно труднее, чем в ранее рассмотренных случаях; главные цели предварительно намечаются, но требуют корректировки по мере прогресса проекта;  то же самое относится и к срокам проекта;  ресурсы для проекта предоставляются по мере необходимости в рамках возможного;  расходы определяются предварительно, контролируются на экономичность и уточняются по мере прогресса проекта. Это означает, что экономические результаты должны быть достигнуты в фиксированные сроки при установленных расходах, а ресурсы предоставляются по потребности. Социальные проекты. Этот вид проектов (реформирование системы социального обеспечения, здравоохранения, социальная защита необеспеченных слоев населения, преодоление последствий чрезвычайных ситуаций) обладает наибольшей неопределенностью и имеет свою специфику:  цели только намечаются и должны корректироваться по мере достижения промежуточных результатов, количественная и качественная их оценка существенно затруднена;  сроки и продолжительность проекта зависит от вероятностных факторов или только намечаются и впоследствии подлежат уточнению;  расходы на проект, как правило, зависят от бюджетных ассигнований;  ресурсы выделяются по мере потребности в рамках возможного. 3. Актуальность управления проектами Управление проектом предполагает приложение знаний, навыков, инструментов и методов к работам проекта для удовлетворения требований, предъявляемых к проекту. Управление проектом осуществляется посредством надлежащего применения и интеграции процессов управления проектом, установленных для данного проекта. Управление проектом дает предприятиям возможность исполнять проекты результативно и эффективно. 7 Управление проектами – методология (искусство) организации, планирования, руководства, координации трудовых, финансовых и материально-технических ресурсов на протяжении проектного цикла, направленная на эффективное достижение его целей путем применения современных методов, техники и технологии управления для достижения определенных в проекте результатов по составу и объему работ, стоимости, времени, качеству и удовлетворению участников проекта. Сложная интегрированная природа управления проектами описывается через процессы (функции) управления, и их взаимосвязи. Результативное управление проектом помогает отдельным лицам, группам, а также государственным и частным предприятиям: ♦ достигать бизнес-целей; ♦ удовлетворять ожидания заинтересованных сторон; ♦ быть более предсказуемыми; ♦ повышать вероятность успеха; ♦ поставлять нужный продукт в нужное время; ♦ разрешать проблемы и вопросы; ♦ своевременно реагировать на риски; ♦ оптимизировать использование ресурсов предприятия; ♦ выявлять, возобновлять или прекращать неудачные проекты; ♦ управлять ограничениями (например, содержанием, качеством, расписанием, стоимостью, ресурсами); ♦ балансировать влияние ограничений на проект (например, увеличение содержания может потребовать увеличения стоимости или сроков); ♦ лучше управлять изменениями. Плохое управление или отсутствие управления проектом может привести к: ♦ нарушению установленных сроков, ♦ превышению стоимости, ♦ плохому качеству, ♦ доработкам, ♦ бесконтрольному расширению проекта, ♦ репутационным потерям предприятия, ♦ неудовлетворенности заинтересованных сторон, ♦ неспособности достичь целей, ради которых проект был организован. Проекты – это главный способ создания ценности и выгод на предприятии, поэтому руководителям предприятий необходимо уметь осуществлять управление в условиях ограниченных бюджетов, сжатых сроков, недостатка ресурсов и быстро меняющихся технологий и конъюнктуры среды. Бизнес-среда характеризуется высокой динамичностью с ускоряющимися темпами изменений. Чтобы сохранить конкурентоспособность в условиях мировой экономики, компании активно переходят к управлению проектами с целью добиться неуклонного получения бизнес-ценности. Результативное и эффективное управление проектом является стратегической компетенцией. Оно позволяет предприятию: ♦ увязывать результаты проекта с бизнес-целями, ♦ более успешно конкурировать на своих рынках, ♦ добиваться устойчивости предприятия, ♦ реагировать на воздействия изменений бизнес-среды на проекты с помощью надлежащей корректировки планов управления проектами. 8 4. Управление проектом, программой, портфелем и операционной деятельностью Применение процессов, инструментов и методов управления проектом создает на предприятии прочную основу для достижения поставленных целей и решения стоящих перед ним задач. Проект может управляться по трем разным сценариям:  как самостоятельный проект (вне портфеля или программы),  в рамках программы,  в рамках портфеля. Когда проект реализуется в составе портфеля или программы, руководитель проекта взаимодействует с руководителем портфеля и программы. Например, для осуществления нескольких целей и задач предприятия может потребоваться осуществить несколько проектов. В таких ситуациях проекты могут быть сгруппированы вместе в одной программе. Программа – это ряд связанных друг с другом проектов, вспомогательных программ и мероприятий программы, управление которыми координируется для получения выгод, которые были бы недоступны при управлении ими по отдельности. Программа не означает «большой проект». Очень большой проект можно назвать «мегапроектом» (стоимость 1 млрд. долл. США и более, оказывают влияние на 1 млн. человек и более и осуществляются в течение многих лет). Некоторые предприятия могут использовать портфель проектов с целью результативного управления несколькими программами и проектами, которые осуществляются одновременно в данное время. Портфель – это проекты, программы, вспомогательные портфели и операционная деятельность, управляемые как группа с целью достижения стратегических целей. На рис. 2.4 представлен пример взаимосвязей между портфелями, программами, проектами и операционной деятельностью в конкретной ситуации. Рис. 2.4 – Портфель, программы, проекты и операционная деятельность Стратегия предприятия Портфель проектов предприятия Общие ресурсы и заинтересованные стороны Проект 1 Проект 2 Проект 3 Проект 4 Проект 5 Проект 6 Проект 7 Проект 8 Проект 9 Опера- ции Программа В1 Программа С Программа А Программа В Портфель А 9 Управление программой и управление портфелем отличаются от управления проектом по их жизненным циклам, операциям, целям, основной задаче и выгодам. Однако портфели, программы, проекты и операционная деятельность во многих случаях связаны с одними и теми же заинтересованными сторонами и могут требовать использования тех же ресурсов (см. рис. 2.4), что может вести к возникновению конфликтной ситуации на предприятии. Ситуация такого типа усиливает необходимость координации внутри предприятия с помощью управления портфелями, программами и проектами в целях обеспечения реалистичного баланса на предприятии. На рис. 1.3 представлена схема структуры типового портфеля, на которой показаны взаимосвязи между программами, проектами, общими ресурсами и заинтересованными сторонами. Компоненты портфеля сгруппированы вместе в целях обеспечения результативного руководства и управления этой работой, которая помогает реализовать стратегические и первоочередные задачи предприятия. Организационное планирование и планирование портфеля оказывают влияние на компоненты в результате приоритизации с учетом рисков, финансирования и других соображений. Представление в разрезе портфеля позволяет предприятиям увидеть, как стратегические цели представлены в портфеле. Данное представление в разрезе портфеля дает также возможность обеспечить реализацию и координацию руководства соответствующими портфелями, программами и проектами. Данное согласованное руководство делает возможным авторизованное выделение человеческих, финансовых и материальных ресурсов с учетом ожидаемых показателей и выгод. Представление об управлении проектом, программой и портфелем с точки зрения предприятия: ♦ в центре управления программой и проектом стоит задача осуществления программ и проектов «правильным» образом, ♦ основная задача управления портфелем состоит в осуществлении «правильных» программ и проектов. В таблице 2.3 представлен сравнительная характеристика портфелей, программ и проектов. Таблица 2.3 – Сравнительная характеристика управления проектом, программой и портфелем Критерий сравнения Проекты Программы Портфели Определение Временное бизнес- предприятие, направленное на создание уникального продукта, результата. Ряд связанных друг с другом проектов, вспомогательных программ, операций, управление которыми координируется для получения выгод, которые были бы не достигнуты при управлении ими по отдельности. Проекты, программы, вспомогательные портфели и операции, управляемые в согласованном порядке для достижения стратегических целей. Содержание Имеет конкретные цели. Последовательно уточняется на всем протяжении жизненного цикла проекта. Охватывает содержание входящих в них компонентов. Приносят выгоды предприятию, благодаря поставке результатов заказчику компонентов программы в согласованном и взаимодополняющем порядке. Охватывает все предприятие и изменяется вместе с его стратегическими целями. Изменение Осуществляются через процессы, необходимые Осуществляется в порядке, который На основе постоянного мониторинга изменений 10 Критерий сравнения Проекты Программы Портфели для управления проектами и контроля над ними. позволяет принять и адаптировать работу с учетом изменения, насколько это необходимо для оптимизации поставки заказчику конечных результатов по мере поставки компонентами программы промежуточных результатов в рамках более широких внутренних и внешних сред. Планирование Путем последовательного уточнения информации высокого уровня в подробных планах на всем протяжении жизненного цикла проекта. На основании планов высокого уровня, в которых отслеживаются взаимозависимости и процессы компонентов программы. Планы программ используются в целях определения параметров планирования на уровне их компонентов. Путем создания и реализации процессов и коммуникаций, относящихся к портфелю в целом. Управление Осуществляется руководителем команды проекта для достижения целей проекта Осуществляется руководителем программ с целью обеспечения поставки результата от программы путем координации процессов и операций компонентов программы. Осуществляется руководителем портфелей путем координации работы сотрудников управления портфелями, программами и проектами, к которым отнесены соответствующие компетенции по имеющим для портфеля в целом вопросы. Мониторинг и контроль Ведут руководители проектов по производству продуктов или результатов, с целью выпуска которых данный проект был предпринят Ведут руководители программ по процессам компонентов программы для обеспечения достижения общих целей, исполнения расписания, бюджета и получения выгод от программы, ее результатов. Ведут руководители портфелей в части отслеживания стратегических изменений и распределения совокупных ресурсов, результатов исполнения и рисков портфеля. Успех Определяется качеством продукта или результата, проекта в целом, соблюдением сроков, исполнением бюджетов и уровня удовлетворенности заказчика. Определяется способностью программы дать предприятию ожидаемый от нее результат, выгоду, эффективности и результативность в части доставки заказчикам этих результатов и выгод. Определяется совокупным исполнением бюджета и реализации заказчику выгод и результатов в рамках портфеля. Управление программой – применение к программе знаний, навыков и принципов для достижения целей программы и получения выгод и контроля, которые были бы недоступны при управлении компонентами программы по отдельности. Компонент программы – проекты и другие программы, входящие в состав данной программы. Управление проектом 11 сосредоточено на взаимозависимостях внутри проекта с целью определить оптимальный подход к управлению им. При управлении программой основное внимание уделяется взаимозависимостям между проектами, а также между уровнями проекта и программы с целью определить оптимальный подход к управлению ими. Действия, связанные с данными взаимозависимостями между уровнями программы и проекта, могут включать в себя: ♦ приведение в соответствие с организационным или стратегическим направлением, затрагивающим цели и задачи программы и проекта; ♦ распределение содержания программы по ее компонентам; ♦ управление взаимозависимостями между компонентами программы с целью наилучшего удовлетворения потребностей программы; ♦ управление рисками программы, которые могут оказать влияние на различные проекты в составе программы; ♦ разрешение ограничений и конфликтов, затрагивающих несколько проектов в рамках одной программы; ♦ разрешение проблем между проектами-компонентами и уровнем программы; ♦ управление запросами на изменения в рамках общей структуры руководства; ♦ распределение бюджетных средств на разные проекты в составе программы; ♦ обеспечение реализации выгод от программы и проектов-компонентов. Портфель – проекты, программы, вспомогательные портфели и операционная деятельность, управляемые как группа для достижения стратегических целей. Управление портфелем – централизованное управление одним или несколькими портфелями для достижения стратегических целей. Программы или проекты портфеля не обязательно являются взаимозависимыми или связанными непосредственно. Целью управления портфелями является: ♦ выработка решений по инвестициям на предприятии; ♦ выбор оптимального сочетания программ и проектов для достижения стратегических целей; ♦ обеспечение прозрачности процесса принятия решений; ♦ приоритизация распределения человеческих и материальных ресурсов; ♦ повышение вероятности осуществления желаемой окупаемости инвестиций; ♦ централизация управления совокупным профилем рисков от всех компонентов. Управление портфелем призвано также соблюсти соответствие портфеля стратегическим задачам предприятия и согласование с ними. Задача максимизации ценности портфеля требует тщательного изучения всех компонентов, которые входят в состав портфеля. Приоритет компонентов определяется так, чтобы для тех из них, которые вносят наибольший вклад в достижение стратегических целей предприятия, были выделены требуемые финансовые, человеческие и материальные ресурсы. Из набора разнообразных проектов предприятие может выбрать ряд связанных проектов и включить их в один портфель. Управление операционной деятельностью – область, которая находится за рамками содержания формального управления проектом и связано с текущим производством продуктов и/или услуг. Оно обеспечивает постоянную эффективность операционной деятельности за счет оптимального использования ресурсов, необходимых для удовлетворения потребностей заказчиков. Это связано с управлением процессами, которые превращают входы (например, материалы, компоненты, энергию и труд) в выходы (например, продукты, товары и/или услуги). Целью конкретного проекта могут быть изменения в операционной деятельности предприятия – особенно в случае наличия существенных изменений в операционной деятельности в результате создания нового продукта или услуги. Постоянная операционная деятельность находится за рамками содержания проекта, однако существуют точки 12 пересечения двух областей. Проекты могут пересекаться с операционной деятельностью в разных точках на протяжении жизненного цикла продукта, например: ♦ в случае разработки нового продукта, усовершенствования продукта или расширения выпуска продукции, ♦ при улучшении операционной деятельности или процесса разработки продукта, ♦ в конце жизненного цикла продукта, ♦ в каждой завершающей фазе. В каждой точке поставляемые результаты и знания передаются между проектами и операционной деятельностью для дальнейшего применения. Это осуществляется через выделение ресурсов или знаний проекта для операционной деятельности или через выделение операционных ресурсов для проекта. 5. Управление проектами и стратегия предприятия Портфели, программы и проекты согласуются со стратегиями предприятия или обусловлены ими и различаются тем, каким образом каждый(-ая) из них способствуют достижению стратегических целей. ♦ Управление портфелем обеспечивает согласование портфелей со стратегиями предприятия путем выбора правильных программ или проектов, приоритизации работ и выделения необходимых ресурсов. ♦ Управление программой обеспечивает согласование компонентов данной программы друг с другом и контроль взаимозависимостей с целью реализации определенных выгод. ♦ Управление проектом обеспечивает достижение целей и решение задач предприятия. Проекты, входящие в состав программ или портфелей, являются средством достижения целей и решения задач предприятия. Это часто осуществляется в связи со стратегическим планом, который является главным фактором регулирования инвестиций в проекты. Согласованность со стратегическими бизнес-целями предприятия может быть достигнута в результате систематического управления портфелями, программами и проектами путем применения организационного управления проектами. Организационное управление проектами – это модель, в рамках которой осуществляется интеграция управления портфелями, программами и проектами с организационными инструментами реализации в целях достижения стратегических целей. Назначение организационного управления проектами – обеспечить инициацию предприятием «правильных» проектов и выделение, по мере целесообразности, всех необходимых ресурсов, а также обеспечить понимание на всех уровнях предприятия стратегической перспективы, инициатив, которые служат проведению в жизнь данной перспективы, целей и поставляемых результатов. На рис. 2.5 показана организационная среда, в которой осуществляется взаимодействие стратегии, портфеля, программ, проектов и операционной деятельности предприятия. 13 Рис. 2.5 – Организационное управление проектом 6. Компоненты управления проектами В составе проектов имеется несколько ключевых компонентов, которые, при условии результативного управления, обеспечивают их успешное завершение. Эти компоненты взаимодействуют друг с другом в ходе управления проектом. Краткое описание ключевых компонентов приведено в таблице 2.4. Таблица 2.4 – Описание ключевых компонентов проекта Ключевой компонент Краткое описание Жизненный цикл проекта Набор фаз, через которые проходит проект с момента его начала до момента завершения. Фаза проекта Совокупность логически связанных операций проекта, завершающихся достижением одного или нескольких установленных результатов. Ворота фазы (веха) проекта Обзор в конце фазы, во время которого принимается решение о переходе к следующей фазе, о продолжении фазы с изменением или о завершении программы или проекта. Процессы управления проектом Систематическая последовательность операций, направленная на достижение конечного результата, когда один или несколько входов используются для последующих действий с целью получения одного или нескольких выходов (результатов). Группа процессов управления проектом Логическое объединение управленческих входов, инструментов и методов, а также выходов проекта. Группы процессов управления проектом включают: инициацию, планирование, исполнение, мониторинг и контроль и закрытие. Группы процессов управления проектом не являются фазами проекта. Область знаний по управлению проектом Выделенная область управления проектом, определяемая ее требованиями к знаниям и описываемая в терминах ее составных процессов, практик, входов, выходов, инструментов и методов. Стратегия: цели предприятия Портфель: решения по стоимости Программы и проекты: поставка результатов Операции: реализация бизнес- ценности Конъюнктура внутренней и внешней среды Анализ исполнения по стоимости Анализ влияния на бизнес Анализ и корректировка портфеля 14 Рис. 2.6 – Взаимодействие ключевых компонентов в рамках проекта Жизненный цикл проекта – это набор фаз, через которые проходит проект с момента его начала до момента завершения. Он определяет основные рамки управления проектом. Данные основные рамки действуют вне зависимости от особенностей конкретных работ по осуществлению проекта. Фазы проекта могут быть последовательными, итеративными или накладываться друг на друга. Все проекты могут иметь структуру жизненного цикла в общем виде представленную на рис. 2.6. Жизненные циклы проекта могут быть предиктивными или адаптивными. В рамках жизненного цикла проекта обычно выделяется одна или более фаз, которые связаны с разработкой продукта, услуги или результата. Их называют жизненный цикл развития. Жизненные циклы развития могут быть предиктивного, итеративного, инкрементного, адаптивного или смешанного типа. ♦ В случае предиктивного жизненного цикла содержание, сроки и стоимость проекта определяются на начальных фазах жизненного цикла. Любые изменения содержания требуют тщательного управления. Предиктивные жизненные циклы могут также называться жизненными циклами типа водопада. ♦ В случае итеративного жизненного цикла содержание проекта обычно определяется на начальной стадии жизненного цикла проекта, однако оценки сроков и стоимости проекта меняются в рабочем порядке по мере расширения понимания продукта командой проекта. Итеративность определяет разработку продукта путем выполнения ряда повторяющихся циклов, в то время как инкрементность определяет последовательное наращивание функциональности продукта. ♦ В случае инкрементного жизненного цикла проекта поставляемый результат производится путем выполнения ряда итераций, которые последовательно наращивают функциональность в рамках заданного временного интервала. Поставляемый результат содержит такие необходимые и достаточные характеристики, чтобы считаться полным только после заключительной итерации. Жизненный цикл проекта (фазы) Группы процессов Процессы Процессы Процессы Процессы Процессы инициации планирования исполнения мониторинга закрытия и контроля – ворота фазы (веха) Начало ׀ Организация и подготовка ׀ Выполнение работ ׀ Окончание ׀ Ш к а л а ׀ в р е м е н и ׀ ׀ ׀ 10 областей знаний 15 ♦ Адаптивные жизненные циклы являются гибкими (agile), итеративными или инкрементными. Подробное содержание определяется и одобряется перед началом каждой итерации. Адаптивные жизненные циклы называют также гибкими (agile) или жизненными циклами, управляемыми изменениями. ♦ Смешанный жизненный цикл представляет собой сочетание предиктивного и адаптивного жизненного цикла. Те элементы проекта, которые хорошо изучены или имеют заранее установленные требования, осуществляются по предиктивному жизненному циклу развития, а те, которые находятся в состоянии формирования – по адаптивному жизненному циклу развития. Наилучший тип жизненного цикла для каждого проекта определяет команда управления проектом. Жизненный цикл проекта должен обладать достаточной гибкостью, чтобы его можно было изменять с учетом различных факторов, включенных в проект. Гибкость жизненного цикла может быть обеспечена путем: ♦ определения процесса или процессов, осуществление которых необходимо в каждой фазе; ♦ осуществления процесса или процессов, определенных для каждой фазы; ♦ корректировки различных качеств фазы (например, название, длительность, критерии выхода и критерии входа). Жизненные циклы проекта существуют независимо от жизненных циклов продукта, который может быть произведен в результате проекта. Жизненный цикл продукта – это набор фаз, которые представляют эволюцию продукта, от концепции через поставку, рост, зрелость и до изъятия из обращения. Фаза проекта – совокупность логически связанных операций проекта, завершающихся достижением одного или ряда поставляемых результатов. Фазы жизненного цикла можно описать с использованием различных свойств. Свойства конкретной фазы могут быть измеряемыми и уникальными. Свойства могу включать в себя, среди прочего: ♦ название (например, «Фаза А», «Фаза В», «Фаза 1», «Фаза 2», «Фаза подготовки предложения»); ♦ количество (например, три фазы в проекте, пять фаз в проекте); ♦ длительность (например, 1 неделя, 1 месяц, 1 квартал); ♦ требования к ресурсам (например, человеческие ресурсы, сооружения, оборудование); ♦ критерии входа (события) для проекта, чтобы перейти в данную фазу (например, необходимые одобрения задокументированы, необходимые документы разработаны); ♦ критерии выхода (события) для проекта, чтобы завершить данную фазу (например, одобрения задокументированы, документы разработаны, поставляемые результаты завершены). Проекты можно разделить на особые фазы или подкомпоненты. Данные фазы или подкомпоненты обычно получают названия, которые указывают на вид работ, выполняемых в этой фазе. В качестве примеров названий фаз можно привести, среди прочего, следующее: ♦ разработка концепции, ♦ анализ целесообразности, ♦ требования заказчика, ♦ разработка решения, ♦ проектирование, ♦ прототипирование, ♦ строительство, ♦ испытания, ♦ передача, ♦ ввод в эксплуатацию, ♦ анализ контрольных событий, ♦ извлеченные уроки. 16 Фазы проекта могут устанавливаться на основе различных факторов, включая, среди прочего: ♦ потребности управления; ♦ характер проекта; ♦ уникальные характеристики предприятия, отрасли или технологии; ♦ элементы проекта включают в себя, среди прочего, технологию, проектирование, бизнес, процесс или юридическую часть; ♦ точки принятия решений (например, о выделении финансирования, продолжении или прекращении проекта и анализе контрольных событий). Использование нескольких фаз может обеспечить углубленное понимание процесса управления проектом. Это также позволяет дать оценку исполнения проекта и совершить необходимые корректирующие или предупреждающие действия в последующих фазах. Ключевым компонентом, используемым с фазами проекта, является анализ фаз (ворота фазы, веха проекта). Ворота фазы – веха проекта проводятся в конце фазы. Исполнение и прогресс проекта сверяются с документами проекта и бизнес-документами, включая, помимо прочего: ♦ бизнес-кейс проекта, ♦ устав проекта, ♦ план управления проектом, ♦ план управления выгодами. Решение (например, продолжать или прекратить проект) принимается по результатам данной сверки с целью принятия решения: ♦ перейти к следующей фазе, ♦ перейти к следующей фазе с изменениями, ♦ прекратить проект, ♦ остаться в данной фазе, ♦ повторить фазу или некоторые ее элементы. Пример содержания фаз жизненного цикла проекта строительства цеха приведен в таблице 2.5. Таблица 2.5 – Содержание фаз жизненного цикла проекта строительства цеха Начальная (прединвестиционная) Инвестиционная (строительная) Эксплуатаци- оннаяПрединвестици- онные исследования Разработка проектно-сметной документации, планирование проекта и подготовка к строительству Проведение торгов и заключение контрактов; организация закупок и поставок, подготови- тельные работы Строительно- монтажные работы Завершение строительной фазы проекта Изучение прогнозов и направлений развития (страны, региона, города). Формирование инвестиционног о замысла. Подготовка ходатайства (декларации) о намерениях. Разработка плана проектно- изыскательских работ. Задание на разработку технико- экономического обоснования (ТЭО) проекта, строительства. Согласование, экспертиза и утверждение ТЭО Тендеры на проектно- изыскательски е работы и заключение контрактов. Тендеры на поставку оборудования и заключение контрактов. Тендеры на подрядные работы и Разработка оперативного плана строительства. Разработка графиков работы машин. Выполнение строительно- монтажных работ. Мониторинг и контроль. Пусконаладо чные работы. Сдача- приемка объекта. Закрытие контракта. Демобилизац ия ресурсов. Анализ результатов. Эксплуатаци я. Ремонт. Развитие производства . Закрытие проекта: − вывод из эксплуатац ии − демонтаж оборудован ия 17 Начальная (прединвестиционная) Инвестиционная (строительная) Эксплуатаци- оннаяПрединвестици- онные исследования Разработка проектно-сметной документации, планирование проекта и подготовка к строительству Проведение торгов и заключение контрактов; организация закупок и поставок, подготови- тельные работы Строительно- монтажные работы Завершение строительной фазы проекта Предварительно е согласование инвестиционног о замысла. Составление и регистрация оферт. Разработка обоснования инвестиций, оценка жизнеспособнос ти проекта (проекта, строительства). Выдача задания на проектирование и утверждение рабочей документации. Принятие окончательного решения об инвестировании. Отвод земли под строительство. Задание на разработку проекта производства работ. Разработка плана проекта. заключение контрактов. Тендеры на услуги консультантов и заключение контрактов. Разработка планов (графиков) поставки ресурсов. Подготовитель ные работы к строительству. Корректировка плана проекта и оперативного плана строительства (управление изменениями). Оплата выполненных работ и поставок. − модернизац ия (начало нового проекта). С учетом особенностей предприятия, отрасли или вида работ «ворота фазы» могут иметь другие названия, например, «анализ фазы», «ворота стадии», «этап критического анализа» и «вход фазы» или «выход фазы». Предприятия могут использовать данные виды анализа для рассмотрения других представляющих интерес вопросов, таких как документирование или моделирование, относящееся к продукту. Управление жизненным циклом проекта осуществляется путем реализации ряда мероприятий по управлению проектом, которые называются «процессы управления проектом». Каждый процесс управления проектом производит один или несколько выходов от одного или нескольких входов с помощью соответствующих инструментов и методов управления проектом. Выходом может быть поставляемый или конечный результат. Конечные результаты – это результаты, которыми заканчивается определенный процесс. Процессы управления проектом логически связаны друг с другом посредством выходов, которые они производят. Процессы могут содержать накладывающиеся друг на друга действия, которые выполняются на протяжении реализации проекта. Результатом выхода процесса обычно является: ♦ либо вход в другой процесс, ♦ либо поставляемый результат проекта или фазы проекта. На рис. 2.7 показан пример того, как входы, инструменты и методы, а также выходы соотносятся друг с другом в рамках одного процесса и с другими процессами. Повторение процессов и их взаимодействие варьируется в зависимости от потребностей проекта. В целом, процессы попадают в одну из указанных ниже трех категорий. ♦ Процессы, которые применяют единожды или в предопределенные моменты в ходе реализации проекта (например, разработка устава проекта и закрытие проекта или фазы). 18 Рис. 2.7 – Пример процесса: входы, инструменты и методы, выходы ♦ Процессы, которые выполняются периодически, по мере необходимости (например, процесс приобретения ресурсов осуществляется тогда, когда в ресурсах возникает необходимость, процесс проведения закупок осуществляется до возникновения необходимости в закупаемом продукте). ♦ Процессы, которые реализуются постоянно на всем протяжении проекта (например, процесс определения операций может происходить на протяжении всего жизненного цикла проекта, большая часть процессов мониторинга и контроля). Управление проектом осуществляется посредством надлежащего применения и интеграции логически сгруппированных процессов управления проектом: по группам процессов и (или) по областям знаний. Группа процессов управления проектом – это логическое объединение процессов управления проектом с целью достижения конкретных целей проекта. Группы процессов независимы от фаз проекта. Процессы управления проектом сгруппированы в следующие пять групп: ♦ Группа процессов инициации (процессы, выполняемые для определения нового проекта или новой фазы существующего проекта путем получения авторизации на начало проекта или фазы). ♦ Группа процессов планирования (процессы, требуемые для установления содержания работ, уточнения целей и определения направления действий, требуемых для достижения целей проекта). ♦ Группа процессов исполнения (процессы, выполняемые для исполнения работ, указанных в плане управления проектом, с целью соответствия требованиям проекта). ♦ Группа процессов мониторинга и контроля (процессы, требуемые для отслеживания, анализа, а также регулирования исполнения проекта; выявления областей, требующих внесения изменений в план и инициирования соответствующих изменений). ♦ Группа процессов закрытия (процессы, выполняемые для формального завершения или закрытия проекта, фазы или договора). Повсеместно используются блок-схемы процессов. Процессы управления проектом связаны между собой соответствующими входами и выходами, причем конечный результат одного процесса может стать входом другого, который не обязательно находится в той же группе процессов. Группы процессов не являются фазами проекта. Процессы также классифицируются по областям знаний. Область знаний по управлению проектом – выделенная область управления проектом, определяемая ее требованиями к знаниям и описываемая в терминах входящих в ее состав процессов, практик, входов, выходов, инструментов и методов. Хотя области знаний взаимосвязаны, они, с точки зрения управления проектом, определяются отдельно. Программа проектов Метод А Инструмент С Вход Н Вход К Выход проекта А Выход проекта В 19 Следующие десять областей знаний используются в большинстве проектов: ♦ Управление интеграцией проекта. Эта область знаний включает в себя процессы и операции, необходимые для идентификации, определения, комбинирования, объединения и координации различных процессов и действий по управлению проектом в рамках групп процессов управления проектом. ♦ Управление содержанием проекта. Эта область знаний включает в себя процессы, необходимые для обеспечения того, чтобы проект содержал все и только те работы, которые требуются для успешного выполнения проекта. ♦ Управление расписанием проекта. Эта область знаний включает в себя процессы, необходимые для управления своевременным выполнением проекта. ♦ Управление стоимостью проекта. Эта область знаний включает в себя процессы, необходимые для планирования, оценки, разработки бюджета, привлечения финансирования, финансирования, управления и контроля стоимости, обеспечивающие исполнение проекта в рамках одобренного бюджета. ♦ Управление качеством проекта. Эта область знаний включает в себя процессы, необходимые для применения политики предприятия в области качества относительно планирования, управления и контроля проекта, а также требований к качеству продукта с целью удовлетворения ожиданий заинтересованных сторон. ♦ Управление ресурсами проекта. Эта область знаний включает в себя процессы, необходимые для идентификации, приобретения и управления ресурсами, необходимыми для успешного выполнения проекта. ♦ Управление коммуникациями проекта. Эта область знаний включает в себя процессы, необходимые для обеспечения своевременного и надлежащего планирования, сбора, создания, распространения, хранения, извлечения, управления, контроля, мониторинга и в конечном счете архивирования/утилизации информации проекта. ♦ Управление рисками проекта. Эта область знаний включает в себя процессы, связанные с осуществлением планирования управления рисками, идентификацией, анализом, планированием реагирования, осуществлением реагирования, а также с мониторингом рисков в проекте. ♦ Управление закупками проекта. Эта область знаний включает в себя процессы, необходимые для покупки или приобретения вне команды проекта необходимых продуктов, услуг или результатов. ♦ Управление заинтересованными сторонами проекта. Эта область знаний включает в себя процессы, необходимые для идентификации людей, групп или предприятий, которые могут воздействовать на проект или подвергаться воздействию проекта, для проведения анализа ожиданий заинтересованных сторон и их воздействия на проект, а также для разработки соответствующих стратегий управления с целью результативного вовлечения заинтересованных сторон в процесс принятия решений и исполнения проекта. Потребности конкретного проекта могут требовать дополнительно одну или несколько областей знаний. В таблице 2.6 сопоставлены группы процессов управления проектом и области знаний. Таблица 2.6 – Сопоставление групп процессов управления проектом и областей знаний Области знаний Группы процессов управления проектом Процессы инициации Процессы планирования Процессы исполнения Процессы мониторинга и контроля Процессы закрытия 1. Управление интеграцией проекта 1.1 Разработка устава проекта 1.2 Разработка плана управления проектом 1.3Руководство и управление работами проекта 1.4 Управление знаниями проекта 1.5 Мониторинг и контроль работ проекта 1.6 Интегрированн ый контроль изменений 4.7 Закрытие проекта или фазы 20 Области знаний Группы процессов управления проектом Процессы инициации Процессы планирования Процессы исполнения Процессы мониторинга и контроля Процессы закрытия 2. Управление содержанием проекта 2.1 Планиро- вание управления содержанием 2.2 Сбор требований 2.3 Определение содержания 2.4 Создание иерархичес-кой структуры работ 2.5 Подтвер- ждение содержания 2.6 Контроль содержания 3. Управление расписанием проекта 3.1Планировани е управления расписанием 3.2Определение операций 3.3Определение последовательн ости операций 3.4Оценка длительности операций 3.5Разработка расписания 3.6 Контроль расписания 4. Управление стоимостью проекта 4.1Планировани е управления стоимостью 4.2Оценка стоимости 4.3Определение бюджета 4.4 Контроль стоимости 5. Управление качеством проекта 5.1Планировани е управления качеством 5.2Управление качеством 5.3 Контроль качества 6. Управление ресурсами проекта 6.1Планировани е управления ресурсами 6.2Оценка ресурсов операций 6.3Приобретени е ресурсов 6.4Развитие команды проекта 6.5Управление командой проекта 6.6 Контроль ресурсов 7. Управление коммуникациями проекта 7.1Планировани е управления коммуникациям и 7.2Управление коммуникациям и 7.3 Мониторинг коммуникаций 8. Управление рисками проекта 8.1Планировани е управления рисками 8.2Идентифика ция рисков 8.3Качественны й анализ рисков 8.4Количествен ный анализ рисков 8.5Планировани е реагирования на риски 8.6 Реагирование на риски 8.7 Мониторинг рисков 9. Управление закупками проекта 9.1Планировани е закупок 9.2Проведение закупок 9.3 Контроль закупок 21 Области знаний Группы процессов управления проектом Процессы инициации Процессы планирования Процессы исполнения Процессы мониторинга и контроля Процессы закрытия 10. Управление заинтересованными сторонами проекта 10.1 Идентификация заинтересованн ых сторон 10.2 Планирование вовлечения заинтересованн ых сторон 10.3 Управление вовлечением заинтересованн ых сторон 10.4 Мониторинг вовлечения заинтересованн ых сторон 7. Данные и информация управления проектом На протяжении жизненного цикла проекта производится сбор, анализ и преобразование значительного количества данных. Сбор данных проекта выполняется в результате различных процессов, после чего они предоставляются членам команды проекта. В ходе различных процессов собранные данные анализируются в контексте, агрегируются, а также преобразуются в информацию проекта. Информация передается вербально или хранится и рассылается в различных форматах в виде отчетов. Сбор и анализ данных проекта производится регулярно на всем протяжении жизненного цикла проекта. Данные проекта обычно регистрируются в информационной системе управления проекта. Рис. 2.8 – Поток данных, информации и отчетов проекта Данные об исполнении работ. Необработанные наблюдения и измерения, выявленные во время операций, предпринимаемых для выполнения работ проекта (например, процентные Процессы исполнения Процессы контроля Общий контроль проекта Контроль изменений проекта Процессы проекта Коммуникации проекта • Данные об исполнении работ • Информация об исполнении работ • Отчеты об исполнении работ • План управления проектом и обновления документов проекта • Одобренные запросы на изменения • Члены команды проекта • Заинтересованные стороны проекта 22 данные о физически выполненной работе, показатели качества и показатели технического исполнения, даты начала и окончания операций по расписанию, количество запросов на изменения, количество дефектов, фактическая стоимость, фактическая длительность и т. д.) Информация об исполнении работ. Данные об исполнении, собранные в рамках различных процессов контроля, проанализированные в контексте и обобщенные на основе связей в различных областях (например, статус поставляемых результатов, статус реализации запросов на изменения и прогнозы до завершения работ). Отчеты об исполнении работ. Физическое или электронное представление собранной в документах проекта информации об исполнении работ, которая предназначена для принятия решений или формулирования проблем, выполнения действий или осведомления (например, отчеты о статусе, служебные записки, обоснования, информационные бюллетени, электронные информационные панели, рекомендации и обновления). На рис. 2.8 показан поток информации проекта в рамках различных процессов, используемых для управления проектом. 8. Бизнес-документы управления проектом Руководитель проекта, при выборе подхода к управлению проектом, должен учитывать предназначение бизнес-документов (бизнес-кейса и плана управления выгодами проекта). Эти два документа зависят друг от друга, разрабатываются итеративно и ведутся на всем протяжении жизненного цикла проекта. Таблица 2.7 – Бизнес-документы проекта Ключевой компонент Краткое описание Бизнес-кейс проекта Документированный анализ экономической целесообразности, используемый для установления обоснованности выгод отобранного компонента, который еще не определен в достаточной степени, а также для авторизации дальнейших операций по управлению проектом. План управления выгодами проекта Документированное разъяснение, определяющее процессы для создания, максимизации и поддержки выгод, которые обеспечивает проект. За разработку и ведение бизнес-кейса проекта, как правило, отвечает спонсор проекта. В обязанности руководителей проектов входит адаптация указанных документов по управлению проектом для своих проектов; выработка рекомендаций и осуществление контроля; обеспечение согласования бизнес-кейса, плана управления проектом, устава проекта и показателей успеха по плану управления выгодами проекта друг с другом, а также с целями и задачами предприятия. Ведение бизнес-кейса и плана управления выгодами может осуществляться на уровне программы. Руководители проектов должны работать вместе с руководителями соответствующих программ, чтобы обеспечить согласованность документов по управлению проектом с документами программы. На рис. 1.8 показаны взаимосвязи этих важнейших бизнес-документов по управлению проектом с оценкой потребностей, а также примерная продолжительность жизненного цикла этих различных документов относительно жизненного цикла проекта. Бизнес-кейс проекта – документированный анализ экономической целесообразности, используемый для установления обоснованности выгод выбранного компонента, который еще не определен в достаточной степени; служит основой для авторизации дальнейших операций управления проектом; содержит перечень целей и причин инициации проекта; помогает оценить успешность проекта по его окончании в сравнении с целями проекта; используется на 23 всем протяжении проекта и может использоваться до инициации проекта и стать основанием принятия решения об инициации или об отказе от проекта. Жизненный цикл проекта Предварительная работа по проекту Начало проекта Организация и подготовка Выполне ние работ Заверше ние проекта В р е м е н н ы е р а м к и Фазы обобщения Рис. 2.9 – Взаимосвязи оценки потребностей и наиболее важных документов проекта (бизнес-документов) Подготовке бизнес-кейса часто предшествует оценка потребностей – обоснование бизнес-целей и бизнес-задач, угроз и возможностей, выработке рекомендаций по их решению и реализации. Обобщение результатов оценки потребностей может быть сделано в документе бизнес-кейса. Процесс определения бизнес-потребности, анализ ситуации, выработка рекомендаций и определение критериев оценки применимы для любых проектов предприятия. Бизнес-кейс может включать в себя, среди прочего, документальное оформление следующего: Бизнес-потребности: • определение причин необходимости действий; • ситуационное заключение, определяющее документально бизнес- проблему или благоприятную возможность, которые требуют принятия мер, включая предполагаемую ценность, получаемую предприятием; • идентификация заинтересованных сторон, на которых будет оказано влияние; • определение содержания. Анализ ситуации: • определение стратегий, целей и задач предприятия; • определение основных причин проблемы или главных источников благоприятной возможности; • анализ необходимых для проекта возможностей в сравнении с существующими возможностями предприятия; • идентификация известных рисков; – ворота фазы (веха) Оценка потребностей Бизнес- кейс План управления выгодами Устав проекта План управления проектом 24 • идентификация критически важных факторов успеха; • определение критериев принятия решений, по которым можно оценить различные варианты способов действий. Критерии, используемые для анализа ситуации: − Требуемые для решения проблемы или использования благоприятной возможности. − Желательные для решения проблемы или использования благоприятной возможности. − Необязательные – не имеют существенного значения. • Определение имеющихся вариантов действий, которые необходимо учесть для разрешения бизнес-проблемы или использования благоприятной возможности. Варианты действий – это альтернативные способы действий, которые предприятие может использовать по своему усмотрению. Варианты действий можно также описать как «бизнес-сценарии» или «стратегии». Например, бизнес-кейс может предложить следующие три варианта действий: − Ничего не делать, действовать, как обычно, отказаться от авторизации проекта. − И (или) выполнять только минимально необходимый объем работ, чтобы решить проблему или использовать благоприятную возможность. − И (или) выполнять работы в объеме больше минимально необходимого, чтобы решить проблему или использовать благоприятную возможность. Выработка рекомендаций: • заключение о рекомендованном варианте действий, который предлагается выбрать для данного проекта; • пункты, которые должно содержать заключение, включают в себя, среди прочего: • результаты анализа возможных вариантов действий; • ограничения, допущения, риски и зависимости по потенциальным вариантам действий; • показатели успеха; • подход к реализации, который может включать в себя, среди прочего, следующее: контрольные события, зависимости, роли и сферы ответственности. Оценка: • заключение с описанием плана по измерению выгод, которые будут получены от проекта. Документ бизнес-кейса дает основу для количественной оценки успеха проекта и хода его исполнения в течение всего жизненного цикла проекта путем сравнения результатов с целями и определенными критериями успеха. План управления выгодами проекта – это документ, описывающий, каким образом и когда будут получены выгоды от реализации проекта, а также механизмы, которые требуется внедрить для измерения этих выгод. Выгода проекта – это конечный результат действий, характеристики поведения, продукты, услуги или результаты, которые приносят ценность предприятию-спонсору и целевым выгодоприобретателям проекта. Разработка плана управления выгодами начинается на ранних стадиях жизненного цикла проекта с определения целевых выгод, которые должны быть получены. План управления выгодами описывает ключевые составляющие выгод и может включать в себя, среди прочего, следующее: ♦ Целевые выгоды (ожидаемые материальные и нематериальные ценности, которые предполагается получить в результате реализации проекта; финансовая ценность выражается в чистой приведенной стоимости). ♦ Приведение в соответствие со стратегией (насколько выгоды от проекта согласуются с бизнес-стратегиями предприятия). 25 ♦ Сроки реализации выгод (выгоды по фазам, в долгосрочной и краткосрочной перспективе, текущие выгоды). ♦ Владелец выгод (ответственное лицо, которое осуществляет мониторинг, ведет документацию о реализованных выгодах и представляет отчетность о них в предусмотренные планом сроки). ♦ Метрики (количественные показатели, которые планируется использовать для демонстрации реализованных выгод, прямые показатели и косвенные показатели). ♦ Допущения (факторы, которые, как ожидается, должны быть в наличии или наблюдаться). ♦ Риски (для реализации выгод). При разработке плана управления выгодами используются данные и информация, содержащиеся в бизнес-кейсе и оценке потребностей План управления выгодами и план управления проектом включают в себя описание того, как бизнес-ценность, полученная по результатам проекта, становится частью текущей операционной деятельности предприятия, включая подлежащие использованию метрики. Метрики служат средством проверки бизнес-ценности и подтверждения успеха проекта. Разработка и ведение плана управления выгодами проекта является итеративной деятельностью, дополняет бизнес-кейс, устав проекта и план управления проектом. Руководитель проекта ведет работу со спонсором с целью согласования на всем протяжении жизненного цикла проекта устава, плана управления и плана управления выгодами проекта. Устав проекта – документ, выпущенный спонсором проекта, который формально авторизует существование проекта и предоставляет руководителю проекта полномочия использовать ресурсы предприятия в операциях проекта. План управления проектом – документ, описывающий, как проект будет исполняться, как будет происходить его мониторинг и контроль. 9. Показатели успеха проекта Наиболее важными факторами определения успешности проекта являются время, стоимость, содержание, качество, достижение целей проекта (см. рис 2.10). Рис. 2.10 – Тройственная природа проекта 26 Заинтересованные стороны проекта могут по-разному оценивать успешность. При этом им необходимо дать ответ на следующие вопросы: ♦ Как выглядит успех для данного проекта? ♦ Как будет измеряться успех? ♦ Какие факторы могут повлиять на успех? Ответы на данные вопросы должны быть приведены в документах и согласованы между ключевыми заинтересованными сторонами и руководителем проекта. Успех проекта может включать в себя дополнительные критерии, увязанные со стратегией предприятия и с поставкой заказчикам бизнес-результатов. Эти цели проекта могут включать в себя, среди прочего: ♦ исполнение плана управления выгодами проекта; ♦ достижение согласованных финансовых показателей, предусмотренных в бизнес- кейсе. Эти финансовые меры могут включать в себя, среди прочего: − чистую приведенную стоимость (net present value, NPV); − окупаемость инвестиций (return on investment, ROI); − внутреннюю норму доходности (internal rate of return, IRR); − период окупаемости инвестиций (payback period, PBP); − отношение выгод к затратам (beneft-cost ratio, BCR); ♦ достижение нефинансовых целей бизнес-кейса; ♦ совершение перехода предприятия из исходного состояния к будущему состоянию; ♦ исполнение условий и положений договора; ♦ исполнение стратегий, целей и задач предприятия; ♦ обеспечение удовлетворенности заинтересованных сторон; ♦ удовлетворительная приемка заказчиком/конечным пользователем; ♦ интеграция поставляемых результатов в операционную среду предприятия; ♦ обеспечение согласованного качества поставляемого продукта; ♦ исполнение критериев руководства; ♦ достижение других согласованных показателей или критериев успеха (например, производительность процесса). Команда проекта должна быть способна оценить положение проекта, уравновесить запросы и сохранить проактивные коммуникации с заинтересованными сторонами в целях достижения успеха проекта. При постоянном приведении в соответствие проекта вероятность его успеха значительно возрастает, так как проект соответствует стратегическому направлению предприятия. Проект может быть успешным с точки зрения содержания/расписания/бюджета, но при этом не достичь успеха с точки зрения бизнеса. Это может произойти в случае изменений в бизнес-потребностях или рыночных условиях до завершения проекта. 10. Международные стандарты управления проектами Обзор стандартов в области управления проектами На сегодняшний день различными организациями и инициативными группами разработано достаточно большое количество стандартов, имеющих отношение к проектному менеджменту. Группы стандартов по основным областям применения: 1) применимые к отдельным объектам управления (проект, программа, портфель проектов) и регламентирующие соответствующие процессы управления; 2) применимые к субъектам управления (менеджеры проектов, участники команд проектов) и определяющие требования к знаниям и квалификации соответствующих специалистов и процессу оценки квалификации; 3) применимые к системе проектного управления и организации в целом и позволяющие оценить уровень зрелости организационной системы менеджмента. 27 Некоторые наиболее известные стандарты международного и национального уровня представлены на рис. 2.11. Рис. 2.11 – Наиболее распространенные стандарты проектного управления  ISO 10006. Системы менеджмента качества. Руководящие указания по менеджменту качества проектов;  PMBОK Guide. А Guide to the Project Management Body of Knowledge. Руководство к своду знаний по управлению проектами, PMI;  PMBOK Guide Government Extension. Руководство к своду знаний по управлению проектами для правительственных организаций, PMI;  WBS. Руководство по разработке иерархической структуры работ проекта, PMI;  Earned Value. Руководство по применению методики освоенного объема, PMI;  PRINCE2. Стандарт управления проектами, OGC (Office of Government Commerce), Великобритания;  The Standard for Portfolio Management, PMI. Стандарт управления портфелем проектов;  The Standard for Program Management, PMI. Стандарт управления программой;  Managing Successful Programmes, OGC UK. Стандарт управления программой, OGC (Office of Government Commerce), Великобритания;  P2M Japan. Стандарт управления проектами и программами в организации, Япония;  OPM3. Модель зрелости организации в области проектного менеджмента, PMI;  IPMA Competence Baseline (ICB). Международные требования к компетенции менеджеров проектов, IPMA;  НТК Россия. Основы профессиональных знаний и Национальные требования к компетентности (НТК) специалистов по управлению проектами, СОВНЕТ;  PMCDF PMI. Структура развития компетенций в проектном менеджменте (Project Management Competence Development Framework), PMI; Проект Программа Портфель Специалисты Организации (предприятия)  ISO 10006  PMBOK Guide  PRINCE2  PMBOK ® Guide Covernment Ext.  WBS Earned Value  The Standart for Project Portfolio Management PMI  The Standart for Program Management PMI  Managing Successful Programmes OGC, UK  P2M, Japan  P2M, Japan  OPM3  IPMA Competence Baseline (ICB)  НТК Россия  PMCDF PMI  GPBSPM 28  GPBSPM. Общий стандарт оценки проектного персонала на основе опыта (Global Performance Based Standards for Project Management Personnel), GPBSPM Initiative. Разработчиками стандартов в основном являются профессиональные организации или группы специалистов международного или национального уровня. Группа стандартов, применимых к отдельным объектам управления (проект, программа, портфель проектов)  ISO 10006. Системы менеджмента качества. Руководящие указания по менеджменту качества проектов.  PMI (институт управления проектами, США). А Guide to the Project Management Body of Knowledge. (РМВОК Guide). Руководство к своду знаний по управлению проектами. PMI имеет наиболее активную и широкую стратегию в области разработки стандартов.  PRINCE2 (Projects in Controlled Environments). регламентирует также процессы управления и параметры контроля на уровне отдельного проекта.  The Standard for Program Management и The Standard for Portfolio Management. Данные стандарты также построены по процессному принципу и регламентируют деятельность по управлению программами и портфелями проектов. ISO 10006. Сам по себе этот стандарт не является руководством по проектному управлению. В нем приведены руководящие указания по качеству процессов управления проектами; основные принципы и практические методики, которые влияют на качество разработки и реализации проектов. Процессы по проекту в стандарте сгруппированы в две категории: процессы управления проектами и процессы, связанные с продуктом проекта (т.е. такие, как проектирование, производство, проверка). Руководящие указания по качеству процессов, относящихся к продукту проекта, рассматриваются в стандартах серии ISO 9000. Стандарт применим к проектам различной степени сложности, небольшим или большим, краткосрочным или долгосрочным, выполняемым в различных окружающих условиях безотносительно к виду продукта или процесса. Представленные рамочные требования требуют последующей адаптации данного руководства к конкретным условиям разработки и реализации отдельного проекта. В стандарте разделяются понятия процессов управления и фаз реализации проекта. Проект может быть разделен на различные взаимозависимые процессы и фазы в качестве средств планирования и контроля за реализацией целей и оценкой связанных с этим рисков. Фазы делят жизненный цикл проекта на управляемые стадии, такие как разработка концепции и проектной документации, реализация, сдача в эксплуатацию. Процессы проекта – это процессы, необходимые для управления им, а также для реализации продукта проекта. Процессы сгруппированы в соответствии с принципом родственности (например, все процессы, связанные с управлением по временным параметрам, включены в одну группу). Всего в стандарте выделено 11 групп процессов:  стратегические (определение направления проекта);  относящиеся к ресурсам и персоналу;  касающиеся взаимосвязей;  касающиеся области применения;  касающиеся времени;  связанные с затратами;  связанные с передачей информации;  касающиеся рисков;  связанные с закупками. 29 Отдельно рассматриваются процессы, касающиеся измерений и анализа и постоянного совершенствования. В стандарте содержится описание каждого процесса, а также руководящие указания по менеджменту качества конкретного процесса. В основе руководящих указаний по менеджменту качества при проектировании, содержащихся в данном международном стандарте, лежат восемь принципов менеджмента качества (см. ISO 9000): 1) ориентация на потребителя; 2) лидерство руководителя; 3) вовлечение работников; 4) процессный подход; 5) системный подход к менеджменту; 6) постоянное улучшение; 7) принятие решений, основанное на фактах; 8) взаимовыгодные отношения с поставщиками. Эти общие принципы образуют основу системы менеджмента качества для организации-инициатора и организации-исполнителя проекта. РМВОК Guide. Руководство к своду знаний по управлению проектами. В основу стандарта положена процессная модель описания деятельности по управлению проектами. Основными целями разработки РМВОК Guide являются унификация терминологического пространства и использование данного документа в качестве базового справочного пособия для сертификации менеджеров проектов (РМР). В РМВОК Guide определяются:  структура управления проектами (часть 1): содержит основные сведения, определены основные термины. Особое внимание уделяется понятиям жизненного цикла проекта, организационным структурам и окружению проектов;  стандарт управления проектами (часть 2) включает описание пяти групп управленческих процессов: 1) инициация, 2) планирование, 3) организация исполнения, 4) контроль и 5) завершение. В рамках данных групп процессов описываются более 50 базовых управленческих процесса и взаимосвязи между ними;  области знаний по управлению проектами (часть 3) состоят из десяти областей знаний (см. выше). В данной части приводится детальное описание для каждого из управленческих процессов, включая общее описание процесса, входной и выходной информации, а также перечисление рекомендуемых методов и инструментов. Одним из направлений развития PMBОK Guide стала его адаптация к отраслевой специфике. В настоящее время выпущены расширения стандарта для правительственных и строительных проектов (Government Extension to the PMBOK Guide, Construction Extension to the PMBOK Guide). PMI также разрабатывает стандарты, связанные с отдельными методиками управления проектами. PRINCE2 (Projects in Controlled Environments) регламентирует процессы управления и параметры контроля на уровне отдельного проекта, программы, портфеля описывает связь управленческих процессов с требованиями к структуре и характеристиками создаваемого в рамках проекта продукта; широко используется в государственном и частном секторе в Великобритании и часто применяется на международном уровне и используются для сертификации менеджеров программ. The Standard for Portfolio Management. Стандарт управления портфелем проектов (PMI). Основные цели разработки стандарта – формулирование понятийного пространства управления портфелем проектов, определение типовых процессов и их результатов без привязки к отраслевым особенностям бизнеса, а также описание ключевых ролей управления портфелем, зон ответственности и полномочий. Важное значение придается стратегии организации, возможности отслеживания достижения целей через процессы интегрированного управления портфелями проектов, программами и отдельными проектами. 30 Раскрывается взаимосвязь с функциональными областями управления: финансами, маркетингом, корпоративными коммуникациями, управлением персоналом. Связь управления портфелем с управлением программами и проектами устанавливается через реализацию функций менеджера портфеля:  выравнивание компонентов в соответствии со стратегией;  обеспечение сбалансированности и устойчивости компонентов как частей портфеля, основанных на ключевых индикаторах;  оценка стоимости и взаимосвязей компонентов портфеля;  определение доступности ресурсов и расстановка приоритетов;  включение и исключение портфельных компонентов. Система управления портфелем для эффективной поддержки выполнения представленных функций предусматривает вовлечение в управление ключевых ролей и подразделений: наблюдательного совета управления портфелем, клиентов, спонсоров, исполнительных директоров, управления операционной деятельностью, менеджеров программ, офиса управления программами и проектами, менеджеров проектов, функциональных менеджеров, финансовых менеджеров, участников команды проекта. При идентификации ключевой роли менеджера портфеля установлены дополнительные функции, определяющие отличительные признаки портфельного управления:  расстановка приоритетов и выравнивание компонентов управления портфелем в соответствии со стратегическими целями;  обеспечение ключевых акционеров своевременными результатами оценки, ранней идентификации воздействий на выполнение работ;  измерение стоимости организации с помощью инвестиционных инструментов, таких как ROI, NPV, PP. Процессы управления портфелем представлены двумя группами: 1) группа процессов формирования портфеля включает процессы управления им, обеспечивающие достижение сбалансированности портфеля проектов со стратегическими целями организации. Группа включает следующие процессы: идентификация проектов, категориизация, оценка, отбор, расстановка приоритетов, балансировка портфеля, авторизация; 2) группа процессов мониторинга и контроля основана на индикаторах деятельности, с помощью которых периодически выравниваются компоненты портфеля относительно стратегических целей. Включает процессы сбора периодической отчетности, анализа состояния портфеля проектов и управления изменениями. Стандарты, определяющие требования к квалификации участников управления проектами (менеджеры проектов, участники команд управления проектами) Стандарты, определяющие требования к компетенции менеджера проекта:  Международные требования к компетенции специалистов по управлению проектами (ICB), разработанные Международной ассоциацией управления проектами IPMA (Швейцария).  Project Manager Competency Development Framework (PMI). Руководство по развитию компетенций менеджера проекта, разработанное на базе структуры и процессов PMBОK Guide.  Global Performance Based Standards for Project Management Personnel – стандарт оценки квалификации менеджеров проектов на основании достигнутых результатов.  IPMA Competence Baseline. Международные требования к компетенции менеджеров проектов. 31  Российский национальный стандарт. Требования к знаниям и квалификации специалистов, их сертификации (Российская ассоциация управления проектами СОВНЕТ). Устанавливаются следующие уровни квалификации в области проектного управления: 1) специалист по проектному управлению; 2) менеджер проекта; 3) ведущий менеджер проекта; 4) директор программы. Международные требования к компетенции специалистов по управлению проектами (ICB) содержат три группы взаимосвязанных элементов знаний: 1) 20 технических элементов знаний, относящихся к содержанию проектного управления; 2) 15 поведенческих элементов знаний, относящихся к межличностным отношениям между индивидуумами и группами, участвующими в проектах, программах и портфелях; 3) 11 контекстуальных элементов знаний, относящихся к вопросу взаимодействия проектной команды в контексте проекта и организаций, инициировавших и участвующих в проекте. В разделы требований входят перечисленные ниже элементы знаний и компетенций. Элементы технической компетенции:  успешность проектного управления;  заинтересованные стороны;  требования и задачи проекта;  проектный риск и возможности;  качество;  проектная организация;  работа команды;  разрешение проблем;  структура проекта;  замысел и итоговый продукт проекта;  время и фазы проекта;  ресурсы;  затраты и финансы;  закупки и контракты;  изменения;  контроль и отчетность;  информация и документация;  коммуникация;  старт проекта;  закрытие проекта. Элементы поведенческой компетенции:  лидерство;  участие и мотивация;  самоконтроль;  уверенность в себе;  разрядка;  открытость;  творчество;  ориентация на результат;  продуктивность;  согласование ; 32  переговоры;  конфликты и кризисы;  надежность;  понимание ценностей;  этика. Элементы контекстуальной компетенции:  проектно-ориентированное управление;  программно-ориентированное управление;  портфельно-ориентированное управление;  осуществление проектов, программ и портфелей;  постоянная организация;  предпринимательская деятельность;  системы, продукты и технология;  управление персоналом;  здоровье, безопасность, охрана труда и окружающая среда;  финансы;  юридические аспекты. Стандарты, применимые к системе управления проектами организации Стандарты, применимые к системе управления проектами организации в целом и позволяющие оценить уровень зрелости организационной системы проектного менеджмента  P2M (Program and Project Management for Innovation of Enterprises), Япония  OPM3® (Organizational Project Management Maturity Model), PMI. P2M – один из наиболее авторитетных стандартов в области управления проектами и программами. Исходная идея концепции стандарта P2M заключается в представлении проектов и программ в качестве основополагающих элементов стратегического управления организацией. Стандарт включает разделы, описывающие общие концепции и терминологию управления проектами и программами, а также основные области управления. Базовый аппарат управления программами:  методология управления отдельными проектами;  интеграция управления проектами и программами друг с другом и с окружением;  управление по сегментам;  общая методология управления программами. Проектное управление по сегментам включает следующие области управления:  стратегическое;  финансами;  системами;  организационной структурой;  достижением целей и показателей;  ресурсами;  рисками;  информационными технологиями;  взаимоотношениями участников проекта;  коммуникациями;  управление проектом, направленное на совершенствование. OPM3 определяет, что организационное управление проектами – это систематическое управление проектами, программами и портфелями проектов, направленное на достижение стратегических целей компании: использование знаний, навыков, инструментов и техник в проектной деятельности организации для достижения стратегических целей через реализацию 33 проектов. Понятие «зрелость организационного управления проектами» описывает способность предприятия отбирать проекты и управлять ими таким образом, чтобы максимально эффективно поддерживать достижение стратегических целей компании. Стандарт OPM3 состоит из свода знаний, а также базы данных и инструментария в электронном виде. Инструментальная составляющая стандарта состоит из трех взаимосвязанных элементов: 1) элемент знание (Knowledge) представляет базу лучших практик по управлению проектами (около 600 практик, относящихся к разным объектам управления: портфель проектов, программа и проект, и к разной степени зрелости описания процессов); 2) элемент оценка (Assessment) – инструмент, помогающий пользователям, ответив на опросный лист (более 150 вопросов), самостоятельно оценить текущую зрелость управления проектами на предприятии, определить основные области компетенций и существующих практик; 3) если организация принимает решение развивать практики проектного управления и переходить на новые, более высокие, уровни зрелости, то в дело вступает элемент улучшение (Improvement), который помогает компаниям выбрать стратегию и определить последовательность развития системы проектного управления. База лучших практик структурирована по трем доменам – объектам управления – портфель проектов, программа, проект – и четырем уровням формализации процессов (процессы стандартизированы, измеряемы, управляемы, оптимизируемы). Кроме того, лучшие практики в основном соответствуют одному из процессов управления проектами: инициация, планирование, организация исполнения, контроль, завершение. Российские стандарты в области проектного управления • ГОСТ Р 54869-2011 «Проектный менеджмент. Требования к управлению проектом» • ГОСТ Р 54871-2011 «Проектный менеджмент. Требования к управлению программой» • ГОСТ Р 54870-2011 «Проектный менеджмент. Требования к управлению портфелем проектов» • ГОСТ Р ИСО 21500-2014 «Руководство по управлению проектами» • Распоряжение Минэкономразвития России № 26Р-АУ от 14 апреля 2014 г. «Об утверждении Методических рекомендаций по внедрению проектного управления в органах исполнительной власти» • Постановление Правительства Российской Федерации № 1050 от 15 октября 2016 г. «Об организации проектной деятельности в Правительстве Российской Федерации» 11. Методология и адаптация Методология – это система практик, методов, процедур и правил, используемых руководителями проекта в определенной сфере деятельности. Руководства и стандарты управления проектами не является методологией проекта, они предлагаются в качестве справочных материалов и лучшая практика для дальнейшей адаптации. Лучшие практики не подразумевает, что описанные в них знания всегда должны единообразно применяться во всех проектах. Методологии управления проектом могут быть: ♦ разработаны собственными экспертами предприятия, ♦ приобретены у поставщиков, ♦ получены от профессиональных ассоциаций, ♦ получены от государственных ведомств. Адаптация управления проектом – деятельность по выбору процессов, входов, инструментов, методов, выходов, а также фаз жизненного цикла. В процессе адаптации руководитель проекта взаимодействует с командой проекта, спонсором, руководством 34 предприятия или с некоторыми из них в определенном сочетании. В некоторых случаях предприятие может требовать применения конкретных методологий управления проектом. Адаптация необходима, поскольку каждый проект является уникальным, и не всякий процесс, инструмент, метод, вход или выход, определенные в руководствах или стандартах, требуется при осуществлении конкретного проекта. В ходе адаптации должны решаться вопросы конкурирующих ограничений: содержания, расписания, стоимости, ресурсов, качества и риска. Значение каждого ограничения для каждого проекта будет разным, и руководитель проекта адаптирует подход к управлению данными ограничениями с учетом среды проекта, культуры предприятия, потребностей заинтересованных сторон и других переменных. В ходе адаптации управления проектом руководитель проекта должен также учитывать различные уровни руководства, которые могут требоваться, и, в рамках которых, проект будет осуществляться, а также культуру предприятия. Кроме того, на решения по адаптации управления проектом может оказать влияние соображение, является ли заказчик проекта внешним или внутренним по отношению к предприятию. В полноценных методологиях управления проектом учитываются уникальный характер проектов, чтобы осуществить адаптацию в разумных пределах. Однако адаптация, которая предусмотрена методологией, может потребовать осуществления дополнительной адаптации для данного проекта. Методы управления проектами Метод проектного управления интегрирует множество приемов и способов: сетевое планирование и управление, календарное планирование, инструменты логистики, стандартного, структурного, ресурсного планирования, имитационного и бизнес- моделирования и др. Характеристика приемов и способов управления проектами приведена в таблице 1.8. Таблица 2.8 – Приемы и способы управления проектами Методология управления проектами Краткая характеристика 1. Waterfall – поточный метод Каскадная модель планирования (водопад). Ход проекта делится на поток следующих друг за другом задач. Цель – полное завершение предыдущего перед началом очередного этапа. Метод подходит для организаций, где для реализации работы выделены определенные ресурсы и установлены конкретные сроки выполнения. 2. Структура разбиения работ (СРР, WBS) Иерархическая структура последовательной декомпозиции проекта, которая позволяет решать проблемы организации работ: определять вехи, распределять ответственность, оценивать стоимость, создавать систему отчетности, поддерживать процедуры сбора информации о выполнении работ и отображать результаты в информационной системе для обобщения графиков, стоимости, ресурсов, работ и дат их завершения, согласовать план проекта с потребностями заказчика, представленный в виде спецификаций или описаний работ: проект – задача – подзадача – комплекс работ – работа – операция. 3. Структурная схема организации (ССО, OBS) Инструмент, содержащий описание организационной структуры, необходимой для выполнения работ, определенных в структуре разбиения работ; который определяет состав и распределение обязанностей исполнителей работ. 4. Диаграмма Гантта Задача метода – визуализировать календарное расписание проекта, основываясь на датах начала и завершения задач (длительность) и их взаимосвязи (последовательность и параллельность выполнения). Используя диаграмму Ганнта рассчитывается самая длинная цепочка взаимосвязанных задач, определяющих длительность проекта – критический путь. 5. CPM (Critical Path Method) – метод критического пути Широко применяется в строительстве, так как четко очерчивает весь маршрут действий и формирует список наиболее продолжительных рабочих процессов. Именно за счет критического пути устанавливается срок реализации всего процесса целиком 6. Метод критической цепи Основная задача – задать ключевые цели, определить сроки их достижения и установить дату завершения проекта. Если ресурсов для соблюдения всех условий недостаточно, то дополнительно вводятся параллельные рабочие процессы 35 Методология управления проектами Краткая характеристика 7. PBPM – процессно- ориентированный метод Перед началом проекта формулируется его миссия. Вся дальнейшая работа строится на соответствии задач проекта этой миссии по установленным критериям. Если при анализе результат проекта неудовлетворительный – продукт не соответствует требованиям заказчика, то он отправляется на доработку. 8. APF (Adaptive Project Framework) – применение адаптивных (изменяемых) рамок Дает шанс сделать проект лучше на очередном шаге работы в зависимости от существующего опыта предыдущих этапов. Важно установить цели проекта и тщательно контролировать его выполнение. Нацелен на заинтересованность потенциального клиента в формируемой в проекте ценности. 9. BF (Benefit Realization) – увеличение прибыли проекта Основная задача – максимальное повышение прибыли после установки и отладки работы CRM. 10. ECM (Event Chain Methodology) – моделирование событий Основная задача метода – выявление и прогнозирование вероятных рисков и оценка уровня их воздействия на выполнение проекта. Анализ проводится наглядно с использованием методики Монте-Карло (статистическое моделирование) и диаграммы цепочки событий (тип схемы для настройки системы планирования ресурсов предприятия), разделенной на события. 11. XP (Extreme Programming) – экстремальное программирование Основная задача – начать деятельность, а уже потом выбрать направление. По факту конечная миссия проекта определяется в процессе работы. Группа сосредотачивается на формировании простейших решений для получения необходимого уровня качества и результативности. Чаще всего применяется при разработке программного продукта в условиях постоянно меняющихся требований. 12. Agile Гибкий подход к управлению. Проект выполняется небольшими группами, сформированными из разнопрофильных работников. Очередные требования формируются на основе уже полученного результата взаимодействия совместной работы команды на предыдущих этапах. Важная особенность: своевременность и скорость корректировок и отслеживание актуальных «болевых точек» в процессе выполнения проекта 13. Scrum Основан на принципах Agile. Работа над проектом разделена на спринты – промежутки времени от 1 до 4 недель, чем достигается максимальная продуктивность, сосредоточенность и сплоченность команды. Такие «забеги» позволяют сделать реализацию проекта максимально эффективной за счет определения ошибок и корректировки дальнейших действий. 14. Lean – бережливое производство Сочетает в себе подходы к снижению всех видов производственных потерь, структурированность и гибкость, но совершенно не сочетается с выполнением больших, разрозномасштабных, неструктурированных проектов. Недостатки: одинаковое внимание ко всем этапам, даже к тем, которые этого не требуют, что ведет к продлению сроков. 15. Kanban Основан на методологии Lean, «точно в срок». Основная задача подхода – снижение количества выполняемых в данный момент задач. Задачи устанавливаются в порядке приоритета и выстраиваются в виде карточек (Kanban), которые переходят от одного этапа к следующему этапу, только когда в этом возникает необходимость (принцип вытягивания). В итоге мы визуализируем график Гантта, а на выходе видим результат – готовый к сдаче заказчику «минимально работоспособный» продукт на каждом шаге (в соответствии с принципами Agile и Scrum). 16. Six Sigma (6 сигм) Один из статистических методов управления качеством. Главная задача метода – постоянное улучшение процессов выполнения проекта за счет прохождения 5 основных этапов. Определение – постановка задач, измерение – выбор показателей успеха, исследование – поиск решений установленных задач в срок, разработка – сам ход выполнения проекта, контроль – проверка и улучшение качества. Этот метод идеален для проектов с высоким уровнем сложности, включающих в себя множество дополнительных операций. 17. PRISM – устойчивые методы Задача метода – сокращение влияния предприятия на окружающую среду за счет снижения расходов и издержек в процессе выполнения проекта. 18. Метод дисконтирования денежных потоков Финансовые показатели обоснованя эффективности проекта могут включать в себя:  чистую приведенную стоимость (net present value, NPV);  окупаемость инвестиций (return on investment, ROI);  внутреннюю норму доходности (internal rate of return, IRR); 36 Методология управления проектами Краткая характеристика  период окупаемости инвестиций (payback period, PBP);  отношение выгод к затратам (beneft-cost ratio, BCR);  срок окупаемости (pay-back period, PP). Гибкие методы управления проектами Не все проекты могут быть структурированы таким образом, чтобы быть реализованными по классическому проектному подходу. Примером может служить разработка программного обеспечения.  Agile – гибкая методология разработки (Agile software development, agile-методы) – совокупность особых итеративных принципов проектного управления разработкой [как правило, программного обеспечения] Рис. 2.12 – Особенности Agile Согласно данному подходу, проект разбивается не на последовательные фазы, а на маленькие подпроекты, которые затем «собираются» в готовый продукт. Инициация и планирование на верхнем уровне проводятся для всего проекта, а последующие этапы: разработка, тестирование и прочие проводятся для каждого мини-проекта отдельно. Это позволяет передавать результаты этих мини-проектов (инкременты) быстрее, а приступая к новому подпроекту (итерации) в него можно внести изменения без больших затрат и влияния на остальные части проекта. Семейство гибких методологий основано на Манифесте Agile (Agile Manifesto), который закрепляет основные ценности и принципы гибкой разработки программного обеспечения, в основе которых – командная работа и адаптация, предрасположенность к изменениям. Сам по себе Agile – не метод управления проектами. Это набор идей и принципов того, как нужно реализовывать проекты. Уже на основе этих принципов и лучших практик были разработаны отдельные гибкие методы (фреймворки – frameworks): Scrum, Kanban (не путать с Kanban бережливого производства, см. ниже), Crystal, и др. Эти методы могут достаточно сильно отличаться друг от друга, но они следуют одним и тем же принципам, и ценностям Agile. Принципы Agile  удовлетворение заказчика за счёт ранней и бесперебойной поставки новой модификации ценного продукта;  приветствие изменений требований даже в конце разработки;  частая поставка обновление работающей модификации продукта;  тесное, ежедневное общение заказчика с разработчиками в общем офисе на протяжении всего проекта; Особенности Agile Итеративный подход: работа короткими циклами (1-3 недели). 1 итерация – 1 мини- проект. Результат – работающая модификация продукта Agile не включает практик, но определяет ценности и принципы, которыми руководств уются успешные команды Постоянное взаимодействи е заказчика и подрядчика «лицом к лицу» в творческом процессе Самооуправля-емые (на принципах комбинирования либеральных и демократических начал). Группы, сформированы по функциональному признаку. Заказчик входит в команду проекта Небольшой объем документации и отсутствие полноценного календарного планирования: отсутствие дорожной карты и плана в каноническом представлении Динамическо е формировани е и изменение требований к процессам и результатам 37  проектом занимаются мотивированные специалисты, которые обеспечены нужными ресурсами, условиями работы, поддержкой и доверием;  рекомендуемый метод передачи информации – личный разговор (лицом к лицу face- to-face);  работающая модификация продукта – лучший измеритель прогресса;  заказчики, спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределённый срок;  постоянное внимание улучшению технического мастерства и удобному дизайну;  простота – искусство не делать лишней работы;  лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды;  постоянная адаптация к изменяющимся обстоятельствам. Рис. 2.13 – Ценности Agile Таблица 2.9 – Преимущества и недостатки методологии Agile Сильные стороны Слабые стороны  Быстрая и относительно безболезненная реакция на изменения: гибкость и адаптивность: подстраивание под любые условия и процессы организации.  Agile подходит для проектов с «открытой датой окончания».  Разработка новых, инновационных продуктов в условиях большой доли неопределённости.  Раскрытие информации о продукте по ходу проекта.  Имеются методологические фреймворки – развитие практик: Scrum, Kanban, – Crystal, LeSS, SAFe, Nexus и др.  Agile – ни методология, ни стандарт, а набор принципов и ценностей.  Каждой команде придётся самостоятельно составлять свою систему управления, руководствуясь принципами Agile.  Требует затрат, а от лидера изменений – знаний и упорства, а также серьёзных административных ресурсов.  Scrum – гибкий фреймворк, созданный в 1986 году, который считается самым структурированным из семейства Agile. Он сочетает в себе элементы классического процесса и идеи гибкого подхода к управлению проектами. В итоге получилось очень сбалансированное сочетание гибкости и структурированности. Как и Agile, Scrum разбивает проект на части – заделы продуктов (product backlog, беклог), которые сразу могут быть использованы заказчиком для получения ценности. Затем эти части приоретизируются (ранжируются) владельцем продукта – представителем заказчика в команде. Ценности Agile Люди и взаимодействие важнее процессов и инструментов Работающий продукт важнее исчерпывающей документации Сотрудничество с заказчиком важнее согласования условий контракта Готовность к изменениям важнее следования первоначальному плану 38 Самые важные части продукта первыми отбираются для исполнения в спринте (спринт – итерации в Scrum, длящиеся от 1 до 4 недель). В конце спринта заказчику представляется рабочая модификация продукта – самые важные части продукта, которые уже можно использовать (например, сайт с частью функционала или программа, которая уже работает, пусть и частично). После этого команда проекта приступает к следующему спринту. Длительность у спринта хоть и фиксированная, но команда выбирает её самостоятельно в начале проекта, исходя из особенностей проекта и собственной производительности. Чтобы удостовериться в том, что проект отвечает требованиям заказчика, которые имеют свойство изменяться со временем, перед началом каждого спринта происходит переоценка ещё не выполненного содержания проекта и внесение в него изменений. В этом процессе участвуют все – команда проекта, Scrum-мастер (Scrum Master, лидер команды проекта) и владелец продукта. И ответственность за этот процесс лежит на всех. Владелец продукта является представителем заказчика в проекте, или олицетворяет всех клиентов будущего проекта, в случае если заказчика нет. Для этого он должен досконально знать их потребности и образ мышления, а также разбираться в продукте и технологии его изготовления. Scrum-мастер призван помочь участникам проекта лучше понять и принять ценности, принципы и нормы практики Scrum. Он лидер и посредник между внешним миром и командой. Его задача – следить, чтобы никто не мешал команде самостоятельно и комфортно работать над поставленными задачами. Команда же отвечает за то, чтобы в конце спринта все необходимые задачи были сделаны, а поставки – выполнены. Основная структура процессов Scrum вращается вокруг основных встреч: упорядочивания беклога, планирования спринта, ежедневных летучек, подведения итогов спринта и ретроспективы спринта. 1) Встреча по упорядочиванию беклога (Backlog Refinement Meeting, «Backlog Grooming») – встреча аналогичная фазе планирования в классическом проектном управлении: проводится в первый день каждого спринта. На ней рассматривается – что уже было сделано по проекту в целом, что ещё осталось сделать и принимается решение о том, что делать дальше. Владелец продукта определяет, какие задачи на данном этапе являются наиболее приоритетными. Данный процесс определяет эффективность спринта, ведь именно от него зависит, какую ценность получит заказчик по итогам спринта. 2) Планирование спринта. После того, как владелец продукта определил приоритеты, команда совместно решает, что конкретно они будут делать во время текущей итерации, как достигнуть поставленной на предыдущей встрече цели. Команды могут применять различные инструменты планирования и оценки на данном этапе, лишь бы они не противоречили принципам и логике Scrum. Планирование спринта проводится в самом начале итерации, после встречи по упорядочиванию продукта. 3) Ежедневные летучки – каждый день спринта, в идеале, в одно и то же время, члены команды тратят 15 минут на то, чтобы поделиться информацией о статусе задач и состоянии проекта. На ней не происходит обсуждений проблем или принятия решений – если после встречи возникают вопросы и конфликты, Scrum-мастер и вовлечённые участники обсуждают их отдельно. Летучка нужна для обмена информацией и поддержания всех членов команды в курсе состояния проекта. 4) Подведение итогов спринта – цель этапа обследование и адаптация создаваемого продукта. Команда представляет результаты деятельности всем заинтересованным лицам. Основная задача – убедиться, что продукт этапа соответствует ожиданиям участников и согласуется с целями проекта. 5) Ретроспектива спринта проводится сразу после подведения итогов спринта и до планирования следующего спринта. На нём команда выясняет, насколько чётко и 39 слаженно проходил процесс реализации этапа. Обследованию подвергаются возникшие проблемы в работе, методологии и взаимодействии. Именно этот этап позволяет команде провести рефлексию и эффективнее провести следующий спринт. Таблица 2.10 – Преимущества и недостатки методологии Scrum Сильные стороны Слабые стороны  Кажущаяся сложность для внедрения: новые процессы, новые роли, много делегирования и совершенно новая организационная структура.  Подходит для проектов, в которых необходимы «быстрые победы» в сочетании с толерантностью к изменениям.  Подходит для ситуаций, когда не все члены команды имеют достаточный опыт в той сфере, в которой реализуется проект – постоянные коммуникации между членами командами позволяют недостаток опыта или квалификации одних сотрудников за счёт информации и помощи от коллег.  Scrum позволяет работать с высокой скоростью  Scrum аккумулирует пользовательский опыт и даёт возможность выявить самое главное для клиентов.  В ходе каждой итерации, разработчики могут добавлять и тестировать новые атрибуты (характеристики) продукта и убирать те, которые не нужны клиенту.  Scrum позволяет «быстро ошибаться». Вместо того, чтобы долго и с большими затратами готовить крупный релиз.  Поставки раз в две недели имеют небольшой размер: их легко отслеживать и, если что-то идёт не так, быстро исправлять.  гибкий и одновременно структурированный подход к реализации проектов, который, в отличие от размытых и общих принципов Agile, не позволит команде отклониться от целей проекта.  Повышенные требования к команде проекта: = она должна быть небольшой (5-9 человек); = кроссфункциональной – т.е. члены команды должны обладать более чем одной компетенцией, необходимой для реализации проекта; = члены команды должны быть «командными игроками», активно брать на себя ответственность и уметь самоорганизовываться.  Подходит не для всех проектов и организаций – может не подойти, например, для разработки проектов машиностроения или строительства (но это не точно). Lean - основан на принципах бережливого производства (lеan – тощий) и добавляет к принципам Agile схему потока операций (workflow) для того, чтобы каждая из итераций выполнялась одинаково качественно и без потерь (времени и ресурсов). В Lean, так же, как и в Scrum, работа разбивается на небольшие пакеты поставки, которые реализуются отдельно и независимо. Но в Lean для разработки каждого пакета поставки используют поэтапный анализ потока операций. Как и в классическом проектном управлении, это могут быть этапы планирования, разработки, производства, тестирования и поставки – или любые другие этапы, необходимые для качественной реализации проектов. Этапы Lean и их гибкость позволяют быть уверенными в том, что каждая часть проекта реализуется без потерь. В Lean не прописаны чёткие границы этапов, как в Scrum прописаны ограничения cпринтов. Но, в отличие от классического проектного управления, Lean позволяет параллельно выполнять несколько задач на разных этапах, что повышает гибкость и увеличивает скорость исполнения проектов. Таблица 2.11 – Преимущества и недостатки методологии Lean Сильные стороны Слабые стороны  Применим, если проект требует очень ровного  Мало приспособлен для применения в крупных и неоднородных проектах, поскольку, не каждая часть проекта требует одинаково детальной, тщательной 40 качества и чёткого исполнения.  Сочетает гибкость, структурированность и исключение потерь. проработки и внимания, а тотальный анализ потоков операций приводит к потерям времени их планирования.  Lean не предлагает чёткого рабочего процесса для реализации «кусочков» проекта, что способствует растягиванию сроков проекта. Kanban очень похож на схему промышленного производства. На входе в этот процесс попадает материал, а на выходе получается готовая деталь. Также и в Kanban, инкремент (напомним, инкремент – результат мини-проектов) продукта передаётся с этапа на этап, а в конце получается готовый к использованию продукт в очередной работоспособной версии. Кроме того, Kanban заимствовал из практики супермаркетов их принцип – «держи на полках только то, что нужно клиенту» (или иначе «положи на полку закончившийся товар». А потому в Kanban разрешается оставить неоконченную задачу на одном из этапов, если её приоритет изменился, он пока не нужен (или уже не нужен) заказчику и есть другие срочные задачи. Неотредактированная статья для блога, подвешенная без даты публикации или часть кода функции, которую возможно не будут включать в продукт – всё это нормально для работы по Kanban. Выглядит Kanban как карточка (или доска с карточками (стикерами)), которая показывает приоритет в выполнении задачи или в поставке продукта либо ресурса и место этой задачи, продукта, ресурса на этапах жизненного цикла проекта. Kanban намного менее строгий, нежели Scrum – он не ограничивает время спринтов, нет ролей, за исключением владельца продукта. Kanban даже позволяет члену команды вести несколько задач одновременно, чего не позволяет Scrum. Также никак не регламентированы встречи по статусу проекта – можно делать это как Вам удобно, а можно не делать вообще. Для работы с Kanban необходимо определить этапы потока операций (workflow). В Kanban они изображаются как столбцы (рис. 6), а задачи обозначают специальные карточки. Карточка перемещается по этапам, и на каждом этапе процент завершения задачи становится выше. На выходе мы получаем готовый к поставке заказчику элемент продукта. Доска со столбцами и карточками может быть как материальной, так и электронной –Kanban не накладывает ограничений на пользователей. Система Kanban может быть настолько гибкой, насколько команда проекта того пожелает – ведь Kanban является элементом визуализации идеи Agile, хоть и появился этот прием гораздо раньше. Принципы Kanban:  Карточки – для каждой задачи создаётся индивидуальная карточка, в которую заносится вся необходима информация о задаче. Таким образом, вся нужная информация о задаче всегда под рукой.  Ограничение на количество задач на этапе – количество карточек на одном этапе строго регламентировано. Благодаря этому сразу становится видно, когда в потоке операций возникает «затор», который оперативно устраняется.  Непрерывный поток – задачи из беклога (задела проекта) попадают в поток в порядке приоритета. Таким образом, работа никогда не прекращается.  Постоянное улучшение («кайдзен» (kaizen)) – концепция постоянного улучшения появилась в Японии в конце XX века. Её суть в постоянном анализе производственного процесса и поиске путей повышения производительности. Таблица 2.12 – Преимущества и недостатки методологии Kanban Сильные стороны Слабые стороны  Kanban хорошо подходит для достаточно сплочённых команды с хорошей коммуникацией.  Kanban может работать с не с любой командой. Он лучше всего подходит для команд, навыки членов которых дублируются друг с другом. Таким образом они могут помогать друг другу 41  В Kanban нет установленных чётких дедлайнов, что хорошо подходит для замотивированных и опытных команд.  При правильной настройке и управлении, расстановке ограничений и концентрации на постоянном улучшении позволяет Kanban серьёзно экономить ресурсы и укладываться в дедлайны и бюджет.  Гибкость преодолевать трудности при решении задач. Без этого Kanban будет не так эффективен.  Для жёстких дедлайнов Kanban не очень подходит: лучше использовать классический подход или Scrum. 6 Сигм (Six Sigma) – более структурированный инструмент управления качеством нежели Kanban, который предполагает больше анализа и планирования для экономии ресурсов, повышения качества, а также снижения количества брака и проблем. Конечная цель проекта – удовлетворение заказчика качеством продукта, которого можно добиться при помощи непрерывного процесса улучшения всех аспектов проекта, основанном на тщательном анализе показателей. В концепции 6 Сигм уделяется отдельное внимание устранению возникающий проблем. Для этого используется процесс из 5 шагов, известных как цикл DMEDC: 1. Определение (Define) – первый этап очень похож на ранние этапы других систем проектного управления. Здесь определяется содержание проекта, собирается информация о предпосылках проекта, ставятся цели. 2. Измерение (Measure) – метод 6 Сигм ориентирован на сбор и анализ статистических данных о проекте. На данном этапе устанавливается, какие показатели будут определять успех проекта и какие данные нужно собирать и анализировать. 3. Исследование (Explore) – на этой стадии менеджер проекта решает, каким образом команда может достичь поставленных целей и исполнить все требования в срок и в рамках бюджета. 4. Разработка (Develop) – на данном этапе измеряется прогресс проекта по реализации планов и решений, принятых на предыдущих этапах. Здесь необходим детальный план, в котором описаны все действия, необходимых для достижения поставленных целей. 5. Контроль (Control) – ключевой и завершающий этап в методологии 6 Сигм. Его основная задача – долгосрочное улучшение процессов реализации проектов. Данный этап требует тщательного документирования результатов контроля, анализа собранных данных и применения полученных знаний как в проектах, так и в компании. 6 Сигм очень похожа на Kanban, только с ограниченными этапами реализации задач – планированием, определением целей и тестированием качества. Процесс реализации проектов при этом более структурирован и команде сложнее сбиться с пути. 6 Сигм можно адаптировать к нуждам конкретной компании или команды. Жёстким требованием является лишь тщательное измерение и контроль показателей проекта на этапах реализации. Таблица 2.13 – Преимущества и недостатки методологии Six Sigma Сильные стороны Слабые стороны  Чёткая схема реализации проектов и постоянного улучшения процессов.  Позволяет улучшить и оптимизировать процессы реализации проекта и экономить ресурсы в будущем.  6 Сигм подходит для сложных проектов, в которых много новых и сложных операций.  Позволяет реализовывать элементы проекта, учиться на ошибках и повышать качество в будущем.  На разных этапах проекта, у команд часто возникает путаница в приоритетах (снизить затраты или удовлетворить требование заказчика.  Лейтмотив 6 Сигм: «Всё всегда можно сделать ещё лучше» может демотивировать сотрудников, не чувствующих удовлетворения от проделанной работы.  Если проект единичный и компания не планирует в будущем реализовывать подобные 42 проекты, все затраты на анализ и рефлексия будут напрасными.  Трудозатратность. Методология быстрой разработки приложений (Rapid Application Development, RAD) – это проектная методология, чаще всего используемая в проектах по разработке ПО, основной целью которых является быстрое и качественное создание приложения. Данная методология управления проектами выделяет 4 стадии проекта:  Планирование.  Пользовательское проектирование.  Быстрое конструирование.  Переключение. Методология быстрой разработки приложений, с одной стороны, помогает улучшить показатели результативности проекта и повысить качество риск-менеджмента. Но, с другой стороны, данная метрология не подходит для масштабных IT проектов, может привести к низкому качеству кода и требует постоянного вовлечение клиента в процесс исполнения всего проекта. Lean – бережливое производство Потери времени и их причины. Потерями в бережливом производстве называют любое действие на всех уровнях организации, при осуществлении которого потребляются ресурсы, но не создаются ценности. Потери времени – это периоды неэффективного использования фондов времени, ведущее к потере личной или корпоративной результативности. Поскольку в управлении проектами большое внимание уделяется планированию этапов работ, а следовательно – времени, здесь необходимо сказать, что существует множество подходов к формированию «перечней» причин потерь времени. В контексте управления проектами следует обратить внимание на причины потерь времени, которые являются предметом бережливого производства (производственная система Лин, Lean, Кайдзен, Toyota Production System). Бережливое производство – это способ организации производства, включающий в себя оптимизацию производственных процессов, ориентацию на потребности заказчика, улучшение качества и экономию за счет сокращения потерь, в том числе, потерь времени. Семь видов потерь, на которых концентрируется бережливое производство:  Перепроизводство (избыточное производство продукции)  Избыток запасов (избыточное количество сырья, материалов, полуфабрикатов)  Потери транспортировки (избыточное перемещение сырья, продукции, материалов)  Потери ожидания (задержки: в рабочее время не осуществляется производственная деятельность)  Излишняя обработка (обработка, не приносящая ценности или добавляющая не нужную функциональность)  Потери на лишние перемещение (движения, не связанные напрямую с осуществлением производственной деятельности)  Потери из-за производства продукции с дефектами (брак) Ещё пять источников потерь  Перегрузка оборудования или работников, возникающая при работе с большей скоростью или темпом и с большими усилиями в течение долгого периода времени по сравнению с расчетной нагрузкой.  Неравномерность выполнения работы (колеблющийся график работ, вызванный не колебаниями спроса, а особенностями производственной системы, или неравномерный темп работы по выполнению операции, заставляющий операторов сначала спешить, а затем ждать). 43  Нереализованный творческий потенциал сотрудников  Транзакционные издержки (издержки взаимодействия)  Недостаточная ценность продукта Рекомендации по применению методологии проектного управления:  Не существует универсальной «наилучшей» методологии управления проектом – выбор определяется типом проекта и спецификой окружающей среды.  Если работаете над проектом с возможными небольшими изменениями содержания работ, например, в области строительства или машиностроения – выбирайте каскадную модель.  Для разработки программного обеспечения, графического дизайна и других сервисно-ориентированных проектов выбирайте гибкие методологии.  Используйте методологию быстрой разработки приложений для небольших IT проектов со сжатыми сроками.  Если необходимо минимизировать риски и требуются структурированный подход в исполнении проекта крупного или среднего масштаба – выбирайте PRINCE2.  Не бойтесь использовать другие, менее популярные методологии, если они в большей степени соответствуют вашему проекту.  Не используйте бережливую методологию и 6 Сигм, если проект единичный, не серийный. 12. Сертификация специалистов по управлению проектами Международная сертификация специалистов по управлению проектами – процесс определения соответствия:  профессиональных знаний, опыта и навыков кандидата – установленным требованиям к специалисту по управлению проектами;  деятельности кандидата – этическому кодексу менеджера проекта. Сертификат является подтверждением опыта и профессионализма специалиста в области управления проектами независимым, авторитетным органом. Преимущества сертифицированных специалистов проектного управления:  международное признание квалификации и компетентности;  персональное преимущество для роста карьеры;  повышение профессионального рейтинга и цены предоставляемых ими услуг. Преимущества компаний, имеющих сертифицированных специалистов по управлению проектами:  обеспечение потребности организации в квалифицированных специалистах проектного управления;  повышение эффективности работы организаций, использующих услуги сертифицированных управляющих проектом;  повышение рейтинга и конкурентоспособности компании за счет наличия профессионалов проектного управления. Международные программ сертификации по управлению проектами (наиболее значимые): 1) сертификация по стандартам Международной ассоциации по управлению проектами (IPMA); 2) сертификация по стандартам американского Института управления проектами (PMI). Система сертификации IPMA основана на международных требованиях к компетентности специалистов по управлению проектами (IBC – International Competence Baseline) и предназначена для определения соответствия профессиональных знаний, опыта и 44 навыков кандидатов установленным требованиям, предъявляемым к специалистам проектного управления. Сертификационная программа IPMA включает четыре уровня, к каждому из которых разработаны свои требования соответствия. По результатам сертификации специалисту может быть присвоено в зависимости от уровня сертификации одно из следующих званий: 1) директор проекта (Project Director, IPMA Level А) способен управлять портфелем проектов или программой, а не только отдельным единичным проектом, с использованием соответствующих методологии и инструментов; 2) старший менеджер проекта (Senior Project Manager, IPMA Level B) способен управлять сложным проектом, координировать его, сколько подпроектов в его рамках; 3) менеджер проекта (Project Manager, IPMA Level C) способен управлять проектом ограниченной сложности. 4) помощник менеджера проекта (Project Manager Associate, IPMA Level D) способен применять знания в области управления проектами и может быть привлечен к участию в проекте в качестве одного из членов команды управления, но его общие знания недостаточны для выполнения более сложных задач. Основные требования к знаниям, компетенциям и опыту специалистов Директор проекта должен:  быть способен управлять всеми проектами компании, или проектами ее отделения, или всеми проектами программы;  иметь минимум пятилетний опыт управления комплексными проектами и программами, из которых не менее трех лет – руководство, координация и управление портфелем проектов;  уметь осуществлять руководство координацией и контролем всех проектов компании или ее отделения;  иметь портфель конкретных стратегических предложений по общему управлению в компании;  принимать участие в подготовке персонала, задействованного в проектном управлении, и управляющих проектами;  нести ответственность за реализацию проектного управления, разработку руководящих и нормативных материалов, а также применение основных методов и средств проектного управления. Старший менеджер проекта должен:  быть способным самостоятельно управлять сложными проектами;  иметь минимум пятилетний опыт проектного управления, из которых не менее трех лет – в качестве ответственного за руководство и управление сложными проектами;  уметь руководить координацией и контролем всех проектов компании или ее отделения;  иметь портфель конкретных стратегических предложений по общему управлению в компании;  принимать участие в подготовке персонала, задействованного в проектном управлении и управляющих проектами;  нести ответственность за реализацию проектного управления, разработку руководящих и нормативных материалов, а также за применение основных методов и средств управления проектами. Менеджер проекта должен:  быть способным самостоятельно управлять несложными проектами и помогать управляющему сложными проектами во всех функциональных областях проектного управления; 45  иметь минимум трехлетний опыт управления проектами в качестве руководителя в функциональных областях несложного проекта;  нести ответственность за осуществление несложного проекта;  управлять небольшими группами персонала по управлению проектами;  применять методы, средства и инструментарий проектного управления;  быть способным работать в качестве руководителя группы специалистов, входящей в команду сложного проекта, и нести ответственность за его соответствующие параметры. Помощник менеджера проекта должен:  обладать знаниями во всех областях проектного управления и быть способным применять их в некоторых областях как специалист;  обладать широким спектром знаний в проектном управлении и быть способным применять эти знания на практике;  быть способным выступать в качестве члена команды проекта в любой функциональной области управления проектами. Тал. 2.14 – Требования, предъявляемые к специалистам по управлению проектами разных уровней сертификации Требования к специалистам Уровень сертификации A B C D 1. Способность управлять:  Программой, комплексом проектов  Сложными проектами  Простыми проектами, основными функциями в сложных проектах  Отдельными функциями в проекте на основе своих знаний Х Х Х Х Х 2. Опыт работы:  Координатора программы, комплекса проектов (пять лет)  Управляющего проектом (пять лет)  В команде проекта (три года) Х Х Х 3. Высшее образование Х Х Х Х 4. Владение одним из иностранных языков (английский, немецкий, французский) Х Х Тал. 2.15 – Общая схема этапов процесса сертификации для разных уровней сертификации. Требования к специалистам Уровень сертификации D C B A 1. Предоставление входных документов 1.1 Свидетельство об уплате сертификационного взноса Х Х Х Х 1.2 Заявка на сертификацию и анкета Х Х Х Х 1.3 Заполненная форма самооценки Х Х Х 1.4 Список выполненных проектов Х Х Х 2. Участие в работе семинара Х Х Х 3. Представление резюме о проекте Х 4. Представление отчета о проекте Х Х 5. Письменный экзамен Х Х Х Х 6. Интервью Х Х Х 7. Вручение сертификата / апелляция Х Х Х Х 8. Ресертификация Х Х Х 46 Сертификация осуществляется уполномоченными сертификационными органами в странах – членах IPMA. Сертификация может проводиться как на базе ICB, так и на базе национальных требований к компетенции специалистов, разработанных в соответствии с требованиями IPMA. IPMA ведет общий реестр сертифицированных специалистов и гарантирует, что сертификаты, выданные в одной стране, действительны в любой другой стране. Сертификация по стандартам американского Института управления проектами (PMI) основана на стандарте PMBOK. Уровни сертификации:  профессиональный менеджер проекта (PMP – Project Management Professional);  сертифицированный специалист по управлению проектами (CAPM – Certified Associate in Project Management);  специалист по управлению программами (PgMP – Program Management Professional);  специалист по планированию проектов (SP – Scheduling Professional);  специалист по управлению рисками (RMP – PMI Risk Management Professional);  специалист по «гибким» методам управления проектами (ACP – Agile Certified Practitioner). Профессиональный менеджер проекта (PMP – Project Management Professional). Сертификация требует наличия теоретических знаний в сфере проектного управления и подтверждения практического опыта в применении этих теоретических знаний. На момент подачи заявки кандидат должен иметь высшее образование со степенью не ниже бакалавра и не менее 4500 часов работы в области управления проектами по пяти группам процессов. Количество часов в заполняемых формах подтверждения опыта должно в сумме составлять 4500, а даты проектов должны показывать, что кандидат имеет не менее трех лет (36 непересекающихся месяцев) опыта управления проектами в течение шести лет до подачи заявки. Если на момент подачи заявки кандидат не имеет высшего образования, но имеет диплом о полном среднем образовании, то он должен подтвердить не менее 7500 часов работы в области управления проектами в период за восемь лет до подачи заявки. Для каждого проекта, в котором участвовал кандидат, заполняется отдельная форма подтверждения опыта. Помимо данных о проекте кандидат должен указать примерное количество часов, потраченных им на проекте в одной или более группах процессов (в сумме по всем проектам кандидат должен иметь опыт во всех группах процессов). Данное описание должно содержать перечень конкретных управленческих процедур, которые выполнял кандидат в качестве менеджера проектов, структурированных в рамках пяти основных процессов (инициация, планирование, исполнение, контроль, завершение). Кандидат также должен иметь не менее 35 часов обучения в области проектного управления. Кандидат может указывать любое обучение в этой области независимо от даты. Кроме того, кандидат должен подписать и соблюдать Кодекс профессиональной этики менеджера проекта. Завершающим этапом получения статуса PMP является сдача экзамена разработанного для того, чтобы объективно оценить нания кандидата в области проектного менеджмента. Экзамен на степень PMP проходит в международных центрах. В России на данный момент существует два таких центра – в Москве и в Петербурге. На весь экзамен отводится четыре астрономических часа, в течение которых необходимо ответить на 200 вопросов. Кандидат должен выбрать правильный ответ из четырех предложенных вариантов. Большинство вопросов предполагает детальное знание стандартов PMI (PMBОK). Однако есть вопросы, предполагающие наличие у кандидата практического опыта. Экзамен можно сдавать на русском языке. 47 Для успешной сдачи экзамена кандидат должен правильно ответить на две трети вопросов. Сертифицированный специалист по управлению проектами (CAPM – Certified Associate in Project Management). Сертификация предназначена для специалистов, которые имеют знания в области проектного управления, но не имеют еще достаточного практического опыта. САРМ – это практик проектного управления, продемонстрировавший основные знания, а также умение применять инструменты и методики управления проектами. Как член команды проекта сертифицированный специалист обычно обращается за руководством, наставлениями и одобрением к более опытным практикам. САРМ обычно выполняет следующие задачи:  помощь в оценке планов управления проектов;  оценка индикаторов производительности и резервов;  помощь в уточнении требований к проекту, допущений и ограничений;  поддержка при административном и финансовом завершении. Чтобы получить степень САРМ, кандидат должен соответствовать требованиям к образованию и опыту, предъявляемым PMI, и демонстрировать высокий уровень понимания и знания проектного управления, подтвержденный экзаменом на степень сертифицированного специалиста по управлению проектом. Экзамен по форме аналогичен экзамену на степень PMP, но состоит из 150 вопросов и длится три часа. На момент подачи заявки кандидат должен иметь высшее образование со степенью не ниже бакалавра и не менее 1500 часов работы в области проектного управления по пяти группам процессов. Если на момент подачи заявки кандидат не имеет высшего образования, но имеет диплом о полном среднем образовании, то он должен подтвердить не менее 2500 часов работы в области проектного управления в период за три года до подачи заявки. Кандидат должен также иметь не менее 23 часов обучения в области проектного управления. Program Management Professional (PgMP), Scheduling Professional (SP), Risk Management Professional (RMP), Agile Certified Practitioner (ACP). К кандидатам на получение этих сертификаций также есть сходные требования. Эти сертификации предусматривают предварительную проверку кандидата на соответствие требованиям к сертификации, после тестирования следует оценка кандидата. Сертификацию необходимо подтверждать каждые три года.

question:Бизнескейс проекта это: Вопрос 1 Выберите один ответ: документированные спонсором проекта его инициация и делегирование полномочий руководителю проекта документированное обоснование процессов создания, максимизации и поддержки выгод проекта документированное обоснование исполнения, мониторинга и контроля проекта документированный анализ экономической целесообразности проекта

question:Что из названного НЕ относится к процессам управления проектами? Вопрос 2 Выберите один ответ: планирование исполнение мониторинг инициация и закрытие содержание проекта

question:Проектом называют: Вопрос 3 Выберите один ответ: ряд связанных друг с другом проектов, вспомогательных программ и мероприятий, управление которыми координируется для получения выгод, которые были бы недоступны при управлении ими по отдельности проекты, программы, вспомогательные портфели и операционная деятельность, управляемые как группа с целью достижения стратегических целей главный способ создания ценности и выгод в условиях ограниченных бюджетов, сроков, ресурсов, быстро меняющихся технологий и конъюнктуры среды