Вам бонус- начислено 1 монета за дневную активность. Сейчас у вас 1 монета

17. Контроль выполненеия проекта

Лекция



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


 

17.1.         Управление стоимостью проекта

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

Одним из ключевых и наиболее известных методов (тем не менее, с невысокой степенью распространения в проектах) являетсяметод освоенного объема EVA (Earned Value Analysis), который предусматривает периодическую регистрацию прошлых состояний проекта для прогнозирования будущего. Во время оценивания состояния проекта производится измерение хода исполнения расписания и стоимости проекта с целью выяснить, отстает проект от расписания или опережает его ( отклонения по срокам ипо стоимости), и почему это происходит. Затем производится прогнозирование окончательной стоимости проекта и даты завершения. Элегантность данного метода состоит в возможностях EVA объединять содержание, стоимость и расписание проектаи проактивно прогнозировать итоговую стоимость завершения проекта. Такие предсказания создают возможности для своевременного решения и удержания проекта в рамках установленных сроков и стоимости [18].

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

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

Применение метода освоенного объема

Для того чтобы EVA был эффективным, он должен опираться на следующую достоверную и корректно подготовленную информацию:

  • детально определенное содержание проекта;
  • базовое расписание проекта;
  • базовый план по стоимости проекта.

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

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

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

Ключевые величины, которыми оперируют в рамках данного метода:

  • плановая стоимость запланированных работ (PV - Planned value);
  • плановая стоимость выполненных работ (EV - Earned Value);
  • фактическая стоимость выполненных работ (AC - Actual Cost);
  • плановая стоимость всего проекта (BAC - Budget at Completion). При правильном сборе информации о проекте и наличии ключевых

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

  17. Контроль выполненеия проекта


Рис. 17.1. Ключевые величины метода освоенного объема (EVA)

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

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

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

  • Метод процента выполненной работы использует периодическую - например, выполняемую раз в неделю или раз в месяц, - оценку доли выполненных работ пакета, выражаемую в виде кумулятивной величины (например, 65%) по отношению к 100% - полному объему работ пакета. Этот метод считается простым и быстрым методом, что, возможно, объясняет его широкую популярность, но также и чрезмерно субъективным. Качественно определение содержания пакетов работ и проверка точности оценок помогает снизить степень субъективизма до приемлемого уровня.
  • Фиксированная формула для пакета работ предполагает различные варианты выбора: 25/75, 50/50, 75/25 и т.д. Например, формула 25/75 означает, что когда исполнение пакета работ начинается, выполненным считается 25% бюджета пакета, а когда заканчивается - добавляются остальные 75%. Естественно, что любое сочетание чисел, равных в сумме 100%, может быть использовано. Это достаточно быстрый способ оценивания, применимый в ситуациях, когда пакеты работ имеют малую длительность и выполняются каскадно в определенных временных рамках.
  • Третьим шагом при использовании метода освоенного объема является оценивание результатов и прогнозирование завершения проекта, использующее ключевые показатели метода EVA (см. Формула 5) в любой из установленных точек управленческого контроля.

Формула 5. Расчет ключевых показателей метода EVA

CV (cost variance) - отклонение по стоимости

CV = EV - AC

SV (schedule variance) - отклонение по срокам

SV = EV - PV

CPI (cost performance index) - индекс выполнения бюджета

CPI = EV / AC

SPI (schedule performance index) - индекс выполнения расписания

SPI = EV / PV

EAC (estimated at completion) - прогноз стоимости при завершении проекта

EAC = BAC / CPI

1.            Отклонение по стоимости ( CV - cost variance). Абсолютный показатель, характеризующий, насколько мы больше/меньше потратили по сравнению с тем, сколько должны были потратить на выполнение уже завершенных задач

2.            Отклонение по срокам ( SV - schedule variance). Об этом говорит сайт https://intellect.icu . Абсолютный показатель, характеризующий, насколько мы больше/меньше сделали по сравнению с объемом задач, запланированным на текущую дату в базовом расписании проекта.

3.            Индекс выполнения бюджета ( CPI - cost performance index). Относительный показатель, характеризующий, насколько мы больше/меньше потратили по сравнению с тем, сколько должны были потратить на выполнение уже завершенных задач. Применяется для сравнения различных проектов между собой.

4.            Индекс выполнения расписания ( SPI - schedule performance index). Относительный показатель, характеризующий, насколько мы больше/меньше сделали по сравнению объемом задач, запланированным на текущую дату в базовом расписании проекта. Применяется для сравнения различных проектов между собой.

5.            Прогноз стоимости при завершении проекта ( EAC - estimate at completion). Оценочная величина совокупных затрат на проект при условии текущего отклонения по стоимости, характеризующего CPI. После расчета ключевых показателей производятся интерпретация результатов (см. рис. 17.2) и, в зависимости от принятых процедур, реализация корректирующих мер (перерасход и/или отставание) или закрепление результата (экономия и/или опережение).

  17. Контроль выполненеия проекта


Рис. 17.2. Интерпретация показателей EVA

Пример процедуры управления стоимостью проекта на основе EVA

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

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

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

4.            Базовый план по стоимости разрабатывается руководителями проекта на очередную фазу, с учетом данных по завершенным и текущей фазам.

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

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

7.            Руководители проекта получают данные о фактической стоимости проекта и обновленную диаграмму календарно-стоимостного планирования. В течение 0,5 дня руководитель проекта со стороны заказчика производит сравнение значения диаграммы календарно-стоимостного планирования с базовым планом по стоимости и с базовым планом управлениярасписанием проекта. Руководитель проекта со стороны заказчика производит расчет ключевых величин освоенного объема (EV, PV, AC ) и коэффициентов ( CV, SV, EAC ), заносит значения в реестр освоенного объема и информирует руководителя проекта со стороны исполнителя;

8.            В случае если значение CV или SV демонстрирует отклонение в одном и том же направлении свыше 10% в течение 3 отчетных периодов, руководители проекта на отчетном совещании информируют об этом спонсора проекта и управляющий орган проекта.

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

10.       Решение об использовании резерва на непредвиденные обстоятельства принимается спонсором проекта.

11.       Решение об использовании управленческого резерва принимается управляющим органом проекта.

12.       Диаграмма календарно-стоимостного отслеживания проекта отражается в информационной системе управления проектами. Реестр освоенного объема ведется в электронных таблицах MS Excel.

 

 

17.2.        Контроль качества проекта

На стадии контроля каждой стадии ЖЦ ИТ выполняются мониторингконтроль и формирование отчетности о соответствующем этапе проекта.

Целями этапа являются [22]:

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

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

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

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

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

Таблица 17.1. Пример формы сводной таблицы сценариев тестирования

Наименование сценария

Описание сценария

Дата, время

Тестировщик

Приемщик

Успешно (да/нет)

Примечания

.

             

Комментарий к форме

1.      : Номер сценария тестирования бизнес-процесса.

2.      Наименование сценария:Короткое наименование сценария тестирования бизнес-процесса.

3.      Описание сценария:Описание сценария тестирования бизнес-процесса.

4.      Дата, время:Дата и время проведения тестирования.

5.      Тестировщик:Консультант от исполнителя, участвующий в тестировании.

6.      Приемщик:Сотрудник функциональной группы от заказчика, участвующий в тестировании.

7.      Успешно? (да/нет):Отметка об успешности прохождения сценария тестирования.

8.      Примечания:Дополнительные пояснения к результатам сценария

Инспекция включает в себя такие процессы, как тестирование, предпринятое с целью определения соответствия результатов проекта принятым требованиям и стандартам. Различают тестирование отдельных бизнес-процессов и их совокупности (интеграционное тестирование). Для проведения тестирования разрабатывают сценарии. Для осуществления контроля качества разработанной ИС составляют сводную таблицу сценариев. Пример формы такой таблицы приведен в табл. 17.1.

Ошибки, выявленные при тестировании, фиксируют в специальном журнале. Пример формы журнала ошибок представлен в табл. 17.2.

Контроль качества обеспечивается руководителем проекта, менеджером по качеству, командой проекта. В табл. 17.3 собраны функции участников процесса контроля [22].

17.3.        Контроль рисков проекта

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

Мониторинг рисков выполняется с помощью следующих методов.

1. Пересмотр рисков

Таблица 17.2. Пример формы журнала ошибок

Наиме-нование сценария

№ шага тестирования

Шаг процесса

Модуль

Описа- ние ошибки

Решение

Ответственный

Наме-ченнаядата

.

             

.

             

.

             

Комментарий к форме "Журнал ошибок"

1.      Наименование сценария:Короткое наименование сценария тестирования бизнес-процесса.

2.      № шага тестирования:Уникальный идентификатор шага тестирования в формате Z.P#.NN, где Z - номер сценария тестирования, Р# - 5-значный номер процесса и NN - уникальный 2-циферный код в рамках сценария.

3.      Шаг процесса:Номер и наименование тестируемого шага бизнес-процесса. Номер шага бизнес процесса в формате P#.NN, где Р# - 5-значный номер процесса, и NN - уникальный 2-циферный код в рамках процесса.

4.      Модуль: Модуль ИС, с использованием которого реализуется шаг бизнес-процесса.

5.      Описание ошибки:подробное описание ошибки, выявленной в ходе тестирования, со ссылкой на файл, в котором находятся полные сведения об ошибке.

6.      Решение:Планируемые мероприятия по устранению ошибки.

7.      Ответственный:Сотрудник, назначенный ответственным за устранение ошибки в намеченный срок.

8.      Намеченная дата:Планируемый срок устранения ошибки

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

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

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

Функция Результат выполнения функции

Руководитель проекта

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

Обзор качества (результаты процесса обзора)

Организация аудита качества работ и согласование выявленных замечаний

Аудит качества (результаты процесса аудита)

Организация работы по сбору информации по показателям качества работ

Показатели качества (результаты процесса контроля показателей качества)

Менеджер по качеству

Анализ и согласование выявленных результатов

Обзор качества (результаты процесса обзора)

Анализ и утверждение результатов аудита

Аудит качества (результаты процесса аудита)

Анализ показателей качества

Показатели качества (результаты процесса контроля показателей качества)

Команда проекта

Участие в обзорах результатов проекта

Обзор качества (результаты процесса обзора)

Участие в проведении аудита качества работ, выполнении согласованных мероприятий

Аудит качества (результаты процесса аудита)

Участие в сборе информации по показателям качества работ.

Показатели качества (результаты процесса контроля показателей качества)

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

2. Аудит рисков

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

Таблица 17.4. Пример формы (интенсивного) мониторинга сотрудника

 

Тип риска

Описание риска

Проактивные мероприятия

Реактивные мероприятия

Пороговые состояния

Вероятность

Влияние

Фактор риска

Политический

Заказчик решил не внедрять систему

Плана нивелирования риска не существует. Заказчик решает либо внедрять систему, либо не внедрять

Если заказчик не представляет стратегической ценности для компании-исполнителя - не начинать проект

 

6

9

54

Политический

Ввиду того, что выбор системы (и подрядчика) проводился холдинговым руководством заказчика, сам заказчик на текущий момент не заинтересован в проекте и внедрении системы

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

10.  Организация референс-визи-тов к успешным клиентам.

11.  Определение реальных лидеров в организации. Точечное повышение уровня их заинтересованности в успешном внедрении системы

12.  ...

п/а

 

8

4

32

.

           

0

3.Анализ отклонений и трендов

Тренды в процессе выполнения проекта подлежат проверке с использованием данных о выполнении. Для мониторинга выполнения всего проекта применяют методику освоенного объема. Отклонения от базового плана могут указывать на вызванные рисками последствия.

4.Анализ резервов

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

5.Совещания по текущему состоянию

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

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

Управление рисками на фазе проектирования производится аналогично управлению на предыдущей стадии.

Во время мониторинга команда проекта выполняет планы по предотвращению рисков. За прогрессом этой деятельности ведется наблюдение. Отслеживаются изменения значений триггеров рисков. Для удобства выполнения мониторинга применяют специальную форму [11], пример которой приведен в таблице 65.

 

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

создано: 2015-12-27
обновлено: 2021-03-13
132568



Рейтиг 9 of 10. count vote: 2
Вы довольны ?:


Поделиться:

Найди готовое или заработай

С нашими удобными сервисами без комиссии*

Как это работает? | Узнать цену?

Найти исполнителя
$0 / весь год.
  • У вас есть задание, но нет времени его делать
  • Вы хотите найти профессионала для выплнения задания
  • Возможно примерение функции гаранта на сделку
  • Приорететная поддержка
  • идеально подходит для студентов, у которых нет времени для решения заданий
Готовое решение
$0 / весь год.
  • Вы можите продать(исполнителем) или купить(заказчиком) готовое решение
  • Вам предоставят готовое решение
  • Будет предоставлено в минимальные сроки т.к. задание уже готовое
  • Вы получите базовую гарантию 8 дней
  • Вы можете заработать на материалах
  • подходит как для студентов так и для преподавателей
Я исполнитель
$0 / весь год.
  • Вы профессионал своего дела
  • У вас есть опыт и желание зарабатывать
  • Вы хотите помочь в решении задач или написании работ
  • Возможно примерение функции гаранта на сделку
  • подходит для опытных студентов так и для преподавателей



Комментарии


Оставить комментарий
Если у вас есть какое-либо предложение, идея, благодарность или комментарий, не стесняйтесь писать. Мы очень ценим отзывы и рады услышать ваше мнение.
To reply

Управление разработкой программных IT проектов

Термины: Управление разработкой программных IT проектов