프로젝트 작업과 프로젝트 결과물은 분해하는 데 사용됩니다. 더 작고, 더 관리하기 쉬울수록 분해할 수 있는 수준입니다.

첫 번째 요점: 너무 작아서 이론상으로는 나눌 수 없습니다.

두 번째 포인트는 도메인별로 관리할 수 있는 작업 패키지입니다. 즉, 이 작업 패키지를 별도로 할당할 수 있고 비용, 일정, 리소스를 추정할 수 있습니다.

기능 구조 트리는 시스템 성능을 다양한 기능으로 분해한 계층적 구조이며, 각 기능은 다시 하위 기능으로 분해되어 독립적으로 제품 형태를 구성할 수 있습니다.

제품 구조 트리는 시스템을 결정된 기능에 따라 순차적으로 형성된 모든 하드웨어 및 소프트웨어 제품으로 분해하는 계층 구조이며 WBS 작성의 기초가 됩니다.

작업분류체계 코드는 일련의 숫자와 구분 기호를 사용하여 작업분류체계의 각 단위를 식별하는 것을 의미합니다. WBS 코드와 WBS 사이에는 일대일 대응이 있습니다. 이 식별은 작업분류체계에서 해당 부서의 위치와 소속을 고유하게 결정할 수 있으며, 이는 컴퓨터 식별 및 WBS 검색을 용이하게 합니다.

작업분류체계 단위(WorkUnit)는 작업분류체계를 구성하는 각각의 독립적인 부분으로, 각 작업 패키지를 구성하는 작업 단위라고 합니다.

WorkPackage는 일련의 작업으로 구성된 작업 분할 구조에서 가장 낮은 작업 단위입니다. 작업 패키지를 사용하면 비용 예산 책정 및 비용 요약 통계를 쉽게 수행할 수 있습니다.

활동은 다양한 프로젝트 결과물을 완료하기 위해 수행해야 하는 특정 활동입니다. 문서 작성, 설계 및 도면, 생산, 테스트, 최종 조립, 테스트, 승인, 검토, 전송, 비행 테스트 등 작업 간의 논리적 관계를 설정하고 작업의 기간과 리소스 요구 사항을 추정하여 세부적인 기술 프로세스와 계획 프로세스를 형성합니다.

속성은 이름, 모델, 단계, 코드(WBS 코드), 작업 유형, 완료 단위, 사람을 포함하여 작업 유형, 위험 수준, 프로젝트 내 우선 순위, 품질 비용 및 작업 단위, 작업 패키지 및 작업에 대해 컴파일된 기타 정보를 나타냅니다. 준공책임자, 준공참여인원, 예산, 준공양식, 전임자 단위(직속 전임자와 직속 후임자의 관계), 계획공사기간, 실제 공사기간 등

내용: 프로젝트 결과

원칙: 내용은 단순 교육 프로그램이 아닌 이름, 성격, 카테고리(프로젝트 관리 종합 툴박스 교육 프로그램)로 명확하고 구체적으로 작성해야 합니다.

내용: 중요한 구성 요소

원칙: 100% 완료되어야 하며, 100% 미만인 경우 진행 중 일부 내용이 누락되며, 100%를 초과하는 경우 범위 크리프가 발생하여 일정의 다음 단계에 영향을 미칩니다.

내용 : 세부 구성

원칙: 결과물의 형식이 있어야만 특정 소유자에게 작업 패키지를 할당할 수 있습니다. 따라서 작업 패키지의 마지막 계층에는 실제로 작업 리더, 시간, 비용(다양한 리소스) 등이 포함될 수 있습니다.

(1) 프로젝트 작업에 대한 직접적인 지식이나 경험이 있어야 하는 핵심 프로젝트 팀 구성원을 구성합니다.

(2) 프로젝트 구현 순서에 따라 프로젝트 수명주기의 각 단계를 결정하거나, 제공된 제품 구조의 구성요소에 따라 또는 프로젝트 관리를 포함한 프로젝트 작업의 성격에 따라 프로젝트의 주요 결과물을 결정합니다. . 중요한 작업을 놓치지 않도록 이 수준부터 확인을 시작하는 것이 중요합니다.

(3) 프로젝트 수명주기의 각 단계에서 주요 작업을 완료하기 위한 구체적인 작업 또는 제품의 다양한 구조를 구현하고 프로젝트 납품 결과를 달성하기 위한 구체적인 작업을 결정합니다.

(4) 각 특정 작업을 완료하고 작업분류체계의 세 번째 수준을 형성하기 위한 하위 작업을 결정합니다.

(5) 각 하위 작업을 완료하는 데 필요한 구체적인 활동을 결정합니다. 각 활동이 완료된 후에는 성과 측정이 용이하도록 검증 가능한 결과를 출력해야 합니다.

분해가 철저하고 완전하며 올바른지 확인하십시오.

누락된 활동이 있습니까? 각 활동의 정의가 명확하고 완전합니까? 하위 수준 활동이 분해 항목을 완료하는 데 필요하고 충분합니까?

각 작업에 책임과 역할을 쉽게 할당하고 해당 부서, 프로젝트 팀 또는 개인에게 할당할 수 있습니까? 각 활동에 필요한 리소스를 쉽게 결정할 수 있습니까?

각 작업의 기간이나 비용을 쉽게 추정할 수 있습니까?

각 작업을 완료하기 위한 조치가 명확하게 이해되어 있습니까?

WBS가 제 역할을 하기 위해서는 어떤 것도 빼놓을 수 없습니다.

이 일정을 관리하려면 크고 작은 모든 작업의 ​​전체 목록이 필요합니다.

WBS는 상세해야 하지만 너무 자세해서 혼란스러울 수는 없습니다.

번호 매기기와 관련하여 레벨은 일반적으로 1, 1.1, 1.1.1 등과 같이 숫자 레벨이 점차 낮아지는 방식으로 구분됩니다.

숫자 뒤의 이름은 명사만 올 수 있고 동사는 올 수 없습니다.

WBS는 결과물과 최종 결과물로 이어질 작업에 더 중점을 둡니다. 따라서 여기서는 "어떻게"보다 "무엇"에 관한 것이 더 중요합니다. 동사는 작업을 설명하는 데 적합하고 설명에 사용해야 하지만 명확성을 위해 WBS의 각 단계에는 명사를 사용해야 합니다.

결과물

프로젝트 단계

하위 프로젝트

지리적 위치

부서

기능

구현 프로세스

작업산물(WorkingProduct)은 프로젝트가 생산해야 하는 작업 결과이며, 프로젝트의 최종 결과물의 구성요소일 수도 있고, 프로젝트 중간 프로세스의 출력 결과일 수도 있습니다.

작업 산출물은 크거나 작을 수 있으며, 일부는 상호 연관되거나 종속될 수 있습니다.

작업 산출물 목록을 작성하는 과정은 프로젝트 팀이 완료하는 브레인스토밍 방법일 수 있습니다.

크고 작은 많은 작업 제품이 나열되어 있습니다. 대규모 프로젝트에는 수백 또는 수천 개의 항목이 있습니다.

이러한 작업 산출물의 속성과 관계는 하향식, 단계별 작업 산출물 분석 구조(PBS: ProductBreakdownStructure)를 형성하는 구조화된 방식으로 구성됩니다.

이는 제조 업계에서 제품이 몇 개의 부품으로 구성되어 있는지를 보여주는 제품 BOM(Bill of Materials)입니다.

PBS를 사용하면 작업 산출물을 얻는 작업이 명확하게 정의되어 있는 한 PBS의 구조에 따라 WBS를 얻을 수 있습니다.

참고: 동일한 작업 산출물을 얻기 위한 작업이 다를 수 있으므로 동일한 PBS를 다른 WBS와 함께 사용할 수 있습니다.

WBS의 작업이 결정되면 작업 완료를 담당하는 사람도 명확해질 수 있습니다.

따라서 WBS는 전체 프로젝트의 조직적 세분화 구조를 형성할 수 있으며, 해당 사람들은 프로젝트 작업을 완료하고 작업 산출물을 획득하여 프로젝트를 완료하게 됩니다.

유사한 작업의 WBS를 기반으로 이 작업의 작업분류체계를 지정합니다.

즉, 프로젝트의 가장 큰 단위부터 시작하여 점차적으로 다음 단계의 여러 하위 항목으로 분해합니다. 이 프로세스는 지속적으로 레벨을 늘리고 업무를 세분화하는 것입니다. 이 접근 방식은 프로젝트 관리자가 프로젝트에 대한 광범위한 기술 지식과 전체적인 관점을 갖고 있기 때문에 틀림없이 최선의 접근 방식입니다.

다양한 사고

기능 포인트를 분류하여 상위 기능 패키지 구성

단계별로 위쪽으로 수렴

트리 구조 다이어그램의 WBS는 명확한 수준을 가지며 매우 직관적입니다. 매우 구조적이지만 수정이 쉽지 않습니다. 크고 복잡한 프로젝트의 경우 주관성으로 인해 프로젝트의 전체적인 관점을 표현하기가 어렵고 일반적으로 소규모 및 중간 규모의 프로젝트에서 더 일반적입니다.

실제 응용 프로그램에서는 작업 목록 스타일의 WBS 응용 프로그램이 상대적으로 일반적이며, 특히 프로젝트 관리 소프트웨어에서는 더욱 그렇습니다.

1. 시설의 구조적 분해를 통한 관리

2. 결과에 초점을 맞추십시오. 방법이 아니라 무엇을 달성했는지;

삼. 업무분할구조를 통해 기술과 사람, 시스템과 조직 사이에서 결과의 균형을 이룰 수 있습니다.

4． 프로젝트에 관련된 모든 부서 간의 역할, 책임 및 업무 관계를 정의하여 계약을 체결합니다.

5. 간결한 보고 구조를 채택하세요.

작업 분할 구조를 사용하면 효과적인 프로젝트 관리의 5가지 원칙 중 처음 3가지를 충족하는 동시에 한 가지 세부 수준에서만 작업을 정의하는 계획의 함정을 피할 수 있습니다. 구조화된 방식으로 작업을 정의하면 더 나은 결과를 얻을 수 있습니다. 결과물을 통해 작업이 정의되면 프로젝트가 진행됨에 따라 생산 시설에 필요한 작업만 수행되므로 일정이 더욱 고정됩니다. 환경이 계속 변하면서 프로젝트에 필요한 작업도 변할 수 있지만, 어떻게 변하더라도 최종 결과에 유익해야 합니다.

WBS의 목적은 제품을 생산하고 책임을 할당하는 동시에 각 제품이나 서비스에 별도의 부서를 제공하는 것이므로 WBS의 작업 패키지는 자연스럽습니다.

작업이 세부적인 수준에서만 정의되어 하나의 작업 패키지로 뭉쳐지면 작업 패키지가 자연스럽지 않고, 프로젝트 관리자는 사람들에게 작업을 독립적으로 완료하게 하는 대신 매일 몇 가지 기술과 방법을 알려주느라 바쁠 수 있습니다. .

낮은 수준에서 제어한다는 것은 작업을 완료하는 데 걸리는 것보다 제어하는 ​​데 더 많은 시간을 소비한다는 것을 의미할 수 있으며, 더 높은 수준에서 제어한다는 것은 중요한 상황이 우리가 보지 않을 때 빠져나가는 것을 의미합니다.

일반적으로 통제 활동 기간은 통제 회의 빈도와 일치해야 합니다.

실제로 WBS의 분해 수준은 반드시 고정되어 있지는 않습니다. 위험 수준에 따라 가장 낮은 수준의 WBS가 결정될 수 있습니다.

위험도가 낮은 프로젝트에서는 작업 분해의 가장 낮은 수준이 작업 패키지일 수 있습니다.

위험도가 높은 프로젝트에서는 프로젝트의 가장 낮은 수준 중 하나로 계속 진행할 수 있습니다.

완전한 WBS 준비는 엔지니어링 프로젝트의 전반적인 목표를 결정하고 각 개별 작업(부분)과 전체 프로젝트(전체) 간의 관계를 결정합니다.

이러한 대형 프로젝트는 막대한 비용이 소요되고 수년에 걸쳐 지속되기 때문에 프로젝트 초기에 구상했던 프로젝트 환경은 프로젝트가 진행됨에 따라 크게 변화하게 됩니다. 이는 우리가 여러 번 언급한 프로젝트 초기 단계의 불확실성입니다. [pp1]. 이를 위해서는 모든 관련 그룹이 공통 정보 기반, 즉 모든 관련 그룹 또는 사용자가 프로젝트의 시작부터 최종 완료까지 정보를 전달하는 데 사용할 수 있는 도구를 보유해야 합니다.

예산, 일정을 준비하고 프로젝트의 다른 측면을 설명하기 위한 기초로 작업분류체계를 사용하면 프로젝트와 관련된 모든 사람이나 그룹이 프로젝트를 완료하는 데 필요한 작업과 프로젝트 진행 상황을 이해할 수 있습니다.

일반적인 프로젝트 제어 시스템에는 일정, 비용, 회계 등과 같은 다양한 하위 시스템이 포함됩니다.

하위 시스템은 어느 정도 서로 독립적이지만, 프로젝트 관리의 목적을 실제로 달성하려면 하위 시스템 간의 시스템 정보 전송이 반드시 필요합니다.

WBS 코드를 적용하면 시스템에 입력되는 모든 정보가 통일된 정의 방법을 통해 생성될 수 있으므로 수집된 모든 데이터를 동일한 기준과 비교할 수 있으며 프로젝트 엔지니어, 회계사 및 기타 프로젝트 관리자가 동일한 정보와 동일한 의미가 있으며 프로젝트 제어에 대한 의미가 분명합니다.

WBS를 기반으로 다양한 하위 시스템 간의 연결이 더 일반적일수록 분석에서 시스템 차이를 줄이거나 제거할 수 있으므로 프로젝트 제어에 더 유리합니다.