Формальное завершение проекта


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

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

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

· Документация по продуктам проекта. Документация, описывающая продукты проекта (спецификации, планы, техническая документация, электронные файлы и пр.).

· Прочая рабочая документация проекта.

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

Формальное утверждение. Документ, подтверждающий приемку заказчиком всех продуктов проекта.

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

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

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

Раздел 8. УПРАВЛЕНИЕ РИСКАМИ В ПРОЕКТЕ Управление рисками в проекте: введение Управление рисками включает процессы, направленные на идентификацию рисков, их анализ и реагирование. Целью является извлечение максимально большей выгоды из событий, положительно влияющих на проект, и минимизация последствий событий, влияющих на проект отрицательно. Риски могут быть связаны как с положительными последствиями, так и с отрицательными. Однако все риски можно привести к отрицательным, если положительные последствия рисков отнести к запланированным возможностям.

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

Риску подвержены в той или иной мере все элементы проекта.

Риск может быть отождествлен с вероятностью наступления какого-либо события, в результате которого возможны потери.

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

Риск – величина вероятностная.

Риск проекта характеризуются тремя параметрами, так называемыми факторами риска:

1) рисковое событие, которое может произойти в ущерб проекту;

2) вероятность наступления такого события;

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



Категория: управление. Дата публикации: 8 Март, 2010.