ISO/IEC/IEEE 15288 6.3.2 Процесс оценки и контроля проекта 6.3.2.1 Цель Цель процесса оценки и контроля проекта состоит в том, чтобы обеспечить сбалансированность и выполнимость планов, определить статус проекта, его технического выполнения и реализации процессов, направить выполнение согласно планам и графикам в пределах спроектированных бюджетов для технических задач. Этот процесс периодически и по главным событиям оценивает продвижение и достижения проекта согласно требованиям, планам и всевозможным бизнес-целям. Если обнаруживаются существенные различия, формируется необходимая информация для управления. Этот процесс также включает перенаправление проектных действий и задач, чтобы соответствующим образом исправить выявленные отклонения и изменения с помощью иного технического управления или других технических процессов. Перенаправление может предусматривать соответствующее перепланирование. 6.3.2.2 Выход (выходные результаты) В результате успешной реализации процесса оценки и контроля проекта: a) становятся доступными показатели качества функционирования или результаты оценки; b) оценивается адекватность ролей, ответственностей, подотчетности и полномочий; c) оценивается адекватность ресурсов; d) выполняются технические анализы продвижения проекта; e) исследуются и анализируются отклонения в проектной работе от планов; f) о проектном статусе сообщается задействованным заинтересованным сторонам; g) по мере необходимости определяются и направляются корректирующие действия или осуществляется перепланирование; h) согласовываются проектные действия, чтобы продвигаться (или не продвигаться) от одной запланированной контрольной точки или события к следующему; i) достигаются цели проекта. |
Руководящие указания:
a) Следует установить технические рабочие команды по оценке и реализации основных технических аспектов проекта и поддерживать их по мере необходимости. Например, рабочие команды по управлению взаимодействием часто формируются для оценки и успешной реализации ограничений взаимодействия. В рабочие команды по управлению взаимодействием следует включать представителей заинтересованных сторон от каждой организации, где затронуты взаимодействия. Рабочие команды по управлению взаимодействием обсуждают программные и системные взаимодействия, изучают варианты и договариваются о наилучшем подходе к реализации взаимодействий. Рекомендации рабочей команды, требующие внесения изменений в проект, следует представлять независимо от формального процесса управления конфигурацией, реализованного в проекте (например, на уровне совета по управлению конфигурацией) для их утверждения до реализации проекта. Взаимодействия следует определять в техническом задании и контролировать как неотъемлемую часть технической спецификации и документации по описанию взаимодействия.
b) В планах технической оценки и контроля проекта следует предусматривать достаточные действия при отклонениях от запланированных графиков, ресурсов или при нарушениях ограничений, чтобы это позволило обеспечить своевременное восстановление. Однако, важно понимать, что чрезмерный контроль может не только оказаться дорогостоящим, но и мешать предпринимаемым усилиям.
c) Оценка системной инженерии и задачи контроля должны включать в себя:
- оценку результатов анализа продукции, действий и задач;
- соответствие между проектом и техническими планами управления, философией, методологией и технологиями;
- документацию и сопровождение технических планов и обязательств;
- удовлетворение требованиям;
- оценку готовности к продвижению к следующему процессу, действию или задаче.
d) Заинтересованным в системной инженерии сторонам следует участвовать в критических анализах согласно ПУПРП и ПУПРСИ. В ПУПРСИ следует определить соответствующую серию технических анализов, планируя оценить уровень завершенности системы и степень продвижение к реализации целей проекта. ПУПРП и связанные с ним планы служат основанием для прослеживания процессов проекта и действий. Для выполнения действий по управлению анализами могут быть использованы комбинации критериев, ориентированных на события, риски и графики.
e) Поддерживающие действия процессов для проекта могут происходить на организационном уровне или непосредственно в рамках приспособленных процессов проектной команды. В любом случае, в управлении проектами и управлении системной инженерией следует осуществлять локальный контроль над действием поддерживающего процесса в пределах соответствующих компетенций. Отчеты о проблемах или об исключениях следует доводить до сведения руководителя проекта для анализа воздействия на стоимость, графики, область применения и качество проекта.
f) Оценку незавершенного производства следует проводить с помощью специалистов, знакомых с требованиями проекта, задействованных технологий, требованиями к продукции, используемыми процессами и инфраструктурой. Для сложных технических проектов в рамках валидации (аттестации) внутренних оценок проектов следует расследовать использование неквалифицированных экспертов и анализов, выполненных без рецензирования. Для поддержки жизненного цикла системы проектные действия следует охватывать соответствующими анализами управления. Анализы на высшем уровне следует в значительной степени основывать на функциональных/технических анализах более низких уровней и использоваться их для формирования общей оценки проекта. Специальные командные анализы независимых рецензентов часто учитываются для критических точек графика или в случаях недопустимого риска.
g) Там, где установленные контрольные точки зависят от достижения контрольных точек или от отчетов и/или результатов по любому поддерживающему процессу, руководителю системной инженерии следует отследить эти события приемлемым способом и в срок в соответствии с утвержденными планами. Поскольку это является общим для различных этапов проекта, связанных на договорном уровне с достижением контрольных точек или выполнением поддерживающих процессов (например, с соблюдением определенной базовой линии), важно, чтобы планы были синхронизированы и руководитель проекта был осведомлен (как можно скорее) о любых сложностях, возникающих для поддерживающих процессов при выполнении поставленных задач.
h) В рамках проектного и технического управления следует проводить структурированные анализы выполнения графика, основанные на приемлемых методах для обеспечения более точной оценки проекта.
i) Следует осуществлять документирование важных проблем и вопросов по действиям, включающим в себя назначения и принятие решений, вытекающих из анализов и оценок. Важные проблемы и вопросы следует периодически оценивать и отслеживать до их закрытия. Выявленные проблемы должны быть внесены в систему корректирующих действий.
j) В рамках проектного и технического управления следует осуществлять определение, документирование и управление взаимозависимостями между процессами проекта.
k) В рамках управленческого анализа выполнения технического графика следует уделять особое внимание продвижению проекта и показателям эффективности, установленным в ходе планирования проекта.
l) Следует тщательно оценить восстановление после отклонения от графика и оценить возможные отрицательные последствия на выполнение, стоимость, риск или качество проекта.
m) Технические базовые линии (например, требования, верификацию) следует регулярно анализировать с заинтересованными сторонами в течение проекта, чтобы обеспечить соответствие или корректировку целей (например, по стоимости, графику и выполнению).
n) Руководству следует уточнить и усовершенствовать методы определения продвижения проекта с тем, чтобы обеспечить раннее выявление перерасход средств или нарушения графика.