13
프로젝트 종료와 감사
전문가는 흔히 판단력보다 데이터를 더 많이 가지고 있습니다.
—콜린 파월, 국무장관 (Harari 2003)
학습 목표
이 단원을 읽고 나면 다음을 할 수 있습니다.
- 기본 요소를 올바르게 갖추고 프로젝트 전반에 걸쳐 이를 올바르게 유지하는 것의 중요성을 논의합니다
- 프로젝트 검토와 감사의 가치를 설명합니다
- 프로젝트 중간의 방향 수정 및 프로젝트 중단 결정과 관련된 문제를 기술합니다
- 프로젝트 종료 단계를 논의합니다
이 단원의 핵심 개념
- 프로젝트에서는 사소한 일이 많이 잘못될 수 있지만, 기본 요소를 올바르게 갖추고 이를 목표에 맞게 유지하기만 하면 프로젝트는 상당한 성공을 거둘 가능성이 높습니다. 그러나 프로젝트 초기에 기본 요소를 올바르게 갖추었다고 해서 그것이 계속 그대로 유지된다는 의미는 아닙니다.
- 프로젝트의 전체 수명 동안 멈추고, 살펴보고, 귀 기울여야 하며, 필요에 따라 방향을 조정해야 합니다. 프로젝트에서 잘못되는 모든 사소한 일에 대해 책임을 묻기보다는 유연성을 유지하는 데 더 집중하십시오.
- 규칙적이고 신중한 정기 검토를 수행하면, 프로젝트의 전략적 변곡점을 충분히 일찍 감지하여 적응하고 조정할 시간을 확보할 가능성이 높아집니다.
13.1 기본 요소를 올바르게 갖추기
프로젝트에서는 사소한 일이 많이 잘못될 수 있지만, 기본 요소를 올바르게 갖추고 이를 목표에 맞게 유지하기만 하면 프로젝트는 상당한 성공을 거둘 가능성이 높습니다. 이 책 전반에서 배웠듯이, 기본 요소를 올바르게 갖추는 가장 좋은 방법은 이해관계자와 협력하여 포괄적이고 현실적인 계획을 수립하는 동시에, 앞으로 닥쳐올 피할 수 없는 살아 있는 질서의 변화에 계속 적응할 수 있도록 하는 것입니다. 그러나 프로젝트 초기에 큰 사항들을 올바르게 갖추었다고 해서 그것이 계속 그대로 유지된다는 의미는 아닙니다. 프로젝트의 전체 수명 동안 멈추고, 살펴보고, 귀 기울여야 합니다. 즉, 주기적으로 멈춰서 프로젝트 진행 중에 프로젝트 검토/감사를 수행하고, 범위, 품질, 일정에 관한 데이터를 살펴보며, 팀원의 말에 귀 기울여야 합니다. 정기적으로 멈추고, 살펴보고, 귀 기울이는 시간은 프로젝트의 현재 상태와 향후 전망에 대한 필수적인 통찰을 제공할 것입니다.
과거에 수행했던 다른 프로젝트와 똑같아 보이는 프로젝트를 진행하고 있더라도, 발밑의 땅이 갑자기 흔들릴 수 있다는 가능성에 늘 경계를 늦추지 말아야 합니다. 그리고 그런 일이 일어나고 있는지 알 수 있는 유일한 방법은 정기적으로 멈추고, 살펴보고, 귀 기울이는 것입니다. 혹은 1997년부터 2005년까지 인텔의 CEO였던 앤드루 그로브(Andrew Grove)의 표현을 빌리자면, 모든 프로젝트에 대해 '수호자의 자세'를 유지하면서 프로젝트에 관해 자신이 모르고 있을지도 모르는 것에 대해 늘 일정 수준의 편집증을 키워야 합니다(1999, 3). 그로브는 특히 아무리 치밀하게 세운 계획이라도 뒤엎을 수 있는 전략적 변곡점에 대해 편집증적으로 경계해야 한다고 주장합니다. 그는 저서 Only the Paranoid Survive에서 전략적 변곡점이 조직 전체에 가하는 위험을 설명하는데, 그가 하는 말의 상당 부분은 개별 프로젝트에도 똑같이 적용될 수 있습니다.
전략적 변곡점이란 기업의 생애에서 그 근간이 바뀌려 하는 시점입니다. 그 변화는 새로운 정점으로 도약할 기회를 의미할 수 있습니다. 그러나 그만큼 종말의 시작을 알리는 신호일 수도 있습니다.
전략적 변곡점은 기술 변화로 인해 생길 수 있지만, 기술 변화 그 이상의 것입니다. 경쟁자로 인해 생길 수도 있지만, 단순한 경쟁 그 이상의 것입니다. 전략적 변곡점은 사업을 수행하는 방식 자체의 전면적인 변화이므로, 단순히 새로운 기술을 도입하거나 예전처럼 경쟁에 맞서는 것만으로는 충분하지 않을 수 있습니다. 전략적 변곡점은 아주 은밀하게 힘을 축적하기 때문에 무엇이 바뀌었는지 짚어 내기조차 어려울 수 있지만, 무언가가 바뀌었다는 것만은 알 수 있습니다.
단도직입적으로 말하겠습니다. 전략적 변곡점은 방치하면 치명적일 수 있습니다. 그 변화로 인해 쇠퇴하기 시작한 기업이 이전의 위상을 되찾는 경우는 드뭅니다.
그러나 전략적 변곡점이 언제나 재앙으로 이어지는 것은 아닙니다. 사업을 수행하는 방식이 바뀌면, 새로운 방식으로 움직이는 데 능숙한 이들에게는 기회가 생겨납니다. 이는 신규 진입자에게도, 기존 기업에게도 해당될 수 있으며, 기존 기업에게 전략적 변곡점은 새로운 성장기를 맞이할 기회를 의미할 수 있습니다. (Grove 1999, 3-4)
반도체 업계에서 쌓은 오랜 경험을 바탕으로, 그로브는 전략적 변곡점을 감지하기에 가장 좋은 위치에 있는 사람이 중간 관리자라고 주장합니다.
중간 관리자라면 회사 전체보다, 때로는 고위 경영진보다도 먼저 바람의 방향이 바뀌는 것을 얼굴로 느낄 수 있습니다. 중간 관리자, 특히 영업 담당자처럼 외부 세계를 상대하는 사람들은 예전에 통하던 것이 더 이상 잘 통하지 않는다는 것, 즉 규칙이 바뀌고 있다는 것을 가장 먼저 깨닫는 경우가 많습니다. 이들은 대개 이를 고위 경영진에게 설명하는 데 어려움을 겪기 때문에, 회사의 고위 경영진은 세상이 자신들을 둘러싸고 바뀌고 있다는 사실을 뒤늦게 깨닫기도 하며, 리더는 흔히 가장 마지막에야 알게 됩니다. (Grove 1999, 21-22)
프로젝트 관리자로서 바람의 방향이 바뀌는 것을 감지하는 가장 좋은 방법은 정기적으로 멈추고, 살펴보고, 귀 기울이는 시간을 갖는 것입니다. 업계의 전략적 변곡점을 감지할 수도 있으며, 그렇다면 알게 된 내용을 활용해 상위 경영진을 설득할 수 있습니다. 그러나 실제로는 개별 프로젝트에서 전략적 변곡점을 감지할 가능성이 더 높으며, 그로브에게서 영감을 얻어 여기서는 이를 프로젝트의 생애에서 그 근간이 바뀌려 하는 시점으로 정의합니다. 프로젝트 관리자로서 여러분의 목표는 적응하고 조정할 시간을 확보할 수 있을 만큼 일찍 프로젝트의 전략적 변곡점을 감지하는 것입니다. 이를 확실히 하는 가장 좋은 방법은 정기적으로 프로젝트 감사를 수행하는 것입니다.
13.2 감사: 좋은 점, 나쁜 점, 추한 점
건강을 유지하려면 체중을 확인하거나 피트니스 모니터를 착용해 운동량이 충분한지 확인하는 등 몇 가지 기본 사항을 매일 점검하는 것이 중요합니다. 하지만 때로는 해박한 의료 전문가로부터 외부의 통찰을 얻기 위해 종합 검진 일정을 잡아야 합니다. 기술 프로젝트도 마찬가지입니다. 11과에서 권장한 대로 심각한 문제를 알려 주도록 설계된 신뢰할 수 있는 모니터링 시스템을 구축했더라도, 때때로 감사를 통해 프로젝트를 더 깊이 들여다보아야 좋은 점, 나쁜 점, 추한 점, 그리고 예상치 못한 점까지 알아야 할 모든 것을 파악할 수 있습니다.
그렇다면 프로젝트 감사란 정확히 무엇입니까? 프로젝트 감사란 이해관계자가 프로젝트의 미래에 관해 충분한 정보를 바탕으로 결정을 내릴 수 있도록 프로젝트의 일부 또는 모든 측면을 심층적으로 조사하는 것입니다. 감사는 프로젝트의 일부 또는 전체에 대해 초점이 분명하고 객관적인 검토를 제공할 수 있습니다.
감사는 비교적 비공식적일 수도 있고 공식적일 수도 있습니다. 비공식 감사는 프로젝트를 비교적 신속하게 평가하는 것으로, 예를 들어 새로 부임한 프로젝트 관리자가 관련된 모든 사람과 대화하고 프로젝트 목표에 대해 최대한 많이 알아내려 하면서 프로젝트 현황을 파악하려는 경우가 이에 해당합니다. 공식 감사는 더 체계적이며, 일반적으로 프로젝트 외부의 사람이, 또는 감사 범위에 따라서는 조직 외부의 사람이 수행합니다.
모든 감사의 궁극적인 목표는 프로젝트를 개선하는 데 활용하거나, 필요한 경우 프로젝트 중단의 정당한 근거로 삼을 수 있는 실행 가능한 정보를 생성하는 것입니다. 이 정보는 보통 감사 보고서 형태로 제시되며, 감사 보고서에는 일반적으로 전반적인 초점이나 중요한 문제를 포함한 감사의 배경 설명, 감사 중 수집한 데이터·인터뷰·관련 조사에 대한 분석, 실행 중심의 권고 사항이 담기고, 경우에 따라서는 교훈과 하나 이상의 보충 부록이 포함되기도 합니다.
일부 조직에서는 특정 단계가 끝날 때 감사나 공식 프로젝트 검토를 실시하여, 팀이 다음으로 나아가기 전에 프로젝트를 계속할 가치가 있는지, 또는 프로젝트 계획에 중대한 변경이 필요한지를 판단합니다. 감사는 다음과 같은 목적으로 활용할 수 있습니다.
- 특정 기준(규모, 위험, 고객, 규정 등)을 충족하는 모든 프로젝트 검토
- 프로젝트의 사업 타당성 재검증
- 프로젝트가 실행 가능하다는 점을 상위 경영진에게 확인시킴
- 프로젝트에 대한 상위 경영진의 지원 재확인
- 다음 프로젝트 단계로 넘어갈 준비가 되었는지 확인
- 특정 문제를 조사하여 다음 단계 결정
- 시장 상황 검증
감사에서 다룰 수 있는 사안은 다음과 같습니다.
- 프로젝트 근거: 애초에 이 프로젝트를 선정한 이유는 무엇입니까? 그 근거는 여전히 유효합니까?
- 조직의 우선순위에서 프로젝트가 차지하는 역할: 시장이 변하면 프로젝트의 요구 사항도 변합니다. 최근의 변화로 인해 프로젝트의 우선순위가 낮아졌습니까, 아니면 높아졌습니까? 프로젝트를 완전히 종료해야 합니까, 아니면 더 빨리 끝내기 위해 자원을 추가로 투입해야 합니까?
- 팀 현황: 프로젝트 팀이 잘 운영되고 있으며 인력이 적절히 배치되어 있습니까?
- 프로젝트의 방향과 중요도에 영향을 미치는 외부 요인: 새로운 규제, 경쟁 제품 또는 기술로 인해 경쟁 환경이 바뀌었습니까?
- 예산과 일정: 예산과 일정의 현재 상태에 관한 정확한 데이터를 확보하고, 완료 시점의 예측치가 타당한지 확인하는 것이 중요합니다. 독립적인 검토자는 때때로 이 두 가지 핵심 항목과 관련하여 이전에는 인식하지 못했던 문제를 찾아낼 수 있습니다.
- 계약업체의 성과: 그들의 작업 품질은 어떻습니까? 일정대로 진행하고 있습니까? 그들의 예산 예측은 현실과 부합합니까?
팀 점검하기
개별 프로젝트를 감사하는 것 외에도, 팀에 대해 정기적으로 감사를 실시하는 것이 좋습니다. 그리고 프로젝트 관리자인 자신도 반드시 감사 대상에 포함하십시오. 자신의 업무를 공식적으로 평가받는 것을 좋아하는 사람은 거의 없지만, 팀 감사를 자주 그리고 일상적으로 실시하면 사람들이 이를 자신을 깎아내리려는 표적 시도가 아니라 단순히 업무의 일부로 여기게 되므로 부정적인 감정을 최소화할 수 있습니다.
브라이언 프라이스(Brian Price, 이 강의 뒷부분의 "현장에서" 참조)는 팀 감사를 실시하는 사람에게 다음과 같이 제안합니다.
- 먼저 당사자에게 자신의 성과를 스스로 평가하도록 요청하십시오.
- 다른 팀원과 비교하는 것을 피하고, 그 대신 확립된 기준과 기대치에 비추어 개인을 평가하십시오.
- 비판은 개인 자체가 아니라 구체적인 행동에 초점을 맞추십시오.
- 모든 팀원을 일관되고 공정하게 대하십시오.
- 평가를 지속적인 과정의 한 시점으로 취급하십시오. (2007)
팀을 대상으로 한 익명 설문조사는 팀 감사를 실시하는 한 가지 방법입니다. Slate에 실린 이 기사는 데이트 앱과 비슷하게 작동하는 설문조사 앱을 소개하는데, 이 앱에서는 사람들이 왼쪽이나 오른쪽으로 스와이프하여 자신의 성과뿐만 아니라 팀원과 관리자의 성과도 평가할 수 있습니다: http://www.slate.com/articles/business/the_ladder/2016/06/can_new_app_tinypulse_disrupt_performance_reviews.html.
어떤 설문조사 방법을 선택하든, 설문조사에서 얻은 정보를 팀의 성과를 향상시키는 데 활용하는 모습을 팀원들이 볼 수 있도록 하십시오. 그렇지 않으면 팀원들은 향후 팀 감사는 물론 프로젝트 관리자인 여러분에 대해서도 신뢰를 잃게 됩니다. 팀 감사는 개인의 "번아웃" 문제를 해결할 수 있으며, 개인의 성과뿐만 아니라 팀원 유지에도 도움이 됩니다.
조직마다 감사 절차는 다르지만, 모든 감사의 핵심은 인터뷰나 설문조사를 통해 프로젝트에 관련된 사람들의 의견을 듣는 것입니다. 문제 프로젝트 구하기(Rescue the Problem Project)의 저자 Todd C. William에 따르면,
사람은 프로젝트의 성패를 가르는 결정적인 요소입니다. 이들은 프로젝트 착수를 승인하고, 범위 크리프를 허용하며, 기술적 해결책을 정의하고, 제약 조건을 부과합니다. 팀의 역학 관계는 어떠합니까? 후원자는 누구입니까? 그들의 기대는 무엇입니까? 리더십의 강점은 무엇입니까? 이 사람들은 프로젝트에 어떤 문제가 있다고 생각합니까? 팀은 적절한 역량을 갖추고 있습니까? 팀이라면 프로젝트를 바로잡기 위해 무엇을 하겠습니까? 이러한 질문에 대한 답은 더 많은 질문으로 이어지며, 결국 근본적인 문제를 가리키게 됩니다…. 다시 말해, 팀원들은 문제와 그에 따르는 해결책을 알고 있으며, 누군가 그들에게 물어보기만 하면 됩니다. 그러므로 감사를 시작하기에 가장 좋은 곳은 프로젝트에 참여하는 사람들입니다. (2011, 35)
감사의 견인 가치
감사는 배우고 평가할 수 있는 훌륭한 기회를 제공합니다. 또한 감사는 다음과 같은 질문을 안전하게 던질 기회를 제공합니다. 이 프로젝트를 (수정하든 수정하지 않든) 계속해야 합니까, 아니면 중단해야 합니까? 감사를 정기적으로, 그리고 언제나 앤드루 그로브가 권한 수호자의 태도로 수행하면, 팀이 한발 물러서서 품질, 일정, 비용, 자원, 그리고 전반적인 실행 가능성에 초점을 맞추어 더 높은 관점에서 진행 상황을 바라보는 주기적인 타임아웃을 가질 수 있습니다. 감사는 감사 결과를 요약한 일종의 보고서로 이어져야 하지만, 일반적으로 감사를 과거를 지나치게 문서화하는 기회로 여기는 것은 피해야 합니다. 대신 감사를 프로젝트의 원하는 최종 목표로부터 현재 상태로 끌어당기는 기회로 생각하고, 다음과 같은 핵심 질문을 던지십시오.
- 원하는 최종 상태에 도달하여 약속한 가치를 전달하는 데 성공하도록 가장 확실하게 보장하려면 다음에 무엇이 이루어져야 합니까?
- 프로젝트의 다음 단계는 필요한 투자만큼의 가치가 있습니까?
세심한 접근 방식을 취하십시오
감사에 대한 접근 방식은 조직마다 다릅니다. 어떤 조직은 모든 주요 프로젝트에 대해 정기적으로 감사를 수행합니다. 또 어떤 조직은 문제가 생길 것으로 보이는 프로젝트에 대해서만 감사를 수행합니다. 다른 조직에서는 특정 유형의 프로젝트에 대해서만 정기적으로 감사를 수행합니다. 여러분의 조직이 어떤 접근 방식을 취하든, 프로젝트와 관련된 사람 및 조직에 적합한 방식으로 감사를 구성하고 수행하는 것이 필수적입니다. 특히 프로젝트에 관한 정확한 정보를 제공해 줄 것이라고 여러분이 의지하게 될 사람들을 소외시키지 않도록, 프로젝트 팀 자체의 문화에 세심하게 주의를 기울여야 합니다.
모든 프로젝트에 대해 정기적이고 체계적인 평가를 수행하는 조직은 의미 있고 유익한 프로젝트 검토와 그에 따른 후속 조치를 위한 더 안전하고 개방적인 환경을 조성하는 경향이 있습니다. 때로는 '감사' 대신 '프로젝트 검토'라는 용어를 사용하는 것만으로도 이 활동을 덜 위협적으로 보이게 할 수 있습니다. 또한 모든 프로젝트에 대해 검토가 이루어진다면, 프로젝트 관리자와 팀원들은 이것이 일상적인 업무의 일부임을 이해하므로 프로젝트 감사 중에 공격받는다고 느낄 가능성이 줄어듭니다. 이를 통해 개방적이고 솔직한 검토, 토론, 협력적 문제 해결을 중시하는 문화를 구축할 수 있습니다.
이해관계자들이 감사를 책임 추궁을 위한 조사가 아니라 프로젝트에 대해 배우려는 시도로 인식하도록 하십시오. 모든 당사자의 말을 주의 깊게, 존중하는 태도로 경청하는 전문적이고 체계적인 접근 방식은 불안해하는 참여자들을 진정시키는 데 크게 도움이 됩니다. 사람들이 감사의 계획과 수행에 대해 더 많이 알수록, 그리고 의견을 제시할 기회가 더 많을수록 감사 결과는 더 유용해집니다.
프로젝트 감사자는 감사나 검토를 이끄는 책임을 맡은 사람입니다. 이상적으로 프로젝트 감사자는 모든 이해관계자가 공정하고 객관적이라고 인식하는 외부인입니다. 프로젝트 감사자는 뛰어난 경청 능력과 조직 또는 업계에 대한 폭넓은 지식을 갖추어야 합니다. 다른 프로젝트의 동료들로 구성된 감사 팀을 활용하면 도움이 됩니다. 이렇게 하면 검토 대상 팀이 감사자들이 자신들이 프로젝트를 수행하며 직면하는 제약을 이해하고 있다고 느끼게 하는 데 도움이 됩니다. 검토 대상 팀은 감사 팀을 비판적인 기구가 아니라 동료로 대하며 협력할 것입니다. 프로젝트 팀은 다른 단계에서 감사자들의 프로젝트를 평가해 줌으로써 보답할 수 있습니다. 외부 당사자가 감사를 수행하는 경우, 검토 대상 팀이 감사 팀을 존중하는 것이 중요합니다. 이는 부당하게 비판받는다는 느낌을 누그러뜨리는 데 도움이 됩니다.
적임자 선정
성공적인 감사의 중요한 열쇠는 모든 이해관계자에게 신뢰와 존중을 받고, 진심으로 조직의 이익을 최우선으로 생각한다고 여겨지며, 업계에서 폭넓은 경험을 쌓은 감사 책임자입니다. 어떤 상황에서는 이해 상충으로 보이는 것을 피하기 위해 프로젝트에 직접 관여하지 않은 공정한 사람을 감사자로 선정하는 것이 가장 좋습니다. Michael Stanleigh가 설명하듯이, 프로젝트와 관련이 없는 감사자가 있으면 팀원과 기타 이해관계자들이 완전히 솔직하게 말할 수 있습니다.
그들은 자신의 의견이 소중히 다루어질 것이며, 최종 보고서에는 개인의 이름이 밝혀지지 않고 오직 사실만 담길 것임을 알고 있습니다. 특히 관리가 매우 부실했던 프로젝트의 프로젝트 감사 중에 면담을 한 사람들은 외부 진행자와 대화하면서 프로젝트 참여에 대한 감정과 느낌, 그리고/또는 프로젝트가 자신에게 미친 영향을 표현할 기회를 얻는다고 느끼는 경우가 흔합니다. 이러한 '감정 분출'은 전체 감사에서 중요한 부분입니다. (n.d.)
그러나 감사의 목적이 팀의 잘못을 잡아내는 데 있는 것처럼 보이지 않도록, 때로는 팀이 스스로를 검토하게 하는 편이 더 낫습니다. 이러한 접근 방식은 사람들이 적극적으로 나서서 프로젝트에 대해 알게 된 좋은 점과 나쁜 점을 모두 공유하도록 장려할 수 있습니다. 결국 감사나 프로젝트 검토의 궁극적인 목적은 조직이 프로젝트에 대해 배우도록 돕는 것입니다.
감사는 본질적으로 학습 경험이므로, 이상적인 감사 책임자는 다른 사람들이 말하는 것뿐만 아니라 말하지 않는 것에도 귀를 기울이며, 표면 아래에서 프로젝트 성과를 좌우하는 숨겨진 흐름을 살필 수 있는 능력을 갖추고 있습니다. 그런 다음 감사 책임자는 감사에서 얻은 모든 정보를 엮어 프로젝트의 현재 상태와 향후 전망에 대한 일관된 그림을 그려 낼 수 있어야 합니다.
이러한 까다로운 개인적 요구 사항 외에도, 감사 리더에게는 독립적으로 활동할 수 있는 능력과 함께 비난을 두려워하지 않고 감사 결과를 보고할 수 있는 권한이 주어져야 합니다. 감사 책임자는 필요한 경우 나쁜 소식도 기꺼이 전달할 수 있어야 하며, 공식 보고서든 프레젠테이션이든 이메일이든 이를 전달할 적절한 수단을 갖추고 있어야 합니다.
토드 C. 윌리엄스(Todd C. Williams)는 실패하고 있는 프로젝트를 감사하고, 가능하다면 성공적인 결말로 이끌기 위해 외부에서 영입한 컨설턴트를 가리켜 복구 관리자라는 용어를 사용합니다. 그의 견해에 따르면, 적합한 복구 관리자를 선정하는 것이 반드시 필요한 첫 단계입니다:
적합한 복구 관리자를 선정하는 것은 매우 중요합니다. 현재 프로젝트에 관여하고 있는 사람은 선택하지 마십시오. 프로젝트에 관여하는 사람은 너무 가까이 있어서 문제를 보지 못하며, 이해관계자들에게 편향되어 있다고 인식될 수 있습니다. 최소한 감사를 수행하는 사람은 확장된 프로젝트 범위 밖에 있으며 제품과 무관한 사람이어야 합니다. 객관적인 시각은 올바른 감사를 수행하고 해결책에 대한 선입견을 줄이는 데 매우 중요합니다. 이상적인 후보자는 공급자와 고객 모두로부터 독립된 외부인이며, 복구 경험과 (기술 팀과의 대화를 위한) 탄탄한 기술적 배경을 갖춘 노련하고 객관적인 프로젝트 관리자입니다. 이를 재무 감사자를 고용하는 경우와 비교해 보십시오. 내부 인사나 경험이 없는 사람을 고용하라고 권하는 사람은 아무도 없을 것입니다. 그렇게 하면 누군가 감사 결과를 믿지 않을 가능성이 너무 커지기 때문입니다…. 무엇보다도 복구 관리자는 정직한 중재자여야 합니다. 객관성이 가장 중요합니다. 복구 관리자는 프로젝트의 어느 한쪽에도 충성해서는 안 됩니다. (17-19)
13.3 경로 수정 또는 프로젝트 중단
감사 결과에 따라 팀은 현재 계획대로 진행하거나, 계획(즉, 작업과 순서)을 수정하거나, 일정을 수정하거나, 예산을 수정하거나, 범위를 수정하거나, 새로운 팀원을 영입하거나 기존 팀원을 제외하거나, 프로젝트를 종료하기로 결정할 수 있습니다. 프로젝트 감사에서는 팀원이 너무 자주 추가되거나 빠져서 프로젝트가 이 목표에서 저 목표로 갈팡질팡하고 있지는 않은지도 조사할 수 있습니다. 때로는 빠르고 실행하기 쉬운 경로 수정 몇 가지만으로 충분합니다. 그러나 대규모 변경이 필요하다면 "핵심 참여자와 이해관계자의 참여를 통해" 필요한 변경에 대한 저항을 최소화할 변경 관리 전략에 합의해야 합니다(Business Dictionary n.d.).
어떤 종류의 변화든 그에 대한 저항은 흔히 두려움에서 비롯됩니다. 그리고 비제이 고빈다라잔(Vijay Govindarajan)과 힐케 페이버(Hylke Faber)가 설명하듯이, 우리는 두려울 때 결코 최상의 모습을 보이지 못합니다:
두려움에 사로잡혀 있을 때 우리는 최상의 상태일 때보다 최소 25배는 덜 지적입니다. 우리는 제대로 생각하지 못합니다. 그리고 우리를 안전지대 밖으로 끌어내는 것은 무엇이든 거부할 가능성이 큽니다. 이러한 반응은 오늘날 "편도체 납치"로 잘 알려져 있습니다. 이는 생존에 맞추어진 더 원시적인 뇌, 즉 "악어의" 뇌가 주도권을 잡을 때 일어납니다. 우리 안의 악어가 활성화되면 우리는 변화에 저항하고 생존에 대한 두려움에 따라 행동합니다. 우리 안의 악어는 혁신과 변화를 희생하면서까지 우리를 안전하게 지키려 합니다. (2016)
Govindarajan과 Faber는 두려움의 힘을 빼는 가장 좋은 방법이 팀원들의 불안에 대해 솔직하고 담담하게 이야기하는 것이라고 주장합니다. 또한 적절한 경우에는 유머를 사용하고, 자신감과 용기를 풍기는 모습을 보일 것을 권장합니다.
의사 결정의 기술
프로젝트의 방향을 성공적으로 수정하려면 여러분과 팀이 효과적인 의사 결정자여야 합니다. 따라서 경력 전반에 걸쳐 의사 결정에 관해 배울 수 있는 모든 것을 배우는 것이 현명합니다. 시작하는 데 도움이 될 몇 가지 자원을 소개합니다.
- Chip Heath와 Dan Heath의 Decisive: How to Make Better Choices in Life and Work —의사 결정에 관한 기초 연구를 소개하고, 더 나은 선택을 하는 방법에 대한 조언을 제공합니다.
- John S. Hammon, Ralph L. Keeney, Howard Raiffa의 Smart Choices: A Practical Guide to Making Better Decisions—의사 결정에 대해 보다 분석적으로 접근하는 책으로, "시간, 에너지, 돈, 평정심의 손실을 최소화하면서 최선의 해결책에 도달하게 해 주는" 유용한 프로세스를 수립하는 것을 강조합니다(2015, 3).
- How to Make Decisions: Making the Best Possible Choices—유용한 의사 결정 전략을 간략히 개관합니다: https://www.mindtools.com/pages/article/newTED_00.htm.
- Deciding How to Decide: 유용한 의사 결정 도구를 평가하고, 특정 결정에 알맞은 도구를 고르는 방법을 제안합니다: https://hbr.org/2013/11/deciding-how-to-decide.
감사 결과 프로젝트를 종료할 때가 되었다는 고통스러운 진실이 드러난다면, 이것이 반드시 나쁜 일은 아니라는 점을 깨닫는 것이 중요합니다.
프로젝트를 취소하는 것은 실패처럼 보일 수 있지만, 프로젝트가 성공하려면 모든 당사자에게 가치를 제공해야 합니다. 최선의 가치는 시간과 비용 양면에서 프로젝트가 모든 당사자에게 미치는 전반적인 부정적 영향을 최소화하는 것입니다. 규모를 축소한 프로젝트, 납기가 늦어지는 프로젝트, 또는 비용이 훨씬 더 많이 드는 프로젝트로 진행하는 것만이 유일한 선택지라면, 그 결과는 프로젝트를 취소하는 것보다 더 나쁠 수 있습니다. 시간과 자원을 다른 사업에 투자하거나, 향후 다른 팀과 수정된 조건으로 프로젝트를 재구성하는 것이 더 신중한 선택일 수 있습니다. (Williams, 8)
프로젝트 종료를 검토할 때는 다음 질문을 던져 보는 것이 도움이 됩니다.
- 기술 발전으로 인해 프로젝트가 쓸모없어졌거나 가치가 떨어졌습니까? 예를 들어, 새 휴대전화를 개발하고 있는데 경쟁사가 여러분의 제품을 매력 없게 만드는 신기술을 출시한다면 이러한 경우에 해당할 수 있습니다.
- 지금까지의 진척도, 완료까지 드는 갱신된 비용, 프로젝트 산출물의 기대 가치를 고려할 때, 계속 진행하는 것이 여전히 비용 효율적입니까? 프로젝트의 비용 효율성에 대한 계산은 시간이 지나면서 바뀔 수 있습니다. 프로젝트 초기에 사실이었던 것이 몇 달 뒤에는 사실이 아닐 수도 있습니다. 최종 비용이 예상보다 높아지는 경우가 많은 IT 프로젝트에서 흔히 이런 일이 일어납니다.
- 프로젝트를 일상 운영에 통합할 때가 되었습니까? 예를 들어, 새로운 네트워크 시스템을 도입하는 IT 프로젝트는 일반적으로 네트워크 사용자들이 새 시스템으로 전환을 마치면 일상 운영에 통합됩니다.
- 프로젝트에 투입된 자금, 시간, 인력을 더 잘 활용할 수 있는 다른 방안이 있습니까? 프로젝트 선정을 다룬 2강에서 배운 것처럼, 성공적인 포트폴리오 관리의 핵심은 부족한 자원을 현명하게 사용하는 것입니다. 이를 위해서는 개별 프로젝트의 상대적 이점에 대해 어려운 선택을 내려야 합니다. 이는 특히 합병의 경우에 중요한 문제가 될 수 있는데, 이때 조직은 경쟁하는 프로젝트들을 평가하고 어떤 프로젝트가 조직의 더 큰 목표에 가장 잘 부합하는지 판단해야 하기 때문입니다.
- 시장이나 규제 요구 사항의 변화로 인한 전략적 변곡점이 프로젝트 결과물의 필요성을 바꾸어 놓았습니까?
- 그 밖에 프로젝트에 관한 어떤 점이 전략적 변곡점의 존재를, 그리고 그에 따라 프로젝트의 근본적인 목표를 재검토할 필요성을 시사하고 있습니까?
프로젝트를 종료할지 여부를 결정하는 것은 프로젝트에 가까이 있는 사람들에게 매우 어려운 결정일 수 있습니다. 그림 13-1에서 보듯이, 프로젝트를 바라보는 관점은 프로젝트의 전반적인 성공에 대한 판단에 막대한 영향을 미칩니다. 그렇기 때문에 객관적인 외부 감사자가 수행하는 검토는 큰 깨달음을 줄 수 있습니다.
출처: Rescue the Problem Project: A Complete Guide to Identifying, Preventing, and Recovering from Project Failure의 그림 1-1을 바탕으로 수정함
13.4 프로젝트 마무리하기
프로젝트 종료는 전통적으로 프로젝트의 마지막 단계로 간주됩니다. 여기에는 다음과 같은 작업이 포함됩니다.
- 고객에게 산출물 이전
- 공급업체 계약 해지하기
- 인력, 장비 및 기타 자원 재배치하기
- 프로젝트의 우여곡절을 요약한 분석을 추가하여 프로젝트 문서 마무리하기
- 향후 프로젝트의 참고 자료로 활용할 수 있도록 조직 내 다른 사람들이 문서에 접근할 수 있게 하기
- 종료 회의 개최하기
- 완료된 프로젝트 축하하기
기하학적 질서의 관점에서 보면, 이러한 작업들은 프로젝트의 확정적인 끝을 나타냅니다. 그러나 그림 13-2에서 보듯이, 프로젝트 생애 주기를 더 넓은 살아 있는 질서의 관점에서 바라보면, 프로젝트 종료는 흔히 프로젝트 전체 생애 주기에서 한 단계의 마무리와 다른 단계로의 전환을 나타낼 뿐입니다. 이러한 관점에서 보면, 프로젝트 종료는 사실 프로젝트 전반에 걸쳐 이루어지는 학습과 조정 과정의 연장입니다. 계획에서 다음 버전에 대한 아이디어에 이르기까지 한 주기를 거치는 데 실제로 걸리는 시간은 몇 주에서 몇 년까지 다양할 수 있지만, 이는 사실상 모든 산업에 해당됩니다.
종료 회의는 프로젝트를 시작했을 때와 같은 방식으로, 즉 팀을 한자리에 모아 프로젝트를 끝낼 수 있는 기회입니다. 이 중요한 행사에서 팀은 잘된 점과 잘되지 않은 점을 검토하고 개선이 필요한 영역을 파악해야 합니다. 이 모든 내용은 최종 종료 보고서에 요약되어야 합니다. 고객과의 최종 종료 회의 또한 필수적입니다. 이를 통해 조직은 프로젝트를 공식적으로 완료하고 향후 있을 수 있는 작업의 토대를 마련할 수 있습니다.
종료 보고서는 프로젝트 성과에 대한 최종 요약을 제공합니다. 종료 보고서에는 다음 내용이 포함되어야 합니다.
- 프로젝트 및 산출물 요약
- 일정, 비용, 품질과 관련된 성과 데이터
- 최종 제품, 서비스 또는 프로젝트의 요약과 그것이 조직의 비즈니스 목표를 어떻게 뒷받침하는지
- 직면한 위험과 그 완화 방법
- 교훈
여러분의 작업이 프로젝트 생애 주기의 정확히 어디에 해당하는지는 애초에 무엇을 "프로젝트"로 보는지에 대한 관점에 따라 달라집니다. 건물의 설계자와 시공자는 소유주가 건물을 인수하는 것을 프로젝트 종료로 여길 수 있습니다. 그러나 프로젝트의 결과물, 즉 건물은 계속 존재합니다. 나중에 다른 시공업체가 고용되어 건물이나 그 시스템 중 하나를 개조할 수 있으며, 이로써 해당 작업에 한정된 새로운 프로젝트가 시작됩니다.
프로젝트 종료를 신중하고 체계적으로 수행하면, 프로젝트 생애 주기의 다음 단계나 후속 관련 프로젝트로 원활하게 전환하는 데 도움이 될 수 있습니다. 잘 수행된 프로젝트 종료는 또한 향후 프로젝트와 비즈니스 지속 가능성에 광범위한 영향을 미칠 수 있는 유용한 교훈을 만들어 낼 수 있습니다. 프로젝트 마지막의 종료 정보는 향후 유사한 프로젝트의 초기 계획을 위한 기초가 항상 되어야 합니다.
대부분의 프로젝트 관리자는 프로젝트 착수를 계획하는 데 시간과 자원을 쓰지만, 프로젝트 종료에 필요한 적절한 계획은 소홀히 하는 경향이 있습니다. 이상적으로 프로젝트 종료에는 결과 문서화, 책임 이관, 인력 및 기타 자원의 재배치, 작업 지시 종결, 대금 지급 준비, 고객 만족도 평가가 포함됩니다. 물론 덜 복잡한 프로젝트에는 덜 복잡한 종료 절차가 필요합니다. 프로젝트 감사와 마찬가지로, 프로젝트 종료 단계가 원활하게 진행되는지는 관리자가 인사 문제를 얼마나 신중하고 세심하게 다루는지에 크게 좌우됩니다. 대규모로 계속 진행되는 프로젝트에서는 팀이 최종 프로젝트 종료 외에도 주요 단계가 끝날 때마다 단계 종료를 수행할 수 있습니다.
13.5 현장의 목소리: Brian Price
UW 전문 실무 공학 석사(Master of Engineering in Professional Practice) 프로그램(공학 경영 석사 프로그램의 전신)을 졸업한 Brian Price는 Harley-Davidson의 수석 파워트레인 엔지니어를 지냈습니다. 그는 UW 엔진 시스템 공학 석사 과정에서 엔진 프로젝트 관리를 가르치고 있습니다. 25년간 엔진 관련 엔지니어링 프로젝트를 관리하면서, 그는 좋은 프로젝트 종료 절차의 이점과 부실하거나 아예 없는 프로젝트 종료 절차가 초래하는 폐해를 직접 볼 기회가 많았습니다. 최근 공학 교수로서 그는 학생들이 프로젝트를 체계적으로 마무리하는 것의 중요성을 이해하도록 장려하며, 특히 프로젝트 전반에서 얻은 지혜를 기록해 두는 데 중점을 둡니다.
브라이언은 인터뷰에서 이 주제에 대해 특히 통찰력 있는 생각을 들려주었습니다.
어떤 프로젝트든 가장 어려운 부분은 시작과 멈춤입니다. 프로젝트 관리 교육의 대부분은 대개 프로젝트를 시작할 때의 어려움, 즉 프로젝트 계획 수립, 자원 확보, 팀 구성 등에 할애됩니다. 그러나 프로젝트가 일단 움직이기 시작하면 추진력이 붙어 독자적인 생명을 얻게 되며, 그 결과 때가 되었을 때 사람들이 작업을 멈추게 하기가 어려워집니다. 따라서 남은 일을 모두 매듭짓는 체계적인 방식으로 프로젝트를 종료하려면 어느 정도의 규율이 필요합니다. 종료 체크리스트가 도움이 될 수 있습니다. (한 가지 예로, Erik W. Laron과 Clifford F. Gray의 프로젝트 관리: The Managerial Process에 있는 그림 14.2를 참고하십시오.) 종료 시에는 최종 예산을 마무리하고 자원을 재배치해야 합니다.
일반적으로 프로젝트의 끝은 무엇이 잘되었고 다음번에는 무엇을 다르게 할 수 있을지 되돌아보기에 더없이 좋은 시점입니다. 군의 모범 사례에서 유래한 사후 검토(After Action Review, AAR) 프로세스는 매우 유용합니다. 이 프로세스는 서로 구별되지만 관련된 세 가지 영역에 초점을 맞춥니다.
- 프로젝트 성과: 목표를 달성했습니까? 효율적이고 효과적으로 수행되었습니까?
- 팀 성과: 사람들이 얼마나 잘 협력했습니까? 팀이 구성원 개개인의 합보다 더 강했습니까?
- 개인 성과: 개인들은 어떻게 성과를 냈습니까? 이는 개인의 성장과 관련됩니다.
AAR 프로세스에 대해 더 알아보려면 Harvard Business Review에 실린 다음 심층 설명을 참고하십시오: https://hbr.org/2005/07/learning-in-the-thick-of-it.
프로젝트 종료 시점의 회고는 기술적인 것이든, 관리적인 것이든, 프로젝트 실행과 관련된 것이든 핵심 교훈을 포착할 수 있는 좋은 기회입니다. 이렇게 얻은 교훈은 체계화하여 다른 프로젝트에 전파하고 적용할 수 있습니다. 기법과 모범 사례를 개선하려면 지식 기반을 지속적으로 구축하는 것이 필수적입니다. 이는 관료적인 보고서 작성으로 여겨질 수 있어 결코 쉽지 않으므로, 프로젝트 관리자로서 이를 강력히 요구해야 합니다. 지식 기반을 구축하는 목적은 물론 지금 마무리하는 프로젝트를 개선하는 것이 아니라, 앞으로 다가올 아직 정해지지 않은 수많은 프로젝트를 개선하는 것임을 명심하십시오.
원래 계획과 비교하여 프로젝트를 완수하는 데 실제로 무엇이 들었는지(시간, 자원, 작업, 예산 등)에 초점을 맞추십시오. 이 정보는 다음 프로젝트를 계획하는 데 필수적입니다. 결국 프로젝트가 실패하는 주된 이유는 계획이 부실했기 때문이며, 계획이 부실한 주된 이유는 계획 수립자에게 완전한 계획 정보가 부족했기 때문입니다. 좋은 계획 정보를 얻을 수 있는 최고의 원천은 최근에 수행한 유사 프로젝트에서 얻은 지혜입니다. 따라서 모든 프로젝트를 종료할 때 그러한 정보를 포착하고 전파하는 것이 필수적입니다.
마지막으로, 프로젝트 팀의 성과를 기리는 일의 중요성을 과소평가하지 마십시오. 프로젝트 종료 단계는 프로젝트 완료 축하 행사로 사기를 북돋우기에 좋은 시기이며, 특히 끈끈하게 결속된 팀이 곧 여러 프로젝트로 흩어지게 될 때 더욱 그렇습니다. 사람들에게는 자신의 일에 대한 일관된 마무리가 필요합니다.
안타깝게도 대부분의 조직은 프로젝트 종료에 거의 관심을 기울이지 않습니다. 이는 부분적으로 기본적인 인간 심리 때문입니다. 사람들은 다음 기회에 들뜨기 마련입니다. 사람들은 다음의 흥미로운 일로 옮겨 가는 경향이 있으며, 새로운 것은 언제나 오래된 것보다 더 흥미롭습니다. 그러나 더 근본적인 문제는 조직이 회사가 프로젝트의 가치를 실현할 수 있게 해 주는 지식과 지혜보다는 프로젝트가 산출하는 결과물에 더 관심을 두는 경향이 있다는 점입니다. 조직의 진정한 가치는 조직이 계속해서 가치를 창출할 수 있게 해 주는 지식입니다. 예를 들어 Harley Davidson의 경우, 그것은 모터사이클을 만드는 방법에 대한 집단적 지식일 것입니다. 잘 수행된 프로젝트 종료는 그러한 지식을 더해 주며, 구체적인 경험을 조직이 향후 사업으로 이어 갈 수 있는 지혜로 바꾸어 줍니다(2016).
실패: 최고의 스승
Laufer 외는 저서 프로젝트 리더 되기(Becoming a Project Leader)에서 실패에 대한 관용의 중요성을 설명합니다. 프로젝트는 때때로 종료되거나 진행 방향이 근본적으로 바뀌기도 하지만, 그렇다고 해서 그 프로젝트에 참여한 팀원들이 무능했다는 뜻은 아닙니다. 오히려 이러한 어려움에 대처하는 경험은 개인과 팀이 훨씬 더 효율적으로 일하는 데 도움이 될 수 있습니다. 미국 공군의 합동 공대지 장거리 미사일(Joint Air-to-Surface Standoff Missile) 프로젝트 관리자로 일하던 당시, 테리 리틀(Terry Little)은 미사일 발사가 실패했을 때 계약업체인 록히드(Lockheed)를 실패의 책임으로 질책하지 않고, 오히려 자신이 어떻게 도울 수 있는지를 물었습니다. Lockheed의 프로젝트 관리자인 Larry Lawson은 Terry의 대응을 "프로젝트의 결정적 순간 . . . . 팀은 역경 속에서 어떻게 대응하는지, 그리고 그 리더가 어떻게 대응하는지에 따라 규정됩니다. 이 팀이 역경에 대응하는 방법에 관해 얻은 교훈 덕분에 우리는 더 큰 과제를 해결할 수 있었습니다"라고 말했습니다. Laufer 등이 명확히 설명하듯이, "실패를 관용하는 리더가 됨으로써 Terry Little은 신뢰와 헌신에 기반한 협업 문화를 발전시킬 수 있었습니다"(2018).
실용적인 팁
다음은 프로젝트 감사 및 프로젝트 종료와 관련된 몇 가지 실용적인 팁입니다.
- 경험이 부족한 인력을 숙련자와 짝지으십시오: 사람들이 은퇴하거나 다른 이유로 떠날 때, 사람들은 지식의 손실을 절실히 깨닫게 됩니다. 조직에 정보를 체계적으로 보관하는 방법이 없다면, 수년간의 경험을 통해 어렵게 얻은 지식이 떠나는 직원과 함께 문밖으로 사라질 수 있습니다. 이처럼 중요한 지식이 손실되는 것을 막으려면, 경험이 부족한 엔지니어를 연차가 높은 엔지니어와 짝지어 지식이 전수되도록 하는 방안을 고려하십시오. 이는 프로젝트 관리자로서 팀과 조직의 이익을 위해 지식을 축적하는 데 도움을 줄 수 있는 한 가지 방법입니다.
- 팀원을 인터뷰하거나 영상 요약을 만드십시오: 팀원들이 프로젝트 종료 요약을 글로 작성하도록 하기가 어렵다면, 팀원들을 인터뷰하고 내용을 기록하는 방안을 고려하십시오. 또 다른 좋은 방법은 팀원들에게 프로젝트에서 자신이 한 작업을 설명하는 짧은 영상을 만들어 달라고 요청하는 것입니다. 사람들은 형식을 갖춘 서면 보고서를 쓸 때보다 카메라 앞에서 이야기할 때 더 솔직하고 구체적으로 말하는 경우가 많습니다.
- 프로젝트의 이야기를 들려주십시오: 때로는 프로젝트 감사보다 덜 격식을 갖춘 방식으로 프로젝트의 뒷이야기를 기록한 프로젝트 "전기"를 정리해 두는 것이 도움이 됩니다. 이는 대개 프로젝트 팀만 사용하는 내부 문서에 불과합니다. 이러한 문서에서 솔직하게 쓸수록 프로젝트 전기의 가치는 더 커집니다. 또한 프로젝트에 관한 가장 중요한 정보는 흔히 이야기를 통해 팀원들 사이에 공유된다는 점을 명심하십시오. 결국 인류의 문화는 언제나 이야기를 통해 규범을 표현하고 정보를 전달해 왔습니다. 이야기는 팀원 간의 정서적 유대를 포함하여 프로젝트의 진정한 본질을 탐구하는 강력한 수단이 될 수 있습니다. 프로젝트 관리자로서 현재 진행 중인 프로젝트나 과거 프로젝트에 관해 자주 반복되는 이야기에 늘 귀를 기울이십시오. 한낱 사무실 잡담으로 치부하고 싶은 이야기가 실제로는 조직, 프로젝트 이해관계자, 현재 프로젝트에 대한 중요한 통찰을 제공할 수 있습니다.
- 데이터를 시각화하십시오: 감사 보고서나 종료 보고서를 작성할 때는 대상 독자가 쉽게 파악할 수 있는 방식으로 데이터를 제시하는 것이 필수적입니다. Harvard Business Review에 실린 다음 기사는 프로젝트 데이터를 효과적으로 시각화하는 데 유용한 아이디어를 제공합니다: https://hbr.org/2016/06/visualizations-that-really-work.
- 감사 보고서와 프로젝트 요약을 위한 저장소를 만드십시오: 시간을 들여 팀원들이 작성한 감사 보고서와 프로젝트 요약(서면이든 영상이든)을 보관할 조직 차원의 저장소를 구축하십시오. 조직 전반의 학습과 전문성 개발을 촉진하는 방법으로, 신규 프로젝트 관리자와 경험 많은 프로젝트 관리자를 주기적으로 초대하여 저장소를 검토하게 하십시오. 이 저장소는 개별 프로젝트 관리자의 개인 파일 속에 묻혀 있지 않고 조직 전체가 접근할 수 있도록 하십시오.
- 교훈에 관한 프로젝트 문서를 서둘러 마무리하지 마십시오: 때로는 프로젝트 실행이 끝나고 몇 주나 몇 달이 지난 뒤가 프로젝트를 돌아보고 무엇을 배웠는지 정확히 짚어 내기에 가장 좋은 시기입니다. 상황이 정리될 때까지 잠시 시간을 두면 더 큰 그림을 보고 무엇이 잘되었고 무엇이 잘못되었는지 온전히 이해할 수 있습니다.
- 모든 프로젝트를 축하할 시간을 가지십시오: 모든 사람의 성과를 축하하고 인정하는 방법은 다양합니다. 예를 들어 개인 맞춤형 감사 편지 쓰기, 팀원 각자를 위한 추천서 작성, 팀원 한 사람 한 사람에게 특별한 의미와 가치가 있는 상 수여, 단체 사진 촬영, 프로젝트를 되돌아보는 팀 노래나 팀 영상 제작, LinkedIn에서 각 프로젝트 구성원의 특정 기술 보증하기 등이 있습니다. 완료된 프로젝트를 축하하는 다른 방법도 아마 많이 떠올릴 수 있을 것입니다. 중요한 것은 무언가를 하는 것입니다.
- 언제 끝났다고 말해야 하는지 아십시오: 프로젝트가 마무리를 향해 갈 때, 때로는 "언제가 진짜 끝인가?"라고 물어야 합니다. 이는 일부 고객에게서 문제가 될 수 있는데, 이런 고객은 팀의 책임이 끝난 지 한참 뒤에도 계속해서 관심을 요구할 수 있습니다. 공식적인 프로젝트 종료 절차는 프로젝트가 공식적으로 끝났다는 사실을 모든 당사자에게 분명히 함으로써 이런 종류의 문제를 미리 막는 데 도움이 될 수 있습니다.
~요약
- 프로젝트에서는 사소한 일들이 많이 잘못될 수 있지만, 기본을 제대로 갖추고 그것이 목표에서 벗어나지 않도록 유지하는 한 프로젝트는 상당한 성공을 거둘 가능성이 높습니다. 그러나 프로젝트 초기에 큰 사항들을 제대로 갖추었다고 해서 그 상태가 계속 유지된다는 뜻은 아닙니다. 프로젝트 전 기간에 걸쳐 멈추고, 살피고, 귀 기울여야 하며, 프로젝트의 건전성에 대해 어느 정도의 경계심을 유지하고 필요할 때는 적극적으로 개입하여 방향을 바꿔야 합니다.
- 심각한 문제를 알려 주도록 설계된 신뢰할 만한 모니터링 시스템을 구축했더라도, 때로는 공식 감사나 비공식 검토를 통해 프로젝트를 더 깊이 들여다볼 필요가 있습니다. 모든 감사/검토의 궁극적인 목표는 프로젝트를 개선하거나, 필요한 경우 프로젝트 중단을 정당화하는 데 사용할 수 있는 실행 가능한 정보를 감사 보고서 형태로 만들어 내는 것입니다.
- 방향을 수정할지 아니면 프로젝트를 완전히 중단할지 결정하는 일은 결코 쉽지 않으며, 바람직한 의사 결정 관행보다는 두려움에 좌우되는 경우가 많습니다. 프로젝트의 존속 가능성을 판단하려면 먼저 프로젝트에 관한 질문에 대해 솔직한 답을 구하는 것에서 시작하는 것이 중요합니다. 또한 프로젝트에 대한 이해관계자의 관점이 그 사람의 프로젝트 존속 가능성 평가에 영향을 미친다는 점도 염두에 두어야 합니다.
- 프로젝트 종료는 전통적으로 프로젝트의 마지막 단계로 여겨지지만, 더 넓은 살아 있는 질서의 관점에서 보면 프로젝트 전체 생명 주기에서 한 단계의 끝과 다른 단계로의 전환을 나타낼 뿐인 경우가 많습니다. 프로젝트 종료를 신중하고 체계적으로 수행하면 프로젝트 생명 주기의 다음 단계나 이후의 관련 프로젝트로 원활하게 전환하는 데 도움이 될 수 있습니다.
용어집
- 감사—이해관계자가 프로젝트의 미래에 대해 충분한 정보를 바탕으로 결정을 내릴 수 있도록 하는 것을 목적으로, 프로젝트의 일부 또는 모든 측면을 깊이 있게 조사하는 것입니다. 감사는 프로젝트의 일부 또는 전체에 대해 초점이 분명하고 객관적인 검토를 제공할 수 있습니다.
- 감사 보고서—감사가 끝날 때 작성하는 보고서로, 일반적으로 전체적인 초점이나 중요한 쟁점을 포함한 감사의 배경 설명, 감사 중에 수집한 데이터·인터뷰·관련 조사에 대한 분석, 실행 중심의 권고 사항, 그리고 경우에 따라 교훈과 하나 이상의 보충 부록을 담습니다.
- 변화 관리—"핵심 인물과 이해관계자의 참여를 통해 조직 변화에 대한 저항을 최소화하는 것"(Business Dictionary n.d.).
- 종료 회의—프로젝트를 시작했을 때와 같은 방식, 즉 팀을 한자리에 모으는 방식으로 프로젝트를 마무리하는 기회입니다. 이 중요한 행사에서 팀은 무엇이 잘되었고 무엇이 잘되지 않았는지 검토하고, 개선할 영역을 파악해야 합니다. 이 모든 내용은 최종 종료 보고서에 요약해야 합니다. 고객과의 최종 종료 회의 또한 필수적입니다. 이를 통해 조직은 프로젝트를 공식적으로 완료하고 향후 있을 수 있는 작업의 토대를 마련할 수 있습니다.
- 종료 보고서—프로젝트 성과에 대한 최종 요약입니다. 이 보고서에는 프로젝트 및 산출물 요약, 일정·비용·품질 관련 성과 데이터, 최종 제품·서비스 또는 프로젝트에 대한 요약과 그것이 조직의 비즈니스 목표를 어떻게 지원하는지, 직면한 위험과 그 완화 방법, 그리고 교훈이 포함되어야 합니다.
- 겐치 겐부쓰(genchi genbutsu)—린(Lean) 방식으로 유명한 도요타 생산 시스템의 핵심 원칙으로, "직접 가서 보라"는 뜻입니다. 다시 말해 프로젝트에서 무슨 일이 일어나고 있는지 정말 알고 싶다면, 팀이 일하는 현장에 실제로 가서 보고 들어야 합니다.
- 프로젝트 감사/검토—프로젝트에 관한 구체적인 정보를 알아내는 것을 목표로, 프로젝트의 일부 또는 모든 측면을 조사하는 것입니다.
- project closure(프로젝트 종료)—대부분의 프로젝트 관리 문헌에 따르면 프로젝트의 마지막 단계입니다. 그러나 프로젝트 생애 주기를 더 넓은 살아 있는 질서의 관점에서 보면, 프로젝트 종료는 프로젝트 전체 생애 주기에서 한 단계가 끝나고 다른 단계로 넘어가는 지점에 불과한 경우가 많습니다. 다만 여러분의 작업이 프로젝트 생애 주기의 정확히 어디에 해당하는지는 애초에 무엇을 "프로젝트"로 보느냐에 따라 달라집니다.
- recovery manager(회복 관리자)—토드 C. 윌리엄스(Todd C. Williams)가 Rescue the Problem Project에서 사용한 용어입니다. 실패하고 있는 프로젝트를 감사하고, 가능하다면 다시 성공의 궤도에 올려놓기 위해 외부에서 영입한 컨설턴트를 가리킵니다(17-19).
- strategic inflection point(전략적 변곡점)—1997년부터 2005년까지 인텔(Intel)의 CEO를 지낸 앤드루 그로브(Andrew Grove)의 정의에 따르면 "기업의 생애에서 그 근본이 막 바뀌려는 시점입니다. 그 변화는 새로운 정점으로 도약할 기회를 의미할 수 있습니다. 그러나 그만큼 종말의 시작을 알리는 신호일 수도 있습니다"(1999, 3). 개별 프로젝트에서 전략적 변곡점이란 프로젝트의 생애에서 그 근본이 막 바뀌려는 시점입니다.
- project auditor(프로젝트 감사자)—감사 또는 검토를 이끄는 책임을 맡은 사람입니다. 이상적으로 프로젝트 감사자는 모든 프로젝트 이해관계자가 공정하고 객관적이라고 인식하는 외부인이어야 합니다. 감사자는 뛰어난 경청 능력과 함께 조직이나 산업에 대한 폭넓은 지식을 갖추어야 합니다.
~참고 문헌
Business Dictionary. 연도 미상. "Change management." BusinessDictionary.com. 2018년 6월 5일 접속. http://www.businessdictionary.com/definition/change-management.html.
Govindarajan, Vijay , and Hylke Faber . 2016. "불확실성 관리: 변화의 시기에 두려움을 다스리는 것에 관해 FDR이 알고 있었던 것(Managing Uncertainty: What FDR Knew About Managing Fear in Times of Change)." Harvard Business Review, 5월 4일. https://hbr.org/2016/05/what-fdr-knew-about-managing-fear-in-times-of-change.
Grove, Andrew S. 1999. Only the Paranoid Survive: How to Exploit the Crisis Points That Challenge Every Company . New York: Doubleday.
Hammon, John S., Keeney, Ralph L. Keeney, and Howard Raiffa. 2015. Smart Choices: A Practical Guide to Making Better Decisions. Cambridge: Harvard Business Review Press.
Harari, Oren. 2003. "18 Lessons: A Leadership Primer, Quotations from Colin Powell." Absolute Advantage. http://www.csun.edu/~alliance/Wellness_Coreteam/Absolute%20Advantage%20Magazine/Articles/Collin%20Powell%2018_lessons.pdf.
Laufer, Alexander, Terry Little, Jeffrey Russell, and Bruce Maas. 2018. 프로젝트 리더 되기: 계획, 민첩성, 회복탄력성, 협업을 결합하여 성공적인 프로젝트 수행하기(Becoming a Project Leader: Blending Planning, Agility, Resilience, and Collaboration to Deliver Successful Projects). New York: Palgrave Macmillan.
Price, Brian. 2007. 엔진 프로젝트 관리 강의 슬라이드, 13주차, 위스콘신 대학교 매디슨 캠퍼스. Madison, 5월 5일.
—, 제프 러셀(Jeff Russell)과 앤 섀퍼(Ann Shaffer)의 인터뷰. 2016. 기술 프로젝트 관리 (9월 2일).
Scrum.org. n.d. "스프린트 회고란 무엇인가?(What is a Sprint Retrospective?)" Scrum.org. 2018년 7월 29일 접속. https://www.scrum.org/resources/what-is-a-sprint-retrospective.
Stanleigh, Michael. n.d. "성공적인 프로젝트 감사 수행하기(Undertaking a Successful Project Audit)." Business Improvement Architects. 2018년 6월 2일 접속. https://bia.ca/undertaking-a-successful-project-audit/.
The Economist. 2009. “Genchi genbutsu.” The Economist, 10월 13일. https://www.economist.com/news/2009/10/13/genchi-genbutsu.
Williams, Todd C. 2011. 문제 프로젝트 구하기: 프로젝트 실패를 식별하고 예방하며 회복하기 위한 완벽한 가이드(Rescue the Problem Project: A Complete Guide to Identifying, Preventing, and Recovering from Project Failure). New York: AMACOM.