WBS를 처음 만들 때 가장 많이 하는 실수

SI 프로젝트를 시작하면 가장 먼저 만드는 문서 중 하나가 WBS입니다

 

전체 프로젝트를 업무 단위로 나누고 각 업무의 일정과 순서를 정리하는 구조입니다

 

하지만 많은 프로젝트에서 WBS는 처음에는 잘 만들어진 것처럼 보이지만 프로젝트가 진행될수록 점점 현실과 멀어지는 경우가 많습니다

 

그 이유는 WBS를 만들 때 자주 반복되는 실수들이 있기 때문입니다

 

 

 

 

1. 업무 단위가 너무 큼

가장 흔한 문제는 업무 단위가 지나치게 큰 경우입니다

 

예를 들어 개발, 테스트, 배포 이렇게만 작성된 WBS는 실제 일정 관리에 거의 도움이 되지 않습니다

 

업무가 너무 크게 묶여 있으면 어디에서 일정이 밀리는지 파악하기 어렵습니다

 

WBS는 업무 단위가 관리 가능한 수준까지 나뉘어야 합니다

 

 

 

2. 실제 작업 흐름이 반영되지 않음

WBS는 단순한 일정표가 아닙니다

 

업무가 어떤 순서로 진행되는지 의존 관계까지 고려해야 합니다

 

예를 들어 화면 설계, API 개발, 화면 개발 이 순서를 무시하고 일정만 배치하면 프로젝트 중간에 일정이 계속 수정됩니다

 

WBS는 실제 개발 흐름을 기반으로 만들어야 합니다

 

 

3. 일정만 있고 책임자가 없음

WBS에는 보통 일정만 작성되는 경우가 많습니다

 

하지만 업무에는 반드시 책임자가 필요합니다

 

담당자가 없는 일정은 결국 아무도 관리하지 않는 일정이 됩니다

 

그래서 WBS에는 업무, 일정, 담당자. 이 세 가지가 함께 있어야 합니다

 

 

4. 엑셀로 관리하면서 계속 깨짐

많은 SI 프로젝트에서 WBS를 엑셀로 관리합니다

 

처음에는 문제가 없어 보이지만 일정 변경, 업무 추가, 담당자 변경 이런 수정이 반복되면 WBS 구조가 점점 복잡해집니다

 

버전 관리도 어렵고 누가 언제 수정했는지도 확인하기 어렵습니다

 

결국 WBS는 점점 신뢰도가 떨어지는 문서가 됩니다

 

 

 

5. WBS는 문서가 아니라 관리 구조입니다

WBS의 목적은 단순히 일정표를 만드는 것이 아닙니다

 

프로젝트 전체 구조를 관리 가능한 형태로 만드는 것입니다

 

그래서 WBS는 단순 문서보다 관리 시스템 안에서 운영되는 것이 더 효과적입니다

 

 

 

6. 프로젝트 관리 도구의 필요성

봄즈의 봄보라는 프로젝트 생성 시 칸반, 스크럼, WBS, 버퍼 중 하나의 관리 방식을 선택해 사용할 수 있습니다

 

SI 프로젝트에서는 WBS를 기반으로 업무 구조, 일정 관리, 진행 상태를 한눈에 관리할 수 있습니다

 

프로젝트 관리에서 중요한 것은 문서를 만드는 것이 아니라 관리 구조를 만드는 것입니다

 

 

 

7. 마무리

WBS는 프로젝트 일정 관리의 기본이지만 업무 단위, 작업 흐름, 담당자 구조. 이 세 가지가 제대로 설계되지 않으면 프로젝트가 진행될수록 의미가 약해집니다

 

프로젝트 초기에 WBS 구조를 제대로 만드는 것이 일정 안정의 시작입니다

 

 

#봄즈 #봄보라 #WBS #SI프로젝트 #프로젝트관리 #IT프로젝트