ИТ-архитектура от А до Я: Теоретические основы. Первое издание

Группа завершающих процессов

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

•официальное завершение работ по контрактам с поставщиками, производителями и заказчиками.

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

•приемка работы по проекту и конечных продуктов заказчиком;

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

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

•выпуск и визирование окончательного отчета или отчета о состоянии проекта, которое показывает, что ожидаемые конечные результаты получены;

•прекращение всех работ по проекту как внутри организации, так и за ее пределами.

Существуют следующие три типа окончания проекта:

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

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

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

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

•приемка конечного продукта заказчиком,

•документирование проекта,

•проведение проверки после реализации проекта

•выпуск окончательного отчета

Следующий список может оказать помощь при определении готовности проекта к окончанию без учета опубликованных или запланированных дат и крайних сроков:

•Согласуется ли все еще проект с поставленными целями?

•Является ли он практичным? Полезным?

•Достаточно ли руководство заинтересованно в проекте, чтобы поддержать его реализацию?

•Имеет ли организация достаточно финансовых средств для реализации проекта?

•Является ли поддержка данного проекта достаточной для его успешной реализации?

•Имеет ли организация требуемую квалификацию для реализации проекта?

•Лишился ли проект ключевой фигуры или поддержки?

•Заинтересована ли рабочая группа в успехе проекта?

•Какова вероятность достижения минимума поставленных целей проекта?

•Является ли он все еще прибыльным и своевременным?

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

Группа завершающих процессов содержит следующие процессы:

•Закрытие проекта или фазы (Close Project or Phase)

•Закрытие контрактов (Close Procurement)

Завершение может состоять из:

•Тестов разработанной системы (протокол тестирования)

•Процедура сдачи-приемки, передача рабочей документации

•Аттестация персонала, извлечение уроков (Lesson Learning), обмен опытом

•Финансовый расчет и анализ фактических расходов

•Ликвидация рабочих мест и ре-интеграция персонала

Область знаний по управлению проектами

Руководство PMBooK (Project Management Body of Knowledge) описывает десять областей знаний, которыми должен обладать руководитель проекта. В стандарте рассматривается каждая область знаний в отдельности, описываются её процессы входов и выходов. Процессы областей знаний представлены в PMBooK в виде дискретных элементов, которые имеют четко определенные границы. Правда на практике эти процессы являются итеративными – могут взаимодействовать между собой и накладываться друг на друга. Стандарт рассматривает следующие области знаний по управлению проектами:

Управление интеграцией проекта (Project Integration Management)

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

Управление содержанием проекта (Project Scope Management)

Под управлением содержанием понимаются процессы, позволяющие производить выборку, фильтрацию и группировку по проекту тех и только тех работ, которые понадобятся руководителю проекта для успешного завершения проекта. Управление содержанием проекта напрямую связано с определением и контролем того (содержания), что будет включено и что не будет включено в проект. Описываются схемы процессов Сбора требований, Определения содержания проекта, создания Иерархической структуры работ – ИСР (Work Breakdown Structure, WBS), Подтверждения содержания и Управления содержанием. При разработках WBS используется правило «8/80» (1 день – 2 рабочие недели). Пакет Работ (Work Breakdown Package WB) должен быть разработан за период от 8 до 80 часов. Каждый Пакет Работ должен быть назначен на конкретное подразделение или сотрудника.

Управление сроками проекта (Project Time Management)

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

Управление стоимостью проекта (Project Cost Management)

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

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

В качестве механизмов и техник оценки расчета стоимости проекта можно использовать: Экспертное мнение, Аналогичный проект, Параметрический, Ballpark Estimate (Rough Order of Magnitude ROM), Top-down, Three-point Estimate или Button-up метод.

Наиболее точный метод (Button-up), но при этом он требует наличие Структуру Рабочих Пакетов (Work Breakdown Structure WBS).

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

Управление качеством проекта (Project Quality Management)

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

Управление человеческими ресурсами проекта (Project Human Resource Management)

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

Управление коммуникациями проекта (Project Communications Management)

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

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

•Планирование коммуникаций,

•Распространение информации,

•Управление ожиданиями заинтересованных сторон

•Отчеты об исполнении.

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

•Руководитель проекта – проектная комиссия, руководитель предприятия. Отчеты по проекту, расходы, анализ тренда вех и расходов, причины отклонений.

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

•Пользователи, потребители продукта – руководитель проекта. Информация о развитии проекта.

•Руководитель проекта – план проекта. Планы постоянно отслеживаются, т. к. это основа проектного контроллинга.

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

Управление рисками проекта (Project Risk Management)

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

•Планирование управления рисками,

•Идентификация рисков,

•Качественный анализ рисков,

•Количественный анализ рисков,

•Планирование реагирования на известные риски,

•Мониторинг и управление рисками.

Управление поставками проекта (Project Procurement Management)

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

•Планирование закупок,

•Осуществление закупок,

•Управление закупочной деятельностью,

•Закрытие закупок.

Управление заинтересованными сторонами проекта (Project Stakeholder Management)

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

Методы и техники Управления Проектами

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

Анализ дерева решений (Decision Tree Analysis)

Анализ дерева решений (Decision Tree Analysis).

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

•Квадраты – места принятия решений.

•Круги – места появления исходов.

•Пунктирные линии – возможные решения.

•Треугольники или прямые линии – возможные исходы.

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

Анализ сильных и слабых сторон, возможностей и угроз (SWOT Analysis)

SWOT-анализ (Strengths Weakness Opportunities Threats Analysis) – это метод оценки внутренних и внешних факторов, которые влияют на развитие компании. Он поможет вам оценить сильные и слабые стороны вашего дела, найти новые возможности и определить возможные угрозы. SWOT-анализ разделяет факторы влияния на компанию на четыре категории, что помогает оценить её со всех сторон, это:

S-strengths (сильные стороны). Например, продажа товаров непосредственно покупателю, прибыль больше, чем у конкурентов, клиент-сервис – лучший на рынке и т. д.;

W-weaknesses (слабые стороны). Например, недостаточно партнёров, неэффективная реклама, маленькая целевая аудитория;

O-opportunities (возможности). Например, потенциальные клиенты узнают всё, что им нужно о вашем товаре из Интернета, покупки совершаются круглосуточно, не зависимо от того, работаете вы или нет;

T-threats (угрозы). Например, бренд ваших конкурентов более известный на рынке, качество товаров, которые предлагают конкуренты выше.

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

Внутренние факторы – сильные и слабые стороны относятся к внутренним факторам, а значит, вы их легко можете оценить:

•Финансовые ресурсы. Это финансирование, возможности получения дохода;

•Физические ресурсы. Это ваше оборудование, здания, местоположение;

•Человеческие ресурсы. Сотрудники, иногда волонтёры, целевая аудитория;

•Доступ к природным ресурсам, авторские права, патенты;

•Текущие процессы. Сюда относится всё, что происходит в компании, мотивационные программы, программы обучения, система иерархии отделов и т. д.

Чтобы найти сильные стороны своего бизнеса ответьте на такие вопросы:

•Какие преимущества у вашего бизнеса?

•Что вы делаете лучше, чем все остальные?

•Какие ваши сильные стороны видят ваши клиенты?

•Какое у вас уникальное торговое предложение (УТП)?

•Как вы можете увеличить свою прибыль?

Рассмотрите свои сильные стороны, как с внутренней точки зрения, так и с точки зрения ваших клиентов. Оценивайте свои сильные стороны относительно к конкурентам.

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

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

•Экономические тенденции. Это местные, национальные, международные финансовые направления;

•Финансирование. Такие, как пожертвования, государственные влияния, налоги и т. д.;

•Демографические данные. Это возраст, пол, раса, национальность, культурные ценности целевой аудитории;

•Отношения с поставщиками и партнёрами;

•Политическая, экологическая, экономическая ситуация в стране.

Метод оценки и анализа программ (Program Evaluation and Review Technique, PERT)

Метод PERT (Program Evaluation Review Technique PERT), Техника Оценки и Анализа Программ и проектов часто используется при управлении проектами и проведении анализа производственных процессов. Метод PERT является инструментом, который вычисляет ожидаемое значение продолжительности проекта или отдельного процесса. При управлении проектами метод PERT практически всегда используется в сочетании с методом критического пути (англ. CPM, Critical Path Method).

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

E = (O+4M+P) /6

O – оптимистичная оценка длительности задачи,

M – наиболее вероятная оценка длительности задачи,

P – пессимистичная оценка длительности задачи.

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

Диаграмма «PERT Chart»

Диаграмма Гантта (Gantt Chart)

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

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

Начало, конец и длина отрезка на шкале времени соответствуют началу, концу и длительности задачи.

Управление освоенным объемом (Earned Value Management, EVM)

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

Условия: Задачу (ЗП1) должен выполнить один исполнитель (ИС1). Выделено по плану – два дня (2 х 8 часов = 16 часов) времени, стоимость работ исполнителя $ 10.00 в час (плановый расход = $ 10.00 х 16 часов = $ 160.00).

По факту: исполнитель закончил работу на третий день, дополнительно истратив два часа, сверх запланированных. Показатели: Факт по времени (2 х 8 часов +2 часа = 18 часов), и фактические расходы = $ 10.00 х 18 часов = $ 180.00.

Результат: На утро третьего дня результат выполнения задачи ЗП1 = 16/ (16+2) * 100% = 89% и стоимость выполнения ЗП1 = $ 180.00

Вывод: Здравый смысл говорит нам о том, что мы тратим деньги быстрее, чем получаем результат.

Основные показатели метода:

• Плановый объем (Planned Value PV) – объем запланированных работ в базовых ценах. Или другое название – БСЗР (базовая стоимость запланированных работ). В нашем примере PV равен 160$, т. к. базовый объем работ, который должен быть выполнен к среде, равен 16 чел-часам, а базовая цена равна 10$ за час работы.

• Освоенный Объем (Earned Value EV) – выполненная часть работ от запланированного объема. Измеряется как % завершения работы, умноженный на базовый бюджет задачи. Ранее этот показатель назывался БСВР (базовая стоимость выполненных работ). В нашем примере EV равен 142$, т. к. % выполнения по задаче равен 89%, а ее базовый бюджет составляет 160$.

• Фактическая стоимость (Actual Cost AC) – реальная стоимость выполненных работ. Измеряется количеством денег, которые мы по факту уже должны за выполненную работу. В нашем примере AC равен 160$, т. к. фактически исполнитель затратил 16 часов, а каждый час стоит 10$.

• Бюджет по завершению БПЗ (Budget At Completion BAC) фиксируется на старте проекта как сумма утвержденного бюджета на весь проект. В нашем кейсе он равен 160$.

• Отклонение по стоимости (Cost Variance CV) – отклонение по стоимости (формула: CV=EV-AC). $142.00 – $160.00 = – $18.00. Отрицательное значение – превысили бюджет, положительное – экономим бюджет. В нашем случае – Мы перерасходовали бюджет.

• Отклонение от календарного плана ОКП (Schedule Variance SV) – отклонение по срокам (формула: SV=EV-PV). $142.00 – $160.00 = – $18.00. Отрицательное значение – отстаем от плановых сроков, положительное – опережаем сроки. Мы отстаем от графика.

• Индекс отклонения по стоимости ИОС (Cost Performance Index CPI) – индекс выполнения стоимости (формула: CPI=EV/AC). Индекс больше 1 – идем с экономией бюджета, меньше 1 – превышаем бюджет. В нашем случае $142.00/$160.00 = 0,89. Перерасход бюджета по задаче на 11%

• Индекс отклонения от календарного плана ИОКП (Schedule Performance Index SPI) – индекс выполнения сроков

(формула: SPI=EV/PV). Индекс больше 1 – опережаем график работ, меньше 1 – отстаем от базового графика.

В нашем случае: SPI = $142.00/$160.00 = 0,89. Отстаем по срокам задачи на 11%

• Предварительная оценка по завершению ПОПЗ (Estimate At Completion EAC) – Представляет ожидаемую общую стоимость проекта после завершения оставшихся работ (Формула: EAC=BAC/CPI). В нашем случае: $160.00/0,89= $ 180.00. На сегодняшний день оценочная стоимость задачи проекта = $180.00.

• Оценка до завершения ОДЗ (Estimate To Complete ETC) – Сколько еще нужно денег, чтобы завершить проект (Формула: ETC=EAC-AC). В нашем случае: ETC=EAC-AC=$180.00 – $160.00= $20.00 – еще нужно на сегодняшний день, чтобы завершить задачу.

• Отклонение бюджета по завершению ОБЗ (Variance At Completion VAC) – Ожидания по перерасходу или экономии бюджета (формула: VAC = BAC-EAC). В нашем случае: VAC = BAC-EAC= $160.00 – $180.00 = – $20.00. На 20$ мы перерасходуем бюджет.

Формулы для расчета состояния проекта: EAC = AC + Button-up ETC, EAC = AC + BAC – EV, EAC = BAC/Cumulative CPI, EAC = AC + [(BAC – EV) / Cumulative CPI x Cumulative SPI], EMV = probability x impact, EV = BAC / % of completion, TCPI = (BAC – EV) / (BAC – AC),

Анализ тренда расходов

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

•Плановые расходы – то, что было запланировано изначально на реализацию.

•Фактические расходы – то, что было затрачено по факту на сделанную работу.

•Стоимость сделанных работ – то, что было запланировано и в действительности потрачено на сделанную работу. Сюда входит стоимость работ, материалов, внешних услуг.

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

•Дополнительные расходы – это разница между фактическими расходами и плановыми.

•Дополнительные расходы = фактические расходы – плановые расходы.

V-факт – предварительные фактические расходы. Выступает, как сигнал пере-расходования средств.

V-факт = бюджет + дополнительные расходы + остаток производства.

Анализ тренда этапов проекта (вех проекта)

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

•Что сделано?

•Что нужно еще сделать для завершения вехи?

•Успели ли в срок?

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

По горизонтали: периоды предоставления отчетности, например, каждую неделю. По вертикале: такая же шкала, с отметками вех. Отметка вех при X=0, соответствует запланированным показателям вех на этапе старта проекта.

Биссектриса – обозначает положение достигнутых вех.

В отчетный период диаграмма обновляется и анализируется. На диаграмму заносятся новые прогнозные сроки по завершению вех. Для каждой вехи получаем линию (кривую) тренда. Достигла биссектрисы, закончилась. Идеальное состояние, когда линия четко идет без изменений по оси Y. Отклонения по вертикале (отклонение прогнозируемого срока от первоначально запланированного):

• Вверх: отставание по срокам;

• Вниз: опережение графика;

Анализ с помощью Треугольника целей

Анализ с помощью Треугольника целей – Углы треугольника обозначаются, как:

•Сроки. Время на реализацию проекта.

•Расходы. Деньги, люди, бюджет.

•Объем работ. Цели, задачи, качество.

Пример хорошего развития проекта – Объем работ соблюден и даже превышен при меньших расходах и сроках.

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

Результаты проекта меряются с определенной периодичностью.

• Сроки – измеряется затраченным временем на проект.

• Расходы – измеряются фактическими затратами.

• Объем работ – измеряется в процентном соотношении запланированных и выполненных работ.

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