Part 15. 우리는 이 프로젝트를 어떻게 수행할 것인가 - Technical Proposal

프로젝트를 수주하기 위해서는 결국 고객에게 한 가지 질문에 답해야 합니다.

 

“그래서 당신들은 이 프로젝트를 어떻게 할 것인가?”

 

앞선 단계에서 우리는 이미 많은 것을 검토했습니다.

 

이 프로젝트가 기술적으로 가능한지 검토했고(Technical Feasibility), 어디까지 우리가 수행할 것인지 Scope를 정했으며, 프로젝트 비용과 Engineering Man-hour를 산정했습니다. 일정도 만들었고, 프로젝트를 망칠 수 있는 Risk도 검토했습니다.

 

그런데 여기서 한 가지 문제가 남습니다.

 

이 모든 내용을 고객에게 어떻게 보여줄 것인가?

 

바로 이때 필요한 것이 Technical Proposal, 기술제안서입니다.

 

 

1. Technical Proposal은 단순한 기술 설명서가 아니다

 

Technical Proposal을 처음 접하면 보통 이렇게 생각하기 쉽습니다.

"우리가 이런 장비를 사용하고,
이런 공정으로 설계하고,
이런 기준을 적용하겠습니다."

 

물론 틀린 말은 아닙니다. 하지만 실제 프로젝트에서 Technical Proposal의 역할은 이것보다 훨씬 큽니다.

 

Technical Proposal은 쉽게 말하면,

“우리는 고객의 요구사항을 이렇게 이해했고,
이 범위까지 수행하며,
이러한 기술과 방법으로 프로젝트를 수행하겠습니다.”

 

라고 고객에게 약속하는 문서입니다.

 

즉, 단순히 무엇을 만들 것인가를 설명하는 문서가 아니라, “어떻게 만들 것인가”를 보여주는 문서입니다.

 

그리고 더 중요한 것이 하나 있습니다.

 

Technical Proposal에 작성된 내용은 향후 계약 과정에서 계약 범위와 기술적 기준을 논의하는 중요한 출발점이 될 수 있습니다.

 

따라서 제안서를 작성하는 엔지니어는 단순히 기술적으로 그럴듯한 내용을 적는 것이 아니라, “이 내용을 실제 프로젝트에서 우리가 수행할 수 있는가?”까지 생각해야 합니다.

 

 

2. 고객은 왜 Technical Proposal을 요구할까?

 

고객 입장에서 생각해 보겠습니다.

 

예를 들어 어떤 고객이 연간 10,000톤 규모의 무알코올 맥주 생산설비를 신규로 건설한다고 가정해 보겠습니다.

 

여러 EPC 업체에 RFQ를 보냈습니다.

 

• A사는 100억 원을 제시했습니다.
• B사는 105억 원을 제시했습니다.
• C사는 110억 원을 제시했습니다.

그렇다면 고객은 무조건 A사를 선택할까요?

 

그렇지는 않습니다. 왜냐하면 가격만으로는 프로젝트를 수행할 수 있는지를 알 수 없기 때문입니다.

 

A사가

 

• 어떤 공정을 적용하는지
• 어떤 장비를 선정하는지
• 기존 설비와 어떻게 연결하는지
• Engineering은 어떻게 수행하는지
• Procurement는 어떻게 진행하는지
• Construction은 어떻게 관리하는지
• 시운전은 어떻게 하는지
• 성능보증은 어떻게 할 것인지

알 수 없다면 가격 100억 원이라는 숫자만 가지고는 판단하기 어렵습니다.

 

그래서 고객은 Technical Proposal을 봅니다.

 

결국 고객이 확인하고 싶은 것은 이것입니다.

“이 회사가 내가 원하는 프로젝트를 실제로 완성할 수 있는가?”

 

 

 

3. Technical Proposal에는 무엇이 들어가는가?

 

회사나 발주처의 요구사항에 따라 구성은 달라집니다.

 

하지만 일반적인 Engineering/EPC 프로젝트라면 다음과 같은 내용이 중심이 됩니다.

Technical Proposal의 주요 구성

 

구분	주요 내용
Project Understanding	프로젝트 및 고객 요구사항에 대한 이해
Scope of Work	수행 범위
Technical Approach	기술적 접근 방법
Design Basis	설계 기준
Process Description	공정 및 시스템 설명
Equipment Philosophy	주요 장비 선정 및 설계 방향
Engineering Plan	Engineering 수행 방법
Procurement Plan	기자재 조달 방법
Construction / Installation	시공 및 설치 전략
Commissioning Plan	시운전 및 성능시험 방법
Project Schedule	주요 일정 및 Milestone
Project Organization	수행 조직
Quality Plan	품질관리 방법
HSE Plan	안전·환경관리 방법
Risk & Mitigation	주요 프로젝트 Risk와 대응방안
Assumption & Exclusion	가정사항 및 제외사항
Deliverables	주요 제출 문서

 

모든 프로젝트에서 위 내용을 똑같이 작성하는 것은 아닙니다.

 

고객의 ITB(Invitation to Bid), RFQ(Request for Quotation), Technical Specification에서 요구하는 항목을 우선적으로 확인해야 합니다.

 

즉, Technical Proposal은 우리가 쓰고 싶은 내용을 쓰는 문서가 아니라 고객이 요구한 내용을 우리가 어떻게 충족할 것인지 설명하는 문서입니다.

 

 

4. 첫 번째는 Project Understanding이다

 

Technical Proposal을 작성할 때 가장 먼저 해야 하는 일은 의외로 설계가 아닙니다.

 

고객의 요구사항을 제대로 이해하는 것입니다.

 

예를 들어 고객이 다음과 같이 요구했다고 해보겠습니다.

"연간 10,000톤의 무알코올 맥주 생산설비를 구축하고 기존 유틸리티와 연결한다."

 

이 문장만 보면 간단해 보입니다. 하지만 엔지니어에게는 수많은 질문이 생깁니다.

 

• 10,000톤은 Finished Product 기준인가?
• 연간 운전일 수는?
• 하루 몇 시간 운전하는가?
• 기존 맥주 생산설비와 연결되는가?
• 기존 Utility Capacity는 충분한가?
• Steam은 어디에서 공급받는가?
• Cooling Water는 기존 시스템을 사용하는가?
• 전력은 기존 변전설비에서 공급받는가?
• 기존 공장의 Shutdown이 필요한가?
• 생산 중단 없이 Tie-in이 가능한가?
• 폐수처리시설 Capacity는 충분한가?

따라서 Technical Proposal에서는 먼저 “우리는 고객의 요구사항을 이렇게 이해하고 있습니다.”라고 명확하게 정리해야 합니다.

 

이 부분이 흔들리면 뒤에 나오는 설계, 비용, 일정도 모두 흔들립니다.

 

 

5. Scope of Work — 어디까지 우리가 할 것인가?

 

앞선 Part 10에서 Project Scope를 다뤘습니다.

 

Technical Proposal에서는 그 Scope를 실제 수행 관점에서 다시 구체화합니다.

 

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

 

Engineering

• Process Design
• Mechanical Engineering
• Piping Engineering
• Electrical Engineering
• Instrumentation & Control
• Civil/Structural Engineering
• HSE Engineering

Procurement

• Major Equipment
• Package Equipment
• Bulk Material
• Vendor Document Review
• Expediting
• Inspection

Construction

• Equipment Installation
• Piping Installation
• Electrical Installation
• Instrument Installation
• Insulation & Painting

Commissioning

• Pre-commissioning
• Commissioning
• Performance Test
• Handover

그런데 중요한 것은 포함되는 것만큼 제외되는 것도 중요하다는 것입니다.

 

예를 들어,

Existing Utility Upgrade는 제외

Civil Building Construction은 제외

Owner-supplied Equipment는 제외

 

와 같이 명확하게 구분해야 합니다.

왜냐하면 나중에 문제가 발생했을 때 가장 먼저 나오는 질문이 이것이기 때문입니다.

“그것도 당연히 포함된 것 아닌가요?”

 

그래서 Technical Proposal에서는 Scope와 Exclusion을 함께 작성하는 것이 중요합니다.

 

 

6. Technical Approach — 그래서 어떻게 설계할 것인가?

 

Technical Proposal에서 엔지니어의 역할이 가장 많이 드러나는 부분입니다.

 

예를 들어 무알코올 맥주 생산설비를 만든다고 생각해 보겠습니다.

 

단순히

"De-alcoholization System을 설치한다."

 

라고 작성하는 것과,

"제품의 목표 Alcohol Content를 만족하기 위해 De-alcoholization 공정을 적용하고, 제품 품질 및 생산능력을 고려하여 주요 운전조건을 결정한다."

 

라고 작성하는 것은 차이가 있습니다. 더 나아가면,

 

• Process Flow
• Mass Balance
• Heat Balance
• Equipment Sizing
• Utility Consumption
• Operating Condition
• Control Philosophy
• Safety Consideration

등으로 연결됩니다.

 

즉 Technical Proposal은 설계 결과물을 모두 보여주는 문서는 아니지만, “설계가 어떤 논리로 진행될 것인지”를 보여주는 문서입니다.

 

 

7. Design Basis — 설계의 출발점을 명확하게 한다

 

Engineering 프로젝트에서 중요한 문서 중 하나가 Design Basis입니다.

 

설계자가 무엇을 기준으로 설계했는지를 정의하기 때문입니다.

 

예를 들어 다음과 같은 내용을 포함할 수 있습니다.

 

Process Design Basis

• Production Capacity
• Operating Hours
• Feed Condition
• Product Specification
• Design Pressure
• Design Temperature
• Utility Conditions
• Environmental Conditions
• Applicable Codes & Standards

예를 들어,

Design Pressure : 10 barg
Design Temperature : 150°C
Operating Days : 330 days/year

 

와 같은 조건이 정해져 있다면 이를 기준으로 장비와 배관을 설계하게 됩니다.

 

여기서 중요한 것은 Proposal 단계에서 모든 설계값을 확정할 필요는 없다는 것입니다.

 

오히려 아직 확정되지 않은 조건은 명확하게 Assumption으로 관리해야 합니다.

 

 

8. Assumption과 Exclusion은 왜 중요한가?

 

Proposal에서 엔지니어들이 가장 조심해야 하는 부분입니다.

 

예를 들어 기존 공장에서 Steam을 공급받는다고 가정해 보겠습니다.

 

그런데 실제 프로젝트가 시작되고 확인해 보니 기존 Steam Header의 Capacity가 부족했습니다.

 

그러면 문제가 생깁니다.

 

• Steam Boiler를 추가해야 할까요?
• 기존 Boiler를 증설해야 할까요?
• 아니면 다른 공정 조건을 변경해야 할까요?

이것은 모두 비용과 일정에 영향을 줍니다.

 

따라서 Proposal 단계에서

“Existing Steam Header Capacity is assumed to be sufficient for the proposed process.”

 

와 같이 가정을 명확하게 남겨두는 것이 중요합니다.

 

이렇게 하면 나중에 실제 조건이 다를 경우, “우리가 어떤 조건을 전제로 가격과 설계를 제시했는가?”를 확인할 수 있습니다.

 

AACE 역시 프로젝트의 Scope, Assumption, Exclusion, Risk 등을 명확하게 문서화하는 것이 비용과 프로젝트 관리의 중요한 기반이 된다고 설명합니다.

 

 

9. Schedule — 우리는 언제까지 만들 수 있는가?

 

Technical Proposal에는 기술만 들어가는 것이 아닙니다.

 

프로젝트를 언제까지 완료할 것인지도 중요한 기술적 제안사항입니다.

 

예를 들어 다음과 같은 일정이 있을 수 있습니다.

 

1. Contract Award
2. Basic Engineering
3. Detail Engineering
4. Procurement
5. Fabrication
6. Construction
7. Pre-commissioning
8. Commissioning
9. Performance Test
10. Mechanical Completion / Handover

 

여기에서 중요한 것은 단순히 날짜를 나열하는 것이 아닙니다.

 

Critical Path가 무엇인지 이해하고 있어야 합니다.

 

예를 들어 Long Lead Equipment가 8개월 걸린다면, Engineering이 끝난 후 Procurement를 시작하는 방식으로는 전체 Schedule을 맞출 수 없을 수 있습니다.

 

따라서 Proposal 단계에서부터

“어떤 장비를 먼저 발주해야 하는가?”

 

를 검토해야 합니다.

 

AACE의 Schedule Basis 관련 가이드에서도 프로젝트 일정은 단순한 날짜 목록이 아니라 프로젝트 계획을 시간축으로 표현한 것이며, 일정의 가정·제외사항·Risk와 주요 고려사항을 함께 문서화하는 것이 중요하다고 설명합니다.

 

 

10. Project Organization — 누가 이 프로젝트를 수행하는가?

 

고객은 회사 이름만 보는 것이 아닙니다.

 

실제로 누가 프로젝트를 수행할 것인지도 중요합니다. 예를 들어,

 		  Project Director
    	  		│
  		  Project Manager
          		│
    ┌───────┬───────┬──────────┬────────────┐
Process Mechanical Piping Electrical  Instrumentation
  			│
	Procurement / Construction / Commissioning

 

와 같은 Project Organization을 제시할 수 있습니다. 특히 대형 EPC 프로젝트라면

 

• Project Manager
• Engineering Manager
• Procurement Manager
• Construction Manager
• Commissioning Manager
• HSE Manager
• QA/QC Manager
• Project Control

등의 역할과 책임을 명확하게 정의할 필요가 있습니다. 결국 고객이 알고 싶은 것은 간단합니다.

“이 프로젝트를 맡겼을 때 책임지고 끌고 갈 사람이 있는가?”

 

입니다.

 

 

 

11. Quality와 HSE — 기술적으로 좋은 프로젝트만으로 충분하지 않다

 

Engineering 프로젝트는 단순히 설비를 만드는 것으로 끝나지 않습니다.

 

품질과 안전을 확보하면서 만들어야 합니다.

 

따라서 Proposal에는 Quality Plan과 HSE Plan도 포함될 수 있습니다.

 

예를 들어 Quality 측면에서는

 

• Engineering Design Review
• Vendor Document Review
• Inspection & Test Plan
• Material Inspection
• Factory Acceptance Test
• Site Inspection
• Punch Management

등을 제시할 수 있습니다. HSE 측면에서는

 

• HAZID
• HAZOP
• Risk Assessment
• Construction Safety
• Permit to Work
• Emergency Response

등을 프로젝트 특성에 맞게 제시할 수 있습니다.

 

즉, “우리는 설비를 만들겠습니다.”가 아니라 “품질과 안전을 관리하면서 설비를 완성하겠습니다.”라는 접근입니다.

 

 

12. Risk & Mitigation — 문제가 생기지 않는다고 약속하지 않는다

 

Technical Proposal에서 중요한 역설이 하나 있습니다. 좋은 Proposal은

“우리 프로젝트에는 Risk가 없습니다.”

 

라고 말하지 않습니다. 오히려

“우리는 어떤 Risk가 있는지 알고 있으며, 이렇게 관리하겠습니다.”

 

라고 말합니다. 예를 들어,

 

Risk	영향	대응방안
Long Lead Equipment	Schedule Delay	Early Procurement
Existing Utility Capacity 부족	Cost/Schedule	Capacity Verification
Site Tie-in 제한	Construction Delay	Shutdown Plan
Vendor Data Delay	Engineering Delay	Vendor Document Schedule
Design Change	Cost/Schedule	Design Freeze 관리

 

와 같이 정리할 수 있습니다.

 

AACE 역시 프로젝트의 비용과 일정은 본질적으로 불확실성을 포함하며, Scope의 성숙도와 실행전략 등이 Risk에 영향을 줄 수 있다고 설명합니다.

 

따라서 Risk를 숨기는 것보다 Risk를 이해하고 관리할 수 있다는 것을 보여주는 것이 더 중요합니다.

 

 

13. Technical Proposal과 Commercial Proposal은 다르다

 

여기서 한 가지 구분해야 할 것이 있습니다.

 

Technical Proposal ≠ Commercial Proposal입니다.

 

쉽게 말하면,

 

Technical Proposal

“무엇을, 어떻게 수행할 것인가?”

 

Commercial Proposal

“그것을 얼마에 수행할 것인가?”

 

입니다.

 

하지만 둘은 서로 떨어져 있지 않습니다.

 

예를 들어 Engineering Man-hour가 10,000 MH로 산정되었다면 그 결과는 Engineering Cost에 영향을 줍니다.

 

Major Equipment를 어떤 사양으로 선정하느냐에 따라 Equipment Cost가 달라집니다.

 

Construction 방법에 따라 Construction Cost와 Schedule이 달라집니다.

 

즉, Technical Proposal → Scope → Quantity → Man-hour → Cost → Schedule이 서로 연결되어 있습니다.

 

그래서 Proposal을 작성할 때 Engineering, Estimation, Procurement, Construction, Project Control이 따로 움직이면 문제가 발생합니다.

 

 

14. Technical Proposal에서 가장 중요한 것은 '일관성'이다

 

Proposal을 작성하다 보면 흔히 이런 일이 발생합니다.

 

Technical Team은

"이 장비를 적용하겠습니다."

 

라고 작성했습니다.

 

그런데 Estimator는 다른 장비 가격을 넣었습니다.

 

Engineering은 12개월 Schedule을 생각하고 있는데, Project Control에서는 10개월 Schedule을 제시합니다.

 

Construction Team은 기존 설비 Shutdown이 필요하다고 판단했는데, Proposal에는 Shutdown이 없는 것으로 되어 있습니다.

 

이렇게 되면 Proposal 하나 안에서 서로 다른 프로젝트가 만들어집니다.

 

따라서 Proposal Review에서는 최소한 다음 항목들이 서로 일치하는지 확인해야 합니다.

Scope ↔ Design ↔ Equipment ↔ Man-hour ↔ Cost ↔ Schedule ↔ Risk

 

이것이 Technical Proposal의 핵심입니다.

 

 

15. 결국 Technical Proposal은 '미래 프로젝트의 축소판'이다

 

Technical Proposal을 조금 다른 관점에서 보면 재미있는 사실을 발견할 수 있습니다.

 

Proposal은 아직 프로젝트가 시작되지 않았습니다.

 

하지만 그 안에는 이미 프로젝트의 상당 부분이 들어 있습니다.

 

• 무엇을 만들 것인지
• 어디까지 할 것인지
• 어떤 기술을 사용할 것인지
• 어떤 장비를 사용할 것인지
• 얼마나 사람이 필요한지
• 얼마가 필요한지
• 언제 끝낼 것인지
• 어떤 Risk가 있는지
• 누가 수행할 것인지

이 모든 것이 들어갑니다. 그래서 저는 Technical Proposal을

“아직 시작하지 않은 프로젝트의 축소판”

 

이라고 생각합니다. Proposal을 제대로 만들었다면 실제 프로젝트가 시작됐을 때도 자연스럽게 이어질 수 있어야 합니다.

 

반대로 Proposal과 실제 프로젝트가 완전히 다르다면, 수주 당시부터 이미 문제가 시작된 것입니다.

 

 

16. Beer to Zero Project에서는 어떻게 제안할까?

 

다시 우리의 Beer to Zero Project로 돌아가보겠습니다. 고객이 우리에게 말합니다.

“무알코올 맥주 생산공장을 만들어 주세요.”

 

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

 

• 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 - 설계를 하는 데 엔지니어가 얼마나 필요한가?

 

그리고 이제 그 결과를 하나의 문서로 묶습니다.

 

"Technical Proposal", 우리는 고객에게 이렇게 제안할 수 있습니다.

“고객의 생산능력과 제품 요구사항을 기준으로 다음과 같은 공정 시스템을 적용하겠습니다.”

“당사의 수행범위는 Process Engineering부터 Commissioning까지이며, 기존 Utility Tie-in은 아래와 같은 조건을 전제로 합니다.”

“주요 장비는 다음과 같은 설계 기준으로 선정하겠습니다.”

“전체 프로젝트는 약 ○○개월의 일정으로 수행하며, Long Lead Equipment는 초기 단계에서 선발주하겠습니다.”

“예상되는 주요 Risk는 Utility Capacity와 Site Tie-in이며, 각각 다음과 같은 방법으로 관리하겠습니다.”

“이를 위해 다음과 같은 Project Organization과 Engineering Man-hour를 투입하겠습니다.”

 

이제 고객은 단순히 “이 회사가 공장을 만들 수 있다.”는 이야기를 듣는 것이 아닙니다.

 

“이 회사가 우리 프로젝트를 어떻게 이해하고 있으며, 어떤 방법으로 수행할 것인지”를 볼 수 있습니다.

 

그것이 Technical Proposal의 역할입니다.

 

 

17. 좋은 Technical Proposal의 조건

 

좋은 Technical Proposal은 두꺼운 문서가 아닙니다. 다음 질문에 명확하게 답할 수 있는 문서입니다.

 

1. 우리가 고객의 요구사항을 제대로 이해했는가?
2. 우리가 수행할 Scope가 명확한가?
3. 어떤 기술을 적용할 것인지 설명되어 있는가?
4. 설계의 기준과 가정이 명확한가?
5. 비용과 일정이 기술적 내용과 일치하는가?
6. 주요 Risk를 알고 있는가?
7. 실제로 이 프로젝트를 수행할 조직과 방법이 있는가?
8. 우리가 무엇을 하지 않는지도 명확한가?

이 질문에 답할 수 있다면 Proposal은 단순한 홍보자료를 넘어섭니다.

 

 

18. 엔지니어에게 Technical Proposal이 중요한 이유

 

엔지니어 입장에서 Technical Proposal은 단순히 입찰팀이나 영업팀이 작성하는 문서라고 생각하기 쉽습니다.

 

하지만 실제로는 그렇지 않습니다. Technical Proposal의 내용 하나하나가 이후 프로젝트의 기준이 될 수 있기 때문입니다.

 

특히 엔지니어가 작성한

 

• Design Basis
• Equipment Specification
• Scope
• Assumption
• Exclusion
• Man-hour
• Schedule
• Technical Deviation

등은 이후 실제 Engineering과 Procurement, Construction 단계와 연결됩니다.

 

따라서 Proposal 단계에서부터 엔지니어는 “이 문장이 나중에 계약서와 실제 설계에 들어가도 문제가 없는가?”를 생각해야 합니다.

 

결국 좋은 엔지니어는 설계를 잘하는 사람만이 아닙니다.

 

자신이 제안한 설계가 비용, 일정, Scope, Risk와 어떻게 연결되는지를 이해하는 사람입니다.

 

 

제안서는 프로젝트의 첫 번째 설계도다

 

프로젝트를 수주하기 전에는 아직 공장이 존재하지 않습니다.

 

장비도 발주하지 않았고, 배관도 설치하지 않았으며, 엔지니어도 실제 설계를 시작하지 않았습니다.

 

그런데 Technical Proposal에는 이미 프로젝트의 모습이 어느 정도 그려져 있습니다.

 

• 무엇을 만들 것인지.
• 어떻게 만들 것인지.
• 얼마나 투입할 것인지.
• 언제까지 만들 것인지.
• 어떤 Risk가 있는지.
• 그리고 어디까지 책임질 것인지.

그래서 Technical Proposal은 단순한 제안서가 아닙니다.

 

저는 Technical Proposal을 이렇게 정의하고 싶습니다.

“Technical Proposal은 고객의 요구사항을 실제 프로젝트 수행계획으로 변환한 첫 번째 설계도이다.”

 

그리고 이 설계도가 고객에게 받아들여지는 순간, 우리가 지금까지 준비했던 Feasibility, Scope, Cost, Schedule, Risk, Man-hour는 더 이상 검토자료가 아닙니다.

 

실제로 수행해야 할 프로젝트의 기준이 됩니다.

 

이제 프로젝트는 제안 단계를 지나 계약 단계로 넘어가게 됩니다.

 

그리고 여기서부터 또 하나의 중요한 질문이 시작됩니다.

 

“고객과 우리는 정확히 무엇을 약속한 것인가?”

 

다음 글에서는 이 질문을 다뤄보겠습니다.

 

Part 16. 계약서에 무엇을 담아야 하는가 - Contract & Commercial Terms

 

 

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