ТЕМА 2: Методология управления ИТ-проектами

ТЕМА 2: Методология управления ИТ-проектами

Процесс разработки инвестиционного ПО

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

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

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

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

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

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

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

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

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

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

 

Стандарты комплекса ГОСТ 34

ГОСТ 34 задумывался в конце 80-х годов как всеобъемлющий комплекс взаимоувязанных межотраслевых документов. Объектами стандартизации являются АС различных (любых!) видов и все виды их компонентов, а не только ПО и БД.

Комплекс рассчитан на взаимодействие заказчика и разработчика. Аналогично ISO12207 предусмотрено, что заказчик может разрабатывать АС для себя сам (если создаст для этого специализированное подразделение). ГОСТ34 в основном уделяет внимание содержанию проектных документов.

Общая структура - см. самостоятельно.

МОДЕЛЬ SEI SW-CMM

Методология CMM разрабатывалась и развивалась в США как средство, позволяющее выбирать лучших производителей ПО для выполнения госзаказов.

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

СММ – стандарт де-факто.

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

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

 

Незрелая организация

Зрелая организация

1. отсутствует долговременное и проектное планирование; 2. процесс ПО и его ключевые составляющие не идентифицированы, реализация процесса зависит от текущих условий, конкретных менеджеров и исполнителей; 3. методы и процедуры не стандартизированы и не документированы; 4. результат не предопределен реальными критериями, вытекающими из запланированных показателей, применения стандартных технологий и разработанных метрик; 5. процесс выработки решения происходит стихийно, на грани искусства.

1. имеются четко определенные и документированные процедуры управления требованиями, планирования проектной деятельности, управления конфигурацией, создания и тестирования программных продуктов, отработанные механизмы управления проектами; 2. процедуры постоянно уточняются и совершенствуются; 3. оценки времени, сложности и стоимости работ основываются на накопленном опыте, разработанных метриках и количественных показателях, что делает их достаточно точными; 4. актуализированы внешние и созданы внутренние стандарты на ключевые процессы и процедуры; 5. существуют обязательные для всех правила оформления методологической программной и пользовательской документации; 6. технологии незначительно меняются от проекта к проекту на основании стабильных и проверенных подходов и методик; 7. максимально используются наработанные в предыдущих проектах организационный и производственный опыт, программные модули, библиотеки программных средств; 8. активно апробируются и внедряются новые технологии, производится оценка их эффективности.

 

СММ определяет 5 уровней технологической зрелости компании:

1. Уровень 1, начальный - организации, разрабатывающие ПО, но не имеющие осознанного процесса разработки, не производящие планирования и оценок своих возможностей;

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

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

4. Уровень 4, управляемый - в этих организациях, помимо установленного и описанного процесса, используются измеримые показатели качества продуктов и результативности процессов, которые позволяют достаточно точно предсказывать объем ресурсов (времени, денег, персонала), необходимый для разработки продукта с определенным качеством);

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

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

 

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

Основными фазами модели MSF являются:

1. Создание общей картины приложения (Envisioning ). На этом этапе решаются следующие основные задачи: оценка существующей ситуации; определение состава команды, структуры проекта, бизнес-целей, требований и профилей пользователей; разработка концепции решения и оценка риска. Устанавливаются две промежуточные вехи: «Организован костяк команды» и «Создана общая картина решения».

2. Планирование (Panning). Этап состоит из трех стадий:

- концептуальное проектирование - определение набора сценариев использования системы,

- логическое проектирование - решение представляется в виде набора сервисов

- физическое проектирование - уточняются используемые технологии и интерфейсы.

3. Разработка (Developing). Создается вариант решения проблемы, в виде кода и документации очередного прототипа, включая спецификации и сценарии тестирования. Основная веха этапа – «Окончательное утверждение области действия проекта». Продукт готов к внешнему тестированию и стабилизации.

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

5. Развертывание (Deploying). Выполняется установка решения и необходимых компонентов окружения, проводится его стабилизация в промышленных условиях и передача проекта в руки группы сопровождения. Кроме того, анализируется проект в целом на предмет уровня удовлетворенности заказчика.

ТЕМА 4: ПРОЦЕССЫ УПРАВЛЕНИЯ ПРОЕКТАМИ: ИНИЦИАЦИЯ, ПЛАНИРОВАНИЕ, ИСПОЛНЕНИЕ, КОНТРОЛЬ, ЗАВЕРШЕНИЕ.

 

Процессы инициации

2. Процессы планирования

Процессы исполнения

Качественные методы

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

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

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

4. По аналогиям.

Количественные методы

1. Исследования – определение рыночного потенциала, степени удовлетворенности нужд потребителей.

2. Пилотный тест - представляет собой апробацию проекта в ограниченных масштабах. Это может быть рыночный тест продукта в небольшой части рын­ка или рабочая модель проекта по строительству.

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

4. Метод весовых коэффициентов -производится в 4 этапа.

1 этап — определение фак­торов (критериев), которые могут в значительной степени повлиять на ус­пешность выполнения проекта.

2 этап — оценка весомости (ранга) каждого из перечис­ленных факторов. Сумма рангов всех должна быть равна 1.

3 этап — проект(-ы) или варианты одного проекта не­обходимо оценить по каждому из факторов (критериев) оценки. При этом может использоваться любая система оценок.

4 этап — рассчитывается экспертная оценка влияния каждого фактора путем перемножения веса каждого фактора на оценку этого фактора для каждого варианта. Интегральная эк­спертная оценка приоритетности вариантов проекта определяет­ся как сумма по графам 9—13.

 

Таблица 3.2 - Форма для экспертной оценки вариантов

№ п/п	Характеристика, фактор	Показатель весомости	Номер проекта или варианта проекта	Интегральная оценка проекта
						…				…
…
Всего	-	1,0	-	-	-	-

 

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

При оценке эффективности ИП необходимо соизмерять разновременные стоимостные показатели. Для этого стоимостные показатели приводятся к настоящему моменту времени с помощью дисконтирования. Дисконтирование осуществляется с помощью коэффициента дисконтирования. , е – норма дисконта, или ставка %, под который можно занять средства, или темп инфляцииСравнение различных ИП и выбор наилучшего их них производится с использованием следующих показателей: 1. Чистый дисконтированный доход (ЧДД, NPV) – определяется как разница между приведенными к настоящей стоимости суммой денежного притока и суммой инвестированных в ИП средств. ,t – год;ДП_t – денежный приток в году t; ИС_t– инвестируемые средства в году tЕсли ЧДД > 0, то проект следует принять; NPV = 0, то проект ни прибыльный, ни убыточный. Чем больше ЧДД, тем выгоднее проект. 2. Индекс доходности (I) – определяется как отношение дисконтированной суммы денежного притока к дисконтированной сумме инвестированных в ИП средств. ,Если I > 1, то ИП будет приносить прибыль. 3. Срок окупаемости – это минимальный временной интервал, начиная с которого все затраты по осуществлению ИП покрываются суммарными результатами по ИП. Если доход распределен по годам равномерно, то срок окупаемости рассчитывается делением единовременных затрат на величину годового дохода, обусловленного ими. Если прибыль распределена неравномерно, то срок окупаемости рассчитывается прямым подсчетом числа лет, в течение которых инвестиция будет погашена кумулятивным доходом. 4. Внутренняя норма доходности – это та ставка % (норма дисконта), при которой дисконтированная сумма денежного притока равна дисконтированной сумме инвестированных в ИП средств.

5. ROI – это коэффициент, который позволяет измерить прибыльность проекта, т.е. прибыльность инвестированного в проект капитала. Оценка ROI делается в пределах утвержденного в компании периода окупаемости для проекта. Некоторые компании закладывают минимальное пороговое значение ROI, например, равное 12% для всех новых проектов компании. Чем выше ROI, тем лучше. ROI рассчитывается как отношение ЧДД к затратам на проект.

=2=

 

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

Деятельность по разработке планов охватывает все этапы создания и реализации проекта. На этапе планирования определяются все необходимые параметры реализации проекта:

- продолжительность по каждому из контролируемых элементов проекта,

- потребность в трудовых, материально-технических и финансовых ресурсах,

- сроки поставки сырья, материалов, комплектующих и технологического оборудования,

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

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

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

Принципы планирования:

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

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

- Сбалансированность по ресурсам означает, что планы не содержат задач и работ, не обеспеченных необходимыми ресурсами.

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

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

- Многофункциональность планирования означает обязательное планирование по всем функциям управления проектом.

- Оптимальность планирования предполагает способность системы формировать не просто приемлемые планы, а лучшие планы по выбранным критериям.

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

- Непротиворечивость планирования обеспечивается преемственностью и взаимоувязанностью всех плановых решений.

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

- Стабильность планирования обеспечивается неизменностью основных целей проекта, его жизнеспособностью.

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

Таблица 1 – Процессы планирования

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

 

 

Выделяют следующие виды планов:

1. концептуальный план проекта;

2. стратегический план реализации проекта;

3. тактические (детальные, оперативные) планы.

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

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

1. что мы собираемся сделать?

2. как мы это сделаем?

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

 

Таблица 4.2.- Последовательность шагов календарного планирования

№	Шаг	Содержательная сущность шага
	Разработка концепции и целей проекта	Почему?
	Построение иерархической структуры работ	Что?
	Построение структурной схемы организации работ. Назначение ответственных	Кто?
	Разработка стратегии реализации. Определение основных вех	Как?
	Разработка сетевых моделей. Определение тактики проекта	Подробно как?
	Расчет календарного графика работ	Когда? Идеальные сроки
	Расчет календарного графика с учетом ограничений на ресурсы	Когда? Реальные сроки
	Оценка затрат. Разработка финансового плана (бюджета) проекта	Сколько это будет стоить?
	Разработка и принятие базового плана проекта	Все учтено?

 

Планы проекта могут формироваться с позиции 2 разных подходов:

1. сверху вниз

2. снизу вверх

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

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

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

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

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

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

 

=3=

Процесс исполнения проекта включает выполнение всех запланированных работ, направленных на создание результата проекта, и управление, включая мониторинг выполняемых работ, контроль выполне­ния и управление изменениями в проекте. Работы по созданию результата проекта обычно достаточно специфичны. Они относятся к специальным предметным областям УП.

В группу процессов исполнения входят следующие процессы:

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

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

3. Набор и развитие команды проекта - процесс нужен для подбора людей, необходимых для успешного выполнения работ проекта.

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

5. Выбор поставщиков -получение информации от поставщиков о предоставляемых услугах, ценах и т.д. для выбора наиболее подходящих предложений.

Результатом исполнения проекта должны стать:

- созданные продукты или услуги, необходимые для выполнения проекта;

- осуществленные в ходе выполнения проекта изменения;

- реализованные корректирующие действия, необходимые для достижения ожидаемой эффективности;

- выполненные спланированные заранее действия по смягчению последствий рисков проекта;

- информация о степени завершенности работы, качестве исполнения и использовании ресурсов.

 

=4=

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

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

Мониторинг – это процесс, предполагающий сбор, измерение и распрост­ранение информации об исполнении проекта, ее регистрацию, оценку измене­ний и подготовку информации для принятия решений по проекту.

Целью мониторинга является предо­ставление руководству проекта оперативной интегрированной информации о реализации проекта, достаточной для принятия ключевых ре­шений по проекту.

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

- сравнение текущего хода исполнения работ проекта с первоначальным планом проекта;

- оценку хода исполнения для выявления моментов, требующих корректирующих или предупреждающих действий;

- анализ, отслеживание и мониторинг рисков проекта для своевременного их выявления, и реагирования;

- ведение достоверной и актуальной информационной базы вплоть до завершения проекта;

предоставление информации для составления отчетов о текущем состоянии, оценки прогресса и прогнозирования.

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

Основной целью контроля проекта - обеспечение вы­полнения плановых показателей и повышение обшей эффектив­ности проекта.

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

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

Процесс контроля включает 3 стадии:

1. отслеживание: сбор и документирование фактических дан­ных;

2. анализ: оценка текущего состояния работ и сравнение фактического выполнения с запла­нированным показателям; определение причины и путей воздействия на отклонения от выполне­ния плана;

3. корректировка: планирование и осуществление действий, направленных на минимизацию неблагоприятных отклонений или по­лучения преимуществ от возникновения благоприятных отклонений.

=5=

Завершение проекта – это процесс, закрывающий все контракты и формально завершающий все проектные работы.

В рамках процесса завершения выполняется:

- сдача контрактных документов в архив проекта;

- создание аудиторского отчета о процессах проекта;

- формальная приемка результатов проекта заказчиком.

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

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

Проект надо считать завершенным в следующих ситу­ациях.

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

- Работа над его продуктом завершается с получением негативного ре­зультата, который в рамках данного проекта уже не может быть изме­нен. Как известно, получение отрицательного результата — это тоже результат.

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

- Руководитель и команда проекта становятся нежелательными для за­казчика или организации-исполнителя.

Процесс завершения заключается в выполнении двух задач:

1.закрытие контрактов;

2.закрытие проекта.

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

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

1. проверка финансовой отчетности

2. паспортизация

3. выявление невыполненных обязательств

4. завершение невыполненных обязательств

5. гарантийное обслуживание и окончательные расчеты.

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

Идентификация риска.

Таблица 12.1 - Классификация рисков

Вид риска	Характеристика
Классификация рисков для оценки:
Экономический риск,в т.ч. внешнеэкономический риск	Риск, связанный с нестабильностью экономического законода­тельства и текущей экономической ситуации, условий инвестиро­вания и использования прибыли, возможность введения ограни­чений на торговлю и поставки, закрытия границ и т.п
Природно-климатический риск	Неопределенность природно-климатических условий, возможность стихийных бедствий
Производственно--технологический риск	Неполнота или неточность информации о динамике технико-экономических показателей, параметрах новой техники и технологии, аварии и отказы оборудования, производственный брак, риск невыполнения планиру­емых объемов работ и/или увеличения затрат, недо­статки производственного планирования и, как следствие, уве­личение текущих расходов предприятия
Инвестиционный риск	Рисквозможного обесценивания инвестиционно-финансового портфеля, состоящего как из собственных ценных бумаг, так и приобретенных
Рыночный риск	Риск колебания рыночной конъюнктуры, цен, валютных курсов и т.п.
Политический риск	Риск понесения убытков или сни­жения прибыли вследствие изменений в государственной по­литике, неопределенности политической ситуации, неблагопри­ятных социально-политических изменений в стране или регионе
Финансовый риск	Риск, связанный с осуществлением операции с финансовыми активами. Включает процентный, кредитный и валютный риски. Процентный риск возникает обычно при заключении