Part 16. 결국 계약이 필요하다 - Commercial & Contract

앞선 글까지 우리는 꽤 많은 것을 결정했습니다.

 

무엇을 만들 것인지 정했고, 어디까지 우리가 해야 하는지도 정했습니다.

 

프로젝트를 수행할 수 있는지 검토했고, 필요한 비용과 일정도 계산했습니다.

 

프로젝트를 망칠 수 있는 위험도 찾아봤고, 고객에게 우리가 어떤 방식으로 프로젝트를 수행할 것인지 기술제안서에 담았습니다.

 

그런데 아직 프로젝트는 시작되지 않았습니다.

 

왜일까요? 계약서에 서명하지 않았기 때문입니다.

 

 

1. 좋은 기술제안서만으로는 프로젝트를 수행할 수 없다

 

회의실에 마지막 견적 검토를 위해 사람들이 모였습니다.

 

Process Engineer는 공정 설계 범위를 설명합니다.

"Process Design은 여기까지 포함되어 있습니다."

 

Mechanical Engineer가 이어받습니다.

"Equipment는 Vendor Package까지 저희가 관리하겠습니다."

 

Electrical Engineer도 이야기합니다.

"MCC와 현장 전기공사는 여기까지입니다."

 

Project Manager가 일정표를 보여줍니다.

"Mechanical Completion은 계약 후 14개월을 목표로 잡았습니다."

 

마지막으로 Commercial 담당자가 한마디를 합니다.

"그리고 이 조건으로 총 계약금액은 ○○억입니다."

 

이제 고객에게 무엇을 제공할지 상당 부분 정리되었습니다.

 

그런데 여기서 끝이 아닙니다. 오히려 이제부터 중요한 질문이 시작됩니다.

 

"그런데 이 내용을 계약서에 어떻게 넣을 것인가?"

 

예를 들어 고객이 프로젝트 중간에 이렇게 이야기한다고 생각해 보겠습니다.

"Tank 하나만 추가해 주세요."

 

엔지니어 입장에서는 간단해 보일 수 있습니다.

 

Tank 하나 추가하고 P&ID 수정하고, 배관을 연결하고, Instrument를 추가하고, 전기와 Control을 수정하면 됩니다.

 

그런데 계약 담당자는 바로 다른 질문을 합니다.

"그 추가 작업은 누가 비용을 부담하는가?"

 

그리고 또 묻습니다.

"일정은 얼마나 늘어나는가?"

 

이 질문부터는 더 이상 순수한 Engineering 문제가 아닙니다.

 

Commercial & Contract의 영역입니다.

 

 

2. Contract는 결국 "누가 무엇을 책임지는가"를 정하는 문서다

 

프로젝트 계약을 어렵게 생각할 필요는 없습니다. 아주 단순하게 보면 계약은 다음 질문에 답하는 문서입니다.

 

• 무엇을 할 것인가? → Scope
• 얼마에 할 것인가? → Price
• 언제까지 할 것인가? → Schedule
• 문제가 생기면 누가 책임질 것인가? → Risk & Liability
• 내용이 바뀌면 어떻게 할 것인가? → Change / Variation
• 돈은 언제 받을 것인가? → Payment
• 약속한 성능을 달성하지 못하면 어떻게 할 것인가? → Performance / Damages

결국 앞에서 검토했던 모든 내용이 계약이라는 하나의 틀 안으로 들어갑니다.

 

그래서 프로젝트 계약은 단순한 법률 문서라고 보기 어렵습니다.

 

프로젝트를 어떻게 수행할 것인지 정의하는 운영 규칙에 가깝습니다.

 

실제로 국제 건설·엔지니어링 계약에서는 Scope, Time, Payment, Compensation Event, Liability, Termination 등의 사항이 계약의 핵심 구조를 이루고 있습니다. 예를 들어 NEC4 Engineering and Construction Contract도 일반조건 아래에 Contractor's Responsibilities, Time, Quality, Payment, Compensation Events, Liabilities and Insurance, Termination 등을 별도의 핵심 영역으로 구성하고 있습니다.

 

 

3. 그래서 계약 전에 Commercial Review가 필요하다

 

여기서 중요한 것이 Commercial Review입니다.

 

기술제안서를 만들었다고 바로 계약서에 서명하는 것은 아닙니다.

 

우리가 제안한 내용과 고객이 요구하는 계약조건 사이에 차이가 없는지 다시 확인해야 합니다.

 

예를 들어 기술제안서에는 다음과 같이 적혀 있다고 해보겠습니다.

"Performance Test는 정상 운전조건에서 수행한다."

 

그런데 계약서에는 이렇게 적혀 있습니다.

"Contractor shall guarantee the specified production capacity under all operating conditions."

 

두 문장은 비슷해 보이지만 의미는 상당히 다릅니다.

 

첫 번째는 특정 조건에서 성능을 확인하겠다는 의미에 가깝습니다.

 

두 번째는 운전조건과 관계없이 계약상 성능을 보증하는 것처럼 해석될 여지가 있습니다.

 

이 차이를 놓치면 나중에 Performance Test 단계에서 문제가 발생할 수 있습니다.

 

따라서 계약 전에는 최소한 다음 내용을 다시 확인해야 합니다.

 

• Contract Scope
• Contract Price
• Payment Terms
• Project Schedule
• Milestone
• Performance Guarantee
• Liquidated Damages
• Warranty
• Change Order / Variation
• Delay
• Force Majeure
• Liability
• Insurance
• Termination
• Governing Law
• Dispute Resolution

결국 Commercial Review의 핵심은 하나입니다.

"우리가 제안한 것과 실제 계약에서 책임지는 것이 같은가?"

 

 

 

4. 가장 먼저 확인해야 하는 것은 Scope다

 

엔지니어 입장에서 계약을 검토할 때 가장 먼저 봐야 할 것은 역시 Scope입니다.

 

앞선 Part 10에서 Project Scope를 이야기했던 이유도 바로 이것입니다.

 

예를 들어 우리가 무알콜 맥주 생산설비를 EPC 방식으로 수행한다고 해보겠습니다.

 

우리의 Scope가 다음과 같다고 가정하겠습니다.

 

• Process Design
• Equipment Procurement
• Piping
• Instrumentation
• Electrical
• Installation
• Commissioning

그런데 고객의 요구사항에는 다음 문장이 있습니다.

"The Contractor shall provide all facilities necessary for successful operation of the plant."

 

상당히 위험한 문장입니다.

 

왜냐하면 "successful operation에 필요한 모든 설비"라는 표현은 해석의 범위가 넓기 때문입니다.

 

처음에는 포함하지 않았던 Utility Line이 필요할 수도 있고, Drain System이 필요할 수도 있고, Operator Building이 필요할 수도 있습니다. 그러면 고객은 이야기할 수 있습니다.

"공장을 정상적으로 운영하려면 필요한 것이니까 당연히 Contractor Scope 아닌가요?"

 

반대로 Contractor는 이야기할 수 있습니다.

"그 설비는 당초 Scope에 없었습니다."

 

이런 상황을 방지하기 위해 계약에서는 Included Scope와 Excluded Scope를 명확하게 정의하는 것이 중요합니다.

 

그리고 이것이 앞선 글에서 다뤘던 Battery Limit과도 연결됩니다.

 

 

5. Scope보다 더 중요한 것이 Exclusion일 때도 있다

 

프로젝트를 처음 경험하는 엔지니어는 보통 무엇을 할 것인지에 집중합니다.

 

하지만 계약에서는 무엇을 하지 않는지도 굉장히 중요합니다.

 

예를 들어 다음과 같이 정할 수 있습니다.

 

Included

• Process Design
• Mechanical Design
• Equipment Procurement
• Piping Installation
• Instrument Installation
• Commissioning

Excluded

• Site civil work
• Building construction
• Main utility generation
• External road construction
• Raw material supply
• Product packaging equipment

 

이렇게 명확하게 구분해 놓으면 프로젝트 중간에 "이것도 포함된 것 아닌가요?"라는 논쟁을 줄일 수 있습니다.

 

특히 EPC 프로젝트에서는 Scope Boundary가 애매할수록 Scope Creep이 발생하기 쉽습니다.

 

처음에는 작은 요청 하나였습니다.

"이 배관 하나만 추가해 주세요."

 

그다음에는,

"Valve도 하나 추가해야겠네요."

 

그리고,

"그러면 Instrument도 필요하겠네요."

 

마지막에는,

"이 설비가 추가됐으니 Control Logic도 수정해 주세요."

 

처음에는 작은 변경처럼 보였지만 결국 하나의 Package가 추가됩니다.

 

따라서 계약에서 Scope를 정의한다는 것은 단순히 "무엇을 한다"를 적는 것이 아니라, 프로젝트의 경계를 그어놓는 일입니다.

 

 

6. 두 번째로 중요한 것은 Price다

 

다음은 Contract Price입니다.

 

여기서 중요한 것은 단순히 계약금액이 얼마인지가 아닙니다.

 

그 금액이 어떤 조건을 전제로 만들어졌는지가 중요합니다.

 

예를 들어 우리가 100억 원에 EPC 프로젝트를 수주했다고 해보겠습니다.

 

100억이라는 숫자만 보면 명확해 보입니다.

 

하지만 실제로는 다음과 같은 질문이 필요합니다.

 

• Lump Sum인가?
• Re-measurement인가?
• Cost Reimbursable인가?
• Escalation이 가능한가?
• 환율 변동은 누가 부담하는가?
• 세금은 포함되는가?
• 물가 상승은 어떻게 처리하는가?
• 추가 Scope는 어떻게 가격을 산정하는가?

국제 계약에서는 계약가격과 지급방법, 선급금, 중간지급, 지급시기, 지연지급 등의 조건이 별도의 계약 조항으로 관리됩니다. FIDIC의 EPC/Turnkey 계약 구조에서도 Variation, Contract Price and Payment, Advance Payment, Interim Payment, Delayed Payment 등이 구분되어 있습니다.

 

따라서 "100억짜리 프로젝트다."라는 말만으로는 계약을 이해했다고 할 수 없습니다.

 

정확하게는,

"어떤 가격조건으로 100억에 계약했는가?"

 

를 알아야 합니다.

 

 

7. Lump Sum Contract가 엔지니어에게 중요한 이유

 

EPC 프로젝트에서 자주 접하는 방식 중 하나가 Lump Sum입니다.

 

쉽게 이야기하면,

정해진 Scope를 정해진 금액으로 수행하는 방식

 

입니다. 예를 들어,

Contract Price = 100억 원

 

으로 계약했다고 하겠습니다.

 

그런데 프로젝트를 수행하다 보니 예상보다 Engineering Man-hour가 많이 들어갔습니다.

 

Process Engineer가 생각합니다.

"설계가 생각보다 어렵네. 2,000 MH 정도 더 필요하겠다."

 

그렇다고 바로 고객에게

"설계가 어려워졌으니 돈을 더 주세요."

 

라고 할 수 있는 것은 아닙니다.

 

계약상 Contractor의 Scope와 Risk라면 그 비용은 Contractor가 부담해야 할 수 있습니다.

 

반대로 고객이 계약 Scope 자체를 변경했다면 이야기가 달라집니다.

 

예를 들어,

"기존 10,000 ton/year 설비를 15,000 ton/year로 변경해 주세요."

 

라고 고객이 요구했다면 추가 설비와 Engineering이 필요할 수 있습니다.

 

이 경우 계약에서 정한 Change / Variation 절차를 통해 추가 비용과 일정 영향을 검토하게 됩니다.

 

즉,

내가 예상보다 돈을 많이 썼다 = 추가금액

 

은 아닙니다. 반대로,

고객의 요구사항이 계약 Scope를 변경했다 = 추가금액 검토 대상

 

이 될 수 있습니다. 이 차이를 이해하는 것이 Commercial Engineering의 핵심입니다.

 

 

8. Change Order는 왜 중요한가

 

프로젝트가 계획대로만 진행된다면 좋겠지만 현실은 그렇지 않습니다.

 

프로젝트 중간에는 반드시 변경이 발생합니다.

 

예를 들어,

 

Before

• Tank 3기
• Pump 6대
• 생산능력 10,000 ton/year

였던 설비가 고객 요구로

 

After

• Tank 5기
• Pump 10대
• 생산능력 15,000 ton/year

로 변경될 수 있습니다.

 

이때 중요한 것은 단순히 설계를 수정하는 것이 아닙니다.

 

변경으로 인해 발생하는 영향을 함께 검토해야 합니다.

 

• Engineering - 추가 설계가 필요한가?
• Procurement - 추가 장비를 구매해야 하는가?
• Construction - 공사량이 증가하는가?
• Schedule - 납기가 늘어나는가?
• Cost - 추가 비용은 얼마인가?
• Performance - 기존 Performance Guarantee에 영향이 있는가?

즉, Change Order는 작은 문서 하나가 아니라

 

Scope → Cost → Schedule → Risk → Performance

 

전체에 영향을 미치는 사건입니다.

 

NEC4에서는 이런 계약상 변경이나 특정 위험 사건을 Compensation Event라는 체계로 관리하며, 해당 사건이 Price나 Completion Date 등에 영향을 줄 수 있도록 계약 절차를 마련하고 있습니다.

 

 

9. Schedule도 계약이 되는 순간 의미가 달라진다

 

앞선 Part 12에서 Project Schedule을 만들었습니다.

 

그때의 일정은 프로젝트를 관리하기 위한 계획이었습니다.

 

하지만 계약서에 들어가는 순간 그 일정은 Contractual Milestone이 됩니다.

 

예를 들어,

 

• Contract Effective Date
• Engineering Completion
• Equipment Delivery
• Mechanical Completion
• Commissioning
• Performance Test
• Final Acceptance

등이 계약상 주요 일정으로 정의될 수 있습니다.

 

이제 일정이 단순한 Project Schedule이 아닙니다.

 

계약상 의무가 됩니다.

 

그래서 일정이 늦어지면 단순히 Project Manager가 혼나는 것으로 끝나지 않을 수 있습니다.

 

계약에 따라 Delay Damages 또는 Liquidated Damages가 적용될 수 있기 때문입니다.

 

NEC4에서도 Delay Damages를 별도의 Option X7로 두고 있으며, 계약에 따라 지연에 대한 금전적 책임을 구조화할 수 있습니다.

 

 

10. Performance Guarantee는 엔지니어에게 특히 중요하다

 

엔지니어 입장에서 계약서를 볼 때 가장 긴장되는 부분 중 하나가 Performance Guarantee입니다.

 

왜냐하면 여기부터는 기술적인 결과가 곧 계약상의 책임으로 연결되기 때문입니다.

 

예를 들어 무알콜 맥주 설비에 대해 다음과 같은 보증조건이 있다고 해보겠습니다.

 

Production Capacity: 10,000 ton/year
Alcohol Content: ≤ 0.05%
Product Quality: Customer Specification 만족

 

문제는 이 숫자들이 어떤 조건에서 적용되는가입니다. 예를 들어,

 

• 원료 조건
• Feed Temperature
• Feed Composition
• Utility Condition
• Ambient Condition
• Operating Hours
• Product Specification
• Sampling Method
• Test Duration

등이 명확하게 정의되어 있어야 합니다.

 

그렇지 않으면 Performance Test에서 문제가 발생할 수 있습니다.

 

예를 들어 Contractor는

"원료 조건이 계약 기준보다 좋지 않았습니다."

 

라고 주장할 수 있고, Customer는

"그건 Contractor의 설계 문제입니다."

 

라고 주장할 수 있습니다.

 

결국 Performance Guarantee 역시 Engineering Condition을 Contract Condition으로 바꾸는 작업이라고 볼 수 있습니다.

 

 

11. Risk는 결국 계약서에 배분된다

 

앞선 Part 13에서 Project Risk Review를 했습니다.

 

Risk Register에는 수많은 위험요소가 있었습니다.

 

하지만 계약 단계에서는 질문이 하나 더 붙습니다.

"그래서 이 Risk는 누가 부담하는가?"

 

예를 들어,

 

Risk	Contractor	Client
설계 오류	●
Contractor 조달 지연	●
Client의 승인 지연		●
Client 제공 원료 문제		●
예상하지 못한 Site Condition	계약조건에 따라	계약조건에 따라
법규 변경	계약조건에 따라	계약조건에 따라

 

이렇게 Risk가 계약상 책임으로 연결됩니다.

 

따라서 Risk Review의 최종 목적은 단순히 위험을 찾는 것이 아닙니다.

 

위험을 찾아서 계약상 누가 부담할지 결정하는 것까지 가야 합니다.

 

 

12. 계약에서 가장 무서운 문장은 "All..."일 수 있다

 

엔지니어 입장에서 계약서를 읽을 때 주의해야 하는 표현들이 있습니다. 대표적으로,

all

any

necessary

complete

suitable

fit for purpose

 

같은 표현입니다. 예를 들어,

"The Contractor shall provide all equipment necessary for successful operation."

 

이라고 되어 있다면, "필요한 장비를 다 제공한다"는 좋은 문장처럼 보일 수 있습니다.

 

하지만 Contractor 입장에서는 질문이 필요합니다.

"Necessary의 기준은 누가 결정하는가?"

 

또한,

"The Contractor shall ensure that the plant is fit for purpose."

 

라는 문장이 있다면,

"Purpose가 정확히 무엇인가?"

 

를 확인해야 합니다.

 

계약에서는 단어 하나가 Scope와 Liability의 범위를 크게 바꿀 수 있습니다.

 

그래서 Commercial Review에서는 문장 자체보다 책임의 범위를 봐야 합니다.

 

 

13. 결국 계약은 "말"이 아니라 "증거"가 된다

 

프로젝트가 잘 진행될 때는 계약서가 잘 보이지 않습니다.

 

회의도 잘 되고, 설계도 잘 진행되고, Vendor도 납기를 맞추고, 고객도 승인해 줍니다. 문제가 없습니다.

 

그런데 문제가 발생하면 상황이 달라집니다. 고객이 이야기합니다.

"이것도 당연히 포함된 것 아닌가요?"

 

Contractor가 대답합니다.

"당초 Scope에는 없었습니다."

 

고객이 다시 묻습니다.

"그럼 왜 처음부터 이야기하지 않았습니까?"

 

이때 필요한 것이 바로 계약 문서와 공식 기록입니다.

 

계약서뿐만 아니라,

 

• Technical Proposal
• Commercial Proposal
• Scope of Work
• Specification
• Clarification
• Meeting Minutes
• Approved Drawing
• Change Order
• Formal Correspondence

등이 프로젝트의 근거가 됩니다.

 

결국 프로젝트에서는 "누가 뭐라고 말했는가"보다 "무엇이 계약상 합의되어 있는가"가 중요합니다.

 

 

14. 그래서 계약 전에는 "Contract Review"를 한다

 

계약서가 들어오면 엔지니어링 조직에서는 Contract Review를 수행합니다.

 

단순히 법무팀만 보는 것이 아닙니다.

 

Project Manager, Engineering, Procurement, Construction, QA/QC, HSE, Commercial, Legal 등이 각자의 관점에서 검토해야 합니다.

 

특히 Engineering에서는 다음을 확인해야 합니다.

 

1. Scope - 우리가 해야 할 일이 정확히 무엇인가?
2. Design Responsibility - 설계 책임은 어디까지인가?
3. Design Criteria - 어떤 기준과 조건으로 설계해야 하는가?
4. Performance Guarantee - 어떤 성능을 보증해야 하는가?
5. Schedule - 어떤 Milestone을 지켜야 하는가?
6. Client Responsibility - 고객은 무엇을 언제 제공해야 하는가?
7. Change - 변경이 발생하면 어떻게 처리하는가?
8. Risk - 어떤 Risk를 Contractor가 부담하는가?
9. Liability - 문제가 발생했을 때 책임의 한계는 어디까지인가?
10. Acceptance - 언제 프로젝트가 완료된 것으로 인정되는가?

이것이 바로 Commercial & Contract Review입니다.

 

 

15. 결국 계약은 프로젝트의 "기준선"이다

 

지금까지의 과정을 다시 연결해 보겠습니다.

 

1. 고객의 요구사항을 받았습니다.
2. User Requirement를 정의했습니다.
3. Product Specification을 정했습니다.
4. Production Capacity를 결정했습니다.
5. Site Condition을 검토했습니다.
6. Battery Limit을 설정했습니다.
7. Technical Feasibility를 검토했습니다.
8. Process를 선정했습니다.
9. Project Scope를 정했습니다.
10. Cost를 계산했습니다.
11. Schedule을 만들었습니다.
12. Risk를 검토했습니다.
13. Technical Proposal을 만들었습니다.

그리고 마지막으로, Commercial & Contract를 통해 이것을 계약으로 확정합니다.

 

이제야 프로젝트의 기준선이 만들어집니다. 그래서 계약은 프로젝트의 마지막 문서가 아닙니다.

 

오히려 이후 모든 Engineering 활동의 출발점입니다.

 

 

16. Beer to Zero Project도 이제 계약서에 서명한다

 

다시 우리의 Beer to Zero Project로 돌아가 보겠습니다. 고객은 말했습니다.

"우리는 무알콜 맥주 생산공장이 필요합니다."

 

처음에는 한 문장이었습니다.

 

하지만 우리는 그 한 문장을 하나씩 쪼개기 시작했습니다.

 

• 얼마나 생산할 것인지.
• 어떤 제품을 만들 것인지.
• 어디에 공장을 지을 것인지.
• 기존 공장을 활용할 것인지.
• 어떤 공정을 사용할 것인지.
• 어디까지 우리가 수행할 것인지.
• 얼마가 필요한지.
• 언제까지 완성해야 하는지.
• 어떤 위험이 있는지.

그리고 고객에게 어떤 방식으로 수행할 것인지 제안했습니다.

 

이제 마지막 질문이 남았습니다.

"그래서 이 모든 것을 어떤 조건으로 계약할 것인가?"

 

고객과 Contractor가 협상을 시작합니다.

 

Scope를 조정하고, Price를 협의하고, Payment 조건을 정하고, Schedule을 확정하고,

Performance Guarantee를 정하고, Risk와 Liability를 배분합니다.

 

그리고 마침내 계약서에 서명합니다.

 

Project Award.

 

이 순간부터 Beer to Zero Project는 더 이상 단순한 사업 아이디어가 아닙니다.

 

계약상 의무를 가진 실제 프로젝트가 됩니다.

 

 

17. 계약서에 서명했다고 프로젝트가 끝난 것은 아니다

 

오히려 반대입니다. 이제부터 진짜 프로젝트가 시작됩니다.

 

계약서에 적힌 Scope를 가지고 Engineering을 시작해야 하고, 계약 Schedule을 기준으로 프로젝트를 관리해야 하며, Contract Price 안에서 비용을 통제해야 합니다.

 

그리고 프로젝트를 수행하면서 발생하는 변경은 Contract Change로 관리해야 합니다.

 

즉, 계약 전에는 "무엇을 할 것인가"를 결정했다면, 계약 후에는 "계약한 것을 어떻게 실행할 것인가"를 고민하게 됩니다.

 

이제 프로젝트의 중심은 Commercial Proposal에서 Engineering으로 이동합니다.

 

그리고 다음 단계부터 우리가 실제로 공장을 설계하기 시작합니다.

 

 

엔지니어에게 계약이 중요한 이유

 

엔지니어는 보통 계약서를 보면 이런 생각을 할 수 있습니다.

"이건 Commercial이나 Legal에서 보는 거 아닌가?"

 

하지만 프로젝트가 커질수록 생각이 달라집니다.

 

Engineering에서 Scope를 잘못 이해하면 비용이 증가합니다.

 

Specification을 잘못 이해하면 설계가 변경됩니다.

 

Performance Guarantee를 잘못 이해하면 시험에서 문제가 발생합니다.

 

Schedule을 잘못 이해하면 지연이 발생합니다.

 

Change를 제대로 관리하지 못하면 추가 비용을 받지 못할 수도 있습니다.

 

결국 Engineering의 판단이 Commercial 결과로 이어집니다.

 

그래서 좋은 엔지니어는 설계만 잘하는 사람이 아닙니다. 자신이 설계하는 것이 계약상 무엇을 의미하는지 이해하는 엔지니어가 되어야 합니다. 프로젝트에서 가장 중요한 질문은 어쩌면 이것일지도 모릅니다.

"우리가 무엇을 만들 것인가?"

 

가 아닙니다. 그보다 먼저,

"우리가 무엇을 약속했는가?"

 

를 알아야 합니다. 그리고 그 약속을 문서로 만든 것이 바로 Contract입니다.

제조기업 - EPC와 계약을 하게 되면 여기까지 연재된 방향대로 가는 게 정석입니다.
단, 제조기업 내 기술부서와 생산부서가 협업을 통해 실무를 하게 된다면, [PART 2 프로젝트를 수주하다]라는 연재 파트에서 절반을 생략하거나 최소화할 수 있습니다.
최근 제조기업이 공장이나 플랜트를 짓는 방향으로는 원가절감을 위해 Client - 설계사 - 시공사 순으로 계약 체결하여 업무를 진행하기도 합니다.

 

 

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. 프로젝트 수주 - 이제 진짜 시작이다