ПРОЦЕССЫ УПРАВЛЕНИЯ ПРЕКТАМИ.

ОСНОВНЫЕ ПОНЯТИЯ И ПРОЦЕССЫ УПРАВЛЕНИЯ ПРОЕКТАМИ.

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

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

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

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

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

Модели жизненного цикла.

Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО (под моделью ЖЦ понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении ЖЦ. Модель ЖЦ зависит от специфики ИС и специфики условий, в которых последняя создается и функционирует). Его регламенты являются общими для любых моделей ЖЦ, методологий и технологий разработки. Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы.

К настоящему времени наибольшее распространение получили следующие две основные модели ЖЦ:

каскадная модель (70-85 г.г.);
спиральная модель (86-90 г.г.).

В изначально существовавших однородных ИС каждое приложение представляло собой единое целое. Для разработки такого типа приложений применялся каскадный способ. Его основной характеристикой является разбиение всей разработки на этапы, причем переход с одного этапа на следующий происходит только после того, как будет полностью завершена работа на текущем (рис. 1.1). Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.

Положительные стороны применения каскадного подхода заключаются в следующем [2]:

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

Рис. 1.1. Каскадная схема разработки ПО

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

Рис. 1.2. Реальный процесс разработки ПО по каскадной схеме

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

Для преодоления перечисленных проблем была предложена спиральная модель ЖЦ [10] (рис. 1.3), делающая упор на начальные этапы ЖЦ: анализ и проектирование. На этих этапах реализуемость технических решений проверяется путем создания прототипов. Каждый виток спирали соответствует созданию фрагмента или версии ПО, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации.

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

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

Рис 1.3. Спиральная модель ЖЦ

Типы связей межу функциями.

Одним из важных моментов проектирования ИС с помощью методологии SADT является точная согласованность типов связей между функциями.Различают по крайней мере 7 типов связывания:

“0” – тип случайной связности- наименее желательный. Случайная связь возникает когда конкретня связь между функциями мала или полностью отсутствует. Это относится к ситуации, когда имена данных на SADT – дугах в одной диаграмме имеют малую связь друг с другом. В крайнем варианте связь вообще отсутствует.

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

“2” – тип временной связности. Связанные во времени элементы возникают вследствии того, что они представляют функции, связанные во времени, когда данные используются одновременно или функции включаются параллельно, а не последовательно.

“3” – тип процедурной связнности. Процедурно связанные элементы появляются сгруппированными вместе вследствии того, что они выполняются втечение одной и той же части цикла и процесса.

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

выходные данные.

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

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

В математических терминах необходимые условия для простейшего типа функциональной свяхности имеет следующий вид: C=g(B) = g(f(A))

Значимость	Тип связности	Для функции	Для данных
0	Случайная	Случайная	Случайная
1	Логическая	Функция одного и того же множества или типа	Данные одного и того же множества или типа
2	Временная	Функции одного и того же периода времени(операции инициализации)	Данные используются в каком-либо временном интервале
3	Процедурная	Функции, работающие в одной и той же фазе или итерации	Данные, используемые во время одной и той же фазе или итерации
4	Коммуникационная	Функция, использующая одни и те же данные	Данные, на которые воздействует однеа и та же деятельность
5	Последовтельная	Функции, выполняющие последовательное преобразование одних и тех же данных	Данные, преобразуемые последователдьными функциями
6	Функциональная	Функции, объединяемые для выполнения одной функции	Данные, связанные с одной функцией

Уровни 4-6 устанавливают типы связногстей, которые разработчики считают важнейшими для получения диаграмм хорошего качества.

Основные понятия электронного документооборота

Документ – это совокупность трех составляющих:

1)Физическая регистрация информации

2) Форма представоения информации

3) Активизация определенной деятельности

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

Документ – это слабоструктурированная совокупность блоков или объектов информации, понятная человеку.

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

Собственно документооборот может быть двух типов:

1)Универсальный, т. е. Автоматизирующий существующие информационные потоки слабоструктурированной нформации.

2) Операционный, т. е. Ориентированный на работу с документами, содержащими операционную атрибутику, вместе с которой ведется слабоструктурированная информация.

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

К основным преимуществам электронного документооборота можно отнести следующие:

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

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

3) Быстрое сохранение новых документов из уже существующих.

4) Поддержка одновременной работы многих пользователей с одним и тем же документом, предотвращение его потери или порчи.

5) Сокращение времени поиска нужных документов.

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

Комплексная автоматизация этих функций требует создания единого информационного пространства предприяти, в котором сотрудники и руководство могут осуществлять свою деятельность руководствуясь едиными правилами представления и обработки информации в документном и бездокументном виде. Для этого в рамках предприятия требуется создать единую ИС по управлению информацией или единую систему управления документами, включающую следующие возможности: 1)возможность удаленной работы, когда члены одного коллектива могут работать в разных местах; 2)возможность доступа к информации, когда разхные пользователи должны иметь доступ к одним и тем же данным без потерь в производительности и независимо от своего местоположения в сети; 3)возможности средств коммуникации; 4)возможность сохранения целостности данных в общей БД; 5)возможность полного текстового и реквизитного поиска информации; 6)открытость системы, когда пользовтели должны иметь доступ к привычным средствам создания документов и уже существующим документам, созданным в других системах; 7)защищенность информации; 8)удобство настройки на конкретные задачи пользователей; 9)возможность ????????????????? системы для поддержки роста организации и защиты вложенных инвестиций.

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

Ось “F” характеризует уровень организации хранения фактографической информации, которая привязана к специфике конкретного рода деятельности кампании или организации.

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

Ось “D” отражает необходимость организации взаимодействия, т. е. Формирования и передачи товаров, услуг или инормации как внутри организации, так и вне ее.

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

Ось “R” вносит в пространство документооборота реглемент процессов прохождения документов, а именно – описание того, какие процедуры, когда и как должны выполняться.

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

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

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

Эволюция модели.

Модель документооборота имеет три основных фазы своей эволюции.

1)Фактографическая. Начало любой деятельности характеризуется обычным периодом накопления первичной информации, имеющую жесткую структуру и атрибутику. Точка оси “F” – это текущее состояние системы документооборота организации. Движение по этой оси вверх характеризует накопление фактографической информации и начиная с определенного момента можно отметить возникновение понятия операция. На этом этапе начинается процесс возникновения неравенства между ранее равноправными документами. После возникновения привязки к конкретным бизнесс-процессам ????????????????? Дальнейшая эволюция документооборота в одномерном пространстве уже невозможна. Необходим переход к новой фазе.

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

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

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

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

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

В процессе описания организации и ее деятельности формируются три основных системы моделей организации: 1)Стратегическая; 2)Укрупненная; 3)Детальная. Все эти системы моделей, описывая основные аспекты организации и ее детальности, базируются на бизнесс-процессах. В систему моделей описания организации добавлена также дополнительная система моделей для того, чтобы можно было учесть аспекты, не связанные с бизнес-процессами, но необходимые при создании ИС.

Построение ролевой модели

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

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

ОСНОВНЫЕ ПОНЯТИЯ И ПРОЦЕССЫ УПРАВЛЕНИЯ ПРОЕКТАМИ.

ПРОЦЕССЫ УПРАВЛЕНИЯ ПРЕКТАМИ.

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

Процессы управления проектами могут быть разбиты на 6 основных групп.

1)Процессы инициации – это принятие решения о начале выполнения проекта.

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

3) Процессы исполнения – это координация людей и других ресурсов для выполнения плана.

4) Процессы анализа – это определение соответствия плана и исполнение проекта по поставленным целям и критериям успеха, и принятие решений о необходимости применения корректирующих воздействий.

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

6) Процессы завершения – это формализация выполнения проекта и подведение его к упорядоченному финалу.

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

Процессы управления проектами связаны своими результатами. Результат выполнения одного становится исходной информацией для другого. В реальном проекте фазы могут не только предшествовать друг другу, но и накладываться. Повторение инициации на разных фазах проекта помогает контролировать актуальность выполнения проекта.

I) Процессы инициации.

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

II) Процессы планирования.

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

1)Планирование качества, т. е. Определение того, какие стандарты качества использовать в проекте и как этих стандартов достичь.

2)Планирование организации, т. е. Определение, документирование и назначение ролей, ответственности и взаимоотношений отчетности в организации.

3) Назначение персонала.

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

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

6) Оценка риска, т. е. Оценка вероятностей наступления событий риска и их характеристик и влияние на проект.

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

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

9) Подготовка условий – выработка требований к поставкам и определение потенциальных поставщиков.

III) Процессы исполнения и контроля.

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

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

1)Учет исполнения – это подготовка и распределение необходимый для участников проектов информации с требуемой периодичностью.

2) Подтверждение качества – регулярная оценка исполнения проекта с целью подтверждения соответствия принятым стандартам качества.

3) Подготовка предложений – сбор рекомендаций, отзывов, заявок и т. д.

4) Выбор поставщиков – это оценка предложений, выбор поставщиков и подрядчиков, и заключение контрактов.

5) Контроль контрактов.

6) Развитие команды проекта – это повышение квалификации участников проекта.

IV) Процессы анализа.

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

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

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

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

1)Анализ сроков – это определение соответствия фактических и прогнозных сроков исполнения операций проектом, директивным или запланированным.

2) Анализ стоимости.

3) Анализ качества – это мониторинг результатов с целью их проверки на соответствие принятым стандартам качества и определение путей устранения причин нежелательных результатов исполнения качества проектов.

4) Подтверждение целей – это процесс формальной приемки результатов проекта его участниками.

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

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

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

V) Процессы управления.

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

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

К основным процессам управления, встречающихся практически в каждом проекте относятся:

1)Общее управление изменениями, т. е. определение, согласование, утверждение и принятие к исполнению корректирующих воздействий и координация изменений по всему проекту.

2) Управление ресурсами, т. е. внесение изменений в состав и назначение ресурсов на работы проекта.

3) Управление целями – это корректировка целей проекта по результатам процессов анализа.

4) Управление качеством, т. е. разработка мероприятий по устранению причин неудовлетворительного исполнения.

Среди вспомогательных процессов можно выделить два:

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

б) управление контрактами – это координация работы подрядчиков, корректировка контрактов и разрешение конфликтов.

VI) Процессы завершения.

Завершение проекта сопровождается следующими процессами:

а) закрытие контрактов, включая разрешение всех возникших споров.

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

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

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