[12월 칼럼] 대규모 프로젝트의 Health Check 도구 발견(R 기반)
프로젝트 성공을 위한 지속적인 모니터링
프로젝트란 고유한 제품, 서비스 또는 결과를 창출하기 위해 일과성(Temporary)으로 투입하는 노력을 말한다. 일과성이란 모든 프로젝트의 시작과 끝이 명확히 한정되어 있는 것을 의미한다. 프로젝트의 목표가 달성되었거나 프로젝트 목표 달성이 불가능한 것으로 명확히 확인되었을 때 또는 프로젝트가 더 이상 필요하지 않아서 중단할 때 프로젝트는 종료된다.
필자는 한해 다수의 프로젝트를 경험(점검 및 시정을 요구하는 업무)하는데 다수의 프로젝트를 관찰하다 보면 프로젝트의 규모, 관리인력의 역량, 프로젝트 환경 등에 따라 관리 수준이 천차만별이다. 이러한 관리 수준을 일정 수준 이상 향상시킬 수 있는 방법은 없는 것인지 고민하지 않을 수 없게된다.
진행중인 프로젝트의 상태를 효율적으로 확인하고 프로젝트가 가시성을 유지한 상태에서 안정적으로 진행을 유도할 수 있는 관리적 기법을 현장에서 고민하고 적용한 사례를 소개하고자 한다.
<대규모 프로젝트에서의 Health Check 도구 발견>
1. 프로젝트 성공은 어려운 일
2. 소프트웨어 구축 프로젝트의 가시성 확보의 중요성
3. 프로젝트에서 계획의 중요성 그리고 WBS
4. 프로젝트의 효율적인 모니터링 및 가시화 방법 발견
5. 맺음말
1. 프로젝트 성공은 어려운 일
소프트웨어 공학 도구가 발전하고, 다양한 생산성 도구가 경쟁적으로 나타나고 있지만 여전히 소프트웨어 구축 프로젝트의 성공은 힘든 것으로 조사되고 있다. Chaos Report 2020에 따르면 소프트웨어 구축 프로젝트의 실패 또는 위험의 경우가 86%에 이르고 있으며 단지 14%만이 성공이라 할 만한 프로젝트로 정의되고 있다[1].
프로젝트 성공이란 개념은 프로젝트 특성 파악을 통해 이해할 수 있다. 프로젝트 특성은 “시작과 종료가 명확히 존재”, “유일한 상품이나 서비스”, “목적이 있는 일”, “상호 연관성이 있는 작업”, “순차적으로 연속되는 작업”으로 정의하고 있으며, 이러한 프로젝트의 특징을 효과적으로 잘 관리하면 프로젝트는 성공하게 된다. 프로젝트 성공이란 “주어진 자원 내에서 유일한 상품이나 서비스를 잘 만들어 내는 것”으로 정의하고 있고 여기서 자원이란 “시작과 종료라는 시간과 만들어야 하는 대상(범위/비용)”으로 이해할 수 있다.
프로젝트를 성공적으로 관리하기 위해 프로젝트의 3대 요소(시간, 범위[비용], 품질)를 잘 관리하는 방향으로 프로젝트 관리 기법은 최적화 되었는데 그 중 시간과 범위를 잘 관리하기 위한 대표적인 도구가 WBS(Work Breakdown Structure, 작업 분할 체계)이다. 다양한 상용 도구들뿐만 아니라 시간/범위/품질을 효과적으로 관리하기 위해 조직마다 유사한 형태의 WBS를 정의하여 프로젝트를 관리한다. WBS와 같은 프로젝트 관리 도구는 나날이 발전하고 있음에도 불구하고 점진적으로 고도화되고 복잡하며, 대규모화되는 소프트웨어 구축 프로젝트는 여전히 관리가 어렵다.
2. 소프트웨어 구축 프로젝트의 가시성 확보의 중요성
소프트웨어 구축 프로젝트의 성공을 위한 핵심요소는 프로젝트 상태에 대한 가시성 확보에 있다. 가시성 확보가 중요한 이유는 역시 소프트웨어의 특징에 기인한다. 소프트웨어 특징은 비가시성, 복잡성, 변경성, 무형성, 복제성 등으로 표현되고 있다[2]. 그러나 전통적인 방법의 소프트웨어 구축 단계에서는 설계가 지난 이후에나 소프트웨어의 기능적 동작 여부를 확인할 수 있고 이 시기부터 사용자는 적극적인 의견을 제시하는 등 관심을 보이게 된다. 그러나 이미 지나버린 분석 및 설계 단계의 시간적 손실은 프로젝트 관리 측면에서 회복하기 어렵게 된다. 그렇다면 분석 및 설계 단계의 진행에 대해 믿음을 줄 수 있는 방법은 없는 것인가?
필자는 한해 수건의 소프트웨어 구축 프로젝트를 경험한다. 이렇게 다양한 소프트웨어 구축 프로젝트에서 얻은 경험에 따르면 프로젝트의 진행 과정을 지속적으로 모니터링하고 이상징후를 재빨리 알아채어 교정하는 방법이 최선의 방법으로 이해하고 있다.
프로젝트의 진행 과정을 지속적으로 모니터링하고 이상징후를 재빨리 알아채는 효과적인 방법으로 PDCA 사이클을 빼놓을 수 없다. PDCA사이클은 데밍사이클로도 불리운다. PDCA 사이클에서 Plan 단계는 프로젝트 계획을 수립하고, Do 단계에 프로젝트를 실행한다. Check 단계에는 모니터링(감사, 감리 등 제3의 객관적 조직에 의한 점검)을 수행하고, Act 단계에는 계획 보완을 통해 변경된 계획 기반의 프로젝트를 실행한다.
3. 프로젝트에서 계획의 중요성 그리고 WBS
그나마 소규모 프로젝트의 경우는 어렵지 않게 모니터링이 가능할(?) 것으로 보일 수 있지만, 중·대규모 프로젝트는 ISBSG에 따르면 화면의 개수가 약 3천여 개, 데이터가 약 700여 개 이상으로 구성된 복잡한 소프트웨어로 소규모 프로젝트에 비해 상대적으로 많은 관리적 노력이 필요하다.
관리적 노력의 시작은 계획부터이다. 사업관리자가 겪는 전형적인 문제점은 계획을 체계적으로 세우지 않았기 때문에 발생하게 되는 것으로 체계적인 계획은 고충체감 곡선상 사업 초기에는 어려움이 많을 수 있으나 사업 진행 과정에서 고충이 줄어들고 프로젝트가 안정적으로 진행된다는 것에 믿음을 갖게 된다.
필자의 프로젝트 경험에 따르면 프로젝트에서 제일 중요한 관리적 산출물이 WBS이지만 프로젝트 규모, 만드는 사람, 프로젝트 환경 등에 따라 수준의 편차가 심한 것도 WBS이다. WBS는 프로젝트의 전체 범위를 구성하고 정의하는 프로젝트 요소작업들의 업무 및 산출물 위주의 체계도이다. 단계가 내려갈수록 프로젝트 요소들은 점진적으로 상세히 정의되며, 프로젝트 요소들은 산출물이나 서비스(기능)가 된다. WBS는 범위, 일정, 산출물, 자원을 통합 관리하기 위한 프로젝트 관리에서 빠져서는 안될 중요 관리 도구이지만, 일부 프로젝트에서는 형식적인 도구로 전락하는 사례도 경험 한다.
의사소통 도구로 주·월간 보고 방법을 채택하여 추진하는 사례가 많으며 주·월간보고에 채워지는 주요 내용으로 WBS의 각 Task별 진척도 및 업무 내용을 참고하여 기입하므로 WBS를 짜임새 있게 계획하는 것은 프로젝트의 가시성 확보를 위해 가장 중요한 업무가 된다. WBS를 작성하는 방법은 추후 다른 지면을 통해 소개할 수 있을 것으로 기대한다.
필자는 다수 프로젝트 현장을 방문하며 프로젝트의 상태를 공식적으로 모니터링하고 문제점을 발견하며 시정조치를 요구하는 업무를 수행한다(PDCA 중 Check 역할과 유사). 대규모 프로젝트의 WBS에는 다양한 구성 요소와 포함하는 내용이 방대함에 따라 WBS의 오류 발견이 어려우며 프로젝트가 정상적으로 진행되고 있는지 여부를 판단하기도 어렵다.
프로젝트의 상태점검(Health-Check)을 위한 효율적인 도구로 간트 차트와 계획 및 실적자료를 통한 프로젝트의 추세 예측 차트를 활용하고 있으나 대규모의 프로젝트는 수많은 업무로 구성되어 있어 진도를 평가하는 것이 만만치 않게 된다. 필자가 경험하고 있는 대규모 프로젝트 환경하에서 많은 수의 단위 업무를 통합적으로 관리하기 위해 활용한 도구 및 모니터링 내용에 대해 소개를 하고자 한다. 사례의 프로젝트는 단위 업무가 13개로 구성된 프로젝트이다. 단위 업무별 소프트웨어 개발 단계가 존재하고, 개발 단계별 소프트웨어 개발 방법론에 따른 산출물과 각 업무 유형별 7 Level까지를 관리하며, 대략 7,000 라인 정도로 각 단위 업무를 관리한다.
이런 대규모 프로젝트 환경에서 가시성을 어떻게 확인해야하고 이상징후를 어떻게 알아챌수 있는 것인가? 프로젝트 상태점검 도구는 통합적 가시성과 각각의 단위 업무에 대한 가시성을 지속적으로 모니터링하며, 이상 데이터를 쉽게 파악할 수 있도록 관리도구를 구성했다.
4. 프로젝트의 효율적인 모니터링 및 가시화 방법 발견
필자는 프로젝트 관리자에게 WBS에 대해 일관된 형식으로 작성 및 관리를 주문하였다. 매주 13개 단위 업무에 대한 WBS가 계속 생산됨에 따라 규모를 효율적으로 관리하기 위한 도구가 필요했고 필자는 13개 단위 업무의 상태점검을 위한 도구로 R-Package를 선택하였다.
1) R을 활용한 대규모 프로젝트의 전체 일정 파악
R을 활용하여 13개 단위 업무를 통합적으로 파악하며, 계획의 변경 여부, 실적과 GAP을 가시적으로 확인하고 계획과 실적 GAP이 관리기준(5%, 10%, 15% 등 차이) 내에 존재하는지 여부도 파악하며 데이터를 탐색한다.
2) R을 활용한 대규모 프로젝트의 각 단위 업무별 진행율·지체율 모니터링
13개 단위 업무별 진행율과 지체율을 가시적으로 동시에 파악함으로써 프로젝트의 관리기준 및 단위 업무별 지체상황에 대해 타겟 관리가 가능하다.
3) R을 활용한 대규모 프로젝트의 각 단위 업무별 개발 진행 현황(1)
사례 프로젝트는 13개의 단위 업무로 구성되었고, 전체 개발해야 할 응용프로그램 개수가 6,919개로 방대한 응용프로그램 개수를 보이고 있다. 이렇게 방대한 개발건수에 대해 계획 대비 실적과 개발 진행 현황을 한 눈에 알수 있도록 구성했다.
4) R을 활용한 대규모 프로젝트의 각 단위 업무별 개발 진행 현황(2)
사례 프로젝트의 13개 단위 업무 6,919개에 대해 계획 대비 실적건수를 한 눈에 알아 볼 수 있도록 구성한 현황이다.
5) R을 활용한 대규모 프로젝트의 각 단위 업무별 개발 진행 현황
WBS 기준에 따라 진도가 적정한지 여부를 점검하기 위해 여러 개의 업무마다 해당되는 세부적인 작업명, 그 작업의 진행현황 등을 특정기준일을 기준으로 파악하고자 정리하였다.
5. 맺음말
현재 관리중인 대규모 프로젝트 환경에 사례 외에도 다양하게 R기반 관리도구를 실험적으로 적용하고 있으며, 관리 효율성 측면에서 의미가 있는 것은 이후 다른 지면을 통해 소개할 기회가 있을 것으로 기대한다.
금번 칼럼의 내용이 효율적인 프로젝트 상태 모니터링 및 가시성 확보에 많은 도움이 되길 기대하고, 프로젝트 진도가 이해관계자들간 객관적인 시각으로 소통할 수 있기를 기대한다.
정보관리기술사, 공학박사, PMI 한국챕터 교육위원회 위원, ISMS-P, KERIS비식별 자문위원 등. 현재 ㈜아이삭의 이사로 AI 등 4차 산업혁명 주요 적용 기술에 대해 컨설팅을 수행하는 컨설턴트이다. 파이썬, R 패키지 및 파이썬을 현장에 적용하며 현장의 문제를 해결하는데 관심을 가지고 있다.
현재 법무부 교정본부의 차세대 정보시스템 개발 업무에 대한 상주감리를 수행하고 있으며, (주)키삭의 수석컨설턴트로 정보시스템 개발 및 정보보안 분야 컨설팅을 수행하는 컨설턴트로 근무중이고, 한국 R 사용자그룹(KRUG) 회원으로서 R을 이용한 데이터분석 및 시각화 업무에 대한 교육 및 프로젝트 적용 활동을 지원하고 있다.
<주석>
1) 최근 Agile방법론의 경우 스프린트라는 짧은 단위의 작업을 주기적으로 반복하며 사용자를 프로젝트 내부에 깊이 참여시켜 소프트웨어 기능 동작을 일찍 경험시켜주는 방법으로 사용자를 프로젝트 초기에 참여시킨다는 점에서 전통적인 방법과 큰 차이가 있다. 전통적인 방법과 Agile방법의 장단점을 논하는 지면은 아니므로 뭐가 더 좋은지에 대해서도 논외이다.
2) 1930년대 통계학자인 Shewart에 의해 처음 소개되었으나, Deming이 품질관리 모델로 대중화 시켰다. 2차 세계대전 이후 1950년에 Deming이 일본에 품질관리의 체계적 접근방법으로 소개하면서 PDCA 사이클로 통하게 되었다.
3) 대규모 사업 : 100억 내외(약 18,000 FP), 소규모 사업 : 1억 내외 (약 181 FP), 중규모 사업 : 1억 이상 ~ 100억 사이
4) ISBSG(International Software Benchmarking Standards Group) : 국제적인 소프트웨어 생산성 지표 및 데이터를 관리하는 국제SW벤치마킹 표준 그
5) FP(Function Point) : 소프트웨어가 가지는 (트랜잭션, 데이터)기능의 개수를 바탕으로 해당 소프트웨어의 규모를 측정하는 기법으로 ISO 14143표준이다.
6) 사업수행계획서를 작성할 때 프로젝트 관리 영역별 계획을 수립하지만 이를 통해 산출될 가장 핵심적인 관리 문서가 WBS 이다. WBS는 범위, 일정, 자원, 의사소통, 산출물이 통합적으로 기입되고, WBS는 사용자의 소프트웨어가 제작되는 과정을 빠짐없이 담고 있어야 하며, 프로젝트 관리 영역의 나머지 부분(품질, 위험, 조달 등)들은 WBS로부터 산출되는 많은 것들을 지원할 수 있어야 한다.
7) 프로젝트 및 단위 업무 세분화(산출물 수준), one-week/one-month(주/월 진도 관리 활용) 관리 기준 등에 따라 프로젝트에서 추진해야 할 업무를 상세하게 세분화하여 일정/자원/산출물을 매핑한다.
8) 프로젝트 업무가 언제 진행될 것인지, 실제 진척, 계획된 요구사항에 대한 정보를 직관적으로 나타낼 수 있는 막대 차트로 어떤 작업이 완료되어야 하는지를 편리하게 파악하며 진도를 평가할 수 있다.
9) 계획과 실적을 선 그래프로 표현하고 계획대로 완료될 것인지 거시적으로 평가할 수 있다.
10) 통계 계산과 그래픽을 위한 프로그래밍 언어이자 소프트웨어 환경이자 프리웨어이다. R은 통계 소프트웨어 개발과 자료 분석에 널리 사용되고 있다.
[참고문헌]
[1] Chaos Repot 설명자료, https://zenexmachina.com/waterfall-vs-agile-a-knowledge –problem-not-a-require ments-problem/
[2] 소프트웨어 공학(2015, 정익사), 최은만
[3] 위키, https://commons.wikimedia.org/wiki/File:PDCA_Process.png