제안서 실습: 두 판 사이의 차이
편집 요약 없음 |
|||
| 98번째 줄: | 98번째 줄: | ||
[[category: | [[category: 업무]] | ||
2025년 10월 14일 (화) 01:16 기준 최신판
제안서 작성의 과정과 제안서를 AI활용을 위한 과정 검토
기준 사항 설정 및 확인
설득력 있는 프로젝트 제안서를 작성하기 위한 6단계 by Asana
- 용어의 이해
- 프로젝트 제안서 - 프로젝트 개시 단계, 이해관계자에게 납득 시키려는 의도 (RFP에서는 제외)
- 프로젝트 헌장 - 프로젝트 목적을 정의하는 참조 문서 (프로젝트 승인후 생성)
- 참고: 비즈니스 케이스 - 프로젝트의 추가 자금을 확보하기 위해 비즈니스 케이스 사용하는 경우
- 요청형 (Solicited): RFP(제안서 요청)에 대한 응답으로 요청형 제안서를 보낼 수 있습니다. RFP는 프로젝트를 자세하게 소개하며 검증된 팀으로부터 입찰을 요청합니다. 다른 회사와 경쟁하는 것이기 때문에, 이 유형의 제안서는 철저한 조사를 실시한 후 설득력 있게 작성해야 합니다.
- 비요청형(Unsolicited): RFP 없이 요청하지 않은 제안서를 보내는 유형을 말합니다. 이와 같은 경우는 다른 회사나 팀과 경쟁하는 것은 아니지만 제안서를 전달하려는 이해관계자가 본인의 팀을 필요로 하는지 알지 못하기 때문에 제안서를 설득력 있게 작성해야 합니다.
- 비공식형(Informal): 클라이언트가 프로젝트 제안서를 비공식적으로 요청하는 경우, 이는 공식적인 RFP가 아니기 때문에 규칙이 확실히 정해져 있지 않으므로 프로젝트 피치로 응답할 수 있습니다.
- 갱신형(Renewal): 조직이 제공하고 있는 서비스 기간을 연장하기 위해 기존 클라이언트에게 갱신형 제안서를 보낼 수 있습니다. 이 유형의 프로젝트 제안서의 목적은 팀이 클라이언트를 위해 만들어온 이전의 결과를 강조하여 미래의 결과를 만들어 낼 수 있다는 것을 설득하는 것입니다.
- 연속형(Continuation): 이해관계자에게 프로젝트가 시작된다는 것을 상기시키기 위해 연속형 제안서를 보낼 수 있습니다. 이 유형의 프로젝트 제안서에서는 이해관계자를 설득하는 것이 아니라 단순히 정보를 제공합니다.
- 보충형(Supplemental): 연속형과 비슷하게, 보충형 제안서는 프로젝트에 참여하는 이해관계자에게 보내는 것입니다. 이 유형의 제안서에서는 이해관계자에게 프로젝트가 시작한다는 것을 알리는 동시에 추가 리소스를 요청합니다. 이 제안서에서 이해관계자가 프로젝트에 리소스를 더 투입하도록 설득해야 합니다.
유형에 상관없이 대부분의 프로젝트 제안서에 적용할 수 있습니다. 대상으로 하는 청자를 위해 제안서를 알맞게 조정해야 하는데, 제안서에 핵심 구성 요소를 포함했는지 확인하기 위한 참조 자료로 이 프로젝트 제안서를 사용할 수 있습니다.
이 핵심 요약 부분은 앞으로의 내용을 요약하고 이해관계자가 계속 읽도록 설득해야 합니다. 핵심 요약은 프로젝트가 얼마나 복잡한지에 따라, 한 문단이 될 수도 있고 여러 문단이 될 수 있습니다. 처음에 작성하거나, 최종 작성 후 만들 수 있음. 프로젝트 헌장 고려.
- 핵심 요약은 다음 사항을 포함해야 합니다.
- 프로젝트가 해결하려고 하는 문제
- 해당 문제에 대해 프로젝트에서 제공하는 해결책
- 프로젝트가 미칠 영향
프로젝트의 배경에 대해 자세히 설명해야 합니다. 참조 자료와 통계 자료를 사용하여 언급하고 있는 문제가 다룰 만한 가치가 있다는 것에 대해 제안서를 읽고 있는 사람을 납득시켜야 합니다.
- 포함해야 하는 몇 가지 질문은 다음과 같습니다.
- 프로젝트에서 해결하려는 문제는 무엇인가?
- 이 문제에 대해서 이미 알려진 것은 무엇인가?
- 이전에 이 문제를 다룬 사람이 있었는가? 어떤 조사가 이루어졌는가?
- 과거에 진행된 조사가 이 문제를 해결하기 부족했던 이유는 무엇인가?
프로젝트 배경 섹션에서 문제를 제시했으니, 다음 단계로 적합한 것은 해결책 제시하기입니다. 이 섹션은 프로젝트 접근 방식에 대해 더 자세히 설명할 수 있는 기회입니다.
다음은 포함해야 하는 몇가지 항목입니다.
- 프로젝트에 대한 비전 선언문
- 중요한 마일스톤이 포함된 프로젝트 일정
- 프로젝트 팀의 역할과 책임 업무
- 리스크를 완화 방안을 보여주는 리스크 관리 대장
- 프로젝트 결과물
- 프로젝트를 진행하는 동안 사용할 보고 툴
제안서 서식에 위 항목 중 없는 항목이 있을 수도 있지만, 프로젝트 범위에 따라 무엇을 포함할지 결정하면 됩니다. 이 섹션은 제안한 해결책을 달성하는 것과 관련한 모든 것을 논의하는 부분이기 때문에 아마도 제안서에서 가장 길고 가장 자세한 섹션이 될 것입니다.
프로젝트 제안서를 작성하는 데 있어 프로젝트 결과물을 정의하는 단계는 매우 중요합니다. 이해관계자는 제품, 프로그램, 기술 업그레이드, 혹은 다른 무언가가 되었든 간에, 프로젝트가 종료될 때 무엇을 생산할지 알고 싶어 합니다. 이해관계자가 비전을 읽어 나갈 때, 이 섹션은 자신의 리소스가 무엇을 위해 사용되는지 명확하게 알게 되는 섹션입니다.
결과물을 정의할 때, 다음을 포함해야 합니다.
프로젝트의 최종 결과물 또는 최종 목표
결과물이 언제 준비되는지 보여주는 프로젝트 타임라인
만들어 내는 결과물에 부합하는 SMART 목표
프로젝트에서 다루는 문제와 그 해결책을 제시하는 것도 중요하지만, 결과물을 정의할 수 있을 때, 이해관계자는 프로젝트를 시각화하기 수월해집니다.
문제, 접근법, 해결책 및 결과물에 대한 개요를 서술했으면, 이니셔티브를 달성하기 위해 어떤 리소스가 필요한지 자세하게 설명할 차례입니다.
이 섹션에는 다음 사항을 포함합니다.
- 프로젝트 예산: 프로젝트 예산은 제품 만들기에 필요한 지급품부터 광고비와 급여에 이르는 모든 것을 포함합니다. 이 섹션에는 프로젝트를 달성하는 데 필요한 모든 예산 항목을 포함해야 합니다.
- 비용 분석: 이 섹션에서는 프로젝트에 특정 리소스가 필요한 이유를 조사한 내용을 포함해야 합니다. 조사 내용을 포함하면, 이해관계자는 승인하는 리소스가 무엇을 위해 사용되는지 이해할 수 있습니다. 비용 분석은 예상치 못한 비용이 생기는 것을 방지할 수도 있습니다.
- 리스소 할당 계획: 필요한 특정 리소스를 어디에 사용할 계획인지를 개략적으로 설명하는 리소스 할당 계획 개요를 포함해야 합니다. 예를 들어, 프로젝트를 완료하는 데 $50,000가 필요하다고 판단되면, 급여, 기술, 자료 등에 이 금액을 할당하는 계획을 세워야 합니다.
제안서의 이 지점에 이르면 제안하는 프로젝트에 이해관계자가 참여하도록 설득하는 것에 성공했길 바랍니다. 이는 제안서의 마지막에서 필요한 리소스를 다루는 것이 현명한 전략이 될 수 있는 이유이기도 합니다.
마지막으로, 설득력 있고 자신감 있는 결론으로 프로젝트 제안서를 마무리합니다. 핵심 요약과 마찬가지로, 결론은 프로젝트에서 다루는 문제와 그 문제를 해결하는 방법에 대해 간단하게 요약해야 합니다. 결론에서 프로젝트의 영향을 강조할 수 있지만 에세이를 작성하는 것과 마찬가지로, 관련성을 유지해야 합니다.
참조: 제안작업 계량화