프로젝트 제안서는 타임라인, 예산, 목적, 목표 등을 포함해 이해관계자가 프로젝트에 대해 알아야 할 모든 내용을 개략적으로 설명하기 위해 작성된 문서입니다. 프로젝트 제안서는 이해관계자가 이니셔티브를 승인할 수 있도록 프로젝트의 세부 사항을 잘 요약하고 아이디어를 설득력 있게 제시해야 합니다. 이 가이드에서는 승인을 얻어 목표한 바를 달성할 수 있도록 프로젝트 제안서를 작성하는 방법을 알려드립니다.
모든 프로젝트에는 창조 스토리가 있습니다. 하지만 누군가 ‘리소스가 있으라!’라고 선언한다고 해서 프로젝트가 시작되는 것이 아닙니다. 프로젝트를 진행하려면, 팀은 조직 내 의사결정권자 또는 외부 이해관계자에게 반드시 제안서를 제출해야 합니다.
프로젝트 제안서는 간략하면서도 효율적인 방식으로 프로젝트를 발표하는 것이 목적인 엘리베이터 피치를 문서로 만든 것과 같습니다. 이 가이드에서는 승인을 얻고 목표한 바를 이룰 수 있도록 프로젝트 제안서를 작성하는 방법을 알려드립니다.
프로젝트 제안서는 타임라인, 예산, 목표, 목적 등을 포함해 이해관계자가 프로젝트에 대해 알아야 할 모든 내용을 개략적으로 설명한 문서입니다. 프로젝트 제안서는 세부 사항을 잘 요약하고 아이디어를 설득력 있게 제시하여, 이해관계자가 이니셔티브에 참여하고 싶어지도록 만들어야 합니다.
프로젝트 제안서의 목표는 다음과 같습니다.
외부 자금 확보
프로젝트에 회사 리소스 배정
이해관계자 승인 얻기
추진력과 기대감 조성
프로젝트 제안서와 프로젝트 헌장은 프로젝트 생성 프로세스에서 서로 다른 목적으로 사용되기 때문에 이 둘의 차이점을 이해하는 것이 중요합니다. 프로젝트 제안서는 프로젝트의 개시 단계에서 사용되지만, 프로젝트 헌장은 계획 단계에서 사용됩니다.
위에 언급한 것처럼, 프로젝트 제안서는 프로젝트를 수행하는 이유를 이해관계자에게 납득시키려는 의도로 작성하는 설득력 있는 문서입니다. 프로젝트 헌장은 프로젝트 목적을 정의하는 참조 문서이며, 프로젝트 제안서가 승인되기 전에는 생성할 수 없습니다.
비즈니스 케이스와 프로젝트 제안서를 혼동하는 경우도 많은데, 비즈니스 케이스 역시 프로젝트 제안서를 작성한 후에 생성합니다. 프로젝트가 제안서를 통해 프로젝트가 승인되고 나면, 프로젝트의 추가 자금을 확보하기 위해 비즈니스 케이스를 사용할 수도 있습니다.
프로젝트 관리자가 접할 수 있는 프로젝트 제안서의 유형은 6가지입니다. 각기 다른 형식을 파악하고 있으면, 프로젝트 제안서를 작성할 때 유용할 수 있습니다. 각 유형마다 목적이 다릅니다.
요청형: RFP(제안서 요청)에 대한 응답으로 요청형 제안서를 보낼 수 있습니다. RFP는 프로젝트를 자세하게 소개하며 검증된 팀으로부터 입찰을 요청합니다. 다른 회사와 경쟁하는 것이기 때문에, 이 유형의 제안서는 철저한 조사를 실시한 후 설득력 있게 작성해야 합니다.
비요청형: RFP 없이 요청하지 않은 제안서를 보내는 유형을 말합니다. 이와 같은 경우는 다른 회사나 팀과 경쟁하는 것은 아니지만 제안서를 전달하려는 이해관계자가 본인의 팀을 필요로 하는지 알지 못하기 때문에 제안서를 설득력 있게 작성해야 합니다.
비공식형: 클라이언트가 프로젝트 제안서를 비공식적으로 요청하는 경우, 이는 공식적인 RFP가 아니기 때문에 규칙이 확실히 정해져 있지 않으므로 프로젝트 피치로 응답할 수 있습니다.
갱신형: 조직이 제공하고 있는 서비스 기간을 연장하기 위해 기존 클라이언트에게 갱신형 제안서를 보낼 수 있습니다. 이 유형의 프로젝트 제안서의 목적은 팀이 클라이언트를 위해 만들어온 이전의 결과를 강조하여 미래의 결과를 만들어 낼 수 있다는 것을 설득하는 것입니다.
연속형: 이해관계자에게 프로젝트가 시작된다는 것을 상기시키기 위해 연속형 제안서를 보낼 수 있습니다. 이 유형의 프로젝트 제안서에서는 이해관계자를 설득하는 것이 아니라 단순히 정보를 제공합니다.
보충형: 연속형과 비슷하게, 보충형 제안서는 프로젝트에 참여하는 이해관계자에게 보내는 것입니다. 이 유형의 제안서에서는 이해관계자에게 프로젝트가 시작한다는 것을 알리는 동시에 추가 리소스를 요청합니다. 이 제안서에서 이해관계자가 프로젝트에 리소스를 더 투입하도록 설득해야 합니다.
프로젝트 제안서의 내용과 어조는 보내려고 하는 제안서의 유형에 따라 달라집니다. 프로젝트 목표를 알고 있어야, 그에 따라 제안서를 작성할 수 있습니다.
참고: 실행 가능성을 입증하기 위한 개념 증명(POC)이 단계별 지침은 유형에 상관없이 대부분의 프로젝트 제안서에 적용할 수 있습니다. 대상으로 하는 청자를 위해 제안서를 알맞게 조정해야 하는데, 제안서에 핵심 구성 요소를 포함했는지 확인하기 위한 참조 자료로 이 프로젝트 제안서를 사용할 수 있습니다.
핵심 요약은 프로젝트 제안서를 소개하는 역할을 합니다. 보고서의 초록이나 에세이의 도입부와 비슷하게, 이 핵심 요약 부분은 앞으로의 내용을 요약하고 이해관계자가 계속 읽도록 설득해야 합니다. 핵심 요약은 프로젝트가 얼마나 복잡한지에 따라, 한 문단이 될 수도 있고 여러 문단이 될 수 있습니다.
핵심 요약은 다음 사항을 포함해야 합니다.
프로젝트가 해결하려고 하는 문제
해당 문제에 대해 프로젝트에서 제공하는 해결책
프로젝트가 미칠 영향
제안서에서 세부 사항을 나중에 더 자세하게 논의할 것이기 때문에 핵심 요약에서는 주제를 간단하게 언급해야 합니다.
이 섹션에서는 프로젝트의 배경에 대해 자세히 설명해야 합니다. 참조 자료와 통계 자료를 사용하여 언급하고 있는 문제가 다룰 만한 가치가 있다는 것에 대해 제안서를 읽고 있는 사람을 납득시켜야 합니다.
포함해야 하는 몇 가지 질문은 다음과 같습니다.
프로젝트에서 해결하려는 문제는 무엇인가?
이 문제에 대해서 이미 알려진 것은 무엇인가?
이전에 이 문제를 다룬 사람이 있었는가? 어떤 조사가 이루어졌는가?
과거에 진행된 조사가 이 문제를 해결하기 부족했던 이유는 무엇인가?
배경 설명 섹션에서 해결하고자 하는 문제가 조직과 직접적으로 어떤 관련이 있는지 설명할 수도 있습니다.
프로젝트 배경 섹션에서 문제를 제시했으니, 다음 단계로 적합한 것은 해결책 제시하기입니다. 이 섹션은 프로젝트 접근 방식에 대해 더 자세히 설명할 수 있는 기회입니다.
다음은 포함해야 하는 몇가지 항목입니다.
제안서 서식에 위 항목 중 없는 항목이 있을 수도 있지만, 프로젝트 범위에 따라 무엇을 포함할지 결정하면 됩니다. 이 섹션은 제안한 해결책을 달성하는 것과 관련한 모든 것을 논의하는 부분이기 때문에 아마도 제안서에서 가장 길고 가장 자세한 섹션이 될 것입니다.
프로젝트 관리를 위해 Asana를 사용해 보세요프로젝트 제안서를 작성하는 데 있어 프로젝트 결과물을 정의하는 단계는 매우 중요합니다. 이해관계자는 제품, 프로그램, 기술 업그레이드, 혹은 다른 무언가가 되었든 간에, 프로젝트가 종료될 때 무엇을 생산할지 알고 싶어 합니다. 이해관계자가 비전을 읽어 나갈 때, 이 섹션은 자신의 리소스가 무엇을 위해 사용되는지 명확하게 알게 되는 섹션입니다.
결과물을 정의할 때, 다음을 포함해야 합니다.
프로젝트에서 다루는 문제와 그 해결책을 제시하는 것도 중요하지만, 결과물을 정의할 수 있을 때, 이해관계자는 프로젝트를 시각화하기 수월해집니다.
문제, 접근법, 해결책 및 결과물에 대한 개요를 서술했으면, 이니셔티브를 달성하기 위해 어떤 리소스가 필요한지 자세하게 설명할 차례입니다.
이 섹션에는 다음 사항을 포함합니다.
프로젝트 예산: 프로젝트 예산은 제품 만들기에 필요한 지급품부터 광고비와 급여에 이르는 모든 것을 포함합니다. 이 섹션에는 프로젝트를 달성하는 데 필요한 모든 예산 항목을 포함해야 합니다.
비용 분석: 이 섹션에서는 프로젝트에 특정 리소스가 필요한 이유를 조사한 내용을 포함해야 합니다. 조사 내용을 포함하면, 이해관계자는 승인하는 리소스가 무엇을 위해 사용되는지 이해할 수 있습니다. 비용 분석은 예상치 못한 비용이 생기는 것을 방지할 수도 있습니다.
리스소 할당 계획: 필요한 특정 리소스를 어디에 사용할 계획인지를 개략적으로 설명하는 리소스 할당 계획 개요를 포함해야 합니다. 예를 들어, 프로젝트를 완료하는 데 $50,000가 필요하다고 판단되면, 급여, 기술, 자료 등에 이 금액을 할당하는 계획을 세워야 합니다.
제안서의 이 지점에 이르면 제안하는 프로젝트에 이해관계자가 참여하도록 설득하는 것에 성공했길 바랍니다. 이는 제안서의 마지막에서 필요한 리소스를 다루는 것이 현명한 전략이 될 수 있는 이유이기도 합니다.
마지막으로, 설득력 있고 자신감 있는 결론으로 프로젝트 제안서를 마무리합니다. 핵심 요약과 마찬가지로, 결론은 프로젝트에서 다루는 문제와 그 문제를 해결하는 방법에 대해 간단하게 요약해야 합니다. 결론에서 프로젝트의 영향을 강조할 수 있지만 에세이를 작성하는 것과 마찬가지로, 관련성을 유지해야 합니다.
위에 나열된 단계를 따르면 프로젝트 제안서에 알맞은 모든 요소를 갖출 수 있습니다. 그러나 이해관계자에게 깊은 인상을 남기고 승인을 얻으려면, 제안서가 뛰어나야 합니다. 위에 언급된 단계 외에도 프로젝트 제안서에 다음 사항을 포함할 수 있습니다.
제안서를 작성하면서 청자 즉, 이해관계자를 항상 염두에 두어야 합니다. 제안서의 목표는 단지 프로젝트 세부 사항을 제시하는 것이 아니라 이해관계자를 설득하는 것이라는 점을 명심하세요. 예를 들어, 어린이 책 출판사를 위한 새로운 편집 툴을 개발하고 있다면, 제품 승인을 설득할 때 감정적인 측면에 대해 호소할 수 있는지 판단할 수 있도록 이해관계자가 부모인지 파악해야 합니다.
프로젝트 제안서는 설득력이 있어야 합니다. 청자가 제안서를 읽고 그 결과로 무언가를 하기를 바라기 때문입니다. 만약 제안서를 읽는 사람이 프로젝트에 흥미를 갖지 못한다면, 프로젝트를 도와주려는 마음이 들지 않을 것입니다. 편집 툴을 설명하면서 다양한 기능, 고객이 사용하면 얻는 이점, 업계에 미칠 긍정적인 영향을 언급하지 않는다면, 청자는 프로젝트에 관심을 가져야 할 이유를 찾지 못합니다.
문제, 접근법, 해결책에 대해 자세히 설명해야 하지만, 프로젝트 제안서를 지나치게 복잡하게 만들면 안 됩니다. 즉, 엔지니어가 어떤 코드를 사용해 각 기능을 작동하도록 만들 것인지에 관해 논의를 하지 않고, 제안하는 편집 툴을 위한 프로젝트 계획을 논의할 수 있다는 의미입니다.
성공적인 프로젝트 제안서에는 철저한 조사 내용이 담겨 있습니다. 믿을 만한 출처, 사례 연구, 통계 자료 또는 차트를 사용하여 문제와 해결책의 근거를 준비하여 청자에게 의문이 남지 않도록 합니다. 제안서를 작성할 때, 제안서를 읽는 사람의 입장이 되어 자문해야 합니다.
이는 왜 문제인가?
이 해결책이 왜 해당 문제의 해결책인가?
이 문제를 이전에 다룬 사람이 있는가?
프로젝트의 비용은 얼마나 드는가?
위 질문에 답할 수 있다면, 제안한 이니셔티브를 지지할 충분한 근거를 조사한 것입니다.
좋은 프로젝트 제안서를 작성하려면 팀이 협업해야 합니다. 올바른 관리 툴을 사용하면 하나의 공유 문서에서 팀이 커뮤니케이션하고, 정보를 공유하고, 함께 협력할 수 있습니다.
프로젝트 데이터를 한 곳에 보관하면 필요할 때 쉽게 접근할 수 있습니다. 프로젝트 제안서는 잘 정리되고 알맞게 계획된 프로젝트에서 비롯됩니다. 그렇기에 프로젝트 관리 소프트웨어는 프로젝트 제안서를 작성하기 위한 핵심 리소스인 것입니다. 시작할 준비가 되었으면, Asana를 사용해 보세요.
프로젝트 관리를 위해 Asana를 사용해 보세요