-제2회- 유저 기업측 프로젝트 매니저의 착각

1. 리스크를 초기 단계에서 해결하기 위한 관리

리스크를 초기 단계에서 해결하기 위한 관리

프로젝트의 스테이크 홀더는 크게 4가지로 나눌 수 있다.

1) 유저 기업측 최고 시스템 책임자
2) 유저 기업측 프로젝트팀
3) 유저 기업측 그 외 시스템 관계자 (타 부문의 시스템 책임자)
4) 시스템 개발자

2 번째는 "사람"에게서 기인하는 리스크 팩터와 매니지먼트 방법, 즉 유저 기업측의 프로젝트 팀을 총괄하는 프로젝트 매니저를 대상으로 시스템 개발회사와의 관계에서 생기는 리스크 팩터와 그 매니지먼트 방법을 프로젝트 현장에서 자주 볼 수 있는 사례를 통하여 소개하고자 한다.

IT 프로젝트 현장에서 자주 볼 수 있는 풍경

개발 기업측 프로젝트 매니저 : "오늘 개발 정기 미팅 말인데요, 앞서 받았던 경리용 장표 항목 위주의 확인을 중점적으로 하고 싶습니다만..."

유저 기업측 프로젝트 매니저 : (말을 막는 듯) "아~ 그 건 말씀이시군요. 사실 경리측 시스템도 교체하고 있어서 말이죠. 그에 관해서 우리 시스템에서 장표를 제출하는 것이 아니라 경리 시스템 측에서 필요한 데이터를 CSV로 보내도록 변경해 주었으면 합니다."

개발 기업측 프로젝트 매니저 : "사양 변경에 관한 건은 들었습니다만, 이 경우 사양 변경의 효과 이외도 납기와 예산에 관해서 재검토하지 않으면 안 될 가능성이..."

유저 기업측 프로젝트 매니저 : "그렇게 큰일은 아니죠. 장표로 제출할 것을 CSV로 바꾸기만 하면 되는건데 말이죠."

개발 기업측 프로젝트 매니저 : "문자 코드 문제나 통신 형식 등 확인해야 할 사항이 있으니 경리 시스템측 담당자님과 협의할 기회를 만들어주실 수 있으십니까?"

유저 기업측 프로젝트 매니저 : "아, 그렇지만 담당자는 이번 주와 다음 주에 여름 휴가라서요. 우선 적당히 CSV로 개발을 진행해 주실 수 없을까요?"

개발 기업측 프로젝트 매니저 : "그러면 우선 납기에 대해서 스케쥴 조절안을 제출해 주실 수 있을까요?"

유저 기업측 프로젝트 매니저 : "납기와 에산은 바꿀 수 없습니다. 그쪽에서 조정해 주시죠."

이 대화를 읽고 독자는 어떻게 느낄까. 유저 기업측의 프로젝트 매니저가 사양 변경에 대해서 능수능란한(무리한?) 교섭 방법으로 개발 기업측 프로젝트 매니저에게 압박을 가했다는 느낌이 오는가? 정말로 그렇게 생각하는 분들이 있다면 지금 곧 생각을 고칠 필요가 있다고 생각한다. 끝까지 읽어주시길 바란다.

유저 기업측의 프로젝트 매니저 중에서 얼마나 싼 발주 금액과 단기의 납기로 개발업자에게 발주시킬 것인가가 유저 기업측 프로젝트 매니저의 일이라고 착각하는 분들이 많은 것은 몹시 한심스러운 일이다. 결국 개발 업자가 유저 기업측에 제기한 금액과 납기는 "이 금액과 납기라면 프로젝트를 안전하게 끝낼 수 있다"고 코멘트한 것으로 교섭에서 발주 금액을 내리거나 납기 기한을 짧게 하는 것은 프로젝트 성공이라는 점에서는 아무런 의미도 가지지 않는다. 이와같은 일방적인 방보를 강요하는 교섭을 프로젝트를 공동으로 운영하는 경우의 "사람"에게 계속 적용하면 프로젝트의 리스크를 비대화시킬 뿐이다.

프로젝트의 실패란 원래 무엇일까? 개발 회사에서 사양 변경 조정 의뢰에 실패하고 상사에게 혼나는 것이 실패일까? 그렇지 않으면 개발 회사에게 사양변경을 하도록 지시하여 납기 직전이 되어 개발 회사로 부터 반려되고 소송문제로 발전하게 되는 사태를 부르는 것일까?

2. 상호이익의 관계를 개발 회사와 쌓아가야 한다

상호이익의 관계를 개발회사와 쌓아가야 한다

본 건의 사상을 예를 들어보면 우선 유저 기업측 프로젝트 매니저는 아래의 대처를 생각해야 했을 것이다.

1. 사양 변경의 스케쥴에게 주는 효과를 개발 회사에게 제공할 수 있는 자료를 어떻게든 경리 시스템 담당자와 연락을 취하여 신속히 입수하고 개발 회사에 상황을 제공하여 사양 변경의 효과를 알린다.

2. 개발 회사로부터 보고 받은 재스케쥴안을 자사 내에서 협의하도록 하여 시스템 납기의 연장이나 사양 변경 부분의 분할 lease안 등 대책을 강구한다. 재스케쥴이 어려운 경우에는 예산 증액에 의한 개발 회사의 증원 요청을 실시하는 등의 대체안을 고안한다.

3. 개발 회사에 대해서 유저 기업측으로부터의 요구, 협의의 경위를 전달하고 대응을 의뢰한다.

전 회에 이야기한 것처럼 프로젝트 매니지먼트의 본질은 "실패를 전제로 한다"라는 것이다. 이 케이스의 경우 납기와 예산을 변경하지 않고 개발 기업측이 사양 변경을 받아들이도록 하는 것을 너무 고집한 나머지 최대의 목적인 프로젝트를 성공시킨다는 점을 소홀히하여 버리는 것이다. 개발업자에게 무리한 납기나 예산을 강요하기 전에 우선은 시스템과 관계되는 스테이크 홀더에 대해서 예산의 교섭이나 시스템의 서비스 인의 시기를 교섭하고 안전한 프로젝트 매니지먼트를 실시하는 것이 프로젝트를 성공시킨다는 본래의 목적에 필적하는 행위라는 인식이 유저 기업측의 프로젝트 매니저의 인식에 부족햇던 것이다.

또 구체적으로 예로 든 사상 이외에도 많은 "사람"에 관련되는 과제가 IT 프로젝트를 덮쳐버릴지도 모른다. 그것은 제안 시에 와 주었던 개발 회사의 프로젝트 매니저가 수주한 순간 경험이 부족한 프로젝트 매니저로 변경된 사태나, 정보시스템 부문측의 담당자가 대신하여 SLA의 재 검토를 시스템 서비스에 들어가기 1주일 전에 시켜야 했다는 등 필자가 경험한 것 만으로도 책을 한 권 쓸 수 있을만큼 많이 존재한다. 중요한 것은 이러한 리스크를 부르는 최악의 사태를 인식하고 조기에 대처하는 것이다. 개발 회사의 프로젝트 매니저가 바뀌어 버렸다면 인계가 무사히 끝났는지를 확인하고 아무래도 프로젝트를 맡길 수 없을 정도로 경험이 부족한 경우에는 프로젝트 매니저의 교체를 영업 담당에게 신청해야 할 것이며, SLA의 재검토가 불가피한 경우에는 그것이 스케쥴 지연으로 연결될 것인지를 파악하여 초기 단계에 스테이크 홀더와 교섭해야 하는 것이다.

요점은 프로젝트 매니지먼트에서의 위기관리는 리스크가 될 수 있다고 인식된 시점에서 사태가 더 심각해지기 전에 선행하여 대처하고 리스크를 초기 단계에서 해결하는 것의 반족인 것이다. 그렇다면 "지극히 당연한 일을 하고있는 것이 아닌가?" 라고 생각될지도 모르겠지만 실제로 그와같이 지극히 당연한 것이다. 그러나 그와같은 당연한 것을 하지도 않아 오늘도 실패 프로젝트는 계속 증가하고 있다. 그 본질적인 원인은 도대체 무엇일까?

유저기업 자신이 리스크 팩터

요즈음 프로젝트 매니지먼트 붐을 타고 수 많은 서적이 출판되고 있지만 고객, 즉 유저기업 측의 생트짐에 대해서 스스로 어떻게 개발회사측의 사정을 설명하고 양보를 끌어낼 것인가하는 교섭술도 생트집에 대해서 위험분산으로 계약이나 변경 이력을 남기는 테크닉이 내용의 중심이 될 것이다.

즉 개발회사는 오늘의 IT 프로젝트에 대해 가장 큰 리스크 팩터가 되는 요인은 유저기업 자신의 체질이다라는 것을 인식하는 것이다. 유저기업 자신이 "개발회사에게 위탁" "프로젝트에의 비협력적인 체제" "사양의 정리를 실시하지 않는다" 등의 큰 리스크 팩터를 안고 있으며, 그것을 해결하는 것이 개발회사에게 있어서 큰 위험분산이 된다고 인식하고 있는 것이다.

유저기업의 프로젝트 매니저는 프로젝트의 성공이 어디에 있는지를 항상 생각하면서 리스크가 될만한 싹을 미리 잘라내어 프로젝트와 관계되는 이해관계자의 이해나 기대를 항상 조정하면서 프로젝트를 운영해 나갈 의무가 잇는 것이다.

프로젝트 최대의 보틀넥은 사실 유저기업측의 당사자 의식이 낮다는데 있다는 주장은 유저기업측 프로젝트 매니저에게는 말도 안되는 주장일지도 모른다. 사실 프로젝트의 성공율이 낮은 요인으로서 개발회사의 프로젝트 매니지먼트가 기능을 잘하지 못하고 있다는 것도 사실일 것이다.

그렇지만 전 회에서도 이야기 했듯이 IT 프로젝트의 매니지먼트의 의무는 어디까지나 유저기업측에 있다는 것을 잊어서는 안된다. 발주자인 유저기업측이 IT프로젝트를 성공시키기 위해서 최선의 매니지먼트의 방책을 취하는 것이 IT 프로젝트 성공의 최대 열쇠인 것이다.

다음 회에는 "사물"에 기인하는 실패의 리스크 팩터로서 시스템 아키텍쳐와 프로젝트의 관련성에 대해 소개하고자 한다. "Windows 인가? Linux 인가?" "Java인가? .NET인가?" IT계 잡지에서 이야기하는 논의와 실제 현장에서의 논의 사이의 격차도 겸하여 소개할 예정이다.