문제: 조직이 직면한 바람직하지 못한 상황
솔루션: 문제를 해결하는 방안
모든 프로젝트는 문제를 해결하기 위해 시작한다. 대부분의 프로젝트는 조금 늦거나 비용을 초과할 수는 있지만 주어진 문제를 해결할 것처럼 보이는 솔루션 개발에 성공한다. 예를 들어 프로젝트 관리시스템이 없는 조직에서 프로젝트 관리 시스템 구축에 착수한 뒤 요구사항 관리, 일정관리, 예산관리, 인력관리, 위험관리, 문서관리 등의 기능을 개발하는 것이다.
여기에서 문제를 ‘프로젝트 관리시스템의 부재’로 정의하면 솔루션은 ‘프로젝트 관리기능을 갖춘 시스템’이면 된다. 문제를 좀 더 상세하게 ‘ OO기능, XX기능 부재’와 같이 정의해도 마찬가지이다. 그러나 문제를 잘못 정의하면 진짜 문제의 정답을 찾기란 불가능하다. 예를 들어 엘리베이터 내 고객이 엘리베이터 속도가 느리다고 불만하는 것을 문제로 인식하면 솔루션은 엘리베이터 속도를 빠르게 하는 것이고, 밀폐된 공간에서 지겨워하는 것을 문제로 인식한다면 뉴스와 같은 볼거리를 제공할 것이다.
‘문제·솔루션’과 관련하여 유의할 사항은 다음과 같다.
첫째, 솔루션보다 문제에 집중한다.
문제가 달라지면 솔루션이 달라진다. 예를 들어 관리시스템의 어떤 기능을 개발할 것인가를 고민하기 전에 왜 프로젝트 관리시스템을 구축하는가를 고민해야 한다. 조직 내에 프로젝트를 관리하는 도구가 없거나 오래되었다는 이유로 프로젝트 관리 시스템을 구축하기로 결정하면 안 된다. 솔루션에 집중하면 없는 문제를 만든다. 솔루션의 부재가 문제가 아니다. 없는 병을 만들고 병을 치료하는 약을 복용하지 않는 것을 문제라고 말해서는 안된다. 솔루션의 부재를 문제로 정의하는 것은 공급(솔루션)이 수요(문제)를 만든다는 사고의 결과이다.
둘째, 사용자들의 문제(불편사항)를 확인한다.
프로젝트 팀원들은 본인들이 누구의 어떤 문제를 해결하기 위해 프로젝트를 수행하는지 잘 안다. 왜냐하면 프로젝트를 개발하는 도중 사용자들과 인터뷰를 하기 때문이다. 많은 사용자들이 좋아하고 잘 사용할 프로젝트 결과물을 개발할 때 프로젝트 팀원의 사기는 높아진다. 프로젝트 관리자와 프로젝트 팀원은 프로젝트 착수 전 또는 착수 초기에 시스템을 사용할 사용자들의 불편사항에 공감하고 그 문제를 해결하는 방안을 프로젝트 범위에 포함시켜야 한다.
때로는 특정 부서 또는 특정 경영층에게만 가치를 제공하는 정치적인 프로젝트를 수행할 수도 있다. 이때는 프로젝트 결과물이 일반 사용자들에게 가치를 제공하지 못하기 때문에 사용자들의 불편을 최소화해야 한다. 불편을 최소화하기 위해서는 입력 데이터를 최소화해야 한다. 가치를 창출하지 못하는 시스템이 많은 데이터를 요구하고, 데이터의 정합성을 복잡하게 체크하는 것은 최악이다. 물론 프로젝트 팀이 사용자들의 불편을 줄이는데 한계는 있다. 그렇지만 프로젝트 팀원들이 어떤 마음가짐으로 프로젝트에 임하느냐에 따라 사용자들이 경험하는 불편을 어느 정도는 줄일 수 있다. 프로젝트 관리자는 본인뿐 아니라 팀원들의 프로젝트 수행이력에 어떠한 프로젝트를 남길 지 고민해야 한다.
셋째, 가짜 문제에 유의한다.
가짜 문제는 정치적인 프로젝트에서 흔히 볼 수 있다. 특정 부서의 권력이나 이해관계를 반영한 프로젝트를 할 때에도 일반 사용자들의 문제를 해결한다는 명분이 필요하기 때문이다. ‘프로젝트 관리자의 위험식별 지원’, ‘WBS 기반의 공정관리’등은 현장중심이 아닌 중앙 집권적인 프로젝트 관리시스템 구축이 진짜 목표일 가능성이 높다. 이 경우 진짜 문제는 개별 프로젝트의 상세 진행상황을 경영층이 파악하기 힘들다는 것이고, 명목상의 문제는 프로젝트 관리자를 지원하는 프로젝트 관리 도구가 없다는 것이다. 진짜 문제를 확인하기 위해서는 두 번, 세 번의 why에 대해 답해야 한다.
넷째, why와 how는 상호보완적이다.
현실에서 문제는 Why, 솔루션은 how에 가깝고 그 둘은 상호 보완적이다. ‘왜 그것이 문제인가요?’, ‘그 문제를 어떻게 해결할까요?’, ‘왜 그렇게 해결해야 하나요?’와 같이 why와 how를 반복하거나 순차적으로 질문하는 과정에서 문제와 해결방안을 검증하고 수정한다. 예를 들어 ‘WBS 기반의 공정관리’는 관점에 따라 문제일 수도 있고, 솔루션일수도 있다. 다음과 같은 문답을 통해 문제 또는 솔루션을 검증한다. 아래의 예와 같이 보통 why에 대해 충분히 답변되면 how로 전환하고, how에 대해 모호하면 why로 질문을 바꾸는 것이 좋다.
Q : 왜 경영층이 프로젝트 진척률을 파악해야 하나요?
A : 프로젝트 위험을 조기에 식별하여 이슈를 하기 위함입니다.
Q : 위험을 식별하기 위해 왜 진척률을 파악하나요?
A : 진척률이 정량적인 데이터이기 때문에 프로젝트 관리자의 주관을 배제하고 실시간 데이터를 분석할 수 있기 때문입니다.
Q : 프로젝트 위험을 식별하는 다른 방안은 무엇인가요?
A : 프로젝트 관리자와 인터뷰하거나 프로젝트 관리자에게 프로젝트 현황을 파악하는 것입니다.
Q : 어떤 방법이 위험식별에 더 효과적인가요?
A : 프로젝트 관리자에게 현황을 파악하는 것입니다.
Q : 그러면 왜 그 방법을 사용하지 않나요?
A : 프로젝트 관리자가 정확한 상황을 공유하는 것을 부담스러워 하기 때문입니다.
Q : 왜 부담스러워 하나요?
A : 위험을 보고하면 숙제가 많이 생기기 때문입니다.
이상의 질의응답을 통해 프로젝트 위험식별을 하기 어려운 근본적인 문제는 위험을 보고하면 지원이 아닌 숙제가 생기는 조직문화 때문임을 알 수 있다.
김병호 님이 브런치에 게재한 글을 편집한 뒤 모비인사이드에서 한 번 더 소개합니다.
