큰 프로젝트를 수행할 때의 낭비는 불필요한 기능을 개발하는 낭비와 관련이 많습니다. 프로젝트 규모가 클수록 불필요한 기능이 포함될 가능성이 높기 때문입니다. 큰 프로젝트를 수행하는 낭비는 다른 유형의 낭비와 종합적으로 이해해야 합니다.
1) 필요이상의 큰 프로젝트를 수행하는 대표적인 이유는 다음의 두 가지입니다.
- 큰 프로젝트를 수행한다고 주변에 과시하고 싶은 마음이 있습니다.
보통사람들은 리더가 관리하는 조직원이 많을수록 직위 또는 파워가 높다고 생각합니다. 따라서 큰 프로젝트를 선호하는 스폰서나 프로젝트 관리자가 많습니다. 그 결과 분리하여 수행하는 것이 바람직한 프로젝트들도 통합하여 수행하게 됩니다. 때로는 프로젝트 덩치를 키우기 위해 본 프로젝트와 상관없는 다른 프로젝트를 포함하기도 합니다.
- 조직내부의 복잡한 검토 프로세스 때문에 프로젝트를 통합하여 승인받습니다.
모든 프로젝트는 투자를 수반하기 때문에 투자타당성을 사전에 검토해야 합니다. 조직의 투자타당성 검토 프로세스가 복잡하고 검토에 참여하는 경영층이 많다면, 준비해야 하는 문서가 많고 승인까지 시간이 오래 걸릴 뿐만 아니라 준비하는 과정도 힘들 것입니다. 따라서 프로젝트를 승인받는 입장에서는 가급적이면 검토회수를 줄이고자 할 것이고 그 결과 별도로 승인받을 프로젝트도 한 번에 통합하여 승인을 받게 됩니다.
2) 큰 프로젝트를 수행할 때의 낭비는 개발단계와 운영단계 모두 발생하며 다른 유형의 낭비와 복합적으로 작용합니다.
- 프로젝트 규모가 커질수록 의사소통이 복잡해지기 때문에 생산성이 낮아집니다.
프로젝트 규모가 커지면 투입인원이 많아지고, 투입인원이 많아지면 의사소통이 복잡해지고, 의사소통이 복잡해지면 의사소통을 위한 문서가 많아질 뿐 아니라 의사소통 오류로 인한 재작업의 가능성도 증가합니다. 따라서 프로젝트 규모가 커질수록 생산성이 낮아집니다. 각각 50MM로 수행할 수 있는 개발기간 6개월인 2개의 프로젝트를 통합하여 수행하면 100MM보다 많은 120MM(예)를 투입할 수 있습니다. 프로젝트 팀원을 유지한다는 전제라면 프로젝트 기간도 12개월보다 증가할 가능성이 높습니다. 12개월로 맞추기 위해서는 더 많은 MM를 투입해야 합니다.
- 프로젝트 규모가 커질수록 설익은 요구사항이 많아 요구사항 변경이 증가합니다.
프로젝트를 규모를 크게 만드는 과정에서 프로젝트가 제공할 가치를 검증하지 못한 즉 ‘설익은 요구사항’도 포함됩니다. 예를 들어 상반기, 하반기로 나누어 진행하는 것이 바람직한 프로젝트를 통합하여 진행한다면 하반기에 수행할 프로젝트는 착수시점에 불확실한 요구사항이 많을 수 있습니다. 하반기에 수행하는 것이 바람직한 프로젝트를 상반기에 진행하면 설익은 요구사항으로 인한 재작업이 발생합니다. 맛있는 과일을 먹으려면 잘 익기까지 기다려야 합니다.
- 상품개발 프로젝트의 규모가 커질수록 시장에 대응하는 속도(time to market)가 느려집니다.
프로젝트 규모가 커질수록 개발기간이 길어지기 때문에 시장에 상품을 출시하는 시점은 늦어집니다. 상품개선주기에 대한 경쟁이 심할수록 핵심기능에 집중하여 프로젝트 규모를 작게 해야 합니다.
3) 큰 프로젝트 수행의 부작용을 최소화하는 방안은 다음과 같습니다.
- 불확실성이 높은 업무의 프로젝트는 분할하여 진행하는 것이 좋습니다.
불확실한 프로젝트는 가능하면 작게 나누어 프로젝트를 진행하는 것이 바람직합니다. 적어도 2개의 프로젝트로 나누어 진행해도 실패의 가능성이 많이 낮아집니다. 왜냐하면 시행착오를 반영할 수 있는 기회가 있기 때문입니다. 프로젝트기 불확실할수록 큰 프로젝트 수행의 유혹을 뿌리치고 프로젝트를 날씬하게 만드시기 바랍니다.
- 불가피하게 큰 프로젝트를 수행해야 한다면 생산성을 보수적으로 반영하시기 바랍니다.
은행의 차세대 프로젝트, 스마트폰 개발 프로젝트처럼 큰 프로젝트를 해야 하는 상황도 많습니다. 이런 경우 소규모 프로젝트의 생산성을 반영해서는 안 됩니다. 유사한 규모의 프로젝트 생산성이 있으면 바람직하지만 믿을 만한 생산성 데이터가 중소형 규모의 프로젝트만 있다면 그것을 그대로 적용해서는 안됩니다. 중소형 프로젝트의 생산성보다는 낮은 생산성을 반영하여 프로젝트 계획을 수립하시기 바랍니다.
- 큰 규모의 프로젝트가 지연된다면 범위보다 일정을 선택합니다.
큰 규모의 프로젝트가 지연된다면 최대한 범위를 줄여서 단계별로 완료하는 것이 바람직합니다. 큰 프로젝트가 지연될 때 범위에 대한 조정을 하지 않는다면, 숨겨진 이슈를 해결하기 위해 물타기 식의 일정변경을 할 수도 있습니다. 따라서 최초 프로젝트 완료일을 준수하면서 기능완료의 우선순위를 조정하는 것이 이상적입니다. 프로젝트를 완료하기 위해서는 상호 연관된 최소한의 기능이 있을 수 있습니다. 고객관점에서 의미 있는 기능들의 집합을 정의하고 우선순위를 고려하여 단계적으로 프로젝트를 완료하는 것이 이해관계자와 프로젝트 팀 모두에 도움이 됩니다.
③ 비효율적인 프로세스를 적용하는 낭비
비효율적인 프로세스는 대부분 기획의 낭비와 무관한 개발의 낭비입니다. 상품기획 프로세스에도 비효율이 있지만 개발 프로세스의 비효율이 더 큰 낭비를 발생시킵니다. 왜냐하면 개발 프로세스와 관련된 인원이 많기 때문입니다. 개발의 낭비는 프로젝트 팀이 불필요한 작업을 수행하거나 활용도가 낮은 문서를 작성하는 활동이 대표적입니다. 비효율적인 프로세스로 인한 낭비는 앞선 설명한 낭비보다는 부작용이 작습니다. 방향보다는 속도와 관련된 낭비이기 때문입니다.
1) 비효율적인 프로세스를 적용하는 이유는 다음과 같습니다.
- 조직의 관료적인 프로세스가 프로젝트 생산성을 저하시킵니다.
조직에서 프로젝트를 수행하는 직접인력보다 프로젝트를 관리하거나 지원하는 간접인력이 많아질 때 관료적인 프로세스가 많아집니다. 품질, 보안, 법무, 재무 등의 간접부서는 프로젝트의 성공보다 각 부서의 목표달성을 중요하게 생각하기 때문에 여러 가지 복잡한 프로세스를 만들 가능성이 높습니다. 한번 만들어진 프로세스는 큰 계기가 없다면 지속되기 때문에 관료적인 프로세스는 줄어들지 않고 확대만 됩니다.
관료적인 조직의 경영층은 현장과 멀어지고 현황파악을 보고서에 의존합니다. 그렇기 때문에 프로젝트 팀은 경영층에게 프로젝트가 잘 진행되고 있다는 믿음을 제공하기 위한 보고서 작성에 많은 노력을 투입해야 합니다. 이슈가 발생했을 때 문제가 심각하지 않고 극복할 수 있다는 보고서를 작성하기 위해서는 더 많은 시간을 투입해야 합니다.
- 경영층이 프로세스로 결과를 통제할 수 있다는 환상을 가질 때 비효율적인 프로세스가 증가합니다.
프로세스가 결과에 영향을 미치는 것은 사실입니다. 그러나 프로세스에 지나치게 집착하는 것은 바람직하지 않습니다. 특히 소프트웨어 개발은 공장에서 물건을 생산하는 것과 다릅니다. 프로젝트를 수행하는 상황이나 조건을 모두 통제할 수 없기 때문에 프로세스로 결과를 통제하기 힘듭니다. 특히 소프트웨어 개발은 사람들의 협업과 개인의 창의력을 필요로 하는데, 협업과 창의력을 프로세스로 통제하는 것은 한계가 있습니다.
프로세스에 대한 신념이 강한 조직에서 이슈 프로젝트가 발생하면 재발방지 대책으로 실효성 낮은 프로세스를 추가합니다. 추가된 프로세스는 단기적으로 경각심을 가지고 적용하지만, 시간이 지나면 본질은 잊히고 왜 하는지도 모르고 수행하는 화석과 같은 프로세스가 됩니다.
결과에 대한 책임이 부담스러운 프로젝트 팀원은 복잡하고 비효율적인 프로세스를 충실하게 이행해야 합니다. 문제가 될 경우 프로세스를 준수하지 않아 이슈가 발생한 프로젝트라는 낙인이 찍힐 수 있기 때문입니다.
- 프로젝트 팀이 방법론 테일러링을 잘못하면 비효율적인 프로세스를 수행합니다.
조직에서 비효율적인 프로세스를 정의하기도 하지만 프로젝트 팀이 비효율적인 프로세스를 정의할 수도 있습니다. 프로젝트 리더가 프로젝트 상황에 적합하지 않은 프로세스에 집착할 때 이러한 현상이 발생합니다.
- 부서 간에 업무를 이관하는 방식으로 업무를 수행하면 비효율적인 프로세스가 많아집니다.
관료조직에서는 수평적인 소통보다는 수직적인 지시가 일반화되어 있기 때문에 사이로(silo) 방식으로 업무를 처리하는 경우가 많습니다. 예를 들어 디자인 부서의 인력이 프로젝트에 투입되는 것이 아니라 프로젝트 팀에서 디자인 부서에 디자인 업무를 이관하는 것입니다. 이런 부서가 많아지면 프로젝트 업무가 여러 부서를 옮겨 다닐 수 있습니다. 전문부서로 업무를 이관하는 이유는 부서업무의 전문화를 중시하는 것과 자원의 효율적인 운영을 추구하는 매트릭스 조직을 적용하기 때문입니다. 프로젝트 팀의 입장에서는 프로젝트와 관련된 모든 사람들이 한 장소에 모여서 처음부터 끝까지 프로젝트를 함께 하는 것이 바람직합니다. 그러나 조직의 입장에서는 그런 식으로 운영하면 자원이 부족하고 자원의 낭비가 발생하기 때문에 매트릭스 조직을 적용합니다.
그러나 다른 부서에 특정업무를 요청하기 위해서는 많은 문서를 작성해야 합니다. 요청하는 업무의 내용을 자세하게 정리해야 하고, 연관된 다른 업무도 문서로 작성하여 설명해야 합니다. 그렇지 않으면 관련부서에서 업무를 받지 않거나, 조직 내에서 부서 간 업무협업의 전제조건으로 정착되어 있기 때문입니다. 아무리 많은 문서를 작성해도 부서 간 업무를 이관하는 방식으로 프로젝트를 수행하면 의사소통의 오류가 증가할 수밖에 없습니다. 여러 부서로 업무를 이관하는 과정에서 지식의 누락도 발생합니다. 부서로 이관하는 과정에서는 한 장소에서 모여서 프로젝트를 수행할 때 보다 지식의 누락이 발생할 수밖에 없습니다. 왜냐하면 문서로 표현하기 힘든 지식도 많기 때문입니다. 포펜딕 부부(Mary Poppendieck, Tom Poppendieck)는 부서에서 부서로 문서를 통해 프로젝트 기획 및 개발의 지식을 이관할 때 암묵적 지식의 50%는 이관되지 못한다고 하였습니다.
2) 비효율적인 프로세스를 적용하면 프로젝트 수행과정에서 다음과 같은 낭비가 발생합니다.
- 불필요한 작업수행으로 개발 생산성이 낮아집니다.
비효율적인 프로세스 적용으로 프로젝트 개발생산성이 낮아지면 개발비용이 증가하고 개발기간도 늘어납니다. 이때 비용과 일정은 프로젝트 계획을 초과한다는 의미는 아닙니다. 프로젝트 계획을 준수하더라도 줄일 수 있는 낭비를 프로젝트 계획에 포함했다는 의미입니다. 프로세스 비효율이 조직에 만연하여 많은 사람들이 비정상을 정상으로 생각하면 개발생산성이 낮다는 생각을 못할 수도 있습니다.
비효율을 호수에 숨어 있는 바위에 비유한다면 호수의 물을 빼야 비효율을 알 수 있습니다. 호수의 물을 빼는 것은 외부환경의 변화 또는 경영층의 일관된 추진이 있을 때 가능합니다. 예를 들어 최소 6개월의 기간이 필요한 프로젝트를 4개월 만에 하려면 모든 활동을 가치창출과 연관 지어 생각해야 합니다. 프로젝트 기간을 30% 줄이지 않으면 조직이 존재할 수 없다고 생각할 때 호수의 물이 빠지고 보이지 않았던 바위가 드러납니다. 그리고 그 바위를 제거해도 프로젝트를 수행하는데 큰 지장이 없다는 것을 조직원들이 학습할 때 비효율적인 프로세스를 제거할 수 있습니다.
- 책임소재 규명을 위한 낭비가 발생합니다.
여러 부서가 나누어 업무를 수행할 때 이슈가 발생하면 책임을 회피하기 위한 갈등이 발생합니다. 조직 내에서 두 개 이상의 부서가 관련된 이슈는 과실의 비율을 정의하기 힘든 자동차의 쌍방사고와 같습니다. 조직에는 과실의 비율을 정해주는 보험회사가 없기 때문에 목소리 큰 부서가 이기는 경우가 많습니다. 목소리 큰 부서가 물론 언성을 높인다는 의미가 아닙니다. 경영층에게 자기 부서의 책임이 작거나 없다는 논리를 설명하기 위한 보고서를 작성하여 적극적으로 어필한다는 부서를 의미합니다. 그러나 책임을 따진다고 한들 발생한 이슈가 줄어들지 않습니다. 오히려 이슈해결에 대응할 시간이 책임소재 규명에 투입되는 낭비가 발생합니다.
- 조직은 활력을 잃어갑니다.
많은 조직원들이 프로세스가 비효율적이라는 것을 알면서도 그것을 수행할 때 조직의 활력은 낮아집니다. 가치 있는 일을 비효율적으로 해도 마찬가지입니다. 비효율적인 프로세스를 인체에 비유하면 나쁜 콜레스테롤과 같습니다. 나쁜 찌꺼기들이 혈액의 순환을 막듯이 비효율적인 프로세스는 의사소통을 힘들게 하여 업무스피드를 저하시킵니다. 조직이 활력을 잃으면 크지 않은 외부의 충격에도 조직은 큰 충격을 받고 회복을 못할 수도 있습니다.
3) 비효율적인 프로세스의 문제점을 줄이는 것은 힘듭니다. 왜냐하면 비효율적인 프로세스는 대부분 프로젝트 팀에서 통제할 수 없는 조직차원의 정책이기 때문입니다. 제한적이지만 비효율적인 프로세스의 낭비를 줄일 수 있는 방안은 다음과 같습니다.
- 필요할 경우에는 프로세스의 예외적용을 스폰서나 고객을 통해 요청하세요.
프로젝트 팀원도 대부분 비효율적인 프로세스에 익숙해져 있기 때문에 비효율적인 작업을 감안한 추정만 하면 개별 프로젝트에는 큰 이슈가 발생하지 않습니다. 그러나 특정 프로젝트를 진행 중이거나 착수할 때 조직에서 새로운 제도나 도구를 적용하면 문제가 달라집니다. 프로젝트 팀 입장에서는 예상하지 못했던 작업이기 때문에 혼란이 있을 수도 있고, 생산성이 예상보다 낮아질 수 있습니다. 대형 프로젝트에서는 더욱 그러합니다.
이럴 경우 프로젝트 리더는 스폰서에게 도움을 요청하시기 바랍니다. 프로젝트 리더가 나서는 것보다 스폰서가 관련부서에 예외적용을 요청하는 것이 훨씬 효과적입니다. 스폰서들은 언제, 어디에서, 어떻게 이 이슈를 논의하는 것이 효과적일지 프로젝트 리더보다 잘 알기 때문입니다. 외부 SI 프로젝트를 한다면 고객사 요청을 근거로 예외적용을 보고하는 것도 좋습니다.
- 프로세스나 적용도구의 결정 때문에 발생하는 갈등을 최소화하기 바랍니다.
프로젝트에 적용할 프로세스나 도구는 각자가 생각하는 정답이 있을 뿐입니다. 생각이 다른 팀원들이 논쟁이 심해지면 부정적인 갈등이 증폭될 수도 있습니다. 프로세스나 도구를 결정할 때 팀원 간의 갈등이 커진다면 프로젝트 리더는 이를 빨리 조정해야 합니다. 합리적인 토의로 결정할 수 없다면 리더의 권한으로 의사결정 하거나 투표를 하는 것도 좋습니다. 사람이 일을 하지 프로세스나 도구가 일을 하는 것은 아닙니다. 프로세스의 문제는 사람이 극복하지만, 사람의 문제는 프로세스가 극복하지 못합니다.
- 프로젝트 팀원은 한 장소에서 함께 근무하는 것이 좋습니다.
프로젝트 관리자는 조직의 자원효율을 고려할 필요는 없습니다. 프로젝트만 생각하면 모든 팀원들이 한 장소에서 근무하는 것이 좋습니다. 한 장소에서 소통하면 문서의 양을 줄일 수 있을 뿐 아니라 협업의 품질도 높아집니다. 프로젝트에 전담 투입할 업무량이 나오지 않아도 인건비를 부담할 수 있다면 프로젝트 팀원들이 함께 근무하는 것이 바람직합니다. 특정 인원들이 2개 이상의 프로젝트 수행을 위해 소속부서에서 근무하는 순간 소통과 협업은 어려워집니다. 연인뿐만 아니라 프로젝트 팀원들도 눈에서 멀어지면 마음도 멀어집니다. 매일 얼굴을 보면서 이야기하는 것이 좋습니다. 물론 개인 간의 성격차이로 매일 보는 것이 고역인 관계가 있을 수 있는데 그럴 때는 리더가 결단을 내려야 합니다.
지금까지 프로젝트의 낭비가 발생하는 이유, 낭비로 인한 문제점, 낭비의 예방방법을 살펴보았습니다. 프로젝트 낭비를 원하는 사람은 없지만 여러 가지 이유로 현실에서 프로젝트의 낭비는 지속적으로 발생하고 있습니다. 그만큼 낭비를 예방하거나 줄이기 힘듭니다. 불필요한 기능개발의 낭비, 큰 프로젝트의 낭비, 비효율적 프로세스의 낭비 중 불필요한 기능을 개발하는 낭비가 가장 치명적입니다. 다행하게도 프로젝트 팀이나 프로젝트 오너부서에서 통제가능한 낭비도 불필요한 기능을 개발하는 낭비입니다. 끝으로 가능하다면 모든 프로젝트는 N개의 프로젝트로 나누어 순차적으로 진행하는 것이 낭비를 줄이는데 도움이 됩니다.
