간트차트·PERT — 시간을 다룬다언제 시작해 언제 끝나는가, 무엇이 무엇에 걸려 있는가를 보여 준다. 일정 관리의 도구이며, 늦어졌을 때 어디를 손봐야 하는지 알려 준다. 마일스톤은 그 위에 큰 분기점을 점으로 찍어 보고와 소통을 돕는다.
VS책임행렬표 — 사람을 다룬다누가 무엇에 어떤 역할로 관여하는가를 보여 준다. 일정이 아무리 잘 짜여도 담당이 불분명하면 일은 진행되지 않는다. 공백(아무도 R이 아닌 활동)과 중복(A가 여럿인 활동)을 눈으로 찾아낼 수 있다.
Plan — 방침을 세우고 부서·개인 목표로 전개한다→Do — 계획대로 실행한다→Check — 결과를 계획과 견주어 확인한다→Act — 차이의 원인을 찾아 조치하고 다음 순환의 계획에 반영한다
RACI 네 역할| 기호 | 역할 | 뜻 |
|---|
| R | 실행(Responsible) | 실제로 그 일을 하는 사람 — 여럿일 수 있다 |
|---|
| A | 최종책임(Accountable) | 결과에 책임지고 승인하는 사람 — 반드시 한 사람 |
|---|
| C | 자문(Consulted) | 의견을 구해야 하는 사람 — 쌍방향 소통 |
|---|
| I | 통보(Informed) | 결과를 알려야 하는 사람 — 일방향 소통 |
|---|
더 알아보기
책임행렬표가 드러내는 두 가지 병
책임행렬표를 실제로 그려 보면 계획 단계에서 보이지 않던 문제가 드러난다. 두 가지가 전형적이다.
첫째, 빈 행(공백). 활동은 목록에 있는데 그 행에 R(실행)이 아무도 없는 경우다. 「누군가 하겠지」로 남아 있던 일이며, 실행 단계에서 아무도 하지 않아 문제가 된다. 부서 사이에 걸친 일, 사업의 앞뒤를 잇는 일(예: 사업 종료 후 대상자 연계), 정기적이지 않은 일에서 자주 생긴다.
둘째, A가 여럿인 행(중복). 최종책임을 두 사람 이상에게 두면 실제로는 아무도 책임지지 않는다. 서로 상대가 결정할 것으로 여기고, 문제가 생기면 서로 상대의 몫이었다고 한다. 그래서 RACI의 규칙은 A는 반드시 한 명이다. 여럿이 함께 실행할 수는 있어도(R은 복수 가능) 최종 승인과 책임은 하나여야 한다.
셋째로 자주 보이는 것이 C의 남용이다. 자문을 받아야 할 사람을 지나치게 많이 지정하면 모든 결정에 여러 사람의 의견을 물어야 하고, 일이 느려진다. 실제로 의견이 결정에 반영될 사람만 C에 두고, 알기만 하면 되는 사람은 I에 두는 것이 요령이다. C와 I를 가르는 기준은 「그 사람의 의견이 결정을 바꿀 수 있는가」다.
사회복지 현장에서 이 도구가 유용한 자리가 있다. 앞 장에서 본 조직 간 협력이 그것이다. 여러 기관이 함께하는 사업에서 「우리 기관은 어디까지 하는가」가 불분명하면, 서로 상대가 할 것으로 여기다 사이로 빠지는 일이 생긴다. 협약을 맺을 때 활동별로 R과 A를 명시해 두면 이 위험이 줄어든다.
통합사례관리에서도 마찬가지다. 한 가구에 여러 기관이 관여할 때 누가 전체를 책임지는지(A), 각 서비스는 누가 실행하는지(R), 누구에게 상의하고(C) 누구에게 알려야 하는지(I)를 정해 두면 사례관리 회의가 훨씬 명확해진다. 앞 장에서 본 인적 의존의 문제도 이 문서가 남아 있으면 담당자가 바뀌었을 때 인수인계의 근거가 된다.
PDCA를 사회복지 프로그램에 돌릴 때 막히는 곳
PDCA 순환은 단순해 보이지만, 사회복지 현장에서 돌리려 하면 특정 지점에서 막힌다.
Plan은 잘 돈다. 사업계획서를 쓰는 것은 이미 제도화되어 있고, 대부분의 기관이 연초에 계획을 세운다.
Do도 돈다. 계획한 사업을 실행한다.
Check에서 막힌다. 앞 장에서 여러 번 본 대로 성과를 재기 어렵기 때문이다. 그래서 확인 단계가 「몇 명에게 몇 회 했는가」의 실적 집계로 축소된다. 계획한 대로 했는지는 확인하지만 그래서 무엇이 달라졌는지는 확인하지 않는다.
Act는 거의 돌지 않는다. 확인이 실적 집계에 그치면 조치할 내용이 나오지 않는다. 「목표한 인원을 채웠다」에서 나올 수 있는 조치는 「내년에도 같은 인원을 목표로 한다」뿐이다. 그러면 순환이 아니라 같은 자리를 도는 반복이 된다.
Check를 되살리는 방법이 몇 가지 있다. 계획 단계에서 확인의 방법을 함께 정하는 것 — 무엇을 어떻게 재어 성공을 판단할지 미리 정해 두면 확인 단계에서 헤매지 않는다. 뒤에 볼 논리모델과 성과지표 설정이 이 작업이다. 실적만이 아니라 질을 묻는 것 — 참여자의 변화, 만족도, 중도 이탈의 이유를 함께 본다. 실패를 드러낼 수 있게 하는 것 — 계획대로 되지 않은 것을 보고하면 불이익을 받는 구조에서는 확인 단계가 정직해질 수 없다. 앞 장에서 본 조직문화의 기본 가정이 여기서도 작동한다.
Act를 되살리는 방법은 확인 결과를 다음 계획에 반영하는 절차를 만드는 것이다. 평가 보고서가 서랍에 들어가고 다음 해 계획은 백지에서 시작하면 순환이 끊긴다. 사업계획서에 「전년도 평가에서 확인된 사항과 그에 대한 조치」 항목을 두는 것만으로도 연결이 생긴다.
곧 PDCA가 돌지 않는 것은 도구의 문제가 아니라 확인을 실질화할 수 있는가의 문제이며, 뒤에 볼 프로그램 평가 편이 그 방법을 다룬다.