시스템 구축을 위한 필요(수) 요소...#7

오랜만의 업데이트 ...

 

=============================================================================================================================

 

1.   재무 (예산 및 비용, 집행 실적 등)

2.   조직 및 인력 (프로젝트 참여 인력 및 참여 조직, 이해당사자)

3.   요구사항 관리 (프로젝트 수행에 참여하는 현업/고객의 요구사항 관리 체계)

4.   업무 진척 및 마일스톤 (흔히 Task라 불리우는 업무 진척관리와 이에 대한 마일스톤 관리)

5.   이슈 및 리스크의 관리

6.   프로젝트 프로세스 (착수 → 수행 → 종료 → 평가)

7.   방법론 (프로젝트 관리 방법론 및 프로젝트 수행 개발 방법론)

8.   산출물

9.   의사소통

10.  프로젝트 품질 관리

11.  프로젝트 성과 관리

12. 인수이관(인수 인계)

 

오늘은 프로젝트의 품질관리에 대해서 알아보자..... 

=============================================================================================================================

 

10. 프로젝트 품질 관리

 

무척이나 쉽고도 어려운 이야기이다.

일단 업무를 수행하는 관점에서 보면, 언제나 품질에 대한 저평가를 두려워할 것이고 또한 방어를 하게 될 것이다. 반대로 업무에 대한 품질을 평가하는 입장에서 보면 향후의 시스템에 대한 안정성 혹은 프로젝트의 건전성이나 완성도를 위해 보다 많은 형태의 관리 업무나 평가 업무를 수행하게 될 것이다. 따라서 다소 공격적인 성향을 보일 수 밖에는 없는 것이다.

 

하여간 프로젝트의 품질관리는 다양한 관점(시각)에서 점검을 필요로 하는 아주 중요한 일이다.

하버드 비즈니스 스쿨에서 2003년인가 암튼 설문 조사 통계를 내놓았는데 ...적잖이 충격적인 결과였다.

내 기억에는 약 83%의 프로젝트가 (물론 IT 프로젝트를 의미한다.) 실패한다는 통계였다.

- 정확한 통계는 아닐 수도 있다. 나의 기억에 일방적으로 의지를 하다보니 -

 

실패의 사유는 무척이나 다양했고, 그리고 우리의 정서상 대충 성공이라고 부르는 몇몇 범주 역시 실패의 영역에 들어간다.

물론 비즈니스의 기본적인 환경이 틀리지만 그들의 표현을 빌면 나는 그들의 통계에 동의한다.

 

1. 납기의 지연

2. 품질의 저하 (원하는 모습의 산출물이 아님)

3. 실행의 복잡한 (만들었지만 실행하거나 수행하기에 너무나도 어렵거나 복잡한 ...)

 

뭐 더 많은 실패의 분류가 있지만 대충 저 정도로 기억이 난다.

  

보자.

납기의 지연은 당연한 이야기이고, 품질의 저하 ....

원하는 성능이 나지 않거나, 잦은 버그, 혹은 종료 이후 고도화 ....

사용자의 사용 편의성 제공의 부족 등등 ....

 

그래서 여러가지 보완 대책이 나온다.

방법론이나 프로세스, 그리고 Check List 등 다양한 방법을 동원하여 프로젝트의 완성도를 높이기 위한 노력이 진행이 된다.

 

물론 새로운 대안이 되었건 아니면 예전부터 있던 대안이 되었건 제대로 지킬 수만 있다면 프로젝트의 성공 또는 높은 품질은 보장이 된다.

문제는 이러한 다양한 방안들이 제대로 지켜지지 않음에 있는 것이다.

 

왜 지켜지지 않을까??????

 

첫번째는 기준이 없거나 있다하더라도 명확하지 않음에 있다.

 

간혹 프로젝트 수행을 위하여 고객사를 방문하여 업무를 진행하면, 프로젝트 관리 도구를 보유하지 못한 곳이 상당수 있다.

이에 프로젝트 수행자의 프로젝트 관리 도구를 사용하는데... 이는 개인적으로 보면 문제가 있다.

왜냐하면, 프로젝트 수행자의 관리도구는 프로젝트의 수행자 관점의 프로젝트 관리 도구이다. 따라서 품질에 대한 기준 역시 고객의 기준과는 상이하다.

 

품질을 유지하기 위한 기준이나 혹은 품질의 평가가 되는 기준이 다름에 그 원인도 있다.

 

그렇기 때문에 다양한 기준과 가변적인 평가가 적용이 되어야 하고, 반드시 원하는 시각이 표현이 되어야 한다.

예전에 방문을 한 인터넷 포털 업체가 있었다. 업무 수행 차 방문을 했는데 ....

 

나에게는 문화적 충격이 있었다.

그곳은 납기 보다는 프로젝트의 품질에 보다 촛점이 맞추어져 있었다.

그래서 무리한 납기보다는 품질의 저하가 있을 가능성이 있다면, 납기를 연장하거나 지연에 대한 부담이 내가 경험한 다른 곳보다 훨씬 아니 거의 없었다라고 생각했다.

 

또 다른 경험들 중 특히 SI의 프로젝트의 경우 납기의 지연은 치명적이다. 물론 돈과 직결이 되어 있으니, 비용이 발생하고 또한 약속한 기일은 비용 이상의 큰 의미를 두고 있기는 하지만....

어찌되었든지 간에 납기가 프로젝트 품질의 척도라고 해도 과언이 아니다.

 

그 이외에도 품질에 대한 많은 시각이 있겠지만, 위의 두 가지 사례만 보더라도 당연히 시각의 차이가 있다.

이러한 품질의 저하는 우선 의사소통의 부재에 있다.

다들 프로젝트의 의사소통이 잘 되고 있다고 혹은 잘 지원하고 있다고 하지만, 중요한 것은 정직한 의사소통이나 쌍방향의 의사소통이 발생하지 않을 경우가 많아서 그런 원인들이 쌓이고 쌓여서 품질의 저하를 가져온다고 할 수 있다.

 

그렇기에 그 조직에 맞는 기준에 의한 품질 관리 체계와 기준이 있는 것이 당연히 중요하다.

 

두번째는 프로세스의 준수가 힘들다는 것이다.

 

업무의 수행 중 새로운 아이디어나 혹은 새로운 기능의 추가가 발생을 한다면, 이에 대한 프로세스를 통한 추가가 이루어지지 않는다는 것이다. 일단 요구사항의 정의부터 시작해서 테스트 및 검수에 이르는 일련 과정의 프로세스를 통하여 변경이 발생해야 하지만...

그렇게 하면 예전의 유행어처럼 "어라 일이 점점 커지네 ~~~"가 된다는 것이다.

 

따라서 요구사항의 변경이 예상되는 부분이 있다거나 혹은 그에 대한 변경의 프로세스를 구성을 해야 한다는 것이다.

이를 통하여 객관적인 근거의 비용이나 납기의 기준 변경이 필요하다는 것이다. 물론 프로젝트를 수행하는 수행 업체나 조직에게는 이 부분이 가장 힘들다. 고객이 그러한 약속을 지키거나 혹은 수용하지 않을 가능성이 무척이나 크기 때문에 이러한 부분의 준수는 무척이나 힘들 수 있지만, 그래도 주장을 할 수 있거나 명문화할 수 있는 근거 정도는 만들어야 한다.

프로젝트의 변경이 발생하는 것은 어쨎거나 품질의 저하 또는 납기의 지연에 밀접한 관련이 있음을 알아야 하고, 이 때문에 발생하는 리스크가 분명히 있다는 것을 인지하고 업무를 진행해야 한다.

 

세번째, 조직 차원의 품질 관리 체계와 척도의 준비가 되어야 한다.

 

간혹 공공기관의 프로젝트 수행을 할 때에 자체적인 프로젝트 관리 도구나 방법론 또는 수행에 대한 관리 방안이 없는 곳이 많다.

결국 프로젝트 수행 업체의 주간보고나 월간보고 등 자신의 기준이 아닌 품질 체계에 대한 보고로 프로젝트의 수행을 관리하는 곳이 많는 것이다. 물론 이렇게 해서라도 관리를 한다는 것이 중요하지만, 여기에는 쓸모없는 공수나 일정이 늘어날 가능성이 있으며, 계획에 대한 수행이 없이 부딪혀서 업무를 처리하는 경우가 많을 수 있다는 것이다.

 

또한 이슈나 위험에 대한 처리 방안이나 기준 역시 문제가 될 수 있다.

따라서 조직 또는 회사에 맞는 관리 방안/도구 등등의 준비가 반드시 선행되어야 한다.

굳이 시스템이나 다른 도구의 도움을 빌지 않더라도, 조직의 기준과 품질 체계는 보유하고 프로젝트 수행에 대한 평가를 해야 한다는 것이다.

 

 

 

마지막으로 중요한 것은 수행 관점의 모니터링과 품질 관리 이후의 문제이다.

수행할 때 아무리 잘해도 운영 시 제대로 활용을 못하는 자원이 있다면 문제가 있는 것이다.

 

결국 수행에 아무런 이상을 발견하지 못하거나 설사 아주 완벽한 시스템이었다하더라도 수행 이후 즉 종료 이후 관리 체계와 품질 관리 기능을 가지고 있어야 한다.

 

하다못해 설문조사를 하건 어떤 방식을 도입하건 종료 이후 유지보수, 운영에 대한 품질 체계 역시 필요한 것이다.

유지보수나 운영은 다른 독립적인 업무나 수행이 아닌 그 프로젝트의 연장선으로 보고 해당 프로젝트 수행의 이력과 추적, 그리고 운영 상의 업무 추적과 이력관리 덧붙여 품질 관리 체계가 유기적으로 연계가 되어야 한다.

 

그렇지 않으면 결국 1년이 지난 시점 혹은 2년이 지난 시점에서는 다시금 고도화를 하거나 혹은 해당 프로젝트의 이슈가 발생하는 것은 불을 보듯 뻔한 일이다.

 

 

 

 

결국 품질 체계 혹은 품질 관리는 ALM(Application Lifecycle Management)의 관점으로 관리해야 한다는 것이다.

전반적인 생명 주기의 관리가 없다면 단편적인 프로젝트로 끝날 수 밖에는 없을 것이다.

 

이런 과정의 품질 관리 체계를 가지고 4 ~ 5년이 아닌 7 ~ 8년을 쓸 수 있는 시스템을 만들고, 연속적인 투자가 수반되는 컨설팅을 수행하고, 보다 먼 미래의 자원을 활용할 수 있는  소프트웨어, 하드웨어의 도입이 되어야 한다.

 

==========================================================================================================================

아주 오랜만의 글인데.... 쩝 ....

암튼 그간 좀 바빴었던 지라서 ...

그럼 다음에 또 휘리릭 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~