КнигаВнедрениеИС
реклама
Грекул В.И., Денищенко Г.Н., Коровкина Н.Л. Управление внедрением информационных систем Учебник Допущено Учебно-методическим объединением в области менеджмента в качестве учебника для студентов высших учебных заведений направления подготовки «Бизнес-информатика» Москва 2008 1 Содержание Лекция 1. ВВЕДЕНИЕ. НАЗНАЧЕНИЕ И СОСТАВ МЕТОДОЛОГИЙ ВНЕДРЕНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ ............................................................................................... 4 Общая характеристика проектов внедрения информационных систем ................................ 5 Назначение и состав методологий внедрения .......................................................................... 7 Стандарты управления проектами .......................................................................................... 10 Характерные особенности проектных работ ......................................................................... 19 Организационная структура проекта ...................................................................................... 25 Лекция 2. СОДЕРЖАНИЕ ПРОЕКТОВ ВНЕДРЕНИЯ ИС В РАЗЛИЧНЫХ МЕТОДОЛОГИЯХ ....................................................................................................................... 36 Методологии внедрения компании Microsoft ........................................................................ 36 Методология внедрения OneMethodology .............................................................................. 43 Методология внедрения компании Oracle.............................................................................. 47 Пример корпоративной методологии внедрения................................................................... 52 Лекция 3. УНИФИЦИРОВАННАЯ МОДЕЛЬ ОРГАНИЗАЦИИ ВНЕДРЕНИЯ РЕШЕНИЙ В МЕТОДОЛОГИИ MICROSOFT SOLUTIONS FRAMEWORK (MSF) .................................... 58 Состав работ проекта — модель процессов MSF .................................................................. 58 Команда проекта — модель проектной группы MSF............................................................ 61 Организация исполнения проекта ........................................................................................... 68 Лекция 4. УПРАВЛЕНИЕ ИНТЕГРАЦИЕЙ ПРОЕКТА. УПРАВЛЕНИЕ СОДЕРЖАНИЕМ ПРОЕКТА ...................................................................................................................................... 78 Управление интеграцией .......................................................................................................... 80 Устав проекта ............................................................................................................................ 85 План управления проектом ...................................................................................................... 92 Управление содержанием проекта .......................................................................................... 93 Планирование содержания....................................................................................................... 96 Уточнение (определение) содержания ................................................................................... 97 Создание иерархической структуры работ .......................................................................... 101 Подтверждение содержания .................................................................................................. 106 Управление изменениями содержания ................................................................................. 107 Лекция 5. УПРАВЛЕНИЕ СРОКАМИ ПРОЕКТА .................................................................. 110 Процессы управления сроками проекта ............................................................................... 110 Определение состава операций ............................................................................................. 113 Определение взаимосвязи операций ..................................................................................... 117 Оценка ресурсов операций..................................................................................................... 123 Оценка длительности операций ............................................................................................ 126 Разработка расписания ........................................................................................................... 130 Управление расписанием ....................................................................................................... 140 Лекция 6. УПРАВЛЕНИЕ СТОИМОСТЬЮ ПРОЕКТА ......................................................... 144 Стоимостная оценка ............................................................................................................... 145 Разработка бюджета расходов ............................................................................................... 149 Лекция 7. УПРАВЛЕНИЕ РИСКАМИ ПРОЕКТА .................................................................. 162 Основные понятия и определения ......................................................................................... 162 Планирование управления рисками ...................................................................................... 164 Идентификация рисков .......................................................................................................... 171 Качественный анализ рисков ................................................................................................. 175 Количественный анализ рисков ............................................................................................ 178 2 Планирование реагирования на риски .................................................................................. 181 Мониторинг и управление рисками ...................................................................................... 183 Лекция 8. УПРАВЛЕНИЕ КАЧЕСТВОМ ПРОЕКТА ............................................................. 189 Планирование качества проекта ............................................................................................ 193 Процесс обеспечения качества .............................................................................................. 199 Процесс контроля качества .................................................................................................... 202 Лекция 9. УПРАВЛЕНИЕ ЧЕЛОВЕЧЕСКИМИ РЕСУРСАМИ ПРОЕКТА ......................... 209 Команда управления проектом .............................................................................................. 210 Функции и полномочия проектных ролей команды управления проектом ...................... 212 Планирование команды проекта ........................................................................................... 218 Управление командой проекта .............................................................................................. 229 3 Лекция 1. ВВЕДЕНИЕ. НАЗНАЧЕНИЕ И СОСТАВ МЕТОДОЛОГИЙ ВНЕДРЕНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ Информационная система (ИС). Задачи и проблемы внедрения информационных систем. Назначение и состав методологии внедрения ИС. Содержание стандартов управления проектами. Концепции управления проектами. Участники проекта и их задачи. Общие особенности проектной деятельности. Окружение проекта. Организационная структура проекта. Основные типы структур организаций, осуществляющих внедрение ИС. Организационная структура проекта. Ключевые слова: информационная система, внедрение информационных систем, факторы успеха внедрения ИС, методология внедрения, проект, стандарт управления проектами, менеджер проекта, руководитель проекта, факторы окружения проекта, действующие лица окружения проекта, спонсор проекта, функциональная организация, матричная организация, проектная организация, команда управления проектом, роль в проекте (проектная роль), куратор проекта (спонсор). Практически в любой современной организации мы можем наблюдать тесное переплетение информационных технологий и бизнес-процессов основной деятельности. Поэтому внедрение преобразованием, (замена) зачастую информационной затрагивающим системы оказывается разнообразные сферы серьезным деятельности предприятия. Как следствие, во многих случаях оно становится сложным и болезненным процессом. Тем не менее проблемы, возникающие при внедрении системы, уже достаточно хорошо изучены, и в настоящее время созданы эффективные методики их решения, объединенные в соответствующих стандартах (методологиях). Начиная информационных рассматривать систем, вопросы, следует связанные прежде всего с организацией уточнить значение внедрения термина «информационная система». К сожалению, до сих пор под информационной системой зачастую подразумевают программный пакет, что совершенно не соответствует истине и не позволяет сформировать правильное представление о задачах проекта внедрения. Информационная система представляет собой сложный комплекс разнородных составляющих, которые взаимодействуют между собой и создают необходимые 4 потребителю свойства системы. Для целей настоящей книги информационную систему следует рассматривать как всю инфраструктуру предприятия, задействованную в процессе управления информационно-документальными потоками и включающую в себя: 1. технологические элементы, обеспечивающие функционирование системы: информационную модель предметной области; кадровые ресурсы, отвечающие за формирование и развитие информационной модели; программный комплекс; кадровые ресурсы, отвечающие за конфигурирование программного комплекса; аппаратно-техническую базу; эксплуатационно-технические кадровые ресурсы; 2. управленческие элементы, обеспечивающие организацию эксплуатации системы: регламент развития информационной модели и правила внесения в нее изменений; регламент технической и пользовательской поддержки программного комплекса; регламент внесения изменений в конфигурацию программного комплекса и состав его функциональных модулей; регламент использования программного комплекса и пользовательские инструкции; регламент обучения и сертификации пользователей. Общая характеристика проектов внедрения информационных систем Задача проекта внедрения информационной системы включает в себя создание (адаптацию) и запуск в продуктивную эксплуатацию всех перечисленных выше элементов. О сложности этой задачи свидетельствует известная из результатов исследований Standish Group неутешительная статистика по успешности ИТ-проектов: в 1998 году только 26% проектов завершились в срок, не превысили бюджет и обеспечили реализацию предусмотренных функций. 5 Источники проблем при внедрении информационной системы охватывают различные аспекты частного проекта и деятельности компании в целом. К ним можно отнести: отсутствие постановки менеджмента на предприятии; необходимость в частичной или полной реорганизации структуры предприятия; необходимость изменения технологии бизнеса в различных аспектах; сопротивление сотрудников предприятия; временное увеличение нагрузки на сотрудников во время внедрения системы; необходимость в формировании квалифицированной группы внедрения и сопровождения системы, выбор сильного руководителя группы. Кроме того, в процессе внедрения существует необходимость в реализации единой ИТ-стратегии предприятия, которая позволит адекватно сочетать развитие (создание) программной и аппаратной частей системы параллельно с комплексом работ по развитию существующей ИТ-инфраструктуры компании. Значительная часть проблем проектов внедрения обусловлена довольно типичными ошибками, которые известны, но тем не менее часто повторяются: проектирование систем без учета стратегии развития бизнеса — необходимо представлять структуру и масштабы бизнеса в перспективе как минимум на 3 года [1.1, 1.2]; нарушение принципа построения системы «сверху-вниз» и, как следствие, отсутствие информационной поддержки принятия управленческих решений на верхних уровнях управления; чрезмерное увлечение реинжинирингом бизнес-процессов и порой неоправданное их подчинение требованиям стандартной функциональности базовой ERPсистемы; кардинальная переработка базовой функциональности ERP-системы; нереалистичные ожидания вследствие неверной оценки экономической эффективности внедрения ERP-системы. В то же время накопленный опыт внедрения информационных систем свидетельствует о наличии устойчивой группы факторов успеха таких проектов [1.3], и, 6 как следствие, о возможности формирования технологии успешного управления проектом внедрения с учетом этих факторов (рис. 1.1). Рациональная организация проектов внедрения информационных систем описывается в стандартах (международных, государственных, корпоративных), которые часто называют методологиями внедрения. Рис. 1.1. Факторы успеха проекта внедрения Назначение и состав методологий внедрения Методологии внедрения обычно разрабатываются ведущими производителями информационных систем с учетом особенностей их программных продуктов, а также сферы внедрения. Положительная сторона таких стандартов — их практическая направленность. Они представляют собой глубоко проработанные, проверенные, многократно апробированные рабочие инструкции и шаблоны проектных документов. Такие стандарты обычно далеки от теоретических абстракций, ориентированы на особенности конкретных систем, содержат наилучший опыт. Но у стандартов есть и отрицательные стороны: даже методологии, предназначенные для систем, близких по классу, не взаимозаменяемы. Например, методология внедрения системы Microsoft Axapta направлена во многом на управление настройками модулей и доработками; а при внедрении функционально подобных модулей SAP или ORACLE EBS превалирует идеология бизнес-реинжиниринга, при котором организации предлагается изменять свои 7 бизнес-процессы, адаптируя их под «лучший опыт», зафиксированный в системе. В качестве наиболее известных примеров методологий можно привести следующий, далеко не исчерпывающий перечень: разработки компании Microsoft — методологии «OnTarget», «MSF (Microsoft Solutions Framework)», «Business Solutions Partner Methodology»; разработки компании SAP — методологии «Процедурная модель SAP», «ASAP (Accelerated SAP)»; разработки компании Oracle — комплекс методологий «Oracle Method». Такое разнообразие стандартов позволяет организациям выбрать на их основе рациональную стратегию и сформировать собственные процедуры внедрения, т. е. не «изобретать велосипед» и в то же время обеспечить конкурентные преимущества. Адаптация методологий к нуждам конкретного предприятия заключается не столько в переводе текстов и шаблонов документов на русский язык, сколько в корректировке подходов с учетом российских рекомендуемые стандартами условий. При этом обычно пересматриваются сроки и последовательность задач, создаются методики сбора, верификации и преобразования исходных данных, разрабатываются решения по интеграции с унаследованными системами. Для Заказчика информационной системы основными результатами использования методологии являются: В создание решения, оптимально соответствующего требованиям клиента; максимально эффективное использование ресурсов проекта; минимизация сроков и затрат на внедрение; уменьшение рисков проекта. то же время организация работы в соответствии с документально зафиксированной методологией оказывается полезной и для разработчика системы: появляется методическая база для обучения новых сотрудников стандартным методам внедрения; сокращаются внутренние расходы на организацию и реализацию проектов; улучшается взаимодействие и взаимопонимание между членами проектной повышается эффективность совместного использования ресурсов между группы; проектами, командами. 8 Несмотря на разнообразие существующих методологий, их содержание включает в себя следующие стандартные компоненты: описание состава и структуры комплекса работ проекта внедрения, правила управления таким проектом, организационную структуру команды внедрения. Структурирование комплекса работ заключается прежде всего в выделении фаз (этапов) проекта. Разбиение проекта на фазы (длительностью 3-4 месяца) обусловлено высокой сложностью проектов и значительными затратами времени на внедрение информационных систем, позволяет получить значимые результаты в более сжатые сроки и реализовать следующие преимущества в организации проекта: данные проектной документации не устаревают; после выполнения каждой фазы проекта появляется возможность уточнить или скорректировать задачи к решению на последующих фазах; снижаются проектные риски, обусловленные организационными изменениями на предприятии Заказчика в ходе проекта; оптимизируются бюджет проекта и график платежей. Состав этапов проекта и распределение работ по этапам зависит от конкретной методологии, однако можно выделить типовой состав этапов, которые в той или иной степени присутствуют во всех методологиях и определяются самой логикой внедрения. Это этапы определения проекта, обследования объекта автоматизации, анализа результатов обследования и разработки дизайна системы, создания (настройки) системы, запуска системы в эксплуатацию, сопровождения системы. Следующим шагом является выделение процессов (комплексов работ), выполняемых на различных этапах проектов. Состав и последовательность исполнения процессов определяются конкретной методологией и служат основой для планирования проекта — для построения иерархической структуры работ (см. раздел 4 «Управление интеграцией и содержанием проекта внедрения»). Таким образом, методология внедрения строится как пересечение двух различных областей знаний: специфической технологии создания продукта — информационной системы — и достаточно универсальной технологии управления проектной деятельностью (рис. 1.2). 9 Технология создания продукта Технология управления проектом Корпоративная методология внедрения Рис. 1.2. Составляющие методологии внедрения Стандарты управления проектами Организация проектной деятельности осуществляется на основе стандартов управления проектами. Эти стандарты обеспечивают концентрацию лучшей практики в области управления проектами, создают основу взаимодействия между командами проекта, формируют базу для сертификации специалистов в области проектного менеджмента, дают возможность систематизировать знания в этой специфической области. В то же время, стандарты управления проектами обычно не содержат четких определений, как необходимо выполнять те или иные действия. Стандарты определяют, ЧТО должно быть сделано для эффективного управления проектом, а КАК это должно быть сделано, определяется в корпоративных документах, разработанных на основе этих стандартов. Обычно стандарт фиксирует определения основных понятий предметной области, определяет действующих лиц управления проектами, необходимые области знаний и исполняемые процессы. Основными действующими лицами проекта являются: менеджер (руководитель) проекта (Project Manager) — лицо, отвечающее за управление проектом; спонсор (куратор) проекта (Project Sponsor) — лицо, обеспечивающее ресурсы проекта и любую административную поддержку; определяет приоритеты, обеспечивает взаимодействие с функциональными подразделениями, утверждает изменения; во внутренних проектах обычно несет ответственность за результаты проекта; 10 Заказчик (потребитель) проекта (Project Customer) — лицо внутри или вне организации, которое будет использовать результаты проекта; Руководитель функционального подразделения — направляет ресурсы в утвержденные проекты; Функциональный лидер проекта — объединяет усилия участников проекта в рамках функции или подразделения (именно с ним взаимодействует менеджер проекта); Лидер пакета работ — объединяет усилия отдельных лиц в рамках пакета работ. Содержание областей знаний является достаточно сходным в различных стандартах. В настоящей книге мы будем ориентироваться в основном на рекомендации стандарта PMBOK (Project Manadgement Body Of Knowledge — свод знаний по управлению проектами) американского института ANCI (American Standards Institute), дополняя их, при необходимости, сведениями из других стандартов и методик. В соответствии с этим стандартом управление проектами базируется на следующих областях знаний: Управление интеграцией (Project Integration Management), Управление содержанием (Project Scope Management), Управление временем (Project Time Management), Управление стоимостью (Project Cost Management), Управление персоналом (Project HR Management), Управление коммуникациями (Project Communication Management), Управление качеством (Project Quality Management), Управление рисками (Project Risk Management), Управление снабжением (Project Procurement Management). В последующих разделах книги будет детально рассматриваться деятельность по управлению проектами внедрения в рамках указанных областей знаний. С точки зрения управления, проекты внедрения информационных систем никаких принципиальных особенностей не имеют. Как правило, под термином «проект» подразумевается ограниченный по времени и доступным ресурсам организационный стратегический план для создания уникального продукта или услуги (см. таблицу 1.1). Это определение полностью соответствует представлению о задачах и организации внедрения информационной системы. Во-первых, процесс внедрения информационной системы носит временный характер, т. е. он всегда имеет определенное начало и окончание. При этом длительность 11 внедрения информационной системы может быть разной, но наступает момент, когда исчезает необходимость в проекте. Во-вторых, при внедрении информационной системы всегда учитываются особенности бизнес-процессов конкретного предприятия. Это означает, что результат внедрения — информационная система предприятия, — всегда будет отличаться от информационных систем других предприятий, т. е. будет уникальной. Наличие повторяющихся элементов информационной системы не нарушает принципиальной уникальности каждого проекта по внедрению ИС. В-третьих, для внедрения информационной системы выделяются ресурсы — конкретные специалисты. В реальной жизни количество специалистов требуемой квалификации и компетентности всегда ограничено. Поэтому имеет смысл рассмотреть общие характеристики проектной организации работ, которые окажутся полезными и при решении задач внедрения информационных систем. Таблица 1.1. Альтернативные определения проекта Определение Временное предприятие Источник (усилие), предназначенное для Руководство создания уникальных продуктов, услуг или результатов к своду знаний по управлению проектами (PMBOK Guide 2000) • Предприятие, которое характеризуется принципиальной ICB — IPMA уникальностью условий его деятельности (таких как (International Competence цели (задачи), показатели) время, и затраты отличается от и качественные Baseline — International других подобных Project Management предприятий специфической проектной организацией • Association) Предпринимаемое усилие, организующее человеческие, материальные и финансовые ресурсы в рамках уникального предмета работы, заданной спецификации, с ограничениями на затраты и время, с тем чтобы следование стандартному жизненному циклу проекта приводило к осуществлению успешных изменений, определенных посредством количественных и 12 качественных целей и задач • Уникальный набор скоординированных действий с определенным началом и завершением, осуществляемых индивидуумом или организацией для решения специфических задач с определенным расписанием, затратами и параметрами исполнения Уникальный процесс, состоящий из набора ISO/TR 10006 Guidelines взаимоувязанных и контролируемых работ с датами начала to quality in Project и окончания и предпринятый для соответствия конкретным Management требованиям, включая ограничения по времени, затратам и ресурсам Уникальная совокупность взаимосвязанных действий AIPM — Australian (работ) с определенными датами начала и окончания, Institute for PM предназначенных для успешного достижения общей цели Уникальная совокупность скоординированных действий British standard 6079(работ) с определенными точками начала и окончания, 1:2000 PM предпринятая достижения индивидуумом определенных или целей организацией с для установленными сроками, затратами и параметрами выполнения Прежде всего, как и для любых проектов, для проекта внедрения принципиально важным является его соответствие целям стратегического развития организации [1.4]. При создании информационной системы необходимо сосредоточиться на той отдаче и выгоде, которую ожидает получить ее потребитель. Если проект ориентирован на нужды Заказчика, то точкой концентрации усилий и оценкой успешности будет бизнес-отдача (businessvalue). В качестве примеров конкретных задач внедрения информационных систем управления можно привести следующие: 1. Предоставление руководству информации для анализа текущего состояния организации и принятия обоснованных управленческих решений. 2. Обеспечение прозрачности и контроля деятельности предприятия на всех уровнях. 13 3. Организация эффективного взаимодействия с контрагентами и клиентами. 4. Снижение трудоемкости процесса бюджетирования и организация бюджетного контроля расходов. 5. Сокращение объема ручной и рутинной работы сотрудников, снижение административных издержек. 6. Снижение вложений в активы, снижение затрат на перемещение материалов, сокращение сроков производства, снижение запасов полуфабрикатов собственного производства. 7. Снижение потерь рабочего времени, минимизация переналадок, повышение коэффициента готовности оборудования. 8. Оперативность и точность расчета себестоимости, возможность оперативного анализа затрат, возможность анализа причин отклонений от плана, определение наиболее рентабельных видов продукции. Второй аспект управления проектами связан с достижением поставленных в проекте целей в рамках выделенного времени и утвержденного бюджета. Эти задачи решаются за счет организации управления проектом на всех этапах его жизненного цикла. Пример модели жизненного цикла проекта, приведенный на рис. 1.3, показывает типичный состав фаз проекта и его связь с процессами проектирования информационной системы. Таким образом, можно сказать, что жизненный цикл разработки нового продукта отражает, что нужно сделать для его создания, а жизненный цикл проекта — как нужно управлять работой. 14 Формирование концепции Шлюз – принятие решения о Определение переходе на следующую фазу Разработка Разработка требований Проектирование Реализация (проектирование) Изготовление Тестирование Ввод в действие Ввод в эксплуатацию Рис. 1.3. Ступенчато-шлюзовая модель жизненного цикла проекта Управление проектами базируется на общепринятой триаде концепций [1.4]: формирование центров ответственности за исполнение проекта в целом (центров интегративной ответственности); интегральное и прогнозирующее планирование (и контроль); формирование и управление командой проекта. Первая из указанных концепций предусматривает наличие в организации определенных должностей, предполагающих ответственность за выполнение проектов. Наиболее важные роли и сферы их ответственности представлены на рис. 1.4. Каждой из указанных ролей вменяются определенные обязанности по управлению проектами. На генерального менеджера возлагается: обеспечение соответствия проектов стратегиям роста организации; предоставление ресурсов для выполнения утвержденных проектов; обеспечение применения соответствующих методик управления проектами в компании; мониторинг общего хода работ по проекту и координация с другими видами деятельности компании; 15 разрешение конфликтов, для которых не найдены решения на более низком оценка качества работы непосредственно подчиненных менеджеров. уровне; Высшее руководство Спонсор проекта Цели Ресурсы Функциональный руководитель Руководитель менеджеров проектов Корпорат ивные ст андарт ы УП Менеджер проекта Чт о делат ь Когда Насколько хорошо Функциональный лидер проекта Сколько Планирование Конт роль Кт о Лидер пакета работ Как Офис проекта Рис. 1.4. Участники проекта и их задачи Спонсор проекта: отвечает за расходование средств, инвестируемых в проект; определяет бизнес-план проекта; утверждает цели, содержание, расписание, бюджет проекта и вносимые в них изменения; издает распоряжения и приказы по проекту, назначает менеджера проекта; осуществляет мониторинг окружения проекта и информирует МП об изменениях, способных повлиять на выполнение работ; отслеживает ход выполнения проекта и формирует стратегические указания; 16 разрешает переадресованные ему конфликты; обеспечивает соответствие требованиям конечного результата проекта. Менеджер проекта: отвечает за получение желаемых результатов в рамках утвержденного бюджета и расписания проекта; обеспечивает общее планирование и контроль проекта в течение всех фаз жизненного цикла; взаимодействует с функциональными руководителями для определения объемов, сроков и стоимости (трудозатрат) работ. Функциональный руководитель подразделения, участвующего в проекте: отвечает за своевременное обеспечение всех проектов необходимыми ресурсами; объединяет требования (часто конфликтующие) всех активных проектов в подразделении; осуществляет детальное планирование работ подчиненного персонала. В большинстве случаев центральной фигурой в управлении проектом является менеджер проекта. Организация его управленческой деятельности в корне отличается от управления регулярно выполняемыми работами (см. таблицу 1.2) и это учитывается в содержании стандартов управления проектами. Таблица 1.2. Различия между проектными и функциональными менеджерами Менеджер проекта Функциональный менеджер Имеет уникальную цель в каждом проекте, Организует регулярное исполнение ряда определенную в техническом задании стабильных функций Руководит проектом, существование Руководит постоянно действующим которого ограничено во времени подразделением Управляет временной командой, возможно, Управляет относительно стабильным изменяющегося состава и двойного коллективом сотрудников подчинения: менеджеру проекта и своему функциональному руководителю Обычно в подчинении — команда Как правило, имеет в подчинении группу разнопрофильных специалистов специалистов одной или смежных 17 специальностей Может не быть специалистом в предметной Обычно разбирается в предметной области области проекта лучше всех своих подчиненных По окончании каждого проекта может Стабильно занимает свою должность оказаться «временно безработным» Карьера в основном «горизонтальная», рост Стремится сделать «вертикальную» состоит в управлении все более сложными, карьеру, занимая все более высокие посты в масштабными проектами своей функциональной сфере Главная мотивация — бонус, зависящий от Основная часть мотивации — стабильный, результатов проекта фиксированный оклад Концепция интегрального и прогнозирующего планирования означает, что планирование и контроль должны охватывать все участвующие в проекте подразделения в течение всего жизненного цикла проекта и учитывать: риски, расписание проекта, стоимость, технические аспекты создаваемого продукта. Проектная документация должна содержать комплекс взаимоувязанных планов, а процедуры контроля — их регулярную проверку. В качестве примера можно привести комплекс планов проекта, рекомендуемый для использования управления проектом внедрения в методологии MSF: И коммуникационный план; план разработки; план обучения; план мер безопасности; план тестирования; план финансирования; план развертывания; план закупок и материального обеспечения; план пилотного внедрения. последней составляющей триады концепций является организация работоспособной команды и управление этой командой. Для решения этих задач в каждом проекте предусматривается следующий комплекс работ по управлению человеческими ресурсами: планирование и подбор персонала, формирование команды, развитие команды проекта, управление командой проекта. 18 Характерные особенности проектных работ Проекты, независимо от сферы деятельности, обладают целым рядом одинаковых особенностей. Распределение затрат времени и ресурсов в проекте описывается Sобразной кривой (см. рис. 1.5), причем до 90% затрат приходится на этапы разработкиреализации. Рис. 1.5. Типовое распределение затрат времени и ресурсов при выполнении проекта Степень неопределенности оценок затрат на выполнение проекта изменяется в зависимости от этапа проекта, на котором такая оценка производится, и возможная величина погрешности сильно варьируется в зависимости от предметной области. Для проектов внедрения информационных систем можно воспользоваться «конусом неопределенности», рекомендованным для ИТ-проектов в методологии MSF [5] (см. рис. 1.6). 19 Рис. 1.6. Относительные значения погрешности в оценке параметров проекта Стоимость внесения изменений в проект экспоненциально нарастает к концу проекта (см. рис. 1.7), а значит, выполнение всех рискованных работ необходимо планировать на ранние стадии проекта. Стоимость 1000 900 800 700 600 500 400 300 200 100 0 0 5 10 15 20 25 Время, мес. Рис. 1.7. Типовой график нарастания стоимости внесения изменений в проект 20 Следующей общей для всех проектов характеристикой является их зависимость от окружения, в котором проекты исполняются. «Успех проекта зачастую определяется не столько логическим или эффективным распределением ролей, обязанностей и ресурсов, сколько созданием работоспособной структуры связей различных внутренних частей проекта с внешними участниками» [1.4]. Зачастую снижение эффективности проектов, появление трудностей в их реализации связано с тем, что их цели, организация и методы управления несовместимы или конфликтуют с ключевыми элементами окружения. Относительно ИТ-проектов можно выделить следующие элементы окружения, оказывающие на них наиболее существенное влияние: структура организации, степень ее знакомства с используемыми технологиями, конкуренция с другими проектами, местные, региональные и национальные организации, поставщики продуктов и услуг, пользователи результатов проекта. Менеджеру необходимо перед началом проекта сформировать представление об окружении, организовать взаимодействие с его элементами и отслеживать изменения окружения, происходящие в процессе исполнения проекта. Обзор окружения может осуществляться в разных формах, от случайного наблюдения до запланированного систематического обследования. Для структурированного представления информации может быть использован шаблон [1.4], показанный на рис. 1.8. 21 Действующие лица Факторы Поддающиеся оценке Социальные Поддающиеся влиянию Инфраструктурные Управляемые Проект Технологические Экономические Рис. 1.8. Шаблон документирования обзора окружения На шаблоне вся область окружения делится на секторы — сферы, влияющие на проект. Концентрическими окружностями разделяются группы элементов окружения в зависимости от возможности влияния на эти элементы со стороны проекта. В соответствующих областях шаблона размещаются обозначения субъектов и факторов, важных с точки зрения проекта. Под субъектом (или действующим лицом) понимается личность, группа, организация или учреждение, способное выполнить какое-либо действие и тем самым повлиять на проект. Примеры действующих лиц окружения для проектов внедрения информационных систем [1.6]: руководство — лица, отвечающие либо за выделение бюджета разработки, либо за бюджет организации, где система будет использоваться; ответственные за стратегию развития компании; инвесторы — лица, которые вкладывают средства в организацию, разрабатывающую или использующую систему; 22 пользователи — лица, которые непосредственно заинтересованы в возможностях или сервисах, предоставляемых системой; возможно существование таких пользователей, которые не взаимодействуют с системой напрямую, но используют результаты ее работы; обслуживающий персонал — обеспечивает эксплуатацию системы после утилизаторы — обеспечивают соблюдение требований законодательства по запуска; защите окружающей среды; обучающий персонал — организует подготовку специалистов для эксплуатации системы; покупатели — лица, которые платят за систему, но не участвуют в ее разработке и последующей эксплуатации; продавцы (маркетологи) — лица, во многом определяющие требования к системам массового спроса; эксперты по эргономике и эффективности — лица, заинтересованные в удобном и эффективном использовании системы; правительство — принимает официальные документы органов власти, регулирующие возможности использования системы; органы стандартизации — принимают стандарты (международные, национальные, корпоративные), влияющие на систему; общественное мнение — отражает географические и национальные особенности среды создания или применения системы; регулирующие органы — сертифицируют и разрешают эксплуатацию систем. Факторы — это элементы окружения, которые не могут совершать действия, но влияют на проект самим фактом своего существования. Примерами факторов являются законы, постановления, традиции, тенденции, экономические, физические или какие-то другие условия и пр. Для успешности проекта необходимо обеспечить его связи с окружением посредством организационных мероприятий и процедур управления. К организационным мероприятиям относятся: создание формальных комитетов для координации, планирования и управления проектами; включение основных участников проекта в совет директоров, в группу советников или комитеты заинтересованных 23 организаций; введение в проекте должности менеджера по взаимодействию с ключевыми фигурами окружения. В процедурах управления целесообразно предусмотреть: приглашение ключевых действующих лиц для участия в совещаниях по проекту; рассылку им копий отчетов по проекту. Работа менеджера проекта с выявленными факторами окружения предусматривает: учет влияния факторов при планировании и обосновании проекта; мониторинг изменения ключевых факторов и отражение изменений в планах проекта. Пример специальных мероприятий, направленных на обеспечение взаимосвязи проекта с его окружением, приведен в таблице 1.3. Таблица 1.3. Взаимодействие проекта с окружением Задачи управления Мероприятия, проектами 1. Определение проекта Мероприятия, направленные на направленные на действующих лиц ключевые факторы Вовлечь действующих лиц в Включить первостепенные процесс определения; если факторы в можно, использовать допущения их планирования, идеи; объяснить им суть идентифицировать проекта; определить налагаемые проблемы и ими негативные ограничения, реакции влияют на которые определение проекта 2. Организация и формирование команды Установить рабочие и формальные, Включить влияние факторов неформальные в организационную отношения с действующими структуру; сообщить членам лицами; рассматривать их команды как членов все ключевые команды факторы и прояснить их проекта, при необходимости влияние на успех проекта приглашать на совещания по проекту 24 3. Создание плана, По возможности привлечь Внести расписания и бюджета действующих лиц подготовке информацию, к имеющую отношение к планов, ключевым факторам, в расписаний и бюджетов; планы, бюджеты и удостовериться, что планы расписания отражают реальность, определяемую ключевыми действующими лицами 4. Авторизация работ и Постоянно начало исполнения информировать По факторов выполнения возникновения проекта, избежание когда операции прямых напрямую влияют на них 5. Контроль исполнения Постоянно расписания бюджета конфликтов информировать По выполнения возможности проекта, избежание когда операции прямых напрямую влияют на них во возникновения конфликтов и им включать обновлять по заранее ключевому предоставлять вести проблем действующих лиц в процесс данные оценки; и факторов Оценка хода работ и По возможности включить Периодически руководство проектом во проблем и действующих лиц о ходе мониторинг особенно 6. вести действующих лиц о ходе мониторинг особенно работ, возможности каждому фактору их в и процесс информацию об основных оценки хода работ изменениях 7. Закрытие проекта Привлечь действующих Продолжать следить лиц к за факторами и вносить планированию и операциям изменения в планы закрытия закрытия; продолжать информирование Организационная структура проекта 25 В управлении проектами важная роль отводится разработке организационной структуры проекта. Организационная структура проекта — соответствующая проекту временная организационная структура, включающая всех его участников и создаваемая для успешного управления и достижения целей проекта. Необходимость разработки организационной структуры объясняется тем, что для выполнения проекта создается команда проекта — новый временный рабочий коллектив, состоящий из специалистов различных структурных подразделений компаний со стороны Исполнителя и со стороны Заказчика. Как и для любого нового коллектива, для членов команды проекта необходимо определить проектные роли (временные должности), функции, обязанности, ответственность, полномочия и правила взаимодействия, а также организационную схему, отражающую отношения подчиненности. При этом несущественно, на какой период времени будет создаваться команда проекта — на несколько месяцев или на несколько лет. Структура проекта определяется сложностью, масштабностью разработки и внедрения ИС, количеством и специализацией членов команды проекта. В команду проекта могут включаться специалисты, как на полную, так и на частичную занятость. Если внедрение информационной системы осуществляется с привлечением сторонней организации — Исполнителя, то для успешного внедрения необходимо сформировать команду проекта не только от Исполнителя, но и от Заказчика, после чего определить допустимые взаимодействия между членами команд Исполнителя и Заказчика (кто, с кем, по каким вопросам взаимодействует), т. е. установить правила взаимодействия. При формировании организационной структуры проекта и принятии решения о подчиненности следует помнить, что управлять непосредственно более чем десятью членами команды проекта становится затруднительно. Идеальный вариант: пять-семь человек. Особо отметим, что при создании организационной структуры проекта штатное расписание компании не должно изменяться. Не следует забывать, что проект — временное мероприятие, по окончанию которого команда проекта распускается и специалисты приступают к своим функциональным обязанностям в соответствии со штатной организационной структурой компании или переходят на следующий проект, где их функции и полномочия могут быть другими. 26 Правильно сформированная организационная структура проекта обеспечит его эффективное управление, планирование, исполнение в запланированные сроки, на определенном качественном уровне. Первая задача в формировании организационной структуры проекта — решить, какой тип структуры наилучшим образом подходит для данного проекта. Различные типы структур имеют определенные преимущества. Основные типы организационных структур Функциональная организация (Functional Organization) (рис. 1.9). Иерархически выстроенная организация, в которой у каждого сотрудника есть один прямой начальник, сотрудники разделены на группы (отделы) по областям специализации. Каждая группа (отдел) управляется одним человеком, имеющим компетенцию в данной области — функциональным руководителем (руководителем отдела). Генеральный директор Линейные службы Сервисная служба Бухгалтерия Финансовая служба Отдел кадров Плановый отдел Логистика Производство Закупки Маркетинг Руководство организации Функциональные службы Рис. 1.9. Линейно-функциональная структура организации Матричная организационная организация структура, в (Matrix которой Organization) Руководитель (рис. 1.10) проекта — любая разделяет с функциональными руководителями (руководителями отделов) ответственность по заданию приоритетов и управлению работой лиц, назначенных на исполнение проекта. 27 Отличительной чертой матричной структуры является наличие у работника одновременно двух начальников. Отвечает за обеспечение сотрудников ресурсами Руководитель проекта 1 Руководитель проекта 2 Руководитель проекта 3 Руководство организацией Начальник отдела 1 Начальник отдела 2 Начальник отдела 3 Начальник отдела 4 Сотрудник 1.1 Сотрудник 2.1 Сотрудник 3.1 Сотрудник 4.1 Сотрудник 1.2 Сотрудник 2.2 Сотрудник 3.2 Сотрудник 4.1 Сотрудник1.1 Сотрудник2.2 Сотрудник3.3 Сотрудник4.2 Отвечает за выполнение проекта Рис. 1.10. Матричная структура организации Проектная организация (Projectized Organization) — любая организационная структура, в которой Руководитель проекта обладает достаточными полномочиями по установлению приоритетов, использованию ресурсов и руководству работой лиц, назначенных на исполнение проекта, а также финансовыми полномочиями в рамках бюджета проекта. Для того чтобы понять сущность различных типов организаций, рассмотрим на условном примере, как может быть построена работа по разработке и внедрению ИС при структуре организации, представленной на рис. 1.11. Основные функции отдела Программирования: программирование алгоритмов расчета, анализа данных, интеграционных решений; разработка форм отчетов, разработка экранных форм, работа с базами данных ИС. Основные функции отдела Бизнес-аналитики: разработка алгоритмов расчета, анализа данных, интеграционных решений, соответствующих бизнес-правилам, требованиям финансового учета и законодательства. 28 Основные функции отдела Консультаций и настроек ИС: настройка модулей ИС с использованием готовых алгоритмов, экранных форм и отчетов, оказание консультаций пользователям ИС. Основные функции отдела Маркетинга и продаж: продажи ИС и услуг по ее внедрению. Организация работ при функциональной структуре компании При организации внедрения ИС в соответствии с функциональной структурой (рис. 1.9), работа, как правило, происходит следующим образом: 1. После продажи отделом маркетинга и продаж услуг на внедрение информационной системы Руководитель компании проводит совещание с участием руководителей отделов Программирования, Бизнес-аналитики, Консультаций и настроек ИС. Руководитель компании доводит до участников совещания содержание и сроки работ по внедрению, в соответствии с условиями договора. Руководители отделов получают задание организовать работу по выполнению условий договора в рамках компетенций отдела. 2. Руководители отделов распределяют работу между сотрудниками отделов, контролируют качество и сроки ее выполнения, взаимодействуют с руководителями других отделов по смежным работам и по приему/передаче результатов работ из одного отдела другому. Например, отделом бизнес-аналитики был разработан в соответствии с Трудовым Кодексом РФ алгоритм расчета оплаты труда за ночные часы и праздничные дни. Разработанные алгоритмы передаются в отдел Программирования, где осуществляется программирование алгоритмов расчета. После завершения работ по программированию консультанты отдела Консультаций и настроек ИС проводят общую настройку системы с использованием разработанных алгоритмов расчета. 29 Руководитель компании Руководитель отдела Программирования Программист 1 Программист N Руководитель отдела Бизнес-аналитики Бизнес-аналитик по финансам Бизнес-аналитик по логистике Бизнес-аналитик по персоналу и заработной плате Руководитель отдела консультаций и настроек ИС Консультант по модулям системы Финансы Консультант по модулям системы Логистика Консультант по модулям системы Кадры. Заработная плата Отдел маркетинга и продаж ... Рис. 1.11. Пример организационной структуры консалтинговой компании Каждый отдел одновременно может работать по нескольким договорам в рамках своих компетенций. При организации работ проекта по функциональной структуре каждый руководитель отдела отвечает за работы своего отдела и не отвечает за выполнение результатов по проекту-договору в целом. Отсутствие выделенного специалиста, ответственного за итоговый результат, является главным недостатком функциональной структуры. Этот недостаток проявляется тем сильнее, чем большее количество проектовдоговоров одновременно выполняются функциональным подразделением и чем больше функциональных подразделений участвует в выполнении проектных работ. Внедрение ИС при таком подходе может происходить как в известной миниатюре артиста А. Райкина — «за рукава костюма отвечает один, за пуговицы — другой, за воротник — третий и т. д., а за костюм никто не отвечает и виновного за брак не найти…». 30 При построении системы управления проектной деятельностью функциональную структуру целесообразно использовать, если работы по проекту могут быть выполнены одним функциональным подразделением (отделом). Рассмотрим на том же условном примере организацию работ проекта, но уже не по функциональной, а по матричной структуре (рис. 1.10). Руководитель компании при матричной организации проектных работ назначает ответственного за достижение конечных целей договора и выполнение условий договора — Руководителя проекта (менеджера проекта). Руководителем проекта при матричной структуре может быть назначен один из руководителей отделов. Если нет особых требований и условий, то Руководителем проекта назначается Руководитель того отдела, который выполняет в данном проекте больший объем работ. При этом с Руководителя отдела, назначенного Руководителем проекта, не снимаются функции по управлению отделом. Другими словами, Руководитель проекта при матричной организации может быть частично задействован на проекте (не на 100%), и продолжать выполнять свои функциональные обязанности. Руководитель проекта анализирует содержание, объем и сроки работ, на основании чего определяет, сколько и каких специалистов нужно для выполнения проекта. Руководитель проекта делает запрос Руководителям отделов на выделение специалистов с указанием их квалификации и процента занятости. В зависимости от объема той или иной работы по проекту, специалисты могут быть выделены как на полную, так и на частичную занятость. После того как специалисты выделены, Руководитель проекта формирует для них задания и координирует работы. Задания Руководитель проекта согласовывает с Руководителем отдела (функциональным руководителем). У выделенного на проектные работы специалиста при матричной организации работ два руководителя — Руководитель отдела и Руководитель проекта. Руководитель проекта, как было сказано выше, отвечает за конечные цели и результат, а Руководитель отдела (функциональный руководитель) несет ответственность только за промежуточный результат в рамках компетенций подразделения (отдела). Руководители проектов могут принимать решения только по организационным вопросам, функциональные руководители — по техническим (предметным) вопросам. Достоинство матричной структуры — наличие ответственного за достижение целей проекта, недостаток — два руководителя у одного специалиста (консультанта), что часто приводит к межличностным конфликтам. При возникновении конфликта ресурсов проблема эскалируется вверх по иерархической структуре. 31 При матричной структуре организации проектных работ Руководитель проекта может быть наделен различной степенью полномочий. В зависимости от степени полномочий Руководителя проекта выделяют слабую, сбалансированную и сильную матричную структуру (таблица 1.4). Организация работ при проектной структуре компании При проектной организации работ, так же как и при матричной, для управления работами назначается Руководитель проекта, но занятость его на проекте не частичная, а полная. Специалисты, выделенные для выполнения проектных работ, подчиняются только Руководителю проекта до завершения проектных работ. Руководители отделов (функциональных подразделений), выделивших специалистов на проектные работы, не несут ответственность за качество их работы, в отличие от матричной структуры организации. Исходя из того, что при проектной структуре Руководитель проекта на 100% занят управлением проектом, напрашивается вопрос: а найдется ли такой Руководитель отдела или другой специалист с навыками управления, который бы на время проекта согласился отказаться от своей должности? Ведь для него возникает риск по окончанию проекта оказаться «не у дел». Решение подобной проблемы найдено в том, что в проектных структурах введена специальная должность — Руководитель проекта. В ряде организаций созданы отделы/департаменты Руководителей проектов, и только из их числа назначаются Руководители проектов. Таким образом, основное отличие проектной структуры компании от матричной — в наличии специально выделенной группы специалистов для управления проектами. Руководитель проекта назначается только из этой группы (отдела, департамента), в проекте он занят на 100% и наделен всеми полномочиями по привлечению и управлению ресурсами, принятию управленческих решений, в том числе и по финансовым вопросам в рамках установленного бюджета. Таблица 1.4. Управление проектами в различных структурах Структура организации Характеристика проекта Функциональн ая Матричная Слабая Сбаланси- Проектная Сильная рованная Полномочия руководителя Нет От От высоких Ограничендо умеренные умеренных ные до высоких абсолютных 32 проекта Занятость руководителя проекта частичная Нет полная полная полная Критерии выбора организационной структуры проекта, отвечающей целям и условиям осуществления проектов в конкретной компании, представлены в таблице 1.5. Таблица 1.5. Критерии выбора организационной структуры проекта Критерий Функциональная Матрична выбора Проектная я Решение проекта стандартное сложное новое Сложность низкая средняя высокая Продолжительность короткая средняя большая Масштаб малый средний крупный Важность не очень важный средней важности важный Рекомендации по выбору организационной структуры: Масштабные, долгосрочные и дорогостоящие проекты обычно требуют проектной структуры либо сбалансированной и сильной матричной структуры. Мелкими, краткосрочными и малозатратными проектами можно управлять с помощью функциональной или слабой матричной структуры. Матричная структура является оптимальной для большинства проектов, а также хорошим компромиссом между функциональной и проектной структурами. Организационная схема проекта После выбора организационной структуры проекта Руководитель проекта должен определить организационную схему, в которой будут отражены взаимосвязи команды проекта, отношения подчиненности. 33 Пример организационной схемы проекта, состоящей из команды Исполнителя и Заказчика, приведен на рис. 1.12. Куратор проекта (Спонсор) со стороны Заказчика <ФИО> Куратор проекта (Спонсор) со стороны Исполнителя <ФИО> Управление проектом Заказчик: Руководитель проекта <ФИО> Команда управления проектом Исполнитель: Руководитель проекта <ФИО> Команда управления проектом : Проектная группа Заказчика Проектная группа Исполнителя Специалисты Заказчика с необходимыми в рамках проекта компетенциями Специалисты Исполнителя с необходимыми в рамках проекта компетенциями Рис. 1.12. Пример организационной схемы проекта В организационной схеме проекта с участием двух команд — команды Исполнителя и команды Заказчика — должны быть предусмотрены как формальные, так и неформальные организационные взаимодействия. Формальные взаимодействия всегда обеспечиваются официальными документами, такими как протоколы совещаний, служебные записки, приказы, распоряжения и т. д. Неформальные взаимодействия не должны обеспечиваться документально. Взаимодействия по вертикали управления внутри одной команды: Куратор (Спонсор) проекта — Руководитель проекта — Команда проекта — должны быть формальными и поддерживаться официальными документами. Взаимодействия Руководителей проекта со стороны Заказчика и Исполнителя также должны оформляться официальными документами. Допускаются неформальные взаимодействия между Кураторами проекта и членами команд проекта от Заказчика и Исполнителя (рис. 1.13). 34 Заказчик Куратор проекта (Спонсор) Руководитель проекта Члены Команды проекта Исполнитель Неформальное взаимодействие Формальное взаимодействие Неформальное взаимодействие Куратор проекта (Спонсор) Руководитель проекта Члены Команды проекта Рис. 1.13. Пример организации формальных и неформальных взаимодействий 35 • Лекция 2. СОДЕРЖАНИЕ ПРОЕКТОВ ВНЕДРЕНИЯ ИС В РАЗЛИЧНЫХ МЕТОДОЛОГИЯХ Этапы проектов внедрения в методологиях On Target, Microsoft Business Solutions Partner Methodology, OneMethodology, Application Implementation Method (AIM). Цели и содержание этапов внедрения. Корпоративная методология внедрения. Ключевые слова: методология внедрения ИС, этап проекта внедрения ИС, фаза проекта внедрения ИС, процессы проекта внедрения ИС, подготовка проекта, анализ, дизайн, разработка, тестирование, опытная эксплуатация, диагностика, конфигурирование, пилотный проект. Как уже отмечалось выше, методологии внедрения информационных систем являются источником информации для разработки иерархической структуры проекта внедрения и иерархической структуры работ проекта. Состав работ (процессов) и последовательность их исполнения в значительной мере определяются целями проекта внедрения, используемым программным обеспечением, особенностями автоматизируемой сферы деятельности, организационной структурой объекта автоматизации, принятой у разработчика организацией работы и пр. В настоящем разделе мы рассмотрим особенности отдельных методологий внедрения: их цели, предусмотренные этапы, состав и взаимосвязи работ. Методологии внедрения компании Microsoft Для поддержки внедрения систем группы Microsoft Business Solutions (Microsoft Dynamics NAV, Microsoft Dynamics AX, Microsoft CRM) компанией Microsoft разработан ряд методологий: On Target, Microsoft Business Solutions Partner Methodology, Microsoft Dynamics Sure Step. Все они поддерживаются специализированными программными средствами и шаблонами проектной документации, которые не являются общедоступными и предоставляются только официальным партнерам Microsoft. Наиболее старая версия — методология On Target — ориентирована главным образом на удовлетворение требований, сформулированных Заказчиком. Процесс внедрения делится на шесть этапов: подготовка проекта, анализ, дизайн, разработка и 36 тестирование, развертывание, опытная эксплуатация. Задачи этапов и выполняемые работы приведены в таблице 2.1. Таблица 2.1. Характеристика этапов внедрения по методологии On Target Этап проекта Цели этапа Выполняемые работы (пакеты работ) Подготовка Разработать проектную Предварительное планирование проекта. проекта документацию. Разработка проектных процедур. Сформировать команду Формирование Рабочей группы Проекта. проекта Разработка и утверждение Устава Проекта. Разработка спецификации на следующую стадию Анализ Подготовить команду Обучение Рабочей группы Заказчика проекта. (ключевые пользователи, разработчики и Разработать администраторы). функциональные требования Анализ бизнес-процессов Заказчика. к системе Подготовка и утверждение функциональных требований к системе. Подготовка Плана и Бюджета Проекта. Разработка спецификации на следующую стадию Дизайн Разработать технические Подготовка и утверждение Технического требования к системе. задания. Разработать принципы Разработка и согласование Дизайна реализации требований решения (реализация функциональных требований в системе). Детальное описание системных модификаций и интерфейсов с внешними программами. Уточнение Плана и Бюджета Проекта. Разработка спецификации на следующую стадию 37 Разработка и Создать программный Разработка и тестирование тестирование продукт дополнительной функциональности. Проверить Разработка и утверждение работоспособность дополнительных интерфейсов. продукта Разработка программы тестирования модификаций и интерфейсов. Выполнение процедур тестирования модификаций и интерфейсов. Разработка спецификации на следующую стадию Развертывание Установить систему у Заказчика Развертывание (инсталляция) системы на рабочие места конечных пользователей. Настройка прав и уровней доступа пользователей. Разработка процедур переноса сальдо и операций. Разработка процедур верификации начальных данных и операций. Подготовка пользовательских инструкций. Обучение конечных пользователей. Разработка спецификации на следующую стадию Опытная Запустить систему в Перенос начальных сальдо и операций. эксплуатация эксплуатацию. Выполнение процедур верификации Осуществить сдачу-приемку начальных данных. проекта Запуск системы в эксплуатацию. Опытная эксплуатация. Приемка В последующих версиях методологии — Microsoft Business Solutions Partner Methodology, Microsoft Dynamics Sure Step — основной акцент делается на нуждах бизнеса Заказчика, которому, в конечном итоге, необходимо решение для эффективной 38 работы бизнеса: система управления предприятием, обеспечивающая достижение его целей. Результат проекта, согласно MBS Partner Methodology, — это работающее решение для бизнеса Заказчика, а не простая настройка программного продукта. Использование в процессе внедрения этой методологии позволяет обеспечить высокую эффективность проекта для Заказчика и реальное достижение тех целей внедрения, ради которых Заказчик и начал проект. Методология обеспечивает регулярный контроль хода проекта на всех этапах, что направлено на снижение проектных рисков. Таким образом, цели MBS Partner Methodology оказываются значительно шире, чем в предыдущей методологии, и включают в себя: создание решения, оптимально соответствующего бизнес-потребностям максимально эффективное использование ресурсов; минимизацию сроков и затрат на внедрение; уменьшение рисков компании клиента. клиента; Состав этапов проекта внедрения отличается от предыдущей версии методологии, как по названиям, так и по выполняемым работам. MBS Partner Methodology On Target 1. Диагностика 1. Подготовка проекта 2. Анализ 2. Анализ 3. Дизайн 3. Дизайн 4. Разработка и тестирование 4. Разработка и тестирование 5. Развертывание 5. Развертывание 6. Начальное сопровождение 6. Опытная эксплуатация Содержание этапов проекта представлено в таблице 2.2. В рамках (ориентированного данной на методологии бизнес-пользователя) вводятся и понятия детального концептуального (ориентированного на разработчика) дизайна системы, что обеспечивает последовательность и преемственность в формировании пользовательских и системных требований к решению. Появляются требования о выделении отдельной среды для разработки программного продукта, среды для тестирования, рабочей среды для интеграции результатов в рабочую систему. 39 Таблица 2.2. Характеристика этапов внедрения по методологии MBS Partner Methodology Этап проекта Цели этапа Выполняемые работы (пакеты работ) Диагностика Анализ и описание Организация рабочей группы бизнес-процессов. сотрудников Заказчика для проведения Выявление основных диагностики. потребностей бизнеса. Сбор предварительной информации. Оценка функциональной Обследование и описание структуры применимости базового предприятия, бизнес-процессов, программного продукта. основных целей, потребностей Определение ожидаемых и ожиданий Заказчика. результатов, сроков, Согласование результатов границ и бюджета обследования, установка критериев проекта оценки результатов проекта. Подготовка отчета о Диагностике. Предложения по разработке и внедрению решения Анализ Организация проекта. Открытие проекта, формирование Детальное обследование Управляющего комитета и проектной и описание предприятия группы. Заказчика. Подготовка плана проекта, Устава Изучение требований проекта, порядка отчетности, к внедряемому решению. управления изменениями и рисками, Документирование сдачи-приемки проекта. функциональных Проведение тренинга для сотрудников требований, создание клиента по базовой функциональности полного перечня продукта. требуемых модификаций Уточнение и детализация требований и доработок к решению бизнес-процессов Заказчика. функциональности Выработка решений относительно изменения существующих бизнеспроцессов, модификации функциональности продукта, 40 построения интерфейсов с внешними системами. Подготовка Спецификации функциональных требований. Согласование и утверждение функциональных требований, уточнение параметров проекта Дизайн Описание создаваемого Разработка Концептуального дизайна решения, детальное (Технического задания), описывающего проектирование в терминах предметной области модификаций концепцию реализации решения, и доработок изменения функциональности и бизнес- функциональности. процессов, требования к отчетности. Планирование изменений Согласование и утверждение бизнес-процессов. Концептуального дизайна Заказчиком Уточнение подходов проекта. к разработке Разработка Детального дизайна и испытаниям (Программного дизайна), проектируемого решения описывающего в терминах системы предполагаемые модификации функциональности, интерфейсы с внешними системами, порядок тестирования разработки, порядок приемки работ. Согласование и утверждение Детального дизайна. Планирование порядка, сроков и ресурсов для разработки и контроля качества. Уточнение параметров последующих стадий Разработка и Реализация и первичное Настройка среды для разработки, среды 41 тестирование тестирование для тестирования, рабочей среды для модификаций интеграции результатов в рабочую и доработок систему. функциональности. Реализация модификаций Установка и настройка и интерфейсов, первоначальное системы. тестирование разработчиками. Планирование Передача результатов разработки и проведение испытаний. Заказчику для тестирования, Доработка решения исправление обнаруженных ошибок, по результатам корректировка требований, повторная испытаний реализация и тестирование. Комплексное тестирование Заказчиком, исправление ошибок и корректировка требований. Установка результатов разработки в рабочую среду, настройка системы, перенос основных справочников и сальдо. Проведение финальных испытаний и подготовка к сдаче-приемке Развертывание Подготовка и настройка Проведение официальной сдачи проекта рабочей системы. Заказчику. Разработка Оценка достижения целей проекта пользовательской и критериев успеха. документации. Планирование запуска в промышленную Тренинг конечных эксплуатацию. пользователей. Подготовка системы к запуску, Планирование и запуск контроль готовности, заведение в рабочую эксплуатацию. актуальных данных. Сдача-приемка проекта Организация и проведение тренинга для конечных пользователей. Запуск ежедневной обработки в новой 42 системе операций. Осуществление первоначальной поддержки специалистами партнера промышленной эксплуатации системы. Официальное завершение проекта, оценка проекта Заказчиком Начальное Сопровождение Осуществление ежедневной поддержки сопровождение функционирования работы Заказчика с системой системы в режиме (по телефону, электронной почте, рабочей эксплуатации. с выездом специалистов на место). Устранение выявленных Периодические обновления системы, несоответствий. связанные с выходом новых версий, Переход к режиму изменениями законодательства, работы Заказчика развитием технологий. в рамках контракта Проведение периодической оценки на регулярное соответствия решения требованиям сопровождение Заказчика, наличия потребностей в изменении и развитии решения. Планирование и организация новых проектов Методология внедрения OneMethodology Методология OneMethodology разработана компанией PeopleSoft (теперь входящей в состав Oracle) для внедрения информационных систем линейки J.D. Edwards. Методология направлена на достижение следующих целей: Обеспечить согласованность иерархии целей и задач проекта, его временных границ и ожидаемых результатов. Определить требования к проектным командам с обеих сторон, а также порядок их взаимодействия. Учесть приоритетность проводимых работ и разделение рисков/ ответственности с фиксацией ролей Исполнителя и Заказчика. 43 Обеспечить реализацию требований к системе согласно составу задач и описанию бизнес-процедур. Обеспечить безболезненный переход к работе в новом информационном окружении. Состав этапов проекта внедрения существенно отличается от рассмотренных методологий. MBS Partner Methodology On Target OneMethodology 1. Диагностика 1. Подготовка проекта 1. Рамки внедрения 2. Анализ 2. Анализ 2. Модель 3. Дизайн 3. Дизайн 3. Конфигурирование 4. Разработка и 4. Разработка и 4. Запуск в эксплуатацию тестирование тестирование 5. Развертывание 5. Развертывание 6. Начальное 6. Опытная сопровождение 5. Развитие эксплуатация Содержание работ по этапам проекта внедрения представлено в таблице 2.3. Таблица 2.3. Характеристика этапов внедрения по методологии OneMethodology. Этап проекта Цели этапа Рамки внедрения Определение целей и Определение функциональных целей: рамок проекта Выполняемые работы (пакеты работ) определение целей внедрения системы управления и преимуществ, которые получит Заказчик в результате внедрения, предварительная оценка эффективности внедрения системы; определение и описание автоматизируемых бизнес-процессов и последовательности автоматизации; определение организационных рамок проекта (подразделений, которые будут участвовать в автоматизируемых бизнес-процессах) 44 формирование проектной группы Заказчика и описание ее задач. Разработка технологической архитектуры: архитектуры приложения, конфигурации сети, конфигурации оборудования. Конвертация данных: определение перечня данных, которые должны быть в системе, определение формата ввода этих данных, определение возможности автоматической конвертации. Интерфейсы с внешними программами: определение состава программ, с которыми будет производиться обмен данными, определение механизмов взаимодействия Модель Проектирование Общий обзор и планирование: будущей системы и описание текущего состояния компании с ее будущих бизнес- бизнес-процессами и планирование процессов мероприятий по моделированию будущих бизнес-процессов, сбору и подготовке исходных данных. Моделирование бизнес-процессов: описание бизнес-процессов и согласование разработанных моделей, определение требований бизнес-процессов к информационной системе. Анализ недостающей функциональности: анализ соответствия приложений потребностям бизнеса, определение набора требований, которые 45 необходимо реализовать с помощью дополнительной разработки либо вообще невозможно реализовать. Планирование доработок ПО: составляется план разработки дополнительного программного обеспечения, оценивается объем и длительность этих работ, затраты; анализ альтернативных вариантов Конфигурирование Выполнение Обучение проектной группы: пилотного проекта и Обучение участников проектной команды развертывание Заказчика функциям и процедурам системы информационной системы и базовым навыкам работы с ней. Прогонка по системе (Solution Walktrough): настройка пилотного проекта, тестирование на ограниченном массиве исходных данных компании Заказчика. Ввод исходных данных: ввод исходных данных по подразделениям компании согласно выбранным бизнес-процессам. Конфигурирование программного обеспечения: развертывание информационной системы для всех пользователей. Разработка пользовательской документации: формирование инструкций пользователей и описаний системы. Формирование прав доступа: настройка прав доступа групп пользователей к информации и обеспечение безопасности данных системы 46 Интеграция: объединение модулей пилотного проекта с внешними программами, которые мы определили на этапе планирования Запуск в Запуск системы в Тестирование рабочей конфигурации: эксплуатацию опытную тестирование настроенной версии с эксплуатацию введенными в нее данными и сравнение их с данными текущих систем. Тренинг (обучение) конечных пользователей. Настройка производительности системы и распределение задач по серверам. Запуск системы в опытную эксплуатацию Развитие Оптимизация, Оценка работоспособности недостающей совершенствование функциональности (Gap analysis системы workshop): оценка работоспособности доработанного функционала и соответствия достижению целей, поставленных перед проектом. Оптимизация бизнес-процессов: изменение бизнес-процессов для обеспечения достижения поставленных целей. Передача системы: передача ИС в промышленную эксплуатацию Методология внедрения компании Oracle Методика компании Oracle внедрения готовых приложений пакета Oracle E-Business Suite, называемая Application Implementation Method (AIM), является составной частью методического комплекса Oracle Method, который охватывает различные аспекты развития ИТ-инфраструктуры компании. Методология Oracle AIM представляет собой детальное 47 описание задач, выполняемых в ходе проекта, с указанием последовательности их выполнения и ответственных ролей проектной группы [2.1]. Общая схема исполнения проекта согласно AIM описывается следующей последовательностью действий: 1. Строится грубая модель явления. 2. Выявляются детальные требования к разным аспектам явления. 3. Модель и детальные требования отображаются в приложение (приложение настраивается и демонстрируется). 4. Если какие-то аспекты модели или требований не реализуются приложением, то формируется подход к их реализации. 5. Стоимость реализации новых возможностей приложения оценивается, и если она «слишком» велика, то происходит возврат к перестройке модели или изменение требований. 6. Если стоимость реализации новых возможностей оправдана, то новые компоненты приложения разрабатываются (и интегрируются в приложение). 7. Составляются инструкции по использованию приложения, объединяющие стандартные и новые возможности приложения и базирующиеся на модели явления и на детальных требованиях к нему. 8. Новая модель внедряется в жизнь. Работы, выполняемые для решения этих задач, по принципу общности результатов сгруппированы в процессы. Проект делится на шесть фаз (см. рис. 2.1). Основные цели, которые должны быть достигнуты в соответствующих фазах проекта В фазе Определение сформулированы совокупные бизнес-требования Заказчика. Впоследствии они могут уточняться и видоизменяться в ходе отображения на функциональность Oracle E-Business Suite, но появления новых бизнес-требований не происходит. В фазе Анализ операций зафиксированы будущие бизнес-процессы и определено, как они будут реализованы с помощью Oracle E-Business Suite; установлено, какие бизнес-требования не могут быть удовлетворены с помощью стандартной функциональности и какая дополнительная разработка необходима. 48 В фазе Дизайн решения получены детальные спецификации для дополнительной разработки (функциональный и технический дизайн) и разработаны сценарии тестирования. В фазе Разработка завершены все дополнительные разработки, проведены приемочные тесты, разработана пользовательская документация для эксплуатации решения. В фазе Переход завершено обучение конечных пользователей, проведена конвертация данных, система введена в эксплуатацию. В фазе Эксплуатация — обеспечение поддержки Заказчика в работе с системой; устранение выявленных недостатков в работе системы. Определение Анализ Дизайн- операций решения Разработка Переход Эксплуатация Определение бизнестребований Отображение бизнестребований Разработка архитектуры Разработка дополнительной функциональности Конвертация данных Документирование Тестирование функциональности Тестирование производительности Обучение Ввод в эксплуатацию Рис. 2.1. Организация проекта внедрения согласно AIM Каждый из выделенных процессов подразумевает выполнение определенного комплекса работ. Определение бизнес-требований (RD). Результатом выполнения задач, входящих в данный процесс, является описание требований Заказчика к развертываемой 49 системе. В ходе этого процесса создаются детальные описания выполнения бизнеспроцессов Заказчика в заданной области автоматизации (модели «как есть»). Затем разрабатываются модели бизнес-процессов Заказчика, которые будут реализованы после развертывания системы (модели «как должно быть»). Последние затем детализируются до уровня конкретных функций, выполняемых системой для каждого элементарного шага бизнес-процесса. Отображение бизнес-требований (BR). В ходе выполнения задач этого процесса выясняется, какая функциональность Oracle E-Business Suite и каким образом может применяться для реализации необходимых Заказчику функциональных возможностей информационной системы. Окончательно определяются бизнес-процессы «как должно быть» и состав используемой в системе информации. Фиксируются значения параметров настройки программных модулей Oracle E-Business Suite и перечень необходимых доработок. Разработка архитектуры (TA). В ходе этого процесса происходит построение технической архитектуры, необходимой для работы системы, а также определяются значения ключевых параметров настройки Oracle E-Business Suite, касающихся архитектуры. Разработка дополнительной функциональности (MD). В рамках этого процесса разрабатывается программное обеспечение, которое необходимо для реализации функциональности, отсутствующей в Oracle E-Business Suit. Конвертация данных (CV). Процесс охватывает задачи, связанные с переносом данных из унаследованных систем в новую. Выявляются объекты, содержащие необходимые данные, определяются методы преобразования и загрузки этих данных в систему. Разрабатывается вспомогательное программное обеспечение. Документирование (DO). В этом процессе создается документация на Тестирование функциональности (TE). На основе бизнес-требований систему. разрабатываются сценарии тестирования и проводится проверка реализации этих требований в системе. Тестирование производительности (PT). Проверяется работоспособность системы в условиях реальной нагрузки (по количеству пользователей, документов, транзакций и пр.). 50 Обучение (TR). Процесс включает в себя две основные задачи: обучение проектной группы (с него начинается проект по внедрению) и обучение конечных пользователей (им проект заканчивается). Ввод в эксплуатацию (PM). В ходе этого процесса рассматриваются все вопросы, связанные с организацией промышленной эксплуатации системы и ее сопровождением. Процессы в AIM формируются из задач. Задача — элементарный (неделимый) объем работ, который обязательно заканчивается формально фиксируемым (документируемым) результатом. Если результат естественным образом в ходе выполнения задачи сформирован в электронной форме (например, выполнены настройки программного модуля), то он должен быть оформлен соответствующим документом, согласован и утвержден (обычно в бумажной форме). Если результатом задачи является выполненная работа, то он документируется в виде акта. Выполнение задачи дает результат либо полезный для целей проекта сам по себе, либо используемый для выполнения (в качестве входа) другой задачи. Задачи в AIM обозначаются двумя буквами (обозначение процесса) и двумя-тремя цифрами через точку. В методологии приводится описание типовых ролей, которые исполняются участниками проекта при выполнении задач. Описание выполняемых работ заключается в формировании цепочек задач, которые необходимо выполнить для достижения целей проекта. Внедрение готового приложения заключается в одновременном согласовании возможностей приложения и организации исполнения автоматизируемых бизнес- процессов. Это приводит к необходимости настройки (доработки) приложения и модификации бизнес-процессов. Рекомендуемая последовательность действий определяется следующей цепочкой задач: RD.020 — RD.030 — RD.070 — BR.020 — BR.080 — MD.020 — MD.060 — DO.070 — TE.110 — PM.050 — CV.140 — PM.080, где RD.020 — изучение существующих бизнес-процессов; RD.030 — моделирование будущих бизнес-процессов; RD.070 — выявление детальных требований к будущим бизнес-процессам; BR.020 — отображение бизнес-процессов в функциональность приложения; BR.080 — тестирование принятых решений; 51 MD.020 — оценка решений по доработке функциональности приложения; MD.060 — дизайн расширений функциональности приложения; DO.070 — разработка инструкций для пользователя; TE.110 PM.050 — установка приложения на систему периода эксплуатации; CV.140 — ввод начальных данных; PM.080 — запуск новой системы. — тестирование приложения; Пример корпоративной методологии внедрения В настоящем разделе рассмотрен ряд примеров достаточно интенсивно применяемых методологий внедрения информационных систем. Следует учитывать, что в «чистом» виде эти методологии используются весьма редко. Обычно на их основе компаниями создаются свои внутренние, корпоративные методики, которые концентрируют опыт и особенности работы компании. Поэтому корпоративные методики рассматриваются как разновидность коммерческого продукта компании, и доступ к их содержанию ограничен. В качестве примера можно привести краткое описание одной из корпоративных методик внедрения информационных систем. Проекты внедрения включают в себя шесть этапов: Подготовка проекта. Анализ операций. Дизайн системы. Построение системы. Переход. Эксплуатация. Цели и задачи этапов приведены в таблице 2.4. Таблица 2.4. Характеристика этапов внедрения корпоративной методологии Этап проекта Цели этапа Подготовка Формирование проекта проектных Выполняемые работы (пакеты работ) • Организовать проект Сформулировать ожидаемые результаты 52 документов и проекта команды проекта Создать инфраструктуру проекта Построить команду внедрения • Создать модель автоматизации Определить финансовую и операционную структуры компании Определить текущие бизнес-процессы и учетные процедуры • Создать детальный план проекта Результаты: Общее описание деятельности Анализ текущих бизнес-процессов Модель управленческого планирования и учета Предварительный концептуальный дизайн системы Обученная команда внедрения Детальный план проекта внедрения Анализ операций Оценка специфики и • Анализ бизнес-процессов создание детального Сбор информации о бизнес-процессах рабочего плана Разработка модели для каждого бизнес- проекта процесса Внесение в существующие бизнес-процессы изменений и дополнений, необходимых для соответствия модели системы • Разработка требований к оборудованию, программному обеспечению и коммуникациям • Определение задания на дополнительные разработки в системе • Разработка дополнительных моделей Разработка моделей тестирования 53 Разработка модели перехода на новую систему Результаты: Утвержденная модель будущих процессов Анализ реализации процессов в системе Анализ достаточности структуры базы данных Концептуальный дизайн системы Требования к изменению или расширению функциональности системы Дизайн системы Проектирование системы • Преобразование бизнес-процессов Определение сценариев работы в системе Проектирование параметров системы Подготовка первой версии рабочих инструкций • Разработка детальных схем дополнительных разработок • Разработка материалов для обучения • «Техническое» проектирование системы Проектирование архитектуры ПО, Проектирование системы безопасности, Определение требований к оборудованию, Проектирование организации базы данных • Разработка средств конвертации данных • Подготовка инфраструктуры тестирования системы Результаты: Описание настройки системы Техническое задание на разработку модулей системы 54 Описание соответствия данных существующей системы с данными системы Сценарии бизнес-тестирования системы Сценарии тестирования интеграции с другими системами План обучения пользователей Построение Создание рабочей системы версии системы • Разработка дополнительного программного обеспечения Функциональное расширение модулей и базы данных Разработка интерфейсов с существующими системами Разработка программ конвертации данных • Тестирование Работоспособности модулей и системы в целом в соответствии с требованиями средств конвертации данных интерфейсов Производительности системы • Разработка документации для пользователей, системных администраторов и технической поддержки • Разработка и тестирование процедур инсталляции Результаты: Установлена рабочая версия системы Настроены параметры системы Проведена тестовая конвертация данных Созданы инструкции для пользователей Проведено бизнес-тестирование системы 55 Проведено тестирование интеграции системы с другими системами План перехода на новую систему Переход Запуск системы в • эксплуатацию Установка системы конвертации данных, загрузка и проверка данных в системе • Обучение пользователей • Подготовка рабочего пространства в системе • Окончательная настройка системы • Организация поддержки системы • Обеспечение нормальной работы пользователей • Определение статуса готовности системы • Переход к эксплуатации системы Результаты: Конвертированные и проверенные данные Результаты окончательного тестирования Подготовленные пользователи Рабочая система Инфраструктура поддержки системы Эксплуатация Поддержка и • Начало эксплуатации системы развитие системы • Аудит системы • Измерение производительности • Прекращение использование старой системы • Поддержка системы • Определение новых направлений Результаты: 56 Работающая система Результаты проверки эффективности использования системы Рекомендации по дальнейшему развитию системы Дополнительно следует отметить, что в рассмотренных методологиях процедуры управления проектом присутствуют в усеченном варианте. Полная технология управления проектами рассматривается в последующих разделах книги. • 57 Лекция 3. УНИФИЦИРОВАННАЯ МОДЕЛЬ ОРГАНИЗАЦИИ ВНЕДРЕНИЯ РЕШЕНИЙ В МЕТОДОЛОГИИ MICROSOFT SOLUTIONS FRAMEWORK (MSF) Понятие «ИТ-решение». Модель процессов MSF. Фазы и вехи проекта внедрения. Модель команды проекта. Ролевые кластеры команды проекта. Масштабирование проектной команды. Организация исполнения проекта. Ключевые слова: Microsoft Solutions Framework (MSF), ИТ-решение, фаза проекта, веха проекта, главная веха, промежуточная веха, команда проекта, ролевой кластер, ролевой кластер «Управление продуктом», ролевой кластер «Управление программой», ролевой кластер «Разработка», ролевой кластер «Тестирование», ролевой кластер «Удовлетворение потребителя», ролевой кластер «Управление выпуском», масштабирование проектной команды, функциональная группа, группы направлений. Рассмотренные в предыдущем разделе методологии ориентированы на внедрение готовых информационных систем, построенных на базе определенных программных продуктов. В отличие от них методология Microsoft Solutions Framework (MSF) носит универсальный характер и может использоваться для внедрения произвольной разрабатываемой в процессе проекта системы. Особенностью этой методологии является глубокая проработка различных аспектов организации проекта внедрения (определение этапов и контрольных точек проекта, состава команды проекта, распределения задач и пр.), что может оказаться весьма полезным при проектировании собственных корпоративных процедур управления проектом. Состав работ проекта — модель процессов MSF Модель процессов MSF отражает интегрированную (общую) методологию разработки и внедрения ИТ-решений. Под ИТ-решением в MSF понимается скоординированная поставка набора элементов (таких как программно-технические средства, документация, обучение и сопровождение), необходимых для удовлетворения некоторой бизнес-потребности конкретного заказчика. Основными компонентами решения являются: 58 • программно-технические средства, которые могут быть как новыми, так и усовершенствованными версиями разработанных ранее; • внедрение — включает в себя процедуры установки/удаления аппаратного и программного обеспечения; • обучение — процедуры, которые распространяются на всех участников использования и сопровождения решения; • документация — вся информация, необходимая для установки, поддержки, сопровождения и использования решения; • сопровождение — процедуры развития, восстановления, действий в нештатных ситуациях и поддержки пользователей; • внешние коммуникации — информирование заинтересованных сторон о ходе внедрения решения и его влиянии на их интересы. В отличие от решений, программные продукты разрабатываются для нужд массового рынка, поставляются в качестве дистрибутивных пакетов или загружаемых файлов и не требуют организации процесса внедрения. Универсальность модели MSF определяется тем, что благодаря своей гибкости и отсутствию жестко установленных связей и процедур она может быть применена при разработке весьма широкого круга систем: традиционного программного обеспечения, ERP-систем, решений в области электронного бизнеса, распределенных сетевых приложений и пр. Эта модель сочетает в себе свойства двух стандартных [3.1] производственных моделей: каскадной и спиральной (см. рис. 3.1). 59 Вехи Фазы Внедрение Разработка концепции Стабилизация Планирование Разработка Рис. 3.1. Модель жизненного цикла решения MSF В основе методологии MSF лежит итеративный интегрированный подход к созданию и внедрению решений, базирующийся на фазах и вехах. Итеративность подхода предусматривает поэтапное создание всех элементов проекта: программного кода, документации, дизайна, планов. Реализацию проекта рекомендуется начинать с построения, тестирования и внедрения базовой функциональности системы. Затем к решению добавляются все новые и новые возможности. Такой подход к процессу разработки подразумевает достаточную гибкость в ведении документации. Проектные документы должны изменяться по мере эволюции проекта. Их пересмотр не прекращается до конца проекта и производится после каждой итерации. Такой подход существенно отличается от принципов ведения документации в каскадной модели, где процесс разработки начинается лишь после того, как готовы и зафиксированы все требования и спецификации. Интеграция в рамках одного проекта процедур разработки и внедрения системы позволяет более полно сосредоточиться на нуждах Заказчика (даже если разработка решения прошла удачно, заказчики не увидят отдачи до тех пор, пока оно не запущено в эксплуатацию), улучшить взаимодействие с командой сопровождения. 60 Фазы проекта определяют последовательно решаемые задачи, а вехи (milestones) — ключевые точки проекта, характеризующие достижение какого-либо существенного результата. В MSF используются два вида вех: главные и промежуточные. Они имеют следующие характеристики: • главные вехи служат точками перехода от одной фазы к другой и определяют изменения в текущих задачах ролевых кластеров проектной команды; в MSF главные вехи являются в достаточной степени универсальными для применения в любом ИТ-проекте; • промежуточные вехи показывают достижение определенного прогресса в исполнении фазы проекта и расчленяют большие сегменты работы на меньшие, обозримые и управляемые участки; промежуточные вехи могут варьироваться в зависимости от характера проекта. Изменения в задачах ролевых кластеров проектной команды происходят по мере смены фаз проекта. Переход от одной фазы к другой включает в себя также перенос основной ответственности от одних ролевых кластеров к другим, как показано в таблице 3.1. Таблица 3.1. Распределение ответственности ролевых кластеров Веха Ведущие ролевые кластеры Концепция утверждена Управление продуктом Планы проекта утверждены Управление программой Разработка завершена Разработка, удовлетворение потребителя Готовность решения утверждена Тестирование, управление выпуском Внедрение завершено Управление выпуском Команда проекта — модель проектной группы MSF Модель команды проекта MSF не предусматривает формирования какой-либо специальной организационной структуры или введения специальных должностей. Все работы выполняются представителями соответствующих ролевых кластеров. Причем обязанности нескольких ролевых кластеров могут возлагаться на одного человека, или 61 обязанности одного ролевого кластера могут выполнять несколько человек в зависимости от масштабности и сложности проекта. Состав команды определяется теми целями, которые необходимо достичь для успеха проекта: за достижение конкретной цели отвечает соответствующий ролевой кластер, а за успешность проекта в целом несет ответственность вся команда. В соответствии с целями проекта MSF выделяет шесть ролевых кластеров, каждый из которых должен обладать специфическими компетенциями для исполнения собственных функций (см. таблицу 3.2). Таблица 3.2. Ролевые кластеры команды проекта Ролевой Цель кластер Область Функции компетенции Управление Удовлетворение Маркетинг Выступает в роли продуктом Заказчиков Бизнес-отдача представителя Заказчика (бизнес-приоритеты) Формирует общее Представление видение/рамки проекта интересов Заказчика Организует работу с Планирование продукта требованиями Заказчика Развивает сферы применения в бизнесе Формирует ожидания Заказчика Определяет компромиссы между параметрами «возможности продукта / время / ресурсы» Организует маркетинг, PR Разрабатывает, поддерживает и исполняет план коммуникаций 62 Управление Достижение Управление проектом Управляет процессом программой результата в Выработка разработки с целью рамках архитектуры решения получения готового продукта проектных ограничений Контроль в отведенные сроки производственного Формулирует спецификацию процесса продукта и разрабатывает его Административные службы архитектуру Регулирует взаимоотношения и коммуникацию внутри проектной группы Следит за временным графиком проекта и готовит отчетность о его состоянии Проводит в жизнь важные компромиссные решения Разрабатывает, поддерживает и исполняет сводный план и календарный график проекта Организует управление рисками Разработка Создание Технологическое Определяет детали продукта в консультирование физического дизайна соответствии со Проектирование и Оценивает необходимые спецификацией осуществление время и ресурсы на реализации реализацию каждого элемента Разработка дизайна приложений Разрабатывает или Разработка контролирует разработку инфраструктуры элементов 63 Подготавливает продукт к внедрению Консультирует команду по технологическим вопросам Тестирование Одобрение Планирование тестов Обеспечивает обнаружение выпуска Разработка тестов всех дефектов Отчетность по тестам Разрабатывает стратегию и продукта только лишь после того, планы тестирования как все дефекты Осуществляет тестирование выявлены и улажены Удовлетворе- Повышение Обеспечение Представляет интересы ние эффективности технической потребителя в команде потребителя пользователя, поддержки Организует работу с увеличение Обучение требованиями пользователя Эргономика Проектирует и разрабатывает Графический дизайн системы поддержки потребительской ценности продукта Интернационализация Общедоступность (обеспечение возможности работы для пользователей с ограниченными производительности Определяет компромиссы, относящиеся к удобству использования и потребительским качествам продукта физическими Определяет требования к возможностями) системе помощи и ее содержание Разрабатывает учебные материалы и осуществляет обучение пользователей 64 Управление Беспроблемное Инфраструктура Представляет интересы выпуском внедрение и Сопровождение отделов поставки и сопровождение продукта обслуживания продукта Бизнес-процессы Организует снабжение Управление проектной группы выпуском готового Организует внедрение продукта продукта Вырабатывает компромиссы в управляемости и удобстве сопровождения продукта Организует сопровождение и инфраструктуру поставки Организует обеспечение проектной группы Можно выделить три направления, в которых осуществляется масштабирование проектной команды. Первое — создание групп направлений. Группы направлений (feature teams) — это компактные мини-команды, отвечающие за определенные компоненты создаваемого решения и образующие матричную организационную структуру (см. рис. 3.2). В них входят по одному или несколько членов из разных ролевых кластеров. Такие команды имеют четко определенную задачу и ответственны за все относящиеся к ней вопросы, начиная от планирования и кончая запуском в эксплуатацию. 65 Рис. 3.2. Разделение проектной команды на группы направлений [1.5] Второе — создание функциональных групп. Функциональные группы — это группы, существующие внутри ролевых кластеров. Они создаются в больших проектах, когда необходимо сгруппировать работников внутри ролевых кластеров по их областям компетенции (рис. 3.3). Например, в команде разработчиков возможна группировка сотрудников в соответствии с назначением разрабатываемых ими модулей: интерфейс пользователя, реализация бизнес-логики или объектов данных. В отличие от групп направлений, функциональные группы имеют внутреннюю иерархическую структуру. Рис. 3.3. Разделение проектной команды на функциональные группы [1.5] 66 Третье направление правило, выделение одного масштабирования человека на — каждый объединение ролевой ролей. кластер Как обеспечивает полноценное исполнение каждой из ролей, но это экономически оправданно не для всех проектов. Зачастую в малых проектных группах члены группы могут объединять роли. При этом MSF рекомендует соблюдать два принципа. Во-первых, роль команды разработчиков не может быть объединена ни с какой другой ролью. Разработчики — это создатели проекта, и они не должны отвлекаться от своей главной задачи. Наделение разработчиков дополнительными обязанностями лишь делает более вероятным выход из календарного графика проекта. Второй принцип — это избежание сочетания ролей, имеющих предопределенные конфликты интересов. Рекомендации MSF по возможностям объединения ролей приведены на рис. 3.4. Роль менеджера проекта возлагается на кластер «Управление программой». Основные функции этого кластера — управление проектом, выработка архитектуры решения, контроль производственного процесса и организация деятельности административных служб. В небольших проектах все эти функции могут успешно осуществляться одним менеджером программы. Но по мере роста объема и сложности проекта в этом ролевом кластере выделяются две ветви специализации: работа над архитектурой и спецификациями и управление проектом. Организация взаимодействия между проектной командой и заказчиками (заинтересованными лицами) распределяется среди ролевых кластеров «Управление программой» и «Управление продуктом». «Управление продуктом» обеспечивает отчетность в части характеристик решения, а «Управление программой» — отчетность о ходе проекта. 67 Рис. 3.4. Возможности объединения ролей в малых проектах [1.5] Организация исполнения проекта Фаза выработки концепции Цель фазы — создание и сплочение проектной группы на основе выработки единого видения проекта. Основные выполняемые задачи: • создание ядра проектной группы; • подготовка документа общего описания (Видение) и рамок проекта (vision / scope document). Видение (vision) — это ничем не ограничиваемое представление о том, каким должно быть решение. Рамки (scope) — определение того, что из предложенного этим видением будет реализовано в условиях существующих проектных ограничений. • определение и оценка главных рисков проекта; • выявление и первичный анализ бизнес-требований (детально эти требования рассматриваются во время фазы планирования). Распределение задач между ролевыми кластерами приведено в таблице 3.3. Таблица 3.3. Задачи проектной группы в фазе выработки концепции Ролевой кластер Задачи 68 Управление продуктом Выявление нужд и требований Заказчика; определение общих целей проекта; документальное оформление общего описания и рамок проекта Управление программой Определение: целей дизайна, концепции решения, структуры проекта Разработка Прототипирование решения; анализ технологических возможностей; анализ осуществимости решения Удовлетворение потребителя Предварительная оценка эксплуатационных характеристик решения и их влияния на его разработку Тестирование Формирование стратегий тестирования и оценка их влияния на разработку решения Управление выпуском Формирование требований внедрения и сопровождения, оценка их влияния на разработку решения Рекомендуемые промежуточные вехи: • Ядро проектной группы сформировано — назначены ключевые члены проектной группы. • документа Черновой вариант концепции проекта составлен — подготовлен вариант общего описания и рамок проекта, который с целью согласования распространяется среди членов проектной группы, представителей Заказчика и других заинтересованных сторон. После согласования концепции проекта достигается главная веха «Концепция утверждена». Результаты выполнения фазы фиксируются в ряде документов (шаблоны документов можно найти в [1.5]): • общее описание и рамки проекта; • документ оценки рисков; • описание структуры проекта. Фаза планирования Цель фазы — разработка планов проекта. Основные выполняемые задачи: 1. Подготовка функциональной спецификации на систему включает в себя анализ и документирование проектных требований (выделяются: бизнес-требования, потребительские требования, эксплуатационные требования и системные требования, 69 относящиеся к решению в целом). Задача предусматривает последовательное выполнение следующих работ: • выявление типов пользователей системы; • выявление сценариев использования, в которых моделируется выполнение какой-либо операции определенным типом пользователя; • выделение последовательностей специфических действий, называемых примерами пользования (use cases), которые необходимо выполнить пользователю для осуществления операции; • проектирование (дизайн системы). В MSF выделяется три уровня процесса проектирования: концептуальный дизайн (conceptual design), логический дизайн (logical design) и физический дизайн (physical design). Концептуальный дизайн — описание всего, что нужно включить в конечный продукт. В это описание не входит информация о способе реализации решения. Концептуальный дизайн включает только подробные сведения о функциональности предлагаемого решения, инфраструктурой, о взаимодействии пользовательском с существующей интерфейсе и технологической предполагаемых рабочих характеристиках системы. Логический дизайн — описание состава, организации и взаимодействия элементов, из которых состоит программное решение. Физический дизайн — описание программного решения в терминах разработчика системы. Включает все необходимые детали для реализации: технологии, организацию, структуру и взаимосвязи элементов, которые будут использованы при создании программного решения. Результаты процесса проектирования документируются в функциональной спецификации. 2. Подготовка рабочих планов. На основе разработанных спецификаций каждый из руководителей ролевых кластеров проектной группы подготавливает планы, относящиеся к его роли (план внедрения, план тестирования, план эксплуатации, план мер безопасности, план обучения и пр.), и принимает участие в командных сессиях планирования, где все планы синхронизируются и представляются вместе в виде сводного плана проекта. 3. Оценка проектных затрат и сроков разработки различных составляющих проекта. 70 Распределение задач между ролевыми кластерами в фазе планирования приведено в таблице 3.4. Таблица 3.4. Задачи проектной группы в фазе планирования Ролевой кластер Фокус Управление продуктом Выявление и анализ бизнес-требований, разработка концептуального дизайна; разработка коммуникационного плана Управление программой Концептуальный и логический дизайн; функциональная спецификация; сводный план и сводный календарный график проекта; бюджет Разработка Оценка технологий; логический и физический дизайн; план и календарный график разработки; смета разработки Удовлетворение потребителя Сценарии/примеры использования, пользовательские требования, требования локализации и общедоступности; пользовательская документация / план обучения / график тестирования удобства эксплуатации; обучение Тестирование Оценка дизайна; требования тестирования; план и календарный график тестирования Управление выпуском Оценка дизайна; эксплуатационные требования; план и календарный график пилотного и окончательного внедрения Рекомендуемые промежуточные вехи: • Верификация технологий — проверка соответствия продуктов и технологий, которые предполагается использовать, спецификациям их поставщиков; отбор наиболее подходящих технологий. • Базовая версия функциональной спецификации создана — функциональная спецификация готова для распространения среди заинтересованных сторон с целью согласования характеристик создаваемого решения. • Базовая версия сводного плана проекта создана — сформирована совокупность согласованных планов работы различных ролевых кластеров. • Базовая версия сводного календарного графика проекта создана — объединено и согласовано календарное планирование деятельности каждого ролевого кластера. 71 • Среды разработки и тестирования развернуты — обеспечивают возможность создавать и тестировать решение вне находящихся в эксплуатации производственных систем, что позволяет избежать негативного влияния на эти системы. Достижение главной вехи «Планы проекта утверждены» означает, что промежуточные процедуры планирования успешно пройдены, составленные календарные графики реалистичны и соответствуют потребностям Заказчика, распределение ролей и ответственности в команде определено должным образом и механизмы управления рисками приведены в действие. Результаты фазы оформляются в базовой версии проекта путем создания следующих документов: • функциональная спецификация; • план управления рисками; • сводный план и сводный календарный график проекта. Фаза разработки Цель фазы — создание компонент решения (включая как документацию, так и программный код). Распределение задач между ролевыми кластерами в фазе разработки приведено в таблице 3.5. Таблица 3.5. Задачи проектной группы в фазе разработки Ролевой кластер Задачи Управление продуктом Формирование ожиданий Заказчика Управление программой Управление изменениями в функциональной спецификации; мониторинг проекта; доработка планов Разработка Разработка программного кода и инфраструктуры; документирование конфигураций Удовлетворение потребителя Обучение пользователей; доработка плана обучения; тестирование удобства эксплуатации Тестирование Функциональное тестирование; тестирование документации; доработка плана тестирования Управление выпуском Планирование развертывания; доработка планов внедрения (включая пилотное внедрение) Рекомендуемые промежуточные вехи: 72 • Концепция подтверждена — успешно проведена проверка ключевых элементов решения в непроизводственной копии существующей среды. • Билд n завершен, билд n+1 завершен — промежуточные вехи, помогающие определить прогресс создания решения. В сложных системах зачастую выделяются компоненты, каждый из которых разрабатывается и тестируется отдельной командой и затем интегрируется в общее решение. Билды (сборки) и являются процедурами слияния компонент. Эти промежуточные вехи могут быть привязаны к некоторым важным элементам системы (например, завершение графического дизайна, разработки базы данных и пр.). Главная веха «Разработка завершена» означает, что создание всех составляющих завершено, решение готово к тестированию и стабилизации. Результаты фазы: • исходный и исполнимый код приложений; • скрипты установки и конфигурирования; • окончательная функциональная спецификация; • материалы поддержки решения; • спецификации и сценарии тестов. Фаза стабилизации Цель фазы — тестирование и отладка разработанного решения в реалистичной модели производственной среды. Основные выполняемые задачи: • выявление, приоритезация и устранение ошибок; • пилотное внедрение решения. Распределение задач между ролевыми кластерами в фазе стабилизации приведено в таблице 3.6. Таблица 3.6. Задачи проектной группы в фазе стабилизации Ролевой кластер Задачи Управление продуктом Исполнение коммуникационного плана; планирование премьеры продукта Управление программой Мониторинг проекта; приоритезация ошибок Разработка Устранение ошибок; оптимизация программного кода 73 Удовлетворение потребителя Доработка эксплуатационных руководств; подготовка учебных материалов Тестирование Организация и проведение тестирования Управление выпуском Развертывание и поддержка пилотного внедрения; планирование внедрения; обучение персонала сопровождения Рекомендуемые промежуточные вехи: • Точка конвергенции — характеризует достижение существенного прогресса в устранении ошибок. В этот момент скорость устранения ошибок начинает превосходить скорость их обнаружения. • Точка достижения нуля — это момент, когда впервые все выявленные ошибки оказываются устраненными. В дальнейшем ошибки еще будут выявляться, но их количество начинает стремительно убывать. • Версии-кандидаты — последовательный выпуск и доработка полнофункциональных версий системы. Каждая версия-кандидат имеет полный набор составляющих, необходимых для внедрения решения в производство. В процессе тестирования версии-кандидата производится оценка ее готовности к внедрению. При необходимости проектная группа должна подготовить новую версию, исправляющую недостатки предыдущей. • Контрольное тестирование завершено. К этому моменту проектная группа должна: — оценить результаты тестирования в соответствии с имеющимися критериями успешности; — подготовить среду внедрения; — создать необходимые для внедрения процедуры, скрипты и массивы данных (load sets); — иметь готовые учебные материалы; — обеспечить условия для сопровождения решения; — создать и протестировать план «отката» для восстановления системы после сбоев. • Тестирование приемлемости для потребителей завершено — пользователи выполнили тестирование и одобряют работу решения в непроизводственной среде. • Пилотное внедрение завершено — выполнено тестирование полного решения в среде, максимально приближенной к производственным условиям. В MSF пилотный 74 релиз (pilot release) — это внедрение решения или в часть производственной среды, или для части пользователей, или на подмножестве данных. Главная веха «Готовность решения утверждена» означает, что к этому моменту проектная группа завершает разрешение всех существенных проблем и решение готово к внедрению. Результаты: • окончательный продукт; • документация выпуска; • материалы поддержки решения; • результаты и инструментарий тестирования; • исходный и исполнимый код приложений; • проектная документация. Фаза внедрения Цель фазы — установка и отладка системы в реальных условиях эксплуатации, передача системы персоналу поддержки и сопровождения, получение окончательного одобрения результатов проекта со стороны Заказчика. Основные задачи проектной группы в фазе внедрения приведены в таблице 3.7. Таблица 3.7. Задачи проектной группы в фазе внедрения Ролевой кластер Задачи Управление продуктом Получение отзывов и оценок Заказчика; оформление акта о приеме выполненной работы Управление программой Сопоставление рамок проекта с поставленным решением; управление стабилизацией Разработка Разрешение проблем; поддержка эскалации Удовлетворение потребителя Обучение; управление календарным графиком обучения Тестирование Тестирование производительности Управление выпуском Управление внедрением; одобрение изменений Рекомендуемые промежуточные вехи • Ключевые компоненты развернуты — установлены элементы системы, обеспечивающие функционирование основных технологий внедряемого решения 75 (например, контроллеры доменов, маршрутизаторы, почтовые серверы, удаленные серверы доступа, серверы баз данных). • Внедрение на местах завершено — к этому моменту все целевые потребители получают доступ к решению и оформляются акты о пуске решения в эксплуатацию. • Внедренное решение стабилизировано — Заказчик и Проектная группа пришли к соглашению о том, что решение функционирует правильно. Временной отрезок между промежуточной вехой «Внедренное решение стабилизировано» и главной вехой «Внедрение завершено» иногда называют «периодом затишья»: проектная группа активно не работает, но она необходима для реагирования на возникающие проблемы. Достижение главной вехи «Внедрение завершено» означает, что решение начинает давать Заказчику ожидаемую бизнес-отдачу, а проектная группа завершила свою деятельность. Результатами этой фазы являются: • информационные системы эксплуатации и поддержки; • работающие процедуры и процессы; • базы знаний, отчеты, журналы протоколов; • версии проектных документов, массивы данных и программный код, разработанные во время проекта; • отчет о завершении проекта; • окончательные версии всех проектных документов; • показатели удовлетворенности Заказчика и потребителей. В первых разделах книги приведены сведения, которые позволяют решить целый ряд вопросов, возникающих при планировании проекта внедрения информационных систем: 1. сформировать структуру проекта — выделить фазы (этапы); 2. определить, что и в какой последовательности будет исполняться, т. е. построить иерархическую структуру работ и сетевой график проекта; 3. определить состав проектной команды и распределение ролей и ответственности между участниками; 4. задать контрольные точки проекта и критерии оценки их достижения (получения нужных результатов). 76 Методика планирования и управления проектом рассматривается в последующих разделах. 77 Лекция 4. УПРАВЛЕНИЕ ИНТЕГРАЦИЕЙ ПРОЕКТА. УПРАВЛЕНИЕ СОДЕРЖАНИЕМ ПРОЕКТА Понятие интеграции. Характеристики интеграции проекта. Элементы интеграционных процессов управления проекта: разработка Устава проекта; разработка предварительного описания содержания проекта; разработка плана управления проектом. Процессы управления содержанием проекта. Построение иерархической структуры работ (ИСР). Словарь ИСР. Контроль за изменениями содержания. Управление содержанием. План управления содержанием проекта. Ключевые слова: группы процессов управления проектом, интеграция процессов управления, Устав проекта, определение проекта, план управления проектом, контрольные события (вехи проекта), иерархическая структура работ (ИСР). Для упрощения управления проектом, организации и координации проектных работ все действия, направленные на достижение целей проекта, разбивают на отдельные составляющие — процессы управления проектом. Управление проектом по стандарту PMBOK выполняется с помощью 44 процессов, которые объединены в пять групп, называемых «группы процессов управления проектом» [4.1]: 1. Группа процессов инициации. 2. Группа процессов планирования. 3. Группа процессов исполнения. 4. Группа процессов мониторинга и управления. 5. Группа завершающих процессов. Все пять групп процессов имеют четкие зависимости, они выполняются в одной и той же последовательности в каждом проекте с определенным наложением. Степень наложения определяется условиями выполнения конкретного проекта. Процессы, входящие в группу процессов, могут иметь взаимосвязи как в рамках данной группы процессов, так и с процессами других групп. Для успешного достижения целей проекта необходимо не только управлять каждым процессом в отдельности, но и обеспечить комплексный подход к управлению с учетом взаимосвязей, взаимозависимостей как отдельных процессов, так и групп процессов. 78 С целью структуризации управления проектом процессы управления проектом распределены по девяти областям знаний [4.1]: 1. Управление интеграцией. 2. Управление содержанием. 3. Управление временем. 4. Управление стоимостью. 5. Управление персоналом. 6. Управление коммуникациями. 7. Управление качеством. 8. Управление рисками. 9. Управление снабжением. Распределение 44 процессов по областям знаний и группам процессов представлено в таблице 4.1. Таблица 4.1. Распределение процессов по областям знаний и группам процессов Процессы и области знаний Интеграция управления проектом Управление содержанием проекта Управление сроками проекта Управление стоимостью Группа процессов инициации Разработка Устава проекта Разработка предварительного содержания проекта Группы процессов управления проектом Группа Группа Группа процессов процессов процессов мониторинга планирования исполнения и управления Разработка Руководство и Мониторинг и плана управление управление управления исполнением работами проектом проекта проекта Планирование содержания Определение содержания Создание ИСР Определение состава операций Определение взаимосвязей операций Оценка ресурсов операций Оценка длительности операций Разработка расписания Стоимостная оценка Группа завершающих процессов Закрытие проекта Подтверждение содержания Управление содержанием Управление расписанием Управление стоимостью 79 Разработка бюджета расходов Планирование качества проекта Управление качеством проекта Управление человеческими ресурсами проекта Планирование человеческих ресурсов Управление коммуникациями проекта Планирование коммуникаций Управление рисками проекта Планирование управления рисками Идентификация рисков Качественный анализ рисков Количественный анализ рисков Планирование реагирования на риски Обеспечение качества Контроль качества Набор команды проекта Развитие команды проекта Распространение информации Управление командой проекта Отчетность по исполнению Управление участниками проекта Мониторинг и управление рисками Управление поставками проекта В данном учебном пособии рассмотрены все области знаний, за исключением области «Управление поставками», которая на проектах по внедрению информационных технологий не является существенной. Управление интеграцией Область знаний «Управление интеграцией» включает все пять групп процессов [4.1]: Инициация, Планирование, Исполнение, Управление и контроль, Завершение. Результаты процессов из группы Инициация являются входящей информацией для группы процессов Планирование. В свою очередь, результаты групп процессов Управление 80 и контроль являются входящими для группы процессов Завершение. В упрощенном виде последовательность применения групп процессов управления проектом при внедрении ИС представлена на рис. 4.1. Управление интеграцией 1. Процессы инициации 2. Процессы планирования 4.Процессы управления и контроля 3. Процессы исполнения 5.Процессы завершения Рис. 4.1. Группы процессов управления проектами из области знаний «Управление интеграцией» Прежде чем перейти к рассмотрению процессов управления из области интеграции, определим, что же понимается под интеграцией процессов. Понятие интеграции процессов управления Интеграция процессов управления проектом — это взаимосвязи групп процессов и входящих в них процессов, обеспечивающие непрерывный и комплексный подход к управлению проектной деятельностью. Цель интеграции состоит в достижении эффективного взаимодействия процессов управления проектами, обеспечивающих достижение целей проекта. Интеграция управления проектом требует, чтобы все процессы управления проектами были выстроены и связаны с другими процессами для облегчения их координации. 81 Необходимость в интеграции процессов управления проектами обусловлена взаимодействием процессов управления. Эти процессы взаимодействуют между собой сложным образом, поэтому рассмотрим на отдельных примерах, как выстраивается интеграционное взаимодействие групп процессов управления проектной деятельностью. Проектная деятельность начинается с процессов инициации — с момента подписания договора с Заказчиком (или согласования с Заказчиком условий договора). При инициации определяются цели, задачи, результаты, сроки проекта, формируется команда управления проектом, определяются необходимые ресурсы, подготавливаются при необходимости рабочие места, разрабатываются необходимые для управления проектом документы. На этом инициация проекта завершается. Команда управления проектом приступает к процессу планирования проекта, составляется расписание проекта. Как правило, вначале разрабатывается укрупненное расписание, которое должно соответствовать этапам договора, затем осуществляется его детализация. С точки зрения управления интеграцией, договор является точкой входа для процесса планирования. Именно договором определяются результат и сроки проекта. По завершению составления расписания проекта — когда определены задачи, их исполнители, сроки выполнения, — приступают к выполнению проектных работ. Процесс планирования при этом не заканчивается, он продолжается практически до момента завершения проекта. В ходе выполнения работ первоначальное укрупненное расписание проекта детализируется, уточняется. А это, в свою очередь, означает необходимость построения интеграционного взаимодействия процессов планирования с процессами исполнения работ. Процессы группы «исполнение» выстраиваются в соответствии с применяемой на проекте методологией внедрения информационной системы. С момента инициации проекта осуществляется непрерывный контроль над всей проектной деятельностью, включая и процессы планирования, и процессы исполнения работ, и процессы завершения, т. е. процессы контроля интегрируются со всеми группами процессов управления проектами. Результатом процессов контроля могут быть решения, управляющие воздействия на планирование, изменение хода проектных работ, процедуры закрытия проекта. Процессы завершения формализуют приемку разработанной ИС. При успешном завершении приемки ИС осуществляется закрытие проекта (включая финансовое и организационное закрытие проекта). 82 Не все процессы могут понадобиться в каждом конкретном выполняемом проекте или его фазе, и не все взаимодействия могут быть к ним применимы. Общая схема управления интеграцией проекта приведена на рис. 4.2. Управление интеграцией включает в себя процессы, которые обеспечивают координацию всех областей и элементов проекта. Управление проектами выполняется с помощью применения и интеграции процессов управления проектами: инициации, планирования, исполнения, контроля, завершения. Интегрированные процессы планирования, исполнения, управления и контроля, завершения являются центральным аспектом дисциплины управления проектами. 83 УПРАВЛЕНИЕ ИНТЕГРАЦИЕЙ ПРОЕКТА 1. Разработка Устава проекта 2. Разработка предварительного описания содержания проекта 2.1 Входы 1. Устав проекта 2. Содержание работ проекта 3. Методология внедрения ИС 1.1. Входы 1. Контракт 2. Содержание работ проекта 3. Методология внедрения ИС 1.2. Инструменты и методы 1.Методы выбора проекта 2. Методология управления проектом 3. Информационная система управления проектами 4. Экспертная оценка 2.2. Инструменты и методы 1. Методология управления проектом 2. Информационная система управления проектами 3. Экспертная оценка 1.3 Выходы 1.Устав проекта 2.3 Выходы 1. Предварительное описание содержания проекта 4. Руководство и управление исполнением проекта 4.1. Входы 1. План управления проектом 2. Одобренные корректирующие действия 3. Одобренные предупреждающие действия 4. Одобренные запросы на изменения 5. Одобренное исправление дефектов 6. Утверждённое исправление дефектов 7. Процедура административного закрытия 4.2. Инструменты и методы 1. Методология управления проектом 2. Информационная система управления проектами 4.3. Выходы 1. Результаты внедрения ИС 2. Запрошенные изменения 3. Обработанные запросы на изменения 4. Выполненные корректирующие действия 5. Выполненные предупреждающие действия 6. Выполненное исправление дефектов 7. Информация об исполнении работ 5. Мониторинг и управление работами проекта 5.1. Входы 1. План управления проектом 2. Информация об исполнении работ 3. Отклоненные запросы на изменения 5.2. Инструменты и методы 1. Методология управления проектом 2. Информационная система управления проектами 3. Метод освоенного объема 4. Экспертная оценка 5.3. Выходы 1. Рекомендованные корректирующие действия 2. Рекомендованные предупреждающие действия 3. Прогнозы 4. Рекомендованное исправление дефектов 5. Запрошенные изменения 3. Разработка плана управления проектом 3.1 Входы 1. Предварительное описание содержания проекта 2. Процессы управления проектами 3. Факторы внешней среды предприятия 4. Активы организационного процесса 3.2. Инструменты и методы 1. Методология управления проектом 2. Информационная система управления проектами 3. Экспертная оценка 3.3 Выходы 1. План управления проектом 6. Общее управление изменениями 6.1. Входы 1. План управления проектом 2. Запрещенные изменения 3. Информация об исполнении работ 4. Рекомендованные предупреждающие действия 5. Рекомендованные корректирующие действия 6. Рекомендованное исправление дефектов 7. Результаты внедрения ИС 6.2. Инструменты и методы 1. Методология управления проектом 2. Информационная система управления проектами 3. Экспертная оценка 6.3. Выходы 1. Одобренные запросы на изменения 2. Отклонённые запросы на изменения 3. План управления проектом (обновления) 4. Описание содержания проекта (обновления) 5. Одобренные корректирующие действия 6. Одобренные предупреждающие действия 7. Одобренное исправление дефектов 8. Утверждённое исправление дефектов 9. Результаты внедрения ИС 7. Закрытие проекта 7.1. Входы 1. План управления проектом 2. Документация по контракту 3. Факторы внешней среды предприятия 4. Активы организационного процесса 5. Информация об исполнении работ 6. Результаты внедрения ИС 7.2. Инструменты и методы 1. Методология управления проектом 2. Информационная система управления проектами 3. Экспертная оценка 7.3. Выходы 1. Процедура административного закрытия 2. Процедура финансового закрытия контракта 3. Окончательный результат ИС, передаваемый Заказчику 4. Активы организационного процесса (Итоговый отчет по проекту) 84 Рис. 4.2. Общая схема управления интеграцией проекта Интеграцию проекта обеспечивают три основных документа проекта. I. Устав проекта. Включает в себя описание содержания проекта на верхнем уровне, которое подлежит дальнейшему уточнению и детализации при разработке Плана проекта. II. Предварительное описание содержания проекта (определение проекта). Содержит описание работы, которую предстоит выполнить, и результатов разработки и внедрения ИС, которые надлежит произвести. План управления проектом. Содержит описание того, как работа III. по разработке и внедрению ИС будет выполняться. Устав проекта — документ, с которого начинается планирование проекта. Определение проекта разрабатывается на базе Устава и содержит ряд более детализированных элементов Устава. Исходной информацией для разработки Плана проекта являются Устав и Определение проекта. План проекта имеет самую высокую степень детализации предстоящих работ по внедрению ИС (рис. 4.3). 1. Устав проекта 2. Определение проекта 3. План проекта Рис. 4.3. Основные документы управления проектом Устав проекта Устав проекта (Project Charter) является официальной авторизацией проекта и разрабатывается Руководителем проекта с привлечением членов команды управления проектом со стороны Исполнителя. Устав проекта согласовывается с командой управления 85 проектом со стороны Заказчика и утверждается Спонсорами проекта как со стороны Исполнителя, так и со стороны Заказчика. Процесс разработки Устава проекта относится к группе процессов Инициация и осуществляется в фазе (на этапе) проекта внедрения ИС, которая имеет свое специфическое название в каждой методологии внедрения ИС, например, «Предварительное определение проекта», «Определение проекта» — методология внедрения продуктов Microsoft, «Концепция» — методология внедрения ASUP. Исходными документами для разработки Устава проекта внедрения ИС являются контракт и результаты предпроектного обследования, определяющие содержание работ по проекту. Результаты предпроектного обследования оформляются в виде отчета, включая описание бизнес-процессов верхнего уровня. Устав проекта содержит следующую информацию: 1. Название проекта. 2. Бизнес-цели компании или причины возникновения проекта. Формулировка причины фактически дает ответ на вопрос «Зачем выполняется данный проект?». Бизнес-цели компании обязательно учитывают стратегию развития компании, включая стратегию развития информационных технологий, на которую ориентирован проект, — например, увеличение капитализации Холдинга и привлечение инвесторов. 3. Цели проекта. Цели проекта определяют, что должно быть выполнено, и описывают конечный результат проекта. В Уставе проекта приводится цель проекта как результат, ожидаемый Заказчиком и полезный для него. Цель формулируется совместно Заказчиком и Исполнителем. При формулировании цели руководитель проекта должен контролировать ее соответствие контракту, в рамках которого будут выполняться работы по проекту. Формулировка целей должна соответствовать следующим критериям (SMARTSpecific, Measurable, Achievable, Relevant, Time-bound): Конкретные (Specific) — позволяющие сформировать расписание проекта; Измеримые (Measurable) — позволяющие качественно (или количественно) оценить, что результат получен; 86 Достижимые (Achievable) — принципиально реализуемые Исполнителем в рамках проекта, с учетом декларируемой помощи со стороны Заказчика; Приносящие результат (Relevant) — соответствуют ожидаемой Заказчиком пользе; Ограниченные во времени (Time-bound) — реализуемые в ожидаемые Заказчиком временные рамки проекта. Результаты проекта должны соотноситься со спецификацией контракта, в рамках которого будут выполняться работы по проекту. Примеры формулировок целей: Проектирование единых унифицированных бизнес-процессов в Головной компании и дочерних компаниях холдинга. Разработка единого унифицированного ERP-решения, которое предназначено для внедрения в Холдинге, состоящем из Головной компании и 10 дочерних компаний. Разработка инструментальных средств развертывания/тиражирования полученного решения во всех дочерних компаниях Холдинга. 4. Границы проекта. Границы проекта определяют в целом то, что включается в проект. Необходимо явно указывать, что не включается в проект (таблица 4.2), чтобы исключить ситуацию, когда участник проекта ошибочно считает некоторый продукт, услугу или результат входящими в проект. Организационные границы Определяется, какие подразделения (включая юридических лиц) должны участвовать в проекте — кто будет использовать и поддерживать ИС, от кого зависит выработка основных решений по требованиям к ИС. Организационные границы определяют максимальные границы обследования и область рождения требований к ИС. Функциональные границы Указываются бизнес-направления, бизнес-процессы, которые будут покрываться ИС. Данным пунктом определяются модули ERP-систем. 87 Географические границы Указываются территориально удаленные объекты, подлежащие автоматизации. Таблица 4.2. Пример границ проекта Раздел функциональности Организационный менеджмент Администрирование персонала Учет рабочего времени Расчет зарплаты 5. Процессы, не подлежащие реализации Формирование фонда заработной платы по специфичным методикам Система оповещения по функциям Управления персоналом в целом Ведение аттестации рабочих мест, вредных условий труда Ведение параллельных данных на английском языке Фактический учет рабочего времени (будет использоваться негативный учет) Учет рабочего времени по заказам/объектам Учет работы во вредных условиях Сдельная система оплаты труда Содержание проекта (задачи проекта). Содержание проекта отвечает на вопрос «Какую конкретную работу нужно выполнить для достижения поставленных целей?» или «Какие задачи необходимо решить для достижения поставленных целей?». Содержание может быть получено от Заказчика в качестве составляющей тендерной документации. Пример описания содержания (задач) проекта Автоматизация бизнес-процессов: Управление основными средствами. Учет затрат. Управление персоналом. Требования к бизнес-процессам должны включать: Требования законодательства РФ в области бухгалтерского, налогового и статистического учета и отчетности. Требования международных стандартов финансового учета и отчетности. Требования управленческого учета Головной компании Холдинга. Требования внутренней отчетности (внутреннего аудита). Требования ТК РФ, отраслевой отчетности, отчетности Головной компании Холдинга. 6. Основные предположения и ограничения. 88 Предположения — это ряд факторов, влияющих на проект, значения которых являются неопределенными. В момент инициации проекта очень важно выделить как можно больше предположений и задокументировать их. Формулируются внешние условия и допущения, без фиксирования которых проект не может быть успешно завершен: лежащие вне контроля сторон условия, без наличия которых не может быть четко определено содержание проекта. Примеры предположений: основные ресурсы будут поставлены согласно графику; участники проекта будут выполнять требования и соблюдать сроки выполнения проекта; Заказчик понимает необходимость начала и завершения проекта; проект имеет организационную поддержку со стороны руководства Заказчика; в организации-заказчике имеется возможность выделить персонал для обеспечения работ по проекту; Заказчик и Исполнитель понимают необходимость обеспечения высокой организационной дисциплины по проекту. Для составления списка предположений рекомендуется называемый «мозговой штурм». Неправильные или использовать так незадокументированные предположения могут вызвать проблемы во время реализации проекта. 7. Ограничения — это условия, влияющие на действия команды или определяющие их. Ограничения проекта задаются в процессе инициации. Ограничения могут быть техническими, физическими, ресурсными или другими. Возможны ограничения на бюджет проекта, ограничение на качество продукта, ограничение на время и технологии. Примеры ограничений: наличие у консультантов Исполнителя сертификатов по управлению проектами, выдаваемых Институтом управления проектами (PMI); 8. увеличение стоимости проекта не более чем на 10%. Контрольные события и ключевые даты. Контрольные события (вехи проекта) — это основные события проекта, контрольные даты получения результатов. Результаты и контрольные события 89 могут совпадать или иметь разные значения. В Уставе приводятся основные вехи проекта. Вехи, указанные в Уставе проекта, будут контролироваться Заказчиком и должны жестко соблюдаться. Необходимо оценивать влияние всех изменений в проекте на соблюдение сроков по данным вехам. Примеры контрольных событий-вех проекта приведены в таблице 4.3. Таблица 4.3. Примеры вех проекта по внедрению ИС Наименование вехи проекта Ключевые даты Конфигурирование программного обеспечения завершено Материалы для обучения разработаны 1 сентября 2008 г. Прототип разработан 12 декабря 2008 г. Тестирование завершено 1 марта 2008 г. Программное обеспечение выпущено 20 января 2009 г. 9. 2 ноября 2008 г. Основные результаты и критерии успеха. Результаты проекта — ИС, отдельные модули ИС, входящие в ИС алгоритмы расчета, экранные формы, формы отчетов и документов, получаемые в рамках выполнения проекта. Критерий успеха — набор стандартов или правил, определяющих выполнение задачи с приемлемым уровнем качества. Критерии успеха должны соответствовать целям и содержанию проекта, зафиксированным в Уставе проекта. Приведем пример описания результатов и критериев успеха проекта по внедрению ИС. Разработанная ИС должна решить нижеследующие задачи. В части Управления Основными Средствами: компании возможность ведения учета Основных Средств (ОС) Головной и дочерних компаний холдинга в соответствии с российским (бухгалтерским и налоговым) законодательством и МСФО; возможность ведения единого реестра основных средств Холдинга; возможность оперативного получения данных об ОС; 90 возможность осуществления контроля по учету и движению объектов ОС. В части Управления Персоналом: возможность ведения и оперативного получения согласованных данных по численности, составу и движению персонала в каждой дочерней компании Холдинга и в целом по Холдингу, возможность получения полной информации по любому сотруднику компании (включая сведения об образовании, квалификации, родственниках, поощрениях и дисциплинарных нарушениях, историю работы на предприятии и т. п.); возможность ведения штатного расписания в каждой дочерней компании и в целом по Холдингу; возможность ведения табелей учета рабочего времени; возможность получения отчетности РФ, отраслевой, отчетности Головной компании Холдинга. В части Учета затрат: автоматизация процесса расчета себестоимости работ; возможность анализа данных о нормативной и фактической себестоимости работ. 10. Планируемая стоимость проекта. Стоимость проекта определяется контрактом между Заказчиком и Исполнителем. Исходя из стоимости проекта в дальнейшем составляется бюджет расходов проекта с указанием статей расходов на внедрение ИС в разрезе месяца, квартала, полугодия, года. Устав проекта официально закрепляет назначение руководителя проекта, определяет ролевой состав команды управления проектом, содержит имена Спонсора и Руководителя проекта, а также определяет их полномочия. Предварительное описание содержания проекта Процесс определения проекта (предварительного описания содержания проекта) входит в группу процессов инициализации. Для разработки предварительного содержания проекта используется Устав проекта. Описание содержания проекта представляет собой детализацию того, что необходимо сделать для достижения цели и какая методология 91 будет использована при внедрении ИС. предварительного описания Согласно PMBOK [4.1], процесс разработки содержания проекта описывает и документирует характеристики и границы проекта и связанные с ним продукты и услуги, а также методы приемки и управление содержанием. Описание содержания проекта включает в себя: цели проекта и продукта; требования к продукту или услуге и характеристики таковых; критерии приемки продукта; границы проекта; требования и результаты проекта; ограничения проекта; допущения проекта; первоначальную организацию проекта; первоначально сформулированные риски; контрольные события (вехи) расписания; первоначальную иерархическую структуру работ (ИСР); смету расходов с указанием порядка величин; требования к управлению конфигурацией проекта; требования к одобрению. Предварительное описание содержания проекта разрабатывается на основе Устава проекта и информации, предоставляемой Инициатором или Спонсором проекта. Команда управления проектом в рамках процесса определения содержания проекта производит дальнейшую доработку предварительного описания содержания проекта до получения окончательного варианта. Содержание этого документа будет изменяться в зависимости от сложности проекта и может включать в себя некоторые или все из вышеуказанных элементов. В последующих фазах многофазных проектов в процессе разработки предварительного описания ратифицируется и дорабатывается содержание проекта, сформулированное для данной фазы. План управления проектом Процесс разработки Плана управления проектом относится к группе процессов планирования. План управления проектом объединяет следующие планы: 92 План управления содержанием; План управления расписанием; План управления стоимостью; План управления качеством; План управления обеспечением проекта персоналом; План управления коммуникациями проекта; План управления рисками; План управления поставками; План управления изменениями. Управление содержанием проекта Согласно PMBOK [4.1], процесс управления содержанием проекта включает в себя процессы, обеспечивающие исполнение в ходе проекта всех тех и только тех работ, которые необходимы для его успешного выполнения. Это следующие процессы: Планирование содержания. Уточнение содержания. Создание ИСР. Подтверждение содержания. Контроль изменений содержания. Эти процессы взаимодействуют друг с другом, а также с процессами из других групп управления проектом. Первые три процесса относятся к группе процессов планирования, два других — к группе процессов мониторинга и управления. На вход процесса «Планирование содержания» поступают результаты выполнения процессов группы инициации — Устав проекта, предварительное содержание описания проекта и план управления проектом. Процесс «Определение содержания» связан с процессом «Планирование содержания» и с процессами группы мониторинга и контроля, получая от них на вход План управления содержанием проекта и Одобренные запросы на изменение. Процесс «Создание ИСР» связан с процессом «Определение содержания». Входами для процесса «Подтверждение содержания» являются выходы процесса «Создание ИСР» и процесса «Руководство и управление исполнением проекта» группы процессов мониторинга и контроля. Процесс «Управление содержанием» связан с процессом «Подтверждение содержания» и процессами группы мониторинга и 93 управления документами «Отчетность по исполнению» и «Руководство и управление исполнением проекта». Управление содержанием проекта должно быть так интегрировано в остальные процессы и области знаний, чтобы результатом проектной работы стало создание информационной системы необходимого содержания. На рис. 4.4 представлена схема взаимосвязи процессов управления содержанием проекта. 94 Устав Предварительное описание содержания проекта Факторы внешней среды предприятия Организационные активы Планирование содержания План управления содержанием проекта Определение содержания Описание содержания проекта План управления содержанием проекта (обновленный) Создание ИСР План управления проектом Одобренные запросы на изменение Запрошенные изменения Одобренные запросы на изменение Запрошенные изменения Описание содержания проекта (обновленное) ИСР Словарь ИСР План управления содержанием проекта (обновленный) Базовый план по содержанию Результаты поставки Подтверждение содержания Запрошенные изменения Рекомендованные корректирующие действия Принятые результаты поставки Информация об исполнении Отчеты об исполнении Управление содержанием Активы организационн ого процесса Запрошенные изменения Рекомендованные корректирующие действия План управления проектом (обновленный) Описание содержания проекта (обновленное) ИСР (обновление) Словарь ИСР (обновление) Базовый план по содержанию Рис. 4.4. Взаимосвязь процессов управления содержанием проекта 95 Рассмотрим, что происходит внутри каждого процесса управления содержанием. Планирование содержания Процесс «Планирование содержания» выполняет разработку и документирование плана управления содержанием проекта. Как показано на рис. 4.4, исходными данными для процесса планирования являются Устав проекта, Предварительное содержание описания проекта и План управления проектом, а также факторы внешней среды и организационные активы. С помощью экспертной оценки и опыта аналогичных проектов, а также шаблонов планов управления содержанием и шаблонов иерархической структуры работ (ИСР), формируется План управления содержанием проекта. Согласно PMBOK [4.1], План управления содержанием проекта (Project Scope Management Plan) — это документ, описывающий, как будут определяться, разрабатываться и проверяться работы, которые необходимо выполнить для получения результата с указанными характеристиками, и задающий действия по управлению содержанием проекта. План управления содержанием проекта является инструментом планирования, описывающим, как проектная команда будет формулировать содержание проекта, разрабатывать подробное описание содержания проекта, определять и разрабатывать иерархическую структуру работ, проверять и контролировать содержание проекта. Разработка плана управления содержанием и детализация содержания проекта начинаются с анализа информации, содержащейся в Уставе проекта, предварительном описании содержания проекта, последней одобренной редакции плана управления проектом, и информации, которая находится в активах организационного процесса и факторов внешней среды предприятия. План управления содержанием проекта должен содержать описание следующих процессов: подготовки подробного описания содержания проекта на основе предварительного описания содержания проекта, создания ИСР на основе подробного описания содержания проекта и определения способов поддержания и одобрения ИСР, определения формальной процедуры верификации и приемки завершенных результатов поставки проекта, 96 контроля обработки запросов на изменения в подробном описании содержания проекта. (Этот процесс непосредственно связан с процессом общего управления изменениями.) План управления содержанием проекта может быть обобщенным или подробным, в зависимости от потребностей проекта. Уточнение (определение) содержания Процесс уточнения (определения) содержания выполняет разработку подробного описания содержания проекта, которое будет основой для принятия будущих решений по проекту. Команда проекта анализирует потребности, пожелания и ожидания участников проекта, проводит корректировку требований к разрабатываемой ИС. Допущения и ограничения анализируются на полноту, и при необходимости производится добавление дополнительных допущений и ограничений. Входными документами процесса определения содержания являются План управления содержанием проекта и Одобренные запросы на изменения. В качестве инструментов для уточнения требований могут быть использованы такие методы, как иерархическая структура продукта, системный анализ, системный инжиниринг, метод оптимизации выгод, анализ стоимости и функциональный анализ, метод «мозгового штурма». Для разработки подробного описания содержания проекта привлекаются эксперты. Анализ участников проекта — инструмент, который выявляет влияние и интересы различных участников проекта и документирует их потребности, пожелания и ожидания, производит отбор потребностей, пожеланий и ожиданий, определяет их приоритет и их количественную оценку. Рекомендуется использовать сетевой график Заказчика — инструмент разработки системного подхода для учета требований Заказчика. Сетевые графики разрабатывают для больших проектов. На рис. 4.5 представлен пример сетевого графика взаимодействия с Заказчиком [4.3]. Сетевой график обеспечивает прозрачность процесса работы с клиентом. 97 Составление целевого плана Зачем сотрудничать? Когда взаимодействовать? Как использовать? Подготовка выборки С кем общаться? Где находиться? Сколько доверенных лиц? Разработка рекомендаций для обсуждения Какая информация? У кого спросить? Значимая информация? Определение состава команды Кто? Хватит ли времени? Необходимо ли обучение? Общение с Заказчиком Обработка информации Встраивание информации в границы Продумана ли логистика? Уведомлен ли Заказчик? Состоялось ли встреча с Заказчиком? Собраны данные? Отчет написан? Опыт зафиксирован? Факторы ценности? Усвоено? Факторы в границах? Рис. 4.5. Пример сетевого графика взаимодействия с Заказчиком Результат процесса определения содержания: 1) описание содержания проекта, 2) обновленный подробный план управления содержанием проекта, 3) запрос на изменения. Рассмотрим результаты процесса определения содержания более подробно. Описание содержания проекта Описание содержания проекта, непосредственно или со ссылкой на другие документы, включает в себя следующее. Цели проекта. Цели проекта — это измеримые критерии его успешности, связанные с бизнесом, стоимостью, расписанием и качеством проекта. У каждой цели 98 проекта есть свои атрибуты: название (например, стоимость), единица измерения (например, доллар США) и абсолютное или относительное значение (например, не более 1,5 млн долларов). Определение содержания продукта. Описывает характеристики информационной системы, которые становятся более подробными на поздних фазах проекта по мере постепенного уточнения характеристик ИС. Требования к информационной системе. Отражают суммарный результат анализа потребностей пользователей ИС, пожеланий и ожиданий всех участников проекта, который преобразуется в перечень требований. В случае, когда имеется слишком много требований и все их выполнить в рамках проекта невозможно, необходимо выстроить перечень требований по приоритетам. Требования к проекту в целях обеспечения их четкого понимания со стороны руководителей и проектной команды уточняются и подтверждаются до начала работ. Границы проекта. Определяют в целом то, что включается в проект, и явно указывают, что в него не входит, чтобы исключить ситуацию, когда участник проекта ошибочно считает некоторый результат, услугу или результат входящими в проект. При определении границ проекта необходимо привлекать к работе системного архитектора, консультантов по внедряемой ИС. Как показывает практика, наиболее «узким местом» в определении границ проекта по разработке и внедрению ИС являются разрабатываемые формы отчетов. Если в содержании проекта указать «Разработать отчеты» и не задать в качестве границ проекта количество разрабатываемых отчетов, их наименования, то проект может быть никогда не закончен: у Заказчика может возникать необходимость в получении все новых и новых отчетов. Необходимо задокументировать все решения, связанные с границами проекта. Результаты поставки проекта. Результаты поставки включают в себя информационную систему, разработанную в ходе проекта, а также отчеты и документацию по управлению проектом. Критерии приемки ИС. Задают порядок и критерии приемки ИС и представляют собой набор стандартов или правил, определяющих выполнение задачи с приемлемым уровнем качества. Разработка и соответственно приемка ИС происходит по этапам. Сдачаприемка этапов выполненных работ осуществляется по предъявлении ИС и комплектов соответствующей документации и завершается оформлением акта сдачи-приемки. 99 Испытания ИС должны быть проведены на основании соответствующих программ и методик испытаний. Ограничения проекта. Перечисляет и описывает ограничения проекта, связанные с его содержанием и ограничивающие возможность выбора для команды проекта. К ним относятся, например, утвержденный предварительный бюджет или требуемые даты (контрольные события расписания), установленные заказчиком или исполняющей организацией. Когда проект выполняется по контракту, то в качестве ограничений обычно выступают условия контракта. Ограничения, перечисляемые в подробном описании содержания проекта, традиционно более многочисленны и детализированы по сравнению с перечисляемыми в Уставе проекта. Допущения проекта. Перечисляет и описывает допущения проекта, связанные с его содержанием, и потенциальный эффект этих допущений в случае, если они окажутся ложными. Команда проекта периодически идентифицирует, документирует и утверждает допущения в рамках процесса планирования. Допущения, перечисляемые в подробном описании содержания проекта, обычно более многочисленны и описываются подробнее, чем допущения, перечисленные в Уставе проекта и предварительном описании содержания проекта. Первоначальная организация проекта. На этом этапе определяются члены команды проекта и участники проекта, а также документально фиксируется организационная структура проекта. Изначально сформулированные риски. Перечисляются известные риски. Контрольные события расписания. Заказчик или исполняющая организация могут задать контрольные события и требуемые даты их выполнения. Эти даты могут быть обозначены в качестве ограничений на сроки. Ограничение финансирования. Описывает все ограничения, наложенные на финансирование проекта, как на уровне его общей стоимости, так и в указанных временных рамках. Сметная стоимость. Сметная стоимость проекта представляет собой ожидаемую общую стоимость проекта, и перед ней обычно ставится модификатор, указывающий на точность, концептуальную или окончательную. Требования к управлению конфигурацией проекта. Описывают уровень управления конфигурацией и изменениями, реализуемыми в проекте. 100 Спецификации проекта. Определяют спецификации, которым должен соответствовать проект. Требования к одобрению. Определяют требования к одобрению, применяющиеся к таким элементам, как цели проекта, результаты поставки проекта, документы и работа. План управления содержанием проекта (обновления) Эта составляющая плана управления проектом может потребовать обновления, а именно включения одобренных запросов на изменение в результате процесса определения содержания. Запрошенные изменения В ходе процесса определения содержания могут вырабатываться запрошенные изменения, затрагивающие план управления проектом и его вспомогательные планы. Запрошенные изменения обрабатываются в рамках процесса общего управления изменениями. Одним из основных моментов при определении содержания проекта является обеспечение максимальной устойчивости (сопротивляемости) к изменениям. Рекомендуется строить разработку содержания проекта по следующим принципам [4.3]: снижение сложности проекта путем деления на более мелкие подпроекты, для каждого из которых разрабатывается свое содержание; создание устойчивых продуктов/услуг, способных функционировать в широком диапазоне условий; фиксирование содержания на ранних этапах жизненного цикла проекта. Создание иерархической структуры работ Процесс создания иерархической структуры работ (ИСР) выполняет разбиение укрупненной структуры работ, представленной в документе «Предварительное описание содержания», на более мелкие, более управляемые элементы. В ИСР включаются работы, указанные в текущем одобренном описании содержания проекта. В процессе создания ИСР структурируется и определяется содержание всего проекта. Входной информацией для процесса создания ИСР являются описание содержания проекта, план управления содержанием проекта, активы организационного процесса, одобренные запросы на изменение (рис. 4.6). Для разработки ИСР PMBOK рекомендует использовать шаблоны иерархической структуры работ, декомпозицию, системный подход к составлению ИСР. 101 Шаблоны иерархической структуры работ Несмотря на уникальность каждого проекта, ИСР предыдущего проекта часто может служить шаблоном для нового проекта. Например, большая часть проектов внедрения ИС в конкретной организации будет иметь одинаковые жизненные циклы, а потому и одинаковые или схожие результаты каждой фазы. Стандарт Института управления проектами (PMI) для иерархической структуры работ содержит руководство по созданию, доработке и применению иерархических структур работ. В это руководство включены примеры шаблонов ИСР, которые можно адаптировать под конкретные проекты в конкретной области приложения. На рис. 6 показана часть шаблона ИСР с несколькими ответвлениями, разбитыми до уровня пакетов работ. Проект Фаза 1 Результат поставки 3 Фаза 2 Результат поставки 2.1 Результат поставки 2.2 Результат поставки 2.2.1 Результат поставки 2.3 Результат поставки 2.2.2 Подпроект 4 Результат поставки 4.1 Результат поставки 4.1.1 Пакет работ 2.2.1.1 Подпроект 2.2.2.1 Пакет работ 2.2.2.2 Подпроект 2.2.2.2 Подпроект п Результат поставки 4.m Результат поставки 4.1.2 Пакет работ 3.1. Результат поставки 4.1.х Пакет работ 4.1.2.1 Пакет работ 3.2 Пакет работ 4.1.2.2 Пакет работ 3.3 Пакет работ 2.2.2.3 Пакет работ 4.1.2.3 Пакет работ 2.2.2.2.1 Пакет работ 3.4 Пакет работ 2.2.2.2.2 Рис. 4.6. Шаблон иерархической структуры работ с несколькими ответвлениями, разбитыми до уровня пакетов работ [4.1] 102 Декомпозиция Декомпозиция — это инструмент, позволяющий выполнить разделение результатов поставки проекта на более мелкие, более управляемые элементы. Каждый следующий уровень иерархии более детально отражает элементы проекта. Декомпозиция выполняется до тех пор, пока работа и результаты поставки не определяются на уровне пакетов работ. Пакеты работ — это низшей уровень детализации, который менеджер проекта должен держать под своим непосредственным контролем. Далее пакеты работ могут разбиваться на операции, которые потом могут быть разбиты на задания. Уровень детализации будет варьироваться в зависимости от размера и сложности проекта. У разных результатов поставки могут быть разные уровни декомпозиции. Чрезмерная декомпозиция может привести к непродуктивной управленческой трудоемкости, неэффективному использованию ресурсов и снижению эффективности при выполнении работы. Команда проекта должна найти баланс между слишком малой и слишком большой детализацией планирования ИСР. Декомпозиция всей совокупности проектных работ включает следующие операции: 1. Определение результатов поставки и работ для их достижения, получаемых путем анализа подробного описания работ по проекту. Список работ определяется путем экспертной оценки результатов поставки. 2. Структурирование и организация ИСР — метод анализа, использующий шаблоны ИСР, структурирует результаты поставки и соответствующие проектные работы и представляет их в виде иерархической структуры. В зависимости от выбранного шаблона в итоге может получиться несколько разных видов структуры. В шаблонах в качестве первого уровня декомпозиции могут быть использованы подпроекты и основные результаты поставки (рис. 4.6) или фазы жизненного цикла проекта (рис. 4.7). 3. Разбиение верхних уровней ИСР на детализированные элементы нижних уровней. 4. Разработка и присвоение идентификационных кодов элементам ИСР. Проверка необходимости и достаточности степени декомпозиции работ, удовлетворяющей требованиям команды проекта к управлению и контролю, является методом анализа, который можно выполнять с использованием шаблона ИСР. При проверке корректности декомпозиции определяется, являются ли элементы ИСР нижнего уровня необходимыми и достаточными для достижения соответствующих результатов поставки на более высоких уровнях. 103 Системный подход к составлению ИСР По оценкам экспертов [4.2], путем декомпозиции определяется примерно 90% от общего объема работ. Системный подход позволяет увеличить точность декомпозиции. В соответствии с теорией управления системами вся работа рассматривается как система, в которой работа является процессом превращения входных элементов в выходные. Исходя из этого, проект внедрения может быть описан как процесс превращения входных элементов (ресурсов, трудозатрат и пр.) в выходные элементы, в нашем случае — в результаты поставки. Согласно теории управления системами, каждая задача нижнего уровня является процессом, превращающим входные элементы в выходные. Входом каждой задачи являются результаты другой части проекта или данные из источника, внешнего к проекту. Выходные элементы также должны быть входом в другие задачи или результатом поставки проекта. Каждый участник команды должен просмотреть созданную ИСР и проанализировать входы и выходы работы, за которую он отвечает. Все входные элементы должны исходить либо от других работ проекта, либо от внешнего источника. Аналогично, выходы должны быть либо результатом поставки, либо входом в другие работы. Такой просмотр позволит выделить лишние работы, выходы которых не используются в проекте, добавить недостающие и исключить дублирующие работы. Программный продукт Управление проектом Требования к продукту Подробное проектирование Разработка Интеграции и тестирование Планирование Программное обеспечение Программное обеспечение Программное обеспечение Программное обеспечение Совещания Пользовательская документация Пользовательская документация Пользовательская документация Пользовательская документация Администрирование Материалы для общей программы Материалы для общей программы Материалы для обучающей программы Материалы для обучающей программы Рис. 4.7. Пример иерархической структуры работ, организованной по фазам [4.1] 104 Выходные документы процесса создания ИСР Описание содержания проекта (обновления) Если одобренные запросы на изменение являются результатом создания ИСР, то в описание содержания проекта включаются эти одобренные изменения. Иерархическая структура работ Текущая иерархическая структура работ является ключевым документом процесса создания ИСР. Структура работ может быть представлена в виде древовидной структуры или в виде иерархического списка. Каждому элементу ИСР обычно присваивается уникальный идентификатор, который используется для иерархического структурирования информации о стоимости, расписании и ресурсах проекта. Словарь ИСР Словарь ИСР — документ, появляющийся при создании ИСР и обеспечивающий работу с ней. Словарь ИСР используется для расширения информации о каждом элементе ИСР. Каждый элемент словаря должен содержать описание элементарной работы, связанные с ней операции, ее стоимость и длительность, ответственного за эту работу и риски, связанные с этой работой. Базовый план по содержанию Базовый план по содержанию проекта состоит из одобренного подробного описания содержания проекта, включающего ИСР и словарь ИСР. При разработке базового плана по содержанию появляются исключенные элементы — работы, ранее считавшиеся полезными для проекта. Эти элементы должны быть документированы как исключения проекта, поскольку недокументированные исключения могут снова появиться в качестве новых требований участников проекта. Базовый план по содержанию проекта является основой для составления двух других базовых планов проекта: базового плана по стоимости и базового расписания. План управления содержанием проекта (обновления) Если одобренные запросы на изменения являются результатом создания ИСР, то одобренные изменения могу быть включены в план управления содержанием проекта. Запрошенные изменения В процессе создания ИСР могут появляться запрошенные изменения описания содержания проекта и его элементов, обрабатываемые в рамках процесса общего управления изменениями. 105 Подтверждение содержания Процесс подтверждения содержания формализует принятие завершенных результатов поставки проекта. Подтверждение содержания — это формальное принятие участниками проекта завершенного содержания проекта и относящихся к нему результатов поставки. Процесс подтверждения содержания проекта включает в себя проверку наличия всех работ, обеспечивающих результаты поставки. Если выполнение проекта прекращается досрочно, процесс подтверждения содержания должен установить и документировать уровень и степень его выполнения. Входной информацией процесса являются: описание содержания проекта; словарь ИСР; план управления содержанием проекта; результаты поставки. Подтверждение содержания выполняется методом инспекции, который включает в себя такие операции, как измерение, изучение и проверка, и служит для определения соответствия работ результатам поставки, требованиям и критериям приемки продукта. (Иногда метод инспекции называют аудитом, проверкой, контролем.) Процесс подтверждения содержания имеет нижеследующие результаты. Принятые результаты поставки. Процесс подтверждения содержания документирует результаты поставки, которые прошли приемку. Непринятые результаты поставки документируются с указанием причин, по которым они не прошли приемку. Подтверждение содержания включает в себя сопроводительную документацию, полученную от Заказчика или Спонсора и подтверждающую факт приемки результатов поставки участниками проекта. Запрошенные изменения. Запрошенные изменения могут появиться в ходе процесса подтверждения содержания и рассматриваются в ходе процесса общего управления изменениями. Рекомендуемые корректирующие действия. Корректирующие действия — это документированные рекомендации, необходимые для приведения ожидаемого хода исполнения проекта в соответствие с планом управления проектом. 106 Управление изменениями содержания Процесс управления содержанием выполняет управление изменениями содержания проекта. Управление содержанием состоит в управлении изменениями содержания проекта. Управление содержанием проекта заключается в воздействии на факторы, создающие изменения содержания проекта, и контролировании производимого этими изменениями эффекта. Управление содержанием призвано обеспечить, чтобы все запрошенные изменения и рекомендованные корректирующие действия проходили через процесс общего управления изменениями. Управление содержанием проекта используется также для управления текущими изменениями по мере их появления; оно интегрировано в остальные процессы управления. Неконтролируемые изменения часто называют также сдвигом содержания проекта. В любом проекте изменения неизбежны, поэтому необходим процесс управления изменениями. Входная информация процесса: описание содержания проекта; иерархическая структура работ; словарь ИСР; план управления содержанием проекта; отчеты об исполнении; Отчеты об исполнении дают информацию о выполнении проектных работ, в частности, о достигнутых промежуточных результатах. одобренные запросы на изменение; Одобренный запрос на изменение, оказывающий влияние на содержание проекта, — любое изменение в согласованном базовом плане проекта, ИСР и словаре ИСР. информация об исполнении работ. Инструменты и методы Система управления изменениями. Система управления изменениями содержания проекта (документально оформленная в плане управления содержанием проекта) определяет процедуры, посредством которых могут быть изменены содержание проекта и содержание продукта. Эта система включает в себя документацию, системы отслеживания и уровни одобрения, необходимые для одобрения изменений. Для контроля содержания 107 проекта система управления изменениями содержания интегрируется с любой информационной системой общего управления проектом. Анализ отклонений. Для оценки величины отклонений используются измерения эффективности проекта. Важные аспекты контроля содержания проекта включают в себя определение причины отклонений по сравнению с базовым планом по содержанию и принятие решения о необходимости корректирующих действий. Корректировка планов. Одобренные запросы на изменения, оказывающие влияние на содержание проекта, могут повлиять на ИСР и словарь ИСР, описание содержания проекта и план управления содержанием проекта. Эти одобренные запросы на изменения могут потребовать обновления компонентов плана управления проектом. Система управления конфигурацией. Формальная система управления конфигурацией определяет процедуры для каждого состояния результатов поставки. Ее целью является обеспечение надлежащего рассмотрения и фиксации запрошенных изменений содержания проекта, перед тем как они будут обработаны в рамках процесса общего управления изменениями. Выходы процесса Описание содержания проекта (обновления). Если одобренные запросы на изменения влияют на содержание проекта, то описание содержания проекта редактируется, и в новую редакцию включаются эти одобренные изменения. Обновленное описание содержания проекта становится новым базовым планом проекта для будущих изменений. Иерархическая структура работ (обновления). Если одобренные запросы на изменения влияют на содержание проекта, то ИСР редактируется и в новую редакцию включаются эти одобренные изменения. Словарь ИСР (обновления). Если одобренные запросы на изменения влияют на содержание проекта, то словарь ИСР редактируется и в новую редакцию включаются эти одобренные изменения. Базовый план по содержанию (обновления) Запрошенные изменения. В результате управления содержанием проекта могут появляться запрошенные изменения, обрабатываемые для рассмотрения и распоряжения в соответствии с процессом общего управления изменениями. Рекомендуемые корректирующие действия. Рекомендуемое корректирующее действие представляет собой любой рекомендованный шаг в целях приведения ожидаемой 108 будущей эффективности проекта в соответствие с планом управления проектом и описанием содержания проекта. Активы организационного процесса (обновления). Причины отклонений, логика выбора конкретного корректирующего действия и прочие виды накопленных знаний из системы управления изменениями содержания проекта документируются и обновляются в исторической базе данных активов организационного процесса. План управления проектом (обновления). Если одобренные запросы на изменения каким-либо образом затрагивают содержание проекта, то создается новая редакция документов и базового плана по стоимости для соответствующего элемента, а также базовых планов по стоимости, входящих в план управления проектом. В новую редакцию включаются эти одобренные изменения. 109 Лекция 5. УПРАВЛЕНИЕ СРОКАМИ ПРОЕКТА Определение состава операций. Инструменты и методы. Список плановых операций. Параметры операций. Список контрольных событий. Определение взаимосвязи операций. Оценка ресурсов операций. Инструменты и методы. Требования к ресурсам операции. Календарь ресурсов. Оценка длительности операций. Понятие длительности операций, периода времени выполнения операций. Разработка расписания. Базовый план расписания. Управление расписанием. Отчетность о прогрессе проекта. Анализ отклонений по срокам. Управление расписанием. Ключевые слова: пакет операций, список операций, параметры операций, взаимосвязи операций, контрольные события (вехи проекта), ресурсы операции, календарь ресурсов проекта, длительность операции, расписание проекта, базовый план расписания проекта. Процессы управления сроками проекта Согласно РMBOК [4.1], управление сроками проекта (time management) — это процесс, используемый для обеспечения своевременного завершения проекта. Управления сроками проекта состоит из шести процессов [4.1]. Определение состава операций — процесс определения конкретных плановых операций, которые необходимо выполнить для получения результатов проекта — внедрения ИС. Определение взаимосвязей операций — процесс выявления и документирования последовательности выполнения плановых операций. Определение ресурсов операции — процесс определения необходимых для выполнения каждой плановой операции ресурсов и их количества. Определение длительности операций — процесс определения продолжительности выполнения каждой плановой операции. Разработка расписания — процесс составления расписания проекта с учетом последовательностей операций, их длительности, требований к ресурсам и ограничений на сроки выполнения проекта в целом. 110 Управление расписанием — процесс управления изменениями расписания проекта. Первые пять процессов относятся к группе процессов планирования, шестой — к группе процессов мониторинга и управления. Процессы взаимодействуют как между собой, так и с процессами из других областей знаний. Процессам управления сроками проекта предшествует процесс планирования, определяющий формат и критерии разработки и контроля расписания проекта, управления проектом, в ходе которого разрабатывается план управления расписанием. План управления расписанием входит в план управления проектом, либо является его вспомогательным планом. На рис. 5.1 показана последовательность процессов, приводящая к разработке расписания проекта и затем к управлению расписанием. Разработка расписания проекта начинается с определения состава операций. После того как операции определены, между ними устанавливаются взаимосвязи. Чтобы определить длительность операций, следует назначить специалистов, которые будут выполнять операции, — уровень их квалификации имеет определяющее значение. Рассмотрим подробнее, каким образом определяются операции проекта, их взаимосвязи, требуемые ресурсы, длительность операций, как составляется расписание проекта и осуществляется управление им. 111 Методология внедрения ИС Контракт Описание содержания проекта ИСР Словарь ИСР Запрошенные изменения Определение состава операций Список операций Параметры операций Список контрольных событий Методология внедрения ИС Описание содержания проекта Определение взаимосвязи операций Сетевые диаграммы расписания проекта Список операций (обновления) Параметры операций (обновления) Наличие ресурсов Оценка ресурсов операций План управления проектом План управления содержанием проекта Одобренные запросы на изменения Одобренные корректирующие действия Запрошенные изменения Плен управления проектом (обновления) Одобренные запросы на изменение Запрошенные изменения Требования к ресурсам операций Иерархическая структура ресурсов Календари ресурсов (обновления) Наличие ресурсов Экспертная оценка длительности операций Реестр рисков Оценка длительности операций Оценка длительности операций Наличие ресурсов Реестр рисков Отчеты об исполнении План управления расписанием Базовый план расписания Одобренные запросы на изменения Разработка расписания Расписание проекта Базовый план расписания Требования к ресурсам (обновления) Календарь проекта проекта(обновления) Управление расписанием Запрошенные изменения Рекомендованные корректирующие действия Запрошенные изменения План управления проектом (обновления) Список операций (обновления) Параметры операций (обновления) План управления проектом (обновления) Расписание проекта (обновления) Базовый план расписания (обновления) Запрошенные изменения Рекомендованные корректирующие действия Рис. 5.1. Связь процессов управления сроками проекта 112 Определение состава операций Определение состава операций предполагает определение и документирование работ, запланированных для выполнения. Инструментальным средством для определения состава операций, а также для оценки их взаимосвязи и длительности, служит ИСР. В предыдущем разделе был рассмотрен вопрос создания иерархической структуры работ путем декомпозиции. Напомним, что результатом процесса декомпозиции является нижний уровень работ, необходимых для завершения проекта. В процессе декомпозиции определяется нижний уровень управления, с которым работает руководитель проекта, — уровень пакетов работ. Пакеты работ, как правило, определяются Методологией внедрения ИС. Пакет работ состоит из операций, имеющих общие функции или конечный результат. Пакеты работ разбивают на операции. Операция — это единица работ, в результате которой имеется конкретный результат по внедрению информационной системы. Перед началом определения состава операций рекомендуется еще раз проанализировать описание содержания проекта, ограничения и допущения с точки зрения полноты списка операций, который будет основой для составления смет, планирования сроков выполнения и контроля проектных работ. Состав операций может определяться последовательно, методом набегающей волны. Этот метод применяется в крупных или долгосрочных проектах, когда имеется неопределенность относительно выполнения некоторых работ. При использовании метода набегающей волны пакеты работ, расположенные в отдаленном будущем, планируются только на высоком уровне, в то время как пакеты работ, расположенные ближе по оси времени, планируются детально. Входная информация для процесса определения состава операций Входом для процесса определения состава операций являются [4.1]: методология внедрения ИС; контракт; описание содержания проекта; иерархическая структура работ (ИСР); словарь ИСР. 113 Инструменты и методы Для определения состава операций используют следующие инструменты и методы: декомпозиция; шаблоны; планирование методом набегающей волны; экспертная оценка. Выходы процесса определения состава операций Процесс определения состава операций завершается формированием нижеследующих документов [4.1]. Список операций — перечень работ, запланированных для выполнения. Параметры операций — могут включать в себя идентификатор операции, коды операции, длительность, начало, окончание, исполнителя операции, перечни предшествующих и последующих операций, логические взаимосвязи, опережения и задержки, плановую трудоемкость работ и другие необходимые для управления проектом параметры операций. Список контрольных событий (вех проекта) — определяет все контрольные события расписания, необходимые для мониторинга хода выполнения и для управления проектом. Список контрольных событий является элементом плана управления проектом. Веха проекта определяет момент перехода проекта из одного состояния в другое. Важным отличием вех от операций проекта является то, что они не имеют длительности. Запрошенные изменения — изменения в составе работ, которые могут появиться в ходе выполнения работ по внедрению ИС и повлиять на описание содержания проекта. Примеры состава операций и контрольных событий (вех проекта) представлены в таблицах 5.1. и 5.2. Таблица 5.1. Пример списка состава операций Наименование Наименование операций пакета работ Формирование и согласование плана проведения интервью Обследование Подготовка и рассылка опросных листов для интервью Проведение интервью для описания бизнес-процессов 114 Наименование Наименование операций пакета работ Описание бизнес-процессов по функциональной области Финансы. Описание бизнеспроцессов Описание бизнес-процессов по функциональной области Логистика. Описание бизнес-процессов по функциональной области Персонал Разработка решений по функциональной архитектуре. Подготовка функционального дизайна расширений. Настройка системы. Разработка системы Техническое проектирование расширений. Разработка расширений. Техническое проектирование программ конвертации данных Разработка программ конвертации данных Планирование тестирования приложения и интеграционного тестирования Разработка сценариев тестирования Подготовка тестовых данных Тестирование системы Проведение тестирования по функциональным областям Финансы, Логистика, Персонал Проведение интеграционного тестирования Проведение тестирования конвертации данных 115 Таблица 5.2. Пример списка вех проекта Вехи проекта Входящие вехи проекта: Начало работ акцептовано Заказчиком Рабочие места подготовлены Команда проекта сформирована Подготовлено и проведено стартовое совещание Утверждено расписание проекта Вехи проекта: Завершен сбор информации для описания бизнес-процессов Обследование завершено Завершена разработка системы Завершено приемочное тестирование Завершено тестирование производительности Готовность к конвертации данных Готовность к развертыванию системы Планирование сроков проекта может быть выполнено с помощью специализированных программных средств. Пример планирования сроков работ в специализированной системе MS Project приведен на рис. 5.2. 116 Рис. 5.2. Планирование работ в MS Project Определение взаимосвязи операций Процесс определения взаимосвязей операций включает в себя идентификацию и документирование логических взаимосвязей между плановыми операциями. Взаимосвязи операций могут быть последовательными, с собственными отношениями предшествования, а также опережениями и задержками. В этом случае каждый выходной элемент операции используется как входной элемент другой операции или является частью поставки. Взаимосвязи операций могут быть с перекрытиями, когда еще незавершенная операция имеет достаточно выходных элементов для начала зависящей от нее операции, или с параллельным выполнением операций. 117 Входная информация для процесса определения взаимосвязи операций Входами для процесса определения взаимосвязи операций могут быть [4.1]: 1. Описание содержания проекта — содержит определение содержания продукта, включающее в себя характеристики продукта, которые могут повлиять на определение взаимосвязей операций, поэтому во избежание ошибок следует повторно проанализировать определение содержания продукта; 2. Методология внедрения ИС; 3. Список операций — выход процесса определения состава операций; 4. Параметры операций — выход процесса определения состава операций; 5. Список контрольных событий — выход процесса определения состава операций; 6. Одобренные запросы на изменение — выход процесса определения состава операций. Методы и инструменты При определении взаимосвязи используются нижеследующие инструменты и методы. Метод предшествования — это метод построения сетевых диаграмм расписания проекта, в котором операции изображаются в виде прямоугольников (называемых «узлами»), а зависимости — соединяющими их дугами. Этот метод еще называется «операции в узлах», он используется в большинстве пакетов программного обеспечения для управления проектами. В этом методе существует четыре типа отношений предшествования: Финиш-старт. Инициация последующей операции зависит от завершения предшествующей операции (работа В не может начаться до завершения работы А); Финиш-финиш. Завершение последующей операции зависит от завершения предшествующей операции (работа В должна окончиться не раньше завершения работы А); Старт-старт. Инициация последующей операции зависит от инициации предшествующей операции (работа В начинается не раньше работы А); 118 Старт-финиш. Завершение последующей операции зависит от инициации предшествующей операции (работа В должна продолжаться, пока не начнется работа А); Гамак — работа В начинается с окончания работы А и продолжается до начала работы С. Для более полного понимания и практического применения Метода предшествования проанализируем отдельные операции, представленные на рис. 5.2. Так, например, операции № 11 и № 9 относятся к типу Финиш-старт. Операция № 11 «Проведение интервью для описания бизнес-процессов» не может начаться до завершения операции №9 «Формирование и согласование плана проведения интервью». К этому же типу относятся операции № 14 и № 11. Действительно, операция № 14 «Описание бизнеспроцессов» не может начаться до того, как будут проведены интервью: интервью являются источником информации для описания бизнес-процессов. Примером операций типа Стартстарт могут служить операции 28 и 29 (рис. 5.2). Операция 29 «Подготовка тестовых данных» должна начинаться не раньше операции 28 «Разработка сценариев тестирования». На рис. 5.3 в графической форме представлены все типы связей. В методе предшествования чаще всего используется отношение предшествования типа Финиш-старт и редко применяются отношения Старт-финиш. . 119 Работа А Работа В Работа А Работа В Работа А Работа В Работа А Работа В Работа А Работа С Работа В Рис. 5.3. Типы связей операций Метод стрелочных диаграмм. Метод стрелочных диаграмм — это метод построения сетевых диаграмм расписания проекта, где операции представляются в виде дуг, которые соединяются в узлах, показывающих их зависимости. Этот метод еще называется «операции на дугах». Шаблоны расписания сети. Стандартизированные шаблоны сетевых диаграмм расписания проекта могут использоваться для ускорения подготовки сетей плановых операций проекта. Они могут включать в себя как весь проект в целом, так и его часть. 120 Определение зависимостей. Для определения последовательности операций используется три типа зависимостей. Жесткая или обязательная зависимость — зависимость, при которой последовательность работ не может изменяться. Обязательные зависимости являются неотъемлемым свойством выполняемой работы и часто подразумевают физические ограничения на последовательность выполнения операций. Нежесткая или произвольная зависимость — последовательность определяется командой проекта и может изменяться. Внешняя зависимость — последовательность работ определяется внешними по отношению к проекту воздействиями. Внешние зависимости включают взаимоотношения операций проекта с непроектными операциями. Например, в проекте по разработке программного обеспечения сроки операции тестирования могут зависеть от поставки аппаратного обеспечения сторонней организацией. Применение опережений и задержек. Опережения и задержки представляют собой интервалы времени, которые модифицируют взаимосвязи между предшествующими и последующими операциями. Опережения и задержки обозначаются знаками плюс (для задержки) и минус (для опережения) перед количеством периодов времени. На рис. 5.4 представлено графическое изображение операции с задержкой — работа Б начнется через 5 дней после окончания работы. Работа А FS + 5 Работа Б Рис. 5.4. Изображение операции Финиш-старт с задержкой на 5 дней Команда управления проектом определяет зависимости, для которых корректное определение логических взаимосвязей может вызвать опережение или задержку выполнения операции. Опережение позволяет ускорить последующую операцию. Например, системный архитектор проекта и программисты могут приступить к разработке функциональности системы по Логистике, не дожидаясь окончания описания бизнеспроцессов по функциональности Финансы, Персонал. 121 Примером операции типа Финиш-старт с опережением могут служить операции «Разработка сценариев тестирования» и «Подготовка тестовых данных». Целесообразно приступить к подготовке тестовых данных до момента полного завершения разработки сценариев тестирования, т. е. начать работу с опережением. Например, за 5 дней до завершения разработки сценариев тестирования уже будет достаточно материала, чтобы начать подготовку тестовых данных. Выходы процесса определения взаимосвязи операций Сетевые диаграммы расписания проекта — схематическое отображение плановых операций проекта и логических взаимосвязей (зависимостей) между ними. Сетевая диаграмма расписания проекта может быть построена вручную или при помощи программного обеспечения для управления проектом, например, Spider или MS Project. Она может включать в себя полную детализацию проекта или одну или несколько суммарных операций (пакет операций). На рис. 5.5 приведен пример представления расписания проекта в виде диаграммы Гантта MS Project. Список операций (обновления). Если одобренные запросы на изменения являются результатом процесса определения взаимосвязей операций, то создается обновленный список операций, включающий в себя эти изменения. Параметры операции (обновления). Если одобренные запросы на изменения, являющиеся результатом процесса определения взаимосвязей между операциями, оказывают влияние на список операций, то в соответствующие элементы параметров операций включаются эти одобренные изменения (логические взаимосвязи и соответствующие опережения и задержки). Запрошенные изменения. При разработке логических взаимосвязей, опережений и задержек проекта могут быть выявлены моменты, которые повлекут за собой запрос на изменение списка операций или параметров операций. Запрошенные изменения рассматриваются и утверждаются в рамках процесса общего управления изменениями. 122 Рис. 5.5. Фрагмент расписания проекта в виде диаграммы Гантта MS Project Оценка ресурсов операций Оценка ресурсов плановой операции призвана определить, какие ресурсы (человеческие ресурсы, оборудование) будут использоваться и в каком количестве и когда каждый из ресурсов будет доступен для выполнения проектных операций. Процесс оценки ресурсов операций тесно координируется с процессом оценки стоимости, который будет рассмотрен в следующей лекции. Входы процесса оценки ресурсов операций Входами для данного процесса являются: Список операций. Список операций определяет плановые операции для оцениваемых ресурсов; Параметры операций. определении состава Параметры операций, дают операций, вход разработанные первичных данных при для 123 использования в оценке ресурсов, необходимых для каждой плановой операции в списке операций; Наличие ресурсов. Для оценки типов ресурсов используется информация о том, какие ресурсы (функциональные консультанты, бизнес-аналитики, серверы и т. п.) потенциально доступны; План управления проектом. План управления расписанием является составляющей частью плана управления проектом и используется в оценке ресурсов операций. Инструменты и методы Инструменты и методы, используемые при оценке ресурсов операций: Экспертная оценка — часто необходима для того, чтобы оценить ресурсные входы этого процесса. Такую оценку может дать экспертная группа, имеющая специальную подготовку в области планирования и оценки ресурсов; Программное обеспечение для управления проектами — помогает планировать, организовывать фонды ресурсов и управлять ими, а также разрабатывать оценки ресурсов. В зависимости от сложности программного обеспечения можно определять иерархические структуры ресурсов, наличие ресурсов и их текущую стоимость, а также различные календари ресурсов; Оценка «снизу вверх». Когда плановую операцию нельзя оценить с достаточной степенью уверенности, то работы в пределах такой операции разбиваются на более мелкие элементы. Ресурсные потребности каждого более детализированного элемента работ оцениваются, и эти оценки объединяются в общее количество по каждому ресурсу плановой операции. Плановые операции могут быть связаны отношениями зависимости, которые могут влиять на привлечение и использование ресурсов, но могут и не иметь такой связи. Если отношений зависимости нет, то эта специфика применения ресурсов отражается в оценочных требованиях плановой операции и фиксируется документально. Выходы процесса оценки ресурсов операций Результатом процесса оценки ресурсов операций является следующая информация. Требования к ресурсам операции. Выход процесса оценки ресурсов операций представляет собой определение и описание типов и количества ресурсов, необходимых 124 для каждой плановой операции в пакете работ. Эти требования можно затем собрать в единое целое для определения оценочных ресурсов по каждому пакету работ. Детализация и уровень специфичности требований к ресурсам могут варьироваться в зависимости от области приложения. В документацию по требованиям к ресурсам для каждой плановой операции может входить оценочная база для каждого ресурса, а также допущения по типам ресурсов, их наличию и количеству. Процесс разработки расписания определяет потребность в тех или иных ресурсах. На рис. 5.6 представлен фрагмент таблицы «Ресурсы», содержащей следующие параметры: название ресурса, его код, количество, стоимостную оценку (фактическую и плановую), длительность и др. Рис. 5.6. Фрагмент таблицы «Ресурсы», выполненной в системе управления проектом Spider Параметры операции (обновления). Виды и количество ресурсов, необходимых для каждой плановой операции, включаются в параметры операций. Если одобренные запросы на изменения являются результатом процесса оценки ресурсов операций, то создается обновленная версия списка операций и параметров операций, куда включаются эти изменения. Иерархическая представляет собой структура иерархическую ресурсов. структуру Иерархическая структура идентифицированных ресурсов ресурсов по категориям и типам ресурсов. Календарь ресурсов (обновления). Сводный календарь ресурсов проекта документирует рабочие и нерабочие дни, определяющие даты, на которые данный ресурс (персонал, сервер и т. п.) может быть активным или не задействован. Календарь ресурсов проекта, в частности, отмечает выходные для данного ресурса дни и периоды доступности 125 ресурса. Календарь ресурсов проекта назначает количество каждого доступного ресурса по каждому периоду доступности. Рис. 5.7. Календарь проекта Запрошенные изменения. Результатом процесса оценки ресурсов операции могут стать добавление в списке операций новых плановых операций или удаление из него старых; эти изменения оформляются как запрошенные изменения. Запрошенные изменения рассматриваются и утверждаются в рамках процесса общего управления изменениями. Оценка длительности операций Длительность операции — это продолжительность времени, необходимого для выполнения операции. Длительность может измеряться количеством дней, в течение которых человек (или несколько человек) трудился над данной операцией. Процесс оценки длительности плановых операций использует информацию о содержании работ операции, требуемых ресурсов, календарях ресурсов с указанием их доступности. Оценка длительности может уточняться в ходе выполнения проекта. Процесс оценки длительности операций требует, чтобы были оценены объем работы, расчетное количество ресурсов и определено количество рабочих. Оценка длительности операции проводится с помощью ИСР. 126 Рис. 5.8. Диаграмма Гантта с привязкой к ресурсам Общая длительность проекта рассчитывается как выход процесса разработки расписания. Входы процесса определения длительности операций Описание содержания проекта. При оценке длительности плановых операций учитываются ограничения и допущения, взятые из описания содержания проекта. Примером ограничения могут служить операции по сдаче документов, проверки, редактирования и аналогичные непродуктивные плановые операции, частота и продолжительность которых, как правило, указывается в контракте или в корпоративных правилах исполняющей организации. Список операций — выход процесса определения взаимосвязи операций. Параметры операций — выход процесса определения взаимосвязи операций. Требования к ресурсам операции. Расчетные требования к ресурсам операции влияют на длительность плановой операции, так как привлеченные для плановой операции ресурсы и их наличие будет в значительной мере влиять на длительность большинства операций. Например, продолжительность разработки сценариев тестирования разрабатываемой ИС будет зависеть от количества консультантов-аналитиков, длительность тестирования разрабатываемой информационной системы будет зависеть от количества тестировщиков и т. д. Можно распределить разработку сценариев тестирования между консультантами127 аналитиками по группам автоматизируемых бизнес-процессов, и тогда длительность плановой операции будет меньше той, где тот же объем работы выполнял бы один человек. Аналогично, за тестировщиками можно закрепить отдельные модули системы или группы бизнес-процессов и тем самым сократить время плановых операций по тестированию. Календарь ресурсов — выход процесса оценки ресурсов операций. План управления проектом включает в себя реестр рисков и проектные сметы. Реестр рисков содержит информацию об идентифицированных рисках проекта, рассматриваемых командой проекта при подготовке оценок длительности операций и ее корректировке с учетом рисков. Оценка стоимости проектных операций показывает расчетные объемы ресурсов по каждой плановой операции. Инструменты и методы Оценка по аналогам подразумевает оценку фактической длительности аналогичной предыдущей плановой операции в качестве основы для оценки длительности будущей плановой операции и использует историческую информацию и экспертную оценку. Параметрическая оценка. Оценочную величину длительности операций можно вычислить путем умножения количества работы на производительность труда. Для определения длительности операций по рабочим периодам общее количество ресурсов умножается на количество рабочего времени или производительность за рабочий период и делится на количество привлеченных ресурсов. Оценка по трем точкам. Точность оценки длительности операций можно увеличить, если в исходной оценке учитывать размер рисков. Оценка по трем точкам основана на определении трех типов оценок: Наиболее вероятная — длительность плановой операции с учетом предварительного выделения ресурсов, их производительности, реалистичной оценки их доступности для выполнения данной плановой операции, отношений зависимости с другими участниками, задержек. Оптимистичная. Длительность операции основывается на оптимистичном сценарии, представленном в наиболее вероятной оценке. Пессимистичная. Длительность операции основывается на пессимистичном сценарии, представленном в наиболее вероятной оценке. 128 Оценка длительности операции может быть выведена с использованием средней из трех оценок длительности. Длительность операции = (наиболее вероятная оценка + оптимистичная + пессимистичная)/3 Анализ резервов. Команда проекта может принять решение о добавлении дополнительного времени в общее расписание проекта, называемого резервом на непредвиденные обстоятельства, временным резервом или буфером, в качестве учета рисков нарушения графика. Резерв на непредвиденные обстоятельства можно использовать полностью или частично, его можно впоследствии сократить или убрать вовсе по мере появления более точной информации. Выходы процесса оценки длительности операций Оценка длительности операций. Количественные оценки вероятного числа рабочих периодов, которые потребуются для выполнения операции, всегда включает оценки диапазонов возможных значений. Например, оценка «2 недели ± 2 дня» означает, что плановая операция будет выполняться не менее 8 дней и не более 12 (при 5-дневной рабочей неделе). Параметры операции (обновления). Параметры операции обновляются каждый раз, когда изменяются длительность плановых операций, допущения, сделанные при оценке длительности операций, и различные резервы на непредвиденные обстоятельства. 129 Разработка расписания Разработка расписания проекта — итеративный процесс, определяющий плановые даты начала и завершения операций проекта. Разработка расписания производится непрерывно по мере выполнения работ проекта. При этом может потребоваться проверять и редактировать оценки длительности и ресурсов, чтобы в итоге получить одобренное расписание проекта. Согласованное расписание используется как базовое, по которому будет оцениваться прогресс рисков. Входы процесса разработки расписания Исходной информацией для процесса разработки расписания является: Описание содержания проекта. Включает допущения (документированные факторы, относящиеся к расписанию, которые при разработке расписания считаются достоверными) и ограничения (факторы, ограничивающие свободу выбора команды управления проектом при проведении анализа сети расписания и влияющие на составление расписания проекта). При разработке расписания учитываются два основных типа ограничений по времени: Требуемые даты для начала или завершения операции, которые можно использовать для ограничения начала или завершения операции. Контрольные события, вследствие чего получение определенных результатов работ привязывается к определенным датам, изменить которые можно только посредством одобренных изменений. Список операций — выход процесса определения взаимосвязи операций. Параметры операций — выходы процесса оценки длительности операций. Сетевые диаграммы расписания проекта — выходы процесса определения взаимосвязи операций. Требования к ресурсам операции — выход процесса оценки ресурсов операций. Календари ресурсов — выход процесса оценки ресурсов операций. Оценка длительности операций — выходы процесса оценки длительности операций. План управления проектом содержит План управления расписанием, План управления стоимостью, План управления содержанием проекта и План управления рисками. В соответствии с этими Планами выполняется разработка расписания и 130 вспомогательных элементов, необходимых в процессе разработки расписания, одним из которых является реестр рисков. Реестр рисков содержит риски проекта и соответствующие мероприятия по реагированию на риски, необходимые для обслуживания процесса разработки расписания. Инструменты и методы Анализ сети расписания представляет собой технологию создания расписания проекта и выполняется с помощью модели расписания. Существуют различные методы анализа: метод критического пути, метод критической цепи, анализ возможных сценариев и выравнивание ресурсов для расчета дат раннего и позднего старта и финиша и расчетных дат начала и завершения для незавершенных частей плановых операций проекта. Метод критического пути — метод анализа сети расписания, проводимого при помощи модели расписания. При методе критического пути рассчитываются теоретические даты раннего старта и раннего финиша и позднего старта и позднего финиша для всех плановых операций без учета ограничений по ресурсам. Этот расчет производится путем проведения анализа прямого и обратного проходов по путям сети расписания проекта. Полученные даты раннего и позднего старта и финиша показывают периоды времени, в пределах которых следует планировать данную операцию, исходя из ее длительности, логических взаимосвязей, опережений, задержек и прочих ограничений. Ранний старт (в методе критического пути) — самый ранний из возможных моментов времени, в который могут начаться плановые операции проекта. Ранний финиш — самый ранний из возможных моментов времени, в который могут завершиться плановые операции проекта. Ранний старт и ранний финиш вычисляются на основании логики сети расписания, отчетной даты и любых ограничений на расписание и могут меняться по ходу исполнения проекта и внесения изменений в план управления проектом. Поздний старт — самый поздний момент времени, в который может быть начата плановая операция, определяемый на основании логики сети расписания, даты завершения проекта и любых ограничений в отношении плановых операций без нарушения ограничений на график или отсрочки даты завершения проекта. Поздний финиш — самый поздний момент времени, в который может быть завершена плановая операция. Поздний старт и поздний финиш определяются с помощью Обратного прохода в сети расписания проекта. Прямой проход — вычисление ранних сроков начала и завершения невыполненных частей всех операций. Обратный проход — определение позднего 131 финиша и позднего старта незавершенных частей всех плановых операций. Определяется в результате расчета проекта от даты завершения проекта к началу на основании логики сети расписания. Дата завершения определяется в результате прямого прохода или задается Заказчиком или Спонсором проекта. Даты раннего старта и раннего финиша и позднего старта и позднего финиша могут не совпадать. Разность между ранними и поздними датами называется временным резервом. У критических путей общий временной резерв равен нулю, а плановые операции на критическом пути называются «критическими операциями». Если временной резерв имеет отрицательное значение, то могут потребоваться корректировки длительности операций, логических взаимосвязей, опережений, задержек и прочих ограничений. Гибкость расписания определяет «свободный временной резерв» — количество времени, на которое плановая операция может быть отложена, не вызывая задержки раннего старта непосредственно примыкающей последующей операции на данном сетевом пути. Критический путь — это группа операций, которые не могут быть задержаны без задержки даты завершения всего проекта, или последовательность операций, имеющих нулевой временной резерв [4.2]. Рассмотрим пример построения сетевой модели и определения критического пути. Требуется составить сетевую модель по заданной технологии выполнения работ проекта, приведенных в таблице 5.3. Необходимо определить резервы работ и критический путь проекта. Работы выполняются каждый день, без учета выходных, с возможностью привлечения необходимых ресурсов. Считаем датой начала проекта 1.01.08. Таблица 5.3. Технология выполнения работ № Предыд работы ущая работа Последу ющая работа Продолжител ьность работы, дн. 1 - 3, 4 2 2 - 5 3 3 1 6 4 4 1 6 6 5 2 7 7 132 6 3,4 8 10 7 5 8 12 8 7,6 - 5 В таблице 5.3 указано, что у работ 1 и 2 нет предшествующих работ, после работы № 1 должны следовать работы 3 и 4, за работой № 2 должна следовать работа 5 и т. д. Работа 8 является завершающей, по данным таблицы 5.2 у нее нет последующих работ. Сетевая модель, соответствующая рассматриваемой технологии выполнения работ, представлена на рис. 5.9. 3 6 1 4 8 2 5 7 Рис. 5.9. Сетевая модель технологии выполнения работ Построим таблицу, в которой для каждой операции отведены по две строки. Первые строчки каждой операции отмечают интервал выполнения операции при прямом проходе, вторые — при обратном. Даты начала и завершения каждой операции при прямом проходе определяются на основании логики сети расписания (рис. 5.9) и продолжительности операций (таблица 5.3). данных о Дата завершения получается в результате прямого прохода. При обратном проходе даты начала и конца операций определяются в 133 результате расчета проекта от даты завершения проекта к началу также с использованием логики сети расписания и данных о продолжительности операций (таблица 5.3). 134 Таблица 5.4. Временные интервалы выполнения операций при прямом и обратном проходах № операции Даты выполнения операций 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 1 2 3 4 5 6 7 8 135 Используя даты прямого и обратного проходов таблицы 5.4, построим следующую таблицу для вычисления временного резерва операции (таблица 5.5). РН РО ПН ПО Резерв я Операци Таблица 5.5. Временный резерв операции 1 1 2 6 7 5 2 1 3 1 3 0 3 3 6 10 13 7 4 3 8 8 13 5 5 4 10 4 10 0 6 9 12 14 17 5 7 11 17 11 17 0 8 18 22 18 22 0 где: РН — дата раннего начала; РО — дата раннего окончания; ПН — дата позднего начала; ПО — дата позднего окончания; Резерв=ПО-РО. Видно, что операции 2, 5, 7, 8 имеют временной резерв, равный нулю, и представляют критический путь данного примера. Сжатие расписания. При составлении расписания могут возникнуть ситуации, когда дата окончания проекта по расписанию будет более поздней, чем дата завершения проекта, утвержденная Заказчиком, или, наоборот, более ранней. В этом случае применяют сжатие расписания. Сжатие расписания укорачивает расписание проекта без изменения содержания проекта, с сохранением ограничения на сроки, требуемые даты или иные цели, указанные в расписании. Методы сжатия расписания: сжатие и быстрый проход. При методе сжатия выполняется анализ компромиссов стоимости и сроков для определения возможности максимально сжать сроки при минимальных дополнительных затратах. Сжатие не всегда позволяет получить приемлемое решение и может привести к увеличению стоимости проекта. Быстрый проход — частный случай сжатия расписания. При быстром проходе операции, обычно выполняемые последовательно, проводятся с 136 некоторым перекрытием или параллельно. Быстрый проход может привести к доработкам и возрастанию риска. Анализ возможных сценариев — анализ, в основе которого лежит рассмотрение вопросов типа «Что произойдет, если ситуация будет развиваться по сценарию Х?» В этом случае выполняется анализ сети расписания, при котором с помощью модели расписания просчитываются различные сценарии (например, задержка поставки или увеличение длительности отдельных операций) или моделируется воздействие непредвиденных внешних факторов. Результаты анализа возможных сценариев могут использоваться для оценки выполнимости расписания при неблагоприятных условиях и для составления резервных планов. Выравнивание ресурсов — метод анализа сети расписания, который применяется к модели расписания, проанализированной методом критического пути [4.2]. Выравнивание ресурсов используется для выявления плановых операций, которые необходимо выполнить, чтобы уложиться в указанные сроки. Выравнивание ресурсов удобно проводить с помощью компьютерных программ составления расписаний, используя гистограммы ресурсов. Гистограмма ресурсов создается на разделенном экране — в верхней части отображается диаграмма Гантта, где изображены операции, использующие ресурсы, представленные в нижней части экрана в виде столбиковой диаграммы. Диаграммы используют одинаковую шкалу времени. Рис. 5.10. Превышение доступности ресурсов 137 Рис. 5.11. Перераспределение ресурсов На рис. 5.10 видно, что в течение двух первых недель использованы не все ресурсы, а на пятой и шестой неделе наблюдается их перерасход, то есть люди должны будут работать сверхурочно по 20 часов в неделю в течение 2-х недель. После анализа внесем в расписание следующее изменение: прервем на третьей неделе выполнение задачи 2 и возобновим его на шестой неделе. Это позволит выравнивать нагрузку и избежать сверхурочных работ (рис. 5.11). В результате метода выравнивания ресурсов получается расписание с ограниченными ресурсами и с расчетными датами начала и завершения проекта. Программное обеспечение для управления проектами автоматизирует расчет математического анализа критического пути с прямым и обратным проходом и выравнивание ресурсов, позволяет оперативно рассмотреть множество альтернативных вариантов расписания. Применение календарей. Календари проекта и календари ресурсов определяют периоды, когда разрешена работа. Модель расписания создается на основе данных и информации расписания и используется для выполнения анализа сети расписания. Выходы процесса разработки расписания Результатами процесса разработки расписания являются: 138 Расписание проекта. Расписание проекта может быть разработано детально или укрупнено как расписание контрольных событий. Расписание может быть представлено в табличном виде или иметь графическое представление в виде сетевых диаграмм, столбиковых контрольных горизонтальных диаграмм или диаграмм событий. На столбиковых диаграммах столбики обозначают операции, показывают даты начала и завершения операций и их ожидаемую длительность. Они легко читаются и часто используются для представления информации руководству организации. Диаграммы контрольных событий показывают только запланированные даты начала или завершения получения основных результатов внедрения ИС и ключевых внешних событий. Данные для модели расписания. Обязательные данные для расписания проекта включают в себя контрольные события расписания, плановые операции, параметры операции и документацию всех имеющихся допущений и ограничений, а дополнительные — требования к ресурсам по периодам времени, альтернативные расписания, резервы на непредвиденные обстоятельства. Базовый план расписания — это особый вариант расписания проекта, разрабатываемый посредством анализа сети расписания модели расписания, принимается и утверждается командой управления проектом в качестве первоначального (базового) плана расписания с указанными базовым стартом и базовым финишем. Базовый план расписания используют для выявления отклонений фактических сроков выполнения операций от плановых. Требования к ресурсам (обновления). Параметры операции (обновления). Календарь проекта (обновления). Запрошенные изменения. В процессе разработки расписания могут появиться запрошенные изменения, которые обрабатываются в процессе общего управления изменениями. План управления проектом (обновления). План управления проектом обновляется с отражением всех одобренных изменений в способах управления расписанием проекта. При разработке расписания рекомендуется соблюдать следующую последовательность работ [4.2]: определить перечень операций, которые должны быть включены в расписание; определить взаимосвязь операций; определить длительность каждой операции; рассчитать с помощью прямого прохода ранее расписание для каждой операции; 139 рассчитать с помощью обратного прохода позднее расписание для каждой операции; вычислить временной резерв для каждой операции; определить критический путь; сравнить дату предполагаемого завершения проекта с датой завершения проекта по обязательству; подкорректировать расписание или дату завершения проекта по обязательству, если завершение проекта по расписанию предполагается раньше этой даты; определить ограничения на ресурсы; откорректировать расписание в соответствии с ограничениями на ресурсы; проверить, не планируется ли завершение проекта по откорректированному расписанию раньше даты обязательства; подкорректировать расписание или дату завершения проекта по обязательству, если завершение проекта по расписанию предполагается раньше этой даты; согласовать расписание. Управление расписанием Управление расписанием связано с определением текущего состояния расписания проекта, влиянием на факторы, создающие изменения в расписании, выявлением фактов изменения расписания проекта, управлением изменениями. Управление расписанием рассматривается как часть процесса общего управления изменениями. Входные данные для процесса управления расписанием План управления расписанием определяет, как будет осуществляться контроль и управление расписанием проекта. Базовый план расписания является составляющей плана управления проектом и основой для измерения исполнения расписания и отчетности по ней в рамках базового плана исполнения. Отчеты об исполнении задач дают информацию об исполнении расписания. Одобренные запросы на изменение используются для обновления базового плана расписания и прочих компонентов плана. Инструменты и методы управления расписанием 140 Отчетность о прогрессе проекта включает в себя фактические даты начала и завершения и оставшуюся длительность незавершенных плановых операций. При использовании методики освоенного объема отчетность может содержать процент выполнения текущих плановых операций. Для упрощения подготовки периодической отчетности о прогрессе проекта удобно использовать типовые формы — шаблоны. Пример шаблона отчетной формы представлен на рис. 5.12. «наименование проекта» Еженедельный статус-отчет Отчетный период:___________________ Кому: От: Дата: Работы, проведенные в отчетном периоде Плано Планов вая ая дата № Название операции дата окончан начал ия а Наименование пакета операций Отклоне ние Ожидае мая дата окончан ия Срок решения Ответственный % заверше ния Комме нтари й 1 Наименование пакета операций 2 3 Выводы и предложения Выводы: Предложения: Открытые вопросы и проблемы №в Решение/Проект № жур Описание решения нале Приор итет Рис. 5.12. Шаблон формы отчета о прогрессе проекта Система управления изменениями расписания определяет порядок изменения расписания проекта; включает в себя работу с документами, системы отслеживания и уровни авторизации, необходимые для авторизации изменений; является частью процесса общего управления изменениями. 141 Измерение эффективности. Методы измерения эффективности выдают отклонение по срокам и индекс выполнения сроков, используемые для оценки величины любых возникающих отклонений от расписания. Анализ отклонений. Ключевой функцией управления расписанием является проведение анализа отклонений по срокам. Сравнение директивных дат начала и выполнения с фактическими/прогнозируемыми дает информацию для осуществления корректирующих действий в случае задержек. Сравнительные диаграммы расписания. Для упрощения анализа исполнения расписания удобно пользоваться сравнительной столбиковой диаграммой, имеющей по два столбика для каждой плановой операции — текущее состояние и состояние одобренного базового плана расписания. На диаграмме наглядно отображаются места, где расписание обгоняет плановое и где отстает от него. Выходы процесса управления расписанием Данные для модели расписания (обновления). Одобренные изменения информации о расписании приводят к построению новых сетевых диаграмм расписания проекта. В некоторых случаях отставания расписания проекта бывают столь серьезными, что делает необходимой разработку нового расписания с пересмотренными директивными датами начала и завершения проекта. Базовый план расписания (обновления). Корректировка базового плана расписания может быть произведена в результате одобренных изменений. Перед созданием нового базового плана расписания во избежание потери исторических данных сохраняются исходные базовый план расписания и модель расписания. Измерения эффективности — значения отклонения по срокам и индекса выполнения сроков, рассчитанные для отдельных элементов ИСР; документально фиксируются и сообщаются участникам проекта. Запрошенные изменения в базовом плане проекта могут быть вызваны анализом отклонений по срокам, проверкой отчетов об исполнении, результатами измерения эффективности и изменений в модели расписания проекта. Запрошенные изменения обрабатываются для рассмотрения и утверждения в рамках процесса общего управления изменениями. Рекомендуемые корректирующие действия — это любые действия, осуществляемые для приведения ожидаемого будущего исполнения расписания проекта в соответствие с одобренным базовым расписанием. Корректирующие действия часто требуют предварительного анализа первопричины отклонений для выявления плановых операций, которые на самом деле вызывают отклонение. 142 Активы организационного процесса (обновления) — накопленные знания о причинах возникновения отклонений, обоснованиях выбранных корректирующих действий и другие типы накопленных знаний. Список операций (обновления). Параметры операций (обновления). План управления проектом (обновления). 143 Лекция 6. УПРАВЛЕНИЕ СТОИМОСТЬЮ ПРОЕКТА Стоимостная оценка проекта. Классификация оценок стоимости. Типы оценок: сверху-вниз, снизу-вверх, параметрическая, по аналогам. Оценка стоимости операций. Вспомогательные данные для оценки стоимости операций. Разработка бюджетов расходов. Базовый план по стоимости. Управление стоимостью. Методы измерения исполнения проекта. Метод освоенного объема. Анализ показателей. Прогнозирование условий выполнения проекта. Ключевые слова: стоимостная оценка, разработка бюджетов расходов, управление стоимостью, базовый план стоимости, бюджет проекта. Проект считается успешным, если он завершен с установленные сроки, выполнен в рамках бюджета и в соответствии с ожиданиями заказчика. Управление стоимостью заключается в обеспечении выполнения тройного ограничения на управление проектами - по стоимости, срокам и содержанию[4.2]. Управление стоимостью проекта объединяет процессы, выполняемые в ходе планирования, разработки бюджета и контролирования затрат и обеспечивающие завершение проекта в рамках утвержденного бюджета. К процессам управления стоимостью относятся: стоимостная оценка — определение примерной стоимости ресурсов, необходимых для выполнения операций проекта; разработка бюджета расходов — суммирование оценок стоимости отдельных операций или пакетов работ с целью формирования базового плана по стоимости; управление стоимостью — воздействие на факторы, вызывающие отклонения по стоимости, и управление изменениями бюджета проекта. Взаимодействие процессов представлено на рис. 6.1. 144 Описание содержания проекта Иерархическая структура работ (ИСР) Факторы внешней среды предприятия Активы организационного процесса План управления расписанием, обеспечения персоналом Риски проекта ИСР Расписание проекта План управления рисками Календарь ресурсов Контракт Отчеты об исполнении Информация об исполнении работ Запрошенные изменения План управления стоимостью (обновления) Стоимостная оценка Оценка стоимости операций Вспомогательные данные для оценки стоимости операций План управления стоимостью Запрошенные изменения Разработка бюджета расходов Запрошенные изменения План управления стоимостью (обновления) Базовый план по стоимости Требования к финансированию проекта Запрошенные изменения Базовый план по стоимости (обновления) План управления проектом (обновления) Рекомендуемые корректирующие воздействия Управление стоимостью Стоимостная оценка (обновления) Измерение эффективности Прогнозируемое завершение Активы организационного процесса (обновления) Запрошенные изменения Рис. 6.1. Связь процессов управления стоимостью проекта При отсутствии управления стоимостью проект, как правило, выходит из-под контроля, и его стоимость возрастает. Рассмотрим подробнее каждый из процессов. Стоимостная оценка Стоимостная оценка — это процесс установления стоимости ресурсов проекта, основанный на определенных фактах и допущениях. Для определения стоимостной оценки прежде всего необходимо определить операции (пакет операций), длительность операций и требуемые ресурсы. Процесс оценки и его результат в значительной степени зависят от точности описания содержания, качества доступной информации, от стадии проекта. На процесс стоимостной оценки оказывают влияние: время, отведенное для проведения оцениваемой операции, опыт менеджера, инструменты оценивания, заданная точность. Оценка стоимости проекта начинается на предпроектной стадии (до заключения контракта) и 145 выполняется в течение всего времени выполнения проекта. Выделяют следующие оценки стоимости [6.1]: оценка порядка величины; концептуальная оценка; предварительная оценка; окончательная оценка; контрольная оценка. На предпроектной стадии первоначально может определяться только порядок величины стоимости. Точность оценки порядка величины стоимости проекта может колебаться от (-50%) до (+100%). Точность концептуальной оценки находится в интервале (30%) — (+50%). Точность предварительной оценки проекта колеблется от (-20%) до (+30%). На этапе окончательной оценки точность колеблется от (-15%) до (+20%). Контрольная оценка имеет точность от -10% до +15%. Таким образом, каждая последующая стадия жизненного цикла проекта имеет более точную стоимостную оценку (рис. 6.2). -50% - +100% -30% - +50% Оценка порядка величины Концептуальная оценка -20% - +30% Предварительная оценка -15% - +20% Окончательная оценка -10% - +15% Контрольная оценка Рис. 6.2. Классификация оценок стоимости проекта Стоимостная оценка обычно выражается в единицах валюты (доллары, рубли и т. д.) для облегчения сравнения проектов и операций внутри проекта. Стоимость плановых операций оценивается для всех ресурсов, задействованных в проекте. К ресурсам относятся, в частности, специалисты, оборудование, телефонная связь, Интернет, арендованные помещения, а также особые статьи расходов, например учет уровня инфляции или расходы на непредвиденные обстоятельства. Входная информация для процесса оценки стоимости [4.1] 146 Факторы внешней среды предприятия. К факторам внешней среды относятся конъюнктура рынка, коммерческие базы данных и прайс-листы. Конъюнктура рынка — это рынок информационных систем, их конкурентная функциональность, стоимость, услуги на внедрение, сопровождение. Коммерческие базы данных и прайс-листы содержат сведения о квалификации и стоимости трудовых ресурсов, стоимости внедрения информационных систем. Активы организационного процесса — официальные и неофициальные правила, процедуры и руководства по стоимостной оценке, шаблоны стоимостной оценки, информация о стоимости ранее выполненных проектов. Описание содержания проекта содержит важную информацию о требованиях, ограничениях и допущениях проекта, которую необходимо учитывать при стоимостной оценке. Иерархическая структура работ определяет взаимоотношения между всеми элементами проекта и результатами проекта. Словарь ИСР содержит подробное описание работы для каждого элемента ИСР. План управления проектом — общий план мероприятий по исполнению, мониторингу и контролю над проектом, содержащий указания и руководства по составлению плана управления стоимостью и контролю за его исполнением, а также дополнительные планы: план управления расписанием; план управления обеспечением проекта персоналом содержит характеристики кадрового обеспечения и тарифные ставки персонала проекта и являются необходимыми элементами при составлении стоимостной оценки расписания; реестр рисков — при определении стоимостной оценки учитывается информация, касающаяся реагирования на риски. Риски могут приводить к негативным или благоприятным последствиям, поэтому они оказывают влияние как на плановые операции, так и на стоимость проекта. В случае возникновения негативного риска стоимость проекта может увеличиться. Инструменты и методы, используемые для оценки стоимости В зависимости от стадии проекта, необходимой степени точности, возможных расходов и трудозатрат применяются различные типы оценок стоимости. Оценка сверху-вниз применяется на ранних стадиях в условиях недостаточной информации о проекте. Производится только одна оценка стоимости всего проекта на самом верхнем уровне. Такая оценка не требует много усилий, но имеет низкую точность. 147 Оценка по аналогам представляет вид оценки сверху-вниз. При этом используется фактическая стоимость ранее выполненных проектов для оценки текущего проекта. При наличии очень похожего проекта оценка может быть довольно точной. Такой тип оценки применяется на любом этапе жизненного цикла проекта. Оценка по аналогам не требует много усилий при гарантированной точности, однако не всегда удается найти и определить схожие проекты. Точность оценки по аналогии колеблется от -30% до +50%. Стоимость подготовки такой оценки составляет 0,04%-0,15% от общей стоимости проекта. Оценка снизу-вверх применяется на этапе подготовки базового плана проекта и формировании контрольной оценки. Процесс начинается с оценки деталей проекта с последующим суммированием деталей на итоговых уровнях. Степень точности оценки зависит от уровня детализации ИСР. Оценка снизу-вверх обеспечивает точность от +0,15/10% до +5%/-5%, но имеет высокую стоимость (от 0,45% до 2% от общей стоимости проекта) и продолжительность. Параметрическая оценка применяется на ранних этапах проекта. Процесс параметрической оценки состоит в определении параметров оцениваемого проекта, которые изменяются пропорционально стоимости проекта. На основании одного или нескольких параметров создается математическая модель. Например, в качестве параметра разработки программного обеспечения может быть выбрана стоимость разработки строки кода. Для оценки стоимости обследования может быть выбрано количество автоматизируемых бизнеспроцессов. Наиболее распространенным параметром оценки стоимости IT-проектов является количество требуемого рабочего времени на выполнение операций (пакета операций). При тесной связи между стоимостью и параметрами проекта и при возможности точного измерения параметров можно увеличить точность расчетов. Преимущество данного метода: для оценки стоимости проекта достаточно знать «ставки» привлекаемых ресурсов: недостатком является низкая точность (-30%-+50%). Стоимость подготовки параметрической оценки составляет 0,04%-0,45% от общей стоимости проекта. Контрольные оценки представляют собой разновидность оценок снизу-вверх [4.2]. В качестве уровня детализации для выполнения оценки стоимости используется ИСР. Контрольная оценка основана на принципе более детальной оценки снизу-вверх. При оценке затрат на работы проекта, как правило, определяют наиболее вероятное значение затрат, затраты при благоприятных и неблагоприятных обстоятельствах, то есть оптимистическую, пессимистическую и наиболее вероятную оценку. Для расчета математического ожидания и среднеквадратичного отклонения применяют формулы, которые используются в методике PERT: 148 Математическое ожидание = [оптимистическое + пессимистическое + (4x наиболее вероятное)]/6 Среднеквадратичное отклонение = (пессимистическое — оптимистическое)/61 Контрольные оценки обладают высокой точностью, применяются для формирования базового плана проекта, но их выполнение продолжительно и стоит довольно дорого. Выходы процесса стоимостной оценки Оценка стоимости операции — количественная оценка примерной стоимости ресурсов, необходимых для выполнения плановых операций. Она может предоставляться в сжатой форме или развернуто. Затраты оцениваются по всем ресурсам, использованным в оценке стоимости операции. Вспомогательные данные, на основании которых была произведена стоимостная оценка, должны содержать описание содержания работ проекта для плановой операции: документацию того, как оценка получена; документацию обо всех допущениях, сделанных для оценки; документацию обо всех ограничениях. Запрошенные изменения. При составлении стоимостной оценки может возникнуть необходимость запроса изменения на требования к ресурсам операции и на другие элементы плана управления проектом. Запрошенные изменения обрабатываются установленным образом, и в процессе общего управления изменениями вносятся соответствующие коррективы в план. План управления стоимостью (обновления). Если в процессе составления стоимостной оценки появляются одобренные запросы на изменение и если эти одобренные изменения влияют на управление стоимостью, то происходит обновление элемента плана управления стоимостью. Разработка бюджета расходов Бюджет проекта2 представляет собой распределение статей расходов и доходов по периодам времени (например по дням, месяцам, кварталам). Процесс формирования, учета и контроля выполнения бюджетов называется бюджетированием. Элементами 1 2 Предполагается, что читатель знаком с основами статистики. Не путать со сметой — перечнем доходов и расходов, структурированным по статьям (разделам). 149 процесса бюджетирования являются: структура расходов и доходов; распределение расходов и доходов во времени; структура центров ответственности и распределение ответственности между ними за статьи доходов и расходов; процессы планирования, учета и контроля, которые предусматривают сбор и интеграцию плановой и фактической информации по центрам ответственности. Распределение ответственности за статьи доходов и расходов выполняется путем построения матрицы ответственности за статьи затрат (таблица 6.1). Статьи затрат определяются по классификации доходов и расходов, принятой в компании; центры ответственности определены на основании организационной структуры проекта. Каждый проект имеет свои статьи доходов и расходов, некоторые проекты имеют только расходные статьи бюджета. Структура статей расходов включает прямые затраты, структурируемые по ИСР, и затраты на накладные расходы проекта. Разработка бюджета расходов — процесс назначения оценок стоимости всем операциям проекта, результатом которого является создание базового плана по стоимости проекта [6.4]. Бюджет расходов содержит объединенные оценки стоимости отдельных плановых операций или пакетов работ. Процесс разработки бюджета расходов включает в себя процесс разработки бюджета для непредвиденных обстоятельств, куда закладывают ожидаемые значения воздействия всех идентифицированных рисков. Ожидаемое значение рассчитывается на основе оптимистичной, пессимистичной и наиболее вероятной оценок величины риска. В бюджет расходов следует включить управленческий резерв — деньги, предусмотренные в бюджете проекта на неидентифицированные риски. Таблица 6.1. Шаблон матрицы ответственности за статьи затрат Статья затрат Центр ответственности (подразделения) 1000 1100 1110 1120 1200 1210 1220 Заработная плата персонала проекта Оплата услуг связи Командировочные расходы Аренда помещения Амортизация оборудования Входы процесса разработки бюджета расходов Бюджет расходов строится на основе следующей информации [4.1]. Описание содержания проекта содержит ограничения по расходованию средств в рамках сметы расходов. 150 Иерархическая структура работ определяет взаимоотношения между всеми элементами проекта и результатами проекта. Словарь ИСР содержит подробное описание работы для каждого элемента ИСР. Оценка стоимости операции является результатом процесса оценки стоимости и представляет количественную оценку примерной стоимости ресурсов, необходимых для выполнения плановых операций. Расписание проекта содержит плановые даты начала и окончания плановых операций, контрольных событий расписания, пакетов работ, планируемых пакетов работ и контрольных счетов проекта, что позволяет суммировать затраты за календарные периоды при выставлении счетов за эти расходы. Календари ресурсов. Сводный календарь ресурсов проекта документирует рабочие и нерабочие дни, определяющие даты, на которые данный ресурс может быть активным или не задействован. План управления стоимостью, входящий в план управления проектом, и другие вспомогательные планы используются при разработке бюджета расходов. Инструменты и методы, используемые для разработки бюджета расходов Суммирование стоимости — процесс объединения стоимостных оценок отдельных плановых операций в группы по пакетам работ в соответствии с ИСР, с последующим объединением в элементы более высоких уровней также согласно ИСР до получения оценки стоимости всего проекта. Анализ резервов — процесс определения размеров резерва на непредвиденные обстоятельства и управленческого резерва. Управленческие резервы на непредвиденные обстоятельства не входят в базовый план по стоимости проекта, а включаются в бюджет проекта. Они не распределяются по проекту, как бюджет, и поэтому не учитываются при расчете освоенного объема. Параметрическая оценка (описана выше). Согласование объемов финансирования. Резкие колебания объемов периодических расходов нежелательны для деятельности любой организации. В связи с этим возникает необходимость в согласовании объемов расходуемых средств по проекту с объемами финансирования, установленными Заказчиком или Исполняющей организацией. Расписание выполнения работ и порядок выплат должны быть согласованы. Изменение расписания может повлиять на порядок распределения ресурсов. Если при разработке расписания расходуемые средства выступали в качестве ограничивающего ресурса, то необходим 151 повторный анализ расписания и внесение в него необходимой корректировки. Результатом плановых итераций является базовый план по стоимости. Разработка бюджета расходов: выходы Базовый план по стоимости — распределенный по времени бюджет, используемый для мониторинга и контроля исполнения стоимости проекта. Он разрабатывается путем суммирования оценок стоимости расходов по периодам времени и обычно имеет вид Sкривой. Базовый план по стоимости является элементом плана управления проектом. Проекты, особенно крупные, могут иметь несколько базовых планов по стоимости, отражающих разные аспекты процесса исполнения стоимости: расходы, входящие платежи, выполненную стоимость. Разработка базового плана по стоимости может быть выполнена по следующим шагам: 1. Сбор исходной информации, к которой относится оценка стоимости, ИСР, расписание проекта. 2. Определение типа базового плана стоимости и статей расходов. Определяющим фактором при выборе типа является характер и размер проекта. Список статей расходов зависит от типа базового плана. В таблице 6.2 приведен список статей доходов и расходов в зависимости от типа плана. Таблица 6.2. Определение статей расходов и доходов для различных типов базового плана №№ Тип базового плана Статьи расходов и доходов 1 Заработная плата персонала проекта. Выплаты подрядчикам. Закупка оборудования. Аренда помещения под проектный офис. Транспортные расходы. Оплата за услуги связи (телефон, Интернет) Поступления от Заказчиков за поставленные услуги: разработка технического задания; реализация проектных решений; тестирование интеграционных сценариев тестирования; разработка документов Системы; разработка Материалов Обучения; Централизованное обучение IT-специалистов Заказчика Статьи расходов и доходов, перечисленных в Базовый план для измерения исходящего потока денежной наличности 2 Базовый план для измерения входящего потока денежной наличности 3 Базовый план для управления потоком денежной наличности пунктах № 1 и № 2 152 3. Установление критериев формирования базового плана — установление отношений между оценкой стоимости и параметрами времени. Критерии определяют события проекта, инициирующие выплаты по статьям расходов базового плана, и интервал времени между инициирующим событием и датой выплаты (таблица 6.3). Таблица 6.3. Критерии базового плана стоимости Статьи расходов Зарплата управленческого персонала Зарплата консультантов Оплата услуг связи Аренда помещения Критерии базового плана стоимости Событие, Интервал времени Примечание инициирующее между событием и выплаты выплатой Согласно рабочему 1 месяц Политика расписанию компании Согласно рабочему 1 месяц расписанию Согласно договору 1 неделя на услуги связи Согласно договору 1 неделя об аренде Политика компании 4. Распределение статей доходов по временным периодам. 5. Суммирование оценочных значений расходов по временным периодам. 6. Графическое изображение базового плана стоимости (рис. 6.3). Июнь Май Апрель Март Январь Декабрь Ноябрь Октябрь Сентябрь Август Июль Июнь 450 400 350 300 250 200 150 100 50 0 Февраль Базовый план по стоимости Рис. 6.3. Графическое изображение базового плана Требования к финансированию проекта формируются на основании базового плана стоимости и представляют сумму средств, указанных в базовом плане по стоимости, и резерва на непредвиденные обстоятельства. 153 Управление стоимостью Управление стоимостью — процесс контролирования затрат проекта и выполнения корректирующих действий, который является частью общего управления изменениями. Управление стоимостью проекта включает в себя следующие действия [4.1]: Воздействие на факторы, вызывающие изменения базового плана по стоимости. Проверка одобрения на запрошенные изменения. Управление изменениями стоимости. Обеспечение сохранения расходов (периодических и всего проекта) в рамках, определенных пределами финансирования проекта. Осуществление мониторинга выполнения стоимости с целью обнаружения и анализа отклонений от базового плана по стоимости. Фиксирование всех отклонений от базового плана по стоимости. Информирование соответствующих участников проекта об утвержденных изменениях. Выполнение действий, необходимых для того, чтобы превышения стоимости затрат оставались в допустимых пределах. Входы процесса управления стоимостью Исходной информацией для управления стоимостью являются: Базовый план по стоимости. Требования к финансированию проекта. Отчеты об исполнении — содержат информацию о расходовании ресурсов в процессе выполнения фактических работ. Информация об исполнении работ — содержит данные, относящиеся к статусу и стоимости выполненных операций проекта, и включает следующее: завершенные и незавершенные результаты поставки; одобренные и произведенные расходы; прогноз времени завершения плановых операций; процент фактически выполненных плановых операций. Одобренные запросы на изменения. План управления проектом. В процессе управления стоимостью учитываются данные плана управления проектом (плана управления стоимостью и других вспомогательных планов). Инструменты и методы для управления стоимостью 154 Система управления изменениями стоимости содержит описания процедур внесения изменений в базовый план по стоимости и включает в себя формы, документацию, системы отслеживания и определения уровня уполномоченных одобрять внесение изменений. Метод освоенного объема — интегрированный анализ исполнения календарного плана проекта и бюджета по стоимостным оценкам, наиболее распространенный метод измерения исполнения проекта и его управления. (Освоенный объем задачи — это утвержденный бюджет, выделенный на ее решение.) Данный метод позволяет в одном отчете — отчете по освоенному объему— представить сведения об исполнении расходов и расписания, причем и расписание и расходы измеряются в валюте, в которой ведется бюджет проекта. Измерение и расходов, и расписания проекта в денежных единицах является наиболее информативным описанием состояния проекта. Метод использует систему отчетности с нарастающим итогом, которая основана на отслеживании трех показателей проекта: Плановая стоимость запланированных работ или плановый объем — PV (Planned Value). Плановый объем рассчитывается на основании базового плана по стоимости и базового расписания, где каждая операция имеет свои сроки и оценку стоимости. Плановый объем представляет бюджет с нарастающим итогом и отображающий во времени, когда предполагается делать затраты согласно плану проекта (рис. 6.4); Фактическая стоимость выполненных работ — AC (Actual Cost). Фактическая стоимость с нарастающим итогом отображается во времени для каждого отчетного периода (рис. 6.4); Плановая стоимость выполненных работ или освоенный объем — EV (Earned Value). Объем работы эквивалентен бюджету, установленному для данной работы. Освоенный объем изображается на графике в конце каждого отчетного периода на основании информации о фактической выполненной работе. Если проект выполняется в соответствии с планом, все три показателя будут иметь одинаковое значение. Отклонения между показателями могут стать сигналом об отставании проекта по срокам или перерасходе бюджетных средств. 155 Отчетная дата З н а ч е н и Actual Cost (AC) я Budget At Completion (BAC) Planned Value (PV) CV = EV – AC < 0, CPI < 1 SV = EV – PV < 0, SPI < 1 Earned Value (EV) Время Рис. 6.4. Управление стоимостью методом освоенного объема Трудными задачами методики освоенного объема является сбор данных и составление отчетности о выполнении работ. Ключевыми показателями методики освоенного объема являются: отклонение по стоимости — CV (Cost Variance). Равно разнице между плановой стоимостью выполненной работы и ее фактической стоимостью. CV = EV — AC. отклонение по срокам — SV (Schedule Variance). Равно разнице между плановой стоимостью выполненной работы и плановой стоимостью запланированных работ. SV = EV — PV. коэффициент выполнения бюджета (или индекс выполнения стоимости) — CPI (Cost Performance Index). CPI = EV/AC. коэффициент выполнения календарного плана (или индекс выполнения сроков) — SPI (Schedule Performance Index). SPI = EV/PV. Индексы — относительные показатели, используемые для сравнения хода выполнения проектов разной величины, когда сравнение абсолютных показателей проектов невозможно. На рис. 6.5 представлены различные варианты состояния проекта и соответствующие им значения показателей. 156 CV>0 CPI>1 Экономия Отставание Экономия Опережение SV>0 SPI> 1 SV<0 SPI< 1 Перерасход Опережение Перерасход Отставание CV<0 CPI<1 Рис. 6.5. Анализ показателей Метод освоенного объема объединяет параметры содержания проекта, стоимости (или ресурсов) и сроков, которые помогают команде управления проектом оценить эффективность исполнения проекта. Прогнозирование включает в себя оценку или описание условий, которые возникнут в будущем проекта, на основании информации и знаний, доступных на момент прогнозирования. По мере выполнения проекта прогнозы создаются, обновляются и переиздаются на основе поступающей информации об исполнении работ. Анализ эффективности исполнения проекта предусматривает сравнение эффективности затрат по времени для плановых операций или пакетов работ, выполнение которых отличается от предусмотренных бюджетом значений как в сторону увеличения, так и в сторону уменьшения. Анализ предназначен для оценки выполнения и оценки состояния плановых операций или пакетов работ. Для проведения анализа используется один или несколько представленных ниже методов составления отчетов об эффективности исполнения проекта: 157 • анализ отклонений включает в себя сравнение данных фактической эффективности проекта с запланированными или ожидаемыми; • анализ тенденций предполагает изучение данных эффективности проекта во времени для определения, происходит ли улучшение или ухудшение исполнения проекта; • метод освоенного объема предусматривает сравнение плановых показателей эффективности с фактическими. Выходы процесса управления стоимостью Стоимостная оценка (обновления) содержит уточнения оценки стоимости и может вызвать необходимость внесения изменений в другие аспекты плана управления проектом. Базовый план по стоимости (обновления). Изменение утвержденного базового плана по стоимости производится только в ответ на одобренные изменения в содержании проекта или при существенных отклонениях по стоимости. Измерение эффективности — показатели, рассчитанные по методике освоенного объема: отклонение по стоимости, отклонение по срокам, индекс выполнения стоимости и индекс выполнения сроков для элементов ИСР. Перечисленные показатели документально оформляются и направляются участникам проекта. Запрошенные изменения — обрабатываются, и в процессе общего управления изменениями вносятся соответствующие коррективы в план. Рекомендованные корректирующие действия. Корректирующим действием в области управления стоимостью часто является внесение изменений в бюджеты плановых операций. Активы организационного процесса (обновления). Документы накопленных знаний включают в себя информацию об основных источниках отклонений, критерии, по которым было выбрано то или иное корректирующее действие, и другие виды накопленных знаний, относящихся к стоимости. План управления проектом (обновления). Документы, относящиеся к базовому плану по стоимости, плану управления стоимостью и бюджету проекта, являются составными элементами плана управления проектом. Все одобренные запросы на изменения, влияющие на содержание этих документов, оформляются в виде обновлений и включаются в состав документов. Задания 158 Вариант 1 1. Ключевыми показателями методики освоенного объема являются: • отклонение по стоимости. + • отклонение по срокам. + • отклонение по качеству. • коэффициент выполнения бюджета. + • коэффициент выполнения календарного плана. + 2. Каково состояние проекта, если отклонение по стоимости (CV) имеет положительное значение, а отклонение по срокам (SV) имеет отрицательное значение: • экономия средств и опережение по срокам. • перерасход средств и отставание по срокам. • экономия средств и отставание по срокам. + • перерасход средств и опережение по срокам. 3. Чему равен индекс выполнения стоимости, если плановый объем PV= 80000, фактическая стоимость выполненных работ AC =10000, освоенный объем EV=8000? • 1. • 1,25. • 0,8. + • 2,5. Вариант2 1. При какой оценке стоимости проекта точность оценки колеблется от-30% до+50%: • концептуальной оценки. + • окончательной оценки. • контрольной оценки. • оценки порядка величины стоимости проекта. 2. При какой оценке стоимости проекта точность оценки колеблется от -10% до +15%: • на этапе концептуальной оценки. • на этапе окончательной оценки. • на этапе контрольной оценки. + • этапе оценки порядка величины стоимости проекта. 159 3. На процесс стоимостной оценки оказывают влияние: • время, отведенное для проведения оцениваемой операции. + • опыт менеджера. + • инструменты оценивания. + • заданная точность. + Вариант 3 1. Сравнивая типы оценки стоимости проекта «сверху вниз» и «снизу-вверх» можно сказать, что оценка «сверху вниз»: • менее точная. + • более точная. • почти одинакова по точности с оценкой «снизу вверх». 2. Оценка снизу-вверх используется, когда: • требуется подготовить базовые планы по стоимости. + • необходима оценка контрольного типа. + • требуется определить стоимость проекта на ранних стадиях разработки проекта 3. Какие оценки являются разновидностью оценки «снизу вверх»? • оценки по аналогам. + • параметрические оценки. + • контрольные оценки. + Вариант 4 1. Распределение статей расходов и доходов по периодам времени (например, по дням, месяцам, кварталам) является : • бюджетом проекта. + • сметой проекта. • стоимостью проекта. 2. Бюджет на непредвиденные обстоятельства определяется для: • рисков, которые могут быть идентифицированы. + • рисков, которые еще не идентифицированы. • корректирующих воздействий. 160 3. Управленческий резерв определяется для: • рисков, которые еще не идентифицированы. + • рисков, которые могут быть идентифицированы. • корректирующих действий Вариант 5 1. Управление стоимостью включает: • определение примерной стоимости ресурсов, необходимых для выполнения операций проекта. + • суммирование оценок стоимости отдельных операций или пакетов работ с целью формирования базового плана по стоимости. + • воздействие на факторы, вызывающие отклонения по стоимости, и управление изменениями бюджета проекта. + 2. Процесс установления стоимости ресурсов проекта, основанный на определенных фактах и допущения. – это: • стоимостная оценка проекта. + • разработка бюджета проекта. • управление стоимостью проекта. 3. Базовый план по стоимости является выходом процесса : • управления стоимостью. + • разработки бюджета расходов. • контроля затрат проекта. • оценки стоимости. 161 Лекция 7. УПРАВЛЕНИЕ РИСКАМИ ПРОЕКТА Основные понятия и Идентификация рисков. определения. Планирование управления рисками. Оценка рисков. Качественный анализ рисков. Количественный анализ рисков. Планирование реагирования на риски. Мониторинг и управление рисками. Ключевые слова: риск, величина риска (ожидаемое значение), резерв для непредвиденных обстоятельств, матрица вероятности и последствий, иерархическая структура рисков, реестр рисков. В первые десятилетия современного управления проектами основное внимание было уделено планированию и контролю проекта. Но повторяющиеся неудачи в достижении целей проекта, связанные с неучтенными рисками, привели к пониманию необходимости управления рисками на протяжении всего жизненного цикла. Несмотря на то, что ИТпроекты могут быть связаны с большим или меньшим числом рисков, нет ни одного проекта, где бы риски полностью отсутствовали. Проекты в области информационных технологий имеют специфические характеристики. Рыночная конкуренция, эволюция технических стандартов, другие факторы могут поставить перед командой проекта задачи по модифицированию утвержденных планов в середине проекта. Изменяющиеся требования Заказчика, новые технологии, растущие проблемы информационной безопасности, текучесть кадров — все это дополнительные факторы, способные повлечь за собой изменения в IT-проекте и заставить команду проекта принимать решения в условиях риска. Процесс управления рисками тесно связан с общим жизненным циклом проекта. На ранних этапах преобладают риски, связанные с бизнесом, рамками проекта, требованиями к конечному продукту и проектированием этого продукта. На стадии реализации доминируют технологические риски, далее возрастает роль рисков, связанных с поддержкой и сопровождением системы. На протяжении всего жизненного цикла проекта возникают новые риски, что требует проведения дополнительных операций анализа и планирования. Целью управления рисками проекта является повышение вероятности реализации и значимости позитивных событий и снижение вероятности реализации событий, негативных для целей проекта. Основные понятия и определения 162 Установим основные понятия и определения, относящиеся к рискам. Риск проекта — это кумулятивный эффект вероятностей наступления неопределенных событий, способных оказать отрицательное или положительное влияние на цели проекта [4.3]. Риски подразделяются на известные и неизвестные. Известные риски идентифицируются и подлежат управлению — создаются планы реагирования на риски и резервы на возможные потери. Неизвестные риски нельзя определить, и, следовательно, невозможно спланировать действия по реагированию на такой риск. Событие риска — потенциально возможное событие, которое может нанести ущерб или принести выгоды проекту [4.3]. Вероятность возникновения риска — вероятность того, что событие риска наступит [4.3]. Все риски имеют вероятность больше нуля и меньше 100%. Риск с вероятностью 0 не может произойти и не считается риском. Риск с вероятностью 100% также не является риском, поскольку это достоверное событие, которое должно быть предусмотрено планом проекта. Последствия риска, если он случится, выражаются через дни расписания, трудозатраты, деньги и определяют степень воздействия на цели проекта. Величина риска — показатель, объединяющий вероятность возникновения риска и его последствия. Величина риска рассчитывается путем умножения вероятности возникновения риска на соответствующие последствия. Резерв для непредвиденных обстоятельств (или резерв для покрытия неопределенности) — сумма денег или промежуток времени, которые необходимы сверх расчетных величин для снижения риска перерасхода, связанного с достижением целей проекта, до приемлемого для организации уровня; обычно включаются в базовый план стоимости или расписания проекта. Управленческий резерв — сумма денег или промежуток времени, не включаемые в базовый план стоимости или расписания проекта и используемый руководством для предотвращения негативных последствий ситуаций, которые невозможно спрогнозировать. Толерантность к риску — это готовность или неготовность лица или организации рисковать [4.2]. Некоторые организации берут на себя риск, в то время как другие его избегают. Одни компании рискуют потерять очень много денег ради шанса получить их еще больше. Другие компании не идут на риски, связанные с финансовыми потерями. 163 Управление рисками включает в себя шесть процессов: планирование управления рисками, идентификация рисков, качественный анализ рисков, количественный анализ рисков, планирование реагирование на риски, мониторинг и управление рисками. Взаимодействие процессов управления рисками представлено на рис. 7.1. Планирование управления рисками К планированию управления рисками следует относиться так же серьезно, как к планированию стоимости и расписания проекта. Качественное планирование повышает вероятность получения положительных результатов остальных процессов управления рисками. Планирование управления рисками — это процесс определения подходов и планирования операций по управлению рисками проекта [4.1]. Формирование стратегии компании по управлению рисками, основных правил, позволяющих управлять рисками проекта, является целью процесса планирования рисков. Исходная информация для планирования рисков Источниками входной информации для процессов планирования рисков являются: Факторы внешней среды предприятия. Отношение к риску и толерантность к риску организаций и лиц, участвующих в проекте, оказывает влияние на план управления проектом и может проявляться в конкретных действиях. Активы организационного процесса. Организации могут иметь заранее разработанные подходы к управлению рисками, например категории рисков, общие определения понятий и терминов, стандартные шаблоны, схемы распределения ролей и ответственности, а также определенные уровни полномочий для принятия решений. Описание содержания проекта (см. лекцию 4). План управления проектом (см. лекцию 4). 164 Описание содержания проекта Факторы внешней среды предприятия Активы организационного процесса Планирование управления рисками План управления проектом План управления рисками Идентификация рисков Одобренные запросы на изменения Реестр рисков Качественный анализ рисков Реестр рисков (обновления) План управления стоимостью План управления расписанием Количественный анализ рисков Реестр рисков (обновления) Планирование реагирования на риски Реестр рисков (обновления) Контрактные соглашения, касающиеся рисков Отчетность по исполнению Информация об исполнении работ Мониторинг управления рисками План управления проектом (обновления) Рекомендованные предупреждающие действия Рекомендованные корректирующие действия Запрошенные изменения Реестр рисков (обновления) План управления проектом (обновления) Активы организационного процесса (обновления) Рис 7.1. Взаимосвязь процессов управления рисками 165 Методы и инструменты планирования рисков В качестве инструментов и методов планирования управлением рисками используют совещания по планированию и анализу. Команда проекта проводит совещания для разработки плана управления рисками, в которых могут принимать участие менеджер проекта, отдельные члены команды проекта и участники проекта, представители организации, отвечающие за операции по планированию рисков и реагированию на них. На совещаниях составляются базовые планы по проведению операций управления рисками. Также разрабатываются элементы стоимости рисков и плановые операции, которые включаются соответственно в бюджет проекта и расписание. Утверждается распределение ответственности в случае наступления риска. Имеющиеся в организации общие шаблоны, касающиеся категорий рисков и определения терминов (например, уровни рисков, вероятность возникновения рисков по типам, последствия рисков для целей проекта по типам целей, а также матрица вероятности и последствий), приспосабливаются для каждого конкретного проекта с учетом его специфики. Выходы этих операций сводятся в план управления рисками. Результаты процесса планирования рисков План управления рисками — документ, разрабатываемый в начале проекта и содержащий описания структуры управления рисками проекта и порядок его выполнения в рамках проекта; включается в состав плана управления проектом. План управления рисками содержит следующие элементы [4.3]: Методология — определение подходов, инструментов и источников данных, которые могут использоваться для управления рисками в данном проекте. Распределение ролей и ответственности — список позиций выполнения, поддержки и управления рисками для каждого вида операций, включенных в план управления рисками, назначение сотрудников на эти позиции и разъяснение их ответственности. Определение операций по управлению рисками, которые необходимо включить в расписание проекта. Определение сроков и частоты выполнения операций по управлению рисками на протяжении всего жизненного цикла проекта. Выделение ресурсов и оценка стоимости мероприятий, необходимых для управления рисками. Эти данные включаются в базовый план по стоимости проекта. Классификации рисков (или категории рисков) — структура, на основании которой производится систематическая и всесторонняя идентификация рисков с нужной степенью детализации. Классификации рисков предназначены для 166 нескольких целей. Во время выявления рисков они стимулируют видение проектной группой всех возможных рисков, возникающих из различных составляющих проекта. При проведении мозгового штурма классификации рисков облегчают одновременную работу с большим числом рисков, предоставляя подходящий способ группирования схожих рисков. Классификации помогают в разработке единой терминологии, используемой участниками проекта для мониторинга и отчетности о состоянии рисков, а также они совершенно необходимы для составления баз знаний о рисках. Классифицировать риски можно с помощью составления иерархической структуры или составив перечень различных аспектов проекта. В процессе идентификации категории рисков могут пересматриваться. На рис. 7.2 приведен пример иерархической структуры рисков, содержащей категории и подкатегории, представлена которые могут появиться на типовом проекте. На рис. 7.3 высокоуровневая классификация источников рисков проектов, используемая Microsoft Solutions Framework ® (MSF) [1.5]. Рис 7.2. Пример иерархической структуры рисков [4.1] проект люди процессы технологии внешние условия Заказчики Цели и задачи Безопасность Законодательство Конечные потребители Принятие решений Среда разработки Индустриальные стандарты 167 Спонсоры Заинтересованные стороны Характеристики проекта Бюджет, затраты, сроки и тестирования Конкуренция Инструментарий Экономические условия Внедрение Требования Организация Проектирование Операционная среда Реализация Профессиональная квалификация Тестирование Технология Сопровождение Персонал Бизнес-условия Доступность Политика Рис. 7.3. Классификация источников риска Определение вероятности возникновения рисков и их последствий. Общие определения уровней вероятности и уровней воздействия адаптируются отдельно для каждого проекта в ходе процесса планирования управления рисками и используются в процессе качественного анализа рисков. Можно применить относительную шкалу, на которой вероятность обозначена описательно, маловероятно» до «почти наверное», или со значениями от «крайне шкалу, на которой вероятности соответствует цифровое значение, например: 0,1 - 0,3 - 0,5 - 0,7 - 0,9. В таблице 7.1 представлено семиуровневое разделение вероятности [1.5]. Для каждого интервала вероятностей выполнена относительная и числовая оценка. Таблица 7.1. Семиуровневая оценка вероятности возникновения риска Интервал Значение Словесная Числовая оценка вероятностей вероятности, формулировка используемое для вычислений От 1% до 14% 7% крайне маловероятно 1 От 15% до 28% 21% низкая вероятность 2 От 29% до 42% 35% скорее нет 3 От 43% до 57% 50% 50-50 4 От 58% до 72% 65% возможно 5 От 73% до 86% 79% весьма правдоподобно 6 От 87% до 99% 93% почти наверняка 7 168 При оценке воздействия риска определяется потенциальный эффект, который он может оказать на цель проекта (например время, стоимость, содержание или качество). В таблице 7.2 представлена шкала для оценки угрозы риска, определенного в денежном выражении. Таблица 7.2. Шкала для оценки последствий риска, измеряемого в деньгах Оценка Денежное выражение 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 миллиардов Когда денежные единицы не могут быть применены, проектная группа может использовать другие шкалы оценки последствий риска (таблица 7.3). Система оценки воздействий должна отражать политику и ценности организации и проектной группы . Таблица 7.3. Шкала для оценки последствий риска, измеряемого отклонениями в стоимости, сроках и технических условиях проекта Оценка Перерасход средств 1 (низкая) до 1% Календарный график сдвиг на 1 неделю 2 (средняя) до 5% сдвиг на 2 недели 3 (высокая) до 10% сдвиг на 1 месяц 4 (критическая) от 10% сдвиг более 1 мес. Относительная шкала последствий разрабатывается Технические условия небольшая потеря производительности умеренное снижение производительности серьезный ущерб для производительности задача не может быть выполнена каждой организацией самостоятельно. Шкала содержит только описательные обозначения, например «очень низкий», «низкий», «средний», «высокий» и «очень высокий», расположенные в порядке возрастания максимальной силы воздействия риска согласно определению данной организации. То же самое можно сделать иначе, путем присвоения данным последствиям 169 цифровых значений, которые могут быть линейными и нелинейными, например 0,1 - 0,3 - 0,5 - 0,7 - 0,9 или 0,05 - 0,1- 0,2 - 0,4 - 0,8. В таблице 7.4 представлены как относительный, так и цифровой (в данном случае нелинейный) способы обозначения последствий риска для четырех целей проекта [4.1]. Таблица 7.4. Определение шкалы оценки воздействия для четырех целей проекта Определенные условия для шкалы оценки степени возможного влияния риска (показаны только примеры негативных воздействий) Показаны значения по относительной и числовой шкалам Очень Цель проекта Очень низкое Низкое Умеренное Высокое высокое 0,05 0,10 0,20 0,40 0,80 Стоимость Незначительное увеличение Увеличение < 5% Увеличение 5-10% Увеличение 10-20% Увеличение > 20% Сроки Незначительное увеличение Увеличение < 5% Увеличение 5-10% Значительные изменения Изменение требует согласия клиента Увеличение 10-20% Неприемлемое для клиента изменение Неприемлемое для клиента изменение Увеличение > 20% Достижение конечных результатов невозможно Достижение конечных результатов невозможно Содержание (объем) Изменения незаметны Незначительные изменения Качество Изменения незаметны Незначительные изменения Матрица вероятности и последствий содержит комбинации вероятности и воздействия, при помощи которых рискам присваивается определенный ранг: низкий, средний или высший [4.1]. Матрица может содержать описательные термины или цифровые обозначения (рис. 7.4) и строится на основании шкал оценки вероятности и оценки степени влияния возможного риска. Левый столбец матрицы содержит значения вероятности возникновения риска, в первой строке расположена шкала со значениями возможных последствий. Ячейки заполняется результатами перемножения значений этих шкал. Сопоставляя значение ячейки матрицы со шкалой оценки воздействия (таблица 7.4), риски можно разделить по категориям — малые, средние и большие. Рассмотрим матрицу вероятности и последствий, представленную на рис. 7.4. Риски, имеющие очень высокие вероятности, но незначительные последствия, а также риски, имеющие низкие вероятности и незначительные последствия, считаются рисками, не оказывающими воздействия (клетки таблицы серого цвета). Риски с очень большими последствиями, но малой вероятностью, как и риски с незначительными последствиями и высокой вероятностью (клетки светло-серого цвета) имеют среднее воздействие на проект. Риски, которым необходимо уделять особое 170 внимание, имеют достаточно высокую вероятность и существенные последствия (клетки таблицы, окрашенные темно-серым цветом). Рис. 7.4. Матрица вероятности и последствий Уточненная толерантность к рискам участников проекта. Формы отчетности. Определяет формат реестра рисков и его содержание, а также любых других требуемых отчетов по рискам. Определяет, каким образом производится документирование, анализ и обмен информацией о результатах процесса управления рисками. Отслеживание. Документирует порядок регистрации всех аспектов операций по рискам в интересах данного проекта, а также для будущих проектов и для включения в документы по накопленным знаниям. Документирует, в каких случаях и как будет проводиться аудит процессов управления рисками. В приложении 8 приводятся примеры формы для общего анализа проектных рисков, описание процедуры для управления рисками, форма запроса на регистрацию риска, описание процедуры управления рисками проекта. Идентификация рисков Идентификация рисков — процесс определения рисков, способных повлиять на проект, и документирование их характеристик. Идентификацию рисков выполняют члены команды проекта и эксперты по вопросам управления рисками, в ней могут принимать участие заказчики, участники проекта и эксперты в определенных областях. Это итеративный процесс, поскольку по мере развития проекта в рамках его жизненного цикла могут обнаруживаться новые риски. Частота итерации и состав участников выполнения 171 каждого цикла в каждом случае могут быть разными. В процессе идентификации должны принимать участие члены команды проекта, чтобы у них вырабатывалось чувство «собственности» и ответственности за риски и за действия по реагированию на них. Исходная информация для процесса идентификации [4.1] Входной информацией для процесса идентификации рисков служит нижеследующая информация. Факторы внешней среды предприятия — информация из открытых источников, в том числе коммерческие базы данных, научные работы, бенчмаркинг и другие исследовательские работы в области управления рисками. Активы организационного процесса — информация о выполнении прежних проектов. Описание содержания проекта. Допущения проекта приводятся в описании содержания проекта. Неопределенность в допущениях проекта следует рассматривать в качестве потенциального источника возникновения рисков проекта. План управления рисками. Входами для процесса идентификации рисков из плана управления рисками являются схема распределения ролей и ответственности, резерв на операции по управлению рисками в бюджете и в расписании, а также категории рисков. План управления проектом. Для идентификации рисков необходимо понимание планов управления расписанием, стоимостью и качеством, которые входят в план управления проектом, и анализ выходов этих процессов. Методы и инструменты идентификации рисков Анализ документации заключается в просмотре материалов проекта, разработанных до проведения данного анализа. Анализируется качество планов, согласованность планов, соответствие требованиям Заказчика, допущения проекта, базовые планы по содержанию срокам, стоимости, — все, что может служить показателями возможности риска в проекте. Методы сбора информации [4.2] Мозговой штурм. Целью мозгового штурма является создание подробного списка рисков проекта. Список рисков разрабатывается на собрании, в котором принимает участие 10-15 человек — члены команды проекта, часто совместно с участием экспертов из разных областей, не являющихся членами команды. Участники собрания называют риски, которые считают важными для проекта, при этом не допускается обсуждение выдвинутых рисков. Далее риски сортируют по категориям и уточняют. Метод Дельфи аналогичен методу мозгового штурма, но его участники не знают друг друга. Ведущий, с помощью списка вопросов для получения идей, 172 касающихся рисков проекта, собирает ответы экспертов. Далее ответы экспертов анализируются, распределяются по категориям и возвращаются экспертам для дальнейших комментариев. Консенсус и список рисков получается через несколько циклов этого процесса. В методе Дельфи исключается давление со стороны коллег и боязнь неловкого положения при высказывании идеи. Метод номинальных групп позволяет идентифицировать и расположить риски в порядке их важности. Данный метод предполагает формирование группы из 710 экспертов. Каждый участник индивидуально и без обсуждений перечисляет видимые им риски проекта. Далее происходит совместное обсуждение всех выделенных рисков и повторное индивидуальное составление списка рисков в порядке их важности. Карточки Кроуфорда. Обычно собирается группа из 7-10 экспертов. Ведущий сообщает, что задаст группе 10 вопросов, на каждый из которых участник письменно, на отдельном листе бумаги, должен дать ответы. Вопрос о том, какой из рисков является наиболее важным для проекта, ведущий задает несколько раз. Каждый участник вынужден обдумать десять различных рисков проекта. Опросы экспертов с большим опытом работы над проектами. Идентификация основной причины. Цель этого процесса: выявить наиболее существенные причины возникновения рисков проекта и сгруппировать риски по причинам, их вызывающим. Анализ сильных и слабых сторон, возможностей и угроз (анализ SWOT). Цель проведения анализа — оценить потенциал и окружение проекта. Потенциал проекта, выраженный в виде его сильных и слабых сторон, позволяет оценить разрывы между содержанием проекта и возможностями его выполнения. Оценка окружения проекта показывает, какие благоприятные возможности предоставляет и какими опасностями угрожает внешняя среда. Анализ контрольных списков. Контрольные списки представляют собой перечни рисков, составленные на основе информации и знаний, которые были накоплены в ходе исполнения прежних аналогичных проектов. Метод аналогии. Для идентификации рисков этот метод использует накопленные знания и планы по управлению рисками других аналогичных проектов. Методы с использованием диаграмм. К методам отображения рисков в виде диаграмм относятся диаграммы причинно-следственных связей и блок-схемы процессов, которые позволяют проследить последовательность событий, происходящих в данном процессе. Сравнение методов идентификации рисков проекта [4.2] представлено в таблице 7.5. 173 Таблица 7.5.Сравнение методов идентификации рисков Метод идентификации Мозговой штурм Преимущества Способствует взаимодействию членов группы Быстрый Недорогой Метод Delphi Нет доминирования одной личности. Может проводиться дистанционно через электронную почту. Исключается проблема ранней оценки. Требует участия каждого члена группы Уменьшается эффект доминирующей личности Обеспечивает взаимодействие участников Дает упорядоченный список рисков Быстрый Легко реализуется Должен участвовать каждый член группы Вырабатывается большое количество идей Можно проводить с группами больше обычного размера Уменьшает эффект доминирующей личности Используется прошлый опыт Метод номинальных групп Карточки Кроуфорда Опрос экспертов Недостатки Может проявиться преобладание одной личности. Можно сосредоточиваться только в конкретных областях. Требует сильного ведущего. Для оценки необходимо контролировать склонности группы Занимает много времени. Высокая загрузка ведущего Требует много времени. Высокая загрузка ведущего Меньшее взаимодействие между участниками Эксперт может быть предвзятым. Требует много времени Предвзятость Может не содержать конкретных элементов для данного проекта Контрольные списки Конкретный и упорядоченный Легко использовать Метод аналогии Использует прошлый опыт для исключения проблем в будущем Подобные проекты содержат много сходных черт Требует много времени. Легко получить результаты, не подходящие для данного случая. Аналогия может быть некорректной Методы с использованием диаграмм Ясное представление участвующих процессов Легкость построения Для них имеется много компьютерных инструментов Иногда вводит в заблуждение Может занимать много времени Выходы процесса идентификации рисков Результатом процесса идентификации рисков является Реестр рисков, содержащий: список идентифицированных рисков; 174 список потенциальных действий по реагированию; основные причины возникновения риска; уточнение категорий рисков. В процессе идентификации список категорий рисков может пополняться новыми категориями, что может привести к расширению иерархической структуры рисков, разработанной в процессе планирования управления рисками. Примеры форм Реестра рисков [1.5] приведены в таблицах 7.6 и 7.7. Таблица 7.6. Форма Реестра рисков № Дата возникнове ния риска Идентификация риска Дата Наимен Описа Инициатор Причины, ПоследствияВладелец Дата регистра ование ние вызвавши риска окончани ции риска риска е риск я риска действия риска Первопричина Условие Необеспеченность кадрами Могут быть объединены проектные роли. Таблица 7.7. Пример Реестра рисков Последствие Несовместимые роли: Менеджер по качеству и разработчик, Совмещение ролей может затруднить контроль и оценку результатов, что снизит качество программного продукта Тестировщик и разработчик Изменения в технологии Разработчикам придется осваивать новые технологии и использовать их впервые Увеличится время на разработку программного продукта. Возможно снижение качества Организация работы Участники проекта территориально удалены Обмен информацией внутри группы затрудняется. Время на достижение целей проекта увеличивается Качественный анализ рисков 175 Основная проблема управления рисками заключается в размере перечня рисков, полученного на этапе идентификации. Управлять всеми выявленными рисками невозможно, так как это требует больших финансовых и кадровых затрат. Основные задачи качественного анализа состоят в разделении рисков на группы и расположении в порядке их приоритетов. Классифицировать риски можно, например, по их временной близости. Так, близкие риски должны иметь более высокий приоритет, чем риски, которые могут случиться в отдаленном будущем. Расположения рисков по степени их важности для дальнейшего анализа или планирования реагирования на риски может быть выполнено путем оценки вероятности их возникновения и воздействия на проект. Качественный анализ рисков — быстрый и недорогой способ установки приоритетов — выполняется на протяжении всего жизненного цикла проекта и должен отражать все изменения, относящиеся к рискам проекта. Входная информация для процесса качественной оценки Качественный анализ выполняется на основании следующей информации: Активы организационного процесса — данные о рисках в предыдущих проектах и база накопленных знаний. Описание содержания проекта. План управления рисками, содержащий следующие элементы: распределение ролей и ответственности в управлении рисками, бюджетом и плановыми операциями по управлению рисками; категории рисков; определение вероятности возникновения и возможных последствий; матрица вероятности и последствий; уточненная толерантность к риску участников проекта. Реестр рисков, который содержит список идентифицированных рисков. Инструменты и методы, используемые для качественного анализа рисков Определение вероятности и воздействия рисков. Вероятность и воздействие оцениваются для каждого идентифицированного риска на основании экспертных оценок и ранжируются в соответствии с определениями, представленными в плане управления проектом. В некоторых случаях риски с явно низкой степенью вероятности возникновения и воздействия в рейтинг не включаются, но включаются в список рисков, за которыми в дальнейшем ведется наблюдение. Матрица вероятности и последствий — инструмент, позволяющий определять ранг риска отдельно для каждой цели, например для стоимости, времени или содержания. Ранг риска помогает управлять реагированием на риски. Например, для рисков, расположенных в 176 зоне высокого риска (область красного цвета) матрицы необходимы предупредительные операции и агрессивная стратегия реагирования (рис. 7.4). Для угроз, расположенных в зоне низкого риска (зеленый цвет), осуществление предупредительных операций может не потребоваться. Матрица вероятностей и последствий позволяет отслеживать миграцию рисков. На рис. 7.5 и 7.6 показано изменение ранга риска А с течением времени. В апреле риск находился в зоне низкого риска, в мае переместился в область умеренного, а в апреле попал в зону высокого риска. Рис. 7.5. Отображение миграции риска А в матрице вероятности и последствий Динамика риска А 0,2 Ранг риска 0,18 0,15 0,1 0,07 0,06 0,05 0,02 0 апр.06 май.06 июн.06 июл.06 Рис. 7.6. Динамика изменения ранга риска А Классификация рисков — инструментарий категоризации всей новой информации о рисках проекта и удобного поиска существующих рисков. С помощью данного инструмента возможно разделение рисков на группы, которые затем могли бы управляться лицами, которые лучше других знают их особенности. Качественный анализ рисков: выходы 177 Реестр рисков (обновления). Обновление реестра рисков происходит на основании информации, получаемой от качественного анализа рисков: список приоритетов рисков проекта; риски, сгруппированные по категориям; список рисков, требующих немедленного реагирования; список рисков для дополнительного анализа и реагирования; список рисков с низким приоритетом, нуждающихся в наблюдении; тренды результатов качественного анализа рисков. Количественный анализ рисков Количественный анализ рисков — это количественный анализ потенциального воздействия идентифицированных рисков на общие цели проекта. Количественный анализ рисков обычно выполняется для рисков, которые были квалифицированы в результате качественного анализа. При количественном анализе также оцениваются вероятности возникновения рисков и размеры ущерба/выгоды; здесь анализируются риски, имеющие высокие и умеренные ранги. Выбор методов анализа определяется для каждого проекта и зависит от наличия времени и от бюджета. Количественный анализ рисков: входы Исходной информацией для количественного анализа рисков служат: Активы организационного процесса. Описание содержания проекта. План управления рисками. Реестр рисков. План управления проектом. Количественный анализ рисков: инструменты и методы Наиболее распространенными методами количественного анализа являются: Методы сбора и представления данных, к которым относятся опросы и экспертная оценка, были описаны в разделе идентификации рисков. Анализ чувствительности помогает определить, какие риски обладают наибольшим потенциальным влиянием на проект. Идея метода состоит в отслеживании параметров, 178 которые оказывают влияние на исследуемую ситуацию проекта. Фиксируя все параметры и изменяя только один из них, можно определить его воздействие на исследуемую ситуацию. Скажем, исследуя вопрос об ожидаемой прибыли Исполнителя проекта, выделяем влияющие на нее параметры, например такие: отсутствие квалифицированного персонала и необходимость в его привлечении, отсутствие помещения под проектный офис и необходимость аренды проектного офиса, отсутствие необходимых технических средств для оборудования рабочих мест и необходимость в закупке требуемых средств. Затем выполняем анализ чувствительности для выделенного параметра, обладающего наибольшим потенциальным риском. Анализ дерева решений. В сложных ситуациях, когда трудно вычислить результат проекта с учетом возможных рисков, используют метод анализа дерева решений. Дерево решений — это графический инструмент для анализа проектных ситуаций, находящихся под воздействием риска. Дерево решений описывает рассматриваемую ситуацию с учетом каждой из имеющихся возможностей выбора и возможного сценария. Дерево решений имеет пять элементов (рис. 7.7). Точки принятия решений — это моменты времени, когда происходит выбор альтернатив. Точка случайного события (точка возникновения последствий) — момент времени, когда с тем или иным результатом наступает случайное событие. Ветви — линии, соединяющие точки принятия решений с точками случайного события. Ветви, исходящие из точки принятия решений, показывают возможные решения, а линии, исходящие из узлов случайных событий, представляют возможные результаты случайного события. Вероятности — числовые значения, расположенные на ветвях дерева и обозначающие вероятность наступления этих событий. Сумма вероятностей в каждой точке принятия решений равна 1. Ожидаемое значение (последствия) — это расположенное в конце ветви количественное выражение каждой альтернативы. Модель создается слева направо. Построение начинается с отображения точки принятия решения, имеющей вид квадрата. Из этой точки рисуют количество ветвей, равное числу проектных альтернативных решений. В конце каждой ветви рисуют кружок, обозначающий возникновение допустимого случайного события, из которого выходят две ветви — возможные результаты вероятностного события. Ветви дерева берут свое начало в точке принятия решений и разрастаются до получения конечных результатов. Путь вдоль ветвей дерева состоит из последовательности отдельных решений и случайных событий. 179 Рассмотрим пример. Торговая компания открывает новый магазин, который должен быть укомплектован новейшим оборудованием. Оборудование производят два конкурирующих поставщика (П1 и П2), объявивших одну и ту же дату появления на рынке нового оборудования. Для увеличения эффективности работы компания планирует осуществить внедрение ИС класса ERP. Разработаны три варианта расписания внедрения информационной системы: (Вариант 1, Вариант 2, Вариант 3). Длительность проекта рассматривается как параметр первостепенной важности. Расписание внедрения ИС зависит от поставки и монтажа оборудования. Команда проекта оценила вероятность того, что поставщик 1 (П1) или поставщик 2 (П2) поставит нужное оборудование первым. Анализ информации о прежних разработках поставщиков позволил предположить, что поставщик 1 поставит на рынок новое оборудование с вероятностью 60%, соответственно для поставщика 2 эта вероятность будет равна 40%. Команда проекта разработала сетевые графики трех альтернативных вариантов расписания внедрения ИС при условии, что оборудование уже поставлено, и оценила возможные значения продолжительности проекта. Вероятность Ожидаемое значение П1 (0,6) 80 Вариант 1 (76) А 70 Б П2 (0,4) 75 0 П1 (0,6) Вариант 3 (78) Точка принятия решения 70 П1 (0,6) Вариант 2 (72) 1 П2 (0,4) 75 В П2 (0,4) 80 Альтернативное решение Точка случайного события (узел) Рис. 7.7. Дерево решений для проектной ситуации, находящейся под воздействием риска Рассчитаем возможную длительность проекта для каждого точки случайного события: 180 ожидаемая длительность для случайного узла А: (80дней* 0,6) + (70дней *0,4) = 76дней ожидаемая длительность для случайного узла Б: (70дней * 0,6) + (75дней *0,4) = 72дней ожидаемая длительность для случайного узла В: (75дней * 0,6) + (80дней *0,4) = 78дней Результат дерева решений — вариант расписания с наименьшей продолжительностью, равной 72 дням. Дерево решений — инструмент, который позволяет наглядно провести анализ проектных решений, содержащих несколько путей решения. Результаты количественного анализа рисков Реестр рисков (обновления) В процессе идентификации рисков начинается формирование реестра рисков, в процессе качественного анализа рисков выполняется его обновление, во время количественного анализа рисков происходит повторное обновление реестра. Реестр рисков является составной частью плана управления проектами, поэтому обновлению подлежат следующие основные элементы плана: Вероятностный анализ проекта, который выполняет оценку потенциальных выходов расписания и стоимости проекта и составляется перечень контрольных дат завершения и стоимости. Результат анализа, в виде распределения кумулятивных вероятностей, с учетом толерантности к риску участников проекта, позволяет корректировать стоимостную и временную составляющие резерва на непредвиденные обстоятельства. Вероятность достижения целей по стоимости и времени. При помощи результатов количественного анализа рисков можно оценить вероятность достижения целей проекта на фоне текущих плановых показателей. Список приоритетных оцененных рисков, куда включены риски, которые представляют наибольшую угрозу или наилучшие благоприятные возможности проекту. Тренды результатов количественного анализа рисков могут способствовать принятию решений, влияющих на реагирование на риски. Планирование реагирования на риски Процесс планирования реагирования на риски начинается после проведения качественного и количественного анализа рисков. На этом этапе следует назначить 181 ответственных за реагирование и разработать предупреждающие действия для каждого риска. Планирование реагирования на риски — это процесс разработки методов и процедур, способствующих повышению благоприятных возможностей и снижению угроз для достижения целей проекта. Способы реагирования рассматриваются для каждого риска отдельно. Входы процесса планирования реагирования на риски Входной информацией для планирования реагирования на риски является: план управления рисками — результат процесса планирования рисков; реестр рисков — результат процесса количественного анализа рисков. Инструменты и методы процесса планирования реагирования на риски Планирование реагирования на риски осуществляется с помощью стратегий реагирования на риски. Стратегия реагирования на риски — это методы, которые будут использованы для снижения последствий или вероятности идентифицированных рисков [4.2]. Для каждого риска необходимо выбрать свою стратегию (или комбинацию из различных стратегий), которая обеспечит наиболее эффективную работу с ним. Выбор стратегии осуществляется на основании результатов количественной и качественной оценок, позволяющих определить, сколько времени, денег и усилий потребуется затратить для ограничения риска. Существует четыре типовые стратегии реагирования на появление негативных рисков: уклонение, передача, принятие и снижение. Уклонение от риска. Эта стратегия состоит в полном исключении воздействия риска на проект за счет изменений характера проекта или плана управления проектом. Некоторые риски, возникающие на ранних стадиях проекта, например из-за отсутствия четкого определения требований Заказчика, можно избежать, затратив дополнительное время и увеличив трудозатраты на их выявление. Однако стратегия уклонения не может полностью исключить риск. Передача риска. Стратегия передачи также исключает угрозу риска путем передачи негативных последствий с ответственностью за реагирование на третью сторону. Передача риска обычно сопровождается выплатой премии за риск стороне, принимающей на себя риск и ответственность за его управление. Сам риск при этом не устраняется. Условия передачи ответственности за определенные риски третьей стороне могут определяться в контракте. Для IT-проектов третьей стороной может выступать консалтинговая компания, на которую возлагается ответственность по управлению рисками. Принятие риска. Стратегия означает решение команды не уклоняться от риска. При пассивном принятии команда ничего не предпринимает в отношении риска и в случае его 182 возникновения разрабатывает способ его обхода или исправления последствий. При активном принятии план действий разрабатывается до того, как риск может произойти, и называется планом действий в непредвиденных обстоятельствах. Снижение риска. Стратегия предполагает усилие, направленное на понижение вероятности и/или последствий риска до приемлемых пределов. В стратегии снижения используется включение в план проекта дополнительной работы, которая будет выполняться независимо от возникновения риска, как, например, проведение дополнительного тестирования функциональности информационной системы, разработка прототипа системы, дополнительное подключение к работе опытных сотрудников. Планирование реагирования на риски: выходы Реестр рисков (обновления). Способы реагирования на риски, разработанные и утвержденные в процессе планирования реагирования, включаются в Реестр рисков. План управления проектом (обновления). Обновление плана управления проектом происходит за счет добавления операций реагирования на риски в процессе общего управления изменениями проекта. Контрактные соглашения, касающиеся рисков. Контрактные соглашения составляются для того, чтобы юридически определить ответственность каждой из сторон на случай возникновения каждого отдельного риска. Это могут быть договоры страхования или оказания услуг. Мониторинг и управление рисками Мониторинг и управление рисками — процесс отслеживания идентифицированных рисков, мониторинга остаточных рисков, идентификации новых рисков, исполнения планов реагирования на риски и оценки их эффективности на протяжении жизненного цикла проекта [4.2]. Мониторинг рисков является последним этапом процесса управления рисками. Он важен для эффективной реализации действий, запланированных на предыдущих этапах . Мониторинг — это наблюдательная деятельность, предусмотренная ранее составленным планом управления рисками. Мониторинг обеспечивает своевременное исполнение превентивных мер и планов по смягчению последствий и выполняется с помощью индикаторов — триггеров (другое название — «признаки рисков», «симптомы риска»), указывающих на возможность то, что события риска произошли или произойдут в ближайшее время. Симптомы рисков определяются на этапе идентификации рисков и фиксируются в Плане управления проектом в разделе «План управления рисками». 183 Примеры параметров, к которым могут быть привязаны признаки рисков и за которыми может проводиться регулярное наблюдение [1.5]: количество «открытых» (найденных и неисправленных) ошибок на один модуль или компонент; среднее за неделю количество сверхурочных часов работы на одного сотрудника; еженедельное количество изменений в требованиях к разрабатываемой системе; изменения бизнес-процессов Заказчика; своевременность выделения требуемых ресурсов; техническое обеспечение работ. Цель мониторинга состоит в наблюдении за прогрессом выполнения принятых планов (предотвращения рисков и смягчения их последствий), количественными параметрами, условиями, определяющими применения плана реагирования на риски, и в информировании команды в случае наступления риска. Во время мониторинга команда проекта выполняет планы по предотвращению рисков. За прогрессом этой деятельности ведется наблюдение. Отслеживаются изменения значений триггеров рисков. Для удобства выполнения мониторинга применяют специальные формы [1.5], пример которой приведен в таблице 7.8 Таблица 7.8. Пример формы для мониторинга рисков Тип риска Описание риска Политичес кий Заказчик решил не внедрять систему Политичес кий Ввиду того, что выбор системы (и подрядчика) проводился холдинговым руководством Заказчика, сам Заказчик на текущий момент не заинтересован в проекте и внедрении Проактивные мероприят ия Плана нивелирова ния риска не существует. Заказчик решает либо внедрять систему, либо не внедрять 1. Проведение ряда заблаговременных семинаров, повышающих уровень заинтересованности Заказчика во внедрении системы Реактивные мероприя тия Если Заказчик не представля ет стратегиче ской ценности для OXS, не начинать проект n/a Пороговые состояния Веро ятно сть Вли Фактор яние риска 6 9 54 8 4 32 184 системы 2. Организация референсвизитов к успешным клиентам 3. Определение реальных лидеров в организации, Точечное повышение уровня их заинтересованности в успешном внедрении 4. ... 0 Исходные данные для процесса мониторинга План управления рисками. Реестр рисков. Одобренные запросы на изменение, которые могут содержать изменения методов работы, условий контрактов, содержания и расписания. Информация об исполнении работ. Отчеты об исполнении. Отчеты об исполнении содержат информацию о выполнении работ проекта, способных повлиять на процесс управления рисками. Мониторинг и управление рисками: инструменты и методы Пересмотр рисков должен проводиться регулярно, согласно расписанию, составленному на этапе планирования. В процессе мониторинга и управления рисками может возникать необходимость в проведении идентификации новых рисков, пересмотре состояния известных рисков и планировании дополнительных мероприятий по реагированию на риски. Аудит рисков предполагает анализ эффективности мероприятий по и документирование результатов оценки реагированию на риски, изучение причин их возникновения, оценку эффективности процесса управления рисками. Анализ отклонений и трендов. Тренды в процессе выполнения проекта подлежат проверке с использованием данных о выполнении. Для мониторинга выполнения всего проекта используют методику освоенного объема. Отклонения от базового плана могут указывать на вызванные рисками последствия. 185 Анализ резервов. При анализе резервов производится сравнение объема оставшихся резервов на непредвиденные обстоятельства с количеством оставшихся рисков. Совещания по текущему состоянию. Периодические совещания команды проекта по вопросам управления рисками являются инструментом для отслеживания состояния рисков проекта. Мониторинг и управление рисками: выходы Реестр рисков (обновления). Обновленный реестр рисков включает в себя результаты пересмотра рисков, аудита и периодической проверки рисков, фактические результаты рисков проектов и результаты реагирования на риски. Реестр рисков становится частью документации по закрытию проекта. Запрошенные изменения. Запрошенные изменения возникают в результате необходимости изменения плана управления проектом в ответ на риск. Одобренные запросы на изменения оформляются документально. Рекомендованные корректирующие действия. К рекомендованным корректирующим действиям относятся работы, внесенные в планы на непредвиденные обстоятельства. Рекомендованные предупреждающие действия используются для приведения проекта в соответствие с планом управления проектом. Активы организационного процесса (обновления). Результаты управления рисками выполняемого проекта могут быть использованы в будущих проектах и должны войти в состав активов организационного процесса. План управления проектом (обновления). Если одобренные запросы на изменения затрагивают процессы управления рисками, то необходимо обновить соответствующие части плана управления проектом. 186 Приложение 7 7.1. Форма 1 Общий анализ проектных рисков Информация о клиенте Название клиента Основное контактное лицо Внутренняя информация о клиенте Код проекта Ответственный за проект Руководитель проекта 7.2. Форма 2 для общего анализа проектных рисков Фаза Выбор системы Позиционирование Определение объема работ Разработка дизайна Построение системы Тестирование системы Внедрение Ввод в эксплуатацию Анализ рисков провел Анализ рисков одобрил Дата одобрения 7.3. Форма 3 для общего анализа проектных рисков Итог по фазе Выбор системы Позиционирование Определение объема работ Разработка дизайна Построение системы Тестирование системы Внедрение Ввод в эксплуатацию Всего Высокие риски Средние риски 2 0 0 0 1 2 2 4 11 1 1 2 9 3 3 1 3 23 Низкие риски Кол-во рисков 0 2 3 7 1 2 1 3 19 3 3 5 16 5 7 4 10 53 7.4. Форма запроса на регистрацию риска 187 Запрос на регистрацию риска Номер в журнале рисков: < > ФИО автора запроса: < > Роль на проекте: < > Наименование проекта: < > Фаза проекта: <> <Заполняется автором запроса> Приоритет:< Высокий, Средний, Низкий > Дата запроса: <дд.мм.гггг> Желаемая дата разрешения: <дд.мм.гггг> Описание риска: <Заполняется автором запроса> <Детальное описание риска, контрольная точка (дата) наступления рискового события> Предпосылки: <Описание причин возникновения риска> Последствия: <Описание влияния на проект рисковых событий> Варианты решения: <Описание предложений по вариантам решения> 7.5. Форма контроля рисков: Проек т Риск Наименование и описание рисков Предлагаемое действие Отв. Срок <Назван ие проекта > <Р или П> <Короткое наименование и детальное описание риска> <Владелец риска > <Проект решения (описание действия)> <Ответст венный> <дд.мм.гг гг> <Проект решения (описание действия)> <Ответст венный> <дд.мм.гг гг> <Проект решения (описание действия)> <Ответст венный> <дд.мм.гг гг> 188 Лекция 8. УПРАВЛЕНИЕ КАЧЕСТВОМ ПРОЕКТА Концепция управления качеством. Стандарты управления качеством проектов в области ИТ. Три процесса управления качеством: планирование качества, обеспечение качества, контроль качества. Основные задачи и процедуры планирования качества; описание связей с другими процессами. Методы, средства и процедуры, используемые для планирования качества. Обеспечение качества проекта: аудиторские проверки качества, методы непрерывного улучшения качества будущих проектов. Контроль качества. Методы контроля качества. Процедуры анализа качества. Анализ состояния и обеспечения качества в проекте. Ключевые слова: качество, управление качеством, планирование качества, обеспечение качества. Согласно PMBOK, целью любого проекта является удовлетворение требований участников проекта [4.1]. Обеспечение данной цели достигается путем обеспечения качества проекта. Качество — это целостная совокупность характеристик объекта, относящихся к его способности удовлетворять установленные или предполагаемые потребности. Примеры качества: готовность, безотказность, безопасность, надежность. Управление качеством (в рамках управления проектом) — это система методов, средств и видов деятельности, направленных на выполнение требований участников проекта к качеству самого проекта и его продукции. Как самостоятельная область профессиональной деятельности, управление качеством имеет собственные стандарты, к которым относятся: — ISO9000 (в России ГОСТ Р ИСО 9001-96) — стандарт для обеспечения качества результатов проектов; — ISO10006 — стандарт регламентирует качество осуществления процессов управления проектами. Стандарты ISO 9000 имеют самое широкое распространение в мире стандартов по системам качества. С 1 января 2002 года введена новая редакция стандартов ИСО 9000:2000: ИСО 9001. Система менеджмента качества. Требования; ИСО 9004. Система менеджмента качества. Руководство для улучшения характеристик СМК для повышения эффективности предприятия. Основные принципы управления качеством по стандартам серии ISO 9000:2000: ориентация деятельности Компании на клиента; управляемость и наблюдаемость всех процессов Компании; 189 вовлечение и мотивация персонала; процессное представление всех видов деятельности; системный подход к управлению; непрерывное совершенствование системы менеджмента качества (СМК); достоверность информации для управленческих решений; взаимовыгодные отношения с поставщиками. Стандарт ISO10006 имеет название «Менеджмент качества. Руководство качеством при управлении проектами». Основные принципы управления качеством по стандартам серии ISO 10006:1997: — ориентация деятельности Компании на клиента; — ответственность руководства за создание благоприятной среды в отношении качества и непрерывное совершенствование СМК; — представление проекта как набора запланированных и взаимоувязанных процессов; — сфокусированность на качестве продуктов и услуг как необходимое условие соответствия целям проекта; — процессное представление всех видов деятельности; — системный подход к управлению проекта в целом. Основными процессами управления проектами по стандарту ISO 10006:1997 являются процессы определения стратегии, процессы управления взаимосвязями в проекте, процессы управления реализацией проекта, включающие управление предметной областью, управление сроками, управление затратами, управление ресурсами, управление персоналом, управление информацией, управление рисками, управление материально-техническим снабжением. Управление качеством проекта осуществляется на протяжении всего жизненного цикла проекта. На рис. 8.1 представлены стадии управления качеством проекта. Стадия «Концепция». На этой стадии определяется политика и стратегия для обеспечения качества разрабатываемого продукта, удовлетворяющего ожидаемым запросам потребителя. «Концепция» имеет следующие разделы: — Политика и стратегия качества; — Общие требования и принципы обеспечения качества; — Стандарты, нормы и правила; — Интеграция функций обеспечения качества; — Требования к системе управления качеством. 190 Стадия планирования. На стадии планирования качества определяются стандарты, которые следует использовать, чтобы содержание проекта оправдывало ожидания участников проекта. Планирование качества включает как идентификацию этих стандартов, так и поиск путей их реализации. Ниже перечислены основные задачи стадии планирования: — определение показателей оценки качества; — определение технических спецификаций; — описание процедур управления качеством; — составление списка объектов контроля; — выбор методов и средств оценки качества; — описание связей с другими процессами; — разработка плана управления качеством. Стадия организации. Стадии организации контроля качества предполагает создание необходимых и достаточных организационных, технических, финансовых и др. условий для обеспечения выполнения требований к качеству проекта и продукции проекта и возможностей их удовлетворения. КОНЦЕПЦИЯ ЗАВЕРШЕНИЕ ПЛАНИРОВАНИЕ РЕГУЛИРОВАНИЕ АНАЛИЗ ОРГАНИЗАЦИЯ КОНТРОЛЬ Рис. 8.1. Стадии процесса управления качеством Стадия контроля. Контроль качества заключается в определении соответствия результатов проекта стандартам качества и причин нарушения такого соответствия. Стадии регулирования и анализа. Стадия осуществления контроля качества предполагает регулярную проверку хода реализации проекта в целях установления фактического соответствия определенным ранее требованиям. 191 — Сравнение фактических результатов проекта с требованиями. — Анализ прогресса качества в проекте на протяжении его жизненного цикла. — Формирование списка отклонений. — Корректирующие действия. — Документирование изменений. Стадия завершения. На стадии завершения выполняются сводная оценка качества результатов проекта, завершающая приемка, составление списка претензий по качеству, разрешение конфликтов и споров, оформление документации, анализ опыта и полученных уроков по управлению качеством. Основными процессами обеспечения качества проекта являются планирование качества, его обеспечение и контроль. Связь этих процессов, их входы и выходы представлены на рис. 8.2. План управления проектом Описание содержания проекта Факторы внешней среды предприятия (национальные стандарты, регламенты) Активы организационного процесса (политика в области качества, принципы и процедуры) Планирование качества План управления проектом (обновления) План управления качеством Результаты оценки качества Контрольные списки процедур контроля качества План совершенствования процессов Базовый план по качеству Одобренные запросы на изменение Выполненные корректирующие действия Выполненные предупреждающие действия Выполненные исправления дефектов Информация об исполнении работ Результаты поставки Процесс обеспечения качества Результаты контроля качества Процесс контроля качества Запрошенные изменения Рекомендуемые корректирующие действия Плен управления проектом (обновления) Результаты контроля качества Базовый план по качеству (обновления) Рекомендуемые корректирующие действия Рекомендуемые предупреждающие действия Рекомендуемое исправление дефектов План управления проектом (обновления) Утвержденные результаты поставки Утвержденное исправление дефектов Запрошенные изменения Рис. 8.2. Связь процессов управления качеством проекта 192 Планирование качества проекта Планирование качества — процесс определения того, какие из стандартов качества относятся к данному проекту и как их удовлетворить [4.1]. Планирование качества осуществляется как часть планирования проекта и выполняется совместно руководителем проекта, архитектором проекта и ответственным за качество проекта. В план управления качеством включаются работы, выполнение которых обеспечивает качество результатов проекта. Одной из главных составляющих плана управления качеством IT-проектов, является план проведения тестирования. Пример формы плана тестирования представлен на рис. 8.3. № Сценария Сценарий Предпосылки Плановая дата Место проведения Ответственные Участники Комментарий к форме: № Сценария: Уникальный идентификатор сценария тестирования. Сценарий: Название сценария тестирования. Предпосылки: Перечень предварительных условий, которые должны быть выполнены перед тем, как приступать к прохождению сценария. Если таким условием является необходимость предварительного прохождения других сценариев, приводятся номера этих сценариев. 4) Плановая дата: Плановая дата проведения тестирования в формате ДД.ММ.ГГГГ. 5) Место проведения: Предполагаемое место проведения тестирования (указывается полный адрес, и, по возможности, номер комнаты). 6) Ответственные: Перечень сотрудников, ответственных за подготовку и проведение тестирования (в формате И.О.Фамилия). 7) Участники: Перечень участников тестирования (в формате И.О.Фамилия). В тестировании в обязательном порядке должны участвовать координаторы соответствующих функций и процессов. Сценарии в таблице упорядочены по плановой дате, далее — по номеру. 1) 2) 3) Рис. 8.3. Пример формы плана тестирования План по качеству должен определять, как в проекте будет обеспечено качество выполнения работ с позиции организационной структуры, ресурсов, методического обеспечения. На стадии планирования качества рекомендуется разработать документы, регламентирующие действия по контролю качества управления проектом (форму отчетности по выполнению проекта, анкеты мониторинга проекта) и процедуры управления качеством, например контроль качества результатов проекта, контроль качества документов проекта, утверждение документов проекта, подготовка и проведение контроля проекта. Для контроля качества документов проекта в плане по качеству следует определить список лиц, согласующих и утверждающих каждый документ проекта, сроки и форму их согласования. Пример плана согласования документа приведен на рис. 8.4. План согласования документа 193 Список лиц, участвующих в согласовании: № 1 2 ФИО Должность План согласования: До 18:00 ХХ.ХХ.2008, лицам, участвующим в согласовании пакета документов, необходимо представить замечания в группу управления качества на электронный адрес: _____________ Способ согласования: по электронной почте. ХХ.ХХ.2008 будет организовано совещание для обсуждения замечаний. При отсутствии замечаний до указанного срока документ будет считаться согласованным и будет передан на утверждение. Рис. 8.4. Пример плана согласования документа На IT-проектах вводится множество специфических терминов, поэтому в план контроля качества проекта необходимо включать разработку и согласование глоссария проекта. Глоссарий проекта представляет собой структурированный список всех терминов и определений проекта, а также используемых аббревиатур с кратким описанием их смысла. Как правило, Руководитель группы управления качеством отвечает за пополнение и работу с Глоссарием проекта на основании поступающих документов. Проверка глоссариев документов проводится в рамках времени, отведенного на общий контроль качества документов. Пример формы Глоссария представлен на рис. 8.5. Термин/ Определение* Английское название Сокращение Объяснение* Область* Документ* Комментарий к форме глоссария: * пункты, обязательные для заполнения Термин/Определение — используемый в документе термин или определение Сокращение — принятое сокращение или аббревиация Объяснение — краткое объяснение смысла термина или определения Область — указание, к какой области деятельности проекта относится данный термин: Техническая архитектура Обучение Поддержка Приложение Проектная терминология (в том числе методологическая) Документ — из Глоссария какого документа поступил данный термин/определение Рис. 8.5. Пример формы Глоссария Планирование качества начинается с определения целей качества проекта, политик и стандартов, относящихся к содержанию проекта. Потом определяются действия и 194 обязанности членов команды, выполнение которых необходимо для достижения целей и соблюдения стандартов. Результат планирования качества представляется в форме планов обеспечения качества и процессов управления, обеспечивающих выполнение этих планов, и достигается путем синхронизации с основными (планирование содержания, расписания, стоимости) и вспомогательными (планирование рисков, команды) процессами планирования. Входная информация процесса планирования качества [4.1] Факторы внешней среды предприятия — правила, стандарты и предписания, свойственные определенным областям приложения. Активы организационного процесса — политика в области качества, принятая на предприятии, процедуры и предписания, базы данных и накопленные знания из предыдущих проектов. План управления проектом обеспечивает интеграцию процесса планирования качества с другими процессами планирования. Описание содержания проекта является ключевым входом для планирования качества, так как оно содержит описание главных результатов поставки проекта, целей проекта, критериев приемки и пороговых величин значения стоимости, времени или ресурсов. Критерии приемки включают в себя требования к исполнению проекта и могут существенным образом повлиять на его стоимость. Планирование качества: инструменты и методы Задача инструментов планирования качества — сделать процессы управления проектом предсказуемыми. Для планирования качества проекта рекомендуется использовать нижеследующие методы. Программа обеспечения качеством — план действий, обеспечивающий соответствие фактического качества проекта запланированному качеству [4.3]. На рис. 8.6 представлен пример фрагмента программы обеспечения качества. Программа обеспечения качества Название проекта: Внедрение проектного менеджмента Дата: 4.10.2007 195 21.ноя 07.ноя 30.окт 23.окт 16.окт 09.окт Зайцев Кравцов Расписание проекта октябрь/ноябрь Прохоров Матрица ответственности Лядов 6 Котов 5 Сидоров 4 Задача обеспечения качества 3 Стандарт качества 2 Элемент ИСР Код элемента ИСР 1 14.ноя Исполнитель: Иванов И.И. 10030 Разработка руководства по управлению проектами Легкость чтения по Флешу* (не менее 70) Выполнение тестов и переписывание ISO 9000 Пересмотр PMBOK Краткость изложения (не более 10 страниц) Пересмотр Организационные политики по написанию руководств В В В В Проверка и коррекция Пересмотр В В В В У У У У Обозначения: В — выполнение У — утверждение * Индекс легкости чтения по Флешу, определяется по среднему числу слогов в слове и слов в предложении. Пределы изменения индекса — от 0 до 100. Чем выше величина индекса, тем легче прочтение текста и тем большему числу читателей он будет понятен. Рис. 8.6. Пример фрагмента программы обеспечения качества Разработка программы начинается с подготовки исходной информации, включающей политики и процедуры компании в области качества, требования Заказчика, описание содержания проекта и ИСР. В политике обеспечения качества обычно излагаются способы управления качеством — процедуры обеспечения качества, принятые компанией. Основой для создания программы качества является ИСР. Программа качества для пакетов работ проекта получается путем суммирования программ обеспечения качества для всех элементов этого пакета, программа проекта — путем суммирования программ пакетов работ. Для измерения ожиданий Заказчика устанавливают стандарты качества (рис. 8.6, столбец 3). Стандарты могут быть международными, национальными или корпоративными. После того как стандарты качества установлены, нужно определить задачи, решение которых обеспечит соответствие стандартам (рис. 8.6, столбец 4), далее закрепляется ответственность за выполнение намеченных работ и сроки их исполнения. Как правило, работы по обеспечению качества не включаются в ИСР проекта и не попадают в матрицу ответственности и расписание проекта, а следовательно, не включаются в бюджет проекта, что приводит в дальнейшем либо к удорожанию проекта, либо к снижению запланированного качества. Разработка программы качества направлена на предотвращение этих проблем. Программа обеспечения качества проекта, имеющая форму таблицы, дает высокую степень наглядности работ, обеспечивающих запланированное качество выполнения требований Заказчика. Недостатком данного инструмента является его сложность для команд, не привыкших к использованию стандартов. 196 Анализ выгод и затрат. Цель метода — выдержать необходимое соотношение между доходами и затратами в проекте. Обеспечение качества проекта, несомненно, приводит к дополнительным расходам, поэтому для каждого предложенного метода обеспечения качества необходимо анализировать коэффициент рентабельности. На рис. 8.7 представлен выбор оптимальной пропорции затрат на профилактику дефектов и устранение дефектов [4.2]. 140 120 100 80 60 40 20 0 Стоимость проверки Общая стоимость 1 2 3 4 5 6 7 Стоимость устранения дефектов Рис. 8.7. Соотношение затрат и выгод в обеспечении качества В таблице 8.1 приведены примеры затрат на обеспечение качества. Таблица 8.1. Перечень статей затрат Затраты на профилактику Затраты на устранение дефектов Дополнительное планирование Приведение функционала в соответствие с бизнес-процессами Заказчика Теоретическое и практическое обучение Доработка команды и участников проекта Инспекция и тестирование внутренних и Устранение ошибок внешних результатов поставки проекта Усовершенствование проекта для Юридические проблемы, вызванные обеспечения качества несоблюдением условий по качеству Персонал для обеспечения качества Обязательства, связанные с дефектом План обеспечения качества и его Организация и проведение повторного выполнение интеграционного тестирования Бенчмаркинг включает в себя сопоставление действующего или планируемого проекта с другими проектами с целью выработать идеи для повышения качества исполнения проекта. Планирование экспериментов — статистический метод, позволяющий определить факторы, которые оказывают влияние на определенные переменные величины продукта или процесса. 197 Стоимость качества — совокупная стоимость всех действий, направленных на повышение качества продукта или услуги и обеспечение их соответствия определенным требованиям, а также на предупреждение факторов, способных вызвать снижение качества продукта или услуги и их несоответствие требованиям (доработка). Планирование качества: выходы План управления качеством — описание того, каким образом команда управления проектом будет осуществлять политику исполняющей организации в области качества. В зависимости от потребностей проекта план управления качеством может быть очень подробным или обобщенным. В таблице 8.2 представлен пример фрагмента плана обеспечения качества проекта [8.1]. Мероприятия по обеспечению качества проекта 1. Анализ требований результатов проекта 2. Выбор и утверждение стандартов выполнения проекта 3. Разработка и утверждение плана управления рисками проекта 4. Задачи обеспечения качества Таблица 8.2. План обеспечения качества проекта График исполнения (в неделях) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 4.1. Разработка и утверждение процедуры управления проблемами (отклонениями) в проекте 4.2. Мониторинг статуса рисков и проблем проекта 4.3. Совещания рабочей группы проекта (еженедельно) 4.4. Рецензирование и утверждение проектных документов, передаваемых Заказчику 4.4.1. Рецензирование и утверждение технического задания 4.4.2. Рецензирование и утверждение технического проекта 4.4.3. Рецензирование и утверждение других документов 4.5. Совещание по анализу результатов этапа проекта 5. Задачи организации и тестирования испытаний 5.1. Разработка и утверждение методики испытаний и тестирования ИС 5.2. Разработка и утверждение плана испытаний 5.3. Разработка и утверждение отчета по результатам испытаний и тестирования 5.4. Подготовка и утверждение акта приемки ИС 6. Внутренние и внешние аудиты проекта 6.1. Внутренние аудиты 6.2.1. Аудит фазы инициации проекта (в соответствии стандарту компании по управлению проектами) 6.2.2. Аудит фазы выполнения проекта (в соответствии стандарту компании по управлению проектами) 6.1.3. Аудит фазы завершения проекта (в соответствии стандарту компании по управлению проектами) 6.2. Внешние аудиты 198 Мероприятия по обеспечению качества проекта 6.2.1. Аудит представителями поставщика ИС по выполнению методологии внедрения ИС 6.2.2. Аудит хода выполнения проекта представителями Заказчика 7. Подготовка и утверждение отчета о выполненном проекте или этапе проекта График исполнения (в неделях) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 Мероприятия по обеспечению качества должны быть разработаны в самом начале проекта и проводиться на основе независимых экспертных оценок. Контрольные списки процедур контроля качества — структурированный документ, который используется для подтверждения выполнения всех намеченных операций. Такие списки позволяют убедиться в правильной последовательности действий в часто выполняемых задачах. Контрольные списки качества используются в процессе контроля качества. Базовый план по качеству содержит требования к качеству данного проекта и служит основой для оценки и составления отчетов по исполнению требований качества. План управления проектом (обновления). Обновление плана происходит вследствие добавления к нему вспомогательного плана управления качеством. Запрошенные изменения подвергаются экспертной оценке и вносятся в соответствующие планы в процессе общего управления изменениями. Процесс обеспечения качества Обеспечения качества — процесс выполнения плановых систематических операций по качеству, которые обеспечивают выполнение всех предусмотренных процессов, необходимых для того, чтобы проект соответствовал установленным требованиям по качеству [4.1]. Функцию обеспечения качества может выполнять команда проекта, руководство исполняющей организации, заказчик или спонсор, другие участники проекта. Для контроля качества проекта проводятся аудиторские проверки, целью которых является выяснение, удовлетворяет ли качество проекта стандартам, установленным в плане обеспечения качества. Процесс обеспечения качества включает методы непрерывного улучшения качества будущих проектов. Знания и опыт по обеспечению качества, накопленные в текущем проекте, должны использоваться при составлении планов обеспечения качества последующих проектов. Входы процесса обеспечения качества План управления качеством, содержащий описание, как будет осуществляться обеспечение качества в рамках проекта. 199 Результаты оценки качества. План улучшения процесса. Информация об исполнении работ — это информация (о состоянии результатов поставки, о необходимых корректирующих действиях, а также отчеты об исполнении), которая используется при проведении аудита, экспертной оценке качества и анализе процессов. Одобренные запросы на изменение содержат изменения, касающиеся методов работы, требований к продукту, требований к качеству, содержанию и расписанию. Одобренные изменения проверяются на возможность их влияния на план управления качеством. Контрольные списки качества (метрики качества). Контрольный список представляет собой страницу с инструкциями для проверяющего лица. Пункты списка должны быть достаточно значимыми, поскольку, если контрольный список будет перегружен, его не будут использовать. Пример контрольного списка приведен в таблице 8.3. Таблица 8.3. Контрольные списки для проверки управления проектом и отчетности (фрагмент) Этап проекта Ожидаемый результат Тип Анализ проекта Наличие протоколов по анализу результатов каждой фазы проекта Документирование корректирующих действий по уменьшению нежелательных последствий отклонений по срокам Управление изменениями происходит в соответствии с утвержденной процедурой Документирование всех запросов на изменение в соответствии с принятой формой и их сохранение в единой базе Критический Управление проектом Управление проектом Управление изменениями Да Нет Серьезный Серьезный Критический Результаты контроля качества — результат выполнения операций по контролю качества. Данные о результатах контроля передаются исполняющей организации для использования в процессе обеспечения качества, для повторной оценки и анализа стандартов качества. Пример формы представления результатов контроля качества приведен в таблице 8.4. Таблица 8.4. Форма представления результатов контроля качества 200 Объект контроля качества № п.п Дата замечания Замечание Автор замечания Процесс обеспечения качества: инструменты и методы Инструменты и методы планирования качества могут использоваться для операций по обеспечению качества. Аудит качества — независимая экспертная оценка, определяющая, насколько операции проекта соответствуют, и соответствуют ли, установленным в рамках проекта или организации правилам процессам и процедурам. Целью аудита качества является выявление неэффективных и экономически не оправданных правил, процессов и процедур, используемых в проекте. Количество и сроки плановых проектных аудитов могут определяться основными этапами проекта или ключевыми событиями. Внеплановые аудиты проводятся по запросам Заказчика, руководителей департаментов и отделов. Аудиты качества проводятся на основе критериев, каждый из которых является следствием требований нормативной документации системы менеджмента качества (требование ISO 9000) и системы управления проектами (PMBOK). Схема проведения внутреннего аудита качества проекта может выглядеть следующим образом: анализ исправления замечаний предыдущей проверки; проведение проверки проекта в соответствии с контрольными списками; оформление отчета о контроле качества; информирование команды проекта о появлении новых отчетных документов. Анализ процесса предусматривает выполнение действий, описанных в плане улучшения процесса и направленных на выявление организационных и технических моментов, которые нуждаются в улучшении. Процесс обеспечения качества: выходы Запрошенные изменения имеют целью проведение специальных мероприятий по повышению эффективности правил, процедур и процессов в исполняющей организации. Рекомендованные корректирующие действия. Корректирующее действие — это рекомендованное к немедленному исполнению действие, выработанное в результате мероприятий по обеспечению качества (аудита или анализа процессов). Активы организационного процесса (обновления). Обновленные стандарты качества используются в дальнейшем процессе контроля качества. 201 План управления проектом (обновления) подлежит обновлению согласно изменениям в плане управления качеством, выработанным в результате процесса обеспечения качества. Запрошенные изменения в план управления проектом и во вспомогательные планы (добавления, изменения, удаления) подвергаются экспертной оценке и вносятся в соответствующие планы в процессе общего управления изменениями. Процесс контроля качества Контроль качества — процесс, который промежуточных результатов проекта, определение включает отслеживание их соответствия принятым стандартам и разработку действий для устранения причин, вызывающих отклонения от стандарта [4.1]. Управление качеством должно производиться на всех этапах выполнения проекта. Количественная оценка контроля качества осуществляется на основе статистического анализа и теории вероятности. Процесс контроля качества: входы План управления качеством. Результаты оценки качества. Контрольные списки процедур контроля качества. Активы организационного процесса. Информация исполнения, об исполнении состояние работ завершенности включает техническое результатов поставки измерение проекта и исполнение необходимых корректирующих действий. Одобренные запросы на изменение могут содержать такие изменения, как исправленные методы работы и исправленное расписание. Результаты поставки. Процесс контроля качества: инструменты и методы Для осуществления контроля качества используют следующие методы и средства: Диаграмма причинно-следственных связей помогает отразить возможные причины, влияющие на качество продукта или процесса в проекте. Такая диаграмма, которую также называют диаграммой Ишикавы или диаграммой рыбьего скелета, иллюстрирует связь различных факторов с возможными проблемами или эффектами [4.1]. На рис. 8.8 показан пример диаграммы причинно-следственных связей. 202 Время Технология Оборудовани е 1.2 Среда Качество продукта (процесса) 1.1 1. 2.1 2.2 2. Энергия 3. Измерения Персонал Материал Следствие Причины Рис. 8.8. Диаграмма причинно-следственных связей Контрольные диаграммы предназначены для определения стабильности протекания процесса и предсказуемости его развития. Отражают результаты осуществления проекта во времени и используются для определения, вызваны ли наблюдаемые отклонения процесса обычными вариациями в процессе или же свидетельствуют о выходе процесса из-под контроля. Контрольные диаграммы представляют собой графическое отображение взаимодействия переменных процесса в течение процесса и дают ответ на вопрос, находятся ли переменные процесса в рамках установленных пределов. Пример контрольной диаграммы представлен на рис. 8.9. 203 Рис. 8.9. Пример контрольной диаграммы При помощи контрольной диаграммы можно определять, как внесенные изменения повлияли на улучшение процесса, — это осуществляется посредством постоянного мониторинга выходных данных процесса во времени. Контрольные диаграммы могут использоваться для отображения жизненного цикла как проекта, так и продукта. Например, применение контрольных диаграмм в проекте позволяет определить, насколько отклонения по стоимости и отклонения по срокам выходят за рамки допустимых пределов (скажем, +/-10 процентов). Контрольные диаграммы можно использовать для наблюдения за любыми выходными переменными. Хотя контрольные графики чаще всего нужны для отслеживания повторяющихся операций, они также могут применяться для наблюдения за колебаниями издержек и исполнением расписания, за объемом и частотой изменения содержания проекта, за ошибками в документах проекта или другими результатами управления. Это позволяет определить, насколько действенным является процесс управления проектом. Диаграммы зависимостей помогают анализировать причины возникновения проблем. Диаграмма зависимостей представляет собой графическое отображение процесса. Существует множество различных стилей представления этих диаграмм, но все они отображают операции, точки принятия решений и порядок обработки данных. Диаграммы зависимостей дают представление о том, как различные элементы системы взаимодействуют между собой. На рис. 8.10 приведен пример диаграммы зависимостей для контрольных оценок. Такая диаграмма зависимостей может оказать помощь команде проекта в прогнозировании, где и какие могут возникнуть проблемы с качеством, — и, следовательно, в разработке мер по их предотвращению. 204 2 Техническое задание на разработку ИС 1 Запрос на проект 3 Разработка ИС 4 Одобренный продукт нет 6 Передача ИС в опытную эксплуатацию 7 Опытная эксплуатация ИС нет 8 Анализ результатов опытной эксплуатации(одобр ение) 5 Упраление изменениями спецификаций 9 Анализ контроля качества (одобрение) да да 11 Передача ИС в промышленную эксплуатацию да нет 12 Подписание Технического Акта выполненных работ 10 Доработка ИС Рис. 8.10. Пример диаграммы зависимостей Диаграмма Парето представляет собой особый тип гистограммы, упорядоченной по частоте возникновения, которая отображает, какое количество обнаруженных дефектов являются следствием причин, относящихся к определенному типу или категории. В таблице 8.4 собраны статистика появления дефектов, появления дефектов нарастающим итогом, вычислен процент от общего количества дефектов. На основании данных таблицы 8.5 построена диаграмма Парето (рис. 8.7). Таблица 8.5. Статистика появления различных дефектов Дефект a b c d e f g Кол-во появлений 100 90 30 22 17 14 11 Нарастающий итог 100 190 220 242 259 273 284 Процент от общего количества дефектов 34,01% 30,61% 10,20% 7,48% 5,78% 4,76% 3,74% 205 h i j Итого 5 3 2 294 289 292 294 1,70% 1,02% 0,68% Количество Диаграмма Парето 120 120.00% 100 100.00% 80 80.00% 60 60.00% 40 40.00% 20 20.00% 0 0.00% a b c d e f g h i Количество проявлений Нарастающий процент j Дефекты Рис. 8.11. Пример диаграммы Парето Порядок ранжирования элементов в диаграмме Парето используется для принятия решений о проведении корректирующих действий. Команда проекта должна в первую очередь принимать решения по тем проблемам, которые являются причиной наибольшего количества дефектов. Диаграммы Парето логически связаны с Законом Парето, который гласит, что относительно малое число причин обычно приводит к большинству проблем или дефектов. Этот закон также известен как принцип 80/20, согласно которому 80 процентов проблем создается 20-ю процентами причин. Схема прогноза отображает историю и модель изменений. Она представляет собой линейный график, отображающий точки ввода данных, расположенные на графике в порядке их возникновения. Схема прогноза дает представление о трендах процесса во времени, колебаниях во времени, а также о позитивных и негативных изменениях процесса во времени. При помощи таких схем также проводится анализ тенденций. Анализ тенденций часто используется для наблюдения за исполнением расписания и стоимости проекта. Статистические выборки — это часть контролируемой продукции, позволяющей сделать вывод обо всей продукции данного вида в проекте. Правильно сделанная выборка часто помогает снизить затраты на контроль качества. Инспекция включает такие процессы, как тестирование, предпринятое с целью определения соответствия результатов проекта принятым требованиям и стандартам. Различают тестирование как отдельных бизнес-процессов, так и их совокупности (интеграционное тестирование). Для проведения тестирования разрабатывают сценарии 206 тестирования. Для осуществления контроля качества разработанной ИС составляют сводную таблицу сценариев тестирования. Пример формы такой таблицы приведен на рис. 8.12. № Наименование сценария Описание сценария Дата, Время Тестировщик Приемщ ик Успеш но? (да/нет) Примечания Комментарий к форме: 1) 2) 3) 4) 5) 6) 7) 8) №: Номер сценария тестирования бизнес-процесса. Наименование сценария: Короткое наименование сценария тестирования бизнес-процесса. Описание сценария: Описание сценария тестирования бизнес-процесса. Дата, Время: Дата и время проведения тестирования. Тестировщик: Консультант от Исполнителя, участвующий в тестировании. Приемщик: Сотрудник функциональной группы от Заказчика, участвующий в тестировании. Успешно? (да/нет): Отметка об успешности прохождения сценария тестирования. Примечания: Дополнительные пояснения к результатам сценария Рис. 8.12. Пример формы сводной таблицы сценариев тестирования Ошибки, выявленные при тестировании, фиксируют в специальном журнале. Пример формы журнала ошибок представлен на рис. 8.13. Наимено вание сценария № шага тестир ования Шаг процесса Мо ду ль Описание ошибки Решение Ответственный Намече нная дата Комментарий к форме «Журнал ошибок»: 1) 2) 3) 4) 5) 6) 7) 8) Наименование сценария: Короткое наименование сценария тестирования бизнес-процесса. № шага тестирования: Уникальный идентификатор шага тестирования в формате Z.P#.NN, где Z — номер сценария тестирования, P# — 5-значный номер процесса, и NN — уникальный 2-циферный код в рамках сценария. Шаг процесса: Номер и наименование тестируемого шага бизнес-процесса. Номер шага бизнес процесса в формате P#.NN, где P# — 5-значный номер процесса, и NN — уникальный 2-циферный код в рамках процесса. Модуль: Модуль ИС, с использованием которого реализуется шаг бизнеспроцесса. Описание ошибки: подробное описание ошибки, выявленной в ходе тестирования, со ссылкой на файл, в котором находятся полные сведения об ошибке. Решение: Планируемые мероприятия по устранению ошибки. Ответственный: Сотрудник, назначенный ответственным за устранение ошибки в намеченный срок. Намеченная дата: Планируемый срок устранения ошибки Рис. 8.13. Пример формы журнала ошибок 207 Проверка исправления дефектов — это действие, предпринимаемое отделом контроля качества, чтобы удостовериться, что дефекты продукта исправлены и сам продукт полностью соответствует Техническому заданию и спецификации. Выходы процесса контроля качества Результаты контроля качества представляют собой результаты мероприятий по контролю качества, переданные в рамках обратной связи в отдел обеспечения качества. Базовый план по качеству (обновления). Рекомендованные корректирующие действия — определенные мероприятия, проведение которых вызвано результатами операций по контролю качества. Рекомендованные предупреждающие действия — специальные мероприятия по предупреждению возникновения условий, при которых процессы проекта могут выйти за пределы установленных параметров. Запрошенные изменения — изменения, которые требуется внести в проект как результат рекомендованных корректирующих или предупреждающих действий. Завершением процесса контроля качества является утвержденные результаты поставки. План управления проектом (обновления). План управления проектом подлежит обновлению в связи с изменениями в плане управления качеством, вызванными результатами процесса контроля качества. Внесение изменений в проект проводится в соответствии с утвержденными процедурами общего управления изменениями через запрос на изменение. Рекомендованное исправление дефектов — предложения по устранению дефектов. Для формирования набора рекомендаций по исправлению дефектов можно использовать Журнал регистрации дефектов. Активы организационного процесса (обновления), содержащие заполненные контрольные списки и документацию о накопленных знаниях. Утвержденные результаты поставки — последствия, которые определяются при установлении соответствия результатов поставки определенным требованиям. Результатом процесса контроля качества являются утвержденные результаты поставки. План управления проектом (обновления). План управления проектом подлежит обновлению в связи с изменениями в плане управления качеством, вызванными результатами процесса контроля качества. 208 Лекция 9. УПРАВЛЕНИЕ ЧЕЛОВЕЧЕСКИМИ РЕСУРСАМИ ПРОЕКТА Планирование команды проекта. Организационные диаграммы и назначения по проекту. Реестр навыков. Распределение ролей и ответственности. План управления обеспечением проекта персоналом. Набор команды проекта. тестирование. Назначение персонала в проекте. Доступность управления обеспечением проекта персоналом (обновления). проекта. Переговоры, ресурсов. План Развитие команды Обучение. Принципы. Операции по укреплению команды. Управление командой проекта. Оценка эффективности выполнения работ проекта. Урегулирование конфликтов. Обновление плана управления проектом. Ключевые слова: команда проекта, роль в проекте, матрица ответственности, реестр навыков, роль, полномочия, ответственность, квалификация, урегулирование конфликтов, оценка эффективности команды, справочник команды проекта, мотивация. Управление человеческими ресурсами проекта — это процесс обеспечения эффективного использования человеческих ресурсов проекта, к которым относятся все участники проекта (спонсоры, заказчики, команда проекта, субподрядчики, подразделения компании и другие участники проекта [4.2]). • Для успешного достижения целей проекта критически важным является следующее: идентифицировать состав участников проекта; • определить роли участников проекта и порядок их взаимодействия; • сформировать команду проекта и команду управления проектом; • построить необходимую и достаточную для управления проектом организационную структуру. Ответим на следующие вопросы: что понимается под проектной ролью, командой проекта, командой управления проектом. Роль в проекте (проектная роль) — определенный набор функций и полномочий в проекте, созданный с целью распределения обязанностей между членами команды проекта. Проектную роль можно рассматривать как временную должность в организации (компании). Команда проекта — временная рабочая группа, выполняющая работы по проекту и ответственная перед Руководителем проекта за их выполнение. Команда проекта состоит из команды управления, участников проекта, выполняющих работы в рамках проекта, — Исполнителей проекта. 209 Команда управления проектом (КУП) — члены команды проекта, уполномоченные принимать управленческие решения по управлению проектом. Участники проекта — организации Заказчика и Исполнителя и специалисты от организаций Заказчика и Исполнителя, а также другие организации и лица, которые участвуют в работе проекта или чьи интересы могут быть затронуты при исполнении или завершении проекта. Участники оказывают влияние на проект и его результаты. Команда управления проектом Формируя команду управления проектом, необходимо определить ключевых лиц проекта, принимающих решения. Для обеспечения всех необходимых функций управления проектом внедрения информационных систем команда управления проектом должна включать в свой состав участников со следующими ролями: Руководитель проекта; Куратор проекта (Спонсор); Архитектор системы; Администратор проекта. Подчиненность членов команды управления представлена на рис. 9.1. КУРАТОР ПРОЕКТА РУКОВОДИТЕЛЬ ПРОЕКТА АРХИТЕКТОР СИСТЕМЫ АДМИНИСТРАТОР ПРОЕКТА Рис. 9.1. Подчиненность членов команды управления проектом внедрения ИС Приведенный состав команды управления проектом является необходимым для управления работами при внедрении информационной системы. Возможны некоторые модификации состава команды в зависимости от сложности и масштабности проекта, 210 например при необходимости можно включать в нее заместителя Руководителя проекта, Руководителей функциональных направлений (финансы, логистика, персонал и т. д.). Состав команды управления должен быть достаточным, чтобы осуществлять: Управление ресурсами проекта, в том числе: o определение требуемых для достижения целей проекта ресурсов; o подготовка предложений по изменению состава группы управления проектом; o утверждение персональных изменений в составе рабочих групп проекта; o оценка стоимости проекта, подготовка бюджетов проекта и отчетов об исполнении бюджетов. Управление сроками выполнения проекта, в том числе: o подготовка плана работ проекта; o контроль над выполнением проекта; o подготовка отчетов о ходе работ проекта. Управление качеством проекта, в том числе: o контроль соответствия разрабатываемых проектных решений Техническому заданию; o организация экспертизы проектных решений. Управление рисками проекта, в том числе: o анализ рисков проекта; o разработка планов мероприятий по снижению рисков; o реализация мероприятий по снижению рисков. Управление проблемами проекта, в том числе: o анализ проблем проекта; o разработка мероприятий по разрешению проблем проекта; o реализация мероприятий по разрешению проблем проекта. Контроль над организацией работ в проектных группах, в том числе: o согласование отчетов о ходе работ; o контроль над функционированием системы сбора и распределения информации; o контроль документирования проектных результатов. Персональный состав команды управления приведенных организационных единиц определяется Уставом проекта. 211 Для того чтобы распределить функции и обязанности по проекту, составляют ролевые инструкции или Положение по проектной роли. В ролевой инструкции должно быть определено следующее: какие цели стоят перед сотрудником, назначенным на данную роль; кому подчиняется сотрудник, назначенный на ту или иную роль; каковы его функции, обязанности, полномочия. Незнание ключевых участников проекта, их функций и полномочий может привести к большим сложностям при исполнении проекта. Функции и полномочия проектных ролей команды управления проектом Как уже было изложено в лекции 1, Куратор проекта (Спонсор) — проектная роль должностного лица, отвечающего за стратегическое управление ходом реализации проекта. Куратор принимает решение по стратегическим вопросам проекта, осуществляет утверждение основных изменений в объеме работ, сроках, этапах, в бюджете проекта, находящихся вне компетенции Руководителя проекта. Как правило, Куратором проекта (Спонсором) является менеджер высшего звена организации. Основные функции: общее руководство ходом реализации проекта; обеспечение выделения необходимых ресурсов для выполнения проекта, обеспечение финансирования работ; рассмотрение и утверждение регламентирующих документов, необходимых для организации и выполнения проекта; получение и анализ сводной отчетности о ходе реализации проекта; управление изменениями базовых параметров проекта и решение проблем, находящихся вне компетенции Руководителя проекта. Основные полномочия: утверждение целей проекта; согласование назначения Руководителя проекта; утверждение общего плана и бюджета проекта; получение от Руководителя проекта сводной отчетности о ходе его выполнения; принятие принципиальных решений при возникновении критических изменений, влияющих на сроки, стоимость и качество результатов проекта. 212 Руководитель проекта — проектная роль должностного лица, ответственного за управление проектом. Руководитель проекта непосредственно отвечает за достижение целей проекта в рамках выделенного бюджета, в соответствии с плановыми сроками осуществления проекта и с заданным уровнем качества. Основные функции: формирование команды проекта и команды управления проектом; планирование, организация и контроль выполнения работ по достижению целей проекта с требуемыми качеством, затратами и в заданный срок; распределение ресурсов проекта и организация взаимодействия команды проекта в процессе его выполнения; организация взаимодействия с Заказчиком и обеспечение всех необходимых коммуникационных связей с другими участниками проекта; учет фактических затрат ресурсов по исполнению проекта; формирование и предоставление Куратору отчетности по проекту. Основные полномочия: назначение задач команде проекта (отдельным ее членам) и контроль их выполнения; требование от команды проекта выполнения своих ролевых функций; подтверждение или отклонение отчетов о фактических затратах исполнителей проекта; обоснование необходимости и запрос Куратору проекта на выделение дополнительных ресурсов на проект; обращение к Куратору за поддержкой в случае необходимости. Архитектор системы — проектная роль должностного лица, отвечающего за предметную область проекта. Архитектор системы подчиняется непосредственно Руководителю проекта. Архитектор системы непосредственно отвечает за разработку информационной системы в соответствии с плановыми сроками проекта и с заданным уровнем качества. На роль Архитектора системы назначается специалист, наиболее компетентный по внедряемой информационной системе. Архитектор системы должен знать методологии и технологии построения ИС, стандарты и нормативные документы в области проектирования и создания ИС, разработки и оформления технической документации. Основные функции: определение состава, продолжительности и технологии выполнения работ по разработке и внедрению информационной системы; 213 определение ресурсов, которые необходимы для разработки и внедрения ИС в рамках, заданных условиями проекта; определение квалификационных требований и состава рабочих групп специалистов по направлениям деятельности, распределение их по задачам, организация работ и верификация результатов в процессе реализации проекта; обеспечение целостности функциональной архитектуры внедряемой информационной системы; организация подготовки, согласования и утверждения всей технической документации, необходимой для создания ИС в рамках проекта; планирование и согласование фактических трудозатрат специалистов при исполнении проекта; формирование и предоставление руководителю проекта необходимой отчетности; анализ хода выполнения и промежуточных результатов создания ИС; организация, проведение и документирование процедур передачи Заказчику разработанной ИС. Основные полномочия: участие в календарном планировании работ по созданию ИС; назначение задач рабочим группам проекта и контроль их выполнения; требование от исполнителей качественного выполнения порученных задач и своевременной информации о возникающих проблемах; обоснование необходимости и запрос руководителю проекта на выделение дополнительных ресурсов на проект. Администратор проекта — проектная роль должностного лица, отвечающего за информационное обеспечение руководителя проекта, организацию и ведение документооборота по проекту. Администратор проекта функционально закрепляется за конкретным проектом и подчиняется непосредственно Руководителю проекта. Основные функции: обеспечение Руководителя проекта структурированной информацией, обеспечивающей возможность контроля за проектом, планами, ресурсами и приоритетами; ведение протоколов совещаний; обеспечение своевременной подготовки, движения и архивации документов по проекту. Основные полномочия: передача и получение от участников проекта необходимой документации по проекту; 214 контроль соблюдения участниками проекта установленной системы документооборота; затребование от конкретных исполнителей по проекту оперативной информации и отчетов о ходе работ по проекту. Распределение основных функций между членами команды управления проекта представляют в виде таблицы 9.3, которая дает точное представление о том, кто и за что отвечает на протяжении всего проекта. Таблица 9.3. Распределение основных функциональных обязанностей команды Администратор проекта Функциональные обязанности Архитектор системы Куратор проекта (Спонсор) Руководитель проекта управления проектом Планирование Разработка и периодическая актуализация плана Утверждение плана + + + Управление командой проекта Назначение сотрудника Руководителя проекта Формирование команды проекта на роль Определение квалификационных требований и состава рабочих групп специалистов по функциональности ИС Обеспечение выделения необходимых ресурсов для выполнения проекта Непосредственное руководство Командой проекта Формирование предложений по стимулированию Команды проекта Обеспечение стимулирования Команды проекта + + + + + + + Организация выполнения работ Организация взаимодействия с Заказчиком и обеспечение всех необходимых коммуникационных связей с другими участниками проекта Организация подготовки, согласования и утверждения всей технической документации, необходимой для создания ИС в рамках проекта Организация, проведение и документирование процедур передачи Заказчику разработанной ИС Рассмотрение и утверждение регламентирующих документов, необходимых для организации и выполнения проекта Ведение организационно-распорядительной и отчетной документации. Поддержание в актуальном состоянии списка команды проекта + + + + + + 215 Обеспечение команды проекта необходимыми информационными материалами Материально-техническое и хозяйственное обеспечение команды проекта Контроль хода выполнения проекта Организация и проведение совещаний по обсуждению хода работ проекта Подготовка и предоставление Куратору отчетов о ходе работ проекта Получение и анализ сводной отчетности о ходе реализации проекта Контроль соответствия результатов проекта Техническому заданию на разработку ИС Согласование фактических трудозатрат специалистов при исполнении проекта + + + + + + + + В состав команды проекта, как было отмечено выше, входит не только команда управления проектом, но и Исполнители. Примеры проектных ролей Исполнителей, характерных для IT-проектов: функциональный архитектор, функциональный консультант, разработчик, администратор ИС, тестировщик, менеджер по качеству, системный аналитик. На проекте один член команды может выступать одновременно в нескольких ролях. Совмещение ролей часто встречается на небольших проектах, что позволяет снизить накладные расходы проекта. Но не все роли можно совмещать, поскольку подобное совмещение может затруднить контроль и оценку результатов проекта. Допускается совмещение таких проектных ролей, как Руководитель проекта и администратор проекта, функциональный архитектор и функциональный консультант, функциональный консультант и аналитик, менеджер разработки и разработчик, менеджер по качеству и тестировщик. Но не следует совмещать роли менеджера по качеству и разработчика, руководителя проекта и разработчика, тестировщика и разработчика. В PMBOK [4.1] процесс управления человеческими ресурсами разбит на два процесса — управление командой проекта и управление участниками проекта. В данной лекции будет рассмотрен только один процесс — управление командой. Согласно PMBOK, управление командой проекта включает в себя следующие процессы по организации команды проекта и управления ею. Планирование человеческих ресурсов — процесс определения и документального оформления ролей, ответственности и подотчетности, а также создание плана управления обеспечением проекта персоналом. Набор команды проекта — процесс привлечения человеческих ресурсов, необходимых для выполнения проекта. 216 Развитие команды проекта — рост квалификации членов команды проекта и укрепление взаимодействия между ними с целью повышения эффективности исполнения проекта. Управление командой проекта — контроль эффективности работы членов команды проекта, обеспечение обратной связи, решение проблем и координация изменений, направленных на повышение эффективности исполнения проекта. Связь этих процессов, их входы и выходы представлены на рис. 9.2. Факторы внешней среды Организационная культура и структура Шаблоны контрольных списков Требования к ресурсам операций Планирование команды проекта План управления проектом Распределение ролей и ответственности Организационные диаграммы проекта контроля качества План управления обеспечением проекта персоналом Одобренные запросы на изменения Одобренные корректирующие действия Одобренные предупреждающие действия Набор команды проекта Назначение персонала в проекте Доступность ресурсов План управления обеспечением проекта персоналом (обновления) Отчеты об исполнении работ Развитие команды проекта Оценка эффективности команды проекта Активы организационного процесса (обновления) План управления проектом (обновления) Запрошенные изменения Рекомендованные корректирующие действия Рекомендованные предупреждающие действия Управление командой проекта Рис. 9.2. Взаимосвязь процессов управления человеческими ресурсами проекта Процесс управления командой проекта тесно связан со всеми процессами планирования проекта. Первоначальный состав команды укрупненной иерархической структуры работ. определяется на основании После того как команда выполнила детализацию состава работ, может появиться необходимость изменения в составе команды, которое приводит к увеличению или уменьшению рисков проекта, связанных с изменением уровня квалификации членов команды, что, в свою очередь, приводит к дополнительному 217 планированию рисков. Квалификация состава команды проекта влияет на оценку длительности операций, поэтому может возникнуть необходимость в изменении расписания операций. Планирование команды проекта При планировании команды проекта определяются роли, ответственность и подотчетность в проекте, а также создается План управления обеспечением персоналом, который включает в себя определение сроков и способов набора членов команды проекта, критерии их освобождения от участия в проекте, рекомендации по проведению дополнительного обучения. В процессе планирования определяются концепция мотивации, способы разрешения конфликтов, разрабатывается график проведения собраний команды проекта и его участников. Планирование команды проекта: входы Факторы внешней среды предприятия Определение ролей и ответственности в проекте должны производиться с учетом факторов внешней среды предприятия. В таблице 9.2 приведены примеры возможного влияния организационных, технических, межличностных и политических факторов на процесс планирования команды проекта. Таблица 9.2. Влияние факторов внешней среды на планирование команды проекта Факторы Влияние на определение ролей команды и внешней среды ответственности Организационные Взаимоотношения организаций или отделов, участвующих в проекте, механизмы взаимодействия между ними Технические Навыки и специальности, необходимые для выполнения проекта, необходимость обеспечения координации между языками программного обеспечения, наличие специфических сложностей при переходе от одной фазы жизненного цикла к другой Межличностные Официальные и потенциальными неофициальные членами отношения команды проекта, между их должностные обязанности. Культурные или языковые различия между членами команды, которые могут оказать влияние на их рабочие взаимоотношения 218 Политические Цели и интересы потенциальных членов команды проекта, люди (или группы людей), которые имеют неформальное влияние в областях, представляющих важность для проекта, существование неформальных связей между потенциальными участниками проекта Активы организационного процесса Активы организационного процесса — это знания о планировании команды проекта, накопленные в результате выполненных ранее проектов: например, организационные диаграммы проекта, описания позиций, методы оценки эффективности работы команды и подход к разрешению конфликтов, матрицы распределения ролей и ответственности, матрицы квалификации для должностей, меры по повышению мотивации членов команды и другое. План управления проектом Для определения команды проекта существуют требования к ресурсам операции, которые содержатся в плане управления проектом. В процессе планирования команды происходит обновление предварительных требований в отношении требуемых людей и их квалификации. Планирование команды: инструменты и методы Организационные диаграммы и назначения по проекту Иерархические организационные диаграммы являются простым и наглядным инструментом для определения иерархии подотчетности, начиная с нижнего уровня организации до руководителя проекта. Существуют различные форматы документирования распределения ролей и ответственности членов команды проекта, например иерархический, матричный или текстовый. Независимо от формата документирования организационные диаграммы позволяют для каждого пакета работ назначить ответственного за его исполнение, а также обеспечивают понимание своей роли и ответственности каждым членом команды. На рис. 9.3 представлен пример документирования распределения ролей и ответственности членов команды проекта, выполненного в виде организационной структуры. Организационная структура является иерархической организационной схемой существующих подразделений организации (отделов, групп или команд). Под каждым отделом указывается список операций проекта или пакета работ. Таким образом, можно увидеть закрепление ответственности в проекте для данного функционального отдела 219 (например, отдела информационных технологий или отдела закупок) в одном месте рядом с названием отдела. Команда управления проектом Группа функциональной разработки Группа качества Ответственность за: -качество проектных документов, -качество разработки ИС. Ответственность за: -разработку функциональности системы в соответствии с планом, -разработку сценариев тестирования, -проведение тестирования и устранение дефектов. Группа организации обучения Подгруппа по направлению «Финансы» Подгруппа по направлению «Логистика» Ответственность за: -аренду учебных классов, -комплектование учебных групп из числа пользователей системы, -материальнотехническое обеспечение процесса обучения. Ответственность за: -достижение целей проекта, -соблюдение сроков и бюджета проекта, -планирование работ. Группа разработки учебных материалов Отдел обеспечения информационнй безопасности Ответственность за: Ответственность за: -разработку учебных материалов по функциональным областям, -разработку инструкций пользователя. -разработку политики информационной безопасности деятельности. Рис. 9.3. Организационная структура проекта Для представления областей ответственности может быть использована иерархическая структуры работ. Для определения иерархии подотчетности может быть применена матрица ответственности, которая является компактной формой представления взаимосвязи между отдельными ролями команды проекта и возложенными на них обязанностями. Матрица имеет следующую структуру: в левом столбце представлены работы проекта, названия столбцов справа содержат перечень ролей, обеспечивающих выполнение указанных работ. На пересечении строк и столбцов в ячейке указывается степень участия роли в данной работе — консультация, разработка, приемка работы, утверждение и др. В таблице 9.3 приведен пример матрицы ответственности проекта. Таблица 9.3. Матрица ответственности проекта Ответственные за работы Работы проекта Спонсор проекта Менеджер Специалист Специалист проекта фин. службы отдела сбыта 220 Согласование целей р к Разработка плана вех Разработка бюджета проекта Составление плана проекта Утверждение плана р к у п п р р у к К Условные обозначения: У — утверждение, Р — разработка, П — приемка работы, К — консультации Пример отображения подотчетности, выполненный в табличном виде, представлен в таблице 9.4. Таблица 9.4. Матрица подотчетности проекта Получают отчет Готовят отчет Спонсор проекта Руководитель Администратор Системный проекта проекта Архитектор Спонсор проекта никогда Руководитель ежемесячно ежедневно Системный архитектор еженедельно Текстовые форматы — никогда по по необходимости необходимости Администратор никогда никогда никогда еще один ежемесячно формат для описания распределения ответственности. В документах, закрепляющих ответственность на проекте, в краткой форме содержится следующая информация: обязанности, полномочия и необходимая квалификация. Реестр навыков Реестр навыков — инструмент для определения навыков, необходимых членам команды проекта . Реестр навыков — это список категорий и компонентов навыков для определенного класса персонала. Пример реестра навыков для руководителя ИТ-проектов (рис. 9.4): 221 Категории и компоненты навыков Технические навыки: Умение управлять проектом и его технологией Оказание помощи в разрешении проблем проекта Взаимодействие с техническим персоналом Участие в достижении компромиссов Понимание тенденций Понимание основных задач маркетинга Наличие навыков системного анализа Административные навыки: Привлечение уникальных специалистов Навыки эффективного общения Умение делегировать полномочия Ведение переговоров с целью обеспечения ресурсами Календарное планирование Понимание политик и рабочих процедур Сотрудничество с другими проектными командами Навыки межличностного общения и лидерства: Оказание помощи в решении проблем Построение многофункциональной команды Определение целей Получение поддержки высшего руководства Мотивация членов команды Управление конфликтами Стратегические навыки: Стратегическое планирование Принятие стратегических решений Умение работать в условиях риска Умение лидировать Рис. 9.4. Пример реестра навыков для руководителя ИТ Для обеспечения анализа совокупностей навыков компоненты группируются в четыре категории: технические навыки, административные, навыки межличностного общения, стратегические навыки. Для каждого навыка отмечаются рейтинг критичности и рейтинг способностей [4.3]. Для оценки рейтинга можно использовать четырехбалльную шкалу (таблица 9.4). Таблица 9.4. Шкала рейтингов критичности и способностей [4.3] Рейтинг Критичность Квалификация 1 Неважно/Маловажно 2 3 Важно Очень важно Отсутствие навыков слабые навыки Базовые навыки Высокая квалификация / 222 Критично проекта 4 для успеха Уникальная квалификация Реестры навыков должны быть составлены для каждого класса персонала, как, например, для руководителя проекта, системного архитектора, специалиста по качеству. Критичность навыков для руководителя проекта определяется во многом масштабом проекта и организационной структурой проекта. Как отмечалось в лекции 1, наибольшими полномочиями наделен руководитель проекта в проектных организационных структурах, и, следовательно, к нему должны предъявляться самые высокие требования. Распределение навыков зависит от уровня административной ответственности. Рейтинг критичности смещается от «технических» в сторону «административных», а затем в сторону «межличностного общения» и «стратегических навыков» по мере роста административной ответственности. Налаживание связей Налаживание связей — метод планирования команды проекта, состоящий из операции по установлению связей с потенциальными членами команды, таких как предварительная переписка, неформальные беседы и собрания по специальности. Использование этого метода может быть полезно не только на этапе планирования, но и до начала проекта. Теория организации Методом планирования команды проекта является использование теории организации, которая дает информацию о поведении людей, команд и подразделений. Применение проверенных принципов позволяет сократить время планирования и повысить его качество. Планирование команды проекта: выходы Распределение ролей и ответственности При распределении ролей и ответственности, необходимых для выполнения проекта, следует учитывать следующие моменты. Роль — обозначение части работ проекта, за выполнение которой несет ответственность определенное лицо. Полномочия — право задействовать ресурсы проекта, принимать решения и утверждать одобрение действий или результатов. Примеры полномочий: выбор способа завершения операции, приемка качества и порядок реагирования на отклонения в проекте. Ответственность — работа, которую член команды проекта должен выполнить для завершения операций проекта. 223 Квалификация — навыки и способности, необходимые для выполнения операций проекта. Отсутствие нужной квалификации у членов команды влияет на расписание проекта, качество выполнения работ, ставит под угрозу цели проекта. Для повышения квалификации планируют проведение обучения членов команды. Организационная диаграмма проекта Организационная диаграмма проекта — это графическое представление состава команды проекта и отношения подотчетности между ее членами. В зависимости от потребностей проекта она может быть официальной или неофициальной, подробной или обобщенной. План управления обеспечением проекта персоналом План управления обеспечением проекта персоналом является составной частью плана управления проектом. Он должен содержать следующую информацию. Набор персонала. При планировании набора членов команды проекта определяется схема, по которой будут задействованы имеющиеся человеческие ресурсы организации (или они будут набираться извне на контрактной основе) и какова стоимость, соответствующая каждому уровню знаний (квалификации), который необходим для проекта. Расписание. В плане управления обеспечением проекта персоналом указываются временные рамки занятости членов команды проекта в графическом или табличном виде. Критерии освобождения ресурсов. Определение метода и времени освобождения членов команды важно как для проекта, так и для членов команды. Расписание высвобождения позволяет исключать выплаты сотрудникам, уже выполнившим свою долю работы в проекте, и тем самым снизить затраты на проект, а также обеспечивает информацией о наличии свободного ресурса. Обучение персонала. Если есть опасения, что квалификация членов команды, привлекаемых для участия в проекте, может оказаться недостаточной, то в рамках плана проекта следует разработать план обучения персонала. В этот план могут быть также включены программы обучения членов команды и получения ими сертификатов, наличие которых способствует успешному выполнению проекта. Поощрение и премирование. Спланированная система премий и определенные критерии премирования стимулируют и мотивируют производительность людей, занятых в проекте. Создание плана с указанием времени премирования гарантирует выплату премий. Безопасность. Нормы и правила по защите членов команды проекта от несчастных случаев могут быть включены в план управления обеспечением проекта персоналом. Набор команды проекта 224 Согласно PMBOK, набор команды проекта — это процесс привлечения человеческих ресурсов, необходимых для выполнения проекта. Набор команды проекта: входы Факторы внешней среды предприятия При наборе членов команды проекта необходимо учитывать следующее: Доступность — возможность привлечения специалиста на проект в запланированные сроки. Квалификация — наличие у потенциального члена команды квалификации, отвечающей требованиям проекта. Опыт работы — наличие опыта выполнения работы, которую планируется закрепить за потенциальным членом команды. Заинтересованность — наличие интереса в работе над проектом. Стоимость — величина оплаты труда потенциального члена команды. Активы организационного процесса Активы организационного процесса могут содержать правила и процедуры назначения персонала на проект и высвобождения персонала с проекта, а также базы данных по персоналу и возможному резерву. Распределение ролей и ответственности Схема распределения ролей и ответственности, необходимые навыки и квалификация, разработанные на этапе планирования команды проекта, являются ключевой информацией при наборе команды. Организационные диаграммы проекта Организационные диаграммы проекта являются входной информацией для определения численности команды проекта. План управления обеспечением проекта персоналом План управления обеспечением проекта персоналом и расписание проекта определяет сроки, на которые привлекается каждый член команды проекта, и время его высвобождения. Набор команды проекта: инструменты и методы Переговоры Набор команды для многих проектов является предметом переговоров с руководителями функциональных подразделений или руководителями других проектов для гарантии обеспечения соответствующим штатом квалифицированных сотрудников на требуемый период времени. Тестирование 225 При подборе команды проекта представляют интерес различные психологические тесты, помогающие руководителям проектов включать в команду людей, личностные характеристики которых охватывают диапазон качеств, необходимых для успешной реализации проекта. В качестве примера можно привести тест Мередита Белбина — американского психолога, который более десяти лет посвятил изучению условий, необходимых для успешной деятельности управленческих команд. Белбин предположил, что каждый член команды играет две роли: функциональную, связанную с формальной спецификой деятельности, и «командную роль», особенно важную для успешной деятельности команды. Белбин выделил и описал восемь типов командных ролей, которыми характеризуется все «ролевое разнообразие» команды: «исполнитель», «председатель», «формирователь», «мыслитель», «исследователь ресурсов», «оценивающий», «коллективист» и «доводящий до конца». Основным качеством «исполнителей» является дисциплинированность, организованность, сознательность, приверженность обязательствам, серьезное отношение к любому делу, надежность, практичность, терпимость к окружающим. «Исполнители» — эффективные организаторы и администраторы. Им присущ практичный и реалистичный подход к выполнению работы. Для «коллективиста» характерен консультативный стиль руководства и склонность к неформальному общению с коллегами и подчиненными. Из них получаются отличные наставники молодых менеджеров. Основное назначение «мыслителя» в команде — привнесение новых и оригинальных идей. «Председатель» — человек, знающий, как использовать ресурсы, исключительно адаптивный при общении с людьми, но в то же время никогда не теряющий контроля над ситуацией и способности принимать самостоятельные решения. Тестирование по методу Белбина позволяет определить «командную роль» потенциального члена команды и при формировании команды включать в нее людей с такими личностными характеристиками, чтобы в команде были реализованы все восемь ролей. Полная ролевая структура создает предпосылки для эффективного партнерского взаимодействия. В случае, если команда проекта работает неэффективно, полезно проанализировать ее состав в свете рассматриваемых восьми ролей. Набор команды проекта: выходы Назначение персонала в проекте Процесс набора команды заканчивается укомплектованием штата, документально оформленного, например, в следующем виде (рис. 9.5). 226 Проектная роль Ф.И.О. Отдел по штатной структуре, должност ь В наличии Количеств о Вакансии Дата выхода на проектную работу Команда управления проектом Группа качества Группа функциональной разработки Группа организации обучения Группа разработки учебных материалов Рис. 9.5. Шаблон для документирования процесса набора команды Доступность ресурсов Для указания доступности ресурсов документально фиксируется период времени, в течение которого каждый член команды проекта может принимать участие в выполнении проекта. Информация о доступности ресурсов необходима для корректировки расписания проекта с учетом отпусков и обязательств по другим проектам. План управления обеспечением проекта персоналом (обновления) По мере назначения специалистов согласно схеме распределения ролей и обязанностей может возникнуть необходимость в изменении плана управления обеспечением проекта персоналом, которая связана с несоответствием требований, предусмотренных планом, повышением в должности, выходом на пенсию, болезнью. Развитие команды проекта Развитие команды проекта проходит в четыре этапа: формирование, притирка, нормализация, функционирование. На этапе формирования происходит определение членов команды и введение их в проект. Как правило, сформированная группа — это еще не команда, способная эффективно решать задачи проекта. Члены команды еще не понимают четко своей роли в проекте. На этом этапе требуется директивный стиль управления, который опирается на четкие указания руководителя. На стадии «притирки» часто возникают конфликтные ситуации. Руководитель проекта должен уделять большее внимание 227 человеческому фактору, созданию благоприятной среды для развития команды проекта. Для этого этапа рекомендуется использовать смешанный стиль директивного руководства со стилем убеждения. На этапе нормализации команда начинает объединяться в единое целое. Повышение эффективности взаимодействия членов команды достигается за счет доверия к опыту коллег. Стиль руководства на этом этапе направлен на развитие мотивации, повышение уверенности команды в ее возможностях. На этапе функционирования команда представляет собой единое целое. Стиль руководства основан на делегировании полномочий членам команды. Основной задачей руководителя проекта является разработка такого плана развития команды, который бы позволил как можно скорее выйти на стадию функционирования. Развитие команды проекта: входы Входной информацией для процесса развития команды являются выходы процесса набора команды: Назначение персонала в проекте. План управления обеспечением проекта персоналом. Доступность ресурсов. Развитие команды проекта: инструменты и методы Навыки в области общего менеджмента Для управления и развития команды проекта важны навыки межличностных отношений, такие как, умение сопереживать, оказывать влияние, творческий подход к работе. Регулируя настроение внутри команды, создавая атмосферу уважения и доверия, руководитель проекта и команда управления проектом могут многократно снизить количество возникающих проблем и повысить взаимодействие сотрудников. Обучение Если члены команды проекта не обладают профессиональными навыками, необходимыми для выполнения какой-либо работы, то развитие таких навыков нужно предусмотреть как часть работы проекта. Для обеспечения обучения составляют план обучения. Обучение включает в себя операции, направленные на повышение квалификации членов команды проекта. Операции по укреплению команды Для того чтобы команда представляла собой единое целое, проводятся мероприятия по ее укреплению. Операции по укреплению команды могут выполняться в виде специальных тренингов. Укреплению команды способствует проведение регулярных 228 обсуждений хода проекта, совместная работа над плановыми задачами, проведение неформальных совместных мероприятий. Принципы Командам проектов рекомендуется следовать формальным принципам, которые позволяют сделать ожидания членов команды понятными и снизить вероятность возникновения конфликтов внутри команды. При помощи принципов устанавливаются правила поведения членов команды проекта. Принципы могут касаться таких пунктов, как свободный рабочий график, добровольная или обязательная работа сверхурочно, обучение, командировки, премии. Соблюдение правил поведения способствует повышению производительности труда. Со-расположение Сплочению команды способствует размещение членов команды проекта в одном месте. Стратегия со-расположения предполагает наличие комнаты, оснащенной электронными средствами связи, досками для расписаний и другими приспособлениями, которые способствуют взаимному общению. Поощрение и премирование Стимулирование и поощрение желаемого поведения членов команды является частью процесса развития команды. План поощрения создается в процессе планирования команды проекта. Решения о премировании принимаются на основании результата оценки эффективности работы команды. Развитие команды проекта: выходы Оценка эффективности команды проекта Для оценки эффективности работы команды могут использоваться следующие показатели: Повышение навыков членов команды. Повышение квалификации. Сокращение текучести кадров. Управление командой проекта Согласно PMBOK [4.1], «управление командой проекта включает в себя контроль за деятельностью членов команды проекта, обеспечение обратной связи, решение проблем и координацию изменений, направленных на повышение эффективности исполнения проекта». В задачи команды управления проектом входит: Наблюдение за деятельностью команды. Урегулирование конфликтов. 229 Оценка работы членов команды. Управление командой проекта усложняется, если проект выполняется в рамках матричной структуры организации, когда члены команды подчиняются одновременно функциональному руководителю и менеджеру проекта. Управление командой проекта: входы Активы организационного процесса Активы организационного процесса содержат правила и процедуры, принятые в организации для поощрения членов команды, например, процедуры награждения грамотами и начисления премий. Назначение персонала в проекте В результате назначения персонала формируется список членов команды проекта, который оценивается в процессе мониторинга и управления командой проекта. Распределение ролей и ответственности Входной информацией для задач мониторинга и оценки работы членов команды проекта является схема распределения ролей и ответственности. Организационные диаграммы проекта Организационные диаграммы проекта содержат информацию об отношениях подотчетности членов команды проекта, необходимую для наблюдения за деятельностью команды. План управления обеспечением проекта персоналом План управления обеспечением проекта персоналом, содержащий информацию о периоде времени, на который сотрудник привлекается к участию в проекте, а также сведения о планах по обучению персонала, требованиях сертификации и соответствия нормативным документам являются входами для решения задачи по оценке работы членов команды и наблюдения за деятельностью команды. Оценка эффективности команды проекта Оценка эффективности команды проекта решения задач по усовершенствованию является исходной информацией для средств коммуникации, урегулированию конфликтов, разработке мер по укреплению взаимодействия членов команды. Информация об исполнении работ и отчеты об исполнении Информация об исполнении работ проекта, отчеты об исполнении работ проекта позволяют проводить оценку соответствия эффективности работы команды плану управления проектом. Отчеты о выполнении работ членами команды проекта помогают в определении требований к составу команды будущих проектов, в создании системы поощрений и в обновлении плана управления обеспечением проекта персоналом. 230 Управление командой проекта: инструменты и методы Наблюдение и обсуждение Наблюдение и обсуждение являются инструментами для контролирования процесса выполнения работ и настроения внутри команды проекта. Многие руководители ИТ- проектов имеют низкую коммуникабельность и испытывают сложности в общении. Для таких руководителей рекомендуется осуществлять управление командой проекта методом «прогулки». Руководитель проекта регулярно обходит пространство офиса, в котором работает команда. Встречая члена команды, руководитель начинает разговор произвольной фразой, например, «С каким счетом закончился вчерашний матч?». Член команды, как правило, после некоторого обсуждения результатов игры перейдет (с таким же увлечением) к рассказу о выполнении проекта. Метод «прогулки» позволяет сделать процесс коммуникации более свободным и искренним. Оценка эффективности выполнения работ проекта Оценка эффективности — это инструмент, позволяющий: уточнить правильность распределения ролей и ответственности; организовать получение исполнителями оценки их работ (особенно положительных оценок, стимулирующих производительность труда); выявить неизвестные ранее проблемы; разработать индивидуальные планы повышения квалификации; определить ближайшие цели. Оценку эффективности команды можно выполнить с помощью теста (см. Приложение 9.1), в основу которого положено определение значения характеристик высокоэффективной команды проекта: A — ясное понимание целей; B — открытость; C — уверенность друг в друге; D — разделение компетенции; E — эффективные внутренние процедуры; F — превосходство команды, основанной на качествах индивидуальностей; G — гибкость и адаптивность; H — непрерывное совершенствование и рост компетенций. 231 Н Н G G F Е F D Е С D В С А В 0 5 10 15 20 А Рис. 9.5. Диаграмма эффективности команды По результатам ответов на вопросы теста строится диаграмма эффективности команды проекта (рис. 9.5), определяются узкие места в управлении командой и разрабатываются меры для их устранения. Как видно из диаграммы, внимания требуют внутренние процедуры проекта (характеристика Е). Урегулирование конфликтов Конфликт возникает, когда одна из конфликтующих сторон полагает, что другая сторона делает что-то, препятствующее достижению поставленной цели. Мерой конфликта является неудовлетворенность несогласованных сторон. Конфликт считается разрешенным, когда неудовлетворенность обеих сторон снижается до приемлемого уровня. Существуют специальные методы для разрешения конфликтов. К ним относятся: принуждение, сглаживание, компромисс, решение проблемы, уклонение. Выбор метода связан с желанием получить немедленное влияние на конфликт или долгосрочное воздействие. Способ разрешения конфликта «Принуждение» заключается в принуждении к согласованию одной стороной другой стороны и применяется, когда одно лицо имеет власть над другим лицом, участвующим в конфликте. Способ «Сглаживание» минимизирует противоречия, породившие конфликт, но полностью его не устраняет, поэтому через некоторое время конфликт может повториться. Способ «Компромисс» подобен сглаживанию, однако, если компромиссы закрепляются документально, то это может быть окончательным решением конфликта. Способ «Решение конфликта» основан на предположении, что все разногласия должны иметь правильное решение. Это наилучший способ разрешения конфликта, поскольку работа над разногласиями раскрывает факты, подтверждающие правоту одной из сторон. 232 «Уклонение» является самым плохим способом разрешения любой конфликтной ситуации. Разрешение конфликта откладывается на неопределенный срок, что оказывает отрицательное воздействие на команду проекта. Журнал регистрации проблем В процессе управления командой проекта следует вести журнал регистрации проблем, где в письменной форме указать конкретных людей, в обязанности которых входит решение конкретных проблем к определенному сроку (таблица 9.6). Такой журнал поможет членам команды следить за тем, как и когда будут решены те или иные проблемы. Проблемы могут возникать из-за разногласия во мнениях, из-за неожиданно возникших непредвиденных обязанностей, выполнение которых необходимо поручить кому-либо из членов команды. Таблица 9.6. Форма регистрации проблем Номер, дата записи Фаза проекта, к которой относится описание проблемы Назначенный ответственн ый для разрешения проблемы Приоритет: Критично Высокий, Средний, Низкий Желае мая дата разрешения Влияние на проект Текущий статус: Открыт, Назначен, Предварит ельное решение, Решен, Утвержден, Отложен, Действий не требуется Решение, дата решения Управление командой проекта: выходы Запрошенные изменения Если изменения в кадровых назначениях, вызванные плановыми перестановками или непредвиденными обстоятельствами, могут оказать влияние на план проекта (увеличение сроков в расписании проекта или увеличение бюджета), необходимо оформить запрос на изменения, который будет рассмотрен в рамках процесса общего управления изменениями. Рекомендованные корректирующие действия К корректирующим действиям по управлению человеческими ресурсами относятся кадровые перестановки, проведение дополнительных тренингов и меры дисциплинарного воздействия и поощрения. Рекомендованные предупреждающие действия 233 К предупреждающим действиям могут относиться тренинги по взаимозаменяемости, целью которых является снижение проблем, связанных с временным отсутствием некоторых членов команды, дополнительное разъяснение должностных обязанностей, выделение дополнительного времени отдельным сотрудникам в случае возникновения необходимости сверхурочной работы. Активы организационного процесса (обновления) При завершении процесса управления персоналом обновляются: Входы для оценки эффективности работы организации. Для оценки эффективности работы организации руководителем проекта должны быть подготовлены представления на каждого члена команды проекта, с которым ему приходиться взаимодействовать. Документация о накопленных знаниях. Все накопленные знания, приобретенные во время проекта, должны быть документированы и могут включать в себя: — организационные диаграммы проекта, описания позиций и планы управления обеспечением проекта персоналом; — принципы, методы урегулирования конфликтов и процедуры поощрения; — специальные навыки и квалификация определенных членов команды, обнаруженные в процессе исполнения проекта; — проблемы и способы их решения, зафиксированные в журнале регистрации проблем проекта. План управления проектом (обновления) Одобренные запросы на изменения и корректирующие действия в качестве обновлений можно внести в план управления обеспечением проекта персоналом, являющегося частью плана управления проектом. 234 Приложение 9.1 Тест на Оценку Эффективности Команды Заданне 1 Оцените каждую из 40 характеристик в баллах от 0 до 4 и поместите Вашу оценку в соответствующую ячейку прилагаемой Таблицы оценки эффективности команды. Используйте следующую шкалу баллов: 0 - характеристика никогда не соответствует команде 1 - редко соответствует 2 - часто 3 - обычно 4 - всегда 1. Члены команды обладают общим видением целей проекта, знают, почему они работают вместе и что от них ожидают 2. Члены команды свободно высказывают свои мысли и ощущения, не опасаясь реакции руководства 3. Каждый член команды ощущает индивидуальную оценку своего вклада, доверие и уважение со стороны лидера 4. Команда вырабатывает важные решения на основе консенсуса и избегает легкие компромиссы 5. Члены команды берут необходимое время на обдумывание и согласование решений перед их реализацией v 6. Члены команды полностью используют индивидуальные сильные стороны, знания и опыт 7. Члены команды постоянно совершенствуют принятые процедуры 8. Члены команды поддерживают инициативу, инновационное мышление и оригинальные идеи 9. Члены команды оценивают результаты в соответствии стратегическим целям проекта 10. Члены команды активно участвуют в общих совещаниях и дискуссиях 235 11. Члены команды заинтересованы в работающих идеях, а не в заслугах авторов этих идей 12. Каждый член команды ясно представляет, какой индивидуальный вклад команда ожидает от него 13. Члены команды используют эффективные инструменты для планирования и отслеживания работ 14. Члены команды стремятся использовать различные подходы для поиска наилучшего решения 15. Команда быстро и гибко отвечает на изменения во внешней среде 16. Члены команды признают допущенные ошибки и извлекают из них уроки 17. Команда имеет четкие приоритеты и цели 18. Члены команды внимательно прислушиваются к мнениям коллег 19. Члены команды запрашивают, получают и дают откровенные отзывы 20. Лидер команды регулярно проводит индивидуальные обзоры результатов работ с каждым членом команды 21. Ясные и понятные процедуры позволяют членам команды легко реализовывать их функции 22. Члены команды стремятся избегать «группового мышления», сохраняя различия в индивидуальном видении ситуации 23. Члены команды выполняют различные функции в соответствии с распределенными ролями и разделенной ответственностью 24. Члены команды не избегают прямых и трудных вопросов к коллегам 25. Члены команды осознают уникальность и необходимость их работы для заказчика 26. Члены команды обладают всей информацией, необходимой для их индивидуальной и коллективной работы 27. Члены команды откровенны и чистосердечны в своих отзывах 28. Члены команды проявляют инициативу по координации совместных работ 29. Команда располагает всеми ресурсами, необходимыми для ее эффективной работы 30. Команда приветствует появление в коллективе людей со свежими взглядами, идеями, знаниями 31. Команда оценивает и отвечает на меняющиеся потребности ее членов 32. Члены команды оказывают друг другу взаимную поддержку, оценивают и отмечают индивидуальные и групповые успехи 33. Члены команды нацелены на следование высоким стандартам и высокому уровню качества работ 236 34. Члены команды уважают индивидуальные мнения каждого и открыто отстаивают свою позицию 35. Члены команды гордятся своей принадлежностью к команде и проявляют взаимную заботу 36. Каждый член команды чувствует свою ответственность перед заказчиком за общий результат 37. Команда принимает решения с целью выполнения заданных критериев и минимизируя риски перед реализацией работ 38. Члены команды поощряют критическую оценку и самооценку 39. Члены команды считают изменения желательными для команды, так как они позволяют переосмыслить принятые подходы 40. Члены команды поощряют индивидуальную работу над собой и совершенствование знаний Задание 2 Поместите Вашу оценку каждой из 40 характеристик в соответствующую ячейку Таблицы Оценки Эффективности Команды. Просуммируйте баллы в каждой колонке Таблицы от А до Н. А В C 3 D 4 E 5 F 6 G 7 Н 1 2 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 TOTAL: 237 Задание 3 Переместите итоговые баллы по каждой колонке Таблицы Эффективности Команды в Диаграмму Эффективности Команды, заштриховав каждый из восьми сегментов. Диаграмма Эффективности Команды 1 А 5 6 10 11 15 16 20 В С D Е F G Н - Характеристики высокоэффективной команды проекта: A – ясное понимание целей B - открытость C – уверенность друг в друге D – разделение компетенции E – эффективные внутренние процедуры F - превосходство команды, основанное на качествах индивидуальностей G – гибкость и адаптивность H – непрерывное совершенствование и рост компетенций Задание 4 Обзор Результатов Оценки Эффективности Команды - обсудите результаты и постарайтесь выработать согласованное мнение команды об ее эффективности - выберите 2-4 характеристики, которые необходимо улучшить - разработайте план улучшения выбранных характеристики. 238 Литература 1.1. Кале В. Внедрение SAP R/3. Руководство для менеджеров и инженеров. М.: АйТи, 2004. 1.2. Внедрение ERP-систем. Основные ошибки. Журнал «Директор-инфо», № 36, 2003. 1.3. Причины неудач внедрения ERP-систем в России. http://www.cfin.ru/press/loginfo/2001-07/70-80.shtml 1.4. Арчибальд Р. Управление высокотехнологичными программами и проектами. М.: ДМК, 2004. 1.5. Microsoft Solutions Framework, http://www.microsoft.com/technet/solutionaccelerators/msf/default.mspx; http://it-management.ru/content/view/103/82/ 1.6. Халл Э., Джексон К., Дик Д. Разработка и управление требованиями. Практическое руководство пользователя.. Telelogic, 2005. 2.1. Саидов-Лебединский О.З. Пособие по освоению методики внедрения готовых приложений на основе методики Oracle AIM, www.naytov-bis.ru 3.1. Грекул В.И., Денищенко Г.Н., Коровкина Н.Л. Проектирование информационных систем. Курс лекций. Учебное пособие. М.: Интернет-университет ИТ, 2005. 4.1. Руководство к своду знаний по управлению проектами (Руководство PMBOK). 3-е издание. 4.2. Ньюэлл Майкл В. Управление проектами для профессионалов. Руководство по подготовке к сдаче сертификационного экзамена. 3-е издание. М.: КУДИЦ-ОБРАЗ, 2006. 4.3. Милошевич Драган З. Набор инструментов для управления проектами. М.: Академия АйТи, ДМК Пресс, 2006. 6.1. Товб А.С., Ципес Г.Л. Управление проектами. Стандарты, методы, опыт. М.: «Олимп-Бизнес», 2003. 8.1. Ильин В. Руководство качеством проектов. Практический опыт. СПб.: Вершина, 2006. 239 240
