Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Уч_Пос_УП.docx
Скачиваний:
4
Добавлен:
01.07.2025
Размер:
727.47 Кб
Скачать

Контрольные вопросы

  1. Охарактеризуйте основное отличие проектной деятельности от операционной

  2. Докажите, что проведение Олимпийских игр в Сочи 2014 является проектом

  3. Опишите основные группы стейкхолдеров проекта Олимпийских игр в Сочи 2014.

  4. Что такое «золотой треугольник управления проектами»? Для чего он используется?

  5. Приведите пример программы и портфеля проектов. Сформулируйте критерии их эффективности.

  6. Сформулируйте цель деятельности менеджера проекта. Чем деятельность менеджера проекта отличается от деятельности линейного менеджера?

  7. В каких проектах необходимо выделение роли куратора проекта

Литература

  1. Руководство к своду знаний по управлению проектами (Руководство PMBOK). Пятое издание// Project Management Institute, 2013. – 614 с.

  2. Управление проектами. Основы профессиональных знаний. Национальные требования к компетентности специалистов (NCB – SOVNET National Competence Baseline Version 3.0) //Сертификационная комиссия СОВНЕТ. М,: ЗАО «Проектная ПРАКТИКА», 2010 – 256 c.

  3. P2M. A Guidebook of Project and Program Management for Enterprise Innovation, Revision 3. – Project Management Association of Japan, 2005

  4. Готин С.В. Логико-структурный подход и его применение для анализа и планирования деятельности / С.В. Готин, В.П. Калоша. – М.: ООО «Вариант», 2007.-118 с.

  5. Демарко Т., Листер Т. Человеческий фактор: успешные проекты и команды, 2-е издание. – Спб.: Символ-Плюс, 2005. -256 с.

  6. Ильина, О.Н. Системный подход к управлению проектами в организации : Монография / О. Н. Ильина. – М.: Креативная экономика, 2012. -208 с.

  7. Козлов, А. С. Методология управления Портфелем Программ и Проектов : монография / А. С. Козлов. - 2-е изд., стер. – М. : ФЛИНТА, 2011. - 194 с.

  8. Математические основы управления проектами: Учебное пособие/ С.А.Баркалов, В.И.Воропаев, Г.И. Секлетова и др. Под ред. В.Н. Бурков а – М.: Высшая школа, 2005. – 423 с.

  9. Фунтов В. Н.Управление проектами развития фирмы: теория и практика. – СПб.: Питер, 2009. - 496 с.

  10. Сайт ГК «Проектная ПРАКТИКА» [Электронный ресурс] – http://www.pmpractice.ru

  11. Портал государственных программ http://www.gosprogrammy.gov.ru

2. Управление содержанием проекта

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

В контексте проекта термин «содержание» может обозначать:

• содержание продукта. Свойства и функции, которые характеризуют продукт, услугу или результат;

• содержание проекта. Работы, которые необходимо выполнить для создания продукта, услуги или результата с указанными характеристиками и функциями [1].

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

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

Цель проекта определяет его предметную область и охватывает всю совокупность продуктов (результатов) проекта.

Например, цель проекта может быть сформулирована следующим образом:

- разработать систему электронного документооборота оценочной компании;

- разработать и внедрить систему электронного документооборота оценочной компании.

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

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

Результат успешного проекта, программы или портфеля – это осязаемые и неосязаемые активы, которые представлены в виде чертежей, схем, описаний, моделей, систем и прототипов различных видов [2].

Результатами проекта могут быть не только товары и услуги, но и организационные/эксплуатационные процессы и изменения.

Процесс управления предметной областью в соответствии со стандартом ICB SOVNET 3.0 представлен в таблице 3.1.

Ключевым документом, содержащим основные элементы содержания проекта, является Устав проекта.

Устав проекта (реже встречаются названия - паспорт, декларация, карточка проекта), краткий (1-2 стр.) документ, «который формально авторизует существование проекта и предоставляет руководителю проекта полномочия использовать ресурсы организации в операциях проекта» [1].

Устав проекта должен содержать:

    • Описание цели и результатов проекта

    • Обоснование запуска проекта

    • Описание состава работ проекта

    • Ключевые заинтересованные стороны и их интересы

    • Основные риски проекта

    • Критерии оценки успешности и т.д.

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

Для определения состава работ проекта используется структурная декомпозиция работ проекта (СДР, Иерархическая структура работ - ИСР, WBS – Work Breakdown Structure).

Инициация

Планирование

Организация и контроль

Анализ и регулирование

Закрытие

  • Анализ проблемы и потребности в проекте;

  • Определение (уточнение) целей и результатов проекта;

  • Определение основных характеристик проекта;

  • Определение критериев успехов и неудач проекта;

  • Определение ограничений;

  • Анализ альтернатив для решения проблемы и выбора варианта проекта;

  • Выбор стратегии осуществления проекта;

  • Разработка Устава проекта;

  • Рассмотрение и утверждение концепции.

  • Уточнение целей и результатов проекта;

  • Уточнение основных характеристик проекта;

  • Подтверждение и уточнение критериев успеха и неудач проекта;

  • Анализ и корректировка ограничений и допущений, принятых на предыдущих стадиях создания проекта;

  • Выбор критериев оценки промежуточных и окончательных результатов проекта;

  • Определение работ проекта;

  • Определение объектов и точек контроля в предметной области проекта;

  • •Разработка плана управления содержанием проекта.

  • Организация выполнения работ проекта;

  • Контроль выполнения работ проекта;

  • Формирование отчетности о ходе выполнения работ проекта (информация, формы отчетности);

  • Ведение баз данных о состоянии предметной области проекта.

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

  • Прогнозирование состояния;

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

  • Анализ причин, вызывающих отклонения в предметной области проекта;

  • Сбор и обработка запросов на изменения в предметной области проекта;

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

  • Доведение информации до участников проекта.

•Проведение заключительного анализа результатов проекта;

• Составление сводного отчета;

• Разрешение спорных и конфликтных ситуаций;

• Формирование архива проекта;

• Извлечение уроков.

Таблица 3.1. - Стадии процесса управления содержанием проекта

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

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

Пакет включает в себя элементы работ, расположенные на низшем уровне СДР.

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

• определение и анализ результатов;

• структурирование и организацию СДР;

• декомпозицию верхних уровней СДР на детализированные компоненты более низких уровней;

• разработку и присвоение идентификационных кодов работам в составе СДР;

• проверку приемлемости степени декомпозиции поставляемых результатов.

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

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

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

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

— результаты проекта, если они достаточно четко определены (рисунок 3.1);

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

Рисунок 3.1 - Пример структурной декомпозиции работ по результатам проекта

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

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

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

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

• от трех до четырех уровней в СДР;

• от 15 до 40 пакетов работ;

• от 40 до 80 часов на средний пакет работ;

• длительность среднего пакета работ — от одной до двух недель;

• от 3 до 7% общего бюджета рабочих часов на средний пакет работ [3].

Достаточность детализации разложения определяется возможностью отнесения каждого элемента нижнего уровня к конкретному подразделению (исполнителю).

Все содержание работ на самых нижних уровнях должно сворачиваться в более высокие уровни, чтобы ничего не было пропущено и не выполнялась лишняя работа. Иногда это называют «правилом 100 %».

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

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

Рисунок 3.2 - Пример структурной декомпозиции работ, выполненной в формате оглавления

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

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

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

Областью применения данного метода являются проекты с высокой степенью неопределенности, недостатком прогнозной информации, высокими рисками, высокой динамикой внешней и внутренней среды проекта. Такие особенности характерны для проектов исследований и разработок (R&D), уникальных, впервые выполняемых работ и т.п.

Иногда вместе с СДР разрабатывается сопроводительный документ – словарь СДР, который может включать:

- идентификатор работы;

- описание работы;

- описание основных контрольных событий (вех проекта);

- фамилию ответственного за выполнение работы.