프로젝트메니지먼트로 계획을 세울 때에 이용되는 수법의 하나로, 프로젝트 전체를 작은 작업 단위로 분할한 구성도이다. [작업분할구성], [작업분해도] 라고 불려진다.
WBS에서는 우선 프로젝트의 성과물을 가능한 한 작은 단위로 분해한다. 그 때, 전체를 큰 단위로 분할하고 난 후, 각각의 부분에 대해 좀 더 작은 단위로 분해하여, 계층적으로 구성화 해 나간다.
성과물의 세분화가 끝나면, 각각의 부분을 구성하는데 필요한 작업(한가지 이상의 작업일 때도 있음)을 생각하여, 최하층에 배치해 간다. 각각의 부분을 구성하는 일련의 작업 단위를 [워크 패키지]라고 한다. WBS의 각각의 워크패키지에 담당인원을 배치하면 프로젝트를 수행하는 조직도가 생성된다. 이것을 OBS(Organization Breakdown Structure)라 한다.
Work Breakdown Structure(이하 WBS)는 프로젝트가 수행해야 하는 업무범위를 계층적 구조로 정의한 문서이다. WBS가 정의되어야 원가, 일정 등 다른 요소들도 정의할 수 있다. PM이 책임을 지고 만들어야 하지만 프로젝트 규모가 큰 경우 모든 업무범위를 PM 혼자서 계획하기란 쉽지 않은 일이다. 이 경우 프로젝트가 완성해야 하는 제품을 시스템과 같은 주요한 단위로 분할하여 각 시스템을 담당하는 PL들에 의해 작성하게 하면 좀 더 효과적으로 WBS를 정의할 수 있다.
PMBOK은 WBS를 산출물 중심의 그룹핑(Deliverable-oriented grouping)으로 정의하고 있다.
산출물 중심의 그룹핑이란 것은 프로젝트에서 고객에게 전달해야 하는 제품이나 서비스를 산출물 단위로 분할 하여 계층적 구조로 정의하라는 것이다. 프로젝트에서 고객에게 전달해야 하는 모든 산출물이 WBS에 포함되어 있으므로 WBS 에 명시되지 않는 산출물은 계약범위를 벗어난 것이 된다. 프로젝트 수행 도중 고객이 추가적인 기능이나 업무를 요청하는 Scope Creep 의 경우 WBS를 확인하여 요청사항이 계약범위 내에 있는지 판단할 수 있다.
프로젝트의 모든 업무범위가 WBS에 포함되기 위해서는 프로젝트에서 수행하는 모든 작업들이 WBS에 나타나야 한다. 많은 프로젝트에서 형상관리, 프로젝트 관리, 사업관리 등 개발과 직접적으로 연관이 없는 작업들을 WBS에 정의하지 않는 경우를 볼 수 있다.
위의 소프트웨어 개발 프로젝트의 WBS를 보면 개발 프로세스 외에 Project Management 라는 카테고리가 따로 존재함을 볼 수 있다. WBS 작성 당시 이러한 관리업무를 고려하지 않는다면 실제로는 수행해야 함에도 불구하고 WBS에는 나타나지 않아 계획 보다 일정이 늦어지고 비용이 늘어나게 된다.
거창한 일이라도 우선 시작해보라.
손이 일에 착수했다는 것만으로도 일의 반은 이룬 셈이다.
그러나 아직 반이 남아있다.
한 번 더 착수해 보라.
그러면 일은 모두 마무리되는 셈이다.
- 마르쿠스 아우렐리우스
작심삼일(作心三日)만 반복하게 되니,
새로운 일을 계획하는 것이 두렵다고 말하는 사람이 있습니다.
그러나 매 3일마다 작심하겠다는 사람도 있습니다.
누구나 아는 ‘시작이 반이다’는 격언을
‘두 번만 시작하면 일이 모두 마무리된다’고 해석한 현인의 지혜가 돋보입니다.
큼지막한 과실은 아이디어를 가진 사람이 아닌, 실행하는 사람의 몫입니다.
친한 사이일수록
예의가 중요하고, 사람을 사귈 때도
적절한 거리를 유지하는 것에 신경을 써야 한다.
누구나 다른 사람이 침범하지 않았으면 하는
개인적인 영역이 있기 때문이다. 아무리
가까운 사이라고 해도 '선을 넘으면'
관계가 오래 지속되지 못한다.
익숙해질수록 상대방을
새롭게 바라보고
배려해야 한다.
- 사이토 시게타의《유쾌한 카리스마》중에서 -
* 친해지면 자칫 소홀해지기 쉽습니다.
가까워질수록, 익숙해질수록 더 조심해야 합니다.
그래야 그 가까운 사이가 깊어지고 오래갑니다.
그러기 위해서는 늘 새로운 다짐이 필요합니다.
'오늘도 처음 마음으로 사랑하고 존경하자!'
여기에 한 가지 더하여 다짐하십시오.
'더 잘 살피고 조심하자!'
