위임에 필요한
기획안 만들기
위임을 위한 실무용 기획안 작성하기
다른 글 <나쁜 리더들: 위임을 못하는 리더>에서 밝혔듯이, 위임을 잘 하려면 우선 사람을 잘 믿는 성격이어야 한다. 의심 많고 남 못 믿는 리더는 하고 싶어도 못 한다. 다시 말해 위임은 타고난 재능에 가깝다.
그렇다고 아예 위임을 포기하는 게 맞을까? 팀으로 협업하고 성장하려면 위임은 필수다. 포기하는 건 리더의 책임을 버리는 짓이다. 재능으로 안된다면 체계로 커버하면 된다.
리더가 권한을 위임하려면 다음과 같이 체계를 만들면 된다.
1. 리더가 과업의 성격과 구성원의 역량을 파악해서 매칭한다.
2. 리더가 구성원에게 과업의 배경, 범위, 레퍼런스, 기대 수준, 허용된 리소스를 설명한다.
3. 구성원이 어떻게 진행할지 기획안을 가져온다.
4. 리더는 구성원과 기획안 내용을 서로 토론하고 합의한 끝에 권한을 위임한다.
5. 구성원은 리더와 약속한 중간중간에 소통하며 업무 내용을 동기화한다.
6. 구성원이 아웃풋을 가져온다.
7. 리더는 구성원의 아웃풋이 기대 수준과 기획안에 충실했는지 체크하고 피드백한다.
8. 리더와 구성원은 해당 업무로 배운점을 서로 공유하고 다음 업무에 연결한다.
여덟 가지 항목 중 특히 3번에서 막히는 경우가 많다. 기획안이 시원치 않으면 믿고 맡기려던 마음이 쏙 들어가버리기 때문이다.
이번 글에서는 실무에서 바로 쓸 수 있는 위임용 기획안 모델을 알아보겠다. 실제로 스타트업에서 팀장으로 재직할 때 위임용으로 만들었던 기획안 모델이다. 노션으로 작성된 문서를 통째로 옮겼다.
프로젝트를 발의해서 문제 해결의 권한을 위임받습니다.
[ 프로젝트란? ]
'프로젝트'란 하나의 문제를 해결하는 업무의 기본 단위입니다.
프로젝트는 프로젝트 매니저(Project Manager, PM)가 발의하고 완료합니다.
프로젝트 매니저는 문제를 해결하기 위해 프로젝트 기획안을 리드에게 발의합니다.
리드는 해당 기획안을 컨펌하여 프로젝트 매니저에게 문제 해결 권한을 위임합니다.
프로젝트 매니저는 자율적으로 문제를 해결하고, 리드가 지원합니다.
[ 프로젝트 기획안 작성법 ]
기획은 현실과 이상의 차이를 극복하는 과정을 체계화한 것입니다. 여행으로 상상하면 이해하기 쉽습니다. 여행을 가려면 가장 먼저 여행의 목적이 필요합니다. 그 다음 출발지와 목적지를 설정하고 두 지점의 거리를 좁히면서 얻는 경험이 여행입니다. 도식으로 표현하면 다음과 같습니다.
1. 개요
문제를 인식한 배경상황, 프로젝트가 필요한 이유 등 읽는 사람이 알아야 할 사항을 서술합니다.
특히 문제가 되는 상황을 묘사하고 문제점을 명확하게 정의합니다.
그 외 프로젝트 매니저의 생각을 자유롭게 기재합니다.
ex) 일을 열심히 하다보니 번아웃이 왔다. 리프레시가 필요하다.
2. 목적
이루고자 하는 바를 정성적으로 표현합니다.
ex) 부산으로 가서 신나게 놀자!
3. 핵심 결과/목표치 설정
목적 달성을 인지할 수 있도록 핵심 지표를 정량적으로 표현합니다.
핵심 지표를 얼마나 달성할 것인지도 표현합니다.
필요하다면 목표치는 여러 개일 수 있습니다.
ex) 서울에서 부산까지 5시간 안에, 예산 10만 원으로 가야 한다
4. 문제 해결을 위한 액션 아이템
목적과 목표를 달성하기 위해 필요한 액션 아이템을 계획합니다.
관련된 계획서, 보고서, 제안서, 레퍼런스 등 모든 문서의 링크를 기재합니다.
구체적으로 어떻게 수행할지를 계획하면 더 좋습니다.
ex) 부산까지 이동하는 옵션이 비행기, 열차, 자동차, 선박, 자전거, 도보가 있는데 견적과 기간을 고려했을 때 열차가 좋을 듯 하다. 근거는 이러하다. 그래서 열차표를 예약하는 방법은 이러이러하다.
5. 필요한 자원 세팅
문제를 해결하는데 필요한 자원을 정의합니다.
PM: 해당 프로젝트를 기획하고 운영하는 사람입니다.
Work with: 협업하는 회사 동료입니다.
시간 자원: 시작일과 마감일을 적습니다.
재정 자원: 예상 비용을 적습니다.
아웃소싱: 외주가 필요하면 해당 업체와 이유를 적습니다.
6. 아웃풋
아웃풋 링크를 기재합니다.
7. 다음 업무
프로젝트의 목적을 달성한 다음 필요할 것으로 예측되는 예상 업무를 적습니다.
특히 근본적인 문제를 완전히 해결하지 못했다면 다음 프로젝트 역시 해당 문제를 해결하기 위한 연속성이 있으면 좋습니다.
ex) 번아웃이 안 풀린다. 부산 여행 다음에는 제주도로 가보자!
8. 회고
프로젝트를 마쳤다는 건 성장을 의미합니다. 축하해요!
프로젝트를 마치고 회고합니다.
리드와 원온원을 통해 피드백을 듣습니다.
팀 동료들에게 느낀 점을 공유합니다.
목적 달성 여부를 Yes or No로 표현합니다.
목표치 달성률을 %로 표현합니다. 객관적인 달성률을 권장하지만 주관적인 완성도를 표현해도 좋습니다.
잘한점을 적습니다.
못한점/아쉬운점을 적습니다.
배운점을 적습니다.
