IT프로젝트가 실패하는 이유와 사례

 

IT 프로젝트 실패 사유

Standish Group  Chaos Report에 따르면 전 세계 프로젝트의 83.9% 가 실패한다고 합니다. standish group은

1994년부터 프로젝트의 성공과 실패에 대한 분석 리포트를 내고 있는데, 1994년부터 현재까지 이 실패율은 크게 변화가 없다고 합니다.

물론 그 안에서 프로젝트의 성공과 실패에 영향을 주는 요인들은 변화가 있지만요.
(Standish Group Chaos Report 정규 리포트는 비싸서(?) 원문을 받아보지는 못했고, 여기저기에서 리뷰해 놓은 것을 참고하였습니다.)

아래는 OpenDoor라는 회사 홈페이지에서 가져온 IT 프로젝트의 주요 실패 요인입니다. 

1. 불완전한 요구 사항
2. 사용자 참여 부족
3. 자원 부족
4. 비현실적인 기대
5. 경영진 지원 부족
6. 요구 사항 및 사양 변경
7. 계획 부족
8. 더 이상 필요하지 않았다
9. IT 관리 부족
10. 기술 문맹

출처: https://www.opendoorerp.com/the-standish-group-report-83-9-of-it-projects-partially-or-comp letely-fail/

Save Your IT Project - Standish Group Reports 83.9% Fail | Open Door

제가 진행하는 프로젝트는 아니지만, 같은 TF에 속한 직원이 맡아 진행하는 프로젝트가 있어서 프로젝트에 주간보고에 참여하는 건이 있습니다. 해당 직원이 관리 쪽 일만 했는지라 도움을 요청한 것인데요. 이 프로젝트를 예시로 이야기해 보려고 합니다.

프로젝트의 개요

이 프로젝트는 사내 여러 개 백오피스 시스템에서 데이터를 수집하여, 시계열 데이터를 시각화하여 보여주고, 데이터 추이 분석해주는 시스템입니다. (약칭 A시스템이라고 하겠습니다.) 운영자의 검증에 대한 부담을 줄이고, 오과금, 오정산을 사전에 (혹은 최대한 빠른 시간 내에) 발견하는 것에 목적이 있습니다.
지난 몇 년 동안 비슷한 시스템을 여러 번 만들었는데, 모두 기존 운영자의 니즈에 맞지 않아서, 흐지부지 없어졌습니다.
이번에는 뭔가 다를까 싶었는데, 분위기가 좋게 흘러가지는 않네요.

프로젝트 상황

저는 프로젝트 중반 이후에 주간보고에 참석하게 되었습니다.
처음 디자인 시안을 보았는데, 대학생이 홈페이지 만든 건가?라는 생각이 들 정도로 조악했습니다.
디자인이 세련되고 촌스럽고의 문제가 아니라 어떤 데이터를 어떻게 담아야 할지에 대한 고민이 전혀 담겨있지 않다고 느꼈습니다.

데이터 아키텍처도 잘못 설계된 것으로 보입니다. 스무 개 가까운 원천  시스템에서 연동받는 데이터 형식이 전부 다릅니다. 이에 따라 UI에서 보여주는 데이터도 업무마다 다르게 구성되었고, 원천시스템 변경이 있으면 같이 변경이 되어야 하는 구조입니다. 업무 특성에 따라 일부 예외 처리하는 부분은 늘 있지만, 기본적인 공통화는 되어야 유지보수에 불필요한 리소스 낭비가 없습니다.

처음에 연동 데이터를 어떻게 구성할지 감을 못 잡고 있어서, 대략 아래와 같이 데이터를 받아서, 항목 분류별로 항목 명의 값을 가지고 라인 그래프를 그리는 것을 추천했는데요. 이런 식으로 구성해야 원천시스템에 변경이 있어도 우리 쪽 수정 없이 진행이 가능하기 때문입니다.

SEQ	항목분류1	항목분류2	항목명1	항목명2	값1	값2
2022-10-28	고객유형	상품코드	개인	전기밥솥	100	200

그런데, 결국 구현된 건 아래와 같은 방식인 것 같더군요. 이러면 원천 시스템에 새로운 항목이 추가될 때마다 칼럼이 추가가 되어야 합니다. 수백 개 항목이 있다면 수백 개 칼럼이 필요하고요. 

SEQ	개인	전기밥솥
2022-10-28	100	200

그리고 데이터 자체도 원천 데이터를 그대로 가져오는 것이 아니라 A시스템에서 그래프 그리기 좋게 운영자들이 통계를 내서 포맷을 맞춰 주어야 합니다. 운영자의 부담을 줄여줘야 되는데, 일을 늘려주고 있으니.. 누군가 강제로 모니터링하면서 독촉하지 않으면 이 시스템이 운영이 될까요? 운영자들이 어차피 통계를 내야 되는 것이면, 그냥 직접 보면 되는데요. 

오픈이 한 달 이상 지연되면서도 오픈 전날까지도 자잘한 버그가 많았고, 안정화 기간으로 잡은 한 달간 추가 수정을 해서 간신히 돌아가는 모양새만 만들었습니다. 가장 문제는 이 시스템이 완성되어도 실제 운영자들이 사용할까? 의문이 생긴다는 거죠.

728x90

 

왜 이렇게 되었을까??

왜 이렇게 되었을까요? 위에서 열거한 프로젝트 실패 이유 중 해당되는 것은 다음과 같이 여섯 가지입니다.
해당하지 않는다고 생각한 나머지도 제가 몰라서 그렇지 해당되는지도 모르겠습니다.

1. 불완전한 요구 사항
2. 사용자 참여 부족
6. 요구 사항 및 사양 변경
7. 계획 부족
9. IT 관리 부족
10. 기술 문맹

하나씩 살펴보겠습니다.

1. 불완전한 요구 사항, 6. 요구 사항 및 사양 변경

이 프로젝트의 오너는 지난 몇 번의 실패를 알고 있었기 때문에, 실제 운영자에게 도움이 되고, 유용하게 사용할 수 있는 시스템을 만들기 원했습니다. 그래서 운영팀 인터뷰를 하고, 요구사항을 받아서 거기에 맞게 시스템을 만들어야 했는데요. PO가 IT 전략을 담당하는 부서였기 때문에(저처럼 도메인 기반으로 일을 하는 BA가 아닌 진짜 전략만 담당) 이 과정을 프로젝트팀이 주도해야 했습니다. PO는 사실상 돈만 댄 거였죠.

그런데, 운영팀 인터뷰를 해보니, 모두의 요구사항이 각기 다르고, 이것을 어떻게 시각화하느냐에 대해서도 이견이 갈리는데, 이것을 PM이 정리하지 못했습니다. 기존에 사장된 시스템의 Pain Point가 무엇이었는지 알고, 프로젝트의 취지를 이해했다면 좀 달랐을까 싶은데요. 운영팀에 넌지시 물어보니, 본인들이 요구하는 요구사항은 다 불가능하다고 했다고 하더군요. 

상황이 이러면, 다른 누구라도 나서서 정리해야 하는데, 이것을 아무도 하지 않았습니다. 설계과정에서 여러 가지 의견이 나왔지만, 요구사항으로 확정되지 않고, 불만만 늘어놓는 수준이었고, 대안이 없었습니다. 결국 요구사항은 개발 시안이 나올 때마다 변경되는 최악의 상황이 되었습니다.

2. 사용자 참여 부족

운영자들은 본인들이 원하는 요구사항이 받아들여지지 않으니, 바로 수동적으로 변했습니다. 이미 실패했던 이전의 유사 프로젝트처럼 공들여봐야 의미 없다고 생각한 거죠. 데이터 제공 등 모든 일정이 후순위로 밀리면서 프로젝트도 지연이 되기 시작합니다.

7. 계획 부족

주간보고에 참석한 이후 모든 일정이 제대로 지켜진 것이 없었습니다.
프로젝트 상황은 늘 변하고, 계획이라는 것은 지킬 수 있을 때 의미가 있는 것이라서 기한이 임박하기 전까지는 러프하게, 기한이 임박할수록 상세하게 계획을 세워야 한다고 생각합니다. 더구나, 이번처럼 짧은 프로젝트면 대략적인 마일스톤만 정하고 나머지는 그때그때 상황에 맞춰 움직이면 된다고 생각하는데요. 그럼에도 불구하고, 개발 관리 측면에서 계획이 아주 없을 수는 없습니다. (그냥 풀어놓으면 누가 일을 하나요?) 하지만, 모든 계획이 다 맞지 않는 것은 어떻게 받아들여야 할지 모르겠더군요. 

9. IT 관리 부족

위에서 언급한 "Standish Group Chaos Report 2020"에서는 사실 PM의 능력이 프로젝트의 성공과 크게 관련이 없다고 하고 있습니다.

위 표를 보면 고도의 스킬을 가진 PM은 프로젝트의 23%만 성공했는데, 스킬이 보잘것없는 PM은 58%가 성공했다고 합니다. 프로젝트 관리자가 관리를 열심히 할수록 개발에 불필요한 오버헤드가 발생되고, 의사결정이 늦어져서 프로젝트가 실패로 갈 확률이 높아지기 때문이라고 하는데요. 그래서 프로젝트 관리자의 능력이 중요하지 않다는 것이죠. 엄밀히 말하면 능력의 유무보다는 부지런한 프로젝트 관리자가 프로젝트를 망친다고 볼 수 있겠네요. 1999년 리포트에서 프로젝트 관리가 성공의 핵심이라고 언급된 이래, 쭉 변경이 없다가 2020년에 이에 대한 판단을 뒤집은 부분입니다. 

저도 이 부분에 동의하고, 늘 그렇게 생각해왔는데요.

이 프로젝트는 반대로 IT 관리 부족이 실패의 큰 원인이라고 생각됩니다.
어떤 면에서 IT 관리가 부족했는지 생각해보겠습니다.

첫째, 수동적인 태도
프로젝트팀이 수동적인 태도로 업무를 진행했습니다. 물론 사업부서가 요구사항을 최대한 구체적이고 논리적으로 만들어 줘야 하지만, 애초에 설계를 해주는 것이 아니기 때문에 어느 정도는 주도적으로 업무를 진행하는 것이 필요합니다. 이 프로젝트의 목적을 달성하기 위해서 어떤 기능이 필요하고, 개발은 어떻게 진행되고 향후 운영단계에서는 어떻게 할 것인지에 대해 큰 고민 없이 그야말로 대충하고 있었습니다. 화면 시연을 하면서부터는 PM이 시스템에 대해 모든 걸 알고 있어야 하는데, 어떤 기능을 보여달라고 하면, 그 기능이 어디 있는지 찾는데, 한참이 걸립니다. 메뉴 depth가 깊은 것도 아니고, 3단계 정도인데, 그러는 것이고요. 외부자인 저도 몇 번 들어가 본 것만으로 파악한 버그들을 PM이 인지도 못하고 있다는 것도 황당하고요.

둘째, 커뮤니케이션 불가능
소통 능력이 부족한 게 아니라, 소통이 불가능한 벽에 대고 말하는 기분이었습니다. 주간회의 시간에 이러이러한 의견을 제시하면, 프로젝트팀은 늘 알겠다고 하고, 확인해보겠다. 다음 주 까지 하겠다고 했는데, 다음 주에도 전 주와 같은 상태였고, 전 주에 말했던 내용을 기억을 못 하는 경우도 많았습니다. 회의시간에 나온 의견들을 이해하는지에 대해서도 의문이 들고, 회의 분위기는 점점 더 안 좋아졌습니다.

10. 기술 문맹

문맹이라고 까지는 그렇지만, 추이를 보기 위해서는 단순하게 라인 그래프만 그리면 아쉽습니다.
임계치 설정도 단순하게 전 달 대비 몇% 초과/미만 같은 식으로는 제대로 분석이 어렵습니다.

그래서 통계적인 지표를 사용을 해야 하는데, 차트용 라이브러리 중에서 그런 지표를 추가로 그려주는 것을 사용하라고 했는데, 결국 단순 라인 그래프를 그리는 라이브러리만 썼고, 그나마 우겨서 이동평균선만 추가로 그려 넣게 되었습니다. 이런 것이 왜 필요한지, 어떻게 구현하는지에 대한 이해가 없으니, 수준이 낮은 결과 물이 나올 수밖에 없었습니다.

그리고 요즘은 다 반응형 웹인데, 그것도 잘 안되었습니다. 지금은 레이아웃은 화면에 맞춰지는데, 폰트 사이즈가 그대로라 보기에 여전히 좋지는 않습니다.

결국...

결국 프로젝트 오픈 일에 오픈도 못하는 사태가 벌어졌고,  해당 PM의 팀장이 직접 개입한 후에야
진척이 되기 시작했습니다. 어찌어찌 돌아가는 상태는 되었습니다만, 지속적으로 유지보수해서 운영하고 사용될 시스템인지 저는 의문을 가지고 있습니다.

마무리

모든 프로젝트는 상황이 다릅니다.

프로젝트팀이 의욕에 넘쳐서 적극적으로 의견 개진하고, 스스로 틀린 것을 고쳐가면서 진행하고 있을 때는 관리자는 가만히 있는 게 도와주는 것입니다. 불필요하게 나서서 일을 만들거나 사기만 떨어트릴 수 있습니다. 관리자는 가끔씩 맥만 짚어주고, 진행사항 체크만 하면 됩니다.

하지만, 프로젝트가 제대로 돌아가지 않을 가능성이 있다고 느껴질 때는 적극적으로 개입을 하는 것이 맞습니다.

위의 실패 원인과 사례에 대해 깊이 고민해보시고, 모두 성공적인 프로젝트를 진행하시길 바라겠습니다.