최고의 IT 조직들은 스스로를 접근 가능하게 만들었으며, 이제는 모든 사람들이 그 일부를 원하고 있다. 프로젝트 포트폴리오 관리(Project Portfolio Management), 즉 PPM은 떠돌이들이 접근하지 못하게 막고 기업이 힘들게 쟁취한 명성을 지킬 수 있게 해준다.

IT 부서는 미 경제계의 연인이거나 원수, 둘 중 하나다. 아마도 이를 두고 어떤 쪽이 더 큰 고통을 유발하는지 논쟁하는 사람들도 있을 것이다. 현실을 직시하자면 최근에는 일을 잘 해낸 보답이 더 많은 일이 되고 있다. 일단 IT 조직에서 비즈니스 부문의 신뢰를 얻으면 그 다음에는 신규 프로젝트의 맹공에서 살아남아야 하기 때문이다.

좋은 상사와 마찬가지로 좋은 조직이라면 감당할 수 있는 것보다 더 많은 일에 시달리다 프로세스 중에 뻗어버리는 사태는 원치 않을 것이다. 본지 조사에 따르면 수행 능력이 뛰어난 비즈니스 조직에서는 IT에서 이런 시류를 중단시켜 주기를 바라는 것으로 드러났다. 그리고 이러한 흐름은 분명 저지될 필요가 있어 보인다. 최근 986명의 IT 및 비즈니스 매니저를 대상으로 실시한 설문 조사에 따르면 이들 가운데 75%는 IT 작업량이 많거나 엄청나다고 답했기 때문이다.

현명한 조직들은 PPM(Project Portfolio Management)을 확보하고 여기에 우선순위를 정하며, 필요할 경우에는 좋지 못한 프로젝트를 안락사시킨다. 최근에 다룬 바 있는 위험 관리 기술과 마찬가지로 PPM은 성숙한 곳에서는 전혀 새롭지 않은 기술이다. 버지니아주의 한 IT 프로젝트 매니저인 존 네임은 “우리는 구성과 엔지니어들이 수년간 있었던 곳을 선택했다”고 말했다.

가장 간단하고 유용한 형태의 PPM에는 모든 프로젝트를 둘러싼 파라미터 설정, 등급 분류 및 우선순위 정하기가 포함된다. 이상한 증명서나 값비싼 소프트웨어와 상관없이 여기로 바로 들어가 보면 PPM은 우리가 매일같이 체육관에 가기 전에 먼저 낚시를 하거나 유치원에 가서 아이들을 데려오거나, 혹은 그보다 먼저 일부터 끝내야겠다고 결심을 할 때 행하고 있는 것에 다름아니다.

부서간 협의는 필수
최근 IT 프로세스 인스티튜트(IT Process Institute)에서 실시한 조사에서 드러난 것처럼, IT 세상에서 가장 이를 잘 수행하고 있는 사람들은 프로젝트를 가장 잘 취소하는 사람들로, 그 비율은 사실 잘 수행을 못하는 사람의 두배에 달했다.

인스티튜트의 매니징 디렉터인 커트 밀른은 “여기에 대해 생각하기 전까지 이것은 직관에 반하는 일”이라고 말했다. 비즈니스 세계는 새로운 이니셔티브를 시도하는 데 익숙한 세계지만 효과가 없으면 가차없이 이동을 한다. 그러나 IT 세상에서는 안정성이 갖는 가치가 중요하기 때문에 방아쇠를 당기는 데 망설이는 게 드문 일은 아니라고 밀른은 지적했다. “IT 사람들이 자신들이 가져야 하는 것이 노련함이라고 생각하는지는 잘 모르겠지만, 논리적으로 볼 때 나쁜 프로젝트를 취소하고 이동하는 게 맞는 것 같다.”

비즈니스 임원들 라인에서는 용량 계획, 우선순위 지정, 그리고 트레이드오프 만들기를 이해하지만 이런 것들이 비즈니스 언어로 제시되기를 기대한다. 이들이 이해하지 못하는 것은 IT에서 과도하게 약속을 한 다음 마감 기한을 맞추지 못하거나 프로젝트를 적절히 완수하지 못함으로써 그 약속을 지키지 못하는 일이다. IT가 PPM에 능숙해지지 못할 경우에는 이런 신뢰성의 간격을 결코 좁힐 수가 없다.

우리 설문조사 응답자들은 프로젝트 포트폴리오를 효율적으로 관리하는 데 있어 가장 큰 장벽을 인성과 숨은 의도, 그리고 정책으로 꼽았다. 잘 정리된 좋은 프로젝트와 진행 중 프로젝트 포트폴리오를 만드는 일은 일시적인 기분에 따라 흔들리지 않을 수 있는 최선의 방법이다. 프로세스를 만들 때는 IT 외 부서 사람들과도 접촉을 해야 최종 제품에 이르기까지 문제가 없다. 이런 사람들과 프로세스에 대해 협의할 때는 다음과 같은 것들을 생각해야 한다.

●작업 역량을 재보라
IT 스태프가 얼마나 바쁜지를 명확히 알지 못하면 왜 프로세스가 필요한지를 정당화하는 일을 시작조차 할 수 없다. 그룹의 일이 과부하 상태가 아니라고 생각하더라도 역량 데이터는 다른 방식으로도 이용될 수 있다. 예를 들어 금융 업계의 한 프로젝트 매니저는 작업 역량 데이터가 언제나 프로젝트를 맡을지를 결정하는 데만 쓰이는 게 아니며 나중에도 그 역할을 한다고 말했다.

“우리는 요청이 들어온 일은 모두 하겠다고 말한 다음 하지 않을 것들에 대해 고객과 협상에 들어간다”고 그는 고백했다. 우리 설문 조사 응답자의 45%가 ‘최고의 추측(best guess)’ 기법을 사용하거나, 그룹의 작업 역량을 판단하려 시도조차 하지 않고 있다는 사실을 보면 아마도 이 근본적인 개념을 두고 왜 그토록 많은 사람들이 고군분투 하고 있는지를 알 수 있을 것이다. 계속해서 추적을 하는 곳들 가운데는 할당된 FTE 시간을 사용하는 사람들도 있고, 프로젝트 대기열의 길이, 즉 IT에서 동시에 작업 중인 프로젝트의 수를 기준으로 하는 곳도 있다. 이것은 비즈니스 환경의 변화에 따라 긍정적인, 혹은 부정적인 동향을 밝히기 위해 먼저 베이스라인을 세우기만 하면 효과가 있다.

●가시성과 지원을 구축하라
좋든 나쁘던 작업 역량을 공유하는 것은 인력과 재정 자원이 한정된 곳에서는 필수적으로 해야 할 일이다. 캘리포니아의 한 정부 프로젝트 매니저는 “이것은 IT와 비즈니스 부문에서 작업에 우선순위를 정하고, 하청업체나 컨설턴트같은 추가 자원을 결정하는 데 도움을 준다”며, “이것은 또한 작업량과 우선순위 지정에 대해 비즈니스에게 정보를 준다”고 말했다. 또 다른 식으로 생각해 보면, 이들이 IT를 얼마나 괴롭혔는지 제대로 알지 못한다면 이들이 어떻게 IT에게 미안해 할 수 있겠는가.

조직에서 IT 프로젝트 흐름을 관리하기 위해 필요로 하는 것을 확립하기 위해서는 명령 계통의 위아래를 모두 커버해야 한다. C 레벨의 사람들을 참여시키지 못할 경우 소프트웨어나 프로젝트 스태프를 위한 자금을 확보할 수 없으며, 일부 프로젝트에 우선순위를 주거나 뺏는 데 있어서 지원을 받을 수가 없거나 심지어 프로젝트가 무산돼 버릴 수도 있다.

한 보건 사업자 CIO는 “IT에서는 어떤 것도 소유하지 않는다는 정신을 갖고 있다. 이는 곧 어떤 프로젝트 우선순위든 비즈니스 프로세싱의 책임이라는 의미”라고 말했다. “IT는 비즈니스 니즈를 지원한다. IT에서는 요청받은 작업에 대해 캡처하고 기록하고 보고한다. IT 경영진에서는 매주 한 번씩 COO와 CFO를 만나 ‘탑 10’ 프로젝트의 우선순위를 정한다.”

이것은 특히 “탑 500”이나 “모든 것이 No. 1으로 중요하다”는 식의 리스트가 아니라 “탑 10” 전략이 도움이 되는 곳에서 좋은 전략이다.

마찬가지로 자기 부대의 무기고에 무엇이 있는지를 알지 못한다면, 이행에서 갖고 싸울 수 있는 PPM 툴이나 프로세스를 사용할 수 없을 것이며, 여기서 그 방법론은 의미가 없어진다. 40시간 이상이 걸릴 것 같은 일일 때는 그 요청이 프로젝트 매니저에게 따로 보내지게 하는 프로세스를 만든다고 해보자. 헬프데스크가 이 고리에 포함돼 있지 않거나 참여를 거부할 경우, 프로세스는 요청한 바로 그 시점에서 실패하게 된다.

●글로벌하게 훔치고 로컬로 평가하라
소모적인 투자를 피하려면 분명 다른 프로세스로부터 프레임워크를 빌려와야 한다. 물론 궁극적으로 프로젝트 평가와 포트폴리오 관리는 자신의 문화에 맞게 조정이 돼야 하겠지만. 조직이 경쟁이 치열한 비즈니스를 하고 있다면 공공 기관들로부터 프로세스를 빌려와 보라. 결국 당신의 세금은 이들에게 나가고 있다. 네바다와 캔사스를 비롯한 몇 개 주에서는 프로젝트 관리에 사용할 수 있는 공공 정보가 있다.

대부분의 평가 프로세스에는 여덟가지 요소들이 참작이 된다. 첫째는 ROI를 포함한 재정적 영향으로, 이것이 비용을 절감해 주거나 매출을 창출해 주는가의 문제다. 그런 다음에는 대부분 위험, 조직적 개발, 고객 서비스, 규정 준수, 건강이나 생명의 안전, 이사진 전략 및 이니시어티브, 손실 관리 등이 추가된다. 각각에는 1에서 10점까지 점수가 주어지며, 몇 가지 항목에 어떤 식으로든 가중치가 주어져서 전체 순위가 매겨진다.
자신의 조직에 어떤 평가 범주가 잘 맞을지 생각할 때는 무엇을 달성하고자 하는지를 생각해야 한다. 참여하고 있는 프로젝트가 끝나는 시간들을 앞당기는 게 목표인가? 우리가 조사한 조직의 27%는 이것을 측정하고 있었다. 혹은 IT를 좀더 비즈니스 필요에 맞추고 싶을 수도 있다. 무엇이든간에 목표로 하는 것을 평가 범주에 포함시켜야 한다.

●거치른 벌판을 정복하라
모든 프로젝트가 공식적인 작업 분석 구조나 냇(Gnatt) 도표, 핵심 경로 분석 등을 필요로 하는 130만 달러짜리의 엔터프라이즈 소프트웨어 프로젝트는 아닐 것이다. 하지만 그렇다고 해서 모든 것이 간단한 업무 요청서는 아니다. “우리가 원하는 건 새 스캐너 몇 개가 전부인데 뭐 그리 어려울 게 있겠는가?”라고 했다가 배달, 네트워크 구성, 장애관리, 조달, 그리고 스캔을 받기 위한 문서 관리 시스템의 추가 라이선스 구성 등에 일주일이 금방 지나가버린다. 언제나 중도(middle ground)가 있는 법이며, 많은 IT 관리자들에게 있어 이 중도는 지금 현재 IT에서는 거치른 서부 벌판에 다름 아니다.

노스 캐롤라이나의 한 애플리케이션 매니저는 “우리는 적은 인원으로 많은 시간을 보내고 있다”며, “우리 식사거리가 된 짐승이 천 마리는 될 것”이라고 말했다.조그마한 모든 일에 공식적인 프로젝트 관리 오버헤드를 만들 필요는 없을 것이다. 하지만 모든 프로젝트를 평가할 수 있는 능력이 없이는, 따라서 그 흐름을 제어할 수 있는 능력이 없이는 조그마한 일이라도 고통스러울 수 있다.크레거(Cregger)사는 한 페이지를 넘기지 않는 ‘미니 스코프(mini scope)’를 사용하고 있는데, 여기에는 작업의 ‘역할과 책임’ 축약본이 포함돼 있다.

이 프랙티스는 작은 일에 큰 도구를 사용하지 않으면서 PMI의 방법론 가운데 좋은 것들을 취하고 있다. 여기서 핵심은 스레숄드를 만드는 것으로, 이것은 헬프데스크 작업 요청 대비 소형 프로젝트에 드는 비용이 될 수도 있고 예상 작업량이 될 수도 있으며, 혹은 이 두 가지가 모두 적용될 수도 있다.이상과 같은 범주들을 사용하되 단 임원의 시간 투자를 요하는 평가는 아마 실행되기 힘들 것이다. 어쨌거나 우리들 대부분은 무엇이든 분명 하기는 해야 할 것 같다. 설문조사 응답자의 33%는 작은 프로젝트를 심지어 추적조차 하지 않고 있는데, 이것은 결코 바람직하지 못한 일이기 때문이다.

정치적인 문제
일단 프로세스를 정립하면 p로 시작되는 다른 것, 즉 politics(정치)가 어쩔 수 없이 그 추한 머리를 들이밀 것이다. 한 대형 의료기기 제조업체의 IT 관리자는 “예산과 자원의 압박 때문에 프로젝트를 완료하지 못하는 사람이 있다”고 말했다. 여기서 한 가지 중요한 의문은, 비즈니스 부문이 밖에서 자기 순서를 기다리며 떨고 있을 것인가, 아니면 멋진 일격을 시도하는가이다.

PPM의 마법은 이것을 제대로만 하면 왜 주어진 프로젝트가 전체 IT 거버넌스 전략의 맥락에 맞게 되지 않았는지가 너무도 명확히 드러난다는 것이다. 사실 어떤 조직들은 프로젝트 평가를 위해 별도의 팀을 만들기보다 이를 IT 거버넌스 위원회로 넘겨버리기도 한다. 그리고 또 다른 곳에서는 첫 평가 프로세스가 만족스럽지 못할 경우 프로젝트가 평가되는 우선 방안으로가 아니라 임원 시간이 부족할 경우 이들을 하나의 매력적인 메커니즘으로서 사용하고 있다.

CIO와 IT 실무자들과의 토론에서 계속 다시 제기된 주제 가운데 하나는 포트폴리오 관리 프로세스가 비즈니스 부문의 프로젝트용으로 “맞지 않거나”, 혹은 “지금은 아니지만”, 자체 예산과 어느 정도의 자율권을 갖고 있는 비즈니스 부문에서 어찌됐건 IT 승인없이 일을 추진할 경우, 그리고 나서 비즈니스 부문에서 제대로 계획하지 못한 기술이 제어권밖으로 나가버리거나 엔터프라이즈 시스템과의 통합에 실패함에 따라 결국에는 이 불량 프로젝트로 인해 IT에 예상치 못한 긴급한 일이 생기게 될 경우에는 어떻게 될까?

ITPI의 밀른은 이 질문에 다음과 같은 질문으로 답했다. “회사의 전략이 ‘남미 시장에는 진출하지 않는다’인데 비즈니스 팀에서 이것을 밀어붙인다면 어떻게 할 것인가?” PPM 프로세스가 회사의 실무 전략에 충분히 통합될 경우에는 완전히 도를 벗어난 부문이라고 해도 IT에게 비난 받을 일은 없을 것이다. IT가 관여를 하든 하지 않든 조직에서 이들을 다스릴 수 있기 때문이다.