Содержание
Введение
1. Планирование управления рисками
2. Идентификация рисков
3. Качественная оценка рисков
4. Количественная оценка рисков
5. Планирование реагирования на риски
6. Мониторинг и контроль
7. Методика управления проектом
Заключение
Список использованных источников
Введение
В основе методов управления проектами лежат методики сетевого планирования, разработанные в конце 70-х годов в Америке и на Заподе. В 1976 г. М.Уолкер из фирмы «Дюпон», исследуя возможности более эффективного использования принадлежащей фирме вычислительной машины Univac, объединил свои усилия с Д.Келли из группы планирования капитального строительства фирмы «Ремингтон Рэнд». Они попытались использовать ЭВМ для составления планов-графиков крупных комплексов работ по модернизации заводов фирмы «Дюпон». В результате был создан рациональный и простой метод описания проекта с использованием ЭВМ. Первоначально он был назван методом Уолкера-Келли, а позже получил название Метода Критического Пути — МКП (или CPM — Critical Path Method).
Использование метода PERT позволило руководству программы точно знать, что требуется делать в каждый момент времени и кто именно должен это делать, а также вероятность своевременного завершения отдельных операций. Руководство программой оказалось настолько успешным, что проект удалось завершить на два года раньше запланированного срока. Благодаря такому успешному началу данный метод управления вскоре стал использоваться для планирования проектов во всех вооруженных силах США. Методика отлично себя зарекомендовала при координации работ, выполняемых различными подрядчиками в рамках крупных проектов.
1. Планирование управления рисками
Планирование управления рисками – процесс принятия решений по применению и планированию управления рисками для конкретного проекта. Этот процесс может включать в себя решения по организации, кадровому обеспечению процедур управления рисками проекта, выбор предпочтительной методологии, источников данных для идентификации риска, временной интервал для анализа ситуации. Важно спланировать управление рисками, адекватное как уровню и типу риска, так и важности проекта для организации.
2 Идентификация рисков.
Идентификация рисков определяет, какие риски способны повлиять на проект, и документирует характеристики этих рисков. Идентификация рисков не будет эффективной, если она не будет проводиться регулярно на протяжении реализации проекта.
Идентификация рисков должна привлекать как можно больше участников: менеджеров проекта, заказчиков, пользователей, независимых специалистов.
Идентификация рисков — итерационный процесс. Вначале идентификация рисков может быть выполнена частью менеджеров проекта или группой аналитиков рисков. Далее идентификацией может заниматься основная группа менеджеров проекта. Для формирования объективной оценки в завершающей стадии процесса могут участвовать независимые специалисты. Возможное реагирование может быть определено в течение процесса идентификации рисков.
3 Качественная оценка рисков.
Качественная оценка рисков – процесс представления качественного анализа идентификации рисков и определения рисков, требующих быстрого реагирования. Такая оценка рисков определяет степень важности риска и выбирает способ реагирования. Доступность сопровождающей информации помогает легче расставить приоритеты для разных категорий рисков. Качественная оценка рисков это оценка условий возникновения рисков и определение их воздействия на проект стандартными методами и средствами. Использование этих средств помогает частично избежать неопределенности, которые часто встречаются в проекте. В течение жизненного цикла проекта должна происходить постоянная переоценка рисков.
4 Количественная оценка рисков.
Количественная оценка рисков определяет вероятность возникновения рисков и влияние последствий рисков на проект, что помогает группе управления проектами верно принимать решения и избегать неопределенностей. Количественная оценка рисков позволяет определять:
Вероятность достижения конечной цели проекта
Степень воздействия риска на проект и объемы непредвиденных затрат и материалов, которые могут понадобиться.
Риски, требующие скорейшего реагирования и большего внимания, а также влияние их последствий на проект.
Фактические затраты, предполагаемые сроки окончания.
Количественная оценка рисков часто сопровождает качественную оценку и также требует процесс идентификации рисков. Количественная и количественная оценка рисков могут использоваться по отдельности или вместе, в зависимости от располагаемого времени и бюджета, необходимости в количественной или качественной оценке рисков.
5 Планирование реагирования на риски.
Планирование реагирования на риски — это разработка методов и технологий снижения отрицательного воздействия рисков на проект. Берет на себя ответственность за эффективность защиты проекта от воздействия на него рисков. Планирование включает в себя идентификацию и распределение каждого риска по категориям. Эффективность разработки реагирования прямо определит, будут ли последствия воздействие риска на проект положительными или отрицательными.
Стратегия планирования реагирования должна соответствовать типам рисков, рентабельности ресурсов и временным параметрам. Вопросы, обсуждаемые во время встреч, должны быть адекватны задачам на каждой стадии проекта, и согласованы со всеми членами группы по управлению проектом. Обычно требуются несколько вариантов стратегий реагирования на риски.
6. Мониторинг и контроль.
Мониторинг и контроль следят за идентификацией рисков, определяют остаточные риски, обеспечивают выполнение плана рисков и оценивают его эффективность с учетом понижения риска. Показатели рисков, связанные с осуществлением условий выполнения плана фиксируются. Мониторинг и контроль сопровождает процесс внедрения проекта в жизнь.
Качественный контроль выполнения проекта предоставляет информацию, помогающую принимать эффективные решения для предотвращения возникновений рисков. Для предоставления полной информации о выполнении проекта необходимо взаимодействие между всеми менеджерами проекта. Целью мониторинга и контроля является выяснить, было ли:
Нужна помощь в написании реферата?
Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Наша система гарантирует сдачу работы к сроку без плагиата. Правки вносим бесплатно.
- Система реагирования на риски внедрена в соответствии с планом Реагирование достаточно эффективно или необходимы изменения
- Риски изменились по сравнению с предыдущим значением
- Наступление влияния рисков
- Необходимые меры приняты.
- Воздействие рисков оказалось запланированным или явилось случайным результатом.
Контроль может повлечь за собой выбор альтернативных стратегий, принятие корректив, перепланировку проекта для достижения базового плана. Между менеджерами проекта и группой риска должно быть постоянное взаимодействие, должны фиксироваться все изменения и явления. Отчеты по выполнению проекта должны формироваться регулярно.
7. Методика управления проектом
Существуют различные методики управления проектами В данном курсе мы будем придерживаться методики «Мягкого внедрения» ведения проекта. Это методики мягкого и жесткого внедрения.
Внедрение — внедрение в условиях взаимного доверия Заказчика и Исполнителя, при котором проблемы и ошибки Заказчика берет на себя большей частью Исполнитель.
Жесткое внедрение — внедрение в условиях жесткого формального управления, пониженного доверия и повышенной ответственности Заказчика и Исполнителя. Жесткое внедрение обычно является следствием сильных политических рисков
Данная технология разработки и внедрения имеет следующие проверенные границы применимости:
Рассчитано на взаимное доверие Заказчика и Исполнителя в пределах не менее одного этапа работ, имеется в виду, что Заказчик или Исполнитель могут блокировать проект, но не более чем в рамках этапа.
Оптимально для проектов сроком до 3х месяцев и трудоемкостью до 1 чел/года. Для изготовления более сложной системы, необходимо, чтобы ее отдельные модули внедрялись не дольше 3х месяцев, в противном случае методика не применима.
Учет модели ценообразования. Данная методика разработана с учетом рискованного для Исполнителя и выгодного для Заказчика «ценообразования за весь проект». Это не исключает возможность применения более простой расчетной схемы повременного типа.
Заказчик готов заплатить больше, но за результат, а не за усилия (время) Исполнителя. Покупка проекта, а не времени Исполнителя позволяет Заказчику снять с себя значительную часть ответственности за свои проблемы и ошибки.
Ключевые пользователи Заказчика не является специалистами в информационных системах. Заказчик предпочитает работать не с формальной спецификацией, а с документацией пользователя и моделями системы.
Методика применима для небольших заказных и серийных систем.
Данный этап проводится по договору о консалтинге, т.е. оплата этапа повременная. В виду неопределенности задачи спланировать заранее ее стоимость невозможно. Себестоимость этапа примерно равна 10% себестоимости всех работ.
Основной продукт этапа — документ «Постановка Задачи» (Product Vision).
Данный документ должен определять цель проекта и включать в себя список ключевых требований без подробной расшифровки. Важный критерий: несмотря на отсутствие подробного описания, список должен поддаваться статистической оценке трудоемкости со стандартным отклонением (риском) в приемлемых рамках.
На основе «Постановки Задачи» требуется составить документ «Экономическое обоснование«.
Данный документ должен содержать статистическую оценку трудоемкости (себестоимости) работ. С другой стороны, должен быть сделан анализ экономического эффекта от внедрения.
При анализе используется статистика трудоемкости (эффективности) аналогичных проектов. При отсутствии данной статистики неизбежны ошибки в оценках причем на порядок, в данном случае следует попробовать получить статистику опираясь на результаты разработки/демонстрации прототипов.
Для оценки рисков требуется разработать как минимум 2 простейших прототипа (они могут быть выполнены как один).
«Интерфейсный прототип» — это прототип, имитирующий 1-2 важнейших диалоговых окна программы. Необходимо проанализировать реакцию пользователей с целью изучения рисков связанных с модификацией их требований.
«Архитектурный прототип» — это прототип, проверяющий самые критические места будущей архитектуры. Данный прототип служит для оценки технологических рисков.
Данные прототипы не должны далее использоваться при разработке системы, требуется начать разработку заново. Это связано с тем, что прототипы служат для нахождения оптимальных решений, но таковыми не являются.
Нужна помощь в написании реферата?
Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Наша система гарантирует сдачу работы к сроку без плагиата. Правки вносим бесплатно.
Оценку рисков требуется выразить в виде возможного превышения трудоемкости (пессимистичная оценка). Именно из данной оценки следует исходить при определении общей трудоемкости (цены) продукта.
В результате мы имеем нечетко сформулированное задание «Постановка Задачи» и оценку стоимости в «Экономическом обосновании». Риски от нечеткости требований должны быть покрыты пессимистичной оценкой. С точки зрения юридического договора «Постановка Задачи» может играть роль ТЗ, но с указанием в договоре на то, что более приоритетный документ «Документация пользователя» (см. ниже) и система будет приниматься по «Приемочным испытаниям» (см. также ниже)
Таблица 1. Оценка рисков
Условие завершения этапа: подписание сторонами «Постановки Задачи» и «Экономического обоснования». На данном этапе производится создание серии рабочих прототипов, охватывающих всю систему, и согласуются все требования с ключевыми пользователями. Себестоимость этапа составляет примерно 30% разработки. Если на данном этапе производится поиск и разработка целой технологии, то его себестоимость увеличивается примерно в 3 раза. Одновременно в виде пошаговых сценариев (use case) пишется «Документация Пользователя», раскрывающая пункты «Постановки Задачи». Сначала создаются сценарии поведения системы в целом. Затем создаются индивидуально направленные сценарии — должностные инструкции пользователям. Запрещается использование в документации слова «должен», время описания выбирается как неопределенное или настоящее. Такие стилистические ограничения необходимы для того, чтобы «Документация пользователя» играла не только роль спецификации, но и роль документации для пользователя, как следует из названия документа. Возможны два варианта взаимодействия «прототип-документация»:
1) При относительно четком представлении о функциональности до разработки очередного прототипа должны быть готовы основные пункты «Документации», описывающие его работу. В данном случае «Документация» одновременно играет роль нечеткой спецификации на прототип. Нечеткость заключается в том, что «Документация» может быть исправлена с целью соответствия реализации в прототипе, если прототип реализовал удачное, но не документированное решение.
2) При отсутствии представления о лучшем варианте реализации по краткому заданию на основе «Постановки Задачи» сначала создается прототип. После одобрения Заказчиком документируется желаемое поведение системы. Пользователь оценивает прототип и документацию одновременно. Если, осмотрев прототип, пользователь согласен с описанием поведения конечной системы в «Документации Пользователя», осуществляется переход к созданию прототипа следующего функционального модуля. Как отмечено выше, «Документация» фактически заменяет классическое ТЗ,. таким образом на лицо ряд преимуществ:
Описание программы делается на языке, понятном пользователю.
Уже на первых этапах разработки программы пользователь включается в анализ своей рабочей документации. Нет необходимости править ТЗ и Документацию одновременно.
Как правило, заботятся в первую очередь о ТЗ, обычно документация далеко отстает от текущего состояния программы. В данном случае этого не наблюдается.
Таблица 2. Описание продуктов
Условие завершения этапа: этап завершается письменным соглашением Заказчика и Исполнителя о том, что конечная система будет принята, если соответствует последней согласованной версии «Документации Пользователя»; архитектура и требования стабильны, не предвидится изменений более чем на 20% в ходе следующего этапа.
Важное замечание о юридической стороне. Вполне возможно, что не удается достигнуть согласия ключевых пользователей с прототипом или описанием в Документации. В данном случае Заказчик должен принять волевое решение на уровне топ-менеджера и определиться с требованиями. Если этого не происходит, или если требования выходят за рамки «Постановки задачи» с учетом надбавок на риск, рекомендуется пересмотреть трудоемкость/цену проекта или прекратить его. Указанная возможность прекращения проекта должна быть предусмотрена в договоре.
Заключение
Широкое применение методика планирования работ на основе проекта получила в строительстве. Например, для управления проектом сооружения гидроэлектростанции на реке Черчилль в Ньюфаундленде (полуостров Лабрадор). Стоимость проекта составила 950 млн. долларов. Гидроэлектростанция строилась с 1977 по 1986 г. Этот проект включал более 100 строительных контрактов, причем стоимость некоторых из них достигала 76 млн. долларов. В 1984 году ход работ по проекту опережал расписание на 18 месяцев и укладывался в плановую оценку затрат.
По существу, значительный выигрыш по времени образовался от применения точных математических методов в управлении сложными комплексами работ, что стало возможным благодаря развитию вычислительной техники.В настоящее время в Америке уже сложились глубокие традиции использования систем управления проектами во многих областях жизнедеятельности. Применение системы управления проектами на практике может быть эффективным и для очень небольших проектов, так как, основную долю среди планируемых проектов составляют именно небольшие по размерам проекты.
Список использованных источников
1. С сайта http://www.publications.reporter-studio.ru/
2. Трубицын Юрий. Системы календарного планирования проектов.