A good Project Proposal explains the reasons why a project is needed, presents a plan of action, and attempts to persuade the reader (in a balanced and transparent way) that the proposed plan is the right plan to approve. It provides a solid foundation for the project to build on should it be approved, and brings all stakeholders to the same level of understanding on the project.
Project Proposals can be produced in response to a Request for Proposal. A Request for Proposal can be issued internally or externally to your organization. In less formal environments, you may find yourself writing a Project Proposal simply because your boss asked you to get working on a new project.
This article will provide a Project Proposal Template, highlighting the core elements which should be included, but you should tailor your own proposal by adding or removing sections/detail to match the needs of your audience and organization. There are 7 main sections you should consider including in your project proposal:
1. Introduction
Use this section to provide a broad introduction to the project, explaining in words why the project is needed, and providing any contextual background information which might help the reader.
2. Project Definition
You can think of this section as containing the “to-do list” for the project. It will typically be made up of the following sections:
2.1 Project Objectives
Project Objectives are the business benefits that the project is trying to achieve when it is complete. Objectives should be written so that at the end of the project it can be checked to see if they have been achieved. One way to do this is by using SMART objectives. It is also good practice to separate the main objectives of the project from those which are secondary or merely beneficial side effects.
2.2 Project Scope
This section defines in broad terms what the the scope (the work which needs to be done) of the project, and also explicitly calls out what is out of scope for the avoidance of doubt.
2.3 Deliverables
The Deliverables section can be thought of as drilling down in to the project scope to define in more detail what the outputs of the project will be. One excellent way to do this is by using a Work Breakdown Structure (WBS) to decompose the major deliverables into their constituent parts.
2.4 Plan & Timeline
The project plan should be built from the Work Breakdown Structure you put together in the previous section. It should show as a sequence the steps which need to be taken in order for the project to be completed. If you’re working with Agile then you may want to allocate themes to each of the R&D Sprints, as it will not be possible to produce as step by step plan. Here is a article to help you Plan Projects Quickly.
2.5 Assumptions
Any project assumptions made to create your your plan should be listed here to avoid misleading the reader of the proposal. For example, you may have assumed access to certain resources, or you may have assumed that the project can start right away. Without these assumptions being called out, your understanding of the proposal may be very different from the person who will approve the project.
3. Business Case
The Business Case simply lays out the reasoning for undertaking the project. It can be formal, or informal and brief. The best business cases will show both the quantifiable and unquantifiable justifications for the project. A typical Business Case will focus either on profit or strategic positioning, or sometimes both.
4. Quality Expectations
This section outlines the quality expectations from the customer and user perspective. It is important to precisely define quality expectations up front to avoid surprises later – you want to avoid the situation where everyone agrees the project will deliver a car as it’s final product, but you think you are delivering a Ford whereas the customer is expecting a BMW.
5. Acceptance Criteria
Here you describe in measurable terms the characteristics needed by the final deliverables for them to be acceptable to the customer and users. In many cases the Acceptance Criteria will be the same as the Quality Expectations, and so only one section is needed in the document.
6. Known Risks
Include any risks to project success you are aware of. You should think about what the risk is of the project being late, and what the risk is of the project running over budget, amongst others. Here is a Risk Checklist you can use to assist you in finding risks and creating this section.
7. Summary
Use this section to summarize all the key information vital to the proposal as succinctly as possible. This will include the need the project solves, a brief overview of the business case, the project timeline, and deliverables as a minimum.
You may want to include an executive summary in the document. This should be placed at the very front of the proposal but can only be written after the proposal is complete. The Executive Summary contains the same information as the Summary but typically in a bullet point fashion for those executives who are very short of time, or other parties interested in the proposal who do not have a major stake or interest in the project and so merely want to be kept abreast of the proposal.
Conclusion
As you have no doubt gathered, it takes time to write a Project Proposal. A good proposal provides in one place an overarching, balanced and transparent view as to the reasons to do the project, how the project would be done, and the risks involved. This information needs to be understood by the people who ultimately approve the project to proceed. However, the process of writing the Project Proposal also helps you, as the project manager, gain a deeper appreciation of the project and thus it helps you identify gaps in the project you may not have previously noticed.
