Управление проектами

Министерство образования и науки Российской Федерации

Федеральное государственное образовательное учреждение

высшего профессионального образования

"Сибирская государственный индустриальный университет”

Институт информационный технологий и автоматизированных систем

Кафедра автоматизации и информационных систем

Отчет по практической работе

"Управление проектами”

Выполнили: ст. гр. ИАТ-11

Ковров Д.А., Пащенко Н.А.,

Кукатов А.О., Соломатина Е.В.,

Терещенко В.А.

Проверил: доц. каф. АИС

Новокрещин Б.Г.

Новокузнецк, 2015

Содержание

Введение

Глоссарий

Внедрение информационных систем

Стандарты по управлению проектами

Пащенко Н.А. Методология внедрения MSF (Microsoft Solutions Framework)

Интеграция проекта

Кукатов А. О. Управление содержанием проекта

Управление временем

Терещенко В.А. Управление стоимостью

Соломатина Е.В. Обзор методологий внедрения

Заключение

Список используемой литературы

Введение

Управление проектами - деятельность, благодаря которой достигаются четкие цели проекта при соблюдении четкого баланса между объемами работ, ресурсами (например, денежными средствами, пространством, материалами и т.д.), временем, качеством работ и рисками. Ключевой фактор успеха - это наличие четкого плана, минимум отклонений от него, грамотного управления изменениями.

Результат работы - продукция предприятия или организации (результат проведенных исследований маркетологов, конструкторская и технологическая документация), решение различных задач производства.

Управление проектами - часть функционирования любого предприятия, иначе оно будет малоэффективным.

Глоссарий

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

Вероятность - степень возможности наступления некоторого события <https://ru.wikipedia.org/wiki/%D0%A1%D0%BE%D0%B1%D1%8B%D1%82%D0%B8%D0%B5_(%D1%82%D0%B5%D0%BE%D1%80%D0%B8%D1%8F_%D0%B2%D0%B5%D1%80%D0%BE%D1%8F%D1%82%D0%BD%D0%BE%D1%81%D1%82%D0%B5%D0%B9)>. Когда основания для того, чтобы какое-нибудь возможное событие произошло в действительности, перевешивают противоположные основания, то это событие называют вероятным, в противном случае - маловероятным или невероятным.

Декомпозиция - разделение целого на части. Также декомпозиция - это научный метод, использующий структуру задачи и позволяющий заменить решение одной большой задачи решением серии меньших задач, пусть и взаимосвязанных, но более простых. Декомпозиция, как процесс расчленения, позволяет рассматривать любую исследуемую систему как сложную, состоящую из отдельных взаимосвязанных подсистем, которые, в свою очередь, также могут быть расчленены на части. В качестве систем могут выступать не только материальные объекты, но и процессы, явления и понятия.

Заинтересованные стороны - это лица или группы лиц, чьи интересы затрагиваются результатами проекта.

Заказчики (customer) - организации или лица, желающие получить от решения бизнес-отдачу.

Закрытие проекта - завершение всех операций во всех группах процессов управления проектами для формального закрытия проекта или проектной фазы.

Идентификация - установление тождественности неизвестного объекта известному на основании совпадения признаков; опознание.

Интегрировать - это объединять в одно целое какие-либо элементы или процессы.

управление проект интеграция стоимость

Итерация - это организация обработки данных, при котором действия повторяются многократно, не приводя при этом к вызовам самих себя.

Модель жизненного цикла - это структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении жизненного цикла.

Модель процессов - описывает последовательность действий, осуществляемых в ходе реализации любых проектов.

Мониторинг и управление работами проекта - мониторинг и управление процессами инициации, планирования, выполнения и завершения проекта для достижения целевых показателей эффективности, намеченных в плане управления проектом.

Организация - объединение, группа людей (например, учреждение, предприятие, ассоциация и т.д.), с общей целью и определенными правилами сотрудничества в группе.

План проекта - это множество документов, которые должны быть составлены и проанализированы по содержанию и синхронизированы по временным параметрам этих планов.

Позиционирование - разработка комплекса маркетинга и рекламы, обеспечивающего предлагаемому товару четко отличное от других товаров и конкурентно способное положение на рынке, а также в организации целевых потребителей.

Потребители (пользователь, user) - люди, сталкивающиеся с работой этого решения в ходе своей профессиональной деятельности.

Производительность устройства <https://ru.wikipedia.org/w/index.php?title=%D0%9F%D1%80%D0%BE%D0%B8%D0%B7%D0%B2%D0%BE%D0%B4%D0%B8%D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D0%BE%D1%81%D1%82%D1%8C_%D1%83%D1%81%D1%82%D1%80%D0%BE%D0%B9%D1%81%D1%82%D0%B2%D0%B0&action=edit&redlink=1> - величина действия <https://ru.wikipedia.org/wiki/%D0%94%D0%B5%D0%B9%D1%81%D1%82%D0%B2%D0%B8%D0%B5_(%D1%84%D0%B8%D0%B7%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B0%D1%8F_%D0%B2%D0%B5%D0%BB%D0%B8%D1%87%D0%B8%D0%BD%D0%B0)> устройства <https://ru.wikipedia.org/wiki/%D0%A3%D1%81%D1%82%D1%80%D0%BE%D0%B9%D1%81%D1%82%D0%B2%D0%BE>, то есть отношение количества <https://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%BB%D0%B8%D1%87%D0%B5%D1%81%D1%82%D0%B2%D0%BE> произведённой работы (выпущенного продукта) ко времени их выполнения (выпуска), объём продукции (работы), производимой в единицу времени данным оборудованием в соответствии с его конструктивными особенностями, технической характеристикой и производственной квалификацией <https://ru.wikipedia.org/wiki/%D0%9A%D0%B2%D0%B0%D0%BB%D0%B8%D1%84%D0%B8%D0%BA%D0%B0%D1%86%D0%B8%D1%8F_(%D0%BE%D0%B1%D1%80%D0%B0%D0%B7%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5)> рабочих.

Риск - сочетание вероятности и последствий наступления неблагоприятных событий. Знание вероятности неблагоприятного события позволяет определить вероятность благоприятных событий. Так же риском часто называют непосредственно предполагаемое событие, способное принести кому-либо ущерб или убыток.

Создание плана проекта - координация всех планов проекта и их интеграция в единый согласованный документ.

Стоимость - основа количественных соотношений при добровольном обмене товарами между собственниками. Разные экономические школы природу стоимости объясняют по-разному: затратами рабочего времени, балансом спроса и предложения, производства.

Стратегия - это конкретный долгосрочный план достижения некоторой цели, а выработка стратегии - это процесс нахождения некоторой цели и составление долгосрочного плана. Такой подход основывается на том, что все возникающие изменения предсказуемы, происходящие в среде процессы носят детерминированный характер и поддаются полному контролю и управлению.

Траектория - линия <https://ru.wikipedia.org/wiki/%D0%9A%D1%80%D0%B8%D0%B2%D0%B0%D1%8F> в пространстве <https://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%BE%D1%81%D1%82%D1%80%D0%B0%D0%BD%D1%81%D1%82%D0%B2%D0%BE_%D0%B2_%D1%84%D0%B8%D0%B7%D0%B8%D0%BA%D0%B5>, вдоль которой движется тело, представляющая собой множество <https://ru.wikipedia.org/wiki/%D0%9C%D0%BD%D0%BE%D0%B6%D0%B5%D1%81%D1%82%D0%B2%D0%BE> точек, в которых находилась, находится или будет находиться материальная точка <https://ru.wikipedia.org/wiki/%D0%9C%D0%B0%D1%82%D0%B5%D1%80%D0%B8%D0%B0%D0%BB%D1%8C%D0%BD%D0%B0%D1%8F_%D1%82%D0%BE%D1%87%D0%BA%D0%B0> при своём перемещении в пространстве относительно выбранной системы отсчёта <https://ru.wikipedia.org/wiki/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0_%D0%BE%D1%82%D1%81%D1%87%D1%91%D1%82%D0%B0>. Существенно, что понятие о траектории имеет физический смысл даже при отсутствии какого-либо по ней движения.

Цель - создание и сплочение проектной группы на основе выработки единого видения проекта.

Эффективность - продуктивность использования ресурсов в достижении какой-либо цели.

Внедрение информационных систем

Информационная система (ИС) - это не программа, а достаточно сложный комплекс. Совокупность технологических и управленческих элементов.

Технологические элементы позволяют работать информационной системе, выполнять её функции. К ним относятся:

•        Информационная модель;

•        Кадровые ресурсы, отвечающие за формирование и развитие информационной модели;

•        Программный комплекс (ПК);

•        Кадровые ресурсы, отвечающие за конфигурирование ПК;

•        Аппаратно-техническая база;

•        Эксплуатационно-технические кадровые ресурсы.

•        Управленческими элементами являются:

•        Регламент развития информационной модели и правила внесения в неё изменений;

•        Регламент технической и пользовательской поддержки ПК;

•        Регламент внесения изменений в конфигурацию ПК и состав его функциональных модулей;

•        Регламент использования ПК и пользовательские инструкции;

•        Регламент обучения и сертификации пользователей.

Попытка внедрения информационной системы - это попытка создания работоспособного комплекса, который включает в себя все вышеперечисленные элементы.

Опыт внедрения ИС позволяет выявить некоторые факторы - факторы успеха, которые оказываются критичными для успешности проекта:

•        Наличие стратегии у клиента;

•        Реинжиниринг бизнес-процессов до внедрения;

•        Качество системы и команды консультантов;

•        Участие специалистов клиентов;

•        Ясные цели и четкие требования;

•        Наличие и соблюдение плана внедрения;

•        Участие руководства в проекте;

•        Получение быстрой и эффективной отдачи.

Преимущества методологии внедрения ИС

1.      Обеспечение базы для обучения новых сотрудников стандартным методам внедрения - быстрота подготовки внедренческих ресурсов;

2.      Сокращение внутренних расходов на организацию и реализацию проектов;

.        Улучшение взаимодействия и взаимопонимания между членами проектной группы;

.        Эффективность совместного использования ресурсов между проектами, командами.

Основные методологии

•        Microsoft - OnTarget;

•        Microsoft - MSF (Microsoft Solutions Framework);

•        Microsoft - Business Solutions Partner Methodology;

•        SAP - ASAP (Accelerated SAP) (Value SAP);

•        Oracle - Oracle Method;

•        J D Edwards - OneMethodology (PeopleSoft);

•        Citrix Systems - Citrix MetaFrame.

Методологии MSF и Oracle Method включаю в себя набор специфических стандартов, который определяет отдельные направления деятельности при создании и внедрении ИС.

Методология MSF включает в себя следующие дисциплины:

•        "Модель процессов MSF";

•        "Модель проектной группы MSF";

•        "Дисциплина управления проектами MSF";

•        "Дисциплина управления рисками MSF";

•        "Дисциплина управления подготовкой MSF".

Методология Oracle Method делится на:

•        CDM (Oracle Custom Development Method) - каким образом разрабатывать программный продукт;

•        AIM (Application Implementation Methodology) - каким образом внедрять программный продукт;

•        PJM (Oracle Project Management Method) - как управлять проектом разработки или создания программного продукта.

Любая методология включает в себя:

•        Структурирование комплекса работ - какие фазы включает в себя проект, в каком порядке эти фазы выполняются, какие работы на этих фазах предусматриваются;

•        Правила управления внедрением;

•        Построение команды внедрения.

Проект - это:

•        Уникальный процесс, состоящий из набора взаимоувязанных и контролируемых работ с датами начала и окончания и предпринятый, чтобы достичь цели соответствия конкретным требованиям, включая ограничения по времени, затратам и ресурсам (ISO/TR 10006 Guidelines to quality in Project Management);

•        Уникальная совокупность взаимосвязанных действий (работ) с определенными датами начала и окончания, предназначенных для успешного достижения общей цели (AIPM - Australian Institute for PM);

•        Уникальная совокупность скоординированных действий (работ) с определенными точками начала и окончания, предпринятая индивидуумом или организацией для достижения определенных целей с установленными сроками, затратами и параметрами выполнения (British standard 6079-1: 2000 PM);

•        Предприятие, которое характеризуется принципиальной уникальностью условий его деятельности (таких как цели (задачи), время, затраты и качественные показатели) и отличается от других подобных предприятий специфической проектной организацией;

•        Уникальный набор скоординированных действий с определенным началом и завершением, осуществляемых индивидуумом или организацией для решения специфических задач с определенным расписанием, затратами и параметрами исполнения (ICB - IPMA (International Competence Baseline - International Project Management Association))

Существует "три кита" на которых базируется любое проектное управление:

.        Должны быть определены центры интегративной ответственности, те, кто отвечают за общие характеристики исполнения проекта и достижения целей проекта. Это могут быть либо отдельные лица, либо, организационно - штатные структуры;

2.      Должна быть сформирована команда проекта;

.        Должна быть запущена система планирования и контроля исполнения проекта. Эта система должна реализовывать интегральное и прогнозирующие планирование и контроль.

Для описания развития проекта используются модели жизненного цикла. На основе ступенчато - шлюзовой модели жизненного цикла проекта разрабатываются иерархическая структура проекта и иерархическая структура работ проекта.

Иерархическая структура проекта (ИСП) - это перечень тех фаз и этапов из которых состоит проект и распределение процессов выполняемых работ по этим фазам и этапам.

Иерархическая структура работ (ИСР) - это детальное уточнение того, что должно быть выполнено в рамках каждого процесса.

Состав окружения проекта:

•        Заинтересованные стороны (бенефициары) проекта (подразделения и специалисты, на которых наибольшее влияние оказывают результаты проекта, контрагенты предприятия)

•        Факторы окружения (характеристики организации, степень знакомства с используемыми технологиями, квалификация сотрудников)

Для обеспечения связей между проектом и окружением проекта (действующими лицами) необходимо сделать их соучастниками проекта. Для этого предлагается несколько стандартных процедур:

•        Создание формальных комитетов по управлению проектами;

•        Включение заинтересованных сторон в совет (группу советников) по проекту;

•        Обеспечение участия менеджера проекта или членов команды в советах или комитетах организаций - заинтересованных сторон.

С действующими лицами можно каким-то образом разбираться "перетаскивать" их на свою сторону или не делать их большими противниками проекта, факторы же можно только учитывать.

Стандарты по управлению проектами

В стандартах описано что нужно делать. В корпоративных стандартах уточняется как можно выполнить те или иные функции с учетом особенностей организации.

Две основные организации, которые занимаются разработкой стандартов:

·        PMI - Project Management Institute (Институт управления проектами, США) PMBOK Guide - 2000 (4) - Project Management Body Of Knowledge - свод знаний по управлению проектами - стандарт ANCI (American Standards Institute);

·        APM - Association of Project Management (Ассоциация управления проектами, Великобритания) APM Body Of Knowledge;

Стандарт PMBOK содержит:

·        Основные понятия и действующие лица управления проектами;

·        Определения 9 областей знаний;

·        Определения 5 групп процессов;

·        Определения 39 процессов.

Основные действующие лица делятся на две группы:

.        Лица, связанные с управлением проектом;

2.      Исполнители работ.

Лица, связанные с управлением проектом это:

·        Менеджер (руководитель) проекта (Project Manager) - лицо, отвечающее за управление проектом;

·        Спонсор (куратор) проекта (Project Sponsor) - лицо, обеспечивающее ресурсы проекта и любую административную поддержку. Определяет приоритеты, обеспечивает взаимодействие с функциональными подразделениями, утверждает изменения. Во внутренних проектах обычно несет ответственность за результаты проекта;

·        Заказчик (потребитель) проекта (Project Customer) - лицо внутри или вне организации, которое будет использовать результаты проекта.

Как было сказано выше существует три основных действующих лица: заказчик, спонсор проекта и руководитель проекта. Это лица, которые определяют:

·        Какие ресурсы уйдут на проект;

·        За какое время проект будет выполнен;

·        Что в этом проекте будет реализовано.

Появляется так называемый "треугольник компромиссов". В нем сбалансированы пожелания всех сторон. После достижения утвержденного равновесия с заказчиком (на запрашиваемые возможности зафиксированы сроки и смета), любое изменение на одной из сторон треугольника влечет изменение на двух оставшихся. Такой подход служит удобным инструментом для нахождения компромиссов с заказчиком и поможет объяснить суть имеющихся ограничений.

Кроме действующих лиц, связанных с руководством проекта, существуют действующие лица, которые исполняют работы в рамках проекта:

·        Руководитель функционального подразделения направляет ресурсы в утвержденные проекты;

·        Функциональный лидер проекта объединяет усилия участников проекта в рамках функции или подразделения. Именно с ним взаимодействует менеджер проекта;

·        Лидер пакета работ объединяет усилия отдельных лиц в рамках пакета работ.

Высшее руководство компании определяет цели проекта. Спонсор проекта определяет те ресурсы, которые будут использоваться в проекте и определяет все изменения этих ресурсов. Менеджер проекта определяет "Кто?", "Что?" и "Когда?" должен сделать. Функциональный руководитель подразделения определяет на сколько хорошо может быть выполнена работа. Лидер пакета работ, организует несколько выполняемых работ.

Ключевые личные качества менеджера проекта:

·        Гибкость и приспособляемость;

·        Инициативность и качества лидера;

·        Агрессивность, уверенность в себе, умение убеждать, ясно выражать свои мысли, честолюбие, активность, энергичность;

·        Умение общаться, вести посредничество, объединять усилия;

·        Широкий кругозор, способность к обобщению;

·        Уравновешенность энтузиазм, воображение, непосредственность;

·        Способность соблюдать баланс технических, временных, стоимостных и человеческих факторов;

·        Организованность и дисциплина;

·        Способность и желание посвящать большую часть своего времени планированию и контролю;

·        Способность выявлять проблемы и принимать решения.

Области знаний PMBOK:

·        Управление интеграцией (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).

Действия, которые нужно выполнять объединены в 5 групп процессов:

·        Процессы инициации, каким образом проект запустить, как осуществлять переход от одного этапа проекта к другому;

·        Процессы планирования, как определить цепочку работ, содержание работ, каким образом оценить, время, стоимость выполнения работ;

·        Процессы контроля, процессы проверки как выполняются планы;

·        Процессы исполнения, реализация работ;

·        Процессы завершения, каким образом заканчивается проект.

С точки зрения управления проектами основная деятельность сосредоточена в области планирования.

Основные отличия PMBOK (3) - 2004г:

•        Внесены уточнения в различии между жизненным циклом проекта и жизненным циклом продукта;

•        Количество процессов управления проектом увеличено с 39 до 44;

•        Составлена карта процессов, показывающая их интеграцию;

•        Сделан акцент на новое содержание группы "Процессы мониторинга и Контроля";

•        Добавлен раздел, определяющий экспертные области, которые команда проекта должна понимать и использовать;

•        По временным параметрам", включая информацию об оценках затрат по проекту, выравниванию загрузки ресурсов и отчетах о ходе работ проекта, чтобы показать, как эти процессы влияют на календарный план проекта. Для наглядности добавлены рисунки;

•        Добавлена новая диаграмма Структурной Декомпозиции рисков (Risk Breakdown Structure).

Пащенко Н.А. Методология внедрения MSF (Microsoft Solutions Framework)

MSF - это достаточно универсальная методология, которая может быть использована для традиционного программного обеспечения, для создания и внедрения информационной системы, для создания распределенных сетевых приложений, то есть особых ограничений по внедрению данной методологии не существует.

Методология представляет собой набор из пяти дисциплин, каждая из которых выполняет особенности той или иной деятельности нужной для создания и внедрения некоторого решения. Базовой основополагающей является решения процесса. Модель жизненного цикла проекта по методологии по MSF представляет собой спиральную модель. Весь жизненный цикл, делится на под циклы, каждый из которых состоит:

.        Разработка концепции;

2.      Планирование;

.        Разработка того, что создается в данном проекте;

.        Стабилизация;

.        Внедрение.

После этих этапов, цикл может повторяется, если программируются требования к той системе, которую мы создаем.

Вехи имеют две смысловые нагрузки:

•        точки синхронизации работ;

•        точки смены производственной ответственности.

Главные вехи служат точками перехода от одной фазы к другой. Они также определяют изменения в текущих задачах ролевых кластеров. В MSF используются обобщенные главные вехи, большинство из которых применимо к любому типу IT-проектов.

Промежуточные вехи показывают достижение в ходе проекта определенного прогресса и расчленяют большие сегменты работы на меньшие, обозримые участки. MSF содержит рекомендации по определению промежуточных вех.

Главные вехи - это моменты жизненного цикла проекта, когда полученные результаты синхронизируются членами проектной группы друг с другом и с ожиданиями заказчика. В этот момент заказчиком, заинтересованными сторонами и проектной группой производится формальный анализ достигнутого прогресса. Успешное прохождение главной вехи знаменует согласие проектной группы и заказчика продолжать далее работу над проектом.

Итеративность подхода, означает, что наша система в принципе должна создаваться в виде отдельных версий. Microsoft рекомендует создание базовой версии и дальнейшее ее использование. Версии решения не обязательно следуют одна за другой. Зрелые программные продукты обычно развиваются по нескольким направлениям параллельно.

Ни один документ в проекте, ни появляется в законченном виде, все документы проекта претерпевают изменения. Одна из концепции MSF, это создание живой документации. "Живые" документы (living documents) должны изменяться по мере эволюции проекта. Пересмотр функциональности, сетевых графиков работ, планов, спецификаций, требований и других проектных артефактов не прекращается до конца проекта и производится после каждой итерации.

Виды документов:

•        описания высокоуровневых "подходов” ("approaches”);

•        базовые (предварительные) версии проектных документов на самых ранних этапах (baseline early);

•        Детальные планы.

Все изменения в уже принятые документы в рамках одной итерации (например, утверждённое ТЗ) вносятся посредством компромиссов проектной группы и согласно технологии управления изменениями. Часто имеет смысл отложить эти изменения до следующей версии, дабы не допускать разрастания рамок проекта и срыва сроков сдачи текущей версии.

Преимущества интегрированной модели процессов:

·        Сосредоточение на нуждах предприятия;

·        Предприятия (и в особенности руководители предприятий) обычно рассматривают разработку и внедрение решения как нечто неразделимое. Даже если разработка решения прошла удачно, заказчики не увидят отдачи до тех пор, пока оно не внедрено на предприятии;

·        Улучшение взаимодействия с командой сопровождения;

·        Зачастую команда разработчиков создает решение, не уделяя должного внимания вопросам его эксплуатации. Это приводит к низким показателям производительности (performance), доступности (availability) и управляемости (manageability) решения. Интегрированная модель процессов MSF обеспечивает процесс передачи ответственности от команды разработчиков к команде сопровождения сквозь ряд последовательных вех, а не как одномоментный перенос нагрузки.

Проектная группа включает в себя следующие группы: заказчики; потребители. Заказчики (customer) - организации или лица, желающие получить от решения бизнес-отдачу. Потребители (пользователь, user) - люди, сталкивающиеся с работой этого решения в ходе своей профессиональной деятельности. Участие заказчика является условием успешности IT-проектов. MSF предоставляет заказчику широкий спектр возможностей для уточнения и модификации проектных требований и установки контрольных точек (вех) для мониторинга работы над проектом.

В свою очередь, это требует затрат времени со стороны заказчика и взятия им на себя определенных обязательств. Заинтересованные стороны (stakeholders) - это лица или группы лиц, чьи интересы затрагиваются результатами проекта:

•        Начальники отделов, чей персонал и режим работы будут изменены в результате внедрения разрабатываемого решения;

•        Персонал сопровождения решения, на который будет возложена ответственность за его функционирование, а также персонал сопровождения других приложений, затрагиваемых внедрением решения;

•        Функциональные руководители (functional managers), обеспечивающие проектную группу необходимыми ресурсами.

За успех проекта ответственна вся команда, но каждый из ее ролевых кластеров ассоциирован с одной из шести целей и работает над ее достижением:

·        "Управление продуктом" (product management);

·        "Управление программой" (program management);

·        "Разработка" (development);

·        "Тестирование" (test);

·        "Удовлетворение потребителя" (user experience);

·        "Управление выпуском" (release management).

Интеграция проекта

Интегрировать - это объединять в одно целое какие-либо элементы или процессы. ИНТЕГРАЦИЯ (integratio - восстановление, восполнение, от integer - целый). Управлять интеграцией в проектном менеджменте означает выполнять действия и процессы, направленные на объединение и координацию процессов и действий, необходимых для достижения целей проекта и удовлетворения ожиданий его заинтересованных сторон.

Области знаний в управлении проектами зависят друг от друга, процессы управления проектами пересекаются между собой, проектная деятельность может быть связана с результатами текущей деятельности организации и, наоборот, поэтому важно управлять данными взаимозависимостями с целью принятия своевременных решений относительно конфликтов ресурсов, конфликтов целей и влиянием на проект различных заинтересованных сторон.

Кроме того, управление интеграцией включает в себя действия, необходимые для интеграции различных документов проектной деятельности. Процессы управления интеграцией проекта. К процессам управления интеграцией проекта относят следующие процессы:

. Разработка Устава проекта;

. Разработка плана управления проектом;

. Руководство и управление исполнением проекта;

. Мониторинг и управление работами проекта;

. Осуществление общего управления изменениями;

. Завершение проекта или фазы.

Управление интеграцией проекта включает в себя действия (процессы и операции), необходимые для выявления, определения, комбинирования, унификации и координации различных процессов и операций по управлению проектами, включает в себя процессы, которые обеспечивают координацию всех областей и элементов проекта.

·        Создание плана проекта - координация всех планов проекта и их интеграция в единый согласованный документ;

·        Исполнение плана проекта - выполнение включенных в план работ;

·        Интегрированный контроль изменений - координация изменений в проекте.

Ориентировочный состав плана проекта:

·        Устав (описание, определение проекта) (Project Charter);

·        Описание стратегии управления проектом;

·        Определение содержания и рамок проекта (Scope) ‏;

·        Иерархическая структура проекта (WBS - Work Breakdown Structure) ‏;

·        Для каждого важного результата - стоимость, даты начала и окончания, ответственные лица;

·        Базовый план для контроля проекта (baseline) ‏;

·        Ключевые контрольные точки (milestones) ‏;

·        План управления содержанием проекта;

·        План управления персоналом проекта;

·        План управления рисками;

·        План управления качеством;

·        План управления взаимодействием.

План проекта - это множество документов, которые должны быть составлены и проанализированы по содержанию и синхронизированы по временным параметрам этих планов.

Виды планов проекта:

·        Предварительный план проекта - готовится менеджером проекта до или на начальной стадии проекта;

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

Руководитель проекта не может изменять базовый план. Изменяет базовый план спонсор, заказчик или Комитет по управлению изменениями на основе установленной процедуры утверждения запросов на изменения.

Рабочий (текущий) план проекта - изменяется руководителем проекта по мере выполнения проекта.

Характеристики планов (степень детализации) определяются корпоративной методологией планирования или контрактом. Реальное исполнение проекта практически всегда отличается от запланированного.

При небольших отклонениях предпринимаются корректирующие воздействия. При больших отклонения корректируется план через установленные процедуры утверждения запросов на отклонения.

Состав процессов Управления интеграцией в PMBOK 2004:

·        Разработка Устава проекта - разработка Устава проекта, формально авторизующего проект или фазу проекта;

·        Разработка предварительного описания содержания проекта - разработка предварительного описания содержания проекта, включающего в себя самое общее изложение содержания;

·        Разработка плана управления проектом - документирование операций, необходимых для определения, подготовки, интеграции всех вспомогательных планов в план управления проектами и их координации;

·        Руководство и управление исполнением проекта - выполнение работы, определенной в Плане управления проектом для выполнения требований, определенных в описании содержания проекта;

·        Мониторинг и управление работами проекта - мониторинг и управление процессами инициации, планирования, выполнения и завершения проекта для достижения целевых показателей эффективности, намеченных в Плане управления проектом;

·        Общее управление изменениями - обработка всех запросов на изменения, утверждение этих изменений и управление ими для оптимизации результатов поставки и активов организационного процесса;

·        Закрытие проекта - завершение всех операций во всех группах процессов управления проектами для формального закрытия проекта или проектной фазы.

Состав плана управления продуктом:

·        Процессы управления проектами, отобранные командой управления проектом;

·        Уровень внедрения каждого выбранного процесса;

·        Описание инструментов и методов, используемых для осуществления этих процессов;

·        Как выбранные процессы будут использоваться для управления конкретным проектом, включая зависимости и взаимодействия между этими процессами и ключевые входы и выходы;

·        Как будет выполняться работа для достижения целей проекта;

·        Как будут наблюдаться и контролироваться изменения;

·        Как будет осуществляться управление конфигурацией;

·        Как будет поддерживаться и использоваться целостность базовых планов исполнения;

·        Потребность и методы коммуникации между участниками проекта;

·        Жизненный цикл выбранного проекта;

·        Основные анализы, проведенные руководством в отношении содержания, объема и сроков для облегчения обсуждения открытых проблем и решений, ожидающих утверждения.

Таблица

Кукатов А. О. Управление содержанием проекта

Данная дисциплина реализуется следующими процессами:

1.      Инициация - нужно понять, требуется ли выполнять проект, и что он сможет принести в итоге. На выходе - устав проекта, менеджер проекта, ограничения и предположения.

Устав проекта - документ верхнего уровня, дающий полную характеристику проекта. Отражены аспекты, которые дают понять, что создается и для чего. Состоит из разделов:

·        описание бизнес потребностей: потребности заказчиков; потребности бизнеса.

·        предварительное описание продуктов проекта: описание того, что нужно будет внедрять, не обращая внимания на ограничения, которые накладываются условиями конкретных работ;

·        описание границ проекта.

Определяется: кто руководитель, кто заказчик, сроки разработки более детальных документов описания проекта. Более устав проекта ничего не содержит, его цель - задать концепцию проекта.

Разработка более подробной документации - это планирование содержания проекта. На этом этапе:

·        анализ продукта;

·        просмотр альтернативных вариантов реализации;

·        определение более выгодного варианта;

·        принятие решение, как будет выглядеть система.

Устав проекта трансформируется в более подробный документ - Определение проекта, который в течении работы изменяется. Содержит:

·        обоснование проекта - описание, почему проект возник;

·        описание продукта проекта;

·        результаты, которые нужно достигнуть;

·        определение целей и критерий различных фаз и этапов проекта;

·        фиксирование границ проекта;

·        описание стратегического подхода к исполнению - в данный момент определяется, какие процессы управления проектами будут использоваться.

В результате - Содержание и План управления содержанием. В плане управления содержанием описывается:

·        Как будет отслеживаться содержание проекта;

·        как будут инициироваться и утверждаться изменения;

·        каким образом задокументировать изменения.

Уточнение содержание - формирование иерархической структуры работ. В качестве методики работ можно использовать:

·        декомпозицию (разделение работ на более мелкие);

·        наборы шаблонов, для агрегированных работ.

На выходе - иерархическая структура работ - перечень тех работ, которые нужно выполнить в проекте. Не описано, сколько требуется ресурсов, времени и прочее. Иерархическая структура работ появляется не только из работ, но и из декомпозиции создаваемого продукта. Учитываются действия необходимые для реализации проекта, а также действия для реализации отдельных элементов.

Иерархическая структура работ отображается в виде диаграммы Ганта, предусматривающая разделение по времени. Все, что в нее включено, - это то, что нужно делать вовремя выполнения проекта.

В иерархическую структуру включаются различные события, которые позволяют фиксировать достижение важных результатов. События бывают:

·        контрольные - достижение конкретного результата;

·        интерфейсные - определяют изменение некоторой ситуации в проекте.

Инициатор проекта - лицо, объясняющее для чего нужно реализовывать проект. Он формулирует устав проекта.

Менеджер проекта назначается в том случае, если проект заинтересует руководство организации.

3.      Контроль (подтверждение содержания: достигнуты ли цели);

4.      Подтверждение содержания - проверка сделанного;

5.      Контроль изменения содержания - отслеживания изменений в содержании.

Причины изменения содержания:

·        изменения во внешней среде;

·        ошибки и опущения при составлении содержания;

·        появление новых технологий;

·        изменения бизнес-потребностей;

·        непредвиденные риски.

Предусмотрены процедуры, позволяющие вносить изменения согласованно.

Цель управления содержанием проекта - зафиксировать те работы, которые нужны для достижения целей. Нужно не включить ничего лишнего в проект, так как все это будет напрасно.

Содержание проекта делится на разделы:

.        Содержание работ.

2.      Содержание продукта - характеристики системы, которая разрабатывается.

Управление временем

Основа любого управления - разработка перечня работ. Фазы проекта и те работы что выполняются зависят от принятой методологии информационной системы. Нужно понимать отличия между ними.

Рассмотрим методологии внедрения Microsoft, People Soft и Oracle. Все они имеют сходства и различия.

Методология Microsoft:

·        OnTarget;

·        MBS.

Предназначены для внедрения информационных систем. По структуре подходят для внедрения систем класса 1C, BEST и прочее.

Отличаются последняя и первая стадии. MBS начинается с диагностики, а OnTarget с подготовки проекта. Ее суть в том, что заказчик должен знать, что он хочет получить в итоге. MBS появилась позже: ориентирована на то, что создается решение, которое обеспечит достижение некоторых бизнес-целей.

Переход от одной методологии к другой связан с тем, что заказчику неинтересно получать продукт, который лишь формально отвечает его требованиям.

Отличия MBS от OnTarget в целях:

.        В OnTarget формируется проектная документация; MBS - понять, что нужно заказчику;

2.      В MBS большая часть действий связана со сбором и анализом данных.

Анализ в OnTarget:

·        Подготовка команды проекта;

·        Разработка функциональных требований к системе.

Анализ в MBS:

Проработка спецификации и понять, как они помогут удовлетворить потребности заказчика.

Выполняемые работы на этапе "Анализ" отличаются кардинально друг от друга. В OnTarget, например, нужно подготовить рабочую группу для работы над проектом. В MBS - на первом этапе осуществляется поверхностное обучение пользователей работе с системой.

По результатам анализа получаются спецификации системы.

Дизайн в OnTarget и MBS

Цель: осуществление проектирования того решения, которое будет внедрено. Формируется техническое задание и эскизный проект. Эскизный проект необязателен. В MBS дизайн разделен на два этапа: разработка концептуального дизайна (формируется в терминах бизнеса, чтобы быть понятным заказчику); разработка детального дизайна (формируется в терминах, понятных для ИТ-специалистов).

Разработка и тестирование в OnTarget Сводится к созданию системы и проверки ее работоспособности.

Разработка и тестирование в MBS: Не только создается продукт, проверка функций, но и осуществляется наполнение системы информацией (реальной), фактически заканчивается процедура создания проекта.

В MBS также есть требования к разделению сред, в которых будут проводиться работы.

Развертывание в OnTarget: Отлаженная система разворачивается на технических средствах заказчика.

Развертывание в MBS: Фактически, проект будет завершен. Проводятся приемки и осуществляется переход к сопровождению системы.

Опытная эксплуатация в OnTarget: Имеется проверенное ПО, которое развернуто на средствах заказчика. Наполнение реальной информации и проверка работоспособности системы. По результатам устраняются выявленные недостатки и проект завершается.

Начальное сопровождение в MBS: Проверка эффективности решение: как можно улучшить его. В итоге, по методологии OnTarget работа ведется более интенсивно, следовательно, и проект будет завершен в более ранние сроки. Эти обе методологии предоставляются партнерам компании Microsoft, есть соответствующее ПО.

Методология компании People Soft - OneMethodology

Спектр систем, предоставляемых People Soft, очень широк. Заказчик всегда имеет выбор. Методология не привязана к конкретным типам систем.

Цели:

Выбрать из имеющегося набора инструментов что-то наиболее подходящее.

Этапы:

·        Рамки внедрения - решение задач описания проекта. Фактически - создание Устава проекта. Определение информации в системе, а также интерфейса и внешних программ;

·        Модель - осуществляется анализ деятельности компании; проверка того, как поддержать ее инструментальными средствами; определение, что нужно доработать; составляется план доработок;

·        Конфигурирование - пилотный проект, то есть попытка внедрения решения на ограниченных данных и рабочих местах; определяется, подходит ли решение; ввод исходных данных; конфигурирование и доработка ПО; разработка пользовательской документации;

·        Запуск в эксплуатацию - проверка рабочей конфигурации; тренинг конечных пользователей; настройка производительности; запуск системы;

·        Развитие - оптимизация процессов; анализ недостающей функциональности; передача системы.

Данная методология не очень сильно ориентирована на разработку с нуля, скорее на доработку чего-либо.

Методология Oracle

Компания Oracle много внимания уделяет множеству дисциплин, которые касаются работе с ИТ-решениями и программными средствами. Там рассказывается, как управлять ПО, как разрабатывать архитектуру сервисов и прочее.

Архитектура предприятия - описание того, как бизнес связан с информационным обеспечением предприятия; какие используются технические средства. Позволяет планировать развитие информационных систем.

Метод внедрения приложений:

Имеется ввиду, что они уже разработаны, но нужно их внедрить. Используется принцип здравого смысла:

.        Попытка описать общее представление, как осуществляется деятельность, какие средства используются.

2.      Детальное описание того, как осуществляется деятельность. Появляется возможность посмотреть, как имеющиеся средства могут поддерживать детальное описание деятельности.

.        Процедура демонстрации.

.        Оценка того, сколько будет стоить доработка программного обеспечения.

Методология состоит из задач, каждая из которых имеет свой вход и выход, образуя цепочки. Выполнение такой цепочки позволяет решить определенную проблему. Цепочки называются процессами.

Коротко про бизнес-процессы:

1.      Определение требований - считается, что те требования, которые будут определены, в последующем не расширяется, но изменения внутри возможны.

2.      Отображения требований - нужно понять, как эти требования будут реализованы в системе.

3.      Разработка дополнительной функциональности;

4.      Конвертация данных - определение какая информация из какой системы будет "перекачана" в новую систему;

5.      Документирование;

6.      Тестирование;

7.      Обучение: готовится группа и осуществляется обучение пользователей;

8.      Ввод в эксплуатацию.

Если нужно работать с этой методологией, то потребуется освоить средство Oracle OBM.

Фазы проекта:

.        Определение;

2.      Анализ операций;

.        Проектирование;

.        Переход к эксплуатации.

Методика предусматривает выделение составляющих:

·        Планирования;

·        исполнения и контроля;

·        завершения.

Выделяются на каждой фазе проекта. По методологии нужно иметь высококвалифицированных специалистов.

Терещенко В.А. Управление стоимостью

1.      Стратегия развития;

2.      Стратегия внедрения;

.        Оценка эффективности проектов внедрения.

Нужно решить проблему систематизации.

.        Любое развитие информационной системы направлено на то чтобы каким, то образом улучить процессы деятельности организации. По этой причине можно ввести 2 оси координат, в которых и рассматривать все имеющиеся ситуации и в эти оси координат ложится развитие информационной системы.

Для того чтобы реализовать процессы мы можем использовать некоторые средства. Средства реализации делятся на 2 группы:

·        Первая группа разрабатываемая информационная система.

·        Вторая группа типовое проектное решение, это и есть две реализации процесса проектирования.

Мы должны управлять группой своих собственных разработчиков, кто будет реализовывать проект. Должны планировать все процессы изменения ситуации в рамках жизненного цикла со спиральной моделью.

В том случае, когда нам все понятно существует четкое представления об имеющихся бизнес процессах, переход осуществляется что в какой-то траектории у нас развиваются имеющиеся средства и уходим на типовое проектное решение, которое можем наращивать функциональные возможности.

Есть такой вариант мы фактически не улучшаем характеристики управления нашей организации, но переходим к некоторому типовому проектному решению. Ситуация, часто встречающая чтоб улучить имидж компании, чтоб быть не хуже, чем конкуренты.

Другой случай, когда мы работаем на некоторой промышленной системе, когда есть некоторое типовое проектное решение внедренное, но эффективность работы этой системы оказывается недостаточной чтоб ее уличить, повысить. Здесь мы работаем с группой, внедрение которой должны корректно управлять. Нужно проектировать собственную систему, которая будет реализована в собственной компании.

Как выбрать вариант развития информационной системы, каким образом принять решение и по какой траектории двигаться. Для того чтобы принимать такого рода решения необходимо учитывать целую массу информации. Финансы, персонал и инфо структура затем технические критерии, организационные критерии и насколько существенно придется изменять бизнес процесс и насколько существенно придется изменять деятельность. Дальше мы можем, принимать решения по какой траектории будем двигаться. Эти задачи можно решать если компания готова к их решению. В том случае если не выполнены некоторые условия, определяющие готовность или степень зрелости компании, то ей лучше не заниматься. Во-первых, должна быть стратегия бизнеса, нужно понимать куда наш бизнес движется и каким образом можем поддерживать этот бизнес через год, через два и т.д.

Во-вторых - это человеческий фактор. Должны быть зафиксированы этапы мы должны понимать, что оптимизируем.

.        Стратегии внедрения информационной системы. Стратегии определяют, куда мы будем идти, как будем организовывать наши проекты. Определяем общий характер нашей деятельности. Хоть и проекты разные можно найти несколько характеристик, комбинируя которые, можно написать любой проект. Характерны некоторые особенности, кокой то проект можно описать в виде набора блоков. По средствам привлечения внешнего партнёра при сохранении старых бизнес процессов, при адаптации особенности системы бизнеса. Из этого набора можно составить характеристику проекта, насколько проект успешен к чему можем прийти в результате этого проекта. Что такое эффективность внедрения системы? Обеспечивает ли некоторая стратегия воздействия положительная на те или иные факторы обеспечивает ли она возможность парировать всякого рода влияния возникающие и на сколько сложно это сделать в рамках данной стратегии.

Внедрение информационной системы своими собственными силами. Это всегда будет проект, сопряжённый с высокими рисками и будет ли он достаточно эффективен. Почему сопряжён, большими рисками? Если это бригада собственная, то мы ее компонуем и есть те кто в области внедрения обладают недостаточными знаниями. Когда внутри своей компании формируем некоторую команду мы отвлекаем людей от их основной деятельности, сразу оказываются ограниченные возможности, ресурсы, поэтому проект оказаться рискованным.

Второй блок стратегии, это решение задач оптимизации бизнес процесса, перед тем как мы будем осуществлять внедрение системы или в процессе внедрения информационной системы. Оптимизация бизнес процесса во всех случаях задача рискованная, потому что она заставляет существенно изменять деятельность компании, а любая компания любой коллектив этому противиться.

Изменение бизнес процесса под логику системы, когда мы насильно изменяем деятельности компании. Наша система оказывается стандартной, с которой могут работать со стандартным функционалом, все изменения доработки проходят в автоматическом режиме и не нужно иметь уникального специалиста. На этапе внедрения проект, оказывается, может оказаться не слишком эффективным.

Теперь каждый проект можно рассматривать в нескольких блоках в его реализации. Эти блоки обладают четко своими характеристиками. Появляется возможность на основе этих блоков оптимизировать информацию.

Оценка эффективности проектов, которые реализуем и для его решения можно использовать средства и методы, относящиеся к двум областям.

Первая область - когда мы пытаемся дать общую оценку характеристик нашего проекта, мы хотим получить его общую оценку его эффективности в деньгах.

Вторая область - когда мы не пытаемся оценить вообще наш проект, когда мы пытаемся определить на что на какие аспекты деятельности информационной системы, повлияет это способ, который называется позиционирование эффекта.

Первый показатель эффекта - это стоимость. Характеристика, которую можно использовать для того чтобы оценивать проект, для того чтоб сравнивать проект и можно сделать выводы том что проект является прибыльным или не является прибыльным. Когда решаем вопрос реализовывать проект или нет если это в нашей власти, то все зависит от нашей позиции в компании. Нужно обратить внимание, что в этом показателе присутствуют коэффициенты, которые не просто вычисляются, эти коэффициенты связаны с дисконтированием денежных средств.

8. Управление рисками

1. Управление временем;

. Управление стоимостью.

Два основных показателя, по которым оценивать исполнение проекта.

Управление временем подразумевает нескольких процессов, концентрируются в области планирования и один процесс относится к области контроля. Вначале должны запланировать временные характеристики.

Первый процесс определение состава работ - идентификация и документальное оформление отдельных работ, определенных в ИСП.

Должны более детально определить из каких элементов будут состоять, работы, выполняемые в проекте, т.е. мы детализируем структуру работ, которую составили на предыдущем этапе.

Определение последовательности работ все работы, сваленные в кучку для того чтобы составить временной план нашего проекта мы должны распределить его во времени.

Процесс рисунка операции потому что длительность операции не всегда может быть оценена как характеристика и длительность работы за частую вычисляется через используемы ресурсы при исполнении данной работы, таким образом приходиться оценивать ресурсы. Разработка описания и контроль. На этапе планирования воздает много работы. Чтобы спланировать работу на нее уходит где-то 30% планирования.

Процесс определения состава работы иерархическая структура проекта, описание содержания проекта, ограничения, предположения. Декомпозиция осуществляется работ. На выходе получится детализированный список, более детальное представление о том, как будет выглядеть иерархическая структура работ, разделённая на элементы соответствующим отдельным операциям. Если проект большой, то лучше осуществлять все последовательно. Разобраться, что мы будем делать, потом определить, сколько это все будет времени занимать.

Определить какие связи между работами существуют, каким образом можем построить цепочки действий той технологии, которую мы используем для реализации своего продукта. Для того чтобы описать такого рода информацию обычно используются диаграммы. Диаграммы могут использоваться различного вида. Стрелочные, условные, предшествующие, сетевые их существует достаточно много. Есть две операции:

·        операция на дугах;

·        операция в узлах.

Содержательные характеристики, где связи могут принадлежать одному из нескольких типов, тип финиш - старт означает что работа последующая будет выполнена после того как закончена предыдущая работа. Часто встречающая. Тип финиш - финиш, работа должна закончиться не раньше предыдущей работы. Старт - страт работа начинается не раньше того, как начнется какая-то другая работа.

Какого типа могут быть операции. Для планирования временных планирований нашего проекта вполне достаточно задать время исполнения операции и это время будет учитываться.

И второй тип, когда операция относится к другому типу, который называется производительность. Т.е. длительность операции мы должны пересчитывать и определять через производительность тех ресурсов, которые мы выделили на исполнения этой операции.

В основе построения вероятностных оценок лежит методика Перт - для того чтобы эффективно управлять исполнением двух проектов. Для проекта можно рассчитывать с помощью метода математического анализа, они связаны с анализом графов.

Программа выделяет те критические пути - это и есть основные точки, на которых должен сконцентрироваться менеджер проекта, он должен отслеживать в основном эти работы, если работы будут идти по плану, то уложится в сроки.

Соломатина Е.В. Обзор методологий внедрения

Стоимость проекта - это стоимость ресурсов, вложенных в проект,

Примеры:

.        Трудовые ресурсы;

2.      Машины, оборудование;

.        Материалы;

.        Денежные средства;

.        Энергетические ресурсы;

.        Информационные ресурсы;

.        производственные площади.

Планирование ресурсов - какие ресурсы необходимы для выполнения работ проекта.

Оценка стоимости - определение стоимости заданного количества ресурсов.

Бюджетирование - составление бюджета по некоторым операциям, пакетам работ и по проекту в целом.

Контроль стоимости - оценка исполнимости бюджетирования.

Ресурсы

Отличия в задании ресурсов наиболее значительны. Ресурсы подразделяются на возобновляемые (люди, механизмы) и не возобновляемые (материалы). В большинстве пакетов те и другие задаются вместе, отличия обычно заключаются лишь в задании стоимости их использования - в час или за единицу. В Spider Project эти виды ресурсов задаются отдельно. При этом можно задать, что возобновляемые ресурсы потребляют материалы (пример: автомобиль потребляет бензин). Тогда назначив ресурсы на исполнение операций проекта, вы автоматически учитываете попутное потребление необходимых материалов. Кроме отдельных ресурсов можно задать мультиресурсы и пулы.

Мультиресурсы - это группы ресурсов, которые выполняют работы вместе (например, бригада, экипаж, автомобиль с шофером и т.д.). Мультиресурсы можно назначать на исполнение операций целиком, что означает назначение всех ресурсов, которые в них входят. Пулы - это группы взаимозаменяемых ресурсов. Основное отличие от подходов, используемых в других пакетах, в которых имеется skill scheduling, заключается в том, что ресурсы пула могут иметь различные производительности.

Метод освоенного объёма (Earned Value Technique, Earned Value Management) - система методик, объединенных под общим названием, использующихся для измерения и контроля эффективности выполнения проектов. Метод основан на использовании ряда числовых показателей, рассчитываемых по ходу проекта. Информационное обеспечение данного метода опирается на данные бухгалтерского и управленческого учёта и последующем калькулировании себестоимости проекта, разложенного в рамках финансового планирования по видам затрат на единой временной шкале. В рамках контроля исполнения отслеживается поэтапное исполнение соответствующих этапов. Используется в методологиях финансового управления проектами (отдельными) или в рамках контроллинга крупных проектно-ориентированных организаций, но данного метода недостаточно для финансового управления всей проектной организации, где должны быть учтены все (параллельные) проекты и полная организационная структура предприятия.

Постоянное отслеживание освоенного объёма и других показателей позволяет менеджеру проекта прогнозировать как успешность его завершения, так и риски выхода из намеченных сроков, бюджета и др.

·        EV - освоенный объём, ОО (Earned Value). Реально выполненный объём работ, указанных в бюджете. Равен произведению доли выполнения проекта или его части и запланированного бюджета по завершению: ;

·        AC (ACWP) - фактическая стоимость, также Фактическая стоимость выполненных работ, ФС (Actual Cost, Actual Cost of Work Performed). Равна реальной стоимости выполненных работ или их части за указанный период времени.

·        PV - плановый объём, ПО (Planned Value);

·        CV - отклонение по стоимости, ОПС (Cost Variance). Отклонение по стоимости равно разнице между освоенным объёмом и фактической стоимостью: ;

·        SV - отклонение по срокам, ОСР (англ.  <https://ru.wikipedia.org/wiki/%D0%90%D0%BD%D0%B3%D0%BB%D0%B8%D0%B9%D1%81%D0%BA%D0%B8%D0%B9_%D1%8F%D0%B7%D1%8B%D0%BA> Schedule Variance). Равно разнице между освоенным и плановым объёмами: ;

·        CPI - индекс выполнения стоимости, ИВС (англ.  <https://ru.wikipedia.org/wiki/%D0%90%D0%BD%D0%B3%D0%BB%D0%B8%D0%B9%D1%81%D0%BA%D0%B8%D0%B9_%D1%8F%D0%B7%D1%8B%D0%BA> Cost Performance Index). ;

·        SPI - индекс выполнения сроков, ИВСР (англ.  <https://ru.wikipedia.org/wiki/%D0%90%D0%BD%D0%B3%D0%BB%D0%B8%D0%B9%D1%81%D0%BA%D0%B8%D0%B9_%D1%8F%D0%B7%D1%8B%D0%BA> Schedule Performance Index).

Следующий показатель - ACWP (Actual Cost of Work Performed) - фактическая стоимость выполненных работ. Как и в случае с BCWS, PMI также дал этому показателю новое имя - Actual Cost, или сокращенно AC (что на русский может быть переведено как "фактические затраты". - Прим. ред. ). При расчете этого показателя объединяются не планируемые, а реальные затраты проекта, произведенные за рассматриваемый период времени. По окончании каждого отчетного периода общий объем затрат проекта за этот период добавляется к общему объему затрат за предыдущие отчетные периоды.

Earned Value, или сокращенно EV ("освоенный объем"). Этот показатель дал название и методу освоенного объема, и отчету по освоенному объему. Планируемая стоимость выполненных работ BCWP (EV), как и два предыдущих показателя, - это объединение денежных средств по рассматриваемому периоду времени. Выше мы указали, что каждая из элементарных работ проекта имеет планируемую бюджетную стоимость и сроки выполнения.

BCWP - это объединение плановых стоимостей, фактически выполненных за отчетный период работ. Например, если выполнена работа с плановой (сметной) стоимостью 1000 долл., то BCWP для этой работы по ее окончанию будет равен 1000 долл. Так же, как и для других показателей, чтобы получить BCWP проекта, суммируются BCWP всех работ, выполненных к окончанию отчетного периода.

Сравнивая освоенный объем и фактическую стоимость, т.е. стоимость по бюджету и стоимость по факту тех работ, которые уже выполнены, можно определить, нет ли перерасхода средств в проекте.

CV (отклонение по стоимости, Cost Variance) - это разность между освоенным объемом и фактической стоимостью: CV = EV - AC.

Если CV <0, в проекте имеет место перерасход средств.

Если CV> 0, в проекте имеет место экономия бюджета.

Физический смысл расчета показателя CV - сравнение реально выполненных работ в плановых (бюджетных) и фактических деньгах.

SV (отклонение по расписанию, Schedule Variance) - это разность между освоенным объемом и плановым объемом: SV = EV - PV.

Если SV <0, в проекте имеет место отставание от графика выполнения работ.

Если SV> 0, в проекте имеет место опережение графика выполнения работ.

Физический смысл расчета показателя SV - сравнение в плановых (бюджетных) деньгах объема работ, который реально выполнен (EV), и объема работ, который должен быть выполнен согласно графику работ.

9.      Стратегия развития информационных систем

·        Планирование и управление рисками;

·        Идентификация рисков;

·        Качественный анализ рисков;

·        Количественный анализ рисков;

·        Планирование реагирование на риски.

Риски известные и риски не известные

Известные риски - это те риски, которые идентифицированы, могут быть подвергнуты анализу, и в отношении которых можно запланировать мероприятия по реагированию.

Неизвестные риски - риски, не поддающиеся предварительной идентификации.

Процессы управления рисками

.        Выявление;

2.      Анализ и приоритезация;

.        Планирование;

.        Мониторинг и отчетность;

.        Корректирование;

.        Извлечение уроков;

.        Выявление рисков.

Идентификация рисков

1. Мозговой штурм (10-15 человек, 2 часа);

. Техника Дельфи (участники не общаются, списки вопросов и ответов состовляет и рассылает ведущий);

. Метод номинальной группы (7-10 человек, анонимно и тайно формируются списки, обсуждаются, анонимно и тайно ранжируются);

. Карточки Кроуфорда (7-10 человек, 10 вопросов, на которые кадлый должен дать различающиеся ответы, 10 раз задается один и тот же вопрос);

. Идентификация основной причины (что, как, почему идет неправильно);

. SWOT анализ сильных и слабых сторон, возможностей и угроз;

. Метод аналогии.

Планирование мероприятий:

·        Исследование (research). Достаточно ли мы знаем о данном конкретном риске? Должны ли мы лучше изучить его, чтобы получить о нем больше информации и определить его характеристики до того, как мы предпримем какие-либо действия?

·        Принятие (accept). Можем ли мы пережить последствия риска, если они все-таки наступят? Можем ли мы принять риск и не предпринимать по этому поводу никаких дальнейших действий?

·        Избежание (avoid). Можем ли мы избежать риска, изменив способ действия?

·        Перенос (transfer). Можем ли мы перенести риск на другой проект, проектную группу, организацию или частных лиц?

·        Предотвращение (mitigation). Можно ли сделать что-то заранее для уменьшения вероятности риска или его угрозы?

·        Смягчение последствий (contingency). Может ли угроза риска быть уменьшена путем планирования некоторой реакции на него?

Исследование

Многие из рисков связаны с неопределенностями, порожденными неполной информированностью. Они могут быть эффективно разрешены после дополнительного изучения связанной с ними предметной области. Например, проектная группа может принять решение о проведении маркетингового исследования, чтобы больше узнать об имеющихся у пользователей базовых навыках и об их желании использовать новые технологии. В случае решения о проведении исследований план управления риском должен включать в себя описание этих исследований, включая формулировки проверяемых гипотез и изучаемых вопросов.

Принятие

Природа некоторых рисков такова, что лучшим решением является их принятие для реализации открываемых ими возможностей, так как просто не существует эффективных превентивных или коррективных мер. Принятие не есть бездействие. План управления рисками должен включать в себя обоснование того, почему проектная группа избрала принятие риска, а не выработку мер по его предотвращению и смягчению последствий.

Избежание

Возможно, выявленный риск может быть разрешен наилучшим образом некоторыми изменениями в самом проекте, исключающими существование риска. В таком случае план управления рисками должен включать в себя обоснование изменения, и оно должно быть также отражено в плане самого проекта. Кроме того, должны быть инициированы мероприятия, необходимые для претворения принятого изменения в жизнь.

Перенос

Иногда возможно передать управление риском третьей стороне, непосредственно не участвующей в проекте. Примерами таких случаев являются:

·        страхование;

·        наем сторонних консультантов с большим опытом работы;

·        покупка готовой компоненты вместо ее создания собственными силами;

·        привлечение внешних субподрядчиков.

Перенос риска не обязательно означает его исчезновение. В общем случае перенос риска породит другие риски, требующие управления, но имеющие приемлемый уровень. Например, привлечение внешнего консультанта может перенести технологические риски за пределы проектной группы, но породит риски в областях управления и бюджетирования.

Предотвращение

План предотвращения риска описывает меры и мероприятия, осуществляемые заблаговременно для предотвращения риска или сокращения его угрозы или последствий до приемлемого уровня. Предотвращение риска, в отличие от избежания, концентрируется на его снижении до приемлемого уровня (избежание означает изменение проекта с целью этот риск обойти).

Главная цель предотвращения риска - снижение его вероятности. Например, некоторое дополнительное количество подключений к Internet сокращает риск полной потери доступа в глобальную сеть.

Не для каждого риска есть эффективная стратегия предотвращения. В таких случаях целесообразно спланировать меры по смягчению последствий риска.

Смягчение последствий

Планирование мер по смягчению последствий риска заключается в создании запасных планов на случай, если превентивные меры по предотвращению негативных последствий не достигнут цели. Такие планы необходимы для всех рисков, включая те, для которых разработаны планы по предотвращению. Они предусматривают действия на случай реализации риска и должны минимизировать влияние последствий. Чтобы быть эффективными, эти планы должны быть разработаны заблаговременно. Проектная группа может установить для каждого риска триггер (Trigger) - условие применения плана реагирования.

Ковров Д.А.

ПРЕДМЕТНЫЙ УКАЗАТЕЛЬ

Базовый план 4, 21, 22

Вероятность 4, 5, 45, 47

Декомпозиция 4, 38

Заинтересованные стороны 4, 11, 18

Заказчики 4, 13, 17, 18, 22, 26, 29, 30, 31

Закрытие проекта 4, 23

Идентификация 4, 37, 43, 44

Интегрировать 4, 20

Итерация 4, 17

Модель жизненного цикла 5, 10, 16

Модель процессов 5, 9, 18

Мониторинг и управление работами проекта 5, 22

Организация 4, 5, 11, 12, 13, 18, 20, 24, 25, 28, 34, 35,41

План проекта 5, 21, 22

Позиционирование 5, 37

Потребители 5,13, 18, 19

Производительность устройства <https://ru.wikipedia.org/w/index.php?title=%D0%9F%D1%80%D0%BE%D0%B8%D0%B7%D0%B2%D0%BE%D0%B4%D0%B8%D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D0%BE%D1%81%D1%82%D1%8C_%D1%83%D1%81%D1%82%D1%80%D0%BE%D0%B9%D1%81%D1%82%D0%B2%D0%B0&action=edit&redlink=1> 5

Риск 5, 6, 9, 14, 15, 21, 28, 36, 37, 41, 43, 44, 45, 46, 47

Создание плана проекта 6, 21

Стоимость 6, 14, 15, 21, 34, 37, 39, 40, 41, 42

Стратегия 6, 7, 21, 24, 27, 34, 35, 36, 43, 47

Траектория 6, 34, 35

Цель 4, 5, 6, 8, 9, 10, 13, 20, 26, 28, 30, 31, 40, 47

Эффективность 5, 6, 8, 22, 31, 34, 35, 36, 37, 40

Заключение

Управление проектом в последнее десятилетие стало мощной технологией управления изменениями в высококонкурентном мире. Эффективное применение методов и средств УП позволяет успешно реализовывать любой проект в соответствии с высокими стандартами качества, достигнув в срок поставленных целей, сэкономив время и уменьшив риск. Понятия проект и управление проектами связаны с необходимостью управления изменениями. Управление проектами является неотъемлемой частью повседневной деятельности руководителей разного уровня. Многие руководители необходимость использования формализованных методов управления проектами все еще связывают с крупными проектами, такими как запуск межпланетной станции, разработка нового вида вооружений или строительство атомной электростанции. Однако, даже в организациях, ориентированных на серийное производство реализация проектов составляет значительную часть деятельности. Применение формализованных методов управления проектами позволяет более обоснованно определять цели инвестиций и оптимально планировать инвестиционную деятельность, более полно учитывать проектные риски, оптимизировать использование имеющихся ресурсов и избегать конфликтных ситуаций, контролировать исполнение составленного плана, анализировать фактические показатели и вносить своевременную коррекцию в ход работ, накапливать, анализировать и использовать в дальнейшем опыт реализованных проектов. Таким образом, система управления проектами является одной из важнейших компонент всей системы управления организацией.

Данная работа может быть использована для дальнейшей углублённой проработки или для общего изучения.

Список используемой литературы

1.      Видеолекторий НОУ "ИНТУИТ" по дисциплине "Управление проектами" [электронный ресурс] / В.И. Грекул - . - Режим доступа: https: // yadi. sk/d/fbvJmEr5ehZdA <https://yadi.sk/d/fbvJmEr5ehZdA>, свободный.

.        Википедия - свободная энциклопедия [электронный ресурс] - . - режим доступа: https: // ru. wikipedia.org/ <https://ru.wikipedia.org/>, свободный.

3.       Товб А.С. Управление проектами. Стандарты, методы, опыт/ А.С. Товб, Г.Л. Ципес Г. - М.: "Олимп-Бизнес", 2003. - 350 с.

4.      Управление проектами (зарубежный опыт) / А.И. Кочетков [и др.]. - СПб: "Два Три", 1993 - 446 с.

.        Щедровицкий Г.П. Организация. Руководство. Управление. (Оргуправленческое мышление: идеология, методология, технология. Курс лекций / из архива Г.П. Щедровицкого. Т.4) / Г.П. Щедровицкий. - М.: "Путь", 2000 - 384 с.