Управление проектами как основа инновационной деятельности. Базовые понятия проектного менеджмента

УПРАВЛЕНИЕ ПРОЕКТАМИ КАК ОСНОВА ИННОВАЦИОННОЙ ДЕЯТЕЛЬНОСТИ ЛЕКЦИЯ 1 ПО ДИСЦИПЛИНЕ «УПРАВЛЕНИЕ ИНФОРМАЦИОННО-ТЕХНОЛОГИЧЕСКИМИ ПРОЕКТАМИ» Доцент кафедры «Бизнес-информатика», к.т.н., доц. Морозова О.А. Москва 2018 ПЛАН ЛЕКЦИИ 1. Базовые понятия проектного менеджмента 2. Принципы и преимущества проектного управления 3. Обзор стандартов управления проектами 4. Управление ИТ-проектами (специфика, статистика, типичные ошибки, классификация ИТ-проектов) 2 1. БАЗОВЫЕ ПОНЯТИЯ ПРОЕКТНОГО МЕНЕДЖМЕНТА 3 ПРОЕКТНЫЙ МЕНЕДЖМЕНТ КАК ОБЛАСТЬ ЗНАНИЙ Начало формирования 50-е годы ХХ века Потребность в развитии менеджмента определяется следующими факторами: 1. эффективность реализации проектов в любой сфере деятельности зависит от качества управления 2. для сложных проектов, в которые вовлечены значительные материальные и людские ресурсы, эффективность использования инвестиций зависит от степени развития технологий и информационных систем поддержки процедур менеджмента Современная концепция управления - на стыке на стыке менеджмента, маркетинга, экономики, техники и технологии производства. 4 ТЕНДЕНЦИИ В РАЗВИТИИ УПРАВЛЕНИЯ ПРОЕКТАМИ В МИРЕ  В 2015 году число занятых в проектно-активных отраслях (традиционные проектно-активные отрасли: строительство, тяжелое машиностроение, перерабатывающие отрасли промышленности (химическая, нефтегазовая и др.); крупные сети (транспортные, трубопроводные, коммуникационные); информационные технологии и телекоммуникации) в мире составляет 32,6 млн;  Общий ВВП проектно-активных отраслей составляет в 2016 году около $4,5 трлн, в том числе $1,2 трлн будет приходиться на Китай и около $1 трлн — на США;  Роль инноваций в развитии большинства стран становится ключевой и будет неуклонно возрастать. По данным PMI 5 ОПРЕДЕЛЕНИЕ ТЕРМИНА “ПРОЕКТ”  это предприятие, которое характеризуется принципиальной уникальностью условий его деятельности, таких как задачи, время, затраты, качество и другими условиями, которые различаются по другим параметрам и проектной специфической организацией;  это предпринимаемое усилие, организующее человеческие, материальные и финансовые ресурсы в неизвестный путь в рамках уникального предмета работы, заданной спецификации, с ограничениями на затраты и время, а следование стандартному жизненному циклу проекта происходит так, чтобы осуществить успешные изменения, определенные посредством количественных и качественных целей и задач;  это единственная в своем роде заданная скоординированная деятельность, с определенным началом и завершением, осуществляемая индивидуумом или организацией для решения специфических задач с определенным расписанием, затратами и параметрами выполнения. ICB - IPMA Competence Baseline.Version 2.0. IPMA Editorial Committee. - Bremen: Eigenverlag, 1999 6 ОПРЕДЕЛЕНИЕ ТЕРМИНА “ПРОЕКТ” Проект — уникальный процесс, состоящий из набора взаимоувязанных и контролируемых работ с датами начала и окончания и предпринятый, чтобы достичь цели (objective) соответствия конкретным требованиям, включая ограничения по времени, затратам и ресурсам. ISO/TR 10006: 1997 (E). Quality Management – Guidelines to quality in project management Проект – это временное усилие, предпринятое для создания уникального продукта или услуги. A Guide to the Project Management Body of Knowledge. PMI Standards Committee. 2000 Edition., 2000 7  Проект - комплекс взаимосвязанных мероприятий, направленный на создание уникального продукта или услуги в условиях временных и ресурсных ограничений. (ГОСТ Р 54869-2011). Проект имеет:  Четко поставленную, заранее определенную цель,  Ограниченные, заранее определенные временные рамки,  Ограниченные, заранее определенные материальные ресурсы (бюджет),  Команду проекта во главе с руководителем. 8 ПРОЕКТНАЯ И ОПЕРАЦИОННАЯ ДЕЯТЕЛЬНОСТЬ • Операционная деятельность - это продолжающийся во времени и повторяющийся процесс. Применяется, когда внешние условия хорошо известны и стабильны, когда производственные операции хорошо изучены и неоднократно испытаны, а функции исполнителей определены и постоянны. В этом случае основой эффективности служат узкая специализация и повышение компетенции. Задача операционной деятельности — обеспечение нормального течения бизнеса. Цель – создание типового продукта или услуги. • Проектная деятельность - временное предприятие, предназначенное для создания уникальных продуктов, услуг или результатов. Задача проекта — достижение конкретной бизнес-цели. 9 ПРОЕКТНАЯ И ОПЕРАЦИОННАЯ ДЕЯТЕЛЬНОСТЬ 10 ПРОЕКТНАЯ И ОПЕРАЦИОННАЯ ДЕЯТЕЛЬНОСТЬ  Продуктивная деятельность – направлена на достижение новых целей, либо на достижение новых известных целей новыми средствами (лежит в основе проектной деятельности).  Репродуктивная деятельность –связана с достижением известного результата с помощью известных средств (лежит в основе операционной деятельности). Используются различные методы управления. 11 ФОРМАЛЬНЫЕ КРИТЕРИИ ДЛЯ ВЫЯВЛЕНИЯ ПРОЕКТА  Масштаб  Длительность  Бюджет  Трудозатраты  Сложность управления  Количество подрядчиков  Наличие внешних экспертов  Локализация команды  Наличие опыта  Наличие ограничений 12 УПРАВЛЕНИЕ ПРОЕКТАМИ (ПРОЕКТНЫЙ МЕНЕДЖМЕНТ , РМ) Область деятельности, в ходе которой определяются и достигаются четкие цели проекта при балансировании между объемом работ, ресурсами, временем, качеством и рисками Задача проекта — достижение конкретной бизнес-цели, при соблюдении ограничений «железного треугольника». Это означает, что ни один из углов треугольника не может быть изменен без оказания влияния на другие. Например, чтобы уменьшить время, потребуется увеличить стоимость и/или сократить содержание 13 ИЛЛЮСТРАЦИЯ ОГРАНИЧЕНИЙ «ЖЕЛЕЗНОГО ТРЕУГОЛЬНИКА» 14 УЧАСТНИКИ ПРОЕКТА 15 РОЛЕВАЯ ОРГАНИЗАЦИОННАЯ СТРУКТУРА УПРАВЛЕНИЯ ПРОЕКТОМ  Спонсор – должностное лицо (подразделение, организация), по инициативе которого происходит организация проекта. Не обязательно источник финансирования. Лицо, максимально заинтересованное в успехе проекта. В стандарте PMI «лицо, обеспечивающее проект финансовыми ресурсами в денежном или ином виде»). Иногда является заказчиком.  Куратор проекта — лицо, ответственное за обеспечение проекта ресурсами и осуществляющее административную, финансовую и иную поддержку проекта;  Заказчик проекта — физическое или юридическое лицо, которое является владельцем результата проекта.  Менеджер проекта — лицо, осуществляющее управление проектом и ответственное за результаты проекта.  Команда проекта — совокупность лиц, групп и организаций, объединенных во временную организационную структуру для выполнения работ проекта  Заинтересованное лицо (stakeholder) – физическое, юридическое, должностное лицо или подразделение, интересы которого могут быть затронуты в ходе реализации проекта. Позитивные (заинтересованы в успехе проекта, спонсор, менеджер, команда) и негативные.  Пользователи – заинтересованные лица, как внутри предприятия, так и вне его, получают преимущества в случае успешной реализации проекта. Источник информации для формирования требований к результатам проекта. 16 17 ГОСТ Р 54869―2011 ПРОЕКТЫ И СТРАТЕГИЯ ОРГАНИЗАЦИИ 18 ПРОЕКТЫ И СТРАТЕГИЯ ОРГАНИЗАЦИИ Деятельность проектной организации, связь между сущностями (стандарт ISO 21500) 19 2. ПРИНЦИПЫ ПРОЕКТНОГО УПРАВЛЕНИЯ УРОВНИ ИННОВАЦИОННОЙ ДЕЯТЕЛЬНОСТИ 20 ОРГАНИЗАЦИОННЫЕ ПРИНЦИПЫ ПРОЕКТНОГО УПРАВЛЕНИЯ  Полнота цикла управления проектами (от выявления потребностей до управления передачей полученных результатов);  Этапность процессов управления проектами (описание полного цикла каждого этапа формирования и реализации проекта);  Многовариантность при выработке управленческих решений;  Системность;  Комплексность (разработка отдельных увязанных между собой элементов проектной структуры, обеспечивающих достижение подцелей, в соответствии с генеральной целью того или иного проекта;  Обеспеченность (сбалансированность) — обеспечение всех мероприятий, предусмотренных в проекте, различными видами необходимых для его реализации ресурсов: финансовыми, информационными, материальными, трудовыми. Принципы проектного управления предусматривают проведение анализа внутренних и внешних условий его реализации, анализ риска и выработку проектного мышления у команды проекта, планирование проектных работ. 21 ПРЕИМУЩЕСТВА ПРОЕКТНОГО УПРАВЛЕНИЯ 22 ПРИЧИНЫ ПЕРЕХОДА К ПРОЕКТНОМУ УПРАВЛЕНИЮ 6% Для получения прибыли 6% Для повышения эффективности бизнеса 8% Основной Для сокращения расходов 10% Согласно нормативным требованиям Для обновления устаревших технологий Основной Другое *По данным PwC Global Project Management survey, 2012 23 ЭФФЕКТИВНОСТЬ ПРОЕКТНОГО УПРАВЛЕНИЯ 24 ТИПЫ ОРГАНИЗАЦИЙ, ИСПОЛЬЗУЮЩИХ ПРОЕКТНОЕ УПРАВЛЕНИЕ  организации, извлекающие основную часть своих доходов от осуществления заказных проектов;  организации, применяющие управление проектами как базовый тип управления. В большинстве организаций отсутствуют методы, позволяющие связать стратегическое управление и оперативное управление по отдельным проектам воедино 25 ОРИЕНТАЦИЯ ПРОЕКТНОЙ ДЕЯТЕЛЬНОСТИ НА БИЗНЕС-ЦЕЛИ • Заинтересованы в достижении целей бизнеса : Владельцы бизнеса (shareholders) – акционеры, собственники, владельцы имущества и активов предприятий. • Заинтересованы в успехе проектной деятельности: Участники проектной деятельности (stakeholders) – руководители портфелей, программ, проектов, их команды, заказчики, спонсоры, поставщики, подрядчики и др. Проблема: требования участников проектной деятельности (stakeholder requirements), как правило, не в полной мере соответствуют требованиям владельцев бизнеса (shareholder requirements) 26 ОРИЕНТАЦИЯ ПРОЕКТНОЙ ДЕЯТЕЛЬНОСТИ НА БИЗНЕС-ЦЕЛИ Требования Участников Проектов (Stakeholders Requirements) Требования Владельцев Бизнеса (Shareholders Requirements) Успех проектов и их выполнение: В установленные сроки В рамках выделенного бюджета При удовлетворении заказчика Успех Программ и Достижение Выгод Бизнеса: Повышение ROI (Return On Investment) Повышение EPS (Earnings Per Share) Повышение PPE (Price Per Earnings) Повышение Чистой Прибыли Увеличение Доли Рынка Удержание Заказчиков 27 ПОТРЕБНОСТЬ В ОРИЕНТАЦИИ НА БИЗНЕС-ЦЕЛИ  Успешный проект, выполненный в установленные сроки, в рамках бюджета и при удовлетворении заказчика – не обязательно принесёт выгоды владельцев бизнеса - ускорение возврата инвестиций, повышение выручки в расчёте на акцию, повышение рыночной стоимости активов в расчёте на выручку и др.  Необходимо обеспечить ориентацию проектной деятельности на достижение целей бизнеса  Достигается за счёт объединения проектов в программы и портфели. 28 ПРОГРАММА  Программа – это ряд связанных друг с другом проектов, управление которыми координируется для достижения преимуществ и степени управляемости, недоступных при управлении ими по отдельности.  Набор взаимосвязанных и взаимозависимых проектов, программ и других работ, объединенных вместе с целью эффективного управления для достижения заранее определенной цели программы.  Программа должна производить некую добавочную стоимость (выгоду). 29 ПОРТФЕЛЬ ПРОЕКТОВ  Портфель проектов - это набор проектов или программ и других работ, объединенных вместе с целью эффективного управления данными работами для достижения стратегических целей предприятия.  Набор действующих программ, проектов, субпортфелей и других работ компании в определенный момент времени . Портфель может быть 2-х типов:  независимые одновременно идущие проекты,  сеть (network) – набор связанных между собой проектов – некоторые проекты могут начаться только после завершения стадии других проектов и влиять на принятие решений по запуску следующих. 30 СТРУКТУРА ПОРТФЕЛЕЙ, ПРОГРАММ И ПРОЕКТОВ КОМПАНИИ 31 ИНТЕГРАЦИЯ РЕЗУЛЬТАТОВ ИННОВАЦИОННОЙ ДЕЯТЕЛЬНОСТИ Три уровня инновационной деятельности в бизнесе компании:  Уровень проектов – тактические задачи  Уровень программ – решение комплексных проблем  Уровень портфелей – достижение превосходства в бизнесе 32 УРОВНИ ИННОВАЦИОННОЙ ДЕЯТЕЛЬНОСТИ КОМПАНИИ Уровни инновационной активности Цель Способ достижения цели Результат Проект Решение тактической задачи Инновационный продукт, услуга, результат Уникальное решение Повышение эффективности Снижение стоимости Повышение качества Программа Решение комплексной проблемы Инновационная технология Ускорение возврата инвестиций Повышение дохода Повышение прибыли Расширение доли рынка Расширение партнерств Портфель Достижение превосходства в бизнесе Инновационный бизнес Глобализация преимуществ 33 ИНТЕГРАЦИЯ УПРАВЛЕНИЯ ИННОВАЦИЯМИ Уровень портфелей компании Бизнес-цели достигнуты Необходимое условие успеха компании Уровень программ Стратегические выгоды получены Необходимое условие успеха портфелей Уровень проектов Требования проектов удовлетворены Необходимое условие успеха программ 34 3. СТАНДАРТЫ ПРОЕКТНОГО МЕНЕДЖМЕНТА 35 ОРГАНИЗАЦИИ ПО РАЗРАБОТКЕ И ПРОДВИЖЕНИЮ СТАНДАРТОВ  Международная организация стандартизации International Organization for Standardization www.iso.org/  В Европе – это International Project Management Association (IPMA)(http://www.ipma.ch)  В США - Project Management Institute (PMI), разработавший стандарт PMBOK (http://www.pmi.org).  В России Российская Ассоциация Управления Проектами «СОВНЕТ» (http://www.sovnet.ru) ( является членом IPMA), Федеральное агентство по техническому регулированию и метрологии, подкомитет «Менеджмент проектов».  Международное объединение по разработке Стандартов управления проектами Global Alliance for Project Performance Standards (GAAPS) (http://globalpmstandards.org/) (волонтерская организация) 36 СТАНДАРТЫ ПО УПРАВЛЕНИЮ ЕДИНИЧНЫМ ПРОЕКТОМ Стандарт PMBOK (Project Management Body of Knowledge), Свод знаний по управлению проектами Разработчик Project Management Institute (PMI) Примечание На сегодня актуальна 6-ая редакция стандарта (6-th edition) (Software Extension to a Guide to the Project Management Body of Knowledge), относящееся к 5-ой редакции стандарта PRINCE 2 (Projects IN Controlled Environments) Проекты в управляемой окружающей среде The Office of Government Commerce (OGC) Управление проектами, программами и услугами. Продукто-ориентированный подход к управлению проектами. Все стандарты носят рекомендательный характер 37 СТАНДАРТЫ ПО УПРАВЛЕНИЮ ЕДИНИЧНЫМ ПРОЕКТОМ Руководство по управлению International Международный стандарт по управлению проектами ISO 21500: 2012 – Guidance Organization for проектами. Процессно-ориентированный Standardization подход. on project management ISO Первый российский стандарт по Автономная некоммерческа управлению проектами. я организация «Центр стандартизаци и управления проектами» ГОСТ Р ИСО 21500-2014 Руководство Идентичен международному стандарту по проектному менеджменту ИСО ISO 21500:2012 ГОСТ Р 54869-2011. Проектный менеджмент. Требования к управлению проектом. 38 PMBOK 6 Дата выхода 6 сентября 2017 Основное – тренд в сторону гибких методологий управления Включил в себя идеи из PRINCE2, теории систем, гибких подходов к проектному управлению. Состоит из двух книг: • стандарт PMI PMBoK 6th Edition, • дополнение к стандарту Agile Practice Guide (создана при совместном участии PMI и Agile Alliance) СТАТУС PMBOK – МЕТОДОЛОГИЯ? « не является методологией, это руководство», используется для разработки корпоративной методологии управления проектами Два уровня адаптивности:  Адаптация процессов и инструментов, предлагаемых PMBoK, под задачи предприятия (разработка корпоративной методологии УП)  Адаптация процессов МП в ходе реализации конкретного проекта (методология должна иметь допуски для таких изменений) КВАЛИФИКАЦИОННЫЕ СТАНДАРТЫ ПО УПРАВЛЕНИЮ ПРОЕКТАМИ Стандарт Разработчик стандарта A Framework for Performance Based Competency Standards for Global level 1 and 2 Project Managers (Рамочные Стандарты практической компетентности проектных менеджеров категорий GL1 и GL2) Project Manager Competency Development (PMCD) Framework APM Competence Framework Global Alliance for Project Global Level 1 (GL1) — Performance Standards «Менеджер проектов» (GAAPS) Global Level 2 (GL2) — «Менеджер проектов высокой сложности». Project Management Доступна вторая редакция. Institute (PMI) Second edition Association for Project Management (APM) Великобритания Научно-технический стандарт основан на стандарте центр «ИНТЕК» GAPPS ГОСТ Р 53892-2010 Руководство по оценке компетентности менеджеров проектов. Области компетентности и критерии профессионального соответствия ГОСТ Р 53892-2010 Руководство по оценке компетентности менеджеров проектов. Области компетентности и критерии профессионального соответствия Научно-технический центр «ИНТЕК» Примечание 41 ТРЕБОВАНИЯ К МП (PMBOK)  Ужесточены квалификационные требования к МП, треугольник талантов МП  навыки лидерства, стратегического и технического управления проектами.  Новая группа компетенций «Стратегическое управление и управление бизнесом».  Главное понимание связи проекта с бизнес-результатом предприятия. 4. ИТ-ПРОЕКТЫ: СПЕЦИФИКА 43 СПЕЦИФИКА ПРОЕКТОВ В ОБЛАСТИ ИКТ  Проблемы коммуникаций между Заказчиком и Исполнителем (согласование требований между ИТ и бизнесом).  Солидарная ответственность Заказчика и Исполнителя за результат проекта.  Взаимодействие ИТ процессов и бизнес-процессов (внедрение ИТ предусматривает реорганизацию структуры предприятия или смену бизнесмодели).  Вовлечение в проект представителей различных подразделений организации (преследуют собственные интересы, вероятность конфликта с проектной командой).  Масштабность ИТ проектов.  Высокая степень изменчивости (по мере реализации уточняются требования к содержанию).  Высокая степень рисков. 44 ПРИЧИНЫ ПРОВАЛА ИТ-ПРОЕКТОВ 45 Специфика проектов в области ИКТ Высокая концентрации уникальных работ, связанных с интеллектуальным и творческим трудом. Сложность нормирования и оценки по срокам, деньгам и ресурсам. Критичны с точки зрения соблюдения сроков и бюджета. Значимость ИТ- проектов для бизнеса формирует объективные требования к срокам, нарушение которых влечет либо потерю бюджета, либо риск фундаментального провала на рынке. Отсутствие стандартных процессов разработки (RUP, XP, Agile…) Требуется высокая квалификация руководителей ИТ-проектов 46 СТАТИСТИКА ИТ-ПРОЕКТОВ В мире выполняется примерно 1 000 000 ИТ - проектов в год.  Из низ треть превышает стоимость и отстает по срокам более, чем на 125%.  Многие не удовлетворяют ожиданиям заказчика по качеству. По результатам исследования Gartner Research Group, 2012: «На протяжении десятилетий статистика принципиально не улучшается – в целом по всем отраслям экономики не более 30 % крупных проектов признаются успешными. 20—35% работ по реализации ERP-систем заканчиваются неудачно, а 50—60% сопровождаются47 серьезными трудностями». КЛАССИЧЕСКИЕ ОШИБКИ УПРАВЛЕНИЯ ИТПРОЕКТОМ  Проект отстает от расписания? - Добавьте исполнителей!  Хотите ускорить разработку? - Откажитесь от тестирования!  В процессе выполнения проекта стала доступна новая версия операционной системы? -Выполняем апгрейд!  Один из ключевых исполнителей намеревается покинуть команду? -Увольняйте его только после окончания проекта!  4 категории типовых ошибок: кадры, процессы, продукт, технологии. 48 КЛАССИЧЕСКИЕ ОШИБКИ УПРАВЛЕНИЯ ИТПРОЕКТОМ  Кадры:  Недостаточная мотивация сильнее всего влияет на производительность и качество работы.  Следующее по степени влияния воздействие на результат проекта оказывает личные качества членов проектной команды и рабочие взаимоотношения между ними.  Нежелание руководителей проекта избавляться от проблемных сотрудников.  Классическая ошибка – добавление исполнителей в команду проекта, отстающего от расписания. Это не приводит к увеличению производительности старых членов команды 49 КЛАССИЧЕСКИЕ ОШИБКИ УПРАВЛЕНИЯ ИТПРОЕКТОМ Процессы: процессы управления ИТ- проектом включают как процессы, характерные для общего менеджмента, так и технические методологии.  Нерациональное распределение рабочего времени. Слишком много времени тратится на разработку замысловатых пользовательских интерфейсов в ущерб проектированию и разработке системы.  Неверная оценка длительности выполнения работ. Составление слишком сжатого расписания, исходя из оптимистических сроков завершения.  Неэффективный риск-менеджмент. Наиболее типичные риски на сегодня – это утрата спонсора, изменения в поведении заинтересованных сторон, расползание границ проекта и неудачи подрядчика.  Неэффективная работа с подрядчиками в аутсорсинговых проектах.  Снижение гарантий качества продукта. Сокращение времени тестирования на 1 день в итоге приводит к затратам 3-10 дней на исправление ошибок и переработку готового продукта 50 КЛАССИЧЕСКИЕ ОШИБКИ УПРАВЛЕНИЯ ИТПРОЕКТОМ Продукт:  Требования «золотой сервировки» - включающие лишние, чрезвычайные требования к функционалу и пользовательским интерфейсам решения  Излишнее усложнение продукта. Даже, если будут исключены требования «золотой сервировки», в среднем изменяется 25% требований за время его выполнения  «Золотая сервировка со стороны разработчиков». Разработчики часто пытаются использовать новые технологии для улучшения продукта, вне зависимости от того необходимы они в данном случае или нет  Исследовательская разработка 51 КЛАССИЧЕСКИЕ ОШИБКИ УПРАВЛЕНИЯ ИТПРОЕКТОМ Технологии:  Синдром «Серебряной пули». Нельзя при решении проблем на проекте возлагать надежду на использование новых технологий или новых практик.  Неправильная оценка времени при использовании новых технологий. Необходимо закладывать время на изучение\овладение технологиями.  Смена инструментов разработки в процессе выполнения проекта. Эффект от использования новых инструментов будет нивелирован затратами «на переделку», ошибками при использовании нового инструмента, необходимо время на обучение. Такой переход нельзя выполнять, если существенная часть работ по проекту уже выполнена. 52 ПРОЕКТЫ В ОБЛАСТИ РАЗРАБОТКИ И СОПРОВОЖДЕНИЯ ПО По уровню сложности и области применения разрабатываемого или модифицируемого ПО.  Проекты по разработке/модификации ответственного ПО (система управления атомным реактором). Требования к качеству работы и квалификации.  Проекты, связанные со сложными многофункциональными системами (пример (ERP), большая команда исполнителей, управление требованиями).  Малые проекты (интернет-магазины, сайты, простые приложения). Критична скорость и стоимость разработки.  «Наукоемкие» проекты (численные расчеты, разработка новых специальных алгоритмов). Сложность – в творческом характере процесса разработки.  Проекты по сопровождению или модификации унаследованных приложений, систем или баз данных (отсутствие проектной документации, недоступность специалистов). 53 ПРОЕКТЫ В ОБЛАСТИ РАЗРАБОТКИ И СОПРОВОЖДЕНИЯ ПО По способу применения разрабатываемого или модифицируемого ПО.  Проекты по разработке неотчуждаемого ПО («для себя»).  Разработка для заранее известного круга пользователей без дальнейшего тиражирования («внутреннее ПО»).  Разработка или модификация ПО для конкретного заказчика.  Разработка «коробочного продукта». 54 ПРОЕКТЫ В ОБЛАСТИ РАЗРАБОТКИ И СОПРОВОЖДЕНИЯ ПО По характеру отношений с заказчиком/потребителем.  Аутсорсинговые проекты – постановка целей и частично управление проектом ведутся на стороне заказчика; на стороне исполнителя ведется, в основном, реализация и кодирование.  Заказные проекты – постановка целей частично происходит на стороне заказчика, но все управление проектом ведется на стороне исполнителя.  Инициативная разработка – все аспекты проекта: постановка целей, планирование, управление, разработка и сопровождение ведутся на стороне исполнителя. 55 ПРОЦЕССЫ ПРОЕКТНОГО МЕНЕДЖМЕНТА ЛЕКЦИЯ 2 ПО ДИСЦИПЛИНЕ «УПРАВЛЕНИЕ ИНФОРМАЦИОННО-ТЕХНОЛОГИЧЕСКИМИ ПРОЕКТАМИ» Доцент кафедры «Бизнес-информатика», к.т.н., доц. Морозова О.А. Москва 2018 ПРОЕКТНЫЙ МЕНЕДЖМЕНТ Определение ISO 21500:  Проектный менеджмент – это применение методов, инструментов, техник и компетенций к проекту. Объединяет различные фазы жизненного цикла проекта. Реализуется посредством процессов 2 ПЛАН ЛЕКЦИИ 1. ЖЦ проекта 2. Области знаний и группы процессов проектного менеджмента 3. Выбор адекватных методологий управления ИТ-проектом 3 1. ЖИЗНЕННЫЙ ЦИКЛ ПРОЕКТА 4 ЖИЗНЕННЫЙ ЦИКЛ ПРОЕКТА  ЖЦ проекта – это набор чаще всего последовательных или перекрывающихся фаз проекта, количество и названия которых определяются спецификой управления, природой проекта и предметной областью.  Жизненный цикл проекта охватывает период времени от начала проекта до его планового окончания или досрочного прекращения.  ЖЦ – это основа управления проектом независимо от его специфики 5 ХАРАКТЕРИСТИКИ ЖЦ ПРОЕКТА Верхнеуровневый (рамочный) взгляд на структуру ЖЦ (PMBoK):  Инициация проекта  Организация и подготовка  Выполнение работ  Закрытие проекта Границами фаз жизненного цикла проекта обычно являются точки принятия решений, состав которых может зависеть от организационного окружения проекта. Точки принятия решений облегчают руководство проектом. На момент окончания последней фазы жизненного цикла проекта должны быть получены все результаты. 6 ХАРАКТЕРИСТИКИ ЖЦ ПРОЕКТА 7 Фазы проекта – это отдельные части в рамках проекта, требующие дополнительного контроля для эффективного управления достижением основного результата проекта. Высокоуровневый характер фаз проекта превращает их в элемент жизненного цикла проекта. 8 Базовые типы взаимосвязи фаз проекта: • Последовательная– следующая фаза начинается после завершения предыдущей (уменьшает неопределенность, увеличивает продолжительность) • Перекрывающаяся – следующая стадия начинается до завершения предыдущей (техника сжатия расписания, увеличивают риск) • Итеративная – планируется только одна фаза, планирование следующей фазы по мере выполнения работ (проекты с изменяемыми требованиями) Структура фаз позволяет разделить проект на логические подгруппы для более легкого управления, планирования и контроля. 9 ФАЗЫ ЖЦ РЕАЛЬНОГО ПРОЕКТА  Стадии ЖЦ должны соответствовать принятым стандартам (международным, государственным, отраслевым) или лучшим практикам для проектов с подобными характеристиками  Каждая стадия должна завершаться получением одного из результатов проекта, определенных в системе целей и результатов проекта  Разбиение на стадии должно обеспечить потребности в планировании и контроле работ по проекту для всех организаций, вовлеченных в проект 10 2. ОБЛАСТИ ЗНАНИЙ И ГРУППЫ ПРОЦЕССОВ ПРОЕКТНОГО МЕНЕДЖМЕНТА 11 ГРУППЫ ПРОЦЕССОВ УПРАВЛЕНИЯ ПРОЕКТОМ 12 ВЗАИМОДЕЙСТВИЕ ГРУПП ПРОЦЕССОВ ПО ФАЗАМ ПРОЕКТА 13 КЛАССИФИКАЦИЯ ПРОЦЕССОВ ПМ 1. процессы, присущие только проектному менеджменту и определяющие, как должны управляться работы проекта (стандарты PM); 2. процессы создания продукта, которые направлены на определение требований и создание конкретного продукта, услуги или результата; 3. поддерживающие (обеспечивающие) процессы, способствующие выполнению процессов проектного менеджмента с точки зрения логистики, финансов, бухгалтерского учета и обеспечения безопасности. 14 ОБЛАСТИ ЗНАНИЙ ПРОЕКТНОГО МЕНЕДЖМЕНТА (PMBOK ) Управление интеграцией Управление содержанием Управление сроками Управление стоимостью Управление качеством Управление человеческими ресурсами Управление коммуникациями Управление рисками Управление закупками Управление заинтересованными сторонами 15 16 17 18 УСЛОВИЯ УСПЕШНОЙ РЕАЛИЗАЦИИ ПРОЕКТА Для успешной реализации проекта необходимо :  выбрать те процессы, которые необходимы для достижения целей проекта;  использовать определенный подход к формированию и изменению требований к продукту проекта и планов для достижения целей проекта и удовлетворения предъявляемых к проекту требований;  учесть требования спонсора проекта, заказчика и других заинтересованных лиц;  определить границы содержания проекта и управлять им в пределах, определяемых ограничениями, для получения результатов проекта, учитывая риски проекта и потребности в ресурсах;  обеспечивать исполнение обязательств всеми участниками проекта, включая заказчика и куратора проекта. (ISO 21500) 19 2. ВЫБОР АДЕКВАТНЫХ МЕТОДОЛОГИЙ УПРАВЛЕНИЯ ИТ-ПРОЕКТОМ 20 МЕТОДОЛОГИЯ ЭТО?  учение об организации разных видов деятельности человека, а именно - научной, практической, учебной, игровой и художественной. В методологии используют различные способы, стратегии и методы построения определенного вида деятельности, разработанные специалистами из этой области знаний на основании глубокого изучения принципов деятельности и процессов работы в выбранном направлении  учение о методах, способах и стратегиях исследования предмета  система принципов и способов организации и построения теоретической и практической деятельности, а также учение об этой системе  Совокупность методов, применяемых в отдельных науках (С.И. Ожегов) 21 ПРОБЛЕМА РАЗРАБОТКИ МЕТОДОЛОГИИ УПРАВЛЕНИЯ ИТ-ПРОЕКТОМ Необходимо учесть: Модель бизнеса компании, ее стратегию, культуру, особенности выполняемых проектов (технологии, риски, наличие финансовых ресурсов) Сложность выбора:  Большое количество стандартов, сложность их структуры  Непрерывное развитие теории управления разработкой ПО (новые методологии, стандарты, модели, техники)  Отсутствие критерия выбора методологии  Необходимость использования различных методологий для разных проектов компании 22 КЛАССИФИКАЦИЯ МЕТОДОЛОГИЙ По характеру обоснования рекомендаций:  Концептуальные – получены логическим методом (основаны на теории менеджмента, процессном управлении, управлении качеством и т.п.). Примеры СММ, RUP  Эмпирические – обобщение лучших практик ИТ-проектов (XP, SCRUM, Cristal) По назначению:  Модели зрелости (СММ,)  Процессные модели (SPICE, ISO 9000)  Проектные методологии (MSF, SCRUM, XP)  Групповые практики (PSP, TSP) 23 КЛАССИФИКАЦИЯ МЕТОДОЛОГИЙ По характеру реализации проекта:  Прогнозируемые – возможно детально планировать будущее (каскадная модель ЖЦ ПО).  Адаптивные – учитывают психологические особенности процесса разработки ПО. Нацелены на преодоление неполноты требований и их постоянное изменение. Важна квалификация команды разработчиков (Scrum, XP). По характеру знаний:  Инженерные  Управленческие  Интегрированные 24 КЛАССИФИКАЦИЯ МЕТОДОВ, МОДЕЛЕЙ И СТАНДАРТОВ РАЗРАБОТКИ ПО 25 МЕТОДОЛОГИИ И СТАНДАРТЫ УПРАВЛЕНИЯ ИТ ITIL (IT Infrastructure Library ) - лучшие практики организации работы подразделений или компаний, занимающихся предоставлением услуг в области ИТ. COBIT (Control Objectives for Information and Related Technology) - стандарты и руководств а в области управления ИТ, аудита ИТ и ИТ-безопасности. 26 ДЕКОМПОЗИЦИЯ ПРОЦЕССОВ УПРАВЛЕНИЯ ИТ (COBIT) Домен – Планирование и организация Процесс - Управление проектами Действия процесса:  Определить методологию управления проектами\программами для ИТ-инвестиций.  Поддерживать методологию управления проектами.  Организовывать и вести мониторинг проектов.  Создавать описание проектов, план-графики, планы качества, бюджеты, управлять рисками.  Обеспечить участие заинтересованных сторон в проекте.  Осуществлять контроль над проектами и внесением изменений в проекты.  Определить и реализовывать методы анализа результатов проекта. 27 ПРОЦЕССЫ В УПРАВЛЕНИИ ИТ-ПРОЕКТОМ Два измерения деятельности: 1. Инженерия (проектирование, программирование, тестирование и др.) 2. Управление проектом (планирование и контроль действий инженерии, позволяют достичь цель проекта по срокам, качеству, стоимости). Небольшие проекты – неформальные приемы управления. Крупные коммерческие проекты – необходимы формальные процессы 28 ПРОЦЕССЫ В УПРАВЛЕНИИ ИТ-ПРОЕКТОМ  Процессы представляют коллективное знание (лучшие практики). Их использование повышает вероятность успешного завершения проекта.  Позволяют предсказать результаты проекта (результат проекта зависит от устойчивости процессов).  Способствуют эффективному обучению организации  Снижают уровень риска проекта. 29 ФОРМИРОВАНИЕ МОДЕЛИ ЖЦ ИТ-ПРОЕКТА  Выбор жизненного цикла проекта определяет подход, который будет применяться для управления проектом  Правильный выбор ЖЦ может значительно повысить эффективность реализации проекта  Универсального жизненного цикла не существует 38 МОДЕЛЬ НЕОПРЕДЕЛЁННОСТЬКОМПЛЕКСНОСТЬ ГИБКОЕ УПРАВЛЕНИЕ ПРОЕКТАМИ  Требования Заказчика, сформулированные в начале проекта фиксируются в т.н. customer story и не являются окончательными;  ЖЦ проекта представляет собой последовательность ограниченных во времени циклов, в каждом из которых выпускается работоспособная версия продукта с постепенно наращиваемым функционалом;  Содержание и качество каждого цикла планируется вместе с Заказчиком в начале каждого цикла и подтверждается вместе с Заказчиком в конце цикла;  В конце каждого цикла командой проекта проводится анализ проделанной работы с целью избежать повторения ошибок на следующем витке и улучшить качество разработки (т.к. следующая итерация, как правило, использует те же технологии, что и предыдущая). ПРЕИМУЩЕСТВА И ОГРАНИЧЕНИЯ ГИБКИХ МЕТОДОЛОГИЙ ПРОЕКТНОГО УПРАВЛЕНИЯ Преимущества Заказчик быстро получает работоспособную версию продукта Ограничения первую Количество циклов заранее не определено, конечные сроки размыты, сложно планировать выделение ресурсов на проект Снижается риск получить продукт, не Не все заказчики способны к постоянному удовлетворяющий заказчика, т.к. заказчик взаимодействию с командой проекта постоянно вовлечен в процесс Качество продукта повышается, поскольку Требует повышенных после каждой итерации выполняется анализ квалификации команды выполненных работ и ошибок инфраструктуре требований исполнителя к и SOFTWARE EXTENSION TO THE PMBOK® GUIDE Опубликовано в 2014 PMBoK 6th edition –»Agile Practice Guide» (при совместном участии PMI и Agile Alliance) ФОРМИРОВАНИЕ МОДЕЛИ ЖЦ ИТ-ПРОЕКТА Специфическая структура ИТ-проекта в зависимости от задач, целей автоматизации, предметной области, ИТ-продукта Этапы ЖЦ ИТ-продукта не совпадают с этапами ЖЦ ИТ-проекта  Фазы ЖЦ продукта могут накладываться на фазы ЖЦ проекта.  Каждая фаза ЖЦ продукта может включать в себя все этапы ЖЦ проекта (ГОСТ Р ИСО/МЭК 15288 на каждой фазе ЖЦ продукта предусмотрены этапы планирования, оценки, контроля, принятия решения) 43 ТИПЫ ЖЦ  Предиктивный ЖЦ (полностью управляемый планом) - тщательное планирование на ранних этапах проекта, низкий уровень изменений требований проекта и единовременная поставка результата  Итеративный ЖЦ – вид адаптивного жизненного цикла, который подразумевает итеративное улучшение или модификацию продукта на основе обратной связи. Каждый этап может повторяться такое количество раз, которое необходимо для достижения желаемого результата.  Инкрементальный ЖЦ – подход, который подразумевает частую поставку готовых к использованию продуктов (частей продукта). Данный тип жизненного цикла ориентирован на быстрое создание бизнес-ценности для клиента.  Гибкий ЖЦ – подход, который сочетает черты итеративного и инкрементального жизненных циклов и направлен на улучшение продукта и увеличение частоты поставок. Гибкие жизненные циклы подходят для использования в проектах с высоким уровнем изменения требований  Адаптивный ЖЦ (управляемый изменениями или гибкий (agile) )- направлены на реагирование на высокие уровни изменений и требуют постоянной вовлеченности заинтересованных сторон. Адаптивные методы являются также итеративными и инкрементными, но отличаются тем, что итерации происходят очень быстро (продолжительность обычно составляет 2–4 недели) и фиксированы по срокам и стоимости. 44 ТИПЫ ЖЦ ПРОДУКТА ПРОЕКТА 45 МОДЕЛЬ ПРЕДИКТИВНОГО ЖЦ  Предиктивный ЖЦ – форма жизненного цикла проекта, при которой содержание, сроки и стоимость определяются на ранних фазах ЖЦ МОДЕЛЬ АДАПТИВНОГО ЖЦ  Адаптивный – жизненный цикл проекта, может быть итеративным или инкрементным Итеративный (пример) Инкрементальный (пример) КОНТИНУУМ ЖИЗНЕННЫХ ЦИКЛОВ ПРОДУКТА ПРОЕКТА Между типами жизненных циклов нет границ, речь идет о континууме вариантов. Критерий Предиктивный подход Инкрементальный подход Agile Требования Полностью специфицированы на этапах инициализации и планирования Фиксированы на весь проект, но уточняются с заданной периодичностью по мере выполнения фаз проекта Изменения Не приветствуются Фиксируются как в начале проекта, так и в начале каждого цикла. Уточняются по мере необходимости в процессе разработки (с переменной периодичностью) Могут вноситься в начале каждого цикла Могут вноситься с ограничениями на основании результатов каждой фазы Готовый продукт По окончании проекта На последних фазах проекта По истечении нескольких начальных циклов Управление рисками и Риски и Управление рисками и стоимостью Управление по планам, уточняемым и стоимостью по мере стоимость осуществляется по плану, детально изменения требований и проработанному с учетом требований детализируемым ограничений периодически при и ограничений, определенных до изменении требований и начала разработки ограничений в процессе разработки Ключевые Вовлекаются в проект на milestones, Вовлекаются в проект Постоянно вовлекаются в стейкхолдеры предусмотренных расписанием. Чаще периодически проект всего при завершении отдельных этапов проекта КАСКАДНАЯ МОДЕЛЬ ЖЦ 50 ВАРИАНТЫ ВЫДЕЛЕНИЯ ФАЗ ПРОЕКТА ДЛЯ АДАПТИВНЫХ ПРОЕКТОВ  Последовательные фазы, основанные на итерациях (аналог Scrum) • Фазы с непрерывным наложением друг на друга (аналог Kanban) ФАКТОРЫ УСПЕХА ИТ-ПРОЕКТА  Участие руководства в проекте.  Наличие и соблюдение плана проекта  Ясные и четкие цели и требования  Участие специалистов Заказчика в проекте  Качество ПО и квалификация специалистов  Реинжениринг бизнес-процессов до внедрения  Наличие ИТ-стратегии у клиента  Получение быстрой и эффективной отдачи Возможно сформировать рациональные методы управления проектами – методологию внедрения 52 МЕТОДОЛОГИИ ВНЕДРЕНИЯ ПО Разрабатываются ведущими вендорами Выгоды для Заказчика:  Создания решения, максимально удовлетворяющего требованиям клиента.  Эффективного использования ресурсов проекта.  Минимизации сроков и затрат на внедрение.  Уменьшения рисков проекта. Для разработчика:  Методическая база для обучения новых сотрудников.  Сокращаются внутренние расходы на реализацию проектов.  Улучшается взаимодействие между членами команды.  Эффективно распределяются ресурсы между проектами 53 МЕТОДОЛОГИИ ВНЕДРЕНИЯ ПО Технология создания продукта Технология управления проектом Корпоративная методология внедрения Этапы разработки: Выделение фаз (этапов) проекта. Выделение процессов, выполняемых на этапах 54 AIM – APPLICATION IMPLEMENTATION METHOD  методика внедрения готовых приложений, разработана компанией Оракл для внедрения пакета готовых приложений Oracle E-Business Suite  представляет собой детальное описание задач(процессов), выполняемых в ходе проекта, с указанием последовательности выполнения и ответственных ролей проектной группы 55 AIM – APPLICATION IMPLEMENTATION METHOD  Определение бизнес-требований- описание требований заказчика к развертываемой системе. разрабатываются детальные модели хозяйственной деятельности (бизнес-процессов) заказчика после развертывания системы.  Отображение бизнес-требований- анализ того, какая функциональность Oracle E-Business Suite и каким образом может использоваться для реализации функциональных возможностей, необходимых заказчику, доработки необходимо сделать, а также значения параметров настройки Oracle E-Business Suite.  Функциональная и техническая архитектура – в ходе этого процесса происходит построение технической архитектуры, необходимой для работы системы.  Разработка дополнительной функциональности – в рамках этого процесса разрабатывается программное обеспечение, необходимое для реализации функциональности, отсутствующей в Oracle E-Business Suit.  Конвертация данных – процесс охватывает задачи, связанные с переносом данных из существующих систем (возможно в бумажном виде) во внедряемую систему. Документирование – вэтом процессе создается документация на систему.  Тестирование системы - разрабатываются сценарии тестирования и производится проверка системы на реализуемость требований.  Тестирование на производительность- в ходе этого процесса выполняются задачи, связанные с тестированием системы на «узкие» места по производительности.  Обучение - обучение проектной группы, с которого начинается проект по внедрению, и обучение конечных пользователей, которым проект заканчивается.  Ввод в эксплуатацию- в ходе этого процесса рассматриваются все вопросы, связанные с вводом в эксплуатацию системы и ее последующим сопровождением. 56 AIM – APPLICATION IMPLEMENTATION METHOD В ходе проекта все фазы внедрения накладываются одна на другую и итеративно повторяются:  внедрение по разным бизнес-областям и даже бизнес-процессам из одной области происходит параллельно  в процессе внедрения реализуется принцип итеративной проработки (уточнение требований влияет на реализацию, а реализация влияет на уточнение требований), при этом постоянно происходит возврат от более поздних задач к более ранним. Результат всегда документируется Документация AIM содержти: Шаблоны документов-результатов всех задач AIM входят в состав стандартной поставки AIM Описание типовых ролей, выполняемых участниками проекта в ходе проекта и при эксплуатации (на практике каждый реальный участник проекта должен выполнять несколько ролей). 57 ACCELERATED SAP IMPLEMENTATION METHODOLOGY 58 Итеративная методология (сходна с RUP), предполагает использование объектно-ориентированного моделирования. MSF (MICROSOFT SOLUTION FRAMEWORK) Фазы:  Разработка концепции  Проектирование  Разработка  Стабилизация  Внедрение 59 RUP (RATIONAL UNIFIED PROCESS) Итеративная модель разработки, цикл разработки - 4 фазы:  Начало  Исследование  Построение  Внедрение Каждая фаза может быть разбита на этапы(итерации), в результате выпускается версия ПО для внутреннего или внешнего использования. Каждый цикл завершается генерацией версии системы. Создание и сопровождение моделей на базе UML. 60 КОРПОРАТИВНАЯ СИСТЕМА УПРАВЛЕНИЯ ПРОЕКТАМИ ЛЕКЦИЯ 3 ПО ДИСЦИПЛИНЕ «УПРАВЛЕНИЕ ИНФОРМАЦИОННО-ТЕХНОЛОГИЧЕСКИМИ ПРОЕКТАМИ» Доцент кафедры «Бизнес-информатика», к.т.н., доц. Морозова О.А. Москва 2018 ОПРЕДЕЛЕНИЕ КСУП  Корпоративная система управления проектами (КСУП) - это интегрированный комплекс методических, административных и информационных средств, позволяющих поддерживать процессы проектного управления на предприятии  Цели внедрения КСП:  повышение эффективности проектной деятельности  единый подход к управлению проектами  создание корпоративной базы знаний проектного управления  отбор проектов, соответствующих стратегическим целям 2 АКТУАЛЬНОСТЬ ЗАДАЧИ ВНЕДРЕНИЯ КСУП 3 4 ПРИОРИТЕТНЫЙ СПИСОК УЛУЧШЕНИЙ ПОСЛЕ ВНЕДРЕНИЯ КСУП 1. Появилась актуальная общая картина проектов 2. Появилось четкое распределение прав и обязанностей между участниками проектной деятельности 3. Повысилась эффективность распределения ресурсов между проектами, 4. Сократились временные задержки в выполнения проектов 5. Повысилась удовлетворенность заказчика результатами проектов 6. Сократились превышения бюджетов проекта По результатам опроса, проведенного компанией PM Expert 5 ПЛАН ЛЕКЦИИ 1. Методология проектного управления 2. Оргструктура проектного управления 3. Информационное обеспечение 6 КОМПОНЕНТЫ КСУП Корпоративная методология управления проектами – стандарт, регламентирующий проектную деятельность предприятия Организационная структура проектного управления – организация участников проектной деятельности Информационная система управления проектами – инструмент для автоматизации проектной деятельности 7 1. МЕТОДОЛОГИЯ ПРОЕКТНОГО УПРАВЛЕНИЯ 8 ОПРЕДЕЛЕНИЕ  Методология - система практик, техник, процедур и правил (PMBoK)  Корпоративная методология проектного управления – это определенный, документированный набор политик, практик, процессов, инструментов, техник и шаблонов, который обеспечивает реализацию портфелей, программ и проектов в организации  Корпоративная методология должна кастомизировать процессы УП с учетом уровня зрелости проектного управления на предприятии, организационной зрелости и др. факторов 9 ЭФФЕКТ ОТ ИСПОЛЬЗОВАНИЯ МЕТОДОЛОГИИ  снижения затрат на управление проектами за счет стандартизации процессов и единого понимания содержания управления проектами среди сотрудников компании  повышение экономической эффективности проектов  четкое разделение власти и ответственности между участниками проекта, в том числе топ-менеджеров, руководителей среднего звена и членов команды проекта  улучшение мониторинга проектов с помощью единой системы отчетов по текущей ситуации на проекте  возможность накапливать и анализировать знания из реализованных проектов 10 СТАТИСТИКА  42% организаций не имеют корпоративной методологии УП,  7% имеют полностью апантированную методологию,  11% используют частично адаптированную методологию,  3% минимально адаптированную  37% сильно адаптировнную методологию.  Для организаций, использующий полностью адаптированную методологию УП 82% проектов завершаются успешно, В организациях, не имеющих какойлибо методологии УП успешных проектов только 67%. Данные Симпозиума PMO 8-11 ноября 2015 11 ЭЛЕМЕНТЫ МЕТОДОЛОГИИ УП  Правила идентификации проектов  Классификацию проектов компании  Ключевые роли и их взаимодействие на проекте  Жизненный цикл проекта  Регламентированные процессы для каждого этапа жизненного цикла проекта  Регламентированный процесс взаимодействия с внешними подрядчиками  Интеграцию процессов УП с другими корпоративными процессами  Шаблоны документов по управлению проектами 12 ВАРИАНТ КЛАССИФИКАЦИИ ПРОЕКТОВ ПО СЛОЖНОСТИ Тип проекта на основании интегральной оценки Базовые проекты Проекты высокого уровня сложности От 211 до 328 Характетистики сложности проекта Издержки, финансирование и бюджет Проекты Проекты низкого среднего уровня уровня сложности сложности Менее 55 От 55 до 124 От 125 до 210 Диапазон максимальных взвешенных баллов Базовый Низкий Средний 22 44 68 Атрибуты команды проекта Расписание, зависимости и длительность 5 8 9 16 18 26 34 40 Опыт команды и новизна решения 7 Значимость проекта (государственная или федеральная, 6 ориентированность на клиентов, ключевые бизнесфункции) Степень вовлеченности конечного пользователя 2 14 20 25 34 36 56 8 14 24 Преобразование данных из других источников 4 6 8 Общая оценка риска, взятая из проектного предложения 5 10 20 30 Максимально возможная сумма баллов 125 211 328 55 Сложный 100 13 РЕГЛАМЕНТНАЯ БАЗА УП НА РОССИЙСКИХ ПРЕДПРИЯТИЯХ • шаблоны документов по управлению проектами, • регламенты работы с информационной системой управления проектами, • должностные инструкции участников проектной деятельности, • ролевая модель участников проектной деятельности, • детальное описание процессов управления проектами, • положение о проектном офисе, • положение о мотивации участников проектной деятельности, регламент управления рисками 14 2. ОРГАНИЗАЦИОННАЯ СТРУКТУРА 15 ОРГАНИЗАЦИОННАЯ СТРУКТУРА Организационная (ролевая) структура проекта (Project organization) – наиболее соответствующая проекту временная организационная структура, включающая всех его участников и создаваемая для успешного достижения целей проекта ОРГАНИЗАЦИОННАЯ СТРУКТУРА Зависит от специфики объекта управления (проекта):  Масштаб и сложность проекта  Наличие субподрядчиков  Тип проекта  Факторы среды предприятия (зрелость процессов проектного управления, уровень корпоративной культуры, национальные и отраслевые особенности и стандарты, инфраструктура, доступные ресурсы, интересы заинтересованных сторон и пр.) ОСНОВЫЕ ТЕРМИНЫ  функция  роль  должность ОРГАНИЗАЦИОННАЯ СТРУКТУРА ИСПОЛНИТЕЛЕЙ  Функция — это вид деятельности, выполняемой в ходе проекта. Выполнение каждой функции требует наличия определенной специфической квалификации и способностей. Примеры функций:  Анализ. Извлечение, документирование и сопровождение требований к продукту.  Управление. Определение и управление производственными процессами.  Производство. Проектирование и разработка ПО.  Тестирование. Тестирование ПО.  Обеспечение. Производство дополнительных продуктов и услуг. ОРГАНИЗАЦИОННАЯ СТРУКТУРА ИСПОЛНИТЕЛЕЙ  Роль – это временное назначение сотруднику набора функций в рамках конкретного проекта Примеры проектных ролей:  Заказчик проекта - физическое или юридическое лицо, являющееся владельцем результатов проекта  Менеджер проекта - лицо, осуществляющее управление проектом и ответственное за результат проекта. Отчитывается перед куратором и заказчиком  Куратор проекта - Лицо, отвечающее за обеспечение проекта ресурсами и осуществляющее административную, организационную, финансовую и иную поддержку проекта  Команда проекта - совокупность лиц, групп и организаций, объединенных во временную организационную структуру для выполнения работ проекта. Подотчетна менеджеру проекта ОРГАНИЗАЦИОННАЯ СТРУКТУРА ИСПОЛНИТЕЛЕЙ  Должность – это сертифицированная способность играть определенные роли и выполнять определенные функции (не привязана к проекту). ФУНКЦИИ И РОЛИ Анализ  Бизнес-аналитик. Построение модели предметной области (онтологии).  Бизнес-архитектор. Разрабатывает бизнес-концепцию системы. Определяет общее видение продукта, его интерфейсы, поведение и ограничения.  Системный аналитик. Отвечает за перевод требований к продукту в функциональные требования к ПО.  Специалист по требованиям. Документирование и сопровождение требований к продукту.  Менеджер продукта (функциональный заказчик). Представляет в проекте интересы пользователей продукта. Управление  Руководитель проекта. Отвечает за достижение целей проекта при заданных ограничениях (по срокам, бюджету и содержанию), осуществляет операционное управление проектом и выделенными ресурсами.  Куратор проекта. Оценка планов и исполнения проекта. Выделение ресурсов.  Системный архитектор. Разработка технической концепции системы. Принятие ключевых проектных решений относительно внутреннего устройства программной системы и её технических интерфейсов.  Руководитель группы тестирования. Определение целей и стратегии тестирования, управление тестированием.  Ответственный за управление изменениями, конфигурациями, за сборку и поставку программного продукта. ФУНКЦИИ И РОЛИ Производство  Проектировщик. Проектирование компонентов и подсистем в соответствие с общей архитектурой, разработка архитектурно значимых модулей.  Проектировщик базы данных.  Проектировщик интерфейса пользователя.  Разработчик. Проектирование, реализация и отладка отдельных модулей системы Тестирование  Проектировщик тестов. Разработка тестовых сценариев.  Разработчик автоматизированных тестов.  Тестировщик. Тестирование продукта. Анализ и документирование результатов. Обеспечение  Технический писатель.  Переводчик.  Дизайнер графического интерфейса.  Разработчик учебных курсов, тренер.  Продажи и маркетинг. ОРГАНИЗАЦИЯ ПРОЕКТНОЙ КОМАНДЫ  Каждый проект имеет свою организационную структуру, которая определяет распределение ответственности и полномочий среди участников проекта, а также обязанностей и отношений отчетности.  Чем меньше проект, тем больше ролей приходится совмещать одному исполнителю.  Возможное совмещение ролейролей  Руководитель проекта + системный аналитик (+ системный архитектор)  Системный архитектор + разработчик  Системный аналитик + проектировщик тестов (+ технический писатель)  Системный аналитик + проектировщик интерфейса пользователя  Ответственный за управление конфигурациями + ответственный за сборку и поставку (+ разработчик)  Нежелательно совмещать  Разработчик + руководитель проекта  Разработчик + системный аналитик.  Разработчик + проектировщик интерфейсов пользователя  Разработчик + тестировщик ОРГСТРУКТУРА ПРОЕКТА  может также включать коллегиальные органы управления:  комитет управления проектом  центры компетенций,  группы обеспечения качества и прочие структуры  может включать функциональных руководителей, менеджеров по операциям и деловых партнеров (поставщиков или подрядчиков). МОДЕЛИ ОРГАНИЗАЦИОННОЙ СТРУКТУРЫ  Организационная структура компании отражает ее внутреннее устройство, потоки управляющих воздействий, распределение труда и специфические особенности производства.  Модели организационных структур :  Функциональная (иерархическая) - использование существующей функциональной иерархической структуры организации. Менеджер проекта осуществляет лишь общую координацию работ  Проектная - комплекс работ проекта разрабатывается независимо от иерархической структуры организации.  Матричная структура - это промежуточная форма, объединяющая преимущества проектной и функциональной структур управления. ИЕРАРХИЧЕСКАЯ СТРУКТУРА ИЕРАРХИЧЕСКАЯ СТРУКТУРА  Сохраняется принцип единоначалия  Понятные и стабильные условия работы  Хорошо приспособлены для операционной деятельности.  Специализация подразделений позволяет накапливать экспертизу.  Недостаточно полномочий у МП.  Затруднено принятие решений и коммуникации между исполнителями. Осуществляются только через руководство.  Управление сконцентрировано и держится на компетенции высшего руководства  Как правило, неэффективен контроль за ходом проекта (нет целостной картины) ПРОЕКТНАЯ СТРУКТУРА ПРОЕКТНАЯ СТРУКТУРА  Проект организуется как самостоятельное производственное подразделение.  Персонал на проект набирается по временным контрактам.  После завершения проекта персонал увольняется.  Медленный старт.  Опыт не аккумулируется.  Команды не сохраняются. Может использоваться в крупных, критически важных проектах или в проектно-ориентированных компаниях. СЛАБАЯ МАТРИЦА  Роль и полномочия МП сильно ограничены. Реальное руководство проектом осуществляет один из функциональных руководителей. МП помогает этому руководителю собирать информацию о статусе выполняемых проектных работ, учитывает затраты, составляет отчеты. МП отвечает за координацию задач по проекту, но имеет ограниченную власть над ресурсами СБАЛАНСИРОВАННАЯ МАТРИЦА  Менеджер проекта реально МП координирует все работы и разделяет ответственность за достижение цели с руководителями функциональных подразделений управляет выделенными на проект ресурсами. Он планирует работы, распределяет задачи среди исполнителей, контролирует сроки и результаты, несет полную ответственность за достижение целей проекта, при соблюдении ограничений.  Проблема двойного подчинения. Руководитель функционального подразделения и менеджер проекта имеют примерно равное влияние на материальный и профессиональный рост разработчиков. СИЛЬНАЯ МАТРИЦА Менеджер проекта обладает максимальными полномочиями, но и несет полную ответственность за выполнение задач проекта Проектное управление является самостоятельной областью компетенции. Поэтому в сильной матрице менеджеры проектов объединяются в самостоятельное функциональное подразделение — офис управления проектами (ОУП). ОУП разрабатывает корпоративные политики и стандарты в области проектного управления, планирует и осуществляет профессиональное развитие менеджеров. СРАВНЕНИЕ МОДЕЛЕЙ ОРГАНИЗАЦИОННЫХ СТРУКТУР Сравнительные характеристики Полномочия МП Возможности распоряжаться ресурсами Бюджет проекта контролируется Занятость менеджера проекта Занятость административного персонала проекта Ограниченные Модель оргструктуры Сбалансированная матрица От низких до средних Средние или высокие Ограниченные От низких до средних Средние или высокие Функциональным руководителем Частичная Функциональным руководителем Частичная Совместно Полная Проектным менеджером Полная Проектным менеджером Полная Полная Частичная Частичная Полная Полная Функциональная Незначительные или отсутствуют Незначительные или отсутствуют Слабая матрица Сильная матрица Проектная Очень высокие Очень высокие МАТРИЧНАЯ ОРГАНИЗАЦИЯ  В разработке ПО наиболее распространена матричная организация. В компаниях, которые занимаются продуктовой разработкой ПО, функциональные подразделения определяются в соответствие с линейкой продуктов. Например, отдел разработки CRM-систем, отдел разработки финансовых систем, отдел разработки дополнительных продуктов.  В компаниях, которые ориентированы в основном на заказную разработку ПО, функциональные подразделения чаще объединяются в соответствие с используемыми информационными технологиями. Например, отдел разработки баз данных, отдел разработки J2EEприложений, отдел веб-разработок, отделы тестирования, документирования и т.д. ПРОЕКТНЫЙ ОФИС (ОУП)  подразделение организации или орган, осуществляющий различные функции, относящиеся к централизации и координации управления проектами, входящими в его компетенцию (PMBoK)  Роль зависит от целей создания, степени зрелости процессов проектного управления, оргструктуры предприятия 38 ФУНКЦИИ ОУП  управление общими ресурсами для проектов  разработка методологии, лучших практик и стандартов управления проектами  наставничество, обучение, инструктирование МП  мониторинг соответствия стандартам, процедурам и шаблонам управления проектами посредством аудитов проектов  разработка и управление процедурами, шаблонами проекта и другой общей документацией  централизованный обмен информацией между заинтересованными сторонами проектов. 39 ТИПЫ ОУП Иерархия построена на базе высокоуровневой модели Portfolio, Programme and Project Offices (P3O) guidance, OGC 40 ПРИМЕР ИЕРАРХИИ ОУП Проектный комитет Линейный руководитель Линейный руководтитель КОУП ОУП ОУП ОУП Проект Функциональное подчинение Административное подчинение Проект Проект Проект 41 3.ИНФОРМАЦИОННАЯ СИСТЕМА УПРАВЛЕНИЯ ПРОЕКТАМИ 42 ОПРЕДЕЛЕНИЕ ИСУП  набор IT-инструментов, предназначенный для информационной поддержки управления проектами в компании  не обязательно единая информационная система проектного управления 43 ТРЕБОВАНИЯ К ФУНКЦИОНАЛЬНОЙ АРХИТЕКТУРЕ ИСУП (ПО ЭТАПАМ ЖЦ ПРОЕКТА) Инициализа ция Ведение укрупненных Сохранение основных параметров нового проекта (цель, старт, финиш, параметров проекта контрольные события, бюджет) 44 ТРЕБОВАНИЯ К ФУНКЦИОНАЛЬНОЙ АРХИТЕКТУРЕ ИСУП (ПО ЭТАПАМ ЖЦ ПРОЕКТА) Планирование проекта Описание структуры работ Календарносетевое планирование Планирование стоимости Планирование ресурсов Наглядное представление структуры работ, планирование сверху-вниз и снизу-вверх Агрегирование показателей проекта по иерархии работ, наглядное представление структуры проекта Составление расписания проекта, формирование сетевого графика проекта. Поддержка различных логических зависимостей между работами проекта(финиш-старт, старт-старт, финиш-финиш и пр.) Определение вех (контрольных точек) проекта Многоуровневая система сетевых графиков, учет межпроектных зависимостей Расчет критического пути по проекту\нескольким проектам Планирование стоимости в разрезе работ, статей затрат, времени и др. аналитических разрезах Учет различных ставок ресурсов Проведенияе стоимостного анализа Ведение единого корпоративного справочника ресурсов. Выделение ресурсов разных типов (трудовых, материальных, механизмов), описание структуры ресурсов и их доступности (календари ресурсов). Назначение ресурсов на задачи, назначение ответственных. Моделирования поведения проекта при различных ограничениях на использование ресурсов. Анализ загрузки ресурсов по проекту и портфелю, оптимизация распределения ресурсов 45 ТРЕБОВАНИЯ К ФУНКЦИОНАЛЬНОЙ АРХИТЕКТУРЕ ИСУП (ПО ЭТАПАМ ЖЦ ПРОЕКТА) Реализация проекта Формирование заданий исполнителям Сбор фактической информации о ходе реализации проекта Формирование индивидуальных управление временем, графиков работы членов проектной команды Публикация проектной информации на интранет-интернет-сервере. Обновление данных проекта с использованием удаленного доступа или электронной почты. Возможность обмена информацией с любыми другими приложениями; Поддержка версионирования планов, использование различных версий планов для реализации сценарного анализа, прогнозирования и отслежтвания ретроспективы. Динамическое перепланирование графика работ и перераспределение ресурсов Контроль Контроль ключевых показателей проекта выполнения Фиксация плановых показателей проекта. Ввод текущей информации о выполнении проекта работ, загрузке ресурсов, расходах и т. д. Сравнение плановых показателей с фактическими. Моделирование хода предстоящих работ; Расчет и анализ показателей освоенного объема Визуализация Наглядное представление информации о проекте в виде различных диаграмм и графиков: проектных календарный график выполнения работ (диаграмма Ганта), сетевая диаграмма проекта, данных и гистограммы загрузки ресурсов и т. д. 46 формирование Создание всех необходимых отчетов. отчетности Анализ что-если ТРЕБОВАНИЯ К ФУНКЦИОНАЛЬНОЙ АРХИТЕКТУРЕ ИСУП (ПО ЭТАПАМ ЖЦ ПРОЕКТА) Завершение проекта Сбор информации по Формирование итоговой отчетности проекту в корпоративной проекту, портфелю проектов. базе, сбор и обработка статистики по проекту по 47 ВЫБОР ИСУП  Нет ни одной системы управления проектами, которая бы могла успешно поддерживать все виды и типы проектов (исследование Gartner) .  Заказчики решений должны подбирать системы под свой бизнес  При подборе решений Gartner рекомендует определить текущий уровень зрелости компании, так как многие решения могут внедрены только при условии существования уже некоторых бизнес-процессов или практик в компании 48 СООТВЕТСТВИЕ УРОВНЕЙ ЗРЕЛОСТИ ПРОЕКТНОГО УПРАВЛЕНИЯ (ПО ГАРТНЕРУ) ИСПОЛЬЗУЕМЫМ ИТИНСТРУМЕНТАМ Уровень зрелости Описание Используемые ИТ-инструменты Отсутствуют формализованные процессы управления проектами Формализованные только некоторые и критичные процессы управления проектами, пользователи используют индивидуальные версии системы управления проектами. Формализовано управление программами проектов ИТ-инструменты управления проектами не используются Простейшие настольные систему управления проектами 1 2 3 Все процессы описаны и имеется формальная процедура оптимизации портфеля проектов, т.е. формализован порядок отбора проектов к запуску. Имеются инструменты для коллективной работы в проектах, при этом часто используются разные инструменты под разные задачи и они не интегрированы Используются несколько разных систем управления проектами с усилением их централизованного управления. 49 СООТВЕТСТВИЕ УРОВНЕЙ ЗРЕЛОСТИ ПРОЕКТНОГО УПРАВЛЕНИЯ (ПО ГАРТНЕРУ) ИСПОЛЬЗУЕМЫМ ИТИНСТРУМЕНТАМ Уровень зрелости Описание Используемые ИТ-инструменты 4 Используются процедуры оптимизацияи В компании применяются несколько систем управления проектами, но все инструменты загрузки ресурсов и управление по доступны всем сотрудникам. бизнес-целям. 5 Процедуры управления проектами и оптимизации портфеля проектов охватывают весь Бизнес компании Используется одна интегрированная система управления проектами для всех целей и нужд 50 ИНСТРУМЕНТЫ ДЛЯ ПОДДЕРЖКИ ПРОЕКТНОГО УПРАВЛЕНИЯ  Электронные таблицы  Специализированные решения класса PM и PPM  Модули в составе учетных систем (ERP)  Системы управления задачами  Системы управления версиями  Системы электронного документооборота  Электронные средства коммуникаций 51 СОСТОЯНИЕ РЫНКА PM PPM  Объем рынка РРМ по состоянию на начало 2018 год на составляет 2.3 миллиарда $ (Gartner)  Устойчивый ежегодный рост на 11%  совокупный среднегодовой темп роста (показатель CAGR) для рынка РМ и PPM на уровне 5.9% на период 2017-2021 годы, к концу указанного периода объем рынка должен составить $ 5,4 млрд. (IDC)  существуют решения для вертикальных рынков (ИТ-индустрия, строительная и финансовая отрасли)  В 2016 году почти 85% мирового рынка РРМ принадлежало десяти компаниям: Microsoft, Oracle, ServiceNow, SAP, Plainview, Workfront, UNIT4, Atlassian, Autodesk, Deltek (a Roper Technologies Company)  доля Microsoft приблизилась к 36% 52 НЕКОТОРЫЕ ПРОЕКТЫ ВНЕДРЕНИЯ ИСУП Вендор Заказчик Отрасль Кол-во пользователей Microsoft United Airlines Arup Авиационные перевозки Проектирование инженерных коммуникаций Энергетика 86000 Стоимость проекта, тыс.$ 37864 12150 1500 8527 6098 Microsoft Oracle Ameren Corporation ServiceNow, Inc. IBM Информационные 377757 технологии 81741 Внедряемый продукт Microsoft Project Server Microsoft Project Online Oracle Primavera P6 Enterprise Project Portfolio Management, Oracle Primavera Risk Analysis, Oracle Primavera Portfolio Management ServiceNow PPM 53 АРХИТЕКТУРА РРМ СИСТЕМ  классические клиент-серверные приложения  нативные облачные решения 54 КЛИЕНТ-СЕРВЕРНЫЕ ПРИЛОЖЕНИЯ Варианты развертывания : • Локальная установка • Развертывание в локальной сети предприятия (on-premises) • Развертывание в облачной инфраструктуре 55 НАТИВНЫЕ ОБЛАЧНЫЕ СИСТЕМЫ  поставляются вендором исключительно по модели «программное обеспечение как услуга» (SaaS)  размещаются в специализированной облачной инфраструктуре  используют новые концепции (архитектура микровервисов, контейнезированные сервисы, концепция распределенного управления и оркестровки) 56 СВОЙСТВА НАТИВНЫХ ОБЛАЧНЫХ СИСТЕМ  Мультитенантностью, т.е. возможностью изолированно обслуживать пользователей из разных организацией (т.е. независимых подписчиков SaaS) посредством одного экземпляра программного обеспечения (одной инсталляции или развертывания). Важно, что подписчики остаются изолированными друг от друга.  Инициализацией, т.е. автоматизированным процессом управления вычислительными ресурсами, конфигурациями и процессами с оптимизацией доступности.  Масштабируемостью, т.е. возможностью системы наращивать (и сокращать) ресурсы для хранения данных, уменьшая расходы для пользователей и сложность для поставщика системы.  Наличием модуля биллинга, позволяющего системе генерировать счета на основе данных об использовании ресурсов и набора предопределенных политик биллинга 57 ОСНОВНЫЕ РАЗЛИЧИЯ НАТИВНЫХ И РАЗМЕЩЕННЫХ В ОБЛАКЕ ПРИЛОЖЕНИЙ Сроки внедрения Обновление ПО Производительность cloud-hosted Сокращение сроков внедрения, т.к. не требуется установка и настройка дополнительного ПО и серверного оборудования Мгновенное обновление для всех пользователей (свойство мультитенантностти) Динамическое масштабирование вычислительных ресурсов в зависимости от нагрузки и числа пользователей cloud-based Длительные сроки внедрения Ручное обновление ПО Возможны проблемы с производительностью при росте нагрузки 58 РЕШЕНИЯ ЛИДЕРОВ РЫНКА. MICROSOFT Microsoft's Project Server Project Online Microsoft Project Professional Microsoft Project Professional for Office 365 Семейство продуктов Microsoft позволяет реализовать любой вариант развертывания PPM-системы: SaaS, on-premises. Microsoft Project Server –это гибкое on-premises решение для управления портфелем проектов и ежедневной работы. Ориентировано на использование членами проектных команд и топ-менеджментом в качестве инструмента для стратегического выравнивания ресурсов и инвестиций, контроля выполнения работ и визуализации состояния компонентов портфеля с использованием дашбордов. Microsoft Project Online – облачный сервис. предоставляющий функционал Project Server on-line. Работает с платформой SharePoint Online и другими облачными сервисами Microsoft (Exchange Online, Lync) Microsoft Project Professional – самый известный в мире продукт для управления проектами. Интегрируется с Project Server. Синхронизируется с Project Online. Microsoft Project Professional for Office 365 – SAAS версия Project Professional. Поставляется по подписке как часть Office 365. 59 РЕШЕНИЯ ЛИДЕРОВ РЫНКА. CLARIZEN Clarizen Clarizen - облачный PPM продукт, отличающийся удобством, и простотой в использовании. Хорошо адаптирован к различным вариантам использования. Хорошо масштабируется по количеству проектов и пользователей. Позволяет создавать проекты «на лету» с задачами и контрольными точками, оперативно формируемыми по запросам бизнеса или члена проектной команды. Последние улучшения расширили возможности по оптимизации портфеля проектов, такие как сценарный анализ (сценарное моделирование) добавлен модуль финансового планирования, расширено ресурсное планирование по временным периодам, появилась возможность интеграции с Microsoft SharePoint и функция автоматической публикации презентаций PowerPoint. 60 РЕШЕНИЯ ЛИДЕРОВ РЫНКА. ORACLE Primavera P6 Enterprise EPPM – облачное решение для управления проектами любого Project Portfolio размера, поддерживает функции приоритезации, планирования, Management (EPPM) выполнения проектов, программ и портфелей. Мобильное приложение Primavera P6 EPPM Team Member — предназначено для ввода и совместного использования информации о статусе выполнения задач проектов с помощью смартфонов и планшетов. Широкий перечень продуктов вендора (в том числе Primavera Risk Analysis, Primavera P6 Analytics, Primavera P6 Progress Reporter и пр. ) могут быть бесшовно интегрированы с EPPM для расширения функциональности. 61 РЕШЕНИЯ ЛИДЕРОВ РЫНКА. PLANVIEW Planview Enterprise Innotas Projectplace Planview предлагает линейку PPM-продуктов, включающую Planview Enterprise, Innotas и Projectplace. Удовлетворяет запросу бизнеса на использование нескольких РРМ продуктов н предприятии, поскольку необходимая комбинация продуктов может удовлетворить потребности предприятия разного масштаба. Planview Enterprise – это решение для корпоративного управления портфелями и ресурсами, может быть развернуто on premises или cloud-hosted, ориентировано на крупные предприятия. Innotas – это облачный IT PPM-продукт, ориентированный на предприятия среднего размера. Projectplace - облачный продукт предназначен, прежде всего для оперативного управления взаимодействием проектных команд. 62 КОММУНИКАЦИЯ И ДОКУМЕНТООБОРОТ В ПРОЕКТАХ Для очень многих пользователей система управления проектами как система сетевого или ресурсного планирования вторична, проект управляется по контрольным точкам, а самый главный момент это коммуникация и документооборот в проекте. Для таких решений Gartner выделил отдельный класс Techniques and Tools for Project Collaboration. Clarizen - универсальная система управления проектами с коммуникационными и портальными средствами топ-класса 63 ТРЕБОВАНИЯ ПО КОЛЛЕКТИВНОЙ РАБОТЕ В Clarizen реализовано:  чат по проекту,  отправка писем с привязкой по задачам,  система автоматического приема писем и их сортировки,  различные уведомления. Процедуры согласований, проверки данных и т.п. можно в Clarizen сделать без программирования. Готовые без настройки дешборы и индикаторы. Совместное редактирование проектов, с возможностью самому менеджеру проекта определить права доступа к его частям. ФУНКЦИИ ISSUE TRACKING СИСТЕМ (СИСТЕМЫ УПРАВЛЕНИЯ ЗАДАЧАМИ)  в реальном времени отслеживать текущее состояние проектов, собирать статистику по проектам;  вести учет ошибок, запросов на изменение, заданий, в соответствии с заданным жизненным циклом;  хранить проектную документацию;  конфигурировать права доступа пользователей, их роли, отправку нотификаций;  интегрироваться с разными third-party продуктами (например, с системами версионного контроля);  доступ к функциям системы программным способом (через соответствующий API); УПРАВЛЕНИЕ СОДЕРЖАНИЕМ ПРОЕКТА ЛЕКЦИЯ 4 ПО ДИСЦИПЛИНЕ «УПРАВЛЕНИЕ ИНФОРМАЦИОННО-ТЕХНОЛОГИЧЕСКИМИ ПРОЕКТАМИ» Доцент кафедры «Бизнес-информатика», к.т.н., доц. Морозова О.А. Москва 2018 ПРОЦЕССЫ УПРАВЛЕНИЯ СОДЕРЖАНИЕМ  Содержание проекта – работа, которую необходимо выполнить для получения нужного продукта  Управление содержанием проекта – процессы, обеспечивающие наличие в проекте всех и только тех видов деятельности, которые необходимы для успешного завершения проекта 2 ПРОЦЕССЫ УПРАВЛЕНИЯ СОДЕРЖАНИЕМ  Инициация – авторизация проекта или его фазы: выделение ресурсов, назначение МП  Планирование содержания – определение документирование содержания  Уточнение содержания – декомпозиция целей и работ проекта  Подтверждение содержания – формальное принятие содержания проекта заинтересованными сторонами  Контроль изменений содержания – контроль и координация вносимых в содержание изменений 3 ПРЕДИНВЕСТИЦИОННАЯ ФАЗА ПРОЕКТА 1.Возникновение и первичное исследование идеи, носящее максимально творческий и неформальный характер. 2. Детальное исследование идеи. Выработка концепции. Постановка задачи. Создание «одностраничного описания проекта» и разработка его расширенной версии (ТЭО или бизнес-кейс проекта).4 3. Экспертиза идеи специалистами. Принятие решения о начале процесса планирования. 4 КРИТЕРИИ ОЦЕНКИ ЗНАЧИМОСТИ ПРОЕКТА  Финансовая ценность.  Стратегическая ценность.  Уровень рисков. Пример шкалы оценки финансовой ценности проекта  Высокая. Ожидаемая окупаемость до 1 года. Ожидаемые доходы от проекта не менее чем в 1.5 раз превышают расходы. Все допущения при проведении этих оценок четко обоснованны.  Выше среднего. Ожидаемая окупаемость проекта от 1 года до 3 лет. Ожидаемые доходы от проекта не менее чем в 1.3 раза превышают расходы. Большинство допущений при проведении этих оценок имеют под собой определенные основания.  Средняя. Проект позволяет улучшить эффективность производства в Компании и потенциально может снизить расходы компании не менее чем на 30%. Проект может иметь информационную ценность или помочь лучше контролировать бизнес.  Низкая. Проект немного снижает расходы компании не менее чем на 10% и дает некоторые улучшения производительности производства. 5 КРИТЕРИИ ОЦЕНКИ ЗНАЧИМОСТИ ПРОЕКТА Пример шкалы оценки стратегической ценности проекта  Высокая. Обеспечивает стратегическое преимущество, дает устойчивое увеличение рынка или позволяет выйти на новый рынок. Решает значительные проблемы, общие для большинства важных клиентов. Повторение конкурентами затруднено или потребует от 1 до 2 лет.  Выше среднего. Создает временные конкурентные преимущества. Выполнение обязательств перед многими важными клиентами. Конкурентное преимущество может быть удержано в течение 1 года.  Средняя. Поддерживается доверие рынка к компании. Повышает мнение клиентов о качестве предоставляемых услуг или способствует выполнению обязательств перед несколькими клиентами. Конкуренты уже имеют или способны повторить новые возможности в пределах года.  Низкая. Стратегическое воздействие отсутствует или незначительно. Влияние на клиентов несущественно. Конкуренты могут легко повторить результаты проекта. 6 КРИТЕРИИ ОЦЕНКИ ЗНАЧИМОСТИ ПРОЕКТА Пример шкалы оценки уровня рисков проекта  Низкий. Цели проекта и требования хорошо поняты и документированы. Масштаб и рамки проекта заданы четко. Ресурсы требуемой квалификации доступны в полном объеме.  Средний. Цели проекта определены более-менее четко. Масштаб и рамки проекта заданы достаточно хорошо. Ресурсы требуемой квалификации доступны в основном.  Выше среднего. Цели проекта недостаточно четки. Понимание масштаба и рамок проекта недостаточно. Ресурсы требуемой квалификации сильно ограничены.  Высокий. Цели проекта нечетки. Масштаб и рамки проекта непонятны. Ресурсы требуемой квалификации практически отсутствуют. Технологии имеют неподтвержденную стабильность. 7 8 ПРОЦЕСС «ИНИЦИАЦИЯ ПРОЕКТА»       Эффективные процессы инициации проекта минимум наполовину определяют его будущую успешность. Состоит из процессов, способствующих формальной авторизации начала нового проекта или фазы проекта. Часто выполняются вне рамок проекта . Уточняются первоначальное описание содержания и ресурсы, которые организация планирует вложить. Назначается менеджер проекта Документируются исходные допущения и ограничения. Составляется Устав проекта и, если он одобряется, проект официально авторизуется. 9 УСТАВ ПРОЕКТА  Устав проекта — документ, выпущенный инициатором или спонсором проекта, который формально узаконивает существование проекта и предоставляет менеджеру проекта полномочия использовать организационные ресурсы в операциях проекта.  В российской практике данный документ чаще называется Концепция проекта.  Разрабатывается на основе анализа потребностей бизнеса. Главная функция документа — подтверждение и согласование единого видения целей, задач и результатов всеми участниками проекта. Концепция определяет что и зачем делается в проекте.  Документ, который используется для принятия решений в ходе всего проекта, а также на фазе приемки — для подтверждения результата. 10 СОДЕРЖАНИЕ УСТАВА ПРОЕКТА Разделы:  Название проекта  Цели проекта  Результаты проекта  Допущения и ограничения  Ключевые участники и заинтересованные стороны  Ресурсы проекта  Сроки  Риски  Критерии приемки  Обоснование полезности проекта 11 ЦЕЛИ ПРОЕКТА 12 ЦЕЛИ ПРОЕКТА Отвечают на вопрос «зачем»?  Описывают бизнес-потребности и задачи, которые решаются в результате исполнения проекта. Проект должен быть закрыт, если признается, что достижение цели невозможно или стало нецелесообразным. Целями проекта могут быть:  Изменения в Компании. (автоматизация бизнес-процессов для повышения эффективности основной производственной деятельности ).  Реализация стратегических планов (завоевание доли растущего рынка за счет вывода на него нового продукта).  Выполнение контрактов (разработка заказного ПО).  Разрешение специфических проблем (доработка программного продукта в целях приведения его в соответствие с изменениями в законодательстве). 13 ЦЕЛИ ИТ-ПРОЕКТА  Владение ИТ не несет ценности – для извлечения выгод необходимо эффективно использовать внедренные технологии.  Реализация бизнес-выгод от внедрения ИТ требует изменений рабочих практик сотрудников и принципов функционирования предприятия.  Ответствнность за реализацию бизнес-выгод возлагаетсяна всех участников проекта.  Целями ИТ-проекта должны быть только бизнес-выгоды, а не любой результат.  Бизнес-цель ИТ-проекта (должна носить тактический или стратегический характер, точно и ясно сформулирована). 14 РЕЗУЛЬТАТЫ ПРОЕКТА  Отвечают на вопрос, что должно быть получено после его завершения. Результаты проекта должны определять:  Какие именно бизнес-выгоды получит заказчик в результате проекта.  Какой продукт или услуга. Что конкретно будет произведено по окончании проекта.  Высокоуровневые требования. Краткое описание и при необходимости ключевые свойства и/или характеристики продукта/услуги.  Результаты проекта должны быть измеримыми (при оценке результатов проекта должна иметься возможность сделать заключение достигнуты оговоренные в концепции результаты или нет). 15 ДОПУЩЕНИЯ И ОГРАНИЧЕНИЯ Допущения связаны с управлением рисками (инфляция е превысит …%, стоимость материалов останется фиксированной, стоимость лицензий на ПО сторонних разработчиков не изменится…). Ограничения сокращают возможности проектной команды в выборе решений. Могут содержать:  Специфические нормативные требования. Например, обязательная сертификация продукта, услуги на соответствие определенным стандартам.  Специфические технические требования. Например, разработка под заданную программноаппаратную платформу.  Специфические требования к защите информации.  В этом разделе также уместно сформулировать те требования к системе, которые могут ожидаться заказчиком по умолчанию, но не включаются в рамки данного проекта. 16 КЛЮЧЕВЫЕ УЧАСТНИКИ И ЗАИНТЕРЕСОВАННЫЕ СТОРОНЫ Ключевые участники:  Спонсор проекта — лицо или группа лиц, предоставляющая финансовые ресурсы для проекта в любом виде.  Заказчик проекта — лицо или организация, которые будут использовать продукт, услугу или результат проекта. Следует учитывать, что заказчик и спонсор проекта не всегда совпадают.  Пользователи результатов проекта.  Куратор проекта — представитель исполнителя, уполномоченный принимать решение о выделении ресурсов и изменениях в проекте.  Руководитель проекта — представитель исполнителя, ответственный за реализацию проекта в срок, в пределах бюджета и с заданным качеством.  Соисполнители проекта. Субподрядчики и поставщики. 17 РЕСУРСЫ ПРОЕКТА  Людские ресурсы и требования к квалификации персонала.  Оборудование, услуги, расходные материалы, лицензии на ПО.  Бюджет проекта. План расходов и, при необходимости, предполагаемых доходов проекта с разбивкой по статьям и фазам/этапам проекта. 18 СРОКИ ПРОЕКТА  Старт  Завершение  Контрольные точки. Контрольная точка — важный момент или событие в расписании проекта, отмечающее достижение заданного результата и/или начало / завершение определенного объема работы. Каждая контрольная точка характеризуется датой и объективными критериями ее достижения (в ИТпроектах может соответствовать выпуску каждой промежуточной версии ПО). 19 КРИТЕРИИ ПРИЕМКИ. ОБОСНОВАНИЕ ПОЛЕЗНОСТИ Критерии приемки должны определять числовые значения характеристик системы, которые должны быть продемонстрированы по результатам приемосдаточных испытаний или опытной эксплуатации и однозначно свидетельствовать о достижении целей проекта Обоснование полезности проекта должен содержать краткое технико-экономическое обоснование проекта:  Для кого предназначены результаты проекта.  Описание текущей ситуации «As Is». Какие у потенциального заказчика существуют проблемы.  Каким образом результаты проекта решают эти проблемы («To Be»).  Насколько значимо для клиента решение данных проблем (оценка экономического эффекта).  Какие преимущества в итоге из этого может извлечь компания-исполнитель проекта. 20 ПЛАНИРОВАНИЕ СОДЕРЖАНИЯ Иерархическая структура работ (ИСР) (Work /Breakdown Structure, WBS) — ориентированная на результат иерархическая декомпозиция работ, выполняемых командой проекта для достижения целей проекта и необходимых результатов Структурируется и определяется все содержание проекта. Каждый следующий уровень иерархии отражает более детальное определение элементов проекта 21 ВИЗУАЛИЗАЦИЯ ИСР 22 ФОРМИРОВАНИЕ ИСР Цель:  повышение точности оценок по стоимости, времени, ресурсам  создание базиса для измерения и контроля хода выполнения проекта  задание четкого распределения ответственности ИСР\ИСП разрабатывается путем сочетания иерархической структуры продукта с процессом его создания: • продукт разбивается на подсистемы и элементы • каждому элементу сопоставляется функциональная задача, в процессе которой он создается • функциональные задачи делятся на пакеты и операции 23 ФОРМИРОВАНИЕ ИСР ИТ-ПРОЕКТА Пример - декомпозиция работ ИТ-проекта по ГОСТ 19.102-77 (каскадный подход) :  Техническое задание  Эскизный проект  Технический проект  Рабочий проект  Внедрение Декомпозиция при коммерческой разработке ПО (инкрементальный подход). На верхнем уровне декомпозиции проекта должны находиться продукты проекта, а на следующем уровне — компоненты, из которых эти продукты состоят. Компоненты далее могут быть декомпозированы на функции, которые они должны реализовывать. Выделение компонентов, составляющих программный продукт, это элемент высокоуровневого проектирования, которое мы должны выполнить на фазе планирования проекта, не дожидаясь проработки всех функциональных требований к разрабатываемому ПО. Компонентами могут быть как прикладные подсистемы, так и инфраструктурные (подсистема логирования, безопасности). 24 ДЕКОМПОЗИЦИЯ ОКАНЧИВАЕТСЯ когда:  становится возможной реалистическая оценка сроков, стоимости , рисков  элемент не может быть разбит дальше логически  элемент может быть выполнен относительно быстро Каждому элементу ИСП присваивается уникальный код, который заносится в справочник ИСП. Работы, не включенные в ИСП, не являются работами проекта! 25 СЛОВАРЬ ИСР № Этап Состав работ Трудоемкость (чел/ Результат час) 1 Установка системы ЗАКАЗЧИК предоставляет ИСПОЛНИТЕЛЮ удаленное рабочее место с доступом к серверу базы данных и обеспечивает консультации администратора СУБД Oracle. 2 Система развернута на площадке ЗАКАЗЧИКА ЗАКАЗЧИК назначает ответственного за эксплуатацию Системы в Группе (далее - Администратор Системы). ИСПОЛНИТЕЛЬ совместно с ЗАКАЗЧИКОМ производит установку Системы на сервере ЗАКАЗЧИКА. 26 ПОДТВЕРЖДЕНИЕ СОДЕРЖАНИЯ Официальное принятие участниками результатов работ по проекту I. Должна быть установлена персональная ответственность за все части проекта (подпроекты и пакеты работ). II. для каждого пакета работ должен быть четко определен результат на выходе. III. Работы и оценки проекта должны быть согласованы с ключевыми участниками команды, руководством компании-исполнителя и, при необходимости, с заказчиком. Члены команды принимают на себя обязательства по реализации проекта, а руководство принимает на себя обязательства по обеспечению проекта необходимыми ресурсами. ИСР - основной инструмент в механизме управления проектом, с помощью которого измеряется степень достижения результатов проекта. 27 КОНТРОЛЬ ИЗМЕНЕНИЙ СОДЕРЖАНИЯ Основные вопросы  как будет отслеживаться содержание проекта – оформление работ, планов и бюджетов по задачам; мониторинг результатов работ МП совместно с функциональными лидерами; мониторинг отклонений от планов и бюджетов МП совместно с функциональными лидерами;  как будут инициироваться и кем будут утверждаться изменения содержания проекта  порядок документирования изменения содержания 28 УПРАВЛЕНИЕ СОДЕРЖАНИЕМ Регламент управления содержанием:  Определить источники запросов на изменение  Установить порядок анализа, оценки и утверждения/отклонения изменения содержания  Определить порядок документирования изменений содержания  Определить порядок информирования об изменении содержания 29 АНАЛИЗ ЗАПРОСА НА ИЗМЕНЕНИЕ  выявить объекты изменений: требования, архитектура, структуры данных, исходные коды, сценарии тестирования, пользовательская документация, проч.  спроектировать и детально описать изменения во всех выявленных объектах.  оценить затраты на внесение изменений, тестирование изменений и регрессионное тестирование продукта и их влияние на сроки проекта  Управление содержанием потребует затрат рабочего времени разных специалистов: аналитиков, проектировщиков, разработчиков, тестировщиков, менеджера проекта. Работа должна обязательно быть учтена в плане 30 ПРИЧИНЫ ИЗМЕНЕНИЯ СОДЕРЖАНИЯ ПРОЕКТА  Требования заинтересованных сторон  Рекомендации членов проектной команды  Ошибки на этапе планирования и исполнения  Результат реагирования на непредвиденные обстоятельства  Результат внесения изменений членами проектной команды по пожеланиям заинтересованных сторон (без согласования) 31 ПРОЦЕСС УПРАВЛЕНИЯ ИЗМЕНЕНИЯМИ  Процесс управления изменениями требований – выполняется при поступлении заявки на изменение.  Процесс обработки заявок на изменения должен быть согласован с Заказчиком.  Заявки на изменения влияют на стоимость необходимо достичь согласия об оплате.  Полезно – предусмотреть резерв для реализации заявок на изменение (с согласия Заказчика). % от общей трудоемкости по проекту. 32 ПРОЦЕСС УПРАВЛЕНИЯ ИЗМЕНЕНИЯМИ Этапы процесса: 1. Регистрация заявок на изменение (номер, содержание, категория изменения, даты, автор) 2. Анализ влияния изменений на продукт (определение изменяемых продуктов, объема изменений, пересмотр плана управления рисками) 3. Оценка трудозатрат на выполнение заявки 4. Оценка изменения графика работ 5. Анализ влияния на накопленную стоимость 6. Обсуждение влияния с вышестоящим руководством, если превышены пороговые значения 7. Получение подтверждения изменения от заказчика (для существенных изменений, незначительные изменения реализуют за счет резерва) 8. Внесение изменения. Используются трекинговые системы. Изменение состояния заявки (создана, принята, одобрена, в разработке, реализована и т.п.) Отслеживание фактического исполнения заявки на изменение выполняется в процессе управления конфигурацией. Важно – учесть совокупное влияние изменений на проект. 33 УПРАВЛЕНИЕ СРОКАМИ ПРОЕКТА ЛЕКЦИЯ 5 ПО ДИСЦИПЛИНЕ «УПРАВЛЕНИЕ ИНФОРМАЦИОННОТЕХНОЛОГИЧЕСКИМИ ПРОЕКТАМИ» Доцент кафедры «Бизнес-информатика», к.т.н., доц. Морозова О.А. Москва 2018 УПРАВЛЕНИЕ СРОКАМИ ПРОЕКТА  Процессы, обеспечивающие своевременное завершением проекта  Включает в себя процессы планирования сроков  Результатом планирования сроков является расписание, то есть календарно-сетевой график проекта 2 ОСНОВНЫЕ ПРОЦЕССЫ  определение состава работ – идентификация и документальное оформление отдельных работ,  определение последовательности работ – определение и документирование зависимостей между работами  оценка продолжительности работ – носит итерационный характер, точность увеличивается по мере выполнения проекта.  разработка расписания – определение даты начала и даты конца каждой работы – основной процесс управления временем!  управление расписанием Выполняются одновременно 3 ОПРЕДЕЛЕНИЕ СОСТАВА РАБОТ Входы Методы Выходы Внешние факторы Декомпозиция Список операций Активы организационного процесса Шаблоны Параметры операций Планирование методом набегающей волны Список контрольных событий Базовый план по содержанию Экспертная оценка 4 ОПРЕДЕЛЕНИЕ СОСТАВА РАБОТ Пакеты работ Работы 5 События, контрольные точки ОПРЕДЕЛЕНИЕ ПОСЛЕДОВАТЕЛЬНОСТИ РАБОТ Вход Методы Выход Список операций Метод диаграммы предшествования Сетевые диаграммы расписания проекта Определение видов зависимостей Обновления документации проекта Параметры операций Список контрольных событий Описание содержания проекта Активы организационного процесса Применение опережений и задержек Шаблоны сетевых диаграмм расписаний Корректно определенная последовательность работ – основа реалистичного и выполнимого расписания проекта 6 ДИАГРАММЫ ПРЕДШЕСТВОВАНИЯ (СЕТЕВОЙ ГРАФИК)  Сетевой график отражает операции проекта, которые необходимо выполнить, логическую последовательность и взаимозависимость этих операций и время начала и окончания самой продолжительной цепочки операций - критический путь.  Сетевой график раскрывает внутренние связи проекта и служит основой для календарного планирования работ.  Сетевой график дает возможность оценить периоды времени, в течение которых выполнение операций может начинаться и заканчиваться, а также время допустимой задержки их выполнения.  Сетевой график - графическое изображение сетевой модели. 7 ТИПЫ ДИАГРАММ ПРЕДШЕСТВОВАНИЯ  обозначением РАБОТ в узлах (блоках) графика ;  Стрелочные диаграммы (подход с обозначением РАБОТ на стрелках графика). Старый метод, сейчас практически не используется. 8 ПРАВИЛА СОСТАВЛЕНИЯ СЕТЕВОГО ГРАФИКА  Сетевой график разворачивается слева направо.  Ни одна операция не может быть начата, пока все предшествующие связанные с ней операции не будут выполнены.  Стрелки в сетевом графике отображают отношения предшествования и следования.  Каждая операция должна иметь свой собственный номер. Номер последующей операции должен быть больше номера любой предшествующей операции.  Образование петель недопустимо .  Условные переходы от одной операции к другой не допускаются.  Должен быть определен общий узел начала всего комплекса работ. Точно так же один узел должен быть использован для четкого обозначения окончания проекта. 9 ТИПЫ СВЯЗЕЙ МЕЖДУ РАБОТАМИ Отражают в сетевой модели проекта. Связь устанавливается между двумя работами ( работой-предшественником и работой-последователем.)  Финиш-старт (Начало после окончания )FS. Последователь не может начаться раньше предшественника. Используется чаще всего.  Старт-старт (Начало после начала ) SS. Последователь не может начаться раньше начала предшественника.  Финиш-финиш (Окончание после окончания) FF . Последователь не может завершиться ранее завершения предшественника.  Старт-финиш (Окончание после начала) SF. Последователь не может завершиться до начала предшественника. Используется редко. Между задачами могут вводиться задержки (лаги) и опережения. 10 ЗАВИСИМОСТИ МЕЖДУ РАБОТАМИ  Зависимости – отношения между операциями  Виды зависимостей:  Обязательная (Жесткая ) зависимость — последовательность операций не может изменяться (в силу технологии или природы работ).  Дискреционная (Нежесткая) зависимость — последовательность операций определяется командой проекта и может изменяться. Опираются на проектный опыт и лучшие практики. При оптимизации расписания можно менять или удалять зависимости.  Внешняя зависимость — последовательность операций определяется внешними по отношению к проекту воздействиями (например, могут быть 11 связаны задачи двух разных проектов в одной программе проектов). ОЦЕНКА ПРОДОЛЖИТЕЛЬНОСТИ РАБОТ Вход Методы Выход Список операций Параметры операций Требования к ресурсам Календари ресурсов Описание содержания проекта Факторы внешней среды предприятия Активы организационного процесса Экспертная оценка Оценки длительности операций Оценка по аналогам Параметрическая оценка Обновления документации проекта Оценка по трем точкам Анализ резервов 12 ОЦЕНКА ПРОДОЛЖИТЕЛЬНОСТИ РАБОТ Процесс оценки длительности плановых операций использует информацию о содержании работ, типах требуемых ресурсов, количестве ресурсов, календарях работы ресурсов с указанием времени их доступности. Методы оценки длительности операций:  экспертная оценка — метод Delphi, использование внешних и внутренних экспертов, баз данных;  по аналогам — по аналогии с предыдущими проектами (оценка сверху-вниз). Наименее затратная оценка, наименее точная;  параметрическая — количественная оценка, по объемам работ и производительности;  оценка по трем точкам — получение трех оценок — оптимистичная (О), наиболее вероятная (М), пессимистическая (Р): Оценка PERT = (Р + 4М + О) / 6.  анализ резервов – резервное время (буферы, резервы на непредвиденные обстоятельства) время, добавляемое к операции для учета рисков. 13 РАЗРАБОТКА РАСПИСАНИЯ Вход Методы Выход •Список операций •Параметры операций •Сетевые диаграммы расписания проекта •Требования к ресурсам •Календари ресурсов •Оценки длительности операций •Описание содержания проекта •Факторы внешней среды предприятия •Активы организационного процесса •Анализ сети расписания •Метод критического пути •Метод критической цепи •Выравнивание ресурсов •Анализ возможных сценариев •Применение опережений и задержек •Сокращение расписания •Инструмент календарного планирования Расписание проекта Данные для модели расписания Базовый план по расписанию Обновления документации проекта 14 МЕТОДЫ РАЗРАБОТКИ РАСПИСАНИЯ  Анализ сети расписания  Метод критического пути  Метод критической цепи  Выравнивание ресурсов  Анализ сценариев «что-если»  Применение опережений и задержек  Сокращение расписания  Инструмент составления расписания 15 АНАЛИЗ СЕТИ РАСПИСАНИЯ  Цель – получить расписание проекта.  Включает в себя:  Определение дат раннего и позднего старта и финиша всех операций проекта.  Используется метод критического пути, критической сети, выравнивание ресурсов, анализ сценариев.  Ограничения на ресурсы не учитываются (полученные даты являются теоретическими) 16 МЕТОД КРИТИЧЕСКОГО ПУТИ (CPM)  Critical path method (CPM) – метод анализа сети расписания. Определяет величину резерва или гибкость расписания для каждого пути в сети на основе анализа ранних и поздних дат старта и финиша операций. Применяется к сетям с последовательными операциями. Предназначен для определения расписания без учета ограничений на ресурсы.  Критический путь — максимальный по продолжительности полный путь в сети (в сетевой модели) называется критическим;  Работы, лежащие на этом пути, называются критическими работами.  Длительность критического пути определяет наименьшую общую продолжительность работ по проекту в целом. Как правило, критические работы составляют небольшую часть всех работ сети, но именно они определяют продолжительность выполнения комплекса в целом.  Длительность выполнения всего проекта в целом может быть сокращена за счет сокращения длительности задач, лежащих на критическом пути. Задержка выполнения задач критического пути повлечет увеличение длительности проекта. 17 МЕТОД КРИТИЧЕСКОГО ПУТИ (CPM) Входные данные для расчета расписания :  перечень задач;  зависимости между задачами;  оценки продолжительности каждой задачи;  календарь рабочего времени проекта ограничения на сроки начала и окончания отдельных работ или этапов;  календарная дата начала проекта. 18 19  Расчет расписания вперед (прямой проход)— вычисление ранних сроков начала и завершения невыполненных частей всех операций.  Расчет расписания начинается с работ, не имеющих предшественников. Эти работы начинаются в первый рабочий период.  Расчет расписания вперед определяет ранние даты работ (Early start, early finish). Ранние даты — наиболее раннее возможное время старта и финиша работ при условии, что предыдущие работы завершены.  Ранний старт (в методе критического пути) — самый ранний из возможных моментов времени, в который могут начаться плановые операции проекта.  Ранний финиш — самый ранний из возможных моментов времени, в который могут завершиться плановые операции проекта.  Ранний старт и ранний финиш вычисляются на основании логики сети расписания, отчетной даты и любых ограничений на расписание и могут меняться по ходу исполнения проекта и внесения изменений в план управления проектом.  Ранний Старт + Длительность – 1 = Ранний Финиш. 20  Расчет расписания назад (обратный проход) — определение позднего финиша и позднего старта незавершенных частей всех плановых операций.  Определяется в результате расчета проекта от даты завершения проекта к началу на основании логики сети расписания. Дата завершения определяется в результате расчета расписания вперед или задается заказчиком или спонсором проекта.  Поздний старт — самый поздний момент времени, в который может быть начата плановая операция, определяемый на основании логики сети расписания, даты завершения проекта и любых ограничений в отношении плановых операций без нарушения ограничений на график или отсрочки даты завершения проекта.  Поздний финиш — самый поздний момент времени, в который может быть завершена плановая операция. Поздний старт и поздний финиш определяются с помощью Обратного прохода в сети расписания проекта. Поздний Финиш – Длительность + 1 = Поздний Старт. 21 Общий резерв — это время, на которое может быть задержана работа относительно раннего старта без задержки проекта . Общий резерв= ПФ Текущей – РФ Текущей Работы, имеющие нулевой резерв — критические. Длительность критического пути проекта – сумма длительности всех операций с нулевым временным резервом. Свободный резерв — время, на которое работа может быть задержана без задержки раннего старта ее последующих работ. Свободный Резерв = РС Последующий – РФ Текущей – 1. С учетом задержки по зависимости: Свободный Резерв = РС Последующий – РФ Текущей – LAG – 1. 22 МЕТОД КРИТИЧЕСКОГО ПУТИ  Совпадает ли полученная конечная дата с ожидаемой? Приемлемо ли это с точки зрения целей проекта?  Какие работы являются критическими? Совпадают ли они с теми, которые предполагались предварительно членами команды?  Какие из некритических работ имеют наименьший общий резерв? Какова вероятность или риск того, что эти работы станут критическими и будут задерживать дату завершения?  Какие работы имеют достаточный полный резерв? Существует ли возможность перераспределения их ресурсов на критические работы?  Какие календарные даты могут быть зафиксированы в графике проекта и действительно ли они соответствуют реальным намерениям руководства 23 и плану по вехам? КАЛЕНДАРИ И ОГРАНИЧЕНИЯ Календари назначаются на работы и ресурсы для определения, когда может быть запланировано выполнение работы и/или использование ресурса:  определяет, какие дни недели являются рабочими;  определяет количество рабочих часов в день;  нерабочее время:  используется для праздников, отпусков, перерывов на обед, частичной занятости.  Ограничения задач — это навязанные даты, использующиеся для отражения требований, которые невозможно формализовать сетевой логикой или календарями. 24 ТИПЫ ОГРАНИЧЕНИЙ  навязанная дата финиша. При этом расписание будет рассчитано так, что все работы проекта будут закончены к этой дате;  ограничения на дату старта;  ограничения на дату финиша;  ограничения на резерв. 25 Ограничения на дату старта определяют, когда работа должна начаться. Типы ограничений на старт:  старт не позже, чем (Start No Later Than):  принуждает работу начаться не позже, чем дата ограничения;  смещает поздний старт к дате ограничения;  влияет на поздние даты предшествующих работ;  старт не раньше, чем (Start No Earlier Than):  принуждает работу начаться не раньше, чем дата ограничения;  смещает ранний старт к дате ограничения;  влияет на ранние даты последующих работ;  старт на дату (Must Start On):  принуждает работу начаться в дату ограничения;  смещает и ранние, и поздние даты старта. 26 Ограничения на дату финиша определяют, когда работа должна быть закончена. Типы ограничений на финиш: финиш не позже, чем (Finish No Later Than): •принуждает работу закончиться не позже, чем дата ограничения; •смещает поздний финиш к дате ограничения; •влияет на поздние даты предшествующих работ; финиш не раньше, чем (Finish No Earlier Than): •принуждает работу закончиться не раньше, чем дата ограничения; •смещает ранний финиш к дате ограничения; •влияет на ранние даты последующих работ; финиш на дату (Must Finish On): •принуждает работу закончиться на дату ограничения; •смещает и ранние, и поздние даты финиша. 27 ВЫЧИСЛЕНИЕ ОЖИДАЕМОГО ЗНАЧЕНИЯ МЕТОДОМ PERT  PERT (Program Evaluation and Review Technique) – разработан в ВМФ США в 1950-х г.г. В ходе работы над программой крылатых ракет. Цель эффективное управление проектом, прогноз расписания с высокой степенью достоверности.  Похож на метод CPM. Отличие CPM использует наиболее вероятные длительности операций, PERT – взвешенное среднее (ожидаемое значение, оценка по трем точкам.)  Если рассчитать стандартное отклонение для каждой операции можно оценить уровень достоверной вероятности (на основании распределения Гаусса).  Работа закончится в указанный срок ± 3σ с вероятностью 99.7%  Работа закончится в указанный срок ± 2σ с вероятностью 95.4%  Работа закончится в указанный срок ± σ с вероятностью 36.3%  Чем выше риск, тем больше σ.  Для оценки длительности всего проекта используется сумма квадратов отклонений по задачам критического пути.  Можно использовать не для всех операций проекта, а для части наиболее рискованных операций 28 УПРАВЛЕНИЕ НЕОПРЕДЕЛЕННОСТЬЮ В МЕТОДЕ КРИТИЧЕСКОГО ПУТИ  Работа стремится занять все время, отпущенное на нее (Закон Паркинсона).  Если какая-нибудь неприятность может произойти, - она случается (Закон Мерфи).  Способ минимизировать риски (минимизировать влияние закона Мерфи) - включение в оценку сроков задачи рисков и неопределенностей (добавляют резервное время для каждой задачи).  Планируются даты начала и окончания задач (исполнители стремятся начать и закончить работу в строк). Досрочное завершение работы не приводит к уменьшению времени всего проекта, зависимые задачи не могут начаться раньше) 29 ОЦЕНКА ПРОДОЛЖИТЕЛЬНОСТИ РАБОТ Почти каждая задачи содержит дополнительный запас прочности, превышающий действительно ожидаемое время завершения данной работы. 30 СИНДРОМ СТУДЕНТА 31 Запаздывание задачи почти всегда приводит к задержке зависимых задач, т.к. на этапе планирования все риски были заложены в самих задачах В случае сдвига по времени - применение корректирующих действий (урезания объема работ проекта или выделения дополнительных ресурсов). 32 МЕТОД КРИТИЧЕСКОЙ ЦЕПИ  Метод «критической цепи» для управления проектами (CCPM - Critical Chain Project Management), основан на теории ограничений Голдратта (TOC – Theory of constraints). Предложен в 1997 г.  Метод критической цепи – метод анализа сети расписания, который модифицирует расписание проекта с учетом ограничений по ресурсам  Критическая цепь – это последовательность задач, от длительности которых зависит общая длительность всего проекта. 33 ПРЕИМУЩЕСТВА МКЦ Устраняет влияния закона Паркинсона. Позволяет: 1. 2.  Создавать календарный план, используя достаточно плотные оценки длительности задач.  Избавиться от жестких дат окончания задачи (но не проекта). Досрочное завершение задач используется для достижения успеха всего проекта (переключение ресурсов на задачи критической цепи). 34 МКЦ: ОПРЕДЕЛЕНИЕ КРИТИЧЕСКОГО ПУТИ 35 БУФЕР ПРОЕКТА  Срок выполнения заданий оцениваем исходя из 50%-ой вероятности выполнения этапа, а весь запас времени на непредвиденные обстоятельства переносится в конец проекта. 36 БУФЕР ПРОЕКТА 37 БУФЕР НА СЛИЯНИЕ ПУТЕЙ 38 ЭТАПЫ СОЗДАНИЯ ГРАФИКА ПРОЕКТА МЕТОДОМ КРИТИЧЕСКОЙ ЦЕПИ 1. Найдите критическую цепь. Постройте логическую последовательность операций со связями типа «поздний финиш». Используйте среднюю длительность операций (вероятность 50/50) и укажите исходные данные о необходимых ресурсах.  Проведите выравнивание ресурсов. Определите, какой конфликт ресурсов нужно разрешить в первую очередь.. Если у вас несколько равноценных конфликтов, беритесь за первый с конца расписания.  Устраните конфликт ресурсов, запланировав выполнение некоторых операций на более ранний срок. (не задумывайтесь о появлении новых конфликтов; вы снимете их позже.) Конфликт необходимо разрешать последовательно по каждому ресурсу. Устраняя текущий конфликт, не допускайте повторного возникновения конфликтов, которые вы уже разрешили ранее. Повторяйте процедуру, пока не закроете все выявленные проблемы с ресурсами. 39  Найдите критическую цепь — самую длинную последовательность зависимых событий.  ЭТАПЫ СОЗДАНИЯ ГРАФИКА ПРОЕКТА МЕТОДОМ КРИТИЧЕСКОЙ ЦЕПИ 2. Найдите способ снизить влияние критической цепи.  Меняя последовательность выполнения работ, попытайтесь сократить общую длительность.  Добавьте проектный буфер в конец критической цепи. 3. Подчините все операции, цепочки и ресурсы нуждам критической цепи. 3.1. Используйте механизм защиты критической цепи: добавьте буферы ко всем цепочкам работ, которые сливаются с критической цепью (буферы на слияние путей). 3.2. Снимите все конфликты ресурсов, появившиеся после добавления буферов, путем перепланирования операций на более ранние сроки. 3.3. Соответственно сдвиньте на более ранние сроки операции, предшествующие тем, которые вы только что перепланировали. 4. Сократите общую длительность проекта, используя дополнительные ресурсы на определенных участках, чтобы снять конфликты. Возврат к п.1. 40 ОСОБЕННОСТИ МКЦ 1) критическая цепь определяется как самая длинная цепочка операций проекта с учетом ограничений как по ресурсам, так и по логике последовательности операций; 2) конфликты по ресурсам не рассматриваются до момента определения критической цепи; 3) в плане используются среднеоценочные характеристики операций (имеющие вероятность 50/50), а запас на компенсацию влияния общих причин вариабельности сосредоточен в конце цепочек работ; 4) выполнение цепочек работ, вливающихся в критическую цепь, координируется с помощью специальных буферов на слияние путей (при одновременном продолжении работ по снятию конфликта ресурсов); 5) уделяется внимание обеспечению ресурсами, особенно по операциям критической цепи 6) в качестве средств оценки и контроля за реализацией проекта используются проектный буфер и буфера на слияние путей. 41 42 АНАЛИЗ СЦЕНАРИЕВ «ЧТО-ЕСЛИ»  Используются различные наборы допущений  Оценка осуществимости расписания проекта в заданных условиях  Методы имитационного моделирования (Монте-Карло) – дает вероятность возможных дат завершения проекта 43 СОКРАЩЕНИЕ РАСПИСАНИЯ 44 ИНСТРУМЕНТЫ СОСТАВЛЕНИЯ РАСПИСАНИЯ  ПО для управления проектами 45 ВЫХОДЫ ПРОЦЕССА РАЗРАБОТКИ РАСПИСАНИЯ  Расписание проекта – определяет даты старта и финиша каждой операции. Может быть предварительным (будет уточняться) до тех пор, пока не произойдет назначение ресурсов.  Базовое расписание – утвержденное расписание проекта (одобряется заинтересованными лицами и функциональными руководителями). Ход проекта отслеживается относительно базового расписания.  Данные расписания – задокументированные данные (контрольные события, операции проекта, параметры операций, ограничения расписания и пр.)  Обновленная документация проекта – обновление требований к ресурсам, календарей, реестра рисков и др. 46 КОНТРОЛЬ РАСПИСАНИЯ Вход Методы Выход План управления проектом •Анализ эффективности исполнения •Анализ отклонений •Программное обеспечение для управления проектами •Выравнивание ресурсов •Анализ возможных сценариев •Применение опережений и задержек •Сокращение расписания •Инструмент календарного планирования Измерения эффективности работ Расписание проекта Данные об исполнении работ Активы организационного процесса Обновления активов организационного процесса Запросы на изменения Обновления плана управления проектом Обновления 47 документации проекта КОНТРОЛЬ РАСПИСАНИЯ Основные действия процесса:  определение текущего статуса расписания проекта;  воздействие на факторы, которые могут привести к изменениям в расписании;  выявление фактов изменения расписания проекта;  управление изменениями при их возникновении. 48 ОТСЛЕЖИВАНИЕ СТАТУСА РАБОТ НА КРИТИЧЕСКОЙ ЦЕПИ  Используются данные о расходовании ресурсов буферов 49 УПРАВЛЕНИЕ ПРОЕКТАМИ УПРАВЛЕНИЕ СТОИМОСТЬЮ ПРОЕКТА ЛЕКЦИЯ 6ПО ДИСЦИПЛИНЕ «УПРАВЛЕНИЕ ИНФОРМАЦИОННО-ТЕХНОЛОГИЧЕСКИМИ ПРОЕКТАМИ» Доцент кафедры «Бизнес-информатика», к.т.н., доц. Морозова О.А. Москва 2018 УПРАВЛЕНИЕ СТОИМОСТЬЮ ПРОЕКТА  Процессы, выполняемые в ходе планирования, разработки бюджета и контролирования затрат, и обеспечивающие завершение проекта в рамках утвержденного бюджета ПЛАН УПРАВЛЕНИЯ СТОИМОСТЬЮ План управления стоимостью входит в план УП В план может входить (по PMBoK):  Уровень точности (сотни, тысячи и др.)  Единицы измерения (для оценки ресурсов, часы, дни, фиксированные суммы)  Контрольные пороги (допустимые отклонения от базового плана, пороги)  Правила измерения исполнения (порядок анализа освоенного объема, формулы расчета показателей)  Форматы отчетности (виды финансовых отчетов и их периодичность)  Описание процессов (процессы оценки стоимости, определения бюджета и контроля стоимости) ПРОЦЕССЫ УПРАВЛЕНИЯ СТОИМОСТЬЮ  планирование ресурсов – какие ресурсы и в каком количестве необходимы для выполнения работ проекта  оценка стоимости – определяется стоимость задействованных ресурсов  бюджетирование – определение стоимости каждой отдельной работы  контроль стоимости – управление изменениями бюджета проекта ПРОЦЕСС ПЛАНИРОВАНИЯ РЕСУРСОВ Вход •ИСП\ИСР •Цели и результаты проекта •Историческая информация •Описание доступных ресурсов •Организационная политика •Оценка продолжительност и работ Методы •Экспертная оценка Выход Потребности в ресурсах •Определение альтернатив •ИСУП Оценка ресурсов производится для самого нижнего уровня ИСП/ИСР, а затем суммируется по уровням ВИДЫ РЕСУРСОВ Ресурсы проекта – то, что необходимо для выполнения операций проекта.  Ресурсы могут быть:  возобновляемыми – люди, материалы и механизмы, которые после выполнения операции могут быть использованы вновь,  не возобновляемыми (расходуемыми) – материалы и оборудование, которые на операциях расходуются. Для удобства возобновляемые ресурсы называют просто ресурсами, а расходуемые – материалами. ПРОЦЕСС ОЦЕНКИ СТОИМОСТИ  Оценка стоимости заключается в определении приблизительной стоимости ресурсов проекта для компании. Вход Методы Выходы •Базовый план по содержанию •Расписание проекта •План управления персоналом •Реестр рисков •Факторы внешней среды предприятия •Экспертная оценка •Оценка по аналогам •Параметрическая оценка •Оценка снизу — вверх •Оценка по трем точкам •Анализ резервов •Стоимость качества •ПО для управления проектами •Анализ предложений исполнителей Оценка стоимости операции Вспомогательные данные для оценки стоимости операции Обновления документации проекта МЕТОДЫ ОЦЕНКИ СТОИМОСТИ  По аналогам - при оценке стоимости текущего проекта в качестве основы принимается фактическая стоимость предыдущих схожих проектов. (самый дешевый и наименее точный метод).  Оценка «снизу вверх». Оценка стоимости отдельных пакетов работ или отдельных плановых операций с максимальной степенью детализации. Стоимость операций суммируется или «переходит» на более высокие уровни. Обычно чем меньше трудоемкость операций, тем выше точность стоимостной оценки плановых операций.  Параметрическая оценка —для стоимостной оценки ресурсов плановой операции используется статистическая зависимость (количество строк в коде, количество часов рабочего времени).  Анализ предложений поствщиков Команда проекта проводит дополнительную стоимостную оценку и определяет стоимость отдельных результатов. Необходимо использовать данные нескольких поставщиков  Анализ резервов. Резерв на непредвиденные обстоятельства — это оценка стоимости, используемая по усмотрению менеджера проекта в случае возникновения ожидаемых, но не определенных событий (проблема завышенной стоимости).  Стоимость качества — это изменение стоимости работ в зависимости от необходимости достижения определенного качества и затраты проверки качества. ОЦЕНКА СТОИМОСТИ СТОИМОСТНАЯ ОЦЕНКА ПРОЕКТА ПО ЭТАПАМ ЖЦ Оценка для заключения контракта Оценка для утверждения бюджетов и получения фондов ПРОЦЕСС БЮДЖЕТИРОВАНИЯ Вход Методы Выход Оценка стоимости операции Суммирование стоимости Базовый план по стоимости Вспомогательные данные для оценки стоимости операции Анализ резервов Экспертная оценка Требования к финансированию проекта Базовый план по содержанию Историческая информация Обновления документации проекта Расписание проекта Согласование объемов финансирования Календари ресурсов Контракты МЕТОДЫ ПРОЦЕССА ОПРЕДЕЛЕНИЯ БЮДЖЕТА  Суммирование стоимости – суммирование оценок стоимости на уровне пакетов работ, суммирование стоимости пакетов для получения стоимости проекта  Анализ резервов – планирование резервов на непредвиденные расходы в части содержания и стоимости проекта. Резервы не включают в базовый план по стоимости, но включают в бюджет проекта. Резервы не учитывают при расчете методом освоенного объема  Историческая информация – для определения общей стоимости проекта можно использовать оценку по аналогам или параметрическую оценку (если подробная информация о проекте недоступна или проект находится в начальной стадии)  Согласование объемов финансирования – согласование объемов фактически выделяемых средств. Иногда требует адаптации расписания для более плавного расходования средств. БЮДЖЕТИРОВАНИЕ Индивидуальные формы бюджета для компаний (статьи затрат)  затраты на фонд оплаты труда;  затраты на оборудование;  затраты на услуги подрядчиков;  затраты на непредвиденные расходы;  затраты на командировки;  затраты на налогообложение; МП - контролирует финансовые потоки проекта (сроки оплаты работ подрядчикам и поставщикам, получение средств от спонсора или заказчика, подает заявки на выделение средств на затраты проекта , отчитываться по затратам). РАЗРАБОТКА БЮДЖЕТА ПРОЕКТА БАЗОВЫЙ ПЛАН ПО СТОИМОСТИ Распределенный по времени бюджет, используемый для мониторинга и контроля исполнения стоимости проекта. Разрабатывается путем суммирования оценок стоимости расходов по периодам времени Распределенный во времени суммарный исходящий денежный поток проекта. ПРОЦЕСС КОНТРОЛЯ СТОИМОСТИ  Процессы мониторинга и управления. Включает:  мониторинг стоимости для выявления расхождений с базовым стоимостным планом  внесение изменений в базовый стоимостной план  информирование участников проекта об изменениях  действия, направленные на соблюдение бюджета проекта КОНТРОЛЬ СТОИМОСТИ Вход Методы Выход План управления проектом Метод освоенного объема Измерение эффективности работ Требования к финансированию проекта Прогнозирование Прогнозы по бюджету расходов Данные об исполнении работ Показатель эффективности выполнения TCPI Анализ эффективности выполнения проекта Анализ отклонений ПО для управления проектами Оценка по завершению Обновление плана управления проектом Обновления документации проекта МЕТОД ОСВОЕННОГО ОБЪЕМА  Метод освоенного объема - интегрированный анализ исполнения календарного плана проекта и бюджета по стоимостным оценкам, наиболее распространенный метод измерения исполнения проекта.  Представляет сведения об исполнении расходов и расписания. Измерение расходов и расписания проекта производится в денежных единицах (расчет нарастающим итогом). МОДЕЛЬ ОСВОЕННОГО ОБЪЕМА ИСПОЛЬЗУЕТСЯ ДЛЯ:  Мониторинга хода выполнения проекта  Оценки степени отставания\опережения плана  Прогнозирования:  Когда будет законен проект\программа.  Потребуется ли дополнительное финансирование (если потребуется, то когда).  Сколько еще средств потребуется вложить в проект для его успешного завершения. ПОКАЗАТЕЛИ ОСВОЕННОГО ОБЪЕМА  Показатели, измеряемые на проекте  Расчетные показатели:  Абсолютные  Относительные  Прогностические МЕТОД ОСВОЕННОГО ОБЪЕМА Показатели, измеряемые на проекте:  Плановая стоимость— PV (Planned Value)  Фактическая стоимость выполненных работ — AC (Actual Cost)  Плановая стоимость выполненных работ или освоенный объем — EV (Earned Value). EV=PV*%выполнения МЕТОД ОСВОЕННОГО ОБЪЕМА  Плановая стоимость (плановый объем) — PV (Planned Value), BCWS. Утвержденный бюджет, выделенный на плановую операцию. Плановая стоимость запланированных работ. Рассчитывается на основании базового плана по стоимости и базового расписания, где каждая операция имеет свои сроки и оценку стоимости. Расчет нарастающим итогом. PV = Vплан * C план  Фактическая стоимость выполненных работ — AC (Actual Cost), ACWP. Фактическая стоимость действительно завершенных работ. Расчет нарастающим итогом AC = Vфакт * Cфакт МЕТОД ОСВОЕННОГО ОБЪЕМА  Плановая стоимость выполненных работ или освоенный объем — EV (Earned Value), BCWP. Утвержденный бюджет на физически выполненные работы. Процент общего бюджета, соответствующий проценту действительно завершенной работы. EV = Vплан * Cфакт ПРОИЗВОДНЫЕ ПОКАЗАТЕЛИ МЕТОДА ОСВОЕННОГО ОБЪЕМА Абсолютные показатели:  отклонение по стоимости — CV (Cost Variance). Равно разнице между плановой стоимостью выполненной работы и ее фактической стоимостью: CV = EV – AC;  отклонение по срокам — SV (Schedule Variance). Равно разнице между плановой стоимостью выполненной работы и плановой стоимостью запланированных работ: SV = EV – PV; С (стоимость) EV Опережение расписания С PV Отставание от расписания AC Экономия бюджета Время Если проект выполняется в соответствии с планом, все три показателя будут иметь одинаковое значение. PV (стоимость) Время С (стоимость) AC Опережение расписания EV PV Превышение бюджета Время EV AC Экономия бюджета ПРОИЗВОДНЫЕ ПОКАЗАТЕЛИ МЕТОДА ОСВОЕННОГО ОБЪЕМА Относительные показатели:  коэффициент выполнения бюджета (или индекс выполнения стоимости) — CPI (Cost Performance Index): CPI = EV / AC; Показывает, на сколько процентов выполнен проект по стоимости  коэффициент выполнения календарного плана (или индекс выполнения сроков) — SPI (Schedule Performance Index). SPI = EV / PV. CV>0 (CPI>1) Экономия бюджета Экономия бюджета Отставание по срокам Опережение сроков SV>0 (SPI>1) SV< 0 (SPI< 1) Перерасход бюджета Перерасход бюджета Отставание по срокам Опережение сроков CV< 0 (CPI< 1) ПРОГНОЗИРУЮЩИЕ ПОКАЗАТЕЛИ МЕТОДИКИ ОЦЕНКИ ОСВОЕННОГО ОБЪЕМА  Бюджет по завершении (Budget at Completion, BAC) - Сумма всех составляющих бюджета, установленных для работ, выполняемых в рамках проекта, элемента иерархической структуры работ или плановой операции. Общий плановый объем проекта  ЕAC - (Estimate at Completion) Прогноз по завершении - Ожидаемая общая стоимость плановой операции, элемента иерархической структуры работ или проекта, когда будет завершено указанное содержание работ. Вероятная итоговая стоимость компонента или проекта. ТРИ ФОРМУЛЫ РАСЧЕТА EAC EAC=AC + ETC (методом снизу вверх)  ETC -(Estimate to Complete) - Прогноз до завершения - Ожидаемые затраты на выполнение всех оставшихся работ для плановой операции, элемента иерархической структуры работ или проекта. Сколько проект еще будет стоить?  ETC (методом снизу вверх) – оценка, сделанная членами команды проекта, участвующими в его реализации. 1. EAC=BAC/CPI Допущение продуктивность проекта будет такой же. 2. EAC= AC + BAC –EV Допущение оставшиеся работы будут выполняться по забюджетированным ставкам ТРИ ФОРМУЛЫ РАСЧЕТА EAC 3. EAC = AC + ((BAC-EV)/СовокупныйCPI*СовокупныйSPI)) Прогноз с учетом обоих факторов CPI и SPI Пример Пусть : AC=800$, BAC =1200$, EV=600$, PV=500$ CPI=600/800=0,75 SPI=600/500=1,2 1. EAC=1200*800/600=1600$ 2. EAC=800+1200-600=1400$ 3. EAC=800+((1200-600)/(0,75*1,2))=800+670=1470; ОЦЕНКИ ETC (ESTIMATE TO COMPLETE) 1. Метод снизу-вверх 2. ETC=(BAC-СовокупныйEV)/СовокупныйCPI допущение о постоянной продуктивности. Отклонения в стоимости будут типичными 3. ETC= BAC-СовокупныйEV Отклонения в стоимости будут нетипичными ИНДЕКС ПРОИЗВОДИТЕЛЬНОСТИ ДО ЗАВЕРШЕНИЯ  TCPI (to-complete performance index) – прогноз эффективности выполнения стоимости, которая должна быть достигнута на оставшихся работах для достижения EAC или ETC.  TCPI = (BAC-EV)/(BAC-AC)  Пусть BAC=1000$, AC=800$, EV=700$  TCPI=(1000-7000/(1000-800)=1,5  Необходимо увеличить CPI в 1,5 раза, чтобы выйти на планируемые значения BAC. ИНДЕКС ПРОИЗВОДИТЕЛЬНОСТИ ДО ЗАВЕРШЕНИЯ  Если BAC больше не актуально, надо вычислить EAC, которое станет целевым для дальнейшего сравнения  TCPI = (BAC-EV)/(ЕAC-AC)  Если совокупный CPI<1, то дальнейшую работу по проекту необходимо выполнять в соответствии с TCPI ПРОГНОЗИРУЮЩИЕ ПОКАЗАТЕЛИ МЕТОДИКИ ОЦЕНКИ ОСВОЕННОГО ОБЪЕМА  FPD = PD/SPI (Forecast project duration) – планируемая продолжительность проекта  VAC=BAC-EAC (variance at completion) – Оценка отклонения по выполнению проекта или его фазы к его завершению, основанная на текущей продуктивности. Показывает ожидаемое фактическое превышение затрат или недоиспользование средств. Отклонение между бюджетом по завершению и оценкой затрат по завершению.  VAC<0 – бюджет исполняется неэффективно УПРАВЛЕНИЕ ПРОЕКТАМИ. УПРАВЛЕНИЕ РИСКАМИ ПРОЕКТА ЛЕКЦИЯ 7 ПО ДИСЦИПЛИНЕ «УПРАВЛЕНИЕ ИНФОРМАЦИОННОТЕХНОЛОГИЧЕСКИМИ ПРОЕКТАМИ» Доцент кафедры «Бизнес-информатика», к.т.н., доц. Морозова О.А. Москва 2018 ОСНОВНЫЕ ОПРЕДЕЛЕНИЯ  Риск проекта — это неопределенное событие или условие, которое в случае возникновения имеет позитивное или негативное воздействие, по меньшей мере, на одну из целей проекта, например, сроки, стоимость, содержание или качество.  Событие риска — потенциально возможное событие, которое может нанести ущерб или принести выгоды проекту.  Вероятность возникновения риска — вероятность того, что событие риска наступит ( >0%, <100%). Риск с вероятностью 100% - достоверное событие (должно быть предусмотрено планом проекта).  Последствия риска – степень воздействия события риска на цели проекта (выражаются в днях расписания, трудозатратах, деньгах).  Величина риска (ранг риска) —рассчитывается путем умножения вероятности возникновения риска на соответствующие последствия.  Причина или источник. Явление, обстоятельство обусловливающее наступление риска.  Симптомы риска, указание на то, что событие риска произошло или вот-вот произойдет. ВИДЫ РИСКОВ  «Известные» - риски, которые можно идентифицировать и подвергнуть анализу. В отношении таких рисков можно спланировать ответные действия. Метод реагирования - планы реагирования и резервы на возможные потери (резервами управляет МП)  «Неизвестные» - риски, которые невозможно идентифицировать и, следовательно, спланировать ответные действия. Неизвестные риски это непредвиденные обстоятельства. Метод реагирования - создание резерва на непредвиденные обстоятельства. Расходование резерва по согласованию с руководством (спонсором проекта). Управленческие резервы на непредвиденные обстоятельства не входят в базовый план по стоимости проекта, но включаются в бюджет проекта. Не распределяются по проекту, как бюджет, не учитываются при расчете освоенного объема. ПРОЦЕССЫ УПРАВЛЕНИЯ РИСКАМИ 1. 2. 3. 4. 5. 6. Планирование управления рисками. Идентификация рисков. Качественный анализ рисков. Количественный анализ рисков. Планирование реагирования на риски. Мониторинг и управление рисками. Управление рисками проекта включает в себя процессы, связанные с определением, анализом и реагированием на риски проекта с целью повышения вероятности и степени влияния положительных и снижения вероятности и степени влияния негативных событий в проекте. Адекватное управление рисками в компании — признак зрелости производственных процессов. ПЛАНИРОВАНИЕ УПРАВЛЕНИЯ РИСКАМИ Вход Методы Выход Описание содержания проекта Совещания по планированию и анализу План управления рисками План управления стоимостью проекта План управления расписанием проекта План управления коммуникациями проекта Факторы внешней среды предприятия ПЛАН УПРАВЛЕНИЯ РИСКАМИ Включает:  Методология. Определение подходов, инструментов и источников данных, которые могут использоваться для управления рисками в данном проекте.  Распределение ролей и ответственности. Список позиций для выполнения каждого вида операций, включенных в план управления рисками, назначение сотрудников на эти позиции.  Разработка бюджета. Выделение ресурсов и оценка стоимости мероприятий, необходимых для управления рисками.  Сроки. Определение сроков и частоты выполнения процессов управления рисками, их включение в расписание проекта.  Категории рисков. Структура, на основании которой производится систематическая и всесторонняя идентификация рисков с нужной степенью детализации.  Характеристики рисков. Принятая шкала измерения рисков КАТЕГОРИИ РИСКОВ ШКАЛА ОЦЕНКИ ВЕРОЯТНОСТИ РИСКА Трехуровневое разделение вероятности Интервал вероятностей Значение вероятности, используемое для вычислений Словесная формулировка Числовая оценка От 1% до 33% 17% низкая 1 От 34% до 67% 50% средняя 2 От 68% до 99% 84% высокая 3 СЕМИУРОВНЕВОЕ РАЗДЕЛЕНИЕ ВЕРОЯТНОСТИ Интервал вероятностей Словесная формулировка Числовая оценка От 1% до 14% Значение вероятности, используемое для вычислений 7% крайне маловероятно 1 От 15% до 28% 21% 2 От 29% до 42% 35% низкая вероятность скорее нет От 43% до 57% 50% 50-50 4 От 58% до 72% 65% возможно 5 От 73% до 86% 79% весьма правдоподобно 6 От 87% до 99% 93% почти наверняка 7 3 ШКАЛА ОЦЕНКИ ПОСЛЕДСТВИЙ (УГРОЗ) Вес 3 2 1 Оценка Оценка Катастрофические Критичные Умеренные Денежное выражение 1 до $100 2 $100-$1000 3 $1000-$10,000 4 $10,000-$100,000 5 $100,000-$1,000,000 6 $1,000,000-$10 миллионов 7 $10 миллионов-$100 миллионов 8 $100 миллионов-$1 миллиард 9 $1 миллиард-$10 миллиардов 10 свыше $10 миллиардов Критерий Потери более $100K Потери от $10K до $100K Потери менее $10K Может оцениваться в денежных единицах или по некоторой субъективной шкале ОЦЕНКА ПОСЛЕДСТВИЙ (УГРОЗ) Система оценки отражает политику и ценности организации и проектной группы. Оценка Перерасход Календарный Технические средств график условия 1 (низкая) до 1% сдвиг на 1 неделю небольшая потеря производительности 2 (средняя) до 5% сдвиг на 2 недели умеренное снижение производительности 3 (высокая) до 10% сдвиг на 1 месяц серьезный ущерб для производительности 4 (критическая) от 10% сдвиг более 1 мес. задача не может быть выполнена РАНГИ РИСКА. КРИТЕРИИ ОЦЕНКИ ВЕЛИЧИНЫ РИСКА ИДЕНТИФИКАЦИЯ РИСКОВ  Идентификация рисков — процесс определения рисков, способных повлиять на проект, и документирование их характеристик.  Выполняют члены команды проекта и эксперты по вопросам управления рисками, заказчики, участники проекта и эксперты в определенных областях.  Итеративный процесс, поскольку по мере развития проекта в рамках его жизненного цикла могут обнаруживаться новые риски. Частота итерации и состав участников выполнения каждого цикла в каждом случае могут быть разными. ИДЕНТИФИКАЦИЯ РИСКОВ Вход Методы Выход •План управления рисками •Оценка стоимости операций •Оценка длительности операций •Базовый план по содержанию •Реестр участников проекта •План управления стоимостью •План управления расписанием •План управления качеством •Факторы внешней среды предприятия Анализ документации Реестр Методы сбора информации рисков Анализ контрольных списков Анализ допущений Методы отображения с помощью диаграмм SWOT-анализ Экспертная оценка МЕТОДЫ ИДЕНТИФИКАЦИИ РИСКОВ  Анализ документации – анализ качества планов, согласованности планов, соответствия требованиям Заказчика. Анализ допущений проекта, базовых планов по содержанию, срокам, стоимости.  Мозговой штурм. Цель - создание подробного списка рисков проекта. Технология - список рисков разрабатывается на собрании (10—15 человек , члены команды проекта + эксперты ). Участники собрания называют риски, которые считают важными для проекта, при этом не допускается обсуждение. Далее риски сортируют по категориям и уточняют. Может проявиться преобладание одной личности.  Метод Дельфи аналогичен методу мозгового штурма, но его участники не общаются, списки вопросов и ответов составляет и рассылает ведущий. Ответы анализируются, распределяются по категориям и возвращаются экспертам для дальнейших комментариев. Список рисков получается через несколько циклов этого процесса. Занимает много времени. Высокая загрузка ведущего МЕТОДЫ ИДЕНТИФИКАЦИИ РИСКОВ  Метод номинальных групп – цель идентифицировать и ранжировать риски. Технология - группа из 7—10 экспертов. Каждый участник без обсуждений перечисляет видимые им риски проекта. Далее совместное обсуждение всех выделенных рисков и повторное индивидуальное составление списка рисков в порядке их важности. Требует много времени.  Карточки Кроуфорда. Технология -группа из 7—10 экспертов. Ведущий 10 раз задает один и тот же вопрос, каждый ответ на отдельной карточке. Участник не может повторять один и тот же ответ.  Опросы экспертов с большим опытом работы над проектами.Цель - выявить наиболее существенные причины возникновения рисков проекта и сгруппировать риски по причинам, их вызывающим. МЕТОДЫ ИДЕНТИФИКАЦИИ РИСКОВ  Анализ сильных и слабых сторон, возможностей и угроз (анализ SWOT). Цель— оценить потенциал и окружение проекта. Потенциал проекта, выраженный в виде его сильных и слабых сторон, позволяет оценить разрывы между содержанием проекта и возможностями его выполнения. Оценка окружения проекта показывает, какие благоприятные возможности предоставляет и какими опасностями угрожает внешняя среда.  Анализ контрольных списков. Контрольные списки - перечни рисков, составленные на основе опыта исполнения прежних аналогичных проектов.  Метод аналогии. Использует планы по управлению рисками других аналогичных проектов.  Методы с использованием диаграмм. Диаграммы причинно-следственных связей (диаграммы Ишикавы), блок-схемы процессов, позволяют проследить последовательность событий, диаграммы влияния. РЕЕСТР РИСКОВ Содержит: ID  список идентифицированных рисков;  список потенциальных действий по реагированию;  основные причины возникновения риска;  уточнение категорий рисков. Наимен ование Описа ние Дата записи Ранг риска Вероятность возникновения Последст вия Стратегия реагирова ния Владелец риска НАИБОЛЕЕ РАСПРОСТРАНЕННЫЕ РИСКИ ПРОЕКТА ПО РАЗРАБОТКЕ ПО  Дефицит специалистов.  Нереалистичные сроки и бюджет.  Реализация несоответствующей функциональности.  Разработка неправильного пользовательского интерфейса.  "Золотая сервировка", ненужная оптимизация и оттачивание деталей.  Непрекращающийся поток изменений.  Нехватка информации о внешних компонентах, определяющих окружение системы или вовлеченных в интеграцию.  Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.  Недостаточная производительность получаемой системы.  "Разрыв" в квалификации специалистов разных областей знаний. КАЧЕСТВЕННЫЙ АНАЛИЗ РИСКОВ  Это процесс приоритезации идентифицированных рисков путем совместной оценки вероятности их возникновения и степени влияния, результаты которого используются впоследствии, например в ходе количественного анализа рисков.  Действия по определению вероятности возникновения и степени потенциального влияния рисков на достижение целей проекта КАЧЕСТВЕННЫЙ АНАЛИЗ РИСКОВ Вход Методы Выход Реестр рисков Определение вероятности и степени влияния рисков Обновления реестра рисков План управления рисками Описание содержания проекта Матрица вероятности и степени влияния Оценка качества данных риска Классификация рисков Оценка срочности реагирования на риски Экспертная оценка ОБНОВЛЕННЫЙ РЕЕСТР РИСКОВ Включает:  сравнительный рейтинг или приоритетный список рисков;  сгруппированные по категориям риски;  причины рисков или области проекта, требующие особого внимания;  список рисков, реагирование на которые должно произойти в кратчайшие сроки;  список рисков для дополнительного анализа и реагирования;  список рисков низкой приоритетности;  тенденции рисков. ТЕНДЕНЦИИ РИСКА  Вероятность и степень воздействия рисков меняются в ходе исполнения проекта.  В течение жизненного цикла проекта должна происходить постоянная переоценка рисков. Динамика риска А 0,2 Ранг рис ка 0,18 0,15 0,1 0,07 0,06 0,05 0,02 38808 38838 38869 38899 КОЛИЧЕСТВЕННАЯ ОЦЕНКА РИСКОВ Количественный анализ рисков — это количественный анализ потенциального воздействия идентифицированных рисков на общие цели проекта. Оценивается: Вероятность достижения конечной цели проекта Риски, требующие скорейшего реагирования и большего внимания, а также влияние их последствий на проект. Фактические затраты, предполагаемые сроки окончания. Степень воздействия риска на проект и объемы непредвиденных затрат и материалов, которые могут понадобиться. Количественная и количественная оценка рисков могут использоваться по отдельности или вместе, в зависимости от располагаемого времени и бюджета. Количественный анализ обычно выполняется для рисков, которые были квалифицированы в результате качественного анализа (риски, имеющие высокие и умеренные ранги). КОЛИЧЕСТВЕННАЯ ОЦЕНКА РИСКОВ Вход Методы Выход Реестр рисков Методы сбора и предоставления данных Обновления реестра рисков План управления рисками План управления стоимостью План управления расписанием Активы организационног о процесса Количественный анализ рисков и методы моделирования Экспертная оценка МЕТОДЫ КОЛИЧЕСТВЕННОГО АНАЛИЗА РИСКОВ  Методы сбора и представления данных  Интервьюирование (предварительно должен быть выбран закон вероятности распределения сл. величины)  Вероятностные распределения. Треугольное (оптимистический, пессимистический и наиболее вероятный сценарий), бетараспределение (оценки мат. ожидания и дисперсии)  Методы количественного анализа и моделирования  Анализ чувствительности  Анализ ожидаемой денежной стоимости  Анализ дерева решений  Имитационное моделирование АНАЛИЗ ЧУВСТВИТЕЛЬНОСТИ  Оценка влияния изменения исходных параметров проекта на его конечные характеристики.  Техника проведения анализа - изменение выбранных параметров в определенных пределах, при условии, что остальные параметры остаются неизменными.  Позволяет определить наиболее критические переменные, которые в наибольшей степени могут повлиять на осуществимость и эффективность проекта.  Варьируемые переменные: объем продаж; цена за единицу продукции; инвестиционные затраты или их составляющие; операционные затраты или их составляющие; срок задержек платежей: уровень инфляции; процент по займам, ставка дисконта и др.  Результирующие показатели: показатели эффективности (чистый дисконтированный доход, внутренняя норма доходности, индекс доходности, срок окупаемости, рентабельность инвестиций); ежегодные показатели проекта (балансовая прибыль, чистая прибыль, сальдо накопленных реальных денег). АНАЛИЗ ЧУВСТВИТЕЛЬНОСТИ Диаграмма торнадо АНАЛИЗ ЧУВСТВИТЕЛЬНОСТИ  Относительный анализ чувствительности - сравнивается относительное влияние исходных переменных (при их изменении на фиксированную величину, например, на 10%) на результирующие показатели проекта. Определяют наиболее существенные для проекта исходные переменные; их изменение должно контролироваться в первую очередь.  Абсолютный анализ чувствительности - определяется численное отклонение результирующих показателей при изменении значений исходных переменных. Значения переменных, соответствующие нулевым значениям результирующих показателей, соответствуют рассмотренным выше показателям предельного уровня. Результаты анализа чувствительности приводятся в табличной или графической формах. АНАЛИЗ ОЖИДАЕМОЙ ДЕНЕЖНОЙ СТОИМОСТИ  Статистический метод для вычисления среднего результата в условиях неопределенности  “Expected monetary value analysis is a statistical concept that calculates the average outcomes when the future includes the scenarios that may or may not happen.”  Используется вместе с анализом дерева решений  Для оценки резерва на непредвиденные обстоятельства АНАЛИЗ ОЖИДАЕМОЙ ДЕНЕЖНОЙ СТОИМОСТИ  Ожидаемая денежная стоимость (EMV) = Вероятность * Последствие ДЕРЕВО РЕШЕНИЙ  Узлы -ключевые события, стрелки - проводимые работы по реализации проекта. Информация по времени, стоимости работ и вероятности принятия того или иного решения. Порядок построения:  определение состава и продолжительности фаз жизненного цикла проекта;  определение ключевых, событий, которые могут повлиять на дальнейшее развитие проекта;  определение времени наступления ключевых событий;  формулировка всех возможных решений, которые могут быть приняты в результате наступления каждого ключевого события;  определение вероятности принятия каждого решения;  определение стоимости каждого этапа осуществления проекта (стоимости работ между ключевыми событиями). В результате построения дерева решений определяется вероятность каждого сценария развития проекта, эффективность по каждому сценарию, а также интегральная эффективность проекта.  Стоимость каждого возможного выбора  Вероятность возникновения каждого сценария  Вознаграждение за каждый логический путь (потери) ДЕРЕВО РЕШЕНИЙ МОДЕЛИРОВАНИЕ И ИМИТАЦИЯ  Имитационное моделирование по методу Монте-Карло (Monte-Carlo Simulation) позволяет построить математическую модель для проекта с неопределенными значениями параметров, и, зная вероятностные распределения параметров проекта, а также связь между изменениями параметров получить распределение выходных показателей проекта  Анализ сроков и стоимости ВЫХОДЫ КОЛИЧЕСТВЕННОГО АНАЛИЗА РИСКОВ  Обновленный реестр рисков:  Доверительные интервалы для прогнозов по расписанию, стоимости проекта  Вероятность достижения целей по стоимости и срокам  Список приоритезированных рисков  Тренды рисков ПЛАНИРОВАНИЕ РЕАГИРОВАНИЯ НА РИСКИ  Планирование реагирования на риски — это процесс разработки путей и определения действий по увеличению возможностей и снижению угроз для целей проекта.  Начинается после проведения качественного и количественного анализа рисков. Включает в себя лиц , «ответственных за реагирование на риски.  В планировании реагирования на риски рассматриваются риски согласно их приоритетам; при необходимости новые ресурсы и операции добавляются в планы управления стоимостью, расписанием и проектом. ПЛАНИРОВАНИЕ РЕАГИРОВАНИЯ НА РИСКИ Вход Методы Выход Реестр рисков Стратегия реагирования на негативные риски (угрозы) Обновления реестра рисков План управления рисками Стратегия реагирования на позитивные риски (возможности) Стратегия реагирования на непредвиденные обстоятельства Экспертная оценка Контрактные соглашения, касающиеся рисков Обновления плана управления проектом Обновления документации проекта СТРАТЕГИЯ РЕАГИРОВАНИЯ НА НЕГАТИВНЫЕ УГРОЗЫ  Уклонение (как избежать риска, изменив способ действия) -изменение плана управления проектом таким образом, чтобы исключить (ослабить) угрозу, вызванную негативным риском, На ранних стадиях проекта, можно избежать рисков путем уточнения требований, получения информации, улучшения коммуникации.  Передача (как перенести риск на другой проект, проектную группу, организацию или частных лиц) - перенос ответственность за управление риском другой стороне; риск при этом не устраняется (наиболее эффективно в отношении финансовых рисков). Инструменты передачи рисков - страховки, гарантии выполнения контракта, гарантийные обязательства и т. д.  Снижение ( как уменьшить вероятность риска , что предпринять заранее) - понижение вероятности и/или последствий негативного рискованного события до приемлемых пределов. Примеры мероприятий: внедрение менее сложных процессов, проведение большего количества испытаний или выбор поставщика, поставки которого носят более стабильный характер. СТРАТЕГИЯ РЕАГИРОВАНИЯ НА ПОЗИТИВНЫЕ РИСКИ  Использование (как гарантированно реализовать благоприятную возможность) – принимаются меры для обеспечения появления данной благоприятной возможности в различных формах. Примеры: привлечение к участию в проекте более талантливого персонала, чтобы сократить время, обеспечение более высокого качества по сравнению с первоначальным планом.  Совместное использование (как использовать благоприятную возможность наилучшим образом) - передача ответственности третьей стороне, способной наилучшим образом воспользоваться представившейся благоприятной возможностью в интересах проекта.  Усиление (как повысить вероятность наступления благоприятных событий и\или усилить воздействие благоприятных рисков). Воздействие напричину, вызывающую благоприятную возможность. Принятие риска — стратегия, при которой риск принимается. Команда проекта не пытается повлиять на риск. ОБНОВЛЕННЫЙ РЕЕСТР РИСКОВ Содержит:  идентифицированные риски, их описания, области проекта, на которые они влияют (например, элемент ИСР), причины рисков (например, компонент ИСР) и как они могут повлиять на цели проекта;  лица, ответственные за риски, их ответственность;  выходы качественного и количественного анализов, включая список рисков проекта, упорядоченных по приоритетности, и вероятностный анализ проекта;  согласованные стратегии реагирования на риски;  конкретные действия, необходимые для применения выбранной стратегии реагирования;  симптомы и признаки возникновения риска;  бюджет и плановые операции, необходимые для выполнения выбранных способов реагирования на риски; ОБНОВЛЕННЫЙ РЕЕСТР РИСКОВ  временной и бюджетный резервы на непредвиденные обстоятельства, предназначенные для обеспечения толерантности к риску участников проекта;  планы на случай возникновения непредвиденных обстоятельств и условия, при которых они вводятся в действие;  резервные планы, используемые в качестве ответной реакции на возникновение риска в случае, если первоначальное реагирование на риск оказалось неадекватным;  остаточные риски, оставшиеся после планового реагирования на риски, а также те, которые были приняты сознательно;  вторичные риски, возникающие в результате применения реагирования на риски;  резервы на непредвиденные обстоятельства, рассчитанные на основе данных количественного анализа проекта и порогов рисков организации. МОНИТОРИНГ И КОНТРОЛЬ РИСКОВ  Задачи:  идентификация, анализ и планирования вновь возникших рисков,  отслеживание идентифицированных рисков,  проверка и исполнения операций реагирования на риски и оценки их эффективности МОНИТОРИНГ И КОНТРОЛЬ РИСКОВ Входы Методы Выходы Реестр рисков Пересмотр рисков Обновления реестра рисков План управления рисками Аудит рисков Обновления активов организационного процесса Данные об исполнении работ Отчеты об исполнении Анализ отклонений и трендов Запрошенные изменения Техническое измерение исполнения Обновления плана управления проектом Анализ резервов Обновления документации проекта Совещания по текущему состоянию МОНИТОРИНГ И КОНТРОЛЬ РИСКОВ  Пересмотр рисков. Идентификация новых рисков и пересмотре известных рисков. Должен проводиться регулярно, согласно расписанию. В ряде случаев проводится дополнительное планирование планирование мероприятий по реагированию на риски.  Аудит рисков. Аудит рисков предполагает изучение и предоставление в документальном виде результатов оценки эффективности мероприятий по реагированию на риски, относящихся к идентифицированным рискам, изучение основных причин их возникновения, а также оценку эффективности процесса управления рисками.  Анализ отклонений и трендов. Цель - прогнозировать потенциальные отклонения проекта на момент его завершения по показателям стоимости и расписания. Тренды строят с использованием данных о выполнении. Для мониторинга выполнения всего проекта могут использоваться анализ освоенного объема и другие методы анализа отклонений проекта и трендов.  Техническое измерение исполнения. Сравниваются получаемые в процессе реализации проекта технические результаты с запланированными.  Анализ резервов. Сравнение объема оставшихся резервов на непредвиденные обстоятельства с количеством оставшихся рисков по состоянию на любой момент времени процесса выполнения проекта.  Совещания по текущему состоянию. УПРАВЛЕНИЕ КАЧЕСТВОМ ЛЕКЦИЯ 8 ПО ДИСЦИПЛИНЕ «УПРАВЛЕНИЕ ИНФОРМАЦИОННОТЕХНОЛОГИЧЕСКИМИ ПРОЕКТАМИ» Доцент кафедры «Бизнес-информатика», к.т.н., доц. Морозова О.А. Москва 2018 КАЧЕСТВО  Качество — это совокупность характеристик объекта, позволяющая ему удовлетворять заявленным или подразумеваемым требованиям. Основные принципы управления качеством .  Удовлетворение заказчика. Обеспечение как формальных требований заказчика (отраженных в контракте), так и неформальных ожиданий конечных пользователей заказчика от использования ими продукта (результата проекта).  Предотвращение прежде, чем устранение. Один из фундаментальных принципов современного управления качеством — предотвращение появления, а не устранение уже появившегося брака (потерь качества продукта).  Непрерывное улучшение. Вся команда проекта непрерывно работает над улучшением процессов выполнения проекта и повышением качества продукта. 2 ИСТОЧНИКИ ТРЕБОВАНИЙ  Стандарты  Обязательно нормативно-технические документы (в т.ч. технические регламенты)  Технические задания и ТУ  Проектная и технологическая документация  Документация процедурного уровня регламентации (описанные процессы управления)  Соглашения сторон в форме договоров или контрактов. 3 МЕТОДОЛОГИИ УПРАВЛЕНИЯ КАЧЕСТВОМ Управление качеством проекта Качество управления Качество в узком и широком смысле (Каору Исикава) Качество продукта • Концепция Total Quality Management (TQM) (50-е - 80-е г.г.ХХ века). Качеством необходимо управлять, это непрерывный процесс • Шесть сигм – стратегия, основанная на измерениях (не более 3.4 дефектов на миллион исходов) • Деминг – качество проблема управления • Джуран – качество планируется 4 КАЧЕСТВО В ОБЛАСТИ ИТ-ПРОЕКТОВ  Качество ИТ-продуктов определяется технологиями, используемыми для их создания.  Качество – это некий уровень выполнения работ, при котором создаваемый продукт удовлетворяет предъявленным требованиям.  Качество не является синонимом «очень хорошего продукта»или «продукта без единого дефекта».  «Золотая сервировка» (gold platting) - добавление в продукт возможностей и функциональности, которые хоть и приятны заказчику, но не были им запрошены и не являются необходимыми для закрытия работ (характерно для ИТ-проектов). Членам команды свойственно увлекаться своими делами, или переключаться с «трудных задач» на «интересные».  Предотвращение «золотой сервировки» – задача ПМ. Основные причины – она съедает драгоценные ресурсы проекта (время, деньги). Даже если в результате этого, выполнение проекта не пострадает – ресурсы вовсе не бесплатны для самой организации. 5 СТАНДАРТЫ Мировые тенденции в области качества - Переход от управления качеством продукта к управлению качеством производственных процессов Глобализация рынка требует общих стандартов и инструментов оценки (потенциальных) партнеров. Общие методические указания по управлению качеством проектов  ИСО 10006:1996 "Административное управление качеством. Руководящие указания по обеспечению качества при управлении проектом",  ИСО 10007:1995 "Административное управление качеством. Руководящие указания по управлению конфигурацией". Стандарты по управлению качеством проектов в области информационных технологий:  COBIT (Control Objectives for Information and Related Technology) ,  корпоративный стандарт Microsoft MSF2 6 ПРИНЦИПЫ КАЧЕСТВА ISO 9000(ГОСТ Р ISO 90002011) 7 РАЗЛИЧИЯ В ПОНИМАНИИ УПРАВЛЕНИЯ КАЧЕСТВОМ В ISO 9000 И PMBOK ISO 9000  Ориентация на ожидания и удовлетворенность потребителя (явный потребитель, в т.ч. внутренний)  Все процессы (производство, сервисные, управление) являются частью системы менеджмента качества (СМК)  Большое внимание созданию системы – тщательная разработка каждого процесса и механизмов улучшения  Явно выделенные и требуемые процессы по анализу и улучшению, предупреждающим и корректирующим мероприятиям PMBoK  Проверка соответствия «нуждам и требованиям проекта»  Только 3 процесса вынесены в блок управления качеством (планирование, обеспечение, контроль)  В стадии планирования управления качеством основные процессы заимствуются из предыдущих проектов с небольшими доработками  Корректирующие и предупреждающие действия – лишь выходы процессов обеспечения и контроля 8 ПРОЦЕССЫ PM  Планирование качества  Обеспечение качества  Контроль качества 9 ПЛАНИРОВАНИЕ КАЧЕСТВА Планирование качества — это документирование того, каким образом будет достигнуто соответствие:  требованиям к качеству продукта и проекта;  стандартам качества, применимым к продукту и проекту. Предполагает ответы на вопросы: «что есть качество на нашем проекте?» и «как мы будем его достигать?». 10 ПЛАНИРОВАНИЕ КАЧЕСТВА Вход Методы Выход •Базовый план по содержанию •Реестр участников проекта •Базовый план по стоимости •Реестр рисков •Активы организационного процесса •Факторы внешней среды предприятия •Анализ прибыли и затрат •Стоимость качества •Контрольные диаграммы •Бенчмаркинг (сравнение с эталоном) •Планирование экспериментов •Выборочные оценки •Диаграммы зависимостей •Собственные методологии управления качеством •Дополнительные инструменты планирования качества План управления качеством Метрики качества Контрольные списки по качеству План совершенствования процессов Обновления документации проекта 11 МЕТОДЫ ПЛАНИРОВАНИЯ КАЧЕСТВА  Анализ прибыли и затрат – учет компромиссов в расходах на качество. Затраты на предотвращение и исправление дефектов.  Выгоды от соблюдения качества:  Повышение удовлетворенности заинтересованных сторон  Снижение стоимости  Повышение производительности  Меньший объем переделок Основные расходы на соблюдение требований качества в проекте – стоимость действий по управлению качеством 12  Анализ прибыли и затрат. Цель метода — выдержать необходимое соотношение между доходами и затратами в проекте. 13 МЕТОДЫ ПЛАНИРОВАНИЯ КАЧЕСТВА Стоимость качества – суммарные расходы на производство продукта или услуги проекта в соответствии со стандартами качества Стоимость всех работ (плановых и внеплановых), направленных на соблюдение качества продукта. 14 Стоимость качества = Стоимость соответствия + стоимость несоответствия Стоимость устранения ошибок Стоимость предотвращения дефектов Стоимость качества Стоимость несоответствия Стоимость соответствия Стоимость предотвращения Стоимость оценки Стоимость ошибок (внутренняя) Стоимость ошибок (внешняя) 15 МЕТОДЫ ПЛАНИРОВАНИЯ КАЧЕСТВА  Стоимость предотвращения – расходы, связанные с удовлетворением требований заказчика по производству продукта без дефектов. Недопущение передачи заказчику результата с дефектами. Расходы планируются заранее (планируется качество)  Стоимость оценки – расходы на проверку соответствия продукта или процесса требованиям (инспекции и тестирование)  Стоимость ошибок – стоимость низкого качества (несоблюдение плана)  Внутренняя – результат проекта не соответствует требованиям Заказчика и находится под контролем Исполнителя (не передан заказчику). Расходы на корректирующие действия, переделку, простой и пр.  Внешняя – продукт передан Заказчику, который обнаружил несоблюдение требований. Расходы на инспекции со стороны Заказчика, расходы на возврат, гарантийное обслуживание. 16 ЭФФЕКТ ОТ УПРАВЛЕНИЯ КАЧЕСТВОМ 17 МЕТОДЫ ПЛАНИРОВАНИЯ КАЧЕСТВА  Контрольные карты – стабилен ли процесс, контролируются ли отклонения процесса  Сравнение с эталоном (бенчмаркинг) - сопоставление действующего или планируемого проекта с другими проектами с целью выработать идеи для усовершенствования и критерии оценки исполнения. Другие проекты могут быть как внутри исполняющей организации, так и за ее пределами, а также могут относиться как к той же области приложения, так и к другой  Планирование экспериментов — статистический метод, позволяющий определить факторы, которые оказывают влияние на определенные переменные величины продукта или процесса 18 МЕТОДЫ ПЛАНИРОВАНИЯ КАЧЕСТВА  Выборочные оценки – выборка элементов и их проверка на попадание в допустимые интервалы отклонений  Авторские методики управления качеством (шесть сигм, бережливое производство, TQM и пр.)  Дополнительные инструменты планирования качества :  Мозговой штурм  Диаграммы сходства (группировка сходных идей)  Анализ силовых полей (метод ранжирования мнений «за» и «против» при принятии решений)  Методы номинальных групп  Матричные диаграммы (принятие решений при наличии альтернатив, проставляются ранги для альтернатив)  Матрицы приоритетов (мнококритериальные решения) 19 Выходы планирования качества План управления качеством описывает, каким образом команда управления проектом будет претворять политику исполняющей организации в области качества. План управления качеством является частью или вспомогательным планом в составе плана управления проектом. Документируются: • Ресурсы • Процессы и процедуры • Ответственность Контроль качества не является действием, выполненным «перед тем как отдать продукт заказчику». Этот процесс идет непрерывно. В него вовлечен каждый член команды (каждый отвечает за качество собственной работы). К моменту «закрытия» работ (т.е. к моменту передачи продукта заказчику), работы по контролю качества должны быть закончены (а не запущены). 20 Выходы планирования качества Метрики качества – предметы измерения и порядок измерения в ходе процесса контроля качества (дата поставки, частота ошибок, надежность, доступность и пр.) Контрольные списки качества – инструкции для проверяющего лица. План совершенствования процессов – выявление неэффективности в процессах и устранение Обновленная документация проекта – реестр заинтересованных сторон, матрица ответственности, риски и пр. 21 ОБЕСПЕЧЕНИЕ КАЧЕСТВА  Обеспечение качества — это принятие плановых систематических мер, обеспечивающих выполнение всех предусмотренных процессов, необходимых для того, чтобы проект (продукт, услуга) удовлетворял требованиям по качеству.  Обеспечение качества — это не проверка конченого продукта (конечным продуктом занимается аудит качества). Вход Методы Выход План управления качеством Инструменты и методы планирования и контроля качества Обновления активов организационного процесса Аудиты качества Запросы на изменения Анализ процесса Обновления плана управления проектом Метрики качества Данные об исполнении работ Измерения контроля качества 22 Обновления документации проекта ОБЕСПЕЧЕНИЕ КАЧЕСТВА Аудит качества — независимая экспертная оценка, определяющая, насколько операции проекта соответствуют, и соответствуют ли, установленным в рамках проекта или организации правилам, процессам и процедурам. Целью аудита качества является выявление неэффективных и экономически неоправданных правил, процессов и процедур, используемых в проекте. Количество и сроки плановых проектных аудитов могут определяться основными этапами проекта или ключевыми событиями. Внеплановые аудиты проводятся по запросам Заказчика, руководителей департаментов и отделов. Аудиты качества проводятся на основе критериев, каждый из которых является следствием требований нормативной документации системы менеджмента качества (требование ISO 9000) и системы управления проектами (PMBOK). Пример схемы проведения внутреннего аудита качества проекта :  анализ исправления замечаний предыдущей проверки;  проведение проверки проекта в соответствии с контрольными списками;  оформление отчета о контроле качества;  информирование команды проекта о появлении новых отчетных документов. Анализ процесса - выполнение действий, описанных в плане улучшения процесса и направленных на выявление организационных и технических моментов, которые нуждаются в улучшении. 23 КОНТРОЛЬ КАЧЕСТВА  Мониторинг определенных результатов с целью определения их соответствия принятым стандартами качества и определение путей устранения причин, вызывающих неудовлетворительное исполнение 24 КОНТРОЛЬ КАЧЕСТВА Вход Методы Выход •План управления качеством •Метрики качества •Контрольные списки процедур контроля качества •Измерение исполнения работ •Одобренные запросы на изменения •Результаты проекта •Активы организационного процесса •Контрольная карта; •Диаграмма Парето; •Гистограмма; •Контрольный лист; •Диаграмма Исикавы; •Расслоение (стратификация); •Диаграмма рассеяния. •Выборочные оценки •Инспекция •Анализ утвержденных запросов на изменения •Измерения контроля качества •Утвержденные изменения •Утвержденные результаты проекта •Обновления активов организационного процесса •Запросы на изменения •Обновления плана управления проектом •Обновления 25 документации проекта КОНТРОЛЬНАЯ КАРТА (КОНТРОЛЬНАЯ ДИАГРАММА) Позволяет визуализировать изменение какой-либо контрольной величины во времени. 26 КОНТРОЛЬНАЯ КАРТА  Контрольные карты Шухарта (ГОСТ Р 50779.40 - 96) предназначены для статистического анализа и управления качеством процесса. Контрольные карты используют для оценки того, находится или не находится исследуемый процесс в статистически управляемом состоянии.  На одной карте может быть отображен только один показатель, изменяющийся во времени. Для одновременного анализа нескольких показателей их необходимо привести к одному параметру.  Чем статистически стабильнее процесс, тем выше его качество и тем меньше различного рода издержек на исправление ошибок, брака, аварий, потерь времени и т.д. 27 РАССЛОЕНИЕ (СТРАТИФИКАЦИЯ)  группируют данные в зависимости от условий их получения и производят обработку каждой группы в отдельности.  При расслоении данных следует стремиться к тому, чтобы различие внутри группы было как можно меньше, а различие между группами – как можно больше.  Расслоение позволяет получить представление о скрытых причинах дефектов, а также помогает выявить причину появления дефекта, если обнаруживается разница в данных между «слоями». Например, если расслоение проведено по фактору «исполнитель», то при значительном различии в данных можно определить влияние того или иного исполнителя на качество изделия; 28