Некорректное определение рисков проекта

Мы знаем, что не существует методик безошибочного задания требований к сложным прикладным автоматизированным системам. Кроме того, жизнь заставляет корректировать требования к системам до завершения проекта. Таким образом, риск изменения требований, обычно фиксируемый в проектах как основной, риском не является. Вероятность уточнения требований по ходу проекта равна 100%. Риски реализуются с вероятностями менее 100%. В качестве такого риска можно задавать не риск изменения требований, а риск изменения требований, например, в объеме, превышающем трудоемкость 1000 чел/дней.

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

Ошибка определения списка участников проекта

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

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

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

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