RACI - 레이키? 레이씨?

얼마전 "ITIL"이라는 "IT 시스템 관리 프레임워크" 교육을 받은 적이 있다. 이 교육을 받으면서 부가적으로 유용한 툴을 하나 발견했다. ITIL에서 말하는 본래의 목적은 아니지만 이것을 개인의 일 처리에 적용하면 많은 도움이 될 것이라는 생각을 했다. 

직장에서 일을 진행하면서 힘들다고 느끼는 부분은 대부분 사람과의 문제라는 것을 많이들 인정할 것이다. 많은 조직에서는 "일을 진행하는 프로세스나 절차등이" 정의되어 있지 않아서 그 결과 구성원들끼리 서로 서로 눈치껏 알아서 해 가는 경우도 있고,일을 처리하는 프로세스나 절차가 정의되었다고 해도 그것들이 작은 활동(activity)들을 제어할 수 있을 정도까지 상세하게 규정되어 있지 않을 수도 있다. 정의되어 있는 수준이하에서 일을 진행하려면 결국 사람들간에 풀어가야 한다. RACI는 이때 응용할 수 있는 툴이다(※ 영국에서는 "레이키"로 발음하고 미국쪽에서는 "레이씨"로 한단다.)

사람과의 갈등들을 돌이켜보면 많은 문제들이 역할 정의 그리고 책임과 권한에 대해서 서로가 합의, 공유가 되지 않아서라는 것을 알게 된다. RACI는 아래 약자이다.

R : Responsible A : Accountable C : Consulted I : Informed

누가 무엇을 해야 하고(Reponsible) 누구의 승인을 받아야 하는지(Accountable) 누구와 사전에 논의를 해야 하는지(Consulted) 일이 끝나면 누구에게 알려야 하는지(Informed)

이 4가지를 일 시작 전에 정의하고 들어가면 사람간의 갈등 해소에 많은 도움이 된다는 것을 알게 되었다. 

문제는 이 4가지를 정의하고 들어가는 것이 힘들다는 것이다. "관리"에 대한 개념이 없는 조직일 수록 나오는 즉각적인 반응들이다. 

"매정하게...", "우리끼리...뭘 그런것까지...", "니 할일만 하려고 그러니?", "서로 서로 도와줘야지..."

모두 "작업 할당"과 관련된 것으로서 Responsible 내의 문제들이다. 우리가 흔히 말하는 WBS(Work Breakdown Structure)에서 최종 작업 항목에 누구를 할당하느냐와 관련되어 있다. RACI와는 다른 문제를 걱정하고 있는 것이다. RACI는 작업 할당과 관련된 것이 아니라 더 높은 수준의 역할 정의이다. 이런 오해로 RACI 정의 자체를 하지 않는 경우가 많다.

일을 하다 보면 "이해관계자 파악"은 본능적으로(?) 하게 된다. 물론 일이 커져서 프로젝트 차원으로 되면 개인의 본능이 아닌 공학적인 접근이 필요하다. 이때 이해관계자 파악으로 끝나서는 안되고 그 사람들의 RACI 분석을 통한 역할 정의 수준까지 가야지 이해관계자 관리가 되고 갈등이 줄어들 수 있는 것 같다.

마지막으로 중요한 사항 하나 더. "RACI 정의는 협의로 되어야 하고 서로 공유가 되어야 한다". 그렇게 하지 않으면 "내가 생각하는 나의 역할과 다른 사람이 생각하는 나의 역할이 달라서" 역시 갈등의 원인이 되는 경우를 많이 봐 왔다.

업데이트) 2016.06.09

참고로, 아래와 RACI 정의 예제 폼을 사용할 수도 있을 것 같다.