[지디넷코리아]일반적으로 ‘생산된다’라고 표현되는 제품은 반복적인 생산이 가능하다. 반면 소프트웨어의 생산 과정은 그 복제의 용이성과는 반대되는 비반복적인 업무들로 구성된다. 어제 그린 데이터베이스 설계도를 그대로 다시 그린다면 쓸데없는 일을 한번 더 했을 뿐이지 두 개의 설계도를 생산한 것은 아니다. 이렇게 주로 일회성 작업들의 연관을 통해 생산되는 대표적인 생산물이 건축물과 소프트웨어이다. 소프트웨어 개발 프로젝트를 진행해 오면서 발생한 많은 문제점들을 극복하기 위해 그만큼 노력이 있었고 다양한 영역의 관리기법이 여기에 수용됐다.
대표적으로 위험관리 부분은 금융분야의 위험관리에서 많은 아이디어들을 차용하고 있고 일정관리 중심의 프로젝트 관리는 건설분야에서 사용돼 오고 있는 기법들을 많이 수용하고 있다. 분명히 프로젝트의 성공을 위한 구성원들의 끊임없는 노력이 없는 성공은 단지 요행일 뿐이라는 사실은 변함이 없지만 프로젝트 관리활동을 더 꼼꼼히 살펴보고 미처 인지하지 못한 정보를 전달해 주고 좀 더 편리하게 분석하고 예측할 수 있게 하는 도구는 분명히 존재한다. ‘주어진 시간 안에’라는 프로젝트의 제약을 관리하기 위한 일정관리 소프트웨어가 그 중 하나가 될 것이다.
알고 있는 만큼 관리된다
일정관리 프로그램들을 포함한 많은 프로젝트 관리 프로그램이 제공하는 혜택을 프로젝트에 수용하려면 사전에 많이 공부해야 한다. 흔히 이런 프로그램들을 접할 때 발생하는 오해가 프로그램을 프로젝트에 적용하는 것만으로 해당 프로그램의 광고 전단에 소개된 성공이 보장될 것이라는 것이다. 이런 오해는 프로그램에 대한 불신으로 이어지기도 한다.
원고지, 연필, 지우개를 대신하는 워드프로세스의 편리함은 분명 존재한다. 하지만 사용하고 있다는 사실만으로 시인을 만들어 주는 도구는 이 세상에 존재하지 않는다. 일정관리 프로그램도 이런 사정은 달라지지 않는다. 도구가 제공하는 기능이 무엇에 쓰는 것인지 명확히 알지 못하면 관리 또한 명확히 이뤄지지 않을 것이다. 이런 의미에서 일정관리에 필요한 여러 방법, 기법, 개념 등을 간략하게 살펴보는 것이 도움이 될 것이다.
프로젝트 관리의 뿌리 WBS
개인용 일정관리 프로그램에 비해 프로젝트 일정관리 프로그램은 다소 복잡한 개념들과 활동을 필요로 한다. 더 전문적인 지식까지 수용한 프로그램도 있으나 대부분의 프로그램이 공통으로 지원하는 기능의 뿌리를 이루고 있는 개념들은 WBS(Work Breakdown Structure), PERT(Program Evaluation and Review Technique), CPM(Critical Path Method), 간트 차트(Gantt Chart) 정도이다. 처음 접하는 용어라면 낯설 수 있으나 알고 나면 상식적인 개념들로 프로젝트 진행을 위해 이러한 개념, 기법들을 적용해야 한다.
 |
| <화면 1> 국산리포팅툴인 OZ의 간트 차트. 차트 컴포넌트에서 간트 차트 생성 기능은 기본이 됐고 이제는 리포팅 툴에도 탑재되는 기능이다. |
먼저 WBS는 프로젝트의 목표에 다다르기 위해 필요한 활동, 업무를 관리할 수 있을 정도로 세분화하는 일정분석 업무이다. 지상에 20층 건물을 지을 때 20층을 먼저 짓고 19층, 18층을 지을 수는 없는 것과 같이 선행돼야 할 업무를 가려 일정을 분석하게 되고 그 결과가 WBS이다. 이를 해당 업무의 담당자를 할당할 수 있을 정도로 작게 나눈 WBS의 최소 단위를 워크 패키지(work package)라고 하며 워크 패키지의 도출은 일정을 설계하는 업무가 된다.
소프트웨어 개발 프로젝트 이외에도 적용 가능한 PMBOK 등에서는 범위관리, 일정관리, 비용관리, 품질관리, 커뮤니케이션관리, 인력관리, 위험관리, 조달관리와 앞서 8개 관리영역에 대한 통합관리를 포함한 9개 영역의 관리 필요성을 이야기하고 있다. WBS는 투입되는 인력을 보여주는 인력계획과 투입되는 시간을 보여주어 일정계획, 그리고 비용계획의 기초가 되는 등 타 관리영역의 계획을 수립하는 기초를 제공한다.
소프트웨어 프로젝트 관리에 특화된 관리활동들과 구분하고 운영시 기능의 중심이 되는 관리영역이 일정관리 위주인 프로그램을 소개하기 위해 다소 적절치 못한 ‘일정관리 프로그램’이라는 표현을 사용했지만 대부분의 프로젝트 일정관리 프로그램은 협업 기능, 분석ㆍ예측 기능, 자원배정 기능, 위험기록 기능, 변경관리 기능 등을 통해 앞의 관리 영역들을 일정 수준 이상 지원하고 있다.
일정관리의 기본 개념
WBS가 일정관리뿐만 아니라 프로젝트 관리계획의 기초가 되는 개념인 것처럼 PERT, CPM, 간트 차트 역시 일정관리 용도에 국한된 정보만 제공하는 것은 아니다. PERT와 CPM은 개별적이라기보다는 PERT/CPM처럼 붙여 사용되는 경우가 현재는 일반적이다(1962년 PERT/CPM이 발표됐다).
PERT/CPM은 WBS상의 작업 순서, 소요기간, 기타 제반사항을 네트워크 형태로 표시해 주요 작업 및 일정의 여유를 갖는 작업을 산출하고 중점관리 대상 작업을 명확히 했다. 전체적인 작업일정을 세분화해 공기지연의 사전예방, 공기단축 등의 효율적인 일정관리를 할 수 있게 한다.
PERT/ CPM 차트는 네트워크 다이어그램이라고도 불린다. 이해를 돕기 위한 간단한 예를 들면 3일이 소요될 A 작업에서 나오는 부품과 10일이 소요될 B 작업에서 나오는 부품이 있어야만 2일이 소요될 C 작업을 거쳐 완성된 제품이 나온다고 가정하면 전체 제품을 완성하는 데는 결국 12일이 걸린다. 이 때 3일 만에 끝나는 A 작업의 인력들을 7일 동안 B 작업에 투여할 수 있는 여유가 생기게 된다. 추가 인력을 투입하는 것이 B 작업의 기간을 줄일 수 있을 것이라 판단된다면 A 작업을 끝낸 인력들을 추가 투여해 B 작업의 기간을 줄일 수도 있다.
콜럼버스의 달걀 사례의 극치를 보여주는 것이 바로 간트 차트이다. 현재라면 시스템 분석가라고 불렸을 것 같은 이피션시 익스퍼트(Efficiency Expert)라는 직업을 가진 간트가 20세기 초 만들었다. 그 골자는 작업에 소요되는 시간을 동일한 폭으로 세로로 배열하고, 각각의 작업의 시작일과 종료일 사이의 공간을 막대그래프 형태로 표시한다는 단순한 개념을 적용한 그림일 뿐이지만 작업의 순서와 기간을 한 눈에 시각적으로 보여주는 형태를 갖추게 된다.
MS 프로젝트의 일정관리 기본 기능
몇 년 새 프로젝트 일정관리 프로그램의 대명사가 되어버린 MS 프로젝트를 통해 일정관리의 기본을 살펴보자. 먼저 MS 프로젝트가 제공하는 기능이 일정관리에 국한된 것은 아니라는 점을 먼저 이야기하고자 한다. 앞서 말한 다양한 관리영역에 대한 기능이 일정 수준 이상 제공되고 있는 프로그램이며, 명확하게 이러한 영역의 구분이 적용되지 않는 활동들이 적지 않기도 하다.
 |
| <화면 2> 오피스 홈페이지의 프로젝트 2003 정보 페이지. 소프트웨어 프로젝트뿐만 아니라 건축, 마케팅 등의 프로젝트에 대한 정보들도 제공한다. |
WBS 기록
MS 프로젝트를 사용하는 것이 일정관리를 비롯한 프로젝트의 관리를 수월하게 해줄 수는 있으나 프로젝트 소프트웨어를 사용하는 것이 성공을 보장하지는 않는다. 그 이유는 앞서 몇 차례 강조한 WBS의 중요성과도 무관하지 않다. 타 프로그램도 마찬가지인 부분으로 WBS를 만들어내는 작업은 아직까지는 프로젝트 관리자의 지식과 경험에 의존하는 부분이 크기 때문이다.
분석ㆍ설계ㆍ구현ㆍ테스트ㆍ적용하는 단순한 업무 구분은 누구나 할 수 있겠지만 담당자에게 업무를 할당하고 그 결과를 원활하게 리뷰할 수 있을 정도로 업무를 세분화해서 이 업무들의 선행-후행 관계와 기간을 예상하는 일 등은 프로그램이 자동으로 해주지 못한다. 프로젝트 일정관리의 시작은 프로그램 상에서 또는 외부에서 정리한 WBS의 내용을 프로그램에 기록하는 것이다.
이 때 상위 작업과 하위 작업을 계층적으로 입력하며 각 작업의 시작일과 종료일을 기록하면 일정계획 업무의 절반 이상이 끝난 셈이다. MS 프로젝트는 이를 기반해 자동으로 간트 차트를 생성하며, 이후 대부분의 관리 작업은 좌측에 WBS 목록을, 우측에 목록별 일정을 막대그래프 형태로 표시한 간트 차트를 보여주는 간트 차트 모드에서 수행된다.
WBS 입력은 엑셀 등에서 작업한 결과를 MS 프로젝트로 임포트하는 방법도 있다. 이후의 관리는 MS 프로젝트라는 강력한 조력자의 힘을 빌릴 수 있지만 WBS의 기록까지는 전적으로 프로젝트 관리자의 능력에 달려있음을 다시 한번 강조해 본다.
 |
| <화면 3> 프로젝트에 기록된 WBS의 모습 |
네트워크 다이어그램, 자원배정
WBS 기록이 끝난 상태라면 간트 차트는 즉시 볼 수 있다. MS 프로젝트는 또한 PERT/CPM 정보도 자동으로 생성해 준다. 보기 모드를 네트워크 다이어그램으로 변경하면 주요 경로와 여유 경로상 일반 작업과 마일스톤을 보여준다. 네트워크 다이어그램이 제공하는 정보를 고려해 관리자는 상황에 맞춰 시작일을 앞당기거나 작업기간을 늘리는 등을 고민하고 이를 다시 반영하게 된다. 이러한 변경은 다시 주요 경로의 변경을 가져올 수 있으므로 반복적으로 네트워크 다이어그램이 제공하는 정보를 살펴봐야 한다.
네트워크 다이어그램이 시간이라는 한정된 자원을 고민해야 하는 부분이라면 인력이라는 한정된 자원의 배분을 고민해야 하는 부분이 자원배정 업무이다. 건설과 관련된 프로젝트를 관리한다면 고가의 건설 장비를 투여하는 일정을 자원배정에서 관리할 수 있겠으나 대부분의 소프트웨어 개발 프로젝트의 경우 인력자원의 배정이 자원배정 업무의 주를 이루게 된다.
먼저 자원 목록을 생성하고 인력자원의 자질과 경험 등을 고려해 업무에 인력을 할당한다. 또한 프로젝트 참여 인력이 주 5일, 하루 8시간을 근무한다면 하루에 두 가지 작업을 수행한다 하더라도 두 작업에 투여되는 시간의 합이 8시간을 넘는 초과 근무가 발생하지 않도록 배정시간을 조정한다.
MS 프로젝트는 여러 시각에서 정보를 제공하고 변환이 가능하도록 구성되어 있다. 프로그램 사용자가 반드시 숙지하고 있어야 하는 부분 중 하나가 한 쪽 시각에서 정보를 변경하면 다른 시각의 정보가 자동으로 변경된다. 인력을 배정해 두고 간트 차트를 보면서 일정을 재조정하다 보면 8시간을 초과해 근무해야 하는 인력과 전혀 일을 하지 않는 일정을 가지게 되는 인력도 발생하게 된다. 일정계획 작업 중 변경이 필요한 경우라면 필요한 모든 시각에서 정보를 살펴봐야 할 것이다. 한 가지 더 일정계획에 유의할 점은 대부분의 프로젝트에서 일정계획 업무 역시 일정에 포함해야 하는 것이 원칙이 될 것이라는 점이다.
 |
| <화면 4> 좌측의 WBS와 일치되는 간트 차트를 우측에 보여주고 있다. |
일정관리의 수행
일정계획이 수립되고 본격적인 업무가 수행되면 이제는 계획한 것과 같이 업무가 진행되는가를 기록할 차례이다. 업무 진행에 따라 해당업무의 진행도를 기록하는 것이 핵심 관리업무가 될 것이다. 이 때 진행도를 기록하는 일은 관리자가 일괄적으로 평가할 수 있으나 진척 상황은 담당자가 기록하게 할 수도 있다.
계획한 일정보다 지연된 경우, 여유가 있어 앞당겨 시작한 경우 등도 추후 일정관리에 큰 영향을 미치는 정보로 반드시 기록돼야 하는 정보이다. 아무리 훌륭한 계획도 실천하지 않거나 계획대로 진행되는지 검토되지 않고, 실행 시 발생한 정보들이 관리되지 못한다면 아무리 훌륭한 일정관리 프로그램도 벽장 속에 감춰 둔 도구 이상의 의미는 없다.
기타 기능
이 외에 MS 프로젝트 서버의 경우 아웃룩과 연동해 개인과 연관된 프로젝트 진행 정보와 관련한 일정을 표시해 주는 등의 협업 기능이 있으며, MS 프로젝트 2003 버전은 셰어 포인트 포탈 서버와 MS SQL 서버를 이용해 웹 기반의 정보 공유가 가능하기도 하다.
또한 여기서는 간략하게 단일 프로젝트의 경우를 설명했으나 복수 프로젝트를 관리하는 상위의 관리자를 위한 정보, 조직 차원에서 진행해 온 프로젝트와 진행하고 있는 프로젝트에 대한 정보도 제공받을 수 있어 추후 프로젝트 계획할 때 필요한 데이터로 활용할 수 있기도 하다.
참고로 WBS를 설명하면서 누차 강조한 바와 같이 일정관리라는 업무 자체가 다른 관리 활동과 독립적인 활동으로 존재하지는 못하며 이를 지원하는 프로그램들 역시 타 관리업무를 지원하는 기능을 포함하고 있다. 여기서는 편의상 일정관리라는 영역을 별도로 설명했으니 오해가 없기를 바란다.
 |
| <화면 5> 네트워크 다이어그램의 예. 평행 사변형은 일반 작업. 육각형은 마일스톤이며 적색으로 표시된 부분이 주요 경로 이다. |
똑같은 프로젝트는 존재하지 않는다
PMBOK에서 언급하고 있는 9개 영역의 관리활동을 소프트웨어 개발 프로젝트에 적용하는 경우 9개 관리영역 외의 관리활동의 도출이 필요할 수 있으며, 특정 활동을 수행하는 것이 오히려 프로젝트에 장애가 될 수도 있다. PMP 그룹 등에서도 소프트웨어 프로젝트의 특성을 고려해 이에 대한 특화된 정보를 제공하기도 한다.
이러한 소프트웨어 개발 프로젝트의 특징은 IEEE, SEI, ISO12207, COBIT 등의 자료와 최근에 관심을 받고 있는 제약 이론(TOC) 등의 일정관리 정보들을 참조하는 것도 더 나은 일정관리에 도움이 될 것이다. 앞서 프로젝트의 일회성에 대해 설명한 바 있다. 세상에 똑같은 프로젝트는 없는 셈이다. 그런 이유로 프로젝트 관리는 알려진 활동을 수행하는 만큼 프로젝트 고유의 특성을 파악하는 것이 중요하다. @
참고자료
① MS 오피스 홈페이지(office.microsoft.com)
② Promat(http://www.promat.or.kr)
③ 소스포지(www.sf.net) : 많은 프로젝트 일정관리 프로그램이 오픈소스로 소개되고 있다.
④ “A Professional’s Guide to Systems Analysis”, Martin E. Modell, 2nd. Ed. McGraw Hill
⑤ PMBok 2000
* 이 기사는 ZDNet Korea의 자매지인 마이크로소프트웨어에 게재된 내용입니다. 
로그인 |
회원가입 (뉴스레터신청) |
SITEMAP
독자의견 남기기 (로그인 후 독자 의견을 남기실 수 있습니다.) 
