로그인|회원가입|고객센터
Top
검색버튼 메뉴버튼

경험의 덫

DBR | 3호 (2008년 2월 Issue 2)
키쇼어 센굽타·타렉 K. 압델-하미드·루크 N. 반 바센호브
 
당신이 소프트웨어 개발팀을 이끌 노련한 매니저를 찾고 있고, 당신이 알고 있는 매니저 중 가장 우수한 ‘알렉스’라는 수석 매니저가 후보로 떠 올랐다고 가정해 보다. 알렉스는 소프트웨어 개발 프로젝트에서 대부분의 경력을 쌓았다. 그가 처음으로 책임졌던 프로젝트는 NASA의 과학 소프트웨어를 개발하는 것이었고, 그 이후로 일반 기업과 정부 기관의 수많은 프로젝트를 감독한 경험이 있다.
 
알렉스는 우리가 실시한 ‘복잡한 프로젝트 환경에서의 경험 기반 학습(ex-perience-based learning)에 대한 연구’에 참여했던 수백 명의 프로젝트 매니저 중 하나다. 그는 컴퓨터 모의 게임을 통해 소프트웨어 개발 프로젝트를 관리하는 능력을 테스트 받았다. 모의 게임은 프로젝트의 계획 수립, 진행상황 모니터링 및 방향설정, 결과 평가 등 프로젝트의 처음부터 끝까지를 관리하는 방식으로 이뤄졌다. 정해진 시간 까지, 예산 범위 안에서 최고 품질의 소프트웨어를 개발하는 것이 그의 목표였다.(품질은 소프트웨어의 결점을 점수화하는 방식으로 측정됐다.)
 
게임에서 알렉스의 의사결정과 그 결과물은 팀 전체를 대표했다. 처음에 그는 4명의 엔지니어로 구성된 소규모 팀을 꾸려 개발 업무에 집중했다. 이 전략은 단기적으로 효과가 컸다. 개발 속도가 빠르고, 생산성도 높았다. 하지만 당초 예상보다 프로젝트 규모가 커지면서 문제가 발생했다. 팀원은 적은데 처리할 일은 계속 늘면서 팀원에게 업무가 과중됐다. 팀원들은 실수를 연발했고, 극도로 피로에 지쳐갔다. 알렉스는 팀원을 더 뽑으려고 했지만 시간이 걸렸다. 새 팀원들이 기존 팀원들과 동화되는 데도 역시 시간이 필요했다. 결국 프로젝트는 원래 일정보다 많이 늦어졌고, 소프트웨어의 결점도 눈덩이처럼 불어났다. 프로젝트 진행 도중 이러한 문제점을 수정하느라 또 많은 시간과 노력이 필요했다. 결과적으로 프로젝트는 예상보다 늦게 완료됐고, 예산을 초과했을 뿐 아니라 결점투성이였다.
 
게임이 끝난 뒤 우리는 알렉스에게 모의 프로젝트에 대해 몇 가지 질문을 던졌다. 프로젝트의 확장이나 소프트웨어의 수많은 결점, 고용 관리의 어려움 등이 예상치 못한 상황이었는지 물었다. 하지만 그는 대부분의 참여자들과 마찬가지로 이런 상황이 그가 과거 참여했던 프로젝트에서 자주 발생했던 일이라고 대답했다.
 
대부분 기업들은 알렉스와 같은 베테랑을 중요한 프로젝트의 매니저로 고용하면 품질이나 직원 관련 문제가 발생하지 않을 것이라고 기대한다. 베테랑은 문제를 효율적으로 해결하는 방법을 안다고 가정하기 때문이다. 하지만 우리는 실험을 통해 경험이 풍부한 매니저들이 꼭 좋은 성과를 거두는 것은 아니라는 사실을 발견했다. 시뮬레이션 결과에 따르면 게임을 하는 동안 알렉스와 같은 프로젝트 매니저들이 ‘경험으로부터 배우는 방식’에 문제가 있었다. 그들은 새로운 결정을 내리는데 있어 이전의 의사결정이 어떤 결과를 낳았는지 전혀 고려하지 않았다. 과거 결정으로 인해 성과가 나빴어도 기존 접근 방식을 바꾸지 않았다.
 
모의 게임에서 프로젝트 매니저들이 마주친 문제들은 참가자들에게 매우 익숙한 것이었다. 시뮬레이션 참가자들에게 모의 게임과 현실의 유사 정도를 5점 만점 척도로 평가하도록 했을 때 평균 4.32점이 나올 정도로 시뮬레이션 게임은 소프트웨어 프로젝트 현실을 잘 반영했다. 매니저들은 게임 도중 과거에 실제로 경험한 유사한 상황에 처했지만 과거 경험을 활용하지 못하고 여전히 고전했다. 우리는 프로젝트 매니저들이 실제 프로젝트에서도 경험을 통한 학습이 전혀 이뤄지지 않았다는 결론에 이르렀다.
 
이 논문에서는 경험을 통한 학습을 방해하는 3가지 원인과 이에 대한 대책을 살펴보도록 할 것이다.
 
학습 장애가 발생하는 원인
사람들은 결정을 내릴 때 이전의 경험을 바탕으로 한 지식의 축적, 즉 ‘사고 모델(思考·mental model)’을 참고한다. 사고 모델은 인과관계를 기본 전제로 한다. 사람들은 자신의 의사결정으로 발생하는 결과를 보면서, 새로운 사실을 배우고 주변의 관계들에 대해 새로운 발견을 한다. 이런 발견들이 다른 상황에도 적용될 수 있다고 일반화하면서 사고 모델로 반영된다. 이러한 과정은 대단히 과학적으로 보인다. 어떤 원인과 결과에 대한 가정을 만들고, 이에 따라 행동하고, 결과를 해석해 그 가정을 확인하거나 수정하는 일련의 과정은 꽤 과학적으로 비춰진다.
 
하지만 이러한 방식은 단순한 환경에서만 효과적이라는 데 문제가 있다. 단순한 환경에서는 인과관계가 명확하며, 쉽게 발견된다. 반면 소프트웨어 개발 프로젝트와 같이 복잡한 환경에서는 이러한 학습 사이클이 효과가 없다. 우리는 시뮬레이션 게임 실험을 통해 학습 사이클을 방해하는 3가지 유형의 장애요인을 발견했다.
 
원인과 결과 사이의 시간차(time-lags) 현실에서는 원인이 결과가 되어 나타나기까지 시간이 걸리기 때문에 그 관계를 명확하게 연결하기 어려운 경우가 많다. 우리는 프로젝트 매니저들이 이러한 문제에 대처하는 방법을 살펴보기 위해 중간 규모의 인공위성 소프트웨어 개발 프로젝트를 관리하는 시뮬레이션 게임에 참여하도록 했다. 그리고는 점점 요구사항이 많아져서 프로젝트 규모가 갑자기 커지는 상황을 설정했다.
   
매니저들은 우리가 설정한 4가지 환경 가운데 1가지 상황에서 프로젝트를 관리해야 했다. 직원을 고용한 시점과 그 직원이 팀에 합류한 시점 사이의 시간차(고용 시간차), 직원이 팀에 합류한 시점과 팀에 적응하는 시점 사이의 시간차(적응 시간차)에 변화를 줬다. 매니저들은 프로젝트를 완성하는 약 18개월 동안 2달에 한 번씩 팀의 고용 수준에 대해 의사결정을 내려야 했다. 우리는 고용 시간차를 다루는 매니저들의 의사결정 능력을 평가했다. 시간차를 고려해본 적이 없고 이론적으로도 부족한 매니저가 내린 고용 결정과 시간차를 항상 고려하는 것은 물론 이론적으로도 완벽한 매니저가 내린 고용 결정을 비교했다.
 
프로젝트마다 새 팀원을 고용하는 데 걸리는 시간과 새 팀원이 팀에 적응하는 데 걸리는 시간을 다르게 했지만 모든 매니저들은 경험이 부족한 매니저와 거의 비슷한 결정을 내렸다. 이는 매니저들이 프로젝트 계획을 수립할 때 시간차가 미치는 영향을 전혀 고려하지 못하고 있음을 나타낸다. 또한 원인과 결과에 시간차가 없는 단순환 환경을 기반으로 매니저들이 사고 모델을 적용한다는 사실을 보여준다.
 
게임에서 시간차의 길이는 중요한 변수로 작용했다. 고용 시간차와 적응 시간차가 긴 환경에 처한 매니저는 시간차가 짧은 환경의 매니저보다 문제 해결에 어려움을 더 겪었다. 또 시간차가 어디에서 발생하는지도 중요했다. 참가자들은 고용 시간차보다 적응 시간차가 길어질 때 문제 해결에 더 어려움을 겪었다. 고용 과정과 적응 과정이 모두 지체되는 상황에서 매니저들의 문제 대처 능력은 급격하게 떨어졌다. 두 과정이 모두 지체되는 상황에서는 프로젝트를 완료하는 데 노력이 83% 이상 더 필요했고, 시간도 40% 이상 더 걸렸다.
 
흥미롭게도 많은 매니저들이 시뮬레이션 게임에서 뒤늦게 더 많은 팀원을 고용했다. 이는 매니저가 그런 상황에서 어떻게 해야 했는지에 대한 그들의 답변과 반대였다. 게임 실행 후 우리는 참가자들에게 프로젝트 진행이 지연되는 상황에서 적합한 고용 정책이 무엇인지 물었다. 숙련된 매니저들 대부분이 프로젝트 진행이 지체되는 경우 직원 고용은 되도록 삼가고, 프로젝트의 기본 틀을 재구성하거나, 몇 가지 핵심적인 업무에 집중하거나, 완성 기한을 연장하는 등 다른 옵션을 찾는다고 진술했다. 그러나 이들은 실제로 자신들이 언급한 주의사항을 지키지 못했다. 첫 번째 시뮬레이션 게임을 마치고, 검토 시간을 가진 뒤 두 번째 게임에 참여해도 매니저들의 행동에는 변화가 없었다. 프로젝트 과정이 지체되면 여전히 프로젝트 후반기에 더 많은 직원을 고용했다. 이러한 결과를 살펴보면 사람들이 지식을 습득하더라도 그에 대처하는 방법을 반드시 학습하는 것은 아니라는 사실을 알 수 있다.
 
정확하지 않은 평가 소프트웨어를 개발할 때 매니저는 프로젝트에 대한 초기 예측평가를 바탕으로 프로젝트 전반에 관한 계획을 세운다. 예를 들어 팀 구성원들의 생산성에 대한 평가는 팀 규모를 결정하는 데 영향을 미치고, 이는 결과적으로 실제 팀의 산출물에 영향을 준다. 여기서 문제는 초기의 평가가 대체로 정확하지 않다는 것이다.
 
우리는 매니저들이 정확하지 않은 평가에 대처하는 법을 살펴보기 위해 또 다른 실험을 수행했다. 프로젝트팀의 생산성 초기 평가가 주어진 상황에서 매니저들이 프로젝트 진행에 따라 주기적으로 팀의 실제 생산성을 측정하도록 하는 ‘의사결정 사이클’을 실험했다.
 
우리는 매니저들에게 팀의 생산성 초기 평가를 1인당 하루 업무 수행 능력을 기준으로 각각 다르게 제시했다. 하나는 높게, 하나는 중간, 하나는 낮게 제시했는데, 이는 한 프로젝트를 두고 측정방식을 달리했을 때 편차를 반영한 것이다. 또 각각의 경우에 매니저들이 △기획 마지막 단계(5개월째) △프로그램 코딩화 중간단계(10개월째) △코딩화 마지막 단계(15개월째) 등 세 차례에 걸쳐 프로젝트팀의 생산성을 새롭게 측정해 보고하도록 했다. 각 단계마다 매니저들은 프로젝트 진행 상황과 함께 프로젝트팀의 새로운 생산성을 보고 받았고, 매니저들이 이 보고를 토대로 팀의 생산성을 수정하도록 권고 받았다.
 
우리는 매니저들의 팀 생산성 평가가 직원 고용 수준과 프로젝트 진행 일정을 수정하는 데 사용될 것이라고 공지했다. 그러나 실제 시뮬레이션 게임은 이들의 평가를 반영하지 않았다. 이 같은 실험 아이디어는 동일한 상황을 제시한 뒤 시간이 경과함에 따라 이들의 평가가 어떻게 변화하는지 비교하기 위한 것이었다. 우리는 참가자들의 팀 생산성 평가가 하나의 결과로 수렴될 것이라는 가설을 세웠다. 시간이 경과함에 따라 팀 생산성 초기 평가를 낮게 제시받은 매니저는 팀 생산성을 더 높게 평가할 것이고, 초기 평가를 높게 제시받은 매니저는 팀 생산성을 낮게 평가할 것이라는 가정이었다.
 
실험 결과 매니저들의 팀 생산성 평가는 수렴되지 않았다. 게다가 명백히 보수적인 성향을 보였다. 모든 생산성 평가가 낮아지는 성향을 보인 것이다. 초기 생산성을 높게 보고 받은 매니저뿐 아니라 낮게 보고 받은 매니저조차 생산성 평가가 낮아지는 쪽으로 보고 했다. 매니저들은 기존 평가와 새로 보고 받은 평가 중에 더 낮은 평가를 바탕으로 팀 생산성을 수정 평가했다. 이런 보수적인 태도는 매니저들이 더 많은 자원을 확보하려 했기 때문이라고 추측된다.
    
초기 목표에 집착하는 성향 프로젝트 매니저들은 항상 비용과 시간, 기타 요소 등과 관련된 목표를 설정하고 프로젝트를 시작한다. 하지만 대부분 프로젝트 진행 과정 도중 목표의 범위가 바뀌거나 예상치 못한 일을 겪게 돼 초기 목표와는 동떨어진 방향으로 프로젝트가 흘러가는 일을 겪는다. 이러한 일이 발생하게 될 경우 매니저들은 상황에 맞게 목표를 수정할 필요가 있다.
 
우리는 매니저들이 변화에 맞게 목표를 수정하는지 알아보기 위해 두 집단을 대상으로 요구 조건이 점점 늘어나는 프로젝트를 관리하도록 했다. 두 집단에 각각 초기 목표가 주어졌다. ‘비용 집단’은 정해진 예산 내에서 일정대로 프로젝트를 완료하라는 목표를 받았다 ‘품질 집단’은 기한 내에 결점이 최소화된 결과를 산출하라는 목표를 받았다. 이러한 목표는 초기 목표일뿐이고, 매니저들에 대한 평가는 전반적인 결과를 바탕으로 이뤄질 것이라고 명확히 공지했다. 게임이 4분의 1 진행됐을 때 요구 조건은 늘어났다. 이때 매니저들은 예산과 일정을 검토해 초기 목표를 수정할 수도 있었다. 참가자들에게 목표를 재검토하라는 공지를 하지는 않았지만 가능성은 충분히 열어두었다.
 
하지만 어느 누구도 새로운 정보를 반영해 목표를 수정하지 않았다. 대신 두 집단의 참가자 모두 기존의 목표를 고수하면서 최적의 결과를 달성하는 데 실패했다. 비용 집단은 초기 목표에 맞춰 비용을 줄이기 위해 이상적인 고용인원보다 적은 수의 직원을 고용했으며, 일정을 지키지 못했다. 비용을 59% 수준으로 낮추는 대신 시간이 17% 더 들었고, 1950가지 결점이 발생했다. 반면 품질 집단은 너무 많은 직원을 고용했다. 결점 목표는 달성했지만 9%의 시간이 더 들었고, 예산은 107%가 더 들었다. 초기 목표에만 몰두하면서 역효과가 발생한 것이다. 예산에 집착한 비용 집단은 비용은 조금 줄였지만 산출물 품질에는 전혀 신경을 쓰지 않았다. 결국 결점이 수없이 발생했고, 이를 수정하는 데 실질적으로 예산을 초과하는 비용이 사용됐다.
 
이런 결과를 통해 매니저들은 목표를 재검토하라는 명확한 지시가 없으면 목표가 부적절하더라도 초기 목표에 계속 매달린다는 것을 알 수 있다. 외형적으로 설정된 목표를 정확히 지키는 것이 중요하다는 사고 모델이 경력 초기부터 정립됐기 때문이다. 이러한 성향은 관리자가 되면서 더 강화된다.
 
일반적으로 많은 회사에서 목표를 수정하는 것은 실패를 인정하는 것으로 비춰진다. 따라서 매니저들은 전반적으로 더 나쁜 결과를 얻게 되더라도 초기의 목표에 매달려 이를 달성하는 것이 경력을 쌓는 데 더 낫다고 판단하는 것이다.
 
실험 결과, 매니저들은 단순한 환경에서 경험을 바탕으로 발달된 사고모델을 뛰어넘기가 어렵다는 사실을 알 수 있었다. 이들은 상황이 복잡해지면 상황을 무시하거나 단순한 상황에만 적용되는 규칙을 활용하려 했다. 매니저들은 복잡한 프로젝트의 현실을 감안할 수 있도록 자신의 사고 모델을 개선하려는 노력을 하지 않았다. 이러한 결과는 직무 기반 학습을 끊임없이 강조하는 기업에게 다음의 2가지 함의를 보여준다.
 
첫째, 알렉스와 같은 베테랑 매니저의 경험이 복잡한 프로젝트를 운영하는 능력을 보장하지 않는다는 점이다. 많은 기업들이 베테랑 매니저 한 명을 교체해도 별 효과가 없는 상황을 자주 경험하게 된다. 복잡한 프로젝트를 수행한 경험이 있더라도 매니저들은 단순한 상황에 맞춰 이미 형성된 사고 모델을 쉽게 바꾸려 하지 않는다. 어떤 경우에는 기업이 경험 없는 매니저를 고용하는 게 더 나을 수도 있다.
 
하지만 이는 매니저에 따라 차이가 없다거나, 매니저가 프로젝트 성과를 개선하지 못한다거나, 또는 일관되게 프로젝트를 성공적으로 운영하지 못한다는 의미가 아니다. 중요한 것은 대부분의 매니저들이 나무랄 데 없는 이력을 갖고 있더라도 일관되게 좋은 성과를 내고, 프로젝트 성과를 개선하는 데 실패할 수 있다는 점이다. 매니저가 꾸준하게 성과를 개선하는 경우라 하더라도, 그것은 복잡한 프로젝트를 통해 체계적이고 점진적으로 학습한 결과이기보다는 약간 다른 과거 경험의 결과일 수 있다.
 
두 번째는 첫 번째 함의로부터 도출된 것이다. 누가 책임자인지 명확히 하지 않는다면, 매니저는 실패에 대한 책임을 본인의 결정 탓이 아니라 지나친 계획이나 재무적 문제 등 다른 요인 탓으로 돌릴 것이다. 이런 생각을 갖게 되면 매니저는 문제의 해결책을 잘못된 곳에서 찾으려고 하게 되고, 결국 실패라는 재앙을 초래하게 된다.
 
경험 학습 사이클 수정하는 방법
이번 연구에서 복잡한 프로젝트에서는 대부분 매니저들의 경험 학습 사이클이 무너진다는 결과가 나왔지만 이는 개선될 수 있다. 우리는 경험 학습 사이클의 결함을 받아들이고, 매니저들이 다른 유형의 학습법을 통해서도 일할 수 있도록 아래의 사항들을 추천할 것이다. 또 사이클의 결함을 줄이는 방법도 추천할 것이다. 기업들이 다음과 같은 권고를 받아들이면 프로젝트 운영 성과를 지속적으로 개선하는 능력을 찾을 수 있을 것이다. 

     
인지적 피드백(cognitive feedback)을 더 많이 제공하라 프로젝트 환경에는 정보가 풍부하다. 특히 현황 보고서를 통해 전달되는 성과에 대한 피드백 자료가 풍부하다. 그러나 인과관계가 불분명한 환경에서는 성과 피드백(outcome feedback)이 특정 문제를 규명하는 데 효과적인 메커니즘이 아니다. 매니저들이 필요로 하는 피드백은 프로젝트 환경에서 중요한 변수들 간의 관계에 대해 통찰력을 주는 ‘인지적 피드백(cognitive feedback)’이다.
 
예를 들어, “복잡한 프로젝트의 인지적 피드백”이라는 도표를 보자. 이 도표는 프로젝트 초기 80일 동안에 품질이 보장되는 수준과 결함이 발견되는 비율 간의 관계를 보여주고 있다. 매니저들은 품질 보장 수준이 상대적으로 낮은 단계에서 프로젝트를 시작해 시간이 지나면서 품질 수준을 높여간다. 약간의 시간차가 있긴 하지만 결함이 발견될 확률도 따라서 높아진다. 결함 발생 비율이 낮아진다는 것은 대부분의 결함이 이미 발견됐다는 것을 의미하며, 이럴 경우 매니저들은 품질 보장 수준을 일정하게 유지하거나 낮출 수 있게 된다. 이러한 피드백 과정에서도 실수가 발생할 수 있기 때문에 매니저들은 이를 방지하기 위한 노력을 하게 되고, 그 과정에서 요소들 간의 복잡한 관계에 대해 학습을 하게 된다. 우리의 연구 결과에 따르면 인지적 피드백을 받은 매니저들이 환경에 대해 보다 깊이 이해하고, 더 나은 성과를 올리는 결정을 내렸다. 우리는 기업들이 인지적 피드백이 프로젝트 현황 보고서에 포함될 수 있도록 투자하라고 권고한다. 인지적 피드백은 다른 프로젝트의 데이터와 결합되면 더 효과적이기 때문에 여러 복합적인 프로젝트에 대한 영향력을 검증해볼 수 있다.
 
모델 기반(model-based) 의사 결정 도구와 지침을 적용하라 우리의 연구 결과에서 꾸준히 강조되는 점은 매니저들이 소프트웨어 프로젝트를 진행하면서 부닥치는 다양한 상황에 대해 적절한 의사결정을 내리지 못한다는 것이다. 의사 결정 문제에 직면한 매니저는 공식적인 모델과 발견적 방법(heuristics)을 결합한 도구의 도움이 필요하다. 예를 들어, 직원을 여러 명 고용하는 경우 고용이 지체되고, 직원이 팀에 적응하는 기간이 지연되는 문제가 발생할 수 있다. 이러한 문제가 계속되는 경우 매니저는 팀의 현재 생산성을 평가하고, 미래 생산성을 예측하는 데 어려움을 겪게 된다. 그러나 매니저가 새로운 직원의 효과와 오랜 기간에 걸쳐 축적된 직원 교체의 효과를 측정할 수 있는 도구의 도움을 받으면 장기적으로 팀 생산성에 대해 보다 정확한 평가를 할 수 있을 것이다. 더불어 이러한 도구는 문제 있는 프로젝트를 잡아내는 올가미가 될 수도 있고, 개발 작업과 품질 보증 수준 사이에서 적당한 균형을 잡아주는 규칙이 될 수도 있다. 연구 결과에 따르면 이러한 도구는 의사 결정을 개선하고, 새로운 매니저가 업무에 더 빨리 적응할 수 있도록 도와준다.
 
평가 도구를 프로젝트에 맞게 조정하라 기업들이 프로젝트를 평가하기 위해 사용하는 도구는 프로젝트의 특별한 목적(해당 산업, 환경, 직원의 능력)에 맞게 조정되어야 한다. 그러나 많은 기업들이 다른 기업이나 환경에 적용되는 프로젝트 운영 평가 도구를 아무 조정 없이 단순하게 도입하고 있다.
 
우리가 연구한 한 소프트웨어 기업은 항공 기업으로부터 평가 도구를 도입했다. 그 결과 이 평가 도구를 통해 얻은 평가치는 신뢰도가 낮아 사용할 수 없었다. 이와 같이 평가의 신뢰도가 떨어지면 매니저들은 자신의 직감에 의존하게 되고, 또 그들이 단순한 상황을 위해 개발한 규칙들을 복잡한 상황에 적용하게 된다. 이러한 상황을 피하려면 기업은 평가 모델을 자사의 프로젝트에 맞게 조정하고 다른 기업이 가설을 세우고 관계를 평가하는 데 사용한 데이터를 모두 삭제해야 한다. 또한 매니저들도 평가 결과를 향상시킬 수 있도록 자사의 데이터를 더 많이 수집하고 조정해야 한다. 성공한 프로젝트 매니저의 우수 사례를 단순하게 벤치마킹하는 것이 위험한 분야가 바로 평가 도구다.
 
주요 반도체 생산업체의 연구개발(R&D)센터는 평가의 오류를 줄이는 방법을 개발했다. R&D센터는 프로젝트를 끝낼 때마다 3단계 프로세스에 따라 결과를 표준화했다. 3단계는 일반적이지 않은 현상을 먼저 찾아내고, 그것이 미친 효과를 측정하고, 최종 결과에서 그 효과를 빼내는 방식이다. 특별한 현상의 영향을 제거한 평가가 새로운 평가 모델이 되는 것이다.
 
성과 목표가 아닌 행동 목표를 정하라평가 도구가 갖는 또 다른 약점은 평가가 보통 산출물의 규모에 따라 결정된다는 점이다. 산출물의 규모는 계획 단계에서 평가하기가 상당히 힘들뿐 아니라 프로젝트 진행에 따라 바뀌기 쉬워 정확하게 평가하기도 어렵다. 또 초기 예측 평가로 적합한 목표를 설정할 수도 없다. 초기 평가는 제대로 된 목표를 만들지 못한다. 실제로, 초기 평가를 잘못 이용할 경우에는 비용과 품질의 트레이드-오프와 같은 부적절한 반응을 촉진할 것이며, 결국 결과도 좋지 못할 것이다.
 
평가는 계획과 통제를 위한 도구로 사용될 때, 그리고 목표는 바람직한 행동을 촉진하기 위한 메커니즘으로 사용될 때, 최선의 도구로 활용될 수 있다는 점을 기업들은 알아야 한다. 우리는 기업들로 하여금 목표를 설정할 때 다음과 같은 2단계 과정을 거칠 것을 제안한다. 먼저 기업은 그들이 이끌어내고 싶은 행동을 결정해야 한다. 그러고 나서 기업이 원하는 행동을 이끌어낼 수 있는 목표를 설정해야 한다. 하나의 프로젝트를 진행할 때, 기업은 매니저가 프로젝트팀의 이직률을 최소화하길 원한다.(그렇게 함으로써 생산을 높이고 결점을 줄일 수 있다고 본다) 이러한 요구 사항은 명백한 목표의 중요한 일부분이 될 수 있다. 매니저는 이 목표를 달성하기 위해 팀 구성원들이 업무 일정으로 인한 압박이나 인원 감축에 따른 충격을 덜 받는 방안을 강구해 낼 것이다.
   
매니저가 다수의 프로젝트를 책임질 때는 목표가 개인의 프로젝트보다 포트폴리오의 성과를 최대화하는 행동을 이끌어내도록 설정해야 한다. 목표를 설정할 때 기업은 매니저들에게 일정한 수준의 재량권을 부여해야 하며, 또한 매니저들의 기여도를 높이기 위해 목표 설정 과정에 매니저들이 참여하도록 해야 한다.
 
프로젝트 시뮬레이션을 개발하라 실제 프로젝트가 좋은 학습 환경을 제공하지 못하는 것은 틀림없다. 하지만 복잡한 환경이 학습 의도를 압도하지 않도록 환경을 조성하는 것은 가능하다. 항공 산업의 비행 시뮬레이션을 예로 들어보자. 비행기 기종에 따라 비행기를 다루는 기술은 독특하다. 파일럿은 기종을 바꿀 때마다 강도 높은 훈련을 받아야 한다. 예를 들어 보잉 747 화물기 기종에서 여객기 기종으로 바꿀 때조차도 훈련이 필요하다. 비행 시뮬레이션은 훈련 과정에서 필수적인 요소다. 비행 시뮬레이션과 같은 프로젝트 시뮬레이션은 가상 세계에서 직원들을 교육, 훈련하는 데 활용될 수 있다. 프로젝트 매니저의 이직률이 예전보다 높아지면서 프로젝트 시뮬레이션의 필요성은 더 강조되고 있다. 특정 상황 또는 특정 기업에 필요한 지식이 있기 때문에 매니저들은 이직을 하거나 업무를 바꿀 때마다 새로운 환경에서 생산성과 품질을 이끌어내는 요소들의 관계에 대해 학습해야 한다. 우리는 매니저 교육 프로그램을 단순한 환경에서 시작해, 단계가 진행될수록 요소가 복잡해지고 피드백의 신뢰가 떨어지는 복잡한 환경으로 발전시키는 방식으로 운영할 것을 권한다. 또 훈련이 진행됨에 따라 고용 의사결정과 품질 보증의 관계와 같이 매니저들이 이해하기 가장 어려운 동적 관계들(dynamic relationships)에 대해 더욱 집중해야 한다.
 
우리가 지적한 학습 사이클의 문제가 학습 과정에서 발생하는 유일한 문제는 아니다. 또한 우리의 권고가 모든 문제를 해결할 것이라고 확신하지 않는다. 다만 우리는 연구 결과를 통해 업무에 대한 학습이 간단히 이뤄지는 것이 아니라는 사실을 밝혀냈다. 매니저들은 일정한 형태의 교육과 그들이 직면할 도전에 대해 적절한 의사 결정 지원 시스템이 뒷받침될 때 학습을 계속할 수 있다는 점을 밝혀냈다. 기업들은 일반적으로 신입 사원 교육에 대부분의 직원 교육비를 사용하고, 다른 기업의 프로젝트 계획 도구를 단순히 도입해 사용한다. 또 경력 직원들은 바로 업무에 착수해 좋은 성과를 거둘 것이라고 기대한다. 이런 기대 때문에 많은 숙련된 매니저들이 새로운 업무를 책임지는 데 실패하고 있는 것이다. 기업은 젊은 직원들이 스스로의 힘으로 업무를 수행할 수 있도록 해야 한다. 대신 젊은 직원에게 쏟던 훈련비용을 기업의 시니어 직원들에게 투자해 그들이 이직을 고려하는 것을 막아야 할 것이다.
 
키쇼어 센굽타(Kishore Sengupta)와 루크 N. 반 바센호브(Luk N. Van Wassenhove)는 프랑스 인시아드 경영대학원 교수이며 타렉 K. 압델-하미드(Tarek K. Abdel-Hamid)는미국 캘리포니아 몬트레이의 해군대학원 교수다.
인기기사