프로젝트 결과는 왜 불확실할까요?

미래는 예측하기 힘들고, 프로젝트 내용은 모호하고, 복잡하기 때문입니다.

프로젝트의 위험이란 ‘프로젝트 결과에 긍정적 또는 부정적 영향을 미칠 수 있는 불확실한 상황’입니다.

프로젝트의 결과가 불확실한 이유는 다음과 같이 세 가지로 구분할 수 있습니다.

• 예측 불가능한 사건 때문에 예상 못한 결과가 발생합니다. (변동성)

• 프로젝트 내용을 정확하게 이해하지 못해 예상 못한 결과가 발생합니다. (모호성)

• 프로젝트 구성요소들의 상호작용으로 예상 못한 결과가 발생합니다. (복잡성)

앞서 설명한 용어들은 뷰카(VUCA) 즉, 변동성(Volatility), 불확실성(Uncertainty), 복잡성(Complexity), 모호성(Ambiguity)으로 정리할 수도 있습니다. 뷰카는 1990년대 초반 미국 육군대학원에서 처음으로 사용했는데, 급변하는 경영환경의 특성을 설명하는 대표적인 용어가 되었습니다. 최근에는 AI로 대표되는 소프트웨어 기술이 시장의 뷰카를 더욱 심화시키고 있으며, 혼돈(Chaos)을 추가하여 ‘VUCCA’라고도 합니다.

불확실성을 관리하는 방안에는 불확실성을 낮추는 것과 불확실성으로 인한 부정적인 피해를 줄이는 것이 있습니다. 

• 불확실성을 낮추는 방안 

적용해보지 않은 신기술을 적용하면 구현의 불확실성이 높고, 고객에 대한 이해가 부족하면 요구사항 관련 불확실성이 높습니다. 이런 경우에는 추가적인 정보를 수집하고 분석하여 불확실성을 낮출 수 있습니다. 예를 들어 신기술을 적용한 파일럿 과제를 수행하거나, 고객 요구사항 검증을 위한 MVP를 개발하여 고객가치를 확인하는 것입니다. 다만, 추가 정보를 수집하여 얻는 혜택(불확실성 감소)이 추가정보 수집을 위한 시간과 예산투입의 손실보다 커야 합니다.

애자일 방법론에서는 이를 스파이크(spike) 적용이라고도 합니다. 스파이크는 ‘기술의 검증 또는 사용자 인터페이스를 검증하기 위해 만든 사용자 스토리’입니다. 스파이크 적용을 통해 기술구현이나 요구사항의 불확실성을  제거하면 사용자스토리의 규모를 추정할 수 있습니다. 프로토타입, 개념 증명(proof of concept), 와이어프레임(wireframe)도 스파이크의 한 유형입니다.  스파이크는 특정 스프린트에 포함하여 진행할 수도 있지만, 스파이크 적용을 위한 별도의 스프린트를 수행할 수도 있습니다. 

기술구현 또는 요구사항의 불확실성이 높을 때는 여러 가지 방안을 동시에 개발하여 그중에서 최적의 방안을 선택할 수 있습니다. 이를 ‘세트기반 설계(Set based design)’라고 합니다. ‘세트기반 설계’는 여러 가지 설계안을 만든 뒤 검증과정을 거치면서 최종적으로 하나의 설계안을 선택하는 것으로, 반대말은 ‘단일방안 설계(point based design)’입니다. 세트기반 설계는 불확실성에 대응하기에 효과적이지만 복수의 설계방안을 만들고 검증하기 위해 투입되는 ‘시간과 비용’이 문제입니다. 만일 세트기반 설계의 장점이 추가로 투입되는 시간과 비용을 상쇄하고도 남는다면 세트기반 디자인을 적용할 수 있습니다.

• 불확실성으로 인한 부정적인 피해를 줄이는 방안

불확실성을 낮추는 방안은 위험을 예방하는 것입니다. 위험을 예방하기 힘들다면 위험이 발생했을 때 피해를 줄여야 합니다. 정전에 대비한 UPS(무정전 전원공급장치)처럼 위험이 발생할 때를 대비해 비상계획을 수립하는 활동이 대표적입니다. 불확실한 미래의 경우의 수를 모르거나 경우의 수가 너무 많다면 대비책을 수립하기 힘듭니다. 가장 발생 가능성이 높은 경우를 분석하여 그에 대한 대비책을 수립해야 합니다.

복원력(resilience)은 심리학에서는 ‘회복탄력성’이라는 용어로도 사용하지만, 위험발생에 대응하는 능력을 의미하기도 합니다. 위험은 발생하지 않는 것이 바람직하지만, 발생했을 때는 이전과 비슷한 상태로 빨리 복원하는 것이 중요합니다. 서비스 장애를 초래할 수 있는 위험이 발생해도 백업시스템이 잘 가동되어 서비스를 차질 없이 제공하는 것이 대표적인 예입니다.

1. 변동성으로 인한 불확실   

프로젝트의 결과가 불확실한 이유는 변동성, 복잡성, 모호성으로 설명하였습니다. 세 가지 내용을 정확하게 이해하면 불확실성을 좀 더 정확하게 이해할 수 있습니다. 먼저 변동성으로 인한 불확실성을 살펴보겠습니다. 변동성은 ‘예측 불가능한 사건이나 상황’으로 그 예는 다음과 같습니다.

• 경쟁사의 신상품 출시 

• COVID-19와 같은 새로운 전염병의 확산

• 시장을 판도를 바꾸는 신기술 또는 비즈니스 모델의 탄생

• 핵심 이해관계자의 변경

• 법적 규제사항 또는 정치적 변수 (예: 플랫폼 사업과 관련된 법안 통과)

변동성은 대부분 예측할 수 없고 사전에 대응할 수 없기 때문에 운의 영역에 해당하며, 유일한 대응방법이 예비기간 또는 예비비를 확보하는 것입니다. 그러나 어느 정도의 불확실성이 있을지 파악하기 힘들기 때문에 예비기간 또는 예비비를 확보하기도 힘든 것이 현실입니다. 변동성과 관련된 위험은 프로젝트 관리자에게 책임을 묻기 힘들기 때문에 프로젝트 수준이 아니라 조직 차원에서 관리해야 할 위험입니다. 변동성은 예방할 수 없기 때문에 위험의 조기식별과 대응이 중요합니다. 

2. 모호성으로 인한 불확실성

   
   

모호성은 ‘여러 가지로 해석되는 상황’으로 ‘개념의 모호성’과 ‘상황의 모호성’이 있습니다. 프로젝트에서 개념의 모호성은 ‘요구사항 정의’또는 ‘완료정의(definition of done)’와 관련될 경우가 많습니다. ‘개념의 모호성’을 줄이려면 표준용어를 정의하고, 문서나 메일보다 대면 의사소통을 자주 해야 합니다. 문서나 메일을 소통의 주요 수단으로 사용할수록 개념의

모호성은 증가합니다. 프로젝트는 새로운 업무를 낯선 사람들이 모여서 수행하기 때문에 일반 운영업무보다 개념의 모호성이 발생할 가능성이 높습니다.

‘상황의 모호성’은 현재의 문제를 해결하기 위한 방안이 여러 가지 있거나, 하나의 상황에 대해 미래의 조건이나 사건들이 여러 가지 발생할 수 있을 때 발생합니다. 기술적 구현의 불확실성, 일정추정의 불확실성이 대표적인 상황의 불확실입니다. 상황의 모호성을 줄이기 위해서는 추가정보를 파악해야 합니다.

3.  복잡성으로 인한 불확실성 

시스템은 ‘공동의 목표 달성을 위해 상호작용하는 구성요소의 집합’입니다. 프로젝트 결과물 또한 하나의 시스템이며 프로젝트 수행을 위한 사람, 도구, 프로세스, 외부환경, 경쟁사등이 시스템 구성요소의 예입니다. 복잡성은 시스템을 구성하는 상호작용의 수와 상호작용의 영향력입니다. 시스템을 구성하는 요소가 많고 다양할수록 구성요소들 간의 상호작용의 수가 많아지고 상호작용의 영향력은 커집니다. 

다음의 요인들은 프로젝트의 복잡성을 증폭시킬 수 있습니다.   

• 프로젝트의 문화 

이해관계자들의 태도, 경험, 가치관은 프로젝트의 주요 의사결정에 영향을 끼칩니다. 프로젝트의 다양한 이해관계자들이 집합적으로 만드는 태도, 경험, 가치관을 ‘프로젝트의 문화’라고 정의하면 프로젝트의 문화는 복잡성을 증폭시키거나 반감시키는 촉매가 됩니다. 예를 들어 SI(Systems Integration) 프로젝트를 수행할 때 발주사 또는 국가기관과 프로젝트 수행사의 문화적 차이로 인한 부작용이 자주 발생합니다. 

• 개인의 정치적인 이해관계 

개인의 정치적인 이해관계도 프로젝트 복잡성을 증가시킵니다. 예를 들어 특정 이해관계자가 프로젝트 검토회의 시 프로젝트 목표에 심각한 영향을 미치는 안건을 상정하는 것입니다. 

• 시스템 구성요소들의 상호의존성 

프로젝트와 관련된 시스템(기술, 프로세스, 자원 등)이 복잡하고 정교하게 연관될수록 시스템을 구성하는 작은 부문의 문제가 전체의 문제로 확대될 가능성이 높습니다. 우주선 발사와 같이 규모가 큰 프로젝트도 대부분 사소한 문제 때문에 실패하는 것도 같은 이유입니다. 

• 기술혁신 또는 비즈니스 모델 혁신 

기술혁신은 기존 제품, 서비스, 프로세스, 도구 등에 변화를 초래할 수 있다. 스마트폰의 출현이 사회 문화, 다른 제품, 프로세스에 끼친 영향을 생각해 보면 알 수 있습니다. 최근에는 기술혁신뿐만 아니라 비즈니스 모델혁신도 기술혁신 못지않게 사회에 큰 영향을 끼칩니다. 에어비엔비, 우버, 배달의민족, 아마존 등은 기술기반의 혁신이 아니라 비즈니스 모델의 혁신으로 기업의 생태계를 변화시킨 대표적인 예입니다. 

복잡성이 프로젝트 관리를 힘들게 만드는 이유는 다음과 같습니다.

• 프로젝트가 복잡할수록 프로젝트 계획수립이 어렵습니다.

• 프로젝트가 복잡할수록 성과예측이 힘들어집니다.

• 프로젝트가 복잡할수록 변경 가능성이 높아지고, 변경에 대한 대응이 어렵습니다. 

복잡성은 위에서 설명한 것과 같이 다양한 원인으로 발생할 수 있고 다양한 원인들은 상호작용하기 때문에 예측하기 힘듭니다. 복잡성에 대응하기 위해서는  앞서 설명한 불확실성 대응과 마찬가지로 복잡성의 내용을 이해하여 복잡성을 낮추고, 복잡성으로 인한 피해를 줄여야 합니다. 

프로젝트의 복잡성을 이해하기 위해서는 시스템적 사고로 프로젝트 내부의 구성요소와 외부환경을 파악해야 합니다. 특히 프로젝트 외부환경의 변화로 인한 복잡성의 증가는 프로젝트에 미치는 영향이 크기 때문에 유의해야 합니다. 기업외부의 환경을 프로젝트 관리자가 분석하고 대응하기 힘들지만, 프로젝트에 영향을 미칠 수 있는 조직의 전략이나 이해관계자의 관심사항은 주의하여 모니터링해야 합니다. 

구성요소 간의 상호작용을 이해하면 복잡성을 관리할 때 도움이 됩니다. 예를 들어 프로젝트 구성요소(예: 기능)를 하나씩 추가하여 변화를 파악하면 해당 구성요소가 나머지 구성요소와 어떤 작용을 하는지 이해할 수 있습니다. 특정변수의 변화가 전체 시스템에 미치는 영향을 파악하는 실험계획법의 접근방법입니다. 반복·점증적인 방식으로 신규기능을 추가하면 한꺼번에 통합할 때 분석하기 힘들었던 구성요소 간의 영향력을 파악할 수 있습니다.

프로젝트 복잡성을 낮추는 방안은 다음과 같습니다. 

• 구성요소 간의 상호작용이나 의존관계를 분리

구성요소 간의 연결을 끊으면 상호작용이 줄어들어 변수가 줄어듭니다. 자체적으로 작동하는 구성요소들이 많을수록 복잡성은 낮아집니다. 이러한 방식은 프로젝트 설계단계에 반영해야 합니다.

• 이해관계자 긍정적인 참여를 유도 

프로젝트에 부정적인 영향을 미치는 개인의 이해관계로 인한 복잡성을 줄이는 방안입니다. 이해관계자들의 긍정적인 참여를 높이면 예상하지 못한 상황을 줄일 수 있습니다.

=======================================================
제가 삼성 SDS에서 30년동안 경험하고 체득한 교훈을 정리한 <슬기로운 PM 생활>을 25년 1월 출간한 소식을 공유합니다.

https://product.kyobobook.co.kr/detail/S000215148133