Contracts

Constraints

Cost-Plus (CP)

Time and Material (T&M)

Time and Material/Not-To-Exceed (T&M/NTE)

Lump-Sum, or Fixed-Price

Hybrid

Project Life Cycle

Feasibility Study

Definition

System Design

Software Development

Deployment

Support

Project Management Tools

The Scope of Work (SOW)

The Estimate

The Design Schedule

The Status Report

Project Management Techniques

Assessing Project Status

Management of Change (MOC)

​

​

36.1 Introduction

Project Management and Execution 프로젝트 관리와 실행

프로젝트(Project)란 제품이나 서비스를 창출하기 위한 일시적인 활동을 의미합니다. 일시적인 프로젝트는 명확한 시작과 종료 시점을 가지고 있으며, 일반적으로 명확한 시작점과 종료점을 가진 일련의 작업들로 구성됩니다. 이러한 시점은 시간, 자원, 그리고 최종 결과에 의해 제한됩니다.

엔지니어링 프로젝트는 특정 목적을 달성하기 위한 수단이며, 이를 위해서는 충족되어야 할 필요성이 인식되고, 그 필요성이 합리적인 투자로 충족될 수 있다는 기대가 있어야 합니다. 프로젝트의 소유자는 위험과 보상을 저울질한 후, 해당 프로젝트가 가치 있다고 판단해야 합니다. 이러한 위험/보상 평가(risk/reward assessment)는 때로는 과학이라기보다는 예술에 가까운 작업이 되기도 합니다. 모든 프로젝트—특히 자동화 프로젝트—는 일정 수준의 위험을 수반합니다.

​

대부분의 분야보다 자동화 프로젝트에서 위험을 잘못 관리할 경우 그 영향은 치명적일 수 있습니다. 잘못된 추정으로 인한 경제적 손실도 충분히 심각하지만, 운영자나 일반 대중에게 미칠 수 있는 잠재적 위험은 훨씬 더 클 수 있습니다. 따라서 사전 평가, 단기 및 장기 계획, 프로젝트 관리에 대한 잘 설계된 절차가 반드시 필요합니다. 이러한 평가는 문제에 대한 철저한 이해에서 시작됩니다. General Yeager의 말처럼, 핵심은 “추측이 아닌 이해”입니다.

​

적절한 프로젝트 관리는 프로젝트 관리자(Project Manager, PM)로부터 시작됩니다. 훌륭한 PM의 자질은 다음과 같습니다:

​

• 실제 고객이 누구인지 이해하고, 고객/소유자(위험 부담자)가 처음에 투자를 결정하게 된 동기를 철저히 파악합니다.
• 자신의 조직 내에서는 고객의 입장을 대변하고, 고객과 협력할 때는 자신의 조직을 대변합니다. PM은 프로젝트 팀 내에서 누구보다도 두 진영 사이에서 균형을 유지해야 합니다.
• 프로젝트 관리 기술뿐만 아니라 기술적, 물류적, 인간 관계적 과제에 대한 지식을 갖추고 있어야 합니다.
• 프로젝트 팀의 모든 구성원이 문제를 철저히 이해하도록 합니다.
• 프로젝트의 진행 상황을 지속적으로 모니터링하며, 합의된 기준에 따라 측정합니다.

​

프로젝트 관리자든 팀 구성원이든, 여기서 논의되는 원칙과 개념을 철저히 이해하는 것은 성공의 길을 넓히는 데 도움이 됩니다. 본 장에서는 다음과 같은 주요 주제를 다룹니다:

​

• 계약(Contracts) – 가장 일반적인 프로젝트 유형은 무엇인가?
• 프로젝트 생애주기(Project Life Cycle) – 일반적인 절차는 어떻게 되는가?
• 프로젝트 관리 도구(Project Management Tools) – 프로젝트 관리자의 도구함에는 무엇이 있는가?
• 프로젝트 실행(Project Execution) – 진행 중인 프로젝트를 관리하기 위한 핵심 기술은 무엇인가?

​

​

​

​

36.2 Contracts

​

프로젝트 팀의 각 구성원은 프로젝트의 매개변수를 기준으로 자신만의 고유한 관점에서 성공을 정의합니다. 고객의 관점에서 성공은 주어진 시간과/또는 예산 내에서 원하는 결과를 달성하는 것입니다. 이는 서비스 제공자의 관점보다 더 넓은 해석일 수 있으며, 서비스 제공자는 수익 창출에도 관심이 있기 때문입니다.

​

진정으로 성공적인 프로젝트란 고객과 서비스 제공자 모두가 결과에 만족하는 프로젝트입니다. 이를 위해서는 가능한 한 넓은 성공 영역(zone of success)이 형성되어야 합니다(Figure 36-1 참조).

​

“성공 삼각형(success triangle)”은 제공된 결과물이 고객의 비용 및 품질 기대치를 충족하면서도 서비스 제공자가 적절한 수익을 창출하고 양질의 작업에 대한 평판을 유지할 수 있을 때 형성됩니다. 이 편안한 영역 내에 머무는 것은 때때로 까다로운 일이지만, 프로젝트의 “물리학(physics)”을 이해하면 큰 도움이 됩니다. 프로젝트의 물리학은 그 제약 조건(constraints)에 의해 정의됩니다.

​

Figure 36-1: Success Triangle

​

36.2.1 제한사항 (Constraints)

시간(time)과 자원(resources)은 설계 과정에 제약을 가하는 두 가지 매개변수입니다(Figure 36-2 참조). 프로젝트에서 시간은 기간(달력 기준 시간) 또는 강도(노동 시간)를 의미할 수 있습니다. 이 문맥에서 “시간 중심(time driven)”이라는 용어는 프로젝트가 달력에 의해 제약을 받는다는 것을 의미하며, “비용 중심(cost driven)”이라는 용어는 프로젝트가 비용에 의해 제약을 받는다는 것을 의미합니다.

비용은 자재 비용(material cost)을 산출한 후, 설계 및 구축에 필요한 프로젝트 시간 단위당 강도 수준(맨아워, man-hours)을 측정하여 계산됩니다.

Figure 36-2: Effects of Constraints on Project Structure

고객과 엔지니어 또는 시공자 간의 관계는 명확하게 정의되어야 합니다. 공급업체가 견적을 제공하면, 해당 공급업체는 그 견적에 구속되며, 제시된 가격에 따라 자재나 서비스를 제공해야 합니다. 동일한 개념은 자동화 서비스 제공자(seller)에게도 적용됩니다. 판매자로서 제안서를 제출하는 행위는 계약 절차를 시작하는 것을 의미합니다. 고객(buyer)이 제안서를 수락하면, 판매자는 계약에 따라 실행할 법적 의무를 가지며, 고객 역시 이를 이행할 법적 의무를 가지게 됩니다. 다음은 가장 일반적인 계약 유형들입니다:

​

• “Cost-Plus”
• “Time and Material”(또는 “Time and Material, Not-to-Exceed”)
• “Lump Sum” 또는 “Fixed-Fee”
• “Turnkey”
• “Hybrid”

​

각 계약 유형은 참여자마다 서로 다른 위험/보상(risk/reward)의 균형을 형성하며, 이에 대한 설명은 다음에 이어집니다.

아래의 Table 36-1은 가장 일반적인 계약 유형들의 상대적인 위험/보상 요소를 보여줍니다. 각 계약 유형은 프로젝트 제약 조건(constraint)에 따라 분석되며, 다음의 척도에 따라 0~4로 평가됩니다:

​

• 0: 없음
• 1: 최소
• 2: 보통
• 3: 최대

​

예를 들어, 위험/보상 비율이 1/3이라면 이는 최소한의 위험과 최대의 보상을 의미하며, 해당 당사자에게 매우 바람직한 상태임을 나타냅니다.

​

36.2.2 Cost-Plus (CP)

Cost-Plus 계약은 판매자에게 수익을 보장합니다. 그 대가로 구매자는 프로젝트 내용과 판매자의 수행 방식에 대한 통제권을 유지할 수 있습니다. 이 계약에서 정의되는 매개변수는 프로젝트 전체 가격이 아니라 단가(unit rate)입니다. 단가는 각 직원의 시간당 요율이나 직원 분류(예: 엔지니어, 프로그래머, 디자이너, 사무원 등)에 따라 협의된 요율로 적용될 수 있습니다. 이러한 단가는 계약 기간 동안 유효하며, 업무 범위가 완료될 때까지 미래로 연장될 수 있습니다.

판매자 입장에서는 프로젝트 제약 조건과 관계없이 최소한의 협의된 수익이 보장됩니다(수익: 위험 없음, 보상 최소). 만약 판매자가 예산 이하로 작업을 완료하면 구매자는 뜻밖의 이익을 얻게 됩니다. 반면, 판매자가 예산을 초과하면 구매자가 그 비용을 부담해야 합니다. 그러나 판매자가 일정(schedule)에 의해 제약을 받는 경우, 일정 기반의 예산 통제가 가능해져 위험/보상 비율을 완화할 수 있습니다.

Table 36-1을 참조하면, 제약 조건이 내용(content)일 경우 판매자는 결국 원하는 결과를 얻게 됩니다(품질: 0, 위험 없음). 하지만 높은 비용이 발생할 위험이 매우 큽니다(비용: 3, 높은 위험). 이 시나리오에서는 구매자가 만족할 때까지 판매자가 무기한 작업을 수행할 수 있습니다.

하지만 일정이 제약 조건으로 정의되면, 품질에 대한 위험은 보통 수준으로 상승하고, 비용 초과에 대한 위험은 높은 수준에서 보통 수준으로 낮아집니다. 판매자는 무한한 자원을 투입할 시간이 없기 때문입니다.

이 계약 형식에서는 비용이 제약 조건이 아닙니다. 구매자는 내부적으로 승인된 예산을 가지고 있지만, 이 예산은 계약상 아무런 영향을 미치지 않습니다. 판매자가 구매자의 목표를 알고 그 범위 내에서 작업하는 것이 바람직하긴 하지만, 계약상 반드시 그렇게 해야 할 의무는 없습니다.

​

36.2.3 Time and Material (T&M)

T&M 계약은 Cost-Plus 계약과 매우 유사합니다. Cost-Plus에서는 서비스 제공자가 비용에 수익과 경비를 더해 보상받는 반면, T&M 계약에서는 비용, 수익, 경비에 더해 자재(material)와 마크업(markup)까지 보상받습니다. 이 계약에서도 정의되는 매개변수는 프로젝트 전체 가격이 아니라 단가(unit rate)입니다.

따라서 두 계약의 주요 차이점은 판매자가 자재에 대한 마크업을 통해 더 높은 잠재적 수익을 얻을 수 있다는 점입니다(Table 36-1 참조). T&M 계약의 품질(Quality) 및 비용(Cost)에 대한 위험/보상 시나리오는 Cost-Plus 형식과 동일합니다. 이 계약 유형에 대한 더 깊은 이해를 위해서는 Cost-Plus에 대한 설명을 참조하십시오.

T&M과 CP 형식 모두 구매자와 판매자 간의 안정적이고 장기적인 비즈니스 관계로 이어지는 검증된 구조입니다. 단, 판매자가 구매자의 이익을 보호하고 관계를 잘 관리하는 경우에 한합니다. 향후 프로젝트에 대한 기대는 판매자가 안일해지는 경향을 상쇄하는 유인책이 됩니다. 이러한 계약을 관리하는 데 있어 우수한 프로젝트 관리 기술은 다른 어떤 계약보다도 중요할 수 있습니다. 그 필요성이 즉각적으로 드러나지 않는 경우가 많기 때문입니다. 본 장 후반의 변경 관리(Management of Change, MOC) 섹션을 참조하십시오.

​

36.2.4 Time and Material / Not-To-Exceed (T&M/NTE)

CP와 T&M 시나리오는 대부분의 예산 위험을 구매자에게 부담시키는 구조입니다. “Not-To-Exceed(초과 금지)” 조건은 “비용”이라는 제약을 추가함으로써 이러한 구조를 반전시킵니다. 판매자의 잠재적 보상은 일반 T&M 형식과 마찬가지로 보통 수준에 머물지만, 제약 조건이 추가됨에 따라 수익에 대한 위험은 매우 빠르게 높은 수준으로 상승합니다.

또한 판매자가 예산 이하로 작업을 완료할 경우, 이익은 판매자가 아닌 구매자에게 돌아갑니다. 판매자에게 있어 높은 위험/보통 보상 구조는 작업 강도와 집중도를 높이며, 구매자와 협력하여 제품을 “조정(tweak)”하려는 의욕을 감소시킵니다. 그 결과, 구매자는 프로젝트 수행 방식에 대한 통제력을 일부 상실하게 되며, 양 조직 간의 의견 충돌 가능성이 다소 증가합니다.

​

36.2.5 Lump-Sum 또는 Fixed-Price

Lump-Sum과 Fixed-Price는 서로 교환 가능한 용어입니다. Lump-Sum 계약에서는 계약서에 정의된 매개변수가 고정된 작업 또는 납품물에 대한 고정된 프로젝트 가격입니다. 서비스가 제공되기 전에 가격이 협의되므로, Fixed-Price 계약은 구매자에게 비용 위험을 최소화해 줍니다.

또한 구매자는 일반적으로 여러 잠재적 판매자들이 최저가 입찰을 통해 경쟁하는 입찰 과정을 거친 후 계약을 체결합니다. 구매자는 최저가를 수락할 수도 있고, 각 입찰을 분석하여 계약 조건을 이행할 수 있을 것으로 판단되는 “합리적인 최저가”를 선택함으로써 가장 많은 비용을 절감하면서도 일정 수준의 신뢰를 유지할 수 있습니다.

​

판매자의 수익 위험은 제공되는 서비스나 제품이 “결정론적(deterministic)”인지 “확률론적(probabilistic)”인지에 따라 달라집니다. 예를 들어, 연구 개발이 거의 또는 전혀 필요 없는 “위젯”을 판매하는 경우, 해당 제품은 결정론적이며, 판매자는 생산에 필요한 자원과 자금을 정확히 알고 있을 것으로 간주됩니다. 반면, 도면이나 소프트웨어 목록이 오래되어 개보수(modification)가 필요한 기존 시설에 대한 작업을 수행하는 경우, 해당 프로젝트는 확률론적으로 간주되며, 판매자의 위험은 극대화됩니다.

​

판매자가 위험을 완화하고 동시에 보상을 극대화할 수 있는 한 가지 방법은 입찰에 “예비비(contingency)”를 추가하는 것입니다.

예비비는 정량화하기 어려운 일반적인 설계 개발 문제와 알려지지 않은 요소들을 대비하기 위한 항목입니다. 불확실성 수준이 낮으면 예비비도 낮게 설정할 수 있고, 불확실성이 높으면 예비비도 높아야 합니다. 적절한 예비비 수준은 존재하는 불확실성의 정도와 수용 가능한 위험 수준 간의 균형을 반영합니다. 때로는 판매자가 인력을 유지하기 위해 수익을 포기하고 예비비를 줄이기도 하며, 반대로 인력이 바쁜 경우에는 예비비를 높이기도 합니다.

​

판매자의 수익은 위에서 설명한 시나리오에 따라 위험에 처할 수 있지만, 동시에 높은 보상의 가능성도 존재합니다. 판매자가 예산 이하로 작업을 수행하면 구매자는 계약 금액 전액을 지불해야 하므로, 판매자는 높은 위험/높은 보상 구조를 갖게 됩니다.

​

고정 가격(fixed-price) 또는 일괄 계약(lump-sum) 프로젝트는 구매자에게 여러 가지 이점을 제공합니다. 그 중 가장 큰 이점은 자원 배분 능력의 향상입니다. 구매자는 프로젝트 자금(안전 여유분 포함)을 별도로 확보할 수 있으며, 추가 자금이 필요하지 않을 것이라는 높은 확신을 가질 수 있습니다. 이는 판매자가 다른 작업을 계획하는 데에도 유리하게 작용합니다. 구매자는 이러한 이점을 얻지만, Cost-Plus 형식과 비교할 때 프로젝트 실행 중 통제력을 상당 부분 상실하게 됩니다. 고정 가격 입찰을 제출하기 위해 입찰자들은 납품물뿐만 아니라 소유자가 정의한 업무 범위를 달성하기 위해 사용할 방법까지 명확히 정의하기 위해 자비로 작업을 수행합니다.

​

적절히 관리된다면 고정 비용 프로젝트는 양 조직 모두에게 가장 효율적이고 효과적인 형식이 될 수 있습니다. 그러나 판매자는 업무 범위의 확장(scope-creep)을 철저히 관리해야 합니다. 구매자가 입찰을 수락한 이후에는, 판매자가 수익성에 부정적인 영향을 미칠 수 있음이 입증되는 경우, 납품물이나 방법을 조정할 의무는 없습니다.

구매자가 업무 범위(scope of work)를 벗어난 요청을 하는 경우, 판매자는 해당 요청을 거부할 권리와 의무가 있으며, 구매자가 엔지니어링 변경 요청(engineering change order)을 승인할 때까지 이를 이행하지 않아도 됩니다(변경 관리(Management of Change) 참조). 이러한 방어적 태도는 사전에 합의된 변경 관리 방식이 적용되지 않을 경우, 고객과의 관계가 갈등으로 이어질 수 있습니다.

​

36.2.6 Hybrid

특정 프로젝트는 앞서 설명된 다양한 시나리오의 여러 특성을 동시에 나타낼 수 있습니다. 예를 들어, 초기 엔지니어링(탐색) 단계는 일반적으로 Cost-Plus 방식으로 수행됩니다. 이는 책임 있는 고정 견적을 제시하기에 충분한 정보가 아직 확보되지 않았기 때문입니다. 이후의 상세 설계 및 시공 단계는 Lump-Sum 방식으로 진행될 수 있습니다.

​

36.3 Project Lifecycle

프로젝트의 형식이 Lump-Sum이든 T&M이든 대부분의 자동화 프로젝트는 개발 및 실행 방식에서 유사한 흐름을 따릅니다. Figure 36-3은 ISA 공인 자동화 전문가(Certified Automation Professional, CAP) 프로그램에서 제시하는 이 생애주기 모델을 보여줍니다.

​

36.3.1 Feasibility Study

자동화 프로젝트는 종종 생산 현장에서 시작됩니다. 문제를 해결하거나 공정을 간소화할 필요가 생기기 때문입니다. 해당 문제를 해결하려면 누군가가 문제를 식별하고 그 특성과 영향을 상세히 설명하는 문서를 작성해야 합니다. 영향을 설명할 때 고려해야 할 주요 항목은 다음과 같습니다:

​

​

Figure 36-3: ISA-CAP Model for Automation Project Flow

A) 필요성 설명(Describe the Need)

고려해야 할 사항:

• 인력 안전
• 생산 속도
• 제품 품질
• 장비 신뢰성
• 유지보수
• 운전 가능성

​

B) 가능한 해결책 식별(Identify Possible Solutions)

• 문제 분석
• 비용 추정

​

C) 예비 업무 범위 개발(Develop a Preliminary Scope of Work)

프로젝트 목표를 명확히 설명하는 업무 범위(scope of work)를 작성합니다. 이 문서는 최소한의 비용으로 합리적인 견적을 산출할 수 있을 만큼 충분한 정보를 제공해야 합니다. 다음과 같은 정보가 포함되어야 합니다:

• 문서 목록
• 장비 목록
• 소프트웨어/하드웨어 성능 사양
• 서비스 제공자 성능 기준 예시:
• 문서는 어떻게 전달되어야 하는가?
• 문서 작성에 어떤 매체를 사용할 것인가? CADD? 수기?
• 어떤 설계 기준을 따라야 하는가? NFPA? NEC? 내부 기준?
• 원하는 일정은 무엇인가?
• 어떤 납품물이 요구되는가?
• 승인된 공급업체 목록
• 안전 관련 사항
• 보안

​

D) 비용/편익 분석 수행(Perform a Cost/Benefit Analysis)

비용/편익 분석은 가장 가능성 높은 투자 비용과 가장 가능성 높은 수익을 비교합니다. 이 분석 결과는 달력 기준 시간 단위로 표현될 수 있습니다. 예를 들어, 프로젝트 비용이 1천만 달러이고, 제품의 연간 순이익이 2백만 달러로 예상된다면, 해당 프로젝트는 5년의 회수 기간(payback)을 갖습니다.

​

E) 자동화 전략 개발(Develop an Automation Strategy)

자동화 전략은 플랜트 셧다운, 장비 가용성, 플랜트 인프라 상태 등 운전 가능성(operability) 문제를 고려해야 합니다. 또한 운영 부서와 유지보수 부서의 요구를 수용하고 기술적 문제도 해결해야 합니다.

​

F) 기술적 검토 수행(Perform Technical Studies)

기본 개념을 입증하기 위한 기술적 검토는 성공적인 프로젝트에 필수적입니다. 이 검토의 목적은 가능한 많은 변수와 미지 요소를 제거하는 것입니다.

​

G) 타당성 분석 수행(Perform Justification Analysis)

타당성 분석은 비용 외에도 시장 영향과 위험을 고려합니다. 이 분석은 해당 기업이 시장에서 경쟁사들과 비교해 어떤 위치에 있는지를 검토하며, 프로젝트가 성공했을 경우와 실패했을 경우 시장에 미치는 영향을 예측합니다.

​

H) 요약 문서 작성(Generate a Summary Document)

타당성 조사는 앞서 언급된 각 활동의 결과를 요약한 문서로 작성되어야 하며, 이는 프로젝트의 가치 평가를 지원하는 역할을 합니다.

​

​

​

​

36.3.2 Definition

​

프로젝트 정의 단계에서는 고객의 요구사항을 식별하고, 해당 요구를 충족시키기 위한 최적의 방법에 대해 고차원적인 분석을 수행합니다.

​

A) 운영 전략 결정(Determine Operational Strategies)

핵심 이해관계자를 식별하고 인터뷰하여 프로젝트의 실제 추진 동기를 파악해야 합니다. 이 프로젝트가 충족하고자 하는 필요는 무엇인가? 서비스 제공자는 고객이 모든 문제를 충분히 고려했으며, 프로젝트가 잘 수행될 경우 결과에 만족할 것이라는 확신을 가져야 합니다. 이 단계에서는 “의도치 않은 결과의 법칙(Law of Unintended Consequences)”도 고려해야 합니다.

​

B) 기술적 해결책 분석(Analyze Technical Solutions)

프로젝트의 진정한 목적이 식별되고 운영 전략이 수립되면, 문제에 대한 기술적 해결책을 모색해야 합니다. 이 과정에는 유사한 상황을 가진 현장 방문, 공급업체 및 제조업체 인터뷰, 때로는 테스트베드 평가나 파일럿 프로젝트가 포함될 수 있습니다.

​

C) 개념적 세부사항 수립(Establish Conceptual Details)

프로젝트의 개념 단계에서는 여러 종류의 문서가 작성됩니다. 이러한 문서들은 “상위 계층(upper-tier)” 문서라고 하며, 설계 기준을 개발하기 위한 개념적 세부사항을 설명합니다.

​

D) 비용 산정 작성(Generate a Cost Estimate)

앞서 개발된 개념적 세부사항은 설계 적용을 위한 기준선(baseline)을 제공합니다. 이제 상세한 업무 분류 구조(Work Breakdown Structure, WBS)를 기반으로 한 견적을 작성할 수 있습니다. 최초 견적 초안이 완성되면, 규모의 경제(economy of scale), 작업 중복 등 비용 절감 요소를 검토하기 위한 리뷰 사이클을 거쳐야 합니다.

​

E) 설계 기준 개발(Develop the Design Basis)

설계 기준(Design Basis)은 시스템 설계 단계(System Design Phase)를 위한 상세 실행 계획입니다. 정의 단계에서 수행된 조사 내용을 바탕으로 납품물(deliverables) 목록을 완성합니다.

​

36.3.3 System Design

시스템 설계(System Design) 단계의 주요 절차는 다음과 같습니다:

​

A) 위험 분석 수행(Perform Hazard Analysis, HAZOP)

설계 기준이 일정 수준까지 정의된 이후, 상세 설계가 시작되기 전에는 계획된 시스템에 대해 운전 가능성과 안전성을 분석해야 합니다.

​

B) 지침 수립(Establish Guidelines)

정의 단계에서 수집된 정보를 바탕으로 자동화 시스템에 적용할 표준, 템플릿, 지침을 수립하며, 인간 요소(human-factor) 영향을 고려하여 고객의 설계 기준과 선호도를 만족시켜야 합니다.

​

C) 장비 사양 및 계측기 데이터 시트 개발(Develop Equipment Specifications and Instrument Data Sheets)

공급업체 선정 기준, 물리적 환경 조건, 규정, 성능 요구사항 등을 고려하여 장기 납기 장비(long-lead-time equipment) 구매 및 시스템 설계·개발을 지원할 수 있도록 상세한 장비 사양과 계측기 데이터 시트를 작성합니다.

​

D) 데이터 구조 레이아웃 및 데이터 흐름 모델 정의(Define the Data Structure Layout and Data Flow Model)

데이터의 양과 유형을 고려하여 데이터 구조 레이아웃과 데이터 흐름 모델을 정의하며, 이는 하드웨어 선택 및 소프트웨어 개발을 위한 사양으로 활용됩니다.

​

E) 물리적 통신 매체, 네트워크 아키텍처 및 프로토콜 선택(Select the Physical Communication Media, Network Architecture, and Protocols)

데이터 요구사항을 기반으로 물리적 통신 매체, 네트워크 아키텍처, 프로토콜을 선택하여 시스템 설계를 완성하고 시스템 개발을 지원합니다.

​

F) 자동화 솔루션의 기능 설명 개발(Develop a Functional Description of the Automation Solution)

정의 단계에서 설정된 규칙을 기반으로 제어 방식(control scheme), 알람, HMI, 보고서 등 자동화 솔루션의 기능 설명서를 개발하여 개발 및 프로그래밍을 안내합니다.

​

G) 시험 계획 수립(Develop a Test Plan)

선택된 방법론을 활용하여 기능 요구사항에 적합한 시험을 수행할 수 있도록 시험 계획을 설계합니다.

​

H) 상세 설계 수행(Perform Detail Design)

엔지니어링 및 시스템 설계를 구매 요청서, 도면, 패널 설계, 설치 세부사항으로 변환하여 사양 및 기능 설명에 부합하는 상세 정보를 제공함으로써 개발 및 구축을 위한 상세 설계를 수행합니다.

​

I) 시공 작업 패키지 준비(Prepare Construction Work Packages)

상세 설계 정보와 문서를 체계적으로 정리하여 프로젝트를 시공 단계로 이관할 수 있도록 포괄적인 시공 작업 패키지를 준비합니다.

​

J) 조달(Procurement)

설계 단계 후반에는 여러 조달 활동이 발생합니다. 자재 및 장비의 납기 시간(delivery lead time)은 발주 시점과 관련하여 반드시 고려되어야 합니다.

​

36.3.4 Software Development

시스템 설계 단계가 적절히 수행되었다면, 소프트웨어 개발 단계는 계획에 따라 실행하는 과정이 됩니다. 대부분의 경우, 아래에 설명된 영역에서 개발되는 콘텐츠는 이전 단계에서 이미 정의된 계획에 기반합니다. 소프트웨어 개발에 포함되는 주요 절차는 다음과 같습니다:

​

A) HMI(Human-Machine Interface) 시스템 개발

다음 항목들을 기반으로 HMI 시스템을 개발합니다:

• 알람 그룹화 및 경보 계획(Alarm Grouping and Annunciation Plan)
• 알람 및 알람 설정값 목록(Alarm and Alarm Setpoint List)
• HMI 화면 계층 구조 및 탐색 계획(HMI Screen Hierarchy and Navigation Plan)
• HMI 색상 구성 및 애니메이션 계획(HMI Color Scheme and Animation Plan)
• 운전 보안 계획(Operational Security Plan)

​

B) 데이터베이스 및 보고 기능 개발

다음 항목들을 기반으로 데이터베이스 및 보고 기능을 개발합니다:

• 데이터 기록기 목록 및 보관 계획(Data Historian List and Archival Plan)
• 데이터 백업 및 복구 계획(Data Backup and Restore Plan)
• 보고서 및 보고 일정 계획(Report and Report Scheduling Plan)

​

C) 제어 시스템 구성 및/또는 프로그램 개발

다음 항목들을 기반으로 제어 시스템 구성 또는 프로그램을 개발합니다:

• 논리 다이어그램(Logic Diagrams)
• 장치 제어 상세 시트(Device Control Detail Sheets, DCDS)
• 공정 제어 상세 시트(Process Control Detail Sheets, PCDS)
• 시퀀스 제어 상세 시트(Sequence Control Detail Sheets, SCDS)
• 레시피(Recipes)
• 인터록 목록 및 알람/트립 설정값 목록(Interlock Lists and Alarm/Trip Setpoint Lists)

​

D) 데이터 전송 계획 구현(Implement the Data Transfer Plan)

통신 프로토콜 및 사양을 활용하여 처리량을 극대화하고 데이터 무결성을 확보할 수 있는 데이터 전송 방법론을 구현합니다.

​

E) 운전 보안 및 데이터 무결성 계획 구현(Implement the Operational Security and Data Integrity Plan)

이해관계자의 요구사항에 따라 보안 방법론을 구현하여 손실 및 위험을 최소화합니다.

​

F) 업무 범위 준수 검토 수행(Perform a Scope Compliance Review)

정의된 절차를 사용하여 구성 및 프로그래밍을 검토하고 기능 요구사항에 대한 준수 여부를 확인합니다.

​

G) 기능(또는 공장) 수용 시험 계획 개발 및 실행(Develop and Implement the Functional (or Factory) Acceptance Test Plan, FAT)

시험 계획에 따라 자동화 시스템을 테스트하여 기능 요구사항에 대한 준수 여부를 판단합니다.

​

H) 문서 정리 및 인수 준비(Assemble Documentation, and Prepare for Turnover)

개발 과정에서 작성된 모든 문서 및 사용자 매뉴얼을 정리하여 고객 및 최종 사용자에게 필수 지식을 전달할 수 있도록 준비합니다.

​

36.3.5 Deployment

“배포(deployment)” 단계, 또는 시공(construction) 단계는 설계가 실제로 구현되는 단계입니다. 배포 단계는 WBS 영역 설계가 완료됨에 따라 설계 단계 활동과 일정 부분 겹쳐서 진행되는 경우가 많습니다. 이 겹치는 기간 동안에는 설계보다 시공자의 요구가 더 중요해집니다. 작업 중단은 어떤 경우에도 피해야 하며, 필요하다면 진행 중인 설계 활동을 중단하고 3단계 문제 해결에 집중해야 할 수도 있습니다.

현장에 도착한 자동화 전문가는 다음의 절차를 시작해야 합니다:

​

A) 현장 장치 상태 확인(Verify Field Device Status)

모든 현장 장치에 대해 수령 확인(receipt verification)을 수행하며, 공급업체 기록과 설계 사양을 비교하여 장치가 사양에 부합하는지 확인합니다.

​

B) 설치된 장비 점검(Inspect Installed Equipment)

설치된 장비에 대해 물리적 점검을 수행하며, 시공 도면과 비교하여 설계 도면 및 사양에 따라 설치되었는지를 확인합니다. 시공 활동 상태는 아래에 제시된 시운전 준비 보고서(Startup Readiness Report)와 유사한 형식의 보고서로 기록되어야 합니다.

​

계측기 데이터베이스와 I/O 목록을 기반으로 시운전 준비 보고서(Startup Readiness Report)를 작성하면, 이 과정을 체계적이고 검증 가능한 절차로 만들 수 있습니다.

​

C) 하드웨어 및 소프트웨어 설치(Install Hardware and Software)

구성(configuration) 및 프로그램을 대상 장치에 로딩하여 시험 준비를 완료합니다.

​

D) 시스템 예비 점검 수행 및 결함 수정(Perform Preliminary System Checks; Troubleshoot and Correct Faults)

설치 과정에서 식별된 예기치 않은 문제를 해결하기 위해 문제 해결(troubleshooting) 기술을 활용하여 결함을 수정합니다.

​

E) 제어 소프트웨어에 대한 현장 수용 시험 수행(Perform the Site Acceptance Test for the Control Software)

설계 문서에 따라 구성 및 프로그래밍을 시험 계획에 따라 테스트하여 시스템이 사양대로 작동하는지 검증합니다.

​

F) 통신 및 현장 장치에 대한 현장 수용 시험 수행(Perform the Site Acceptance Test for Communications and Field Devices)

설계 사양에 따라 통신 시스템 및 현장 장치를 시험하여 정상 작동 여부를 확인합니다. 이 단계는 종종 “체크아웃(checkout)” 또는 “범프 앤 스트로크(bump and stroke)” 단계라고도 불리며, 각 현장 장치는 정상 작동을 입증하기 위해 작동 테스트를 수행해야 합니다.

​

G) 현장 안전 시험 수행(Perform the Site Safety Test)

시험 계획에 따라 모든 안전 요소 및 시스템을 시험하여 안전 기능이 설계대로 작동하는지 확인합니다.

​

H) 현장 보안 시험 수행(Perform the Site Security Test)

시험 계획에 따라 모든 보안 기능을 시험하여 보안 기능이 설계대로 작동하는지 확인합니다.

​

I) 교육 계획 실행(Execute the Training Plan)

시설 인력에게 시스템 운전 및 유지보수에 대한 초기 교육을 제공하며, 교실 교육과 실습 교육을 통해 시스템의 적절한 사용을 보장합니다.

​

J) 현장 시스템 무결성 시험 수행(Perform the Site System Integrity Test, 즉 시운전 및 커미셔닝)

시험 계획에 따라 시스템 수준의 시험을 수행하여 전체 시스템이 설계대로 작동하는지 확인합니다. 이 단계에서 시험이 성공적으로 완료되면 시스템 시운전(startup)이 이루어진 것으로 간주됩니다. 이 단계가 완료되면 시스템은 일반적으로 “커미셔닝(commissioned)”된 것으로 간주됩니다. 시운전은 체계적이고 순차적으로 진행되어야 하며, 공식적인 시운전 절차가 권장됩니다.

​

K) 종료 및 평가(Closeout & Assess)

배포 단계의 마지막 절차는 종료(closeout) 단계입니다. 이 단계에서는 다음과 같은 작업이 수행됩니다:

​

• 프로젝트 문서를 실제 시공 조건(as-built condition)을 반영하여 최종화합니다(배포 과정 중 발생한 변경 사항을 문서화). 시공 중 발생한 레드라인(redline) 수정 사항은 원래 설계 문서에 반영되어야 합니다.
• 프로젝트 문서를 최종 사용자에게 인계합니다.
• 최종 청구 관련 사항을 해결합니다.
• 사후 평가(post-mortem)를 통해 교훈을 분석하고, 우수 성과를 인정합니다.
• 프로젝트 종료를 기념하는 행사를 개최합니다. 직원들의 노고를 인정하는 것은 매우 중요합니다.

​

36.3.6 Support

프로젝트의 “지원(Support)” 단계는 자동화 전문가에게 매우 중요한 단계입니다. 많은 경우, 이 단계에서 다음 주요 프로젝트가 도출됩니다.

​

A) 시스템 성능 모니터링 계획 수립 및 실행(Develop and Implement a System Performance Monitoring Plan)

정해진 절차에 따라 시스템 성능과 기록을 주기적으로 검증하여 표준, 규정 및 모범 사례에 대한 준수 여부를 확인합니다.

​

B) 장기 기술 지원 계획 수립 및 실행(Develop and Implement a Long-Term Technical Support Plan)

시스템 전문 지식을 활용하여 시설 인력에게 기술 지원을 제공하고 시스템 가용성을 극대화합니다.

​

C) 장기 교육 계획 수립 및 실행(Develop and Implement a Long-Term Training Plan)

시설 인력에 대한 교육 필요 분석을 주기적으로 수행하며, 역량 평가(skill assessments)를 통해 교육 프로그램의 목표를 설정합니다.

​

D) 시설 인력에 대한 정기 교육 제공(Provide Periodic Training for Facility Personnel)

식별된 교육 목표를 기반으로 시설 인력에게 교육을 제공하여 시스템에 사용되는 기술 및 제품에 대해 적절한 역량 수준을 유지할 수 있도록 합니다.

​

E) 시스템 성능 모니터링(Monitor System Performance)

소프트웨어 및 하드웨어 진단 도구를 활용하여 성능을 모니터링하고, 잠재적인 문제를 조기에 탐지할 수 있도록 지원합니다.

​

F) 시스템 재인증을 위한 정기 점검 및 시험 수행(Perform Periodic Inspections and Tests to Re-certify the System)

작성된 기준 및 절차에 따라 정기적인 점검 및 시험을 수행하여 시스템 또는 구성 요소가 요구사항을 충족하는지 검증합니다.

​

G) 지속적 개선 계획 수립 및 실행(Develop and Implement a Continuous Improvement Plan)

시설 인력과 협력하여 생산 능력, 신뢰성 및/또는 효율성을 향상시키기 위한 지속적 개선 활동을 수행합니다.

​

H) 교훈 문서화(Document Lessons Learned)

모든 이해관계자와 함께 프로젝트를 검토하여 교훈을 문서화하고 향후 프로젝트의 품질을 향상시킵니다.

​

I) 라이선스 및 서비스 계약 유지 관리 계획 수립 및 실행(Develop and Implement a License and Service Contract Maintenance Plan)

내부 및 외부 옵션을 검토하여 소프트웨어 및 장비의 라이선스, 업데이트, 서비스 계약을 유지 관리하며, 기능 및 가용성에 대한 기대를 충족시킵니다.

​

J) 예비 부품 추천 목록 제공(Provide a Recommended Spare Parts List)

설치된 장비의 구성과 고장 확률을 평가하여 예비 부품의 필요성을 결정하고, 시스템 가용성을 극대화하며 비용을 최소화합니다.

​

K) 시스템 관리 계획 수립(Develop a System Management Plan)

예방 정비 수행, 백업 구현, 복구 계획 설계를 통해 시스템 장애를 예방하고 복구할 수 있도록 시스템 관리 계획을 제공합니다.

​

L) 변경 관리 계획 수립 및 실행(Develop and Implement a Change Control Plan)

시스템 및 문서의 무결성을 보호하기 위해, 승인 및 변경 실행 절차를 수립된 기준 또는 관행에 따라 수행합니다.

​

​

​

​

36.4 프로젝트 관리 도구

​

잘 기획되고 잘 관리된 프로젝트는 성공할 수 있는 기회를 가진 프로젝트입니다. 프로젝트 팀이 계획대로 진행할 수 있도록 돕기 위한 일련의 도구들이 개발되었습니다. 이러한 도구들이 적절히 개발되고 활용된다면, 수행해야 할 작업을 정의하고, 정확한 진행 상황 보고를 용이하게 하며, 비용 초과 및/또는 일정 충돌의 가능성을 조기에 경고하는 데 도움이 됩니다. 이 도구에는 작업 범위(scope of work), 프로젝트 견적(project estimate), 프로젝트 일정(project schedule), 그리고 다양한 프로젝트 보고서(project reports)가 포함됩니다.

​

36.4.1 작업 범위(SOW)

작업 범위(scope of work)란 원하는 결과를 달성하기 위해 수행되어야 할 작업들을 설명한 것입니다. 이는 이후에 발생할 수 있는 가정의 수를 제거하거나 줄이기 위한 조사 과정을 거쳐 도출된 결과입니다. 따라서 SOW에는 프로젝트의 범위에 포함되는 각 프로세스 영역별 주요 작업이 나열되어야 합니다. 각 작업은 각 분야(discipline)의 관점에서 평가되어야 하며, 모든 실행 문장은 수행되는 작업의 유형을 전달할 수 있도록 동사로 시작해야 합니다. 각 작업에는 작업 분류 구조 번호(work breakdown structure (WBS) number)라는 고유 번호가 부여되어야 합니다. 이 항목에 대한 견적 및 자재 비용이 산출되어 작업 범위의 일부로 저장됩니다.

​

36.4.2 견적(Estimate)

견적(estimate)은 프로젝트 관리자에게 충분히 활용되지 않는 도구입니다. 많은 경우, 프로젝트는 실제 수행 방식과 관련이 없는 기준을 사용하여 견적이 산출되며, 이는 단순히 가격을 산출하는 데 그치는 쓸모없는 문서가 되어버립니다. 산출된 가격이 정확할 수는 있지만, 프로젝트에 의미 있는 구조를 제공할 기회를 놓치게 됩니다. 더 나은 방법은 작업 범위(scope of work)에 명시된 실행 계획을 반영한 형식으로 견적을 작성하는 것입니다.

​

견적과 작업 범위 간의 관계는 성공 가능성을 담은 범위를 형성하며, 이는 충분히 넓거나 지나치게 좁을 수 있습니다. 작업 범위와 일정은 프로젝트의 “기계적 요소”를 정의하며, 견적은 상황의 “물리적 요소”를 정의하여 프로젝트 수행 방식에 영향을 주는 한계를 설정합니다. 이러한 물리적 지표는 프로젝트 관리자가 전략적 수준에서 프로젝트를 추적할 때, 그리고 설계 감독자가 전술적 수준에서 작업을 관리할 때 사용하는 주요 도구입니다. 작업 범위는 수행해야 할 작업을 정의하며, 자재 비용 견적(material cost estimate)과 인건비 견적(labor cost estimate)은 작업이 수행될 수 있는 범위를 정의합니다.

​

견적에는 세 가지 주요 유형이 있습니다: 예산 견적(budget), 입찰 견적(bid), 확정 견적(definitive). 각 유형에 대한 간략한 설명은 다음과 같습니다:

​

• 예산 자재 및 인건비 견적(budgetary cost and labor estimate)은 현장과 공정에 익숙한 그룹에 의해 작성됩니다. 이 그룹은 프로젝트의 나머지 부분을 수행할 수도 있고 그렇지 않을 수도 있습니다. 이 견적의 목적은 주로 초기 자금 확보이며, 일반적으로 “간단하고 빠르게” 작성되며 정확도가 낮을 것으로 예상됩니다. 실제로 ±30%의 오차 범위가 허용됩니다. 이 견적 이전에는 공식적인 작업 범위가 작성되지 않았거나, 프로젝트 사양이 아직 확정되지 않았을 가능성이 높습니다. 이 유형의 견적은 일반적으로 고객으로부터 자금 지원을 받지 않거나, 충분한 자금이 지원되지 않습니다.

​

• 입찰 자재 및 인건비 견적(bid material cost and labor estimate)은 작업을 수주하려는 여러 엔지니어링 입찰자들에 의해 작성됩니다. 이 견적 역시 일반적으로 고객으로부터 자금 지원을 받지 않습니다.

​

• 확정 자재 및 인건비 견적(definitive material cost and labor estimate)은 입찰을 통해 계약을 수주한 엔지니어링 회사에 의해 작성됩니다. 이 견적은 일반적으로 프로젝트의 일부로 고객이 자금을 지원하므로, 대부분 충분한 자금이 확보됩니다. 계약이 체결되고 비밀 유지 계약 관련 사항이 해결되면, 엔지니어링 계약자는 고객이 내부 평가 과정에서 개발한 모든 정보에 접근할 수 있습니다. 이후 엔지니어링 회사는 기본 가정을 검증하기 위한 조사를 수행하고, 최종 작업 범위를 개발합니다. 이 정보는 때때로 프로젝트의 전반적인 그림을 크게 바꾸며, 엔지니어링 계약자는 새로운 정보에 따라 견적과 일정을 조정할 기회를 갖게 됩니다. 물론, 입찰 과정에서 모든 정보가 완전히 공개되었다면 이 재견적 과정은 생략되며, 입찰 견적이 곧 확정 견적이 됩니다.

​

견적은 프로젝트 관리의 기준 문서가 되어, 향후 성과를 측정하는 기준이 됩니다. 이는 작업 범위를 기반으로 하며, 가능하다면 작업별로 작업 범위를 반영해야 합니다. 다양한 견적 도구들이 존재하며, 어떤 도구를 선택하든 다음과 같은 견적을 산출할 수 있어야 합니다:

​

• 정확성: 작업 범위와 관련된 각 작업을 식별하고, 그 수행에 필요한 인력과 비용을 정량화함으로써 달성됩니다.

• 적시성: 반복 가능한 방식으로 작성되어야 합니다.

• 검증 가능성: 참고자료, 주석 및 보충 설명을 추가하고, 계산 과정을 분석할 수 있도록 제공함으로써 확보됩니다.

• 의미 있음: 모든 산출물을 실질적인 데이터와 연계함으로써 달성됩니다.

• 적응성: “만약의 경우” 시나리오에 대응할 수 있도록 쉽게 수정 가능해야 합니다.

​

​

36.4.3 설계 일정(Design Schedule)

견적(estimate)이 충분한 세부사항을 포함하고 작업 중심으로 구성되어 있다면, 이를 기반으로 일정(schedule)을 수립할 수 있습니다. 각 작업에는 고유한 작업 분류 구조 식별자(WBS identifier)가 부여되어야 하며, 연계된 관계를 식별하고 분석해야 합니다. 대부분의 경우, 이러한 관계는 다음과 같이 정의될 수 있습니다:

​

• 시작-시작(Start-to-start): 작업 A가 시작되어야 작업 B를 시작할 수 있습니다. 이 관계는 외부 요인이 일련의 일정된 작업을 시작할 때 사용됩니다. 예를 들어, 특정 자재의 입고가 여러 작업을 동시에 시작하게 할 수 있습니다.

• 종료-시작(Finish-to-start): 작업 A가 완료되어야 작업 B를 시작할 수 있습니다.

• 시작-종료(Start-to-finish): 작업 B가 시작되어야 작업 A를 완료할 수 있습니다.

• 종료-종료(Finish-to-finish): 작업 A가 완료되어야 작업 B를 완료할 수 있습니다.

​

이러한 관계가 정의되고 각 작업에 자원이 할당되면, 전체 프로젝트 기간을 산정할 수 있습니다. 고객이 이미 특정 기간을 염두에 두고 있을 수 있으며, 이는 일정을 특정 마일스톤(milestone)에 맞추도록 제약합니다. 일정이 이 시간표와 비교될 때, 일정을 늘리거나 줄이기 위해 자원을 조정해야 할 수도 있습니다.

​

36.4.4 진행 보고서(Status Report)

설계 팀은 주기적으로 작업 수행 상태에 대한 피드백을 요청받게 됩니다. 이 피드백은 다음과 같은 질문에 대한 답을 제공합니다: 프로젝트를 제시간에 시작하셨습니까? 현재 진행 상황은 어느 정도입니까? 어떤 작업을 시작하셨고, 언제 시작하셨습니까? 프로젝트를 제시간에, 예산 내에서 완료하실 수 있습니까?

​

WBS 마일스톤 일정(WBS milestone schedule)을 활용하면 가용 인력 시간 및/또는 비용을 세분화할 수 있습니다. 이는 예산을 더 작고 관리하기 쉬운 단위로 나누어 개별적으로 보고할 수 있도록 합니다. 각 작업(WBS item)에 대한 데이터를 수집한 후, 프로젝트 관리자(PM)가 이를 전체 프로젝트 일정에 반영합니다. 진행 보고는 일반적으로 다음과 같은 항목의 업데이트를 포함합니다:

​

• 시작일(Start date)

• 종료일(Finish date)

• 완료율(Percent complete)

• 잔여 인력 시간 추정치(Man-hours estimate to complete, Manhrs ETC)

​

그림(Figure) 36-5는 10개의 WBS 그룹으로 구성된 진행 데이터 수집 양식을 보여줍니다. 각 그룹은 6개의 하위 작업으로 세분화되어 있으며, 이는 앞서 설명한 프로젝트의 6단계(CAP 모델)에 해당합니다. 10개 중 WBS-T01과 WBS-T02만 시작된 상태입니다. WBS-T01은 계획의 철도차량 하역(Railcar Unloading) 영역을 포함하며, 250 인력 시간이 할당되어 있습니다. 이상적으로는 각 하위 작업이 개별적으로 평가되어 견적이 작성되고, 이 시간들이 주 작업에 합산되어 총 250이 되는 형식으로 견적이 작성되었어야 합니다. 하위 작업 가중치(Subtask Weight)는 반드시 100%가 되어야 합니다.

​

총 인력 시간, 하위 작업 가중치, 하위 작업 인력 시간 값은 프로젝트 시작 시점에 입력되어 모든 업데이트가 비교되는 기준 데이터(baseline data)를 형성합니다. 업데이트되는 데이터는 프로젝트 일정의 날짜와 잔여 인력 시간(Manhrs ETC)입니다. 일정 팀은 날짜 정보를 일정에 반영하고, 프로젝트 관리자는 인력 시간 데이터를 예산에 반영하여 분석합니다(이 내용은 이후에 설명됩니다). WBS-T01의 ETC가 188 인력 시간으로 표시되어 있으며, 총 250이 할당되어 있습니다. 이를 통해 설계팀이 100% – 188/250 = 약 25% 완료되었다고 추정할 수 있지만, 이는 정확하지 않으며 이후에 설명됩니다.

​

​

36.5 프로젝트 관리 기법(Project Management Techniques)

36.5.1 프로젝트 상태 평가(Assessing Project Status)

섹션 36.4.4에서 수집된 프로젝트 상태 업데이트 데이터는 프로젝트 관리자가 프로젝트의 성공 가능성을 예측하는 데 도움이 되는 추가 데이터를 개발하는 데 활용될 수 있습니다(그림 36-6 참조). 필요한 추가 정보는 다음과 같습니다:

​

• 획득 인력 시간(Earned hours) = 예상 완료율(Estimated percent complete) × 예산 인력 시간(budgeted man hours)

• 실제 인력 시간(Actual hours): 현재까지 실제로 투입된 시간으로, 근태 시스템을 통해 보고됩니다

• 잔여 인력 시간 추정치(Estimate to complete, ETC): 설계 팀이 남은 작업량을 반영하여 입력합니다

• 완료 시점 인력 시간 추정치(Estimate at completion, EAC) = 실제 인력 시간(Manhrs actual) + 잔여 인력 시간(Manhrs ETC); 최종적으로 예상되는 총 인력 시간을 나타냅니다

• 명목상 완료율(Apparent percent complete) = 실제 인력 시간 / 할당된 인력 시간; 초기 기대치 대비 실제 진행 상황을 측정합니다

• 실제 완료율(Actual percent complete) = 실제 인력 시간 / 완료 시점 인력 시간 추정치; 최종 기대치 대비 실제 진행 상황을 측정합니다

• 효율성 지수(Efficiency rating) = 실제 완료율 / 명목상 완료율

​

Figure 36-6: Analyzing Project Status

​

예상 완료율(estimated), 명목상 완료율(apparent), 실제 완료율(actual) 간의 차이를 주의 깊게 살펴보아야 합니다. 예를 들어 WBS-T01-2의 경우, 설계팀은 자신들이 95% 완료했다고 판단했습니다(예상). 그러나 실제로는 원래 예산을 이미 60% 초과한 상태였으며(명목상), 오래전에 완료되었어야 했습니다. EAC 관점에서 보면, 즉 실제로 중요한 기준에서 보면, 실제 완료율은 83%에 불과합니다.

​

36.5.2 변경 관리(MOC, Management of Change)

모든 프로젝트는 계약 유형과 관계없이 명시적 기대치와 암묵적 기대치를 모두 가지고 있습니다. 이는 계약서에 모든 가능한 상황을 명확히 기술하는 것이 불가능하기 때문입니다. 계약서에 명시된 프로젝트의 매개변수(명시적 기대치)는 충족될 수 있지만, 관계 악화, 오해, 잘못된 인식 등으로 인해 프로젝트가 실패할 수 있습니다(암묵적 기대치).

​

성공 삼각형(Success Triangle, 그림 36-1)을 다시 떠올려보면, 구매자는 품질과 비용에 집중하고, 판매자는 품질과 수익에 집중합니다. 어느 한쪽이라도 삼각형이 너무 작거나 존재하지 않는다고 판단하면 대부분의 프로젝트는 시작조차 하지 못합니다. 그럼에도 불구하고 프로젝트는 여전히 실패할 수 있습니다. 이는 프로젝트 시작 시점의 예상과 종료 시점의 실제 사이에 괴리가 존재한다는 것을 의미합니다.

​

이러한 문제의 핵심은 양측 모두가 변경을 얼마나 잘 관리할 수 있는가에 달려 있습니다. 계약 유형은 MOC 프로세스에 투입되는 노력의 정도에 영향을 미치지만, 어떤 경우든 변경 관리는 반드시 일정 방식으로 다루어져야 합니다. 가장 단순한 형태인 비용 가산 계약(cost-plus contract)의 경우에도 구매자는 최종 가격에 대한 기대를 가지고 있습니다. 작업 범위(scope of work)가 장기간에 걸쳐 통제 없이 확장된다면, 어떤 예산 견적도 안전하지 않으며, 판매자의 역량과 관계없이 구매자가 만족할 가능성은 매우 낮습니다.

​

따라서 변경 관리(MOC)는 프로젝트 시작 시점에 개방적이고 솔직하게 논의되어야 합니다. 변경 통보(change notice)를 처리하는 절차는 모든 당사자의 승인을 받아야 하며, 필요하다면 계약을 수정하는 수준까지 철저히 문서화되어야 합니다.

​

변경을 관리하기 위해서는 견고한 기준선(baseline)이 설정되어야 합니다. 이 기준선은 설계 기준(design basis)입니다. 설계 기준에는 산출물 목록뿐만 아니라 프로젝트 실행 계획(PEP)도 포함됩니다. PEP는 작업 범위를 포함하며, 방법론과 가정을 상세히 기술합니다. 프로젝트 팀의 모든 구성원은 설계 기준을 인지하고 있어야 하며, 수행 중인 작업을 지속적으로 해당 문서와 비교해야 합니다. 변경 사항이 발견되면, 변경 통보서를 작성하여 관리팀에 전달하고 검토 및 승인을 받아야 합니다.