칼럼 | 비즈니스 이해관계자가 IT 프로젝트를 좌초시킬 수 있는 징후 7가지

프로젝트 실패 위험을 줄이려면 IT 리더는 사용자 및 이해관계자와 정기적으로 연락하고 프로젝트 흐름의 변화를 감지해야 한다.
 

프로젝트 관리 도구 서비스 기업 팀스테이지(TeamStage)에 따르면 IT 프로젝트의 실패율은 70%에 달하는 것으로 나타났다. 일반적으로 실패는 기한을 놓쳤거나 예산을 낭비한 경우, 혹은 결과물이 원래 목표를 달성하지 못한 경우에 나타난다. 

CIO와 프로젝트 관리자는 이런 리스크를 잘 알고 있으며, 리스크를 해결하기 위해 IT 측면에서 할 수 있는 모든 일을 한다. 비즈니스 요구 사항에 세심한 주의를 기울이고, 기대치를 설정 및 관리하고 범위 확대를 방지한다. 그리고 프로젝트 예산을 계속 파악한다.

하지만 문제가 IT 부서가 아니라 사용자 자체에 있는 경우라면 어떨까?

필자는 과거 주니어 프로그래머로 대규모 주문 입력 시스템 프로젝트에 배정받으며 첫 IT 직무를 시작했다. 당시 주문 부서의 사용자들이 새로운 시스템에 반발하기 시작했고, 프로젝트는 1년 넘게 진행됐지만 사용자의 저항이 너무 컸기에 결국 취소됐다. CIO와 프로젝트 관리자 모두 직장을 잃었다. 

주니어 프로젝트 담당자이기도 했던 필자는 무엇이 잘못됐는지 잘 몰랐지만, 사용자들의 역풍을 만나면 치명적일 수 있다는 사실을 경력 초기에 배웠다. 나중에 CIO가 됐을 때도 당시의 교훈을 마음에 새겼다.

CIO가 된 이후 사용자 및 비즈니스 관리자와 정기적으로 연락하는 업무를 맡았다. 이 업무의 일부는 프로젝트 위험을 초래하는 사용자, 특히 주요 이해관계자의 ‘징후’에 귀를 기울이는 것이었다. 

프로젝트에 문제가 있을 수 있음을 알리는 이해관계자의 몇 가지 일반적인 행동을 소개한다.

1. 회의 불참
프로젝트 회의는 전원이 참석해야 열정적으로 시작된다. 보통 프로젝트에 참여하는 사용자 영역의 관리자가 포함되지만, 시간이 지나면서 관리자는 회의에서 빠지기 시작한다. 처음에는 내부 갈등이 있다는 사실을 알려주지만 시간이 지날수록 말조차 하지 않는다. 그냥 나타나지 않는 것이다. 

이는 이해관계자가 프로젝트에 참여하지 않는다는 신호다. 사용자와 IT 직원 모두 이해관계자의 관심이 부족하다는 것을 알기 때문에 사기가 떨어지게 된다.

2. 부하 직원이 대신 참여
이해관계자와 사용자 관리자가 프로젝트에 참여하지 않는다는 또 다른 징후는 자신을 대신해 부하 직원을 회의에 보내기 시작할 때 나타난다. 회의에서는 중요한 프로젝트 결정이 나올 수밖에 없는데, 부하 직원은 대개 의사 결정권이 없다. 그는 “잘 모르겠다. 상사에게 물어보겠다”라고 말할 것이다.

회의에서 의사 결정을 내리지 못한다는 것은 회의가 제대로 이뤄지지 않는다는 의미다. 중요한 프로젝트에서 CIO나 프로젝트 관리자는 이런 일이 너무 많이 발생하도록 해서는 안 된다.

3. 사용자가 마감일을 놓칠 때
중요한 사용자 의견과 협업이 필요한 프로젝트를 진행 중인 경우를 예로 들어본다. IT 부서는 작업 마감일을 지키지만, 기능 테스트와 같은 작업이 사용자에게 넘어가면 지연과 마감일 누락이 반복될 수 있다.

주된 이유는 사용자 도메인에 더 시급하다고 판단되는 다른 우선순위가 있기 때문일 가능성이 높다. 하지만 때로는 도메인을 이끄는 이해관계자가 작업을 소홀히 하고 있다는 신호일 수 있다.

사용자가 마감일을 놓치는 패턴이 정기적으로 발생하기 시작한다면, CIO나 프로젝트 관리자가 사업부 이해관계자를 찾아가 프로젝트를 연기하거나 취소해야 하는지 물어봐야 할 때라는 의미다. 

4. 주의 산만
관리자는 많은 일을 해야 하기 때문에 프로젝트 진행을 위한 일에 집중할 수 없는 시점에 도달하는 경우가 종종 있다. 처음에 프로젝트를 과도하게 지지하거나 다른 업무에 너무 집중하게 되는 경우다.

관리자는 각 작업에 최선을 다해 우선순위를 조정하려고 하지만, 그것만으로는 충분하지 않을 수 있다. 다른 우선순위가 방해가 된다면 프로젝트를 좌초시키지 말고 일시 중지하는 것을 고려해야 한다.

5. 부정적 피드백
핵심 이해관계자가 프로젝트를 지지하며 프로젝트를 시작하고 진행하기 위해 많은 에너지를 쏟을 때 갑자기 직원으로부터 부정적인 피드백을 받을 때가 있다. 프로젝트 구성권들이 수정해야 할 사항을 발견했을 때 건설적인 비판은 당연하지만, 비판이 계속 늘어난다면 상황을 파악하고 회의를 소집해야 할 때라는 의미다.

이해관계자는 프로젝트에 대한 실망감을 직접적으로 표현하지 않으며, 그 의견이 부정적인 피드백으로 나타나는 경우가 많기 때문에 상황 파악은 빠르면 빠를수록 좋다.

6. 다른 옵션 추구
사용자와 IT 부서가 함께 시스템을 개발하는 프로젝트에 배정된 적이 있었다. 사용자는 이미 시스템을 망가뜨리고 있었다. 자체 예산을 들여 개발 중인 내부 시스템만큼 강력하지는 않지만 사용이 더 쉬운 상용 시스템을 구입한 것이었다.

IT 부서는 그때 내부 프로젝트를 중단했어야 했지만, CIO는 사용자들이 다른 시스템으로 이동한 사실을 몰랐다. 대신 사용자들은 내부 시스템에 대한 피드백을 계속 제공했고, 프로젝트는 계속 진행될 수밖에 없었다. 결국 중복되어 사실상 죽은 프로젝트가 됐다.

이상적인 상황이라면 CIO가 사용자 경영진과 긴밀하게 연락을 유지해 상용 시스템으로의 전환을 파악하고 즉시 IT 부서에 알렸어야 했다. 그랬다면 내부 시스템에 대한 추가 작업을 중단하고 IT 부서가 다음 단계로 넘어갈 수 있었을 것이다.

7. 새로운 상사
가령 IT와 사용자가 함께 구축하는 새 프로젝트가 순조롭게 진행되고 있는 상황에서 원래 이해관계자를 지지하던 관리자가 회사를 떠나고 새로운 사람이 들어오는 경우가 있다.

새로운 관리자는 내부 시스템에 관심을 두지 않고 이전 회사에서 사용하던 시스템을 선호할 수 있다. 그 경우 관리자는 자신이 익숙한 시스템을 고수하고 프로젝트를 중단시킬 가능성이 높다.

가장 좋은 방법은 관리자 및 기타 이해관계자와 상황을 정면으로 논의하며 명확한 프로젝트 방향을 합의하는 것이다.

정기적으로 기본 사항을 점검하고 필요할 때 전환하기
훌륭한 프로젝트는 IT와 최종 사용자 간의 강력한 협업과 열정, 경영진의 지지와 충분한 예산, 뛰어난 사용자 및 기술적 성과 등으로 나타난다. 전문가들은 많은 프로젝트가 실패한다고 말하지만 꼭 실패할 필요는 없다.

확실한 건 프로젝트에서 가장 쉽게 해결할 수 있는 것이 기술적인 문제라는 점이다. 사람과 관련된 문제가 더 어려우며, 대부분의 경우 프로젝트가 혜택을 줘야 하는 최종 사용자가 바로 그 사람들이다.

따라서 CIO와 IT 리더십팀은 정기적으로 사용자와 소통하고, 이해관계자의 ‘징후’를 파악하고, 변화를 감지할 때 즉시 조치를 취해 프로젝트 리스크를 줄여 나가야 한다.

* Mary Shacklett는 컨설팅 기업 트랜스월드 데이터의 대표이자 프리랜서 작가다. ciokr@idg.co.kr