скачать рефераты

МЕНЮ


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

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

оборудование (покупка, взятие в аренду, лизинг);

приспособления, устройства и производственные мощности;

рабочий труд (штатные сотрудники, нанятые по контракту);

расходные товары (канцелярские принадлежности и т. д.);

материалы;

обучение, семинары, конференции;

субконтракты;

перевозки и т. д.

Все затраты можно классифицировать как:

прямые и накладные расходы;

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

постоянные и переменные по признаку зависимости от объема работ;

плата за сверхурочное рабочее время.


Глава 2. Анализ и планирование рисков


Прежде всего, необходимо пояснить какие риски, с чем они связаны. Планируя проект, мы предполагаем, что не все получится так, как запланировано. И реальное исполнение проекта, как правило, подтверждает эти опасения. Возникающие несовпадения первоначального согласованного и зафиксированного представления о проекте (project baseline) и того, что получается в действительности, называется отклонениями. Управление отклонениями в основном сводится к борьбе с неприятностями, которая в общем случае может включать три стадии:

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

2.                Управление проблемами. Неприятности наступили, и необходимо выяснить их происхождение, степень влияния на проект, способы преодоления. Цель этой стадии – обеспечить проекту возможность идти так, как запланировано.

3.                Управление изменениями. Неприятности оказались достаточно серьезными, и справиться с ними без ущерба для проекта не удалось. Цель этого этапа – то, что у финансистов называется «зафиксировать убытки», - это модификация ранее согласованного технического задания, сроков исполнения и стоимости работ, управленческих и технологических процессов и т.п.

Строго говоря, отклонения могут быть не обязательно связаны с неприятностями. Так, к рисковым событиям относятся и желательные, но не запланированные события. Соответственно и изменения будут носить положительный характер. Однако, большее опасение вызывают изменения со знаком минус, поэтому мы не будем рассматривать «желательные изменения».

Итак, причиной возникновения рисков являются неопределенности, существующие в каждом проекте. Риски могут быть “известные" те, которые определены, оценены, для которых возможно планирование. Риски “неизвестные” – те, которые не идентифицированы и не могут быть спрогнозированы. Хотя специфические риски и условия их возникновения не определены, менеджеры проекта знают, исходя из прошлого опыта, что большую часть рисков можно предвидеть.

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

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

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

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

3.                Качественная оценка рисков – качественный анализ рисков и условий их возникновения с целью определения их влияния на успех проекта.

4.                Количественная оценка – количественный анализ вероятности возникновения и влияния последствий рисков на проект.

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

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

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

 

2.1. Планирование управления рисками

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


 

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

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

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

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



2.3 Качественная оценка рисков

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



2.4 Количественная оценка рисков

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

·                     Вероятность достижения конечной цели проекта

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

·                     Риски, требующие скорейшего реагирования и большего внимания, а также влияние их последствий на проект.

·                     Фактические затраты, предполагаемые сроки окончания.

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


 

2.5 Планирование реагирования на риски

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

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

 

2.6 Мониторинг и контроль


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

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

Целью мониторинга и контроля является выяснить, было ли:

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

·                     Реагирование достаточно эффективно или необходимы изменения

·                     Риски изменились по сравнению с предыдущим значением

·                     Наступление влияния рисков

·                     Необходимые меры приняты

·                     Воздействие рисков оказалось запланированным или явилось случайным результатом.

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



Глава 3. Методика управления проектом


Существуют различные методики управления проектами В данном курсе мы будем придерживаться методики «Мягкого внедрения» ведения проекта. Это методики мягкого и жесткого внедрения.

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

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

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

·                     Рассчитано на взаимное доверие Заказчика и Исполнителя в пределах не менее одного этапа работ, имеется в виду, что Заказчик или Исполнитель могут блокировать проект, но не более чем в рамках этапа.

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

·                     Учет модели ценообразования. Данная методика разработана с учетом рискованного для Исполнителя и выгодного для Заказчика "ценообразования за весь проект". Это не исключает возможность применения более простой расчетной схемы повременного типа.

·                     Заказчик готов заплатить больше, но за результат, а не за усилия (время) Исполнителя. Покупка проекта, а не времени Исполнителя позволяет Заказчику снять с себя значительную часть ответственности за свои проблемы и ошибки.

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

·                     Методика применима для небольших заказных и серийных систем.

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

Основной продукт этапа - документ "Постановка Задачи" (Product Vision).

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

На основе "Постановки Задачи" требуется составить документ "Экономическое обоснование".

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

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

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

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

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

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

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

В результате мы имеем нечетко сформулированное задание "Постановка Задачи" и оценку стоимости в "Экономическом обосновании". Риски от нечеткости требований должны быть покрыты пессимистичной оценкой. С точки зрения юридического договора "Постановка Задачи" может играть роль ТЗ, но с указанием в договоре на то, что более приоритетный документ "Документация пользователя" (см. ниже) и система будет приниматься по "Приемочным испытаниям" (см. также ниже)


Степень Важности

Продукт этапа

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

1

Постановка Задачи

Цель проекта.

Список ключевых требований без подробной расшифровки

2

Экономическое обоснование

Оценка экономического эффекта и себестоимости проекта.

3

Интерфейсный прототип

Модель одного из ключевых интерфейсов пользователя

4

Архитектурный прототип

Модель для оценочной проверки выбранной архитектуры

 

Условие завершения этапа: подписание сторонами "Постановки Задачи" и "Экономического обоснования".

На данном этапе производится создание серии рабочих прототипов, охватывающих всю систему, и согласуются все требования с ключевыми пользователями. Себестоимость этапа составляет примерно 30% разработки. Если на данном этапе производится поиск и разработка целой технологии, то его себестоимость увеличивается примерно в 3 раза.

Одновременно в виде пошаговых сценариев (use case) пишется "Документация Пользователя", раскрывающая пункты "Постановки Задачи". Сначала создаются сценарии поведения системы в целом. Затем создаются индивидуально направленные сценарии - должностные инструкции пользователям. Запрещается использование в документации слова "должен", время описания выбирается как неопределенное или настоящее. Такие стилистические ограничения необходимы для того, чтобы "Документация пользователя" играла не только роль спецификации, но и роль документации для пользователя, как следует из названия документа.

Возможны два варианта взаимодействия "прототип-документация":

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

2) При отсутствии представления о лучшем варианте реализации по краткому заданию на основе "Постановки Задачи" сначала создается прототип. После одобрения Заказчиком документируется желаемое поведение системы.

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

Как отмечено выше, "Документация" фактически заменяет классическое ТЗ,. таким образом на лицо ряд преимуществ:

1.                Описание программы делается на языке, понятном пользователю.

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

3.                Нет необходимости править ТЗ и Документацию одновременно.

4.                Как правило, заботятся в первую очередь о ТЗ, обычно документация далеко отстает от текущего состояния программы. В данном случае этого не наблюдается.


Степень

Важности

Продукт этапа

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

1

Прототип всей системы

Прототип системы - это набор прототипов проверяющий не менее 80% пользовательских и архитектурных решений.

Все прототипы должны быть приняты Заказчиком.

2

Документация (ТЗ)

Должны быть составлены и одобрены сценарии не менее 80% поведения конечной Системы.


Условие завершения этапа: этап завершается письменным соглашением Заказчика и Исполнителя о том, что конечная система будет принята, если соответствует последней согласованной версии "Документации Пользователя"; архитектура и требования стабильны, не предвидится изменений более чем на 20% в ходе следующего этапа.

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


Заключение


Широкое применение методика планирования работ на основе проекта получила в строительстве. Например, для управления проектом сооружения гидроэлектростанции на реке Черчилль в Ньюфаундленде (полуостров Лабрадор). Стоимость проекта составила 950 млн. долларов. Гидроэлектростанция строилась с 1977 по 1986 г. Этот проект включал более 100 строительных контрактов, причем стоимость некоторых из них достигала 76 млн. долларов. В 1984 году ход работ по проекту опережал расписание на 18 месяцев и укладывался в плановую оценку затрат.

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

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


Страницы: 1, 2


Copyright © 2012 г.
При использовании материалов - ссылка на сайт обязательна.