프로젝트 팀이 해결하고자 하는 문제와 근본원인이 누가 봐도 명확하고 단순할 수 있다. 예를 들어 단순하고 반복적인 자료 취합을 로봇을 활용하여 자동화하는 프로젝트는 해결할 문제와 근본원인이 명확하다. 그 문제를 해결할 기술만 있으면 된다. 만일 검증된 기술이 있다면 프로젝트가 실패할 가능성은 낮다. 그러나 대부분의 프로젝트는 문제와 근본원인이 간단하지 않고 복합적(complicated)이거나 복잡(complex)하다. 시간을 가지고 꼼꼼하게 검토하면 문제를 정확하게 이해할 수 있는 프로젝트가 있는 반면, 해보기 전에는 문제를 정확하게 이해했는지 확인하기 힘든 프로젝트도 많다. 물론 문제를 정의하고 분석하는 사람의 역량에 따라 복합적인 문제가 복잡한 문제가 되기도 한다.
프로젝트 문제를 상세하게 분석해야 할 복합적인 프로젝트
프로젝트를 구성하는 요소(element)들이 많고 요소들 간의 상호작용이 많으면 복합적인 프로젝트가 된다. 초고층 빌딩을 건설하는 프로젝트에서 엔지니어가 고려할 요소는 하중, 내진, 바람에 견디기, 수평/수직 잡기, 메인 프레임 등 다양하다. 많은 요소들을 고려한 설계를 하고 다양한 시뮬레이션을 통해 문제가 없음을 검증한 뒤에 시공을 착수해야 한다. 초고층 빌딩건설에서 이러한 문제를 충분히 검증하지 않고 시공에 착수한다면 부실한 빌딩을 건설하게 된다. 초고층 빌딩 건설은 많은 요소를 고려해야 하는 복합적인 프로젝트이다. 그러나 실력 있는 엔지니어들에게 시간만 준다면 복합적인 문제를 해결할 수 있다.
복합적인 소프트웨어 시스템의 예로는 SI기업의 프로젝트 관리시스템이나 은행의 차세대 시스템을 생각할 수 있다. SI기업의 프로젝트 관리시스템은 초고층 빌딩의 건설보다는 복합도가 낮지만 영업관리, 구매관리, 손익관리, 인력관리, 일정관리, 위험관리, 지식관리, 외주관리, 품질관리 등의 상호관계를 분석하고 설계한 뒤 개발에 착수해야 한다. 특히 구매관리•손익관리•인력관리•일정관리의 연계는 복잡하기 때문에 어떤 데이터를 언제 어떻게 주고받고, 데이터 변경 시 검증할 로직이 무엇인지 개발하기 전에 분석해야 한다. 사내 업무전문가들이 모여 프로세스 개선 포인트를 협의하고 예외사항들에 대한 대비도 해야 한다.
물론 프로젝트 관리시스템을 개선하는 목적과 해결방안도 검증해야 한다. 프로젝트 관리시스템을 최초에 구축하는 것은 업무자동화의 의미가 있지만 개선하는 것은 다르다. 누구의 어떤 불편을 해결하고자 하는지, 불편 해결을 위한 방안은 명확한지, 그 과정에서 새로운 불편을 만들지는 않는지 검증해야 한다. 시스템을 개선할 때 좋아하는 현업이 명확하지 않거나, 있다 해도 일부 부서의 일부 인원에 국한된다면 잘못된 문제를 풀고 있을 가능성이 높다.
복합도가 높은 프로젝트에서 ‘빨리’는 치명적이다. 처음부터 애자일 방식으로 스프린트를 적용하는 것도 위험하다. 시간을 가지고 복합적인 관계를 제대로 분석하면 재작업을 줄일 수 있고, 근본원인이 맞는지 검증할 수 있다.
실험을 통해 문제와 해결방안을 확인할 복잡한 프로젝트
프로젝트 구성하는 요소가 많고 상호관계가 역동적이면 결과를 예측하기 힘든 복잡한 프로젝트가 된다. 조직문화 개선 프로젝트가 대표적이다. 구글, 아마존, 애플과 같은 혁신기업의 프랙티스를 그대로 따라 한다고 조직문화가 혁신적으로 변경되지 않는다. 오은영 박사의 TV 프로그램을 많이 본다고 자녀를 잘 키우고, 자녀와 잘 지내는 방법을 터득하는 것도 아니다.
신상품을 개발할 때 최소한의 기능을 갖춘 MVP(minimum Viable Product)를 활용하여 고객가치를 검증하는 것은 복잡한 프로젝트를 관리하는 대표적인 방안이 다. 복잡한 프로젝트는 분석만으로 정답을 찾기 힘들기 때문에 일단 작게 해 보고 결과에서 배워야 한다. 대포를 쏘기 전에 총알로 실험하여 문제점을 발견하는 것이다.
사람의 마음을 움직여야 효과를 볼 수 있는 시스템 구축은 대부분 복잡한 프로젝트이다. 사람들이 어떻게 반응할지 사전에 예측하기 힘들기 때문이다. 이전에 예를 들었던 프로젝트 리스크 관리 시스템도 관점에 따라 복잡한 프로젝트가 될 수 있다. 리스크를 파악하기 위해서는 누군가 데이터를 제공해야 하는데 데이터 제공시기, 데이터 품질에 따라 리스크 식별의 정확도가 좌우되기 때문이다. 프로젝트 리스크 관리를 위한 핵심기능을 특정 사업부에 먼저 적용해 보고 문제점을 보완한 시스템을 본격적으로 개발하여 전사로 확산하는 것이 실패의 크기를 줄이고, 정답을 찾기에 적합한 방법론이다.
복잡도가 높은 프로젝트에서 ‘큰 규모’는 치명적일 수 있다.해보기 전에는 문제를 파악하기 힘들기 때문에 크게 시작하면 크게 실패할 가능성이 높기 때문이다.
복합적인 프로젝트인지 복잡한 프로젝트인지 구분이 힘들 때에는 복잡한 프로젝트로 간주하여 시작하는 것도 방법이다. 단, 프로젝트 업무를 쪼개어 작게 실험할 수 있어야 한다.
