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