Академический Документы
Профессиональный Документы
Культура Документы
Учебник
Москва
2008
1
Содержание
2
Планирование реагирования на риски...................................................................................198
Мониторинг и управление рисками.......................................................................................200
Лекция 8. УПРАВЛЕНИЕ КАЧЕСТВОМ ПРОЕКТА..............................................................212
Планирование качества проекта.............................................................................................216
Процесс обеспечения качества...............................................................................................222
Процесс контроля качества.....................................................................................................225
Лекция 9. УПРАВЛЕНИЕ ЧЕЛОВЕЧЕСКИМИ РЕСУРСАМИ ПРОЕКТА..........................237
Команда управления проектом...............................................................................................238
Функции и полномочия проектных ролей команды управления проектом......................240
Планирование команды проекта............................................................................................246
Управление командой проекта...............................................................................................258
3
Лекция 1. ВВЕДЕНИЕ. НАЗНАЧЕНИЕ И СОСТАВ
МЕТОДОЛОГИЙ ВНЕДРЕНИЯ ИНФОРМАЦИОННЫХ
СИСТЕМ
4
Информационная система представляет собой сложный комплекс разнородных
составляющих, которые взаимодействуют между собой и создают необходимые
потребителю свойства системы. Для целей настоящей книги информационную систему
следует рассматривать как всю инфраструктуру предприятия, задействованную в процессе
управления информационно-документальными потоками и включающую в себя:
1. технологические элементы, обеспечивающие функционирование системы:
информационную модель предметной области;
кадровые ресурсы, отвечающие за формирование и развитие
информационной модели;
программный комплекс;
кадровые ресурсы, отвечающие за конфигурирование программного
комплекса;
аппаратно-техническую базу;
эксплуатационно-технические кадровые ресурсы;
2. управленческие элементы, обеспечивающие организацию эксплуатации системы:
регламент развития информационной модели и правила внесения в нее
изменений;
регламент технической и пользовательской поддержки программного
комплекса;
регламент внесения изменений в конфигурацию программного комплекса и
состав его функциональных модулей;
регламент использования программного комплекса и пользовательские
инструкции;
регламент обучения и сертификации пользователей.
5
проектов завершились в срок, не превысили бюджет и обеспечили реализацию
предусмотренных функций.
Источники проблем при внедрении информационной системы охватывают
различные аспекты частного проекта и деятельности компании в целом. К ним можно
отнести:
отсутствие постановки менеджмента на предприятии;
необходимость в частичной или полной реорганизации структуры
предприятия;
необходимость изменения технологии бизнеса в различных аспектах;
сопротивление сотрудников предприятия;
временное увеличение нагрузки на сотрудников во время внедрения системы;
необходимость в формировании квалифицированной группы внедрения и
сопровождения системы, выбор сильного руководителя группы.
Кроме того, в процессе внедрения существует необходимость в реализации единой
ИТ-стратегии предприятия, которая позволит адекватно сочетать развитие (создание)
программной и аппаратной частей системы параллельно с комплексом работ по развитию
существующей ИТ-инфраструктуры компании.
Значительная часть проблем проектов внедрения обусловлена довольно типичными
ошибками, которые известны, но тем не менее часто повторяются:
проектирование систем без учета стратегии развития бизнеса — необходимо
представлять структуру и масштабы бизнеса в перспективе как минимум на 3 года [1.1,
1.2];
нарушение принципа построения системы «сверху-вниз» и, как следствие,
отсутствие информационной поддержки принятия управленческих решений на верхних
уровнях управления;
чрезмерное увлечение реинжинирингом бизнес-процессов и порой
неоправданное их подчинение требованиям стандартной функциональности базовой ERP-
системы;
кардинальная переработка базовой функциональности ERP-системы;
нереалистичные ожидания вследствие неверной оценки экономической
эффективности внедрения ERP-системы.
6
В то же время накопленный опыт внедрения информационных систем
свидетельствует о наличии устойчивой группы факторов успеха таких проектов [1.3], и,
как следствие, о возможности формирования технологии успешного управления проектом
внедрения с учетом этих факторов (рис. 1.1). Рациональная организация проектов
внедрения информационных систем описывается в стандартах (международных,
государственных, корпоративных), которые часто называют методологиями внедрения.
7
направлена во многом на управление настройками модулей и доработками; а при
внедрении функционально подобных модулей SAP или ORACLE EBS превалирует
идеология бизнес-реинжиниринга, при котором организации предлагается изменять свои
бизнес-процессы, адаптируя их под «лучший опыт», зафиксированный в системе. В
качестве наиболее известных примеров методологий можно привести следующий, далеко
не исчерпывающий перечень:
разработки компании Microsoft — методологии «OnTarget», «MSF (Microsoft
Solutions Framework)», «Business Solutions Partner Methodology»;
разработки компании SAP — методологии «Процедурная модель SAP»,
«ASAP (Accelerated SAP)»;
разработки компании Oracle — комплекс методологий «Oracle Method».
Такое разнообразие стандартов позволяет организациям выбрать на их основе
рациональную стратегию и сформировать собственные процедуры внедрения, т. е. не
«изобретать велосипед» и в то же время обеспечить конкурентные преимущества.
Адаптация методологий к нуждам конкретного предприятия заключается не столько в
переводе текстов и шаблонов документов на русский язык, сколько в корректировке
подходов с учетом российских условий. При этом обычно пересматриваются
рекомендуемые стандартами сроки и последовательность задач, создаются методики
сбора, верификации и преобразования исходных данных, разрабатываются решения по
интеграции с унаследованными системами.
Для Заказчика информационной системы основными результатами использования
методологии являются:
создание решения, оптимально соответствующего требованиям клиента;
максимально эффективное использование ресурсов проекта;
минимизация сроков и затрат на внедрение;
уменьшение рисков проекта.
В то же время организация работы в соответствии с документально
зафиксированной методологией оказывается полезной и для разработчика системы:
появляется методическая база для обучения новых сотрудников стандартным
методам внедрения;
сокращаются внутренние расходы на организацию и реализацию проектов;
8
улучшается взаимодействие и взаимопонимание между членами проектной
группы;
повышается эффективность совместного использования ресурсов между
проектами, командами.
Несмотря на разнообразие существующих методологий, их содержание включает в
себя следующие стандартные компоненты: описание состава и структуры комплекса работ
проекта внедрения, правила управления таким проектом, организационную структуру
команды внедрения.
Структурирование комплекса работ заключается прежде всего в выделении фаз
(этапов) проекта. Разбиение проекта на фазы (длительностью 3-4 месяца) обусловлено
высокой сложностью проектов и значительными затратами времени на внедрение
информационных систем, позволяет получить значимые результаты в более сжатые сроки и
реализовать следующие преимущества в организации проекта:
данные проектной документации не устаревают;
после выполнения каждой фазы проекта появляется возможность уточнить
или скорректировать задачи к решению на последующих фазах;
снижаются проектные риски, обусловленные организационными
изменениями на предприятии Заказчика в ходе проекта;
оптимизируются бюджет проекта и график платежей.
Состав этапов проекта и распределение работ по этапам зависит от конкретной
методологии, однако можно выделить типовой состав этапов, которые в той или иной
степени присутствуют во всех методологиях и определяются самой логикой внедрения.
Это этапы определения проекта, обследования объекта автоматизации, анализа результатов
обследования и разработки дизайна системы, создания (настройки) системы, запуска
системы в эксплуатацию, сопровождения системы.
Следующим шагом является выделение процессов (комплексов работ),
выполняемых на различных этапах проектов. Состав и последовательность исполнения
процессов определяются конкретной методологией и служат основой для планирования
проекта — для построения иерархической структуры работ (см. раздел 4 «Управление
интеграцией и содержанием проекта внедрения»).
Таким образом, методология внедрения строится как пересечение двух различных
областей знаний: специфической технологии создания продукта — информационной
9
системы — и достаточно универсальной технологии управления проектной деятельностью
(рис. 1.2).
10
спонсор (куратор) проекта (Project Sponsor) — лицо, обеспечивающее
ресурсы проекта и любую административную поддержку; определяет приоритеты,
обеспечивает взаимодействие с функциональными подразделениями, утверждает
изменения; во внутренних проектах обычно несет ответственность за результаты проекта;
Заказчик (потребитель) проекта (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]. При
создании информационной системы необходимо сосредоточиться на той отдаче и выгоде,
которую ожидает получить ее потребитель. Если проект ориентирован на нужды Заказчика,
то точкой концентрации усилий и оценкой успешности будет бизнес-отдача (business-
value).
В качестве примеров конкретных задач внедрения информационных систем
управления можно привести следующие:
1. Предоставление руководству информации для анализа текущего состояния
организации и принятия обоснованных управленческих решений.
13
2. Обеспечение прозрачности и контроля деятельности предприятия на всех
уровнях.
3. Организация эффективного взаимодействия с контрагентами и клиентами.
4. Снижение трудоемкости процесса бюджетирования и организация бюджетного
контроля расходов.
5. Сокращение объема ручной и рутинной работы сотрудников, снижение
административных издержек.
6. Снижение вложений в активы, снижение затрат на перемещение материалов,
сокращение сроков производства, снижение запасов полуфабрикатов собственного
производства.
7. Снижение потерь рабочего времени, минимизация переналадок, повышение
коэффициента готовности оборудования.
8. Оперативность и точность расчета себестоимости, возможность оперативного
анализа затрат, возможность анализа причин отклонений от плана, определение наиболее
рентабельных видов продукции.
Второй аспект управления проектами связан с достижением поставленных в проекте
целей в рамках выделенного времени и утвержденного бюджета.
Эти задачи решаются за счет организации управления проектом на всех этапах его
жизненного цикла. Пример модели жизненного цикла проекта, приведенный на рис. 1.3,
показывает типичный состав фаз проекта и его связь с процессами проектирования
информационной системы. Таким образом, можно сказать, что жизненный цикл разработки
нового продукта отражает, что нужно сделать для его создания, а жизненный цикл проекта
— как нужно управлять работой.
14
Формирование
концепции
Разработка
требований
Шлюз –
принятие
Проектирование
решения о Определение
переходе на
следующую Реализация
фазу Разработка
Тестирование
(проектирование)
Ввод в
действие
Изготовление
Ввод в
эксплуатацию
15
разрешение конфликтов, для которых не найдены решения на более низком
уровне;
оценка качества работы непосредственно подчиненных менеджеров.
Высшее
руководство
Спонсор проекта
Цели
Ресурсы
Руководитель Функциональный
менеджеров руководитель
проектов
Корпоративные Насколько
стандарты УП Что хорошо
делать
Менеджер проекта Когда Функциональный
лидер проекта
Сколько
Кто
Планирование
Лидер пакета Как
Контроль работ
Офис проекта
Спонсор проекта:
отвечает за расходование средств, инвестируемых в проект;
определяет бизнес-план проекта;
утверждает цели, содержание, расписание, бюджет проекта и вносимые в них
изменения;
издает распоряжения и приказы по проекту, назначает менеджера проекта;
осуществляет мониторинг окружения проекта и информирует МП об
изменениях, способных повлиять на выполнение работ;
отслеживает ход выполнения проекта и формирует стратегические указания;
16
разрешает переадресованные ему конфликты;
обеспечивает соответствие требованиям конечного результата проекта.
Менеджер проекта:
отвечает за получение желаемых результатов в рамках утвержденного
бюджета и расписания проекта;
обеспечивает общее планирование и контроль проекта в течение всех фаз
жизненного цикла;
взаимодействует с функциональными руководителями для определения
объемов, сроков и стоимости (трудозатрат) работ.
Функциональный руководитель подразделения, участвующего в проекте:
отвечает за своевременное обеспечение всех проектов необходимыми
ресурсами;
объединяет требования (часто конфликтующие) всех активных проектов в
подразделении;
осуществляет детальное планирование работ подчиненного персонала.
В большинстве случаев центральной фигурой в управлении проектом является
менеджер проекта. Организация его управленческой деятельности в корне отличается от
управления регулярно выполняемыми работами (см. таблицу 1.2) и это учитывается в
содержании стандартов управления проектами.
17
специальностей
Может не быть специалистом в предметной Обычно разбирается в предметной области
области проекта лучше всех своих подчиненных
По окончании каждого проекта может Стабильно занимает свою должность
оказаться «временно безработным»
Карьера в основном «горизонтальная», рост Стремится сделать «вертикальную»
состоит в управлении все более сложными, карьеру, занимая все более высокие посты в
масштабными проектами своей функциональной сфере
Главная мотивация — бонус, зависящий от Основная часть мотивации — стабильный,
результатов проекта фиксированный оклад
18
Характерные особенности проектных работ
Проекты, независимо от сферы деятельности, обладают целым рядом одинаковых
особенностей. Распределение затрат времени и ресурсов в проекте описывается S-
образной кривой (см. рис. 1.5), причем до 90% затрат приходится на этапы разработки-
реализации.
Рис. 1.5. Типовое распределение затрат времени и ресурсов при выполнении проекта
19
Рис. 1.6. Относительные значения погрешности в оценке параметров проекта
Стоимость 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
Действующие лица Факторы
Поддающиеся оценке
Социальные
Поддающиеся влиянию Инфраструктурные
Управляемые
Проект
Технологические
Экономические
23
В процедурах управления целесообразно предусмотреть: приглашение ключевых
действующих лиц для участия в совещаниях по проекту; рассылку им копий отчетов по
проекту.
Работа менеджера проекта с выявленными факторами окружения предусматривает:
учет влияния факторов при планировании и обосновании проекта; мониторинг изменения
ключевых факторов и отражение изменений в планах проекта.
Пример специальных мероприятий, направленных на обеспечение взаимосвязи
проекта с его окружением, приведен в таблице 1.3.
25
Организационная структура проекта — соответствующая проекту временная
организационная структура, включающая всех его участников и создаваемая для
успешного управления и достижения целей проекта.
Необходимость разработки организационной структуры объясняется тем, что для
выполнения проекта создается команда проекта — новый временный рабочий коллектив,
состоящий из специалистов различных структурных подразделений компаний со стороны
Исполнителя и со стороны Заказчика. Как и для любого нового коллектива, для членов
команды проекта необходимо определить проектные роли (временные должности),
функции, обязанности, ответственность, полномочия и правила взаимодействия, а также
организационную схему, отражающую отношения подчиненности. При этом
несущественно, на какой период времени будет создаваться команда проекта — на
несколько месяцев или на несколько лет. Структура проекта определяется сложностью,
масштабностью разработки и внедрения ИС, количеством и специализацией членов
команды проекта. В команду проекта могут включаться специалисты, как на полную, так и
на частичную занятость.
Если внедрение информационной системы осуществляется с привлечением
сторонней организации — Исполнителя, то для успешного внедрения необходимо
сформировать команду проекта не только от Исполнителя, но и от Заказчика, после чего
определить допустимые взаимодействия между членами команд Исполнителя и Заказчика
(кто, с кем, по каким вопросам взаимодействует), т. е. установить правила взаимодействия.
При формировании организационной структуры проекта и принятии решения о
подчиненности следует помнить, что управлять непосредственно более чем десятью
членами команды проекта становится затруднительно. Идеальный вариант: пять-семь
человек.
Особо отметим, что при создании организационной структуры проекта штатное
расписание компании не должно изменяться. Не следует забывать, что проект — временное
мероприятие, по окончанию которого команда проекта распускается и специалисты
приступают к своим функциональным обязанностям в соответствии со штатной
организационной структурой компании или переходят на следующий проект, где их
функции и полномочия могут быть другими.
Правильно сформированная организационная структура проекта обеспечит его
эффективное управление, планирование, исполнение в запланированные сроки, на
определенном качественном уровне.
26
Первая задача в формировании организационной структуры проекта — решить,
какой тип структуры наилучшим образом подходит для данного проекта. Различные типы
структур имеют определенные преимущества.
Основные типы организационных структур
Функциональная организация (Functional Organization) (рис. 1.9). Иерархически
выстроенная организация, в которой у каждого сотрудника есть один прямой начальник,
сотрудники разделены на группы (отделы) по областям специализации. Каждая группа
(отдел) управляется одним человеком, имеющим компетенцию в данной области —
функциональным руководителем (руководителем отдела).
Генеральный директор
Руководство организации
л
де ба
о от уж
тв й ов я сл
нг дс а ы др ба ри я
ти и во ик в ка служ те на
ке пк из ст но ел вая ал ис
ар ку ро ги ла тд ансо хг рв
М За П Ло П О Фин Бу Се
27
Отвечает за Руководство организацией
обеспечение
сотрудников
ресурсами Начальник Начальник Начальник Начальник
отдела 1 отдела 2 отдела 3 отдела 4
Руководитель Сотрудник 1.1 Сотрудник 2.1 Сотрудник 3.1 Сотрудник 4.1
проекта 1
Отвечает за
выполнение
проекта
28
Основные функции отдела Маркетинга и продаж: продажи ИС и услуг по ее
внедрению.
Организация работ при функциональной структуре компании
При организации внедрения ИС в соответствии с функциональной структурой (рис.
1.9), работа, как правило, происходит следующим образом:
1. После продажи отделом маркетинга и продаж услуг на внедрение
информационной системы Руководитель компании проводит совещание с участием
руководителей отделов Программирования, Бизнес-аналитики, Консультаций и настроек
ИС. Руководитель компании доводит до участников совещания содержание и сроки
работ по внедрению, в соответствии с условиями договора. Руководители отделов
получают задание организовать работу по выполнению условий договора в рамках
компетенций отдела.
2. Руководители отделов распределяют работу между сотрудниками отделов,
контролируют качество и сроки ее выполнения, взаимодействуют с руководителями
других отделов по смежным работам и по приему/передаче результатов работ из одного
отдела другому. Например, отделом бизнес-аналитики был разработан в соответствии с
Трудовым Кодексом РФ алгоритм расчета оплаты труда за ночные часы и праздничные
дни. Разработанные алгоритмы передаются в отдел Программирования, где
осуществляется программирование алгоритмов расчета. После завершения работ по
программированию консультанты отдела Консультаций и настроек ИС проводят общую
настройку системы с использованием разработанных алгоритмов расчета.
29
Рис. 1.11. Пример организационной структуры консалтинговой компании
30
Рассмотрим на том же условном примере организацию работ проекта, но уже не по
функциональной, а по матричной структуре (рис. 1.10).
Руководитель компании при матричной организации проектных работ назначает
ответственного за достижение конечных целей договора и выполнение условий договора
— Руководителя проекта (менеджера проекта). Руководителем проекта при матричной
структуре может быть назначен один из руководителей отделов. Если нет особых
требований и условий, то Руководителем проекта назначается Руководитель того отдела,
который выполняет в данном проекте больший объем работ. При этом с Руководителя
отдела, назначенного Руководителем проекта, не снимаются функции по управлению
отделом. Другими словами, Руководитель проекта при матричной организации может быть
частично задействован на проекте (не на 100%), и продолжать выполнять свои
функциональные обязанности.
Руководитель проекта анализирует содержание, объем и сроки работ, на основании
чего определяет, сколько и каких специалистов нужно для выполнения проекта.
Руководитель проекта делает запрос Руководителям отделов на выделение специалистов с
указанием их квалификации и процента занятости. В зависимости от объема той или иной
работы по проекту, специалисты могут быть выделены как на полную, так и на частичную
занятость. После того как специалисты выделены, Руководитель проекта формирует для
них задания и координирует работы. Задания Руководитель проекта согласовывает с
Руководителем отдела (функциональным руководителем). У выделенного на проектные
работы специалиста при матричной организации работ два руководителя — Руководитель
отдела и Руководитель проекта. Руководитель проекта, как было сказано выше, отвечает за
конечные цели и результат, а Руководитель отдела (функциональный руководитель) несет
ответственность только за промежуточный результат в рамках компетенций подразделения
(отдела). Руководители проектов могут принимать решения только по организационным
вопросам, функциональные руководители — по техническим (предметным) вопросам.
Достоинство матричной структуры — наличие ответственного за достижение целей
проекта, недостаток — два руководителя у одного специалиста (консультанта), что часто
приводит к межличностным конфликтам. При возникновении конфликта ресурсов
проблема эскалируется вверх по иерархической структуре.
При матричной структуре организации проектных работ Руководитель проекта
может быть наделен различной степенью полномочий. В зависимости от степени
31
полномочий Руководителя проекта выделяют слабую, сбалансированную и сильную
матричную структуру (таблица 1.4).
Организация работ при проектной структуре компании
При проектной организации работ, так же как и при матричной, для управления
работами назначается Руководитель проекта, но занятость его на проекте не частичная, а
полная. Специалисты, выделенные для выполнения проектных работ, подчиняются только
Руководителю проекта до завершения проектных работ. Руководители отделов
(функциональных подразделений), выделивших специалистов на проектные работы, не
несут ответственность за качество их работы, в отличие от матричной структуры
организации. Исходя из того, что при проектной структуре Руководитель проекта на 100%
занят управлением проектом, напрашивается вопрос: а найдется ли такой Руководитель
отдела или другой специалист с навыками управления, который бы на время проекта
согласился отказаться от своей должности? Ведь для него возникает риск по окончанию
проекта оказаться «не у дел». Решение подобной проблемы найдено в том, что в проектных
структурах введена специальная должность — Руководитель проекта. В ряде организаций
созданы отделы/департаменты Руководителей проектов, и только из их числа назначаются
Руководители проектов. Таким образом, основное отличие проектной структуры компании
от матричной — в наличии специально выделенной группы специалистов для управления
проектами. Руководитель проекта назначается только из этой группы (отдела,
департамента), в проекте он занят на 100% и наделен всеми полномочиями по привлечению
и управлению ресурсами, принятию управленческих решений, в том числе и по
финансовым вопросам в рамках установленного бюджета.
32
Критерии выбора организационной структуры проекта, отвечающей целям и
условиям осуществления проектов в конкретной компании, представлены в таблице 1.5.
33
Куратор проекта (Спонсор) Куратор проекта (Спонсор)
со стороны Заказчика со стороны Исполнителя
<ФИО> <ФИО>
Управление проектом
Заказчик: Исполнитель:
Руководитель проекта Руководитель проекта
<ФИО> <ФИО>
Команда управления проектом Команда управления проектом
:
34
Заказчик Исполнитель
Куратор Куратор
проекта Неформальное взаимодействие
проекта
(Спонсор) (Спонсор)
Руководитель Руководитель
Формальное взаимодействие
проекта проекта
35
• Лекция 2. СОДЕРЖАНИЕ ПРОЕКТОВ ВНЕДРЕНИЯ ИС В РАЗЛИЧНЫХ
МЕТОДОЛОГИЯХ
Ключевые слова: методология внедрения ИС, этап проекта внедрения ИС, фаза
проекта внедрения ИС, процессы проекта внедрения ИС, подготовка проекта, анализ,
дизайн, разработка, тестирование, опытная эксплуатация, диагностика,
конфигурирование, пилотный проект.
36
тестирование, развертывание, опытная эксплуатация. Задачи этапов и выполняемые работы
приведены в таблице 2.1.
37
Разработка и Создать программный Разработка и тестирование
тестирование продукт дополнительной функциональности.
Проверить Разработка и утверждение
работоспособность дополнительных интерфейсов.
продукта Разработка программы тестирования
модификаций и интерфейсов.
Выполнение процедур тестирования
модификаций и интерфейсов.
Разработка спецификации на следующую
стадию
Развертывание Установить систему у Развертывание (инсталляция) системы на
Заказчика рабочие места конечных пользователей.
Настройка прав и уровней доступа
пользователей.
Разработка процедур переноса сальдо и
операций.
Разработка процедур верификации
начальных данных и операций.
Подготовка пользовательских
инструкций.
Обучение конечных пользователей.
Разработка спецификации на следующую
стадию
Опытная Запустить систему в Перенос начальных сальдо и операций.
эксплуатация эксплуатацию. Выполнение процедур верификации
Осуществить сдачу-приемку начальных данных.
проекта Запуск системы в эксплуатацию.
Опытная эксплуатация.
Приемка
39
Таблица 2.2. Характеристика этапов внедрения по методологии MBS Partner Methodology
Этап проекта Цели этапа Выполняемые работы (пакеты работ)
Диагностика Анализ и описание Организация рабочей группы
бизнес-процессов. сотрудников Заказчика для проведения
Выявление основных диагностики.
потребностей бизнеса. Сбор предварительной информации.
Оценка функциональной Обследование и описание структуры
применимости базового предприятия, бизнес-процессов,
программного продукта. основных целей, потребностей
Определение ожидаемых и ожиданий Заказчика.
результатов, сроков, Согласование результатов
границ и бюджета обследования, установка критериев
проекта оценки результатов проекта.
Подготовка отчета о Диагностике.
Предложения по разработке
и внедрению решения
Анализ Организация проекта. Открытие проекта, формирование
Детальное обследование Управляющего комитета и проектной
и описание предприятия группы.
Заказчика. Подготовка плана проекта, Устава
Изучение требований проекта, порядка отчетности,
к внедряемому решению. управления изменениями и рисками,
Документирование сдачи-приемки проекта.
функциональных Проведение тренинга для сотрудников
требований, создание клиента по базовой функциональности
полного перечня продукта.
требуемых модификаций Уточнение и детализация требований
и доработок к решению бизнес-процессов Заказчика.
функциональности Выработка решений относительно
изменения существующих бизнес-
процессов, модификации
функциональности продукта,
построения интерфейсов с внешними
40
системами.
Подготовка Спецификации
функциональных требований.
Согласование и утверждение
функциональных требований, уточнение
параметров проекта
Дизайн Описание создаваемого Разработка Концептуального дизайна
решения, детальное (Технического задания), описывающего
проектирование в терминах предметной области
модификаций концепцию реализации решения,
и доработок изменения функциональности и бизнес-
функциональности. процессов, требования к отчетности.
Планирование изменений Согласование и утверждение
бизнес-процессов. Концептуального дизайна Заказчиком
Уточнение подходов проекта.
к разработке Разработка Детального дизайна
и испытаниям (Программного дизайна),
проектируемого решения описывающего в терминах системы
предполагаемые модификации
функциональности, интерфейсы
с внешними системами, порядок
тестирования разработки, порядок
приемки работ.
Согласование и утверждение
Детального дизайна.
Планирование порядка, сроков
и ресурсов для разработки и контроля
качества.
Уточнение параметров последующих
стадий
Разработка и Реализация и первичное Настройка среды для разработки, среды
тестирование тестирование для тестирования, рабочей среды для
модификаций интеграции результатов в рабочую
41
и доработок систему.
функциональности. Реализация модификаций
Установка и настройка и интерфейсов, первоначальное
системы. тестирование разработчиками.
Планирование Передача результатов разработки
и проведение испытаний. Заказчику для тестирования,
Доработка решения исправление обнаруженных ошибок,
по результатам корректировка требований, повторная
испытаний реализация и тестирование.
Комплексное тестирование Заказчиком,
исправление ошибок и корректировка
требований.
Установка результатов разработки
в рабочую среду, настройка системы,
перенос основных справочников
и сальдо.
Проведение финальных испытаний
и подготовка к сдаче-приемке
Развертывание Подготовка и настройка Проведение официальной сдачи проекта
рабочей системы. Заказчику.
Разработка Оценка достижения целей проекта
пользовательской и критериев успеха.
документации. Планирование запуска в промышленную
Тренинг конечных эксплуатацию.
пользователей. Подготовка системы к запуску,
Планирование и запуск контроль готовности, заведение
в рабочую эксплуатацию. актуальных данных.
Сдача-приемка проекта Организация и проведение тренинга для
конечных пользователей.
Запуск ежедневной обработки в новой
системе операций.
Осуществление первоначальной
поддержки специалистами партнера
42
промышленной эксплуатации системы.
Официальное завершение проекта,
оценка проекта Заказчиком
Начальное Сопровождение Осуществление ежедневной поддержки
сопровождение функционирования работы Заказчика с системой
системы в режиме (по телефону, электронной почте,
рабочей эксплуатации. с выездом специалистов на место).
Устранение выявленных Периодические обновления системы,
несоответствий. связанные с выходом новых версий,
Переход к режиму изменениями законодательства,
работы Заказчика развитием технологий.
в рамках контракта Проведение периодической оценки
на регулярное соответствия решения требованиям
сопровождение Заказчика, наличия потребностей
в изменении и развитии решения.
Планирование и организация новых
проектов
43
Обеспечить безболезненный переход к работе в новом информационном
окружении.
Состав этапов проекта внедрения существенно отличается от рассмотренных
методологий.
MBS Partner Methodology On Target OneMethodology
1. Диагностика 1. Подготовка проекта 1. Рамки внедрения
2. Анализ 2. Анализ 2. Модель
3. Дизайн 3. Дизайн 3. Конфигурирование
4. Разработка и 4. Разработка и 4. Запуск в эксплуатацию
тестирование тестирование
5. Развертывание 5. Развертывание 5. Развитие
6. Начальное 6. Опытная
сопровождение эксплуатация
47
3. Модель и детальные требования отображаются в приложение (приложение
настраивается и демонстрируется).
4. Если какие-то аспекты модели или требований не реализуются приложением, то
формируется подход к их реализации.
5. Стоимость реализации новых возможностей приложения оценивается, и если она
«слишком» велика, то происходит возврат к перестройке модели или изменение
требований.
6. Если стоимость реализации новых возможностей оправдана, то новые компоненты
приложения разрабатываются (и интегрируются в приложение).
7. Составляются инструкции по использованию приложения, объединяющие
стандартные и новые возможности приложения и базирующиеся на модели явления
и на детальных требованиях к нему.
8. Новая модель внедряется в жизнь.
Работы, выполняемые для решения этих задач, по принципу общности результатов
сгруппированы в процессы. Проект делится на шесть фаз (см. рис. 2.1).
Основные цели, которые должны быть достигнуты в соответствующих фазах
проекта
В фазе Определение сформулированы совокупные бизнес-требования
Заказчика. Впоследствии они могут уточняться и видоизменяться в ходе отображения на
функциональность Oracle E-Business Suite, но появления новых бизнес-требований не
происходит.
В фазе Анализ операций зафиксированы будущие бизнес-процессы и
определено, как они будут реализованы с помощью Oracle E-Business Suite; установлено,
какие бизнес-требования не могут быть удовлетворены с помощью стандартной
функциональности и какая дополнительная разработка необходима.
В фазе Дизайн решения получены детальные спецификации для
дополнительной разработки (функциональный и технический дизайн) и разработаны
сценарии тестирования.
В фазе Разработка завершены все дополнительные разработки, проведены
приемочные тесты, разработана пользовательская документация для эксплуатации
решения.
48
В фазе Переход завершено обучение конечных пользователей, проведена
конвертация данных, система введена в эксплуатацию.
В фазе Эксплуатация — обеспечение поддержки Заказчика в работе с
системой; устранение выявленных недостатков в работе системы.
Конвертация данных
Документирование
Тестирование функциональности
Тестирование производительности
Обучение
Ввод в эксплуатацию
49
Отображение бизнес-требований (BR). В ходе выполнения задач этого
процесса выясняется, какая функциональность Oracle E-Business Suite и каким образом
может применяться для реализации необходимых Заказчику функциональных
возможностей информационной системы. Окончательно определяются бизнес-процессы
«как должно быть» и состав используемой в системе информации. Фиксируются значения
параметров настройки программных модулей Oracle E-Business Suite и перечень
необходимых доработок.
Разработка архитектуры (TA). В ходе этого процесса происходит
построение технической архитектуры, необходимой для работы системы, а также
определяются значения ключевых параметров настройки Oracle E-Business Suite,
касающихся архитектуры.
Разработка дополнительной функциональности (MD). В рамках этого
процесса разрабатывается программное обеспечение, которое необходимо для реализации
функциональности, отсутствующей в Oracle E-Business Suit.
Конвертация данных (CV). Процесс охватывает задачи, связанные с
переносом данных из унаследованных систем в новую. Выявляются объекты, содержащие
необходимые данные, определяются методы преобразования и загрузки этих данных в
систему. Разрабатывается вспомогательное программное обеспечение.
Документирование (DO). В этом процессе создается документация на
систему.
Тестирование функциональности (TE). На основе бизнес-требований
разрабатываются сценарии тестирования и проводится проверка реализации этих
требований в системе.
Тестирование производительности (PT). Проверяется работоспособность
системы в условиях реальной нагрузки (по количеству пользователей, документов,
транзакций и пр.).
Обучение (TR). Процесс включает в себя две основные задачи: обучение
проектной группы (с него начинается проект по внедрению) и обучение конечных
пользователей (им проект заканчивается).
Ввод в эксплуатацию (PM). В ходе этого процесса рассматриваются все
вопросы, связанные с организацией промышленной эксплуатации системы и ее
сопровождением.
50
Процессы в AIM формируются из задач. Задача — элементарный (неделимый)
объем работ, который обязательно заканчивается формально фиксируемым
(документируемым) результатом. Если результат естественным образом в ходе выполнения
задачи сформирован в электронной форме (например, выполнены настройки программного
модуля), то он должен быть оформлен соответствующим документом, согласован и
утвержден (обычно в бумажной форме). Если результатом задачи является выполненная
работа, то он документируется в виде акта. Выполнение задачи дает результат либо
полезный для целей проекта сам по себе, либо используемый для выполнения (в качестве
входа) другой задачи. Задачи в AIM обозначаются двумя буквами (обозначение процесса) и
двумя-тремя цифрами через точку.
В методологии приводится описание типовых ролей, которые исполняются
участниками проекта при выполнении задач.
Описание выполняемых работ заключается в формировании цепочек задач, которые
необходимо выполнить для достижения целей проекта.
Внедрение готового приложения заключается в одновременном согласовании
возможностей приложения и организации исполнения автоматизируемых бизнес-
процессов. Это приводит к необходимости настройки (доработки) приложения и
модификации бизнес-процессов. Рекомендуемая последовательность действий
определяется следующей цепочкой задач:
51
CV.140 — ввод начальных данных;
PM.080 — запуск новой системы.
52
Определить текущие бизнес-процессы и
учетные процедуры
• Создать детальный план проекта
Результаты:
Общее описание деятельности
Анализ текущих бизнес-процессов
Модель управленческого планирования и
учета
Предварительный концептуальный
дизайн системы
Обученная команда внедрения
Детальный план проекта внедрения
Анализ операций Оценка специфики и • Анализ бизнес-процессов
создание детального Сбор информации о бизнес-процессах
рабочего плана Разработка модели для каждого бизнес-
проекта процесса
Внесение в существующие бизнес-процессы
изменений и дополнений, необходимых для
соответствия модели системы
• Разработка требований к
оборудованию, программному
обеспечению и коммуникациям
• Определение задания на
дополнительные разработки в системе
• Разработка дополнительных моделей
Разработка моделей тестирования
Разработка модели перехода на новую
систему
Результаты:
Утвержденная модель будущих процессов
Анализ реализации процессов в системе
Анализ достаточности структуры базы
53
данных
Концептуальный дизайн системы
Требования к изменению или расширению
функциональности системы
Дизайн системы Проектирование • Преобразование бизнес-процессов
системы Определение сценариев работы в системе
Проектирование параметров системы
Подготовка первой версии рабочих
инструкций
• Разработка детальных схем
дополнительных разработок
• Разработка материалов для обучения
• «Техническое» проектирование
системы
Проектирование архитектуры ПО,
Проектирование системы безопасности,
Определение требований к оборудованию,
Проектирование организации базы данных
• Разработка средств конвертации
данных
• Подготовка инфраструктуры
тестирования системы
Результаты:
Описание настройки системы
Техническое задание на разработку
модулей системы
Описание соответствия данных
существующей системы с данными
системы
Сценарии бизнес-тестирования системы
Сценарии тестирования интеграции с
другими системами
54
План обучения пользователей
Построение Создание рабочей • Разработка дополнительного
системы версии системы программного обеспечения
Функциональное расширение модулей и базы
данных
Разработка интерфейсов с существующими
системами
Разработка программ конвертации данных
• Тестирование
Работоспособности модулей и системы в
целом в соответствии с требованиями
средств конвертации данных
интерфейсов
Производительности системы
• Разработка документации для
пользователей, системных
администраторов и технической
поддержки
• Разработка и тестирование процедур
инсталляции
Результаты:
Установлена рабочая версия системы
Настроены параметры системы
Проведена тестовая конвертация данных
Созданы инструкции для пользователей
Проведено бизнес-тестирование системы
Проведено тестирование интеграции
системы с другими системами
План перехода на новую систему
Переход Запуск системы в • Установка системы конвертации
эксплуатацию данных, загрузка и проверка данных в
системе
55
• Обучение пользователей
• Подготовка рабочего пространства в
системе
• Окончательная настройка системы
• Организация поддержки системы
• Обеспечение нормальной работы
пользователей
• Определение статуса готовности
системы
• Переход к эксплуатации системы
Результаты:
Конвертированные и проверенные данные
Результаты окончательного
тестирования
Подготовленные пользователи
Рабочая система
Инфраструктура поддержки системы
56
Дополнительно следует отметить, что в рассмотренных методологиях процедуры
управления проектом присутствуют в усеченном варианте. Полная технология управления
проектами рассматривается в последующих разделах книги.
•
57
Лекция 3. УНИФИЦИРОВАННАЯ МОДЕЛЬ ОРГАНИЗАЦИИ
ВНЕДРЕНИЯ РЕШЕНИЙ В МЕТОДОЛОГИИ MICROSOFT
SOLUTIONS FRAMEWORK (MSF)
Понятие «ИТ-решение». Модель процессов MSF. Фазы и вехи проекта
внедрения. Модель команды проекта. Ролевые кластеры команды проекта.
Масштабирование проектной команды. Организация исполнения проекта.
58
• программно-технические средства, которые могут быть как новыми, так и
усовершенствованными версиями разработанных ранее;
• внедрение — включает в себя процедуры установки/удаления аппаратного
и программного обеспечения;
• обучение — процедуры, которые распространяются на всех участников
использования и сопровождения решения;
• документация — вся информация, необходимая для установки, поддержки,
сопровождения и использования решения;
• сопровождение — процедуры развития, восстановления, действий в
нештатных ситуациях и поддержки пользователей;
• внешние коммуникации — информирование заинтересованных сторон о ходе
внедрения решения и его влиянии на их интересы.
В отличие от решений, программные продукты разрабатываются для нужд
массового рынка, поставляются в качестве дистрибутивных пакетов или загружаемых
файлов и не требуют организации процесса внедрения.
Универсальность модели MSF определяется тем, что благодаря своей гибкости
и отсутствию жестко установленных связей и процедур она может быть применена при
разработке весьма широкого круга систем: традиционного программного обеспечения,
ERP-систем, решений в области электронного бизнеса, распределенных сетевых
приложений и пр.
Эта модель сочетает в себе свойства двух стандартных [3.1] производственных
моделей: каскадной и спиральной (см. рис. 3.1).
59
Вехи
Фазы
Внедрение Разработка
концепции
Стабилизация Планирование
Разработка
60
Фазы проекта определяют последовательно решаемые задачи, а вехи (milestones) —
ключевые точки проекта, характеризующие достижение какого-либо существенного
результата.
В MSF используются два вида вех: главные и промежуточные. Они имеют
следующие характеристики:
• главные вехи служат точками перехода от одной фазы к другой и
определяют изменения в текущих задачах ролевых кластеров проектной команды; в
MSF главные вехи являются в достаточной степени универсальными для применения в
любом ИТ-проекте;
• промежуточные вехи показывают достижение определенного прогресса в
исполнении фазы проекта и расчленяют большие сегменты работы на меньшие,
обозримые и управляемые участки; промежуточные вехи могут варьироваться в
зависимости от характера проекта.
Изменения в задачах ролевых кластеров проектной команды происходят по мере
смены фаз проекта. Переход от одной фазы к другой включает в себя также перенос
основной ответственности от одних ролевых кластеров к другим, как показано в таблице
3.1.
61
обязанности одного ролевого кластера могут выполнять несколько человек в зависимости
от масштабности и сложности проекта.
Состав команды определяется теми целями, которые необходимо достичь для успеха
проекта: за достижение конкретной цели отвечает соответствующий ролевой кластер, а за
успешность проекта в целом несет ответственность вся команда. В соответствии с целями
проекта MSF выделяет шесть ролевых кластеров, каждый из которых должен обладать
специфическими компетенциями для исполнения собственных функций (см. таблицу 3.2).
Формирует ожидания
Заказчика
Определяет компромиссы
между параметрами
«возможности продукта /
время / ресурсы»
Организует маркетинг, PR
Разрабатывает, поддерживает
и исполняет план
коммуникаций
62
программой результата в разработки с целью
рамках получения готового продукта
Выработка
проектных в отведенные сроки
архитектуры решения
ограничений Формулирует спецификацию
Контроль
продукта и разрабатывает его
производственного
архитектуру
процесса
Регулирует взаимоотношения
Административные
и коммуникацию внутри
службы
проектной группы
Следит за временным
графиком проекта и готовит
отчетность о его состоянии
Разрабатывает, поддерживает
и исполняет сводный план и
календарный график проекта
Организует управление
рисками
63
внедрению
Консультирует команду по
технологическим вопросам
Разрабатывает учебные
материалы и осуществляет
обучение пользователей
64
выпуском сопровождение Сопровождение обслуживания продукта
продукта Бизнес-процессы Организует снабжение
проектной группы
Управление
выпуском готового Организует внедрение
продукта продукта
Вырабатывает компромиссы в
управляемости и удобстве
сопровождения продукта
Организует сопровождение и
инфраструктуру поставки
Организует обеспечение
проектной группы
65
Рис. 3.2. Разделение проектной команды на группы направлений [1.5]
Второе — создание функциональных групп. Функциональные группы — это
группы, существующие внутри ролевых кластеров. Они создаются в больших проектах,
когда необходимо сгруппировать работников внутри ролевых кластеров по их областям
компетенции (рис. 3.3). Например, в команде разработчиков возможна группировка
сотрудников в соответствии с назначением разрабатываемых ими модулей: интерфейс
пользователя, реализация бизнес-логики или объектов данных. В отличие от групп
направлений, функциональные группы имеют внутреннюю иерархическую структуру.
66
Третье направление масштабирования — объединение ролей. Как
правило, выделение одного человека на каждый ролевой кластер обеспечивает
полноценное исполнение каждой из ролей, но это экономически оправданно не для всех
проектов. Зачастую в малых проектных группах члены группы могут объединять роли. При
этом MSF рекомендует соблюдать два принципа. Во-первых, роль команды разработчиков
не может быть объединена ни с какой другой ролью. Разработчики — это создатели
проекта, и они не должны отвлекаться от своей главной задачи. Наделение разработчиков
дополнительными обязанностями лишь делает более вероятным выход из календарного
графика проекта.
Второй принцип — это избежание сочетания ролей, имеющих предопределенные
конфликты интересов.
Рекомендации MSF по возможностям объединения ролей приведены на рис. 3.4.
Роль менеджера проекта возлагается на кластер «Управление программой».
Основные функции этого кластера — управление проектом, выработка архитектуры
решения, контроль производственного процесса и организация деятельности
административных служб. В небольших проектах все эти функции могут успешно
осуществляться одним менеджером программы. Но по мере роста объема и сложности
проекта в этом ролевом кластере выделяются две ветви специализации: работа над
архитектурой и спецификациями и управление проектом.
Организация взаимодействия между проектной командой и заказчиками
(заинтересованными лицами) распределяется среди ролевых кластеров «Управление
программой» и «Управление продуктом». «Управление продуктом» обеспечивает
отчетность в части характеристик решения, а «Управление программой» — отчетность о
ходе проекта.
67
Рис. 3.4. Возможности объединения ролей в малых проектах [1.5]
68
Управление продуктом Выявление нужд и требований Заказчика; определение
общих целей проекта; документальное оформление
общего описания и рамок проекта
Управление программой Определение: целей дизайна, концепции решения,
структуры проекта
Разработка Прототипирование решения; анализ технологических
возможностей; анализ осуществимости решения
Удовлетворение потребителя Предварительная оценка эксплуатационных
характеристик решения и их влияния на его разработку
Тестирование Формирование стратегий тестирования и оценка их
влияния на разработку решения
Управление выпуском Формирование требований внедрения и сопровождения,
оценка их влияния на разработку решения
69
относящиеся к решению в целом). Задача предусматривает последовательное выполнение
следующих работ:
• выявление типов пользователей системы;
• выявление сценариев использования, в которых моделируется выполнение
какой-либо операции определенным типом пользователя;
• выделение последовательностей специфических действий, называемых
примерами пользования (use cases), которые необходимо выполнить пользователю для
осуществления операции;
• проектирование (дизайн системы). В MSF выделяется три уровня процесса
проектирования: концептуальный дизайн (conceptual design), логический дизайн (logical
design) и физический дизайн (physical design).
Концептуальный дизайн — описание всего, что нужно включить в конечный
продукт. В это описание не входит информация о способе реализации решения.
Концептуальный дизайн включает только подробные сведения о функциональности
предлагаемого решения, взаимодействии с существующей технологической
инфраструктурой, о пользовательском интерфейсе и предполагаемых рабочих
характеристиках системы.
Логический дизайн — описание состава, организации и взаимодействия элементов,
из которых состоит программное решение.
Физический дизайн — описание программного решения в терминах разработчика
системы. Включает все необходимые детали для реализации: технологии, организацию,
структуру и взаимосвязи элементов, которые будут использованы при создании
программного решения.
Результаты процесса проектирования документируются в функциональной
спецификации.
2. Подготовка рабочих планов.
На основе разработанных спецификаций каждый из руководителей ролевых
кластеров проектной группы подготавливает планы, относящиеся к его роли (план
внедрения, план тестирования, план эксплуатации, план мер безопасности, план обучения и
пр.), и принимает участие в командных сессиях планирования, где все планы
синхронизируются и представляются вместе в виде сводного плана проекта.
3. Оценка проектных затрат и сроков разработки различных составляющих проекта.
70
Распределение задач между ролевыми кластерами в фазе планирования приведено в
таблице 3.4.
Таблица 3.4. Задачи проектной группы в фазе планирования
71
• Среды разработки и тестирования развернуты — обеспечивают возможность
создавать и тестировать решение вне находящихся в эксплуатации производственных
систем, что позволяет избежать негативного влияния на эти системы.
Достижение главной вехи «Планы проекта утверждены» означает, что
промежуточные процедуры планирования успешно пройдены, составленные календарные
графики реалистичны и соответствуют потребностям Заказчика, распределение ролей и
ответственности в команде определено должным образом и механизмы управления
рисками приведены в действие.
Результаты фазы оформляются в базовой версии проекта путем создания
следующих документов:
• функциональная спецификация;
• план управления рисками;
• сводный план и сводный календарный график проекта.
Фаза разработки
Цель фазы — создание компонент решения (включая как документацию, так и
программный код).
Распределение задач между ролевыми кластерами в фазе разработки приведено в
таблице 3.5.
72
• Концепция подтверждена — успешно проведена проверка ключевых
элементов решения в непроизводственной копии существующей среды.
• Билд n завершен, билд n+1 завершен — промежуточные вехи, помогающие
определить прогресс создания решения. В сложных системах зачастую выделяются
компоненты, каждый из которых разрабатывается и тестируется отдельной командой и
затем интегрируется в общее решение. Билды (сборки) и являются процедурами слияния
компонент. Эти промежуточные вехи могут быть привязаны к некоторым важным
элементам системы (например, завершение графического дизайна, разработки базы данных
и пр.).
Главная веха «Разработка завершена» означает, что создание всех составляющих
завершено, решение готово к тестированию и стабилизации.
Результаты фазы:
• исходный и исполнимый код приложений;
• скрипты установки и конфигурирования;
• окончательная функциональная спецификация;
• материалы поддержки решения;
• спецификации и сценарии тестов.
Фаза стабилизации
Цель фазы — тестирование и отладка разработанного решения в реалистичной
модели производственной среды.
Основные выполняемые задачи:
• выявление, приоритезация и устранение ошибок;
• пилотное внедрение решения.
Распределение задач между ролевыми кластерами в фазе стабилизации приведено в
таблице 3.6.
73
Удовлетворение потребителя Доработка эксплуатационных руководств; подготовка
учебных материалов
Тестирование Организация и проведение тестирования
Управление выпуском Развертывание и поддержка пилотного внедрения;
планирование внедрения; обучение персонала
сопровождения
74
релиз (pilot release) — это внедрение решения или в часть производственной среды, или для
части пользователей, или на подмножестве данных.
Главная веха «Готовность решения утверждена» означает, что к этому моменту
проектная группа завершает разрешение всех существенных проблем и решение готово к
внедрению.
Результаты:
• окончательный продукт;
• документация выпуска;
• материалы поддержки решения;
• результаты и инструментарий тестирования;
• исходный и исполнимый код приложений;
• проектная документация.
Фаза внедрения
Цель фазы — установка и отладка системы в реальных условиях эксплуатации,
передача системы персоналу поддержки и сопровождения, получение окончательного
одобрения результатов проекта со стороны Заказчика.
Основные задачи проектной группы в фазе внедрения приведены в таблице 3.7.
75
(например, контроллеры доменов, маршрутизаторы, почтовые серверы, удаленные серверы
доступа, серверы баз данных).
• Внедрение на местах завершено — к этому моменту все целевые потребители
получают доступ к решению и оформляются акты о пуске решения в эксплуатацию.
• Внедренное решение стабилизировано — Заказчик и Проектная группа
пришли к соглашению о том, что решение функционирует правильно.
Временной отрезок между промежуточной вехой «Внедренное решение
стабилизировано» и главной вехой «Внедрение завершено» иногда называют «периодом
затишья»: проектная группа активно не работает, но она необходима для реагирования на
возникающие проблемы.
Достижение главной вехи «Внедрение завершено» означает, что решение начинает
давать Заказчику ожидаемую бизнес-отдачу, а проектная группа завершила свою
деятельность.
Результатами этой фазы являются:
• информационные системы эксплуатации и поддержки;
• работающие процедуры и процессы;
• базы знаний, отчеты, журналы протоколов;
• версии проектных документов, массивы данных и программный код,
разработанные во время проекта;
• отчет о завершении проекта;
• окончательные версии всех проектных документов;
• показатели удовлетворенности Заказчика и потребителей.
В первых разделах книги приведены сведения, которые позволяют решить целый
ряд вопросов, возникающих при планировании проекта внедрения информационных
систем:
1. сформировать структуру проекта — выделить фазы (этапы);
2. определить, что и в какой последовательности будет исполняться, т. е. построить
иерархическую структуру работ и сетевой график проекта;
3. определить состав проектной команды и распределение ролей и ответственности
между участниками;
4. задать контрольные точки проекта и критерии оценки их достижения (получения
нужных результатов).
76
Методика планирования и управления проектом рассматривается в последующих
разделах.
77
Лекция 4. УПРАВЛЕНИЕ ИНТЕГРАЦИЕЙ ПРОЕКТА.
УПРАВЛЕНИЕ СОДЕРЖАНИЕМ ПРОЕКТА
Понятие интеграции. Характеристики интеграции проекта. Элементы
интеграционных процессов управления проекта: разработка Устава проекта;
разработка предварительного описания содержания проекта; разработка плана
управления проектом. Процессы управления содержанием проекта. Построение
иерархической структуры работ (ИСР). Словарь ИСР. Контроль за изменениями
содержания. Управление содержанием. План управления содержанием проекта.
78
С целью структуризации управления проектом процессы управления проектом
распределены по девяти областям знаний [4.1]:
1. Управление интеграцией.
2. Управление содержанием.
3. Управление временем.
4. Управление стоимостью.
5. Управление персоналом.
6. Управление коммуникациями.
7. Управление качеством.
8. Управление рисками.
9. Управление снабжением.
Распределение 44 процессов по областям знаний и группам процессов представлено
в таблице 4.1.
79
стоимостью оценка стоимостью
проекта Разработка
бюджета
расходов
Управление Планирование Обеспечение Контроль
качеством качества качества качества
проекта
Управление Планирование Набор команды Управление
человеческими человеческих проекта командой
ресурсами ресурсов Развитие проекта
проекта команды
проекта
Управление Планирование Распространен Отчетность по
коммуникациям коммуникаций ие информации исполнению
и проекта Управление
участниками
проекта
Управление Планирование Мониторинг и
рисками управления управление
проекта рисками рисками
Идентификаци
я рисков
Качественный
анализ рисков
Количественны
й анализ
рисков
Планирование
реагирования
на риски
Управление
поставками
проекта
В данном учебном пособии рассмотрены все области знаний, за исключением
области «Управление поставками», которая на проектах по внедрению информационных
технологий не является существенной.
Управление интеграцией
Область знаний «Управление интеграцией» включает все пять групп процессов [4.1]:
Инициация,
Планирование,
Исполнение,
Управление и контроль,
Завершение.
80
Результаты процессов из группы Инициация являются входящей информацией для
группы процессов Планирование. В свою очередь, результаты групп процессов Управление
и контроль являются входящими для группы процессов Завершение. В упрощенном виде
последовательность применения групп процессов управления проектом при внедрении ИС
представлена на рис. 4.1.
Управление
интеграцией
1. Процессы
инициации 2. Процессы
планирования
4.Процессы 3. Процессы
управления и исполнения
контроля
5.Процессы
завершения
81
Интеграция управления проектом требует, чтобы все процессы управления
проектами были выстроены и связаны с другими процессами для облегчения их
координации.
Необходимость в интеграции процессов управления проектами обусловлена
взаимодействием процессов управления. Эти процессы взаимодействуют между собой
сложным образом, поэтому рассмотрим на отдельных примерах, как выстраивается
интеграционное взаимодействие групп процессов управления проектной деятельностью.
Проектная деятельность начинается с процессов инициации — с момента
подписания договора с Заказчиком (или согласования с Заказчиком условий договора).
При инициации определяются цели, задачи, результаты, сроки проекта, формируется
команда управления проектом, определяются необходимые ресурсы, подготавливаются при
необходимости рабочие места, разрабатываются необходимые для управления проектом
документы. На этом инициация проекта завершается. Команда управления проектом
приступает к процессу планирования проекта, составляется расписание проекта. Как
правило, вначале разрабатывается укрупненное расписание, которое должно
соответствовать этапам договора, затем осуществляется его детализация. С точки зрения
управления интеграцией, договор является точкой входа для процесса планирования.
Именно договором определяются результат и сроки проекта. По завершению составления
расписания проекта — когда определены задачи, их исполнители, сроки выполнения, —
приступают к выполнению проектных работ. Процесс планирования при этом не
заканчивается, он продолжается практически до момента завершения проекта. В ходе
выполнения работ первоначальное укрупненное расписание проекта детализируется,
уточняется. А это, в свою очередь, означает необходимость построения интеграционного
взаимодействия процессов планирования с процессами исполнения работ.
Процессы группы «исполнение» выстраиваются в соответствии с применяемой на
проекте методологией внедрения информационной системы.
С момента инициации проекта осуществляется непрерывный контроль над всей
проектной деятельностью, включая и процессы планирования, и процессы исполнения
работ, и процессы завершения, т. е. процессы контроля интегрируются со всеми группами
процессов управления проектами. Результатом процессов контроля могут быть решения,
управляющие воздействия на планирование, изменение хода проектных работ, процедуры
закрытия проекта.
82
Процессы завершения формализуют приемку разработанной ИС. При успешном
завершении приемки ИС осуществляется закрытие проекта (включая финансовое и
организационное закрытие проекта).
Не все процессы могут понадобиться в каждом конкретном выполняемом проекте
или его фазе, и не все взаимодействия могут быть к ним применимы.
83
84
Рис. 4.2. Общая схема управления интеграцией проекта
1. Устав проекта
2. Определение проекта
3. План проекта
Устав проекта
Устав проекта (Project Charter) является официальной авторизацией проекта и
разрабатывается Руководителем проекта с привлечением членов команды управления
проектом со стороны Исполнителя. Устав проекта согласовывается с командой управления
85
проектом со стороны Заказчика и утверждается Спонсорами проекта как со стороны
Исполнителя, так и со стороны Заказчика.
Процесс разработки Устава проекта относится к группе процессов Инициация и
осуществляется в фазе (на этапе) проекта внедрения ИС, которая имеет свое специфическое
название в каждой методологии внедрения ИС, например, «Предварительное определение
проекта», «Определение проекта» — методология внедрения продуктов Microsoft,
«Концепция» — методология внедрения ASUP.
Исходными документами для разработки Устава проекта внедрения ИС являются
контракт и результаты предпроектного обследования, определяющие содержание работ по
проекту. Результаты предпроектного обследования оформляются в виде отчета, включая
описание бизнес-процессов верхнего уровня.
Устав проекта содержит следующую информацию:
1. Название проекта.
2. Бизнес-цели компании или причины возникновения проекта.
Формулировка причины фактически дает ответ на вопрос «Зачем выполняется данный
проект?».
Бизнес-цели компании обязательно учитывают стратегию развития компании,
включая стратегию развития информационных технологий, на которую ориентирован
проект, — например, увеличение капитализации Холдинга и привлечение инвесторов.
3. Цели проекта.
Цели проекта определяют, что должно быть выполнено, и описывают конечный результат
проекта. В Уставе проекта приводится цель проекта как результат, ожидаемый
Заказчиком и полезный для него. Цель формулируется совместно Заказчиком и
Исполнителем.
При формулировании цели руководитель проекта должен контролировать ее
соответствие контракту, в рамках которого будут выполняться работы по проекту.
Формулировка целей должна соответствовать следующим критериям (SMART-
Specific, Measurable, Achievable, Relevant, Time-bound):
Конкретные (Specific) — позволяющие сформировать
расписание проекта;
Измеримые (Measurable) — позволяющие качественно (или
количественно) оценить, что результат получен;
86
Достижимые (Achievable) — принципиально реализуемые
Исполнителем в рамках проекта, с учетом декларируемой помощи со стороны
Заказчика;
Приносящие результат (Relevant) — соответствуют
ожидаемой Заказчиком пользе;
Ограниченные во времени (Time-bound) — реализуемые в
ожидаемые Заказчиком временные рамки проекта.
4. Границы проекта.
Границы проекта определяют в целом то, что включается в проект. Необходимо
явно указывать, что не включается в проект (таблица 4.2), чтобы исключить ситуацию,
когда участник проекта ошибочно считает некоторый продукт, услугу или результат
входящими в проект.
Организационные границы
Определяется, какие подразделения (включая юридических лиц) должны
участвовать в проекте — кто будет использовать и поддерживать ИС, от кого зависит
выработка основных решений по требованиям к ИС. Организационные границы
определяют максимальные границы обследования и область рождения требований к ИС.
Функциональные границы
Указываются бизнес-направления, бизнес-процессы, которые будут покрываться
ИС. Данным пунктом определяются модули ERP-систем.
87
Географические границы
Указываются территориально удаленные объекты, подлежащие автоматизации.
89
могут совпадать или иметь разные значения. В Уставе приводятся основные вехи
проекта. Вехи, указанные в Уставе проекта, будут контролироваться Заказчиком и должны
жестко соблюдаться. Необходимо оценивать влияние всех изменений в проекте на
соблюдение сроков по данным вехам. Примеры контрольных событий-вех проекта
приведены в таблице 4.3.
90
возможность осуществления контроля по учету и движению объектов
ОС.
В части Управления Персоналом:
возможность ведения и оперативного получения согласованных
данных по численности, составу и движению персонала в каждой дочерней
компании Холдинга и в целом по Холдингу, возможность получения полной
информации по любому сотруднику компании (включая сведения об образовании,
квалификации, родственниках, поощрениях и дисциплинарных нарушениях,
историю работы на предприятии и т. п.);
возможность ведения штатного расписания в каждой дочерней
компании и в целом по Холдингу;
возможность ведения табелей учета рабочего времени;
возможность получения отчетности РФ, отраслевой, отчетности
Головной компании Холдинга.
В части Учета затрат:
автоматизация процесса расчета себестоимости работ;
возможность анализа данных о нормативной и фактической
себестоимости работ.
91
детализацию того, что необходимо сделать для достижения цели и какая методология
будет использована при внедрении ИС. Согласно PMBOK [4.1], процесс разработки
предварительного описания содержания проекта описывает и документирует
характеристики и границы проекта и связанные с ним продукты и услуги, а также методы
приемки и управление содержанием. Описание содержания проекта включает в себя:
цели проекта и продукта;
требования к продукту или услуге и характеристики таковых;
критерии приемки продукта;
границы проекта;
требования и результаты проекта;
ограничения проекта;
допущения проекта;
первоначальную организацию проекта;
первоначально сформулированные риски;
контрольные события (вехи) расписания;
первоначальную иерархическую структуру работ (ИСР);
смету расходов с указанием порядка величин;
требования к управлению конфигурацией проекта;
требования к одобрению.
Предварительное описание содержания проекта разрабатывается на основе Устава
проекта и информации, предоставляемой Инициатором или Спонсором проекта. Команда
управления проектом в рамках процесса определения содержания проекта производит
дальнейшую доработку предварительного описания содержания проекта до получения
окончательного варианта. Содержание этого документа будет изменяться в зависимости от
сложности проекта и может включать в себя некоторые или все из вышеуказанных
элементов. В последующих фазах многофазных проектов в процессе разработки
предварительного описания ратифицируется и дорабатывается содержание проекта,
сформулированное для данной фазы.
93
связан с процессом «Подтверждение содержания» и процессами группы мониторинга и
управления документами «Отчетность по исполнению» и «Руководство и управление
исполнением проекта».
Управление содержанием проекта должно быть так интегрировано в остальные
процессы и области знаний, чтобы результатом проектной работы стало создание
информационной системы необходимого содержания.
На рис. 4.4 представлена схема взаимосвязи процессов управления содержанием
проекта.
94
Устав План
Предварительное управления
описание содержания
проекта
Планирование проектом
Определение
содержания Запрошенные
изменения
Описание содержания
проекта
План управления
содержанием проекта
(обновленный) Одобренные
запросы на
изменение
Создание
ИСР Запрошенные
изменения
Описание содержания
проекта (обновленное)
ИСР
Словарь ИСР
План управления
содержанием проекта
(обновленный)
Базовый план по
содержанию
Результаты
поставки
Подтверждение Запрошенные
изменения
содержания Рекомендованные
корректирующие
действия
Принятые
результаты
поставки
Информация об Активы
исполнении
Отчеты об
Управление организационн
ого процесса
исполнении содержанием
Запрошенные изменения
Рекомендованные
корректирующие действия
План управления проектом
(обновленный)
Описание содержания
проекта (обновленное)
ИСР (обновление)
Словарь ИСР (обновление)
Базовый план по
содержанию
95
Рассмотрим, что происходит внутри каждого процесса управления содержанием.
Планирование содержания
Процесс «Планирование содержания» выполняет разработку и документирование
плана управления содержанием проекта. Как показано на рис. 4.4, исходными данными для
процесса планирования являются Устав проекта, Предварительное содержание описания
проекта и План управления проектом, а также факторы внешней среды и организационные
активы. С помощью экспертной оценки и опыта аналогичных проектов, а также шаблонов
планов управления содержанием и шаблонов иерархической структуры работ (ИСР),
формируется План управления содержанием проекта.
Согласно PMBOK [4.1], План управления содержанием проекта (Project Scope
Management Plan) — это документ, описывающий, как будут определяться,
разрабатываться и проверяться работы, которые необходимо выполнить для получения
результата с указанными характеристиками, и задающий действия по управлению
содержанием проекта.
План управления содержанием проекта является инструментом планирования,
описывающим, как проектная команда будет формулировать содержание проекта,
разрабатывать подробное описание содержания проекта, определять и разрабатывать
иерархическую структуру работ, проверять и контролировать содержание проекта. Разработка
плана управления содержанием и детализация содержания проекта начинаются с анализа
информации, содержащейся в Уставе проекта, предварительном описании содержания проекта,
последней одобренной редакции плана управления проектом, и информации, которая
находится в активах организационного процесса и факторов внешней среды предприятия.
План управления содержанием проекта должен содержать описание следующих
процессов:
подготовки подробного описания содержания проекта на основе
предварительного описания содержания проекта,
создания ИСР на основе подробного описания содержания проекта и
определения способов поддержания и одобрения ИСР,
определения формальной процедуры верификации и приемки
завершенных результатов поставки проекта,
96
контроля обработки запросов на изменения в подробном описании
содержания проекта. (Этот процесс непосредственно связан с процессом общего
управления изменениями.)
План управления содержанием проекта может быть обобщенным или подробным, в
зависимости от потребностей проекта.
97
Составление
целевого
плана
Подготовка
выборки Разработка
Зачем сотрудничать? рекомендаций
Когда для обсуждения
взаимодействовать?
Как использовать? С кем общаться?
Где находиться?
Сколько доверенных Какая информация?
лиц? У кого спросить? Определение
Значимая информация? состава
команды
Кто?
Хватит ли времени?
Необходимо ли
обучение?
Общение с
Заказчиком
Продумана ли логистика?
Обработка Уведомлен ли Заказчик?
информации Состоялось ли встреча с
Заказчиком?
Собраны данные?
Встраивание Отчет написан?
информации в Опыт зафиксирован?
границы
Факторы ценности?
Усвоено?
Факторы в границах?
98
проекта есть свои атрибуты: название (например, стоимость), единица измерения
(например, доллар США) и абсолютное или относительное значение (например, не более
1,5 млн долларов).
Определение содержания продукта. Описывает характеристики информационной
системы, которые становятся более подробными на поздних фазах проекта по мере
постепенного уточнения характеристик ИС.
Требования к информационной системе. Отражают суммарный результат анализа
потребностей пользователей ИС, пожеланий и ожиданий всех участников проекта, который
преобразуется в перечень требований. В случае, когда имеется слишком много требований
и все их выполнить в рамках проекта невозможно, необходимо выстроить перечень
требований по приоритетам. Требования к проекту в целях обеспечения их четкого
понимания со стороны руководителей и проектной команды уточняются и подтверждаются
до начала работ.
Границы проекта. Определяют в целом то, что включается в проект, и явно
указывают, что в него не входит, чтобы исключить ситуацию, когда участник проекта
ошибочно считает некоторый результат, услугу или результат входящими в проект. При
определении границ проекта необходимо привлекать к работе системного архитектора,
консультантов по внедряемой ИС. Как показывает практика, наиболее «узким местом» в
определении границ проекта по разработке и внедрению ИС являются разрабатываемые
формы отчетов. Если в содержании проекта указать «Разработать отчеты» и не задать в
качестве границ проекта количество разрабатываемых отчетов, их наименования, то проект
может быть никогда не закончен: у Заказчика может возникать необходимость в получении
все новых и новых отчетов. Необходимо задокументировать все решения, связанные с
границами проекта.
Результаты поставки проекта. Результаты поставки включают в себя
информационную систему, разработанную в ходе проекта, а также отчеты и документацию
по управлению проектом.
99
Испытания ИС должны быть проведены на основании соответствующих программ и
методик испытаний.
Ограничения проекта. Перечисляет и описывает ограничения проекта, связанные с
его содержанием и ограничивающие возможность выбора для команды проекта. К ним
относятся, например, утвержденный предварительный бюджет или требуемые даты
(контрольные события расписания), установленные заказчиком или исполняющей
организацией. Когда проект выполняется по контракту, то в качестве ограничений обычно
выступают условия контракта. Ограничения, перечисляемые в подробном описании
содержания проекта, традиционно более многочисленны и детализированы по сравнению с
перечисляемыми в Уставе проекта.
Допущения проекта. Перечисляет и описывает допущения проекта, связанные с его
содержанием, и потенциальный эффект этих допущений в случае, если они окажутся
ложными. Команда проекта периодически идентифицирует, документирует и утверждает
допущения в рамках процесса планирования. Допущения, перечисляемые в подробном
описании содержания проекта, обычно более многочисленны и описываются подробнее,
чем допущения, перечисленные в Уставе проекта и предварительном описании содержания
проекта.
Первоначальная организация проекта. На этом этапе определяются члены
команды проекта и участники проекта, а также документально фиксируется
организационная структура проекта.
Изначально сформулированные риски. Перечисляются известные риски.
Контрольные события расписания. Заказчик или исполняющая организация могут
задать контрольные события и требуемые даты их выполнения. Эти даты могут быть
обозначены в качестве ограничений на сроки.
Ограничение финансирования. Описывает все ограничения, наложенные на
финансирование проекта, как на уровне его общей стоимости, так и в указанных временных
рамках.
Сметная стоимость. Сметная стоимость проекта представляет собой ожидаемую
общую стоимость проекта, и перед ней обычно ставится модификатор, указывающий на
точность, концептуальную или окончательную.
Требования к управлению конфигурацией проекта. Описывают уровень
управления конфигурацией и изменениями, реализуемыми в проекте.
100
Спецификации проекта. Определяют спецификации, которым должен
соответствовать проект.
Требования к одобрению. Определяют требования к одобрению, применяющиеся к
таким элементам, как цели проекта, результаты поставки проекта, документы и работа.
План управления содержанием проекта (обновления)
Эта составляющая плана управления проектом может потребовать обновления, а
именно включения одобренных запросов на изменение в результате процесса определения
содержания.
Запрошенные изменения
В ходе процесса определения содержания могут вырабатываться запрошенные
изменения, затрагивающие план управления проектом и его вспомогательные планы.
Запрошенные изменения обрабатываются в рамках процесса общего управления
изменениями.
Одним из основных моментов при определении содержания проекта является
обеспечение максимальной устойчивости (сопротивляемости) к изменениям.
Рекомендуется строить разработку содержания проекта по следующим принципам [4.3]:
снижение сложности проекта путем деления на более мелкие подпроекты, для
каждого из которых разрабатывается свое содержание;
создание устойчивых продуктов/услуг, способных функционировать в
широком диапазоне условий;
фиксирование содержания на ранних этапах жизненного цикла проекта.
101
Шаблоны иерархической структуры работ
Несмотря на уникальность каждого проекта, ИСР предыдущего проекта часто может
служить шаблоном для нового проекта. Например, большая часть проектов внедрения ИС в
конкретной организации будет иметь одинаковые жизненные циклы, а потому и
одинаковые или схожие результаты каждой фазы.
Стандарт Института управления проектами (PMI) для иерархической структуры
работ содержит руководство по созданию, доработке и применению иерархических
структур работ. В это руководство включены примеры шаблонов ИСР, которые можно
адаптировать под конкретные проекты в конкретной области приложения. На рис. 6
показана часть шаблона ИСР с несколькими ответвлениями, разбитыми до уровня пакетов
работ.
102
Декомпозиция
Декомпозиция — это инструмент, позволяющий выполнить разделение
результатов поставки проекта на более мелкие, более управляемые элементы. Каждый
следующий уровень иерархии более детально отражает элементы проекта. Декомпозиция
выполняется до тех пор, пока работа и результаты поставки не определяются на уровне
пакетов работ. Пакеты работ — это низшей уровень детализации, который менеджер
проекта должен держать под своим непосредственным контролем. Далее пакеты работ
могут разбиваться на операции, которые потом могут быть разбиты на задания. Уровень
детализации будет варьироваться в зависимости от размера и сложности проекта. У разных
результатов поставки могут быть разные уровни декомпозиции.
Чрезмерная декомпозиция может привести к непродуктивной управленческой
трудоемкости, неэффективному использованию ресурсов и снижению эффективности при
выполнении работы. Команда проекта должна найти баланс между слишком малой и
слишком большой детализацией планирования ИСР.
Декомпозиция всей совокупности проектных работ включает следующие операции:
1. Определение результатов поставки и работ для их достижения, получаемых
путем анализа подробного описания работ по проекту. Список работ определяется путем
экспертной оценки результатов поставки.
2. Структурирование и организация ИСР — метод анализа, использующий
шаблоны ИСР, структурирует результаты поставки и соответствующие проектные работы
и представляет их в виде иерархической структуры. В зависимости от выбранного
шаблона в итоге может получиться несколько разных видов структуры. В шаблонах в
качестве первого уровня декомпозиции могут быть использованы подпроекты и основные
результаты поставки (рис. 4.6) или фазы жизненного цикла проекта (рис. 4.7).
3. Разбиение верхних уровней ИСР на детализированные элементы нижних
уровней.
4. Разработка и присвоение идентификационных кодов элементам ИСР.
Проверка необходимости и достаточности степени декомпозиции работ,
удовлетворяющей требованиям команды проекта к управлению и контролю,
является методом анализа, который можно выполнять с использованием шаблона ИСР. При
проверке корректности декомпозиции определяется, являются ли элементы ИСР нижнего
уровня необходимыми и достаточными для достижения соответствующих результатов
поставки на более высоких уровнях.
103
Системный подход к составлению ИСР
По оценкам экспертов [4.2], путем декомпозиции определяется примерно 90% от
общего объема работ. Системный подход позволяет увеличить точность декомпозиции.
В соответствии с теорией управления системами вся работа рассматривается как
система, в которой работа является процессом превращения входных элементов в
выходные. Исходя из этого, проект внедрения может быть описан как процесс превращения
входных элементов (ресурсов, трудозатрат и пр.) в выходные элементы, в нашем случае —
в результаты поставки. Согласно теории управления системами, каждая задача нижнего
уровня является процессом, превращающим входные элементы в выходные. Входом
каждой задачи являются результаты другой части проекта или данные из источника,
внешнего к проекту. Выходные элементы также должны быть входом в другие задачи или
результатом поставки проекта. Каждый участник команды должен просмотреть созданную
ИСР и проанализировать входы и выходы работы, за которую он отвечает. Все входные
элементы должны исходить либо от других работ проекта, либо от внешнего источника.
Аналогично, выходы должны быть либо результатом поставки, либо входом в другие
работы. Такой просмотр позволит выделить лишние работы, выходы которых не
используются в проекте, добавить недостающие и исключить дублирующие работы.
104
Выходные документы процесса создания ИСР
105
В процессе создания ИСР могут появляться запрошенные изменения описания
содержания проекта и его элементов, обрабатываемые в рамках процесса общего
управления изменениями.
Подтверждение содержания
Процесс подтверждения содержания формализует принятие завершенных
результатов поставки проекта. Подтверждение содержания — это формальное принятие
участниками проекта завершенного содержания проекта и относящихся к нему результатов
поставки. Процесс подтверждения содержания проекта включает в себя проверку наличия
всех работ, обеспечивающих результаты поставки. Если выполнение проекта прекращается
досрочно, процесс подтверждения содержания должен установить и документировать
уровень и степень его выполнения.
Входной информацией процесса являются:
описание содержания проекта;
словарь ИСР;
план управления содержанием проекта;
результаты поставки.
Подтверждение содержания выполняется методом инспекции, который включает в
себя такие операции, как измерение, изучение и проверка, и служит для определения
соответствия работ результатам поставки, требованиям и критериям приемки продукта.
(Иногда метод инспекции называют аудитом, проверкой, контролем.)
Процесс подтверждения содержания имеет нижеследующие результаты.
Принятые результаты поставки. Процесс подтверждения содержания
документирует результаты поставки, которые прошли приемку. Непринятые результаты
поставки документируются с указанием причин, по которым они не прошли приемку.
Подтверждение содержания включает в себя сопроводительную документацию,
полученную от Заказчика или Спонсора и подтверждающую факт приемки результатов
поставки участниками проекта.
Запрошенные изменения. Запрошенные изменения могут появиться в ходе
процесса подтверждения содержания и рассматриваются в ходе процесса общего
управления изменениями.
106
Рекомендуемые корректирующие действия. Корректирующие действия — это
документированные рекомендации, необходимые для приведения ожидаемого хода
исполнения проекта в соответствие с планом управления проектом.
107
определяет процедуры, посредством которых могут быть изменены содержание проекта и
содержание продукта. Эта система включает в себя документацию, системы отслеживания
и уровни одобрения, необходимые для одобрения изменений. Для контроля содержания
проекта система управления изменениями содержания интегрируется с любой
информационной системой общего управления проектом.
Анализ отклонений. Для оценки величины отклонений используются измерения
эффективности проекта. Важные аспекты контроля содержания проекта включают в себя
определение причины отклонений по сравнению с базовым планом по содержанию и
принятие решения о необходимости корректирующих действий.
Корректировка планов. Одобренные запросы на изменения, оказывающие влияние
на содержание проекта, могут повлиять на ИСР и словарь ИСР, описание содержания
проекта и план управления содержанием проекта. Эти одобренные запросы на изменения
могут потребовать обновления компонентов плана управления проектом.
Система управления конфигурацией. Формальная система управления
конфигурацией определяет процедуры для каждого состояния результатов поставки. Ее
целью является обеспечение надлежащего рассмотрения и фиксации запрошенных
изменений содержания проекта, перед тем как они будут обработаны в рамках процесса
общего управления изменениями.
Выходы процесса
Описание содержания проекта (обновления). Если одобренные запросы на
изменения влияют на содержание проекта, то описание содержания проекта редактируется,
и в новую редакцию включаются эти одобренные изменения. Обновленное описание
содержания проекта становится новым базовым планом проекта для будущих изменений.
Иерархическая структура работ (обновления). Если одобренные запросы на
изменения влияют на содержание проекта, то ИСР редактируется и в новую редакцию
включаются эти одобренные изменения.
Словарь ИСР (обновления). Если одобренные запросы на изменения влияют на
содержание проекта, то словарь ИСР редактируется и в новую редакцию включаются эти
одобренные изменения.
Базовый план по содержанию (обновления)
Запрошенные изменения. В результате управления содержанием проекта могут
появляться запрошенные изменения, обрабатываемые для рассмотрения и распоряжения в
соответствии с процессом общего управления изменениями.
108
Рекомендуемые корректирующие действия. Рекомендуемое корректирующее
действие представляет собой любой рекомендованный шаг в целях приведения ожидаемой
будущей эффективности проекта в соответствие с планом управления проектом и
описанием содержания проекта.
Активы организационного процесса (обновления). Причины отклонений, логика
выбора конкретного корректирующего действия и прочие виды накопленных знаний из
системы управления изменениями содержания проекта документируются и обновляются в
исторической базе данных активов организационного процесса.
План управления проектом (обновления). Если одобренные запросы на
изменения каким-либо образом затрагивают содержание проекта, то создается новая
редакция документов и базового плана по стоимости для соответствующего элемента, а
также базовых планов по стоимости, входящих в план управления проектом. В новую
редакцию включаются эти одобренные изменения.
109
Лекция 5. УПРАВЛЕНИЕ СРОКАМИ ПРОЕКТА
110
Управление расписанием — процесс управления изменениями расписания
проекта.
Первые пять процессов относятся к группе процессов планирования, шестой — к
группе процессов мониторинга и управления. Процессы взаимодействуют как между
собой, так и с процессами из других областей знаний.
Процессам управления сроками проекта предшествует процесс планирования,
определяющий формат и критерии разработки и контроля расписания проекта,
управления проектом, в ходе которого разрабатывается план управления расписанием.
План управления расписанием входит в план управления проектом, либо является его
вспомогательным планом.
На рис. 5.1 показана последовательность процессов, приводящая к разработке
расписания проекта и затем к управлению расписанием. Разработка расписания проекта
начинается с определения состава операций. После того как операции определены, между
ними устанавливаются взаимосвязи. Чтобы определить длительность операций, следует
назначить специалистов, которые будут выполнять операции, — уровень их квалификации
имеет определяющее значение. Рассмотрим подробнее, каким образом определяются
операции проекта, их взаимосвязи, требуемые ресурсы, длительность операций, как
составляется расписание проекта и осуществляется управление им.
111
Методология
внедрения ИС Запрошенные
Контракт изменения
Описание содержания
проекта Определение состава
ИСР
Словарь ИСР операций План управления проектом
План управления
содержанием проекта
Список операций Одобренные запросы на
Параметры операций изменения
Список контрольных Одобренные корректирующие
событий действия
Сетевые диаграммы
расписания проекта
Список операций
(обновления)
Параметры операций Одобренные
(обновления) запросы на
изменение
Наличие ресурсов
Экспертная оценка Оценка длительности Запрошенные
длительности изменения
операций
операций Рекомендованные
Реестр рисков корректирующие
действия
Оценка
длительности
операций
Расписание проекта
Базовый план
Отчеты об расписания
исполнении Требования к ресурсам
План управления (обновления) Список операций (обновления)
расписанием Календарь проекта Параметры операций (обновления)
проекта(обновления) План управления проектом
(обновления)
Расписание проекта (обновления)
Базовый план Управление Базовый план расписания
расписания (обновления)
Одобренные расписанием Запрошенные изменения
запросы на Рекомендованные
изменения корректирующие действия
113
Инструменты и методы
Для определения состава операций используют следующие инструменты и
методы:
декомпозиция;
шаблоны;
планирование методом набегающей волны;
экспертная оценка.
Выходы процесса определения состава операций
Процесс определения состава операций завершается формированием
нижеследующих документов [4.1].
Список операций — перечень работ, запланированных для выполнения.
Параметры операций — могут включать в себя идентификатор операции, коды
операции, длительность, начало, окончание, исполнителя операции, перечни
предшествующих и последующих операций, логические взаимосвязи, опережения и
задержки, плановую трудоемкость работ и другие необходимые для управления проектом
параметры операций.
Список контрольных событий (вех проекта) — определяет все контрольные
события расписания, необходимые для мониторинга хода выполнения и для управления
проектом. Список контрольных событий является элементом плана управления проектом.
Веха проекта определяет момент перехода проекта из одного состояния в другое. Важным
отличием вех от операций проекта является то, что они не имеют длительности.
Запрошенные изменения — изменения в составе работ, которые могут появиться в
ходе выполнения работ по внедрению ИС и повлиять на описание содержания проекта.
Примеры состава операций и контрольных событий (вех проекта) представлены в
таблицах 5.1. и 5.2.
114
Наименовани Наименование операций
е пакета работ
Описание бизнес-процессов по функциональной области Финансы.
Описание Описание бизнес-процессов по функциональной области
бизнес- Логистика.
процессов Описание бизнес-процессов по функциональной области Персонал
115
Таблица 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
Работа А Работа В
Работа А
Работа В
Работа А
Работа В
Работа А
Работа В
Работа А Работа С
Работа В
120
Определение зависимостей. Для определения последовательности операций
используется три типа зависимостей.
Жесткая или обязательная зависимость — зависимость, при которой
последовательность работ не может изменяться. Обязательные зависимости
являются неотъемлемым свойством выполняемой работы и часто подразумевают
физические ограничения на последовательность выполнения операций.
Нежесткая или произвольная зависимость — последовательность
определяется командой проекта и может изменяться.
Внешняя зависимость — последовательность работ определяется внешними
по отношению к проекту воздействиями. Внешние зависимости включают
взаимоотношения операций проекта с непроектными операциями. Например, в
проекте по разработке программного обеспечения сроки операции тестирования
могут зависеть от поставки аппаратного обеспечения сторонней организацией.
Применение опережений и задержек. Опережения и задержки представляют
собой интервалы времени, которые модифицируют взаимосвязи между предшествующими
и последующими операциями. Опережения и задержки обозначаются знаками плюс (для
задержки) и минус (для опережения) перед количеством периодов времени. На рис. 5.4
представлено графическое изображение операции с задержкой — работа Б начнется через
5 дней после окончания работы.
121
приступить к подготовке тестовых данных до момента полного завершения разработки
сценариев тестирования, т. е. начать работу с опережением. Например, за 5 дней до
завершения разработки сценариев тестирования уже будет достаточно материала, чтобы
начать подготовку тестовых данных.
Выходы процесса определения взаимосвязи операций
Сетевые диаграммы расписания проекта — схематическое отображение
плановых операций проекта и логических взаимосвязей (зависимостей) между ними.
Сетевая диаграмма расписания проекта может быть построена вручную или при помощи
программного обеспечения для управления проектом, например, Spider или MS Project. Она
может включать в себя полную детализацию проекта или одну или несколько суммарных
операций (пакет операций). На рис. 5.5 приведен пример представления расписания
проекта в виде диаграммы Гантта MS Project.
Список операций (обновления). Если одобренные запросы на изменения являются
результатом процесса определения взаимосвязей операций, то создается обновленный
список операций, включающий в себя эти изменения.
Параметры операции (обновления). Если одобренные запросы на изменения,
являющиеся результатом процесса определения взаимосвязей между операциями,
оказывают влияние на список операций, то в соответствующие элементы параметров
операций включаются эти одобренные изменения (логические взаимосвязи и
соответствующие опережения и задержки).
Запрошенные изменения. При разработке логических взаимосвязей, опережений и
задержек проекта могут быть выявлены моменты, которые повлекут за собой запрос на
изменение списка операций или параметров операций. Запрошенные изменения
рассматриваются и утверждаются в рамках процесса общего управления изменениями.
122
Рис. 5.5. Фрагмент расписания проекта в виде диаграммы Гантта MS Project
123
использования в оценке ресурсов, необходимых для каждой плановой
операции в списке операций;
Наличие ресурсов. Для оценки типов ресурсов используется информация о
том, какие ресурсы (функциональные консультанты, бизнес-аналитики,
серверы и т. п.) потенциально доступны;
План управления проектом. План управления расписанием является
составляющей частью плана управления проектом и используется в оценке
ресурсов операций.
Инструменты и методы
Инструменты и методы, используемые при оценке ресурсов операций:
Экспертная оценка — часто необходима для того, чтобы оценить ресурсные
входы этого процесса. Такую оценку может дать экспертная группа, имеющая
специальную подготовку в области планирования и оценки ресурсов;
Программное обеспечение для управления проектами — помогает
планировать, организовывать фонды ресурсов и управлять ими, а также
разрабатывать оценки ресурсов. В зависимости от сложности программного
обеспечения можно определять иерархические структуры ресурсов, наличие
ресурсов и их текущую стоимость, а также различные календари ресурсов;
Оценка «снизу вверх».
Когда плановую операцию нельзя оценить с достаточной степенью
уверенности, то работы в пределах такой операции разбиваются на более мелкие
элементы. Ресурсные потребности каждого более детализированного элемента работ
оцениваются, и эти оценки объединяются в общее количество по каждому ресурсу
плановой операции. Плановые операции могут быть связаны отношениями
зависимости, которые могут влиять на привлечение и использование ресурсов, но
могут и не иметь такой связи. Если отношений зависимости нет, то эта специфика
применения ресурсов отражается в оценочных требованиях плановой операции и
фиксируется документально.
Выходы процесса оценки ресурсов операций
Результатом процесса оценки ресурсов операций является следующая информация.
Требования к ресурсам операции. Выход процесса оценки ресурсов операций
представляет собой определение и описание типов и количества ресурсов, необходимых
124
для каждой плановой операции в пакете работ. Эти требования можно затем собрать в
единое целое для определения оценочных ресурсов по каждому пакету работ. Детализация
и уровень специфичности требований к ресурсам могут варьироваться в зависимости от
области приложения. В документацию по требованиям к ресурсам для каждой плановой
операции может входить оценочная база для каждого ресурса, а также допущения по типам
ресурсов, их наличию и количеству. Процесс разработки расписания определяет
потребность в тех или иных ресурсах. На рис. 5.6 представлен фрагмент таблицы
«Ресурсы», содержащей следующие параметры: название ресурса, его код, количество,
стоимостную оценку (фактическую и плановую), длительность и др.
125
ресурса. Календарь ресурсов проекта назначает количество каждого доступного ресурса по
каждому периоду доступности.
126
Рис. 5.8. Диаграмма Гантта с привязкой к ресурсам
127
аналитиками по группам автоматизируемых бизнес-процессов, и тогда длительность
плановой операции будет меньше той, где тот же объем работы выполнял бы один человек.
Аналогично, за тестировщиками можно закрепить отдельные модули системы или группы
бизнес-процессов и тем самым сократить время плановых операций по тестированию.
Календарь ресурсов — выход процесса оценки ресурсов операций.
План управления проектом включает в себя реестр рисков и проектные сметы. Реестр
рисков содержит информацию об идентифицированных рисках проекта, рассматриваемых
командой проекта при подготовке оценок длительности операций и ее корректировке с
учетом рисков. Оценка стоимости проектных операций показывает расчетные объемы
ресурсов по каждой плановой операции.
Инструменты и методы
129
Разработка расписания
130
вспомогательных элементов, необходимых в процессе разработки расписания, одним из
которых является реестр рисков. Реестр рисков содержит риски проекта и
соответствующие мероприятия по реагированию на риски, необходимые для обслуживания
процесса разработки расписания.
Инструменты и методы
Анализ сети расписания представляет собой технологию создания расписания
проекта и выполняется с помощью модели расписания. Существуют различные методы
анализа: метод критического пути, метод критической цепи, анализ возможных сценариев
и выравнивание ресурсов для расчета дат раннего и позднего старта и финиша и расчетных
дат начала и завершения для незавершенных частей плановых операций проекта.
Метод критического пути — метод анализа сети расписания, проводимого при
помощи модели расписания. При методе критического пути рассчитываются
теоретические даты раннего старта и раннего финиша и позднего старта и позднего
финиша для всех плановых операций без учета ограничений по ресурсам. Этот расчет
производится путем проведения анализа прямого и обратного проходов по путям сети
расписания проекта. Полученные даты раннего и позднего старта и финиша показывают
периоды времени, в пределах которых следует планировать данную операцию, исходя из ее
длительности, логических взаимосвязей, опережений, задержек и прочих ограничений.
Ранний старт (в методе критического пути) — самый ранний из возможных
моментов времени, в который могут начаться плановые операции проекта. Ранний финиш
— самый ранний из возможных моментов времени, в который могут завершиться плановые
операции проекта. Ранний старт и ранний финиш вычисляются на основании логики сети
расписания, отчетной даты и любых ограничений на расписание и могут меняться по ходу
исполнения проекта и внесения изменений в план управления проектом.
Поздний старт — самый поздний момент времени, в который может быть начата
плановая операция, определяемый на основании логики сети расписания, даты завершения
проекта и любых ограничений в отношении плановых операций без нарушения
ограничений на график или отсрочки даты завершения проекта. Поздний финиш — самый
поздний момент времени, в который может быть завершена плановая операция. Поздний
старт и поздний финиш определяются с помощью Обратного прохода в сети расписания
проекта.
Прямой проход — вычисление ранних сроков начала и завершения
невыполненных частей всех операций. Обратный проход — определение позднего
131
финиша и позднего старта незавершенных частей всех плановых операций.
Определяется в результате расчета проекта от даты завершения проекта к началу на
основании логики сети расписания. Дата завершения определяется в результате прямого
прохода или задается Заказчиком или Спонсором проекта.
Даты раннего старта и раннего финиша и позднего старта и позднего финиша могут
не совпадать. Разность между ранними и поздними датами называется временным
резервом. У критических путей общий временной резерв равен нулю, а плановые
операции на критическом пути называются «критическими операциями». Если временной
резерв имеет отрицательное значение, то могут потребоваться корректировки длительности
операций, логических взаимосвязей, опережений, задержек и прочих ограничений.
Гибкость расписания определяет «свободный временной резерв» — количество времени,
на которое плановая операция может быть отложена, не вызывая задержки раннего
старта непосредственно примыкающей последующей операции на данном сетевом
пути.
Критический путь — это группа операций, которые не могут быть задержаны
без задержки даты завершения всего проекта, или последовательность операций,
имеющих нулевой временной резерв [4.2].
Рассмотрим пример построения сетевой модели и определения критического пути.
Требуется составить сетевую модель по заданной технологии выполнения работ
проекта, приведенных в таблице 5.3. Необходимо определить резервы работ и критический
путь проекта. Работы выполняются каждый день, без учета выходных, с возможностью
привлечения необходимых ресурсов. Считаем датой начала проекта 1.01.08.
132
7 5 8 12
8 7,6 - 5
В таблице 5.3 указано, что у работ 1 и 2 нет предшествующих работ, после работы
№ 1 должны следовать работы 3 и 4, за работой № 2 должна следовать работа 5 и т. д.
Работа 8 является завершающей, по данным таблицы 5.2 у нее нет последующих работ.
Сетевая модель, соответствующая рассматриваемой технологии выполнения работ,
представлена на рис. 5.9.
6
1
2
5 7
Построим таблицу, в которой для каждой операции отведены по две строки. Первые
строчки каждой операции отмечают интервал выполнения операции при прямом проходе,
вторые — при обратном. Даты начала и завершения каждой операции при прямом
проходе определяются на основании логики сети расписания (рис. 5.9) и данных о
продолжительности операций (таблица 5.3). Дата завершения получается в результате
прямого прохода. При обратном проходе даты начала и конца операций определяются в
результате расчета проекта от даты завершения проекта к началу также с использованием
логики сети расписания и данных о продолжительности операций (таблица 5.3).
133
Таблица 5.4. Временные интервалы выполнения операций при прямом и обратном
проходах
№
Даты выполнения операций
операции
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
134
Используя даты прямого и обратного проходов таблицы 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 имеют временной резерв, равный нулю, и представляют
критический путь данного примера.
Сжатие расписания. При составлении расписания могут возникнуть ситуации, когда
дата окончания проекта по расписанию будет более поздней, чем дата завершения проекта,
утвержденная Заказчиком, или, наоборот, более ранней. В этом случае применяют сжатие
расписания. Сжатие расписания укорачивает расписание проекта без изменения содержания
проекта, с сохранением ограничения на сроки, требуемые даты или иные цели, указанные в
расписании. Методы сжатия расписания: сжатие и быстрый проход.
При методе сжатия выполняется анализ компромиссов стоимости и сроков для
определения возможности максимально сжать сроки при минимальных дополнительных
затратах. Сжатие не всегда позволяет получить приемлемое решение и может привести к
увеличению стоимости проекта. Быстрый проход — частный случай сжатия расписания.
При быстром проходе операции, обычно выполняемые последовательно, проводятся с
135
некоторым перекрытием или параллельно. Быстрый проход может привести к доработкам и
возрастанию риска.
Анализ возможных сценариев — анализ, в основе которого лежит рассмотрение
вопросов типа «Что произойдет, если ситуация будет развиваться по сценарию Х?» В этом
случае выполняется анализ сети расписания, при котором с помощью модели расписания
просчитываются различные сценарии (например, задержка поставки или увеличение
длительности отдельных операций) или моделируется воздействие непредвиденных внешних
факторов. Результаты анализа возможных сценариев могут использоваться для оценки
выполнимости расписания при неблагоприятных условиях и для составления резервных
планов.
Выравнивание ресурсов — метод анализа сети расписания, который применяется к
модели расписания, проанализированной методом критического пути [4.2]. Выравнивание
ресурсов используется для выявления плановых операций, которые необходимо выполнить,
чтобы уложиться в указанные сроки. Выравнивание ресурсов удобно проводить с помощью
компьютерных программ составления расписаний, используя гистограммы ресурсов.
Гистограмма ресурсов создается на разделенном экране — в верхней части отображается
диаграмма Гантта, где изображены операции, использующие ресурсы, представленные в
нижней части экрана в виде столбиковой диаграммы. Диаграммы используют одинаковую
шкалу времени.
136
Рис. 5.11. Перераспределение ресурсов
На рис. 5.10 видно, что в течение двух первых недель использованы не все ресурсы, а
на пятой и шестой неделе наблюдается их перерасход, то есть люди должны будут работать
сверхурочно по 20 часов в неделю в течение 2-х недель.
После анализа внесем в расписание следующее изменение: прервем на третьей неделе
выполнение задачи 2 и возобновим его на шестой неделе. Это позволит выравнивать
нагрузку и избежать сверхурочных работ (рис. 5.11).
В результате метода выравнивания ресурсов получается расписание с ограниченными
ресурсами и с расчетными датами начала и завершения проекта.
Программное обеспечение для управления проектами автоматизирует расчет
математического анализа критического пути с прямым и обратным проходом и
выравнивание ресурсов, позволяет оперативно рассмотреть множество альтернативных
вариантов расписания.
Применение календарей. Календари проекта и календари ресурсов определяют
периоды, когда разрешена работа.
Модель расписания создается на основе данных и информации расписания и
используется для выполнения анализа сети расписания.
Выходы процесса разработки расписания
Результатами процесса разработки расписания являются:
137
Расписание проекта. Расписание проекта может быть разработано детально или
укрупнено как расписание контрольных событий. Расписание может быть представлено в
табличном виде или иметь графическое представление в виде сетевых диаграмм,
столбиковых горизонтальных диаграмм или диаграмм контрольных событий. На
столбиковых диаграммах столбики обозначают операции, показывают даты начала и
завершения операций и их ожидаемую длительность. Они легко читаются и часто
используются для представления информации руководству организации. Диаграммы
контрольных событий показывают только запланированные даты начала или завершения
получения основных результатов внедрения ИС и ключевых внешних событий.
Данные для модели расписания. Обязательные данные для расписания проекта
включают в себя контрольные события расписания, плановые операции, параметры
операции и документацию всех имеющихся допущений и ограничений, а дополнительные —
требования к ресурсам по периодам времени, альтернативные расписания, резервы на
непредвиденные обстоятельства.
Базовый план расписания — это особый вариант расписания проекта,
разрабатываемый посредством анализа сети расписания модели расписания, принимается и
утверждается командой управления проектом в качестве первоначального (базового) плана
расписания с указанными базовым стартом и базовым финишем. Базовый план расписания
используют для выявления отклонений фактических сроков выполнения операций от
плановых.
Требования к ресурсам (обновления).
Параметры операции (обновления).
Календарь проекта (обновления). Запрошенные изменения. В процессе
разработки расписания могут появиться запрошенные изменения, которые обрабатываются в
процессе общего управления изменениями.
План управления проектом (обновления). План управления проектом обновляется
с отражением всех одобренных изменений в способах управления расписанием проекта.
При разработке расписания рекомендуется соблюдать следующую
последовательность работ [4.2]:
определить перечень операций, которые должны быть включены в расписание;
определить взаимосвязь операций;
определить длительность каждой операции;
рассчитать с помощью прямого прохода ранее расписание для каждой
операции;
138
рассчитать с помощью обратного прохода позднее расписание для каждой
операции;
вычислить временной резерв для каждой операции;
определить критический путь;
сравнить дату предполагаемого завершения проекта с датой завершения
проекта по обязательству;
подкорректировать расписание или дату завершения проекта по
обязательству, если завершение проекта по расписанию предполагается раньше
этой даты;
определить ограничения на ресурсы;
откорректировать расписание в соответствии с ограничениями на ресурсы;
проверить, не планируется ли завершение проекта по откорректированному
расписанию раньше даты обязательства;
подкорректировать расписание или дату завершения проекта по
обязательству, если завершение проекта по расписанию предполагается раньше
этой даты;
согласовать расписание.
Управление расписанием
139
Отчетность о прогрессе проекта включает в себя фактические даты начала и
завершения и оставшуюся длительность незавершенных плановых операций. При
использовании методики освоенного объема отчетность может содержать процент
выполнения текущих плановых операций. Для упрощения подготовки периодической
отчетности о прогрессе проекта удобно использовать типовые формы — шаблоны. Пример
шаблона отчетной формы представлен на рис. 5.12.
«наименование проекта»
Еженедельный статус-отчет
Отчетный период:___________________
Кому:
От:
Дата:
Работы, проведенные в отчетном периоде
План Ожидае
Планов
овая мая % Комм
ая дата Отклоне
№ Название операции дата дата заверше ентар
оконча ние
начал окончан ния ий
ния
а ия
Наименование пакета операций
1
Наименование пакета операций
2
3
Выводы и предложения
Выводы:
Предложения:
140
Измерение эффективности. Методы измерения эффективности выдают отклонение
по срокам и индекс выполнения сроков, используемые для оценки величины любых
возникающих отклонений от расписания.
Анализ отклонений. Ключевой функцией управления расписанием является
проведение анализа отклонений по срокам. Сравнение директивных дат начала и
выполнения с фактическими/прогнозируемыми дает информацию для осуществления
корректирующих действий в случае задержек.
Сравнительные диаграммы расписания. Для упрощения анализа исполнения
расписания удобно пользоваться сравнительной столбиковой диаграммой, имеющей по два
столбика для каждой плановой операции — текущее состояние и состояние одобренного
базового плана расписания. На диаграмме наглядно отображаются места, где расписание
обгоняет плановое и где отстает от него.
Выходы процесса управления расписанием
Данные для модели расписания (обновления). Одобренные изменения информации
о расписании приводят к построению новых сетевых диаграмм расписания проекта. В
некоторых случаях отставания расписания проекта бывают столь серьезными, что делает
необходимой разработку нового расписания с пересмотренными директивными датами
начала и завершения проекта.
Базовый план расписания (обновления). Корректировка базового плана расписания
может быть произведена в результате одобренных изменений. Перед созданием нового
базового плана расписания во избежание потери исторических данных сохраняются
исходные базовый план расписания и модель расписания.
Измерения эффективности — значения отклонения по срокам и индекса
выполнения сроков, рассчитанные для отдельных элементов ИСР; документально
фиксируются и сообщаются участникам проекта.
Запрошенные изменения в базовом плане проекта могут быть вызваны анализом
отклонений по срокам, проверкой отчетов об исполнении, результатами измерения
эффективности и изменений в модели расписания проекта. Запрошенные изменения
обрабатываются для рассмотрения и утверждения в рамках процесса общего управления
изменениями.
Рекомендуемые корректирующие действия — это любые действия,
осуществляемые для приведения ожидаемого будущего исполнения расписания проекта в
соответствие с одобренным базовым расписанием. Корректирующие действия часто требуют
предварительного анализа первопричины отклонений для выявления плановых операций,
которые на самом деле вызывают отклонение.
141
Активы организационного процесса (обновления) — накопленные знания о
причинах возникновения отклонений, обоснованиях выбранных корректирующих действий
и другие типы накопленных знаний.
Список операций (обновления).
Параметры операций (обновления).
План управления проектом (обновления).
142
Лекция 6. УПРАВЛЕНИЕ СТОИМОСТЬЮ ПРОЕКТА
143
Описание содержания проекта
Иерархическая структура работ Стоимостная оценка Запрошенные изменения
(ИСР) План управления
Факторы внешней среды стоимостью (обновления)
предприятия
Активы организационного
процесса Оценка стоимости операций
План управления расписанием, Вспомогательные данные для оценки
обеспечения персоналом стоимости операций
Риски проекта План управления стоимостью
Запрошенные изменения
Стоимостная оценка
144
выполняется в течение всего времени выполнения проекта. Выделяют следующие оценки
стоимости [6.1]:
оценка порядка величины;
концептуальная оценка;
предварительная оценка;
окончательная оценка;
контрольная оценка.
На предпроектной стадии первоначально может определяться только порядок
величины стоимости. Точность оценки порядка величины стоимости проекта может
колебаться от (-50%) до (+100%). Точность концептуальной оценки находится в интервале (-
30%) — (+50%). Точность предварительной оценки проекта колеблется от (-20%) до (+30%).
На этапе окончательной оценки точность колеблется от (-15%) до (+20%). Контрольная
оценка имеет точность от -10% до +15%. Таким образом, каждая последующая стадия
жизненного цикла проекта имеет более точную стоимостную оценку (рис. 6.2).
-10% - +15%
Контрольная оценка
145
Факторы внешней среды предприятия. К факторам внешней среды относятся
конъюнктура рынка, коммерческие базы данных и прайс-листы. Конъюнктура рынка — это
рынок информационных систем, их конкурентная функциональность, стоимость, услуги на
внедрение, сопровождение. Коммерческие базы данных и прайс-листы содержат сведения о
квалификации и стоимости трудовых ресурсов, стоимости внедрения информационных
систем.
Активы организационного процесса — официальные и неофициальные правила,
процедуры и руководства по стоимостной оценке, шаблоны стоимостной оценки,
информация о стоимости ранее выполненных проектов.
Описание содержания проекта содержит важную информацию о требованиях,
ограничениях и допущениях проекта, которую необходимо учитывать при стоимостной оценке.
Иерархическая структура работ определяет взаимоотношения между всеми
элементами проекта и результатами проекта.
Словарь ИСР содержит подробное описание работы для каждого элемента ИСР.
План управления проектом — общий план мероприятий по исполнению,
мониторингу и контролю над проектом, содержащий указания и руководства по составлению
плана управления стоимостью и контролю за его исполнением, а также дополнительные
планы:
план управления расписанием;
план управления обеспечением проекта персоналом содержит
характеристики кадрового обеспечения и тарифные ставки персонала
проекта и являются необходимыми элементами при составлении
стоимостной оценки расписания;
реестр рисков — при определении стоимостной оценки учитывается
информация, касающаяся реагирования на риски. Риски могут
приводить к негативным или благоприятным последствиям, поэтому
они оказывают влияние как на плановые операции, так и на стоимость
проекта. В случае возникновения негативного риска стоимость проекта
может увеличиться.
Инструменты и методы, используемые для оценки стоимости
В зависимости от стадии проекта, необходимой степени точности, возможных
расходов и трудозатрат применяются различные типы оценок стоимости.
Оценка сверху-вниз применяется на ранних стадиях в условиях недостаточной
информации о проекте. Производится только одна оценка стоимости всего проекта на самом
верхнем уровне. Такая оценка не требует много усилий, но имеет низкую точность.
146
Оценка по аналогам представляет вид оценки сверху-вниз. При этом используется
фактическая стоимость ранее выполненных проектов для оценки текущего проекта. При
наличии очень похожего проекта оценка может быть довольно точной. Такой тип оценки
применяется на любом этапе жизненного цикла проекта. Оценка по аналогам не требует
много усилий при гарантированной точности, однако не всегда удается найти и определить
схожие проекты. Точность оценки по аналогии колеблется от -30% до +50%. Стоимость
подготовки такой оценки составляет 0,04%-0,15% от общей стоимости проекта.
Оценка снизу-вверх применяется на этапе подготовки базового плана проекта и
формировании контрольной оценки. Процесс начинается с оценки деталей проекта с
последующим суммированием деталей на итоговых уровнях. Степень точности оценки
зависит от уровня детализации ИСР. Оценка снизу-вверх обеспечивает точность от +0,15/-
10% до +5%/-5%, но имеет высокую стоимость (от 0,45% до 2% от общей стоимости
проекта) и продолжительность.
Параметрическая оценка применяется на ранних этапах проекта. Процесс
параметрической оценки состоит в определении параметров оцениваемого проекта, которые
изменяются пропорционально стоимости проекта. На основании одного или нескольких
параметров создается математическая модель. Например, в качестве параметра разработки
программного обеспечения может быть выбрана стоимость разработки строки кода. Для
оценки стоимости обследования может быть выбрано количество автоматизируемых бизнес-
процессов. Наиболее распространенным параметром оценки стоимости IT-проектов
является количество требуемого рабочего времени на выполнение операций (пакета
операций). При тесной связи между стоимостью и параметрами проекта и при возможности
точного измерения параметров можно увеличить точность расчетов. Преимущество данного
метода: для оценки стоимости проекта достаточно знать «ставки» привлекаемых ресурсов:
недостатком является низкая точность (-30%-+50%). Стоимость подготовки параметрической
оценки составляет 0,04%-0,45% от общей стоимости проекта.
Контрольные оценки представляют собой разновидность оценок снизу-вверх [4.2].
В качестве уровня детализации для выполнения оценки стоимости используется ИСР.
Контрольная оценка основана на принципе более детальной оценки снизу-вверх. При оценке
затрат на работы проекта, как правило, определяют наиболее вероятное значение затрат,
затраты при благоприятных и неблагоприятных обстоятельствах, то есть оптимистическую,
пессимистическую и наиболее вероятную оценку. Для расчета математического ожидания и
среднеквадратичного отклонения применяют формулы, которые используются в методике
PERT:
147
Математическое ожидание = [оптимистическое + пессимистическое + (4x наиболее
вероятное)]/6
148
и доходов во времени; структура центров ответственности и распределение ответственности
между ними за статьи доходов и расходов; процессы планирования, учета и контроля,
которые предусматривают сбор и интеграцию плановой и фактической информации по
центрам ответственности. Распределение ответственности за статьи доходов и расходов
выполняется путем построения матрицы ответственности за статьи затрат (таблица 6.1).
Статьи затрат определяются по классификации доходов и расходов, принятой в компании;
центры ответственности определены на основании организационной структуры проекта.
Каждый проект имеет свои статьи доходов и расходов, некоторые проекты имеют только
расходные статьи бюджета. Структура статей расходов включает прямые затраты,
структурируемые по ИСР, и затраты на накладные расходы проекта.
Разработка бюджета расходов — процесс назначения оценок стоимости всем
операциям проекта, результатом которого является создание базового плана по
стоимости проекта [6.4]. Бюджет расходов содержит объединенные оценки стоимости
отдельных плановых операций или пакетов работ. Процесс разработки бюджета расходов
включает в себя процесс разработки бюджета для непредвиденных обстоятельств, куда
закладывают ожидаемые значения воздействия всех идентифицированных рисков.
Ожидаемое значение рассчитывается на основе оптимистичной, пессимистичной и наиболее
вероятной оценок величины риска. В бюджет расходов следует включить управленческий
резерв — деньги, предусмотренные в бюджете проекта на неидентифицированные риски.
149
Иерархическая структура работ определяет взаимоотношения между всеми
элементами проекта и результатами проекта.
Словарь ИСР содержит подробное описание работы для каждого элемента ИСР.
Оценка стоимости операции является результатом процесса оценки стоимости и
представляет количественную оценку примерной стоимости ресурсов, необходимых для
выполнения плановых операций.
Расписание проекта содержит плановые даты начала и окончания плановых
операций, контрольных событий расписания, пакетов работ, планируемых пакетов работ и
контрольных счетов проекта, что позволяет суммировать затраты за календарные периоды
при выставлении счетов за эти расходы.
Календари ресурсов. Сводный календарь ресурсов проекта документирует рабочие и
нерабочие дни, определяющие даты, на которые данный ресурс может быть активным или не
задействован.
План управления стоимостью, входящий в план управления проектом, и другие
вспомогательные планы используются при разработке бюджета расходов.
150
повторный анализ расписания и внесение в него необходимой корректировки. Результатом
плановых итераций является базовый план по стоимости.
Разработка бюджета расходов: выходы
Базовый план по стоимости — распределенный по времени бюджет, используемый
для мониторинга и контроля исполнения стоимости проекта. Он разрабатывается путем
суммирования оценок стоимости расходов по периодам времени и обычно имеет вид S-
кривой. Базовый план по стоимости является элементом плана управления проектом.
Проекты, особенно крупные, могут иметь несколько базовых планов по стоимости,
отражающих разные аспекты процесса исполнения стоимости: расходы, входящие платежи,
выполненную стоимость. Разработка базового плана по стоимости может быть выполнена по
следующим шагам:
1. Сбор исходной информации, к которой относится оценка стоимости, ИСР,
расписание проекта.
2. Определение типа базового плана стоимости и статей расходов. Определяющим
фактором при выборе типа является характер и размер проекта. Список статей
расходов зависит от типа базового плана. В таблице 6.2 приведен список статей
доходов и расходов в зависимости от типа плана.
Таблица 6.2. Определение статей расходов и доходов для различных типов базового плана
№№ Тип базового плана Статьи расходов и доходов
1 Заработная плата персонала проекта.
Выплаты подрядчикам.
Базовый план для измерения
Закупка оборудования.
исходящего потока денежной
Аренда помещения под проектный офис.
наличности
Транспортные расходы.
Оплата за услуги связи (телефон, Интернет)
2 Поступления от Заказчиков за поставленные
услуги:
разработка технического задания;
реализация проектных решений;
Базовый план для измерения
тестирование интеграционных сценариев
входящего потока денежной
тестирования;
наличности
разработка документов Системы;
разработка Материалов Обучения;
Централизованное обучение IT-специалистов
Заказчика
3 Статьи расходов и доходов, перечисленных в
Базовый план для управления
потоком денежной наличности пунктах № 1 и № 2
151
3. Установление критериев формирования базового плана — установление
отношений между оценкой стоимости и параметрами времени. Критерии
определяют события проекта, инициирующие выплаты по статьям расходов
базового плана, и интервал времени между инициирующим событием и датой
выплаты (таблица 6.3).
Апрель
Октябрь
Ноябрь
Декабрь
Июнь
Сентябрь
Январь
Июнь
Март
Май
Август
Июль
152
Управление стоимостью
Управление стоимостью — процесс контролирования затрат проекта и
выполнения корректирующих действий, который является частью общего управления
изменениями. Управление стоимостью проекта включает в себя следующие действия [4.1]:
Воздействие на факторы, вызывающие изменения базового плана по
стоимости.
Проверка одобрения на запрошенные изменения.
Управление изменениями стоимости.
Обеспечение сохранения расходов (периодических и всего проекта) в рамках,
определенных пределами финансирования проекта.
Осуществление мониторинга выполнения стоимости с целью обнаружения и
анализа отклонений от базового плана по стоимости.
Фиксирование всех отклонений от базового плана по стоимости.
Информирование соответствующих участников проекта об утвержденных
изменениях.
Выполнение действий, необходимых для того, чтобы превышения стоимости
затрат оставались в допустимых пределах.
Входы процесса управления стоимостью
Исходной информацией для управления стоимостью являются:
Базовый план по стоимости.
Требования к финансированию проекта.
Отчеты об исполнении — содержат информацию о расходовании ресурсов в
процессе выполнения фактических работ.
Информация об исполнении работ — содержит данные, относящиеся к статусу
и стоимости выполненных операций проекта, и включает следующее:
завершенные и незавершенные результаты поставки;
одобренные и произведенные расходы;
прогноз времени завершения плановых операций;
процент фактически выполненных плановых операций.
Одобренные запросы на изменения.
План управления проектом. В процессе управления стоимостью
учитываются данные плана управления проектом (плана управления стоимостью
и других вспомогательных планов).
153
Система управления изменениями стоимости содержит описания процедур
внесения изменений в базовый план по стоимости и включает в себя формы, документацию,
системы отслеживания и определения уровня уполномоченных одобрять внесение
изменений.
Метод освоенного объема — интегрированный анализ исполнения календарного
плана проекта и бюджета по стоимостным оценкам, наиболее распространенный метод
измерения исполнения проекта и его управления. (Освоенный объем задачи — это
утвержденный бюджет, выделенный на ее решение.) Данный метод позволяет в одном отчете
— отчете по освоенному объему— представить сведения об исполнении расходов и
расписания, причем и расписание и расходы измеряются в валюте, в которой ведется бюджет
проекта. Измерение и расходов, и расписания проекта в денежных единицах является
наиболее информативным описанием состояния проекта. Метод использует систему
отчетности с нарастающим итогом, которая основана на отслеживании трех показателей
проекта:
Плановая стоимость запланированных работ или плановый объем — PV
(Planned Value). Плановый объем рассчитывается на основании базового плана
по стоимости и базового расписания, где каждая операция имеет свои сроки и
оценку стоимости. Плановый объем представляет бюджет с нарастающим
итогом и отображающий во времени, когда предполагается делать затраты
согласно плану проекта (рис. 6.4);
Фактическая стоимость выполненных работ — AC (Actual Cost).
Фактическая стоимость с нарастающим итогом отображается во времени для
каждого отчетного периода (рис. 6.4);
Плановая стоимость выполненных работ или освоенный объем — EV
(Earned Value). Объем работы эквивалентен бюджету, установленному для
данной работы. Освоенный объем изображается на графике в конце каждого
отчетного периода на основании информации о фактической выполненной
работе.
Если проект выполняется в соответствии с планом, все три показателя будут иметь
одинаковое значение. Отклонения между показателями могут стать сигналом об отставании
проекта по срокам или перерасходе бюджетных средств.
154
Отчетная дата
Значения Budget At Completion (BAC)
Время
Рис. 6.4. Управление стоимостью методом освоенного объема
155
CV>0
CPI>1
Экономия Экономия
Отставание Опережение
SV<0 SV>0
SPI< SPI>
1 1
Перерасход Перерасход
Отставание Опережение
CV<0
CPI<1
156
• анализ отклонений включает в себя сравнение данных фактической
эффективности проекта с запланированными или ожидаемыми;
• анализ тенденций предполагает изучение данных эффективности проекта во
времени для определения, происходит ли улучшение или ухудшение исполнения
проекта;
• метод освоенного объема предусматривает сравнение плановых показателей
эффективности с фактическими.
Задания
157
Вариант 1
1. Ключевыми показателями методики освоенного объема являются:
• отклонение по стоимости. +
• отклонение по срокам. +
• отклонение по качеству.
• коэффициент выполнения бюджета. +
• коэффициент выполнения календарного плана. +
3. Чему равен индекс выполнения стоимости, если плановый объем PV= 80000,
фактическая стоимость выполненных работ AC =10000, освоенный объем EV=8000?
• 1.
• 1,25.
• 0,8. +
• 2,5.
Вариант2
1. При какой оценке стоимости проекта точность оценки колеблется от-30% до+50%:
• концептуальной оценки. +
• окончательной оценки.
• контрольной оценки.
• оценки порядка величины стоимости проекта.
2. При какой оценке стоимости проекта точность оценки колеблется от -10% до +15%:
• на этапе концептуальной оценки.
• на этапе окончательной оценки.
• на этапе контрольной оценки. +
• этапе оценки порядка величины стоимости проекта.
158
3. На процесс стоимостной оценки оказывают влияние:
• время, отведенное для проведения оцениваемой операции. +
• опыт менеджера. +
• инструменты оценивания. +
• заданная точность. +
Вариант 3
1. Сравнивая типы оценки стоимости проекта «сверху вниз» и «снизу-вверх» можно
сказать, что оценка «сверху вниз»:
• менее точная. +
• более точная.
• почти одинакова по точности с оценкой «снизу вверх».
Вариант 4
1. Распределение статей расходов и доходов по периодам времени (например, по дням,
месяцам, кварталам) является :
• бюджетом проекта. +
• сметой проекта.
• стоимостью проекта.
2. Бюджет на непредвиденные обстоятельства определяется для:
• рисков, которые могут быть идентифицированы. +
• рисков, которые еще не идентифицированы.
• корректирующих воздействий.
159
3. Управленческий резерв определяется для:
• рисков, которые еще не идентифицированы. +
• рисков, которые могут быть идентифицированы.
• корректирующих действий
Вариант 5
1. Управление стоимостью включает:
• определение примерной стоимости ресурсов, необходимых для выполнения операций
проекта. +
• суммирование оценок стоимости отдельных операций или пакетов работ с целью
формирования базового плана по стоимости. +
• воздействие на факторы, вызывающие отклонения по стоимости, и управление
изменениями бюджета проекта. +
160
Лекция 7. УПРАВЛЕНИЕ РИСКАМИ ПРОЕКТА
162
Управление рисками включает в себя шесть процессов: планирование управления
рисками, идентификация рисков, качественный анализ рисков, количественный анализ
рисков, планирование реагирование на риски, мониторинг и управление рисками.
Взаимодействие процессов управления рисками представлено на рис. 7.1.
163
Описание содержания
проекта План
Факторы внешней управления
среды предприятия
Планирование проектом
Активы управления рисками
организационного
процесса
План управления
рисками
Одобренные
Идентификация рисков запросы на
изменения
Реестр рисков
Качественный анализ
рисков
Реестр рисков
(обновления)
План
управления Количественный
стоимостью
План анализ рисков
управления
расписанием
Реестр рисков
(обновления)
План управления
Планирование проектом
реагирования на риски (обновления)
Реестр рисков
(обновления)
Контрактные
соглашения,
касающиеся рисков Рекомендованные
предупреждающие действия
Рекомендованные
Отчетность по корректирующие действия
исполнению Запрошенные изменения
Информация об Мониторинг Реестр рисков (обновления)
исполнении работ управления рисками План управления проектом
(обновления)
Активы организационного
процесса (обновления)
164
Методы и инструменты планирования рисков
В качестве инструментов и методов планирования управлением рисками используют
совещания по планированию и анализу. Команда проекта проводит совещания для
разработки плана управления рисками, в которых могут принимать участие менеджер
проекта, отдельные члены команды проекта и участники проекта, представители
организации, отвечающие за операции по планированию рисков и реагированию на них. На
совещаниях составляются базовые планы по проведению операций управления рисками.
Также разрабатываются элементы стоимости рисков и плановые операции, которые
включаются соответственно в бюджет проекта и расписание. Утверждается распределение
ответственности в случае наступления риска. Имеющиеся в организации общие шаблоны,
касающиеся категорий рисков и определения терминов (например, уровни рисков,
вероятность возникновения рисков по типам, последствия рисков для целей проекта по
типам целей, а также матрица вероятности и последствий), приспосабливаются для каждого
конкретного проекта с учетом его специфики. Выходы этих операций сводятся в план
управления рисками.
Результаты процесса планирования рисков
План управления рисками — документ, разрабатываемый в начале проекта и
содержащий описания структуры управления рисками проекта и порядок его выполнения в
рамках проекта; включается в состав плана управления проектом. План управления рисками
содержит следующие элементы [4.3]:
Методология — определение подходов, инструментов и источников данных,
которые могут использоваться для управления рисками в данном проекте.
Распределение ролей и ответственности — список позиций выполнения,
поддержки и управления рисками для каждого вида операций, включенных в план
управления рисками, назначение сотрудников на эти позиции и разъяснение их
ответственности.
Определение операций по управлению рисками, которые необходимо
включить в расписание проекта.
Определение сроков и частоты выполнения операций по управлению
рисками на протяжении всего жизненного цикла проекта.
Выделение ресурсов и оценка стоимости мероприятий, необходимых для
управления рисками. Эти данные включаются в базовый план по стоимости проекта.
Классификации рисков (или категории рисков) — структура, на основании
которой производится систематическая и всесторонняя идентификация рисков с
нужной степенью детализации. Классификации рисков предназначены для
165
нескольких целей. Во время выявления рисков они стимулируют видение проектной
группой всех возможных рисков, возникающих из различных составляющих
проекта. При проведении мозгового штурма классификации рисков облегчают
одновременную работу с большим числом рисков, предоставляя подходящий способ
группирования схожих рисков. Классификации помогают в разработке единой
терминологии, используемой участниками проекта для мониторинга и отчетности
о состоянии рисков, а также они совершенно необходимы для составления баз
знаний о рисках. Классифицировать риски можно с помощью составления
иерархической структуры или составив перечень различных аспектов проекта. В
процессе идентификации категории рисков могут пересматриваться. На рис. 7.2
приведен пример иерархической структуры рисков, содержащей категории и
подкатегории, которые могут появиться на типовом проекте. На рис. 7.3
представлена высокоуровневая классификация источников рисков проектов,
используемая Microsoft Solutions Framework ® (MSF) [1.5].
проект
167
При оценке воздействия риска определяется потенциальный эффект, который он может
оказать на цель проекта (например время, стоимость, содержание или качество). В таблице
7.2 представлена шкала для оценки угрозы риска, определенного в денежном выражении.
Таблица 7.4. Определение шкалы оценки воздействия для четырех целей проекта
Определенные условия для шкалы оценки степени возможного влияния риска
(показаны только примеры негативных воздействий)
Показаны значения по относительной и числовой шкалам
Очень
Цель проекта
Очень низкое Низкое Умеренное Высокое высокое
0,05 0,10 0,20 0,40 0,80
169
внимание, имеют достаточно высокую вероятность и существенные последствия (клетки
таблицы, окрашенные темно-серым цветом).
Идентификация рисков
Идентификация рисков — процесс определения рисков, способных повлиять на
проект, и документирование их характеристик. Идентификацию рисков выполняют
члены команды проекта и эксперты по вопросам управления рисками, в ней могут
принимать участие заказчики, участники проекта и эксперты в определенных областях. Это
итеративный процесс, поскольку по мере развития проекта в рамках его жизненного цикла
могут обнаруживаться новые риски. Частота итерации и состав участников выполнения
170
каждого цикла в каждом случае могут быть разными. В процессе идентификации должны
принимать участие члены команды проекта, чтобы у них вырабатывалось чувство
«собственности» и ответственности за риски и за действия по реагированию на них.
Исходная информация для процесса идентификации [4.1]
Входной информацией для процесса идентификации рисков служит нижеследующая
информация.
Факторы внешней среды предприятия — информация из открытых источников, в
том числе коммерческие базы данных, научные работы, бенчмаркинг и другие
исследовательские работы в области управления рисками.
Активы организационного процесса — информация о выполнении прежних
проектов.
Описание содержания проекта. Допущения проекта приводятся в описании
содержания проекта. Неопределенность в допущениях проекта следует рассматривать в
качестве потенциального источника возникновения рисков проекта.
План управления рисками. Входами для процесса идентификации рисков из плана
управления рисками являются схема распределения ролей и ответственности, резерв на
операции по управлению рисками в бюджете и в расписании, а также категории рисков.
План управления проектом. Для идентификации рисков необходимо понимание
планов управления расписанием, стоимостью и качеством, которые входят в план
управления проектом, и анализ выходов этих процессов.
Методы и инструменты идентификации рисков
Анализ документации заключается в просмотре материалов проекта, разработанных
до проведения данного анализа. Анализируется качество планов, согласованность планов,
соответствие требованиям Заказчика, допущения проекта, базовые планы по содержанию
срокам, стоимости, — все, что может служить показателями возможности риска в проекте.
Методы сбора информации [4.2]
Мозговой штурм. Целью мозгового штурма является создание подробного
списка рисков проекта. Список рисков разрабатывается на собрании, в котором
принимает участие 10-15 человек — члены команды проекта, часто совместно с
участием экспертов из разных областей, не являющихся членами команды. Участники
собрания называют риски, которые считают важными для проекта, при этом не
допускается обсуждение выдвинутых рисков. Далее риски сортируют по категориям и
уточняют.
Метод Дельфи аналогичен методу мозгового штурма, но его участники не
знают друг друга. Ведущий, с помощью списка вопросов для получения идей,
171
касающихся рисков проекта, собирает ответы экспертов. Далее ответы экспертов
анализируются, распределяются по категориям и возвращаются экспертам для
дальнейших комментариев. Консенсус и список рисков получается через несколько
циклов этого процесса. В методе Дельфи исключается давление со стороны коллег и
боязнь неловкого положения при высказывании идеи.
Метод номинальных групп позволяет идентифицировать и расположить
риски в порядке их важности. Данный метод предполагает формирование группы из 7-
10 экспертов. Каждый участник индивидуально и без обсуждений перечисляет
видимые им риски проекта. Далее происходит совместное обсуждение всех выделенных
рисков и повторное индивидуальное составление списка рисков в порядке их важности.
Карточки Кроуфорда. Обычно собирается группа из 7-10 экспертов.
Ведущий сообщает, что задаст группе 10 вопросов, на каждый из которых участник
письменно, на отдельном листе бумаги, должен дать ответы. Вопрос о том, какой из
рисков является наиболее важным для проекта, ведущий задает несколько раз. Каждый
участник вынужден обдумать десять различных рисков проекта.
Опросы экспертов с большим опытом работы над проектами.
Идентификация основной причины. Цель этого процесса: выявить
наиболее существенные причины возникновения рисков проекта и сгруппировать риски
по причинам, их вызывающим.
Анализ сильных и слабых сторон, возможностей и угроз (анализ SWOT).
Цель проведения анализа — оценить потенциал и окружение проекта. Потенциал
проекта, выраженный в виде его сильных и слабых сторон, позволяет оценить разрывы
между содержанием проекта и возможностями его выполнения. Оценка окружения
проекта показывает, какие благоприятные возможности предоставляет и какими
опасностями угрожает внешняя среда.
Анализ контрольных списков. Контрольные списки представляют собой
перечни рисков, составленные на основе информации и знаний, которые были
накоплены в ходе исполнения прежних аналогичных проектов.
Метод аналогии. Для идентификации рисков этот метод использует
накопленные знания и планы по управлению рисками других аналогичных проектов.
Методы с использованием диаграмм. К методам отображения рисков в виде
диаграмм относятся диаграммы причинно-следственных связей и блок-схемы
процессов, которые позволяют проследить последовательность событий, происходящих
в данном процессе.
Сравнение методов идентификации рисков проекта [4.2] представлено в таблице 7.5.
172
Таблица 7.5.Сравнение методов идентификации рисков
Метод идентификации Преимущества Недостатки
Мозговой штурм Способствует взаимодействию Может проявиться преобладание
членов группы одной личности. Можно
Быстрый сосредоточиваться только в
Недорогой конкретных областях. Требует
сильного ведущего. Для оценки
необходимо контролировать
склонности группы
Метод Delphi Нет доминирования одной Занимает много времени.
личности. Может проводиться Высокая загрузка ведущего
дистанционно через электронную
почту. Исключается проблема
ранней оценки. Требует участия
каждого члена группы
Метод номинальных групп Уменьшается эффект Требует много времени.
доминирующей Высокая загрузка ведущего
личности
Обеспечивает взаимодействие
участников
Дает упорядоченный список
рисков
Карточки Кроуфорда Быстрый Меньшее взаимодействие между
Легко реализуется участниками
Должен участвовать каждый член
группы
Вырабатывается большое
количество идей
Можно проводить с группами
больше
обычного размера
Уменьшает эффект доминирующей
личности
Опрос экспертов Используется прошлый опыт Эксперт может быть предвзятым.
Требует много времени
Контрольные списки Конкретный и упорядоченный Предвзятость
Легко использовать Может не содержать конкретных
элементов для данного проекта
Метод аналогии Использует прошлый опыт для Требует много времени. Легко
исключения проблем в будущем получить результаты, не
Подобные проекты содержат много подходящие для данного случая.
сходных черт Аналогия может быть некоррект-
ной
Методы с использованием Ясное представление участвующих Иногда вводит в заблуждение
диаграмм процессов Может занимать много времени
Легкость построения
Для них имеется много
компьютерных
инструментов
173
список потенциальных действий по реагированию;
основные причины возникновения риска;
уточнение категорий рисков. В процессе идентификации список категорий
рисков может пополняться новыми категориями, что может привести к
расширению иерархической структуры рисков, разработанной в процессе
планирования управления рисками.
Примеры форм Реестра рисков [1.5] приведены в таблицах 7.6 и 7.7.
174
Основная проблема управления рисками заключается в размере перечня рисков,
полученного на этапе идентификации. Управлять всеми выявленными рисками невозможно,
так как это требует больших финансовых и кадровых затрат. Основные задачи качественного
анализа состоят в разделении рисков на группы и расположении в порядке их приоритетов.
Классифицировать риски можно, например, по их временной близости. Так, близкие риски
должны иметь более высокий приоритет, чем риски, которые могут случиться в отдаленном
будущем. Расположения рисков по степени их важности для дальнейшего анализа или
планирования реагирования на риски может быть выполнено путем оценки вероятности их
возникновения и воздействия на проект. Качественный анализ рисков — быстрый и
недорогой способ установки приоритетов — выполняется на протяжении всего жизненного
цикла проекта и должен отражать все изменения, относящиеся к рискам проекта.
Входная информация для процесса качественной оценки
Качественный анализ выполняется на основании следующей информации:
Активы организационного процесса — данные о рисках в предыдущих проектах и
база накопленных знаний.
Описание содержания проекта.
План управления рисками, содержащий следующие элементы:
распределение ролей и ответственности в управлении рисками, бюджетом и
плановыми операциями по управлению рисками;
категории рисков;
определение вероятности возникновения и возможных последствий;
матрица вероятности и последствий;
уточненная толерантность к риску участников проекта.
Реестр рисков, который содержит список идентифицированных рисков.
175
зоне высокого риска (область красного цвета) матрицы необходимы предупредительные
операции и агрессивная стратегия реагирования (рис. 7.4). Для угроз, расположенных в зоне
низкого риска (зеленый цвет), осуществление предупредительных операций может не
потребоваться.
Матрица вероятностей и последствий позволяет отслеживать миграцию рисков. На
рис. 7.5 и 7.6 показано изменение ранга риска А с течением времени. В апреле риск
находился в зоне низкого риска, в мае переместился в область умеренног о, а в апреле попал в
зону высокого риска.
Динамика риска А
0,2
0,18
0,15
Ранг риска
0,1
0,07
0,06
0,05
0,02
0
апр.06 май.06 июн.06 июл.06
176
Реестр рисков (обновления). Обновление реестра рисков происходит на основании
информации, получаемой от качественного анализа рисков:
список приоритетов рисков проекта;
риски, сгруппированные по категориям;
список рисков, требующих немедленного реагирования;
список рисков для дополнительного анализа и реагирования;
список рисков с низким приоритетом, нуждающихся в наблюдении;
тренды результатов качественного анализа рисков.
177
которые оказывают влияние на исследуемую ситуацию проекта. Фиксируя все параметры и
изменяя только один из них, можно определить его воздействие на исследуемую ситуацию.
Скажем, исследуя вопрос об ожидаемой прибыли Исполнителя проекта, выделяем влияющие
на нее параметры, например такие: отсутствие квалифицированного персонала и
необходимость в его привлечении, отсутствие помещения под проектный офис и
необходимость аренды проектного офиса, отсутствие необходимых технических средств для
оборудования рабочих мест и необходимость в закупке требуемых средств. Затем выполняем
анализ чувствительности для выделенного параметра, обладающего наибольшим
потенциальным риском.
Анализ дерева решений. В сложных ситуациях, когда трудно вычислить результат
проекта с учетом возможных рисков, используют метод анализа дерева решений.
Дерево решений — это графический инструмент для анализа проектных
ситуаций, находящихся под воздействием риска. Дерево решений описывает
рассматриваемую ситуацию с учетом каждой из имеющихся возможностей выбора и
возможного сценария. Дерево решений имеет пять элементов (рис. 7.7).
Точки принятия решений — это моменты времени, когда происходит выбор
альтернатив.
Точка случайного события (точка возникновения последствий) — момент
времени, когда с тем или иным результатом наступает случайное событие.
Ветви — линии, соединяющие точки принятия решений с точками случайного
события. Ветви, исходящие из точки принятия решений, показывают возможные решения, а
линии, исходящие из узлов случайных событий, представляют возможные результаты
случайного события.
Вероятности — числовые значения, расположенные на ветвях дерева и
обозначающие вероятность наступления этих событий. Сумма вероятностей в каждой
точке принятия решений равна 1.
Ожидаемое значение (последствия) — это расположенное в конце ветви
количественное выражение каждой альтернативы.
Модель создается слева направо. Построение начинается с отображения точки
принятия решения, имеющей вид квадрата. Из этой точки рисуют количество ветвей, равное
числу проектных альтернативных решений. В конце каждой ветви рисуют кружок,
обозначающий возникновение допустимого случайного события, из которого выходят две
ветви — возможные результаты вероятностного события. Ветви дерева берут свое начало в
точке принятия решений и разрастаются до получения конечных результатов. Путь вдоль
ветвей дерева состоит из последовательности отдельных решений и случайных событий.
178
Рассмотрим пример. Торговая компания открывает новый магазин, который должен быть
укомплектован новейшим оборудованием. Оборудование производят два конкурирующих
поставщика (П1 и П2), объявивших одну и ту же дату появления на рынке нового
оборудования. Для увеличения эффективности работы компания планирует осуществить
внедрение ИС класса ERP. Разработаны три варианта расписания внедрения
информационной системы: (Вариант 1, Вариант 2, Вариант 3). Длительность проекта
рассматривается как параметр первостепенной важности. Расписание внедрения ИС зависит
от поставки и монтажа оборудования. Команда проекта оценила вероятность того, что
поставщик 1 (П1) или поставщик 2 (П2) поставит нужное оборудование первым. Анализ
информации о прежних разработках поставщиков позволил предположить, что поставщик 1
поставит на рынок новое оборудование с вероятностью 60%, соответственно для поставщика
2 эта вероятность будет равна 40%.
Команда проекта разработала сетевые графики трех альтернативных вариантов
расписания внедрения ИС при условии, что оборудование уже поставлено, и оценила
возможные значения продолжительности проекта.
Вероятность
Ожидаемое
значение П1 (0,6)
80
Вариант 1 (76)
А П2 (0,4) 70
П1 (0,6)
Вариант 2 (72) 70
1 Б П2 (0,4) 75
0
П1 (0,6)
Вариант 3 (78) 75
Точка принятия
решения
В П2 (0,4)
80
Альтернативное
решение
Точка случайного
события (узел)
Рис. 7.7. Дерево решений для проектной ситуации, находящейся под воздействием риска
179
ожидаемая длительность для случайного узла А: (80дней* 0,6) + (70дней *0,4) =
76дней
ожидаемая длительность для случайного узла Б: (70дней * 0,6) + (75дней *0,4) =
72дней
ожидаемая длительность для случайного узла В: (75дней * 0,6) + (80дней *0,4) =
78дней
Результат дерева решений — вариант расписания с наименьшей
продолжительностью, равной 72 дням.
Дерево решений — инструмент, который позволяет наглядно провести анализ
проектных решений, содержащих несколько путей решения.
Результаты количественного анализа рисков
Реестр рисков (обновления)
В процессе идентификации рисков начинается формирование реестра рисков, в
процессе качественного анализа рисков выполняется его обновление, во время
количественного анализа рисков происходит повторное обновление реестра. Реестр рисков
является составной частью плана управления проектами, поэтому обновлению подлежат
следующие основные элементы плана:
Вероятностный анализ проекта, который выполняет оценку потенциальных
выходов расписания и стоимости проекта и составляется перечень
контрольных дат завершения и стоимости. Результат анализа, в виде
распределения кумулятивных вероятностей, с учетом толерантности к риску
участников проекта, позволяет корректировать стоимостную и временную
составляющие резерва на непредвиденные обстоятельства.
Вероятность достижения целей по стоимости и времени. При помощи
результатов количественного анализа рисков можно оценить вероятность
достижения целей проекта на фоне текущих плановых показателей.
Список приоритетных оцененных рисков, куда включены риски, которые
представляют наибольшую угрозу или наилучшие благоприятные возможности
проекту.
Тренды результатов количественного анализа рисков могут
способствовать принятию решений, влияющих на реагирование на риски.
180
ответственных за реагирование и разработать предупреждающие действия для каждого
риска. Планирование реагирования на риски — это процесс разработки методов и
процедур, способствующих повышению благоприятных возможностей и снижению
угроз для достижения целей проекта. Способы реагирования рассматриваются для
каждого риска отдельно.
Входы процесса планирования реагирования на риски
Входной информацией для планирования реагирования на риски является:
план управления рисками — результат процесса планирования рисков;
реестр рисков — результат процесса количественного анализа рисков.
181
возникновения разрабатывает способ его обхода или исправления последствий. При
активном принятии план действий разрабатывается до того, как риск может произойти, и
называется планом действий в непредвиденных обстоятельствах.
Снижение риска. Стратегия предполагает усилие, направленное на понижение
вероятности и/или последствий риска до приемлемых пределов. В стратегии снижения
используется включение в план проекта дополнительной работы, которая будет выполняться
независимо от возникновения риска, как, например, проведение дополнительного
тестирования функциональности информационной системы, разработка прототипа системы,
дополнительное подключение к работе опытных сотрудников.
Планирование реагирования на риски: выходы
Реестр рисков (обновления). Способы реагирования на риски, разработанные и
утвержденные в процессе планирования реагирования, включаются в Реестр рисков.
План управления проектом (обновления). Обновление плана управления проектом
происходит за счет добавления операций реагирования на риски в процессе общего
управления изменениями проекта.
Контрактные соглашения, касающиеся рисков. Контрактные соглашения
составляются для того, чтобы юридически определить ответственность каждой из сторон на
случай возникновения каждого отдельного риска. Это могут быть договоры страхования или
оказания услуг.
182
Примеры параметров, к которым могут быть привязаны признаки рисков и за
которыми может проводиться регулярное наблюдение [1.5]:
количество «открытых» (найденных и неисправленных) ошибок на один модуль или
компонент;
среднее за неделю количество сверхурочных часов работы на одного сотрудника;
еженедельное количество изменений в требованиях к разрабатываемой системе;
изменения бизнес-процессов Заказчика;
своевременность выделения требуемых ресурсов;
техническое обеспечение работ.
Цель мониторинга состоит в наблюдении за прогрессом выполнения принятых
планов (предотвращения рисков и смягчения их последствий), количественными
параметрами, условиями, определяющими применения плана реагирования на риски, и в
информировании команды в случае наступления риска.
Во время мониторинга команда проекта выполняет планы по предотвращению
рисков. За прогрессом этой деятельности ведется наблюдение. Отслеживаются изменения
значений триггеров рисков. Для удобства выполнения мониторинга применяют специальные
формы [1.5], пример которой приведен в таблице 7.8
183
системы 2. Организа-
ция
референс-
визитов к
успешным
клиентам
3. Определе-
ние
реальных
лидеров в
организа-
ции,
Точечное
повышение
уровня их
заинтересо-
ванности в
успешном
внедрении
4. ...
0
184
Анализ резервов. При анализе резервов производится сравнение объема оставшихся
резервов на непредвиденные обстоятельства с количеством оставшихся рисков.
Совещания по текущему состоянию. Периодические совещания команды проекта
по вопросам управления рисками являются инструментом для отслеживания состояния
рисков проекта.
Мониторинг и управление рисками: выходы
Реестр рисков (обновления). Обновленный реестр рисков включает в себя
результаты пересмотра рисков, аудита и периодической проверки рисков, фактические
результаты рисков проектов и результаты реагирования на риски. Реестр рисков становится
частью документации по закрытию проекта.
Запрошенные изменения. Запрошенные изменения возникают в результате
необходимости изменения плана управления проектом в ответ на риск. Одобренные запросы
на изменения оформляются документально.
Рекомендованные корректирующие действия. К рекомендованным
корректирующим действиям относятся работы, внесенные в планы на непредвиденные
обстоятельства.
Рекомендованные предупреждающие действия используются для приведения
проекта в соответствие с планом управления проектом.
Активы организационного процесса (обновления). Результаты управления рисками
выполняемого проекта могут быть использованы в будущих проектах и должны войти в
состав активов организационного процесса.
План управления проектом (обновления). Если одобренные запросы на изменения
затрагивают процессы управления рисками, то необходимо обновить соответствующие части
плана управления проектом.
185
Приложение 7
7.1. Форма 1
Общий анализ проектных рисков
Информация о клиенте
Название клиента
Основное контактное лицо
Внутренняя информация о
клиенте
Код проекта
Ответственный за проект
Руководитель проекта
Выбор системы 2 1 0 3
Позиционирование 0 1 2 3
Определение объема работ 0 2 3 5
Разработка дизайна 0 9 7 16
Построение системы 1 3 1 5
Тестирование системы 2 3 2 7
Внедрение 2 1 1 4
Ввод в эксплуатацию 4 3 3 10
Всего 11 23 19 53
186
Запрос на регистрацию риска
Номер в журнале рисков: < >
ФИО автора запроса: < > <Заполняется автором запроса>
Роль на проекте: < > Приоритет:< Высокий, Средний, Низкий >
Наименование проекта: < > Дата запроса: <дд.мм.гггг>
Фаза проекта: <>
Желаемая дата разрешения: <дд.мм.гггг>
Описание риска: <Заполняется автором запроса>
<Детальное описание риска, контрольная точка (дата) наступления рискового события>
Предпосылки:
<Описание причин возникновения риска>
Последствия:
<Описание влияния на проект рисковых событий>
Варианты решения:
<Описание предложений по вариантам решения>
<Назван <Р или <Короткое наименование и <Проект решения (описание действия)> <Ответст <дд.мм.гг
ие П> детальное описание риска> венный> гг>
проекта <Владелец риска >
> <Проект решения (описание действия)> <Ответст <дд.мм.гг
венный> гг>
187
Лекция 8. УПРАВЛЕНИЕ КАЧЕСТВОМ ПРОЕКТА
Концепция управления качеством. Стандарты управления качеством проектов в
области ИТ. Три процесса управления качеством: планирование качества, обеспечение
качества, контроль качества. Основные задачи и процедуры планирования качества;
описание связей с другими процессами. Методы, средства и процедуры, используемые
для планирования качества.
Обеспечение качества проекта: аудиторские проверки качества, методы непрерывного
улучшения качества будущих проектов. Контроль качества. Методы контроля
качества. Процедуры анализа качества. Анализ состояния и обеспечения качества в
проекте.
188
управляемость и наблюдаемость всех процессов Компании;
вовлечение и мотивация персонала;
процессное представление всех видов деятельности;
системный подход к управлению;
непрерывное совершенствование системы менеджмента
качества (СМК);
достоверность информации для управленческих решений;
взаимовыгодные отношения с поставщиками.
189
— Интеграция функций обеспечения качества;
— Требования к системе управления качеством.
Стадия планирования. На стадии планирования качества определяются стандарты,
которые следует использовать, чтобы содержание проекта оправдывало ожидания
участников проекта. Планирование качества включает как идентификацию этих стандартов,
так и поиск путей их реализации. Ниже перечислены основные задачи стадии планирования:
— определение показателей оценки качества;
— определение технических спецификаций;
— описание процедур управления качеством;
— составление списка объектов контроля;
— выбор методов и средств оценки качества;
— описание связей с другими процессами;
— разработка плана управления качеством.
Стадия организации. Стадии организации контроля качества предполагает создание
необходимых и достаточных организационных, технических, финансовых и др. условий для
обеспечения выполнения требований к качеству проекта и продукции проекта и
возможностей их удовлетворения.
РЕГУЛИРОВАНИЕ ОРГАНИЗАЦИЯ
КОНТРОЛЬ
АНАЛИЗ
190
Стадии регулирования и анализа. Стадия осуществления контроля качества
предполагает регулярную проверку хода реализации проекта в целях установления
фактического соответствия определенным ранее требованиям.
— Сравнение фактических результатов проекта с требованиями.
— Анализ прогресса качества в проекте на протяжении его жизненного цикла.
— Формирование списка отклонений.
— Корректирующие действия.
— Документирование изменений.
Стадия завершения. На стадии завершения выполняются сводная оценка качества
результатов проекта, завершающая приемка, составление списка претензий по качеству,
разрешение конфликтов и споров, оформление документации, анализ опыта и полученных
уроков по управлению качеством.
Основными процессами обеспечения качества проекта являются планирование
качества, его обеспечение и контроль. Связь этих процессов, их входы и выходы
представлены на рис. 8.2.
191
План управления проектом
Описание содержания План управления проектом
проекта (обновления)
Факторы внешней среды Планирование качества
предприятия
(национальные стандарты,
регламенты) План управления качеством
Активы организационного Результаты оценки качества
процесса (политика в Контрольные списки процедур
области качества, контроля качества
принципы и процедуры) План совершенствования процессов
Базовый план по качеству
Одобренные запросы
на изменение
Процесс обеспечения
Выполненные
корректирующие действия
качества Запрошенные изменения
Выполненные Рекомендуемые корректирующие
предупреждающие действия
действия Плен управления проектом
Выполненные исправления Результаты контроля (обновления)
дефектов качества
Информация об
исполнении работ
Комментарий к форме:
1) № Сценария: Уникальный идентификатор сценария тестирования.
192
№ Сценария Сценарий Предпосылки Плановая дата Место проведения Ответственные Участники
План согласования:
До 18:00 ХХ.ХХ.2008, лицам, участвующим в согласовании пакета
документов, необходимо представить замечания в группу управления
качества на электронный адрес: _____________
Способ согласования: по электронной почте.
ХХ.ХХ.2008 будет организовано совещание для обсуждения
замечаний.
При отсутствии замечаний до указанного срока документ будет
считаться согласованным и будет передан на утверждение.
193
Рис. 8.4. Пример плана согласования документа
194
План управления проектом обеспечивает интеграцию процесса планирования
качества с другими процессами планирования.
Описание содержания проекта является ключевым входом для планирования
качества, так как оно содержит описание главных результатов поставки проекта, целей
проекта, критериев приемки и пороговых величин значения стоимости, времени или
ресурсов. Критерии приемки включают в себя требования к исполнению проекта и могут
существенным образом повлиять на его стоимость.
Планирование качества: инструменты и методы
Задача инструментов планирования качества — сделать процессы управления
проектом предсказуемыми. Для планирования качества проекта рекомендуется использовать
нижеследующие методы.
Программа обеспечения качеством — план действий, обеспечивающий
соответствие фактического качества проекта запланированному качеству [4.3]. На рис. 8.6
представлен пример фрагмента программы обеспечения качества.
Задача обеспечения
Стандарт качества
Элемент ИСР
качества
Лядов
Кравцов
09.окт
23.окт
Сидоров
Зайцев
07.ноя
14.ноя
21.ноя
16.окт
30.окт
Прохоров
руководства
по изложения (не Проверка и
управлению более 10 страниц) коррекция В У
проектами
Организационные
политики по
написанию
руководств Пересмотр В У
Обозначения: В — выполнение
У — утверждение
* Индекс легкости чтения по Флешу, определяется по среднему числу слогов в слове и слов в
предложении. Пределы изменения индекса — от 0 до 100. Чем выше величина индекса, тем легче
прочтение текста и тем большему числу читателей он будет понятен.
195
Разработка программы начинается с подготовки исходной информации, включающей
политики и процедуры компании в области качества, требования Заказчика, описание
содержания проекта и ИСР. В политике обеспечения качества обычно излагаются способы
управления качеством — процедуры обеспечения качества, принятые компанией. Основой
для создания программы качества является ИСР. Программа качества для пакетов работ
проекта получается путем суммирования программ обеспечения качества для всех
элементов этого пакета, программа проекта — путем суммирования программ пакетов работ.
Для измерения ожиданий Заказчика устанавливают стандарты качества (рис. 8.6, столбец 3).
Стандарты могут быть международными, национальными или корпоративными. После того
как стандарты качества установлены, нужно определить задачи, решение которых обеспечит
соответствие стандартам (рис. 8.6, столбец 4), далее закрепляется ответственность за
выполнение намеченных работ и сроки их исполнения.
Как правило, работы по обеспечению качества не включаются в ИСР проекта и не
попадают в матрицу ответственности и расписание проекта, а следовательно, не включаются
в бюджет проекта, что приводит в дальнейшем либо к удорожанию проекта, либо к
снижению запланированного качества. Разработка программы качества направлена на
предотвращение этих проблем.
Программа обеспечения качества проекта, имеющая форму таблицы, дает высокую
степень наглядности работ, обеспечивающих запланированное качество выполнения
требований Заказчика. Недостатком данного инструмента является его сложность для
команд, не привыкших к использованию стандартов.
Анализ выгод и затрат. Цель метода — выдержать необходимое соотношение между
доходами и затратами в проекте. Обеспечение качества проекта, несомненно, приводит к
дополнительным расходам, поэтому для каждого предложенного метода обеспечения
качества необходимо анализировать коэффициент рентабельности. На рис. 8.7 представлен
выбор оптимальной пропорции затрат на профилактику дефектов и устранение дефектов
[4.2].
140 Стоимость
120 проверки
100
80 Общая
60 стоимость
40
20 Стоимость
0 устранения
1 2 3 4 5 6 7 дефектов
196
Рис. 8.7. Соотношение затрат и выгод в обеспечении качества
197
Мероприятия по обеспечению качества График исполнения (в неделях)
проекта 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
2. Выбор и утверждение стандартов
выполнения проекта
3. Разработка и утверждение плана
управления рисками проекта
4. Задачи обеспечения качества
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. Внешние аудиты
6.2.1. Аудит представителями
поставщика ИС по выполнению
методологии внедрения ИС
6.2.2. Аудит хода выполнения проекта
представителями Заказчика
7. Подготовка и утверждение отчета о
выполненном проекте или этапе проекта
198
План управления проектом (обновления). Обновление плана происходит
вследствие добавления к нему вспомогательного плана управления качеством. Запрошенные
изменения подвергаются экспертной оценке и вносятся в соответствующие планы в процессе
общего управления изменениями.
199
Таблица 8.3. Контрольные списки для проверки управления проектом и
отчетности (фрагмент)
Этап проекта Ожидаемый результат Тип Да Не
т
Анализ проекта Наличие протоколов по анализу Критически
результатов каждой фазы проекта й
Управление Документирование Серьезный
проектом корректирующих действий по
уменьшению нежелательных
последствий отклонений по срокам
Управление Управление изменениями Серьезный
проектом происходит в соответствии с
утвержденной процедурой
Управление Документирование всех запросов на Критически
изменениями изменение в соответствии с й
принятой формой и их сохранение
в единой базе
Объект
Дата Автор
№ п.п контроля Замечание
замечания замечания
качества
200
качества проводятся на основе критериев, каждый из которых является следствием
требований нормативной документации системы менеджмента качества (требование ISO
9000) и системы управления проектами (PMBOK). Схема проведения внутреннего аудита
качества проекта может выглядеть следующим образом:
анализ исправления замечаний предыдущей проверки;
проведение проверки проекта в соответствии с контрольными списками;
оформление отчета о контроле качества;
информирование команды проекта о появлении новых отчетных
документов.
Анализ процесса предусматривает выполнение действий, описанных в плане
улучшения процесса и направленных на выявление организационных и технических
моментов, которые нуждаются в улучшении.
Процесс обеспечения качества: выходы
Запрошенные изменения имеют целью проведение специальных мероприятий по
повышению эффективности правил, процедур и процессов в исполняющей организации.
Рекомендованные корректирующие действия. Корректирующее действие — это
рекомендованное к немедленному исполнению действие, выработанное в результате
мероприятий по обеспечению качества (аудита или анализа процессов).
Активы организационного процесса (обновления). Обновленные стандарты
качества используются в дальнейшем процессе контроля качества.
План управления проектом (обновления) подлежит обновлению согласно
изменениям в плане управления качеством, выработанным в результате процесса
обеспечения качества. Запрошенные изменения в план управления проектом и во
вспомогательные планы (добавления, изменения, удаления) подвергаются экспертной оценке
и вносятся в соответствующие планы в процессе общего управления изменениями.
201
Результаты оценки качества.
Контрольные списки процедур контроля качества.
Активы организационного процесса.
Информация об исполнении работ включает техническое измерение
исполнения, состояние завершенности результатов поставки проекта и
исполнение необходимых корректирующих действий.
Одобренные запросы на изменение могут содержать такие изменения, как
исправленные методы работы и исправленное расписание.
Результаты поставки.
Процесс контроля качества: инструменты и методы
Для осуществления контроля качества используют следующие методы и средства:
Диаграмма причинно-следственных связей помогает отразить возможные
причины, влияющие на качество продукта или процесса в проекте. Такая диаграмма,
которую также называют диаграммой Ишикавы или диаграммой рыбьего скелета,
иллюстрирует связь различных факторов с возможными проблемами или эффектами [4.1].
На рис. 8.8 показан пример диаграммы причинно-следственных связей.
1.2
Качество
продукта
(процесса)
2.1 2.2
202
Среда
1.1
1.
2.
3.
Материал
Причины Следствие
203
по стоимости и отклонения по срокам выходят за рамки допустимых пределов (скажем, +/-10
процентов). Контрольные диаграммы можно использовать для наблюдения за любыми
выходными переменными. Хотя контрольные графики чаще всего нужны для отслеживания
повторяющихся операций, они также могут применяться для наблюдения за колебаниями
издержек и исполнением расписания, за объемом и частотой изменения содержания проекта,
за ошибками в документах проекта или другими результатами управления. Это позволяет
определить, насколько действенным является процесс управления проектом.
Диаграммы зависимостей помогают анализировать причины возникновения
проблем. Диаграмма зависимостей представляет собой графическое отображение процесса.
Существует множество различных стилей представления этих диаграмм, но все они
отображают операции, точки принятия решений и порядок обработки данных. Диаграммы
зависимостей дают представление о том, как различные элементы системы взаимодействуют
между собой. На рис. 8.10 приведен пример диаграммы зависимостей для контрольных
оценок. Такая диаграмма зависимостей может оказать помощь команде проекта в
прогнозировании, где и какие могут возникнуть проблемы с качеством, — и, следовательно,
в разработке мер по их предотвращению.
204
Рис. 8.10. Пример диаграммы зависимостей
Диаграмма Парето
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
Дефекты
205
количества дефектов. Диаграммы Парето логически связаны с Законом Парето, который
гласит, что относительно малое число причин обычно приводит к большинству проблем или
дефектов. Этот закон также известен как принцип 80/20, согласно которому 80 процентов
проблем создается 20-ю процентами причин.
Схема прогноза отображает историю и модель изменений. Она представляет собой
линейный график, отображающий точки ввода данных, расположенные на графике в порядке
их возникновения. Схема прогноза дает представление о трендах процесса во времени,
колебаниях во времени, а также о позитивных и негативных изменениях процесса во
времени. При помощи таких схем также проводится анализ тенденций. Анализ тенденций
часто используется для наблюдения за исполнением расписания и стоимости проекта.
Статистические выборки — это часть контролируемой продукции, позволяющей
сделать вывод обо всей продукции данного вида в проекте. Правильно сделанная выборка
часто помогает снизить затраты на контроль качества.
Инспекция включает такие процессы, как тестирование, предпринятое с целью
определения соответствия результатов проекта принятым требованиям и стандартам.
Различают тестирование как отдельных бизнес-процессов, так и их совокупности
(интеграционное тестирование). Для проведения тестирования разрабатывают сценарии
тестирования. Для осуществления контроля качества разработанной ИС составляют сводную
таблицу сценариев тестирования. Пример формы такой таблицы приведен на рис. 8.12.
Комментарий к форме:
1) №: Номер сценария тестирования бизнес-процесса.
2) Наименование сценария: Короткое наименование сценария тестирования
бизнес-процесса.
3) Описание сценария: Описание сценария тестирования бизнес-процесса.
4) Дата, Время: Дата и время проведения тестирования.
5) Тестировщик: Консультант от Исполнителя, участвующий в тестировании.
6) Приемщик: Сотрудник функциональной группы от Заказчика, участвующий в
тестировании.
7) Успешно? (да/нет): Отметка об успешности прохождения сценария
тестирования.
8) Примечания: Дополнительные пояснения к результатам сценария
207
План управления проектом (обновления). План управления проектом подлежит
обновлению в связи с изменениями в плане управления качеством, вызванными
результатами процесса контроля качества.
Внесение изменений в проект проводится в соответствии с утвержденными
процедурами общего управления изменениями через запрос на изменение.
Рекомендованное исправление дефектов — предложения по устранению дефектов.
Для формирования набора рекомендаций по исправлению дефектов можно использовать
Журнал регистрации дефектов.
Активы организационного процесса (обновления), содержащие заполненные
контрольные списки и документацию о накопленных знаниях.
Утвержденные результаты поставки — последствия, которые определяются при
установлении соответствия результатов поставки определенным требованиям. Результатом
процесса контроля качества являются утвержденные результаты поставки.
План управления проектом (обновления). План управления проектом подлежит
обновлению в связи с изменениями в плане управления качеством, вызванными
результатами процесса контроля качества.
208
Управление человеческими ресурсами проекта — это процесс обеспечения
эффективного использования человеческих ресурсов проекта, к которым относятся все
участники проекта (спонсоры, заказчики, команда проекта, субподрядчики,
подразделения компании и другие участники проекта [4.2]).
Для успешного достижения целей проекта критически важным является следующее:
• идентифицировать состав участников проекта;
• определить роли участников проекта и порядок их взаимодействия;
• сформировать команду проекта и команду управления проектом;
• построить необходимую и достаточную для управления проектом организационную
структуру.
Ответим на следующие вопросы: что понимается под проектной ролью, командой
проекта, командой управления проектом.
Роль в проекте (проектная роль) — определенный набор функций и
полномочий в проекте, созданный с целью распределения обязанностей между
членами команды проекта. Проектную роль можно рассматривать как временную
должность в организации (компании).
Команда проекта — временная рабочая группа, выполняющая работы по
проекту и ответственная перед Руководителем проекта за их выполнение. Команда
проекта состоит из команды управления, участников проекта, выполняющих работы в
рамках проекта, — Исполнителей проекта.
Команда управления проектом (КУП) — члены команды проекта,
уполномоченные принимать управленческие решения по управлению проектом.
Участники проекта — организации Заказчика и Исполнителя и специалисты
от организаций Заказчика и Исполнителя, а также другие организации и лица, которые
участвуют в работе проекта или чьи интересы могут быть затронуты при
исполнении или завершении проекта. Участники оказывают влияние на проект и его
результаты.
209
Куратор проекта (Спонсор);
Архитектор системы;
Администратор проекта.
210
Управление качеством проекта, в том числе:
o контроль соответствия разрабатываемых проектных решений
Техническому заданию;
o организация экспертизы проектных решений.
Управление рисками проекта, в том числе:
o анализ рисков проекта;
o разработка планов мероприятий по снижению рисков;
o реализация мероприятий по снижению рисков.
Управление проблемами проекта, в том числе:
o анализ проблем проекта;
o разработка мероприятий по разрешению проблем проекта;
o реализация мероприятий по разрешению проблем проекта.
Контроль над организацией работ в проектных группах, в том числе:
o согласование отчетов о ходе работ;
o контроль над функционированием системы сбора и распределения
информации;
o контроль документирования проектных результатов.
Персональный состав команды управления приведенных организационных единиц
определяется Уставом проекта.
Для того чтобы распределить функции и обязанности по проекту, составляют
ролевые инструкции или Положение по проектной роли. В ролевой инструкции должно быть
определено следующее:
какие цели стоят перед сотрудником, назначенным на данную роль;
кому подчиняется сотрудник, назначенный на ту или иную роль;
каковы его функции, обязанности, полномочия.
Незнание ключевых участников проекта, их функций и полномочий может привести к
большим сложностям при исполнении проекта.
211
проекта, осуществляет утверждение основных изменений в объеме работ, сроках, этапах,
в бюджете проекта, находящихся вне компетенции Руководителя проекта. Как правило,
Куратором проекта (Спонсором) является менеджер высшего звена организации.
Основные функции:
общее руководство ходом реализации проекта;
обеспечение выделения необходимых ресурсов для выполнения проекта, обеспечение
финансирования работ;
рассмотрение и утверждение регламентирующих документов, необходимых для
организации и выполнения проекта;
получение и анализ сводной отчетности о ходе реализации проекта;
управление изменениями базовых параметров проекта и решение проблем,
находящихся вне компетенции Руководителя проекта.
Основные полномочия:
утверждение целей проекта;
согласование назначения Руководителя проекта;
утверждение общего плана и бюджета проекта;
получение от Руководителя проекта сводной отчетности о ходе его выполнения;
принятие принципиальных решений при возникновении критических изменений,
влияющих на сроки, стоимость и качество результатов проекта.
Руководитель проекта — проектная роль должностного лица,
ответственного за управление проектом. Руководитель проекта непосредственно
отвечает за достижение целей проекта в рамках выделенного бюджета, в соответствии с
плановыми сроками осуществления проекта и с заданным уровнем качества.
Основные функции:
формирование команды проекта и команды управления проектом;
планирование, организация и контроль выполнения работ по достижению целей
проекта с требуемыми качеством, затратами и в заданный срок;
распределение ресурсов проекта и организация взаимодействия команды проекта в
процессе его выполнения;
организация взаимодействия с Заказчиком и обеспечение всех необходимых
коммуникационных связей с другими участниками проекта;
учет фактических затрат ресурсов по исполнению проекта;
формирование и предоставление Куратору отчетности по проекту.
Основные полномочия:
назначение задач команде проекта (отдельным ее членам) и контроль их выполнения;
212
требование от команды проекта выполнения своих ролевых функций;
подтверждение или отклонение отчетов о фактических затратах исполнителей
проекта;
обоснование необходимости и запрос Куратору проекта на выделение
дополнительных ресурсов на проект;
обращение к Куратору за поддержкой в случае необходимости.
Архитектор системы — проектная роль должностного лица, отвечающего за
предметную область проекта. Архитектор системы подчиняется непосредственно
Руководителю проекта.
Архитектор системы непосредственно отвечает за разработку информационной
системы в соответствии с плановыми сроками проекта и с заданным уровнем качества.
На роль Архитектора системы назначается специалист, наиболее компетентный по
внедряемой информационной системе. Архитектор системы должен знать методологии и
технологии построения ИС, стандарты и нормативные документы в области проектирования
и создания ИС, разработки и оформления технической документации.
Основные функции:
определение состава, продолжительности и технологии выполнения работ по
разработке и внедрению информационной системы;
определение ресурсов, которые необходимы для разработки и внедрения ИС в рамках,
заданных условиями проекта;
определение квалификационных требований и состава рабочих групп специалистов
по направлениям деятельности, распределение их по задачам, организация работ и
верификация результатов в процессе реализации проекта;
обеспечение целостности функциональной архитектуры внедряемой информационной
системы;
организация подготовки, согласования и утверждения всей технической
документации, необходимой для создания ИС в рамках проекта;
планирование и согласование фактических трудозатрат специалистов при исполнении
проекта;
формирование и предоставление руководителю проекта необходимой отчетности;
анализ хода выполнения и промежуточных результатов создания ИС;
организация, проведение и документирование процедур передачи Заказчику
разработанной ИС.
Основные полномочия:
участие в календарном планировании работ по созданию ИС;
213
назначение задач рабочим группам проекта и контроль их выполнения;
требование от исполнителей качественного выполнения порученных задач и
своевременной информации о возникающих проблемах;
обоснование необходимости и запрос руководителю проекта на выделение
дополнительных ресурсов на проект.
Администратор проекта — проектная роль должностного лица, отвечающего за
информационное обеспечение руководителя проекта, организацию и ведение
документооборота по проекту. Администратор проекта функционально закрепляется за
конкретным проектом и подчиняется непосредственно Руководителю проекта.
Основные функции:
обеспечение Руководителя проекта структурированной информацией,
обеспечивающей возможность контроля за проектом, планами, ресурсами и
приоритетами;
ведение протоколов совещаний;
обеспечение своевременной подготовки, движения и архивации документов по
проекту.
Основные полномочия:
передача и получение от участников проекта необходимой документации по проекту;
контроль соблюдения участниками проекта установленной системы
документооборота;
затребование от конкретных исполнителей по проекту оперативной информации и
отчетов о ходе работ по проекту.
Распределение основных функций между членами команды управления проекта
представляют в виде таблицы 9.3, которая дает точное представление о том, кто и за что
отвечает на протяжении всего проекта.
Архитектор
(Спонсор)
системы
Куратор
проекта
проекта
проекта
Функциональные обязанности
Планирование
Разработка и периодическая актуализация + +
плана
Утверждение плана +
214
Управление командой проекта
Назначение сотрудника на роль +
Руководителя проекта
Формирование команды проекта +
Определение квалификационных требований и +
состава рабочих групп специалистов по
функциональности ИС
Обеспечение выделения необходимых +
ресурсов для выполнения проекта
Непосредственное руководство +
Командой проекта
Формирование предложений по +
стимулированию Команды проекта
Обеспечение стимулирования Команды +
проекта
Организация выполнения работ
Организация взаимодействия с Заказчиком и +
обеспечение всех необходимых
коммуникационных связей с другими
участниками проекта
Организация подготовки, согласования и +
утверждения всей технической документации,
необходимой для создания ИС в рамках
проекта
Организация, проведение и документирование + +
процедур передачи Заказчику разработанной
ИС
Рассмотрение и утверждение +
регламентирующих документов, необходимых
для организации и выполнения проекта
Ведение организационно-распорядительной и +
отчетной документации. Поддержание в
актуальном состоянии списка команды
проекта
Обеспечение команды проекта необходимыми +
информационными материалами
Материально-техническое и хозяйственное +
обеспечение команды проекта
Контроль хода выполнения проекта
Организация и проведение совещаний по +
обсуждению хода работ проекта
Подготовка и предоставление Куратору +
отчетов о ходе работ проекта
Получение и анализ сводной отчетности о +
ходе реализации проекта
Контроль соответствия результатов проекта +
Техническому заданию на разработку ИС
Согласование фактических трудозатрат + +
специалистов при исполнении проекта
В состав команды проекта, как было отмечено выше, входит не только команда
управления проектом, но и Исполнители. Примеры проектных ролей Исполнителей,
характерных для IT-проектов: функциональный архитектор, функциональный консультант,
разработчик, администратор ИС, тестировщик, менеджер по качеству, системный аналитик.
На проекте один член команды может выступать одновременно в нескольких ролях.
215
Совмещение ролей часто встречается на небольших проектах, что позволяет снизить
накладные расходы проекта. Но не все роли можно совмещать, поскольку подобное
совмещение может затруднить контроль и оценку результатов проекта. Допускается
совмещение таких проектных ролей, как Руководитель проекта и администратор проекта,
функциональный архитектор и функциональный консультант, функциональный консультант
и аналитик, менеджер разработки и разработчик, менеджер по качеству и тестировщик. Но
не следует совмещать роли менеджера по качеству и разработчика, руководителя проекта и
разработчика, тестировщика и разработчика.
216
Факторы внешней среды
Организационная культура
Планирование команды План управления проектом
и структура проекта
Шаблоны контрольных
списков
Требования к ресурсам Распределение ролей и
операций ответственности
Организационные диаграммы проекта
контроля качества
План управления обеспечением
проекта персоналом
Одобренные запросы на
изменения
Набор команды Одобренные корректирующие
действия
проекта Одобренные предупреждающие
действия
Назначение персонала в
проекте
Доступность ресурсов
План управления
обеспечением проекта
персоналом (обновления)
Отчеты об
исполнении работ
Развитие команды
проекта
Оценка эффективности
команды проекта
План управления проектом
(обновления)
Запрошенные изменения
Рекомендованные
Активы
организационного
Управление командой корректирующие действия
процесса проекта Рекомендованные
(обновления) предупреждающие действия
217
критерии их освобождения от участия в проекте, рекомендации по проведению
дополнительного обучения. В процессе планирования определяются концепция мотивации,
способы разрешения конфликтов, разрабатывается график проведения собраний команды
проекта и его участников.
Планирование команды проекта: входы
Факторы внешней среды предприятия
Определение ролей и ответственности в проекте должны производиться с учетом
факторов внешней среды предприятия. В таблице 9.2 приведены примеры возможного
влияния организационных, технических, межличностных и политических факторов на
процесс планирования команды проекта.
218
диаграммы проекта, описания позиций, методы оценки эффективности работы команды и
подход к разрешению конфликтов, матрицы распределения ролей и ответственности,
матрицы квалификации для должностей, меры по повышению мотивации членов команды и
другое.
План управления проектом
Для определения команды проекта существуют требования к ресурсам операции,
которые содержатся в плане управления проектом. В процессе планирования команды
происходит обновление предварительных требований в отношении требуемых людей и их
квалификации.
Планирование команды: инструменты и методы
Организационные диаграммы и назначения по проекту
Иерархические организационные диаграммы являются простым и наглядным
инструментом для определения иерархии подотчетности, начиная с нижнего уровня
организации до руководителя проекта. Существуют различные форматы документирования
распределения ролей и ответственности членов команды проекта, например иерархический,
матричный или текстовый. Независимо от формата документирования организационные
диаграммы позволяют для каждого пакета работ назначить ответственного за его
исполнение, а также обеспечивают понимание своей роли и ответственности каждым
членом команды.
На рис. 9.3 представлен пример документирования распределения ролей и
ответственности членов команды проекта, выполненного в виде организационной
структуры. Организационная структура является иерархической организационной схемой
существующих подразделений организации (отделов, групп или команд). Под каждым
отделом указывается список операций проекта или пакета работ. Таким образом, можно
увидеть закрепление ответственности в проекте для данного функционального отдела
(например, отдела информационных технологий или отдела закупок) в одном месте рядом с
названием отдела.
219
Рис. 9.3. Организационная структура проекта
Разработка плана р к
вех
Разработка бюджета у п р
проекта
220
Составление плана п р
проекта
Утверждение плана у к К
Реестр навыков
Реестр навыков — инструмент для определения навыков, необходимых членам
команды проекта . Реестр навыков — это список категорий и компонентов навыков для
определенного класса персонала. Пример реестра навыков для руководителя ИТ-проектов
(рис. 9.4):
221
Понимание тенденций
Понимание основных задач маркетинга
Наличие навыков системного анализа
Административные навыки:
Привлечение уникальных специалистов
Навыки эффективного общения
Умение делегировать полномочия
Ведение переговоров с целью обеспечения ресурсами
Календарное планирование
Понимание политик и рабочих процедур
Сотрудничество с другими проектными командами
Навыки межличностного общения и лидерства:
Оказание помощи в решении проблем
Построение многофункциональной команды
Определение целей
Получение поддержки высшего руководства
Мотивация членов команды
Управление конфликтами
Стратегические навыки:
Стратегическое планирование
Принятие стратегических решений
Умение работать в условиях риска
Умение лидировать
Реестры навыков должны быть составлены для каждого класса персонала, как,
например, для руководителя проекта, системного архитектора, специалиста по качеству.
Критичность навыков для руководителя проекта определяется во многом масштабом проекта
222
и организационной структурой проекта. Как отмечалось в лекции 1, наибольшими
полномочиями наделен руководитель проекта в проектных организационных структурах, и,
следовательно, к нему должны предъявляться самые высокие требования. Распределение
навыков зависит от уровня административной ответственности. Рейтинг критичности
смещается от «технических» в сторону «административных», а затем в сторону
«межличностного общения» и «стратегических навыков» по мере роста административной
ответственности.
Налаживание связей
Налаживание связей — метод планирования команды проекта, состоящий из
операции по установлению связей с потенциальными членами команды, таких как
предварительная переписка, неформальные беседы и собрания по специальности.
Использование этого метода может быть полезно не только на этапе планирования, но и до
начала проекта.
Теория организации
Методом планирования команды проекта является использование теории
организации, которая дает информацию о поведении людей, команд и подразделений.
Применение проверенных принципов позволяет сократить время планирования и повысить
его качество.
Планирование команды проекта: выходы
Распределение ролей и ответственности
При распределении ролей и ответственности, необходимых для выполнения проекта,
следует учитывать следующие моменты.
Роль — обозначение части работ проекта, за выполнение которой несет
ответственность определенное лицо.
Полномочия — право задействовать ресурсы проекта, принимать решения и
утверждать одобрение действий или результатов. Примеры полномочий: выбор способа
завершения операции, приемка качества и порядок реагирования на отклонения в проекте.
Ответственность — работа, которую член команды проекта должен выполнить
для завершения операций проекта.
Квалификация — навыки и способности, необходимые для выполнения операций
проекта. Отсутствие нужной квалификации у членов команды влияет на расписание
проекта, качество выполнения работ, ставит под угрозу цели проекта. Для повышения
квалификации планируют проведение обучения членов команды.
Организационная диаграмма проекта
223
Организационная диаграмма проекта — это графическое представление состава
команды проекта и отношения подотчетности между ее членами. В зависимости от
потребностей проекта она может быть официальной или неофициальной, подробной или
обобщенной.
План управления обеспечением проекта персоналом
План управления обеспечением проекта персоналом является составной частью плана
управления проектом. Он должен содержать следующую информацию.
Набор персонала. При планировании набора членов команды проекта определяется
схема, по которой будут задействованы имеющиеся человеческие ресурсы организации (или
они будут набираться извне на контрактной основе) и какова стоимость, соответствующая
каждому уровню знаний (квалификации), который необходим для проекта.
Расписание. В плане управления обеспечением проекта персоналом указываются
временные рамки занятости членов команды проекта в графическом или табличном виде.
Критерии освобождения ресурсов. Определение метода и времени освобождения
членов команды важно как для проекта, так и для членов команды. Расписание
высвобождения позволяет исключать выплаты сотрудникам, уже выполнившим свою долю
работы в проекте, и тем самым снизить затраты на проект, а также обеспечивает
информацией о наличии свободного ресурса.
Обучение персонала. Если есть опасения, что квалификация членов команды,
привлекаемых для участия в проекте, может оказаться недостаточной, то в рамках плана
проекта следует разработать план обучения персонала. В этот план могут быть также
включены программы обучения членов команды и получения ими сертификатов, наличие
которых способствует успешному выполнению проекта.
Поощрение и премирование. Спланированная система премий и определенные
критерии премирования стимулируют и мотивируют производительность людей, занятых в
проекте. Создание плана с указанием времени премирования гарантирует выплату премий.
Безопасность. Нормы и правила по защите членов команды проекта от несчастных
случаев могут быть включены в план управления обеспечением проекта персоналом.
224
Доступность — возможность привлечения специалиста на проект в
запланированные сроки.
Квалификация — наличие у потенциального члена команды квалификации,
отвечающей требованиям проекта.
Опыт работы — наличие опыта выполнения работы, которую планируется
закрепить за потенциальным членом команды.
Заинтересованность — наличие интереса в работе над проектом.
Стоимость — величина оплаты труда потенциального члена команды.
Активы организационного процесса
Активы организационного процесса могут содержать правила и процедуры
назначения персонала на проект и высвобождения персонала с проекта, а также базы данных
по персоналу и возможному резерву.
Распределение ролей и ответственности
Схема распределения ролей и ответственности, необходимые навыки и квалификация,
разработанные на этапе планирования команды проекта, являются ключевой информацией
при наборе команды.
Организационные диаграммы проекта
Организационные диаграммы проекта являются входной информацией для
определения численности команды проекта.
План управления обеспечением проекта персоналом
План управления обеспечением проекта персоналом и расписание проекта определяет
сроки, на которые привлекается каждый член команды проекта, и время его высвобождения.
Набор команды проекта: инструменты и методы
Переговоры
Набор команды для многих проектов является предметом переговоров с
руководителями функциональных подразделений или руководителями других проектов для
гарантии обеспечения соответствующим штатом квалифицированных сотрудников на
требуемый период времени.
Тестирование
При подборе команды проекта представляют интерес различные психологические
тесты, помогающие руководителям проектов включать в команду людей, личностные
характеристики которых охватывают диапазон качеств, необходимых для успешной
реализации проекта. В качестве примера можно привести тест Мередита Белбина —
американского психолога, который более десяти лет посвятил изучению условий,
необходимых для успешной деятельности управленческих команд. Белбин предположил, что
225
каждый член команды играет две роли: функциональную, связанную с формальной
спецификой деятельности, и «командную роль», особенно важную для успешной
деятельности команды. Белбин выделил и описал восемь типов командных ролей, которыми
характеризуется все «ролевое разнообразие» команды: «исполнитель», «председатель»,
«формирователь», «мыслитель», «исследователь ресурсов», «оценивающий»,
«коллективист» и «доводящий до конца». Основным качеством «исполнителей» является
дисциплинированность, организованность, сознательность, приверженность обязательствам,
серьезное отношение к любому делу, надежность, практичность, терпимость к окружающим.
«Исполнители» — эффективные организаторы и администраторы. Им присущ практичный и
реалистичный подход к выполнению работы. Для «коллективиста» характерен
консультативный стиль руководства и склонность к неформальному общению с коллегами и
подчиненными. Из них получаются отличные наставники молодых менеджеров. Основное
назначение «мыслителя» в команде — привнесение новых и оригинальных идей.
«Председатель» — человек, знающий, как использовать ресурсы, исключительно
адаптивный при общении с людьми, но в то же время никогда не теряющий контроля над
ситуацией и способности принимать самостоятельные решения. Тестирование по методу
Белбина позволяет определить «командную роль» потенциального члена команды и при
формировании команды включать в нее людей с такими личностными характеристиками,
чтобы в команде были реализованы все восемь ролей. Полная ролевая структура создает
предпосылки для эффективного партнерского взаимодействия. В случае, если команда
проекта работает неэффективно, полезно проанализировать ее состав в свете
рассматриваемых восьми ролей.
Набор команды проекта: выходы
Назначение персонала в проекте
Процесс набора команды заканчивается укомплектованием штата, документально
оформленного, например, в следующем виде (рис. 9.5).
Количеств
структуре,
В наличии
Отдел по
штатной
Дата выхода
Вакансии Проектная роль Ф.И.О. на проектную
о
работу
Группа качества
226
Группа функциональной разработки
Доступность ресурсов
Для указания доступности ресурсов документально фиксируется период времени, в
течение которого каждый член команды проекта может принимать участие в выполнении
проекта. Информация о доступности ресурсов необходима для корректировки расписания
проекта с учетом отпусков и обязательств по другим проектам.
План управления обеспечением проекта персоналом (обновления)
По мере назначения специалистов согласно схеме распределения ролей и
обязанностей может возникнуть необходимость в изменении плана управления
обеспечением проекта персоналом, которая связана с несоответствием требований,
предусмотренных планом, повышением в должности, выходом на пенсию, болезнью.
227
членам команды. Основной задачей руководителя проекта является разработка такого плана
развития команды, который бы позволил как можно скорее выйти на стадию
функционирования.
Развитие команды проекта: входы
Входной информацией для процесса развития команды являются выходы процесса набора
команды:
Назначение персонала в проекте.
План управления обеспечением проекта персоналом.
Доступность ресурсов.
228
командировки, премии. Соблюдение правил поведения способствует повышению
производительности труда.
Со-расположение
Сплочению команды способствует размещение членов команды проекта в одном
месте. Стратегия со-расположения предполагает наличие комнаты, оснащенной
электронными средствами связи, досками для расписаний и другими приспособлениями,
которые способствуют взаимному общению.
Поощрение и премирование
Стимулирование и поощрение желаемого поведения членов команды является частью
процесса развития команды. План поощрения создается в процессе планирования команды
проекта. Решения о премировании принимаются на основании результата оценки
эффективности работы команды.
Развитие команды проекта: выходы
Оценка эффективности команды проекта
Для оценки эффективности работы команды могут использоваться следующие
показатели:
Повышение навыков членов команды.
Повышение квалификации.
Сокращение текучести кадров.
229
Активы организационного процесса содержат правила и процедуры, принятые в
организации для поощрения членов команды, например, процедуры награждения грамотами
и начисления премий.
Назначение персонала в проекте
В результате назначения персонала формируется список членов команды проекта,
который оценивается в процессе мониторинга и управления командой проекта.
Распределение ролей и ответственности
Входной информацией для задач мониторинга и оценки работы членов команды
проекта является схема распределения ролей и ответственности.
Организационные диаграммы проекта
Организационные диаграммы проекта содержат информацию об отношениях
подотчетности членов команды проекта, необходимую для наблюдения за деятельностью
команды.
План управления обеспечением проекта персоналом
План управления обеспечением проекта персоналом, содержащий информацию о
периоде времени, на который сотрудник привлекается к участию в проекте, а также сведения
о планах по обучению персонала, требованиях сертификации и соответствия нормативным
документам являются входами для решения задачи по оценке работы членов команды и
наблюдения за деятельностью команды.
Оценка эффективности команды проекта
Оценка эффективности команды проекта является исходной информацией для
решения задач по усовершенствованию средств коммуникации, урегулированию
конфликтов, разработке мер по укреплению взаимодействия членов команды.
Информация об исполнении работ и отчеты об исполнении
Информация об исполнении работ проекта, отчеты об исполнении работ проекта
позволяют проводить оценку соответствия эффективности работы команды плану
управления проектом. Отчеты о выполнении работ членами команды проекта помогают в
определении требований к составу команды будущих проектов, в создании системы
поощрений и в обновлении плана управления обеспечением проекта персоналом.
Управление командой проекта: инструменты и методы
Наблюдение и обсуждение
Наблюдение и обсуждение являются инструментами для контролирования процесса
выполнения работ и настроения внутри команды проекта. Многие руководители ИТ-
проектов имеют низкую коммуникабельность и испытывают сложности в общении. Для
таких руководителей рекомендуется осуществлять управление командой проекта методом
230
«прогулки». Руководитель проекта регулярно обходит пространство офиса, в котором
работает команда. Встречая члена команды, руководитель начинает разговор произвольной
фразой, например, «С каким счетом закончился вчерашний матч?». Член команды, как
правило, после некоторого обсуждения результатов игры перейдет (с таким же увлечением)
к рассказу о выполнении проекта. Метод «прогулки» позволяет сделать процесс
коммуникации более свободным и искренним.
Оценка эффективности выполнения работ проекта
Оценка эффективности — это инструмент, позволяющий:
уточнить правильность распределения ролей и ответственности;
организовать получение исполнителями оценки их работ (особенно
положительных оценок, стимулирующих производительность труда);
выявить неизвестные ранее проблемы;
разработать индивидуальные планы повышения квалификации;
определить ближайшие цели.
Оценку эффективности команды можно выполнить с помощью теста (см. Приложение
9.1), в основу которого положено определение значения характеристик
высокоэффективной команды проекта:
A — ясное понимание целей;
B — открытость;
C — уверенность друг в друге;
D — разделение компетенции;
E — эффективные внутренние процедуры;
F — превосходство команды, основанной на качествах индивидуальностей;
G — гибкость и адаптивность;
H — непрерывное совершенствование и рост компетенций.
Н
Н
G
G
F
Е F
D Е
С D
В С
А В
А
0 5 10 15 20
Номер, Фаза проекта, к Назначен- Приори- Желае Влия- Текущий Решение, дата
дата которой ный тет: мая ние на статус: решения
записи относится ответствен Критично дата проект Открыт,
232
описание ный для Высокий, разре- Назначен,
проблемы разреше- Средний, шения Предвари
ния Низкий тельное
проблемы решение,
Решен,
Утвер-
жден,
Отложен,
Действий
не
требуется
233
— организационные диаграммы проекта, описания позиций и планы
управления обеспечением проекта персоналом;
— принципы, методы урегулирования конфликтов и процедуры
поощрения;
— специальные навыки и квалификация определенных членов команды,
обнаруженные в процессе исполнения проекта;
— проблемы и способы их решения, зафиксированные в журнале
регистрации проблем проекта.
План управления проектом (обновления)
Одобренные запросы на изменения и корректирующие действия в качестве
обновлений можно внести в план управления обеспечением проекта персоналом,
являющегося частью плана управления проектом.
234
Приложение 9.1
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 D E F G Н
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 29 30 31 32
33 34 35 36 37 38 39 40
TOTAL:
237
Задание 3
Переместите итоговые баллы по каждой колонке Таблицы Эффективности Команды в
Диаграмму Эффективности Команды, заштриховав каждый из восьми сегментов.
Диаграмма Эффективности Команды
1 5 6 10 11 15 16 20
А
Н -
Задание 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