IT프로젝트에서 흔히하는 실수(1)-계획따로,실행따로

IT에세이

프로젝트를 숱하게 해 오면서 IT프로젝트를 하는 사람들이 반복하는 행태가 있다.

프로젝트 진행과정에서 이슈와 리스크를 따로 관리하고 해결한다지만, 결국 '사람'이 하는 일이기 때문에 '누가', '어떤 방식'으로 일하냐에 따라 이슈나 리스크가 아예 생기지 않을 수도 있고, 설사 생겨도 빠르고 효과적으로 해결하기도 한다.

'사람'이라고 표현했으나, '실력'도 필요하지만 올바른 '태도'가 더 중요하다. 일반적으로 합리적인 사고를 할 줄 아는 리더 몇 명만 있어도 프로젝트는 상당히 순항을 한다. 몇 번 언급한 적이 있듯이, 시작과 끝이 있는 기간에서 다양한 사람이 모여 결과물을 만들어내야 하므로 리더십이 그 어떤 조직보다 중요하다.

F프로젝트 워크숍에서 '프로젝트 점검에 따른 개선 Point'라는 제목으로 발표를 하였는데, 가장 마지막 장은 나의 경험으로 뽑은 '프로젝트 참여자들에게 당부하고 싶은 7가지'를 특별히 추가했다.

이 앞 프로젝트에서도 비슷한 발표 요청을 받았을 때 고심해서 7가지 당부사항을 정리했는데 이를 아주 약간 손봤다.

신기하게도 매 프로젝트마다 사람들이 반복하는 행동들이며 이런 태도만 고쳐도 프로젝트는 큰 문제없이 잘 진행된다.

<IT프로젝트 참여자들에게 말하고 싶은 7가지 당부> 중 이번 글은 첫 번째인

"계획 따로, 실행 따로는 목적 없는 여행이다."에 대해서 쓰고자 한다.

어느 기업이건 프로젝트를 발주하기 전, 길게는 몇 년 정도 준비작업을 거친다. 시장동향, 경쟁사와의 차별성, 기업 및 시스템의 미래 가치 등 많은 것을 고려하여 프로젝트의 방향, 목적, 비용, 일정을 결정한다.

하지만 발주와 계약은 여러 행정적인 절차도 함께 따르므로 일정을 준수하기 어렵다. 프로젝트 로드맵을 수립했지만 계약이 늘어져서 프로젝트 착수일이 늦어지게 되는 경우가 비일비재하다.

이럴 때 전체 프로젝트 기간이 순연되면 좋으련만, 일반적으로는 오픈일은 변동을 하지 않으므로 전체 기간이 줄어든다.

가장 많이 줄이는 기간이 초반 분석/설계와 테스트 단계이며, 많은 경우 단계를 오버랩해서 프로젝트 관리의 복잡성을 확 높여버린다. 

프로젝트를 시작했다고 해서 바로 일을 착수할 수 있는 게 아니라, 각종 계획 및 방안 수립, 가이드 작성, 절차 셋업이 필요하다. 아무리 정교하게 준비해도 실제로 해 보면 현실상황과 차이가 나기 때문에 현실세계에서는 계획과 방안에 대해 보완이 필요하다.

프로젝트 초기 정한 역할도 실전에 들어가 보면 grey area가 있어서 팀/사람별 역할 조정, 추가 인력 투입이 빈번히 일어난다.

계약 때문에 착수부터 일정이 밀리고, 프로젝트 초기 setup과 동시에 바로 일을 시작해야 하다 보니 불가피하게 '계획'과 '실행'은 따로 놀기 시작한다. 

관리가 투명할 경우, 이 둘 간의 gap이 공유/보고가 되므로 해결방법을 찾게 되고 시간이 갈수록 이 gap은 줄어들게 된다.

하지만 아쉽게도 프로젝트 참여자들은 '계획'에 관심이 없다. 특히 전체 계획은 더욱 관심이 없다. 

새로 투입된 프로젝트에서 적응도 해야 하고, 나 혼자 하기 어려운 일들이 산재해 있다 보니, 다른 일을 신경 쓸 겨를 없이 '일단 내 눈앞의 불부터 끈다.' 선후관계가 있는 일들은 선행 Task지연으로 후속 Task가 지연되는 연쇄반응마저 생긴다.

이때 계획에 대한 검증 없이 진행을 하고, 관리의 누수가 생기면 어디에서 어떤 문제가 발생하는지 알 수가 없다.

무엇보다 계획서 상에는 이미 끝난 일인데, 실제로는 아직도 하고 있으면서, 보고에도 해당 내용을 누락을 하거나 축소를 하면 점차 사람들이

이런 현상에 대해 '어쩔 수 없다'며 '무감각'해 진다.

프로젝트에서의 주간보고는 그냥 보고가 아니다. 일주일 간 계획대로 진행을 했는지, 다음 일주일간 어떤 계획이 예정되어 있는지를 중심으로 많은 논의를 한다.

그런데 이 자리가 '하고 있습니다. 특이사항 없습니다. 일부 지연은 있으나 critical 한 문제는 아닙니다'는 말만 하게 되면, 시간낭비는 둘째치고 통합테스트 단계에 모든 문제가 다 터진다.

테스트 단계인데, 실제로는 설계, 개발, 단위테스트, 통합테스트를 동시에 하면서 여전히 '어쩔 수 없다'라고 생각한다. 이미  '관리'나 '통제'의 범위를 넘어섰기 때문이며, 결국 오픈에 심각한 영향을 미친다.

프로젝트 수행계획서, 각 단계별 수행방안, 프로젝트 관리방안, WBS, 각 테스트 계획서, 이행계획서 등을 한두 명에게 맡기는 경우가 많다.

과거했던 산출물을 참조해서 만들고, 이를 별다른 검증 없이 사용한다면 '계획'따로 '실행'따로는 당연한 결과다.

계획과 방안 수립은  그 담당자만 해야 할 일이 아니다. 다 함께 이 프로젝트에 적합한 '전략'을 고민해 보라는 것이다.

이 프로젝트만의 특징이 있고, 제약사항이 있으므로 거기에 걸맞은 전략을 고민한 계획을 세워야 실행할 때도 현실감이 있다.

아직도 빈번히 하는 두 가지 행태가,

첫째, 큰 고민 없이 이전 계획서를 가져다 재활용하는 것과, 둘째, 계획에 대해 이해하려는 노력 없이 과거했던 관행대로 일하는 모습이다.

프로젝트 진단 시, 건강한 프로젝트를 위해 집요하게 파고드는 점이 '계획점검'과 '계획대로 했느냐'이다.  '사람'이 바뀌지 않으면 진정한 문제해결은 되지 않는다.

그래서 프로젝트 진단의 핵심은 결국 사람의 진단으로 향하고 '일하는 방식의 변화'를 요구하게  된다.

계획을 무시하고 기존 관행대로 일을 하면, 그 끝은 목적을 상실한 여행임을 잊지 말자.

*계획관리 관련 몇 가지 Tip

1. 계획, 방안은 draft를 만들고 나면 각 영역의 리더가 모여 선후관계에 대한 검증을 해야 한다.

이때 일정 align은 반드시 해야 하고, sub milestone 차원의 추가  task를 전략적으로 추가하여야 한다.

2. WBS작성 시 가장 이상적인 task 길이는 2주이다. 설계, 개발, 테스트 등 대량 공정관리가 필요한 task에서 의미 없이 task를 세분화하고 숫자를 붙이는 경향이 있는데,  이런 방식보다 논리적 그룹으로  task를 분류하고 이를 계량화 하는 전략이 훨씬 효과적이다.

3. 단위테스트의 경우 단기 목표에 따라 task를 세분화하면 품질 향상에 효과적이다. 긴 기간 동안 단위테스트한 줄의 task가 있으면 일정이 경과함에 따른 프로그램 소스의 시점차가 생겨 단위테스트 끝날 무렵 많은 문제가 발생한다.

단위테스트 후반부 Regression test의 의미를 가진 task를 추가하는 등의 전략이 필요하다.

4. 대형 프로젝트는 기간이 긴데도 초기 정의한 WBS를 그대로 사용하는 경우가 많다.

매 단계시작 전 이후 단계의 WBS 점검을 통해 계획 정교화 작업을 거쳐야 한다.

반드시 금지해야 할 것은 Task 삭제와 Task 기간 연장. 이 두 가지는 철저한 통제하에 이루어져야 한다.

---

https://blog.naver.com/jykang73/222908863825