훌륭한 프로젝트 브리프는 프로젝트가 시작되기 전에 모두를 같은 페이지로 맞춰 줍니다. 무엇을 만들고, 왜 중요한지, 누가 참여하는지, 그리고 성공을 어떻게 측정할지까지요. Trupeer를 사용하면 무료 프로젝트 브리프 템플릿으로 시작해 브랜드 아이덴티티로 커스터마이즈한 뒤, 브리프를 이해관계자가 3분 만에 볼 수 있는 짧은 비디오 요약으로 바꿔 프로젝트 브리프 작성에 드는 시간을 몇 시간이나 절약할 수 있습니다.

프로젝트 브리프 템플릿이란 무엇이며, 언제 작성하나요?

프로젝트 브리프는 계획이 존재하기도 전에 프로젝트의 맨 처음에 작성되는 짧은 문서로, 프로젝트가 무엇을 위한 것인지, 지금 왜 중요한지, 누에게 영향을 미치는지, 성공이 어떤 모습인지, 그리고 무엇이 이를 제약하는지를 명시합니다.

이 문서는 작업을 승인하기 위해 사람들이 서명하는 대상이며, 6개월 뒤 모두가 그 문서를 근거로 논쟁하게 되는 기준점이 됩니다. 정보가 가장 적은 시점에 작성되기 때문에 의도적으로 짧게, 보통 1~2페이지로 구성합니다.

템플릿은 섹션을 제공합니다. 배경, 목표, 범위, 산출물, 일정, 예산, 이해관계자, 성공 기준. 여러분이 보게 될 모든 버전은 대체로 이런 구성이며, 그 자체로 문제는 없습니다.

브리프의 문제는 거의 결코 섹션이 아닙니다. 그 섹션 안에 무엇을 담느냐의 문제입니다.

대부분의 브리프는 문제를 말하지 않고 해결책을 말합니다

다음은 모든 딜리버리 팀, 에이전시, 엔지니어링 그룹이 브리프에 대해 하는 불만입니다. 업계마다 같은 방식으로 표현되죠. “우리는 해결책에 대해 브리핑을 받았습니다.”

“고객 포털을 구축하세요.” “새 인트라넷을 만드세요.” “모바일 앱을 제공하세요.” “온보딩 플로우를 재설계하세요.” 각각은 만들어야 할 무언가이지만, 마치 요구사항인 것처럼 도착합니다. 하지만 실제로는 브리프가 한 번도 제시하지 않은 질문에 대한 누군가의 답일 뿐입니다.

이런 일이 생기는 데는 나름의 합리적인 이유가 있습니다. 프로젝트를 의뢰하는 쪽은 보통 몇 주 동안 그 내용을 생각해 왔고 결론에 도달해 있습니다. 결론을 쓰는 건 명확해 보이고, 문제를 쓰는 건 막연해 보이기 때문입니다.

대가는 있습니다. 아무도 살펴보기 전에 가장 저렴한 해결책이 배제됩니다. 브리프가 “포털”이라고 말하는 순간, 프로젝트는 포털 프로젝트가 되고, 돈의 5%로 문제의 80%를 해결했을 선택지는 아무도 평가해 달라고 요청하지 않았기 때문에 끝내 평가되지 않습니다.

문제를 명시한 브리프는 답을 불러옵니다. 해결책을 명시한 브리프는 견적을 불러옵니다.

Trupeer에서 이 템플릿을 커스터마이즈하는 방법

1단계: 템플릿 섹션 열기

메인 내비게이션에서 템플릿 섹션으로 이동하세요.

2단계: 템플릿 선택 후 열기

작업하려는 템플릿을 클릭해 열어 주세요.

3단계: 템플릿 보기 확장

필요한 경우 템플릿 보기를 확장해 전체 레이아웃과 세부 정보를 더 명확하게 확인하세요.

4단계: 템플릿 편집

편집을 클릭해 선택한 템플릿을 수정하기 시작하세요.

편집기에서 다음을 할 수 있습니다.

• 새 섹션 추가

• 서식 규칙 정의 또는 업데이트

• 로고를 추가하고 위치 및 관련 설정을 조정

5단계: 커스터마이즈한 템플릿 저장

필요한 모든 변경을 마친 후 저장을 클릭해 업데이트된 템플릿을 본인만의 템플릿으로 저장하세요.

6단계: 미리보기 및 템플릿 미세 조정

커스터마이즈한 템플릿이 어떻게 보이는지 확인하려면 미리보기를 여세요.

미리보기 화면에서 필요하다면 직접 계속 조정할 수 있어, 템플릿이 원하는 그대로 정확히 표시되도록 할 수 있습니다.

프로젝트 브리프 템플릿으로 할 수 있는 것:

• 작성에 드는 시간을 절약: 검증된 브리프 구조로 빈 페이지를 건너뛰세요.

• 이해관계자를 빠르게 정렬: 1페이지 브리프로 승인과 합의가 더 빨라집니다.

• 브랜드에 맞게 유지: Trupeer의 브랜드 키트를 사용해 로고, 폰트, 색상을 적용하세요. 에이전시 및 클라이언트 브리프에 완벽합니다.

• 임팩트 있게 제안: 브리프를 비디오 요약으로 전환하세요. 세일즈 enablement와 이해관계자 대상 피치에 특히 좋습니다.

• 프로젝트 전반을 표준화: 모든 이니셔티브에 동일한 브리프 형식을 사용하세요.

• 글로벌 팀에 도달: 한 번의 클릭으로 브리프를 65개+ 언어로 번역하세요.

모든 프로젝트 브리프에 필요한 세 가지 답 테스트

2분이면 충분하며, 실행할 가치가 있는 유일한 브리프 테스트입니다.

브리프를 읽고, 이를 만족시킬 수 있는 진짜로 서로 다른 세 가지를 이름으로 말해 보세요.

같은 것의 변형 세 가지가 아닙니다. 서로 다른 세 가지 접근 방식입니다. 무언가를 구축하기, 프로세스를 바꾸기, 무언가를 구매하기, 단계를 제거하기, 다르게 커뮤니케이션하기, 더 적게 하기.

세 가지를 말할 수 있다면, 브리프는 문제를 설명하고 있으며, 프로젝트 앞에는 실제 의사결정이 놓여 있는 것입니다.

하나만 말할 수 있다면, 브리프는 해결책을 설명하는 것입니다. 이것이 자동으로 틀린 건 아닙니다. 때로는 의사결정이 정말로 좋은 이유로 이미 내려졌을 수도 있고, 그 경우에는 솔직하게 그렇게 말하고 문서를 브리프가 아니라 명세서(specification)라고 부르는 것이 정직합니다. 정직하지 않은 것은, 이미 정해진 결론을 열린 질문처럼 제시한 뒤 아무도 이의를 제기하지 않는다는 사실에 놀라는 것입니다.

브리프가 배포되기 전에, 그리고 작성에 참여하지 않은 누군가와 함께 이 테스트를 실행해 보세요. 작성자는 항상 세 가지를 말할 수 있습니다. 자신이 무엇을 거절했는지 알기 때문입니다. 다른 누구도 말할 수 없는 이유는, 브리프에 그것이 들어 있지 않기 때문입니다.

산출물이 아니라 문제를 쓰는 방법

네 가지 습관이며, 그중 어느 것도 해결책을 쓰는 것보다 오래 걸리지 않습니다.

관찰과 숫자로 시작하세요. “고객이 주문을 확인하기 어렵다”가 아니라 “지난달 고객이 주문이 어디 있는지 확인하려고 우리에게 6,700번 연락했다”처럼요. 숫자는 두 가지를 합니다. 문제는 실제로 존재한다는 점을 확립하고, 해결책이 가치를 가질 수 있는 규모를 정합니다.

지금 무엇이 일어나는지 말하세요. 문제는 현재 어떻게 처리되고 있는지, 나쁘게 처리되고 있는지, 그리고 사람들이 만들어 낸 우회 방법(임시 해결책)까지 포함해 설명하세요. 현재 상태 설명은 누군가가 더 저렴한 답을 제안할 수 있게 해 줍니다.

제약을 요구사항과 분리하세요. 예산은 제약입니다. 마감일도 제약입니다. 기존 창고 시스템과 반드시 통합해야 한다는 것도 제약입니다. “반드시 로그인해야 한다”는 요구사항을 제약처럼 위장한 것이며, 보통 누군가의 머릿속 해결책 이미지에서 비롯됩니다.

성공을 산출물의 존재가 아니라 ‘숫자의 변화’로 정의하세요. 예를 들어 6개월 안에 해당 연락을 절반으로 줄이는 것이 성공 기준입니다. 포털 출시(portal launch)는 마일스톤입니다.

진짜로 해결책을 이미 염두에 두고 있다면, 브리프가 아니라 ‘후보(candidate)’로서 명확히 라벨링된 섹션에 넣어 두세요.

무료 프로젝트 브리프 템플릿: 복사해서 쓰는 구조

여기서 복사하세요. 1~2페이지로 작성하고, 분량이 늘어나지 않도록 하세요.

헤더. 프로젝트명, 후원자, 작성자, 날짜, 버전, 그리고 요청하는 의사결정.

문제. 숫자가 포함된 관찰, 발생 빈도, 그리고 그 비용. 2~3문장.

현재는 어떻게 처리하나요. 현재 프로세스(우회 방법 포함)와 왜 충분하지 않은지.

왜 지금인가요. 다음 해가 아니라 이번 분기에 이 일을 해야 할 만큼 긴급하게 만든 변화는 무엇인지.

누가 영향을 받나요. 관련된 사람 또는 고객, 그리고 대략적인 규모.

성공 기준. 어떤 숫자가 얼마나, 언제까지 움직여야 하는지. 결과(outcome)로 1~2개 제시하세요.

제약. 예산, 마감일, 변경할 수 없는 시스템, 규제 또는 계약상 의무, 사용 가능하지 않은 인력. 정말로 고정된 것은 모두 포함하고, 실제로는 선호에 불과한 것은 포함하지 마세요.

범위 제외(Out of scope). 이 프로젝트가 다루지 않을 내용. 논쟁이 될 만큼 충분히 구체적으로 명시하세요.

후보 접근 방식(해당되는 경우). 이미 고려된 해결책을 브리프가 아니라 ‘후보’로 명확히 라벨링하고, 각 해결책이 목록에 포함된 이유를 적으세요.

요청하는 의사결정과 이를 내리는 사람. 무엇을 승인받고 있는지, 그리고 누가 승인하는지.

여기까지 복사하세요. 브리프가 2페이지를 넘는다면 보통 원인은 배경인데, 이는 아무도 읽지 않을 부록에 들어가도 괜찮습니다.

아무도 등록하지 않은 포털을 만든 소매업체

Ashfold Group은 약 90개의 매장을 가진 전문 소매업체이며, 규모 있는 온라인 사업도 운영하고 있습니다.

브리프는 2페이지였고 글도 잘 쓰여 있었으며, 별다른 어려움 없이 승인되었습니다. 내용은 이랬습니다. 고객이 로그인해 주문 상태를 확인하고, 인보이스를 다운로드하며, 문의를 제기할 수 있는 고객 셀프서비스 포털을 구축하세요. 예산은 34만 파운드. 기간은 9개월.

정해진 일정에 맞춰 예산에도 거의 근접하게, 37만 1천 파운드로 납품했습니다.

출시 후 6개월이 지나자 등록 계정은 약 4만 6천 명의 활성 고객 중 3,100개였으므로 7% 미만이었습니다. 서비스 센터로의 연락량은 변하지 않았습니다.

사후 구현 검토(post-implementation review)에서 나온 질문은 간단했습니다. “이 포털은 어떤 문제를 해결하려고 만든 건가요?” 아무도 브리프에서 그 문제를 짚어낼 수 없었습니다. 브리프가 해결책을 설명했기 때문입니다.

그래서 누군가가 문제를 찾아 나섰습니다. 서비스 센터는 한 달에 약 1만 1천 건의 연락을 처리하고 있었습니다. 500건 샘플을 보니 61%가 “내 주문이 어디 있나요”의 어떤 형태였고, 이는 한 달에 약 6,700건에 해당했습니다.

그중 84%의 고객은 이미 추적 링크(tracking link)가 포함된 발송 이메일을 받아 본 적이 있었습니다. 둘 중 하나였죠. 그 이메일을 보지 못했거나, 링크가 14일 후 만료된 뒤에 다시 돌아와 확인했을 가능성이었습니다.

따라서 가장 큰 문제는 고객이 확인할 방법이 없었다는 점이 아니었습니다. 이미 가지고 있던 방식이 제대로 작동하지 않았다는 점이었습니다.

더 저렴한 세 가지 접근 방식은 한 번도 평가되지 않았습니다. 브리프가 어떤 것도 초대하지 않았기 때문입니다. 추적 링크의 유효 기간을 연장하기. 배송될 때까지 일정에 맞춰 링크를 다시 보내기. 이미 존재하던 계정 영역에 주문 상태를 추가하기(추후 약 1만 8천 파운드로 추정).

포털은 실제 문제에 대한 정당한 해결책이었습니다. 다만 가장 큰 문제는 아니었고, 등록이 필요했는데 고객의 93%는 등록을 하지 않았습니다.

후속 프로젝트에 대한 브리프는 다르게 작성되었습니다. 고객은 한 달에 6,700번 우리에게 연락해 “내 주문이 어디 있는지”를 묻습니다. 그중 84%는 이미 추적 링크를 받아 본 적이 있습니다. 6개월 안에 이러한 연락을 절반으로 줄이세요. 제약: 운송사(carrier) 통합에는 변경이 없어야 하며, 예산은 15만 파운드입니다. 그리고 고객이 등록을 하지 않아도 작동해야 합니다.

세 팀이 각각 정말로 다른 세 가지 답을 제안했습니다. 선택된 안은 6만 2천 파운드가 들었고, 5개월 안에 해당 연락을 58% 줄였습니다.

두 브리프의 차이는 두 번째는 세 가지 방식으로 답할 수 있었던 반면, 첫 번째는 한 가지 방식으로만 답할 수 있었고 그 방식은 이미 선택되어 있었다는 점입니다.

모든 프로젝트 브리프에 필요한 핵심 요소

가장 무게를 싣는 두 줄은 현재 상태와 제약이며, 둘 다 보통 얇습니다. 현재 상태는 누군가가 저렴한 답을 제안할 수 있게 해 줍니다. 선호와 솔직하게 분리된 제약은 브리프가 우연히 명세서(specification)로 변하는 것을 막아 줍니다.

다섯 단계로 프로젝트 브리프 작성하기

1. 숫자가 포함된 문제를 쓰세요. 숫자를 구할 수 없다면, 오후 한나절을 투자해 숫자를 만들어 보세요. 숫자가 없는 브리프는 선호(preference)입니다.

2. 현재 상태를 설명하세요, 사람들이 오늘날 이를 어떻게 우회하는지도 포함해요.

3. 성공을 그 숫자의 변화로 설정하세요, 날짜와 함께요.

4. 제약을 나열하고 각각에 이의를 제기하세요. 각 항목마다 “누가 이것을 고정했으며, 바뀔 수는 없을까?”를 물어보세요. 대략 3분의 1은 보통 바뀔 수 있고, 바뀔 수 있는 제약 하나하나는 가능한 답의 범위를 넓혀 줍니다.

5. 세 가지 답 테스트를 실행하세요 작성하지 않은 누군가와 함께요. 실패한다면 브리프를 열어 주거나 문서를 솔직하게 다시 라벨링하세요.

그다음 배포하세요. 돌아오는 답변에는 여러분이 생각하지 못했던 최소 한 가지가 포함될 거라고 기대하세요. 그중 어떤 것도 놀랍지 않다면, 브리프는 아마도 명세서였을 가능성이 큽니다.

제약과, 그것이 요구사항으로 몰래 들어오는 방식

여기가 대부분의 브리프가 조용히 명세서로 변하는 지점이며, 의도한 사람이 아무도 없는데도 그렇게 됩니다.

진짜 제약은 프로젝트의 통제 밖에 있는 무언가입니다. 예산은 예산 그대로입니다. 규제 마감일은 고정되어 있습니다. 올해는 창고 시스템을 교체하지 않습니다. 팀에는 4명이 있습니다.

제약처럼 보이지만 사실은 선호인 경우는 똑같이 들립니다. “모바일 앱이어야 합니다.” “대시보드가 필요합니다.” “사용자는 로그인을 해야 합니다.” 각각은 누군가의 머릿속 해결책 이미지이고, 제약 섹션에 들어가면 이후 단계에서는 모두가 그것을 움직일 수 없는 것으로 취급합니다.

테스트는 각 항목마다 “누가 이걸 결정했는지, 그리고 이것이 바뀌면 어떻게 되는지”를 묻는 것입니다. 진짜 제약에는 프로젝트 밖의 오너가 있고, 위반 시 결과(consequence)가 있습니다. 선호는 둘 다 없으며, 보통 작성자는 직접 물어보면 기꺼이 그것을 내려놓습니다.

브리프가 배포되기 전에 그 대화를 먼저 해 보세요. 20분이면 되고, 전체 프로젝트에서 가장 가치 있는 20분인 경우가 많습니다. 왜냐하면 제거되는 제약마다 가능한 답이 하나씩 늘어나기 때문입니다.

프로젝트 브리프, 비즈니스 케이스, 프로젝트 플랜 중 무엇인가요?

프로젝트 시작 시점에 순서대로, 서로 다른 역할을 하는 세 가지 문서가 있습니다.

브리프는 문제, 제약, 성공 기준을 명시합니다. 먼저 작성하며 짧고, 조사를 진행하거나 딜리버리(제공)를 승인하는 문서입니다.

비즈니스 케이스는 지출을 정당화합니다. 비용과 이점이 포함된 옵션을 담고, 재무 기능 또는 투자 위원회가 승인하는 문서입니다. 길어지고 숫자로 가득 찬 브리프는 보통 잘못된 이름을 쓴 비즈니스 케이스입니다.

프로젝트 플랜은 선택한 접근 방식이 어떻게 제공되는지(범위, 일정, 리소스, 의존성, 리스크)를 다룹니다. 저희의 IT 프로젝트 플랜 템플릿이 그 레이어를 커버합니다.

순서는 중요합니다. 브리프, 그다음 옵션, 그다음 비즈니스 케이스, 그다음 플랜입니다. 브리프보다 먼저 플랜을 쓰는 것(누구도 인정하지 않지만 더 자주 일어납니다)은 문제를 말하기 전에 접근 방식이 이미 선택되었다는 뜻입니다.

플랜이 존재하게 되면, 브리프는 합의된 범위의 두 번째 근거로 파일에 그대로 두는 것이 아니라 명시적으로 대체(supersede)되어야 합니다. 권한을 주장하는 문서가 두 개라는 것은 범위 분쟁이 해결 불가능해지는 방식입니다.

프로젝트 브리프 변형: 크리에이티브, 디자인, 소프트웨어, 건설

구조는 유형 전반에 걸쳐 유지되며, 강조점만 달라집니다.

크리에이티브 및 마케팅 브리프에는 타깃 오디언스와 메시지가 필요하며, 클라이언트가 특정 형식을 염두에 두고 오기 때문에 해결책 중심 브리핑(solution-briefing)에 가장 취약합니다. 여기서의 문제는 보통 만들고 싶은 ‘무언가’라기보다 바꾸고 싶은 ‘행동’인 경우가 많습니다.

디자인 브리프에는 사용자, 사용 맥락, 기존 시스템의 제약이 필요합니다. 이 카테고리의 거의 모든 브리프는 세 가지 답 테스트의 혜택을 받습니다. 레이아웃을 지정하는 디자인 브리프는 디자인을 제거해 버리기 때문입니다.

소프트웨어 프로젝트 브리프는 무엇보다도 문제와 현재의 우회 방법이 필요하며, 기능(features)에는 아예 선을 긋고 명확히 해야 합니다. 기능이 범위에 들어가면 요구사항 문서를 쓰는 것이고, 이는 저희의 lean PRD 템플릿에서 다룹니다.

건설 및 디자인 브리프에는 실제로 제약인 것들이 포함됩니다. 현장, 플래닝, 규제, 예산. 여기서는 제약 섹션이 리스크가 아니라 본질입니다.

조달 비중이 큰 프로젝트는 명세서가 아니라 결과(outcome)로서 무엇을 구매하는지 브리프에 명시해야 합니다. 명세서 성숙도(specification maturity) 결정은 나중에 내려지며, 이는 저희의 조달 관리 플랜 템플릿에서 다룹니다.

Word나 Excel로 프로젝트 브리프 템플릿을 받을 수 있나요?

Word 또는 Google Docs. 브리프는 글(산문)이며 1~2페이지로 작성되고, 승인 전에 코멘트를 달 수 있습니다. 스프레드시트를 원할 만한 요소는 없습니다.

Excel은 여러 프로젝트를 운영하고 등록(register)을 원할 때에만 자리를 잡습니다. 예: 프로젝트, 후원자, 문제를 한 줄에, 성공 기준, 예산에 대한 제약, 상태, 승인 날짜. 이 등록은 다른 방식으로는 보이지 않는 패턴을 발견하는 데 정말 유용합니다. 즉, 여러분의 프로젝트 중 상당수가 숫자가 아니라 산출물로 표현된 성공 기준을 갖고 있다는 사실을 빠르게 찾아낼 수 있습니다.

승인된 버전은 PDF로 내보내세요(사인오프 시점에). 브리프는 이후 분쟁의 기준점이 되기 때문에, 대부분의 문서보다 여기서는 승인 버전을 날짜와 함께 고정(freeze)하는 것이 더 중요합니다.

PowerPoint는 담기(컨테이너)로는 좋지 않습니다. 슬라이드로 브리프를 제시하면, 이 페이지 전반에서 설명한 것과 같은 이유로 문제 진술을 잃고 해결책만 남기기 쉽습니다.

설명하기보다 문제를 보여주는 방법

좋은 브리프에서 가장 어려운 부분은, 그 문제를 직접 겪지 않은 사람들에게도 문제를 ‘현실처럼’ 느끼게 만드는 것입니다. 숫자는 도움이 됩니다. 단락(paragraph)은 거의 도움이 되지 않습니다.

거의 아무도 쓰지 않는 저렴한 대안이 하나 있습니다. 문제 상황을 실제로 기록하는 것입니다.

서비스 에이전트가 “주문이 어디 있는지”를 묻는 전화를 처리하는 2분, 또는 누군가가 고장 난 단계를 세 개의 브라우저 탭과 스프레드시트로 우회하는 2분은, 한 페이지의 설명보다 더 많은 것을 전달하며 설득하기도 매우 어렵습니다. 브리프에 첨부하세요.

Trupeer AI는 이를 쉽게 만들어 줍니다. 화면 녹화가 현재 프로세스에 대한 비디오이자 서면 워크스루(written walkthrough)가 되기 때문입니다. 이는 브리프의 ‘현재 상태(current state)’ 섹션에 정확히 필요한 형태입니다. 또한 나중에 몇 달 뒤 브리프의 문구에만 의존하지 않고, 딜리버리 팀이 접근 방식 사이에서 결정을 내릴 때 참고할 수 있는 자료도 제공합니다.

기록하세요. 브랜딩하세요. 번역하세요. Trupeer하세요.

같은 녹화본은 프로젝트가 실제로 잘 작동했는지 측정할 때 ‘이전(before) 상태’로도 유용합니다. 자료는 일관된 브랜딩으로 지식 베이스에 보관하고, 설정 지침은 문서 템플릿 설정 가이드에 있습니다.

자주 묻는 질문

Word에서 무료 프로젝트 브리프 템플릿을 사용할 수 있나요?

위의 구조는 Word 또는 Google Docs에 그대로 붙여 넣을 수 있습니다. 잠금 해제 다운로드도 없고, 폼도 없습니다. 먼저 작성해야 하는 두 섹션은 숫자가 포함된 문제와 제약입니다. 나머지는 모두 여기서부터 나오며, 이 두 가지가 템플릿에서 가장 약하게 처리되는 부분이기 때문입니다.

Excel에서 무료 프로젝트 브리프 템플릿을 사용할 수 있나요?

Excel은 개별 브리프보다 포트폴리오 전반의 브리프 등록(register)에 더 적합합니다. 프로젝트, 후원자, 문제를 한 줄에, 성공 기준, 예산 제약, 상태, 승인 날짜. 이 등록을 훑어보며 산출물로 표현된 성공 기준을 찾는 것은, 측정 가능한 결과가 없는 프로젝트가 무엇인지 빠르게 파악하는 방법입니다.

PDF로 된 프로젝트 브리프 샘플은 어디에서 찾을 수 있나요?

공공 부문 기관 및 보건 관련 조직 등에서 공개된 샘플을 쉽게 찾을 수 있으며, 섹션 순서 관점에서 읽어볼 가치가 있습니다. 공개된 브리프의 상당수가 해결책 중심 브리프이기 때문에, 비판적으로 읽어 보세요. 이 페이지가 다루는 습관을 무비판적으로 강화할 수 있습니다.

프로젝트 브리프는 얼마나 길어야 하나요?

1~2페이지입니다. 더 긴 브리프는 보통 부록에 들어가야 할 배경을 담고 있거나, 비즈니스 케이스를 흡수해 버린 경우입니다. 후원자가 5분 안에 읽을 수 없다면 훑어보게 되고, 먼저 훑어본 섹션이 문제 진술이 됩니다.

프로젝트 브리프는 누가 작성해야 하나요?

후원자 또는 문제를 소유한 사람이 작성하되, 배포 전에 딜리버리 측에서 읽어 보는 사람이 한 명 더 있어야 합니다. 두 번째 독자는 해결책 중심 브리핑을 잡아냅니다. 그렇지 않으면 누군가가 9개월 동안 잘못된 답을 만들게 될 가능성이 있기 때문입니다.

프로젝트 브리프와 크리에이티브 브리프의 차이는 무엇인가요?

대체로 구조가 아니라 ‘도메인’의 차이입니다. 크리에이티브 브리프는 타깃 오디언스, 메시지, 톤, 채널을 추가하며, 보통 에이전시를 위해 클라이언트가 작성합니다. 두 문서 모두 해결책 중심 브리핑으로 인해 동일한 문제를 겪고, 세 가지 답 테스트는 수정 없이 둘 다에 적용됩니다.

프로젝트 브리프는 언제 승인(사인오프)해야 하나요?

어떤 계획이나 산정도 시작되기 전에, 그리고 특히 누구도 접근 방식에 전념하기 전에 승인해야 합니다. 접근 방식이 선택된 뒤에 승인된 브리프는 형식에 불과하며, 나중에 범위가 분쟁될 때 도움이 되지 않습니다. 모두가 문서보다 접근 방식을 기억하기 때문입니다.

프로젝트 플랜이 생긴 뒤 브리프는 어떻게 되나요?

브리프는 명시적으로 대체되고 그렇게 표시되어야 하며, 플랜이 합의된 범위의 단일 근거가 되어야 합니다. 브리프를 두 번째 권한으로 계속 열어 두는 것이 범위 분쟁을 해결 불가능하게 만드는 이유입니다. 양측 모두 문서를 인용할 수 있기 때문이죠. 브리프는 어떤 문제를 해결하려 했는지 기록으로 남기세요. 이는 종료 시점에서 실제로 유용합니다.