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

IT 프로젝트를 성공시키는 것은 생각보다 어렵다.

 

통계적으로 보면 알 수 있는데, 보스턴 컨설팅 그룹(Boston Consulting Group)의 조사에 따르면 디지털 전환 시동 중 70%가 목표 달성에 실패 했다. 이와 유사하게 '2020년 글로벌 애플리케이션 현대화 비즈니스 지표 보고서'에 따르면 구형 시스템 현대화 프로젝트를 시작했던 조직 중 74%가 이를 달성하지 못했다. 2016년에 맥킨지(Mckinsey&Co.)가 보고한 70%의 실패율과 일치한다.

프로젝트 관리 도구 서비스 기업 팀스테이지(TeamStage) IT 프로젝트의 실패율은 70%에 달한다고 한다.

일반적으로 발생하는 실패는 기한을 놓쳤거나 예산을 낭비한 경우, 혹은 결과물이 원래 목표를 달성하지 못한 경우이다.

프로젝트관리자나 해당기업 담당자는 리스크를 해결하기위해 IT측면에서 할 수 있는 모든 일을 한다. 비즈니스 요구사항 파악에 많은 시간을 할애하고, 목표 기대치를 설정 및 관리하고 범위확대를 방지 한다. 동시에 프로젝트 예산을 계속 파악한다. 여기에서 범위확대를 방지하는 이유는 설정한 목표외 외부 요청에 의해서 범위가 확대되면 이를 해결하기위한 자원낭비가 발생하여 실패로 이어질 수 있기때문이다.

하지만 문제가 IT 부서나 프로젝트팀이 아니라 사용자(이해관계자) 자체에 잇는 경우라면 어떨까?
IT 프로젝트에서 개발한 시스템을 운영하는 사용자들의 적극적인 협조가 필요한데, 반대로 저항과 반발이 높으면 프로젝트는 실패할 수 밖에 없다.

 

진행하는 프로젝트에 문제가 발생할 수 있는 이해관계자의 몇 가지 일반적인 행동을 소개하고자 한다.

 

---

IT 프로젝트가 망하는 징후 7가지

1. 회의불참
2. 부하 직원이 대신 참여
3. 사용자가 마감일을 놓칠 때
4.  주의 산만
5. 부정적 피드백
6. 다른 옵션 추가
7. 새로운 상사

 

---

 

 

 

1. 회의 불참

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

이는 이해관계자가 프로젝트에 참여하지 않는다는 신호다. 사용자와 IT 프로젝트 팀원 모두 이해관계자의 관심이 부족하다는 것을 알기 때문에 사기가 떨어지고, 프로젝트 진행 방향이 불안정하게 된다. 즉, 이해관계자의 관심이 떨어짐으로 해서 배가 산으로 갈 수 있다는 것이다.

 

2. 부하 직원이 대신 참여

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

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

 

3. 사용자가 마감일을 놓칠 때

중요한 사용자 의견과 협업이 필요한 프로젝트를 진행 중인 경우를 예로 들어본다. IT 프로젝트팀은 작업 마감일을 지키지만, 기능 테스트와 같은 작업이 사용자에게 넘어가면 지연과 마감일 누락이 반복되는 경우가 많아 프로젝트 기간이 늘어날 수 밖에 없다.

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

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

 

4. 주의 산만

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

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

 

5. 부정적 피드백

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

부정적 피드백은 빠를 수록 좋다

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

 

6. 다른 옵션 추가

사용자와 IT 프로젝트팀이 함께 시스템을 개발하는 프로젝트의 경우, 사용자는 이미 시스템을 망가뜨리고 있는경우가 있을수 있다. 바로 자체 예산을 들여 개발 중인 내부 시스템만큼 강력하지는 않지만 사용이 더 쉬운 상용 시스템을 구입하여 사용하고 있는것이다.

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

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

 

7. 새로운 상사

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

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

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

정기적으로 기본 사항을 점검하고 필요할 때 전환하기

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

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

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

 

[참조 : CIO 칼럼]