brunch

You can make anything
by writing

C.S.Lewis

by 김병호 Oct 08. 2023

프로젝트 일정지연에 대응하는 방법(2)

마지막이라는 마음으로 일정을 연기해야 합니다. 

 프로젝트 일정지연에 대응하는 방법(1)에서는 지금까지 일정지연에 대한 팀원의 관점과 일정지연의 원인을 살펴보았습니다. 지금부터는 일정지연에 대한 대응방안을 설명하겠습니다.  


일정지연의 과거, 현재, 미래를 구분해야 합니다. 

일정이 지연되는 정도는 과거, 현재, 미래로 표현할 수 있습니다. 예를 들어 다음과 같습니다. 

“8월에 완료 예정이었던 통합 테스트가 2개월 지연되어 10월에 끝났습니다.”(과거)

“8월에 완료 예정이었던 통합테스트가 아직 진행 중입니다.” (현재)

“8월에 완료 예정이었던 통합테스트가 3개월 지연되어 11월에 종료될 전망입니다.” (미래)

과거, 현재, 미래의 일정지연에서 유의할 사항은 다음과 같습니다. 


 과거에 지연된 일정지연은 미래에 따라잡기 힘듭니다. 

프로젝트 초반이라면 일정지연의 규모도 작고 남은 시간도 많아 일정지연을 만회하는 것이 상대적으로 용이하지만, 중반 이후로 넘어가면 범위를 줄이는 것 외에는 일정지연을 만회하는 확실한 방법은 없습니다. 인력을 추가해도, 잔업을 해도, 다른 도구나 방법론을 사용해도 전환비용(switching cost)때문에 일정지연 만회는 힘듭니다. 비용을 추가하여 지연된 일정을 만회하려는 전략은 성공하기 힘듭니다. 조직의 사활이 걸린 일정목표가 아니라면 현재까지의 생산성을 반영한 일정을 인정하는 것이 비용도 절감하고 프로젝트 팀원의 번 아웃도 줄일 수 있습니다. 시간은 의외로 많은 것을 해결합니다.     


 현재 지연 중인 마일스톤보다 지연 중인 작업을 파악해야 합니다. 

현재 통합테스트가 지연 중인 것은 상황을 파악하는데 도움이 되지 않습니다. 통합테스트를 구성하는 작업 중 어떤 작업들이 얼마큼 지연 중이고 무엇 때문에 지연되는지를 파악해야 합니다. 현재의 상황을 정확하게 파악해야 미래의 일정을 예측할 수 있습니다. 예를 들어 2개월 동안 통합테스트를 수행할 예정이었는데 2개월이 지난 시점에서 전제 작업의 40%를 완료했다면 4개월이 지나도 통합테스트를 끝내기 힘들 것입니다. 만일 논리적 근거 없이 안되면 되게 하라는 식으로 일정을 단축하라고 압박하면 부실한 통합테스트 실시를 유도하고, 그 결과 이해관계자들의 더 큰 불신을 초래하게 됩니다. 


 일정 단축에 대한 압박을 견뎌야 합니다. 

경영층이 현재 지연된 일정을 최대한 단축하여 프로젝트를 완료하라고 압박하는 것을 견딜 수 있어야 합니다. 특히 인력을 얼마라도 투입해도 좋으니 일정을 최대한 단축하라는 것과 같이 견디기 힘든 압박에도 다음과 같이 말할 수 있어야 합니다.


“현시점에서 인력을 추가하면 신규 인력의 업무 파악, 기존 인력들이 교육을 위해 투입하는 시간, 의사소통의 복잡성 증가 등으로 프로젝트 팀의 생산성이 낮아지기 때문에 추가인력 투입을 통해 일정을 단축하기 힘듭니다. 현재 역량이 부족한 부문에 2명만 충원하는 것이 비용과 일정측면에서 최적의 의사결정입니다.” 


다음 해에 임원 승진을 앞두고 있는 프로젝트 관리자라면 도전적인 목표를 제시할 수 있지만, 진실을 이야기한다고 해서 크게 손해를 보는 것도 아닙니다. 경영층 앞에서 자신감 없고 부정적으로 보이는 것이 두려울 수 있는데, 생각보다 별 일이 발생하지 않습니다. 합리적인 경영층이라면 말하기 힘든 진실을 논리적으로 설명하는 프로젝트 관리자를 좋게 평가합니다. 만일 진실을 이야기하는 프로젝트 관리자를 문책하는 조직이라면 향후 조직생활을 어떻게 해야 할지 고민해야 합니다. 프로젝트 관리자가 진실을 이야기했음에도 불구하고 경영층이 일정을 단축하는 방안을 추진하자고 하면 경영층의 지시를 따르면 됩니다. 그래야 목표일정을 달성했을 때 추가인력의 효과뿐만 아니라 프로젝트 팀의 일정단축을 위한 노력도 인정받을 수 있습니다. 반대로 목표일정을 달성하지 못했을 때 프로젝트 관리자 혼자만 책임지지 않습니다. 정치적으로 표현하면 ‘보험’에 가입한 것입니다.   


마지막 계획변경이라는 마음가짐으로 계획을 수립해야 합니다. 

프로젝트 일정변경이 이슈가 되어 경영층에게 보고해야 하는 상황까지 이어질 수 있습니다. 프로젝트 관리자에게는 부담이 되는 상황입니다. 회사생활에서 모든 것을 내려놓은 사람이 아니라면, 조기에 프로젝트를 정상화하겠다는 약속을 해서 부담스러운 자리를 벗어나고 싶은 충동을 느낍니다. 그러나 일정변경이 이슈가 된 상황에서는 경영층의 인식에서는 3개월 지연이나 5개월 지연이나 큰 차이가 없을 수 있습니다. 물론 비즈니스 관점에서는 큰 차이가 있지만 일정지연으로 인한 프로젝트 관리자의 평판에는 둘의 차이가 크지 않습니다. 그러나 한번 변경한 일정을 지키지 못하면 프로젝트 관리자의 평판은 회복하기 힘든 수준으로 나빠집니다. 예를 들어 3개월 연장을 약속하고 4개월에 걸쳐 완료하는 것보다 5개월 연장을 약속하고 5개월에 끝내는 것이 프로젝트 관리자에게 훨씬 좋습니다. 프로젝트 일정을 변경하지 않았으면 좋겠지만, 기왕에 변경한 것이라면 몇 개월인지 중요하지 않습니다. 변경한 일정을 반드시 지키는 것이 중요합니다. 지연된 프로젝트에서 버퍼를 반영하는 것이 비도덕적이라고 생각해서는 안됩니다. 조직을 위해서도 프로젝트 관리자를 위해서도 변경된 일정을 반드시 준수하는 것이 중요합니다. 일정을 준수하기 위해서는 어느 정도의 버퍼는 반영해야 합니다. 물론 그 버퍼를 낭비하지 않도록 프로젝트 관리자는 잘 관리해야 합니다. 


일정지연의 원인에 따라 대응전략을 다르게 해야 합니다. 

앞서 설명한 일정지연의 원인별로 일정변경의 대응전략은 다음과 같습니다. 


① 프로젝트에서 적용하는 솔루션을 변경하거나 자체개발로 전환

솔루션을 변경하는 상황은 매우 정치적입니다. 프로젝트에 적용할 솔루션을 결정한 사람이 발주자 또는 조직의 이해관계자이기 때문입니다. 도입한 솔루션의 기능이나 아키텍처상의 제약이 명확하다면 프로젝트 팀은 일정지연의 책임이 거의 없습니다. 솔루션을 변경한다는 것은 벤더사를 변경하는 것이기 때문에 기존 벤더사와 계약을  종료해야 합니다. 수행사와 벤더사가 다르다면 수행사가 고객(또는 이해관계자)과 벤더사의 중간에서 벤더사 계약종료를 위한 행정절차를 조율해야 합니다.


명확한 기술제약은 없지만, 솔루션 커스터마이징을 하기 힘든 상황도 있을 수 있습니다. 예를 들어 고객의 요구사항 중 일부가 구현되지 않거나 매우 불편하게 구현되는 경우가 이에 해당합니다. 만일 고객이 중요하게 생각하는 요구사항이 구현되지 않는다면 솔루션을 변경하거나 자체개발로 전환하는 의사결정을 할 수도 있습니다. 솔루션 변경 또는 자체개발에 대한 공감대를 형성하기 위해서는 기존 솔루션의 문제점 또는 벤더사의 역량 미흡에 대해 공개적인 비난을 하는 경우가 많습니다. 그러한 비난에 맞설 수 있는 사람은 해당 솔루션 구매를 결정한 사람입니다. 그 사람이 조직 내에서 반대의견을 이야기할 수 있는 명분을 제공하지 못한다면 솔루션 변경 또는 자체개발로 인한 일정지연의 피해는 벤더사와 수행사가 분담해야 합니다. 특히 국내 고객사들의 눈높이는 높기 때문에 솔루션 적용의 장점은 기본이고, 솔루션 적용의 한계인 UX는 자체개발과 비슷한 수준을 요구하는 경우가 많습니다. 만일 솔루션 변경의 주요 요인이 UX와 관련되어 있다면 솔루션 프로세스를 적용하는 장점을 경쟁사 또는 글로벌사의 적용 레퍼런스와 함께 설득해야 합니다. 


만일 기존 솔루션 적용을 포기하는 의사결정을 내린다면 단계별 오픈 전략을 제안하는 것이 바람직합니다. 기존 솔루션 적용을 포기하는 것은 쉬운 결정이 아니기 때문에 고객과 프로젝트 팀(수행사) 모두 지쳐 있습니다. 이런 상황에서는 개발전략의 변경이 올바른 결정이었다는 증거를 빠른 시간 내에 가시화하는 것이 중요합니다. 그러기 위해서는 핵심업무를 새로운 개발전략으로 구현하여 잘 작동하는 것을 보여줘야 합니다. 새로운 개발전략으로 업무범위 변경 없이 처음부터 모든 업무를 다시 시작하자는 것은 기름을 지고 불속으로 뛰어드는 것과 같습니다. 일단 핵심업무를 대상으로 1단계를 성공한 뒤 2단계의 적용범위를 결정하는 것이 바람직합니다. 이러한 결정에 돈을 우선시하면 잘못된 결정을 내리기 쉽습니다. 어떻게 하는 것이 프로젝트 가치를 최적화할 것인가에 집중해야 합니다. 


 ② 특정 기능 또는 성능이슈 발생  

기술적인 문제를 해결하지 못해 일정이 지연될 때에는 문제해결을 위한 업무를 별도의 프로젝트로 진행하는 것을 고려해야 합니다. 기술이슈와 무관한 업무는 먼저 진행하고, 기술이슈 해결을 위한 업무는 전문가가 별도로 강도 높게 관리하는 것이 좋습니다. 만일 해당 기술이슈가 프로젝트에 미치는 범위가 넓다면 해당 이슈를 해결할 때까지 신규 업무수행은 중단하고 프로젝트를 재정비하는 시간을 가지는 것도 고려해야 합니다. 

 

③ 달성하기 힘든 무리한 계획수립

무리한 계획수립으로 인한 일정지연은 대응이 어렵습니다. 이러한 일정지연은 팀워크붕괴, 관리부실과 함께 발생하는 경우가 많기 때문입니다. 프로젝트 착수 전에 프로젝트 관리자가 무리한 계획임을 이야기한 적이 없다면, 일정이 지연된 후에 처음부터 무리한 계획이었다고 주장해도 핑계처럼 들리기 쉽습니다. 경영층이 판단할 때에는 일정지연의 원인이 명확하지 않기 때문에 프로젝트 관리자의 역량 미흡으로 인한 일정지연으로 파악하여 프로젝트 관리자를 교체하기도 합니다. 반면에 프로젝트 팀원들은 프로젝트 관리자의 욕심 또는 무능으로 무리한 계획을 수립하여 본인들을 힘들게 만들었다고 생각합니다. 이런 상황의 프로젝트 관리자는 위와 아래 모두 신뢰를 잃어버렸기 때문에, 스스로 프로젝트 관리자 교체를 요청하는 것도 방안이 됩니다. 그렇지 않다면 프로젝트 팀원들과 협의된 일정을 경영층에 설득해야 합니다. 잔인하지만 그것이 프로젝트 관리자의 숙명입니다. 성적으로 말해야 하는 프로야구 감독과 비슷합니다. 하위팀의 체질개선이 아닌, 성적을 약속한 감독은 결과에 책임도 져야 합니다. 선수의 실력 탓을 하거나 구단의 지원 탓을 하면 안 됩니다. 


④ 요구사항 변경으로 인한 일정지연

요구사항 변경의 원인은 일정지연으로 인한 피해를 누가 책임질 것인가를 결정하고,  요구사항 변경의 내용은 일정지연 규모를 결정합니다. 그러나 고객이나 이해관계자 때문에 요구사항이 변경된 것을 프로젝트 팀이 입증하지 못한다면 비용 때문에 일정지연을 최소화하는 노력을 해야 하는 경우가 많습니다. 요구사항 변경의 책임소재에 따라 일정변경에 대한 입장이 달라지는 것은 당연하지만 무리한 일정변경을 하지 않도록 유의해야 합니다. 


프로젝트 팀에서 관리가능한 시기를 놓치지 않아야 합니다. 

요구사항 변경이나 기술이슈는 특정 이벤트가 발생하는 시점부터 일정이 지연되기 시작합니다. 그러나 무리한 일정계획 수립은 대부분 일정이 조금씩 지속적으로 지연됩니다. 가랑비에 옷 젖는 것처럼 조금씩 지속적으로 일정이 지연되면 프로젝트 팀원들은 일정지연에 대한 이슈를 식별하지 못할 수 있습니다. 외부에서 프로젝트를 방문하면 지속적인 일정지연의 문제점을 쉽게 파악합니다. 프로젝트 관리자는 외부의 시각으로 문제를 파악하고 분위기를 수습하는 시도를 해야 합니다. 냄비의 기포가 많아지는 시점을 놓치면 물처럼 갑자기 끓기 시작합니다.  


 무기력한 일정지연이 전염되지 않도록 해야 합니다. 

일정지연이 확산되어 일상화되면 일정을 지키지 못해도 팀원들은 부담이 없고 당연한 것으로 인식할 수 있습니다. 나 혼자 일정을 지키기 위해 잔업을 한다고 프로젝트가 끝나는 것도 아니고 열심히 일한 것에 대한 보상이나 인정도 없으니 열심히 업무를 수행할 필요를 느끼지 못합니다. 앞서 설명한 팀워크의 붕괴와 관리의 부실이 동시에 나타나면 무기력한 일정지연의 분위기가 프로젝트 팀 내부에 빠른 속도로 전염됩니다. 프로젝트 일정을 변경할 때에는 이미 이런 분위기가 있었거나 곧 나타날 조짐을 보이는 경우가 많습니다. 따라서 프로젝트 관리자는 일정을 변경할 때 조직 분위기도 쇄신해야 합니다. 조직 분위기를 쇄신하는 것은 일정변경의 전제조건입니다. 분위기를 쇄신하는 방법은 앞서 설명한 이번 변경한 일정은 반드시 지키자는 공감대를 얻는 것입니다. 이런 공감대는 구호나 지시로 얻을 수 없습니다. 프로젝트 관리자는 팀원들 모두와 개별면담을 하여 새로운 출발을 설명하고 스스로 프로젝트에 헌신하는 모습을 보여야 합니다.


프로젝트 진척현황을 챙길 때는 디테일하게 확인합니다. 

프로젝트 일정계획 변경 후 프로젝트 진척현황을 점검할 때에는 디테일하게 확인해야 합니다. 예를 들어 주간보고 시에 이슈가 있는 업무에 대해 밑바닥까지 프로젝트 관리자가 직접 확인하는 것이 바람직합니다. “다음 주에 캐치업(catch up)하겠습니다.”라는 식으로 보고하는 것을 직접 믿어서는 안 됩니다. 프로젝트 관리자가 디테일하게 세부사항을 확인해야 프로젝트 팀원에게는 더 이상 일정지연은 곤란하다는 메시지를 제공할 뿐만 아니라 일정지연의 진짜 원인을 파악할 수도 있습니다. 그리고 지연된 업무는 정상화될 때까지 더 자주 파악하는 방안도 고려해야 합니다. 지연된 일정을 관리할 때는 성선설보다는 성악성의 관점에서 팀원을 관리하는 것이 효과적인 경우가 많습니다. 


지금까지 일정지연의 원인과 일정지연에 대응하는 방법을 설명했습니다. 일정지연에 대응하는 핵심은 팀원의 동기부여입니다. 일정지연 없이 프로젝트를  끝내면 좋겠지만 쉽지 않습니다. 일정지연을 최소화하기 위해서는 팀원들의 마음관리가 중요합니다. 팀원들의 마음을 얻지 못하면 변경된 일정준수가 어려워집니다. 프로젝트 관리자의 다그침으로 일정관리의 효과를 보는 것은 아주 잠깐 일시적일 뿐입니다.  일정지연의 원인에 적합한 일정관리 전략을 수립하되,   일정을 변경할 때에는 마지막이라는 마음가짐으로 변경하시기 바랍니다. 


https://brunch.co.kr/@kbhpmp/160


매거진의 이전글 프로젝트 일정지연에 대응하는 방법(1)
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari