프로젝트 불확실성을 살펴보겠습니다.
프로젝트 불확실성 이해
프로젝트에는 다양한 불확실성이 있습니다. 불확실성은 프로젝트에 위협이 될 수도 있고 기회가 될 수도 있습니다. 위협은 “부정적” 불확실성인 반면, 기회는 “긍정적” 불확실성입니다. 즉, 불확실성은 부정적인 측면뿐만 아니라 긍정적인 측면의 기회도 갖고 있어 긍정적인 방향으로 연결될 수 있다는 뜻이다. 불확실성에는 다섯 가지 유형이 있습니다. 불확실성의 다섯 가지 유형은 일반 불확실성, 모호성, 복잡성, 변동성, 위험이는 프로젝트의 이슈, 이벤트(event), 프로젝트가 추구하는 솔루션에 대한 이해나 인식이 부족한 일반적인 불확실성(Uncertainty)입니다. 모호함은 프로젝트의 원인을 파악하고 다양한 옵션을 선택하는 데 어려움을 겪는 불분명한 상태입니다. 복잡성이란 인간의 행동, 시스템의 행동, 모호성으로 인해 관리하기 어려운 프로젝트의 특성과 환경을 말합니다. 변동성은 빠르고 예측할 수 없는 변화의 가능성입니다. 위험은 문제나 이벤트가 발생할 경우 하나 이상의 프로젝트 목표에 긍정적이거나 부정적인 영향을 미칠 수 있는 불확실한 이벤트 또는 조건입니다. 위험은 체계적으로 잘 관리되어야 합니다. 프로젝트의 불확실성을 VUCA라고도 합니다. VUCA는 변동성(Volatility), 불확실성(Uncertainty), 복잡성(Complexity), 모호함(Ambuguity)의 앞 글자를 모아 만든 개념이다. . 그리고 디지털 트랜스포메이션의 추세 그것 기술은 시장에 대한 관점을 심화시키고 있습니다. 카오스를 더하면 “VUCCA”가 됩니다.
프로젝트 불확실성에 대한 설명
불확실성은 모든 프로젝트에 내재되어 있습니다. 프로젝트 목표에 도움이 되는 잠재적 결과를 기회(Opportunity), 부정적인 영향을 미치는 잠재적 결과를 위협(Threat)이라고 하며, 이러한 프로젝트의 기회와 위협이 프로젝트의 리스크를 구성합니다. 프로젝트의 불확실성이 존재하는 이유는 무엇입니까? 프로젝트의 미래가 불확실한 이유는 내부와 외부 구성 요소가 상호 작용하고 프로젝트의 요구 사항, 비즈니스 정의 및 구현 기술을 이해하지 못하는 “복잡성”이 있기 때문입니다. 현존할 수 있는 ‘모호함’이 있을 수 있고, 미래는 원본 자체를 예측할 수 없는 ‘변동성’의 성격을 갖고 있기 때문이다. 이 “불확실성”은 프로젝트에서 “위험”이 됩니다. 미래는 원래 불확실하고 프로젝트에는 상호작용이 있기 때문에 프로젝트가 더 불확실하고, 여기서는 내용과 방향을 모르기 때문에 불확실하기 때문에 프로젝트의 미래 상황이 불확실하다는 것입니다. 결국 위험과 연결된다. . 여기서 프로젝트 위험은 프로젝트 목표 달성이 불확실할 수 있음을 의미합니다. 이러한 프로젝트에 존재하는 불확실성에 대응하는 방법에는 네 가지가 있습니다. 사전 준비로 세 번째 불확실성을 줄이기 위한 설계나 대안을 조사하고, 마지막 네 번째 회복탄력성을 구축합니다.[프로젝트 불확실성 대응 옵션 4가지]
관련 정보의 수집은 의견을 제시하거나 관련 연구 및 분석을 수행할 수 있는 각 분야의 전문가를 참여시키는 것입니다. 사전 준비는 초기 대응 솔루션, 백업 및 격리를 계획하는 것이며 설계 또는 대체 조사에 내용을 반영하여 불확실성을 줄일 수 있습니다. 회복력은 예상치 못한 환경에 빠르게 적응하고 대응할 수 있는 능력을 키우는 것입니다. 프로젝트 불확실성에는 다섯 가지 유형이 있습니다. 프로젝트 불확실성의 5가지 유형은 공통 불확실성, 모호성, 복잡성, 변동성, 위험으로 구성됩니다.[프로젝트 불확실성의 5가지 유형]
1. 일반적인 불확실성의 이해
일반적인 불확실성은 알 수 없거나 예측하기 어려운 상태입니다. 모르는 것은 현재나 미래의 상황이고, 예측하기 어려운 것은 미래의 사건(사건)이다. 일반적인 불확실성으로 인한 불확실성과 미래의 사건을 예측하기 어렵기 때문에 발생하는 불확실성이 있습니다. 알 수 없는 불확실성은 요구사항이나 비즈니스 정의가 부족한 경우, 요구사항이 변경될 가능성이 있는 경우 시스템을 구성하는 하드웨어, 소프트웨어, 데이터베이스(DB, 데이터베이스)아키텍처 다이어그램이 복잡하고, 프로젝트 기간이나 비용을 추정할 때 가정하는 작업 규모와 자원 생산성이 변동될 수 있습니다. 미래의 사건을 예측하기 어려울 때 발생하는 불확실성에는 경쟁사의 동향, 코로나 19예상치 못한 미래 사건, 시장을 바꿀 수 있는 신기술, 비즈니스 모델의 등장, 기업 조직의 변화에 따른 프로젝트 핵심 이해관계자의 변화, 법적 규제에 따른 변수 등이 있습니다. 일반적인 불확실성에 대한 대응 방향은 불확실성을 줄이거나 불확실성으로 인한 부정적 피해를 줄이는 것입니다. 그리고 불확실성을 줄이기 위해 프로젝트 관리자는 불확실성의 세부 사항을 정확하게 파악하고 이해해야 합니다. 또한, 요구사항 및 기술과 관련된 불확실성은 추가적인 정보 수집 및 분석을 통해 어느 정도 해소될 수 있습니다. 그러나 추가 정보 수집을 통해 얻을 수 있는 불확실성의 감소는 추가 정보 수집을 위한 시간 및 예산 손실보다 커야 합니다.애자일 프로젝트스파이크는 불확실성을 줄이는 방법으로 사용됩니다. Agile Project에서 사용하는 Spike 세션은 기술적 검증이나 사용자 인터페이스 검증을 위한 사용자 스토리를 설명하는 세션입니다. 프로토타입이나 와이어프레임을 만드는 과정과 개념 증명(PoC)도 불확실성을 줄이는 방법입니다. 불확실성으로 인한 부정적 피해를 줄이기 위해서는 반드시 다양한 결과에 대비하고 세트 기반으로 디자인하는 것이 중요합니다. 세트 기반 디자인에는 여러 디자인을 만든 후 검증 과정을 거쳐 최종적으로 하나의 디자인을 선택하는 작업이 포함됩니다. 기술이나 요구사항이 불확실한 경우에는 포인트 기반 디자인보다는 세트 기반 디자인이 효과적입니다.
2. 모호성에 대한 이해
모호성에는 ‘개념적 모호성’과 ‘상황적 모호성’이 있습니다. 개념적 모호성은 사람들이 용어와 주장을 다른 방식으로 사용할 때 발생합니다. 상황 모호성은 둘 이상의 결과가 가능할 때 발생합니다. 문제를 해결할 때 다양한 선택지와 대안이 있다면 무엇이 좋은 것인지 모호해집니다. 개념적 모호성은 프로젝트의 불확실성으로 이어지며, 이는 종종 요구 사항이나 완료 정의와 관련이 있습니다. 개념의 모호성을 줄이기 위해서는 표준 용어를 정의하고 프로젝트 내 의사소통을 명확히 해야 합니다. 프로젝트에 참여하는 모든 사람이 동일한 요구사항을 이해하고 사용할 수 있도록 하는 명확성이 가장 중요한 조건입니다. 상황의 모호성을 줄이기 위해 점진적인 개선, 실험 및 프로토타입 제작을 사용할 수 있습니다.[상황적 모호성 해결 방법]
상황의 모호성을 탐색하려면 점진적인 정교화를 사용하는 것이 좋습니다. 점진적 정교화란 정보의 양이 증가하고 견적이 더욱 정확해짐에 따라 프로젝트 관리 계획의 정확성을 높이는 반복적이고 진보적인 계획 접근 방식을 의미합니다. 하다. 계획을 수립할 때 상황에 따라 점진적, 반복적으로 지속적으로 세부화하는 방식이다. 점진적 사양이란 프로젝트가 진행됨에 따라 획득되는 정보의 양이 증가하고 이것이 사양으로 이어질 수 있음을 의미합니다. 프로젝트 기획과 관련된 대부분의 모호함은 점진적인 구체화를 통해 해결된다고 할 수 있습니다. 프로젝트가 끝나면 프로젝트 계획과 관련된 모든 모호함이 사라집니다. 실험은 모호성을 탐구하는 한 가지 방법입니다. 실험 방법을 사용할 수 있습니다. 잘 설계된 실험을 통해 인과관계를 알 수 있습니다. 실험은 주로 인과관계를 확인하기 위해 사용됩니다. 전형적인 예는 다음과 같습니다 A/B 테스트이는 실험과 유사한 프로토타입입니다. 요구 사항이 모호한 경우 프로토타입을 만들고 프로젝트 설계 단계에서 요구 사항을 자세히 설명할 수 있습니다. 실험이 인과관계를 파악하는 데 초점을 맞춘 방법이라면, 프로토타입은 다양한 변수 간의 관계를 탐색하는 데 사용되는 방법입니다. 상황적 모호성의 경우, 하나의 상황에 대해 미래의 조건이나 사건이 여러 경우에 발생할 수 있습니다. 이는 업무규모, 완료일자, 성과예산 등 계산결과와 관련하여 모호성이 있는 경우에 발생할 수 있다. 상황의 모호성을 줄이기 위해 불확실성을 해결하는 데 일반적으로 사용되는 방법인 추가 정보 수집 및 세트 기반 설계를 사용할 수 있습니다.
3. 복잡성 이해
복잡성은 다양한 방식으로 서로 상호 작용하고 작동하며 영향을 미칠 때 존재합니다. 복잡한 환경에서는 프로젝트의 개별 요소가 함께 모여 예상치 못한 결과를 초래할 수 있으며, 프로젝트 과정에서 결과가 어떻게 나타날 수 있는지 살펴보겠습니다. 어떤 경우에는 정확하게 예측하기 어려울 수도 있습니다. 복잡성을 처리하는 접근 방식에는 시스템 기반, 재구성 가능 및 프로세스 기반 작업이 포함됩니다.[복잡성을 다루는 방식]
시스템 기반 작업에는 분리 및 시뮬레이션이 포함됩니다. 디커플링(Decoupling)은 인프라와 애플리케이션을 설계할 때 시스템 복잡성을 줄이기 위해 사용되는 방법으로 아키텍처를 분리하는 것을 의미합니다. 대표적인 예로 MSA(Micro Service Architecture)가 있습니다. 마이크로서비스 아키텍처는 각 서비스를 분리하여 API(애플리케이션 프로그래밍 인터페이스)재구성은 복잡한 시스템을 다양한 관점에서 검토하여 재구성하는 것입니다. 프로세스 기반 작업은 반복적이고 점진적으로 구축하고 프로젝트 이해관계자의 참여를 촉진하는 것입니다. 계속해서 점진적으로 프로세스를 구축하고 이해관계자의 참여를 장려하는 것도 복잡성을 줄이는 좋은 방법입니다. 복잡성을 다루고 리스크를 관리할 때에는 이해관계자의 참여를 촉진하고 의견을 수렴하는 것이 좋습니다. 복잡성의 원인은 시스템, 인간 행동, 모호성 등으로 볼 수 있습니다. 복잡성을 해결하기 위해서는 복잡성 자체를 낮추거나, 복잡성에 대한 이해도를 높이거나, 문제로 인한 피해를 최소화하는 방법이 있습니다. 복잡성을 해결하는 방법으로는 시스템 분리, 재구성, 프로세스라는 세 가지 관점에서 접근하면 해결할 수 있는 것으로 요약할 수 있다. 시스템의 고립이란 구성 요소 간의 연결이 끊어지면 상호 작용이 줄어들어 변수가 줄어드는 것을 의미합니다. 시스템에 자체적으로 작동할 수 있는 구성 요소가 많을수록 복잡성이 낮아진다고 말할 수 있습니다. 이러한 분리 방식은 프로젝트 설계 단계에서 고려 및 반영되어야 하며, 이는 프로젝트 이해관계자를 적극적으로 활용하여 프로젝트의 복잡성을 줄일 수 있습니다. 프로젝트 이해관계자의 긍정적인 참여는 예상치 못한 좋은 효과를 가져올 수도 있습니다. 복잡성에 대한 이해 수준을 높이면 추가 프로젝트 구성 요소를 추가하여 추가적인 변경 사항과 영향을 식별할 수 있습니다. 그리고 복잡한 시스템을 다양한 각도에서 이해하고 분석하기 위해 브레인 저장이나 델파이와 같은 프로세스를 적용할 수 있습니다. 시뮬레이션은 시스템의 다양한 구성 요소가 어떻게 상호 작용하는지 이해하는 방법입니다. 다양한 데이터를 활용하는 것도 중요하지만, 확보하기 쉬운 데이터만 분석할 수는 없고, 어렵더라도 다양한 관점에서 데이터를 확보하고 활용할 수 있어 다양한 관점에서 복잡성을 줄일 수 있다. 이를 달성하기 위해서는 복원력(Resilience)을 확보하는 것이 중요하며, 대표적인 것이 시스템의 중복 구성이다.
4. 변동성의 이해
빠르고 예측할 수 없는 변화의 영향을 받는 환경에는 변동성이 존재합니다. 가변성은 일반적으로 프로젝트 일정과 비용에 영향을 미칩니다. 변동성은 본질적으로 예측할 수 없는 속성입니다. 전형적인 예는 하드웨어 및 상용 패키지와 같은 프로젝트 입력의 변동성입니다. 변동성을 해결하는 데는 두 가지 옵션이 있습니다. 변동성을 해결하는 두 가지 옵션은 대체 분석과 준비금입니다.[변동성을 해결하기 위한 옵션]
대안 분석은 변동성에 대응하여 목표를 달성하기 위해 다양한 대안을 식별하고 평가하는 것입니다. 대안은 계획 1, 계획 2, 계획 3 등 여러 계획을 수립하는 것입니다. 대안 분석은 프로젝트에 사용되는 기술, 투입물, 개발 주체의 다양한 조합을 만들어 최적의 계획을 찾는 방법입니다. 비즈니스 목표를 충족하기 위한 대안 분석 또는 선택한 솔루션을 구현하기 위한 대안 분석이 있습니다. 문제를 해결하는 방법은 다양하며, 개발 방법, 개발 대상, 적용 기술도 다양할 수 있습니다. 예비에는 비용 예비와 일정 예비가 포함됩니다. Cost Reserve는 가격 변동성으로 인해 예산이 초과되는 경우에 사용할 수 있으며, Schedule Reserve는 자원 가용성과 관련된 변동성으로 인한 일정 지연 문제를 해결하기 위해 사용할 수 있습니다. 일정예비란 프로젝트 일정을 짤 때 각 마일스톤 말미에 버퍼를 제공하는 것과 같은 방식이다. 변동성은 정확하게 예측하고 예방하기 어렵기 때문에 변동성이 발생할 경우를 대비한 예비비와 예비일정을 확보해야 합니다. .
5. 위험 이해
위험은 불확실성의 한 측면이며, 프로젝트 팀은 위협을 최소화하고 기회를 극대화하기 위해 프로젝트 전반에 걸쳐 위험을 식별해야 합니다. 위험 관리 활동은 프로젝트 전반에 걸쳐 수행됩니다. 위험관리를 위해 가장 먼저 해야 할 일은 위험식별이다. 위험은 개별 위험과 전체 프로젝트 위험으로 구분되어야 합니다. 총 프로젝트 위험은 불확실성이 전체 프로젝트에 영향을 미치는 위험입니다. 위험을 효과적으로 탐색하려면 회사, 조직 및 프로젝트 이해관계자의 위험 선호도 및 임계값을 반영하는 프로젝트 목표 달성과 관련하여 허용 가능한 위험 노출을 알아야 합니다. 이는 다음과 같이 정의할 수 있습니다. 위험 임계값은 회사, 조직 및 이해관계자의 위험 성향을 반영하는 목표에 대한 허용 가능한 변화를 나타냅니다. 임계값은 명시적으로 명시하고, 프로젝트 팀에 전달하고, 반영해야 하는 기준입니다. 위험에 관해서는 사람마다 선호하는 것이 다릅니다. 그래서 우리는 위험과 관련하여 사람들을 위험 회피형, 위험 중립형, 위험 선호형으로 분류합니다. 위험 한도는 위험 선호도를 반영하기 위해 결정된 목표 주위에 허용되는 변형입니다. 프로젝트에서는 위험과 이슈를 구별해야 합니다. 위험은 아직 발생하지 않은 불확실한 상황이나 조건입니다. 이슈란 현재의 문제, 편차, 불일치, 이미 발생한 문제를 말합니다. 따라서 리스크에는 발생을 방지하는 방법을 다루는 강력한 예방적 측면이 있고, 이슈에는 현안에 대응하는 방법에 대한 강력한 대응 측면이 있습니다. 리스크와 관련된 프로젝트 관리 문서는 리스크 등록부(Risk Register)이고, 이슈에는 이슈 로그(Issue Log)가 있습니다. 아직 리스크가 발생하지 않았으므로 “발생한 경우”라는 단서를 추가하고, 이슈는 이미 발생하였으므로 대응 및 해결이 필요한 이슈를 다루도록 하겠습니다.