Part 13. 무엇이 프로젝트를 망칠 수 있는가 - Project Risk Review

프로젝트는 설계만 잘한다고 성공하는 것이 아니다

 

• “기술적으로 만들 수 있습니다.”
• “예상 공사비는 약 50억 원입니다.”
• “공사 기간은 약 18개월이면 가능합니다.”

여기까지 검토했다면 이제 프로젝트를 수주할 준비가 거의 끝난 것처럼 보입니다.

 

그런데 마지막으로 한 가지 질문이 남습니다.

 

“그래서 이 프로젝트, 정말 해도 되는 것인가?”

 

기술적으로 가능하고, Scope도 정리했고, Cost와 Schedule까지 계산했습니다.

 

그럼에도 불구하고 프로젝트가 실패하는 경우는 많습니다.

 

설계가 불가능해서가 아닙니다.

 

계약 조건을 잘못 이해했거나, 예상하지 못한 인허가 문제가 발생하거나, 주요 장비의 납기가 늦어지거나, 기존 공장과의 Interface가 예상보다 복잡하거나, 고객의 요구사항이 계속 바뀌는 경우도 있습니다.

 

심지어 각각의 문제만 놓고 보면 해결할 수 있는 수준인데도, 여러 문제가 동시에 발생하면서 프로젝트 전체가 흔들리는 경우도 있습니다.

 

그래서 계약을 체결하기 전에는 마지막으로 프로젝트 전체를 한 번 더 바라볼 필요가 있습니다.

 

이것이 바로 Project Risk Review입니다.

 

 

1. Risk란 무엇인가?

 

프로젝트에서 Risk를 단순하게 생각하면 다음과 같습니다.

“앞으로 발생할 수 있는 불확실한 사건이 프로젝트의 목표에 영향을 줄 가능성”

 

여기서 중요한 것은 아직 발생하지 않았다는 점입니다.

 

예를 들어 다음과 같은 상황이 있다고 해보겠습니다.

 

• 주요 장비의 납기가 늦어질 가능성
• 인허가가 예상보다 오래 걸릴 가능성
• 고객의 요구사항이 변경될 가능성
• 기존 설비와 신규 설비의 연결 조건이 달라질 가능성
• 예상보다 높은 Utility 사용량이 발생할 가능성
• 공사 중 기존 공장의 생산에 영향을 줄 가능성
• 원자재 가격이 상승할 가능성
• 설계 변경으로 공사비가 증가할 가능성

아직 아무것도 발생하지 않았습니다.

 

하지만 발생한다면 Cost, Schedule, Quality, Safety 또는 Project Scope에 영향을 줄 수 있습니다.

 

이러한 불확실성을 사전에 찾아내고, 발생 가능성과 영향을 평가하고, 대응책을 준비하는 것이 Project Risk Management의 핵심입니다.

 

PMI 역시 프로젝트 리스크 관리를 위험을 식별하고, 분석하고, 대응하고, 프로젝트 전반에서 지속적으로 모니터링하는 과정으로 설명하고 있습니다. 또한 Risk는 Cost, Schedule, Quality와 밀접하게 연결되어 있다고 설명합니다.

 

즉, Risk Review는 문제가 발생한 뒤 해결하는 활동이 아닙니다.

 

문제가 발생하기 전에 “만약 이런 일이 발생하면 어떻게 할 것인가?”를 생각하는 과정입니다.

 

 

2. Beer to Zero Project의 Risk Review

 

다시 Beer to Zero Project로 돌아가 보겠습니다. 우리가 계획하고 있는 프로젝트는 기존 맥주 생산시설을 기반으로 무알코올 맥주 생산설비를 추가하는 프로젝트입니다.

 

지금까지 우리는 여러 가지를 검토했습니다.

 

Part 9. Technical Feasibility

우리가 이 기술을 구현할 수 있는가?

 

Part 10. Project Scope

어디까지 우리가 수행해야 하는가?

 

Part 11. Project Cost Estimation

이 프로젝트에는 얼마가 필요한가?

 

Part 12. Project Schedule

언제까지 만들어야 하는가?

 

이제 마지막 질문을 던집니다.

“그런데 이 계획을 방해할 수 있는 것은 무엇인가?”

 

이 질문에서부터 Risk Review가 시작됩니다.

 

 

3. Risk는 어디에서 발생하는가?

 

Risk를 검토할 때 가장 흔한 실수는 단순히 생각나는 문제를 나열하는 것입니다. 예를 들어,

“장비가 늦게 들어오면 어떡하지?”

“공사 중 문제가 생기면 어떡하지?”

 

이런 식으로 접근하면 중요한 Risk를 놓칠 수 있습니다.

 

따라서 먼저 Risk를 발생 원인별로 나누어 보는 것이 좋습니다.

 

프로젝트에 따라 다르지만 일반적인 Engineering Project에서는 다음과 같은 Category로 구분할 수 있습니다.

 

Risk Category	주요 Risk
Technical	기술적 구현 실패, 설계 오류, 성능 미달
Scope	업무 범위 불명확, Scope 변경
Cost	원자재 가격 상승, 예상외 공사비 증가
Schedule	장비 납기 지연, 설계 지연, 공사 지연
Procurement	Vendor 선정 지연, 장비 제작 지연
Construction	공사조건 불량, 기존 설비 간섭
Interface	기존 설비와 신규 설비의 연결 문제
Safety	사고, 위험물질 누출, 작업허가 문제
Regulatory	인허가 지연, 법규 변경
Contract	책임범위 불명확, Liquidated Damages
Customer	요구사항 변경, 승인 지연
Operation	운전성 부족, 유지보수성 문제

 

이렇게 구분하면 Risk를 훨씬 체계적으로 볼 수 있습니다.

 

IEC 31010 역시 Risk Assessment를 위해 다양한 평가 기법을 활용할 수 있도록 하고 있으며, 상황에 따라 적절한 기법을 선택해 불확실한 상황에서 의사결정을 지원하도록 하고 있습니다.

 

 

4. 가장 먼저 봐야 할 것은 Technical Risk

 

엔지니어링 프로젝트에서 가장 먼저 확인해야 하는 것은 역시 Technical Risk입니다.

 

Beer to Zero Project에서 예를 들어보겠습니다.

 

무알코올 맥주를 만들기 위해 새로운 탈알코올 공정을 적용한다고 가정해 보겠습니다.

 

설계상으로는 가능합니다. 그런데 실제 운전에서 다음과 같은 문제가 발생할 수 있습니다.

 

• 목표 Alcohol 함량까지 충분히 낮아지지 않음
• 제품의 Flavor가 기존 맥주와 달라짐
• 처리량이 설계 Capacity에 미달
• 열에 의해 제품 품질이 저하됨
• Utility 사용량이 예상보다 증가
• 연속운전 안정성이 확보되지 않음

이것은 단순한 설계 문제가 아닙니다. 고객이 요구한 제품을 만들 수 있느냐의 문제입니다.

 

따라서 기술적으로 중요한 Risk가 있다면 수주 전에 반드시 확인해야 합니다.

 

필요하다면 다음과 같은 방법을 사용할 수 있습니다.

 

• Pilot Test
• Vendor Reference 확인
• 기존 유사 Plant 운전자료 검토
• Material Balance 검증
• Heat & Mass Balance 검증
• 주요 Equipment 선정 근거 확인
• Process Simulation
• Performance Guarantee 조건 검토

특히 “이론적으로 가능하다”와 “상업 Plant에서 보장할 수 있다”는 완전히 다른 이야기라는 점이 중요합니다.

 

 

5. Cost Risk는 숫자 하나로 끝나지 않는다

 

Part 11에서 Project Cost Estimation을 했습니다.

 

예상 EPC Cost가 50억 원이라고 가정해 보겠습니다.

 

그렇다면 질문은 여기서 끝나지 않습니다.

“50억 원이 정말 50억 원일까?”

 

예를 들어 다음과 같은 상황을 생각해 볼 수 있습니다.

 

처음에는 신규 Equipment 한 대만 설치하면 된다고 생각했습니다.

 

그런데 실제 설계를 시작해 보니 기존 Utility Capacity가 부족합니다. 그러면 Utility 설비를 증설해야 합니다. Utility를 증설하니 Electrical Load가 증가합니다. Electrical Load가 증가하니 Transformer와 MCC도 변경해야 합니다.

 

기존 설비의 Capacity가 부족하니 또 다른 Equipment가 필요할 수도 있습니다. 결국 처음에는 보이지 않았던 비용이 계속 발생합니다. 이것이 Cost Risk입니다.

 

따라서 Risk Review에서는 단순히 “예산이 얼마인가?”가 아니라,

“이 예산을 초과하게 만들 수 있는 요인은 무엇인가?”

 

를 봐야 합니다. 예를 들어 다음과 같은 항목을 확인할 수 있습니다.

 

• 주요 Equipment 가격 변동
• Steel 및 Construction Material 가격
• 환율
• Vendor Quotation 유효기간
• Engineering Man-hour 증가
• Scope Change
• 기존 설비 Modification
• Utility 증설
• 인허가 비용
• 예상하지 못한 Construction Work

그리고 중요한 Risk에는 Contingency를 고려해야 합니다.

 

다만 Contingency는 모든 불확실성을 무조건 돈으로 얹는다는 의미가 아닙니다.

 

Risk를 식별하고 평가한 뒤, 필요한 수준의 예비비를 합리적으로 설정하는 것이 핵심입니다.

 

 

6. Schedule Risk는 “늦어질 가능성”을 보는 것

 

Part 12에서 Project Schedule을 만들었습니다. 예를 들어,

Engineering 4개월
Procurement 8개월
Construction 6개월
Commissioning 2개월

 

총 20개월이라고 해보겠습니다.

 

그런데 실제 프로젝트에서는 각각의 기간이 독립적으로 움직이지 않습니다.

 

예를 들어 주요 Equipment의 납기가 3개월 지연되면, Equipment Delivery Delay → Construction Delay → Commissioning Delay → Start-up Delay로 연결될 수 있습니다.

 

더 심각한 경우에는 고객의 생산계획까지 영향을 받을 수 있습니다.

 

따라서 Schedule Risk에서는 단순히 Activity Duration만 보는 것이 아니라 Critical Path를 봐야 합니다.

 

특히 다음 항목은 중요합니다.

 

• Long Lead Item
• Critical Equipment
• Vendor Drawing Approval
• 고객 승인
• 인허가
• Construction Start 조건
• Shutdown 일정
• Tie-in 작업
• Commissioning 조건

결국 중요한 질문은 이것입니다.

“어떤 작업 하나가 늦어졌을 때 전체 프로젝트가 같이 늦어지는가?”

 

Risk Review에서는 바로 이런 Single Point of Failure를 찾아야 합니다.

 

 

7. Engineering Project에서 의외로 큰 Risk — Interface

 

개인적으로 엔지니어링 프로젝트에서 특히 중요하게 보는 것이 Interface Risk입니다.

 

새로운 Plant를 완전히 새로 만드는 Greenfield Project라면 상대적으로 명확합니다.

 

하지만 기존 공장에 설비를 추가하는 Brownfield Project에서는 이야기가 달라집니다.

 

Beer to Zero Project 역시 기존 맥주 공장을 활용하기 때문에 Interface가 중요합니다.

 

예를 들어,

신규 공정 ↔ 기존 Process
신규 설비 ↔ 기존 Utility
신규 DCS ↔ 기존 Control System
신규 배관 ↔ 기존 Pipe Rack
신규 Electrical ↔ 기존 MCC
신규 설비 ↔ 기존 생산설비

 

이 모든 접점에서 문제가 발생할 수 있습니다.

 

도면상으로는 연결할 수 있습니다.

 

그런데 현장에 가보니 기존 배관이 지나가고 있습니다. 또는 기존 설비의 실제 Nozzle 위치가 오래된 도면과 다를 수도 있습니다. Utility Header Pressure가 설계 당시와 달라졌을 수도 있습니다.

 

이런 문제는 Engineering 단계에서 발견하면 수정할 수 있지만, Construction 단계에서 발견하면 Cost와 Schedule을 동시에 흔들 수 있습니다. 그래서 Brownfield Project에서는 현장조사와 Interface Management가 매우 중요합니다.

 

 

8. Contract Risk를 반드시 같이 봐야 한다

 

이번 PART 2의 제목이 “프로젝트를 수주하다 — 설계하기 전에 계약부터”인 이유도 여기에 있습니다.

 

프로젝트 Risk는 기술적인 것만 있는 것이 아닙니다. 오히려 계약을 잘못하면 기술적으로 문제가 없더라도 프로젝트가 손실로 끝날 수 있습니다. 예를 들어 고객이 다음과 같은 조건을 계약서에 넣었다고 생각해 보겠습니다.

“계약된 성능을 만족하지 못할 경우 Contractor가 책임진다.”

 

문제는 여기서 말하는 성능이 무엇인지입니다.

 

• 생산 Capacity?
• Product Quality?
• Energy Consumption?
• Alcohol Content?
• Availability?
• Utility Consumption?

그리고 성능을 어떤 조건에서 측정할 것인지도 중요합니다.

 

예를 들어,

Feed 조건이 달라졌는데도 동일한 Performance Guarantee를 요구한다면?

 

이것은 기술 문제가 아니라 Contract Risk입니다.

 

따라서 수주 전 Risk Review에서는 반드시 계약조건을 Engineering 관점에서도 읽어야 합니다.

 

특히 다음과 같은 항목은 중요합니다.

 

• Scope of Work
• Battery Limit
• Performance Guarantee
• Acceptance Criteria
• Liquidated Damages
• Warranty
• Delay Responsibility
• Change Order
• Force Majeure
• Customer Responsibility
• Vendor Responsibility

결국 엔지니어에게도 계약서는 중요한 기술문서입니다.

 

계약서에 적힌 한 문장이 수십억 원의 책임으로 돌아올 수 있기 때문입니다.

 

 

9. Risk를 찾았으면 이제 평가해야 한다

 

Risk를 100개 찾았다고 좋은 Risk Review가 되는 것은 아닙니다.

 

중요한 것은 어떤 Risk가 프로젝트에 가장 큰 영향을 주는지 판단하는 것입니다.

 

가장 기본적인 방법 중 하나가 Probability × Impact 방식입니다.

 

예를 들어,

 

Risk	발생 가능성	영향도	평가
주요 장비 납기 지연	높음	높음	🔴 High
Minor Pipe Support 변경	높음	낮음	🟢 Low
고객 승인 지연	중간	높음	🟠 Medium/High
Utility Capacity 부족	낮음	매우 높음	🟠 High
Office Printer 고장	높음	매우 낮음	🟢 Low

 

여기서 중요한 것은 단순한 숫자가 아닙니다.

 

“이 Risk가 발생하면 프로젝트가 얼마나 흔들리는가?”를 보는 것입니다. 특히 발생 가능성은 낮지만 영향도가 매우 큰 Risk를 놓쳐서는 안 됩니다. 예를 들어,

발생 가능성 5%
발생 시 프로젝트 손실 10억 원

 

이라면 무시할 수 있는 Risk인지 고민해야 합니다.

 

프로젝트의 규모와 Risk tolerance에 따라 정량적인 분석이 필요한 경우에는 Expected Monetary Value, Simulation 등의 방법을 활용할 수도 있습니다.

 

 

10. Risk Register — Risk를 문서로 만들어라

 

Risk Review의 가장 대표적인 결과물이 Risk Register입니다.

 

쉽게 말하면 프로젝트의 Risk 목록표입니다.

 

예를 들어 Beer to Zero Project의 Risk Register를 만들어보면 다음과 같습니다.

 

No.	Risk	Probability	Impact	Risk Level	Response	Owner
R-01	주요 장비 납기 지연	High	High	High	Early Procurement	Procurement
R-02	기존 Utility Capacity 부족	Medium	High	High	Site Survey / Hydraulic Check	Process
R-03	제품 성능 미달	Low	Very High	High	Pilot Test	Process
R-04	고객 요구사항 변경	Medium	High	High	Scope Freeze	PM
R-05	인허가 지연	Medium	High	High	Early Consultation	PM
R-06	Construction 중 기존 생산 영향	Medium	High	High	Shutdown Plan	Construction
R-07	Vendor Drawing 승인 지연	Medium	Medium	Medium	Approval Schedule	Engineering

 

이 표에서 중요한 것은 Risk를 적어놓는 것으로 끝나지 않는다는 것입니다.

 

각 Risk에는 Owner가 있어야 합니다. 그리고,

“그래서 누가 무엇을 할 것인가?”

 

까지 정해야 합니다.

 

 

11. Risk의 핵심은 Response Plan

 

Risk를 발견했다고 해서 Risk Management가 끝난 것이 아닙니다.

 

오히려 여기서부터가 중요합니다. 예를 들어,

 

Risk 1

주요 Equipment 납기 지연

 

그렇다면 Response는?

Vendor 3곳의 납기 확인

Long Lead Item 우선 발주

Procurement Schedule 조기 착수

대체 Vendor 확보

 

이렇게 구체적으로 만들어야 합니다. 또 다른 예를 들어보겠습니다.

 

Risk 2

기존 Utility Capacity 부족

 

Response는?

기존 Utility 사용량 조사

Header Pressure 확인

Hydraulic Calculation

추가 Utility 증설 안 검토

고객과 Utility Responsibility 협의

 

처럼 이어져야 합니다.

즉, Risk → Impact → Response → Owner → Due Date까지 연결되어야 실제로 관리할 수 있는 Risk가 됩니다.

 

PMI의 프로젝트 리스크 관리 접근에서도 위험을 식별하고 우선순위를 정한 뒤 대응계획을 수립하고, 이후 프로젝트 진행 중 지속적으로 모니터링하는 반복적인 프로세스를 강조합니다.

 

 

12. 가장 위험한 Risk는 무엇일까?

 

Risk Review를 하다 보면 이상한 현상을 발견하게 됩니다.

 

가장 위험한 Risk가 반드시 가장 큰 문제처럼 보이는 것은 아닙니다.

 

오히려 처음에는 별것 아닌 것처럼 보이는 작은 문제가 다른 문제와 연결되면서 커질 수 있습니다.

 

예를 들어,

 

1. Customer Approval Delay
2. Engineering Drawing Delay
3. Equipment Procurement Delay
4. Construction Delay
5. Commissioning Delay
6. Performance Test Delay
7. Commercial Operation Date Delay
8. Liquidated Damages

이렇게 연결될 수 있습니다.

 

하나의 Risk가 여러 개의 Risk를 연쇄적으로 발생시키는 것입니다.

 

그래서 Risk Review에서는 개별 Risk뿐만 아니라 Risk 간의 연결관계도 봐야 합니다.

 

PMI에서도 프로젝트 전체 Risk는 개별 Risk의 단순한 합보다 클 수 있으며, 프로젝트 전체에 영향을 주는 불확실성을 별도로 바라볼 필요가 있다고 설명합니다.

 

 

13. Risk Review는 수주 전에 해야 한다

 

여기서 중요한 질문이 하나 있습니다.

“Risk Review는 프로젝트가 시작된 다음에 하면 되는 것 아닌가?”

 

물론 프로젝트가 시작된 이후에도 지속적으로 해야 합니다.

 

하지만 수주 전 Risk Review가 특히 중요합니다.

 

왜냐하면 계약을 체결하고 나면 선택할 수 있는 옵션이 급격히 줄어들기 때문입니다.

 

수주 전에는,

“이 Scope는 제외하겠습니다.”

“이 성능은 Guarantee 할 수 없습니다.”

“납기를 3개월 연장해야 합니다.”

“Pilot Test가 필요합니다.”

 

라고 말할 수 있습니다.

 

하지만 계약 후에는 같은 말을 하기가 훨씬 어려워집니다.

 

따라서 수주 전 Risk Review는 단순히 프로젝트를 성공시키기 위한 검토가 아닙니다.

 

“이 프로젝트를 우리가 감당할 수 있는가?”를 판단하는 의사결정 과정입니다.

 

PMI에서도 프로젝트의 Scope와 목표가 구체화되는 초기 단계에서 프로젝트 전체 Risk 수준과 Risk tolerance를 검토하는 것이 중요하다고 설명합니다.

 

 

14. Beer to Zero Project — 마지막 회의

 

다시 Beer to Zero Project의 수주 전 회의실로 돌아가 보겠습니다.

 

회의실에는 지금까지 작성한 자료가 놓여 있습니다.

 

한쪽에는 Technical Feasibility Review가 있습니다.

 

다른 쪽에는 Scope Definition이 있습니다.

 

그 옆에는 Cost Estimate와 Project Schedule이 있습니다.

 

그리고 마지막으로 Risk Register가 놓였습니다.

 

Project Manager가 질문합니다.

“그래서 이 프로젝트, 우리가 할 수 있습니까?”

 

Process Engineer가 대답합니다.

“기술적으로는 가능합니다.”

 

Cost Engineer가 말합니다.

“현재 Scope 기준으로 예산도 맞습니다.”

 

Planner가 말합니다.

“Critical Path를 기준으로 보면 18개월이면 가능합니다.”

 

잠시 정적이 흐릅니다. 그리고 Risk Manager가 마지막으로 말합니다.

“그런데 세 가지가 걸립니다.”

 

첫 번째.

“주요 장비의 납기가 10개월입니다. 일정에 여유가 없습니다.”

 

두 번째.

“기존 Utility Capacity가 부족할 가능성이 있습니다. 현장 확인이 필요합니다.”

 

세 번째.

“고객이 요구하는 Performance Guarantee 조건이 아직 명확하지 않습니다.”

 

회의실이 조용해집니다.

 

프로젝트를 하지 못하는 것은 아닙니다. 하지만 지금 상태로 계약하면 위험합니다. 그래서 팀은 세 가지 Action을 결정합니다.

 

• Long Lead Item 선행 검토.
• Existing Utility 현장조사.
• Performance Guarantee 조건 고객 협의.

그리고 이 세 가지가 해결된 후 최종적으로 수주 여부를 결정하기로 합니다. 이것이 Project Risk Review입니다.

 

 

15. 결국 Risk Review의 목적은 “겁내는 것”이 아니다

 

Risk Review를 하다 보면 프로젝트의 문제가 계속 보입니다.

 

그래서 어떤 사람들은 Risk Review를 부정적으로 생각하기도 합니다.

“안 되는 이유만 찾는 것 아닌가?”

 

그렇지 않습니다. Risk Review의 목적은 프로젝트를 포기하기 위해서가 아닙니다.

 

프로젝트를 성공시키기 위해 미리 문제를 발견하는 것입니다.

 

Risk가 있다는 것 자체가 문제는 아닙니다. 모든 프로젝트에는 Risk가 존재합니다.

 

중요한 것은, 우리가 그 Risk를 알고 있는가? 그리고 그 Risk에 대응할 준비가 되어 있는가?입니다.

 

PMI에서도 Risk Management의 핵심을 불확실한 사건 자체를 통제하는 것이 아니라, 그 가능성과 영향에 대비하고 적절한 대응을 준비하는 것으로 설명합니다.

 

 

16. 프로젝트는 Risk를 없애는 것이 아니라 관리하는 것

 

현실적으로 Risk를 0으로 만드는 것은 불가능합니다.

 

오히려 프로젝트는 새로운 것을 만드는 과정이기 때문에 어느 정도의 불확실성을 가지고 시작할 수밖에 없습니다.

 

따라서 좋은 Project Manager와 Engineer의 역할은

Risk가 없는 프로젝트를 만드는 것

 

이 아니라,

중요한 Risk를 알고 있는 프로젝트를 만드는 것

 

에 가깝습니다.

 

그리고 더 좋은 프로젝트는 여기에서 한 단계 더 나아갑니다. Risk가 발생했을 때 무엇을 할 것인지까지 준비되어 있습니다.

 

즉,

Identify
↓
Analyze
↓
Respond
↓
Monitor

 

의 반복입니다. Risk Management는 한 번 작성하고 끝나는 문서가 아니라 프로젝트가 진행되는 동안 계속 업데이트되는 관리 활동입니다.

 

 

17. 그리고 이제 계약서를 다시 본다면

 

Beer to Zero Project의 PART 2에서 우리가 지금까지 한 일을 다시 정리해 보겠습니다.

 

Technical Feasibility

우리가 만들 수 있는가?

 

Project Scope

어디까지 우리가 해야 하는가?

 

Project Cost Estimation

프로젝트에는 얼마가 필요한가?

 

Project Schedule

언제까지 만들어야 하는가?

 

Project Risk Review

무엇이 이 프로젝트를 망칠 수 있는가?

 

이 다섯 가지 질문에 대한 답을 찾았습니다.

 

이제야 비로소 하나의 프로젝트를 사업적으로 검토할 수 있는 상태가 되었습니다.

 

그리고 여기서부터 진짜 중요한 문서가 등장합니다. 바로 Contract입니다.

 

지금까지 우리가 검토한 모든 내용은 결국 계약서에 반영되어야 합니다.

 

• 우리가 어디까지 책임질 것인지.
• 무엇을 보장할 것인지.
• 언제까지 완료할 것인지.
• 얼마를 받을 것인지.
• 문제가 발생했을 때 누가 책임질 것인지.
• 이것이 계약으로 정해집니다.

결국 프로젝트는 설계도에서 시작되는 것이 아닙니다. 계약에서 시작됩니다. 그리고 좋은 계약은 단순히 가격을 협상해서 만들어지는 것이 아닙니다.

 

Technical Feasibility, Scope, Cost, Schedule 그리고 Risk에 대한 이해가 모두 반영되어 만들어집니다.

 

Beer to Zero Project의 PART 2가 “설계하기 전에 계약부터”인 이유입니다.

 

 

Beer to Zero Project 연재 순서

 

PART 2. 프로젝트를 수주하다 — 설계하기 전에 계약부터

 

• Part 9. 우리가 이 프로젝트를 할 수 있는가 - Technical Feasibility
• Part 10. 어디까지 우리가 해야 하는가 - Project Scope 설정
• Part 11. 프로젝트에는 얼마가 필요한가 - Project Cost Estimation
• Part 12. 언제까지 만들어야 하는가 - Project Schedule
• Part 13. 무엇이 프로젝트를 망칠 수 있는가 - Project Risk Review
• Part 14. 엔지니어가 견적을 만드는 방법 - Engineering Man-hour
• Part 15. 기술제안서에는 무엇을 담는가 - Technical Proposal
• Part 16. 결국 계약이 필요하다 - Commercial & Contract
• Part 17. 프로젝트 수주 - 이제 진짜 시작이다