Управление критическим процессом в проекте

Вступление

планирование зоопарк бюджет В течение последних десятилетий сформировалась новая научная дисциплина — управление проектами (project management) — раздел теории управления социально — экономическими системами, изучающий методы, формы, средства наиболее эффективного и рационального управления изменениями. В течение многих веков человечеству приходилось реализовывать множество проектов. Растущая сложность проектов, с одной стороны, и накопленный опыт управления, с другой, сделали необходимым и возможным создание идеологии и методологии управления проектами. бурное развитие кибернетики, теории управления и исследования операций в середине 20 сториччя позволило создать ряд формальных моделей и тем самым заложить систематическую научную основу управления проектами Актуальность данной темы определяется тем, что в Луганске не имеет зоопарке, а есть лишь не большой зооуголок, который и так находится в плачевном состоянии.

Объектом исследования является процесс исследования состояния существующего зооуголка.

Предметом исследования является процесс Модернизация зооуголка.

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

1. Планирование содержания и исполнителей проекта модернизации зооуголка г. Луганска в зоопарк

1.1 Иерархическая структура работ

Содержание проекта разрабатывается на основе такого инструмента, как WBS — иерархическая структура работ.

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

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

Иерархическая структура работ (ИСР) (Work Breakdown Structure, WBS) — это иерархическая декомпозиция работ, выполняемых командой проекта для достижения целей проекта и необходимых результатов поставки и ориентированная на результат поставки. С ее помощью структурируется и определяется все содержание проекта. Каждый следующий уровень иерархии отражает более детальное определение элементов проекта. ИСР разбивается на пакеты работ.

Ориентированность на результат поставки включает внутренние и внешние результаты поставки.

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

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

Work (Работа) — непрерывное физическое или умственное усилие, направленное на преодоление препятствий и достижение целей или результатов; специфическая задача, обязанность, функция или задание, часто являющиеся частью фазы или другой, большей по объему работы; что-то, производимое или выполняемое в результате усилия или применения навыков (квалификации).

Breakdown (Декомпозиция) — разделение на части или категории, выделение простых составляющих.

Structure (Структура) — фиксированное упорядоченное множество объектов и отношений между ними, классификация чего-либо по заданному основанию.

Эти определения означают, что Структура Декомпозиции Работ (WBS) имеет следующие характеристики:

· Описывает с необходимой точностью содержание работ по проекту;

· Определяет весь объем работ по проекту;

· Формируется в виде иерархической структуры (проект декомпозируется на пакеты / субпакеты и т. д. работ).

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

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

ИСР может быть представлена в виде:

· таблицы (очень удобный метод отражения)

· ментальной карты (например, в FreeMind)

· иерархической структуры задач (например, в Microsoft Project)

· диаграммы на рыбьих костях.

Главные цели разработки WBS структуры:

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

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

Все элементы ИСР имеют специальную кодировку, смысл которой — присвоить каждому элементу уникальный номер.

Самый верхний уровень имеет код 0 (ноль) и его часто именуют просто: «проект». Элементы первого уровня нумеруются последовательно от 1 до количества элементов на уровне (обычно не более 7). Второй и последующие уровни нумеруется таким образом, чтобы элемент сохранил ссылку на вышестоящий.

В данной работе проект имеет код Z, поэтому все данные, закодированные с начальной буквой «Z», принадлежат к первому уровню проекта. Буквенный символ «Z» и одна цифра WBS будут представлять элементы WBS-структуры второго уровня. На примере достаточным есть цифровая система и буква «Z», элементы которой имеют такие коды:

Z Реконструированный зооуголок

Z.1. Проведение работ по реконструкции зооуголка

Z.1.1. Принятие решения о реконструкции зооуголка

Z.1.2. Демонтаж зооуголка

Z.1.3. Разработка инженерно-технической документации

Z.1.4. Конструирование вольеров для животных

Z.2. Проведение рекламной компании

Z.2.1. Печатная реклама

Z.2.2. ТВ и радиореклама

Z.2.3. Интернет реклама

Z.3. Обеспечение проекта

Z.3.1. Подбор персонала

Z.3.2. Доставка животных

Z.3.3. Закупка материалов

Z.3.4. Открытие зоопарка Дальше приведем пример разработанной WBS-структуры проекта модернизации зооуголка г. Луганска в зоопарк на рис. 1.1

Рис. 1.1 Иерархическая структура работ проекта Представлена трехуровневая рабочей структура проекта по модернизации зооуголка. Первый уровень — это сам проект, второй — это субпроекты, сформированные по продуктовым принципу: обеспечение кадрами, техническое обеспечение, программное обеспечение и управление проектом. На третьем уровне WBS находятся рабочие пакеты для первых трех субпроектов, а управление проектом не детализируется. То есть следует подчеркнуть, что глубина разбивки по определенным блоками может быть разной.

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

1.2 ОBS-структура проекта

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

на первом уровне отображается организационная структура как единый элемент;

на втором и более низких уровнях продолжается деление структуры на основные организационные элементы. (рис. 1.2).

Рис. 1.2 Организационная структура проекта Этот процесс повторяется до самого низкого уровня — базовых рабочих групп (смешанных целевых или функциональных), а при реализации малых проектов — до отдельных исполнителей.

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

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

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

Кодирование OBS-структуры:

Z Высшее руководство компании

Z.1. Проектный комитет

Z.2. Менеджер проекта

Z.2.1. Руководитель финансов

Z.2.1.1. Исполнители

Z.2.2. Руководитель персонала

Z.2.2.1. Специалист по кадрам 1 категории

Z.2.3. Главный инженер

Z.2.3.1. Подрядчик

Z.2.3.2. Руководитель по маркетингу

Z.2.3.2.1. Руководитель по охране труда

Z.3. Куратор проекта

Z.3.1. Ответственный за работу с фондом На рисунке 1.2 приведена организационная структура проектной команды для модернизации зооуголка, где первый уровень — это проектная команда во главе с высшим руководством компании, второй уровень — управленческая команда во главе с менеджером проекта, третий уровень — основные подразделения для выполнения работы.

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

1.3 Построение RAM-матрицы проекта

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

Таблица 1.1. Матрица ответственности проекта

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

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

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

2. Планирование сроков проекта

2.1 Формирование PDM-сетки проекта

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

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

Рис. 2.1 PDM — сеть проекта

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

Если для простоты расчетов параметров графика использовать не даты, а номера дней и договориться, что работа A может начинаться сегодня — в день с номером 0, то для работы, А расчет ранних дат выполняется следующим образом:

Ранний старт: день с номером 0

Ранний финиш равен «ранний старт» плюс «длительность»: 0 +2 = 2 день Т.к. нам не известно точное время завершения работы A во второй день сделаем допущение, что следующую в графике работу можно начинать в тот же день, когда заканчивается предыдущая задача.

Тогда для работы B ранние даты старта и финиша:

Ранний старт: день с номером 2

Ранний финиш: 2 + 15 = 17 день Таким же образом выполняются расчеты ранних дат старта и финиша для всех задач сетевого графика. Если задач-предшественников несколько (как у задачи F) — при расчете раннего старта выбирается наибольшее значение из имеющихся дат ранних финишей.

Для определения поздних дат старта и финиша по задаче используются следующие правила:

Поздняя дата финиша задачи равна поздней дате старта задачи-последователя (если у задачи нет последователя, поздний финиш задачи равен ее раннему финишу).

Если задач-последователей несколько (как у задачи А) — выбирается наименьшее значение из имеющихся.

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

2.2 Расчет продолжительности проекта PERT методом

PERT почти полностью совпадает с методом критического пути (СРМ), за исключением того, что PERT считает, что продолжительность каждой операции имеет пределы, которые исходят из статистического распределения.

PERT использует 3 оценки расчета времени для каждой операции:

· оптимистическое (наилучшее);

· средний показатель;

· пессимистическое (наихудшее).

Разработчики PERT для выражения продолжительности операции решили избрать аппроксимацию бета-распределения.

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

Средневзвешенное время операции рассчитывается по следующей формуле:

(2.1.)

где t_e — средневзвешенное время операции;

а — оптимистическое время операции (1 шанс из 100, что при нормальных условиях операция будет закончена раньше срока);

b — пессимистическое время операции (1 шанс из 100, что при нормальных условиях операция будет закончена позже срока);

m — наиболее вероятное время операции.

Рис. 2.2. Работы на критическом пути Таблица 2.1. Расчет продолжительности проекта PERT методом

Среднее (детерминистическое) значение накладывают на сеть проекта, как и при использовании СРМ, и затем рассчитывают раннее, позднее, резервное и время завершения проектных работ, как они указаны в СРМ.

Отклонения в оценках времени операции определяются при помощи следующих уравнений. Уравнение 2.2 представляет стандартное отклонение для операции.

(2.2)

(2.3)

Уравнение 2.3 представляет стандартное отклонение для проекта.

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

Средняя продолжительность проекта (Т_Е) — это сумма всех средних показателей времени, отведенных на выполнение операций по критическому пути (сумма от t_e), и она следует нормальному распределению.

==4,14

t

844,14 (79,86 — 88,14)68%

t

848,28 (75,72 — 92,28)

t

8412,42 (71,58 — 96,42))

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

Уравнение 2.4 используется для расчета величины Z, приводимой в статистических таблицах (Z — количество стандартных отклонений от средней величины):

(2.4)

где Т_Е — продолжительность критического пути;

T_S — продолжительность работы по графику;

Z — вероятность (выполнения графика)

1=(4*13+10+15)/5=15,4

2=(4*30+22+35)/5=35,4

(4*20+13+24)/5=23,4

(4*20+17+25)/5=24,4

(4*1+1+2)/5=1,4

Рис. 2.3. Расчет времени PERT методом

(15−10)/5=1

(35−22)/5=2,6

(24−13)/5=2,2

(25−17)/5=1,6

(2−1)/5=0,2

Рис. 2.4. Расчет сигмы — стандартного отклонения

2.3 Календарное планирование проекта

PDM — сеть проекта даёт представление о критическом пути и длительность в рабочих днях при условии, что нет ограничений на ресурсы для выполнения работ проекта. В реальной жизни выполнение проекта останавливается в праздничные, выходные дни. Кроме того, запланированная длительность работ может увеличиться из-за невозможности использовать некоторые ресурсы на протяжении запланированных рабочих дней. Это приводит к увеличению фактической длительности проекта.

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

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

Рис. 2.5 график Ганта проекта Планы-графики в перечень работ включают решения о результатах выполнения работ и вспомогательные работы (передача информации, контроль результатов и т. п.), что позволяет увидеть взаимную обусловленность работ, которые включены в план.

3. Ресурсное планирование

3.1 Планирование ресурсов

Планирование ресурсов — это процесс определения потребностей в ресурсах для выполнения работ проекта. А именно, определение:

* типов необходимых ресурсов — людских, материальных, финансовых;

* количества этих ресурсов и их единичной стоимости;

* сроков использования ресурсов;

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

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

* ИСР и оценки длительности операций;

* Констатация содержания;

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

Лист ресурсов представлен на таблице 3.1

Таблица 3.1. Лист ресурсов

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

На таблице 3.2 изображена каждая работа, кто ее выполняет и сколько она длится.

Таблица 3.2. Использование ресурсов

3.2 Бюджет проекта

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

Результатами оценки стоимости являются:

Смета. Смета — это количественная оценка вероятных значений стоимости ресурсов, необходимых для завершения работ проекта. Они могут быть представлены суммарно или подробно (таблица 3.3).

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

Таблица3.3. Смета проекта

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

Оценка стоимости может уточняться в ходе выполнения проекта, для того чтобы отразить дополнительные детали. Для некоторых прикладных сфер разработаны рекомендации относительно того, когда и с каким ожидаемым степенью точности должны выполняться подобные усовершенствования. Например, компания ААСЕ International определила такую последовательность из пяти типов оценки в строительных проектах на стадии инжиниринга: порядок величин, концептуальная, подготовительная, основная и контрольная.

Стоимостные оценки рассчитываются на протяжении всего проекта. Чтобы начать проект, необходимо сначала проверить концептуальные (предпроектные) оценки его стоимости. На этом этапе используется ется предварительная оценка, так называемая оценка «порядка величины» (order of magnitude estimate), отличие которой от реальной стоимости лежит в интервале от -25% до + 75%. По ходу реализации проекта нужны точ-ниши оценки. При этом определение сметной стоимости (budget estimates) проводится с точностью от 10% до 25%. И наконец, к моменту установления согласованной базовой цены проекта (project cost baseline) необходимо провести окончательную стоимостную оценку (definitive estimate), значение которой не должно быть меньше реальной более чем на 5% и превышать ее более чем на 10%.

3.3 Построение и анализ ресурсных профилей проекта

Актуальной проблемой ресурсного планирования является возникновение «ресурсных конфликтов». Ведь многие работы проекта выполняются одновременно. При распределении ресурсов по таким работам возможны ситуации, когда какого-либо ресурса не хватает для обеспечения всех работ. И, наоборот — в некоторые периоды этот ресурс потребляется лишь на одной-двух работах. Для преодоления ресурсных конфликтов проводят процедуру выравнивания ресурсных профилей. В учебниках [1, 2], при объяснении этой процедуры используются столбчатые диаграммы потребления ресурсов в разные периоды осуществления проекта. Авторы подразумевают, что высотакаждого столбика диаграммы определяется суммой количеств данного ресурса, требуемых всеми одновременно выполняемыми работами. Но ни в тексте, ни на диаграмме не просматривается вклад каждой работы в эту общую сумму. Также не показано, как и за счет чего изменяется высота каждого столбика в процессе выравнивания. Это затрудняет понимание студентами сути процедуры выравнивания ресурсных графиков. Приводится лишь результат выравнивания, когда все столбики на диаграмме не превышают по высоте предельное (доступное) значение количества ресурса. В курсе «Управление проектами», читаемом в МИТСО, мы используем для выравнивания ресурсных профилей те же инструменты, что и для календарного планирования. Линейные диаграммы, предложенные Генри Гантом [3], называют также «ленточными». Но на практике обычно чертят линии, длина которых пропорциональна продолжительности соответствующей работы. Для ресурсного планирования удобнее использовать именно ленточки, ширина которых должна показывать количество ресурса, необходимое для выполнения данной работы. На рис. 1 это количество продублировано также цифрами, расположенными справа от оси ординат. Пунктирной линией обозначено предельно доступное количество планируемого ресурса в день (50 единиц). Уже по потребностям первых трех работ видно заметное превышение этого предела, если производить указанные работы одновременно. А если суммировать потребности всех работ в каждый момент времени на протяжении всего периода выполнения данного пакета работ, то такое превышение предельного количества ресурса будет наблюдаться в течение 55 дней. Выход из создавшейся ситуации в том, что некритические работы (имеющие резерв времени) могут выполняться не только в ранние сроки начала и окончания. Сроки их выполнения можно сдвинуть в пределах резерва времени каждой работы, и это не нанесет ущерба проекту в целом. Зато при таком сдвиге можно добиться выравнивания графика потребления ресурсов. Например, сдвинув выполнение всех некритических работ в сторону поздних сроков начала и окончания, можно решить вышеупомянутый ресурсный конфликт для первых трех работ, но возникнут такие конфликты в другие периоды и для других работ. В этом случае превышение потребностей в ресурсе над его предельным уровнем будет наблюдаться в течение 40 дней (рис. 3.1).

Рис. 3.1 Ресурсный профиль всех ресурсов до выравнивания Рис. 3.2. Ресурсный профиль всех ресурсов после выравнивания

3.4 Рабочие задания на пакеты работ

Цель проекта по СМАРТ методу: модернизировать зооуголок м. Луганска в зоопарк на базе парка им. 1 мая до 1.06.2014, стоимостью не более 1 млн. грн.

Концепция проекта «Модернизации луганского зооуголка в зоопарк» представлена в таблице 3.4

Таблиця 3.4. Концепція проекту

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

Таблица 3.5. Логическая матрица проекта

4. Управление критическим процессом в проекте

4.1 Определение критического процесса в проекте

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

Таблица 4.1. Описание проблемы как причины инициализации проекта

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

Таблица 4.2. Матрица заинтересованных сторон проекта

В матрице хорошо просматривается отношение каждого заинтересованной стороны в проект. В таблице 4.3. представлена оценка заинтересованных сторон проекта.

Таблица 4.3. Матрица оценки заинтересованных сторон проекта

Таблица 4.4. Оценка уровня критичности процессов управления проектом модернизации зооуголка г. Луганска в зоопарк

4.2 Обоснование и выбор инструментов для снижения критичности процессов в проекте

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

Событие риска — потенциально возможное событие, которое может нанести ущерб или принести выгоды проекту.

Вероятность возникновения риска — вероятность того, что событие риска наступит. Все риски имеют вероятность больше нуля и меньше 100%. Риск с вероятностью 0 не может произойти и не считается риском. Риск с вероятностью 100% также не является риском, поскольку это достоверное событие, которое должно быть предусмотрено планом проекта.

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

Величина риска — показатель, объединяющий вероятность возникновения риска и его последствия.

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

Таблица 4.5. План управления рисками проекта модернизации зооуголка г. Луганска в зоопарк

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

На этапе планирования в соответствии с принятой политикой и процедурами в процессе управления рисками организация должна осуществлять следующие действия:

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

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

— идентифицировать риски.

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

Выводы

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

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

Список используемой литературы

1. Гилев А. П. Зоопарки и проблема сохранения диких видов животных // Первое всесоюзное совещание по проблемам зоокультуры. Тезисы докладов. Часть вторая. Москва, 1986. С. 190−192.

2. http://www.zoo.kharkov.ua/files/01.pdf Харьковский зоопарк. Сборник научных статей. Выпуск 5

3. Шапиро В. Д. і ін. Керування проектами. Підручник для вузів — Спб; «Дватри», 1996.

4. Управління проектами. Український досвід. С.Н. Анісімов, Є.В. Анісімова. — СПб.: Вектор, 2006.

5. Разу М. Л. і ін. Модульна програма для менеджерів. Керування програмами й проектами 8. М.: ІНФРАнМ, 2000.

6. Румянцева К. Р. Менеджмент в организации. — М.: УЦ «Перспектива», 2004. -321 с.

7. Тарасюк Г. М., Шваб Л.І. Планування діяльності підприємства. Навчальний посібник. Київ: «Каравела», 2003.

8. Тарасюк Г. М. Управління проектами: Навч. посібн.-К.:Каравела, 2004.-344 с.

9. Керівництво з питань проектного менеджменту. Пер. з англ. (Под ред. Бушуева С.Д.) К.: Деловая Украина, 2000.-198 с.

10. Клиффорд Ф. Грей, Эрик У. Ларсон. Управление проектами: Практическое руководство/ Пер. с англ.-М.: Дело и сервис, 2003.-528с

11. Мазур.И.И., Шапиро В. Д., Ольдерогге Н. Г. Управление проектами. Учебн. пособие. — М.: Омега-Л, 2004.-664 с.