얼마 전 모 은행의 정보시스템실 사원 및 간부들과 함께 프로젝트 관리에 대한 온라인 세미나를 했다. 언제나처럼 프로젝트 매니저가 갖추어야 할 지식 및 경험에 대한 질문이 나왔고 WBS, 진도 관리 방법 등과 같은 구체적인 내용에 대해서도 질문을 받았다. 대부분의 내용들은 한 두 차례의 답변을 통하여 비교적 쉽게 수긍을 가져올 수 있는 반면, 끊임없이 문제 제기에 시달리는 내용들이 있다. 그것은 바로 변경 관리와 문서화에 대한 내용이다. 국내의 수많은 소프트웨어 개발 프로젝트에서 항상 이 두 가지는 뜨거운 감자이기 때문이다. 그리고 이 두 가지 쟁점은 서로 깊이 연계되어 있다.프로젝트를 진행하면서 수많은 변경에 부딪친다고 호소하는 사람들이 많다. 프로젝트 팀원들은 그 이유가 대개 고객의 변덕 내지는 욕심에 있다고 생각하는 듯 하다. 많은 프로젝트 경험이 있는 사람들조차도 그러한 고객의 요구를 관리하는 것이 힘들기 때문에, 변경 발생은 어쩔 수 없는 것이고 그래서 문서화도 무의미하다고 얘기하며, 더욱 극단적인 사람은 프로젝트 관리의 무용론을 주장하기도 한다. 프로젝트 관리가 이론적으로는 필요한 것이 사실이지만, 실제적으로는 효과가 없기 때문에 관리할 필요가 없다는 주장이다.이러한 주장은 조직 경영적 관점에서는 지극히 위험한 발상이다. 왜냐하면 정확한 이익/비용 측정을 위해서 조직 내 모든 활동들의 계획을 만들고 과정을 관리되고 결과를 측정하여야 하기 때문이다. 그렇기 때문에 많은 위험을 내포하고 있는 변경을 어떻게 관리하는가 하는 것이 프로젝트 관리의 중요한 요소이다. 그것은 충분히 주의를 기울려 집중해야 어떻게든 성과를 달성하여야 하는 것이지, 그것을 이유로 프로젝트 관리 자체를 부정하는 것은 바람직하지 않다. 그러한 변경 관리를 효과적으로 수행하기 위해서는 프로젝트 범위와 구체적인 활동들을 문서화하고 또한 변경 절차를 규정화하는 것이 아주 중요하다. 그러한 테두리를 통하여 여러 이해관계자들이 상황과 내용을 자의적으로 해석하고 요구하는 것에 대해 대처할 수 있는 것이다. 이 부분과 관련하여, 프로젝트 매니저가 수행해야 할 역할에 대해 나열해보면 다음과 같다.
① 프로젝트 초기 단계에서 이해관계자가 누구인지, 그리고 어떠한 욕구를 갖고 있는지 정확히 파악한다② 해당 이해관계자가 프로젝트에 영향을 미치는 능력이 어느 정도인지 파악한다. 프로젝트 내에서의 정치적인 구조를 이해하는 것이 중요하다.③ 프로젝트의 목적과 범위에 대해 이해관계자들의 승인을 득한다. 프로젝트의 목적과 범위에 대해 이해관계자들 간의 자의적인 해석을 막아야 한다.④ 모든 변경은 공식적인 변경 절차를 따라야 한다. 프로젝트 매니저는 공식적인 변경 절차를 만들어야 하며, 그 절차 내에는 절차를 따를 필요가 없는 변경 또한 기술되어 있어서 불필요한 관리가 발생하지 않도록 한다.⑤ 절차, 변경 요청, 변경이 미치는 영향, 변경의 결과 등 모든 사항은 프로젝트 기록(문서화)으로 남겨져야 한다.
언제나 필자가 강조하는 것이지만 프로젝트 관리는 경험의 산물이기 때문에 그러한 경험을 얼마나 문서화, 또는 데이터베이스화하여 관리하는가가 중요하다. 그러한 것들이 쌓임에 따라서 조직 내 프로젝트 관리의 질이 점차 향상될 수 있는 것이다. 하나의 프로젝트만 생각한다면 그것은 일시적일 수 있지만, 해당 수행 조직의 거시적인 관점 또는 역사적 관점에서 볼 때에는 과거부터 현재까지 수많은 프로젝트가 공존할 수 있고, 또한 미래에도 프로젝트가 계속 발생할 것이므로 앞으로의 시행착오를 줄일 수 있는 실적 데이터베이스의 유무는 참으로 중요한 것이다. 이 점을 우리는 언제나 기억하여야 할 것이다. 우리가 하는 일이 비록 고난이 뒤따르고 불가피한 시행착오가 있다 할지라도 분명한 한 가지는 미래에는 조금이라도 더 나아질 것이라는 점이다.지난 연재를 통해서 프로젝트 관리의 정의를 비롯하여 프로젝트 매니저로서 갖추어야 할 항목들에 대해 살펴보았고, PMBOK 중심의 프로젝트 관리 프레임워크, 통합 관리, 범위 관리, 시간 관리에 대해서도 살펴보았다. 이번 호에서는 비용 관리를 포함하여 품질 관리, 인적자원 관리, 의사소통 관리에 대해 알아 볼 것이다. 그리고 마이크로소프트 프로젝트 2002의 활용 팁과 마이크로소프트 프로젝트 서버 2002가 제공하는 엔터프라이즈 기능에 대해 간략하게 살펴보겠다. 물론 엔터프라이즈 프로젝트 관리가 단지 프로젝트 관리 소프트웨어에 대한 활용법을 아는 것만으로 원활하게 수행되는 것이 아님을 명심해야 한다.프로젝트 비용 관리프로젝트 비용 관리는 프로젝트가 승인된 예산 하에서 완료될 수 있음을 보증하는 다음과 같은 여러 프로세스들을 포함한다.① 자원 기획② 비용 산정③ 비용 예산 수립④ 비용 통제
프로젝트 비용 관리는 근본적으로 프로젝트 활동을 완료하는데 필요한 자원들의 비용에 주목한다. 일반적으로 실무에서 프로젝트 제품의 예상되는 재무 성과를 예측하고 분석하는 것은 프로젝트의 외부에서 수행된다. 하지만 재무 중심의 일부 프로젝트에서는 프로젝트 비용 관리에서 그러한 것들을 포함하기도 한다.소프트웨어 개발 프로젝트에서는 투입되는 자원의 대부분이 인적 자원이기 때문에 비용 산정을 단순하게 생각하거나 간과하는 경우가 많다. 이것은 예를 들어, 건설업의 프로젝트에서 설계 시 빌딩에 사용되는 전기 스위치 개수까지 정확히 산정해서 물품을 구매해야 하는 것과는 상당히 비교되는 부분이다. 소프트웨어 프로젝트에서 비용 관리를 제대로 수행하지 않는 것은 프로젝트 위험을 증가시키는 커다란 요인 중의 하나이다.프로젝트 비용 관리는 프로젝트 이해관계자들의 요구사항을 고려한다. 여러 이해관계자들은 여러 다른 시점에 각기 다른 방법으로 프로젝트 비용을 측정할 수 있다. 또한 프로젝트 비용이 보상(reward) 및 표창(recognition) 시스템의 요소로 사용될 때 실제 성과를 반영하기 위해 통제 가능한 비용과 통제 불가능한 비용은 별개로 산정되고 예산이 수립되어야 한다. 일부 프로젝트에서는 자원 기획, 비용 산정, 비용 예산 수립이 단일 프로세스로 보이게끔 밀접하게 연계되어 있다. 비용이 영향을 받은 것은 프로젝트 초기에 가장 크며 그렇기 때문에 철저한 요구사항 식별과 견고한 계획 수행뿐만 아니라 초기의 범위 정의가 아주 중요하다.자원 기획자원 기획은 물리적인 자원(사람, 장비)이 무엇인지, 그리고 각각의 자원들이 사용되어야 할 양이 얼마인지, 프로젝트 활동 수행을 위해 그러한 자원들이 필요한 때가 언제인지를 결정하는 것이다.자원 기획을 수행하기 위한 입력물로써 WBS, 과거 실적 정보, 범위 기술서, 자원 풀(pool) 기술서, 수행 조직의 정책, 활동 기간 산정치 등이 필요하다. WBS는 자원을 필요로 하는 프로젝트 인도물과 프로세스를 식별함으로써 자원 기획에 있어 중요한 입력물이 된다. 자원 기획을 위해서는 잠재적으로 이용 가능한 자원에 대한 지식이 필요하다. 자원 풀 기술서에 대한 상세한 양과 특수성의 수준은 다양하다. 예를 들어, 소프트웨어 개발 프로젝트의 초기에는 많은 수의 주니어/시니어 개발자가 포함되지만, 후기에는 프로젝트에 대해 알고 있는 제한된 인원만 있으면 된다. 현재 단계에서 활용 가능한 인적 자원에 대해 알고 있는 것은 중요하다. 또한 스태프 선정과 장비 구매/대여에 관한 수행 조직의 정책은 자원 기획을 하는 동안 고려되어야 한다.프로젝트 관리 소프트웨어는 자원 풀을 조직화하는데 유용한데, 소프트웨어에 의해 자원 달력뿐만 아니라 자원의 가용성(availabilities)과 단가(rates)가 정의된다.결과물로서 자원 요구사항이 만들어진다. 이것은 WBS의 가장 낮은 레벨에서 어떤 자원이 얼마만큼 필요한가에 대해 설명한 것이다. WBS의 상위 레벨을 위한 자원 요구사항은 낮은 레벨의 값들에 기반하여 계산된다. 이러한 자원들은 스태프 충원 및 조달 프로세스를 통하여 확보된다.비용 산정비용 산정은 프로젝트 활동을 완료하는데 필요한 자원의 대략적인 비용을 산정하는 것이다. 이러한 대략적인 비용 산정을 하는 사람은 더 나은 프로젝트 관리를 위하여 최종 산정치와의 편차 원인을 고려하여야 한다. 계약 하에서 프로젝트가 진행되고 있을 때 비용 산정과 가격 결정을 구분하는 것이 필요하다. 비용 산정이란 수행 조직이 제품 또는 서비스를 제공하기 위해 비용을 얼마만큼 지불해야 하는지에 대한 양적인 결과를 평가한 것이며, 가격 결정은 제품 또는 서비스를 위해 수행 조직이 부과하는 요금이 얼마인지를 정하는 비즈니스적인 의사 결정이다.비용 산정은 다양한 비용 대안을 식별하고 고려하는 것을 포함한다. 입력물 중 계정 차트(chart of accounts)는 원장에 재무 정보를 보고하기 위해 수행 조직에 의해 작성된 코드 체계이다. 프로젝트 비용 산정치는 정확한 계정 과목에 할당되어야 한다. 프로젝트 팀은 비용 산정시, 위험(그것이 위협이든 기회이든)이 비용에 중대한 영향을 가져올 수 있으므로 위험에 관한 정보를 고려해야 한다. 또한 프로젝트 팀은 활동의 비용 산정시 위험의 영향이 미치는 범위를 고려하여야 한다.유사 산정(analogous estimating) 테크닉은 하향식(top-down) 산정이라고도 하며, 현재 프로젝트의 비용을 산정하는 데 있어서 과거의 유사한 프로젝트에서 사용되었던 실제 비용을 토대로 하는 것이다. 프로젝트에 대한 상세한 정보의 양이 제한되어 있을 때, 전체 프로젝트 비용을 산정하는 경우가 종종 있다. 유사 산정은 전문가 판단의 한 형태이다. 유사 산정은 일반적으로 다른 테크닉에 비해 저렴하지만 정확하지 않다. 이것은 과거 프로젝트가 단지 외관이 아니라 실제로 유사할 때 산정을 담당하는 개인 또는 그룹이 필요한 전문적 기술을 갖고 있을 때 가장 신뢰가 있다.상향식 산정(bottom-up estimating) 테크닉은 개별적인 활동 또는 작업 패키지(work packages)의 비용을 산정한 다음 프로젝트 전체 합계를 얻기 위해 요약하는 것이다. 상향식 산정의 정확성은 개별 활동의 크기와 복잡성에 좌우되는데, 작은 활동들은 산정 프로세스의 비용과 정확성을 모두 증대시킨다. 프로젝트 관리팀은 추가되는 비용에 따라 얻게 되는 정확성의 정도를 비교 검토하여야 한다.이 프로세스의 결과물로서, 비용 산정치(cost estimates)가 만들어진다. 비용 산정치는 프로젝트 활동을 완료하기 위해 요구되는 자원의 비용을 정량적으로 평가한 것이며, 요약된 형태 또는 상세한 형태로 표시될 수 있다. 프로젝트에 필요한 모든 자원에 대해 비용 산정이 되어야 하며 인건비, 재료비를 포함하여 물가상승비, 비용 예비비 등의 특별한 범주까지 모두 고려되어야 한다. 프로젝트가 진행되는 동안 비용 산정은 추가적인 세부 내용들을 반영함으로써 더욱 개선된다. 비용은 일반적으로 통화 단위로 표시되지만 적절한 관리 통제를 촉진하기 위해 시간당 인건비, 일당 인건비 등과 같은 단위를 사용할 수도 있다. 비용 산정은 일반적으로 비상 계획(contingency plan) 등과 같은 적절한 위험 응답 기획(risk response planning)을 포함한다. 비용 예산 수립비용 예산 수립은 프로젝트 성과 측정을 위한 비용 기준선을 구축하기 위하여 개별 활동 또는 작업 패키지에 대해 전체 비용 산정치를 할당하는 것이다. 비용 기준선(cost baseline)은 프로젝트의 비용 성과를 측정하고 감시하기 위해 사용되는 시간 단위로 구분된 예산이다. 이것은 기간별로 산정된 비용을 요약하여 개발되며, 일반적으로 S-커브의 형태로 표시된다. 규모가 큰 프로젝트는 비용 성과의 여러 관점을 측정하기 위해 여러 개의 비용 기준선을 가질 수 있다. 예를 들어, 지출 계획(spending plan) 또는 현금흐름 예측(cash-flow forecast) 등비용 통제비용 통제는 다음을 포함한다.◆계획과의 편차를 감지하고 이해하기 위해, 비용 성과를 감시한다.◆비용 기준선에 따라 모든 적절한 변경이 정확하게 기록되었는지를 보증한다.◆비용 기준선에 따라 잘못되었거나 부적절하거나 승인되지 않은 변경을 방지한다.◆승인된 변경에 대해 적절한 이해관계자들에게 통지한다.◆허용 가능한 한계 내에서 예상 비용이 처리될 수 있도록 행동한다.
비용 통제는 긍정적이거나 부정적인 편차의 이유(whys)를 발견하는 것을 포함한다. 이것은 다른 통제 프로세스들(범위 변경 통제, 일정 통제, 품질 통제 등)과 철저하게 통합되어야 한다. 비용 편차에 대한 부적절한 대응은 품질 또는 일정 문제를 유발하거나 추후에 허용될 수 없는 위험 수준을 만들어낼 수도 있기 때문이다. 비용 변경 통제 시스템(cost change control system)을 통하여 비용 기준선의 변경 절차를 정의한다.비용 통제의 테크닉 중 하나로 획득 가치 관리(EVM, Earned Vale Management)를 사용한다. 모든 EVM 통제 계정 계획(CAPs, Control Account Plans)은 관련이 있는 세 가지의 독립 변수들에 의해 프로젝트 성과를 지속적으로 측정하는 것이다.◆PV(Planed Value)는 수행되어야 할 물리적인 작업 일정이며 해당 작업의 산정된 가치를 포함한다. 이전에는 BCWS(Budgeted Costs for Work Scheduled)라고 불렸다.◆EV(Earned Value)는 실제로 수행된 물리적인 작업이며 해당 작업의 산정된 가치를 포함한다. 이전에는 BCWP(Budgeted Costs for Work Performed)라고 불렸다.◆AC(Actual Costs)는 EV를 완수하기 위해 발생한 비용이다.
EV에서 PV를 뺀 것이 SV(Schedule Variance)이며, EV에서 AC를 뺀 것이 CV(Cost Variance)가 된다. EVM은 프로젝트 관리에 있어서 중요한 도구 중 하나이며, 이것에 대해 자세하게 설명하는 것은 이 연재의 범위를 벗어나므로 글의 끝 부분에 필자가 정리하여 소개한 PM 관련 서적을 참고하기 바란다.비용 통제 프로세스의 결과로 비용 산정치가 개정될 수 있다. 개정된 비용 산정치는 프로젝트를 관리하는데 사용되는 비용 정보에 대한 수정 사항이며, 필요한 경우 적절한 이해관계자에게 통지되어야 한다. 개정된 비용 산정치는 프로젝트의 계획에 조정을 필요로 할 수도 있고 그렇지 않을 수도 있다.또한 예산 갱신이 발생할 수도 있는데 이는 개정된 비용 산정치의 특별한 범주이며, 승인된 비용 기준선에 변경을 가하는 것이다. 해당 수치들은 일반적으로 단지 범위 변경에 따른 응답으로써 개정되며, 어떤 경우 비용 편차는 현실적인 성과 측정을 제공하기 위해서 기준선의 재작성(rebaselining)을 가져올 수도 있다.이론적으로는 비용 통제의 결과에 따라서 프로젝트의 종료 또는 취소를 위한 프로세스와 절차가 개발되어야 한다. 하지만 대부분의 SI 프로젝트는 이미 고객과 계약을 마친 이후에 정확한 비용이 산정되는 경우가 많기 때문에 계약 후에는 비용 통제의 결과를 이유로 계약을 해지할 수도 없는 노릇이므로 프로젝트 관리에 상당한 부담으로 작용하게 된다. 필자의 생각으로는, 소프트웨어 개발 프로젝트에서는 초기 계약 단계에서 정확한 비용 산정을 할 수 없다는 것을 감안하여 새로운 계약 절차와 형식이 범 정부 및 업계 차원에서 마련되어야 한다고 생각한다. 특히 현재의 저가 입찰과 같은 계약 형태는 전문 소프트웨어 업체의 생존을 심각하게 위협할 뿐만 아니라, 결과적으로 결과물의 품질 저하를 가져오기 때문에 하루 빨리 개선되어야 한다.비용 통제로부터 편차의 원인, 시정조치가 선택된 이유, 기타 교훈은 문서화되어야 하며, 실적 데이터베이스의 일부분이 되어 수행 조직의 현재 프로젝트와 타 프로젝트를 위해 사용된다. 프로젝트 품질 관리프로젝트 품질 관리는 품질 시스템 하에서 품질 기획, 품질 보증, 품질 통제, 품질 향상 등을 통하여 품질 정책, 목표, 책임 그리고 그것을 구현하는 것을 결정하는 총괄적인 관리 기능 활동이며 다음과 같은 프로세스들을 포함한다.① 품질 기획② 품질 보증③ 품질 통제
품질 관리에 대한 기본적인 방법은 ISO(International Organization for Standard)의 9000 & 10000 시리즈와 호환성이 있다. 프로젝트 품질 관리는 반드시 프로젝트 및 프로젝트의 제품에 대한 관리 두 가지 모두를 포함해야 한다. 제품(product)이라는 일반적인 용어는 때때로 품질 문헌에서 물품(goods)과 서비스(services) 모두를 지칭하기 위해 사용된다. 품질 요구사항을 만족시키지 못하는 것은 모든 이해관계자들에게 심각한 부정적 결과를 가져오게 된다.또한 프로젝트 관리팀은 품질(quality)과 등급(grade)을 혼동하지 말아야 한다. 등급은 '동일한 기능적 용도를 갖고 있으나 다른 기술적 특성을 가진 실체에게 주어진 범주 또는 순위'를 의미한다. 낮은 품질은 항상 문제이지만 낮은 등급은 그렇지 않을 수 있다. 예를 들어 소프트웨어 제품은 높은 품질(버그 없음, 읽기 쉬운 매뉴얼)과 낮은 등급(제한적인 기능)을 가지거나, 또는 낮은 품질(많은 버그, 빈약한 문서)과 높은 등급(많은 기능)을 가질 수 있다. 품질과 등급의 수준을 결정하고 제공하는 것은 프로젝트 매니저의 책임이다.품질 기획품질 기획은 품질 표준이 프로젝트에 적절한지 식별하고 그것을 어떻게 만족시켜야 하는 지를 결정하는 것이다. 이것은 프로젝트 기획을 하는 동안 중요한 프로세스이며, 다른 프로젝트 기획 프로세스들과 함께 규칙적이고 병렬로 수행된다. 예를 들어 품질 표준에 대처하기 위해 요구되는 프로젝트 제품의 변경은 비용 또는 일정의 조정을 필요로 할 수도 있다. 또는 요구되는 제품 품질이 식별된 문제의 상세한 위험 분석을 필요로 할 수도 있다. 프로젝트 팀은 또한 다음과 같은 현대 품질 관리의 기본적인 원칙을 하나 알아야 한다."품질은 검사되는 것이 아니라, 계획되는 것이다(Quality is planned in, not inspected in)."입력물로서 품질 정책이 필요하다. 품질 정책이란 '최고 경영진이 공포한 품질에 대한 전반적인 의지 및 조직의 방침'을 의미한다. 대개 수행 조직의 품질 정책이 프로젝트에 사용된다. 하지만 수행 조직의 공식적인 품질 정책이 부족하거나 또는 프로젝트가 다중의 수행 조직을 포함하고 있다면 프로젝트 관리팀은 프로젝트를 위한 품질 정책을 개발할 필요가 있다. 또한 프로젝트 관리팀은 프로젝트 이해관계자가 품질 정책에 대해 완전히 알고 있음을 보증할 책임이 있다.품질 기획의 도구로서, 이익/비용 분석(benefit/cost analysis)을 사용한다. 기획 프로세스는 반드시 이익/비용 트레이드오프를 고려해야 한다. 품질 요구에 부합하는 주요 이익은 적은 재작업, 높은 생산성, 적은 비용, 이해관계자 만족의 증대이다. 품질 요구에 부합하는 주요 비용은 프로젝트 품질 관리 활동에 소요된 비용이다. 벤치마킹(benchmarking)은 개선을 위한 아이디어를 만들어내고 성과 측정에 의해 표준을 제공하기 위해 계획된 또는 실제의 프로젝트 수행을 다른 프로젝트와 비교하는 것이다. 다른 프로젝트는 수행 조직 내에 있을 수도 있고 그렇지 않을 수도 있다.순서도 작성(flowcharting)은 품질 기획을 위한 하나의 도구이며, 소프트웨어 설계 시 작성하는 순서도와는 응용 영역에 차이가 있다. 품질 기획에 있어서의 순서도는 시스템의 다양한 요소들이 어떻게 연관되어 있는지를 보여주는 다이어그램이다. 순서도 작성 테크닉은 품질 관리에서 일반적으로 사용된다. 순서도는 프로젝트 팀이 품질 문제가 어떤 것이고, 그것이 어디에서 발생하는지를 예상하는데 도움을 준다. 따라서 문제를 다루는 방법을 개발하는데 도움이 된다.품질 비용(cost of quality)은 제품/서비스의 품질을 확보하는데 필요한 모든 노력의 전체 비용을 나타낸다. 이것은 요구사항의 일치를 보증하는 모든 작업뿐만 아니라 요구사항에 대한 불일치로부터 발생하는 모든 작업 비용을 포함한다. 품질 비용에는 예방 비용(prevention costs), 평가 비용(appraisal costs), 실패 비용(failure costs)의 세 가지 유형이 있다. 실패 비용은 내부 비용(internal costs)과 외부 비용(external costs)으로 구분된다.이 프로세스의 결과물로서 품질 관리 계획이 만들어지며, 이것은 프로젝트 관리팀이 품질 정책을 어떻게 구현할지를 기술한 것이다. ISO 9000 용어로는 프로젝트 품질 시스템(project quality system)이라고 표현한다. 프로젝트 품질 시스템은 품질 관리를 구현하는데 필요한 조직 구조, 책임, 절차, 프로세스, 자원을 포함하고 있다. 품질 관리 계획은 전체 프로젝트 계획에 입력물을 제공한다. 체크 리스트(checklists) 또한 품질 기획의 중요한 결과물이다. 체크 리스트는 일련의 필요한 단계들이 수행되었는지를 검증하기 위해 사용하는 구조화된 도구이며, 단순할 수도 있고 복잡할 수도 있다. 명령문('이것을 해라!') 또는 의문문('이것을 수행하였는가?')의 문장을 사용한다. 조직의 입장에서 보았을 때 수행된 과업의 일관성을 보증하기 위해 표준화된 체크 리스트를 갖는 것이 좋다.품질 보증 품질 보증은 프로젝트가 관련된 품질 표준을 만족한다는 확신을 제공하는 계획되고 체계적인 활동을 의미하며 프로젝트 전반에 걸쳐 수행된다. 품질 보증은 품질 보증 부서 또는 유사한 이름의 조직 단위에 의해 대개 제공된다. 그러나 그러한 조직 단위가 반드시 존재하는 것은 아니다. 품질 보증은 프로젝트 관리팀 또는 수행 조직의 관리자(내부 품질 보증)에 의해 수행될 수 있으며, 고객 또는 프로젝트 작업에 포함되지 않은 제3자(외부 품질 보증)에 의해 수행될 수도 있다.품질 감사(quality audits)는 품질 관리 활동들의 체계적인 검토이다. 품질 감사의 목적은 수행 조직 내의 프로젝트 성과를 향상시킬 수 있는 교훈을 만들어 내는데 있다. 품질 감사는 계획되거나 임의로 수행될 수 있으며, 적절하게 교육받은 내부 감사자 또는 품질 시스템 등록 에이전시들과 같은 제3자에 의해 수행될 수 있다.품질 보증의 결과로 품질이 개선된다. 품질 개선은 프로젝트 이해관계자들에게 추가적인 이익을 제공하기 위해 효과(effectiveness)와 효율(efficiency)을 증가시키는 행동을 의미한다.품질 통제품질 통제는 특정 프로젝트 결과가 적절한 품질 표준에 부합하는가를 감시하고 불만족스러운 결과의 원인을 제거하는 것이다. 이것은 프로젝트 전반에 걸쳐서 수행되며 프로젝트 결과는 인도물과 같은 제품 결과물, 비용 및 일정 성과와 같은 프로젝트 관리 결과물을 모두 포함한다. 품질 통제는 품질 통제 부서 또는 유사한 명칭의 조직 단위에 의해 흔히 수행되지만, 반드시 그런 조직이 있어야 하는 것은 아니다.검사(inspection)는 결과가 요구사항에 부합하는지를 확인하기 위해 필요한 측정, 시험, 테스트 등과 같은 활동을 하는 것이다. 검사는 모든 레벨에서 행해질 수 있다. 검사는 검토(reviews), 제품 검토(product reviews), 감사(audits) 등으로 불리기도 한다.품질 통제의 결과로 품질이 개선되고, 작업 결과물에 대해서는 수용이 결정되거나 거부된 작업 결과물의 경우 재작업을 필요로 할 수 있다. 재작업은 결점이 있거나 부적격 아이템을 요구사항 또는 명세에 부합하도록 만드는 것이다. 재작업, 특히 예상되지 않은 재작업은 프로젝트 일정을 초과하게 만드는 중요한 원인이다. 프로젝트 팀은 재작업을 최소화하기 위해 모든 노력을 쏟아야 한다.프로젝트 인적 자원 관리프로젝트 인적 자원 관리는 프로젝트에 포함된 사람을 가장 효과적으로 활용하기 위한 프로세스들로 구성되어 있다. 이것은 스폰서, 고객, 파트너 등 모든 프로젝트 이해관계자들을 포함하며 다음과 같은 프로세스들로 구성되어 있다.① 조직 기획② 스태프 충원③ 팀 개발
프로젝트 인적 자원 관리는 다음과 같은 방대한 주제들을 포함하고 있다.◆지휘(leading), 의사소통(communication), 협상(negotiating), 그 외 핵심적인 일반 관리 기술◆위임(delegating), 동기부여(motivating), 지도(coaching), 조언(mentoring), 그 외 개인을 다루는 여러 가지 주제◆팀 개발(team building), 분쟁 조정(dealing with conflict), 그 외 그룹을 다루는 여러 가지 주제◆실적 평가(performance appraisal), 채용(recruitment), 노사 관계(labor relations), 건강 및 안전 규정(health and safety regulations), 그 외 인적자원 관리와 관련된 여러 가지 주제
소프트웨어 개발 프로젝트에 있어서는 인적 자원이 가장 중요한 요소라고 할 수 있으므로 특히 신경을 써야 할 부분이 바로 인적 자원 관리이다. 하지만 국내에서는 상당히 소홀히 다루어지는 분야라고 할 수 있다. 프로젝트 팀이라는 조직의 특성상 또한 엔지니어의 특성상 인적 자원에 대한 전문 지식이 없는 경우가 많기 때문에 프로젝트 팀원들에 대한 관리가 방치되는 경우가 많고, 경영자의 인식 부족도 중요한 문제점으로 작용한다.다음은 프로젝트에서 인적 자원 관리를 수행함에 있어 유의할 부분이다.◆프로젝트의 한시적 특성은 개인과 조직에게 있어 임시적이고 새로운 관계를 만들어낸다. 프로젝트 관리팀은 이러한 임시적 관계를 위해 적절한 테크닉을 선택하여 신중하게 사용해야만 한다.◆프로젝트 이해관계자의 특성과 숫자는 라이프 사이클의 단계가 변하고 프로젝트가 진행됨에 따라서 흔히 변경된다. 결과적으로 하나의 단계에서 효과적이었던 기술이 다른 단계에서는 그렇지 않을 수 있다. 프로젝트 관리팀은 프로젝트의 현재 요구에 적절한 테크닉을 사용해야 한다.◆인적 자원 관리 활동이 프로젝트 관리팀의 직접적인 책임인 경우는 드물다. 하지만 팀은 그것을 보증하는 관리적 요구사항에 충분히 주의를 기울여야 한다. 프로젝트 매니저는 그들이 속한 산업 또는 조직에 따라서, 인적자원의 재배치와 해제에 대한 책임을 가질 수도 있다.
조직 기획역할, 책임, 관계는 개인 또는 그룹에 배정될 수 있다. 개인과 그룹은 프로젝트를 수행하는 조직의 일부분일 수 있고, 또는 외부에 존재할 수도 있다. 내부 그룹은 엔지니어링, 마케팅, 회계 등과 같은 특정 기능부서와 흔히 연계되어 있다. 대부분의 프로젝트에서 조직 기획의 대부분은 초기 프로젝트 단계의 일부로서 수행된다. 그러나 그것의 결과는 계속적인 적합성을 보증하기 위해 프로젝트 내내 정기적으로 검토된다. 초기의 조직이 더 이상 효과적이지 않다면 즉시 개정되어야 한다. 조직 기획은 대개 의사소통 기획과 강하게 연계되어 있다. 프로젝트의 조직 구조는 프로젝트 의사소통 요구사항에 중요한 영향을 미친다.프로젝트 인터페이스는 다음의 세 가지 범주로 구분되며, 흔히 동시적으로 발생한다.◆조직적 인터페이스(organizational interfaces) : 다른 조직 단위 사이에 공식적/비공식적인 보고되는 관계이다. 조직적 인터페이스는 아주 복잡하거나 단순할 수 있다.◆기술적 인터페이스(technical interfaces) : 다른 기술 분야들 사이에 공식적/비공식적으로 보고되는 관계이다. 기술적 인터페이스는 프로젝트 단계 내에서와 프로젝트 단계들 간에 모두 발생한다.◆인적 인터페이스(interpersonal interfaces) : 프로젝트에서 작업하고 있는 다른 개인들 사이에서 공식적/비공식적으로 보고되는 관계이다.
스태프 배정 요구사항은 타임 프레임에 있는 개인 또는 그룹들에 요구되는 능력의 종류를 정의한다. 스태프 배정 요구사항은 자원 기획 동안 식별된 전체 자원 요구사항의 부분 집합이다.제약은 프로젝트 팀의 선택권에 제한을 주는 요소이다. 팀을 조직화하는데 있어 다음과 같은 제약이 있을 수 있다.◆수행 조직의 조직 구조 : 강한 매트릭스 구조의 조직은 약한 매트릭스 구조의 조직에 비하여 프로젝트 매니저의 역할이 더 강력하다.◆단체 협약 : 노조와의 계약상 협약 또는 기타 종업원 그룹은 특정 역할 또는 관계를 요구할 수도 있다. 본질적으로 노조는 이해관계자이다.◆프로젝트 관리팀의 선호 : 만일 프로젝트 관리팀의 멤버가 과거에 특정 구조 하에서 성공한 적이 있다면, 미래에도 유사한 구조를 선호할 것이다.◆예상되는 스태프 배정 : 프로젝트가 어떻게 조직화되는가는 특정 개인의 능력에 의해 흔히 영향을 받는다.
조직 기획의 결과로서, 역할 및 책임 배정이 이루어진다. 프로젝트 역할(누가 무엇을 하는지)과 책임(누가 무엇을 결정하는지)은 적절한 프로젝트 이해관계자에게 배정되어야만 한다. 대부분의 역할과 책임은 프로젝트 매니저, 프로젝트 관리팀, 개인 등과 같이 프로젝트 작업에 적극적으로 포함된 이해관계자에게 배정된다. 프로젝트 매니저의 역할과 책임은 대부분의 프로젝트에서 일반적으로 아주 중요하지만, 실무에서는 상당히 다양하다. 프로젝트 역할 및 책임은 프로젝트 범위 정의와 강하게 연계되어 있다. 책임 배정 매트릭스(RAM, Responsibility Assignment Matrix)는 이러한 목적을 위하여 흔히 사용한다.스태프 배정 관리 계획은 언제 어떻게 인적 자원이 프로젝트 팀에 합류되고 떠날지를 기술한 것이다. 스태프 배정 계획은 프로젝트의 요구에 따라, 공식적이거나 비공식적일 수도 있고 아주 상세하거나 개략적일 수도 있다. 이것은 전체 프로젝트 계획의 부가적인 요소이다. 스태프 배정 계획은 흔히 자원 히스토그램을 포함한다. 팀 멤버가 프로젝트에 더 이상 필요하지 않게 되었을 때 프로젝트 팀 멤버가 어떻게 해제되는지에 대해 특별한 주의를 기울여야 한다. 현재 배정된 작업과 다음 작업간의 시간을 채우기 위한 불요 불급한 일('make work')을 감소시키거나 제거함으로써 비용을 절감한다. 그리고 미래 고용 기회에 대한 불확실성을 감소시키거나 제거함으로써 사기를 향상시킨다.스태프 충원스태프 충원은 프로젝트에 배정되고 작업하기 위해 필요한 인적 자원을 얻는 것이다. 대부분의 환경에서, 최고의(best) 자원은 가능하지 않은 경우가 많다. 하지만 프로젝트 관리팀은 가능한 자원이 프로젝트 요구사항에 부합한다는 것을 보증해야 한다.입력물로서 스태프 풀 기술서가 사용된다. 프로젝트 관리팀은 스태프 배정에 영향을 주거나 직접적으로 관여한다. 또한 다음과 같이 잠재적으로 가능한 스태프의 특성이 반드시 고려되어야 한다.◆과거의 경험 : 개인 또는 그룹이 전에 유사하거나 연관된 작업을 수행해본 적이 있는가? 그들은 그것을 잘 수행하였는가?◆개인적 관심 : 개인 또는 그룹이 이 프로젝트에서 작업하는 것에 대해 관심이 있는가?◆개인적 특성 : 개인 또는 그룹이 팀 내에서 함께 작업을 잘 수행할 수 있는가?◆가용성 : 가장 적합한 개인 또는 그룹이 필요한 타임 프레임 내에서 가능한가?◆능력과 숙련도 : 어떤 능력이 어느 수준으로 요구되는가?
또한 채용 실무 관행도 무시할 수 없는 요소이다. 프로젝트에 포함된 하나 또는 그 이상의 조직들이 정책, 가이드라인, 스태프 배정 절차 등을 갖고 있다면 그것은 스태프 충원 프로세스에 있어서 제약으로 작용한다.대부분의 프로젝트에서 스태프 배정은 협상되어야 한다. 그리고 일부의 경우에는 프로젝트에 스태프가 미리 배정될 수 있다. 그것은 프로젝트가 경쟁적인 제안의 결과이고 또한 특정 스태프가 제안의 일부분으로 약속되어 있을 경우 프로젝트가 내부 프로젝트이고 또한 프로젝트 헌장에 스태프 배정이 정의되어 있을 경우에 그렇다. 그리고 프로젝트를 완료하기 위해 수행 조직의 내부(in-house) 스태프가 부족할 경우에는 조달이 요구된다.조직 기획의 결과로서, 프로젝트 스태프 배정이 이루어진다. 이것은 적절한 사람이 작업에 신뢰할 수 있게 배정되는 것이다. 스태프는 프로젝트의 요구에 따라서 풀 타임, 파트 타임 등 다양하게 배정될 수 있다. 그리고 프로젝트 팀 명부는 모든 프로젝트 팀 멤버와 기타 이해관계자들을 기록한 것이다.팀 개발팀 개발은 이해관계자들이 개인으로서 기여할 수 있는 능력을 향상시키는 것뿐만 아니라, 팀으로서 기능할 수 있도록 팀의 능력을 향상시키는 것을 모두 포함한다. 개인의 관리적 능력과 기술적 능력의 개발은 팀 개발을 위해 필요한 기초가 된다. 프로젝트의 목표를 달성하기 위한 프로젝트의 능력에 있어, 팀으로의 개발은 아주 중요하다.팀 멤버 개인이 기능 매니저와 프로젝트 매니저 양쪽 모두에게 책임이 있을 때 프로젝트의 팀 개발은 복잡해진다. 이러한 두 가지 관계에 대한 효과적인 관리는 프로젝트에 있어 중요한 성공 요인이다. 그리고 그것은 일반적으로 프로젝트 매니저의 책임이다. 팀 개발은 프로젝트 전체를 걸쳐서 수행된다. 하지만 안타깝게도 국내 IT 프로젝트 현실에 있어서는 이러한 팀 개발이 많이 간과되고 있는 것이 사실이다.팀 육성(team-building) 활동은 관리 및 특별하게 주어진 개별 행동들과 성과를 향상시키는 것을 포함한다. 리더십 등과 같은 일반 관리 기술은 팀 개발에 있어 특별히 중요하다. 보상 및 표창 시스템은 훌륭한 행위를 촉진시키거나 강화하기 위한 공식적인 관리 기술이다. 이것이 효과적이기 위해서는 프로젝트 성과와 보상간에 연계가 되어야 하며 명백하고 달성 가능해야 한다. 수행 조직의 시스템이 적절하지 않을 경우, 프로젝트는 자신만의 보상 및 표창 시스템을 가질 수 있다. 이러한 시스템 구축 시에는 반드시 조직간의 문화적 차이가 고려되어야 한다.동일 장소 배치(collocation)는 팀으로서의 수행 능력을 향상시키기 위하여 거의 모든 프로제트 팀 멤버를 동일한 물리적 공간에 배치하는 것을 의미한다. 일부 프로젝트에서는 동일 장소 배치를 선택할 수가 없을 수 있는데, 그러한 경우 상호작용을 촉진시키기 위해 빈번한 대면(face-to-face) 회의를 하는 것이 하나의 대안이 될 수도 있다.훈련은 프로젝트 팀의 능력을 향상시키기 위해 설계된 모든 활동을 포함한다. 훈련은 공식적이거나(교육장에서의 훈련, 컴퓨터 기반의 훈련) 비공식적(다른 팀 멤버로부터의 피드백)일 수 있다. 성인에게 훈련을 제공하는 방법을 아는 것은 중요하다. 만일 프로젝트 팀 멤버가 필요한 관리적 또는 기술적 능력이 부족하다면, 그것은 프로젝트의 일부분으로 개발되거나 스태프의 재배정이 필요하다.팀 개발의 결과로서 성과가 향상된다. 팀의 성과 향상은 다음과 같은 여러 원천으로부터 가능하다.◆개인 기술의 향상은 특정 개인이 배정된 활동을 더욱 효과적으로 수행할 수 있게 해준다.◆팀 행위의 향상은 프로젝트 팀 멤버가 기술적 활동에 대해 그들의 노력을 더 많이 투자할 수 있도록 해준다.◆개인 또는 팀 능력의 향상은 프로젝트 작업을 수행하는데 있어 더 나은 방법을 식별하고 개발할 수 있도록 촉진한다.
프로젝트 의사소통 관리프로젝트 의사소통 관리는 프로젝트 정보의 생성, 수집, 보급, 저장, 최종 처리를 적시에 할 수 있도록 보증하는 여러 가지 프로세스들을 포함한다. ① 의사소통 기획② 정보 배포③ 성과 보고④ 행정적 종결
이것은 성공을 위해, 필요한 사람, 아이디어, 정보 사이의 중대한 연계를 제공한다. 프로젝트에 포함된 사람이라면 누구나 의사소통의 준비가 되어있어야 하며, 어떻게 의사소통을 하는지 이해하고 있어야 한다. 의사소통은 다음과 같은 광범위한 주제를 포함한다.◆송신자-수신자(sender-receiver) 모델 : 피드백 루프, 의사소통 장벽 등◆미디어 선택 : 집필 vs. 구두, 비공식적인 메모 vs. 공식적인 보고 등◆필기 스타일 : 적극적 vs. 수동적, 문장 구조, 단어 선택 등◆프리젠테이션 테크닉 : 바디 랭귀지, 시각적인 보조 도구의 설계 등◆회의 관리 테크닉 : 의사 일정 준비, 갈등 다루기 등
의사소통 기획의사소통 기획은 이해관계자의 정보 및 의사소통 요구를 결정하는 것이다. 모든 프로젝트는 프로젝트 정보의 의사소통 필요성을 공유하며, 정보 요구와 배포 방법은 다양하다. 이해관계자의 정보 요구를 식별하고 그것이 프로젝트 성공을 위해 중요한 요소가 될 수 있도록 하는 것이 중요하다. 대부분의 프로젝트에서 의사소통 기획의 대부분은 초기 프로젝트 단계의 일부분으로 수행된다. 그러나 그것의 결과는 계속적인 적합성을 보증하기 위해 프로젝트 내내 필요에 따라 정기적으로 갱신된다. 의사소통 기획은 프로젝트의 조직 구조가 프로젝트의 의사소통 요구사항에 중대한 영향을 미치기 때문에 흔히 조직 기획과 강하게 연계된다.의사소통 요구사항은 프로젝트 이해관계자들의 정보 요구에 대한 합계이다. 요구사항은 정보에 대한 분석을 통하여 정보의 유형과 형식을 조합함으로써 정의된다. 성공을 위해 정보 의사소통하는 것을 통하여 또는 의사소통 부족에 따른 실패로 프로젝트 자원이 소비된다. 프로젝트 의사소통 요구사항을 결정하는데 있어 전형적으로 다음과 같은 것들이 요구된다.◆프로젝트 조직 및 이해관계자 책임 관계◆프로젝트에 포함된 전문 분야, 부서, 특수성◆얼마나 많은 개인들이 또한 어느 장소에서 프로젝트에 포함되었는지에 대한 세부 계획◆외부의 정보 요구: 예를 들면, 미디어와의 의사소통 등
프로젝트 이해관계자들 사이에 정보를 전달하는데 있어 다양한 기술 또는 방법들이 사용된다. 간결한 대화에서 공개 미팅까지 단순한 문서에서 즉시 액세스 가능한 일정 및 데이터베이스까지 여러 가지 방법이 있다.이해관계자 분석은 의사소통 기획에 있어 중요하다. 다양한 이해관계자들의 정보 요구는 그들의 정보 요구의 체계적이고 논리적인 관점을 개발하고 또한 그러한 요구를 만족시키는 원천을 개발하기 위해 분석되어야 한다. 프로젝트에 적합한 방법과 기술들을 고려한 분석을 통하여 필요한 정보를 제공할 수 있다. 불필요한 정보 또는 부적절한 기술 때문에 자원을 낭비하는 일이 없도록 신중함이 요구된다.의사소통 기획의 결과로서 의사소통 관리 계획이 만들어진다. 의사소통 관리 계획은 다음을 제공하는 문서이다.◆수집 및 서류 정리 구조 : 정보의 다양한 유형을 모으고 저장하는데 사용하는 방법이 무엇인지를 설명한다. 절차는 과거에 배포된 내용들을 시정하고 갱신된 내용을 수집하고 배포하는 것을 포함한다.◆배포 구조 : 어떤 정보가(현황 보고서, 데이터, 일정, 기술 문서 등) 어떤 방법으로(보고서, 미팅 등) 배포되는지에 대해 설명한다. 이 구조는 프로젝트 조직 차트에 의해 설명되는 책임과 관계에 호환성을 가져야 한다.◆배포될 정보 기술서 : 형식, 내용, 상세함의 정도, 사용될 약정/정의를 포함한다.◆제작 일정 : 각각의 의사소통 유형이 언제 만들어질지를 보여준다.◆계획된 의사소통간의 정보 접근 방법◆프로젝트가 진행되고 개발됨에 따라 의사소통 관리 계획을 갱신하고 개량하는 방법
정보 배포정보 배포는 프로젝트 이해관계자에게 필요한 정보를 적절한 시점에 가능하게 하는 것이다. 이것은 의사소통 관리 계획뿐만 아니라 예기치 않은 정보 요구에 응답하는 것을 포함한다.의사소통 기술은 정보를 교환하는데 사용된다. 발송인(sender)은 정보를 애매모호하지 않고 명백하고 완전하게 만들 책임이 있다. 그래야 수신인(receiver)이 그것을 정확하게 수신할 수 있으며 그것이 적절하게 이해되었다는 것을 확인할 수 있다. 수신인은 정보가 온전하고 정확한 이해 내에서 수신되었다는 확실하게 할 책임이 있다. 정보는 매뉴얼 시스템, 데이터베이스, 프로젝트 관리 소프트웨어, 기술 문서(설계 명세, 테스트 계획 등)에 접근을 허용하는 시스템을 통하여 팀 멤버와 이해관계자들간에 공유될 수 있다. 프로젝트 정보는 프로젝트 회의, 하드 카피 문서 배포, 네트워크의 데이터베이스에 대한 접근, 팩스, e-메일, 음성 메일, 회상 회의, 프로젝트 인트라넷 등의 다양한 방법을 통하여 배포될 수 있다.프로젝트 결과물로서 프로젝트 기록(records)이 만들어지며, 프로젝트 기록은 서신, 메모, 프로젝트를 기술한 문서 등을 포함할 수 있다. 이러한 정보는 조직 내에 보관될 수 있고, 프로젝트 팀 멤버는 흔히 노트북에 개인적인 기록을 보관한다. 그리고 공식적인 프로젝트 보고서는 프로젝트 현황과 문제를 나타낸다. 프로젝트 팀은 프로젝트 이해관계자 전부 또는 일부에게 공식적 또는 비공식적으로 정보를 제공한다. 정보는 청중의 요구에 적절해야 하고, 적절한 프리젠테이션 방법이 사용되어야 한다.성과 보고자원이 프로젝트 목적을 달성하기 위해 어떻게 사용되었는지에 대한 정보를 이해관계자에게 제공하기 위해 성과 정보를 수집하고 배급하는 것이 요구된다. 성과 보고는 일반적으로 범위, 일정, 비용, 품질에 대한 정보를 제공한다. 대부분의 프로젝트는 또한 위험과 조달에 관한 정보를 요구한다.성과 검토는 프로젝트 현황과 진도를 평가하기 위해 갖는 회의이다. 성과 검토는 전형적으로 하나 또는 그 이상의 성과 보고 테크닉이 결합되어 사용된다. 편차 분석(variance analysis)은 계획과 실제 프로젝트 결과물과의 비교를 수행하는 것이다. 비용 및 일정 편차는 가장 자주 분석되지만 범위, 자원, 품질, 위험과 관련된 계획과의 편차도 중요하다. 경향 분석(trend analysis)은 시간에 따라 성과가 향상되었는지 나빠졌는지를 확인하기 위해 프로젝트 결과물을 조사하는 것이다.정보 배포의 결과로 성과 보고서(performance reports)가 만들어지는데, 성과 보고서는 수집된 정보를 체계화하고 요약하고 분석 결과를 표시한 것이다. 보고서는 의사소통 관리 계획에 문서화된 내용에 따라서 다양한 이해관계자들에 의해 요구되는 다양한 수준의 정보 종류를 제공한다. 성과 보고서의 일반적인 형식은 막대 차트(또는 간트 차트), S-커브, 히스토그램, 테이블 등의 형태로 나타낼 수 있다. 프로젝트 성과의 분석은 종종 프로젝트의 일부 관점에 대한 변경 요청을 만들어낸다. 이러한 변경 요청은 다양한 변경 통제 프로세스에 기술된 내용대로 다루어진다.행정적 종결프로젝트(또는 단계)에서 목표를 달성했거나 또는 다른 이유로 중지되었을 때 종결을 요구하게 된다. 행정적 종결은 스폰서, 고객에 의해 프로젝트 제품의 공식적인 승인을 얻기 위해 프로젝트 결과물을 문서화하는 것이다. 이것은 프로젝트 기록을 수집하는 것, 최종 명세를 반영했다는 것을 보증하는 것, 프로젝트 성공과 효과 및 교훈을 분석하는 것, 미래 사용을 위해 정보를 취합하는 것을 포함한다. 행정적 종결 활동은 프로젝트 완료 시까지 지연되지 않는다. 프로젝트의 각각의 단계에서 중요하고 유용한 정보가 유실되지 않았다는 것을 보증하기 위해 적절하게 종료되어야 한다.프로젝트 성과를 기록하고 분석하기 위해 만들어진 모든 문서에는 성과 측정을 위해 프레임워크를 확립한 기획 문서가 포함된다. 프로젝트의 제품을 설명하기 위해 만들어진 문서(계획, 명세, 기술 문서, 도면, 파일 등)는 검토를 위하여 반드시 행정적 종결 기간 동안 사용 가능해야 한다.행정적 종결의 결과로 프로젝트 기록 보관이 이루어진다. 색인이 부여된 프로젝트 기록의 완전한 셋트는 적절한 당사자에 의해 기록 보관될 준비가 된 것이다. 프로젝트에 관련이 있는 실적 데이터베이스는 갱신된다. 프로젝트가 계약 하에 있거나 또는 중요한 조달을 포함하고 있을 때 재무 기록을 보관하는데 특별한 주의를 기울여야 한다.최종적으로 프로젝트 종결(closure)이 일어나는데 이것은 프로젝트의 제품에 대한 모든 고객의 요구사항이 부합되었다는 것을 확정하는 것이다. 고객은 프로젝트의 결과물, 인도물, 스태프 평가, 예산보고서 및 교훈 등과 같은 제공 조직의 요구사항들을 공식적으로 승인한다.MSP 2002 활용 및 엔터프라이즈 기능프로젝트 관리 소프트웨어(또는 프로젝트 관리 정보 시스템, PMIS라고도 함)가 프로젝트 관리에 있어 차지하는 비중은 어느 정도일까? 사실 그 비중은 클 수도 있고 그렇지 않을 수도 있다. 대개의 IT 인력들은 프로젝트 관리에 관심을 갖게 될 때 프로젝트 관리 소프트웨어의 중요성을 과대 평가하는 경우가 많다. 하지만 프로젝트 관리 소프트웨어는 오피스의 워드나 액셀 등과 같은 프로그램과는 분명히 틀리다. 일반적인 오피스 프로그램은 대개 사용자가 해야 할 작업을 분명히 알고 있는 상황에서 도구를 이용하여 그것을 효과적으로 수행하는 것이지만 프로젝트 관리 소프트웨어는 아무리 그 도구의 활용법을 안다고 할 지라도 그 안에 어떠한 데이터를 입력하고 무엇을 분석하고 또한 분석 내용을 이해하는 능력은 도구의 활용법과는 완전히 별개의 내용이기 때문이다. 그렇기 때문에 도구 중심의 접근에 앞서 PMBOK 등의 프로젝트 관리 지식과 분석력을 갖추는 것이 중요하다. 필자는 프로젝트 관리 소프트웨어에 대한 지식이 프로젝트 관리 지식을 의미하는 것은 아님을 분명히 밝히며, 그러한 소프트웨어 중심의 접근법에 대해 우려를 나타내지 않을 수 없다. 무언가 먼저 선행되어야 한다면 그것은 프로젝트 관리 지식의 습득이지 소프트웨어의 활용법 습득은 아니다.그리고 IT 인력들과는 반대로 경영적으로 접근하는 관리자들은 대개 프로젝트 관리 소프트웨어를 간과하는 경우가 많다. 하지만 스스로 아무리 프로젝트 관리 지식과 경험이 충분하고 그것을 잘 수행할 수 있는 능력을 갖추었다고 하더라도 프로젝트 내에 포함된 방대한 데이터를 수작업으로 관리하고 분석 및 보고를 수작업으로 할 수는 없는 노릇이다. 사실 현재와 같이 프로젝트의 규모가 커지고 팀원 및 이해관계자 수가 많은 상황에서는 프로젝트 매니저가 데이터를 알고서 관리하는 것 이상으로 정보를 공유하고 협업하는 것이 중요하다. 그래서 엔터프라이즈 프로젝트 관리 지식 및 소프트웨어의 필요성이 대두되고 있는 것이다.단일 프로젝트 환경이 아닌 다중 프로젝트 환경 그리고 더욱이 그러한 다중 프로젝트들이 서로 미묘하게 연관되어 있는 환경에서는 엔터프라이즈 프로젝트 관리가 요구된다. 이를 위하여 전사적으로 권한을 갖고 있는 PMO(Project Management Office)가 조직 내 반드시 필요하다는 주장도 설득력을 얻고 있다.프로젝트 매니저는 프로젝트 관리와 관련된 이론적인 확고한 지식 기반을 갖고 있어야 하며, 또한 프로젝트 관리 소프트웨어의 활용법에 대해서도 충분히 알고 있어야 한다. 이러한 두 가지에 대한 균형 감각을 갖추는 것이 현대의 프로젝트 매니저에게는 필수적으로 요구되고 있는 것이다.지난 호에서 MSP(Microsoft Project)의 계획, 작업 목록 작성, 자원 배정의 활용에 대해 살펴봤는데, 이번 호에서는 진도 관리 및 보고서 기능의 활용에 대해 살펴보고 MSP 기반의 협업을 위한 두 가지 방식과 프로젝트 서버(Project Server)의 기능에 대해 살펴보도록 하겠다.초기 계획 저장MSP는 하나의 계획 내에 11개의 초기 계획을 저장할 수 있다. 프로젝트 계획이 개발된 이후에 프로젝트 매니저는 지속적으로 프로젝트 진도를 관리하고 작업 성과를 평가한다. 작업 성과를 평가하기 위해서는 원래 계획(baseline)과의 비교가 필요하다. 초기 계획에는 작업, 자원, 자원 배정, 시간 배정 등의 값들이 포함된다. 여러 가지 초기 계획을 관리함으로써 이전 값들과의 비교를 하는데 커다란 도움이 될 수 있다. [도구] 메뉴의 [작업 진행 관리]에서 [초기 계획 저장]을 클릭하여 초기 계획을 저장한다.① 철저한 분석② 체계적인 분류③ 객관적인 계량화④ 성실한 문서화⑤ 1∼4의 통합적인 노력 및 교훈의 활용
그렇지만 이러한 컨셉은 솔직히 지금까지의 우리의 조직 문화, 업무 방식과는 차이가 있으며 그러한 이유로 서구의 프로젝트 관리 지식을 수용하는데 많은 어려움이 있는 것이 사실이다. 그러나 현재 우리의 방식에는 분명히 문제가 있으며 한참을 양보해서 얘기한다고 할지라도 개선할 여지가 있는 것은 부정할 수 없는 사실이다.필자가 주장하는 것은 우리의 프로젝트 관리 방식의 개선을 위해 여러 가지 프로젝트 관리 지식과 기법과 도구가 검토되어야 하며 그러한 과정에서 우리에게 최적화된 지식과 기법이 개발될 수도 있다는 것이다. 그리고 그 결과물로서 훌륭한 프로젝트 매니저들이 많이 양산될 수 있을 것이고 그것은 결국은 IT 산업 전체의 경쟁력 향상을 가져오게 된다고 생각한다. 지금까지의 프로젝트 관리는 지극히 개인적인 능력과 경험에만 의존한 감이 크다. 프로젝트 관리 업무 자체가 오히려 프로젝트 자체에 있어 커다란 위험 요인이었던 것이다. 하지만 조만간 여러 조직에서 프로젝트 관리 지식의 적용은 선택이 아닌 필수가 될 것이다.지면 관계상 다양하고 깊이 있는 내용을 살펴보지 못했다는 아쉬움이 많지만 3회에 걸친 연재를 통하여 거시적인 관점에서 프로젝트 관리의 개요적 내용을 살펴보았으므로 추후에는 단위 지식을 통해 더욱 상세한 내용을 살펴 볼 수 있는 기회를 만들어 보도록 하겠다. 그것을 위해서는 독자들의 호응과 지적이 필요하며, 그러한 참여야말로 IT 프로젝트 관리의 질을 향상시키는데 있어 소중한 밑거름이 될 것이라고 생각한다. @
