Управление проектами
Понятие управления проектами как важной части функционирования любого предприятия. Внедрение информационных систем. Стандарты по управлению проектами. Интеграция проекта и управление его содержанием. Особенности управления временем и стоимостью.
| Рубрика | Менеджмент и трудовые отношения |
| Вид | практическая работа |
| Язык | русский |
| Дата добавления | 07.04.2015 |
| Размер файла | 341,1 K |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Министерство образования и науки Российской Федерации
Федеральное государственное образовательное учреждение
высшего профессионального образования
"Сибирская государственный индустриальный университет”
Институт информационный технологий и автоматизированных систем
Кафедра автоматизации и информационных систем
Отчет по практической работе
"Управление проектами”
Выполнили: ст. гр. ИАТ-11
Ковров Д.А., Пащенко Н.А.,
Кукатов А.О., Соломатина Е.В.,
Терещенко В.А.
Проверил: доц. каф. АИС
Новокрещин Б.Г.
Новокузнецк, 2015
Содержание
- Введение
- Глоссарий
- Внедрение информационных систем
- Стандарты по управлению проектами
- Пащенко Н.А. Методология внедрения MSF (Microsoft Solutions Framework)
- Интеграция проекта
- Кукатов А. О. Управление содержанием проекта
- Управление временем
- Терещенко В.А. Управление стоимостью
- Соломатина Е.В. Обзор методологий внедрения
- Заключение
- Список используемой литературы
Введение
Управление проектами - деятельность, благодаря которой достигаются четкие цели проекта при соблюдении четкого баланса между объемами работ, ресурсами (например, денежными средствами, пространством, материалами и т.д.), временем, качеством работ и рисками. Ключевой фактор успеха - это наличие четкого плана, минимум отклонений от него, грамотного управления изменениями.
Результат работы - продукция предприятия или организации (результат проведенных исследований маркетологов, конструкторская и технологическая документация), решение различных задач производства.
Управление проектами - часть функционирования любого предприятия, иначе оно будет малоэффективным.
Глоссарий
Базовый план - официально утвержденный для управления и контроля документ, относительно которого измеряется выполнение проекта.
Вероятность - степень возможности наступления некоторого события. Когда основания для того, чтобы какое-нибудь возможное событие произошло в действительности, перевешивают противоположные основания, то это событие называют вероятным, в противном случае - маловероятным или невероятным.
Декомпозиция - разделение целого на части. Также декомпозиция - это научный метод, использующий структуру задачи и позволяющий заменить решение одной большой задачи решением серии меньших задач, пусть и взаимосвязанных, но более простых. Декомпозиция, как процесс расчленения, позволяет рассматривать любую исследуемую систему как сложную, состоящую из отдельных взаимосвязанных подсистем, которые, в свою очередь, также могут быть расчленены на части. В качестве систем могут выступать не только материальные объекты, но и процессы, явления и понятия.
Заинтересованные стороны - это лица или группы лиц, чьи интересы затрагиваются результатами проекта.
Заказчики (customer) - организации или лица, желающие получить от решения бизнес-отдачу.
Закрытие проекта - завершение всех операций во всех группах процессов управления проектами для формального закрытия проекта или проектной фазы.
Идентификация - установление тождественности неизвестного объекта известному на основании совпадения признаков; опознание.
Интегрировать - это объединять в одно целое какие-либо элементы или процессы.
управление проект интеграция стоимость
Итерация - это организация обработки данных, при котором действия повторяются многократно, не приводя при этом к вызовам самих себя.
Модель жизненного цикла - это структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении жизненного цикла.
Модель процессов - описывает последовательность действий, осуществляемых в ходе реализации любых проектов.
Мониторинг и управление работами проекта - мониторинг и управление процессами инициации, планирования, выполнения и завершения проекта для достижения целевых показателей эффективности, намеченных в плане управления проектом.
Организация - объединение, группа людей (например, учреждение, предприятие, ассоциация и т.д.), с общей целью и определенными правилами сотрудничества в группе.
План проекта - это множество документов, которые должны быть составлены и проанализированы по содержанию и синхронизированы по временным параметрам этих планов.
Позиционирование - разработка комплекса маркетинга и рекламы, обеспечивающего предлагаемому товару четко отличное от других товаров и конкурентно способное положение на рынке, а также в организации целевых потребителей.
Потребители (пользователь, user) - люди, сталкивающиеся с работой этого решения в ходе своей профессиональной деятельности.
Производительность устройства - величина действия устройства, то есть отношение количества произведённой работы (выпущенного продукта) ко времени их выполнения (выпуска), объём продукции (работы), производимой в единицу времени данным оборудованием в соответствии с его конструктивными особенностями, технической характеристикой и производственной квалификацией рабочих.
Риск - сочетание вероятности и последствий наступления неблагоприятных событий. Знание вероятности неблагоприятного события позволяет определить вероятность благоприятных событий. Так же риском часто называют непосредственно предполагаемое событие, способное принести кому-либо ущерб или убыток.
Создание плана проекта - координация всех планов проекта и их интеграция в единый согласованный документ.
Стоимость - основа количественных соотношений при добровольном обмене товарами между собственниками. Разные экономические школы природу стоимости объясняют по-разному: затратами рабочего времени, балансом спроса и предложения, производства.
Стратегия - это конкретный долгосрочный план достижения некоторой цели, а выработка стратегии - это процесс нахождения некоторой цели и составление долгосрочного плана. Такой подход основывается на том, что все возникающие изменения предсказуемы, происходящие в среде процессы носят детерминированный характер и поддаются полному контролю и управлению.
Траектория - линия в пространстве, вдоль которой движется тело, представляющая собой множество точек, в которых находилась, находится или будет находиться материальная точка при своём перемещении в пространстве относительно выбранной системы отсчёта. Существенно, что понятие о траектории имеет физический смысл даже при отсутствии какого-либо по ней движения.
Цель - создание и сплочение проектной группы на основе выработки единого видения проекта.
Эффективность - продуктивность использования ресурсов в достижении какой-либо цели.
Внедрение информационных систем
Информационная система (ИС) - это не программа, а достаточно сложный комплекс. Совокупность технологических и управленческих элементов.
Технологические элементы позволяют работать информационной системе, выполнять её функции. К ним относятся:
• Информационная модель;
• Кадровые ресурсы, отвечающие за формирование и развитие информационной модели;
• Программный комплекс (ПК);
• Кадровые ресурсы, отвечающие за конфигурирование ПК;
• Аппаратно-техническая база;
• Эксплуатационно-технические кадровые ресурсы.
• Управленческими элементами являются:
• Регламент развития информационной модели и правила внесения в неё изменений;
• Регламент технической и пользовательской поддержки ПК;
• Регламент внесения изменений в конфигурацию ПК и состав его функциональных модулей;
• Регламент использования ПК и пользовательские инструкции;
• Регламент обучения и сертификации пользователей.
Попытка внедрения информационной системы - это попытка создания работоспособного комплекса, который включает в себя все вышеперечисленные элементы.
Опыт внедрения ИС позволяет выявить некоторые факторы - факторы успеха, которые оказываются критичными для успешности проекта:
• Наличие стратегии у клиента;
• Реинжиниринг бизнес-процессов до внедрения;
• Качество системы и команды консультантов;
• Участие специалистов клиентов;
• Ясные цели и четкие требования;
• Наличие и соблюдение плана внедрения;
• Участие руководства в проекте;
• Получение быстрой и эффективной отдачи.
Преимущества методологии внедрения ИС
1. Обеспечение базы для обучения новых сотрудников стандартным методам внедрения - быстрота подготовки внедренческих ресурсов;
2. Сокращение внутренних расходов на организацию и реализацию проектов;
3. Улучшение взаимодействия и взаимопонимания между членами проектной группы;
4. Эффективность совместного использования ресурсов между проектами, командами.
Основные методологии
• 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))
Существует "три кита" на которых базируется любое проектное управление:
1. Должны быть определены центры интегративной ответственности, те, кто отвечают за общие характеристики исполнения проекта и достижения целей проекта. Это могут быть либо отдельные лица, либо, организационно - штатные структуры;
2. Должна быть сформирована команда проекта;
3. Должна быть запущена система планирования и контроля исполнения проекта. Эта система должна реализовывать интегральное и прогнозирующие планирование и контроль.
Для описания развития проекта используются модели жизненного цикла. На основе ступенчато - шлюзовой модели жизненного цикла проекта разрабатываются иерархическая структура проекта и иерархическая структура работ проекта.
Иерархическая структура проекта (ИСП) - это перечень тех фаз и этапов из которых состоит проект и распределение процессов выполняемых работ по этим фазам и этапам.
Иерархическая структура работ (ИСР) - это детальное уточнение того, что должно быть выполнено в рамках каждого процесса.
Состав окружения проекта:
• Заинтересованные стороны (бенефициары) проекта (подразделения и специалисты, на которых наибольшее влияние оказывают результаты проекта, контрагенты предприятия)
• Факторы окружения (характеристики организации, степень знакомства с используемыми технологиями, квалификация сотрудников)
Для обеспечения связей между проектом и окружением проекта (действующими лицами) необходимо сделать их соучастниками проекта. Для этого предлагается несколько стандартных процедур:
• Создание формальных комитетов по управлению проектами;
• Включение заинтересованных сторон в совет (группу советников) по проекту;
• Обеспечение участия менеджера проекта или членов команды в советах или комитетах организаций - заинтересованных сторон.
С действующими лицами можно каким-то образом разбираться "перетаскивать" их на свою сторону или не делать их большими противниками проекта, факторы же можно только учитывать.
Стандарты по управлению проектами
В стандартах описано что нужно делать. В корпоративных стандартах уточняется как можно выполнить те или иные функции с учетом особенностей организации.
Две основные организации, которые занимаются разработкой стандартов:
· 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 процессов.
Основные действующие лица делятся на две группы:
1. Лица, связанные с управлением проектом;
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 представляет собой спиральную модель. Весь жизненный цикл, делится на под циклы, каждый из которых состоит:
1. Разработка концепции;
2. Планирование;
3. Разработка того, что создается в данном проекте;
4. Стабилизация;
5. Внедрение.
После этих этапов, цикл может повторяется, если программируются требования к той системе, которую мы создаем.
Вехи имеют две смысловые нагрузки:
• точки синхронизации работ;
• точки смены производственной ответственности.
Главные вехи служат точками перехода от одной фазы к другой. Они также определяют изменения в текущих задачах ролевых кластеров. В 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 - целый). Управлять интеграцией в проектном менеджменте означает выполнять действия и процессы, направленные на объединение и координацию процессов и действий, необходимых для достижения целей проекта и удовлетворения ожиданий его заинтересованных сторон.
Области знаний в управлении проектами зависят друг от друга, процессы управления проектами пересекаются между собой, проектная деятельность может быть связана с результатами текущей деятельности организации и, наоборот, поэтому важно управлять данными взаимозависимостями с целью принятия своевременных решений относительно конфликтов ресурсов, конфликтов целей и влиянием на проект различных заинтересованных сторон.
Кроме того, управление интеграцией включает в себя действия, необходимые для интеграции различных документов проектной деятельности. Процессы управления интеграцией проекта. К процессам управления интеграцией проекта относят следующие процессы:
1. Разработка Устава проекта;
2. Разработка плана управления проектом;
3. Руководство и управление исполнением проекта;
4. Мониторинг и управление работами проекта;
5. Осуществление общего управления изменениями;
6. Завершение проекта или фазы.
Управление интеграцией проекта включает в себя действия (процессы и операции), необходимые для выявления, определения, комбинирования, унификации и координации различных процессов и операций по управлению проектами, включает в себя процессы, которые обеспечивают координацию всех областей и элементов проекта.
· Создание плана проекта - координация всех планов проекта и их интеграция в единый согласованный документ;
· Исполнение плана проекта - выполнение включенных в план работ;
· Интегрированный контроль изменений - координация изменений в проекте.
Ориентировочный состав плана проекта:
· Устав (описание, определение проекта) (Project Charter);
· Описание стратегии управления проектом;
· Определение содержания и рамок проекта (Scope) ю;
· Иерархическая структура проекта (WBS - Work Breakdown Structure) ю;
· Для каждого важного результата - стоимость, даты начала и окончания, ответственные лица;
· Базовый план для контроля проекта (baseline) ю;
· Ключевые контрольные точки (milestones) ю;
· План управления содержанием проекта;
· План управления персоналом проекта;
· План управления рисками;
· План управления качеством;
· План управления взаимодействием.
План проекта - это множество документов, которые должны быть составлены и проанализированы по содержанию и синхронизированы по временным параметрам этих планов.
Виды планов проекта:
· Предварительный план проекта - готовится менеджером проекта до или на начальной стадии проекта;
· Базовый план - официально утвержденный для управления и контроля документ, относительно которого измеряется выполнение проекта.
Руководитель проекта не может изменять базовый план. Изменяет базовый план спонсор, заказчик или Комитет по управлению изменениями на основе установленной процедуры утверждения запросов на изменения.
Рабочий (текущий) план проекта - изменяется руководителем проекта по мере выполнения проекта.
Характеристики планов (степень детализации) определяются корпоративной методологией планирования или контрактом. Реальное исполнение проекта практически всегда отличается от запланированного.
При небольших отклонениях предпринимаются корректирующие воздействия. При больших отклонения корректируется план через установленные процедуры утверждения запросов на отклонения.
Состав процессов Управления интеграцией в PMBOK 2004:
· Разработка Устава проекта - разработка Устава проекта, формально авторизующего проект или фазу проекта;
· Разработка предварительного описания содержания проекта - разработка предварительного описания содержания проекта, включающего в себя самое общее изложение содержания;
· Разработка плана управления проектом - документирование операций, необходимых для определения, подготовки, интеграции всех вспомогательных планов в план управления проектами и их координации;
· Руководство и управление исполнением проекта - выполнение работы, определенной в Плане управления проектом для выполнения требований, определенных в описании содержания проекта;
· Мониторинг и управление работами проекта - мониторинг и управление процессами инициации, планирования, выполнения и завершения проекта для достижения целевых показателей эффективности, намеченных в Плане управления проектом;
· Общее управление изменениями - обработка всех запросов на изменения, утверждение этих изменений и управление ими для оптимизации результатов поставки и активов организационного процесса;
· Закрытие проекта - завершение всех операций во всех группах процессов управления проектами для формального закрытия проекта или проектной фазы.
Состав плана управления продуктом:
· Процессы управления проектами, отобранные командой управления проектом;
· Уровень внедрения каждого выбранного процесса;
· Описание инструментов и методов, используемых для осуществления этих процессов;
· Как выбранные процессы будут использоваться для управления конкретным проектом, включая зависимости и взаимодействия между этими процессами и ключевые входы и выходы;
· Как будет выполняться работа для достижения целей проекта;
· Как будут наблюдаться и контролироваться изменения;
· Как будет осуществляться управление конфигурацией;
· Как будет поддерживаться и использоваться целостность базовых планов исполнения;
· Потребность и методы коммуникации между участниками проекта;
· Жизненный цикл выбранного проекта;
· Основные анализы, проведенные руководством в отношении содержания, объема и сроков для облегчения обсуждения открытых проблем и решений, ожидающих утверждения.
Таблица
|
Процессы |
Входы |
Инструменты и методы |
Выходы |
|
|
УПРАВЛЕНИЕ ИНТЕГРАЦИЕЙ ПРОЕКТА |
||||
|
Разработка Устава проекта |
Описание работ по проекту: Бизнес-потребность; Описание содержания продукта; Стратегический план; Экономическое обоснование; Контракт; Факторы среды предприятия; Активы процессов организации |
Экспертные оценки |
Устав проекта |
|
|
Разработка плана управления проектом |
Устав проекта; Выходы процессов планирования Факторы среды предприятия; Активы процессов организации |
Экспертные оценки |
План управления проектом |
|
|
Руководство и управление исполнением проекта |
План управления проектом; Одобренные запросы на изменение; Факторы среды предприятия; Активы процессов организации |
Экспертные оценки Информационная система управления проектами |
Результаты: Информация о выполненных работах; Запросы на изменение; Обновления плана управления проектом Обновления документов проекта |
|
|
Мониторинг и управление работами проекта |
План управления проектом; Отчеты об исполнении Факторы среды предприятия; Активы процессов организации |
Экспертные оценки |
Запросы на изменение Обновления плана управления проектом Обновления документов проекта |
|
|
Осуществление общего управления изменениями |
План управления проектом; Информация о выполненных работах; Запросы на изменения; Факторы среды предприятия; Активы процессов организации |
Экспертные оценки Собрания по управлению изменениями |
Обновления статусов запросов на изменение Обновления плана управления проектом Обновления документов проекта |
|
|
Завершение проекта или фазы |
План управления проектом; Принятые результаты; Активы процессов организации |
Экспертные оценки |
Передача конечного продукта, услуги или результата Обновления активов процессов организации |
Кукатов А. О. Управление содержанием проекта
Данная дисциплина реализуется следующими процессами:
1. Инициация - нужно понять, требуется ли выполнять проект, и что он сможет принести в итоге. На выходе - устав проекта, менеджер проекта, ограничения и предположения.
Устав проекта - документ верхнего уровня, дающий полную характеристику проекта. Отражены аспекты, которые дают понять, что создается и для чего. Состоит из разделов:
· описание бизнес потребностей: потребности заказчиков; потребности бизнеса.
· предварительное описание продуктов проекта: описание того, что нужно будет внедрять, не обращая внимания на ограничения, которые накладываются условиями конкретных работ;
· описание границ проекта.
Определяется: кто руководитель, кто заказчик, сроки разработки более детальных документов описания проекта. Более устав проекта ничего не содержит, его цель - задать концепцию проекта.
Разработка более подробной документации - это планирование содержания проекта. На этом этапе:
· анализ продукта;
· просмотр альтернативных вариантов реализации;
· определение более выгодного варианта;
· принятие решение, как будет выглядеть система.
Устав проекта трансформируется в более подробный документ - Определение проекта, который в течении работы изменяется. Содержит:
· обоснование проекта - описание, почему проект возник;
· описание продукта проекта;
· результаты, которые нужно достигнуть;
· определение целей и критерий различных фаз и этапов проекта;
· фиксирование границ проекта;
· описание стратегического подхода к исполнению - в данный момент определяется, какие процессы управления проектами будут использоваться.
В результате - Содержание и План управления содержанием. В плане управления содержанием описывается:
· Как будет отслеживаться содержание проекта;
· как будут инициироваться и утверждаться изменения;
· каким образом задокументировать изменения.
Уточнение содержание - формирование иерархической структуры работ. В качестве методики работ можно использовать:
· декомпозицию (разделение работ на более мелкие);
· наборы шаблонов, для агрегированных работ.
На выходе - иерархическая структура работ - перечень тех работ, которые нужно выполнить в проекте. Не описано, сколько требуется ресурсов, времени и прочее. Иерархическая структура работ появляется не только из работ, но и из декомпозиции создаваемого продукта. Учитываются действия необходимые для реализации проекта, а также действия для реализации отдельных элементов.
Иерархическая структура работ отображается в виде диаграммы Ганта, предусматривающая разделение по времени. Все, что в нее включено, - это то, что нужно делать вовремя выполнения проекта.
В иерархическую структуру включаются различные события, которые позволяют фиксировать достижение важных результатов. События бывают:
· контрольные - достижение конкретного результата;
· интерфейсные - определяют изменение некоторой ситуации в проекте.
Инициатор проекта - лицо, объясняющее для чего нужно реализовывать проект. Он формулирует устав проекта.
Менеджер проекта назначается в том случае, если проект заинтересует руководство организации.
2. Процесс составления иерархической структуры работ;
3. Контроль (подтверждение содержания: достигнуты ли цели);
4. Подтверждение содержания - проверка сделанного;
5. Контроль изменения содержания - отслеживания изменений в содержании.
Причины изменения содержания:
· изменения во внешней среде;
· ошибки и опущения при составлении содержания;
· появление новых технологий;
· изменения бизнес-потребностей;
· непредвиденные риски.
Предусмотрены процедуры, позволяющие вносить изменения согласованно.
Цель управления содержанием проекта - зафиксировать те работы, которые нужны для достижения целей. Нужно не включить ничего лишнего в проект, так как все это будет напрасно.
Содержание проекта делится на разделы:
1. Содержание работ.
2. Содержание продукта - характеристики системы, которая разрабатывается.
Управление временем
Основа любого управления - разработка перечня работ. Фазы проекта и те работы что выполняются зависят от принятой методологии информационной системы. Нужно понимать отличия между ними.
Рассмотрим методологии внедрения Microsoft, People Soft и Oracle. Все они имеют сходства и различия.
Методология Microsoft:
· OnTarget;
· MBS.
Предназначены для внедрения информационных систем. По структуре подходят для внедрения систем класса 1C, BEST и прочее.
Отличаются последняя и первая стадии. MBS начинается с диагностики, а OnTarget с подготовки проекта. Ее суть в том, что заказчик должен знать, что он хочет получить в итоге. MBS появилась позже: ориентирована на то, что создается решение, которое обеспечит достижение некоторых бизнес-целей.
Переход от одной методологии к другой связан с тем, что заказчику неинтересно получать продукт, который лишь формально отвечает его требованиям.
Отличия MBS от OnTarget в целях:
1. В 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 много внимания уделяет множеству дисциплин, которые касаются работе с ИТ-решениями и программными средствами. Там рассказывается, как управлять ПО, как разрабатывать архитектуру сервисов и прочее.
Архитектура предприятия - описание того, как бизнес связан с информационным обеспечением предприятия; какие используются технические средства. Позволяет планировать развитие информационных систем.
Метод внедрения приложений:
Имеется ввиду, что они уже разработаны, но нужно их внедрить. Используется принцип здравого смысла:
1. Попытка описать общее представление, как осуществляется деятельность, какие средства используются.
2. Детальное описание того, как осуществляется деятельность. Появляется возможность посмотреть, как имеющиеся средства могут поддерживать детальное описание деятельности.
3. Процедура демонстрации.
4. Оценка того, сколько будет стоить доработка программного обеспечения.
Методология состоит из задач, каждая из которых имеет свой вход и выход, образуя цепочки. Выполнение такой цепочки позволяет решить определенную проблему. Цепочки называются процессами.
Коротко про бизнес-процессы:
1. Определение требований - считается, что те требования, которые будут определены, в последующем не расширяется, но изменения внутри возможны.
2. Отображения требований - нужно понять, как эти требования будут реализованы в системе.
3. Разработка дополнительной функциональности;
4. Конвертация данных - определение какая информация из какой системы будет "перекачана" в новую систему;
5. Документирование;
6. Тестирование;
7. Обучение: готовится группа и осуществляется обучение пользователей;
8. Ввод в эксплуатацию.
Если нужно работать с этой методологией, то потребуется освоить средство Oracle OBM.
Фазы проекта:
1. Определение;
2. Анализ операций;
3. Проектирование;
4. Переход к эксплуатации.
Методика предусматривает выделение составляющих:
· Планирования;
· исполнения и контроля;
· завершения.
Выделяются на каждой фазе проекта. По методологии нужно иметь высококвалифицированных специалистов.
Терещенко В.А. Управление стоимостью
1. Стратегия развития;
2. Стратегия внедрения;
3. Оценка эффективности проектов внедрения.
Нужно решить проблему систематизации.
1. Любое развитие информационной системы направлено на то чтобы каким, то образом улучить процессы деятельности организации. По этой причине можно ввести 2 оси координат, в которых и рассматривать все имеющиеся ситуации и в эти оси координат ложится развитие информационной системы.
Для того чтобы реализовать процессы мы можем использовать некоторые средства. Средства реализации делятся на 2 группы:
· Первая группа разрабатываемая информационная система.
· Вторая группа типовое проектное решение, это и есть две реализации процесса проектирования.
Мы должны управлять группой своих собственных разработчиков, кто будет реализовывать проект. Должны планировать все процессы изменения ситуации в рамках жизненного цикла со спиральной моделью.
В том случае, когда нам все понятно существует четкое представления об имеющихся бизнес процессах, переход осуществляется что в какой-то траектории у нас развиваются имеющиеся средства и уходим на типовое проектное решение, которое можем наращивать функциональные возможности.
Есть такой вариант мы фактически не улучшаем характеристики управления нашей организации, но переходим к некоторому типовому проектному решению. Ситуация, часто встречающая чтоб улучить имидж компании, чтоб быть не хуже, чем конкуренты.
Другой случай, когда мы работаем на некоторой промышленной системе, когда есть некоторое типовое проектное решение внедренное, но эффективность работы этой системы оказывается недостаточной чтоб ее уличить, повысить. Здесь мы работаем с группой, внедрение которой должны корректно управлять. Нужно проектировать собственную систему, которая будет реализована в собственной компании.
Как выбрать вариант развития информационной системы, каким образом принять решение и по какой траектории двигаться. Для того чтобы принимать такого рода решения необходимо учитывать целую массу информации. Финансы, персонал и инфо структура затем технические критерии, организационные критерии и насколько существенно придется изменять бизнес процесс и насколько существенно придется изменять деятельность. Дальше мы можем, принимать решения по какой траектории будем двигаться. Эти задачи можно решать если компания готова к их решению. В том случае если не выполнены некоторые условия, определяющие готовность или степень зрелости компании, то ей лучше не заниматься. Во-первых, должна быть стратегия бизнеса, нужно понимать куда наш бизнес движется и каким образом можем поддерживать этот бизнес через год, через два и т.д.
Во-вторых - это человеческий фактор. Должны быть зафиксированы этапы мы должны понимать, что оптимизируем.
2. Стратегии внедрения информационной системы. Стратегии определяют, куда мы будем идти, как будем организовывать наши проекты. Определяем общий характер нашей деятельности. Хоть и проекты разные можно найти несколько характеристик, комбинируя которые, можно написать любой проект. Характерны некоторые особенности, кокой то проект можно описать в виде набора блоков. По средствам привлечения внешнего партнёра при сохранении старых бизнес процессов, при адаптации особенности системы бизнеса. Из этого набора можно составить характеристику проекта, насколько проект успешен к чему можем прийти в результате этого проекта. Что такое эффективность внедрения системы? Обеспечивает ли некоторая стратегия воздействия положительная на те или иные факторы обеспечивает ли она возможность парировать всякого рода влияния возникающие и на сколько сложно это сделать в рамках данной стратегии.
Внедрение информационной системы своими собственными силами. Это всегда будет проект, сопряжённый с высокими рисками и будет ли он достаточно эффективен. Почему сопряжён, большими рисками? Если это бригада собственная, то мы ее компонуем и есть те кто в области внедрения обладают недостаточными знаниями. Когда внутри своей компании формируем некоторую команду мы отвлекаем людей от их основной деятельности, сразу оказываются ограниченные возможности, ресурсы, поэтому проект оказаться рискованным.
Второй блок стратегии, это решение задач оптимизации бизнес процесса, перед тем как мы будем осуществлять внедрение системы или в процессе внедрения информационной системы. Оптимизация бизнес процесса во всех случаях задача рискованная, потому что она заставляет существенно изменять деятельность компании, а любая компания любой коллектив этому противиться.
Изменение бизнес процесса под логику системы, когда мы насильно изменяем деятельности компании. Наша система оказывается стандартной, с которой могут работать со стандартным функционалом, все изменения доработки проходят в автоматическом режиме и не нужно иметь уникального специалиста. На этапе внедрения проект, оказывается, может оказаться не слишком эффективным.
Теперь каждый проект можно рассматривать в нескольких блоках в его реализации. Эти блоки обладают четко своими характеристиками. Появляется возможность на основе этих блоков оптимизировать информацию.
Подобные документы
Сущность и актуальность управления проектами. Методы исследования и обоснования инвестиций в проекте. Управление рисками и стоимостью проекта. Организация финансирования проекта, торги и контракты. Планирование и формы структуры управления проектами.
реферат [57,0 K], добавлен 14.02.2011Организационные структуры управления проектами, их отличительные особенности и содержание, принципы построения. Система менеджмента качества разработанного проекта, закономерности управления стоимостью и определение основных факторов, влияющих на нее.
контрольная работа [34,8 K], добавлен 09.12.2014Управление проектами в рыночных условиях, особенности управления ими в России. Управление эффективностью, рентабельностью и продолжительностью работы проекта. Деятельность людей в проектах. Факторы и правила достижения успеха в управлении проектами.
курсовая работа [33,8 K], добавлен 25.03.2008Системная модель управления проектом. Процессы реновации, реорганизации и ликвидации больших и сложных систем. Этапы внедрения управления проектами, управление их стоимостью и финансированием. Цикл "Планирование-исполнение-проверка-воздействие".
презентация [2,2 M], добавлен 25.01.2014Понятие и структура корпоративной системы управления проектами. Основные методы диагностики уровня зрелости управления проектами. Инициация и планирование, финансирование проектов. Управление программами, рисками, коммуникациями и портфелем предприятия.
дипломная работа [2,4 M], добавлен 20.08.2017Анализ существующих информационных технологий в области управления проектами. Разработка методики внедрения в работу образовательного учреждения программного комплекса управления проектами Microsoft Project и оценка эффективности его использования.
курсовая работа [151,2 K], добавлен 14.01.2014Характеристика этапов развития управления проектами в России. Понятие, роль и актуальность проектного управления. Основные формы планирования и контроля текущей деятельности фирмы. Особенности управления проектами в фирмах-партнерах "1С:Франчайзи".
курсовая работа [1021,2 K], добавлен 23.10.2015Стратегическое значение современных методов и средств управления проектами. Характеристика основных методов управления проектами. Фазы жизненного цикла проекта. Фаза разработки коммерческого предложения. Формальное и детальное планирование проекта.
контрольная работа [30,3 K], добавлен 04.02.2010Сущность управления инновационными проектами. Классификация инновационных проектов, идеи, замыслы и технические решения. Фазы жизненного цикла проекта и основные области его приложения. Программное обеспечение управления инновационными проектами.
реферат [484,6 K], добавлен 29.09.2012Сущность понятия "проект". Связь методологии управления проектами с другими управленческими дисциплинами. Разница между менеджером и владельцем. Источники успеха руководителя. Рычаги управления проектами. Жизненный цикл и фазы инвестиционного проекта.
презентация [930,4 K], добавлен 21.11.2011
