주어진 예산 내에서 납기 일정을 준수했느냐로 IT프로젝트를 평가하는 경우가 종종 있다. 그렇다면, 선도적인 기업들은 어떻게 IT프로젝트를 평가할까? IT프로젝트 성공 가능성을 높여주는 '동료 평가'를 누가, 언제, 얼마나 자주, 어떻게 실시할 지 정리했다.
프로젝트의 성공은 PM이 프로젝트의 성패를 가르는 요소들을 정확히 이해하고, 필요할 때 적절한 조치를 취할 수 있는가에 달려있다. 물론 이것이 쉬운 일은 아니다. 아무리 훌륭한 PM이라 해도 처음 겪는 상황에 직면할 수 있으며, 이런 상황에서 적절한 조치를 취할 수 없게 만드는 여러 가지 장애 요인들도 등장할 수 있기 때문이다.
게다가 PM들은 보통 세부적인 것들에 몰두한 나머지 미래에 대해 지나치게 낙관적인 전망을 갖기도 한다. 따라서 프로젝트의 성공 확률을 높이기 위해서는 동료 평가(Peer Review)를 통해 프로젝트의 취약점을 파악하고 성공에 장애물이 되는 요소들을 미리 제거할 수 있어야 한다.
프로젝트 성패를 좌우하는 주요 요소들
동료 평가에 대해 설명하기에 앞서, 프로젝트의 최종 결과에 중대한 영향을 미치는 여러 가지 요소들에 대해 간단히 설명해 볼까 한다.
동료 평가 진행자 선정
동료 평가를 진행할 사람은 해당 팀 전체에서 인정받는 사람이어야 한다. 그래야만 그의 의견도 진지하게 받아들여질 것이기 때문이다. 또 간부들에게 인정받고 있어 프로젝트에 변경이 필요할 경우 간부를 설득할 수 있는 사람이면 더 좋다.
동료 평가의 목적은 ‘프로젝트 성공’에만 있다
따라서 동료 평가는 평가 참여자와 프로젝트 팀, 그리고 간부들 간의 협력이 원활해야 한다. 평가의 효과가 있으려면 우선 팀원들 스스로 해당 평가가 자신들에게 정말로 도움이 되며 프로젝트를 성공으로 이끌어 줄 것이라고 믿게 해야 한다. 반대로 동료 평가가 단순히 팀원들의 단점을 지적하고 이를 간부에게 ‘일러바치는’것 이상도 이하도 아니라는 인상을 줄 경우 팀원들은 결코 개방적인 태도를 보이지 않을 것이다.
특히 동료 평가가 단순히 질문지에 체크 몇 번 하는 것으로 끝나거나, 팀원들의 실수를 지적하는 취조 같은 양상으로 흘러가는 것을 본 적 있다. 이 경우 PM은 프로젝트 성공보다는 단순히 평가에서 책잡히지 않기 위해 애쓰게 된다. 때문에 간부들은 모든 프로젝트에는 리스크가 따르며 동료 평가의 목적은 이러한 위험 부담을 줄이기 위해 경영진이 도울 수 있는 일은 없는지 알아보는 것임을 늘 기억해야 한다.
동료 평가, 프로젝트 기간 동안 2회 이상 실시해야 한다
우선 프로젝트를 시작할 때 한 번 실시하고, 프로젝트가 새로운 국면에 접어들 때마다 재차 진행하는 것이 좋다. 여기서 핵심은, 프로젝트의 성공을 이끌어 낼 수 있는 변화를 도입하기 적절한 시점에 평가해야 한다는 것이다. 평가 시기가 빠르면 빠를수록 실수를 미연에 방지하는 데 도움이 되며 너무 늦게 동료 평가를 진행할 경우 이미 문제가 발생하기 시작한 시점에서 뒷북만 치다 끝나는 수도 있다.
특히 첫 번째 평가를 프로젝트 초반에 하는 것이 아주 중요하다. 왜냐면 많은 대규모 프로젝트들이 시작 과정에서 휘청거리는 일이 많기 때문이다. 필자가 본 프로젝트들만 해도 시작 후 몇 달이 지날 때까지 제대로 운을 떼지 못하는 것들이 여럿이었다. 매니저들이 프로젝트를 진척시킬 최선의 방법을 생각도 하기 전에 프로젝트에 누구를 포함할 지에만 지나치게 골몰하고 있었기 때문이었다. 이런 경우 프로젝트 진행은 되지 않고 예산만 계속해서 지출되는 모양새가 될 수 있다. 때문에 프로젝트 초반에 동료 평가를 실시함으로써 팀원들이 정말로 집중해야 할 것에 집중할 수 있도록 해 주는 것이 중요하다.
동료 평가 진행 방식
이제는 동료 평가를 진행하는 방식 전반을 살펴볼 차례다. 동료 평가는 얼핏 보기엔 단순하고 간단한 작업 같지만, 사실 그 양상은 프로젝트의 규모나 중요도에 따라 달라질 수 있다.
반드시 필요하고 중요한 프로젝트의 경우 실패에 들어가는 비용이 시간 소모를 정당화 해 주기 때문에 프로세스를 철저하게 따르게 된다. 물론 정식으로 동료 평가를 해야 하는지 여부를 결정할 때 단순히 프로젝트의 금액 규모를 기준으로 하면 결정이야 쉬워 지겠지만(예를 들어 예산 100만 달러 규모 이상의 프로젝트는 동료 평가를 한다는 식으로), 가장 좋은 결정 방식은 경영진이 직접 프로젝트 포트폴리오를 검토하고 동료 평가를 해야 할 프로젝트와 안 해도 될 프로젝트를 결정하는 것이다.
반면 중요도 측면에서 떨어지는 프로젝트들의 경우 동료 평가를 하긴 하되 경영진의 개입까지는 필요하지 않다. 전체 프로젝트 팀을 모아 IT프로젝트들이 빠지기 쉬운 함정이나 실수하기 쉬운 부분들에서 현재 프로젝트가 어떻게 진행되고 있는지 의논하도록 하는 것이다. 다음에 열거된 질문들을 활용하면 매우 효율적인 논의가 가능하리라 믿는다.
프로젝트 팀 설문조사를 실시하라
동료 평가의 첫 단계는 프로젝트 팀의 생각을 묻는 것이다. 가장 쉬운 방법은 각 팀원들에게 설문지를 나눠주고 작성토록 하는 것이다. 프로젝트를 실패로 이끄는 문제들에 관련된 질문을 물어봐야 함은 물론이다.
다음은 필자가 직접 개발한 설문지다. 각각 5점 만점 기준으로 점수를 매길 수 있는 11가지 질문으로 구성돼 있으며 마지막에는 각자의 의견을 자유롭게 개진할 수 있는 주관식 질문이 추가돼 있다. 답하고 분석하는 데 오랜 시간이 걸리지 않으므로 전체 평가에서 크게 시간을 소모하지 않는 단계다. 필자가 개발한 설문지는 다음과 같다.
1. 프로젝트 요구 사항을 제대로 숙지하고 있는가?
2. 프로젝트의 범위가 안정적이라고 생각하는가?
3. 이 프로젝트에 경영진이 충분히 지원하고 있다고 생각하는가?
4. 비즈니스와 IT측면에서 프로젝트에 적합한 인력과 자원이 투입되고 있다고 생각하는가?
5. 이 프로젝트의 팀원들이 프로젝트 성공에 필요한 기술력을 갖추고 있다고 생각하는가?
6. 새로운 기술을 사용하는 프로젝트의 경우, 해당 기술을 제대로 이해하고 활용하고 있는가?
7. 프로젝트 진행 상황을 파악하기 위한 분명한 기준을 활용하고 있는가?
8. 프로젝트 마감 시한 목표가 현실적으로 설정 되었는가?
9. 프로젝트의 결과물과 이정표에 대한 공과가 분명히 정해져 있는가?
10. 프로젝트 팀원들간에 의욕적이고 협조적인 분위기가 형성되어 있는가?
11. 비즈니스 사례의 양적 분석에 기반해 봤을 때 적절한 프로젝트라 생각하는가?
12. 현재 프로젝트에서 바뀌었으면 하는 부분이 있다면 무엇이고 그 이유는 무엇인가?
설문 결과 분석하기
동료 평가의 두 번째 단계는 설문조사 결과를 분석하는 일이다. 설문 분석 작업이란 대부분 단순히 수치를 분석해 두드러지는 부분을 포착하는데 목적을 두지만, 시각을 달리하면 여기에서 다른 결과도 충분히 이끌어낼 수 있다. 예를 들어, 정확한 분석을 위해선 현업의 응답자와 IT부문의 응답자가 프로젝트를 바라보는 시각이 어떻게 다른지, 임원과 평사원들의 시각에는 어떤 차이가 있는지, 조직 성격에 따른 입장 차이는 없는지, 프로그래머가 애널리스트들과 생각을 달리하는 부분은 어디인지 등의 여부를 따져봐야 하는 것이다.
위의 11가지 질문은 프로젝트 팀이 프로젝트를 바라보는 시각을 잘 보여주는 것들이며, 실제로 가장 효율적으로 프로젝트를 진행시킬 수 있는 질문들이다. 지금껏 필자가 경험하거나 직접 시행해온 많은 동료 평가들에서 이 질문과 답변들은 언제나 최종 보고서에서 가장 중요한 요소로 활용됐다.
프로젝트 팀 인터뷰 시행
프로젝트 팀의 시각을 이해했다면, 다음 단계는 인터뷰를 통해 보다 심도 있는 정보를 획득하는 것이다. 인터뷰는 모든 직급의 직원들을 대상으로 진행돼야 하며, 프로젝트의 건전성에 대한 팀 구성원들의 생각을 수집하는데 초점을 맞춰야 한다.
개방형 질문 방식으로 인터뷰를 진행하는 경우엔 답변에서 이야기된 주제들을 정확히 정리하는데 특히 신경을 써야 함을 기억하자. 덧붙여 설문지 결과에서 부족한 점이나 모순점이 확인된 경우에는 인터뷰 과정에서 그 부분을 짚고 넘어가야 할 것이다. 예를 들어 애널리스트들이 전달한 요구 사항에 프로그래머들은 불충분하다는 입장을 보일 경우, 그러한 시각의 불일치를 애널리스트와 프로그래머 두 집단 모두에게 이야기해 간극을 없애는 것이 평가 진행자의 역할이다.
조사 결과를 문서화 하고 결론을 이끌어 낸다
인터뷰를 마치고 나면 그 결과를 문서로 작성해 거기서 잠정적인 결론을 내린다. 이후 PM과 함께 다시 한 번 결과를 확인한다. 평가 진행자와 매니저의 의견이 다를 경우 이 의견 차를 좁히기 위해 노력해야 한다. 예를 들어 두 사람의 논의에 일부 팀 멤버들을 포함시켜 의견 차를 해소하는 것도 하나의 방법이다.
둘 사이에 의견이 합치하는 것이 PM 에게도, 평가 진행자에게도 좋은 일이다. 두 사람이 한 목소리를 내는 것이 간부의 도움을 받기에도 훨씬 유리하기 때문이다. 합의가 이루어지면, 최종 보고서에 들어갈 핵심 내용을 무엇으로 할 지 대략 정리한다.
최종 보고서를 작성하고 결과물을 상급 관리자에게 보고하라
동료 평가의 마지막은 결과를 보고서로 작성해 상급 관리자에게 제출하는 단계다. 보고서 제출의 목적은 프로젝트의 잠재적 위험 요인을 임원과 공유해 추후 오해의 여지를 줄이고 그들의 지원을 확보하는데 있다. 보고는 PM과 평가 진행자가 함께 서로의 생각을 이야기하며 각자가 필요로 하는 지원 내용을 명확히 설명하는 방식으로 진행되는 것이 좋다.
다시 한 번 강조하자면, 보고 단계에서 상급 관리자의 역할은 프로젝트 팀의 차선적 결과물을 꾸짖는 것이 아닌, 그들을 앞으로 나아가게 할 지원을 제공하는 것이다. 이는 프로젝트 팀에게 ‘오류를 바로잡을’ 기회다. 이 재검토의 시간이 없다면, 동료 평가에서 공유된 문제점은 결코 해결될 수 없을 것이다. 간부가 엄격한 태도를 취해야 하는 시점은 문제가 표면적으로 드러난 이후며 간부가 문제 해결을 위해 도움을 주었음에도 불구하고 여전히 문제가 해결되지 않았을 때다.
정리하며
처음 동료 평가를 받았을 때가 기억난다. 당시 필자는 컨설팅 회사에서 일하고 있었다. 당시 평가 진행자는 필자가 한 번도 동료 평가를 받아본 적 없음을 알고 있었고 필자와 의견을 나누고자 하는 의사를 밝혀 왔다.
그에 따르면, 프로젝트 때문에 계약한 외부 협력사들은 문제가 생길 경우 이를 감추기 보다는 오히려 최대한 많은 사람에게 이야기해야 한다고 했다. 그렇게 해야 문제를 공론화 시키기 쉬워지기 때문이다. 그는 자신의 일은 필자가 프로젝트 진행 상황을 평가하는 것을 돕는 일이며 필자를 도와 프로젝트를 성공으로 이끄는 일이라고 말했다. 이런 마음 가짐으로 동료 평가를 진행한다면 그 평가는 분명 프로젝트의 성공에 크게 공헌하는 자료가 될 것이다.
*Bob Ronan은 문제 있는 조직이나 현재 잘 하고 있는 조직이 다음 단계로 성공적으로 나아가도록 도우며 컨설팅 경력을 쌓은 IT전문가다. dl-ciokorea@foundryco.com
