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

Управление сроками:

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

Управление сроками включает в себя:

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

• минимизацию (оптимизацию) временных характеристик;

• разработку расписания;

• разумное использование резервов времени;

• контроль развития проекта по временным характеристикам;

• прогнозирование сроков завершения работ, этапов и проекта в целом;

• принятие решений по ликвидации нежелательных временных отклонений;

• оценку продолжительностей;

• календарное планирование.

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

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

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

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

---

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

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

---

4.УПРАВЛЕНИЕ СОДЕРЖАНИЕМ ПРОЕКТА.
 Управление содержанием проекта включает в себя процессы, обеспечивающие планирование, выполнение и контроль работ, которые требуются для успешного завершения проекта.

Управление содержанием проекта включает в себя шесть процессов:

• 
  Планирование управления содержанием;
  
• 
  Сбор требований;
  
• 
  Определение содержания;
  
• 
  Создание иерархической структуры работ (ИСР);
  
• 
  Подтверждение содержания - процесс формализованной приемки полученных поставляемых результатов проекта;
  
• 
  Контроль содержания.
  

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

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

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

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

Таблица№2 Инструменты и методы, входы и выходы процесса сбора требований
Входы процесса	Инструменты и методы	Выходы процесса
Устав проекта	Экспертная оценка	Документация по требованиям
План управления проектом	Сбор данных (Мозговой штурм, Интервью, Фокус-группы, Анкеты и опросы, Бенчмаркинг)	Матрица отслеживания Требований (рис. 3.1)
Документы проекта	Анализ данных
Бизнес-документы	Принятие решений
Соглашения	Отображение данных
Факторы среды предприятия	Навыки межличностных отношений и работы с командой
Активы процессов организации	Контекстная диаграмма
	Прототипы

---

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

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

Обычно в плане управления указывают:

1. 
   методы и инструменты управления;
   
2. 
   роли участников при возникновении рисковых ситуация;
   
3. 
   допустимые значения и диапазоны угроз;
   
4. 
   принципы и правила внесения изменений в работу;
   
5. 
   форматы отчетности и документации по проектным угрозам ;
   
6. 
   способы мониторинга и ответственные;
   

Рисунок №2



4.1ИНДЕТИФИКАЦИЯ.

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

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

Рисунок №3



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

---

, поэтому есть смысл использовать и другие способы классификации.

Рисунок №4



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

4.2АНАЛИЗ И ОЦЕНКА РИСКОВ.

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

Он позволяет получит на выходе:

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

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

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

Количественная оценка помогает проанализировать:

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

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

---

Смотрите также файлы

• Император ГоЁзэй, настоящее имя которого было Масахито, родился 31 июля 1571 года в Японии. Он стал 107ым императором Японии в 1586 году после смерти своего отца императора Огасавары.docx

• Анализ воздействия жизненного цикла продукта на выбор.docx

• Конспект открытого урока по математике Буквенные выражения умк Школа России.docx

• Дисциплина Методика обучения продуктивным видам деятельности с практикумом Практическое занятие 5.doc

• 1. Основные положения современной клеточной теории. Типы клеточной организации. Отличия между прокариотическими и эукариотическими клетками.doc