[펌] WBS (Work Breakdown Sheet)

[펌] WBS (Work Breakdown Sheet)

작업분류체계(WBS)

범위와 요건은 종합적인 WBS를 만드는 작업을 지원하고 명확성을 더하는 데 기초가 되는 주춧돌이 됩니다. 이 WBS는 마찬가지로 프로젝트 관리에 필요한 기본 문서입니다. PMI?榮? WBS를 “프로젝트 요소인 산출물 중심의 분류 체계로 프로젝트의 전체 범위를 구성하고 정하는 것”이라고 정의합니다. WBS는 태스크 위주의 활동 가계도(Family Tree)로 묘사되기도 합니다. WBS의 용어로도 알 수 있듯이 WBS는 전체 업무를 분류하여 구성 요소로 만든 후 각 요소를 평가하고 일정별로 계획하며 그것을 완수할 수 있는 사람에게 할당해 주는 역할을 합니다. WBS는 현대적인 프로젝트 관리의 주춧돌이 됩니다.

WBS와 연관된 개념 중 가장 어려운 것은 그것을 개발하는 데 쓰이는 원칙에 제한이 있다는 것입니다. 서로 다른 조직은 WBS를 작성하는 데 다른 프로토콜(Protocols)을 사용합니다. 또한 WBS가 담고 있어야 할 내용에 대한 이해도 마찬가지로 서로 다릅니다. 이제 WBS의 형식과 작성 방법, 쓰임을 통해서 그 특성을 알아보겠습니다.


WBS 의 사용

프로젝트에서 WBS는 많은 용도로 사용됩니다. WBS는

- 일정계획과 산정,
- 정보 추적,
- 팀 의사소통,
- 보고

등에 있어서 많은 기능을 제공합니다.

WBS는 프로젝트 매니저의 중요한 전략적인 도구의 하나로 사용됩니다.
WBS가 제대로 활용되려면 프로젝트 매니저가 WBS의 특성과 쓰임새를 잘 파악하고 있어야 합니다.
WBS의 상위 레벨들은(제품, 단계, 핵심 구성요소, 요약 레벨) 프로젝트의 상위 관리 요소들이 무엇인지 보여줍니다.
WBS는 상위 레벨의 원가를 파악할 수 있도록 하며 프로젝트가 어떤 방식으로 진행되어야 할 지에 대한 넓은 안목을 갖게 해 줍니다.

WBS의 하위 레벨은 프로젝트 원가를 추적할 수 있도록 정보를 제공해 주며, 매일 일어나는 활동을 파악할 수 있도록 해줍니다. 팀원들은 자신에게 할당된 태스크를 쉽게 식별하고, 프로젝트 매니저들은 작업 패키지를 체크 리스트로 사용해 어떤 작업이 완성되었고 어떤 작업이 남아 있는지를 알아볼 수 있습니다.
WBS는 작업 패키지 레벨에서 가장 많이 활용됩니다. 이때 각 태스크별로 원가를 할당할 수 있으며 프로젝트와 관련된 모든 작업에 할당된 원가를 파악할 수 있습니다. 이것은 결국 팀의 원가 계산을 쉽게 합니다. 일정 계획의 측면에서 작업 패키지 레벨에 포함된 항목들은 네트워크도의 기본 단위로 활용됩니다. 결국 프로젝트 매니저는 작업 패키지들 간의 논리적 선후관계를 정립하고 각 태스크가 전체적인 일정에 어떤 영향을 미치는지 파악할 수 있게 됩니다.

레벨에 상관없이 WBS는 프로젝트 매니저에게 중요한 의사소통 링크를 제공합니다. 프로젝트 관리의 가장 중요한 요소로서 WBS는 프로젝트를 검토하고 평가할 수 있는 기본 체계를 제공합니다. WBS는 프로젝트 문서의 하나로 팀원들에게 지나친 세부사항을 배제한 채 프로젝트 전체를 볼 수 있는 안목도 제공해줍니다. WBS는 태스크별로 기록되어있기 때문에 프로젝트나 특정 활동에서 자신의 역할을 좀더 명확히 이해하고자 하는 팀원들에게 좋은 의사소통 도구로서 작용합니다.


WBS 작성 방법

WBS를 작성하는 방법은 프로젝트 매니저들마다 다릅니다. 이들이 선호하는 방법과 성향도 서로 차이가 납니다. 여기에서는 WBS를 작성하는 데 기초가 될 4가지 방법을 함께 알아보고자 합니다.
대부분의 프로젝트 매니저에게 하향식 접근 방법이 가장 기본적인 WBS 작성 방식일 것입니다. 먼저 프로젝트의 가장 큰 작업 요소를 선별하고 그에 해당하는 하부 작업으로 분류해 나가면서 매니저들은 점차 더 자세한 세부 항목으로 작업을 나누게 됩니다. 제품 위주의 WBS에서 하향식 접근 방법은 산출물로 시작합니다. 이 산출물은 계속적으로 더 작은 시스템과 서브시스템으로 구분됩니다. 각 서브시스템이 관리 가능한 레벨로 분류되면 필요한 일이 각 작업 패키지에 따라 구분됩니다. 이 작업 패키지는(목적어-동사 형식으로 표현) 그 서브시스템의 산출물을 만들어내기 위해 팀원들이 완성해야 할 태스크를 정의합니다.

태스크 위주의 WBS에서 작업은 선형적인 형태로 분류됩니다. 한 단계는 그에 속하는 하위 단계로 구분되는데 가장 하위 레벨은 특정한 태스크를 수행하기 위해 팀원들에게 할당되는 작업 패키지가 됩니다. 실질적으로 모든 작업은 작업 패키지 레벨에서 할당됩니다. 때로 일부 소프트웨어 패키지에서 전체 단계 혹은 전체 시스템에 걸쳐 작업하는 사람들을 위해 상위 레벨에서 작업을 분담하려는 시도가 있기도 했습니다. 하지만 이러한 시도는 현명한 것이 아닙니다. 상위 레벨에서 작업을 할당하게 되면 자칫 구체적인 작업이나 개인별 태스크 책임을 명확히 구분할 수 없게 될 수 있습니다.
하향식 WBS 작성 방식에는 나름대로 한계가 있습니다. 이것을 제대로 작성하기 위해서는 광범위한 기술적 통찰력과 완성될 전체 업무에 대한 총괄적인 안목이 필요합니다. 또한 프로젝트 매니저는 모든 필요한 작업을 정의 내릴 수 있어야 하고 불확실한 정보로 인한 그 어떤 빈틈도 없을 것이라고 가정 합니다. 그러나 이러한 가정은 경험이 부족한 프로젝트 매니저나 자신에게 친숙하지 못한 프로젝트를 진행하는 프로젝트 매니저들에게는 매우 위험한 것이 될 수 있습니다. 자신의 직접적인 전문 분야가 아닌 프로젝트를 관리하는 매니저들도 마찬가지입니다.

위와 같은 경우에서는 유사 WBS 방식이 더 효율적입니다. 이 WBS는 그 어떤 프로젝트도 완전히 새로운 접근 방식을 취하지 않는다는 가정을 취합니다. 유사성을 이용해 프로젝트 매니저는 기본적으로 자신의 프로젝트와 비슷한 프로젝트WBS를 찾아 내어 현 프로젝트의 요구에 부합하도록 수정하는 작업을 합니다. 이 방법의 장점은 작성하는 방법이 쉽고 빠르다는 것입니다. 하지만 부적절한 가정을 포함하거나 성공적이지 못했던 WBS를 기반으로 만들어질 수도 있다는 단점도 있습니다.
템플릿 방식도 이와 유사합니다. 템플릿은 특정한 분야의 범주에 포함된 프로젝트들을 위해 작성됩니다. 많은 현대 프로젝트 관리 소프트웨어 회사들은 신중하게 개발된 템플릿을 제공해 프로젝트 관리에 “빈칸 채우기” 방식을 적용합니다. 이러한 템플릿은 해당 전문 분야에 속하는 대부분의 활동과 구조를 미리 제시해 주고 현 프로젝트의 특성에 맞는 세부 사항만을 채워 넣도록 제작되어 있습니다. 템플릿 방식의 장단점은 유사성을 이용한 방식과 비슷합니다. 그러나 템플릿은 조직적으로 실험되고 인정되었다는 장점이 더 있습니다.

전적으로 새로운 시스템이나 접근 방식을 필요로 하는 프로젝트라면 상향식 접근 방식을 고려해 볼 수 있습니다. 상향식 접근 방법이란 팀원들이 가능한 모든 구체적인 태스크들을 식별하는 것을 말합니다. 이 태스크들은 다시 종합적으로 정리되어 팀에게 주어집니다. 각 태스크에는 다음과 같은 질문이 주어져야 합니다.

- 입력물은 무엇인가?
- 누가 입력물을 제공할 것인가?
- 산출물은 무엇인가?
- 누가 산출물을 얻게 될 것인가?

많은 경우 이 질문들을 통해 예전에 고려되지 않았던 태스크들을 보충적으로 추가하게 될 것입니다. 모든 태스크 목록이 만들어지면 이것은 상위 요약활동으로 배치되고 정리될 것입니다.


WBS형식

WBS는 다양한 형식으로 표현될 수 있습니다. 이것은

- 개요
- 간트 차트
- 단순한 활동 리스트

등으로 소프트웨어 패키지에 구현될 수 있습니다. 어떤 프로젝트 관리 소프트웨어 도구는 특유의 차트나 가계도 형식으로 표현하기도 합니다.

WBS의 내용이나 형식은 그것이 태스크 위주의 WBS인지, 제품 위주의 WBS인지에 따라 달라집니다.
태스크 위주의 WBS는 직선적인 형태를 취합니다. 여기에서 활동은 그 시작 순서에 따라 나열됩니다. 그러나
제품 위주의 WBS는 주요 시스템 산출물에 따라 배열되기 때문에 태스크 위주의 WBS와 같이 동일한 일정 방향이나 일정과의 상호 관계를 가지지 않습니다.

WBS는 종종 개요(Outline) 형식으로 배열됩니다. 이때 여러 층으로 나열된 목록은 작업이 여러 단계로 분류 되었음을 보여 줍니다. 아래의 예에서 가장 상위 레벨인 (1)은 프로젝트 레벨(요약 레벨)이 되며, 그 아래의 모든 일정 및 원가 정보는 하위 개별 수준으로 표현됩니다.
그 다음 레벨인 (1.1)은 WBS의 형식에 따라 좌우됩니다. 제품 위주의 WBS 에서 이 레벨은 주요 시스템 산출물을 나타냅니다. 그러나 이 예와 같이 태스크 위주의 구조에서는 프로젝트의 각 단계(앞으로 우리는 이 부분을 자세히 알아볼 것입니다)를 표시합니다.
단순한 WBS에서의 그 다음은 활동 레벨(혹은 작업 패키지 레벨)을 나타냅니다. 그러나 좀 더 복잡한 구조의 WBS라면 그 밑에 속한 모든 하위 작업을 포함하는 레벨이 구성 될 것입니다. 또한 제품 위주의 WBS에서는 중요 시스템 구성 요소 혹은 중요 서브시스템을 나타낼 것입니다. 이론적으로는 각각의 요약태스크 밑에는 무수한 개별 작업 패키지가 배정될 수 있습니다.

작업 패키지 레벨의 상위 항목은 성과관리 레벨을 나타냅니다.
이것은 어떤 기능 부서가 하위 작업 패키지와 관련된 성과를 관리할 지 를 보여줍니다. (제시된 표에서 성과관리는 1.1과 1.2에서 이루어질 것입니다.) 물론 간단한 WBS라면 굳이 몇 가지 레벨을 하나로 묶어 표시할 필요는 없을 것입니다. 그러나 좀 더 복잡한 분류 체계에서는 특정한 성과관리 레벨이나 기능 조직에 포함된 작업들을 찾고 하나로 묶는 것이 훨씬 편리할 것입니다.
그림에서 보여주는 것과 같이 WBS의 가장 하위 레벨은 작업 패키지입니다. PMI?榮? 예전부터 작업 패키지가 대략 80시간의 작업을 포함해한다는 원칙을 세웠습니다. 하지만 이와 같은 산정은 조직마다 다를 것입니다. 대기업의 경우 프로젝트 매니저들은 몇 달의 작업 수준 이하로 WBS를 계획할 수 없을 것입니다. 왜냐하면 수십억 달러짜리 프로젝트에서는 그와 같은 분류 자체가 비현실적이기 때문입니다. 그러나 더 작은 프로젝트를 관리하는 중소 기업의 경우 80 시간의 작업 패키지가 너무 커서 일부의 작업을 구분하지 못한 채 간과 될 수 있다고 여길 것입니다. PMI?瑛? 정의는 일반적인 지침일 뿐이지 불변의 원칙은 아니라는 것을 명심하십시오.

적절히 작성되어 시행되는 WBS는 프로젝트 관리에 있어서 일반적으로 작업정의를 제공합니다. WBS는 전체 작업을 개별적인 패키지들로 분류해 팀원들이 쉽게 이해할 수 있도록 되어 있습니다. 또한 제시된 작업을 달성하기 위해 요구되는 통찰력을 제공해줍니다. 프로젝트 생애 주기를 따라 작업을 정의하고 분류하면서 프로젝트 매니저들이 좀 더 쉽고 정확하게 프로젝트를 관리할 수 있도록 도와주는 역할도 합니다.


WBS

-----------------------------------------------------

# WBS (Work Breakdown Structures)란?

여기서는 프로젝트 관리의 측면이 아니라 각 멤버가 프로젝트에 있어서 자신의 작업목표를 관리하는 데에 WBS를 어떻게 활용할 것인가를 생각해 보기로 한다. WBS는 한마디로 말하면 프로젝트 목적달성에 필요한 작업을 정의하기 위한 툴이라 할 수 있고, 다음의 4스텝을 거쳐서 작성한다.

1. 프로젝트의 목적을 정한다.
2. 프로젝트에서 작성할 프로덕트, 서비스, 결과 등의 성과물을 구체적으로 정한다.
3. 요소 성과물이나 중간 성과물, 전체 성과물에 공통적인 작업항목을 빠짐없이 정한다.
4. 2와 3의 항목을 분해해서 계획 및 컨트롤에 적절한 볼륨이 될 때까지 계속 분해한다.
4의 결과 분해된 최후의 항목을 워크패키지라고 부른다.

여기서 포인트는 WBS의 각 요소는 명사와 수식어로 표현한다는 것이다.
워크패키지까지 분해하고 나면 그 다음에는 워크패키지를 액티비티라고 하는 작업레벨로 분해한다. 액티비티는 [~을 수행한다]란 표현이 되도록 한다. 작성한 WBS는 요원조달, 예산작성, 스코프 설명 등 프로젝트의 여러 방면에 사용되며, 멤버의 역할과 책임은 워크패키지 또는 액티비티 단위로 주어진다. 이처럼 WBS는 프로젝트의 전체상을 나타내는 지도의 역할을 한다.


# WBS (Work Breakdown Structures)의 작성 방법

프로젝트 전체의 WBS는 프로젝트 관리팀에서 작성하며 각 멤버가 직접 관여하는 일은 많지 않다.
그리고, 작성된 WBS에 의해 멤버에게 역할과 책임이 주어지면 작업을 실행하게 된다. 즉, 개개의 멤버는 워크패키지 또는 액티비티로 구체화 되어진 후에 비로서 WBS와 관계를 갖게 된다. 그리하여 워크패키지나 액티비티의 수행에 책임을 지니게 되는 것이다.

통상적으로 WBS에서는 다음과 같은 요소 성과물을 고려해서 분해/구체화한다.

1. 프로덕트를 분해
2. 서비스를 분해
3. 프로젝트 결과를 분해
4. 프로젝트 전체의 횡단적 요소
5. 프로젝트 매니지먼트 요소

그러나, 멤버에게 있어서는 분해/구체화의 기준이나 그 레벨보다는 구체화된 WBS항목(워크패키지)의 구체적인 내용이 더욱 중요하다. 이 내용을 WBS사전이라 부른다.
즉, 프로젝트 전체의 WBS를 작성하는 것 그 자체보다는 담당부분의 WBS와 전체와의 정합성을 맞추어서 작성하는 것이 멤버력향상을 위해서는 보다 더 중요하다는 것이다.


# WBS 사전에 쓸 항목

WBS사전에 어떤 항목이 필요한지는 프로젝트의 종류나 성격에 따라 다르긴 하나 최소한 다음의 항목은 필요하다.

1. WBS 항목 번호
2. WBS 항목 명칭
3. WBS 항목의 내용
4. 필요한 액티비티 (작업내용)
5. 작업에 필요한 성과물
6. 견적 공수
7. 개시 예정일과 완료 예정일
8. 담당자명
9. 예상되는 리스크

그리고, 프로젝트에 있어서 멤버가 책임을 갖는다는 것은 담당하는 WBS 항목에 대하여 요구되어지는 성과를 주어진 시간내에 달성한다는 것이다. 즉, 담당 작업에 대하여 커밋한다는 것을 의미한다. 이를 위해서도 담당할 작업의 WBS 부분을 작성하는 것은 커밋이 보다 원할하게 이루어질 수 있으며, 이것은 담당부분의 WBS 작성에 멤버가 참여함으로써 얻을 수 있는 잇점이라 할 수 있을 것이다