- •Раменская л.А. Управление проектами
- •Введение
- •1. Объекты, субъекты и процессы управления проектами
- •1.1 Объекты управления проектами
- •1.2 Субъекты управления проектами
- •1.3 Процессы управления проектами
- •Контрольные вопросы
- •Литература
- •2. Управление содержанием проекта
- •Контрольные вопросы
- •Литература
- •3. Управление проектом по временным параметрам
- •Контрольные вопросы
- •Литература
- •4. Управление стоимостью и финансированием проекта
- •Контрольные вопросы
- •Литература
- •5. Управление рисками в проекте
- •Контрольные вопросы
- •Литература
- •Дисциплина управления рисками msf. Белая книга, 2003, перевод eLine Software [Электронный ресурс] – http://www.Pmpractice.Ru
- •Сайт управления рисками в России http://www.Risk-manage.Ru
- •Официальный сайт Русского общества управления рисками - http://www.Rrms.Ru/
Контрольные вопросы
Охарактеризуйте основное отличие проектной деятельности от операционной
Докажите, что проведение Олимпийских игр в Сочи 2014 является проектом
Опишите основные группы стейкхолдеров проекта Олимпийских игр в Сочи 2014.
Что такое «золотой треугольник управления проектами»? Для чего он используется?
Приведите пример программы и портфеля проектов. Сформулируйте критерии их эффективности.
Сформулируйте цель деятельности менеджера проекта. Чем деятельность менеджера проекта отличается от деятельности линейного менеджера?
В каких проектах необходимо выделение роли куратора проекта
Литература
Руководство к своду знаний по управлению проектами (Руководство PMBOK). Пятое издание// Project Management Institute, 2013. – 614 с.
Управление проектами. Основы профессиональных знаний. Национальные требования к компетентности специалистов (NCB – SOVNET National Competence Baseline Version 3.0) //Сертификационная комиссия СОВНЕТ. М,: ЗАО «Проектная ПРАКТИКА», 2010 – 256 c.
P2M. A Guidebook of Project and Program Management for Enterprise Innovation, Revision 3. – Project Management Association of Japan, 2005
Готин С.В. Логико-структурный подход и его применение для анализа и планирования деятельности / С.В. Готин, В.П. Калоша. – М.: ООО «Вариант», 2007.-118 с.
Демарко Т., Листер Т. Человеческий фактор: успешные проекты и команды, 2-е издание. – Спб.: Символ-Плюс, 2005. -256 с.
Ильина, О.Н. Системный подход к управлению проектами в организации : Монография / О. Н. Ильина. – М.: Креативная экономика, 2012. -208 с.
Козлов, А. С. Методология управления Портфелем Программ и Проектов : монография / А. С. Козлов. - 2-е изд., стер. – М. : ФЛИНТА, 2011. - 194 с.
Математические основы управления проектами: Учебное пособие/ С.А.Баркалов, В.И.Воропаев, Г.И. Секлетова и др. Под ред. В.Н. Бурков а – М.: Высшая школа, 2005. – 423 с.
Фунтов В. Н.Управление проектами развития фирмы: теория и практика. – СПб.: Питер, 2009. - 496 с.
Сайт ГК «Проектная ПРАКТИКА» [Электронный ресурс] – http://www.pmpractice.ru
Портал государственных программ 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), уникальных, впервые выполняемых работ и т.п.
Иногда вместе с СДР разрабатывается сопроводительный документ – словарь СДР, который может включать:
- идентификатор работы;
- описание работы;
- описание основных контрольных событий (вех проекта);
- фамилию ответственного за выполнение работы.
