프로젝트 진척률에서 건강의 혈압측정 이상을 기대해서는 안된다.
프로젝트 일정성과를 판단하는 손쉬운 방법은 마일스톤 일정 준수여부를 판단하는 것이다. 예를 들어 수행기간이 6개월인 프로젝트에서 통합테스트 완료가 일주일 지연되었다면 큰 문제없는 것이고, 통합테스트가 2개월 지연되었다면 일정의 큰 차질이 있는 것이다.
그러나 프로젝트 WBS를 통합한 진척상황을 관리하려면 1~2개월 단위의 마일스톤만으로는 부족하며, 개별 업무들을 통합한 진척지표가 필요하다. 뿐만 아니라 고객이 진척률에 따라 대가를 지불하는 프로젝트에서도 객관적이고 체계적인 진척지표가 필요하다.
프로젝트 진척률 관리를 통해 얻고자 하는 답은 다음과 같다.
- 프로젝트가 계획대로 진행되고 있는지? (계획달성률)
- 현재까지 프로젝트 전체 업무의 몇 %를 완료했는지?(업무완성률)
- 현시점에서 예상하는 프로젝트 완료일은?(예상완료일)
프로젝트 진척률 지표는 사람의 건강에 비유하면 혈압과 비슷하다. 혈압은 개인의 건강을 체크하기 위한 기본적인 지표이다. 높은 혈압은 건강에 대한 적신호이지만, 혈압이 정상이라고 해서 그 사람이 건강하다고 이야기할 수 없다. 진척률 지표도 마찬가지이다. 진척률이 나쁘면 프로젝트가 궤도를 이탈하고 있다고 판단할 수 있지만, 진척률이 좋다고 프로젝트가 잘 진행되고 있다고 판단해서는 안된다. 왜냐하면 프로젝트 과거성과를 측정하는 계획달성률과 업무완성률은 정확한 측정이 어렵고 미래의 성과를 추정하는 예상완료일은 추정자체가 힘들기 때문이다.
프로젝트 진척률은 프로젝트 성과를 판단하는 참고지표로만 활용해야 하며 그것을 맹신해서는 안된다. 예를 들어 프로젝트 ‘업무완성률’이 95%, ‘계획달성율’ 99%는 무엇을 의미할까? 전체 업무 중 5%만 남았고 프로젝트 계획은 99% 달성하고 있으니 프로젝트가 큰 문제없이 곧 완료할 것이라고 판단하기 쉽지만 현실은 그렇지 않은 경우가 많다. 프로젝트 진척률에 대한 대표적인 오해는 다음과 같다.
오해 1. 프로젝트 진척률을 정확하게 측정할 수 있다.
진척률을 측정하는 식은 다음과 같다.
- 계획달성률 : 특정시점까지 완료한 업무의 크기/특정 시점까지 완료예정인 업무의 크기
- 업무완성률 : 특정시점까지 완료한 업무의 크기/프로젝트 전체 업무의 크기
- 예상완료일 : 현재일 + 남은 업무의 크기/남은 기간의 업무 생산성
‘업무완료 기준’과 ‘업무의 크기’가 정확할수록 진척률의 신뢰도는 높아진다. 그러나 현실에서 이 두 가지를 정확하게 측정하기 힘들다.
[업무완료 기준]
완료하지 않은 업무를 완료한 것으로 평가하면 진척률은 실제보다 높아진다. 그 결과 완료로 평가한 업무를 수정하기 위한 노력은 프로젝트 진척률에 반영되지 않는다. 이 때문에 프로젝트 진척률이 일정 수준(예:90%) 이상이 되면 투입노력대비 진척률이 더디게 올라간다.
업무 완료를 정확하게 판단하기 위해서는 다음에 유의해야 한다.
① 요구사항을 정확하게 이해해야 한다. 엉뚱한 업무를 완료하는데 투입된 노력은 의미 없다.
② 품질기준을 달성하지 않은 업무를 완료로 판단해서는 안된다. 단위테스트를 대충 수행한 뒤 통합테스트에서 개별 프로그램의 결함을 많이 발견한다면 프로그램 개발진척을 실제보다 높게 판단한 것이다.
③ 연관된 업무의 인터페이스에 문제가 없어야 한다. 상호 연관된 업무들의 연계를 위해 필요한 요건을 누락해서는 안된다. 인터페이스 업무는 WBS에 별도업무로 정의하거나 인터페이스 요건을 관련 업무의 요건에 명시해야 한다.
[업무의 크기]
프로젝트 수행업무(WBS)를 구성하는 다양한 개별업무의 크기를 정확하게 측정하는 것은 어려우며 그 이유는 다음과 같다.
- 프로젝트 업무크기를 정확하게 측정하려면 업무에 따라 측정단위가 달라진다.
예를 들어 프로젝트 계획수립, 스프린트 수행, 통합테스트 실행, 데이터 전환을 정확하게 측정하는 기준은 아래 표와 같이 다르다. 개별업무의 크기를 정확하게 측정하기 위해서는 다양한 지표를 사용해야 하지만, 다양한 지표를 사용하면 전체 진척률을 통합하여 측정할 수 없다.
- WBS의 모든 업무의 크기를 측정할 수 있는 기준인 수행기간(duration)과 MM는 상세한 정의가 힘들고 직관적이지 않다.
예를 들어 프로그램 개발과 통합테스트의 크기를 진척률을 수행기간 또는 MM로 평가한다면 개별 프로그램이나 테스트 시나리오별로 수행기간 또는 MM를 추정해야 하는데 그것은 많은 노력을 필요로 하며 프로젝트 팀원들이 이해하기에 직관적이지 않다. 요구사항(또는 기능)의 크기를 측정하는 기능점수(Function point)나 스토리 점수(story point)가 있지만 그것은 프로그램 개발에 국한할 때 효과적이다. 요구사항 분석, UX 설계, 개발을 통합하여 측정하면 진척 측정 및 모니터링 기간이 길어질 뿐 아니라 WBS에 기반한 진척측정이 아니다.
오해 2. 정밀하게 측정하는 진척률이 정확하다.
과학적 관리를 맹신하는 고객이나 경영층을 주변에서 흔히 볼 수 있다. 그런 사람들은 프로젝트 진척률을 정밀하게 측정할수록 프로젝트 상황을 정확하게 측정할 수 있다고 생각한다. 그러나 아무리 고가의 장비를 측정하여 혈압을 측정해도 헬스장에서 측정하는 혈압과 큰 차이가 없듯이 프로젝트 진척률도 마찬가지다. 프로젝트 진척률은 보통의 사람들이 직관적으로 판단했을 때 큰 문제가 없으면 된다. 예를 들어 통합테스르를 완료한 시점에서 프로젝트 진척률(업무완성률)은 80%에서 95% 사이면 적정하다. 82%면 어떻고 95%면 어떨까? 사람에 따라 80%에 가깝게 느낄 수도 있고, 95%에 가깝게 느낄 수도 있지만 큰 문제가 없다. 업무가 완료될 때마다 진척률이 증가하면 된다. 그것을 정밀하게 측정한다고 한들 어떤 이득이 있을까? 중요한 것은 남은 일의 내용이지 남은 일의 %가 아니다. 프로젝트 진척률은 무게나 길이를 측정하는 것처럼 절대단위가 아니기 때문에 ‘다이어트 프로젝트’의 몸무게와 같은 지표를 기대해서는 안된다.
진척률을 관리하기 위한 노력대비 진척률 관리에서 얻는 혜택을 비교하여 진척률의 상세화 정도를 결정해야 한다. 진척률 관리는 수단이지 목적이 아니다. 왜 진척률을 관리하는지 그 목적을 분명하게 한 뒤 그 목적을 달성하기 위해 가장 효율적인 방법을 선택해야 한다. 프로젝트 진척률을 정밀하게 측정할수록 프로젝트 팀원들로부터 많은 데이터를 취합하고 통합해야 한다. 정밀한 프로젝트 진척관리를 위해 엑셀이 아닌 상용도구를 사용한다면 도구 시용비용과 도구 교육비용이 발생한다. 특히 애자일 방법론을 적용하는 프로젝트에서 WBS에 기반한 정밀한 진척관리 도구를 적용한다면 득 보다 실이 크다. 애자일 방법론을 적용하는 프로젝트에서는 프로젝트 계획을 상세하게 확정하지 않고 프로젝트를 진행하기 때문이다.
오해 3. 진척률을 관리하면 프로젝트 리스크를 관리할 수 있다.
프로젝트 성과를 관리하는 대표적인 영역은 품질, 일정, 원가이며 이는 리스크 관리의 영역이기도 하다. 일반적으로 품질은 일정에 선행하며, 일정은 원가에 선행한다. 즉 품질이슈가 발생하면 일정이 지연되고 일정이 지연되면 원가가 증가한다. 품질은 통합지표로 관리하지 않고 개별 사안으로 관리하기 때문에 모니터링 주기적인 모니터링 지표로는 적합하지 않다. 일정과 원가는 통합지표로 관리 가능하지만 대부분 일정은 원가에 선행하고 일정과 원가는 비례하는 경우가 많기 때문에 일정지표(계획달성률)가 리스크를 식별하고 리스크 관리효과를 판단하는 지표가 된다.
리스크와 이슈를 구분하기도 하는데 이슈는 발생한 리스크이고, 리스크는 발생하지 않은 이슈로 정의한다. 계획달성률을 리스크를 식별하고 이슈해결을 관리하는 지표로 사용할 수 있다. 예를 들어 계획달성률을 몇 개의 구간으로 나누어 리스크의 심각도를 구분하여 관리하는 것이다. 현실에서 계획달성률은 리스크를 식별하는 지표로는 한계가 있다. 물속의 개구리처럼 조금씩 지연되는 계획달성률에 둔감해지기 때문이다. 반면 이슈해결이 효과적인지를 판단하는 지표로 계획달성률은 어느 정도 유용하게 사용할 수 있다. 어느 정도라고 표현한 이유는 이슈 프로젝트가 정상적인 궤도로 진입하고 있는지 판단하는 지표로는 결함조치율과 같이 보다 구체적인 지표가 있는 경우가 많기 때문이다.
오해 4. 프로젝트 진척률(업무 완성률)은 감소하지 않는다.
프로젝트 진척률은 몸무게처럼 줄었다 늘었다 하지 않고, 시공 중인 빌딩의 진척처럼 시간이 지날수록 증가한다. 따라서 프로젝트 진척률은 예외적인 상황이 아니라면 지속적으로 증가해야 한다. 그러나 프로젝트 진척률도 감소하는 상황이 있다. 첫째 프로젝트 업무가 증가하는 경우이다. 예를 들어 프로그램 100개를 개발할 때 프로그램 50개를 완료하면 50%의 진척률이지만, 프로그램이 증가하여 200개가 되면 진척률이 25%로 감소한다. 이러한 경우는 프로젝트 계획을 변경하기 때문에 진척률을 조정하는 것도 당연하다. 둘째 완료되지 않은 업무를 완료했다고 평가한 것을 미완료로 수정할 때이다. 이는 프로젝트 팀의 잘못을 인정하는 것이기 때문에 고객이나 경영층이 요청하기 전에는 발생하지 않는다. 잘못 수행한 업무를 재 작업하는 것도 이 경우에 포함된다.
https://brunch.co.kr/@kbhpmp/160