Планирование и управление проектом
Чтобы оценить стоимость
проекта, требуется знать стоимость составляющих проект ресурсов, время
выполнения работ и стоимость этих работ. Таким образом, оценка стоимости
начинается с определения структуры ресурсов и работ проекта. Данные задачи
решаются в рамках планирования проекта, а в модуль оценки стоимости должны
поступать результаты выполнения этого процесса. Стоимость проекта
определяется ресурсами, необходимыми для выполнения работ, в том числе:
оборудование (покупка,
взятие в аренду, лизинг);
приспособления, устройства
и производственные мощности;
рабочий труд (штатные
сотрудники, нанятые по контракту);
расходные товары
(канцелярские принадлежности и т. д.);
материалы;
обучение, семинары,
конференции;
субконтракты;
перевозки и т. д.
Все затраты можно классифицировать
как:
прямые и накладные
расходы;
повторяющиеся и
единовременные. Например, ежемесячные платежи за использование производственных
мощностей — повторяющиеся затраты, закупка комплекта оборудования —
единовременные затраты;
постоянные и переменные
по признаку зависимости от объема работ;
плата за сверхурочное
рабочее время.
Глава 2. Анализ и планирование рисков
Прежде всего,
необходимо пояснить какие риски, с чем они связаны. Планируя проект, мы
предполагаем, что не все получится так, как запланировано. И реальное
исполнение проекта, как правило, подтверждает эти опасения. Возникающие
несовпадения первоначального согласованного и зафиксированного представления о
проекте (project baseline) и того, что получается в
действительности, называется отклонениями. Управление отклонениями в основном
сводится к борьбе с неприятностями, которая в общем случае может включать три
стадии:
1.
Управление
рисками. Неприятности еще не наступили, но не исключена возможность
возникновения нежелательных и незапланированных событий, которые могут привести
к тому, что цели проекта (одна или несколько) не будут достигнуты. Цель этой
стадии – предотвратить неприятности до их возникновения или, по крайней мере,
встретить их во всеоружии.
2.
Управление проблемами.
Неприятности наступили, и необходимо выяснить их происхождение, степень влияния
на проект, способы преодоления. Цель этой стадии – обеспечить проекту
возможность идти так, как запланировано.
3.
Управление
изменениями. Неприятности оказались достаточно серьезными, и справиться с ними
без ущерба для проекта не удалось. Цель этого этапа – то, что у финансистов
называется «зафиксировать убытки», - это модификация ранее согласованного
технического задания, сроков исполнения и стоимости работ, управленческих и
технологических процессов и т.п.
Строго
говоря, отклонения могут быть не обязательно связаны с неприятностями. Так, к
рисковым событиям относятся и желательные, но не запланированные события.
Соответственно и изменения будут носить положительный характер. Однако, большее
опасение вызывают изменения со знаком минус, поэтому мы не будем рассматривать «желательные
изменения».
Итак,
причиной возникновения рисков являются неопределенности, существующие в каждом
проекте. Риски могут быть “известные" те, которые определены, оценены, для
которых возможно планирование. Риски “неизвестные” – те, которые не
идентифицированы и не могут быть спрогнозированы. Хотя специфические риски и
условия их возникновения не определены, менеджеры проекта знают, исходя из прошлого
опыта, что большую часть рисков можно предвидеть.
Реализуя
проекты, имеющие высокую степень неопределенности в таких элементах, как цели и
технологии их достижения многие компании уделяют внимание разработке и
применению корпоративных методов управления рисками. Данные методы учитывают
как специфику проектов, так и корпоративных методов управления .
Управление
рисками – это
процессы, связанные с идентификацией, анализом рисков и принятием решений,
которые включают максимизацию положительных и минимизацию отрицательных
последствий наступления рисковых событий. Процесс управления рисками проекта
обычно включает выполнение следующих процедур:
1.
Планирование
управления рисками – выбор подходов и планирование деятельности по управлению
рисками проекта.
2.
Идентификация
рисков – определение рисков, способных повлиять на проект, и документирование
их характеристик.
3.
Качественная
оценка рисков – качественный анализ рисков и условий их возникновения с целью
определения их влияния на успех проекта.
4.
Количественная
оценка – количественный анализ вероятности возникновения и влияния последствий
рисков на проект.
5.
Планирование
реагирования на риски– определение процедур и методов по ослаблению
отрицательных последствий рисковых событий и использованию возможных преимуществ.
6.
Мониторинг и
контроль рисков - мониторинг рисков, определение остающихся рисков, выполнение
плана управления рисками проекта и оценка эффективности действий по минимизации
рисков.
Все эти
процедуры взаимодействуют друг с другом, а также с другими процедурами. Каждая
процедура выполняется, по крайней мере, один раз в каждом проекте. Несмотря на
то, что процедуры, представленные здесь, рассматриваются как дискретные
элементы с четко определенными характеристиками, на практике они могут частично
совпадать и взаимодействовать.
Планирование
управления рисками –
процесс принятия решений по применению и планированию управления рисками для
конкретного проекта. Этот процесс может включать в себя решения по организации,
кадровому обеспечению процедур управления рисками проекта, выбор
предпочтительной методологии, источников данных для идентификации риска,
временной интервал для анализа ситуации. Важно спланировать управление рисками,
адекватное как уровню и типу риска, так и важности проекта для организации.
Идентификация
рисков определяет,
какие риски способны повлиять на проект, и документирует характеристики этих
рисков. Идентификация рисков не будет эффективной, если она не будет
проводиться регулярно на протяжении реализации проекта.
Идентификация
рисков должна привлекать как можно больше участников: менеджеров проекта,
заказчиков, пользователей, независимых специалистов.
Идентификация
рисков - итерационный процесс. Вначале идентификация рисков может быть
выполнена частью менеджеров проекта или группой аналитиков рисков. Далее
идентификацией может заниматься основная группа менеджеров проекта. Для
формирования объективной оценки в завершающей стадии процесса могут участвовать
независимые специалисты. Возможное реагирование может быть определено в течение
процесса идентификации рисков.
2.3 Качественная оценка рисков
Качественная
оценка рисков –
процесс представления качественного анализа идентификации рисков и определения
рисков, требующих быстрого реагирования. Такая оценка рисков определяет степень
важности риска и выбирает способ реагирования. Доступность сопровождающей
информации помогает легче расставить приоритеты для разных категорий рисков.
Качественная оценка рисков это оценка условий возникновения рисков и
определение их воздействия на проект стандартными методами и средствами.
Использование этих средств помогает частично избежать неопределенности, которые
часто встречаются в проекте. В течение жизненного цикла проекта должна происходить
постоянная переоценка рисков.
Количественная
оценка рисков
определяет вероятность возникновения рисков и влияние последствий рисков на
проект, что помогает группе управления проектами верно принимать решения и
избегать неопределенностей. Количественная оценка рисков позволяет определять:
·
Вероятность
достижения конечной цели проекта
·
Степень
воздействия риска на проект и объемы непредвиденных затрат и материалов,
которые могут понадобиться.
·
Риски, требующие
скорейшего реагирования и большего внимания, а также влияние их последствий на
проект.
·
Фактические
затраты, предполагаемые сроки окончания.
Количественная
оценка рисков часто сопровождает качественную оценку и также требует процесс
идентификации рисков. Количественная и количественная оценка рисков могут
использоваться по отдельности или вместе, в зависимости от располагаемого
времени и бюджета, необходимости в количественной или качественной оценке
рисков.
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
|