역량만 있어선 안 된다… IT 프로젝트가 여전히 실패하는 8가지 이유

IT 및 비즈니스 리더의 전략적 연계에도 불구하고, 기술 및 혁신 이니셔티브는 여전히 많은 실패를 겪는다. IT 부서가 실수로부터 교훈을 얻는 방법을 소개한다.
 

IT 부서는 과거 프로젝트 운영 프로세스를 괴롭혔던 문제에서 벗어나기 위해 부단히 노력해 왔다. 이전과 같은 대규모 실패를 피하기 위해 범위 확장, 폭포수 방법론(Waterfall Methodology), 반복 개발을 위한 긴 타임라인, 애자일 접근 방식, 멀티위크 스프린트 등의 업무 방식을 도입해 왔다.

이러한 변화가 실제로 도움이 되긴 했지만, 여전히 많은 IT 프로젝트가 실패하고 있다. 

프로젝트 실패는 이제 수십 년 전처럼 IT 환경 전체를 무너뜨리는 것을 의미하지 않는다. 일반적으로 새 시스템이 작동하지 않아 완전히 폐기해야 하는 경우도 드물다. 

CIO, 프로젝트 리더, 연구원 및 IT 컨설턴트에 따르면 오늘날의 실패는 조직이 기대한 수준의 이점을 IT 프로젝트가 일부 또는 전부 제공하지 못했다는 의미에 가깝다. 실패는 프로젝트가 수익을 창출하지 못하거나, 완료 시기가 너무 늦어 쓸모없게 되거나, 참여를 유도하지 못해 사용자가 프로젝트를 외면하게 되는 것을 의미할 수도 있다.

몽클레어 주립대학의 부교수이자 프로젝트 관리 전문가(PMP)인 테 우는 “오늘날 애자일이 발전하면서 ‘실패’의 정의가 달라졌다”라고 말했다. 다시 말해 이제 IT 프로젝트 실패는 기술적 재해라기보다는 목표 시점을 놓친 것에 더 가깝다.

몇몇 연구 결과가 이를 뒷받침한다. KPMG의 ‘2023 기술 설문조사’에 따르면 미국 기술 임원 400명 중 51%가 지난 2년 동안 디지털 혁신 투자를 통해 성과나 수익성이 증가하지 않았다고 답했다. 

IT 프로젝트 실패율에 대해 일관적인 설문조사 및 연구 결과는 없지만, 많은 연구자들은 IT 프로젝트가 기대에 미치지 못하는 비율이 계속 높아지고 있다고 보고 있다. 그렇다면 무슨 일이 일어나고 있는 걸까? IT 프로젝트가 계속 실패하는 이유는 뭘까? 몇 가지 일반적인 원인을 살펴볼 수 있다. 

1. 프로젝트 관리 전문성 부족
직원들은 종종 추가 업무를 맡는다. 때로는 IT 직원이 프로젝트를 이끌어야 하는 경우도 있다. 

직원들이 프로젝트 관리자(PM) 역할을 수행한다고 해서 전문 지식, 교육 또는 경험이 제대로 갖춰진 것은 아니다. 프로젝트를 관리하거나 추가 프로젝트 관리 작업을 완수하는 데 필요한 사항을 학습할 시간도 충분히 주어지지 않는다. 

몬타나 대학의 CIO인 잭 로스밀러는 “조직은 아무 교육도 받지 않은 사람이 프로젝트를 운영할 수 있다고 기대한다. 또는 풀타임으로 다른 일을 하는 관리자에게 프로젝트 관리까지 맡기기도 한다”라고 말했다. 

로스밀러는 자신이 속한 IT 부서에서 이러한 접근 방식을 취하면 어떤 결과를 초래하는지 알고 있다고 말했다. 그는 “과거 수백 개의 서로 다른 프로젝트가 진행돼야 했을 때, 조직은 관리자가 이를 효율적으로 관리하며 운영할 것으로 기대했다. 프로젝트 관리를 전담하는 부서가 있었다면 훨씬 더 나은 성과를 거둘 수 있었을 것이다”라고 전했다. 

로스밀러는 최근 IT 부서에 프로젝트 관리자 2명을 고용해 문제를 해결하고 있다. 로스밀러는 숙련된 프로젝트 관리 전문가가 합류한 뒤 개선 효과가 나타나고 있으며, 특히 수고를 줄이고 프로젝트 배포를 더 효율적으로 하는 데 도움이 되고 있다고 설명했다. 

그는 숙련된 프로젝트 관리자가 리소스를 모으고 일정을 조정하고 직원 일정을 조율하고, 모두가 같은 방향으로 나아가도록 유도하는 데 더 능숙하며, 여러 프로젝트에 걸쳐 이를 수행할 수 있기 때문이라고 말했다. 그에 따르면 프로젝트 관리자는 프로젝트가 예상 목표를 달성하기 위해 필요한 거버넌스를 구현할 수 있으며, 범위 내 비용과 일정이 늘어나지 않도록 하는 데 더 능숙하다. 

2. 경영진의 지원이 거의 또는 전혀 없는 경우
IT 프로젝트를 방해하는 또 다른 문제는 최고 경영진의 무관심이다. 베테랑 프로젝트 리더들은 이러한 시나리오가 생각보다 자주 발생한다고 말했다.

프로젝트 관리 전문가이자 PMI의 북미 지역 운영 관리자인 칼라 아이뎀은 “회의나 프로젝트 현황 보고에서 경영진이 ‘왜 이 일을 하는가’라고 물은 적이 있다. 우리가 가려는 방향의 중요성을 제대로 이해하지 못한 것이다”라고 말했다.

아이뎀은 프로젝트에 비즈니스 스폰서가 있는 경우에도 경영진의 지원이 부족할 수 있으며, 이는 해당 프로젝트가 특정 부서의 우선순위일지라도 조직의 목표와는 일치하지 않음을 시사한다고 말했다. 

이러한 경우에는 재조정할 필요가 있다. 

그는 “경영진에게 물어봐야 할 수도 있다. ‘여러분 앞에 놓인 모든 사실을 고려할 때 이 프로젝트를 진행해야 할까요, 아니면 하지 말아야 할까요?’ 때로는 어떤 이유로 인해 진행할 수 없는 경우도 있지만, 결정을 내려야 한다”라고 말했다. 그는 경영진의 지원이 자금, 인력, 관심 자원을 확보하는 수단이기 때문에 성공에 매우 중요한 요소라고 덧붙였다. 

3. 비즈니스 스폰서의 무책임
마찬가지로 프로젝트의 스폰서가 기술 프로젝트 성공에 대한 책임을 지지 않고 IT 부서에 모든 부담을 떠넘기면 프로젝트가 실패로 끝날 수 있다.

테 우는 “훌륭한 프로젝트 리더십은 비즈니스 사례를 만들어 본 사람이 스폰서가 돼 프로젝트가 현실적으로 수행되는지 확인하고, 지지자가 돼 주는 것에서 시작한다”라고 말했다. 

경영진과 같은 비즈니스 스폰서는 프로젝트의 사업적인 이유를 명확히 하고, 예상되는 장점을 설정하고, 목표를 달성하기 위해 리소스를 모으는 데 중요한 역할을 한다. 또한 이들의 지원은 직원들에게 프로젝트 중요성을 알리는 신호가 되기 때문에, 신기술 채택과 관련 프로세스 변경을 촉진하는 데 도움이 된다고 테 우는 덧붙였다. 

4. 비즈니스 스폰서의 참여 부족
비즈니스 스폰서는 지원과 정보를 제공하며 장애물과 병목 현상을 제거하고, 문제를 제기해 신속하게 해결할 수 있도록 돕고, 성공을 지지해 앞으로의 변화에 대한 추진력과 흥미를 높일 수 있다고 아이뎀은 말했다. 

스폰서가 제 역할을 하지 않으면 이러한 이점도 사라진다. 아이뎀은 그런 일을 실제로 겪었다고 말했다. 

한때 그녀는 복잡한 다중 위치 소프트웨어 구현 작업을 꾸준히 진행하고 있었다. 다음 단계를 위해 지역 부서를 한데 모아야 했고, 스폰서의 도움을 받아야 했다. 하지만 스폰서는 문제 해결에 참여하지 않았다. 일부 운영 부서는 무슨 일이 일어나는지 알 수 없었고, 일부는 왜 참여해야 하는지 이해하지 못했다. 

아이뎀은 “정보가 순차적으로 전달되지 않고 일부 영역에서 반발이 있었다”라고 말하며, 이러한 상황이 프로젝트의 추진력을 위태롭게 했다고 전했다. 

아이뎀은 스폰서가 다른 큰 이슈로 인해 프로젝트에서 멀어졌으며, 그 결과로 관련 지역에 프로젝트 정보를 전달하는 데 제대로 주의를 기울이지 않았다고 언급했다. 그녀는 “스폰서가 프로젝트에 집중해야 할 때 다른 우선순위가 너무 많았다. 그래서 분명히 해야 했다. 조직으로서 이 프로젝트가 최우선 순위라고 분명히 말해야 했다”라고 전했다.

프로젝트가 무산되는 것을 막기 위해 아이뎀은 후원자와 더 많은 일대일 미팅을 예약해 관계를 강화했다. 또한 프로젝트 요구 사항에 대해 더 직접적으로 소통할 수 있도록 해 후원자가 다시 집중하고 프로젝트를 이어나갈 수 있도록 했다. 

5. 모든 이해관계자가 참여하지 않을 때
IT 프로젝트 관리자 크리스타 필립스는 어느 다국적 대기업이 회사 전체에 신기술을 구현했으나 진행 중인 작업을 한 부서에서 전혀 인지하지 못했던 사례를 언급했다. 특정 부서가 모든 계획 및 프로젝트 프로세스에서 제외된 사례다. 

필립스는 “프로젝트 리더가 어떻게 놓쳤는지는 모르겠지만, 한 부서를 완전히 놓쳤다. 그래서 시스템이 가동됐을 때 해당 부서 직원들은 ‘이게 뭐야’라고 생각했다. 이로 인해 프로젝트의 기회를 일부 누락했다”라고 말했다. 

필립스는 프로젝트 부서가 일반적으로 전체 부서를 간과할 일은 없지만, 프로젝트 프로세스에 포함해야 하는 이해관계자를 전부 식별하고 포함하지 못하는 경우도 있다고 말했다. 그러면 중요한 요구 사항, 고려해야 할 규정, 활용 기회를 놓칠 가능성이 있다. 필립스는 콜로라도 PMI의 파이크스 피크 지역 지부 회장을 맡고 있다.

6. 리소스가 충분하지 않거나 올바르지 않은 경우
일부 프로젝트 리더는 오늘날 IT 프로젝트가 실패하는 또 다른 이유로 ‘더 적은 비용으로 더 많은 성과를 내야 한다’는 기대치가 만연한다는 점을 꼽았다. 이 사고방식은 프로젝트 부서가 작업을 제시간에 완료하는 데 필요한 리소스를 부족하게 만든다.

필립스는 “모두 수익에 대해 신경을 기울이고 있다. 그 이면에는 소수의 사람이 많은 일을 하기를 기대하는 측면도 있다”라고 언급했다. 

필립스에 따르면 직원이 여러 프로젝트에 동시에 배정되는 경우가 많으며, 기존 업무에 더해 프로젝트 업무까지 맡는 경우도 있다. 그렇게 되면 직원들은 업무에 집중하지 못하고 여러 방향으로 끌려 다니게 된다. 

어떤 이들은 프로젝트 관리자가 성공에 필요한 비용, 인재, 시간을 과소 할당할 경우 어떤 결과가 초래되는지 잘 알고 있으면서도, 기업 리더가 비용과 작업 완료에 필요한 시간을 과소평가하거나 적절한 인재를 팀에 할당하지 않는다고 말하기도 한다(교육을 받지 않았거나 경험이 없는 직원이 업무에서 필요한 기술을 습득할 것이라고 생각한다).

노련한 프로젝트 리더들에 따르면, IT 프로젝트 관리자와 CIO는 후원자와 최고 경영진이 필요 리소스, 자원 및 일정에 대해 현실적인 정보를 얻을 수 있도록 지원해야 한다. 하지만 이는 상당히 까다로운 작업일 수 있다.

이를 위해서는 포트폴리오 관리 프로그램을 구현해 현재 진행 중인 작업에 대한 가시성을 확보하고, 리소스를 과소 할당할 수 있는 프로젝트 사일로를 허물어야 한다고 프로젝트 리더들은 조언했다. 

테 우는 “포트폴리오 관리에 중점을 두면 생산성 문제는 상당 부분 해결할 수 있다. 더 적은 일을 하면서도 제대로 해내는 것, 이것이 포트폴리오 관리의 핵심이다”라고 말했다. 

7. 대면 협업의 부족
테 우에 따르면 원격 근무로의 전환은 프로젝트 작업을 전 세계로 확장할 수 있는 가능성을 불러왔지만, 가상 업무 환경은 프로젝트 운영에 있어 몇 가지 문제점을 야기할 수 있다. 

그는 우선 조직에서 더 어려운 문제를 해결할 때 비대면 근무 부서가 모이는 데 어려움을 겪는다는 사실을 발견했다. 그는 “모듈 작업을 처리하는 데 있어서는 가상 환경이 좋다고 생각한다. 하지만 크고 복잡한 문제를 해결할 때는 ‘줌’을 통해 할 수 있는 일이 많지 않다”라고 전했다. 

그는 또한 일부 부서가 가상 업무 환경에서 유대감을 형성하는 데 어려움을 겪는 것을 봤다면서, “(비대면 근무로 인해) 인간적인 유대감을 희생하게 된다”라고 덧붙였다. 

따라서 작업 시간은 더 길어질 수 있으며, 얼굴을 맞대고 일하면 한 시간에 해결할 수 있는 문제가 가상 환경에서는 90분이 걸린다고 테 우는 말했다. 또한 팀이 물리적으로 한 공간에 있을 때는 빠르고 원활하게 진행되던 핸드오프도 가상 환경에서 조율하기에 많은 시간이 소요될 수 있다.

그는 “사람들은 동일한 효율성을 얻기 위해 더 많은 시간을 소비하고 있으며, 인간 관계가 소원해지기 시작한 것 같다”라며, 특히 신입 직원들이 롤 모델이나 본받을 만한 업무 패턴을 지켜보는 것처럼 사무실에서 이뤄지는 비공식적 멘토링 및 학습 기회를 놓칠 수 있다고 지적했다. 

그는 이러한 역학 관계로 인해 ‘협업과 소통을 위해 훨씬 더 많은 업무와 시간을 투자하는’ 프로젝트 관리자에게 더 많은 업무가 가중된다고 말했다. 이 문제에 대해 아직 해결책을 찾지 못했다고 그는 덧붙였다. 

8. 단절된 핸드오프
프로젝트가 프로덕션으로 전환되고, 프로젝트 관리자가 자리를 옮기고, IT 이니셔티브가 가치를 발휘할 것으로 기대받는 시점이 있다. 

테 우는 조직이 이 단계에 있을 경우 프로젝트와 프로젝트에 남아있는 문제가 제대로 관리되지 않으며, 이것이 책임 분담의 단절로 이어져 실패를 낳는다고 지적했다.

그는 “만약 비즈니스 사례가 한 당사자가 되고, 프로젝트 관리자가 다른 당사자를 자처하며, 프로젝트의 비즈니스 사례와는 더 멀리 떨어진, 프로젝트의 결과를 관리하는 이들이 또 다른 당사자가 된다면 연결이 얼마나 단절돼 있는지 볼 수 있다”라고 말했다. 

이러한 단절은 기회를 놓치고, 잘못된 방향으로 가고, 어긋난 의사 소통으로 이어져 최종 결과물이 차선책에 그치게 할 수 있다. 

그는 애자일과 데브옵스(DevOps) 방법론을 사용하는 조직에서도 단절은 발생할 수 있다고 언급하며 “이는 한 쪽에서 다른 쪽으로 물을 운반하는 다른 방법일 뿐이다. 데브옵스는 변화를 빠르게 처리할 수 있지만, 그 변화가 올바른 변화인지, 투자수익(ROI)을 충분히 제공하는지 여부를 확인하는 것은 다른 문제다”라고 설명했다. 

테 우를 비롯한 전문가는 이러한 상황에 대응하기 위해, 프로젝트 작업은 물론 구현 및 채택 단계 전반에 걸쳐 프로젝트의 비즈니스 사례와 결과물을 지속적으로 연결하는 관리 역량과 강력한 프로젝트 거버넌스가 필요하다고 말했다. ciokr@idg.co.kr