측정과 분석 (Measurement and Analysis) 프로세스 영역에 대하여

측정과 분석 프로세스 영역에 대한 이해를 위한 해설보다는 프로젝트 내에서, 그리고 조직 레벨에서의 효과적인 구현 및 대응 방향에 대해 얘기하려고 한다.

프로젝트나 조직 내에 "측정과 분석" 프로세스를 가진 조직은 과연 몇이나 될까? 그것도 '프로세스'란 이름으로?

CMMI 모델의 PA (Process Area) 를 번역하자면 '프로세스 영역'이다. '프로세스 영역'은 단일 프로세스를 말하지 않는다.

물론, CMMI 의 각 PA 에 대응하는 하나의 프로세스 (예를 들면 형상관리, 품질보증 등) 를 만들어 해당 CMMI 모델 Practice를 전부 만족할 수 있게 정의하고 수행할 수 있다면 좋은 방법이겠지만, 프로세스 영역에 따라서는 여러 프로세스/practice 들을 연관하여 효과적으로 조합 수행함으로써 프로세스 영역(PA)의 목적을 보다 총체적이고 효과적으로 달성할 수 있다는 사실을 간과해서는 안 될 것이다.

하지만 어디서부터 잘못된 것인지는 모르지만, 소위 프로세스 컨설팅 받았다는 조직의 프로세스들을 보면 프로세스 내에 '측정과 분석' 프로세스(?) 라는 것이 필수 프로세스인 양 자리잡고 있고, 향후 거론할 기회가 있겠지만 '문제 분석 및 해결 (Decision Analysis and resolution)' 프로세스 같은 매우 근사한(? 이름의 프로세스도 보이기까지 한다. 심지어는 프로젝트 레벨의 프로세스에도 조직의 표준 프로세스를 테일러링하다보니 그러한 프로세스들이 프로젝트 프로세스로 존재하게 되는 일이 벌어지게 되는 것이다.

'측정과 분석' 프로세스 영역은 매우 중요하면서도 재미 있는 프로세스 영역이다.

 '측정과 분석 (MA, Measurement and Analysis)' 는 CMMI Level 2 PA 이다. MA는 조직이 Level 3 를 거쳐 Level 4~5 가 되면서 모든 Level 2 PA 들이 그러하듯이 자연적으로 진화(Evolving) 되어 나가지만 그 중에서도 가장 영향을 많이 받게 되는 PA 이기도 하다. 즉, Level 2 에서는 조직의 policy 에 따라 프로젝트 레벨로 계획하고 수행하게 되겠지만, Level 3 에서는 조직의 표준 프로세스를 tailoring 하여 수행하고 그 결과를 조직에 feedback 해 돌려 주어야 하며, Level 4~5에서는 수집된 performance data 를 이용해서 프로세스 performance baseline 을 만들고 performance model 을 만들고, 프로젝트의 정량적인 관리를 해나가고, 아울러 조직 perfomance 관리 및 지속적인 프로세스 개선을 해 나가는 활동의 가장 중추적인 기능이 되는 것이다. 따라서 CMMI 에서는 향후 Level 4~5 를 염두에 둔다면 Level 2~3 추진 시에도 이 MA 에 대해 특별히 더 관심을 가지기를  당부하고 있다.

그런데, 정말로 그렇게 중요한 '측정과 분석' 프로세스가 있는게 왜 이상하단 말인가?

결론적으로 얘기하자면 전혀 이상한 건 아니다.

다만, 프로세스는 그 목적에 따라 정의되고, 효과적이고 효율적으로 운영되어야 하는데 자칫 지극히 비현실적이고 비능률적이게도 프로세스를 위한 프로세스수립의 오류에 빠질 수 있다는 점에 주의해야 한다는 것이다. 즉, CMMI 모델 및 사상을 이해하지 못하고 인증만을 염두에 두게 되는 경우에 자칫 기형적인 프로세스를 만드는 오류를 지적하고 싶은 것이다.

측정과 분석은 프로젝트 레벨과 조직 레벨의 활동으로 이원화 하여 이해되어야 한다. 즉 프로젝트 레벨에서는 CMMI Level 과 무관하게 주기적으로 프로젝트의 성과를 측정하고 분석 보고 및 프로세스 개선 활동을 해 나가게 되며, 조직 레벨에서는 프로젝트의 측정과 분석 활동을 모니터링하고 상위 관리자와 함께 이슈를 해결해 나가며 (Level 2), 조직 표준에 맞추어 프로젝트 들이 측정과 분석 활동을 하고, 그 데이터들을 조직 레벨의 측정 리파지토리에 모으고 (Level 3), 오랫동안의 수행 성과 데이터를 적극적으로 이용하여 정량적인 프로젝트 관리, 지속적인 프로세스 개선 등에 이용하게 되는 활동을 하게 되는 것이다 (Level 4~5).

따라서, 프로젝트 입장에서 쳐다 본다면, 측정 및 분석이 이루어 지는 가장 효과적인 활동은 주기적인 프로젝트 관리 활동일 것이다. 즉, 주간, 월간, 마일스톤 별로 공수, 비용, 진도, 품질 등등에 대한 데이터를 수집하여 분석 보고하고 프로젝트 수행 개선 활동을 하는 것이 통상적인 것이다. 데이터에는 각종 테스트나 검사 결과 역시 포함되며 시기적으로 수집 시기와 분석 방법들이 틀릴 뿐이며 근본적인 측정과 분석 활동에서 벗어 나지 않는다.

프로젝트의 규모, 기간, 고객 요구 사항 등등에  따라 예외의 경우도 있겠지만, 프로젝트 내에서 특별히 측정 활동과 분석 활동을 구분하여 프로세스 화 하고 독립적인 활동을 한다고 하면 뭔가 프로젝트 현실과는 멀어 보인다. 따라서, 보다 자연스럽게 측정과 분석 활동을 프로젝트 계획 (Project Planning) 활동에서 고려하고 프로젝트 수행 기간 동안의 모니터링 및 컨트롤 (Project Monitoring and Control) 활동에 자연스레 접목되어 달성될 수 있도록 하는 방법을 추천하고 싶다. 그렇게 된다면, 주기적인 주간, 월간 등의 프로젝트 관리 과정에서는 진도만 따지고, 별개의 측정과 분석 프로세스를 통해서 이원적으로 공수, 비용, 품질 관련 지표를 측정하고 분석한다는 이상한 논리에서 벗어나게 되지 않을까?

보다 효과적인 '측정과 분석' Practice 를 위하여 아래와 같은 질문을 한번 던져 보자.

프로젝트 계획에 측정과 분석의 목적을 추가하는게 현실적일지?

'의사 소통 계획'에 참석자 및 보고 회의 주기 만을 정의하고 말 것인지? 아니면 목적, 보고 내용 등을 좀 더 자세하게 정의할 것인지?

실제 측정 데이터를 기입하는 template 내에서 측정 데이터를 이용한 derived measure 들의 자동 계산을 하게 할 것인지? 아니면 분석 가이드를 자세히 정의하는게 효과적일지?

조직레벨에서는 프로젝트 레벨의 측정 및 분석 데이터를 언제, 누가, 어떻게 수집하고 검토할지?

 

CMMI 모델의 적용 및 인증심사를 위해서 각 PA 에 해당하는 프로세스가 꼭 있어야 한다는 생각의 수정이 필요하다...

 

--------------------------------------------------------------------------------------

Kim, Sungil (金成一)

SEI 공인 CMMI 인증 선임심사원, SP 품질인증 선임심사원

Live Pro-Consulting (www.LivePro.kr) 대표/대표컨설턴트

Tel) 070-4124-7522 Mobile) 010-3137-7522 Fax) 02-6280-7520

Address) 135-565 서울 강남구 역삼1동 702-10 아남 타워 빌딩 917호

Twitter: http://twitter.com/sungil  Facebook: www.facebook.com/go2hevn 

Blogs: http://blog.naver.com/go2hevn , http://sungilkim.tistory.com

--------------------------------------------------------------------------------------