당연히 솔루션보다 문제부터 정의해야 합니다.
프로젝트는 문제를 해결하기 위해 시작하고 대부분의 프로젝트는 조금 늦거나 비용을 초과해도 주어진 문제를 해결합니다. 예를 들어 ‘프로젝트 관리시스템의 OO기능, XX기능 부재’를 문제로 정의하면 요구사항 관리, 일정관리, 예산관리, 인력관리, 위험관리, 문서관리 등의 기능을 갖춘 프로젝트 관리시스템을 개발하면 문제를 해결한 것입니다.
주어진 문제를 푸는 것은 어렵지 않습니다. 올바른 문제를 정의하는 것이 훨씬 어렵습니다. 프로젝트가 해결하고자 하는 사용자불편의 실체가 있고 불편이 클수록 프로젝트 가치는 높아집니다. 고객이 상품을 구매하는 동기는 솔루션이 아니라 문제를 해결하기 위해서입니다. 고객은 드릴이 필요한 것이 아니라 벽에 그림을 걸기 위한 구멍이 필요합니다. 고객의 문제를 해결하기 위한 솔루션은 여러 가지가 가능합니다. 벽에 그림을 걸고 싶은 욕구는 예전이나 지금이나 같지만 구멍을 뚫는 수단은 망치나 송곳에서 전동드릴로 변했습니다.
문제를 잘못 정의한 프로젝트는 당연히 틀린 답을 개발합니다. 예를 들어 엘리베이터 내 고객이 엘리베이터 속도가 느리다고 불만하는 것을 문제로 인식하면 솔루션은 엘리베이터 속도를 빠르게 하는 것이고, 밀폐된 공간에서 지겨워하는 것을 문제로 인식한다면 뉴스와 같이 볼거리를 제공할 것입니다.
문제가 달라지면 당연히 솔루션이 달라집니다. 프로젝트 관리시스템의 어떤 기능을 개발할 것인가를 고민하기 전에 왜 프로젝트 관리시스템을 구축하는 가를 고민해야 합니다. 프로젝트를 관리하는 도구가 오래되었다는 이유로, 새로운 프로젝트 관리도구가 유행한다는 이유로, 특정부서의 영향력을 확대하기 위한 이유로 프로젝트 관리 시스템을 구축하면 안 됩니다.
솔루션에 집중하면 없는 문제를 만들 수 있습니다. 문제를 해결하기 위한 솔루션을 찾는 것이 아니라 솔루션을 적용할 문제를 찾는 것이죠. 최근 화두인 생성형 AI는 좀 다를 것 같긴 하지만 유행했던 경영이론 또는 신기술들이 오랫동안 지속하는 것을 보지 못했습니다. 왜냐하면 그런 유행들은 대부분 고객의 구체적인 불편을 해결하기보다 추상적인 생산성향상에 집중하기 때문입니다. 따라서 목적보다 수단에 집중하여 단지 유행에 뒤처지지 않기 위한 프로젝트를 했다면 득 보다 실이 많았을 것입니다.
최근 유행했던 ‘디지털 전환’의 사례를 보면 알 수 있습니다. 모든 업종에서 디지털 전환을 하지 않으면 큰 기회를 놓치는 것처럼 이야기했지만, 디지털 전환 프로젝트를 수행한 기업 중 실질적인 성과를 창출한 기업이 얼마나 될지 의문입니다. 디지털 전환이 나쁘다는 이야기는 아닙니다. 문제가 명확하고 심각할 때 이를 해결하는 수단으로 ‘디지털 전환’을 사용할 때 성과를 창출할 수 있습니다. 모든 기업의 중요한 문제를 디지털 전환으로 해결할 수 없습니다. 문제가 달라지면 솔루션이 달라야 하는데 만병통치약 식으로 유행하는 트렌드를 맹신하는 따라 하면 안 됩니다.
컨설턴트들은 솔루션을 적용하지 않는 것을 문제로 인식시키는 재주가 있는 사람들입니다. 홈쇼핑이나 인터넷에서는 약을 팔기 위해 없는 질병 또는 무시해도 좋을 질병을 심각한 질병처럼 느끼게 합니다. 이런 사람들은 생존을 위해 수요(문제)를 창출하기 위해 노력하기 때문에 비난할 수 없습니다. 상품을 구매하는 기업이나 소비자가 진짜 문제를 제대로 판단해야 합니다.
그러나 진짜 문제를 찾기란 쉽지 않습니다. 프로젝트를 시작하기 전에 진짜 문제를 확인할 때 적용할 수 있는 아이디어 몇 가지를 공유합니다.
많은 사람들이 공감하는 불편사항을 확인합니다.
SI 프로젝트의 팀원들은 본인들이 누구의 어떤 문제를 해결하기 위해 프로젝트를 수행하는지 잘 압니다. 왜냐하면 프로젝트를 개발하는 도중 사용자들과 인터뷰를 하기 때문입니다. 많은 사용자들이 좋아하고 잘 사용할 프로젝트 결과물을 개발할 때 프로젝트 팀원의 사기는 높아집니다.
프로젝트 관리자와 프로젝트 팀원은 프로젝트 착수 전 또는 착수 초기에 시스템을 사용할 사용자들의 불편사항에 공감하고 그 문제를 해결하는 방안을 프로젝트 범위에 포함시켜야 합니다. 추상적인 불편이 아니라 눈에 보일 정도로 구체적인 불편을 많은 사람들이 이야기할수록 좋은 문제를 포착한 프로젝트입니다.
제대로 포착한 문제는 많은 사람들의 시간, 노력을 절감해 주는 것이 선명하게 보입니다. 길고 어려운 말로 프로젝트를 설명할 필요가 없습니다. 제가 경험한 최고의 프로젝트는 ‘연말 정산서류 자동화’ 였습니다. 지금은 국세청에서 파일을 다운로드하여 회사시스템에 업로드하면 연말정산이 간단히 끝나지만, 이전에는 연말 정산을 위해 모든 서류들을 취합하여 인사부서에 제출했었는데 정말 귀찮고 스트레스받는 작업이었습니다.
상품개발 프로젝트는 프로젝트 팀원들이 직접 고객의 불편이나 요구사항을 청취하기 힘들기 때문에 상품관리자가 고객을 대신하여 고객의 문제를 잘 설명해야 합니다. 상품관리자도 본인이 생각하는 솔루션을 설명하면 안 됩니다.
가짜 문제에 유의합니다.
가짜 문제는 정치적인 프로젝트에서 흔히 볼 수 있습니다. 특정 부서의 이해관계를 반영한 프로젝트를 할 때에도 사용자들의 문제를 해결한다는 명분이 필요하기 때문입니다. 조직생활을 하다 보면 특정 부서 또는 특정 경영층에게만 가치를 제공하는 정치적인 프로젝트를 수행할 수도 있습니다. ‘프로젝트 관리자의 위험식별 지원’, ‘WBS 기반의 공정관리’ 등은 현장중심이 아닌 중앙 집권적인 프로젝트 관리시스템 구축이 진짜 목표일 가능성이 높습니다. 그러한 프로젝트들은 대부분 신기술 적용을 명분으로 구체적이지 않고 추상적인 생산성 향상을 주장하기 때문에 프로젝트의 진짜 문제보다 솔루션을 강조합니다.
예를 들어 진짜 문제는 개별 프로젝트의 상세 진행상황을 경영층이 파악하기 힘들다는 것이고, 명목상의 문제는 프로젝트 관리자를 지원하는 프로젝트 관리 도구가 없다는 것입니다.
가짜 문제를 해결하는 프로젝트의 결과물은 일반 사용자들에게 가치를 제공하지 못하기 때문에 사용자들의 불편을 최소화하기 위한 노력을 해야 합니다. 불편을 최소화하기 위해서는 사용자들의 입력 데이터를 최소화하는 것이 중요합니다. 가치를 창출하지 못하는 시스템이 많은 데이터를 요구하고, 데이터의 정합성을 복잡하게 체크하는 것은 최악입니다. 물론 프로젝트 팀이 사용자들의 불편을 줄이는데 한계는 있습니다. 그렇지만 프로젝트 팀원들이 어떤 마음가짐으로 프로젝트에 임하느냐에 따라 사용자들이 경험하는 불편을 어느 정도는 줄일 수 있습니다. 프로젝트 관리자는 긴 호흡으로 프로젝트의 미래를 예상하고 의사결정해야 합니다.
‘why’와 ‘how’는 상호 보완적입니다.
프로젝트의 문제는 why에 해당하고, 솔루션은 how에 해당합니다. 그 둘은 상호 보완적입니다. ‘왜 그것이 문제인가요?’, ‘그 문제를 어떻게 해결할까요?’, ‘왜 그렇게 해결해야 하나요?’ 와 같이 why와 how를 반복하거나 순차적으로 질문하는 과정에서 문제와 해결방안을 검증하고 수정해야 합니다. 예를 들어 ‘WBS 기반의 공정관리’는 관점에 따라 문제일 수도 있고, 솔루션일수도 있습니다. 문제 또는 솔루션을 검증하는 인터뷰를 수행할 때 아래의 예와 같이 보통 why에 대해 충분히 답변되면 how로 전환하고, how에 대해 모호하면 why로 질문을 바꾸는 것이 좋습니다.
Q : 프로젝트 진척률을 파악하는 이유는 무엇인가요?
A : 프로젝트 위험을 조기에 식별하여 이슈를 하기 위함입니다.
Q : 위험을 식별하기 위해 왜 진척률을 파악하나요?
A : 진척률이 정량적인 데이터이기 때문에 프로젝트 관리자의 주관을 배제하고 실시간 데이터를 분석할 수 있기 때문입니다.
Q : 프로젝트 진척률을 파악하는 이유는 무엇인가요?
A : 프로젝트 위험을 조기에 식별하여 이슈를 하기 위함입니다.
Q : 위험을 식별하기 위해 왜 진척률을 파악하나요?
A : 진척률이 정량적인 데이터이기 때문에 프로젝트 관리자의 주관을 배제하고 실시간 데이터를 분석할 수 있기 때문입니다.
Q : 프로젝트 위험을 식별하는 다른 방안은 무엇인가요?
A : 프로젝트 관리자와 인터뷰하거나 프로젝트 관리자가 프로젝트 현황을 등록하는 것입니다.
Q : 어떤 방법이 위험식별에 더 효과적인가요?
A : 프로젝트 관리자에게 현황을 파악하는 것입니다.
Q : 그러면 왜 그 방법을 사용하지 않나요?
A : 프로젝트 관리자가 정확한 상황을 공유하는 것을 부담스러워 하기 때문입니다.
Q : 왜 부담스러워 하나요?
A : 위험을 보고하면 지원은 하지 않고 숙제가 많이 생기기 때문입니다.
이상의 질의응답을 통해 프로젝트 위험식별을 하기 어려운 근본적인 문제는 위험을 보고하면 지원이 아닌 숙제가 생기는 조직문화 때문임을 알 수 있습니다.
김병호 님이 브런치에 게재한 글을 편집한 뒤 모비인사이드에서 한 번 더 소개합니다.
