РАЗРАБОТКА УСТАВА ПРОЕКТА

Стр 1 из 6Следующая ⇒

УНИВЕРСИТЕТ ПУТЕЙ СООБЩЕНИЯ ИМПЕРАТОРА АЛЕКСАНДРА I»

(ФГБОУ ВПО ПГУПС)

Кафедра «Экономика транспорта»

УПРАВЛЕНИЕ ПРОЕКТАМИ

Методические указания

и задания для практических занятий

Санкт-Петербург

2015

УДК 658.5

ББК 65.290-2

У66

Управление проектами: метод. указания и задания для практ. занятий / А. Н. Спасскова. – СПб.: ФГБОУ ВПО ПГУПС, 2015. – 26 с.

Задания и методические указания к практическим занятиям по курсу «Управление проектами» предназначены для студентов-бакалавров, обучающихся по профилям «Производственный менеджмент», «Экономика предприятий и организаций (транспорт)».

УДК 658.5

ББК 65.290-2

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

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

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

РАЗРАБОТКА УСТАВА ПРОЕКТА

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

Задание 1.1. Разработать устав проекта (табл. 1.1) и представить его на обсуждение.

Таблица 1.1

Устав проекта

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

Окончание табл. 1.1

3. Описание проекта высокого уровня

Примечание: Описание высокого уровня – базовое понимание того, что является результатом (продуктом) проекта (примером может служить краткое Техническое задание).

4. Требования к проекту высокого уровня

Примечание: Требования к проекту – ожидания от результата проекта; требования должны быть измеримыми.

5. Риски высокого уровня

Примечание: Базовые риски – те, что очевидны уже на стадии инициации.

6. Бюджет проекта

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

7. Перечень заинтересованных сторон

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

8. Описание контрольных событий

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

9. Критерии эффективности (успеха) по отдельным целям проекта

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

10. Контроль проекта

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

11. Менеджер проекта и его полномочия

Примечание: Краткое изложение должностных инструкций и полномочий менеджера проекта. Зачастую, как минимум, разрабатывает устав проекта, план управления проектом и утверждает «входы» для разработки плана управления проектом.

12. Спонсор проекта

Примечание: Спонсор проекта – лицо, авторизующее проект, принимающее ключевые решения по проекту (включая финансирование) и обладающее правом заверяющей подписи.

УПРАВЛЕНИЕ СОДЕРЖАНИЕМ ПРОЕКТА

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

· планирование управления содержанием – процесс создания плана управления содержанием, документирующего, каким образом будет определяться, подтверждаться и контролироваться содержание проекта;

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

· определение содержания – процесс разработки подробного описания проекта и продукта;

· создание иерархической структуры работ – процесс разделения результатов и работ проекта на более мелкие элементы, которыми легче управлять;

· подтверждение содержания – процесс формализованной приемки результатов проекта;

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

3.1. Сбор требований

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

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

Задание 3.1. Разработать матрицу отслеживания требований (табл. 3.1) и представить результат на обсуждение.

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

1) каждое требование добавляет бизнес-ценность (связывая требование с целями организации и проекта);

2) требования, одобренные в документации по требованиям, выполнены в конце проекта.

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

Таблица 3.1

Матрица отслеживания требований

Код	Описание требования	Источник	Предъявитель требования	Приоритет	Порядок проверки	Подтверждение проверки	Текущий статус
1	2	3	4	5	6	7	8
1	Требования к проекту
1.1
1.2
2	Требования к продукту (и/или к решению)
2.1
2.2

Примечание:

«Описание требования» должно быть лаконичным, но при этом содержать достаточно информации для быстрой идентификации требований.

«Источник» указывает на обоснование требования. Источниками требований могут быть бизнес-потребности организации, цели проекта, ИСР и т. д.

«Предъявитель требования» – лицо, предъявляющее требование.

«Приоритет» указывает на степень значимости требования (соответствующая цифра/буква разработанной шкалы приоритета).

«Порядок проверки» – описывается, каким образом проверяется требование (критерии проверки и в какой фазе).

«Подтверждение проверки» – указывается, проведена проверка или нет.

«Текущий статус» – отражается информация о состоянии требования, например: активно, отменено, отложено, добавлено, одобрено, назначено, выполнено. Формулировка «текущий статус» означает, что работа с требованиями – это итерационный процесс, осуществляемый на протяжении работы над проектом.

Определение содержания

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

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

Задание 3.2. Описать содержание проекта (табл. 3.2) и представить результат на обсуждение.

Таблица 3.2

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

Название проекта:		Подготовлен:
Дата:		Утвержден:
1. Описание содержания продукта
Примечание: Подробное описание продукта проекта. Последовательно уточняются характеристики продукта, услуги или результата проекта, описанного в уставе проекта и в документации по требованиям. Содержание продукта проверяется относительно удовлетворения требований к нему.
2. Критерии приемки продукта
Примечание: Набор условий и критериев, которые должны быть выполнены до того, как поставляемые результаты будут приняты. Данный пункт также должен содержать описание процесса приемки результатов проекта заинтересованными сторонами.
3. Результаты проекта
Примечание: Составляющие (промежуточные цели), которые должны быть достигнуты с тем, чтобы проект считался выполненным. Результаты должны быть четкими и проверяемыми. Результаты количественно описывают компоненты целей и задач, в дальнейшем они сформируют «шапку» ИСР. Окончательные результаты могут также включать в себя вспомогательные результаты, такие как отчеты и документы по управлению проектом.
4. Исключения проекта
Примечание: Исключения (границы проекта) – результаты или работы, которые не включаются в проект. Подобная конкретизация необходима, если ТЗ на текущий момент недостаточно подробно и конкретно, и/или есть информация, что какая-либо из заинтересованных сторон ожидает то, что не планируется выполнять.
5. Ограничения проекта
Примечание: Ограничивающий фактор, влияющий на ход исполнения проекта или процесса. Ограничения либо сужают круг возможных действий команды проекта, либо заставляют действовать ее определенным образом. Практически все проекты осуществляются в рамках как минимум тройного ограничения: содержание, сроки, стоимость. Актуальными также являются ограничения по качеству, срокам, ресурсам, технологии и т. д. Одной из важнейших задач руководителя проекта является балансировка ограничений проекта при удовлетворении ожиданий заинтересованных сторон.

Окончание табл. 3.2

6. Допущения проекта

Примечание: Допущение – это утверждение, которое считается верным или определенным без предоставления доказательств. Событие, вероятность осуществления которого, по вашему мнению (в ходе планирования), 100 %. Допущения могут формулироваться в отношении: доступности ключевых специалистов, информации, оборудования; надежности поставщиков; поддержки руководства; сроков подписания контракта, начала проекта (фаз проекта); квалификации персонала; курсов валют и т. п. Крайне важно выявить как можно больше допущений, чтобы легче было реагировать в случае, если допущения окажутся неверными.

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

УПРАВЛЕНИЕ СРОКАМИ ПРОЕКТА

Управление сроками проекта включает в себя процессы, обеспечивающие своевременное выполнение проекта, а именно (PMBOK 5, 2013 г.):

1) планирование управления расписанием – процесс, устанавливающий процедуры и документацию по планированию, разработке, управлению, исполнению и контролю за расписанием проекта;

2) определение операций – идентификация и документирование конкретных операций, которые необходимо выполнить для получения результатов проекта;

3) определение последовательности операций – определение и документирование взаимосвязей между операциями проекта;

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

5) оценка длительности операций – оценка количества рабочих периодов, необходимых для выполнения отдельных операций с учетом оценки требуемых ресурсов;

6) разработка расписания – составление расписания проекта с учетом последовательности операций, их длительности, потребности в ресурсах и ограничений по срокам;

7) контроль расписания – мониторинг статуса операций проекта для фиксирования прогресса проекта и управления изменениями базового расписания для выполнения плана.

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

Оценка ресурсов операций

Определению длительности операций предшествует оценка требуемых ресурсов по каждой операции. Количество и качество необходимых ресурсов влияют на длительность и риски проекта. На данном этапе ресурсы могут оцениваться в натуральном выражении для дальнейшей стоимостной оценки. Ключевые составляющие процесса оценки ресурсов операций (установленные стандартом PMBOK 5, 2013 г.) представлены на рис. 4.4.

Рис. 4.4. Оценка ресурсов операций

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

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

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

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

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

Задание 4.2. Определить необходимые ресурсы по каждому узлу разработанной ранее сетевой диаграммы проекта; создать иерархическую структуру ресурсов проекта и представить результаты на обсуждение.

Бюджет проекта, ден. ед.

Код	Наименование пакета работ/операций	Временной период/дата						Итого
Код	Наименование пакета работ/операций							Итого
1	2	3	4	5	6	7	8	9
1.1	Операция А
2.1	Операция В
Итого:
Резервы (управленческие):
Всего:

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

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

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

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

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

Представленные выше понятия взаимосвязаны следующим образом:

· затраты по проекту – совокупность затрат по операциям на основании ресурсных оценок (включая резервы на возможные потери по операциям);

· базовый план по стоимости – это затраты по проекту + резервы на возможные потери (по направлениям (пакетам) работ);

· бюджет проекта – это базовый план по стоимости + управленческие резервы.

Библиографический список

1. Коваленок Т. П. Управление проектами: учеб. пособие / Т. П. Коваленок. – СПб.: ПГУПС, 2011. – 73 с.

2. Кутузов А. С. Шаблоны документов для управления проектами / А. С. Кутузов, А. Н. Павлов, А. В. Шаврин. – 2-е изд., испр. – М.: Бином. Лаборатория знаний, 2012. – 159 с.

3. Основы профессиональных знаний и национальные требования к компетентности (НТК) специалистов по управлению проектами / СОВНЕТ. – М.: ЗАО «Проектная практика», 2010. – 256 с.

4. Материалы курса «Управление проектами. Стандарт PMBOK 5» ЧОУ ДО «Центр бизнес-образования проектного менеджмента», 2013 [Электронный ресурс]. – Режим доступа: www.pmblc.ru.

5. Руководство к Своду знаний по управлению проектами. – Пятое изд. PMI, Inc. – Newtown Square, Pennsylvania, USA: Project Management Institute. – 614 с.

6. Сооляттэ А. Ю. Управление проектами в компании: методология, технологии, практика / А. Ю. Сооляттэ. – М.: Синергия, 2012. – 816 с.

7. Троцкий М. Управление проектами / М. Троцкий, Б. Груча, К. Огонек. – М.: Финансы и статистика, 2011. – 304 с.

8. Хелдман К Профессиональное управление проектом / К. Хелдман; пер. с англ. – М.: Бином. Лаборатория знаний, 2012. – 728 с.

Оглавление

1. Разработка устава проекта ………………………………………………………..	3
2. Определение заинтересованных сторон проекта ……………………………….	5
3. Управление содержанием проекта ……………………………………………….	8
3.1. Сбор требований ………………………………………………………......	9
3.2. Определение содержания ………………………………………………....	10
3.3. Создание иерархической структуры работ ……………………………...	12
4. Управление сроками проекта …………………………………………………….	14
4.1. Определение последовательности операций ………………………….	15
4.2. Оценка ресурсов операций ……………………………………………...	18
4.3. Оценка длительности операций ……………………………...………...	19
4.4. Разработка расписания проекта ………………………………………...	20
5. Управление стоимостью проекта ……………………………………….………..	23
Библиографический список ……………………………………………….………...	25

Учебное издание

УПРАВЛЕНИЕ ПРОЕКТАМИ

Методические указания и задания

для практических занятий

Разработала: канд. экон. наук, РМР, доцент Спасскова А. Н.

Редактор и корректор И. А. Шабранская

Компьютерная верстка М. С. Савастеевой

План 2014 г., № 166

Подписано в печать с оригинал-макета 16.10.2015.

Формат 60× 84 ¹/₁₆. Бумага для множ. апп. Печать ризография.

Усл. печ. л. 1, 7. Тираж 300 экз.

Заказ 963.

ФГБОУ ВПО ПГУПС. 190031, СПб., Московский пр., 9.

Типография ФГБОУ ВПО ПГУПС. 190031, СПб., Московский пр., 9.

УНИВЕРСИТЕТ ПУТЕЙ СООБЩЕНИЯ ИМПЕРАТОРА АЛЕКСАНДРА I»

(ФГБОУ ВПО ПГУПС)

Кафедра «Экономика транспорта»

УПРАВЛЕНИЕ ПРОЕКТАМИ

Методические указания

и задания для практических занятий

Санкт-Петербург

2015

УДК 658.5

ББК 65.290-2

У66

УДК 658.5

ББК 65.290-2

РАЗРАБОТКА УСТАВА ПРОЕКТА

Задание 1.1. Разработать устав проекта (табл. 1.1) и представить его на обсуждение.

Таблица 1.1

Устав проекта

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

Окончание табл. 1.1

12 3 4 5 6 Следующая ⇒

Последнее изменение этой страницы: 2019-04-09; Просмотров: 990; Нарушение авторского права страницы