[기획의 근본] 기획자의 표현

기획의 근본 '표현'

 

기획(Planning)은 '어떤 일을 꾸미어 계획하는 것'이라고 정의하곤 한다.

문장은 단순하지만, 이 문장 안에는 '기획의 목적과 역할'이 잘 표현되어 있다. 

• 어떤 일(Why, What)
   - 경영전략, 신사업개발, 상품/제품/서비스, 기술, 영업 등 기획의 근본적 배경과 목적
• 꾸미다(How much/many, How to do)
   - 어떤 일을 얼만큼 할지의 목표(Mission, Goal, Objective)와 실행전략의 설정
• 계획하는 것(When, Where, Who)
   - 누가, 언제, 어디서 전략과제를 실행할 지를 계획하고 진행 과정의 평가와 피드백 정의

이 기획의 정의를 단계별로 구분한 것이 '착상(Ideation) - 구상(Planning) - 표현(Presentation)' 이다.

앞 선 기획의 정의에서는 드러나지 않는 '표현(Presentation)'의 단계가 사실 상 모든 기획의 행위 중 가장 중요하다. 그 이유는 바로 커뮤니케이션(의사소통)에 있다.

---

기획의 궁극적 사명(Mission)은 기획 그 자체가 아니라, 계획한 것이 실행될 수 있도록 하는 것이고, 실행 과정에서의 피드백을 확인하여 전략을 점검하고 업데이트 하는, '최초에 구상한 아이디어가 목적지에 완전히 정착하게 하는 것'이다. 이를 위해서 작게는 이해관계자(Stakeholder)들과의 컨센서스 과정이 있고, 크게는 '일이 되게 하는' 다양한 내/외부 담당자와의 협력(Collaboration) 과정이 진행되는데, 이때 필요한 것이 '착상, 구상' 단계를 거쳐 표현된 일련의 문서(Document) 꾸러미이다.   

 

기획은 프로젝트라는 실행 과정(Production)을 통해 목적지로 정착할 준비를 마치는데, 이 프로젝트 운영에 가장 중요한 것 중 하나가 커뮤니케이션 관리이고, 이 커뮤니케이션의 시작과 끝은 모두 문서로 작성되어 공유하고, 관리된다. 물론, 모든 일을 혼자서 하거나 2~3명의 작은 팀으로 신속하게 업무를 해야할 때는 문서라는 것이 업무의 효율을 막는 개악(改惡)이 되지만 그런 상황과 환경에서 조차 최소한의 커뮤니케이션 도구이자 정보와 데이터를 남기는 방법으로서 문서화는 반드시 필요하다. 

---

프로젝트를 운영하는 회사의 규모와 정책, 과업의 유형, 목적/목표, 추진전략, 투입 기간/리소스/비용 등에 따라 차이는 있지만 대개 크게 3단계로 나누어 커뮤니케이션에 필요한 문서와 산출물들을 남긴다.

Pre Project - Project - Post Project 

Pre Project, 말 그대로 프로젝트의 전(前) 단계이다. 이 과정의 핵심은 프로젝트를 만드는 것이다. 즉, 기획자가 구상하여 진행하고자 하는 것을 문서화하고 이를 통해서 여러 이해관계자(Stakeholder)들의 동의를 얻어 프로젝트에 이르게 하는 과정이다. 동의를 얻어내야 하는 이유는 이해관계자들을 통해 자금(투자비, 비용)을 받아내고 타 부문/부서의 인력을 참여시켜 팀(Team Building)을 만들어야 하기 때문이다. 프로젝트 규모에 따라서 필요한 자금이 수 십, 수 백억원에 달할 수도 있고 수 십, 수 백명이 참여해야 하는 프로젝트가 될 수도 있기에 동의를 얻는 과정은 매우 치열하고 동의를 얻어 낼 수 있는 각종 데이터, 차트, 다이어그램이 필요하기도 하다. (공감대 형성, 동의를 얻기에 '숫자와 차트, 다이어그램'을 정말 중요한다.)

• (상품) 구상서 / 프로젝트 발의서 / 투자 제안서 / 프로젝트 헌장서 

이런 문서류가 이 단계에서 작성된다. 뭐라고 표현하던 이 단계에서 가장 중요한 것은 '컨센서스(Con-Sensus)'이다. 아무리 훌륭하고 뛰어난 아이디어라고 해도 컨센서스가 없으면 일장춘몽일 뿐이다. 때문에, 컨센서스를 얻기 위한 표현의 방식 즉, 문서 작성은 기획자의 근본 자질이자 역량일 수 밖에 없다.

 

물론, 기가막히게 잘 작성된 문서만으로는 컨센서스를 다 이루지 못할 수 있다. 문서 상에 드러난 것은 어디까지나 하얀 종이나 모니터에 누워있는 활자와 그림 뿐일테니. 이런 한계가 있어 우리 기획자에게 주어진 기회이자 또 다른 표현의 방법은 바로, 프리젠테이션(Presentation) 이다.

 

음악가가 제 아무리 아름다운 운율을 오선지에 그린 듯 오케스트라가 연주를 하지 않고, 가수가 불러주지 않는 한 그 어떤 감동을 줄 수 있겠는가. 기획도 마찬가지다. 딱딱한 숫자나 차트로는 감동을 주지 못한다. 프로젝트 발의를 하거나 투자 제안을 하는데 감동이 뭐가 필요하냐고? 스타트업 투자 제안서를 봐라. VC 심사역들이 가장 중요하게 보는 건 사업 아이템 뿐 아니라 대표자가 갖고 있는 서사다. 왜 사업을 하게 됐고, 어떤 배경이 있으며, 어떤 비전을 갖고 있는지.. 가급적 좋은 스토리를 갖고 있는 사업 아이템이 선정될 수 밖에 없다. 그렇다. 차가운 숫자나 차트는 의사결정에 중요한 가늠자이나 그것이 꼭 프로젝트의 성공을 담보하진 않기 때문에 여기에 기획자의 따뜻한 스토리와 서사가 한 스푼 필요하다. 이 한 스푼이 바로 기획자에게 중요한 역량, 프리젠테이션 스킬이다. 오죽하면 요즘은 프로젠테이션만 강의하는 유튜브나 강사들이 있겠는가. (프리젠테이션 잘하는 법은 다른 포스트에서 다루기로 하겠다.)

 

프로젝트 발의서에 들어가는 작성 항목을 예시로 두고 다음 단계은 Project로 넘어가겠다.

(※ 실제 내가 대기업에서 경영전략담당으로 재직 시 운영했던 신제품개발 프로젝트의 발의서 항목이다.)

1. Executive Summary
2. 환경분석 1) 시장동향 2) 고객 요구사항분석 3) 경쟁사/제품 분석 4) Key Findings
3. 상품기획 1-1) 상품전략 (포지셔닝 전략) 1-2) 상품전략 (4P 전략) 2) 핵심 차별화/주요 기능 3) 성능 목표 
4. 개발계획 1) 개발방법 및 주요기술 확보방안 2) HW 사양 3) 특허 검토 
5. 마케팅/영업기획 1) 브랜드/마케팅 방안 2) 판매/유통 방안
6. 일정 및 투입계획 1) 추진일정(Gate) 2) 조직체계 3) 참여인원 및 담당업무
7. 투자 및 손익계획 1) 투자계획 2) 년도별 손익계획 
8. 위험예상 이슈 및 대응방안

---

이제, Project의 단계이다. 사실 이 프로젝트 단계가 기획자에게 좀 애매한 면이 있다. 회사마다 조직마다 다를 수 있지만, 통상 IT 프로젝트(HW, SW, 플랫폼, App/Web 등)의 경우 '전략기획, 상품/서비스기획, UI/UX기획(프론트/백엔드)'의 역할이 나눠지 있는 경우도 있고 어떤 경우는 그 개념 조차 나누지 못하는 경우도 있다. 안타깝게도 나는 두 가지 모든 케이스를 경험했는데 어쨌든 포스트에는 각 기능이 구분되어 있는 경우를 전제로 하겠다. 

 

예를 들어, 포스트 초기에 언급한 기획자가 전략기획자라고 하면, 이제 프로젝트 단계에서 전략기획자의 역할은 사실 상 없다고 봐야한다. 이 단계부터는 상품기획자 혹은 서비스기획자가 그 바통을 이어받게 되는데 이들은 상위 전략의 관점보다는 실제 제품화, 서비스화(Production)를 위한 '기획'에 훨씬 능통할 뿐더러 'HW, SW, Database, 심지어 제품 디자인'에도 어느 정도의 경험과 센스가 있기 때문에 프로젝트를 매니징하거나 리딩을 하는 역할을 맡기도 한다. 즉, PM이 된다는 말이다.  

 

프로젝트 매니저나 리더를 맡게되면 이제는 기획자는 자신이 작성해야 하는 문서도 있지만, 개발자나 디자이너, 품질담당 등이 작성한 문서를 관리해야 하는 역할을 맡기도 한다. QA 조직이 잘 구성된 회사의 경우는 각 역할이 작성해야 할 문서를 친절하게 Tailoring 해 주기도 하고 그들이 문서 관리자의 역할을 하기도 한다. 

 

프로젝트 단계에서는 작성해야 할 문서의 유형이 다양하기에 문서의 종류를 나열하기 보다는 프로젝트의 관리 요소를 정리해 보고 그 단계에서 필요로 하는 문서를 가늠해 보기로 하겠다.

1. 통합관리 (프로젝트 평가와 타당성 검토 _ 프로젝트 발의서, 투자 제안서 등이 여기 포함된다.)
2. 범위관리
3. 일정관리
4. 비용관리
5. 리소스관리
6. 인적자원관리
7. 의사소통관리
8. 리스크관리
9. 품질관리
10. 조달/계약관리

대락적으로 프로젝트는 10대 관리 항목으로 구분될 수 있다. 굉장히 많은 문서들이 복잡하게 많이 필요해 보이지만 꼭 필요한 몇 가지만 정리하면 아래와 같다. (이 역시 내 경험치 일 뿐, 프로젝트 유형과 규모별로 상이할 수 있다.)

• 요구사항 분석서, 기능 명세서, WBS, 제품 사양서, UI 화면 기획서, 테스트 케이스, 테스트 시나리오 등

특이한 건, 프로젝트 단계에서 기획자들이 작성하고 관리하는 문서들은 앞선 Pre Project의 단계보다 훨씬 더 많이 그리고 자주 버전이 업데이트 되기에 이때부터는 MS 프로젝트, JIRA 등의 상용 SW를 활용하거나 기업별로 자신들이 운영하는 프로젝트 특성에 맞게 PMS(Project Management System)를 구축하여 사용하기도 하고 작은 조직의 경우는 SaaS 기반의 협업 SW를 사용하는 등 시스템의 도움을 받아야 한다. 

---

마지막은 Post-Project 단계이다. 외부 프로젝트였다면 산출물을 정리하여 고객에게 인도하거나 유지보수를 위한 정비에 들어가야 할 때이고 내부 프로젝트였다면 이제 본격적으로 운영(Operation)에 이르게 될 것이다.

 

내부 프로젝트라면 요즘은 DevOps라 하여 개발 프로젝트와 운영을 굳이 나누지 않는 경우가 있고, Agile 방법론, Lean Process 등 다양한 방법론과 프로세스 등이 현업에서 사용되고 있기에 Post Project 없이 지속적으로 On-Going 하는 경우도 많은데, 어쨌든 프로젝트가 종료되면 기업 내부에는 Lessons Learned를 위한 문서들을 저장하여 두고 추후, 운영 인력들의 교육 자료나 운영 매뉴얼 등으로 사용될 수 있어야 한다. 

 

앞서서 언급한 최소한의 모든 문서는 최종 자료로 프로젝트 종료 시에 기록되어야 하고 특별히 아래의 문서를 종료 시에 남기기도 한다.

• 회고록, Lessons Learned, 운영 매뉴얼 등  

---

기획의 모든 유형과 단계는 중요하다.

그 중에서 표현의 단계가 무엇보다 중요한 건, 표현의 목적이 커뮤니케이션(의사소통)에 있기 때문이다. 사소한 여행계획일지라도 여행에 참여하는 모든 이의 만족을 위해서는 공감과 동의의 과정이 필요하다.

 

음악가가 노래로 표현하고, 화가와 화폭에 그림을 그리듯. 자신의 착상과 구상된 아이디어를 얼만큼 좋은 데이터와 시나리로 표현하느냐는 기획자의 자질을 가르는 근본이 될 것이다. 

 

다음은 좋은 기획서를 찾아 함께 공유하는 포스트를 작성해 보겠다.

"측정할 수 없는 것은 관리할 수 없다." - 피터 드러커

 

 

- DeungZan ('25년 1월 13일) -