문제를 만들어 낸 것과 같은 수준의 사고로는 그 문제를 해결할 수 없습니다.
—알베르트 아인슈타인(1946)

C.1 어려움에 처한 프로젝트 식별하기

가장 성공적인 프로젝트 관리자라도 자신이 맡은 동안 통제 불능 상태로 치닫는 것처럼 보이는 프로젝트를 겪어 보았을 가능성이 큽니다. 또는 이미 실패 직전에서 흔들리고 있는 프로젝트에 투입되어 이를 넘겨받으라는 요청을 받았을 수도 있습니다. 돌이켜 보면 그러한 프로젝트에 나타난 문제의 징후와 프로젝트를 살리는 데 필요한 조치가 명백해 보일 수 있지만, 프로젝트가 어려움에 처해 있음을 인식하고 이를 다시 궤도에 올려놓겠다고 결심하는 것은 쉽지 않은 첫걸음일 수 있습니다.

프로젝트 관리 문헌은 어려움에 처한 프로젝트를 구제하는 일에 관해 많은 것을 다루고 있습니다. 흔히 초점은 프로젝트에서 발생한 문제의 근본 원인을 식별하는 일의 중요성에 맞춰지는데, 마치 해결책이 그저 "고치기"만 하면 되는 문제의 밑바닥까지 파고드는 데 있다는 듯합니다. 현실은 대개 훨씬 더 복잡하며, 위험에 처한 프로젝트가 겪는 어려움에도 여러 단계가 있어서, 핵심 팀원의 이탈이나 연료유 가격의 급등처럼 하나의 주요 변수로 인해 생기는 문제부터 프로젝트 내부와 외부의 수많은 변수가 상호 작용하여 생기는 문제에 이르기까지 다양합니다.

이러한 변수는 프로젝트의 성격, 프로젝트 팀, 이해관계자, 조직, 그리고 프로젝트가 진행되는 전반적인 환경에 따라 셀 수 없이 다양한 방식으로 상호 작용할 수 있습니다. 예를 들어 주요 프로젝트 이해관계자가 더 이상 관여하지 않아 프로젝트 팀이 고객에게 가치를 전달하는 데 두었던 초점에서 점차 멀어지게 되면, 프로젝트가 위험에 처할 수 있습니다. 그 표류는 범위 크리프로 이어질 수 있고, 범위 크리프는 다시 더 이상 프로젝트 예비비로 흡수할 수 없는 비용 및 일정 초과로 이어집니다. 프로젝트 관리자의 부실한 의사소통이 이러한 문제를 악화시킬 수 있으며, 고객과 프로젝트 팀이 프로젝트 초기에 성공을 명확하게 정의하지 못한 것 또한 마찬가지로 문제를 악화시킬 수 있습니다.

때로는 그 자체로는 무해했을 요인들의 상호 작용에 문제가 있기도 합니다. 예를 들어, 공급업체의 독점 기술로 산출물을 만들도록 그 업체를 고용해 성공을 거둘 수도 있습니다. 또는 그 대신 과정과 결과를 확실히 이해할 수 있도록 자체 기술을 사용하여 내부에서 직접 수행하기로 선택할 수도 있습니다. 어느 쪽을 선택하든 문제가 없을 수 있습니다. 그러나 공급업체를 고용하여 그들이 이해하지 못하는 여러분의 기술을 사용하게 하면 재앙을 초래할 수 있습니다.

수많은 프로젝트 변수와 그 상호 작용의 복잡성 때문에 프로젝트에 존재하는 문제의 전체 규모를 이해하기가 매우 어려울 수 있으며, 프로젝트를 다시 궤도에 올려놓기 위한 최선의 접근 방식을 파악하기는 더더욱 어렵습니다. 그런데 인지 편향에 눈이 가려져 있다면 상황을 완전히 이해하는 것은 거의 불가능합니다.

인지 편향 피하기

앞선 강의에서 이미 인지 편향, 즉 사고의 오류가 사람들이 프로젝트 위험을 명확하게 이해하지 못하도록 어떻게 방해하는지 살펴보았습니다. 예를 들어, 확증 편향(자신의 선입견을 뒷받침하는 정보에만 주의를 기울이는 경향)은 통제의 환상을 불러일으켜, 프로젝트가 잘 진행되고 있지 않을 때조차 팀이 프로젝트가 순조롭다고 믿게 만들 수 있습니다(Virine, Trumper and Virine 2018). 프로젝트를 관리하는 동시에 옹호하려는 프로젝트 관리자나 특정 접근 방식에 이해관계가 걸린 팀은 자신의 프로젝트가 곤경에 처해 있다는 사실을 알아차리지 못할 수 있습니다. 설령 문제를 감지하더라도, 확증 편향 때문에 기존 프로젝트를 뒤엎지 않아도 상황이 나아질 것이라고 착각할 수 있습니다. 한편, 계획 오류는 망상에 가까운 낙관주의를 부추겨, 실제로는 프로젝트가 걷잡을 수 없이 통제를 벗어나고 있는데도 모두가 아무 문제가 없다고 믿게 만듭니다. 보수주의(새로운 증거보다 이미 익숙한 증거에 더 큰 비중을 두는 것)나 집단사고(상당수의 사람들이 이미 어떤 믿음을 가지고 있다는 이유로 그 믿음을 받아들이는 것)와 같은 다른 인지 편향은 상상력을 제한하여, 지금은 사소해 보이는 일이 어떻게 심각한 문제로 번질 수 있는지 예견하지 못하게 만들 수 있습니다. 또한 인지 편향 때문에 겉보기에 서로 관련 없어 보이는 일련의 문제들이 종합적으로는 프로젝트가 심각한 위기에 처해 있음을 가리킬 수 있다는 사실을 깨닫지 못할 수도 있습니다.

프로젝트 관리자로서 여러분은 자신의 편향뿐만 아니라 프로젝트에 관한 정보를 제공하는 사람들의 편향도 경계해야 합니다. 인지 편향에 관한 획기적인 연구로 노벨상을 수상한 대니얼 카너먼은 인지 편향의 영향에 대응하는 가장 효과적인 방법 중 하나가 참조 집단 예측임을 보여 주었습니다. 이는 여러분과 팀이 예측한 결과를 제쳐 두고, 대신 유사한 프로젝트들의 실제 결과를 분석하여 결과를 예측하는 방법입니다. 외부 관점 취하기라고도 알려진 이 결과 예측 방식은 "계획 수립자가 과거의 유사한 사업들로 이루어진 참조 집단을 식별하고, 그 사업들의 결과 분포를 파악한 다음, 당면한 프로젝트를 그 분포상의 적절한 지점에 위치시킬 것을 요구합니다"(Lovallo and Kahneman, 2003). 올바른 참조 집단, 즉 관련 프로젝트들의 올바른 그룹을 선택하려면 프로젝트 리더가 많은 변수를 따져 보아야 하지만, 결국에는 판단의 문제로 귀결됩니다.

여러분이 새로운 공정 기술을 도입한 올레핀 공장 건설을 검토하는 화학 회사의 관리자라면, 본능적으로 현재 가동 중인 올레핀 공장들이 참조 집단에 포함되어야 한다고 생각할 수 있습니다. 그러나 실제로는 새로운 공정 기술로 건설된 다른 화학 공장들을 살펴보는 편이 더 나은 결과를 얻을 수 있습니다. 다시 말해, 공장의 결과는 무엇을 생산하느냐보다 기술이 얼마나 새로운가에 더 큰 영향을 받을 수 있습니다. 핵심은 의미가 있으면서도 당면한 프로젝트와 진정으로 비교할 수 있을 만큼 충분히 좁은 집단을 선택하는 것입니다. (Lovallo and Kahneman, 2003)

인지 편향의 힘을 인식하고 참조 집단 예측을 활용해 그 영향에 대응하면, 여러분과 팀이 어려움에 처한 프로젝트를 제대로 이해하는 데 도움이 됩니다. Terry Little은 혁신적인 미국 공군 프로그램 관리자로서 실패해 가는 프로젝트를 구해내는 일로 경력을 쌓았으며, 진정한 이해가 성공의 필수 전제 조건이라는 사실을 일찍이 깨달았습니다. 그는 정체된 순항 미사일 프로그램을 되살리기 위해 자신이 내디딘 첫걸음을 다음과 같이 설명했습니다.

한 집단의 사람들이 현실을 인식하는 방식을 바꾸는 것은 결코 작은 일이 아닙니다. 하지만 이것은 어려움에 처한 프로젝트를 실패의 벼랑 끝에서 되돌리는 임무를 맡은 리더가 해야 할 첫 번째이자 가장 중요한 일입니다.

문제의 징후 포착하기

실패한 프로젝트의 문제는 나중에 돌이켜 보면 너무나도 명백한 경우가 많지만, "때로는 프로젝트 안에 있으면서 그것을 매일 관리하다 보면 실제로 무슨 일이 일어나고 있는지 보기가 매우 어려워집니다. 세부 사항에 너무 가까이 있기 때문입니다"(Harrin n.d.). 매일 쏟아지는 세부 사항에 눈이 가려지지 않도록 하려면, 이따금 멈춰 서서 프로젝트를 구제가 필요하다는 신호인 경우가 많은 것으로 알려진 문제 유형 목록과 비교해 보는 것이 도움이 될 수 있습니다.

• 프로젝트가 예산을 크게 초과했으며, 다시 정상 궤도로 되돌릴 가능성이 거의 없습니다.
• 프로젝트 팀이 기본적인 성과 지표나 주요 마감일/마일스톤을 번번이 놓치고 있습니다.
• 프로젝트 범위가 계속 바뀝니다.
• 프로젝트에서 무엇을 인도하려 하는지 제대로 설명할 수 있는 사람이 아무도 없으며, 프로젝트의 요구 사항과 목표를 두고 이해관계자 간에 의견 충돌이 계속되고 있습니다.
• 팀의 사기가 낮고, 팀원들이 서로 단절된 것처럼 보이며, 프로젝트 팀의 이직률이 높아지고 있습니다(Warcholinski n.d.).
• 핵심 이해관계자들이 더 이상 참여하지 않습니다. 회의에 참석하지 않게 되었고, 의사 결정에 참여해 달라는 요청을 받아도 피드백을 거의 주지 않습니다.
• 변경 지시 건수가 늘고 있으며, 최근 몇 주 동안 고객이 여러 건의 프로젝트 청구서에 이의를 제기했습니다(Seador 2019).
• 고위 경영진이 팀원과 기타 자원을 프로젝트에서 빼내고 있습니다.
• 프로젝트 기술이 제대로 작동하지 않습니다.
• 엉뚱한 사람들이 엉뚱한 역할을 맡고 있어 프로젝트를 성공적으로 수행하지 못하고 있습니다.
• 아직 문제를 찾아내지 못했더라도 정보에 기반한 직관이 프로젝트에 무언가 잘못되었다고 알려 줍니다.

경험 많은 프로젝트 관리자라면 대개 자신만의 경고 신호 목록을 가지고 있으며, 시간이 지나면 여러분도 자신만의 목록을 만들게 될 것입니다. 조직에서 가장 의미 있는 경고 신호가 무엇인지 더 잘 파악하는 한 가지 방법은 11과에서 배운 현장 순회 관리(MBWA, managing by walking around) 방식입니다. MBWA를 꾸준히 실천하면 아직 대응할 시간이 있을 때 경고 신호를 포착할 가능성이 높아집니다. 팀원들과의 즉흥적인 대화나 진행 중인 작업에 대한 비공식적인 검토를 통해 즉각적인 조치나 추가 조사가 필요한 문제를 발견할 수 있습니다.

물론 경고 신호가 있다는 사실만으로 프로젝트가 반드시 위험에 처했다는 뜻은 아닙니다. 정말로 문제가 되는 것은 뚜렷한 해결책이 보이지 않는 채로 "전반적으로 커져 가는 불안감"을 키우는 문제들이 지속되는 상황입니다. Matt Warcholinski에 따르면, 그 문제들을 활용해 "프로젝트가 왜 실패하고 있는지 분석"하고 그에 대한 대처 방안을 찾아내기만 한다면, 프로젝트의 문제 지점이 곧 프로젝트의 실패를 의미하지는 않습니다(Warcholinski, n.d.). 다시 말해, 문제를 찾아냈다면 그 문제를 확실히 이해해야 합니다.

C.2 문제 이해하기

문제를 이해한다는 것은 무엇을 의미합니까? 무엇보다도 먼저 문제를 맥락 속에서 바라보아야 합니다.

맥락의 여러 층위 살펴보기

1과에서 배운 것처럼, 프로젝트의 맥락은 프로젝트가 전개되는 일상적인 환경과 더 큰 조직적 배경으로 이루어집니다. 그림 C-1은 하나의 프로젝트를 둘러쌀 수 있는 여러 층위의 맥락을 보여 줍니다.

그렇다면 분명히, 문제를 식별하는 것은 시작에 불과합니다. 문제가 프로젝트 팀, 프로젝트 자체, 프로그램이나 포트폴리오, 사업부, 조직, 고객, 주주, 나아가 일반 대중에게까지 어느 정도로 영향을 미치고 있는지 이해하기 전에는 그 문제를 제대로 이해할 수 없습니다. 이러한 큰 그림을 보지 않고 문제를 "해결"하려는 프로젝트 리더는 뒤편에서 산불이 맹렬히 번지고 있는데 불씨 하나를 밟아 끄는 데만 열중하는 공원 관리원과 같습니다.

문제가 있는 팀 역학을 다룰 때는 맥락이 특히 중요합니다. 팀 내 긴장은 프로젝트 관리자와 팀 사이, 그리고 팀원들 사이에 의사소통 문제를 일으킬 수 있으며, 이러한 문제는 바깥으로 퍼져 나가 재작업, 마일스톤 미달성, 비용 초과로 이어집니다. 그리고 이러한 문제는 다시 불만과 팀 기능 장애로 이어질 수 있으며, 이 모든 것이 프로젝트(또는 프로젝트의 프로그램이나 포트폴리오 전체)를 위험에 빠뜨릴 수 있습니다.

프로젝트에서 바깥으로 문제가 퍼져 나간 사례는 Revlon에서 일어났습니다. Revlon은 새로운 회사인 Elizabeth Arden을 인수한 뒤, 변경 사항을 점진적으로 도입하여 직원들이 새 시스템을 단계적으로 익힐 수 있게 하는 대신, 인수한 회사의 시스템을 자사 ERP에 단번에 통합하는 작업을 밀어붙였습니다. 모든 것을 한꺼번에 진행했기 때문에 개별 문제가 발생할 때 이를 식별하는 것이 불가능했습니다. 더 나쁜 것은, 이 회사가 실제로 연쇄적으로 발생한 문제에 대처하기 위한 진지한 위험 관리 전략을 전혀 수립하지 못한 것으로 보인다는 점입니다. 거의 즉시, Revlon의 노스캐롤라이나 공장 중 한 곳에서 배송 지연이 발생했습니다. Revlon은 결국 약 6,400만 달러의 매출 손실을 입었고 자사 주주들에게 소송을 당했습니다(Techliance, n.d. 및 Dolfing 2019). 여러 소송 중 하나는 무엇보다도 이 회사가 해당 프로젝트에서 "효과적인 프로세스 수준 통제를 설계하고, 구현하고, 일관되게 운영하지 못했다"고 주장했습니다(Saran 2019).

복잡한 엔지니어링 프로젝트에서 발생한 문제는 조직 이상의 것을 위험에 빠뜨릴 수 있으며, 특히 그 문제가 기술적 결함과 결함 있는 산출물의 형태로 나타날 때 더욱 그렇습니다. 이러한 유형의 문제는 흔히 프로젝트 리더십의 실패로 거슬러 올라갈 수 있으며, 그 영향은 플로리다 국제 대학교 보행자 다리 붕괴 사고에서 볼 수 있듯이 프로젝트와 조직을 넘어 고객, 나아가 일반 대중에게까지 쉽게 미칠 수 있습니다.

근본 원인 식별하기

어려움에 처한 프로젝트의 맥락을 충분히 이해했다면, 프로젝트 문제의 근본 원인을 찾을 수 있습니다. 이 단계에서 여러분의 목표는 문제의 근본 원인을 고쳐 프로젝트를 "바로잡는" 것이 아니라(이는 대개 불가능한 목표입니다), 구하려는 프로젝트를 더 깊이 이해하는 것입니다. 그러한 이해가 없으면 잘못된 문제를 해결하려는 함정에 쉽게 빠질 수 있습니다.

조직 이론가 Russell L. Ackoff는 이 과제를 다음과 같이 설명했습니다. "우리는 올바른 문제에 대해 잘못된 해결책을 내놓아서보다 잘못된 문제를 해결하기 때문에 더 자주 실패한다"(1974, 8). 올바른 문제를 해결하려면 여러분과 팀이 직면한 문제의 근본 원인에 도달하기 위해 핵심적인 질문을 던져야 합니다.

미국품질학회(ASQ)는 근본 원인을 "궁극적으로 문제를 일으키는 원인과 결과의 연쇄 반응 전체를 촉발하는 핵심 사안, 즉 최상위 원인"으로 정의합니다. 근본 원인 분석은 "문제의 원인을 밝혀내는 데 사용되는 다양한 접근 방식, 도구, 기법을 통칭하는 용어"입니다. (n.d.)

Todd C. Williams는 Rescue the Problem Project에서 실패하고 있는 프로젝트를 회복시키기 위한 노력의 초기에 근본 원인 분석을 수행하는 것이 얼마나 중요한지 논의합니다.

John Nelson은 실패하고 있는 프로젝트의 근본 원인을 찾을 때 장기적인 관점을 취할 것을 권장합니다.

프로젝트 팀 및 기타 이해관계자 참여시키기

프로젝트 팀 및 기타 이해관계자와 소통하여 프로젝트의 맥락과 문제의 근본 원인에 대한 그들의 견해를 듣지 않고서는 해결하려는 문제를 명확하게 이해할 수 없습니다. 이러한 초기 참여는 해결책을 실행하는 데 필요한 변화에 모든 사람이 동참하도록 만드는 데 꼭 필요한 첫 단계이기도 하며, 그 결과 최종적으로 성공할 가능성을 높여 줍니다. Moira Alexander가 TechRepublic 기고문에서 언급했듯이, ”팀이 결정이나 해결책에 영향을 미칠 수 있을 때, 팀은 두려움을 극복하고 자신의 에너지를 활용하여 문제를 더 빠르게 해결할 수 있습니다“(Alexander 2019).

팀 및 이해관계자와 소통한다는 것이 이미 파악한 문제 목록을 단순히 제시하는 것을 의미하지는 않는다는 점을 명심하십시오. 그 대신 핵심 인물들에게 함께 프로젝트가 겪는 어려움에 대한 대안적 설명을 도출하자고 요청하십시오. 이렇게 하면 자신의 확증 편향을 극복하는 데 도움이 되어, 핵심 문제를, 그리고 궁극적으로는 최적의 대응 방안을 찾아낼 가능성이 높아집니다. (Larson and Gray, 2011, 393). 이 작업을 시작할 때 "무책(no fault)" 문화를 확립하면 팀이 문제를 더 빠르게 파악하는 데 도움이 되고, 해결책 개발 단계로 넘어갈 때 협업을 촉진할 수 있습니다(Lloyd-Walker, Mills and Walker 2014). ­­

C.3 대안 평가 및 계획 수립

프로젝트의 문제를 확실히 이해했다면, 앞으로 나아가기 위한 선택지를 검토해야 합니다. 13과에서 논의했듯이, 때로는 어려움에 처한 프로젝트를 중단하는 것이 조직에 가장 좋은 선택입니다. 필요한 자원을 확보할 수 없게 만드는 새로운 수입 할당제, 경쟁사의 신기술 출시, 또는 상당하고 비용이 많이 드는 재작업을 요구하는 프로젝트 도중의 규제 변경과 같은 외부 요인으로 인해 문제에 빠진 프로젝트의 경우, 종료가 유일한 선택지일 수 있습니다. 조직 전략의 변화와 같은 특정 내부 요인 역시 프로젝트 종료 쪽으로 저울을 기울게 하기에 충분할 수 있습니다.

그러나 많은 경우 문제에 빠진 프로젝트는 통제 아래로 되돌려 실패에서 구해 낼 수 있으며, 또 그래야 합니다. Matt Warcholinski에 따르면, "프로젝트 제약 조건에서 트레이드오프를 이끌어 내면서도 여전히" 조직이 요구하는 "결과를 달성할 수 있을 때" 구제 작업을 추진해야 합니다(n.d.). 어려움에 처한 프로젝트가 여전히 조직에 가치가 있다고 판단했다면, 다음 단계는 프로젝트의 이점을 명확히 설명해 핵심 이해관계자가 프로젝트에 다시 전념하도록 설득한 뒤, 프로젝트를 실패에서 구해 낼 계획을 수립하는 것일 수 있습니다.

계획을 수립할 때는 특정 활동의 가치를 고려하여 프로젝트를 재개하기 전에 중단해야 할 일이 무엇인지 파악하십시오. 이렇게 하면 자원이 확보되고 팀이 중요한 일에 집중할 수 있습니다. 단순히 더 많은 작업과 업무를 쌓아 올리기만 하는 해결책이 제안되지 않는지 주의 깊게 살피십시오. 특정 문제가 다시 발생하지 않도록 추적과 모니터링을 더 많이 부과하는 것이 그 예입니다. 그러한 작업이 필요할 수도 있지만, 회복 계획에 추가하기 전에 그것이 가치를 더하는지 반드시 확인하십시오. 또한 이른바 만능 해결책도 경계하십시오. 이 부록의 앞부분에서 언급했듯이, 단 하나의 사건이나 문제가 프로젝트를 실패 직전까지 몰고 갔을 가능성은 낮습니다. "대개는 복잡하게 얽힌 일련의 문제가 결합하여 총체적으로 실패를 초래합니다"(McGrath and Martin, n.d.). 제안된 회복 계획은 이 점을 고려해야 합니다.

시나리오 계획

상당한 범위 변경을 고려하고 있다면, 이해관계자와 함께하는 시나리오 계획(때로는 "가정 분석(what-if analysis)"이라고도 합니다)이 기대 사항을 명확히 하고 의도하지 않은 결과를 피하는 데 도움이 될 수 있습니다. 이는 압박 속에서 변경을 신속하게 해야 하는 경우에 특히 중요합니다. 다양한 선택지(아무것도 하지 않기, 하나 이상의 시정 조치 시행, 프로젝트 종료 등)에 대해 각각 위험 확률을 붙여 예상 결과 시나리오를 실행하면, 증상을 해결하는 데 그치지 않고 고려 중인 변경의 영향을 평가하는 단계로 나아가는 데 도움이 될 수 있습니다.

시나리오 계획은 미래가 현재와 같지 않을 것이라는 전제에서 출발하며, 그 범위는 "하나 이상의 활동 기간을 변경했을 때의 효과를 단순히 평가하는 것에서부터 기간 불확실성을 도입하거나 현재까지의 성과를 바탕으로 프로젝트 예측을 실행하는 것과 같은 보다 복잡한 분석"에 이르거나, 식별된 프로젝트 위험과 전사적 위험을 고려하는 일정 및 비용 위험 분석을 수행하는 것까지 다양합니다(Røberg 2017). 회복 계획을 확정하기 전에 각 선택지의 위험과 이점을 평가하는 것은 프로젝트를 정상 궤도로 되돌리는 데 결정적일 수 있습니다. 프로젝트가 실패하고 있을 때 시나리오 계획은 사치처럼 보일 수 있지만, 프로젝트 팀과 이해관계자가 제안된 해결책의 잠재적 영향과 위험을 충분히 고려하지 않은 채 어려움에 처한 프로젝트를 구하는 최선의 방법을 서둘러 결정하면 결국 상황이 더 악화될 수 있습니다.

레드 팀 구성

이 중요한 단계에서 집단사고와 기타 편향에 맞서기 위해, 프로젝트 복구 팀을 지원할 외부 레드 팀을 구성하는 것을 고려하십시오. Bryce Hoffman이 그의 저서 Red Teaming에서 설명했듯이, 레드 팀의 역할은 "아이디어와 결정이 옳아 보이든 그렇지 않든 대안적 관점으로 이에 반박하는 것"입니다(TechTarget 2017). 레드 팀 접근 방식은 복구 팀이 가능한 시나리오를 검토하고 구조 계획을 수립하는 동안 "가정을 냉철하게 살펴보고, 계획이 실패할 수 있는 경우를 검토하며, 대안적 설명과 관점을 신중하게 고려하도록" 하는 데 도움이 됩니다(Hoffman 2017). 복구 팀 내부에서 누군가를 선의의 비판자(devil's advocate)로 지정하여 비슷한 이점을 얻을 수도 있습니다. 그 목적은 팀원들이 "문제의 다른 측면을 고려하고, 자신의 견해에 대해 더 깊이 생각하며, 어쩌면 이전에는 고려하지 않았을 해결책을 탐색하도록 자극받게" 하는 것입니다(Business News Daily 2020).

다만 이러한 접근 방식은 서로를 신뢰하는 팀원들이 있는, 협업이 강한 문화에서만 성공할 수 있다는 점을 명심하십시오. 자신감 있고 유연한 팀은 레드 팀이나 선의의 비판자가 제기하는 진지한 비판을 견뎌 내고, 함께 협력하여 상황을 개선할 수 있습니다. 반면에 모든 세부 사항에 대한 통제권을 고수하는, 다 안다고 자부하는 사람들로 구성된 팀은 이러한 접근 방식에서 이점을 얻을 만큼 적응력이 있는 경우가 드뭅니다. 그런 경우에는 한발 물러서서 적합한 사람이 적합한 역할을 맡고 있는지 판단하고, 진행하기 전에 필요에 따라 변경해야 할 수도 있습니다.

이해관계자의 동의 얻기

어려움에 처한 프로젝트에 중대한 변경을 도입하려면 이해관계자의 합의가 필요하며, 이 합의는 협상을 통해 이끌어 냅니다(William 2011, 185). 이 단계에서 협상 주제가 될 가능성이 높은 것 중 하나는 프로젝트 범위입니다. 여기에는 수정된 프로젝트 범위에 포함될 산출물과, 프로젝트를 정상 궤도로 되돌리기 위해 프로젝트에서 제외해야 하는 산출물이 모두 포함됩니다. 협상이 필요할 수 있는 다른 항목으로는 수정된 예산과 일정, 새로운 작업 프로세스의 수립, 그리고 기술이나 공급업체를 교체할지에 대한 결정이 있습니다. 회복 계획을 수립하는 맥락에서, 12강에서 다룬 원칙 협상 접근법은 긴장을 완화하고 모든 당사자가 입장이 아닌 이익에 집중하도록 돕습니다. 이러한 이익은 객관적인 기준에 따라 평가할 수 있습니다. 협상 전반에 걸쳐 최적의 해결책에 도달하고 프로젝트를 진전시키는 데 필요한 동의를 얻으려면 의사소통 및 설득 능력과 감성 지능을 활용해야 합니다.

C.4 회복 계획 확정

Todd C. William이 Rescue the Problem Project에서 말했듯이, "프로젝트 회복의 핵심은 변화입니다….변화가 없으면 프로젝트는 계속 실패할 것입니다."(2011, 185). 필요한 수준의 변화를 만들어 내려면 상세한 회복 계획이 필요하며, 이 계획은 "기존 프로젝트 계획과 필연적으로 다릅니다"(10). William에 따르면, 회복 계획은 "수정할 영역을 정의하고 원하는 결과를 달성하기 위해 프로젝트와 제품의 변경 사항을 권고"하며, 다음 내용을 포함해야 합니다(82, 184):

요컨대, 프로젝트를 정상 궤도로 되돌리고 새로운 문제를 피하려면 상세한 요구 사항과 명확한 성공의 정의, 그리고 새로 정한 프로젝트 산출물의 인수 기준을 갖춘 회복 계획이 필요합니다. 또한 새로운 일정과 예산을 수립하고, 무엇을 먼저 처리할지 우선순위를 정하고, 자원을 재배치하거나 추가하며, 새로운 작업 프로세스와 기대 사항을 팀에 전달해야 합니다.

포괄적인 회복 계획을 수립하기 위해, 위스콘신 대학교 매디슨 캠퍼스의 수석 비즈니스 분석가인 Robert Merrill은 이 작업을 "백지 계획"으로 접근할 것을 제안합니다. Merrill은 "사실상 새로운 프로젝트를 맡게 되는 것입니다(이전 프로젝트가 남긴 혼란을 정리하는 일까지 포함해서)."라고 설명합니다. 하지만 원래 프로젝트를 시작할 때보다 훨씬 많은 지식을 가지고 시작한다는 이점이 있으므로, 또 다른 어려움에 처한 프로젝트를 만들어 내는 일을 피하기에 더 유리한 위치에 서게 됩니다(개인 서신, 2020년 3월 28일).

백지 계획 방식으로 회복 계획을 수립하더라도 원래 프로젝트 문서 중 상당수를 활용해야 합니다. 비즈니스 케이스, 계약 또는 작업 기술서, 프로젝트 헌장, 프로젝트 범위 기술서 같은 문서는 회복 계획의 일환으로 개정해야 하더라도, 원래 프로젝트가 만들어 내고자 했던 핵심 가치에 대해 꼭 필요한 관점과 지침을 제공할 수 있습니다.

회복 계획을 수립할 때 필요한 문서 검토에 대한 더 자세한 논의는 Surge ERP Consulting의 다음 백서를 읽어 보십시오. 이 백서는 프로젝트 구제의 첫 단계로 핵심 이해관계자 및 프로젝트 팀원과 함께 문서를 검토할 것을 권장합니다: http://surge-erp.ca/wp-content/uploads/2016/01/Rescuing_a_Troubled_Project-20160115-FINAL.pdf.

C.5 계획 실행하기

회복 계획의 세부 사항과 이를 시행하는 방식은 프로젝트, 조직, 그리고 여러분이 일하는 업계에 따라 상당히 달라집니다. 그러나 어떤 프로젝트든 다시 불거지는 기존 문제와 "해결책"으로 인해 생길 수 있는 새로운 문제를 주의 깊게 살펴야 합니다. 행동상의 문제가 재발할 수 있으며, 응답하지 않는 이해관계자나 문제가 있는 기술과 같은 일부 문제는 해결하기 어렵거나 아예 해결이 불가능할 수도 있습니다(Williams, 2011, 216). 일부 이해관계자는 기존 범위에 이해관계가 걸려 있어 이를 유지하려 할 수 있으며, 특정 접근 방식에 이미 많은 투자를 했다는 이유만으로 무슨 일이 있어도 계속 많은 투자를 해야 한다고 믿는 매몰 비용의 오류에 빠져 있을 수도 있습니다. 회복 계획을 실행하려면 때때로 프로젝트 관리자가 기존 접근 방식을 폐기하는 데 단호한 태도를 보이는 동시에 새로운 접근 방식을 열정적으로 옹호해야 합니다.

커네빈 프레임워크는 회복 과정을 시작하면서 초기 성공에 안주하면 프로젝트 전체가 혼돈에 빠질 수 있음을 상기시킵니다(Snowden과 Boone, 2007). 계획이 아무리 상세하고 프로젝트 팀과 핵심 이해관계자가 회복 계획 수립에 아무리 적극적으로 참여했더라도, 계획을 실행하는 과정에서 새로운 문제가 생깁니다. 회복이 궤도에서 벗어나지 않도록 하려면 변화 관리 전략과 함께 위험 관리에 집중해야 합니다.

실행 단계에서는 기술 프로젝트 관리 업무를 완수하는 것과 더불어 이해관계자의 신뢰와 팀의 사기를 회복하는 일도 해야 합니다. 1과에서 살펴본 것처럼, 살아 있는 질서 속에서 일한다는 것의 일부는 프로젝트 팀원과 기타 이해관계자가 프로젝트의 가치를 이해하고 그 가치를 실현하는 데 전념하도록 하는 것입니다. 회복 계획을 실행하기 시작할 때는 이 점이 더욱 중요합니다.

지금은 소통에 계속 집중해야 할 때입니다. 이는 이해관계자의 참여를 유지하기 위해서이기도 하고, 팀원들이 갱신된 활동과 프로세스를 익히는 과정의 학습 곡선으로 인해 생길 수 있는 새로운 문제와 오류를 줄이기 위해서이기도 합니다. 프로젝트 문서를 갱신하고, 팀이 가장 최신 정보만 접할 수 있도록 하십시오. 오래된 자료는 참고용으로 보관해 둘 수 있습니다. 가상 프로젝트 웹사이트와 프로젝트 대시보드는 프로젝트에 관한 단일 정보 출처를 제공하는 훌륭한 도구이지만, 이는 최신 상태로 유지될 때에만 그렇습니다. 복구 모드로 일하는 프로젝트 팀은 대개 새로운 방향을 제시하는 데는 꽤 능숙하지만, 오래된 정보를 정리하지 못하는 경우가 많아 혼란을 일으키고 프로젝트를 정상 궤도로 되돌리는 데 필요한 작업을 지연시킵니다.

C.6 다음 프로젝트에서 문제 피하기

모든 프로젝트는 프로젝트 종료에 기하학적 질서 접근 방식을 적용함으로써 이점을 얻습니다. 이 방식은 향후 프로젝트를 위해 교훈을 체계적으로 보존하는 것이 중요하다고 강조합니다. 이는 실패 직전에서 되살아난 프로젝트에 특히 해당됩니다.

핵심 프로젝트 활동이나 그 실행, 혹은 단순히 프로젝트 계획과 관리가 어떻게 성공했는지(또는 성공하지 못했는지)와 관련된 것이든, 교훈은 다음 프로젝트를 더 잘 계획하는 데 활용할 수 있는 중요한 정보입니다. 프로젝트의 맥락에서 교훈이란 긍정적이거나 부정적인 경험을 통해 얻은 지식이나 이해를 말하며, 다음과 같은 특성을 지닙니다(Secchi 1999):

프로젝트나 개별 스프린트가 끝날 때 실시하는 사후 검토(after-action review, AAR)나 애자일 회고는 팀원들과 함께 교훈을 정리하는 여러 방법 가운데 두 가지일 뿐입니다. 회의 형식과 관계없이, 목표는 프로젝트 팀 전체가 무엇을 배웠는지, 그리고 다음 프로젝트나 스프린트에서는 무엇을 다르게 할지 되돌아보게 하는 것입니다.

구제된 프로젝트에서 교훈을 문서화하는 일에는 고유한 어려움이 따른다는 점에 주목할 필요가 있습니다. 팀원들이 누군가를 탓하는 것처럼 보이지 않게 문제와 실수를 기록하기가 쉽지 않기 때문입니다. 실제로 배운 것을 제대로 정리하려면 맥락에 민감해야 하며, 그 맥락이 학습에 어떤 영향을 미치는지 살펴야 합니다. 결국 그러한 노력은 프로젝트 관리자와 개별 팀원뿐만 아니라 조직에도 가치 있는 것으로 드러날 것입니다. 다양한 산업 분야에서 경험을 쌓은 오랜 경력의 프로젝트 리더 George Watson은 다음과 같이 말합니다. "실패한 거의 모든 프로젝트에서는 실패 이전에는 고려되지 않았거나 실현조차 불가능했을 새로운 무언가가 생겨납니다. 수년간 저는 프로젝트 관리자가 되기에 가장 좋은 때는 큰 실패 직후라는 것을 깨달았습니다"(개인 서신, 2020년 5월 7일).

실용적인 팁

• 프로젝트가 시작되기 전에 신뢰를 쌓으십시오: 그렇게 할 수 없다면, 프로젝트를 진행하는 동안 정직하게 행동하고 아는 것과 모르는 것을 공유함으로써 신속하게 신뢰를 쌓으십시오. 사람들을 질책하지 말고 진실을 말하십시오. 도움과 의견을 구하고, 그렇게 얻은 정보를 활용하십시오.
• 범위 크리프에 주의하십시오: 작은 변경 사항은 그 자체로는 관리할 수 있어 보이지만, 그것이 쌓이면 프로젝트가 현재 형태로는 더 이상 실행 가능하지 않은 지경에 이를 수 있습니다.
• 회복 팀에 적합한 사람들이 있는지 확인하십시오: 회복 계획을 수립하고 실행하기 전에 적합한 사람들이 적합한 역할을 맡고 있는지 판단하십시오. 같은 안경을 쓴 같은 사람들, 즉 프로젝트와 그 문제에 대해 같은 관점을 제시하는 사람들과 함께 앞으로 나아가려 한다면 아무것도 바뀌지 않을 수 있습니다. 가능하다면 팀을 조정하여 다양한 관점과 기술이 어우러지도록 하십시오. 자신감 있고 유연하며 협업에 열린 사람들이 필요합니다.
• 원래의 프로세스를 평가하십시오: 회복 계획을 수립할 때, 원래 프로젝트의 프로세스에 근본적인 결함이 있었는지, 아니면 단지 실행이 잘못되었을 뿐인지 검토하십시오.
• 사후 판단을 활용하십시오: 잠시 멈추고 다음과 같은 근본적인 질문을 던지십시오. "지금의 조건과 현재 알고 있는 것을 바탕으로 이 프로젝트를 처음부터 계획한다면, 우리는 이 프로젝트를 하겠는가?" 사람들은 프로젝트를 생명 유지 장치에 매단 채 계속 끌고 가려 하는 경우가 꽤 많지만, 같은 조건에서 처음 이 프로젝트를 접했다면 아예 시작하지 않기로 했을 것입니다.
• 증거를 요구하십시오: 때로는 프로젝트가 사람들이 생각하는 만큼 곤경에 처해 있지 않을 수도 있습니다. 프로젝트가 곤경에 처해 있다는 증거가 있습니까, 아니면 곤경에 처해 있지 않다는 증거가 있습니까? 프로젝트를 바로잡을 가치가 있다는 증거가 있습니까? 사람들에게 자신의 결정을 정당화할 구체적인 증거를 제시하도록 하면, 막연한 희망이나 두려움에 기대는 태도에서 벗어나도록 도울 수 있습니다.
• 제대로 작동하지 않는 기술을 경계하십시오: 어떤 프로젝트는 팀이 기술을 구현하는 동시에 그 기술을 고치려 하기 때문에 곤경에 빠집니다. 처음부터 기술이나 프로세스의 성숙도를 객관적으로 평가하면 이러한 상황을 피할 수 있습니다.
• 지나친 복잡성을 경계하십시오: 때로는 프로젝트가 필요 이상으로 복잡합니다. 예를 들어, 변경된 워크플로를 갖춘 새로운 IT 플랫폼을 사용하는 새 급여 프로세스를 구현하라는 요청을 받을 수 있습니다. 이처럼 여러 요소를 한데 묶은 프로젝트는 수많은 이유로 실패할 수 있습니다. 구성 프로젝트들을 분리한 다음, 각각 따로 또는 순차적으로 실행해 보십시오.
• 행동하고 앞으로 나아가십시오: 프로젝트가 곤경에 처했을 때 지나친 자기 성찰과 분석에 빠지는 경우가 너무나 많습니다. 충분히 괜찮은 결정을 내리고 앞으로 나아가십시오. 잘못된 방향에 시간을 허비하는 것은 진행 중인 프로젝트에 큰 비용입니다.
• 소통하십시오: 회복 계획을 실행하려면 지속적이고 철저한 소통이 필요합니다. 새로운 프로세스와 접근 방식에 대한 최신 정보를 제공하는 것만큼이나, 오래된 정보를 확실히 제거하는 것도 중요합니다.

~요약

• 가장 성공적인 프로젝트 관리자들조차도 통제 불능 상태로 치닫는 것처럼 보이는 프로젝트를 맡아 본 경험이 있을 것입니다. 위험에 처한 프로젝트가 겪는 문제의 정도는 핵심 팀원의 이탈이나 연료유 가격의 급등과 같은 단일한 주요 변수로 인한 문제에서부터, 프로젝트 내외부의 여러 다양한 변수들의 상호 작용으로 발생하는 문제에 이르기까지 다양합니다.
• 이러한 변수들은 무수히 많은 방식으로 상호 작용할 수 있으므로, 프로젝트의 위험을 명확하게 이해하기 어렵게 만듭니다. 인지 편향, 즉 사고의 오류는 위험을 인식하는 일을 더욱 어렵게 만들 수 있습니다. 예를 들어, 계획 오류는 현실이 정당화하는 것보다 프로젝트를 훨씬 더 낙관적으로 느끼게 할 수 있으며, 보수성 편향은 새로운 증거보다 이미 익숙한 증거에 더 큰 비중을 두게 할 수 있습니다.
• 인지 편향에 관한 획기적인 연구로 노벨상을 받은 대니얼 카너먼(Daniel Kahneman)은 인지 편향의 영향에 대응하는 가장 효과적인 방법 중 하나가 참조 집단 예측(reference class forecasting)임을 보여 주었습니다. 이는 여러분과 팀이 예측한 결과를 제쳐 두고, 그 대신 유사한 프로젝트들의 실제 결과를 분석하여 결과를 예측하는 방법입니다. 잠시 멈추어 프로젝트를, 구제가 필요한 프로젝트임을 흔히 나타내는 것으로 알려진 문제 유형 목록과 비교해 보는 것만으로도 도움이 됩니다.
• 프로젝트의 문제를 파악했다면, 그 문제를 제대로 이해하고 있는지 확인해야 합니다. 무엇보다도 먼저 문제를 맥락 속에서 바라보아야 합니다. 즉, 그 문제들이 프로젝트 팀, 프로젝트 자체, 프로그램이나 포트폴리오, 사업부, 조직, 고객, 주주, 나아가 일반 대중에게까지 어느 정도로 영향을 미치고 있는지 이해해야 합니다.
• 어려움에 처한 프로젝트의 맥락을 이해하고 나면 프로젝트가 겪는 문제의 근본 원인을 찾을 수 있습니다. 이 단계에서의 목표는 문제의 근본 원인을 해결함으로써 프로젝트를 "고치는" 것이 아니라(이는 대개 불가능한 목표입니다), 구제하려는 프로젝트를 더 깊이 이해하는 것입니다. 그러한 이해가 없으면 엉뚱한 문제를 해결하려는 함정에 쉽게 빠질 수 있습니다. 근본 원인을 찾을 때는 장기적인 관점을 취하는 것이 도움이 되며, 필요하다면 수년 전까지 거슬러 올라가 프로젝트가 통제 불능 상태에 빠지기 시작한 정확한 시점을 찾아야 합니다.
• 해결하려는 문제를 명확히 이해하려면 프로젝트 팀 및 다른 이해관계자와 소통하면서 프로젝트의 맥락과 문제의 근본 원인을 그들이 어떻게 보는지 들어야 합니다. 그렇게 하지 않고서는 문제를 명확히 이해할 수 없습니다. 이러한 초기 소통은 해결책을 실행하는 데 필요한 변화에 모든 사람이 동참하도록 만드는 필수적인 첫 단계이기도 하며, 그만큼 최종적으로 성공할 가능성을 높여 줍니다.
• 프로젝트의 문제를 확실히 이해했다면, 이제 앞으로 나아갈 방안들을 검토해야 합니다. 때로는 프로젝트 종료가 최선의 선택이지만, 잘 구상하고 관리한 구제 계획으로 어려움에 처한 프로젝트를 살릴 수 있는 경우가 많습니다. 범위를 크게 변경하는 것을 고려하고 있다면, 시나리오 계획을 통해 기대치를 명확히 하고 의도하지 않은 결과를 피할 수 있습니다. 이 중요한 단계에서 집단사고와 기타 편향에 맞서려면 프로젝트 회복 팀을 지원할 외부 레드 팀을 구성하는 것을 고려하십시오. 당연히 어떤 구제 계획이든 성공적으로 실행하려면 이해관계자의 동의를 얻는 것이 매우 중요합니다.

용어집

• 확증 편향—사람들이 자신의 선입견을 뒷받침하는 정보에만 주의를 기울이게 만드는 인지 편향, 즉 사고의 오류입니다.
• 보수주의—사람들이 새로운 증거보다 이미 익숙한 증거에 더 큰 비중을 두게 만드는 인지 편향, 즉 사고의 오류입니다.
• 집단사고—상당수의 사람들이 이미 어떤 믿음을 가지고 있다는 이유로 사람들이 그 믿음을 받아들이게 만드는 인지 편향, 즉 사고의 오류입니다.
• 외부 관점—참조 집단 예측을 통해 도출한 결과 예측을 가리키는 용어입니다.
• 계획 오류—사람들이 어떤 일에서 성공할 가능성을 지나치게 낙관하게 만드는 인지 편향, 즉 사고의 오류입니다.
• 회복 계획—원하는 결과를 달성하기 위해 바로잡아야 할 영역을 정의하고 프로젝트와 제품의 변경 사항을 권고하는 계획입니다(William 2011, 82).
• 참조 집단 예측—자신과 팀이 예측한 결과는 제쳐 두고, 대신 유사한 프로젝트들의 실제 결과를 분석하여 결과를 예측하는 방법입니다.
• 근본 원인—“궁극적으로 문제를 일으키는 인과 반응 전체를 촉발하는 핵심 사안, 즉 최상위 원인”(American Society for Quality n.d.).
• 근본 원인 분석— “문제의 원인을 밝혀내는 데 사용하는 다양한 접근 방식, 도구, 기법을 통칭하는 용어”(American Society for Quality n.d.).

~참고 문헌

Ackoff, Russell L. 1974. Redesigning the Future: A Systems Approach to Societal Problems, Volume 10. Hoboken: Wiley.

Alexander, Moira. 2019. “프로젝트 이해관계자에게 나쁜 소식을 전하는 방법.” TechRepublic. 8월 19일. https://www.techrepublic.com/article/how-to-deliver-bad-news-to-project-stakeholders/.

American Society for Quality. n.d. “Cause Analysis Tools.” American Society for Quality. 2020년 4월 21일 접속. https://asq.org/quality-resources/root-cause-analysis/tools.

—. “근본 원인 분석(RCA)이란 무엇인가?.” American Society for Quality. 2020년 4월 28일 접속. https://asq.org/quality-resources/root-cause-analysis.

Anderson, Tim. 2018. “제품 관리자 번아웃을 피하는 방법.” Jama Software. 1월 23일. https://www.jamasoftware.com/blog/avoid-product-manager-burnout/.

Ballestrin, Kim. 2015. “불확실성을 헤쳐 나가며 커네빈으로 문제 해결하기.” The Lean Post. 7월 28일. https://www.lean.org/LeanPost/Posting.cfm?LeanPostId=444.

Business News Daily. 2020. “Speak Up! Dissension Is Key to Successful Teamwork.” Business News Daily. 3월 6일. https://www.businessnewsdaily.com/8594-dissenting-voice-teamwork.html.

Clarizen. 2019. “프로젝트 실패를 조기에 발견하는 방법.” Clarizen. 7월 14일. https://www.clarizen.com/how-to-spot-project-failure-early/.

Cook, Matthew, and John P.T. Mo. 2018. “복잡한 엔지니어링 프로젝트의 생애 주기 위험 예측을 위한 시스템 접근 방식.” Cogent Engineering. 3월 26일. https://www.tandfonline.com/doi/full/10.1080/23311916.2018.1451289.

Dolfing, Henrico. 2019. “Case Study 6: How Revlon Got Sued by Its Own Shareholders Because of a Failed SAP Implementation. Medium. 8월 8일. https://medium.com/@henricodolfing/case-study-how-revlon-got-sued-by-its-own-shareholders-because-of-a-failed-sap-implementation-58b66f1267fa.

Funcheon, Deirdra. 2019. “NTSB: Fatal Miami Bridge Collapse Caused By ‘A Paralyzing Culture of Group-Think’.” Bisnow. 10월 23일. https://www.bisnow.com/south-florida/news/construction-development/miami-bridge-collapse-fiu-101395.

Harrin, Elizabeth. n.d. “실패하는 프로젝트를 구하는 방법.” LiquidPlanner. https://www.liquidplanner.com/explore/resources/how-to-save-a-failing-project/.

Hoffman, Bryce G. 2017. “Red Teaming.” Bryce G. Hoffman. https://brycehoffman.com/books/red-teaming/.

Kenny & Company. 2012. “프로젝트 실패의 경고 신호와 해결 방법.” Kenny & Company. 7월 23일. https://michaelskenny.com/points-of-view/warning-signs-of-project-failure-and-resolution-methods/.

Larson, Erik W., and Clifford F. Gray. 2011. 프로젝트 관리: Managerial Process, 제6판. New York: McGraw-Hill Education.

Laufer, Alexander. 2012. 프로젝트 관리에서 리더십 역할 마스터하기: 놀라운 결과를 내는 실천 방법. Upper Saddle River: FT Press.

Leitch, Rebecca. 2017. “전략적 프로젝트 실패의 다섯 가지 경고 신호와 이를 피하는 방법.” Strategy Execution. 7월 27일. https://www.strategyex.co.uk/blog/pmoperspectives/the-five-warning-signs-of-strategic-project-failure-and-how-to-avoid-them.

Linanne, Ciara. 2019. “Revlon Shares Slide 6.9% After Report of Material Weakness in Financial Controls.” MarketWatch. 3월 24일. https://www.marketwatch.com/story/revlon-shares-slide-65-after-report-of-material-weakness-in-financial-controls-2019-03-19.

Lloyd-Walker, Beverly, Anthony Mills, and Derek Walker. 2014. “건설 혁신 촉진: 프로젝트 얼라이언스에서 협업 행동 동인으로서 무책임 추궁(no-blame) 문화의 역할.” Construction Management and Economics. 32 (3). https://www.researchgate.net/publication/262576462_Enabling_construction_innovation_The_role_of_a_no-blame_culture_as_a_collaboration_behavioural_driver_in_project_alliances.

Lovallo, Dan & Kahneman, Daniel. 2003. “Delusions of Success: How Optimism Undermines Executives’ Decisions.” Harvard Business Review. (6월.) https://hbr.org/2003/07/delusions-of-success-how-optimism-undermines-executives-decisions.

McGrath, John, and Philip Martin. n.d. “프로젝트 실패: 성공의 촉매.” Project Times. 2020년 4월 25일 접속. https://www.projecttimes.com/articles/project-failure-a-catalyst-for-success.html.

National Highway Transportation Safety Board (NTSB). 2019. “Highway Accident Report: Pedestrian Bridge Collapse Over SW 8th Street, Miami, Florida, March 15, 2018.” NTSB. https://www.ntsb.gov/investigations/AccidentReports/Reports/HAR1902.pdf.

Nelson, John. 2020. Ann Shaffer와 Mary Pat Shaffer의 인터뷰. (7월 29일).

Røberg, Oyvind. 2017. “What-If 시나리오 분석이 프로젝트 관리를 개선하는 방법.” Safran. 9월 25일. https://www.safran.com/blog/how-what-if-scenario-analysis-improves-project-management.

Saran, Cliff. 2019 “SAP Disruption Leads to Revlon Class Action Lawsuit.” ComputerWeekly. 5월 31일. https://www.computerweekly.com/news/252464278/SAP-disruption-leads-to-Revlon-class-action-lawsuit.

Seador, Gregory. 2019. “건설 프로젝트 분쟁 피하기.” Risk Management(위험 관리). 10월 1일. http://www.rmmagazine.com/2019/10/01/avoiding-construction-project-disputes/.

Secchi, P., 편. 1999. “경보 및 교훈 회의록: 실패와 문제를 예방하는 효과적인 방법. Technical Report WPP-167.” Noordwijk, The Netherlands: ESTEC.

Snowden, David. 2018. “Dave Snowden의 커네빈® 소개.” Cognitive Edge. http://cognitive-edge.com/videos/cynefin-framework-introduction/.

—. 2019. “커네빈 성 데이비드의 날 2019 (5편 중 1편).” Cognitive Edge. 3월 5일. https://cognitive-edge.com/blog/cynefin-as-of-st-davids-day-2019/.

Snowden, David J., and Mary E. Boone. 2007. “A Leader’s Framework for Decision Making.” Harvard Business Review. https://hbr.org/2007/11/a-leaders-framework-for-decision-making.

Techliance. n.d. “Major ERP Failures to Learn from for Better Implementation.” https://techliance.com/blog/erp-failures/.

TechTarget. 2017. “Red Teaming.” WhatIs.com. https://whatis.techtarget.com/definition/red-teaming.

Virine, Lev, Michael Trumper, and Eugenia Virine. 2018. “프로젝트 관리에서의 휴리스틱과 편향.” PM World Journal. VII (1): 1-11. https://pmworldlibrary.net/wp-content/uploads/2018/01/pmwj66-Jan2018-Virines-heuristics-and-biases-in-project-management.pdf.

Warcholinski, Matt. n.d. “문제에 빠진 IT 프로젝트: 구제해야 할 때와 포기해야 할 때.” Brainhub. https://brainhub.eu/blog/troubled-it-projects-when-to-rescue/.

Weber, Rosina. 2001. “지능형 교훈 프로세스.” ScienceDirect. vol. 20, no.1, pp 17-34. https://www.sciencedirect.com/science/article/abs/pii/S0957417400000464?via%3Dihub.

Williams, Todd C. 2011. 문제 프로젝트 구하기: 프로젝트 실패의 식별, 예방, 회복을 위한 완벽 가이드. New York: AMACOM.