// 방법1 // 방법2
  • 2023. 8. 10.

    by. 푸른솔개의 꿈

    리스크 관리 계획 (Risk Management)은 개발 과정 중에 특정한 일이 발생하여 개발 일정, Cost, 개발 범위 (Scope), 품질 등의 프로젝트 목표에 플러스나 마이너스의 영향을 미치는 상황을 관리하기 위해 수행합니다.

     

     

    프로젝트의 성공을 위해서는 불 안정하거나 불 확실한 요소를 식별하고 분석하여 대응 계획을 수립하고 실행함으로써 불안 요소가 계획대로 줄어들고 제거되고 있는지를 감시하고 Control 해야 합니다.

    개발에 플러스가 되는 요인의 확률과 영향은 증대시키고, 마이너스가 되는 요인의 발생 확률과 영향은 저감 시킬 수 있는 Risk Management 내용에 대해 설명드리겠습니다.

     

    Risk-Management-섬네일
    Risk Management

     

    프로젝트 리스크 (Project Risk) 관리 계획

    프로젝트 리스크는 만약 그 일이 발생하면 개발 일정, Cost, 개발 Scope, 품질 등의 프로젝트 목표에 영향을 미치는 불확실한 이벤트 (Event) 혹은 상태를 말하며, 이미 인지하고 있는 Risk와 발생이 예상되는 Risk로 분류하여 관리해야 합니다.

    인지하고 있는 Risk는 이전 기종의 실패 사례와 같이 이미 알고 있는 Risk로 중요한 Risk가 재발되지 않도록 사전 대책을 수립하여 대응해야 하고, 발생할 가능성이 예상되는 미지의 Risk는 사전에 구체적인 완화 대책을 수립하기에는 어려움이 있으므로 Risk가 발생한다는 가정하에 이렇게 위기 대응을 하겠다는 행동 지침 정도의 포괄적인 Risk 대책을 기재합니다.

    이렇게 돌발적인 위기 상황을 예상하여 대안 대책을 수립하는 것을 컨틴젠시 플랜 (Contingency Plan)을 수립한다라고 말합니다. 이미 알고 있는 기지의 Risk도 사전에 대책을 정확하게 수립할 수 없는 경우에는 컨틴젠시 플랜 (Contingency Plan)으로 대응할 수 있습니다.

     

    Risk와 달리 Issue는 이미 발생한 문제를 의미합니다. 개발 목표 달성에 플러스 요인은 없고 100% 마이너스 요인만 있으므로 필수 적으로 Issue를 조기에 완결하는 절차를 갖추어야 합니다.

    Issue의 발생부터 완결까지 관리하는 시스템을 문제점 관리 시스템이라고 부르는데 이에 대해서는 추후에 설명드리도록 하겠습니다.

     

     

    프로젝트 리스크 (Project Risk) 식별과 세분화 사례

    Risk 관리를 빠짐없이 효율적으로 수행하기 위해서 Risk 항목을 세분화하여 식별합니다.

    이렇게 세분화 구조로 정리하는 것을 Breakdown Structure를 구성한다라고 합니다.

    Project Risk 세분화 구조 (Breakdown Structure)의 첫 번째  단계 (Step 1)는 기술적 요인, 외부 환경 요인, 당사 조직 내 요인, 개발 관리 (Project Management) 요인으로 구성합니다.

     

    [Project Risk Breakdown Structue 사례]

    Risk-Management-Breakdown-Structure
    Risk Management Breakdown Structure (이미지 클릭하면 확대됩니다.)

     

    기술적 Risk 요인의 세부 분류

    기술적 Risk 요인의 세부 분류로는 고객의 요구 특성, 개발 범위 (Scope), 고객의 수용 조건, 기술의 복잡성, 기술의 신규성 등을 들 수 있습니다.

    고객의 요구 특성 Risk에서는 고객의 요구 사항을 정확하게 파악하였는지, 고객의 요구가 애매하여 검증이 불가능하거나 요구 특성이 일관성이 없어 상호 간 Trade off 관계에 있는 요구 특성이 있는지, 고객의 요구를 간과한 것은 없는지 체크하고 확인해야 합니다.

     

    개발 범위 (Scope) 측면에서는 기술적으로 개발해야 하는 범위가 다 포함되어 있는지 확인해야 합니다. 예를 들면 기술적으로 디스플레이 패널부터 구동회로, 기구부 까지 개발 범위로 포함되어야 하는데 기구부와 패널 간의 부착 방법 최적화 등을 개발 범위에서 누락했다면 이것이 추후에 기술적 Risk로 작용하게 될 것입니다.

     

    기술의 복잡성과 신규성 Risk는 기술이 복잡하거나 신규 기술인 경우에는 개발의 난이도가 올라가게 되고, 많은 부분의 설계적 변경이 필요하며 신 기능을 검증하는 절차가 강화됩니다. 또 제품을 구성하는 모듈 간의 매칭성 확보에도 일정이 많이 소요되므로 가능한 개발 일정을 줄이고 효율적으로 개발할 수 있는 방법에 대한 대책을 수립해야 합니다.

     

     

    외부 환경 Risk 요인의 세부 분류

    외부 환경 Risk 요인을 세분화하면 외부 부품 조달 Risk, 법률과 규제 Risk, 시장과 고객 Risk 등으로 분류할 수 있습니다.

    외부 부품 조달 Risk는 부품 협력사 또는 부품 공급원의 부품 품질에 문제가 발생하였거나 조달에 문제가 발생했을 때를 상정하여 완화 대책을 수립하는 것입니다.

    작년에 발생한 반도체 Shortage 대란을 반추해 보면 외부 환경 조달 Risk를 관리하여 사전에 대란을 예측하여 대책을 수립한 회사와 그렇지 못한 회사 간에는 엄청난 경쟁력 차이가 있음을 쉽게 유추해 볼 수 있습니다.

     

    법률과 규제 Risk 관리는 승인에 필수적인 규제 사항의 변경을 미리 확인하여 승인 절차에 일정 차질이 발생하지 않도록 관리하기 위함입니다.

    시장과 고객 Risk는 목표 시장이 예상보다 확대되거나 축소되는 지를 확인해야 하고 경쟁사의 제품 수준도 수시로 확인하여 경쟁사 제품의 수준과 일정이 예상보다 우수하거나 빠르게 진행되는 지를 확인해야 합니다. 또한 가격의 추이도  확인하여 시장 환경이 급속하게 변화하고 있다면 빠르게 대책을 수립해야 합니다.

     

     

    조직 내 요인, 개발 관리 요인의 세부 분류

    당사 내부의 조직과 관련한 Risk 요인은 개발 인력 투입수와 투입되는 개발 인력의 기술 역량이 충분한가를 수시로 확인하고 차질이 예상된다면 충원 또는 멤버 교체 등을 고려해야 합니다.

    그리고 시스템 (PLM 등), 개발 시설, 실험실, 개발 장비 등이 충분하고 최고의 상태를 유지하고 있는지도 확인해야 합니다.

    개발 관리의 Risk 요인은 표준화된 개발 프로세스가 있는 지와 개발 프로세스가 최근에 변경되었는 지를 확인해야 합니다. 규정화되고 문서화된 프로세스에 따라 개발 마일스톤 (Milestone) 검증이 진행되므로 규정된 개발 문서와 절차들을 차질 없이 준비하고 수행해야 합니다.

    그리고 개발 인력 간 관련 부서 간 Communication과 협업이 잘 이루어지고 있는지도 개발 관리 Risk 요인으로 관리해야 합니다. 협업에 의한 동시 개발 (Concurrent Engineering)이 이루어지지 않고 개발은 개발대로 제조 기술과 품질은 또 다른 계획으로 개발에 참여하고 있다면 그 Project의 성공을 위해서는 많은 시행착오를 겪어야 할 것입니다.

     

     

    ※ Risk Management를 위한 Check List가 필요 하시면 아래 첨부 파일을 참조하십시오.

    Risk Checklist.xlsx
    0.01MB

     

    이상과 같이 프로젝트 진행 시 Risk 요인에 대응하기 위한 Risk Management 개요에 대해 알아보았습니다. 다음 포스팅에서는 Risk Management 실행 방법에 대해 정리하겠습니다.