brunch

You can make anything
by writing

C.S.Lewis

by 정재헌 Oct 06. 2015

PM 컨버팅 #12

2. 프로젝트 실전편   : 이해당사자 관리

#12. 고객분석 및 이해당사자 관리(10.1 Identify Stakeholders)


PM은 머슴이냐 선생이냐? 

이 명제는 많은 부분을 내포한다.

머슴은 고객은 항상 옳고 고객의 모든 요구를 들어주고 고객의 모든 변경요구는 수행하여야 한다.

과연 이게 옳은가?

그러면 어떻게 하면 우리팀은 스승으로  대우받을 수 있을까? 이 부분은 사업 초기 가장 먼저 고객분석을 통하여 그 향배가 가름될 수 있다.


PMI에서는 고객 및 이해당사자를 통틀어서 스테이크홀더라고 정의한다. 우선 내 위에 감독관이 있을 것이고 대부분 공공프로젝트에서 실무감독관은 대리~과장레벨 정도이고 책임감독관은 차장~부장레벨 정도일 것이다. 거기다 공공의 특성상 정부중앙부처의 일을 대행하는 경우에는 그 위에 사무관이나 서기관이 있을 것이다. 그리고 그 프로젝트와 연관된 현업(또는 전산팀)이 있을 것이고 뭐 등등 등 수없이 많은 이해당사자가 프로젝트 주변에 포진하고 있다. 내 눈에 안 보인다고 이 수많은 사람들이 프로젝트에 영향을 안 미치는 것은 아니고 PM이 모르는 사이에도 이해당사자들 때문에 프로젝트가 지옥이 되는 경우가 다반사다.


이 부분을 가장 먼저 언급하는 이유도 이해당사자 관리가 가장 중요하기 때문에 가장 먼저 언급하는 것이다.


수 많은 이해당사자 중에서 나에게 가장 중요한 사람은 일적인 면에서는 대리~과장급인 실무감독관이고 프로젝트의 성패를 좌우하는 사람은 당연히 차장~부장급인 책임감독관이다. 둘 중 누가 더 중요하냐고 물으신다면 당연히 책임감독관이다.


우선 본론에 들어가기 전에 내가 수주하여 진행하는 프로젝트의 성격을 먼저 봐야 된다.

이 프로젝트는 고객이 모든 것을 알고 단순히 수행팀은 구현만 하면 되는 프로젝트인가 아니면

고객은 역량이 안되어서 프로젝트의 전반적인 것을 수행팀이 리드를 해서 진행하여야 하는 것인가로 구분 지을 수 있다.


그러나 핵심은 똑같다.


첫 번째는 고객 말만 잘 들으면 된다. 결국 충실하게 머슴역할만 하면 된다. 그러나 두 번째 경우에는

수행팀의 역량을 가장 빠르게 고객의 역량으로 바꾸어주어야 한다.


결국 수많은 이해당사자를 상대하는 것은 나와 일하는 감독관이고 감독관의 역량에 따라 프로젝트의 성패가 좌우된다. 나와 일하는 감독관이 힘을 받을 수 있게 지식을 제공하고 명분을 제공하고 문서를 제공하고 성과를 제공하여야 한다.


일부 PM관련 서적들에서는 이해당사자들을 개별적으로 관리하라고 정의되어 있는데 실무에서 PM이 감독관을 배제하고 이해당사자들을 직접 만나서 의견을 듣고 그 의견을 프로젝트에 반영한다는게 좀 보편적이지 않다고 본다.


아래 부분에 대하여서는 또 이견이 있을 수 있다.

왜 프로젝트 팀에서 고객이 만들어야 하는 문서를 만들어줘야 하는가? 난 프로젝트팀에서 그 문서를 만들어줘야 한다고 강력히 주장한다. 아니 문서만 만들어주면 안된다. 어떤 이슈가 있을 경우에 고객이 그 이슈에 대하여 완벽하게 이해할 수 있게 최선을 다하여야 한다.

프로젝트의 중대한 이슈나 방향 설정을 할 경우 PM은 실무감독관에게 설명하고 실무감독관은 책임감독관에게 설명하고 책임 감독관은 또 그 상위 조직의 누군가에게 설명을 하고 그 설명이 충실치 못하고 상급자가 이해를 못하면 그 일이 되돌아 오거나 지연되거나 변경이 될 것이다. 결국 그 피해는 프로젝트팀에게 고스란히 전가된다.  


그럼 이런 경우에 어떤 방법이 최선일까.

이런 이슈가 있을 경우 대부분 한글문서로 보고를 하는데 필히 이해를 돕기 위하여 PPT로 설명자료를 첨부하여야 한다. 한글문서로는 충분히 원하는 내용을 설명하기 힘들고 전반적인 프로세스와 다이어그램 위주의 설명자료를 필히 첨부하면 상급자의 이해도를 높일 수 있다.


그리고 프로세스나 기능의 변경이 있는 경우에 필히 조직의 비즈니스 목표와 연관 지어야 한다. 고객이 이 기능을 이 기능으로 바꿔봐라고 지시가  내려올 경우 그 지시의 내용을 비즈니의 목표와 연관해서 생각하여야 한다. 그러면 고객에게 제출하는 기획문서들도 지엽적으로 기능만 나열하면 안되고 그 기능이 어떤 비즈니스 목표에서 도출된 건지에 대한 명확한 정의가 필요하다. 그러면 상당한 부분에서 변경이 줄어들게 될 것이고 이해당사자들의 간섭도 줄어들게 될 것이다. 즉 프로젝트의 목표가 고객사의 한 팀의 목표가 아니라 고객사 전체를 아우룰 수 있는 목표라는 인식이 공유될 수 있는 기반을 사업 초기에 만들어야 한다.


일부 PM들의 그릇된 시각이 분석설계 단계를 짧게 잡고 인력 투입도 안 하고 그냥 허비해 버리는 경우를 많이 보아왔다.  사업 초기 분석 설계단계에서 이런 일들을 하여야 한다.


초보 PM들한테는 위에 기술한 내용들이 분명히 어렵게 느껴질 것이다. 그러나 노력하여야 한다. 이런 노력들이 프로젝트 마지막에 PM을 웃게 만들 것이다.


다음회에 계속.....


지금 읽으신 글은 책으로 출판되어 있습니다.

내일부터 Project Manager가 되어야 한다.

http://www.kyobobook.co.kr/product/detailViewKor.laf?mallGb=KOR&ejkGb=KOR&linkClass=130509&barcode=9791165457037

http://www.yes24.com/Product/Goods/108921595

매거진의 이전글 PM 컨버팅 #22
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari