무엇이 IT조직을 실패하게 만들까? 때론 어설프게 알았던, 또는 업무에 절대 도입하지 말았어야 할 이른바 '업계 베스트 프랙티스'를 도입한 것이 원인인 때가 종종 있다.
내부 고객이라는 인식부터 차지백 제도 도입, ROI에 대한 주장까지 ‘멀리서’ 바라보면 그럴듯한 조언들이 존재한다. 그러나 ‘속’을 들여 보면, IT의 성공을 보장하는 것이 아니라 실패로 이어지는 때가 많은 조언들이다.
1. 모든 사람에게 고객이라고 말한다
실패하는 방법은 간단하다. IT부서의 모든 사람들이 IT 외부사람 모두에게 “당신은 우리 고객이다. 당신의 기대를 뛰어넘는 것이 우리가 할 일이다. 당신을 행복하게 만드는 것이다”라고 말하도록 만들면 된다.
IT외 부서의 직원들은 IT의 고객이 아니다. 회사를 위해 IT가 동등하게 협력해야 하는 IT의 동료들이다.
내부 고객이라는 개념을 정당화 하면 IT는 부수적인 위치에 놓이게 된다. 다른 사업부의 직원들이 회사 사업에 도움이 되지 않아도, 더 나아가 고객들이 더 많은 제품과 서비스를 구입하도록 유도하지 못하는 경우에도 동료들을 만족시켜야 하는 위치에 놓이게 되는 것이다.
2. SLA를 만들어 ‘계약서’처럼 취급한다
실패하는 방법은 또 있다. SLA(Service Level Agreement)를 만들어, ‘내부 고객’들에게 서명하도록 만든 후 계약서처럼 취급한다. 그리고 매번 IT가 SLA를 충족했다고 주장하는 것이다.
그러면 ‘내부 고객’들은 IT가 해야 할 일을 하지 않는다고 말하기 시작할 것이다. 이는 관계를 소원하게 만드는 지름길이다.
성공하고 싶다면 관계에는 신뢰가 필요하고, 신뢰를 쌓기 위해서는 동료를 존중해야 한다는 점을 명심해야 한다. 동료가 IT를 좋아해야, 서로 협력해 문제를 해결할 수 있다. 계약은 관계 정립이 목적이 아니다. 신뢰가 없고, 심각한 문제가 발생했을 때 취할 조치를 규정하는 것이 목적이다.
3. ‘내부 사용자’를 조롱한다
잘 알고 있는 내용일 것이다. “다시 확실히 설명해 드리겠습니다. 정전 때문에 부팅이 되지 않는 것입니다. 모르겠어요?”, “그 바보 같은 사람이 프린터 3상 플러그를 반대로 삽입했지 뭐야!(동료들의 낄낄거리는 비웃음)”
다른 IT직원들이 (특히 이름까지 구체적으로 언급하며) 다른 부서 동료들을 비웃을 때 동참하라. 아니 더 확실히 실패하고 싶다면, 직접 다른 부서 동료를 면전에서 비웃기 바란다. 그러면 IT부서 사람들은 하나 같이 다른 부서 사람들을 존중하지 않는다는 말이 퍼져 나갈 것이다. 이 또한 쉽게 실패할 수 있는 방법이다.
4. 차지백(Charge-backs)을 실시한다
정보기술을 사용하지 못하도록 유도하는 좋은 방법이 있다. 차지백을 실시하는 것이다. 그냥 차지백이 아니다. CPU 사이클부터 SAN, NAS 스토리지(당연히 분리), 개발자 작업시간, 헬프 데스크 지원까지 모든 비용 중심에서 발생하는 비용을 10분 단위로 상세히 항목 별로 청구하는 차지백을 만든다.
이렇게 하면 협력이 사라진다. 청구 내용이 정확한지, 청구 비용을 책임질 부서가 누구인지를 놓고 논쟁을 벌이게 될 것이다.
5. ROI를 고집한다
아주 중요한 프로젝트에 자금이 투입되지 않도록 만들면 IT는 이내 실패할 수 있다. 그리고 이에 도달하는 방법은 간단하다. IT거버넌스 프로세스에 명확하고 가시적인 투자 수익이 보장되어야 한다고 주장하면 된다.
이렇게 하면 손쉽게 시대에 뒤쳐질 것이다. 비즈니스 부서가 더 빨리 성과를 내도록 도와주는 기술에 예산이 투입되지 않도록 만들고, IT는 입증할 수 없는 영업 측면의 비용을 줄이는 한편, 장기적으로 매출을 증대 시키고 고객 만족을 견인하는 프로젝트들이 뒷전으로 밀릴 것이다.
6. IT프로젝트를 비호한다
비즈니스와 IT부서가 삐걱거리도록 만들고 싶은가? 프로젝트의 결과물을 소프트웨어 전달로 규정하면 된다. 즉 소프트웨어가 요구사항과 사양(명세서)을 충족하면 IT의 할 일이 끝나는 것이다.
이렇게 하면, 비즈니스 부서 관리자가 소프트웨어가 필요한 기능을 제공하지 않는다고 불평할 때, 사양을 충족하기 때문에 소프트웨어에는 아무 문제가 없다고 주장할 수 있다. 또 프로젝트가 요구 사항을 충족하지 않을 경우, 요구 사항이 잘못되었다고 주장할 수 있다. 누구의 잘못이냐고? 당연히 프로젝트를 승인한 비즈니스 부서 관리자의 잘못이다.
이러한 사태를 피하고자 한다면 효과가 있는 방법을 실천할 수도 있다. 프로젝트 명칭부터 시작한다. 그리고 소프트웨어가 아닌 비즈니스 성과를 규정한다. 세일즈포스닷컴(Salesforce.com) 구현 대신 영업 효과 향상 등을 결과물로 규정하는 것이다.
7. 프로젝트 스폰서(후원자)를 지정한다
프로젝트 관리 분야 종사자들은 프로젝트가 성공하기 위해서는 비즈니스 부문에 후원자가 있어야 한다는 점을 잘 알고 있다. 그렇다면 프로젝트 실패를 초래하는 방법은 무엇일까? 스폰서 한 명을 지정하는 것이다.
SINO(이름 뿐인 스폰서)가 아닌 진짜 스폰서는 진심으로 프로젝트가 성공하기 원하고, 프로젝트를 성공시키기 위해 필요한 모든 위험을 감수할 의지를 갖고 있다. 또 프로젝트가 비즈니스에 제공할 혜택에 자신의 이름과 평판을 건다. 그런데 스폰서로 지정된 사람 중에 이런 사람이 생각나는가?
8. 클라우드 컴퓨팅 전략을 수립한다
IT가 실패하는 또 다른 방법은 클라우드 컴퓨팅 전략을 수립하는 것이다. 어찌됐든 클라우드를 추구해야 한다. 그러니, 문제가 되는 클라우드 전략의 목표는 그저 클라우드 구현이다.
이보다 넓게 생각하지 않는다. 서비스 측면에서 관리형 기술 아키텍처를 고려하지 않는다. 이런 고려를 하면 정말 필요한 것은 서비스이고, 클라우드는 이를 제공하는 도구라는 점을 깨닫게 된다.
‘기능이 형식에 앞서야 한다’는 격언이 있다. 서비스가 바로 기능이다. 클라우드는 필요한 서비스를 전달하는 형식이다. 이는 IT의 실패가 아닌 성공을 견인하는 생각이다.
9. 애자일을 추구한다 오프쇼어를 추구한다 동시에 둘 모두를 추구한다
애자일은 이점이 많은 기법이다. 성공의 전제 조건 중 하나는 많은 사용자가 격의 없이 참여, 작지만 자주 방향을 수정하고, 개발자가 매일 진행 상황을 확인하고, 매일 사용자 수용도를 테스트 할 수 있도록 만드는 것이다.
반면 오프쇼어에는 한 가지 이점이 있다. 인건비 절감이다. 그렇지만 애자일이 요구하는 사용자의 격의 없는 활발한 참여를 기대할 수 없다. 표준 시간대의 차이, 언어 장벽, 문화적 차이, 웹 컨퍼런싱으로 국한되는 접촉과 커뮤니케이션 측면의 한계가 애자일에 많은 도전 과제를 제시한다.
둘 모두 효과가 있도록 만들 수 있을지 모른다. 그러나 애자일이 생소한 IT 조직은 힘들다. 애자일을 추구하고 싶은가? 오프쇼어를 추구하고 싶은가? 하나만 고를 일이다.
10. 멀티태스킹이라는 ‘방해’를 강요한다
모든 사람에게 멀티태스킹을 강요하는 것도 IT가 확실히 실패할 수 있는 방법이다. 누구나 멀티태스킹을 원한다. 그렇지 않은가? 하지만 멀티태스킹은 실제 생산성과 품질을 낮추고, 더 많은 것에 집중해야 해서 스트레스를 높인다.
다른 사람에게 지금 하고 있는 일을 잠시 중단하고 다른 일을 하라고 요구할 때 기억해야 할 점이 있다. 사람은 멀티태스킹을 하지 않는다. 일을 번갈아 하는 것에 불과하다. 일을 번갈아 할 때마다 ‘멘탈’을 바꾸면서 시간을 낭비한다. 작업에 요구되는 집중력이 높을 수록 낭비되는 시간도 증가한다.
IT가 성공하려면 어떻게 해야 할까? 하고 있는 일을 끝낸 후, 다른 일을 시작하도록 만들면 된다.
11. 많은 프로젝트를 추진한다
IT에는 사람들이 원하는 모든 프로젝트를 처리할 인력이 없다. 할 수 있는 일은 여러 프로젝트를 시작하고, 직원들을 필요에 따라 계속 번갈아 재배치하면서 여러 프로젝트를 추진하는 것이다.
이렇게 할 경우, 추진하는 모든 프로젝트의 시간이 지연된다. 또 기준에 미달되는 결과만 전달한다.
IT의 평판을 높이기 위해 지켜야 할 원칙이 있다. 어떤 프로젝트이든 필요한 인력을 모두 투입하는 것이다. 특정 직원이 시간이 날 때까지 프로젝트를 잠시 중단하는 일이 있어서는 안 된다는 의미다.
이렇게 하면 여러 프로젝트를 추진했을 때보다 더 빨리 모든 프로젝트를 완료할 수 있다.
12. 요청에 ‘예’ 또는 ‘아니요’로만 대답한다
IT의 실패를 ‘보장’하는 마지막 방법은 요청이 무엇이든 ‘예’ 또는 ‘아니요’로만 대답하는 것이다. ‘아니요’라는 대답을 하면 관계가 손상된다. ‘예’라고 대답하면 지킬 수 없는 약속을 하는 것이다.
IT가 성공할 수 있는 대답은 “할 수 있습니다. 단 이런 조건이 있고, 이런 조건 아래 이렇게 처리할 것입니다”이다.
요청 관리에는 깰 수 없는 원칙 하나가 있다. 프로젝트 범위 변경, 소프트웨어 업데이트, 예정에 없는 노트북 컴퓨터 지급 등 모든 것에 적용되는 원칙이다. 공짜는 없다는 것이다.
‘예’ 또는 ‘아니요’로 대답하지 않는다. 요청을 들어 주기 위해 해야 할 일을 설명한다. 그러면 논쟁이 아닌 대화를 하게 될 것이다.
* Bob Lewis는 선임 관리 및 IT 컨설턴트다. dl-ciokorea@foundryco.com
