Lessons Learned란 무엇인가? 프로젝트 실패를 반복하지 않는 방법

프로젝트를 성공적으로 완료했다고 해서 모든 업무가 끝나는 것은 아닙니다.

 

오히려 우수한 기업일수록 프로젝트 종료 이후에 반드시 수행하는 업무가 있습니다. 바로 Lessons Learned(교훈 도출)입니다.

 

많은 신입 엔지니어나 프로젝트 담당자는 "프로젝트가 끝났는데 왜 또 회의를 하지?"라고 생각하기도 합니다. 하지만 Lessons Learned는 단순한 회고가 아니라, 다음 프로젝트의 품질과 생산성을 높이는 가장 중요한 자산입니다.

 

이번 글에서는 Lessons Learned의 의미와 작성 목적, 실제 플랜트 프로젝트에서는 어떤 내용을 기록하는지 알아보겠습니다.

 

 

Lessons Learned란 무엇인가?

 

Lessons Learned란 프로젝트를 수행하면서 발생했던 성공 사례와 실패 사례를 체계적으로 정리하여 향후 프로젝트에 활용하기 위한 문서를 의미합니다.

 

쉽게 말하면,

"이번 프로젝트에서 무엇이 잘 되었고, 무엇이 문제였으며, 다음에는 어떻게 개선할 것인가?"

 

를 기록하는 문서입니다.

 

미국의 PMI(Project Management Institute)에서도 프로젝트 종료 단계(Project Closing)에서 Lessons Learned를 수행하여 조직의 지식 자산(Organizational Process Assets)을 축적하도록 권장하고 있습니다.

 

즉, 프로젝트가 끝나는 순간 경험도 함께 끝나는 것이 아니라, 조직의 자산으로 남기기 위한 과정입니다.

 

 

왜 Lessons Learned가 중요한가?

 

플랜트 프로젝트는 수백 명에서 수천 명이 참여하는 대규모 사업입니다.

 

같은 실수를 반복한다면 손실 규모 역시 매우 커집니다.

 

예를 들어,

 

• P&ID 변경사항 전달 누락
• Vendor Data 제출 지연
• 구매 일정 지연
• 시공 간섭 발생
• FAT 일정 변경
• Commissioning 중 예상치 못한 Trouble

이러한 문제들은 대부분 이전 프로젝트에서도 발생했던 사례인 경우가 많습니다.

 

하지만 Lessons Learned가 제대로 관리된다면 동일한 문제가 반복될 가능성을 크게 줄일 수 있습니다.

 

결국 Lessons Learned의 목적은 "실패를 기록하는 것이 아니라, 성공 확률을 높이는 것"입니다.

 

 

Lessons Learned에는 무엇을 작성할까?

 

기업마다 양식은 조금씩 다르지만 일반적으로 다음과 같은 내용을 기록합니다.

 

항목	내용
Issue	무슨 문제가 발생했는가
Cause	원인은 무엇인가
Impact	일정, 비용, 품질에 어떤 영향을 주었는가
Action Taken	어떻게 대응했는가
Recommendation	다음 프로젝트에서는 어떻게 개선할 것인가
Owner	누가 관리할 것인가

 

여기서 가장 중요한 것은 Recommendation입니다.

 

문제를 적는 것보다 재발 방지 방안을 구체적으로 작성해야 Lessons Learned의 가치가 생깁니다.

 

 

플랜트 프로젝트에서는 어떤 사례가 있을까?

 

사례 ① Vendor Drawing 제출 지연

문제 : Vendor의 Drawing 제출이 3주 지연되어 배관 설계 일정이 늦어졌습니다.

 

원인 : Vendor 계약 시 제출 일정(MDR)이 충분히 관리되지 않았습니다.

 

개선안

 

• Kick-off Meeting에서 제출 일정 재확인
• Vendor Data Tracking Sheet 운영
• 지연 시 Escalation 절차 마련

 

사례 ② P&ID Revision 관리 미흡

문제 : 현장에서는 최신 Revision이 아닌 이전 Revision을 기준으로 시공을 진행했습니다.

 

영향 : 재시공(Rework)이 발생하여 비용이 증가했습니다.

 

개선안

 

• Revision 관리 절차 강화
• Document Controller 승인 절차 개선
• 최신 도면 자동 배포 시스템 운영

 

사례 ③ HAZOP Action Item 관리 부족

문제 : HAZOP Action Item 일부가 설계 완료 이후까지 남아 있었습니다.

 

영향 : Commissioning 직전에 설계 변경이 발생했습니다.

 

개선안

 

• Action Item Tracking Sheet 운영
• 설계 완료 전 반드시 Close Out 확인
• 정기 Review Meeting 수행

 

 

성공 사례도 반드시 기록해야 한다

 

많은 사람들이 Lessons Learned를 실패 사례 모음이라고 생각합니다.

 

하지만 실제로는 성공 사례(Best Practice)를 기록하는 것이 더욱 중요합니다.

 

예를 들어,

 

• Modular Construction으로 공기를 단축한 사례
• Vendor와 Weekly Meeting으로 납기를 개선한 사례
• BIM Clash Check를 통해 재시공을 줄인 사례
• 조기 위험 식별(Risk Identification)로 설계 변경을 최소화한 사례

이러한 경험은 다음 프로젝트에서도 그대로 활용할 수 있는 조직의 경쟁력이 됩니다.

 

 

Lessons Learned는 언제 작성할까?

 

일반적으로 프로젝트 종료(Project Close Out) 단계에서 작성합니다.

 

대표적인 시점은 다음과 같습니다.

 

• Mechanical Completion 이후
• Start-up 완료 이후
• Performance Test 완료 이후
• Final Acceptance 이후
• Project Close Out 직전

대규모 EPC 프로젝트에서는 전체 프로젝트 종료 시점뿐 아니라 Engineering, Procurement, Construction, Commissioning 등 단계별로 Lessons Learned Workshop을 실시하는 경우도 많습니다.

 

 

Lessons Learned를 잘 작성하는 방법

 

효과적인 Lessons Learned를 작성하려면 다음 원칙을 지키는 것이 좋습니다.

 

• 문제보다 원인을 먼저 분석합니다.
• 개인이 아닌 프로세스를 개선하는 관점에서 작성합니다.
• 가능한 한 정량적인 데이터를 포함합니다.
• 재발 방지 방안을 구체적으로 작성합니다.
• 다른 프로젝트에서도 적용 가능한 형태로 정리합니다.

단순히 "소통이 부족했다"와 같은 추상적인 표현보다, "Vendor Drawing 승인 리드타임이 평균 12일로 계획 대비 5일 초과되었으므로 승인 책임자를 명확히 지정한다."처럼 구체적으로 작성하는 것이 훨씬 실질적인 도움이 됩니다.

 

 

Lessons Learned와 Post Project Review의 차이

 

많은 사람이 두 용어를 혼용하지만 목적에는 차이가 있습니다.

 

구분	Lessons Learned	Post Project Review
목적	지식 축적 및 재발 방지	프로젝트 성과 평가
초점	성공·실패 사례와 개선 방안	일정, 비용, 품질 달성 여부
산출물	Lessons Learned Register	프로젝트 종료 보고서
활용	향후 프로젝트에 적용	프로젝트 성과 분석 및 평가

 

즉, Post Project Review가 프로젝트의 결과를 평가하는 활동이라면, Lessons Learned는 미래 프로젝트의 개선을 위한 지식 관리 활동이라고 이해하면 됩니다.

 

 

마무리

 

플랜트 프로젝트는 동일한 실수를 반복하지 않는 것이 경쟁력입니다.

 

Lessons Learned는 단순히 프로젝트를 마무리하기 위한 문서가 아니라, 조직의 경험을 체계적으로 축적하고 다음 프로젝트의 품질과 효율을 높이는 핵심 도구입니다. PMI의 프로젝트 관리 프레임워크에서도 프로젝트 종료 단계에서 교훈을 문서화하여 조직의 지식 자산으로 관리할 것을 권장하고 있으며, 이를 통해 일정 지연, 비용 증가, 품질 문제와 같은 반복 리스크를 줄일 수 있습니다.

 

프로젝트가 끝났다면 "무엇을 했는가"보다 "무엇을 배웠는가"를 남기는 것이 더욱 중요합니다. 그 기록이 다음 프로젝트의 성공 가능성을 높이는 가장 가치 있는 자산이 되기 때문입니다.